[4.9] GCC 4.9.0 official release refresh

Change-Id: Ic99a7da8b44b789a48aeec93b33e93944d6e6767

32 files changed, 171950 insertions, 57 deletions

diff --git a/gcc-4.9/gcc/doc/aot-compile.1 b/gcc-4.9/gcc/doc/aot-compile.1
new file mode 100644
index 000000000..1afeb5837
--- /dev/null
+++ b/gcc-4.9/gcc/doc/aot-compile.1
@@ -0,0 +1,209 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "AOT-COMPILE 1"
+.TH AOT-COMPILE 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+aot\-compile \- Compile bytecode to native and generate databases
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+aot-compile [\fB\s-1OPTION\s0\fR] ... \fI\s-1SRCDIR\s0\fR \fI\s-1DSTDIR\s0\fR
+.PP
+aot-compile [\fB\-M, \-\-make\fR=\fI\s-1PATH\s0\fR] [\fB\-C, \-\-gcj\fR=\fI\s-1PATH\s0\fR]
+  [\fB\-D, \-\-dbtool\fR=\fI\s-1PATH\s0\fR] [\fB\-m, \-\-makeflags\fR=\fI\s-1FLAGS\s0\fR] 
+  [\fB\-c, \-\-gcjflags\fR=\fI\s-1FLAGS\s0\fR] [\fB\-l, \-\-ldflags\fR=\fI\s-1FLAGS\s0\fR] 
+  [\fB\-e, \-\-exclude\fR=\fI\s-1PATH\s0\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\f(CW\*(C`aot\-compile\*(C'\fR is a script that searches a directory for Java bytecode
+(as class files, or in jars) and uses \f(CW\*(C`gcj\*(C'\fR to compile it to native
+code and generate the databases from it.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-M, \-\-make=\fR\fI\s-1PATH\s0\fR" 4
+.IX Item "-M, --make=PATH"
+Specify the path to the \f(CW\*(C`make\*(C'\fR executable to use.
+.IP "\fB\-C, \-\-gcj=\fR\fI\s-1PATH\s0\fR" 4
+.IX Item "-C, --gcj=PATH"
+Specify the path to the \f(CW\*(C`gcj\*(C'\fR executable to use.
+.IP "\fB\-D, \-\-dbtool=\fR\fI\s-1PATH\s0\fR" 4
+.IX Item "-D, --dbtool=PATH"
+Specify the path to the \f(CW\*(C`gcj\-dbtool\*(C'\fR executable to use.
+.IP "\fB\-m, \-\-makeflags=\fR\fI\s-1FLAGS\s0\fR" 4
+.IX Item "-m, --makeflags=FLAGS"
+Specify flags to pass to \f(CW\*(C`make\*(C'\fR during the build.
+.IP "\fB\-c, \-\-gcjflags=\fR\fI\s-1FLAGS\s0\fR" 4
+.IX Item "-c, --gcjflags=FLAGS"
+Specify flags to pass to \f(CW\*(C`gcj\*(C'\fR during compilation, in addition to
+\&'\-fPIC \-findirect\-dispatch \-fjni'.
+.IP "\fB\-l, \-\-ldflags=\fR\fI\s-1FLAGS\s0\fR" 4
+.IX Item "-l, --ldflags=FLAGS"
+Specify flags to pass to \f(CW\*(C`gcj\*(C'\fR during linking, in addition to
+\&'\-Wl,\-Bsymbolic'.
+.IP "\fB\-e, \-\-exclude=\fR\fI\s-1PATH\s0\fR" 4
+.IX Item "-e, --exclude=PATH"
+Do not compile \fI\s-1PATH\s0\fR.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgcc\fR\|(1), \fIgcj\fR\|(1), \fIgcjh\fR\|(1), \fIjcf\-dump\fR\|(1), \fIgfdl\fR\|(7),
+and the Info entries for \fIgcj\fR and \fIgcc\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/bugreport.texi b/gcc-4.9/gcc/doc/bugreport.texi
index be0352225..e465c24b0 100644
--- a/gcc-4.9/gcc/doc/bugreport.texi
+++ b/gcc-4.9/gcc/doc/bugreport.texi
@@ -16,11 +16,9 @@ report the problem.
 @menu
 * Criteria:  Bug Criteria.   Have you really found a bug?
 * Reporting: Bug Reporting.  How to report a bug effectively.
-* Known: Trouble.            Known problems.
-* Help: Service.             Where to ask for help.
 @end menu
 
-@node Bug Criteria,Bug Reporting,,Bugs
+@node Bug Criteria
 @section Have You Found a Bug?
 @cindex bug criteria
 
@@ -83,7 +81,7 @@ If you are an experienced user of one of the languages GCC supports, your
 suggestions for improvement of GCC are welcome in any case.
 @end itemize
 
-@node Bug Reporting,,Bug Criteria,Bugs
+@node Bug Reporting
 @section How and where to Report Bugs
 @cindex compiler bugs, reporting
 
diff --git a/gcc-4.9/gcc/doc/contrib.texi b/gcc-4.9/gcc/doc/contrib.texi
index b16fc1ffd..9117f8e29 100644
--- a/gcc-4.9/gcc/doc/contrib.texi
+++ b/gcc-4.9/gcc/doc/contrib.texi
@@ -1050,6 +1050,9 @@ Carlo Wood for various fixes.
 Tom Wood for work on the m88k port.
 
 @item
+Chung-Ju Wu for his work on the Andes NDS32 port.
+
+@item
 Canqun Yang for work on GNU Fortran.
 
 @item
diff --git a/gcc-4.9/gcc/doc/cpp.1 b/gcc-4.9/gcc/doc/cpp.1
new file mode 100644
index 000000000..0c34e8453
--- /dev/null
+++ b/gcc-4.9/gcc/doc/cpp.1
@@ -0,0 +1,1046 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "CPP 1"
+.TH CPP 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+cpp \- The C Preprocessor
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+cpp [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
+    [\fB\-I\fR\fIdir\fR...] [\fB\-iquote\fR\fIdir\fR...]
+    [\fB\-W\fR\fIwarn\fR...]
+    [\fB\-M\fR|\fB\-MM\fR] [\fB\-MG\fR] [\fB\-MF\fR \fIfilename\fR]
+    [\fB\-MP\fR] [\fB\-MQ\fR \fItarget\fR...]
+    [\fB\-MT\fR \fItarget\fR...]
+    [\fB\-P\fR] [\fB\-fno\-working\-directory\fR]
+    [\fB\-x\fR \fIlanguage\fR] [\fB\-std=\fR\fIstandard\fR]
+    \fIinfile\fR \fIoutfile\fR
+.PP
+Only the most useful options are listed here; see below for the remainder.
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The C preprocessor, often known as \fIcpp\fR, is a \fImacro processor\fR
+that is used automatically by the C compiler to transform your program
+before compilation.  It is called a macro processor because it allows
+you to define \fImacros\fR, which are brief abbreviations for longer
+constructs.
+.PP
+The C preprocessor is intended to be used only with C, \*(C+, and
+Objective-C source code.  In the past, it has been abused as a general
+text processor.  It will choke on input which does not obey C's lexical
+rules.  For example, apostrophes will be interpreted as the beginning of
+character constants, and cause errors.  Also, you cannot rely on it
+preserving characteristics of the input which are not significant to
+C\-family languages.  If a Makefile is preprocessed, all the hard tabs
+will be removed, and the Makefile will not work.
+.PP
+Having said that, you can often get away with using cpp on things which
+are not C.  Other Algol-ish programming languages are often safe
+(Pascal, Ada, etc.) So is assembly, with caution.  \fB\-traditional\-cpp\fR
+mode preserves more white space, and is otherwise more permissive.  Many
+of the problems can be avoided by writing C or \*(C+ style comments
+instead of native language comments, and keeping macros simple.
+.PP
+Wherever possible, you should use a preprocessor geared to the language
+you are writing in.  Modern versions of the \s-1GNU\s0 assembler have macro
+facilities.  Most high level programming languages have their own
+conditional compilation and inclusion mechanism.  If all else fails,
+try a true general text processor, such as \s-1GNU M4.\s0
+.PP
+C preprocessors vary in some details.  This manual discusses the \s-1GNU C\s0
+preprocessor, which provides a small superset of the features of \s-1ISO\s0
+Standard C.  In its default mode, the \s-1GNU C\s0 preprocessor does not do a
+few things required by the standard.  These are features which are
+rarely, if ever, used, and may cause surprising changes to the meaning
+of a program which does not expect them.  To get strict \s-1ISO\s0 Standard C,
+you should use the \fB\-std=c90\fR, \fB\-std=c99\fR or
+\&\fB\-std=c11\fR options, depending
+on which version of the standard you want.  To get all the mandatory
+diagnostics, you must also use \fB\-pedantic\fR.
+.PP
+This manual describes the behavior of the \s-1ISO\s0 preprocessor.  To
+minimize gratuitous differences, where the \s-1ISO\s0 preprocessor's
+behavior does not conflict with traditional semantics, the
+traditional preprocessor should behave the same way.  The various
+differences that do exist are detailed in the section \fBTraditional
+Mode\fR.
+.PP
+For clarity, unless noted otherwise, references to \fB\s-1CPP\s0\fR in this
+manual refer to \s-1GNU CPP.\s0
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+The C preprocessor expects two file names as arguments, \fIinfile\fR and
+\&\fIoutfile\fR.  The preprocessor reads \fIinfile\fR together with any
+other files it specifies with \fB#include\fR.  All the output generated
+by the combined input files is written in \fIoutfile\fR.
+.PP
+Either \fIinfile\fR or \fIoutfile\fR may be \fB\-\fR, which as
+\&\fIinfile\fR means to read from standard input and as \fIoutfile\fR
+means to write to standard output.  Also, if either file is omitted, it
+means the same as if \fB\-\fR had been specified for that file.
+.PP
+Unless otherwise noted, or the option ends in \fB=\fR, all options
+which take an argument may have that argument appear either immediately
+after the option, or with a space between option and argument:
+\&\fB\-Ifoo\fR and \fB\-I foo\fR have the same effect.
+.PP
+Many options have multi-letter names; therefore multiple single-letter
+options may \fInot\fR be grouped: \fB\-dM\fR is very different from
+\&\fB\-d\ \-M\fR.
+.IP "\fB\-D\fR \fIname\fR" 4
+.IX Item "-D name"
+Predefine \fIname\fR as a macro, with definition \f(CW1\fR.
+.IP "\fB\-D\fR \fIname\fR\fB=\fR\fIdefinition\fR" 4
+.IX Item "-D name=definition"
+The contents of \fIdefinition\fR are tokenized and processed as if
+they appeared during translation phase three in a \fB#define\fR
+directive.  In particular, the definition will be truncated by
+embedded newline characters.
+.Sp
+If you are invoking the preprocessor from a shell or shell-like
+program you may need to use the shell's quoting syntax to protect
+characters such as spaces that have a meaning in the shell syntax.
+.Sp
+If you wish to define a function-like macro on the command line, write
+its argument list with surrounding parentheses before the equals sign
+(if any).  Parentheses are meaningful to most shells, so you will need
+to quote the option.  With \fBsh\fR and \fBcsh\fR,
+\&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
+.Sp
+\&\fB\-D\fR and \fB\-U\fR options are processed in the order they
+are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
+\&\fB\-include\fR \fIfile\fR options are processed after all
+\&\fB\-D\fR and \fB\-U\fR options.
+.IP "\fB\-U\fR \fIname\fR" 4
+.IX Item "-U name"
+Cancel any previous definition of \fIname\fR, either built in or
+provided with a \fB\-D\fR option.
+.IP "\fB\-undef\fR" 4
+.IX Item "-undef"
+Do not predefine any system-specific or GCC-specific macros.  The
+standard predefined macros remain defined.
+.IP "\fB\-I\fR \fIdir\fR" 4
+.IX Item "-I dir"
+Add the directory \fIdir\fR to the list of directories to be searched
+for header files.
+.Sp
+Directories named by \fB\-I\fR are searched before the standard
+system include directories.  If the directory \fIdir\fR is a standard
+system include directory, the option is ignored to ensure that the
+default search order for system directories and the special treatment
+of system headers are not defeated
+\&.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-o\fR \fIfile\fR" 4
+.IX Item "-o file"
+Write output to \fIfile\fR.  This is the same as specifying \fIfile\fR
+as the second non-option argument to \fBcpp\fR.  \fBgcc\fR has a
+different interpretation of a second non-option argument, so you must
+use \fB\-o\fR to specify the output file.
+.IP "\fB\-Wall\fR" 4
+.IX Item "-Wall"
+Turns on all optional warnings which are desirable for normal code.
+At present this is \fB\-Wcomment\fR, \fB\-Wtrigraphs\fR,
+\&\fB\-Wmultichar\fR and a warning about integer promotion causing a
+change of sign in \f(CW\*(C`#if\*(C'\fR expressions.  Note that many of the
+preprocessor's warnings are on by default and have no options to
+control them.
+.IP "\fB\-Wcomment\fR" 4
+.IX Item "-Wcomment"
+.PD 0
+.IP "\fB\-Wcomments\fR" 4
+.IX Item "-Wcomments"
+.PD
+Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
+comment, or whenever a backslash-newline appears in a \fB//\fR comment.
+(Both forms have the same effect.)
+.IP "\fB\-Wtrigraphs\fR" 4
+.IX Item "-Wtrigraphs"
+Most trigraphs in comments cannot affect the meaning of the program.
+However, a trigraph that would form an escaped newline (\fB??/\fR at
+the end of a line) can, by changing where the comment begins or ends.
+Therefore, only trigraphs that would form escaped newlines produce
+warnings inside a comment.
+.Sp
+This option is implied by \fB\-Wall\fR.  If \fB\-Wall\fR is not
+given, this option is still enabled unless trigraphs are enabled.  To
+get trigraph conversion without warnings, but get the other
+\&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
+.IP "\fB\-Wtraditional\fR" 4
+.IX Item "-Wtraditional"
+Warn about certain constructs that behave differently in traditional and
+\&\s-1ISO C. \s0 Also warn about \s-1ISO C\s0 constructs that have no traditional C
+equivalent, and problematic constructs which should be avoided.
+.IP "\fB\-Wundef\fR" 4
+.IX Item "-Wundef"
+Warn whenever an identifier which is not a macro is encountered in an
+\&\fB#if\fR directive, outside of \fBdefined\fR.  Such identifiers are
+replaced with zero.
+.IP "\fB\-Wunused\-macros\fR" 4
+.IX Item "-Wunused-macros"
+Warn about macros defined in the main file that are unused.  A macro
+is \fIused\fR if it is expanded or tested for existence at least once.
+The preprocessor will also warn if the macro has not been used at the
+time it is redefined or undefined.
+.Sp
+Built-in macros, macros defined on the command line, and macros
+defined in include files are not warned about.
+.Sp
+\&\fINote:\fR If a macro is actually used, but only used in skipped
+conditional blocks, then \s-1CPP\s0 will report it as unused.  To avoid the
+warning in such a case, you might improve the scope of the macro's
+definition by, for example, moving it into the first skipped block.
+Alternatively, you could provide a dummy use with something like:
+.Sp
+.Vb 2
+\&        #if defined the_macro_causing_the_warning
+\&        #endif
+.Ve
+.IP "\fB\-Wendif\-labels\fR" 4
+.IX Item "-Wendif-labels"
+Warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
+This usually happens in code of the form
+.Sp
+.Vb 5
+\&        #if FOO
+\&        ...
+\&        #else FOO
+\&        ...
+\&        #endif FOO
+.Ve
+.Sp
+The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments, but often are not
+in older programs.  This warning is on by default.
+.IP "\fB\-Werror\fR" 4
+.IX Item "-Werror"
+Make all warnings into hard errors.  Source code which triggers warnings
+will be rejected.
+.IP "\fB\-Wsystem\-headers\fR" 4
+.IX Item "-Wsystem-headers"
+Issue warnings for code in system headers.  These are normally unhelpful
+in finding bugs in your own code, therefore suppressed.  If you are
+responsible for the system library, you may want to see them.
+.IP "\fB\-w\fR" 4
+.IX Item "-w"
+Suppress all warnings, including those which \s-1GNU CPP\s0 issues by default.
+.IP "\fB\-pedantic\fR" 4
+.IX Item "-pedantic"
+Issue all the mandatory diagnostics listed in the C standard.  Some of
+them are left out by default, since they trigger frequently on harmless
+code.
+.IP "\fB\-pedantic\-errors\fR" 4
+.IX Item "-pedantic-errors"
+Issue all the mandatory diagnostics, and make all mandatory diagnostics
+into errors.  This includes mandatory diagnostics that \s-1GCC\s0 issues
+without \fB\-pedantic\fR but treats as warnings.
+.IP "\fB\-M\fR" 4
+.IX Item "-M"
+Instead of outputting the result of preprocessing, output a rule
+suitable for \fBmake\fR describing the dependencies of the main
+source file.  The preprocessor outputs one \fBmake\fR rule containing
+the object file name for that source file, a colon, and the names of all
+the included files, including those coming from \fB\-include\fR or
+\&\fB\-imacros\fR command line options.
+.Sp
+Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
+object file name consists of the name of the source file with any
+suffix replaced with object file suffix and with any leading directory
+parts removed.  If there are many included files then the rule is
+split into several lines using \fB\e\fR\-newline.  The rule has no
+commands.
+.Sp
+This option does not suppress the preprocessor's debug output, such as
+\&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
+rules you should explicitly specify the dependency output file with
+\&\fB\-MF\fR, or use an environment variable like
+\&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR.  Debug output
+will still be sent to the regular output stream as normal.
+.Sp
+Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
+warnings with an implicit \fB\-w\fR.
+.IP "\fB\-MM\fR" 4
+.IX Item "-MM"
+Like \fB\-M\fR but do not mention header files that are found in
+system header directories, nor header files that are included,
+directly or indirectly, from such a header.
+.Sp
+This implies that the choice of angle brackets or double quotes in an
+\&\fB#include\fR directive does not in itself determine whether that
+header will appear in \fB\-MM\fR dependency output.  This is a
+slight change in semantics from \s-1GCC\s0 versions 3.0 and earlier.
+.IP "\fB\-MF\fR \fIfile\fR" 4
+.IX Item "-MF file"
+When used with \fB\-M\fR or \fB\-MM\fR, specifies a
+file to write the dependencies to.  If no \fB\-MF\fR switch is given
+the preprocessor sends the rules to the same place it would have sent
+preprocessed output.
+.Sp
+When used with the driver options \fB\-MD\fR or \fB\-MMD\fR,
+\&\fB\-MF\fR overrides the default dependency output file.
+.IP "\fB\-MG\fR" 4
+.IX Item "-MG"
+In conjunction with an option such as \fB\-M\fR requesting
+dependency generation, \fB\-MG\fR assumes missing header files are
+generated files and adds them to the dependency list without raising
+an error.  The dependency filename is taken directly from the
+\&\f(CW\*(C`#include\*(C'\fR directive without prepending any path.  \fB\-MG\fR
+also suppresses preprocessed output, as a missing header file renders
+this useless.
+.Sp
+This feature is used in automatic updating of makefiles.
+.IP "\fB\-MP\fR" 4
+.IX Item "-MP"
+This option instructs \s-1CPP\s0 to add a phony target for each dependency
+other than the main file, causing each to depend on nothing.  These
+dummy rules work around errors \fBmake\fR gives if you remove header
+files without updating the \fIMakefile\fR to match.
+.Sp
+This is typical output:
+.Sp
+.Vb 1
+\&        test.o: test.c test.h
+\&        
+\&        test.h:
+.Ve
+.IP "\fB\-MT\fR \fItarget\fR" 4
+.IX Item "-MT target"
+Change the target of the rule emitted by dependency generation.  By
+default \s-1CPP\s0 takes the name of the main input file, deletes any
+directory components and any file suffix such as \fB.c\fR, and
+appends the platform's usual object suffix.  The result is the target.
+.Sp
+An \fB\-MT\fR option will set the target to be exactly the string you
+specify.  If you want multiple targets, you can specify them as a single
+argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
+.Sp
+For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
+.Sp
+.Vb 1
+\&        $(objpfx)foo.o: foo.c
+.Ve
+.IP "\fB\-MQ\fR \fItarget\fR" 4
+.IX Item "-MQ target"
+Same as \fB\-MT\fR, but it quotes any characters which are special to
+Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR gives
+.Sp
+.Vb 1
+\&        $$(objpfx)foo.o: foo.c
+.Ve
+.Sp
+The default target is automatically quoted, as if it were given with
+\&\fB\-MQ\fR.
+.IP "\fB\-MD\fR" 4
+.IX Item "-MD"
+\&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
+\&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
+whether an \fB\-o\fR option is given.  If it is, the driver uses its
+argument but with a suffix of \fI.d\fR, otherwise it takes the name
+of the input file, removes any directory components and suffix, and
+applies a \fI.d\fR suffix.
+.Sp
+If \fB\-MD\fR is used in conjunction with \fB\-E\fR, any
+\&\fB\-o\fR switch is understood to specify the dependency output file, but if used without \fB\-E\fR, each \fB\-o\fR
+is understood to specify a target object file.
+.Sp
+Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
+a dependency output file as a side-effect of the compilation process.
+.IP "\fB\-MMD\fR" 4
+.IX Item "-MMD"
+Like \fB\-MD\fR except mention only user header files, not system
+header files.
+.IP "\fB\-x c\fR" 4
+.IX Item "-x c"
+.PD 0
+.IP "\fB\-x c++\fR" 4
+.IX Item "-x c++"
+.IP "\fB\-x objective-c\fR" 4
+.IX Item "-x objective-c"
+.IP "\fB\-x assembler-with-cpp\fR" 4
+.IX Item "-x assembler-with-cpp"
+.PD
+Specify the source language: C, \*(C+, Objective-C, or assembly.  This has
+nothing to do with standards conformance or extensions; it merely
+selects which base syntax to expect.  If you give none of these options,
+cpp will deduce the language from the extension of the source file:
+\&\fB.c\fR, \fB.cc\fR, \fB.m\fR, or \fB.S\fR.  Some other common
+extensions for \*(C+ and assembly are also recognized.  If cpp does not
+recognize the extension, it will treat the file as C; this is the most
+generic mode.
+.Sp
+\&\fINote:\fR Previous versions of cpp accepted a \fB\-lang\fR option
+which selected both the language and the standards conformance level.
+This option has been removed, because it conflicts with the \fB\-l\fR
+option.
+.IP "\fB\-std=\fR\fIstandard\fR" 4
+.IX Item "-std=standard"
+.PD 0
+.IP "\fB\-ansi\fR" 4
+.IX Item "-ansi"
+.PD
+Specify the standard to which the code should conform.  Currently \s-1CPP\s0
+knows about C and \*(C+ standards; others may be added in the future.
+.Sp
+\&\fIstandard\fR
+may be one of:
+.RS 4
+.ie n .IP """c90""" 4
+.el .IP "\f(CWc90\fR" 4
+.IX Item "c90"
+.PD 0
+.ie n .IP """c89""" 4
+.el .IP "\f(CWc89\fR" 4
+.IX Item "c89"
+.ie n .IP """iso9899:1990""" 4
+.el .IP "\f(CWiso9899:1990\fR" 4
+.IX Item "iso9899:1990"
+.PD
+The \s-1ISO C\s0 standard from 1990.  \fBc90\fR is the customary shorthand for
+this version of the standard.
+.Sp
+The \fB\-ansi\fR option is equivalent to \fB\-std=c90\fR.
+.ie n .IP """iso9899:199409""" 4
+.el .IP "\f(CWiso9899:199409\fR" 4
+.IX Item "iso9899:199409"
+The 1990 C standard, as amended in 1994.
+.ie n .IP """iso9899:1999""" 4
+.el .IP "\f(CWiso9899:1999\fR" 4
+.IX Item "iso9899:1999"
+.PD 0
+.ie n .IP """c99""" 4
+.el .IP "\f(CWc99\fR" 4
+.IX Item "c99"
+.ie n .IP """iso9899:199x""" 4
+.el .IP "\f(CWiso9899:199x\fR" 4
+.IX Item "iso9899:199x"
+.ie n .IP """c9x""" 4
+.el .IP "\f(CWc9x\fR" 4
+.IX Item "c9x"
+.PD
+The revised \s-1ISO C\s0 standard, published in December 1999.  Before
+publication, this was known as C9X.
+.ie n .IP """iso9899:2011""" 4
+.el .IP "\f(CWiso9899:2011\fR" 4
+.IX Item "iso9899:2011"
+.PD 0
+.ie n .IP """c11""" 4
+.el .IP "\f(CWc11\fR" 4
+.IX Item "c11"
+.ie n .IP """c1x""" 4
+.el .IP "\f(CWc1x\fR" 4
+.IX Item "c1x"
+.PD
+The revised \s-1ISO C\s0 standard, published in December 2011.  Before
+publication, this was known as C1X.
+.ie n .IP """gnu90""" 4
+.el .IP "\f(CWgnu90\fR" 4
+.IX Item "gnu90"
+.PD 0
+.ie n .IP """gnu89""" 4
+.el .IP "\f(CWgnu89\fR" 4
+.IX Item "gnu89"
+.PD
+The 1990 C standard plus \s-1GNU\s0 extensions.  This is the default.
+.ie n .IP """gnu99""" 4
+.el .IP "\f(CWgnu99\fR" 4
+.IX Item "gnu99"
+.PD 0
+.ie n .IP """gnu9x""" 4
+.el .IP "\f(CWgnu9x\fR" 4
+.IX Item "gnu9x"
+.PD
+The 1999 C standard plus \s-1GNU\s0 extensions.
+.ie n .IP """gnu11""" 4
+.el .IP "\f(CWgnu11\fR" 4
+.IX Item "gnu11"
+.PD 0
+.ie n .IP """gnu1x""" 4
+.el .IP "\f(CWgnu1x\fR" 4
+.IX Item "gnu1x"
+.PD
+The 2011 C standard plus \s-1GNU\s0 extensions.
+.ie n .IP """c++98""" 4
+.el .IP "\f(CWc++98\fR" 4
+.IX Item "c++98"
+The 1998 \s-1ISO \*(C+\s0 standard plus amendments.
+.ie n .IP """gnu++98""" 4
+.el .IP "\f(CWgnu++98\fR" 4
+.IX Item "gnu++98"
+The same as \fB\-std=c++98\fR plus \s-1GNU\s0 extensions.  This is the
+default for \*(C+ code.
+.RE
+.RS 4
+.RE
+.IP "\fB\-I\-\fR" 4
+.IX Item "-I-"
+Split the include path.  Any directories specified with \fB\-I\fR
+options before \fB\-I\-\fR are searched only for headers requested with
+\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
+\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR.  If additional directories are
+specified with \fB\-I\fR options after the \fB\-I\-\fR, those
+directories are searched for all \fB#include\fR directives.
+.Sp
+In addition, \fB\-I\-\fR inhibits the use of the directory of the current
+file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
+.Sp
+This option has been deprecated.
+.IP "\fB\-nostdinc\fR" 4
+.IX Item "-nostdinc"
+Do not search the standard system directories for header files.
+Only the directories you have specified with \fB\-I\fR options
+(and the directory of the current file, if appropriate) are searched.
+.IP "\fB\-nostdinc++\fR" 4
+.IX Item "-nostdinc++"
+Do not search for header files in the \*(C+\-specific standard directories,
+but do still search the other standard directories.  (This option is
+used when building the \*(C+ library.)
+.IP "\fB\-include\fR \fIfile\fR" 4
+.IX Item "-include file"
+Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
+line of the primary source file.  However, the first directory searched
+for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
+the directory containing the main source file.  If not found there, it
+is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
+chain as normal.
+.Sp
+If multiple \fB\-include\fR options are given, the files are included
+in the order they appear on the command line.
+.IP "\fB\-imacros\fR \fIfile\fR" 4
+.IX Item "-imacros file"
+Exactly like \fB\-include\fR, except that any output produced by
+scanning \fIfile\fR is thrown away.  Macros it defines remain defined.
+This allows you to acquire all the macros from a header without also
+processing its declarations.
+.Sp
+All files specified by \fB\-imacros\fR are processed before all files
+specified by \fB\-include\fR.
+.IP "\fB\-idirafter\fR \fIdir\fR" 4
+.IX Item "-idirafter dir"
+Search \fIdir\fR for header files, but do it \fIafter\fR all
+directories specified with \fB\-I\fR and the standard system directories
+have been exhausted.  \fIdir\fR is treated as a system include directory.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-iprefix\fR \fIprefix\fR" 4
+.IX Item "-iprefix prefix"
+Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
+options.  If the prefix represents a directory, you should include the
+final \fB/\fR.
+.IP "\fB\-iwithprefix\fR \fIdir\fR" 4
+.IX Item "-iwithprefix dir"
+.PD 0
+.IP "\fB\-iwithprefixbefore\fR \fIdir\fR" 4
+.IX Item "-iwithprefixbefore dir"
+.PD
+Append \fIdir\fR to the prefix specified previously with
+\&\fB\-iprefix\fR, and add the resulting directory to the include search
+path.  \fB\-iwithprefixbefore\fR puts it in the same place \fB\-I\fR
+would; \fB\-iwithprefix\fR puts it where \fB\-idirafter\fR would.
+.IP "\fB\-isysroot\fR \fIdir\fR" 4
+.IX Item "-isysroot dir"
+This option is like the \fB\-\-sysroot\fR option, but applies only to
+header files (except for Darwin targets, where it applies to both header
+files and libraries).  See the \fB\-\-sysroot\fR option for more
+information.
+.IP "\fB\-imultilib\fR \fIdir\fR" 4
+.IX Item "-imultilib dir"
+Use \fIdir\fR as a subdirectory of the directory containing
+target-specific \*(C+ headers.
+.IP "\fB\-isystem\fR \fIdir\fR" 4
+.IX Item "-isystem dir"
+Search \fIdir\fR for header files, after all directories specified by
+\&\fB\-I\fR but before the standard system directories.  Mark it
+as a system directory, so that it gets the same special treatment as
+is applied to the standard system directories.
+.Sp
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-iquote\fR \fIdir\fR" 4
+.IX Item "-iquote dir"
+Search \fIdir\fR only for header files requested with
+\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
+\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR, before all directories specified by
+\&\fB\-I\fR and before the standard system directories.
+.Sp
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-fdirectives\-only\fR" 4
+.IX Item "-fdirectives-only"
+When preprocessing, handle directives, but do not expand macros.
+.Sp
+The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
+options.
+.Sp
+With \fB\-E\fR, preprocessing is limited to the handling of directives
+such as \f(CW\*(C`#define\*(C'\fR, \f(CW\*(C`#ifdef\*(C'\fR, and \f(CW\*(C`#error\*(C'\fR.  Other
+preprocessor operations, such as macro expansion and trigraph
+conversion are not performed.  In addition, the \fB\-dD\fR option is
+implicitly enabled.
+.Sp
+With \fB\-fpreprocessed\fR, predefinition of command line and most
+builtin macros is disabled.  Macros such as \f(CW\*(C`_\|_LINE_\|_\*(C'\fR, which are
+contextually dependent, are handled normally.  This enables compilation of
+files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
+.Sp
+With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
+\&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
+files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
+.IP "\fB\-fdollars\-in\-identifiers\fR" 4
+.IX Item "-fdollars-in-identifiers"
+Accept \fB$\fR in identifiers.
+.IP "\fB\-fextended\-identifiers\fR" 4
+.IX Item "-fextended-identifiers"
+Accept universal character names in identifiers.  This option is
+experimental; in a future version of \s-1GCC,\s0 it will be enabled by
+default for C99 and \*(C+.
+.IP "\fB\-fno\-canonical\-system\-headers\fR" 4
+.IX Item "-fno-canonical-system-headers"
+When preprocessing, do not shorten system header paths with canonicalization.
+.IP "\fB\-fpreprocessed\fR" 4
+.IX Item "-fpreprocessed"
+Indicate to the preprocessor that the input file has already been
+preprocessed.  This suppresses things like macro expansion, trigraph
+conversion, escaped newline splicing, and processing of most directives.
+The preprocessor still recognizes and removes comments, so that you can
+pass a file preprocessed with \fB\-C\fR to the compiler without
+problems.  In this mode the integrated preprocessor is little more than
+a tokenizer for the front ends.
+.Sp
+\&\fB\-fpreprocessed\fR is implicit if the input file has one of the
+extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
+extensions that \s-1GCC\s0 uses for preprocessed files created by
+\&\fB\-save\-temps\fR.
+.IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
+.IX Item "-ftabstop=width"
+Set the distance between tab stops.  This helps the preprocessor report
+correct column numbers in warnings or errors, even if tabs appear on the
+line.  If the value is less than 1 or greater than 100, the option is
+ignored.  The default is 8.
+.IP "\fB\-fdebug\-cpp\fR" 4
+.IX Item "-fdebug-cpp"
+This option is only useful for debugging \s-1GCC. \s0 When used with
+\&\fB\-E\fR, dumps debugging information about location maps.  Every
+token in the output is preceded by the dump of the map its location
+belongs to.  The dump of the map holding the location of a token would
+be:
+.Sp
+.Vb 1
+\&        {"P":F</file/path>;"F":F</includer/path>;"L":<line_num>;"C":<col_num>;"S":<system_header_p>;"M":<map_address>;"E":<macro_expansion_p>,"loc":<location>}
+.Ve
+.Sp
+When used without \fB\-E\fR, this option has no effect.
+.IP "\fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR]" 4
+.IX Item "-ftrack-macro-expansion[=level]"
+Track locations of tokens across macro expansions. This allows the
+compiler to emit diagnostic about the current macro expansion stack
+when a compilation error occurs in a macro expansion. Using this
+option makes the preprocessor and the compiler consume more
+memory. The \fIlevel\fR parameter can be used to choose the level of
+precision of token location tracking thus decreasing the memory
+consumption if necessary. Value \fB0\fR of \fIlevel\fR de-activates
+this option just as if no \fB\-ftrack\-macro\-expansion\fR was present
+on the command line. Value \fB1\fR tracks tokens locations in a
+degraded mode for the sake of minimal memory overhead. In this mode
+all tokens resulting from the expansion of an argument of a
+function-like macro have the same location. Value \fB2\fR tracks
+tokens locations completely. This value is the most memory hungry.
+When this option is given no argument, the default parameter value is
+\&\fB2\fR.
+.Sp
+Note that \-ftrack\-macro\-expansion=2 is activated by default.
+.IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
+.IX Item "-fexec-charset=charset"
+Set the execution character set, used for string and character
+constants.  The default is \s-1UTF\-8.  \s0\fIcharset\fR can be any encoding
+supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
+.IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
+.IX Item "-fwide-exec-charset=charset"
+Set the wide execution character set, used for wide string and
+character constants.  The default is \s-1UTF\-32\s0 or \s-1UTF\-16,\s0 whichever
+corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR.  As with
+\&\fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
+by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
+problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
+.IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
+.IX Item "-finput-charset=charset"
+Set the input character set, used for translation from the character
+set of the input file to the source character set used by \s-1GCC. \s0 If the
+locale does not specify, or \s-1GCC\s0 cannot get this information from the
+locale, the default is \s-1UTF\-8. \s0 This can be overridden by either the locale
+or this command line option.  Currently the command line option takes
+precedence if there's a conflict.  \fIcharset\fR can be any encoding
+supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
+.IP "\fB\-fworking\-directory\fR" 4
+.IX Item "-fworking-directory"
+Enable generation of linemarkers in the preprocessor output that will
+let the compiler know the current working directory at the time of
+preprocessing.  When this option is enabled, the preprocessor will
+emit, after the initial linemarker, a second linemarker with the
+current working directory followed by two slashes.  \s-1GCC\s0 will use this
+directory, when it's present in the preprocessed input, as the
+directory emitted as the current working directory in some debugging
+information formats.  This option is implicitly enabled if debugging
+information is enabled, but this can be inhibited with the negated
+form \fB\-fno\-working\-directory\fR.  If the \fB\-P\fR flag is
+present in the command line, this option has no effect, since no
+\&\f(CW\*(C`#line\*(C'\fR directives are emitted whatsoever.
+.IP "\fB\-fno\-show\-column\fR" 4
+.IX Item "-fno-show-column"
+Do not print column numbers in diagnostics.  This may be necessary if
+diagnostics are being scanned by a program that does not understand the
+column numbers, such as \fBdejagnu\fR.
+.IP "\fB\-A\fR \fIpredicate\fR\fB=\fR\fIanswer\fR" 4
+.IX Item "-A predicate=answer"
+Make an assertion with the predicate \fIpredicate\fR and answer
+\&\fIanswer\fR.  This form is preferred to the older form \fB\-A\fR
+\&\fIpredicate\fR\fB(\fR\fIanswer\fR\fB)\fR, which is still supported, because
+it does not use shell special characters.
+.IP "\fB\-A \-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
+.IX Item "-A -predicate=answer"
+Cancel an assertion with the predicate \fIpredicate\fR and answer
+\&\fIanswer\fR.
+.IP "\fB\-dCHARS\fR" 4
+.IX Item "-dCHARS"
+\&\fI\s-1CHARS\s0\fR is a sequence of one or more of the following characters,
+and must not be preceded by a space.  Other characters are interpreted
+by the compiler proper, or reserved for future versions of \s-1GCC,\s0 and so
+are silently ignored.  If you specify characters whose behavior
+conflicts, the result is undefined.
+.RS 4
+.IP "\fBM\fR" 4
+.IX Item "M"
+Instead of the normal output, generate a list of \fB#define\fR
+directives for all the macros defined during the execution of the
+preprocessor, including predefined macros.  This gives you a way of
+finding out what is predefined in your version of the preprocessor.
+Assuming you have no file \fIfoo.h\fR, the command
+.Sp
+.Vb 1
+\&        touch foo.h; cpp \-dM foo.h
+.Ve
+.Sp
+will show all the predefined macros.
+.Sp
+If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
+interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
+.IP "\fBD\fR" 4
+.IX Item "D"
+Like \fBM\fR except in two respects: it does \fInot\fR include the
+predefined macros, and it outputs \fIboth\fR the \fB#define\fR
+directives and the result of preprocessing.  Both kinds of output go to
+the standard output file.
+.IP "\fBN\fR" 4
+.IX Item "N"
+Like \fBD\fR, but emit only the macro names, not their expansions.
+.IP "\fBI\fR" 4
+.IX Item "I"
+Output \fB#include\fR directives in addition to the result of
+preprocessing.
+.IP "\fBU\fR" 4
+.IX Item "U"
+Like \fBD\fR except that only macros that are expanded, or whose
+definedness is tested in preprocessor directives, are output; the
+output is delayed until the use or test of the macro; and
+\&\fB#undef\fR directives are also output for macros tested but
+undefined at the time.
+.RE
+.RS 4
+.RE
+.IP "\fB\-P\fR" 4
+.IX Item "-P"
+Inhibit generation of linemarkers in the output from the preprocessor.
+This might be useful when running the preprocessor on something that is
+not C code, and will be sent to a program which might be confused by the
+linemarkers.
+.IP "\fB\-C\fR" 4
+.IX Item "-C"
+Do not discard comments.  All comments are passed through to the output
+file, except for comments in processed directives, which are deleted
+along with the directive.
+.Sp
+You should be prepared for side effects when using \fB\-C\fR; it
+causes the preprocessor to treat comments as tokens in their own right.
+For example, comments appearing at the start of what would be a
+directive line have the effect of turning that line into an ordinary
+source line, since the first token on the line is no longer a \fB#\fR.
+.IP "\fB\-CC\fR" 4
+.IX Item "-CC"
+Do not discard comments, including during macro expansion.  This is
+like \fB\-C\fR, except that comments contained within macros are
+also passed through to the output file where the macro is expanded.
+.Sp
+In addition to the side-effects of the \fB\-C\fR option, the
+\&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
+to be converted to C\-style comments.  This is to prevent later use
+of that macro from inadvertently commenting out the remainder of
+the source line.
+.Sp
+The \fB\-CC\fR option is generally used to support lint comments.
+.IP "\fB\-traditional\-cpp\fR" 4
+.IX Item "-traditional-cpp"
+Try to imitate the behavior of old-fashioned C preprocessors, as
+opposed to \s-1ISO C\s0 preprocessors.
+.IP "\fB\-trigraphs\fR" 4
+.IX Item "-trigraphs"
+Process trigraph sequences.
+.IP "\fB\-remap\fR" 4
+.IX Item "-remap"
+Enable special code to work around file systems which only permit very
+short file names, such as MS-DOS.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+.PD 0
+.IP "\fB\-\-target\-help\fR" 4
+.IX Item "--target-help"
+.PD
+Print text describing all the command line options instead of
+preprocessing anything.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+Verbose mode.  Print out \s-1GNU CPP\s0's version number at the beginning of
+execution, and report the final form of the include path.
+.IP "\fB\-H\fR" 4
+.IX Item "-H"
+Print the name of each header file used, in addition to other normal
+activities.  Each name is indented to show how deep in the
+\&\fB#include\fR stack it is.  Precompiled header files are also
+printed, even if they are found to be invalid; an invalid precompiled
+header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
+.IP "\fB\-version\fR" 4
+.IX Item "-version"
+.PD 0
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+.PD
+Print out \s-1GNU CPP\s0's version number.  With one dash, proceed to
+preprocess as normal.  With two dashes, exit immediately.
+.SH "ENVIRONMENT"
+.IX Header "ENVIRONMENT"
+This section describes the environment variables that affect how \s-1CPP\s0
+operates.  You can use them to specify directories or prefixes to use
+when searching for include files, or to control dependency output.
+.PP
+Note that you can also specify places to search using options such as
+\&\fB\-I\fR, and control dependency output with options like
+\&\fB\-M\fR.  These take precedence over
+environment variables, which in turn take precedence over the
+configuration of \s-1GCC.\s0
+.IP "\fB\s-1CPATH\s0\fR" 4
+.IX Item "CPATH"
+.PD 0
+.IP "\fBC_INCLUDE_PATH\fR" 4
+.IX Item "C_INCLUDE_PATH"
+.IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
+.IX Item "CPLUS_INCLUDE_PATH"
+.IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
+.IX Item "OBJC_INCLUDE_PATH"
+.PD
+Each variable's value is a list of directories separated by a special
+character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
+The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
+determined at \s-1GCC\s0 build time.  For Microsoft Windows-based targets it is a
+semicolon, and for almost all other targets it is a colon.
+.Sp
+\&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
+specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
+options on the command line.  This environment variable is used
+regardless of which language is being preprocessed.
+.Sp
+The remaining environment variables apply only when preprocessing the
+particular language indicated.  Each specifies a list of directories
+to be searched as if specified with \fB\-isystem\fR, but after any
+paths given with \fB\-isystem\fR options on the command line.
+.Sp
+In all these variables, an empty element instructs the compiler to
+search its current working directory.  Empty elements can appear at the
+beginning or end of a path.  For instance, if the value of
+\&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
+effect as \fB\-I.\ \-I/special/include\fR.
+.IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
+.IX Item "DEPENDENCIES_OUTPUT"
+If this variable is set, its value specifies how to output
+dependencies for Make based on the non-system header files processed
+by the compiler.  System header files are ignored in the dependency
+output.
+.Sp
+The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
+which case the Make rules are written to that file, guessing the target
+name from the source file name.  Or the value can have the form
+\&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
+file \fIfile\fR using \fItarget\fR as the target name.
+.Sp
+In other words, this environment variable is equivalent to combining
+the options \fB\-MM\fR and \fB\-MF\fR,
+with an optional \fB\-MT\fR switch too.
+.IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
+.IX Item "SUNPRO_DEPENDENCIES"
+This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
+except that system header files are not ignored, so it implies
+\&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
+main input file is omitted.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7),
+\&\fIgcc\fR\|(1), \fIas\fR\|(1), \fIld\fR\|(1), and the Info entries for \fIcpp\fR, \fIgcc\fR, and
+\&\fIbinutils\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 1987\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation.  A copy of
+the license is included in the
+man page \fIgfdl\fR\|(7).
+This manual contains no Invariant Sections.  The Front-Cover Texts are
+(a) (see below), and the Back-Cover Texts are (b) (see below).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/cpp.info b/gcc-4.9/gcc/doc/cpp.info
new file mode 100644
index 000000000..dcb300666
--- /dev/null
+++ b/gcc-4.9/gcc/doc/cpp.info
@@ -0,0 +1,5602 @@
+This is cpp.info, produced by makeinfo version 5.1 from cpp.texi.
+
+Copyright (C) 1987-2014 Free Software Foundation, Inc.
+
+   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.  A copy of
+the license is included in the section entitled "GNU Free Documentation
+License".
+
+   This manual contains no Invariant Sections.  The Front-Cover Texts
+are (a) (see below), and the Back-Cover Texts are (b) (see below).
+
+   (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.
+INFO-DIR-SECTION Software development
+START-INFO-DIR-ENTRY
+* Cpp: (cpp).                  The GNU C preprocessor.
+END-INFO-DIR-ENTRY
+
+
+File: cpp.info,  Node: Top,  Next: Overview,  Up: (dir)
+
+The C Preprocessor
+******************
+
+The C preprocessor implements the macro language used to transform C,
+C++, and Objective-C programs before they are compiled.  It can also be
+useful on its own.
+
+* Menu:
+
+* Overview::
+* Header Files::
+* Macros::
+* Conditionals::
+* Diagnostics::
+* Line Control::
+* Pragmas::
+* Other Directives::
+* Preprocessor Output::
+* Traditional Mode::
+* Implementation Details::
+* Invocation::
+* Environment Variables::
+* GNU Free Documentation License::
+* Index of Directives::
+* Option Index::
+* Concept Index::
+
+ -- The Detailed Node Listing --
+
+Overview
+
+* Character sets::
+* Initial processing::
+* Tokenization::
+* The preprocessing language::
+
+Header Files
+
+* Include Syntax::
+* Include Operation::
+* Search Path::
+* Once-Only Headers::
+* Alternatives to Wrapper #ifndef::
+* Computed Includes::
+* Wrapper Headers::
+* System Headers::
+
+Macros
+
+* Object-like Macros::
+* Function-like Macros::
+* Macro Arguments::
+* Stringification::
+* Concatenation::
+* Variadic Macros::
+* Predefined Macros::
+* Undefining and Redefining Macros::
+* Directives Within Macro Arguments::
+* Macro Pitfalls::
+
+Predefined Macros
+
+* Standard Predefined Macros::
+* Common Predefined Macros::
+* System-specific Predefined Macros::
+* C++ Named Operators::
+
+Macro Pitfalls
+
+* Misnesting::
+* Operator Precedence Problems::
+* Swallowing the Semicolon::
+* Duplication of Side Effects::
+* Self-Referential Macros::
+* Argument Prescan::
+* Newlines in Arguments::
+
+Conditionals
+
+* Conditional Uses::
+* Conditional Syntax::
+* Deleted Code::
+
+Conditional Syntax
+
+* Ifdef::
+* If::
+* Defined::
+* Else::
+* Elif::
+
+Implementation Details
+
+* Implementation-defined behavior::
+* Implementation limits::
+* Obsolete Features::
+* Differences from previous versions::
+
+Obsolete Features
+
+* Obsolete Features::
+
+
+   Copyright (C) 1987-2014 Free Software Foundation, Inc.
+
+   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.  A copy of
+the license is included in the section entitled "GNU Free Documentation
+License".
+
+   This manual contains no Invariant Sections.  The Front-Cover Texts
+are (a) (see below), and the Back-Cover Texts are (b) (see below).
+
+   (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.
+
+
+File: cpp.info,  Node: Overview,  Next: Header Files,  Prev: Top,  Up: Top
+
+1 Overview
+**********
+
+The C preprocessor, often known as "cpp", is a "macro processor" that is
+used automatically by the C compiler to transform your program before
+compilation.  It is called a macro processor because it allows you to
+define "macros", which are brief abbreviations for longer constructs.
+
+   The C preprocessor is intended to be used only with C, C++, and
+Objective-C source code.  In the past, it has been abused as a general
+text processor.  It will choke on input which does not obey C's lexical
+rules.  For example, apostrophes will be interpreted as the beginning of
+character constants, and cause errors.  Also, you cannot rely on it
+preserving characteristics of the input which are not significant to
+C-family languages.  If a Makefile is preprocessed, all the hard tabs
+will be removed, and the Makefile will not work.
+
+   Having said that, you can often get away with using cpp on things
+which are not C.  Other Algol-ish programming languages are often safe
+(Pascal, Ada, etc.)  So is assembly, with caution.  '-traditional-cpp'
+mode preserves more white space, and is otherwise more permissive.  Many
+of the problems can be avoided by writing C or C++ style comments
+instead of native language comments, and keeping macros simple.
+
+   Wherever possible, you should use a preprocessor geared to the
+language you are writing in.  Modern versions of the GNU assembler have
+macro facilities.  Most high level programming languages have their own
+conditional compilation and inclusion mechanism.  If all else fails, try
+a true general text processor, such as GNU M4.
+
+   C preprocessors vary in some details.  This manual discusses the GNU
+C preprocessor, which provides a small superset of the features of ISO
+Standard C.  In its default mode, the GNU C preprocessor does not do a
+few things required by the standard.  These are features which are
+rarely, if ever, used, and may cause surprising changes to the meaning
+of a program which does not expect them.  To get strict ISO Standard C,
+you should use the '-std=c90', '-std=c99' or '-std=c11' options,
+depending on which version of the standard you want.  To get all the
+mandatory diagnostics, you must also use '-pedantic'.  *Note
+Invocation::.
+
+   This manual describes the behavior of the ISO preprocessor.  To
+minimize gratuitous differences, where the ISO preprocessor's behavior
+does not conflict with traditional semantics, the traditional
+preprocessor should behave the same way.  The various differences that
+do exist are detailed in the section *note Traditional Mode::.
+
+   For clarity, unless noted otherwise, references to 'CPP' in this
+manual refer to GNU CPP.
+
+* Menu:
+
+* Character sets::
+* Initial processing::
+* Tokenization::
+* The preprocessing language::
+
+
+File: cpp.info,  Node: Character sets,  Next: Initial processing,  Up: Overview
+
+1.1 Character sets
+==================
+
+Source code character set processing in C and related languages is
+rather complicated.  The C standard discusses two character sets, but
+there are really at least four.
+
+   The files input to CPP might be in any character set at all.  CPP's
+very first action, before it even looks for line boundaries, is to
+convert the file into the character set it uses for internal processing.
+That set is what the C standard calls the "source" character set.  It
+must be isomorphic with ISO 10646, also known as Unicode.  CPP uses the
+UTF-8 encoding of Unicode.
+
+   The character sets of the input files are specified using the
+'-finput-charset=' option.
+
+   All preprocessing work (the subject of the rest of this manual) is
+carried out in the source character set.  If you request textual output
+from the preprocessor with the '-E' option, it will be in UTF-8.
+
+   After preprocessing is complete, string and character constants are
+converted again, into the "execution" character set.  This character set
+is under control of the user; the default is UTF-8, matching the source
+character set.  Wide string and character constants have their own
+character set, which is not called out specifically in the standard.
+Again, it is under control of the user.  The default is UTF-16 or
+UTF-32, whichever fits in the target's 'wchar_t' type, in the target
+machine's byte order.(1)  Octal and hexadecimal escape sequences do not
+undergo conversion; '\x12' has the value 0x12 regardless of the
+currently selected execution character set.  All other escapes are
+replaced by the character in the source character set that they
+represent, then converted to the execution character set, just like
+unescaped characters.
+
+   Unless the experimental '-fextended-identifiers' option is used, GCC
+does not permit the use of characters outside the ASCII range, nor '\u'
+and '\U' escapes, in identifiers.  Even with that option, characters
+outside the ASCII range can only be specified with the '\u' and '\U'
+escapes, not used directly in identifiers.
+
+   ---------- Footnotes ----------
+
+   (1) UTF-16 does not meet the requirements of the C standard for a
+wide character set, but the choice of 16-bit 'wchar_t' is enshrined in
+some system ABIs so we cannot fix this.
+
+
+File: cpp.info,  Node: Initial processing,  Next: Tokenization,  Prev: Character sets,  Up: Overview
+
+1.2 Initial processing
+======================
+
+The preprocessor performs a series of textual transformations on its
+input.  These happen before all other processing.  Conceptually, they
+happen in a rigid order, and the entire file is run through each
+transformation before the next one begins.  CPP actually does them all
+at once, for performance reasons.  These transformations correspond
+roughly to the first three "phases of translation" described in the C
+standard.
+
+  1. The input file is read into memory and broken into lines.
+
+     Different systems use different conventions to indicate the end of
+     a line.  GCC accepts the ASCII control sequences 'LF', 'CR LF' and
+     'CR' as end-of-line markers.  These are the canonical sequences
+     used by Unix, DOS and VMS, and the classic Mac OS (before OSX)
+     respectively.  You may therefore safely copy source code written on
+     any of those systems to a different one and use it without
+     conversion.  (GCC may lose track of the current line number if a
+     file doesn't consistently use one convention, as sometimes happens
+     when it is edited on computers with different conventions that
+     share a network file system.)
+
+     If the last line of any input file lacks an end-of-line marker, the
+     end of the file is considered to implicitly supply one.  The C
+     standard says that this condition provokes undefined behavior, so
+     GCC will emit a warning message.
+
+  2. If trigraphs are enabled, they are replaced by their corresponding
+     single characters.  By default GCC ignores trigraphs, but if you
+     request a strictly conforming mode with the '-std' option, or you
+     specify the '-trigraphs' option, then it converts them.
+
+     These are nine three-character sequences, all starting with '??',
+     that are defined by ISO C to stand for single characters.  They
+     permit obsolete systems that lack some of C's punctuation to use C.
+     For example, '??/' stands for '\', so '??/n' is a character
+     constant for a newline.
+
+     Trigraphs are not popular and many compilers implement them
+     incorrectly.  Portable code should not rely on trigraphs being
+     either converted or ignored.  With '-Wtrigraphs' GCC will warn you
+     when a trigraph may change the meaning of your program if it were
+     converted.  *Note Wtrigraphs::.
+
+     In a string constant, you can prevent a sequence of question marks
+     from being confused with a trigraph by inserting a backslash
+     between the question marks, or by separating the string literal at
+     the trigraph and making use of string literal concatenation.
+     "(??\?)" is the string '(???)', not '(?]'.  Traditional C compilers
+     do not recognize these idioms.
+
+     The nine trigraphs and their replacements are
+
+          Trigraph:       ??(  ??)  ??<  ??>  ??=  ??/  ??'  ??!  ??-
+          Replacement:      [    ]    {    }    #    \    ^    |    ~
+
+  3. Continued lines are merged into one long line.
+
+     A continued line is a line which ends with a backslash, '\'.  The
+     backslash is removed and the following line is joined with the
+     current one.  No space is inserted, so you may split a line
+     anywhere, even in the middle of a word.  (It is generally more
+     readable to split lines only at white space.)
+
+     The trailing backslash on a continued line is commonly referred to
+     as a "backslash-newline".
+
+     If there is white space between a backslash and the end of a line,
+     that is still a continued line.  However, as this is usually the
+     result of an editing mistake, and many compilers will not accept it
+     as a continued line, GCC will warn you about it.
+
+  4. All comments are replaced with single spaces.
+
+     There are two kinds of comments.  "Block comments" begin with '/*'
+     and continue until the next '*/'.  Block comments do not nest:
+
+          /* this is /* one comment */ text outside comment
+
+     "Line comments" begin with '//' and continue to the end of the
+     current line.  Line comments do not nest either, but it does not
+     matter, because they would end in the same place anyway.
+
+          // this is // one comment
+          text outside comment
+
+   It is safe to put line comments inside block comments, or vice versa.
+
+     /* block comment
+        // contains line comment
+        yet more comment
+      */ outside comment
+
+     // line comment /* contains block comment */
+
+   But beware of commenting out one end of a block comment with a line
+comment.
+
+      // l.c.  /* block comment begins
+         oops! this isn't a comment anymore */
+
+   Comments are not recognized within string literals.  "/* blah */" is
+the string constant '/* blah */', not an empty string.
+
+   Line comments are not in the 1989 edition of the C standard, but they
+are recognized by GCC as an extension.  In C++ and in the 1999 edition
+of the C standard, they are an official part of the language.
+
+   Since these transformations happen before all other processing, you
+can split a line mechanically with backslash-newline anywhere.  You can
+comment out the end of a line.  You can continue a line comment onto the
+next line with backslash-newline.  You can even split '/*', '*/', and
+'//' onto multiple lines with backslash-newline.  For example:
+
+     /\
+     *
+     */ # /*
+     */ defi\
+     ne FO\
+     O 10\
+     20
+
+is equivalent to '#define FOO 1020'.  All these tricks are extremely
+confusing and should not be used in code intended to be readable.
+
+   There is no way to prevent a backslash at the end of a line from
+being interpreted as a backslash-newline.  This cannot affect any
+correct program, however.
+
+
+File: cpp.info,  Node: Tokenization,  Next: The preprocessing language,  Prev: Initial processing,  Up: Overview
+
+1.3 Tokenization
+================
+
+After the textual transformations are finished, the input file is
+converted into a sequence of "preprocessing tokens".  These mostly
+correspond to the syntactic tokens used by the C compiler, but there are
+a few differences.  White space separates tokens; it is not itself a
+token of any kind.  Tokens do not have to be separated by white space,
+but it is often necessary to avoid ambiguities.
+
+   When faced with a sequence of characters that has more than one
+possible tokenization, the preprocessor is greedy.  It always makes each
+token, starting from the left, as big as possible before moving on to
+the next token.  For instance, 'a+++++b' is interpreted as
+'a ++ ++ + b', not as 'a ++ + ++ b', even though the latter tokenization
+could be part of a valid C program and the former could not.
+
+   Once the input file is broken into tokens, the token boundaries never
+change, except when the '##' preprocessing operator is used to paste
+tokens together.  *Note Concatenation::.  For example,
+
+     #define foo() bar
+     foo()baz
+          ==> bar baz
+     _not_
+          ==> barbaz
+
+   The compiler does not re-tokenize the preprocessor's output.  Each
+preprocessing token becomes one compiler token.
+
+   Preprocessing tokens fall into five broad classes: identifiers,
+preprocessing numbers, string literals, punctuators, and other.  An
+"identifier" is the same as an identifier in C: any sequence of letters,
+digits, or underscores, which begins with a letter or underscore.
+Keywords of C have no significance to the preprocessor; they are
+ordinary identifiers.  You can define a macro whose name is a keyword,
+for instance.  The only identifier which can be considered a
+preprocessing keyword is 'defined'.  *Note Defined::.
+
+   This is mostly true of other languages which use the C preprocessor.
+However, a few of the keywords of C++ are significant even in the
+preprocessor.  *Note C++ Named Operators::.
+
+   In the 1999 C standard, identifiers may contain letters which are not
+part of the "basic source character set", at the implementation's
+discretion (such as accented Latin letters, Greek letters, or Chinese
+ideograms).  This may be done with an extended character set, or the
+'\u' and '\U' escape sequences.  The implementation of this feature in
+GCC is experimental; such characters are only accepted in the '\u' and
+'\U' forms and only if '-fextended-identifiers' is used.
+
+   As an extension, GCC treats '$' as a letter.  This is for
+compatibility with some systems, such as VMS, where '$' is commonly used
+in system-defined function and object names.  '$' is not a letter in
+strictly conforming mode, or if you specify the '-$' option.  *Note
+Invocation::.
+
+   A "preprocessing number" has a rather bizarre definition.  The
+category includes all the normal integer and floating point constants
+one expects of C, but also a number of other things one might not
+initially recognize as a number.  Formally, preprocessing numbers begin
+with an optional period, a required decimal digit, and then continue
+with any sequence of letters, digits, underscores, periods, and
+exponents.  Exponents are the two-character sequences 'e+', 'e-', 'E+',
+'E-', 'p+', 'p-', 'P+', and 'P-'.  (The exponents that begin with 'p' or
+'P' are new to C99.  They are used for hexadecimal floating-point
+constants.)
+
+   The purpose of this unusual definition is to isolate the preprocessor
+from the full complexity of numeric constants.  It does not have to
+distinguish between lexically valid and invalid floating-point numbers,
+which is complicated.  The definition also permits you to split an
+identifier at any position and get exactly two tokens, which can then be
+pasted back together with the '##' operator.
+
+   It's possible for preprocessing numbers to cause programs to be
+misinterpreted.  For example, '0xE+12' is a preprocessing number which
+does not translate to any valid numeric constant, therefore a syntax
+error.  It does not mean '0xE + 12', which is what you might have
+intended.
+
+   "String literals" are string constants, character constants, and
+header file names (the argument of '#include').(1)  String constants and
+character constants are straightforward: "..." or '...'.  In either case
+embedded quotes should be escaped with a backslash: '\'' is the
+character constant for '''.  There is no limit on the length of a
+character constant, but the value of a character constant that contains
+more than one character is implementation-defined.  *Note Implementation
+Details::.
+
+   Header file names either look like string constants, "...", or are
+written with angle brackets instead, <...>.  In either case, backslash
+is an ordinary character.  There is no way to escape the closing quote
+or angle bracket.  The preprocessor looks for the header file in
+different places depending on which form you use.  *Note Include
+Operation::.
+
+   No string literal may extend past the end of a line.  Older versions
+of GCC accepted multi-line string constants.  You may use continued
+lines instead, or string constant concatenation.  *Note Differences from
+previous versions::.
+
+   "Punctuators" are all the usual bits of punctuation which are
+meaningful to C and C++.  All but three of the punctuation characters in
+ASCII are C punctuators.  The exceptions are '@', '$', and '`'.  In
+addition, all the two- and three-character operators are punctuators.
+There are also six "digraphs", which the C++ standard calls "alternative
+tokens", which are merely alternate ways to spell other punctuators.
+This is a second attempt to work around missing punctuation in obsolete
+systems.  It has no negative side effects, unlike trigraphs, but does
+not cover as much ground.  The digraphs and their corresponding normal
+punctuators are:
+
+     Digraph:        <%  %>  <:  :>  %:  %:%:
+     Punctuator:      {   }   [   ]   #    ##
+
+   Any other single character is considered "other".  It is passed on to
+the preprocessor's output unmolested.  The C compiler will almost
+certainly reject source code containing "other" tokens.  In ASCII, the
+only other characters are '@', '$', '`', and control characters other
+than NUL (all bits zero).  (Note that '$' is normally considered a
+letter.)  All characters with the high bit set (numeric range 0x7F-0xFF)
+are also "other" in the present implementation.  This will change when
+proper support for international character sets is added to GCC.
+
+   NUL is a special case because of the high probability that its
+appearance is accidental, and because it may be invisible to the user
+(many terminals do not display NUL at all).  Within comments, NULs are
+silently ignored, just as any other character would be.  In running
+text, NUL is considered white space.  For example, these two directives
+have the same meaning.
+
+     #define X^@1
+     #define X 1
+
+(where '^@' is ASCII NUL).  Within string or character constants, NULs
+are preserved.  In the latter two cases the preprocessor emits a warning
+message.
+
+   ---------- Footnotes ----------
+
+   (1) The C standard uses the term "string literal" to refer only to
+what we are calling "string constants".
+
+
+File: cpp.info,  Node: The preprocessing language,  Prev: Tokenization,  Up: Overview
+
+1.4 The preprocessing language
+==============================
+
+After tokenization, the stream of tokens may simply be passed straight
+to the compiler's parser.  However, if it contains any operations in the
+"preprocessing language", it will be transformed first.  This stage
+corresponds roughly to the standard's "translation phase 4" and is what
+most people think of as the preprocessor's job.
+
+   The preprocessing language consists of "directives" to be executed
+and "macros" to be expanded.  Its primary capabilities are:
+
+   * Inclusion of header files.  These are files of declarations that
+     can be substituted into your program.
+
+   * Macro expansion.  You can define "macros", which are abbreviations
+     for arbitrary fragments of C code.  The preprocessor will replace
+     the macros with their definitions throughout the program.  Some
+     macros are automatically defined for you.
+
+   * Conditional compilation.  You can include or exclude parts of the
+     program according to various conditions.
+
+   * Line control.  If you use a program to combine or rearrange source
+     files into an intermediate file which is then compiled, you can use
+     line control to inform the compiler where each source line
+     originally came from.
+
+   * Diagnostics.  You can detect problems at compile time and issue
+     errors or warnings.
+
+   There are a few more, less useful, features.
+
+   Except for expansion of predefined macros, all these operations are
+triggered with "preprocessing directives".  Preprocessing directives are
+lines in your program that start with '#'.  Whitespace is allowed before
+and after the '#'.  The '#' is followed by an identifier, the "directive
+name".  It specifies the operation to perform.  Directives are commonly
+referred to as '#NAME' where NAME is the directive name.  For example,
+'#define' is the directive that defines a macro.
+
+   The '#' which begins a directive cannot come from a macro expansion.
+Also, the directive name is not macro expanded.  Thus, if 'foo' is
+defined as a macro expanding to 'define', that does not make '#foo' a
+valid preprocessing directive.
+
+   The set of valid directive names is fixed.  Programs cannot define
+new preprocessing directives.
+
+   Some directives require arguments; these make up the rest of the
+directive line and must be separated from the directive name by
+whitespace.  For example, '#define' must be followed by a macro name and
+the intended expansion of the macro.
+
+   A preprocessing directive cannot cover more than one line.  The line
+may, however, be continued with backslash-newline, or by a block comment
+which extends past the end of the line.  In either case, when the
+directive is processed, the continuations have already been merged with
+the first line to make one long line.
+
+
+File: cpp.info,  Node: Header Files,  Next: Macros,  Prev: Overview,  Up: Top
+
+2 Header Files
+**************
+
+A header file is a file containing C declarations and macro definitions
+(*note Macros::) to be shared between several source files.  You request
+the use of a header file in your program by "including" it, with the C
+preprocessing directive '#include'.
+
+   Header files serve two purposes.
+
+   * System header files declare the interfaces to parts of the
+     operating system.  You include them in your program to supply the
+     definitions and declarations you need to invoke system calls and
+     libraries.
+
+   * Your own header files contain declarations for interfaces between
+     the source files of your program.  Each time you have a group of
+     related declarations and macro definitions all or most of which are
+     needed in several different source files, it is a good idea to
+     create a header file for them.
+
+   Including a header file produces the same results as copying the
+header file into each source file that needs it.  Such copying would be
+time-consuming and error-prone.  With a header file, the related
+declarations appear in only one place.  If they need to be changed, they
+can be changed in one place, and programs that include the header file
+will automatically use the new version when next recompiled.  The header
+file eliminates the labor of finding and changing all the copies as well
+as the risk that a failure to find one copy will result in
+inconsistencies within a program.
+
+   In C, the usual convention is to give header files names that end
+with '.h'.  It is most portable to use only letters, digits, dashes, and
+underscores in header file names, and at most one dot.
+
+* Menu:
+
+* Include Syntax::
+* Include Operation::
+* Search Path::
+* Once-Only Headers::
+* Alternatives to Wrapper #ifndef::
+* Computed Includes::
+* Wrapper Headers::
+* System Headers::
+
+
+File: cpp.info,  Node: Include Syntax,  Next: Include Operation,  Up: Header Files
+
+2.1 Include Syntax
+==================
+
+Both user and system header files are included using the preprocessing
+directive '#include'.  It has two variants:
+
+'#include <FILE>'
+     This variant is used for system header files.  It searches for a
+     file named FILE in a standard list of system directories.  You can
+     prepend directories to this list with the '-I' option (*note
+     Invocation::).
+
+'#include "FILE"'
+     This variant is used for header files of your own program.  It
+     searches for a file named FILE first in the directory containing
+     the current file, then in the quote directories and then the same
+     directories used for '<FILE>'.  You can prepend directories to the
+     list of quote directories with the '-iquote' option.
+
+   The argument of '#include', whether delimited with quote marks or
+angle brackets, behaves like a string constant in that comments are not
+recognized, and macro names are not expanded.  Thus, '#include <x/*y>'
+specifies inclusion of a system header file named 'x/*y'.
+
+   However, if backslashes occur within FILE, they are considered
+ordinary text characters, not escape characters.  None of the character
+escape sequences appropriate to string constants in C are processed.
+Thus, '#include "x\n\\y"' specifies a filename containing three
+backslashes.  (Some systems interpret '\' as a pathname separator.  All
+of these also interpret '/' the same way.  It is most portable to use
+only '/'.)
+
+   It is an error if there is anything (other than comments) on the line
+after the file name.
+
+
+File: cpp.info,  Node: Include Operation,  Next: Search Path,  Prev: Include Syntax,  Up: Header Files
+
+2.2 Include Operation
+=====================
+
+The '#include' directive works by directing the C preprocessor to scan
+the specified file as input before continuing with the rest of the
+current file.  The output from the preprocessor contains the output
+already generated, followed by the output resulting from the included
+file, followed by the output that comes from the text after the
+'#include' directive.  For example, if you have a header file 'header.h'
+as follows,
+
+     char *test (void);
+
+and a main program called 'program.c' that uses the header file, like
+this,
+
+     int x;
+     #include "header.h"
+
+     int
+     main (void)
+     {
+       puts (test ());
+     }
+
+the compiler will see the same token stream as it would if 'program.c'
+read
+
+     int x;
+     char *test (void);
+
+     int
+     main (void)
+     {
+       puts (test ());
+     }
+
+   Included files are not limited to declarations and macro definitions;
+those are merely the typical uses.  Any fragment of a C program can be
+included from another file.  The include file could even contain the
+beginning of a statement that is concluded in the containing file, or
+the end of a statement that was started in the including file.  However,
+an included file must consist of complete tokens.  Comments and string
+literals which have not been closed by the end of an included file are
+invalid.  For error recovery, they are considered to end at the end of
+the file.
+
+   To avoid confusion, it is best if header files contain only complete
+syntactic units--function declarations or definitions, type
+declarations, etc.
+
+   The line following the '#include' directive is always treated as a
+separate line by the C preprocessor, even if the included file lacks a
+final newline.
+
+
+File: cpp.info,  Node: Search Path,  Next: Once-Only Headers,  Prev: Include Operation,  Up: Header Files
+
+2.3 Search Path
+===============
+
+GCC looks in several different places for headers.  On a normal Unix
+system, if you do not instruct it otherwise, it will look for headers
+requested with '#include <FILE>' in:
+
+     /usr/local/include
+     LIBDIR/gcc/TARGET/VERSION/include
+     /usr/TARGET/include
+     /usr/include
+
+   For C++ programs, it will also look in
+'LIBDIR/../include/c++/VERSION', first.  In the above, TARGET is the
+canonical name of the system GCC was configured to compile code for;
+often but not always the same as the canonical name of the system it
+runs on.  VERSION is the version of GCC in use.
+
+   You can add to this list with the '-IDIR' command line option.  All
+the directories named by '-I' are searched, in left-to-right order,
+_before_ the default directories.  The only exception is when 'dir' is
+already searched by default.  In this case, the option is ignored and
+the search order for system directories remains unchanged.
+
+   Duplicate directories are removed from the quote and bracket search
+chains before the two chains are merged to make the final search chain.
+Thus, it is possible for a directory to occur twice in the final search
+chain if it was specified in both the quote and bracket chains.
+
+   You can prevent GCC from searching any of the default directories
+with the '-nostdinc' option.  This is useful when you are compiling an
+operating system kernel or some other program that does not use the
+standard C library facilities, or the standard C library itself.  '-I'
+options are not ignored as described above when '-nostdinc' is in
+effect.
+
+   GCC looks for headers requested with '#include "FILE"' first in the
+directory containing the current file, then in the directories as
+specified by '-iquote' options, then in the same places it would have
+looked for a header requested with angle brackets.  For example, if
+'/usr/include/sys/stat.h' contains '#include "types.h"', GCC looks for
+'types.h' first in '/usr/include/sys', then in its usual search path.
+
+   '#line' (*note Line Control::) does not change GCC's idea of the
+directory containing the current file.
+
+   You may put '-I-' at any point in your list of '-I' options.  This
+has two effects.  First, directories appearing before the '-I-' in the
+list are searched only for headers requested with quote marks.
+Directories after '-I-' are searched for all headers.  Second, the
+directory containing the current file is not searched for anything,
+unless it happens to be one of the directories named by an '-I' switch.
+'-I-' is deprecated, '-iquote' should be used instead.
+
+   '-I. -I-' is not the same as no '-I' options at all, and does not
+cause the same behavior for '<>' includes that '""' includes get with no
+special options.  '-I.' searches the compiler's current working
+directory for header files.  That may or may not be the same as the
+directory containing the current file.
+
+   If you need to look for headers in a directory named '-', write
+'-I./-'.
+
+   There are several more ways to adjust the header search path.  They
+are generally less useful.  *Note Invocation::.
+
+
+File: cpp.info,  Node: Once-Only Headers,  Next: Alternatives to Wrapper #ifndef,  Prev: Search Path,  Up: Header Files
+
+2.4 Once-Only Headers
+=====================
+
+If a header file happens to be included twice, the compiler will process
+its contents twice.  This is very likely to cause an error, e.g. when
+the compiler sees the same structure definition twice.  Even if it does
+not, it will certainly waste time.
+
+   The standard way to prevent this is to enclose the entire real
+contents of the file in a conditional, like this:
+
+     /* File foo.  */
+     #ifndef FILE_FOO_SEEN
+     #define FILE_FOO_SEEN
+
+     THE ENTIRE FILE
+
+     #endif /* !FILE_FOO_SEEN */
+
+   This construct is commonly known as a "wrapper #ifndef".  When the
+header is included again, the conditional will be false, because
+'FILE_FOO_SEEN' is defined.  The preprocessor will skip over the entire
+contents of the file, and the compiler will not see it twice.
+
+   CPP optimizes even further.  It remembers when a header file has a
+wrapper '#ifndef'.  If a subsequent '#include' specifies that header,
+and the macro in the '#ifndef' is still defined, it does not bother to
+rescan the file at all.
+
+   You can put comments outside the wrapper.  They will not interfere
+with this optimization.
+
+   The macro 'FILE_FOO_SEEN' is called the "controlling macro" or "guard
+macro".  In a user header file, the macro name should not begin with
+'_'.  In a system header file, it should begin with '__' to avoid
+conflicts with user programs.  In any kind of header file, the macro
+name should contain the name of the file and some additional text, to
+avoid conflicts with other header files.
+
+
+File: cpp.info,  Node: Alternatives to Wrapper #ifndef,  Next: Computed Includes,  Prev: Once-Only Headers,  Up: Header Files
+
+2.5 Alternatives to Wrapper #ifndef
+===================================
+
+CPP supports two more ways of indicating that a header file should be
+read only once.  Neither one is as portable as a wrapper '#ifndef' and
+we recommend you do not use them in new programs, with the caveat that
+'#import' is standard practice in Objective-C.
+
+   CPP supports a variant of '#include' called '#import' which includes
+a file, but does so at most once.  If you use '#import' instead of
+'#include', then you don't need the conditionals inside the header file
+to prevent multiple inclusion of the contents.  '#import' is standard in
+Objective-C, but is considered a deprecated extension in C and C++.
+
+   '#import' is not a well designed feature.  It requires the users of a
+header file to know that it should only be included once.  It is much
+better for the header file's implementor to write the file so that users
+don't need to know this.  Using a wrapper '#ifndef' accomplishes this
+goal.
+
+   In the present implementation, a single use of '#import' will prevent
+the file from ever being read again, by either '#import' or '#include'.
+You should not rely on this; do not use both '#import' and '#include' to
+refer to the same header file.
+
+   Another way to prevent a header file from being included more than
+once is with the '#pragma once' directive.  If '#pragma once' is seen
+when scanning a header file, that file will never be read again, no
+matter what.
+
+   '#pragma once' does not have the problems that '#import' does, but it
+is not recognized by all preprocessors, so you cannot rely on it in a
+portable program.
+
+
+File: cpp.info,  Node: Computed Includes,  Next: Wrapper Headers,  Prev: Alternatives to Wrapper #ifndef,  Up: Header Files
+
+2.6 Computed Includes
+=====================
+
+Sometimes it is necessary to select one of several different header
+files to be included into your program.  They might specify
+configuration parameters to be used on different sorts of operating
+systems, for instance.  You could do this with a series of conditionals,
+
+     #if SYSTEM_1
+     # include "system_1.h"
+     #elif SYSTEM_2
+     # include "system_2.h"
+     #elif SYSTEM_3
+     ...
+     #endif
+
+   That rapidly becomes tedious.  Instead, the preprocessor offers the
+ability to use a macro for the header name.  This is called a "computed
+include".  Instead of writing a header name as the direct argument of
+'#include', you simply put a macro name there instead:
+
+     #define SYSTEM_H "system_1.h"
+     ...
+     #include SYSTEM_H
+
+'SYSTEM_H' will be expanded, and the preprocessor will look for
+'system_1.h' as if the '#include' had been written that way originally.
+'SYSTEM_H' could be defined by your Makefile with a '-D' option.
+
+   You must be careful when you define the macro.  '#define' saves
+tokens, not text.  The preprocessor has no way of knowing that the macro
+will be used as the argument of '#include', so it generates ordinary
+tokens, not a header name.  This is unlikely to cause problems if you
+use double-quote includes, which are close enough to string constants.
+If you use angle brackets, however, you may have trouble.
+
+   The syntax of a computed include is actually a bit more general than
+the above.  If the first non-whitespace character after '#include' is
+not '"' or '<', then the entire line is macro-expanded like running text
+would be.
+
+   If the line expands to a single string constant, the contents of that
+string constant are the file to be included.  CPP does not re-examine
+the string for embedded quotes, but neither does it process backslash
+escapes in the string.  Therefore
+
+     #define HEADER "a\"b"
+     #include HEADER
+
+looks for a file named 'a\"b'.  CPP searches for the file according to
+the rules for double-quoted includes.
+
+   If the line expands to a token stream beginning with a '<' token and
+including a '>' token, then the tokens between the '<' and the first '>'
+are combined to form the filename to be included.  Any whitespace
+between tokens is reduced to a single space; then any space after the
+initial '<' is retained, but a trailing space before the closing '>' is
+ignored.  CPP searches for the file according to the rules for
+angle-bracket includes.
+
+   In either case, if there are any tokens on the line after the file
+name, an error occurs and the directive is not processed.  It is also an
+error if the result of expansion does not match either of the two
+expected forms.
+
+   These rules are implementation-defined behavior according to the C
+standard.  To minimize the risk of different compilers interpreting your
+computed includes differently, we recommend you use only a single
+object-like macro which expands to a string constant.  This will also
+minimize confusion for people reading your program.
+
+
+File: cpp.info,  Node: Wrapper Headers,  Next: System Headers,  Prev: Computed Includes,  Up: Header Files
+
+2.7 Wrapper Headers
+===================
+
+Sometimes it is necessary to adjust the contents of a system-provided
+header file without editing it directly.  GCC's 'fixincludes' operation
+does this, for example.  One way to do that would be to create a new
+header file with the same name and insert it in the search path before
+the original header.  That works fine as long as you're willing to
+replace the old header entirely.  But what if you want to refer to the
+old header from the new one?
+
+   You cannot simply include the old header with '#include'.  That will
+start from the beginning, and find your new header again.  If your
+header is not protected from multiple inclusion (*note Once-Only
+Headers::), it will recurse infinitely and cause a fatal error.
+
+   You could include the old header with an absolute pathname:
+     #include "/usr/include/old-header.h"
+This works, but is not clean; should the system headers ever move, you
+would have to edit the new headers to match.
+
+   There is no way to solve this problem within the C standard, but you
+can use the GNU extension '#include_next'.  It means, "Include the
+_next_ file with this name".  This directive works like '#include'
+except in searching for the specified file: it starts searching the list
+of header file directories _after_ the directory in which the current
+file was found.
+
+   Suppose you specify '-I /usr/local/include', and the list of
+directories to search also includes '/usr/include'; and suppose both
+directories contain 'signal.h'.  Ordinary '#include <signal.h>' finds
+the file under '/usr/local/include'.  If that file contains
+'#include_next <signal.h>', it starts searching after that directory,
+and finds the file in '/usr/include'.
+
+   '#include_next' does not distinguish between '<FILE>' and '"FILE"'
+inclusion, nor does it check that the file you specify has the same name
+as the current file.  It simply looks for the file named, starting with
+the directory in the search path after the one where the current file
+was found.
+
+   The use of '#include_next' can lead to great confusion.  We recommend
+it be used only when there is no other alternative.  In particular, it
+should not be used in the headers belonging to a specific program; it
+should be used only to make global corrections along the lines of
+'fixincludes'.
+
+
+File: cpp.info,  Node: System Headers,  Prev: Wrapper Headers,  Up: Header Files
+
+2.8 System Headers
+==================
+
+The header files declaring interfaces to the operating system and
+runtime libraries often cannot be written in strictly conforming C.
+Therefore, GCC gives code found in "system headers" special treatment.
+All warnings, other than those generated by '#warning' (*note
+Diagnostics::), are suppressed while GCC is processing a system header.
+Macros defined in a system header are immune to a few warnings wherever
+they are expanded.  This immunity is granted on an ad-hoc basis, when we
+find that a warning generates lots of false positives because of code in
+macros defined in system headers.
+
+   Normally, only the headers found in specific directories are
+considered system headers.  These directories are determined when GCC is
+compiled.  There are, however, two ways to make normal headers into
+system headers.
+
+   The '-isystem' command line option adds its argument to the list of
+directories to search for headers, just like '-I'.  Any headers found in
+that directory will be considered system headers.
+
+   All directories named by '-isystem' are searched _after_ all
+directories named by '-I', no matter what their order was on the command
+line.  If the same directory is named by both '-I' and '-isystem', the
+'-I' option is ignored.  GCC provides an informative message when this
+occurs if '-v' is used.
+
+   There is also a directive, '#pragma GCC system_header', which tells
+GCC to consider the rest of the current include file a system header, no
+matter where it was found.  Code that comes before the '#pragma' in the
+file will not be affected.  '#pragma GCC system_header' has no effect in
+the primary source file.
+
+   On very old systems, some of the pre-defined system header
+directories get even more special treatment.  GNU C++ considers code in
+headers found in those directories to be surrounded by an 'extern "C"'
+block.  There is no way to request this behavior with a '#pragma', or
+from the command line.
+
+
+File: cpp.info,  Node: Macros,  Next: Conditionals,  Prev: Header Files,  Up: Top
+
+3 Macros
+********
+
+A "macro" is a fragment of code which has been given a name.  Whenever
+the name is used, it is replaced by the contents of the macro.  There
+are two kinds of macros.  They differ mostly in what they look like when
+they are used.  "Object-like" macros resemble data objects when used,
+"function-like" macros resemble function calls.
+
+   You may define any valid identifier as a macro, even if it is a C
+keyword.  The preprocessor does not know anything about keywords.  This
+can be useful if you wish to hide a keyword such as 'const' from an
+older compiler that does not understand it.  However, the preprocessor
+operator 'defined' (*note Defined::) can never be defined as a macro,
+and C++'s named operators (*note C++ Named Operators::) cannot be macros
+when you are compiling C++.
+
+* Menu:
+
+* Object-like Macros::
+* Function-like Macros::
+* Macro Arguments::
+* Stringification::
+* Concatenation::
+* Variadic Macros::
+* Predefined Macros::
+* Undefining and Redefining Macros::
+* Directives Within Macro Arguments::
+* Macro Pitfalls::
+
+
+File: cpp.info,  Node: Object-like Macros,  Next: Function-like Macros,  Up: Macros
+
+3.1 Object-like Macros
+======================
+
+An "object-like macro" is a simple identifier which will be replaced by
+a code fragment.  It is called object-like because it looks like a data
+object in code that uses it.  They are most commonly used to give
+symbolic names to numeric constants.
+
+   You create macros with the '#define' directive.  '#define' is
+followed by the name of the macro and then the token sequence it should
+be an abbreviation for, which is variously referred to as the macro's
+"body", "expansion" or "replacement list".  For example,
+
+     #define BUFFER_SIZE 1024
+
+defines a macro named 'BUFFER_SIZE' as an abbreviation for the token
+'1024'.  If somewhere after this '#define' directive there comes a C
+statement of the form
+
+     foo = (char *) malloc (BUFFER_SIZE);
+
+then the C preprocessor will recognize and "expand" the macro
+'BUFFER_SIZE'.  The C compiler will see the same tokens as it would if
+you had written
+
+     foo = (char *) malloc (1024);
+
+   By convention, macro names are written in uppercase.  Programs are
+easier to read when it is possible to tell at a glance which names are
+macros.
+
+   The macro's body ends at the end of the '#define' line.  You may
+continue the definition onto multiple lines, if necessary, using
+backslash-newline.  When the macro is expanded, however, it will all
+come out on one line.  For example,
+
+     #define NUMBERS 1, \
+                     2, \
+                     3
+     int x[] = { NUMBERS };
+          ==> int x[] = { 1, 2, 3 };
+
+The most common visible consequence of this is surprising line numbers
+in error messages.
+
+   There is no restriction on what can go in a macro body provided it
+decomposes into valid preprocessing tokens.  Parentheses need not
+balance, and the body need not resemble valid C code.  (If it does not,
+you may get error messages from the C compiler when you use the macro.)
+
+   The C preprocessor scans your program sequentially.  Macro
+definitions take effect at the place you write them.  Therefore, the
+following input to the C preprocessor
+
+     foo = X;
+     #define X 4
+     bar = X;
+
+produces
+
+     foo = X;
+     bar = 4;
+
+   When the preprocessor expands a macro name, the macro's expansion
+replaces the macro invocation, then the expansion is examined for more
+macros to expand.  For example,
+
+     #define TABLESIZE BUFSIZE
+     #define BUFSIZE 1024
+     TABLESIZE
+          ==> BUFSIZE
+          ==> 1024
+
+'TABLESIZE' is expanded first to produce 'BUFSIZE', then that macro is
+expanded to produce the final result, '1024'.
+
+   Notice that 'BUFSIZE' was not defined when 'TABLESIZE' was defined.
+The '#define' for 'TABLESIZE' uses exactly the expansion you specify--in
+this case, 'BUFSIZE'--and does not check to see whether it too contains
+macro names.  Only when you _use_ 'TABLESIZE' is the result of its
+expansion scanned for more macro names.
+
+   This makes a difference if you change the definition of 'BUFSIZE' at
+some point in the source file.  'TABLESIZE', defined as shown, will
+always expand using the definition of 'BUFSIZE' that is currently in
+effect:
+
+     #define BUFSIZE 1020
+     #define TABLESIZE BUFSIZE
+     #undef BUFSIZE
+     #define BUFSIZE 37
+
+Now 'TABLESIZE' expands (in two stages) to '37'.
+
+   If the expansion of a macro contains its own name, either directly or
+via intermediate macros, it is not expanded again when the expansion is
+examined for more macros.  This prevents infinite recursion.  *Note
+Self-Referential Macros::, for the precise details.
+
+
+File: cpp.info,  Node: Function-like Macros,  Next: Macro Arguments,  Prev: Object-like Macros,  Up: Macros
+
+3.2 Function-like Macros
+========================
+
+You can also define macros whose use looks like a function call.  These
+are called "function-like macros".  To define a function-like macro, you
+use the same '#define' directive, but you put a pair of parentheses
+immediately after the macro name.  For example,
+
+     #define lang_init()  c_init()
+     lang_init()
+          ==> c_init()
+
+   A function-like macro is only expanded if its name appears with a
+pair of parentheses after it.  If you write just the name, it is left
+alone.  This can be useful when you have a function and a macro of the
+same name, and you wish to use the function sometimes.
+
+     extern void foo(void);
+     #define foo() /* optimized inline version */
+     ...
+       foo();
+       funcptr = foo;
+
+   Here the call to 'foo()' will use the macro, but the function pointer
+will get the address of the real function.  If the macro were to be
+expanded, it would cause a syntax error.
+
+   If you put spaces between the macro name and the parentheses in the
+macro definition, that does not define a function-like macro, it defines
+an object-like macro whose expansion happens to begin with a pair of
+parentheses.
+
+     #define lang_init ()    c_init()
+     lang_init()
+          ==> () c_init()()
+
+   The first two pairs of parentheses in this expansion come from the
+macro.  The third is the pair that was originally after the macro
+invocation.  Since 'lang_init' is an object-like macro, it does not
+consume those parentheses.
+
+
+File: cpp.info,  Node: Macro Arguments,  Next: Stringification,  Prev: Function-like Macros,  Up: Macros
+
+3.3 Macro Arguments
+===================
+
+Function-like macros can take "arguments", just like true functions.  To
+define a macro that uses arguments, you insert "parameters" between the
+pair of parentheses in the macro definition that make the macro
+function-like.  The parameters must be valid C identifiers, separated by
+commas and optionally whitespace.
+
+   To invoke a macro that takes arguments, you write the name of the
+macro followed by a list of "actual arguments" in parentheses, separated
+by commas.  The invocation of the macro need not be restricted to a
+single logical line--it can cross as many lines in the source file as
+you wish.  The number of arguments you give must match the number of
+parameters in the macro definition.  When the macro is expanded, each
+use of a parameter in its body is replaced by the tokens of the
+corresponding argument.  (You need not use all of the parameters in the
+macro body.)
+
+   As an example, here is a macro that computes the minimum of two
+numeric values, as it is defined in many C programs, and some uses.
+
+     #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
+       x = min(a, b);          ==>  x = ((a) < (b) ? (a) : (b));
+       y = min(1, 2);          ==>  y = ((1) < (2) ? (1) : (2));
+       z = min(a + 28, *p);    ==>  z = ((a + 28) < (*p) ? (a + 28) : (*p));
+
+(In this small example you can already see several of the dangers of
+macro arguments.  *Note Macro Pitfalls::, for detailed explanations.)
+
+   Leading and trailing whitespace in each argument is dropped, and all
+whitespace between the tokens of an argument is reduced to a single
+space.  Parentheses within each argument must balance; a comma within
+such parentheses does not end the argument.  However, there is no
+requirement for square brackets or braces to balance, and they do not
+prevent a comma from separating arguments.  Thus,
+
+     macro (array[x = y, x + 1])
+
+passes two arguments to 'macro': 'array[x = y' and 'x + 1]'.  If you
+want to supply 'array[x = y, x + 1]' as an argument, you can write it as
+'array[(x = y, x + 1)]', which is equivalent C code.
+
+   All arguments to a macro are completely macro-expanded before they
+are substituted into the macro body.  After substitution, the complete
+text is scanned again for macros to expand, including the arguments.
+This rule may seem strange, but it is carefully designed so you need not
+worry about whether any function call is actually a macro invocation.
+You can run into trouble if you try to be too clever, though.  *Note
+Argument Prescan::, for detailed discussion.
+
+   For example, 'min (min (a, b), c)' is first expanded to
+
+       min (((a) < (b) ? (a) : (b)), (c))
+
+and then to
+
+     ((((a) < (b) ? (a) : (b))) < (c)
+      ? (((a) < (b) ? (a) : (b)))
+      : (c))
+
+(Line breaks shown here for clarity would not actually be generated.)
+
+   You can leave macro arguments empty; this is not an error to the
+preprocessor (but many macros will then expand to invalid code).  You
+cannot leave out arguments entirely; if a macro takes two arguments,
+there must be exactly one comma at the top level of its argument list.
+Here are some silly examples using 'min':
+
+     min(, b)        ==> ((   ) < (b) ? (   ) : (b))
+     min(a, )        ==> ((a  ) < ( ) ? (a  ) : ( ))
+     min(,)          ==> ((   ) < ( ) ? (   ) : ( ))
+     min((,),)       ==> (((,)) < ( ) ? ((,)) : ( ))
+
+     min()      error-> macro "min" requires 2 arguments, but only 1 given
+     min(,,)    error-> macro "min" passed 3 arguments, but takes just 2
+
+   Whitespace is not a preprocessing token, so if a macro 'foo' takes
+one argument, 'foo ()' and 'foo ( )' both supply it an empty argument.
+Previous GNU preprocessor implementations and documentation were
+incorrect on this point, insisting that a function-like macro that takes
+a single argument be passed a space if an empty argument was required.
+
+   Macro parameters appearing inside string literals are not replaced by
+their corresponding actual arguments.
+
+     #define foo(x) x, "x"
+     foo(bar)        ==> bar, "x"
+
+
+File: cpp.info,  Node: Stringification,  Next: Concatenation,  Prev: Macro Arguments,  Up: Macros
+
+3.4 Stringification
+===================
+
+Sometimes you may want to convert a macro argument into a string
+constant.  Parameters are not replaced inside string constants, but you
+can use the '#' preprocessing operator instead.  When a macro parameter
+is used with a leading '#', the preprocessor replaces it with the
+literal text of the actual argument, converted to a string constant.
+Unlike normal parameter replacement, the argument is not macro-expanded
+first.  This is called "stringification".
+
+   There is no way to combine an argument with surrounding text and
+stringify it all together.  Instead, you can write a series of adjacent
+string constants and stringified arguments.  The preprocessor will
+replace the stringified arguments with string constants.  The C compiler
+will then combine all the adjacent string constants into one long
+string.
+
+   Here is an example of a macro definition that uses stringification:
+
+     #define WARN_IF(EXP) \
+     do { if (EXP) \
+             fprintf (stderr, "Warning: " #EXP "\n"); } \
+     while (0)
+     WARN_IF (x == 0);
+          ==> do { if (x == 0)
+                fprintf (stderr, "Warning: " "x == 0" "\n"); } while (0);
+
+The argument for 'EXP' is substituted once, as-is, into the 'if'
+statement, and once, stringified, into the argument to 'fprintf'.  If
+'x' were a macro, it would be expanded in the 'if' statement, but not in
+the string.
+
+   The 'do' and 'while (0)' are a kludge to make it possible to write
+'WARN_IF (ARG);', which the resemblance of 'WARN_IF' to a function would
+make C programmers want to do; see *note Swallowing the Semicolon::.
+
+   Stringification in C involves more than putting double-quote
+characters around the fragment.  The preprocessor backslash-escapes the
+quotes surrounding embedded string constants, and all backslashes within
+string and character constants, in order to get a valid C string
+constant with the proper contents.  Thus, stringifying 'p = "foo\n";'
+results in "p = \"foo\\n\";".  However, backslashes that are not inside
+string or character constants are not duplicated: '\n' by itself
+stringifies to "\n".
+
+   All leading and trailing whitespace in text being stringified is
+ignored.  Any sequence of whitespace in the middle of the text is
+converted to a single space in the stringified result.  Comments are
+replaced by whitespace long before stringification happens, so they
+never appear in stringified text.
+
+   There is no way to convert a macro argument into a character
+constant.
+
+   If you want to stringify the result of expansion of a macro argument,
+you have to use two levels of macros.
+
+     #define xstr(s) str(s)
+     #define str(s) #s
+     #define foo 4
+     str (foo)
+          ==> "foo"
+     xstr (foo)
+          ==> xstr (4)
+          ==> str (4)
+          ==> "4"
+
+   's' is stringified when it is used in 'str', so it is not
+macro-expanded first.  But 's' is an ordinary argument to 'xstr', so it
+is completely macro-expanded before 'xstr' itself is expanded (*note
+Argument Prescan::).  Therefore, by the time 'str' gets to its argument,
+it has already been macro-expanded.
+
+
+File: cpp.info,  Node: Concatenation,  Next: Variadic Macros,  Prev: Stringification,  Up: Macros
+
+3.5 Concatenation
+=================
+
+It is often useful to merge two tokens into one while expanding macros.
+This is called "token pasting" or "token concatenation".  The '##'
+preprocessing operator performs token pasting.  When a macro is
+expanded, the two tokens on either side of each '##' operator are
+combined into a single token, which then replaces the '##' and the two
+original tokens in the macro expansion.  Usually both will be
+identifiers, or one will be an identifier and the other a preprocessing
+number.  When pasted, they make a longer identifier.  This isn't the
+only valid case.  It is also possible to concatenate two numbers (or a
+number and a name, such as '1.5' and 'e3') into a number.  Also,
+multi-character operators such as '+=' can be formed by token pasting.
+
+   However, two tokens that don't together form a valid token cannot be
+pasted together.  For example, you cannot concatenate 'x' with '+' in
+either order.  If you try, the preprocessor issues a warning and emits
+the two tokens.  Whether it puts white space between the tokens is
+undefined.  It is common to find unnecessary uses of '##' in complex
+macros.  If you get this warning, it is likely that you can simply
+remove the '##'.
+
+   Both the tokens combined by '##' could come from the macro body, but
+you could just as well write them as one token in the first place.
+Token pasting is most useful when one or both of the tokens comes from a
+macro argument.  If either of the tokens next to an '##' is a parameter
+name, it is replaced by its actual argument before '##' executes.  As
+with stringification, the actual argument is not macro-expanded first.
+If the argument is empty, that '##' has no effect.
+
+   Keep in mind that the C preprocessor converts comments to whitespace
+before macros are even considered.  Therefore, you cannot create a
+comment by concatenating '/' and '*'.  You can put as much whitespace
+between '##' and its operands as you like, including comments, and you
+can put comments in arguments that will be concatenated.  However, it is
+an error if '##' appears at either end of a macro body.
+
+   Consider a C program that interprets named commands.  There probably
+needs to be a table of commands, perhaps an array of structures declared
+as follows:
+
+     struct command
+     {
+       char *name;
+       void (*function) (void);
+     };
+
+     struct command commands[] =
+     {
+       { "quit", quit_command },
+       { "help", help_command },
+       ...
+     };
+
+   It would be cleaner not to have to give each command name twice, once
+in the string constant and once in the function name.  A macro which
+takes the name of a command as an argument can make this unnecessary.
+The string constant can be created with stringification, and the
+function name by concatenating the argument with '_command'.  Here is
+how it is done:
+
+     #define COMMAND(NAME)  { #NAME, NAME ## _command }
+
+     struct command commands[] =
+     {
+       COMMAND (quit),
+       COMMAND (help),
+       ...
+     };
+
+
+File: cpp.info,  Node: Variadic Macros,  Next: Predefined Macros,  Prev: Concatenation,  Up: Macros
+
+3.6 Variadic Macros
+===================
+
+A macro can be declared to accept a variable number of arguments much as
+a function can.  The syntax for defining the macro is similar to that of
+a function.  Here is an example:
+
+     #define eprintf(...) fprintf (stderr, __VA_ARGS__)
+
+   This kind of macro is called "variadic".  When the macro is invoked,
+all the tokens in its argument list after the last named argument (this
+macro has none), including any commas, become the "variable argument".
+This sequence of tokens replaces the identifier '__VA_ARGS__' in the
+macro body wherever it appears.  Thus, we have this expansion:
+
+     eprintf ("%s:%d: ", input_file, lineno)
+          ==>  fprintf (stderr, "%s:%d: ", input_file, lineno)
+
+   The variable argument is completely macro-expanded before it is
+inserted into the macro expansion, just like an ordinary argument.  You
+may use the '#' and '##' operators to stringify the variable argument or
+to paste its leading or trailing token with another token.  (But see
+below for an important special case for '##'.)
+
+   If your macro is complicated, you may want a more descriptive name
+for the variable argument than '__VA_ARGS__'.  CPP permits this, as an
+extension.  You may write an argument name immediately before the '...';
+that name is used for the variable argument.  The 'eprintf' macro above
+could be written
+
+     #define eprintf(args...) fprintf (stderr, args)
+
+using this extension.  You cannot use '__VA_ARGS__' and this extension
+in the same macro.
+
+   You can have named arguments as well as variable arguments in a
+variadic macro.  We could define 'eprintf' like this, instead:
+
+     #define eprintf(format, ...) fprintf (stderr, format, __VA_ARGS__)
+
+This formulation looks more descriptive, but unfortunately it is less
+flexible: you must now supply at least one argument after the format
+string.  In standard C, you cannot omit the comma separating the named
+argument from the variable arguments.  Furthermore, if you leave the
+variable argument empty, you will get a syntax error, because there will
+be an extra comma after the format string.
+
+     eprintf("success!\n", );
+          ==> fprintf(stderr, "success!\n", );
+
+   GNU CPP has a pair of extensions which deal with this problem.
+First, you are allowed to leave the variable argument out entirely:
+
+     eprintf ("success!\n")
+          ==> fprintf(stderr, "success!\n", );
+
+Second, the '##' token paste operator has a special meaning when placed
+between a comma and a variable argument.  If you write
+
+     #define eprintf(format, ...) fprintf (stderr, format, ##__VA_ARGS__)
+
+and the variable argument is left out when the 'eprintf' macro is used,
+then the comma before the '##' will be deleted.  This does _not_ happen
+if you pass an empty argument, nor does it happen if the token preceding
+'##' is anything other than a comma.
+
+     eprintf ("success!\n")
+          ==> fprintf(stderr, "success!\n");
+
+The above explanation is ambiguous about the case where the only macro
+parameter is a variable arguments parameter, as it is meaningless to try
+to distinguish whether no argument at all is an empty argument or a
+missing argument.  In this case the C99 standard is clear that the comma
+must remain, however the existing GCC extension used to swallow the
+comma.  So CPP retains the comma when conforming to a specific C
+standard, and drops it otherwise.
+
+   C99 mandates that the only place the identifier '__VA_ARGS__' can
+appear is in the replacement list of a variadic macro.  It may not be
+used as a macro name, macro argument name, or within a different type of
+macro.  It may also be forbidden in open text; the standard is
+ambiguous.  We recommend you avoid using it except for its defined
+purpose.
+
+   Variadic macros are a new feature in C99.  GNU CPP has supported them
+for a long time, but only with a named variable argument ('args...', not
+'...' and '__VA_ARGS__').  If you are concerned with portability to
+previous versions of GCC, you should use only named variable arguments.
+On the other hand, if you are concerned with portability to other
+conforming implementations of C99, you should use only '__VA_ARGS__'.
+
+   Previous versions of CPP implemented the comma-deletion extension
+much more generally.  We have restricted it in this release to minimize
+the differences from C99.  To get the same effect with both this and
+previous versions of GCC, the token preceding the special '##' must be a
+comma, and there must be white space between that comma and whatever
+comes immediately before it:
+
+     #define eprintf(format, args...) fprintf (stderr, format , ##args)
+
+*Note Differences from previous versions::, for the gory details.
+
+
+File: cpp.info,  Node: Predefined Macros,  Next: Undefining and Redefining Macros,  Prev: Variadic Macros,  Up: Macros
+
+3.7 Predefined Macros
+=====================
+
+Several object-like macros are predefined; you use them without
+supplying their definitions.  They fall into three classes: standard,
+common, and system-specific.
+
+   In C++, there is a fourth category, the named operators.  They act
+like predefined macros, but you cannot undefine them.
+
+* Menu:
+
+* Standard Predefined Macros::
+* Common Predefined Macros::
+* System-specific Predefined Macros::
+* C++ Named Operators::
+
+
+File: cpp.info,  Node: Standard Predefined Macros,  Next: Common Predefined Macros,  Up: Predefined Macros
+
+3.7.1 Standard Predefined Macros
+--------------------------------
+
+The standard predefined macros are specified by the relevant language
+standards, so they are available with all compilers that implement those
+standards.  Older compilers may not provide all of them.  Their names
+all start with double underscores.
+
+'__FILE__'
+     This macro expands to the name of the current input file, in the
+     form of a C string constant.  This is the path by which the
+     preprocessor opened the file, not the short name specified in
+     '#include' or as the input file name argument.  For example,
+     '"/usr/local/include/myheader.h"' is a possible expansion of this
+     macro.
+
+'__LINE__'
+     This macro expands to the current input line number, in the form of
+     a decimal integer constant.  While we call it a predefined macro,
+     it's a pretty strange macro, since its "definition" changes with
+     each new line of source code.
+
+   '__FILE__' and '__LINE__' are useful in generating an error message
+to report an inconsistency detected by the program; the message can
+state the source line at which the inconsistency was detected.  For
+example,
+
+     fprintf (stderr, "Internal error: "
+                      "negative string length "
+                      "%d at %s, line %d.",
+              length, __FILE__, __LINE__);
+
+   An '#include' directive changes the expansions of '__FILE__' and
+'__LINE__' to correspond to the included file.  At the end of that file,
+when processing resumes on the input file that contained the '#include'
+directive, the expansions of '__FILE__' and '__LINE__' revert to the
+values they had before the '#include' (but '__LINE__' is then
+incremented by one as processing moves to the line after the
+'#include').
+
+   A '#line' directive changes '__LINE__', and may change '__FILE__' as
+well.  *Note Line Control::.
+
+   C99 introduces '__func__', and GCC has provided '__FUNCTION__' for a
+long time.  Both of these are strings containing the name of the current
+function (there are slight semantic differences; see the GCC manual).
+Neither of them is a macro; the preprocessor does not know the name of
+the current function.  They tend to be useful in conjunction with
+'__FILE__' and '__LINE__', though.
+
+'__DATE__'
+     This macro expands to a string constant that describes the date on
+     which the preprocessor is being run.  The string constant contains
+     eleven characters and looks like '"Feb 12 1996"'.  If the day of
+     the month is less than 10, it is padded with a space on the left.
+
+     If GCC cannot determine the current date, it will emit a warning
+     message (once per compilation) and '__DATE__' will expand to
+     '"??? ?? ????"'.
+
+'__TIME__'
+     This macro expands to a string constant that describes the time at
+     which the preprocessor is being run.  The string constant contains
+     eight characters and looks like '"23:59:01"'.
+
+     If GCC cannot determine the current time, it will emit a warning
+     message (once per compilation) and '__TIME__' will expand to
+     '"??:??:??"'.
+
+'__STDC__'
+     In normal operation, this macro expands to the constant 1, to
+     signify that this compiler conforms to ISO Standard C.  If GNU CPP
+     is used with a compiler other than GCC, this is not necessarily
+     true; however, the preprocessor always conforms to the standard
+     unless the '-traditional-cpp' option is used.
+
+     This macro is not defined if the '-traditional-cpp' option is used.
+
+     On some hosts, the system compiler uses a different convention,
+     where '__STDC__' is normally 0, but is 1 if the user specifies
+     strict conformance to the C Standard.  CPP follows the host
+     convention when processing system header files, but when processing
+     user files '__STDC__' is always 1.  This has been reported to cause
+     problems; for instance, some versions of Solaris provide X Windows
+     headers that expect '__STDC__' to be either undefined or 1.  *Note
+     Invocation::.
+
+'__STDC_VERSION__'
+     This macro expands to the C Standard's version number, a long
+     integer constant of the form 'YYYYMML' where YYYY and MM are the
+     year and month of the Standard version.  This signifies which
+     version of the C Standard the compiler conforms to.  Like
+     '__STDC__', this is not necessarily accurate for the entire
+     implementation, unless GNU CPP is being used with GCC.
+
+     The value '199409L' signifies the 1989 C standard as amended in
+     1994, which is the current default; the value '199901L' signifies
+     the 1999 revision of the C standard.  Support for the 1999 revision
+     is not yet complete.
+
+     This macro is not defined if the '-traditional-cpp' option is used,
+     nor when compiling C++ or Objective-C.
+
+'__STDC_HOSTED__'
+     This macro is defined, with value 1, if the compiler's target is a
+     "hosted environment".  A hosted environment has the complete
+     facilities of the standard C library available.
+
+'__cplusplus'
+     This macro is defined when the C++ compiler is in use.  You can use
+     '__cplusplus' to test whether a header is compiled by a C compiler
+     or a C++ compiler.  This macro is similar to '__STDC_VERSION__', in
+     that it expands to a version number.  Depending on the language
+     standard selected, the value of the macro is '199711L', as mandated
+     by the 1998 C++ standard; '201103L', per the 2011 C++ standard; an
+     unspecified value strictly larger than '201103L' for the
+     experimental languages enabled by '-std=c++1y' and '-std=gnu++1y'.
+
+'__OBJC__'
+     This macro is defined, with value 1, when the Objective-C compiler
+     is in use.  You can use '__OBJC__' to test whether a header is
+     compiled by a C compiler or an Objective-C compiler.
+
+'__ASSEMBLER__'
+     This macro is defined with value 1 when preprocessing assembly
+     language.
+
+
+File: cpp.info,  Node: Common Predefined Macros,  Next: System-specific Predefined Macros,  Prev: Standard Predefined Macros,  Up: Predefined Macros
+
+3.7.2 Common Predefined Macros
+------------------------------
+
+The common predefined macros are GNU C extensions.  They are available
+with the same meanings regardless of the machine or operating system on
+which you are using GNU C or GNU Fortran.  Their names all start with
+double underscores.
+
+'__COUNTER__'
+     This macro expands to sequential integral values starting from 0.
+     In conjunction with the '##' operator, this provides a convenient
+     means to generate unique identifiers.  Care must be taken to ensure
+     that '__COUNTER__' is not expanded prior to inclusion of
+     precompiled headers which use it.  Otherwise, the precompiled
+     headers will not be used.
+
+'__GFORTRAN__'
+     The GNU Fortran compiler defines this.
+
+'__GNUC__'
+'__GNUC_MINOR__'
+'__GNUC_PATCHLEVEL__'
+     These macros are defined by all GNU compilers that use the C
+     preprocessor: C, C++, Objective-C and Fortran.  Their values are
+     the major version, minor version, and patch level of the compiler,
+     as integer constants.  For example, GCC 3.2.1 will define
+     '__GNUC__' to 3, '__GNUC_MINOR__' to 2, and '__GNUC_PATCHLEVEL__'
+     to 1.  These macros are also defined if you invoke the preprocessor
+     directly.
+
+     '__GNUC_PATCHLEVEL__' is new to GCC 3.0; it is also present in the
+     widely-used development snapshots leading up to 3.0 (which identify
+     themselves as GCC 2.96 or 2.97, depending on which snapshot you
+     have).
+
+     If all you need to know is whether or not your program is being
+     compiled by GCC, or a non-GCC compiler that claims to accept the
+     GNU C dialects, you can simply test '__GNUC__'.  If you need to
+     write code which depends on a specific version, you must be more
+     careful.  Each time the minor version is increased, the patch level
+     is reset to zero; each time the major version is increased (which
+     happens rarely), the minor version and patch level are reset.  If
+     you wish to use the predefined macros directly in the conditional,
+     you will need to write it like this:
+
+          /* Test for GCC > 3.2.0 */
+          #if __GNUC__ > 3 || \
+              (__GNUC__ == 3 && (__GNUC_MINOR__ > 2 || \
+                                 (__GNUC_MINOR__ == 2 && \
+                                  __GNUC_PATCHLEVEL__ > 0))
+
+     Another approach is to use the predefined macros to calculate a
+     single number, then compare that against a threshold:
+
+          #define GCC_VERSION (__GNUC__ * 10000 \
+                               + __GNUC_MINOR__ * 100 \
+                               + __GNUC_PATCHLEVEL__)
+          ...
+          /* Test for GCC > 3.2.0 */
+          #if GCC_VERSION > 30200
+
+     Many people find this form easier to understand.
+
+'__GNUG__'
+     The GNU C++ compiler defines this.  Testing it is equivalent to
+     testing '(__GNUC__ && __cplusplus)'.
+
+'__STRICT_ANSI__'
+     GCC defines this macro if and only if the '-ansi' switch, or a
+     '-std' switch specifying strict conformance to some version of ISO
+     C or ISO C++, was specified when GCC was invoked.  It is defined to
+     '1'.  This macro exists primarily to direct GNU libc's header files
+     to restrict their definitions to the minimal set found in the 1989
+     C standard.
+
+'__BASE_FILE__'
+     This macro expands to the name of the main input file, in the form
+     of a C string constant.  This is the source file that was specified
+     on the command line of the preprocessor or C compiler.
+
+'__INCLUDE_LEVEL__'
+     This macro expands to a decimal integer constant that represents
+     the depth of nesting in include files.  The value of this macro is
+     incremented on every '#include' directive and decremented at the
+     end of every included file.  It starts out at 0, its value within
+     the base file specified on the command line.
+
+'__ELF__'
+     This macro is defined if the target uses the ELF object format.
+
+'__VERSION__'
+     This macro expands to a string constant which describes the version
+     of the compiler in use.  You should not rely on its contents having
+     any particular form, but it can be counted on to contain at least
+     the release number.
+
+'__OPTIMIZE__'
+'__OPTIMIZE_SIZE__'
+'__NO_INLINE__'
+     These macros describe the compilation mode.  '__OPTIMIZE__' is
+     defined in all optimizing compilations.  '__OPTIMIZE_SIZE__' is
+     defined if the compiler is optimizing for size, not speed.
+     '__NO_INLINE__' is defined if no functions will be inlined into
+     their callers (when not optimizing, or when inlining has been
+     specifically disabled by '-fno-inline').
+
+     These macros cause certain GNU header files to provide optimized
+     definitions, using macros or inline functions, of system library
+     functions.  You should not use these macros in any way unless you
+     make sure that programs will execute with the same effect whether
+     or not they are defined.  If they are defined, their value is 1.
+
+'__GNUC_GNU_INLINE__'
+     GCC defines this macro if functions declared 'inline' will be
+     handled in GCC's traditional gnu90 mode.  Object files will contain
+     externally visible definitions of all functions declared 'inline'
+     without 'extern' or 'static'.  They will not contain any
+     definitions of any functions declared 'extern inline'.
+
+'__GNUC_STDC_INLINE__'
+     GCC defines this macro if functions declared 'inline' will be
+     handled according to the ISO C99 standard.  Object files will
+     contain externally visible definitions of all functions declared
+     'extern inline'.  They will not contain definitions of any
+     functions declared 'inline' without 'extern'.
+
+     If this macro is defined, GCC supports the 'gnu_inline' function
+     attribute as a way to always get the gnu90 behavior.  Support for
+     this and '__GNUC_GNU_INLINE__' was added in GCC 4.1.3.  If neither
+     macro is defined, an older version of GCC is being used: 'inline'
+     functions will be compiled in gnu90 mode, and the 'gnu_inline'
+     function attribute will not be recognized.
+
+'__CHAR_UNSIGNED__'
+     GCC defines this macro if and only if the data type 'char' is
+     unsigned on the target machine.  It exists to cause the standard
+     header file 'limits.h' to work correctly.  You should not use this
+     macro yourself; instead, refer to the standard macros defined in
+     'limits.h'.
+
+'__WCHAR_UNSIGNED__'
+     Like '__CHAR_UNSIGNED__', this macro is defined if and only if the
+     data type 'wchar_t' is unsigned and the front-end is in C++ mode.
+
+'__REGISTER_PREFIX__'
+     This macro expands to a single token (not a string constant) which
+     is the prefix applied to CPU register names in assembly language
+     for this target.  You can use it to write assembly that is usable
+     in multiple environments.  For example, in the 'm68k-aout'
+     environment it expands to nothing, but in the 'm68k-coff'
+     environment it expands to a single '%'.
+
+'__USER_LABEL_PREFIX__'
+     This macro expands to a single token which is the prefix applied to
+     user labels (symbols visible to C code) in assembly.  For example,
+     in the 'm68k-aout' environment it expands to an '_', but in the
+     'm68k-coff' environment it expands to nothing.
+
+     This macro will have the correct definition even if
+     '-f(no-)underscores' is in use, but it will not be correct if
+     target-specific options that adjust this prefix are used (e.g. the
+     OSF/rose '-mno-underscores' option).
+
+'__SIZE_TYPE__'
+'__PTRDIFF_TYPE__'
+'__WCHAR_TYPE__'
+'__WINT_TYPE__'
+'__INTMAX_TYPE__'
+'__UINTMAX_TYPE__'
+'__SIG_ATOMIC_TYPE__'
+'__INT8_TYPE__'
+'__INT16_TYPE__'
+'__INT32_TYPE__'
+'__INT64_TYPE__'
+'__UINT8_TYPE__'
+'__UINT16_TYPE__'
+'__UINT32_TYPE__'
+'__UINT64_TYPE__'
+'__INT_LEAST8_TYPE__'
+'__INT_LEAST16_TYPE__'
+'__INT_LEAST32_TYPE__'
+'__INT_LEAST64_TYPE__'
+'__UINT_LEAST8_TYPE__'
+'__UINT_LEAST16_TYPE__'
+'__UINT_LEAST32_TYPE__'
+'__UINT_LEAST64_TYPE__'
+'__INT_FAST8_TYPE__'
+'__INT_FAST16_TYPE__'
+'__INT_FAST32_TYPE__'
+'__INT_FAST64_TYPE__'
+'__UINT_FAST8_TYPE__'
+'__UINT_FAST16_TYPE__'
+'__UINT_FAST32_TYPE__'
+'__UINT_FAST64_TYPE__'
+'__INTPTR_TYPE__'
+'__UINTPTR_TYPE__'
+     These macros are defined to the correct underlying types for the
+     'size_t', 'ptrdiff_t', 'wchar_t', 'wint_t', 'intmax_t',
+     'uintmax_t', 'sig_atomic_t', 'int8_t', 'int16_t', 'int32_t',
+     'int64_t', 'uint8_t', 'uint16_t', 'uint32_t', 'uint64_t',
+     'int_least8_t', 'int_least16_t', 'int_least32_t', 'int_least64_t',
+     'uint_least8_t', 'uint_least16_t', 'uint_least32_t',
+     'uint_least64_t', 'int_fast8_t', 'int_fast16_t', 'int_fast32_t',
+     'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t', 'uint_fast32_t',
+     'uint_fast64_t', 'intptr_t', and 'uintptr_t' typedefs,
+     respectively.  They exist to make the standard header files
+     'stddef.h', 'stdint.h', and 'wchar.h' work correctly.  You should
+     not use these macros directly; instead, include the appropriate
+     headers and use the typedefs.  Some of these macros may not be
+     defined on particular systems if GCC does not provide a 'stdint.h'
+     header on those systems.
+
+'__CHAR_BIT__'
+     Defined to the number of bits used in the representation of the
+     'char' data type.  It exists to make the standard header given
+     numerical limits work correctly.  You should not use this macro
+     directly; instead, include the appropriate headers.
+
+'__SCHAR_MAX__'
+'__WCHAR_MAX__'
+'__SHRT_MAX__'
+'__INT_MAX__'
+'__LONG_MAX__'
+'__LONG_LONG_MAX__'
+'__WINT_MAX__'
+'__SIZE_MAX__'
+'__PTRDIFF_MAX__'
+'__INTMAX_MAX__'
+'__UINTMAX_MAX__'
+'__SIG_ATOMIC_MAX__'
+'__INT8_MAX__'
+'__INT16_MAX__'
+'__INT32_MAX__'
+'__INT64_MAX__'
+'__UINT8_MAX__'
+'__UINT16_MAX__'
+'__UINT32_MAX__'
+'__UINT64_MAX__'
+'__INT_LEAST8_MAX__'
+'__INT_LEAST16_MAX__'
+'__INT_LEAST32_MAX__'
+'__INT_LEAST64_MAX__'
+'__UINT_LEAST8_MAX__'
+'__UINT_LEAST16_MAX__'
+'__UINT_LEAST32_MAX__'
+'__UINT_LEAST64_MAX__'
+'__INT_FAST8_MAX__'
+'__INT_FAST16_MAX__'
+'__INT_FAST32_MAX__'
+'__INT_FAST64_MAX__'
+'__UINT_FAST8_MAX__'
+'__UINT_FAST16_MAX__'
+'__UINT_FAST32_MAX__'
+'__UINT_FAST64_MAX__'
+'__INTPTR_MAX__'
+'__UINTPTR_MAX__'
+'__WCHAR_MIN__'
+'__WINT_MIN__'
+'__SIG_ATOMIC_MIN__'
+     Defined to the maximum value of the 'signed char', 'wchar_t',
+     'signed short', 'signed int', 'signed long', 'signed long long',
+     'wint_t', 'size_t', 'ptrdiff_t', 'intmax_t', 'uintmax_t',
+     'sig_atomic_t', 'int8_t', 'int16_t', 'int32_t', 'int64_t',
+     'uint8_t', 'uint16_t', 'uint32_t', 'uint64_t', 'int_least8_t',
+     'int_least16_t', 'int_least32_t', 'int_least64_t', 'uint_least8_t',
+     'uint_least16_t', 'uint_least32_t', 'uint_least64_t',
+     'int_fast8_t', 'int_fast16_t', 'int_fast32_t', 'int_fast64_t',
+     'uint_fast8_t', 'uint_fast16_t', 'uint_fast32_t', 'uint_fast64_t',
+     'intptr_t', and 'uintptr_t' types and to the minimum value of the
+     'wchar_t', 'wint_t', and 'sig_atomic_t' types respectively.  They
+     exist to make the standard header given numerical limits work
+     correctly.  You should not use these macros directly; instead,
+     include the appropriate headers.  Some of these macros may not be
+     defined on particular systems if GCC does not provide a 'stdint.h'
+     header on those systems.
+
+'__INT8_C'
+'__INT16_C'
+'__INT32_C'
+'__INT64_C'
+'__UINT8_C'
+'__UINT16_C'
+'__UINT32_C'
+'__UINT64_C'
+'__INTMAX_C'
+'__UINTMAX_C'
+     Defined to implementations of the standard 'stdint.h' macros with
+     the same names without the leading '__'.  They exist the make the
+     implementation of that header work correctly.  You should not use
+     these macros directly; instead, include the appropriate headers.
+     Some of these macros may not be defined on particular systems if
+     GCC does not provide a 'stdint.h' header on those systems.
+
+'__SIZEOF_INT__'
+'__SIZEOF_LONG__'
+'__SIZEOF_LONG_LONG__'
+'__SIZEOF_SHORT__'
+'__SIZEOF_POINTER__'
+'__SIZEOF_FLOAT__'
+'__SIZEOF_DOUBLE__'
+'__SIZEOF_LONG_DOUBLE__'
+'__SIZEOF_SIZE_T__'
+'__SIZEOF_WCHAR_T__'
+'__SIZEOF_WINT_T__'
+'__SIZEOF_PTRDIFF_T__'
+     Defined to the number of bytes of the C standard data types: 'int',
+     'long', 'long long', 'short', 'void *', 'float', 'double', 'long
+     double', 'size_t', 'wchar_t', 'wint_t' and 'ptrdiff_t'.
+
+'__BYTE_ORDER__'
+'__ORDER_LITTLE_ENDIAN__'
+'__ORDER_BIG_ENDIAN__'
+'__ORDER_PDP_ENDIAN__'
+     '__BYTE_ORDER__' is defined to one of the values
+     '__ORDER_LITTLE_ENDIAN__', '__ORDER_BIG_ENDIAN__', or
+     '__ORDER_PDP_ENDIAN__' to reflect the layout of multi-byte and
+     multi-word quantities in memory.  If '__BYTE_ORDER__' is equal to
+     '__ORDER_LITTLE_ENDIAN__' or '__ORDER_BIG_ENDIAN__', then
+     multi-byte and multi-word quantities are laid out identically: the
+     byte (word) at the lowest address is the least significant or most
+     significant byte (word) of the quantity, respectively.  If
+     '__BYTE_ORDER__' is equal to '__ORDER_PDP_ENDIAN__', then bytes in
+     16-bit words are laid out in a little-endian fashion, whereas the
+     16-bit subwords of a 32-bit quantity are laid out in big-endian
+     fashion.
+
+     You should use these macros for testing like this:
+
+          /* Test for a little-endian machine */
+          #if __BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__
+
+'__FLOAT_WORD_ORDER__'
+     '__FLOAT_WORD_ORDER__' is defined to one of the values
+     '__ORDER_LITTLE_ENDIAN__' or '__ORDER_BIG_ENDIAN__' to reflect the
+     layout of the words of multi-word floating-point quantities.
+
+'__DEPRECATED'
+     This macro is defined, with value 1, when compiling a C++ source
+     file with warnings about deprecated constructs enabled.  These
+     warnings are enabled by default, but can be disabled with
+     '-Wno-deprecated'.
+
+'__EXCEPTIONS'
+     This macro is defined, with value 1, when compiling a C++ source
+     file with exceptions enabled.  If '-fno-exceptions' is used when
+     compiling the file, then this macro is not defined.
+
+'__GXX_RTTI'
+     This macro is defined, with value 1, when compiling a C++ source
+     file with runtime type identification enabled.  If '-fno-rtti' is
+     used when compiling the file, then this macro is not defined.
+
+'__USING_SJLJ_EXCEPTIONS__'
+     This macro is defined, with value 1, if the compiler uses the old
+     mechanism based on 'setjmp' and 'longjmp' for exception handling.
+
+'__GXX_EXPERIMENTAL_CXX0X__'
+     This macro is defined when compiling a C++ source file with the
+     option '-std=c++0x' or '-std=gnu++0x'.  It indicates that some
+     features likely to be included in C++0x are available.  Note that
+     these features are experimental, and may change or be removed in
+     future versions of GCC.
+
+'__GXX_WEAK__'
+     This macro is defined when compiling a C++ source file.  It has the
+     value 1 if the compiler will use weak symbols, COMDAT sections, or
+     other similar techniques to collapse symbols with "vague linkage"
+     that are defined in multiple translation units.  If the compiler
+     will not collapse such symbols, this macro is defined with value 0.
+     In general, user code should not need to make use of this macro;
+     the purpose of this macro is to ease implementation of the C++
+     runtime library provided with G++.
+
+'__NEXT_RUNTIME__'
+     This macro is defined, with value 1, if (and only if) the NeXT
+     runtime (as in '-fnext-runtime') is in use for Objective-C.  If the
+     GNU runtime is used, this macro is not defined, so that you can use
+     this macro to determine which runtime (NeXT or GNU) is being used.
+
+'__LP64__'
+'_LP64'
+     These macros are defined, with value 1, if (and only if) the
+     compilation is for a target where 'long int' and pointer both use
+     64-bits and 'int' uses 32-bit.
+
+'__SSP__'
+     This macro is defined, with value 1, when '-fstack-protector' is in
+     use.
+
+'__SSP_ALL__'
+     This macro is defined, with value 2, when '-fstack-protector-all'
+     is in use.
+
+'__SSP_STRONG__'
+     This macro is defined, with value 3, when
+     '-fstack-protector-strong' is in use.
+
+'__SANITIZE_ADDRESS__'
+     This macro is defined, with value 1, when '-fsanitize=address' is
+     in use.
+
+'__TIMESTAMP__'
+     This macro expands to a string constant that describes the date and
+     time of the last modification of the current source file.  The
+     string constant contains abbreviated day of the week, month, day of
+     the month, time in hh:mm:ss form, year and looks like
+     '"Sun Sep 16 01:03:52 1973"'.  If the day of the month is less than
+     10, it is padded with a space on the left.
+
+     If GCC cannot determine the current date, it will emit a warning
+     message (once per compilation) and '__TIMESTAMP__' will expand to
+     '"??? ??? ?? ??:??:?? ????"'.
+
+'__GCC_HAVE_SYNC_COMPARE_AND_SWAP_1'
+'__GCC_HAVE_SYNC_COMPARE_AND_SWAP_2'
+'__GCC_HAVE_SYNC_COMPARE_AND_SWAP_4'
+'__GCC_HAVE_SYNC_COMPARE_AND_SWAP_8'
+'__GCC_HAVE_SYNC_COMPARE_AND_SWAP_16'
+     These macros are defined when the target processor supports atomic
+     compare and swap operations on operands 1, 2, 4, 8 or 16 bytes in
+     length, respectively.
+
+'__GCC_HAVE_DWARF2_CFI_ASM'
+     This macro is defined when the compiler is emitting Dwarf2 CFI
+     directives to the assembler.  When this is defined, it is possible
+     to emit those same directives in inline assembly.
+
+'__FP_FAST_FMA'
+'__FP_FAST_FMAF'
+'__FP_FAST_FMAL'
+     These macros are defined with value 1 if the backend supports the
+     'fma', 'fmaf', and 'fmal' builtin functions, so that the include
+     file 'math.h' can define the macros 'FP_FAST_FMA', 'FP_FAST_FMAF',
+     and 'FP_FAST_FMAL' for compatibility with the 1999 C standard.
+
+'__GCC_IEC_559'
+     This macro is defined to indicate the intended level of support for
+     IEEE 754 (IEC 60559) floating-point arithmetic.  It expands to a
+     nonnegative integer value.  If 0, it indicates that the combination
+     of the compiler configuration and the command-line options is not
+     intended to support IEEE 754 arithmetic for 'float' and 'double' as
+     defined in C99 and C11 Annex F (for example, that the standard
+     rounding modes and exceptions are not supported, or that
+     optimizations are enabled that conflict with IEEE 754 semantics).
+     If 1, it indicates that IEEE 754 arithmetic is intended to be
+     supported; this does not mean that all relevant language features
+     are supported by GCC. If 2 or more, it additionally indicates
+     support for IEEE 754-2008 (in particular, that the binary encodings
+     for quiet and signaling NaNs are as specified in IEEE 754-2008).
+
+     This macro does not indicate the default state of command-line
+     options that control optimizations that C99 and C11 permit to be
+     controlled by standard pragmas, where those standards do not
+     require a particular default state.  It does not indicate whether
+     optimizations respect signaling NaN semantics (the macro for that
+     is '__SUPPORT_SNAN__').  It does not indicate support for decimal
+     floating point or the IEEE 754 binary16 and binary128 types.
+
+'__GCC_IEC_559_COMPLEX'
+     This macro is defined to indicate the intended level of support for
+     IEEE 754 (IEC 60559) floating-point arithmetic for complex numbers,
+     as defined in C99 and C11 Annex G. It expands to a nonnegative
+     integer value.  If 0, it indicates that the combination of the
+     compiler configuration and the command-line options is not intended
+     to support Annex G requirements (for example, because
+     '-fcx-limited-range' was used).  If 1 or more, it indicates that it
+     is intended to support those requirements; this does not mean that
+     all relevant language features are supported by GCC.
+
+
+File: cpp.info,  Node: System-specific Predefined Macros,  Next: C++ Named Operators,  Prev: Common Predefined Macros,  Up: Predefined Macros
+
+3.7.3 System-specific Predefined Macros
+---------------------------------------
+
+The C preprocessor normally predefines several macros that indicate what
+type of system and machine is in use.  They are obviously different on
+each target supported by GCC.  This manual, being for all systems and
+machines, cannot tell you what their names are, but you can use 'cpp
+-dM' to see them all.  *Note Invocation::.  All system-specific
+predefined macros expand to a constant value, so you can test them with
+either '#ifdef' or '#if'.
+
+   The C standard requires that all system-specific macros be part of
+the "reserved namespace".  All names which begin with two underscores,
+or an underscore and a capital letter, are reserved for the compiler and
+library to use as they wish.  However, historically system-specific
+macros have had names with no special prefix; for instance, it is common
+to find 'unix' defined on Unix systems.  For all such macros, GCC
+provides a parallel macro with two underscores added at the beginning
+and the end.  If 'unix' is defined, '__unix__' will be defined too.
+There will never be more than two underscores; the parallel of '_mips'
+is '__mips__'.
+
+   When the '-ansi' option, or any '-std' option that requests strict
+conformance, is given to the compiler, all the system-specific
+predefined macros outside the reserved namespace are suppressed.  The
+parallel macros, inside the reserved namespace, remain defined.
+
+   We are slowly phasing out all predefined macros which are outside the
+reserved namespace.  You should never use them in new programs, and we
+encourage you to correct older code to use the parallel macros whenever
+you find it.  We don't recommend you use the system-specific macros that
+are in the reserved namespace, either.  It is better in the long run to
+check specifically for features you need, using a tool such as
+'autoconf'.
+
+
+File: cpp.info,  Node: C++ Named Operators,  Prev: System-specific Predefined Macros,  Up: Predefined Macros
+
+3.7.4 C++ Named Operators
+-------------------------
+
+In C++, there are eleven keywords which are simply alternate spellings
+of operators normally written with punctuation.  These keywords are
+treated as such even in the preprocessor.  They function as operators in
+'#if', and they cannot be defined as macros or poisoned.  In C, you can
+request that those keywords take their C++ meaning by including
+'iso646.h'.  That header defines each one as a normal object-like macro
+expanding to the appropriate punctuator.
+
+   These are the named operators and their corresponding punctuators:
+
+Named Operator   Punctuator
+'and'            '&&'
+'and_eq'         '&='
+'bitand'         '&'
+'bitor'          '|'
+'compl'          '~'
+'not'            '!'
+'not_eq'         '!='
+'or'             '||'
+'or_eq'          '|='
+'xor'            '^'
+'xor_eq'         '^='
+
+
+File: cpp.info,  Node: Undefining and Redefining Macros,  Next: Directives Within Macro Arguments,  Prev: Predefined Macros,  Up: Macros
+
+3.8 Undefining and Redefining Macros
+====================================
+
+If a macro ceases to be useful, it may be "undefined" with the '#undef'
+directive.  '#undef' takes a single argument, the name of the macro to
+undefine.  You use the bare macro name, even if the macro is
+function-like.  It is an error if anything appears on the line after the
+macro name.  '#undef' has no effect if the name is not a macro.
+
+     #define FOO 4
+     x = FOO;        ==> x = 4;
+     #undef FOO
+     x = FOO;        ==> x = FOO;
+
+   Once a macro has been undefined, that identifier may be "redefined"
+as a macro by a subsequent '#define' directive.  The new definition need
+not have any resemblance to the old definition.
+
+   However, if an identifier which is currently a macro is redefined,
+then the new definition must be "effectively the same" as the old one.
+Two macro definitions are effectively the same if:
+   * Both are the same type of macro (object- or function-like).
+   * All the tokens of the replacement list are the same.
+   * If there are any parameters, they are the same.
+   * Whitespace appears in the same places in both.  It need not be
+     exactly the same amount of whitespace, though.  Remember that
+     comments count as whitespace.
+
+These definitions are effectively the same:
+     #define FOUR (2 + 2)
+     #define FOUR         (2    +    2)
+     #define FOUR (2 /* two */ + 2)
+but these are not:
+     #define FOUR (2 + 2)
+     #define FOUR ( 2+2 )
+     #define FOUR (2 * 2)
+     #define FOUR(score,and,seven,years,ago) (2 + 2)
+
+   If a macro is redefined with a definition that is not effectively the
+same as the old one, the preprocessor issues a warning and changes the
+macro to use the new definition.  If the new definition is effectively
+the same, the redefinition is silently ignored.  This allows, for
+instance, two different headers to define a common macro.  The
+preprocessor will only complain if the definitions do not match.
+
+
+File: cpp.info,  Node: Directives Within Macro Arguments,  Next: Macro Pitfalls,  Prev: Undefining and Redefining Macros,  Up: Macros
+
+3.9 Directives Within Macro Arguments
+=====================================
+
+Occasionally it is convenient to use preprocessor directives within the
+arguments of a macro.  The C and C++ standards declare that behavior in
+these cases is undefined.
+
+   Versions of CPP prior to 3.2 would reject such constructs with an
+error message.  This was the only syntactic difference between normal
+functions and function-like macros, so it seemed attractive to remove
+this limitation, and people would often be surprised that they could not
+use macros in this way.  Moreover, sometimes people would use
+conditional compilation in the argument list to a normal library
+function like 'printf', only to find that after a library upgrade
+'printf' had changed to be a function-like macro, and their code would
+no longer compile.  So from version 3.2 we changed CPP to successfully
+process arbitrary directives within macro arguments in exactly the same
+way as it would have processed the directive were the function-like
+macro invocation not present.
+
+   If, within a macro invocation, that macro is redefined, then the new
+definition takes effect in time for argument pre-expansion, but the
+original definition is still used for argument replacement.  Here is a
+pathological example:
+
+     #define f(x) x x
+     f (1
+     #undef f
+     #define f 2
+     f)
+
+which expands to
+
+     1 2 1 2
+
+with the semantics described above.
+
+
+File: cpp.info,  Node: Macro Pitfalls,  Prev: Directives Within Macro Arguments,  Up: Macros
+
+3.10 Macro Pitfalls
+===================
+
+In this section we describe some special rules that apply to macros and
+macro expansion, and point out certain cases in which the rules have
+counter-intuitive consequences that you must watch out for.
+
+* Menu:
+
+* Misnesting::
+* Operator Precedence Problems::
+* Swallowing the Semicolon::
+* Duplication of Side Effects::
+* Self-Referential Macros::
+* Argument Prescan::
+* Newlines in Arguments::
+
+
+File: cpp.info,  Node: Misnesting,  Next: Operator Precedence Problems,  Up: Macro Pitfalls
+
+3.10.1 Misnesting
+-----------------
+
+When a macro is called with arguments, the arguments are substituted
+into the macro body and the result is checked, together with the rest of
+the input file, for more macro calls.  It is possible to piece together
+a macro call coming partially from the macro body and partially from the
+arguments.  For example,
+
+     #define twice(x) (2*(x))
+     #define call_with_1(x) x(1)
+     call_with_1 (twice)
+          ==> twice(1)
+          ==> (2*(1))
+
+   Macro definitions do not have to have balanced parentheses.  By
+writing an unbalanced open parenthesis in a macro body, it is possible
+to create a macro call that begins inside the macro body but ends
+outside of it.  For example,
+
+     #define strange(file) fprintf (file, "%s %d",
+     ...
+     strange(stderr) p, 35)
+          ==> fprintf (stderr, "%s %d", p, 35)
+
+   The ability to piece together a macro call can be useful, but the use
+of unbalanced open parentheses in a macro body is just confusing, and
+should be avoided.
+
+
+File: cpp.info,  Node: Operator Precedence Problems,  Next: Swallowing the Semicolon,  Prev: Misnesting,  Up: Macro Pitfalls
+
+3.10.2 Operator Precedence Problems
+-----------------------------------
+
+You may have noticed that in most of the macro definition examples shown
+above, each occurrence of a macro argument name had parentheses around
+it.  In addition, another pair of parentheses usually surround the
+entire macro definition.  Here is why it is best to write macros that
+way.
+
+   Suppose you define a macro as follows,
+
+     #define ceil_div(x, y) (x + y - 1) / y
+
+whose purpose is to divide, rounding up.  (One use for this operation is
+to compute how many 'int' objects are needed to hold a certain number of
+'char' objects.)  Then suppose it is used as follows:
+
+     a = ceil_div (b & c, sizeof (int));
+          ==> a = (b & c + sizeof (int) - 1) / sizeof (int);
+
+This does not do what is intended.  The operator-precedence rules of C
+make it equivalent to this:
+
+     a = (b & (c + sizeof (int) - 1)) / sizeof (int);
+
+What we want is this:
+
+     a = ((b & c) + sizeof (int) - 1)) / sizeof (int);
+
+Defining the macro as
+
+     #define ceil_div(x, y) ((x) + (y) - 1) / (y)
+
+provides the desired result.
+
+   Unintended grouping can result in another way.  Consider 'sizeof
+ceil_div(1, 2)'.  That has the appearance of a C expression that would
+compute the size of the type of 'ceil_div (1, 2)', but in fact it means
+something very different.  Here is what it expands to:
+
+     sizeof ((1) + (2) - 1) / (2)
+
+This would take the size of an integer and divide it by two.  The
+precedence rules have put the division outside the 'sizeof' when it was
+intended to be inside.
+
+   Parentheses around the entire macro definition prevent such problems.
+Here, then, is the recommended way to define 'ceil_div':
+
+     #define ceil_div(x, y) (((x) + (y) - 1) / (y))
+
+
+File: cpp.info,  Node: Swallowing the Semicolon,  Next: Duplication of Side Effects,  Prev: Operator Precedence Problems,  Up: Macro Pitfalls
+
+3.10.3 Swallowing the Semicolon
+-------------------------------
+
+Often it is desirable to define a macro that expands into a compound
+statement.  Consider, for example, the following macro, that advances a
+pointer (the argument 'p' says where to find it) across whitespace
+characters:
+
+     #define SKIP_SPACES(p, limit)  \
+     { char *lim = (limit);         \
+       while (p < lim) {            \
+         if (*p++ != ' ') {         \
+           p--; break; }}}
+
+Here backslash-newline is used to split the macro definition, which must
+be a single logical line, so that it resembles the way such code would
+be laid out if not part of a macro definition.
+
+   A call to this macro might be 'SKIP_SPACES (p, lim)'.  Strictly
+speaking, the call expands to a compound statement, which is a complete
+statement with no need for a semicolon to end it.  However, since it
+looks like a function call, it minimizes confusion if you can use it
+like a function call, writing a semicolon afterward, as in 'SKIP_SPACES
+(p, lim);'
+
+   This can cause trouble before 'else' statements, because the
+semicolon is actually a null statement.  Suppose you write
+
+     if (*p != 0)
+       SKIP_SPACES (p, lim);
+     else ...
+
+The presence of two statements--the compound statement and a null
+statement--in between the 'if' condition and the 'else' makes invalid C
+code.
+
+   The definition of the macro 'SKIP_SPACES' can be altered to solve
+this problem, using a 'do ... while' statement.  Here is how:
+
+     #define SKIP_SPACES(p, limit)     \
+     do { char *lim = (limit);         \
+          while (p < lim) {            \
+            if (*p++ != ' ') {         \
+              p--; break; }}}          \
+     while (0)
+
+   Now 'SKIP_SPACES (p, lim);' expands into
+
+     do {...} while (0);
+
+which is one statement.  The loop executes exactly once; most compilers
+generate no extra code for it.
+
+
+File: cpp.info,  Node: Duplication of Side Effects,  Next: Self-Referential Macros,  Prev: Swallowing the Semicolon,  Up: Macro Pitfalls
+
+3.10.4 Duplication of Side Effects
+----------------------------------
+
+Many C programs define a macro 'min', for "minimum", like this:
+
+     #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
+
+   When you use this macro with an argument containing a side effect, as
+shown here,
+
+     next = min (x + y, foo (z));
+
+it expands as follows:
+
+     next = ((x + y) < (foo (z)) ? (x + y) : (foo (z)));
+
+where 'x + y' has been substituted for 'X' and 'foo (z)' for 'Y'.
+
+   The function 'foo' is used only once in the statement as it appears
+in the program, but the expression 'foo (z)' has been substituted twice
+into the macro expansion.  As a result, 'foo' might be called two times
+when the statement is executed.  If it has side effects or if it takes a
+long time to compute, the results might not be what you intended.  We
+say that 'min' is an "unsafe" macro.
+
+   The best solution to this problem is to define 'min' in a way that
+computes the value of 'foo (z)' only once.  The C language offers no
+standard way to do this, but it can be done with GNU extensions as
+follows:
+
+     #define min(X, Y)                \
+     ({ typeof (X) x_ = (X);          \
+        typeof (Y) y_ = (Y);          \
+        (x_ < y_) ? x_ : y_; })
+
+   The '({ ... })' notation produces a compound statement that acts as
+an expression.  Its value is the value of its last statement.  This
+permits us to define local variables and assign each argument to one.
+The local variables have underscores after their names to reduce the
+risk of conflict with an identifier of wider scope (it is impossible to
+avoid this entirely).  Now each argument is evaluated exactly once.
+
+   If you do not wish to use GNU C extensions, the only solution is to
+be careful when _using_ the macro 'min'.  For example, you can calculate
+the value of 'foo (z)', save it in a variable, and use that variable in
+'min':
+
+     #define min(X, Y)  ((X) < (Y) ? (X) : (Y))
+     ...
+     {
+       int tem = foo (z);
+       next = min (x + y, tem);
+     }
+
+(where we assume that 'foo' returns type 'int').
+
+
+File: cpp.info,  Node: Self-Referential Macros,  Next: Argument Prescan,  Prev: Duplication of Side Effects,  Up: Macro Pitfalls
+
+3.10.5 Self-Referential Macros
+------------------------------
+
+A "self-referential" macro is one whose name appears in its definition.
+Recall that all macro definitions are rescanned for more macros to
+replace.  If the self-reference were considered a use of the macro, it
+would produce an infinitely large expansion.  To prevent this, the
+self-reference is not considered a macro call.  It is passed into the
+preprocessor output unchanged.  Consider an example:
+
+     #define foo (4 + foo)
+
+where 'foo' is also a variable in your program.
+
+   Following the ordinary rules, each reference to 'foo' will expand
+into '(4 + foo)'; then this will be rescanned and will expand into '(4 +
+(4 + foo))'; and so on until the computer runs out of memory.
+
+   The self-reference rule cuts this process short after one step, at
+'(4 + foo)'.  Therefore, this macro definition has the possibly useful
+effect of causing the program to add 4 to the value of 'foo' wherever
+'foo' is referred to.
+
+   In most cases, it is a bad idea to take advantage of this feature.  A
+person reading the program who sees that 'foo' is a variable will not
+expect that it is a macro as well.  The reader will come across the
+identifier 'foo' in the program and think its value should be that of
+the variable 'foo', whereas in fact the value is four greater.
+
+   One common, useful use of self-reference is to create a macro which
+expands to itself.  If you write
+
+     #define EPERM EPERM
+
+then the macro 'EPERM' expands to 'EPERM'.  Effectively, it is left
+alone by the preprocessor whenever it's used in running text.  You can
+tell that it's a macro with '#ifdef'.  You might do this if you want to
+define numeric constants with an 'enum', but have '#ifdef' be true for
+each constant.
+
+   If a macro 'x' expands to use a macro 'y', and the expansion of 'y'
+refers to the macro 'x', that is an "indirect self-reference" of 'x'.
+'x' is not expanded in this case either.  Thus, if we have
+
+     #define x (4 + y)
+     #define y (2 * x)
+
+then 'x' and 'y' expand as follows:
+
+     x    ==> (4 + y)
+          ==> (4 + (2 * x))
+
+     y    ==> (2 * x)
+          ==> (2 * (4 + y))
+
+Each macro is expanded when it appears in the definition of the other
+macro, but not when it indirectly appears in its own definition.
+
+
+File: cpp.info,  Node: Argument Prescan,  Next: Newlines in Arguments,  Prev: Self-Referential Macros,  Up: Macro Pitfalls
+
+3.10.6 Argument Prescan
+-----------------------
+
+Macro arguments are completely macro-expanded before they are
+substituted into a macro body, unless they are stringified or pasted
+with other tokens.  After substitution, the entire macro body, including
+the substituted arguments, is scanned again for macros to be expanded.
+The result is that the arguments are scanned _twice_ to expand macro
+calls in them.
+
+   Most of the time, this has no effect.  If the argument contained any
+macro calls, they are expanded during the first scan.  The result
+therefore contains no macro calls, so the second scan does not change
+it.  If the argument were substituted as given, with no prescan, the
+single remaining scan would find the same macro calls and produce the
+same results.
+
+   You might expect the double scan to change the results when a
+self-referential macro is used in an argument of another macro (*note
+Self-Referential Macros::): the self-referential macro would be expanded
+once in the first scan, and a second time in the second scan.  However,
+this is not what happens.  The self-references that do not expand in the
+first scan are marked so that they will not expand in the second scan
+either.
+
+   You might wonder, "Why mention the prescan, if it makes no
+difference?  And why not skip it and make the preprocessor faster?"  The
+answer is that the prescan does make a difference in three special
+cases:
+
+   * Nested calls to a macro.
+
+     We say that "nested" calls to a macro occur when a macro's argument
+     contains a call to that very macro.  For example, if 'f' is a macro
+     that expects one argument, 'f (f (1))' is a nested pair of calls to
+     'f'.  The desired expansion is made by expanding 'f (1)' and
+     substituting that into the definition of 'f'.  The prescan causes
+     the expected result to happen.  Without the prescan, 'f (1)' itself
+     would be substituted as an argument, and the inner use of 'f' would
+     appear during the main scan as an indirect self-reference and would
+     not be expanded.
+
+   * Macros that call other macros that stringify or concatenate.
+
+     If an argument is stringified or concatenated, the prescan does not
+     occur.  If you _want_ to expand a macro, then stringify or
+     concatenate its expansion, you can do that by causing one macro to
+     call another macro that does the stringification or concatenation.
+     For instance, if you have
+
+          #define AFTERX(x) X_ ## x
+          #define XAFTERX(x) AFTERX(x)
+          #define TABLESIZE 1024
+          #define BUFSIZE TABLESIZE
+
+     then 'AFTERX(BUFSIZE)' expands to 'X_BUFSIZE', and
+     'XAFTERX(BUFSIZE)' expands to 'X_1024'.  (Not to 'X_TABLESIZE'.
+     Prescan always does a complete expansion.)
+
+   * Macros used in arguments, whose expansions contain unshielded
+     commas.
+
+     This can cause a macro expanded on the second scan to be called
+     with the wrong number of arguments.  Here is an example:
+
+          #define foo  a,b
+          #define bar(x) lose(x)
+          #define lose(x) (1 + (x))
+
+     We would like 'bar(foo)' to turn into '(1 + (foo))', which would
+     then turn into '(1 + (a,b))'.  Instead, 'bar(foo)' expands into
+     'lose(a,b)', and you get an error because 'lose' requires a single
+     argument.  In this case, the problem is easily solved by the same
+     parentheses that ought to be used to prevent misnesting of
+     arithmetic operations:
+
+          #define foo (a,b)
+     or
+          #define bar(x) lose((x))
+
+     The extra pair of parentheses prevents the comma in 'foo''s
+     definition from being interpreted as an argument separator.
+
+
+File: cpp.info,  Node: Newlines in Arguments,  Prev: Argument Prescan,  Up: Macro Pitfalls
+
+3.10.7 Newlines in Arguments
+----------------------------
+
+The invocation of a function-like macro can extend over many logical
+lines.  However, in the present implementation, the entire expansion
+comes out on one line.  Thus line numbers emitted by the compiler or
+debugger refer to the line the invocation started on, which might be
+different to the line containing the argument causing the problem.
+
+   Here is an example illustrating this:
+
+     #define ignore_second_arg(a,b,c) a; c
+
+     ignore_second_arg (foo (),
+                        ignored (),
+                        syntax error);
+
+The syntax error triggered by the tokens 'syntax error' results in an
+error message citing line three--the line of ignore_second_arg-- even
+though the problematic code comes from line five.
+
+   We consider this a bug, and intend to fix it in the near future.
+
+
+File: cpp.info,  Node: Conditionals,  Next: Diagnostics,  Prev: Macros,  Up: Top
+
+4 Conditionals
+**************
+
+A "conditional" is a directive that instructs the preprocessor to select
+whether or not to include a chunk of code in the final token stream
+passed to the compiler.  Preprocessor conditionals can test arithmetic
+expressions, or whether a name is defined as a macro, or both
+simultaneously using the special 'defined' operator.
+
+   A conditional in the C preprocessor resembles in some ways an 'if'
+statement in C, but it is important to understand the difference between
+them.  The condition in an 'if' statement is tested during the execution
+of your program.  Its purpose is to allow your program to behave
+differently from run to run, depending on the data it is operating on.
+The condition in a preprocessing conditional directive is tested when
+your program is compiled.  Its purpose is to allow different code to be
+included in the program depending on the situation at the time of
+compilation.
+
+   However, the distinction is becoming less clear.  Modern compilers
+often do test 'if' statements when a program is compiled, if their
+conditions are known not to vary at run time, and eliminate code which
+can never be executed.  If you can count on your compiler to do this,
+you may find that your program is more readable if you use 'if'
+statements with constant conditions (perhaps determined by macros).  Of
+course, you can only use this to exclude code, not type definitions or
+other preprocessing directives, and you can only do it if the code
+remains syntactically valid when it is not to be used.
+
+   GCC version 3 eliminates this kind of never-executed code even when
+not optimizing.  Older versions did it only when optimizing.
+
+* Menu:
+
+* Conditional Uses::
+* Conditional Syntax::
+* Deleted Code::
+
+
+File: cpp.info,  Node: Conditional Uses,  Next: Conditional Syntax,  Up: Conditionals
+
+4.1 Conditional Uses
+====================
+
+There are three general reasons to use a conditional.
+
+   * A program may need to use different code depending on the machine
+     or operating system it is to run on.  In some cases the code for
+     one operating system may be erroneous on another operating system;
+     for example, it might refer to data types or constants that do not
+     exist on the other system.  When this happens, it is not enough to
+     avoid executing the invalid code.  Its mere presence will cause the
+     compiler to reject the program.  With a preprocessing conditional,
+     the offending code can be effectively excised from the program when
+     it is not valid.
+
+   * You may want to be able to compile the same source file into two
+     different programs.  One version might make frequent time-consuming
+     consistency checks on its intermediate data, or print the values of
+     those data for debugging, and the other not.
+
+   * A conditional whose condition is always false is one way to exclude
+     code from the program but keep it as a sort of comment for future
+     reference.
+
+   Simple programs that do not need system-specific logic or complex
+debugging hooks generally will not need to use preprocessing
+conditionals.
+
+
+File: cpp.info,  Node: Conditional Syntax,  Next: Deleted Code,  Prev: Conditional Uses,  Up: Conditionals
+
+4.2 Conditional Syntax
+======================
+
+A conditional in the C preprocessor begins with a "conditional
+directive": '#if', '#ifdef' or '#ifndef'.
+
+* Menu:
+
+* Ifdef::
+* If::
+* Defined::
+* Else::
+* Elif::
+
+
+File: cpp.info,  Node: Ifdef,  Next: If,  Up: Conditional Syntax
+
+4.2.1 Ifdef
+-----------
+
+The simplest sort of conditional is
+
+     #ifdef MACRO
+
+     CONTROLLED TEXT
+
+     #endif /* MACRO */
+
+   This block is called a "conditional group".  CONTROLLED TEXT will be
+included in the output of the preprocessor if and only if MACRO is
+defined.  We say that the conditional "succeeds" if MACRO is defined,
+"fails" if it is not.
+
+   The CONTROLLED TEXT inside of a conditional can include preprocessing
+directives.  They are executed only if the conditional succeeds.  You
+can nest conditional groups inside other conditional groups, but they
+must be completely nested.  In other words, '#endif' always matches the
+nearest '#ifdef' (or '#ifndef', or '#if').  Also, you cannot start a
+conditional group in one file and end it in another.
+
+   Even if a conditional fails, the CONTROLLED TEXT inside it is still
+run through initial transformations and tokenization.  Therefore, it
+must all be lexically valid C.  Normally the only way this matters is
+that all comments and string literals inside a failing conditional group
+must still be properly ended.
+
+   The comment following the '#endif' is not required, but it is a good
+practice if there is a lot of CONTROLLED TEXT, because it helps people
+match the '#endif' to the corresponding '#ifdef'.  Older programs
+sometimes put MACRO directly after the '#endif' without enclosing it in
+a comment.  This is invalid code according to the C standard.  CPP
+accepts it with a warning.  It never affects which '#ifndef' the
+'#endif' matches.
+
+   Sometimes you wish to use some code if a macro is _not_ defined.  You
+can do this by writing '#ifndef' instead of '#ifdef'.  One common use of
+'#ifndef' is to include code only the first time a header file is
+included.  *Note Once-Only Headers::.
+
+   Macro definitions can vary between compilations for several reasons.
+Here are some samples.
+
+   * Some macros are predefined on each kind of machine (*note
+     System-specific Predefined Macros::).  This allows you to provide
+     code specially tuned for a particular machine.
+
+   * System header files define more macros, associated with the
+     features they implement.  You can test these macros with
+     conditionals to avoid using a system feature on a machine where it
+     is not implemented.
+
+   * Macros can be defined or undefined with the '-D' and '-U' command
+     line options when you compile the program.  You can arrange to
+     compile the same source file into two different programs by
+     choosing a macro name to specify which program you want, writing
+     conditionals to test whether or how this macro is defined, and then
+     controlling the state of the macro with command line options,
+     perhaps set in the Makefile.  *Note Invocation::.
+
+   * Your program might have a special header file (often called
+     'config.h') that is adjusted when the program is compiled.  It can
+     define or not define macros depending on the features of the system
+     and the desired capabilities of the program.  The adjustment can be
+     automated by a tool such as 'autoconf', or done by hand.
+
+
+File: cpp.info,  Node: If,  Next: Defined,  Prev: Ifdef,  Up: Conditional Syntax
+
+4.2.2 If
+--------
+
+The '#if' directive allows you to test the value of an arithmetic
+expression, rather than the mere existence of one macro.  Its syntax is
+
+     #if EXPRESSION
+
+     CONTROLLED TEXT
+
+     #endif /* EXPRESSION */
+
+   EXPRESSION is a C expression of integer type, subject to stringent
+restrictions.  It may contain
+
+   * Integer constants.
+
+   * Character constants, which are interpreted as they would be in
+     normal code.
+
+   * Arithmetic operators for addition, subtraction, multiplication,
+     division, bitwise operations, shifts, comparisons, and logical
+     operations ('&&' and '||').  The latter two obey the usual
+     short-circuiting rules of standard C.
+
+   * Macros.  All macros in the expression are expanded before actual
+     computation of the expression's value begins.
+
+   * Uses of the 'defined' operator, which lets you check whether macros
+     are defined in the middle of an '#if'.
+
+   * Identifiers that are not macros, which are all considered to be the
+     number zero.  This allows you to write '#if MACRO' instead of
+     '#ifdef MACRO', if you know that MACRO, when defined, will always
+     have a nonzero value.  Function-like macros used without their
+     function call parentheses are also treated as zero.
+
+     In some contexts this shortcut is undesirable.  The '-Wundef'
+     option causes GCC to warn whenever it encounters an identifier
+     which is not a macro in an '#if'.
+
+   The preprocessor does not know anything about types in the language.
+Therefore, 'sizeof' operators are not recognized in '#if', and neither
+are 'enum' constants.  They will be taken as identifiers which are not
+macros, and replaced by zero.  In the case of 'sizeof', this is likely
+to cause the expression to be invalid.
+
+   The preprocessor calculates the value of EXPRESSION.  It carries out
+all calculations in the widest integer type known to the compiler; on
+most machines supported by GCC this is 64 bits.  This is not the same
+rule as the compiler uses to calculate the value of a constant
+expression, and may give different results in some cases.  If the value
+comes out to be nonzero, the '#if' succeeds and the CONTROLLED TEXT is
+included; otherwise it is skipped.
+
+
+File: cpp.info,  Node: Defined,  Next: Else,  Prev: If,  Up: Conditional Syntax
+
+4.2.3 Defined
+-------------
+
+The special operator 'defined' is used in '#if' and '#elif' expressions
+to test whether a certain name is defined as a macro.  'defined NAME'
+and 'defined (NAME)' are both expressions whose value is 1 if NAME is
+defined as a macro at the current point in the program, and 0 otherwise.
+Thus, '#if defined MACRO' is precisely equivalent to '#ifdef MACRO'.
+
+   'defined' is useful when you wish to test more than one macro for
+existence at once.  For example,
+
+     #if defined (__vax__) || defined (__ns16000__)
+
+would succeed if either of the names '__vax__' or '__ns16000__' is
+defined as a macro.
+
+   Conditionals written like this:
+
+     #if defined BUFSIZE && BUFSIZE >= 1024
+
+can generally be simplified to just '#if BUFSIZE >= 1024', since if
+'BUFSIZE' is not defined, it will be interpreted as having the value
+zero.
+
+   If the 'defined' operator appears as a result of a macro expansion,
+the C standard says the behavior is undefined.  GNU cpp treats it as a
+genuine 'defined' operator and evaluates it normally.  It will warn
+wherever your code uses this feature if you use the command-line option
+'-pedantic', since other compilers may handle it differently.
+
+
+File: cpp.info,  Node: Else,  Next: Elif,  Prev: Defined,  Up: Conditional Syntax
+
+4.2.4 Else
+----------
+
+The '#else' directive can be added to a conditional to provide
+alternative text to be used if the condition fails.  This is what it
+looks like:
+
+     #if EXPRESSION
+     TEXT-IF-TRUE
+     #else /* Not EXPRESSION */
+     TEXT-IF-FALSE
+     #endif /* Not EXPRESSION */
+
+If EXPRESSION is nonzero, the TEXT-IF-TRUE is included and the
+TEXT-IF-FALSE is skipped.  If EXPRESSION is zero, the opposite happens.
+
+   You can use '#else' with '#ifdef' and '#ifndef', too.
+
+
+File: cpp.info,  Node: Elif,  Prev: Else,  Up: Conditional Syntax
+
+4.2.5 Elif
+----------
+
+One common case of nested conditionals is used to check for more than
+two possible alternatives.  For example, you might have
+
+     #if X == 1
+     ...
+     #else /* X != 1 */
+     #if X == 2
+     ...
+     #else /* X != 2 */
+     ...
+     #endif /* X != 2 */
+     #endif /* X != 1 */
+
+   Another conditional directive, '#elif', allows this to be abbreviated
+as follows:
+
+     #if X == 1
+     ...
+     #elif X == 2
+     ...
+     #else /* X != 2 and X != 1*/
+     ...
+     #endif /* X != 2 and X != 1*/
+
+   '#elif' stands for "else if".  Like '#else', it goes in the middle of
+a conditional group and subdivides it; it does not require a matching
+'#endif' of its own.  Like '#if', the '#elif' directive includes an
+expression to be tested.  The text following the '#elif' is processed
+only if the original '#if'-condition failed and the '#elif' condition
+succeeds.
+
+   More than one '#elif' can go in the same conditional group.  Then the
+text after each '#elif' is processed only if the '#elif' condition
+succeeds after the original '#if' and all previous '#elif' directives
+within it have failed.
+
+   '#else' is allowed after any number of '#elif' directives, but
+'#elif' may not follow '#else'.
+
+
+File: cpp.info,  Node: Deleted Code,  Prev: Conditional Syntax,  Up: Conditionals
+
+4.3 Deleted Code
+================
+
+If you replace or delete a part of the program but want to keep the old
+code around for future reference, you often cannot simply comment it
+out.  Block comments do not nest, so the first comment inside the old
+code will end the commenting-out.  The probable result is a flood of
+syntax errors.
+
+   One way to avoid this problem is to use an always-false conditional
+instead.  For instance, put '#if 0' before the deleted code and '#endif'
+after it.  This works even if the code being turned off contains
+conditionals, but they must be entire conditionals (balanced '#if' and
+'#endif').
+
+   Some people use '#ifdef notdef' instead.  This is risky, because
+'notdef' might be accidentally defined as a macro, and then the
+conditional would succeed.  '#if 0' can be counted on to fail.
+
+   Do not use '#if 0' for comments which are not C code.  Use a real
+comment, instead.  The interior of '#if 0' must consist of complete
+tokens; in particular, single-quote characters must balance.  Comments
+often contain unbalanced single-quote characters (known in English as
+apostrophes).  These confuse '#if 0'.  They don't confuse '/*'.
+
+
+File: cpp.info,  Node: Diagnostics,  Next: Line Control,  Prev: Conditionals,  Up: Top
+
+5 Diagnostics
+*************
+
+The directive '#error' causes the preprocessor to report a fatal error.
+The tokens forming the rest of the line following '#error' are used as
+the error message.
+
+   You would use '#error' inside of a conditional that detects a
+combination of parameters which you know the program does not properly
+support.  For example, if you know that the program will not run
+properly on a VAX, you might write
+
+     #ifdef __vax__
+     #error "Won't work on VAXen.  See comments at get_last_object."
+     #endif
+
+   If you have several configuration parameters that must be set up by
+the installation in a consistent way, you can use conditionals to detect
+an inconsistency and report it with '#error'.  For example,
+
+     #if !defined(FOO) && defined(BAR)
+     #error "BAR requires FOO."
+     #endif
+
+   The directive '#warning' is like '#error', but causes the
+preprocessor to issue a warning and continue preprocessing.  The tokens
+following '#warning' are used as the warning message.
+
+   You might use '#warning' in obsolete header files, with a message
+directing the user to the header file which should be used instead.
+
+   Neither '#error' nor '#warning' macro-expands its argument.  Internal
+whitespace sequences are each replaced with a single space.  The line
+must consist of complete tokens.  It is wisest to make the argument of
+these directives be a single string constant; this avoids problems with
+apostrophes and the like.
+
+
+File: cpp.info,  Node: Line Control,  Next: Pragmas,  Prev: Diagnostics,  Up: Top
+
+6 Line Control
+**************
+
+The C preprocessor informs the C compiler of the location in your source
+code where each token came from.  Presently, this is just the file name
+and line number.  All the tokens resulting from macro expansion are
+reported as having appeared on the line of the source file where the
+outermost macro was used.  We intend to be more accurate in the future.
+
+   If you write a program which generates source code, such as the
+'bison' parser generator, you may want to adjust the preprocessor's
+notion of the current file name and line number by hand.  Parts of the
+output from 'bison' are generated from scratch, other parts come from a
+standard parser file.  The rest are copied verbatim from 'bison''s
+input.  You would like compiler error messages and symbolic debuggers to
+be able to refer to 'bison''s input file.
+
+   'bison' or any such program can arrange this by writing '#line'
+directives into the output file.  '#line' is a directive that specifies
+the original line number and source file name for subsequent input in
+the current preprocessor input file.  '#line' has three variants:
+
+'#line LINENUM'
+     LINENUM is a non-negative decimal integer constant.  It specifies
+     the line number which should be reported for the following line of
+     input.  Subsequent lines are counted from LINENUM.
+
+'#line LINENUM FILENAME'
+     LINENUM is the same as for the first form, and has the same effect.
+     In addition, FILENAME is a string constant.  The following line and
+     all subsequent lines are reported to come from the file it
+     specifies, until something else happens to change that.  FILENAME
+     is interpreted according to the normal rules for a string constant:
+     backslash escapes are interpreted.  This is different from
+     '#include'.
+
+     Previous versions of CPP did not interpret escapes in '#line'; we
+     have changed it because the standard requires they be interpreted,
+     and most other compilers do.
+
+'#line ANYTHING ELSE'
+     ANYTHING ELSE is checked for macro calls, which are expanded.  The
+     result should match one of the above two forms.
+
+   '#line' directives alter the results of the '__FILE__' and '__LINE__'
+predefined macros from that point on.  *Note Standard Predefined
+Macros::.  They do not have any effect on '#include''s idea of the
+directory containing the current file.  This is a change from GCC 2.95.
+Previously, a file reading
+
+     #include "gram.h"
+
+   would search for 'gram.h' in '../src', then the '-I' chain; the
+directory containing the physical source file would not be searched.  In
+GCC 3.0 and later, the '#include' is not affected by the presence of a
+'#line' referring to a different directory.
+
+   We made this change because the old behavior caused problems when
+generated source files were transported between machines.  For instance,
+it is common practice to ship generated parsers with a source release,
+so that people building the distribution do not need to have yacc or
+Bison installed.  These files frequently have '#line' directives
+referring to the directory tree of the system where the distribution was
+created.  If GCC tries to search for headers in those directories, the
+build is likely to fail.
+
+   The new behavior can cause failures too, if the generated file is not
+in the same directory as its source and it attempts to include a header
+which would be visible searching from the directory containing the
+source file.  However, this problem is easily solved with an additional
+'-I' switch on the command line.  The failures caused by the old
+semantics could sometimes be corrected only by editing the generated
+files, which is difficult and error-prone.
+
+
+File: cpp.info,  Node: Pragmas,  Next: Other Directives,  Prev: Line Control,  Up: Top
+
+7 Pragmas
+*********
+
+The '#pragma' directive is the method specified by the C standard for
+providing additional information to the compiler, beyond what is
+conveyed in the language itself.  Three forms of this directive
+(commonly known as "pragmas") are specified by the 1999 C standard.  A C
+compiler is free to attach any meaning it likes to other pragmas.
+
+   GCC has historically preferred to use extensions to the syntax of the
+language, such as '__attribute__', for this purpose.  However, GCC does
+define a few pragmas of its own.  These mostly have effects on the
+entire translation unit or source file.
+
+   In GCC version 3, all GNU-defined, supported pragmas have been given
+a 'GCC' prefix.  This is in line with the 'STDC' prefix on all pragmas
+defined by C99.  For backward compatibility, pragmas which were
+recognized by previous versions are still recognized without the 'GCC'
+prefix, but that usage is deprecated.  Some older pragmas are deprecated
+in their entirety.  They are not recognized with the 'GCC' prefix.
+*Note Obsolete Features::.
+
+   C99 introduces the '_Pragma' operator.  This feature addresses a
+major problem with '#pragma': being a directive, it cannot be produced
+as the result of macro expansion.  '_Pragma' is an operator, much like
+'sizeof' or 'defined', and can be embedded in a macro.
+
+   Its syntax is '_Pragma (STRING-LITERAL)', where STRING-LITERAL can be
+either a normal or wide-character string literal.  It is destringized,
+by replacing all '\\' with a single '\' and all '\"' with a '"'.  The
+result is then processed as if it had appeared as the right hand side of
+a '#pragma' directive.  For example,
+
+     _Pragma ("GCC dependency \"parse.y\"")
+
+has the same effect as '#pragma GCC dependency "parse.y"'.  The same
+effect could be achieved using macros, for example
+
+     #define DO_PRAGMA(x) _Pragma (#x)
+     DO_PRAGMA (GCC dependency "parse.y")
+
+   The standard is unclear on where a '_Pragma' operator can appear.
+The preprocessor does not accept it within a preprocessing conditional
+directive like '#if'.  To be safe, you are probably best keeping it out
+of directives other than '#define', and putting it on a line of its own.
+
+   This manual documents the pragmas which are meaningful to the
+preprocessor itself.  Other pragmas are meaningful to the C or C++
+compilers.  They are documented in the GCC manual.
+
+   GCC plugins may provide their own pragmas.
+
+'#pragma GCC dependency'
+     '#pragma GCC dependency' allows you to check the relative dates of
+     the current file and another file.  If the other file is more
+     recent than the current file, a warning is issued.  This is useful
+     if the current file is derived from the other file, and should be
+     regenerated.  The other file is searched for using the normal
+     include search path.  Optional trailing text can be used to give
+     more information in the warning message.
+
+          #pragma GCC dependency "parse.y"
+          #pragma GCC dependency "/usr/include/time.h" rerun fixincludes
+
+'#pragma GCC poison'
+     Sometimes, there is an identifier that you want to remove
+     completely from your program, and make sure that it never creeps
+     back in.  To enforce this, you can "poison" the identifier with
+     this pragma.  '#pragma GCC poison' is followed by a list of
+     identifiers to poison.  If any of those identifiers appears
+     anywhere in the source after the directive, it is a hard error.
+     For example,
+
+          #pragma GCC poison printf sprintf fprintf
+          sprintf(some_string, "hello");
+
+     will produce an error.
+
+     If a poisoned identifier appears as part of the expansion of a
+     macro which was defined before the identifier was poisoned, it will
+     _not_ cause an error.  This lets you poison an identifier without
+     worrying about system headers defining macros that use it.
+
+     For example,
+
+          #define strrchr rindex
+          #pragma GCC poison rindex
+          strrchr(some_string, 'h');
+
+     will not produce an error.
+
+'#pragma GCC system_header'
+     This pragma takes no arguments.  It causes the rest of the code in
+     the current file to be treated as if it came from a system header.
+     *Note System Headers::.
+
+'#pragma GCC warning'
+'#pragma GCC error'
+     '#pragma GCC warning "message"' causes the preprocessor to issue a
+     warning diagnostic with the text 'message'.  The message contained
+     in the pragma must be a single string literal.  Similarly, '#pragma
+     GCC error "message"' issues an error message.  Unlike the
+     '#warning' and '#error' directives, these pragmas can be embedded
+     in preprocessor macros using '_Pragma'.
+
+
+File: cpp.info,  Node: Other Directives,  Next: Preprocessor Output,  Prev: Pragmas,  Up: Top
+
+8 Other Directives
+******************
+
+The '#ident' directive takes one argument, a string constant.  On some
+systems, that string constant is copied into a special segment of the
+object file.  On other systems, the directive is ignored.  The '#sccs'
+directive is a synonym for '#ident'.
+
+   These directives are not part of the C standard, but they are not
+official GNU extensions either.  What historical information we have
+been able to find, suggests they originated with System V.
+
+   The "null directive" consists of a '#' followed by a newline, with
+only whitespace (including comments) in between.  A null directive is
+understood as a preprocessing directive but has no effect on the
+preprocessor output.  The primary significance of the existence of the
+null directive is that an input line consisting of just a '#' will
+produce no output, rather than a line of output containing just a '#'.
+Supposedly some old C programs contain such lines.
+
+
+File: cpp.info,  Node: Preprocessor Output,  Next: Traditional Mode,  Prev: Other Directives,  Up: Top
+
+9 Preprocessor Output
+*********************
+
+When the C preprocessor is used with the C, C++, or Objective-C
+compilers, it is integrated into the compiler and communicates a stream
+of binary tokens directly to the compiler's parser.  However, it can
+also be used in the more conventional standalone mode, where it produces
+textual output.
+
+   The output from the C preprocessor looks much like the input, except
+that all preprocessing directive lines have been replaced with blank
+lines and all comments with spaces.  Long runs of blank lines are
+discarded.
+
+   The ISO standard specifies that it is implementation defined whether
+a preprocessor preserves whitespace between tokens, or replaces it with
+e.g. a single space.  In GNU CPP, whitespace between tokens is collapsed
+to become a single space, with the exception that the first token on a
+non-directive line is preceded with sufficient spaces that it appears in
+the same column in the preprocessed output that it appeared in the
+original source file.  This is so the output is easy to read.  *Note
+Differences from previous versions::.  CPP does not insert any
+whitespace where there was none in the original source, except where
+necessary to prevent an accidental token paste.
+
+   Source file name and line number information is conveyed by lines of
+the form
+
+     # LINENUM FILENAME FLAGS
+
+These are called "linemarkers".  They are inserted as needed into the
+output (but never within a string or character constant).  They mean
+that the following line originated in file FILENAME at line LINENUM.
+FILENAME will never contain any non-printing characters; they are
+replaced with octal escape sequences.
+
+   After the file name comes zero or more flags, which are '1', '2',
+'3', or '4'.  If there are multiple flags, spaces separate them.  Here
+is what the flags mean:
+
+'1'
+     This indicates the start of a new file.
+'2'
+     This indicates returning to a file (after having included another
+     file).
+'3'
+     This indicates that the following text comes from a system header
+     file, so certain warnings should be suppressed.
+'4'
+     This indicates that the following text should be treated as being
+     wrapped in an implicit 'extern "C"' block.
+
+   As an extension, the preprocessor accepts linemarkers in
+non-assembler input files.  They are treated like the corresponding
+'#line' directive, (*note Line Control::), except that trailing flags
+are permitted, and are interpreted with the meanings described above.
+If multiple flags are given, they must be in ascending order.
+
+   Some directives may be duplicated in the output of the preprocessor.
+These are '#ident' (always), '#pragma' (only if the preprocessor does
+not handle the pragma itself), and '#define' and '#undef' (with certain
+debugging options).  If this happens, the '#' of the directive will
+always be in the first column, and there will be no space between the
+'#' and the directive name.  If macro expansion happens to generate
+tokens which might be mistaken for a duplicated directive, a space will
+be inserted between the '#' and the directive name.
+
+
+File: cpp.info,  Node: Traditional Mode,  Next: Implementation Details,  Prev: Preprocessor Output,  Up: Top
+
+10 Traditional Mode
+*******************
+
+Traditional (pre-standard) C preprocessing is rather different from the
+preprocessing specified by the standard.  When GCC is given the
+'-traditional-cpp' option, it attempts to emulate a traditional
+preprocessor.
+
+   GCC versions 3.2 and later only support traditional mode semantics in
+the preprocessor, and not in the compiler front ends.  This chapter
+outlines the traditional preprocessor semantics we implemented.
+
+   The implementation does not correspond precisely to the behavior of
+earlier versions of GCC, nor to any true traditional preprocessor.
+After all, inconsistencies among traditional implementations were a
+major motivation for C standardization.  However, we intend that it
+should be compatible with true traditional preprocessors in all ways
+that actually matter.
+
+* Menu:
+
+* Traditional lexical analysis::
+* Traditional macros::
+* Traditional miscellany::
+* Traditional warnings::
+
+
+File: cpp.info,  Node: Traditional lexical analysis,  Next: Traditional macros,  Up: Traditional Mode
+
+10.1 Traditional lexical analysis
+=================================
+
+The traditional preprocessor does not decompose its input into tokens
+the same way a standards-conforming preprocessor does.  The input is
+simply treated as a stream of text with minimal internal form.
+
+   This implementation does not treat trigraphs (*note trigraphs::)
+specially since they were an invention of the standards committee.  It
+handles arbitrarily-positioned escaped newlines properly and splices the
+lines as you would expect; many traditional preprocessors did not do
+this.
+
+   The form of horizontal whitespace in the input file is preserved in
+the output.  In particular, hard tabs remain hard tabs.  This can be
+useful if, for example, you are preprocessing a Makefile.
+
+   Traditional CPP only recognizes C-style block comments, and treats
+the '/*' sequence as introducing a comment only if it lies outside
+quoted text.  Quoted text is introduced by the usual single and double
+quotes, and also by an initial '<' in a '#include' directive.
+
+   Traditionally, comments are completely removed and are not replaced
+with a space.  Since a traditional compiler does its own tokenization of
+the output of the preprocessor, this means that comments can effectively
+be used as token paste operators.  However, comments behave like
+separators for text handled by the preprocessor itself, since it doesn't
+re-lex its input.  For example, in
+
+     #if foo/**/bar
+
+'foo' and 'bar' are distinct identifiers and expanded separately if they
+happen to be macros.  In other words, this directive is equivalent to
+
+     #if foo bar
+
+rather than
+
+     #if foobar
+
+   Generally speaking, in traditional mode an opening quote need not
+have a matching closing quote.  In particular, a macro may be defined
+with replacement text that contains an unmatched quote.  Of course, if
+you attempt to compile preprocessed output containing an unmatched quote
+you will get a syntax error.
+
+   However, all preprocessing directives other than '#define' require
+matching quotes.  For example:
+
+     #define m This macro's fine and has an unmatched quote
+     "/* This is not a comment.  */
+     /* This is a comment.  The following #include directive
+        is ill-formed.  */
+     #include <stdio.h
+
+   Just as for the ISO preprocessor, what would be a closing quote can
+be escaped with a backslash to prevent the quoted text from closing.
+
+
+File: cpp.info,  Node: Traditional macros,  Next: Traditional miscellany,  Prev: Traditional lexical analysis,  Up: Traditional Mode
+
+10.2 Traditional macros
+=======================
+
+The major difference between traditional and ISO macros is that the
+former expand to text rather than to a token sequence.  CPP removes all
+leading and trailing horizontal whitespace from a macro's replacement
+text before storing it, but preserves the form of internal whitespace.
+
+   One consequence is that it is legitimate for the replacement text to
+contain an unmatched quote (*note Traditional lexical analysis::).  An
+unclosed string or character constant continues into the text following
+the macro call.  Similarly, the text at the end of a macro's expansion
+can run together with the text after the macro invocation to produce a
+single token.
+
+   Normally comments are removed from the replacement text after the
+macro is expanded, but if the '-CC' option is passed on the command line
+comments are preserved.  (In fact, the current implementation removes
+comments even before saving the macro replacement text, but it careful
+to do it in such a way that the observed effect is identical even in the
+function-like macro case.)
+
+   The ISO stringification operator '#' and token paste operator '##'
+have no special meaning.  As explained later, an effect similar to these
+operators can be obtained in a different way.  Macro names that are
+embedded in quotes, either from the main file or after macro
+replacement, do not expand.
+
+   CPP replaces an unquoted object-like macro name with its replacement
+text, and then rescans it for further macros to replace.  Unlike
+standard macro expansion, traditional macro expansion has no provision
+to prevent recursion.  If an object-like macro appears unquoted in its
+replacement text, it will be replaced again during the rescan pass, and
+so on _ad infinitum_.  GCC detects when it is expanding recursive
+macros, emits an error message, and continues after the offending macro
+invocation.
+
+     #define PLUS +
+     #define INC(x) PLUS+x
+     INC(foo);
+          ==> ++foo;
+
+   Function-like macros are similar in form but quite different in
+behavior to their ISO counterparts.  Their arguments are contained
+within parentheses, are comma-separated, and can cross physical lines.
+Commas within nested parentheses are not treated as argument separators.
+Similarly, a quote in an argument cannot be left unclosed; a following
+comma or parenthesis that comes before the closing quote is treated like
+any other character.  There is no facility for handling variadic macros.
+
+   This implementation removes all comments from macro arguments, unless
+the '-C' option is given.  The form of all other horizontal whitespace
+in arguments is preserved, including leading and trailing whitespace.
+In particular
+
+     f( )
+
+is treated as an invocation of the macro 'f' with a single argument
+consisting of a single space.  If you want to invoke a function-like
+macro that takes no arguments, you must not leave any whitespace between
+the parentheses.
+
+   If a macro argument crosses a new line, the new line is replaced with
+a space when forming the argument.  If the previous line contained an
+unterminated quote, the following line inherits the quoted state.
+
+   Traditional preprocessors replace parameters in the replacement text
+with their arguments regardless of whether the parameters are within
+quotes or not.  This provides a way to stringize arguments.  For example
+
+     #define str(x) "x"
+     str(/* A comment */some text )
+          ==> "some text "
+
+Note that the comment is removed, but that the trailing space is
+preserved.  Here is an example of using a comment to effect token
+pasting.
+
+     #define suffix(x) foo_/**/x
+     suffix(bar)
+          ==> foo_bar
+
+
+File: cpp.info,  Node: Traditional miscellany,  Next: Traditional warnings,  Prev: Traditional macros,  Up: Traditional Mode
+
+10.3 Traditional miscellany
+===========================
+
+Here are some things to be aware of when using the traditional
+preprocessor.
+
+   * Preprocessing directives are recognized only when their leading '#'
+     appears in the first column.  There can be no whitespace between
+     the beginning of the line and the '#', but whitespace can follow
+     the '#'.
+
+   * A true traditional C preprocessor does not recognize '#error' or
+     '#pragma', and may not recognize '#elif'.  CPP supports all the
+     directives in traditional mode that it supports in ISO mode,
+     including extensions, with the exception that the effects of
+     '#pragma GCC poison' are undefined.
+
+   * __STDC__ is not defined.
+
+   * If you use digraphs the behavior is undefined.
+
+   * If a line that looks like a directive appears within macro
+     arguments, the behavior is undefined.
+
+
+File: cpp.info,  Node: Traditional warnings,  Prev: Traditional miscellany,  Up: Traditional Mode
+
+10.4 Traditional warnings
+=========================
+
+You can request warnings about features that did not exist, or worked
+differently, in traditional C with the '-Wtraditional' option.  GCC does
+not warn about features of ISO C which you must use when you are using a
+conforming compiler, such as the '#' and '##' operators.
+
+   Presently '-Wtraditional' warns about:
+
+   * Macro parameters that appear within string literals in the macro
+     body.  In traditional C macro replacement takes place within string
+     literals, but does not in ISO C.
+
+   * In traditional C, some preprocessor directives did not exist.
+     Traditional preprocessors would only consider a line to be a
+     directive if the '#' appeared in column 1 on the line.  Therefore
+     '-Wtraditional' warns about directives that traditional C
+     understands but would ignore because the '#' does not appear as the
+     first character on the line.  It also suggests you hide directives
+     like '#pragma' not understood by traditional C by indenting them.
+     Some traditional implementations would not recognize '#elif', so it
+     suggests avoiding it altogether.
+
+   * A function-like macro that appears without an argument list.  In
+     some traditional preprocessors this was an error.  In ISO C it
+     merely means that the macro is not expanded.
+
+   * The unary plus operator.  This did not exist in traditional C.
+
+   * The 'U' and 'LL' integer constant suffixes, which were not
+     available in traditional C.  (Traditional C does support the 'L'
+     suffix for simple long integer constants.)  You are not warned
+     about uses of these suffixes in macros defined in system headers.
+     For instance, 'UINT_MAX' may well be defined as '4294967295U', but
+     you will not be warned if you use 'UINT_MAX'.
+
+     You can usually avoid the warning, and the related warning about
+     constants which are so large that they are unsigned, by writing the
+     integer constant in question in hexadecimal, with no U suffix.
+     Take care, though, because this gives the wrong result in exotic
+     cases.
+
+
+File: cpp.info,  Node: Implementation Details,  Next: Invocation,  Prev: Traditional Mode,  Up: Top
+
+11 Implementation Details
+*************************
+
+Here we document details of how the preprocessor's implementation
+affects its user-visible behavior.  You should try to avoid undue
+reliance on behavior described here, as it is possible that it will
+change subtly in future implementations.
+
+   Also documented here are obsolete features and changes from previous
+versions of CPP.
+
+* Menu:
+
+* Implementation-defined behavior::
+* Implementation limits::
+* Obsolete Features::
+* Differences from previous versions::
+
+
+File: cpp.info,  Node: Implementation-defined behavior,  Next: Implementation limits,  Up: Implementation Details
+
+11.1 Implementation-defined behavior
+====================================
+
+This is how CPP behaves in all the cases which the C standard describes
+as "implementation-defined".  This term means that the implementation is
+free to do what it likes, but must document its choice and stick to it.
+
+   * The mapping of physical source file multi-byte characters to the
+     execution character set.
+
+     The input character set can be specified using the
+     '-finput-charset' option, while the execution character set may be
+     controlled using the '-fexec-charset' and '-fwide-exec-charset'
+     options.
+
+   * Identifier characters.
+
+     The C and C++ standards allow identifiers to be composed of '_' and
+     the alphanumeric characters.  C++ and C99 also allow universal
+     character names, and C99 further permits implementation-defined
+     characters.  GCC currently only permits universal character names
+     if '-fextended-identifiers' is used, because the implementation of
+     universal character names in identifiers is experimental.
+
+     GCC allows the '$' character in identifiers as an extension for
+     most targets.  This is true regardless of the 'std=' switch, since
+     this extension cannot conflict with standards-conforming programs.
+     When preprocessing assembler, however, dollars are not identifier
+     characters by default.
+
+     Currently the targets that by default do not permit '$' are AVR,
+     IP2K, MMIX, MIPS Irix 3, ARM aout, and PowerPC targets for the AIX
+     operating system.
+
+     You can override the default with '-fdollars-in-identifiers' or
+     'fno-dollars-in-identifiers'.  *Note fdollars-in-identifiers::.
+
+   * Non-empty sequences of whitespace characters.
+
+     In textual output, each whitespace sequence is collapsed to a
+     single space.  For aesthetic reasons, the first token on each
+     non-directive line of output is preceded with sufficient spaces
+     that it appears in the same column as it did in the original source
+     file.
+
+   * The numeric value of character constants in preprocessor
+     expressions.
+
+     The preprocessor and compiler interpret character constants in the
+     same way; i.e. escape sequences such as '\a' are given the values
+     they would have on the target machine.
+
+     The compiler evaluates a multi-character character constant a
+     character at a time, shifting the previous value left by the number
+     of bits per target character, and then or-ing in the bit-pattern of
+     the new character truncated to the width of a target character.
+     The final bit-pattern is given type 'int', and is therefore signed,
+     regardless of whether single characters are signed or not (a slight
+     change from versions 3.1 and earlier of GCC).  If there are more
+     characters in the constant than would fit in the target 'int' the
+     compiler issues a warning, and the excess leading characters are
+     ignored.
+
+     For example, ''ab'' for a target with an 8-bit 'char' would be
+     interpreted as
+     '(int) ((unsigned char) 'a' * 256 + (unsigned char) 'b')', and
+     ''\234a'' as
+     '(int) ((unsigned char) '\234' * 256 + (unsigned char) 'a')'.
+
+   * Source file inclusion.
+
+     For a discussion on how the preprocessor locates header files,
+     *note Include Operation::.
+
+   * Interpretation of the filename resulting from a macro-expanded
+     '#include' directive.
+
+     *Note Computed Includes::.
+
+   * Treatment of a '#pragma' directive that after macro-expansion
+     results in a standard pragma.
+
+     No macro expansion occurs on any '#pragma' directive line, so the
+     question does not arise.
+
+     Note that GCC does not yet implement any of the standard pragmas.
+
+
+File: cpp.info,  Node: Implementation limits,  Next: Obsolete Features,  Prev: Implementation-defined behavior,  Up: Implementation Details
+
+11.2 Implementation limits
+==========================
+
+CPP has a small number of internal limits.  This section lists the
+limits which the C standard requires to be no lower than some minimum,
+and all the others known.  It is intended that there should be as few
+limits as possible.  If you encounter an undocumented or inconvenient
+limit, please report that as a bug.  *Note Reporting Bugs: (gcc)Bugs.
+
+   Where we say something is limited "only by available memory", that
+means that internal data structures impose no intrinsic limit, and space
+is allocated with 'malloc' or equivalent.  The actual limit will
+therefore depend on many things, such as the size of other things
+allocated by the compiler at the same time, the amount of memory
+consumed by other processes on the same computer, etc.
+
+   * Nesting levels of '#include' files.
+
+     We impose an arbitrary limit of 200 levels, to avoid runaway
+     recursion.  The standard requires at least 15 levels.
+
+   * Nesting levels of conditional inclusion.
+
+     The C standard mandates this be at least 63.  CPP is limited only
+     by available memory.
+
+   * Levels of parenthesized expressions within a full expression.
+
+     The C standard requires this to be at least 63.  In preprocessor
+     conditional expressions, it is limited only by available memory.
+
+   * Significant initial characters in an identifier or macro name.
+
+     The preprocessor treats all characters as significant.  The C
+     standard requires only that the first 63 be significant.
+
+   * Number of macros simultaneously defined in a single translation
+     unit.
+
+     The standard requires at least 4095 be possible.  CPP is limited
+     only by available memory.
+
+   * Number of parameters in a macro definition and arguments in a macro
+     call.
+
+     We allow 'USHRT_MAX', which is no smaller than 65,535.  The minimum
+     required by the standard is 127.
+
+   * Number of characters on a logical source line.
+
+     The C standard requires a minimum of 4096 be permitted.  CPP places
+     no limits on this, but you may get incorrect column numbers
+     reported in diagnostics for lines longer than 65,535 characters.
+
+   * Maximum size of a source file.
+
+     The standard does not specify any lower limit on the maximum size
+     of a source file.  GNU cpp maps files into memory, so it is limited
+     by the available address space.  This is generally at least two
+     gigabytes.  Depending on the operating system, the size of physical
+     memory may or may not be a limitation.
+
+
+File: cpp.info,  Node: Obsolete Features,  Next: Differences from previous versions,  Prev: Implementation limits,  Up: Implementation Details
+
+11.3 Obsolete Features
+======================
+
+CPP has some features which are present mainly for compatibility with
+older programs.  We discourage their use in new code.  In some cases, we
+plan to remove the feature in a future version of GCC.
+
+11.3.1 Assertions
+-----------------
+
+"Assertions" are a deprecated alternative to macros in writing
+conditionals to test what sort of computer or system the compiled
+program will run on.  Assertions are usually predefined, but you can
+define them with preprocessing directives or command-line options.
+
+   Assertions were intended to provide a more systematic way to describe
+the compiler's target system and we added them for compatibility with
+existing compilers.  In practice they are just as unpredictable as the
+system-specific predefined macros.  In addition, they are not part of
+any standard, and only a few compilers support them.  Therefore, the use
+of assertions is *less* portable than the use of system-specific
+predefined macros.  We recommend you do not use them at all.
+
+   An assertion looks like this:
+
+     #PREDICATE (ANSWER)
+
+PREDICATE must be a single identifier.  ANSWER can be any sequence of
+tokens; all characters are significant except for leading and trailing
+whitespace, and differences in internal whitespace sequences are
+ignored.  (This is similar to the rules governing macro redefinition.)
+Thus, '(x + y)' is different from '(x+y)' but equivalent to '( x + y )'.
+Parentheses do not nest inside an answer.
+
+   To test an assertion, you write it in an '#if'.  For example, this
+conditional succeeds if either 'vax' or 'ns16000' has been asserted as
+an answer for 'machine'.
+
+     #if #machine (vax) || #machine (ns16000)
+
+You can test whether _any_ answer is asserted for a predicate by
+omitting the answer in the conditional:
+
+     #if #machine
+
+   Assertions are made with the '#assert' directive.  Its sole argument
+is the assertion to make, without the leading '#' that identifies
+assertions in conditionals.
+
+     #assert PREDICATE (ANSWER)
+
+You may make several assertions with the same predicate and different
+answers.  Subsequent assertions do not override previous ones for the
+same predicate.  All the answers for any given predicate are
+simultaneously true.
+
+   Assertions can be canceled with the '#unassert' directive.  It has
+the same syntax as '#assert'.  In that form it cancels only the answer
+which was specified on the '#unassert' line; other answers for that
+predicate remain true.  You can cancel an entire predicate by leaving
+out the answer:
+
+     #unassert PREDICATE
+
+In either form, if no such assertion has been made, '#unassert' has no
+effect.
+
+   You can also make or cancel assertions using command line options.
+*Note Invocation::.
+
+
+File: cpp.info,  Node: Differences from previous versions,  Prev: Obsolete Features,  Up: Implementation Details
+
+11.4 Differences from previous versions
+=======================================
+
+This section details behavior which has changed from previous versions
+of CPP.  We do not plan to change it again in the near future, but we do
+not promise not to, either.
+
+   The "previous versions" discussed here are 2.95 and before.  The
+behavior of GCC 3.0 is mostly the same as the behavior of the widely
+used 2.96 and 2.97 development snapshots.  Where there are differences,
+they generally represent bugs in the snapshots.
+
+   * -I- deprecated
+
+     This option has been deprecated in 4.0.  '-iquote' is meant to
+     replace the need for this option.
+
+   * Order of evaluation of '#' and '##' operators
+
+     The standard does not specify the order of evaluation of a chain of
+     '##' operators, nor whether '#' is evaluated before, after, or at
+     the same time as '##'.  You should therefore not write any code
+     which depends on any specific ordering.  It is possible to
+     guarantee an ordering, if you need one, by suitable use of nested
+     macros.
+
+     An example of where this might matter is pasting the arguments '1',
+     'e' and '-2'.  This would be fine for left-to-right pasting, but
+     right-to-left pasting would produce an invalid token 'e-2'.
+
+     GCC 3.0 evaluates '#' and '##' at the same time and strictly left
+     to right.  Older versions evaluated all '#' operators first, then
+     all '##' operators, in an unreliable order.
+
+   * The form of whitespace between tokens in preprocessor output
+
+     *Note Preprocessor Output::, for the current textual format.  This
+     is also the format used by stringification.  Normally, the
+     preprocessor communicates tokens directly to the compiler's parser,
+     and whitespace does not come up at all.
+
+     Older versions of GCC preserved all whitespace provided by the user
+     and inserted lots more whitespace of their own, because they could
+     not accurately predict when extra spaces were needed to prevent
+     accidental token pasting.
+
+   * Optional argument when invoking rest argument macros
+
+     As an extension, GCC permits you to omit the variable arguments
+     entirely when you use a variable argument macro.  This is forbidden
+     by the 1999 C standard, and will provoke a pedantic warning with
+     GCC 3.0.  Previous versions accepted it silently.
+
+   * '##' swallowing preceding text in rest argument macros
+
+     Formerly, in a macro expansion, if '##' appeared before a variable
+     arguments parameter, and the set of tokens specified for that
+     argument in the macro invocation was empty, previous versions of
+     CPP would back up and remove the preceding sequence of
+     non-whitespace characters (*not* the preceding token).  This
+     extension is in direct conflict with the 1999 C standard and has
+     been drastically pared back.
+
+     In the current version of the preprocessor, if '##' appears between
+     a comma and a variable arguments parameter, and the variable
+     argument is omitted entirely, the comma will be removed from the
+     expansion.  If the variable argument is empty, or the token before
+     '##' is not a comma, then '##' behaves as a normal token paste.
+
+   * '#line' and '#include'
+
+     The '#line' directive used to change GCC's notion of the "directory
+     containing the current file", used by '#include' with a
+     double-quoted header file name.  In 3.0 and later, it does not.
+     *Note Line Control::, for further explanation.
+
+   * Syntax of '#line'
+
+     In GCC 2.95 and previous, the string constant argument to '#line'
+     was treated the same way as the argument to '#include': backslash
+     escapes were not honored, and the string ended at the second '"'.
+     This is not compliant with the C standard.  In GCC 3.0, an attempt
+     was made to correct the behavior, so that the string was treated as
+     a real string constant, but it turned out to be buggy.  In 3.1, the
+     bugs have been fixed.  (We are not fixing the bugs in 3.0 because
+     they affect relatively few people and the fix is quite invasive.)
+
+
+File: cpp.info,  Node: Invocation,  Next: Environment Variables,  Prev: Implementation Details,  Up: Top
+
+12 Invocation
+*************
+
+Most often when you use the C preprocessor you will not have to invoke
+it explicitly: the C compiler will do so automatically.  However, the
+preprocessor is sometimes useful on its own.  All the options listed
+here are also acceptable to the C compiler and have the same meaning,
+except that the C compiler has different rules for specifying the output
+file.
+
+   _Note:_ Whether you use the preprocessor by way of 'gcc' or 'cpp',
+the "compiler driver" is run first.  This program's purpose is to
+translate your command into invocations of the programs that do the
+actual work.  Their command line interfaces are similar but not
+identical to the documented interface, and may change without notice.
+
+   The C preprocessor expects two file names as arguments, INFILE and
+OUTFILE.  The preprocessor reads INFILE together with any other files it
+specifies with '#include'.  All the output generated by the combined
+input files is written in OUTFILE.
+
+   Either INFILE or OUTFILE may be '-', which as INFILE means to read
+from standard input and as OUTFILE means to write to standard output.
+Also, if either file is omitted, it means the same as if '-' had been
+specified for that file.
+
+   Unless otherwise noted, or the option ends in '=', all options which
+take an argument may have that argument appear either immediately after
+the option, or with a space between option and argument: '-Ifoo' and '-I
+foo' have the same effect.
+
+   Many options have multi-letter names; therefore multiple
+single-letter options may _not_ be grouped: '-dM' is very different from
+'-d -M'.
+
+'-D NAME'
+     Predefine NAME as a macro, with definition '1'.
+
+'-D NAME=DEFINITION'
+     The contents of DEFINITION are tokenized and processed as if they
+     appeared during translation phase three in a '#define' directive.
+     In particular, the definition will be truncated by embedded newline
+     characters.
+
+     If you are invoking the preprocessor from a shell or shell-like
+     program you may need to use the shell's quoting syntax to protect
+     characters such as spaces that have a meaning in the shell syntax.
+
+     If you wish to define a function-like macro on the command line,
+     write its argument list with surrounding parentheses before the
+     equals sign (if any).  Parentheses are meaningful to most shells,
+     so you will need to quote the option.  With 'sh' and 'csh',
+     '-D'NAME(ARGS...)=DEFINITION'' works.
+
+     '-D' and '-U' options are processed in the order they are given on
+     the command line.  All '-imacros FILE' and '-include FILE' options
+     are processed after all '-D' and '-U' options.
+
+'-U NAME'
+     Cancel any previous definition of NAME, either built in or provided
+     with a '-D' option.
+
+'-undef'
+     Do not predefine any system-specific or GCC-specific macros.  The
+     standard predefined macros remain defined.  *Note Standard
+     Predefined Macros::.
+
+'-I DIR'
+     Add the directory DIR to the list of directories to be searched for
+     header files.  *Note Search Path::.  Directories named by '-I' are
+     searched before the standard system include directories.  If the
+     directory DIR is a standard system include directory, the option is
+     ignored to ensure that the default search order for system
+     directories and the special treatment of system headers are not
+     defeated (*note System Headers::) .  If DIR begins with '=', then
+     the '=' will be replaced by the sysroot prefix; see '--sysroot' and
+     '-isysroot'.
+
+'-o FILE'
+     Write output to FILE.  This is the same as specifying FILE as the
+     second non-option argument to 'cpp'.  'gcc' has a different
+     interpretation of a second non-option argument, so you must use
+     '-o' to specify the output file.
+
+'-Wall'
+     Turns on all optional warnings which are desirable for normal code.
+     At present this is '-Wcomment', '-Wtrigraphs', '-Wmultichar' and a
+     warning about integer promotion causing a change of sign in '#if'
+     expressions.  Note that many of the preprocessor's warnings are on
+     by default and have no options to control them.
+
+'-Wcomment'
+'-Wcomments'
+     Warn whenever a comment-start sequence '/*' appears in a '/*'
+     comment, or whenever a backslash-newline appears in a '//' comment.
+     (Both forms have the same effect.)
+
+'-Wtrigraphs'
+     Most trigraphs in comments cannot affect the meaning of the
+     program.  However, a trigraph that would form an escaped newline
+     ('??/' at the end of a line) can, by changing where the comment
+     begins or ends.  Therefore, only trigraphs that would form escaped
+     newlines produce warnings inside a comment.
+
+     This option is implied by '-Wall'.  If '-Wall' is not given, this
+     option is still enabled unless trigraphs are enabled.  To get
+     trigraph conversion without warnings, but get the other '-Wall'
+     warnings, use '-trigraphs -Wall -Wno-trigraphs'.
+
+'-Wtraditional'
+     Warn about certain constructs that behave differently in
+     traditional and ISO C.  Also warn about ISO C constructs that have
+     no traditional C equivalent, and problematic constructs which
+     should be avoided.  *Note Traditional Mode::.
+
+'-Wundef'
+     Warn whenever an identifier which is not a macro is encountered in
+     an '#if' directive, outside of 'defined'.  Such identifiers are
+     replaced with zero.
+
+'-Wunused-macros'
+     Warn about macros defined in the main file that are unused.  A
+     macro is "used" if it is expanded or tested for existence at least
+     once.  The preprocessor will also warn if the macro has not been
+     used at the time it is redefined or undefined.
+
+     Built-in macros, macros defined on the command line, and macros
+     defined in include files are not warned about.
+
+     _Note:_ If a macro is actually used, but only used in skipped
+     conditional blocks, then CPP will report it as unused.  To avoid
+     the warning in such a case, you might improve the scope of the
+     macro's definition by, for example, moving it into the first
+     skipped block.  Alternatively, you could provide a dummy use with
+     something like:
+
+          #if defined the_macro_causing_the_warning
+          #endif
+
+'-Wendif-labels'
+     Warn whenever an '#else' or an '#endif' are followed by text.  This
+     usually happens in code of the form
+
+          #if FOO
+          ...
+          #else FOO
+          ...
+          #endif FOO
+
+     The second and third 'FOO' should be in comments, but often are not
+     in older programs.  This warning is on by default.
+
+'-Werror'
+     Make all warnings into hard errors.  Source code which triggers
+     warnings will be rejected.
+
+'-Wsystem-headers'
+     Issue warnings for code in system headers.  These are normally
+     unhelpful in finding bugs in your own code, therefore suppressed.
+     If you are responsible for the system library, you may want to see
+     them.
+
+'-w'
+     Suppress all warnings, including those which GNU CPP issues by
+     default.
+
+'-pedantic'
+     Issue all the mandatory diagnostics listed in the C standard.  Some
+     of them are left out by default, since they trigger frequently on
+     harmless code.
+
+'-pedantic-errors'
+     Issue all the mandatory diagnostics, and make all mandatory
+     diagnostics into errors.  This includes mandatory diagnostics that
+     GCC issues without '-pedantic' but treats as warnings.
+
+'-M'
+     Instead of outputting the result of preprocessing, output a rule
+     suitable for 'make' describing the dependencies of the main source
+     file.  The preprocessor outputs one 'make' rule containing the
+     object file name for that source file, a colon, and the names of
+     all the included files, including those coming from '-include' or
+     '-imacros' command line options.
+
+     Unless specified explicitly (with '-MT' or '-MQ'), the object file
+     name consists of the name of the source file with any suffix
+     replaced with object file suffix and with any leading directory
+     parts removed.  If there are many included files then the rule is
+     split into several lines using '\'-newline.  The rule has no
+     commands.
+
+     This option does not suppress the preprocessor's debug output, such
+     as '-dM'.  To avoid mixing such debug output with the dependency
+     rules you should explicitly specify the dependency output file with
+     '-MF', or use an environment variable like 'DEPENDENCIES_OUTPUT'
+     (*note Environment Variables::).  Debug output will still be sent
+     to the regular output stream as normal.
+
+     Passing '-M' to the driver implies '-E', and suppresses warnings
+     with an implicit '-w'.
+
+'-MM'
+     Like '-M' but do not mention header files that are found in system
+     header directories, nor header files that are included, directly or
+     indirectly, from such a header.
+
+     This implies that the choice of angle brackets or double quotes in
+     an '#include' directive does not in itself determine whether that
+     header will appear in '-MM' dependency output.  This is a slight
+     change in semantics from GCC versions 3.0 and earlier.
+
+'-MF FILE'
+     When used with '-M' or '-MM', specifies a file to write the
+     dependencies to.  If no '-MF' switch is given the preprocessor
+     sends the rules to the same place it would have sent preprocessed
+     output.
+
+     When used with the driver options '-MD' or '-MMD', '-MF' overrides
+     the default dependency output file.
+
+'-MG'
+     In conjunction with an option such as '-M' requesting dependency
+     generation, '-MG' assumes missing header files are generated files
+     and adds them to the dependency list without raising an error.  The
+     dependency filename is taken directly from the '#include' directive
+     without prepending any path.  '-MG' also suppresses preprocessed
+     output, as a missing header file renders this useless.
+
+     This feature is used in automatic updating of makefiles.
+
+'-MP'
+     This option instructs CPP to add a phony target for each dependency
+     other than the main file, causing each to depend on nothing.  These
+     dummy rules work around errors 'make' gives if you remove header
+     files without updating the 'Makefile' to match.
+
+     This is typical output:
+
+          test.o: test.c test.h
+
+          test.h:
+
+'-MT TARGET'
+
+     Change the target of the rule emitted by dependency generation.  By
+     default CPP takes the name of the main input file, deletes any
+     directory components and any file suffix such as '.c', and appends
+     the platform's usual object suffix.  The result is the target.
+
+     An '-MT' option will set the target to be exactly the string you
+     specify.  If you want multiple targets, you can specify them as a
+     single argument to '-MT', or use multiple '-MT' options.
+
+     For example, '-MT '$(objpfx)foo.o'' might give
+
+          $(objpfx)foo.o: foo.c
+
+'-MQ TARGET'
+
+     Same as '-MT', but it quotes any characters which are special to
+     Make.  '-MQ '$(objpfx)foo.o'' gives
+
+          $$(objpfx)foo.o: foo.c
+
+     The default target is automatically quoted, as if it were given
+     with '-MQ'.
+
+'-MD'
+     '-MD' is equivalent to '-M -MF FILE', except that '-E' is not
+     implied.  The driver determines FILE based on whether an '-o'
+     option is given.  If it is, the driver uses its argument but with a
+     suffix of '.d', otherwise it takes the name of the input file,
+     removes any directory components and suffix, and applies a '.d'
+     suffix.
+
+     If '-MD' is used in conjunction with '-E', any '-o' switch is
+     understood to specify the dependency output file (*note -MF:
+     dashMF.), but if used without '-E', each '-o' is understood to
+     specify a target object file.
+
+     Since '-E' is not implied, '-MD' can be used to generate a
+     dependency output file as a side-effect of the compilation process.
+
+'-MMD'
+     Like '-MD' except mention only user header files, not system header
+     files.
+
+'-x c'
+'-x c++'
+'-x objective-c'
+'-x assembler-with-cpp'
+     Specify the source language: C, C++, Objective-C, or assembly.
+     This has nothing to do with standards conformance or extensions; it
+     merely selects which base syntax to expect.  If you give none of
+     these options, cpp will deduce the language from the extension of
+     the source file: '.c', '.cc', '.m', or '.S'.  Some other common
+     extensions for C++ and assembly are also recognized.  If cpp does
+     not recognize the extension, it will treat the file as C; this is
+     the most generic mode.
+
+     _Note:_ Previous versions of cpp accepted a '-lang' option which
+     selected both the language and the standards conformance level.
+     This option has been removed, because it conflicts with the '-l'
+     option.
+
+'-std=STANDARD'
+'-ansi'
+     Specify the standard to which the code should conform.  Currently
+     CPP knows about C and C++ standards; others may be added in the
+     future.
+
+     STANDARD may be one of:
+     'c90'
+     'c89'
+     'iso9899:1990'
+          The ISO C standard from 1990.  'c90' is the customary
+          shorthand for this version of the standard.
+
+          The '-ansi' option is equivalent to '-std=c90'.
+
+     'iso9899:199409'
+          The 1990 C standard, as amended in 1994.
+
+     'iso9899:1999'
+     'c99'
+     'iso9899:199x'
+     'c9x'
+          The revised ISO C standard, published in December 1999.
+          Before publication, this was known as C9X.
+
+     'iso9899:2011'
+     'c11'
+     'c1x'
+          The revised ISO C standard, published in December 2011.
+          Before publication, this was known as C1X.
+
+     'gnu90'
+     'gnu89'
+          The 1990 C standard plus GNU extensions.  This is the default.
+
+     'gnu99'
+     'gnu9x'
+          The 1999 C standard plus GNU extensions.
+
+     'gnu11'
+     'gnu1x'
+          The 2011 C standard plus GNU extensions.
+
+     'c++98'
+          The 1998 ISO C++ standard plus amendments.
+
+     'gnu++98'
+          The same as '-std=c++98' plus GNU extensions.  This is the
+          default for C++ code.
+
+'-I-'
+     Split the include path.  Any directories specified with '-I'
+     options before '-I-' are searched only for headers requested with
+     '#include "FILE"'; they are not searched for '#include <FILE>'.  If
+     additional directories are specified with '-I' options after the
+     '-I-', those directories are searched for all '#include'
+     directives.
+
+     In addition, '-I-' inhibits the use of the directory of the current
+     file directory as the first search directory for '#include "FILE"'.
+     *Note Search Path::.  This option has been deprecated.
+
+'-nostdinc'
+     Do not search the standard system directories for header files.
+     Only the directories you have specified with '-I' options (and the
+     directory of the current file, if appropriate) are searched.
+
+'-nostdinc++'
+     Do not search for header files in the C++-specific standard
+     directories, but do still search the other standard directories.
+     (This option is used when building the C++ library.)
+
+'-include FILE'
+     Process FILE as if '#include "file"' appeared as the first line of
+     the primary source file.  However, the first directory searched for
+     FILE is the preprocessor's working directory _instead of_ the
+     directory containing the main source file.  If not found there, it
+     is searched for in the remainder of the '#include "..."' search
+     chain as normal.
+
+     If multiple '-include' options are given, the files are included in
+     the order they appear on the command line.
+
+'-imacros FILE'
+     Exactly like '-include', except that any output produced by
+     scanning FILE is thrown away.  Macros it defines remain defined.
+     This allows you to acquire all the macros from a header without
+     also processing its declarations.
+
+     All files specified by '-imacros' are processed before all files
+     specified by '-include'.
+
+'-idirafter DIR'
+     Search DIR for header files, but do it _after_ all directories
+     specified with '-I' and the standard system directories have been
+     exhausted.  DIR is treated as a system include directory.  If DIR
+     begins with '=', then the '=' will be replaced by the sysroot
+     prefix; see '--sysroot' and '-isysroot'.
+
+'-iprefix PREFIX'
+     Specify PREFIX as the prefix for subsequent '-iwithprefix' options.
+     If the prefix represents a directory, you should include the final
+     '/'.
+
+'-iwithprefix DIR'
+'-iwithprefixbefore DIR'
+     Append DIR to the prefix specified previously with '-iprefix', and
+     add the resulting directory to the include search path.
+     '-iwithprefixbefore' puts it in the same place '-I' would;
+     '-iwithprefix' puts it where '-idirafter' would.
+
+'-isysroot DIR'
+     This option is like the '--sysroot' option, but applies only to
+     header files (except for Darwin targets, where it applies to both
+     header files and libraries).  See the '--sysroot' option for more
+     information.
+
+'-imultilib DIR'
+     Use DIR as a subdirectory of the directory containing
+     target-specific C++ headers.
+
+'-isystem DIR'
+     Search DIR for header files, after all directories specified by
+     '-I' but before the standard system directories.  Mark it as a
+     system directory, so that it gets the same special treatment as is
+     applied to the standard system directories.  *Note System
+     Headers::.  If DIR begins with '=', then the '=' will be replaced
+     by the sysroot prefix; see '--sysroot' and '-isysroot'.
+
+'-iquote DIR'
+     Search DIR only for header files requested with '#include "FILE"';
+     they are not searched for '#include <FILE>', before all directories
+     specified by '-I' and before the standard system directories.
+     *Note Search Path::.  If DIR begins with '=', then the '=' will be
+     replaced by the sysroot prefix; see '--sysroot' and '-isysroot'.
+
+'-fdirectives-only'
+     When preprocessing, handle directives, but do not expand macros.
+
+     The option's behavior depends on the '-E' and '-fpreprocessed'
+     options.
+
+     With '-E', preprocessing is limited to the handling of directives
+     such as '#define', '#ifdef', and '#error'.  Other preprocessor
+     operations, such as macro expansion and trigraph conversion are not
+     performed.  In addition, the '-dD' option is implicitly enabled.
+
+     With '-fpreprocessed', predefinition of command line and most
+     builtin macros is disabled.  Macros such as '__LINE__', which are
+     contextually dependent, are handled normally.  This enables
+     compilation of files previously preprocessed with '-E
+     -fdirectives-only'.
+
+     With both '-E' and '-fpreprocessed', the rules for '-fpreprocessed'
+     take precedence.  This enables full preprocessing of files
+     previously preprocessed with '-E -fdirectives-only'.
+
+'-fdollars-in-identifiers'
+     Accept '$' in identifiers.  *Note Identifier characters::.
+
+'-fextended-identifiers'
+     Accept universal character names in identifiers.  This option is
+     experimental; in a future version of GCC, it will be enabled by
+     default for C99 and C++.
+
+'-fno-canonical-system-headers'
+     When preprocessing, do not shorten system header paths with
+     canonicalization.
+
+'-fpreprocessed'
+     Indicate to the preprocessor that the input file has already been
+     preprocessed.  This suppresses things like macro expansion,
+     trigraph conversion, escaped newline splicing, and processing of
+     most directives.  The preprocessor still recognizes and removes
+     comments, so that you can pass a file preprocessed with '-C' to the
+     compiler without problems.  In this mode the integrated
+     preprocessor is little more than a tokenizer for the front ends.
+
+     '-fpreprocessed' is implicit if the input file has one of the
+     extensions '.i', '.ii' or '.mi'.  These are the extensions that GCC
+     uses for preprocessed files created by '-save-temps'.
+
+'-ftabstop=WIDTH'
+     Set the distance between tab stops.  This helps the preprocessor
+     report correct column numbers in warnings or errors, even if tabs
+     appear on the line.  If the value is less than 1 or greater than
+     100, the option is ignored.  The default is 8.
+
+'-fdebug-cpp'
+     This option is only useful for debugging GCC. When used with '-E',
+     dumps debugging information about location maps.  Every token in
+     the output is preceded by the dump of the map its location belongs
+     to.  The dump of the map holding the location of a token would be:
+          {'P':/file/path;'F':/includer/path;'L':LINE_NUM;'C':COL_NUM;'S':SYSTEM_HEADER_P;'M':MAP_ADDRESS;'E':MACRO_EXPANSION_P,'loc':LOCATION}
+
+     When used without '-E', this option has no effect.
+
+'-ftrack-macro-expansion[=LEVEL]'
+     Track locations of tokens across macro expansions.  This allows the
+     compiler to emit diagnostic about the current macro expansion stack
+     when a compilation error occurs in a macro expansion.  Using this
+     option makes the preprocessor and the compiler consume more memory.
+     The LEVEL parameter can be used to choose the level of precision of
+     token location tracking thus decreasing the memory consumption if
+     necessary.  Value '0' of LEVEL de-activates this option just as if
+     no '-ftrack-macro-expansion' was present on the command line.
+     Value '1' tracks tokens locations in a degraded mode for the sake
+     of minimal memory overhead.  In this mode all tokens resulting from
+     the expansion of an argument of a function-like macro have the same
+     location.  Value '2' tracks tokens locations completely.  This
+     value is the most memory hungry.  When this option is given no
+     argument, the default parameter value is '2'.
+
+     Note that -ftrack-macro-expansion=2 is activated by default.
+
+'-fexec-charset=CHARSET'
+     Set the execution character set, used for string and character
+     constants.  The default is UTF-8.  CHARSET can be any encoding
+     supported by the system's 'iconv' library routine.
+
+'-fwide-exec-charset=CHARSET'
+     Set the wide execution character set, used for wide string and
+     character constants.  The default is UTF-32 or UTF-16, whichever
+     corresponds to the width of 'wchar_t'.  As with '-fexec-charset',
+     CHARSET can be any encoding supported by the system's 'iconv'
+     library routine; however, you will have problems with encodings
+     that do not fit exactly in 'wchar_t'.
+
+'-finput-charset=CHARSET'
+     Set the input character set, used for translation from the
+     character set of the input file to the source character set used by
+     GCC.  If the locale does not specify, or GCC cannot get this
+     information from the locale, the default is UTF-8.  This can be
+     overridden by either the locale or this command line option.
+     Currently the command line option takes precedence if there's a
+     conflict.  CHARSET can be any encoding supported by the system's
+     'iconv' library routine.
+
+'-fworking-directory'
+     Enable generation of linemarkers in the preprocessor output that
+     will let the compiler know the current working directory at the
+     time of preprocessing.  When this option is enabled, the
+     preprocessor will emit, after the initial linemarker, a second
+     linemarker with the current working directory followed by two
+     slashes.  GCC will use this directory, when it's present in the
+     preprocessed input, as the directory emitted as the current working
+     directory in some debugging information formats.  This option is
+     implicitly enabled if debugging information is enabled, but this
+     can be inhibited with the negated form '-fno-working-directory'.
+     If the '-P' flag is present in the command line, this option has no
+     effect, since no '#line' directives are emitted whatsoever.
+
+'-fno-show-column'
+     Do not print column numbers in diagnostics.  This may be necessary
+     if diagnostics are being scanned by a program that does not
+     understand the column numbers, such as 'dejagnu'.
+
+'-A PREDICATE=ANSWER'
+     Make an assertion with the predicate PREDICATE and answer ANSWER.
+     This form is preferred to the older form '-A PREDICATE(ANSWER)',
+     which is still supported, because it does not use shell special
+     characters.  *Note Obsolete Features::.
+
+'-A -PREDICATE=ANSWER'
+     Cancel an assertion with the predicate PREDICATE and answer ANSWER.
+
+'-dCHARS'
+     CHARS is a sequence of one or more of the following characters, and
+     must not be preceded by a space.  Other characters are interpreted
+     by the compiler proper, or reserved for future versions of GCC, and
+     so are silently ignored.  If you specify characters whose behavior
+     conflicts, the result is undefined.
+
+     'M'
+          Instead of the normal output, generate a list of '#define'
+          directives for all the macros defined during the execution of
+          the preprocessor, including predefined macros.  This gives you
+          a way of finding out what is predefined in your version of the
+          preprocessor.  Assuming you have no file 'foo.h', the command
+
+               touch foo.h; cpp -dM foo.h
+
+          will show all the predefined macros.
+
+          If you use '-dM' without the '-E' option, '-dM' is interpreted
+          as a synonym for '-fdump-rtl-mach'.  *Note (gcc)Debugging
+          Options::.
+
+     'D'
+          Like 'M' except in two respects: it does _not_ include the
+          predefined macros, and it outputs _both_ the '#define'
+          directives and the result of preprocessing.  Both kinds of
+          output go to the standard output file.
+
+     'N'
+          Like 'D', but emit only the macro names, not their expansions.
+
+     'I'
+          Output '#include' directives in addition to the result of
+          preprocessing.
+
+     'U'
+          Like 'D' except that only macros that are expanded, or whose
+          definedness is tested in preprocessor directives, are output;
+          the output is delayed until the use or test of the macro; and
+          '#undef' directives are also output for macros tested but
+          undefined at the time.
+
+'-P'
+     Inhibit generation of linemarkers in the output from the
+     preprocessor.  This might be useful when running the preprocessor
+     on something that is not C code, and will be sent to a program
+     which might be confused by the linemarkers.  *Note Preprocessor
+     Output::.
+
+'-C'
+     Do not discard comments.  All comments are passed through to the
+     output file, except for comments in processed directives, which are
+     deleted along with the directive.
+
+     You should be prepared for side effects when using '-C'; it causes
+     the preprocessor to treat comments as tokens in their own right.
+     For example, comments appearing at the start of what would be a
+     directive line have the effect of turning that line into an
+     ordinary source line, since the first token on the line is no
+     longer a '#'.
+
+'-CC'
+     Do not discard comments, including during macro expansion.  This is
+     like '-C', except that comments contained within macros are also
+     passed through to the output file where the macro is expanded.
+
+     In addition to the side-effects of the '-C' option, the '-CC'
+     option causes all C++-style comments inside a macro to be converted
+     to C-style comments.  This is to prevent later use of that macro
+     from inadvertently commenting out the remainder of the source line.
+
+     The '-CC' option is generally used to support lint comments.
+
+'-traditional-cpp'
+     Try to imitate the behavior of old-fashioned C preprocessors, as
+     opposed to ISO C preprocessors.  *Note Traditional Mode::.
+
+'-trigraphs'
+     Process trigraph sequences.  *Note Initial processing::.
+
+'-remap'
+     Enable special code to work around file systems which only permit
+     very short file names, such as MS-DOS.
+
+'--help'
+'--target-help'
+     Print text describing all the command line options instead of
+     preprocessing anything.
+
+'-v'
+     Verbose mode.  Print out GNU CPP's version number at the beginning
+     of execution, and report the final form of the include path.
+
+'-H'
+     Print the name of each header file used, in addition to other
+     normal activities.  Each name is indented to show how deep in the
+     '#include' stack it is.  Precompiled header files are also printed,
+     even if they are found to be invalid; an invalid precompiled header
+     file is printed with '...x' and a valid one with '...!' .
+
+'-version'
+'--version'
+     Print out GNU CPP's version number.  With one dash, proceed to
+     preprocess as normal.  With two dashes, exit immediately.
+
+
+File: cpp.info,  Node: Environment Variables,  Next: GNU Free Documentation License,  Prev: Invocation,  Up: Top
+
+13 Environment Variables
+************************
+
+This section describes the environment variables that affect how CPP
+operates.  You can use them to specify directories or prefixes to use
+when searching for include files, or to control dependency output.
+
+   Note that you can also specify places to search using options such as
+'-I', and control dependency output with options like '-M' (*note
+Invocation::).  These take precedence over environment variables, which
+in turn take precedence over the configuration of GCC.
+
+'CPATH'
+'C_INCLUDE_PATH'
+'CPLUS_INCLUDE_PATH'
+'OBJC_INCLUDE_PATH'
+     Each variable's value is a list of directories separated by a
+     special character, much like 'PATH', in which to look for header
+     files.  The special character, 'PATH_SEPARATOR', is
+     target-dependent and determined at GCC build time.  For Microsoft
+     Windows-based targets it is a semicolon, and for almost all other
+     targets it is a colon.
+
+     'CPATH' specifies a list of directories to be searched as if
+     specified with '-I', but after any paths given with '-I' options on
+     the command line.  This environment variable is used regardless of
+     which language is being preprocessed.
+
+     The remaining environment variables apply only when preprocessing
+     the particular language indicated.  Each specifies a list of
+     directories to be searched as if specified with '-isystem', but
+     after any paths given with '-isystem' options on the command line.
+
+     In all these variables, an empty element instructs the compiler to
+     search its current working directory.  Empty elements can appear at
+     the beginning or end of a path.  For instance, if the value of
+     'CPATH' is ':/special/include', that has the same effect as
+     '-I. -I/special/include'.
+
+     See also *note Search Path::.
+
+'DEPENDENCIES_OUTPUT'
+     If this variable is set, its value specifies how to output
+     dependencies for Make based on the non-system header files
+     processed by the compiler.  System header files are ignored in the
+     dependency output.
+
+     The value of 'DEPENDENCIES_OUTPUT' can be just a file name, in
+     which case the Make rules are written to that file, guessing the
+     target name from the source file name.  Or the value can have the
+     form 'FILE TARGET', in which case the rules are written to file
+     FILE using TARGET as the target name.
+
+     In other words, this environment variable is equivalent to
+     combining the options '-MM' and '-MF' (*note Invocation::), with an
+     optional '-MT' switch too.
+
+'SUNPRO_DEPENDENCIES'
+     This variable is the same as 'DEPENDENCIES_OUTPUT' (see above),
+     except that system header files are not ignored, so it implies '-M'
+     rather than '-MM'.  However, the dependence on the main input file
+     is omitted.  *Note Invocation::.
+
+
+File: cpp.info,  Node: GNU Free Documentation License,  Next: Index of Directives,  Prev: Environment Variables,  Up: Top
+
+GNU Free Documentation License
+******************************
+
+                     Version 1.3, 3 November 2008
+
+     Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
+     <http://fsf.org/>
+
+     Everyone is permitted to copy and distribute verbatim copies
+     of this license document, but changing it is not allowed.
+
+  0. PREAMBLE
+
+     The purpose of this License is to make a manual, textbook, or other
+     functional and useful document "free" in the sense of freedom: to
+     assure everyone the effective freedom to copy and redistribute it,
+     with or without modifying it, either commercially or
+     noncommercially.  Secondarily, this License preserves for the
+     author and publisher a way to get credit for their work, while not
+     being considered responsible for modifications made by others.
+
+     This License is a kind of "copyleft", which means that derivative
+     works of the document must themselves be free in the same sense.
+     It complements the GNU General Public License, which is a copyleft
+     license designed for free software.
+
+     We have designed this License in order to use it for manuals for
+     free software, because free software needs free documentation: a
+     free program should come with manuals providing the same freedoms
+     that the software does.  But this License is not limited to
+     software manuals; it can be used for any textual work, regardless
+     of subject matter or whether it is published as a printed book.  We
+     recommend this License principally for works whose purpose is
+     instruction or reference.
+
+  1. APPLICABILITY AND DEFINITIONS
+
+     This License applies to any manual or other work, in any medium,
+     that contains a notice placed by the copyright holder saying it can
+     be distributed under the terms of this License.  Such a notice
+     grants a world-wide, royalty-free license, unlimited in duration,
+     to use that work under the conditions stated herein.  The
+     "Document", below, refers to any such manual or work.  Any member
+     of the public is a licensee, and is addressed as "you".  You accept
+     the license if you copy, modify or distribute the work in a way
+     requiring permission under copyright law.
+
+     A "Modified Version" of the Document means any work containing the
+     Document or a portion of it, either copied verbatim, or with
+     modifications and/or translated into another language.
+
+     A "Secondary Section" is a named appendix or a front-matter section
+     of the Document that deals exclusively with the relationship of the
+     publishers or authors of the Document to the Document's overall
+     subject (or to related matters) and contains nothing that could
+     fall directly within that overall subject.  (Thus, if the Document
+     is in part a textbook of mathematics, a Secondary Section may not
+     explain any mathematics.)  The relationship could be a matter of
+     historical connection with the subject or with related matters, or
+     of legal, commercial, philosophical, ethical or political position
+     regarding them.
+
+     The "Invariant Sections" are certain Secondary Sections whose
+     titles are designated, as being those of Invariant Sections, in the
+     notice that says that the Document is released under this License.
+     If a section does not fit the above definition of Secondary then it
+     is not allowed to be designated as Invariant.  The Document may
+     contain zero Invariant Sections.  If the Document does not identify
+     any Invariant Sections then there are none.
+
+     The "Cover Texts" are certain short passages of text that are
+     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
+     that says that the Document is released under this License.  A
+     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
+     be at most 25 words.
+
+     A "Transparent" copy of the Document means a machine-readable copy,
+     represented in a format whose specification is available to the
+     general public, that is suitable for revising the document
+     straightforwardly with generic text editors or (for images composed
+     of pixels) generic paint programs or (for drawings) some widely
+     available drawing editor, and that is suitable for input to text
+     formatters or for automatic translation to a variety of formats
+     suitable for input to text formatters.  A copy made in an otherwise
+     Transparent file format whose markup, or absence of markup, has
+     been arranged to thwart or discourage subsequent modification by
+     readers is not Transparent.  An image format is not Transparent if
+     used for any substantial amount of text.  A copy that is not
+     "Transparent" is called "Opaque".
+
+     Examples of suitable formats for Transparent copies include plain
+     ASCII without markup, Texinfo input format, LaTeX input format,
+     SGML or XML using a publicly available DTD, and standard-conforming
+     simple HTML, PostScript or PDF designed for human modification.
+     Examples of transparent image formats include PNG, XCF and JPG.
+     Opaque formats include proprietary formats that can be read and
+     edited only by proprietary word processors, SGML or XML for which
+     the DTD and/or processing tools are not generally available, and
+     the machine-generated HTML, PostScript or PDF produced by some word
+     processors for output purposes only.
+
+     The "Title Page" means, for a printed book, the title page itself,
+     plus such following pages as are needed to hold, legibly, the
+     material this License requires to appear in the title page.  For
+     works in formats which do not have any title page as such, "Title
+     Page" means the text near the most prominent appearance of the
+     work's title, preceding the beginning of the body of the text.
+
+     The "publisher" means any person or entity that distributes copies
+     of the Document to the public.
+
+     A section "Entitled XYZ" means a named subunit of the Document
+     whose title either is precisely XYZ or contains XYZ in parentheses
+     following text that translates XYZ in another language.  (Here XYZ
+     stands for a specific section name mentioned below, such as
+     "Acknowledgements", "Dedications", "Endorsements", or "History".)
+     To "Preserve the Title" of such a section when you modify the
+     Document means that it remains a section "Entitled XYZ" according
+     to this definition.
+
+     The Document may include Warranty Disclaimers next to the notice
+     which states that this License applies to the Document.  These
+     Warranty Disclaimers are considered to be included by reference in
+     this License, but only as regards disclaiming warranties: any other
+     implication that these Warranty Disclaimers may have is void and
+     has no effect on the meaning of this License.
+
+  2. VERBATIM COPYING
+
+     You may copy and distribute the Document in any medium, either
+     commercially or noncommercially, provided that this License, the
+     copyright notices, and the license notice saying this License
+     applies to the Document are reproduced in all copies, and that you
+     add no other conditions whatsoever to those of this License.  You
+     may not use technical measures to obstruct or control the reading
+     or further copying of the copies you make or distribute.  However,
+     you may accept compensation in exchange for copies.  If you
+     distribute a large enough number of copies you must also follow the
+     conditions in section 3.
+
+     You may also lend copies, under the same conditions stated above,
+     and you may publicly display copies.
+
+  3. COPYING IN QUANTITY
+
+     If you publish printed copies (or copies in media that commonly
+     have printed covers) of the Document, numbering more than 100, and
+     the Document's license notice requires Cover Texts, you must
+     enclose the copies in covers that carry, clearly and legibly, all
+     these Cover Texts: Front-Cover Texts on the front cover, and
+     Back-Cover Texts on the back cover.  Both covers must also clearly
+     and legibly identify you as the publisher of these copies.  The
+     front cover must present the full title with all words of the title
+     equally prominent and visible.  You may add other material on the
+     covers in addition.  Copying with changes limited to the covers, as
+     long as they preserve the title of the Document and satisfy these
+     conditions, can be treated as verbatim copying in other respects.
+
+     If the required texts for either cover are too voluminous to fit
+     legibly, you should put the first ones listed (as many as fit
+     reasonably) on the actual cover, and continue the rest onto
+     adjacent pages.
+
+     If you publish or distribute Opaque copies of the Document
+     numbering more than 100, you must either include a machine-readable
+     Transparent copy along with each Opaque copy, or state in or with
+     each Opaque copy a computer-network location from which the general
+     network-using public has access to download using public-standard
+     network protocols a complete Transparent copy of the Document, free
+     of added material.  If you use the latter option, you must take
+     reasonably prudent steps, when you begin distribution of Opaque
+     copies in quantity, to ensure that this Transparent copy will
+     remain thus accessible at the stated location until at least one
+     year after the last time you distribute an Opaque copy (directly or
+     through your agents or retailers) of that edition to the public.
+
+     It is requested, but not required, that you contact the authors of
+     the Document well before redistributing any large number of copies,
+     to give them a chance to provide you with an updated version of the
+     Document.
+
+  4. MODIFICATIONS
+
+     You may copy and distribute a Modified Version of the Document
+     under the conditions of sections 2 and 3 above, provided that you
+     release the Modified Version under precisely this License, with the
+     Modified Version filling the role of the Document, thus licensing
+     distribution and modification of the Modified Version to whoever
+     possesses a copy of it.  In addition, you must do these things in
+     the Modified Version:
+
+       A. Use in the Title Page (and on the covers, if any) a title
+          distinct from that of the Document, and from those of previous
+          versions (which should, if there were any, be listed in the
+          History section of the Document).  You may use the same title
+          as a previous version if the original publisher of that
+          version gives permission.
+
+       B. List on the Title Page, as authors, one or more persons or
+          entities responsible for authorship of the modifications in
+          the Modified Version, together with at least five of the
+          principal authors of the Document (all of its principal
+          authors, if it has fewer than five), unless they release you
+          from this requirement.
+
+       C. State on the Title page the name of the publisher of the
+          Modified Version, as the publisher.
+
+       D. Preserve all the copyright notices of the Document.
+
+       E. Add an appropriate copyright notice for your modifications
+          adjacent to the other copyright notices.
+
+       F. Include, immediately after the copyright notices, a license
+          notice giving the public permission to use the Modified
+          Version under the terms of this License, in the form shown in
+          the Addendum below.
+
+       G. Preserve in that license notice the full lists of Invariant
+          Sections and required Cover Texts given in the Document's
+          license notice.
+
+       H. Include an unaltered copy of this License.
+
+       I. Preserve the section Entitled "History", Preserve its Title,
+          and add to it an item stating at least the title, year, new
+          authors, and publisher of the Modified Version as given on the
+          Title Page.  If there is no section Entitled "History" in the
+          Document, create one stating the title, year, authors, and
+          publisher of the Document as given on its Title Page, then add
+          an item describing the Modified Version as stated in the
+          previous sentence.
+
+       J. Preserve the network location, if any, given in the Document
+          for public access to a Transparent copy of the Document, and
+          likewise the network locations given in the Document for
+          previous versions it was based on.  These may be placed in the
+          "History" section.  You may omit a network location for a work
+          that was published at least four years before the Document
+          itself, or if the original publisher of the version it refers
+          to gives permission.
+
+       K. For any section Entitled "Acknowledgements" or "Dedications",
+          Preserve the Title of the section, and preserve in the section
+          all the substance and tone of each of the contributor
+          acknowledgements and/or dedications given therein.
+
+       L. Preserve all the Invariant Sections of the Document, unaltered
+          in their text and in their titles.  Section numbers or the
+          equivalent are not considered part of the section titles.
+
+       M. Delete any section Entitled "Endorsements".  Such a section
+          may not be included in the Modified Version.
+
+       N. Do not retitle any existing section to be Entitled
+          "Endorsements" or to conflict in title with any Invariant
+          Section.
+
+       O. Preserve any Warranty Disclaimers.
+
+     If the Modified Version includes new front-matter sections or
+     appendices that qualify as Secondary Sections and contain no
+     material copied from the Document, you may at your option designate
+     some or all of these sections as invariant.  To do this, add their
+     titles to the list of Invariant Sections in the Modified Version's
+     license notice.  These titles must be distinct from any other
+     section titles.
+
+     You may add a section Entitled "Endorsements", provided it contains
+     nothing but endorsements of your Modified Version by various
+     parties--for example, statements of peer review or that the text
+     has been approved by an organization as the authoritative
+     definition of a standard.
+
+     You may add a passage of up to five words as a Front-Cover Text,
+     and a passage of up to 25 words as a Back-Cover Text, to the end of
+     the list of Cover Texts in the Modified Version.  Only one passage
+     of Front-Cover Text and one of Back-Cover Text may be added by (or
+     through arrangements made by) any one entity.  If the Document
+     already includes a cover text for the same cover, previously added
+     by you or by arrangement made by the same entity you are acting on
+     behalf of, you may not add another; but you may replace the old
+     one, on explicit permission from the previous publisher that added
+     the old one.
+
+     The author(s) and publisher(s) of the Document do not by this
+     License give permission to use their names for publicity for or to
+     assert or imply endorsement of any Modified Version.
+
+  5. COMBINING DOCUMENTS
+
+     You may combine the Document with other documents released under
+     this License, under the terms defined in section 4 above for
+     modified versions, provided that you include in the combination all
+     of the Invariant Sections of all of the original documents,
+     unmodified, and list them all as Invariant Sections of your
+     combined work in its license notice, and that you preserve all
+     their Warranty Disclaimers.
+
+     The combined work need only contain one copy of this License, and
+     multiple identical Invariant Sections may be replaced with a single
+     copy.  If there are multiple Invariant Sections with the same name
+     but different contents, make the title of each such section unique
+     by adding at the end of it, in parentheses, the name of the
+     original author or publisher of that section if known, or else a
+     unique number.  Make the same adjustment to the section titles in
+     the list of Invariant Sections in the license notice of the
+     combined work.
+
+     In the combination, you must combine any sections Entitled
+     "History" in the various original documents, forming one section
+     Entitled "History"; likewise combine any sections Entitled
+     "Acknowledgements", and any sections Entitled "Dedications".  You
+     must delete all sections Entitled "Endorsements."
+
+  6. COLLECTIONS OF DOCUMENTS
+
+     You may make a collection consisting of the Document and other
+     documents released under this License, and replace the individual
+     copies of this License in the various documents with a single copy
+     that is included in the collection, provided that you follow the
+     rules of this License for verbatim copying of each of the documents
+     in all other respects.
+
+     You may extract a single document from such a collection, and
+     distribute it individually under this License, provided you insert
+     a copy of this License into the extracted document, and follow this
+     License in all other respects regarding verbatim copying of that
+     document.
+
+  7. AGGREGATION WITH INDEPENDENT WORKS
+
+     A compilation of the Document or its derivatives with other
+     separate and independent documents or works, in or on a volume of a
+     storage or distribution medium, is called an "aggregate" if the
+     copyright resulting from the compilation is not used to limit the
+     legal rights of the compilation's users beyond what the individual
+     works permit.  When the Document is included in an aggregate, this
+     License does not apply to the other works in the aggregate which
+     are not themselves derivative works of the Document.
+
+     If the Cover Text requirement of section 3 is applicable to these
+     copies of the Document, then if the Document is less than one half
+     of the entire aggregate, the Document's Cover Texts may be placed
+     on covers that bracket the Document within the aggregate, or the
+     electronic equivalent of covers if the Document is in electronic
+     form.  Otherwise they must appear on printed covers that bracket
+     the whole aggregate.
+
+  8. TRANSLATION
+
+     Translation is considered a kind of modification, so you may
+     distribute translations of the Document under the terms of section
+     4.  Replacing Invariant Sections with translations requires special
+     permission from their copyright holders, but you may include
+     translations of some or all Invariant Sections in addition to the
+     original versions of these Invariant Sections.  You may include a
+     translation of this License, and all the license notices in the
+     Document, and any Warranty Disclaimers, provided that you also
+     include the original English version of this License and the
+     original versions of those notices and disclaimers.  In case of a
+     disagreement between the translation and the original version of
+     this License or a notice or disclaimer, the original version will
+     prevail.
+
+     If a section in the Document is Entitled "Acknowledgements",
+     "Dedications", or "History", the requirement (section 4) to
+     Preserve its Title (section 1) will typically require changing the
+     actual title.
+
+  9. TERMINATION
+
+     You may not copy, modify, sublicense, or distribute the Document
+     except as expressly provided under this License.  Any attempt
+     otherwise to copy, modify, sublicense, or distribute it is void,
+     and will automatically terminate your rights under this License.
+
+     However, if you cease all violation of this License, then your
+     license from a particular copyright holder is reinstated (a)
+     provisionally, unless and until the copyright holder explicitly and
+     finally terminates your license, and (b) permanently, if the
+     copyright holder fails to notify you of the violation by some
+     reasonable means prior to 60 days after the cessation.
+
+     Moreover, your license from a particular copyright holder is
+     reinstated permanently if the copyright holder notifies you of the
+     violation by some reasonable means, this is the first time you have
+     received notice of violation of this License (for any work) from
+     that copyright holder, and you cure the violation prior to 30 days
+     after your receipt of the notice.
+
+     Termination of your rights under this section does not terminate
+     the licenses of parties who have received copies or rights from you
+     under this License.  If your rights have been terminated and not
+     permanently reinstated, receipt of a copy of some or all of the
+     same material does not give you any rights to use it.
+
+  10. FUTURE REVISIONS OF THIS LICENSE
+
+     The Free Software Foundation may publish new, revised versions of
+     the GNU Free Documentation License from time to time.  Such new
+     versions will be similar in spirit to the present version, but may
+     differ in detail to address new problems or concerns.  See
+     <http://www.gnu.org/copyleft/>.
+
+     Each version of the License is given a distinguishing version
+     number.  If the Document specifies that a particular numbered
+     version of this License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that specified version or of any later version that has been
+     published (not as a draft) by the Free Software Foundation.  If the
+     Document does not specify a version number of this License, you may
+     choose any version ever published (not as a draft) by the Free
+     Software Foundation.  If the Document specifies that a proxy can
+     decide which future versions of this License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Document.
+
+  11. RELICENSING
+
+     "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
+     World Wide Web server that publishes copyrightable works and also
+     provides prominent facilities for anybody to edit those works.  A
+     public wiki that anybody can edit is an example of such a server.
+     A "Massive Multiauthor Collaboration" (or "MMC") contained in the
+     site means any set of copyrightable works thus published on the MMC
+     site.
+
+     "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
+     license published by Creative Commons Corporation, a not-for-profit
+     corporation with a principal place of business in San Francisco,
+     California, as well as future copyleft versions of that license
+     published by that same organization.
+
+     "Incorporate" means to publish or republish a Document, in whole or
+     in part, as part of another Document.
+
+     An MMC is "eligible for relicensing" if it is licensed under this
+     License, and if all works that were first published under this
+     License somewhere other than this MMC, and subsequently
+     incorporated in whole or in part into the MMC, (1) had no cover
+     texts or invariant sections, and (2) were thus incorporated prior
+     to November 1, 2008.
+
+     The operator of an MMC Site may republish an MMC contained in the
+     site under CC-BY-SA on the same site at any time before August 1,
+     2009, provided the MMC is eligible for relicensing.
+
+ADDENDUM: How to use this License for your documents
+====================================================
+
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and license
+notices just after the title page:
+
+       Copyright (C)  YEAR  YOUR NAME.
+       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, no Front-Cover Texts, and no Back-Cover
+       Texts.  A copy of the license is included in the section entitled ``GNU
+       Free Documentation License''.
+
+   If you have Invariant Sections, Front-Cover Texts and Back-Cover
+Texts, replace the "with...Texts."  line with this:
+
+         with the Invariant Sections being LIST THEIR TITLES, with
+         the Front-Cover Texts being LIST, and with the Back-Cover Texts
+         being LIST.
+
+   If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+
+   If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of free
+software license, such as the GNU General Public License, to permit
+their use in free software.
+
+
+File: cpp.info,  Node: Index of Directives,  Next: Option Index,  Prev: GNU Free Documentation License,  Up: Top
+
+Index of Directives
+*******************
+
+
+* Menu:
+
+* #assert:                               Obsolete Features.   (line  48)
+* #define:                               Object-like Macros.  (line  11)
+* #elif:                                 Elif.                (line   6)
+* #else:                                 Else.                (line   6)
+* #endif:                                Ifdef.               (line   6)
+* #error:                                Diagnostics.         (line   6)
+* #ident:                                Other Directives.    (line   6)
+* #if:                                   Conditional Syntax.  (line   6)
+* #ifdef:                                Ifdef.               (line   6)
+* #ifndef:                               Ifdef.               (line  40)
+* #import:                               Alternatives to Wrapper #ifndef.
+                                                              (line  11)
+* #include:                              Include Syntax.      (line   6)
+* #include_next:                         Wrapper Headers.     (line   6)
+* #line:                                 Line Control.        (line  20)
+* #pragma GCC dependency:                Pragmas.             (line  55)
+* #pragma GCC error:                     Pragmas.             (line 100)
+* #pragma GCC poison:                    Pragmas.             (line  67)
+* #pragma GCC system_header:             System Headers.      (line  31)
+* #pragma GCC system_header <1>:         Pragmas.             (line  94)
+* #pragma GCC warning:                   Pragmas.             (line  99)
+* #sccs:                                 Other Directives.    (line   6)
+* #unassert:                             Obsolete Features.   (line  59)
+* #undef:                                Undefining and Redefining Macros.
+                                                              (line   6)
+* #warning:                              Diagnostics.         (line  27)
+
+
+File: cpp.info,  Node: Option Index,  Next: Concept Index,  Prev: Index of Directives,  Up: Top
+
+Option Index
+************
+
+CPP's command line options and environment variables are indexed here
+without any initial '-' or '--'.
+
+
+* Menu:
+
+* A:                                     Invocation.          (line 567)
+* ansi:                                  Invocation.          (line 311)
+* C:                                     Invocation.          (line 625)
+* CPATH:                                 Environment Variables.
+                                                              (line  15)
+* CPLUS_INCLUDE_PATH:                    Environment Variables.
+                                                              (line  17)
+* C_INCLUDE_PATH:                        Environment Variables.
+                                                              (line  16)
+* D:                                     Invocation.          (line  40)
+* dD:                                    Invocation.          (line 598)
+* DEPENDENCIES_OUTPUT:                   Environment Variables.
+                                                              (line  44)
+* dI:                                    Invocation.          (line 607)
+* dM:                                    Invocation.          (line 583)
+* dN:                                    Invocation.          (line 604)
+* dU:                                    Invocation.          (line 611)
+* fdebug-cpp:                            Invocation.          (line 498)
+* fdirectives-only:                      Invocation.          (line 446)
+* fdollars-in-identifiers:               Invocation.          (line 467)
+* fexec-charset:                         Invocation.          (line 525)
+* fextended-identifiers:                 Invocation.          (line 470)
+* finput-charset:                        Invocation.          (line 538)
+* fno-canonical-system-headers:          Invocation.          (line 475)
+* fno-show-column:                       Invocation.          (line 562)
+* fno-working-directory:                 Invocation.          (line 548)
+* fpreprocessed:                         Invocation.          (line 479)
+* ftabstop:                              Invocation.          (line 492)
+* ftrack-macro-expansion:                Invocation.          (line 507)
+* fwide-exec-charset:                    Invocation.          (line 530)
+* fworking-directory:                    Invocation.          (line 548)
+* H:                                     Invocation.          (line 669)
+* help:                                  Invocation.          (line 661)
+* I:                                     Invocation.          (line  72)
+* I-:                                    Invocation.          (line 360)
+* idirafter:                             Invocation.          (line 402)
+* imacros:                               Invocation.          (line 393)
+* imultilib:                             Invocation.          (line 427)
+* include:                               Invocation.          (line 382)
+* iprefix:                               Invocation.          (line 409)
+* iquote:                                Invocation.          (line 439)
+* isysroot:                              Invocation.          (line 421)
+* isystem:                               Invocation.          (line 431)
+* iwithprefix:                           Invocation.          (line 415)
+* iwithprefixbefore:                     Invocation.          (line 415)
+* M:                                     Invocation.          (line 181)
+* MD:                                    Invocation.          (line 272)
+* MF:                                    Invocation.          (line 216)
+* MG:                                    Invocation.          (line 225)
+* MM:                                    Invocation.          (line 206)
+* MMD:                                   Invocation.          (line 288)
+* MP:                                    Invocation.          (line 235)
+* MQ:                                    Invocation.          (line 262)
+* MT:                                    Invocation.          (line 247)
+* nostdinc:                              Invocation.          (line 372)
+* nostdinc++:                            Invocation.          (line 377)
+* o:                                     Invocation.          (line  83)
+* OBJC_INCLUDE_PATH:                     Environment Variables.
+                                                              (line  18)
+* P:                                     Invocation.          (line 618)
+* pedantic:                              Invocation.          (line 171)
+* pedantic-errors:                       Invocation.          (line 176)
+* remap:                                 Invocation.          (line 656)
+* std=:                                  Invocation.          (line 311)
+* SUNPRO_DEPENDENCIES:                   Environment Variables.
+                                                              (line  60)
+* target-help:                           Invocation.          (line 661)
+* traditional-cpp:                       Invocation.          (line 649)
+* trigraphs:                             Invocation.          (line 653)
+* U:                                     Invocation.          (line  63)
+* undef:                                 Invocation.          (line  67)
+* v:                                     Invocation.          (line 665)
+* version:                               Invocation.          (line 677)
+* w:                                     Invocation.          (line 167)
+* Wall:                                  Invocation.          (line  89)
+* Wcomment:                              Invocation.          (line  97)
+* Wcomments:                             Invocation.          (line  97)
+* Wendif-labels:                         Invocation.          (line 144)
+* Werror:                                Invocation.          (line 157)
+* Wsystem-headers:                       Invocation.          (line 161)
+* Wtraditional:                          Invocation.          (line 114)
+* Wtrigraphs:                            Invocation.          (line 102)
+* Wundef:                                Invocation.          (line 120)
+* Wunused-macros:                        Invocation.          (line 125)
+* x:                                     Invocation.          (line 295)
+
+
+File: cpp.info,  Node: Concept Index,  Prev: Option Index,  Up: Top
+
+Concept Index
+*************
+
+
+* Menu:
+
+* '#' operator:                          Stringification.     (line   6)
+* '##' operator:                         Concatenation.       (line   6)
+* '_Pragma':                             Pragmas.             (line  25)
+* alternative tokens:                    Tokenization.        (line 105)
+* arguments:                             Macro Arguments.     (line   6)
+* arguments in macro definitions:        Macro Arguments.     (line   6)
+* assertions:                            Obsolete Features.   (line  13)
+* assertions, canceling:                 Obsolete Features.   (line  59)
+* backslash-newline:                     Initial processing.  (line  61)
+* block comments:                        Initial processing.  (line  77)
+* C++ named operators:                   C++ Named Operators. (line   6)
+* character constants:                   Tokenization.        (line  84)
+* character set, execution:              Invocation.          (line 525)
+* character set, input:                  Invocation.          (line 538)
+* character set, wide execution:         Invocation.          (line 530)
+* command line:                          Invocation.          (line   6)
+* commenting out code:                   Deleted Code.        (line   6)
+* comments:                              Initial processing.  (line  77)
+* common predefined macros:              Common Predefined Macros.
+                                                              (line   6)
+* computed includes:                     Computed Includes.   (line   6)
+* concatenation:                         Concatenation.       (line   6)
+* conditional group:                     Ifdef.               (line  14)
+* conditionals:                          Conditionals.        (line   6)
+* continued lines:                       Initial processing.  (line  61)
+* controlling macro:                     Once-Only Headers.   (line  35)
+* 'defined':                             Defined.             (line   6)
+* dependencies for make as output:       Environment Variables.
+                                                              (line  45)
+* dependencies for make as output <1>:   Environment Variables.
+                                                              (line  61)
+* dependencies, 'make':                  Invocation.          (line 181)
+* diagnostic:                            Diagnostics.         (line   6)
+* differences from previous versions:    Differences from previous versions.
+                                                              (line   6)
+* digraphs:                              Tokenization.        (line 105)
+* directive line:                        The preprocessing language.
+                                                              (line   6)
+* directive name:                        The preprocessing language.
+                                                              (line   6)
+* directives:                            The preprocessing language.
+                                                              (line   6)
+* empty macro arguments:                 Macro Arguments.     (line  66)
+* environment variables:                 Environment Variables.
+                                                              (line   6)
+* expansion of arguments:                Argument Prescan.    (line   6)
+* FDL, GNU Free Documentation License:   GNU Free Documentation License.
+                                                              (line   6)
+* function-like macros:                  Function-like Macros.
+                                                              (line   6)
+* grouping options:                      Invocation.          (line  34)
+* guard macro:                           Once-Only Headers.   (line  35)
+* header file:                           Header Files.        (line   6)
+* header file names:                     Tokenization.        (line  84)
+* identifiers:                           Tokenization.        (line  33)
+* implementation limits:                 Implementation limits.
+                                                              (line   6)
+* implementation-defined behavior:       Implementation-defined behavior.
+                                                              (line   6)
+* including just once:                   Once-Only Headers.   (line   6)
+* invocation:                            Invocation.          (line   6)
+* 'iso646.h':                            C++ Named Operators. (line   6)
+* line comments:                         Initial processing.  (line  77)
+* line control:                          Line Control.        (line   6)
+* line endings:                          Initial processing.  (line  14)
+* linemarkers:                           Preprocessor Output. (line  28)
+* macro argument expansion:              Argument Prescan.    (line   6)
+* macro arguments and directives:        Directives Within Macro Arguments.
+                                                              (line   6)
+* macros in include:                     Computed Includes.   (line   6)
+* macros with arguments:                 Macro Arguments.     (line   6)
+* macros with variable arguments:        Variadic Macros.     (line   6)
+* 'make':                                Invocation.          (line 181)
+* manifest constants:                    Object-like Macros.  (line   6)
+* named operators:                       C++ Named Operators. (line   6)
+* newlines in macro arguments:           Newlines in Arguments.
+                                                              (line   6)
+* null directive:                        Other Directives.    (line  15)
+* numbers:                               Tokenization.        (line  60)
+* object-like macro:                     Object-like Macros.  (line   6)
+* options:                               Invocation.          (line  39)
+* options, grouping:                     Invocation.          (line  34)
+* other tokens:                          Tokenization.        (line 119)
+* output format:                         Preprocessor Output. (line  12)
+* overriding a header file:              Wrapper Headers.     (line   6)
+* parentheses in macro bodies:           Operator Precedence Problems.
+                                                              (line   6)
+* pitfalls of macros:                    Macro Pitfalls.      (line   6)
+* predefined macros:                     Predefined Macros.   (line   6)
+* predefined macros, system-specific:    System-specific Predefined Macros.
+                                                              (line   6)
+* predicates:                            Obsolete Features.   (line  26)
+* preprocessing directives:              The preprocessing language.
+                                                              (line   6)
+* preprocessing numbers:                 Tokenization.        (line  60)
+* preprocessing tokens:                  Tokenization.        (line   6)
+* prescan of macro arguments:            Argument Prescan.    (line   6)
+* problems with macros:                  Macro Pitfalls.      (line   6)
+* punctuators:                           Tokenization.        (line 105)
+* redefining macros:                     Undefining and Redefining Macros.
+                                                              (line   6)
+* repeated inclusion:                    Once-Only Headers.   (line   6)
+* reporting errors:                      Diagnostics.         (line   6)
+* reporting warnings:                    Diagnostics.         (line   6)
+* reserved namespace:                    System-specific Predefined Macros.
+                                                              (line   6)
+* self-reference:                        Self-Referential Macros.
+                                                              (line   6)
+* semicolons (after macro calls):        Swallowing the Semicolon.
+                                                              (line   6)
+* side effects (in macro arguments):     Duplication of Side Effects.
+                                                              (line   6)
+* standard predefined macros.:           Standard Predefined Macros.
+                                                              (line   6)
+* string constants:                      Tokenization.        (line  84)
+* string literals:                       Tokenization.        (line  84)
+* stringification:                       Stringification.     (line   6)
+* symbolic constants:                    Object-like Macros.  (line   6)
+* system header files:                   Header Files.        (line  13)
+* system header files <1>:               System Headers.      (line   6)
+* system-specific predefined macros:     System-specific Predefined Macros.
+                                                              (line   6)
+* testing predicates:                    Obsolete Features.   (line  37)
+* token concatenation:                   Concatenation.       (line   6)
+* token pasting:                         Concatenation.       (line   6)
+* tokens:                                Tokenization.        (line   6)
+* trigraphs:                             Initial processing.  (line  32)
+* undefining macros:                     Undefining and Redefining Macros.
+                                                              (line   6)
+* unsafe macros:                         Duplication of Side Effects.
+                                                              (line   6)
+* variable number of arguments:          Variadic Macros.     (line   6)
+* variadic macros:                       Variadic Macros.     (line   6)
+* wrapper '#ifndef':                     Once-Only Headers.   (line   6)
+* wrapper headers:                       Wrapper Headers.     (line   6)
+
+
+
+Tag Table:
+Node: Top945
+Node: Overview3549
+Node: Character sets6383
+Ref: Character sets-Footnote-18564
+Node: Initial processing8745
+Ref: trigraphs10304
+Node: Tokenization14504
+Ref: Tokenization-Footnote-121638
+Node: The preprocessing language21749
+Node: Header Files24628
+Node: Include Syntax26544
+Node: Include Operation28181
+Node: Search Path30029
+Node: Once-Only Headers33230
+Node: Alternatives to Wrapper #ifndef34889
+Node: Computed Includes36631
+Node: Wrapper Headers39789
+Node: System Headers42212
+Node: Macros44262
+Node: Object-like Macros45403
+Node: Function-like Macros48993
+Node: Macro Arguments50609
+Node: Stringification54752
+Node: Concatenation57958
+Node: Variadic Macros61066
+Node: Predefined Macros65853
+Node: Standard Predefined Macros66441
+Node: Common Predefined Macros72410
+Node: System-specific Predefined Macros92190
+Node: C++ Named Operators94213
+Node: Undefining and Redefining Macros95177
+Node: Directives Within Macro Arguments97275
+Node: Macro Pitfalls98823
+Node: Misnesting99356
+Node: Operator Precedence Problems100468
+Node: Swallowing the Semicolon102334
+Node: Duplication of Side Effects104357
+Node: Self-Referential Macros106540
+Node: Argument Prescan108949
+Node: Newlines in Arguments112704
+Node: Conditionals113655
+Node: Conditional Uses115484
+Node: Conditional Syntax116842
+Node: Ifdef117162
+Node: If120319
+Node: Defined122623
+Node: Else123904
+Node: Elif124474
+Node: Deleted Code125763
+Node: Diagnostics127010
+Node: Line Control128559
+Node: Pragmas132334
+Node: Other Directives137088
+Node: Preprocessor Output138138
+Node: Traditional Mode141336
+Node: Traditional lexical analysis142394
+Node: Traditional macros144897
+Node: Traditional miscellany148698
+Node: Traditional warnings149694
+Node: Implementation Details151891
+Node: Implementation-defined behavior152512
+Ref: Identifier characters153262
+Node: Implementation limits156340
+Node: Obsolete Features159013
+Node: Differences from previous versions161900
+Node: Invocation166102
+Ref: Wtrigraphs170554
+Ref: dashMF175331
+Ref: fdollars-in-identifiers185073
+Node: Environment Variables194900
+Node: GNU Free Documentation License197866
+Node: Index of Directives223010
+Node: Option Index225090
+Node: Concept Index231493
+
+End Tag Table
diff --git a/gcc-4.9/gcc/doc/cppinternals.info b/gcc-4.9/gcc/doc/cppinternals.info
new file mode 100644
index 000000000..391787ef2
--- /dev/null
+++ b/gcc-4.9/gcc/doc/cppinternals.info
@@ -0,0 +1,1029 @@
+This is cppinternals.info, produced by makeinfo version 5.1 from
+cppinternals.texi.
+
+INFO-DIR-SECTION Software development
+START-INFO-DIR-ENTRY
+* Cpplib: (cppinternals).      Cpplib internals.
+END-INFO-DIR-ENTRY
+
+This file documents the internals of the GNU C Preprocessor.
+
+   Copyright (C) 2000-2014 Free Software Foundation, Inc.
+
+   Permission is granted to make and distribute verbatim copies of this
+manual provided the copyright notice and this permission notice are
+preserved on all copies.
+
+   Permission is granted to copy and distribute modified versions of
+this manual under the conditions for verbatim copying, provided also
+that the entire resulting derived work is distributed under the terms of
+a permission notice identical to this one.
+
+   Permission is granted to copy and distribute translations of this
+manual into another language, under the above conditions for modified
+versions.
+
+
+File: cppinternals.info,  Node: Top,  Next: Conventions,  Up: (dir)
+
+The GNU C Preprocessor Internals
+********************************
+
+1 Cpplib--the GNU C Preprocessor
+********************************
+
+The GNU C preprocessor is implemented as a library, "cpplib", so it can
+be easily shared between a stand-alone preprocessor, and a preprocessor
+integrated with the C, C++ and Objective-C front ends.  It is also
+available for use by other programs, though this is not recommended as
+its exposed interface has not yet reached a point of reasonable
+stability.
+
+   The library has been written to be re-entrant, so that it can be used
+to preprocess many files simultaneously if necessary.  It has also been
+written with the preprocessing token as the fundamental unit; the
+preprocessor in previous versions of GCC would operate on text strings
+as the fundamental unit.
+
+   This brief manual documents the internals of cpplib, and explains
+some of the tricky issues.  It is intended that, along with the comments
+in the source code, a reasonably competent C programmer should be able
+to figure out what the code is doing, and why things have been
+implemented the way they have.
+
+* Menu:
+
+* Conventions::         Conventions used in the code.
+* Lexer::               The combined C, C++ and Objective-C Lexer.
+* Hash Nodes::          All identifiers are entered into a hash table.
+* Macro Expansion::     Macro expansion algorithm.
+* Token Spacing::       Spacing and paste avoidance issues.
+* Line Numbering::      Tracking location within files.
+* Guard Macros::        Optimizing header files with guard macros.
+* Files::               File handling.
+* Concept Index::       Index.
+
+
+File: cppinternals.info,  Node: Conventions,  Next: Lexer,  Prev: Top,  Up: Top
+
+Conventions
+***********
+
+cpplib has two interfaces--one is exposed internally only, and the other
+is for both internal and external use.
+
+   The convention is that functions and types that are exposed to
+multiple files internally are prefixed with '_cpp_', and are to be found
+in the file 'internal.h'.  Functions and types exposed to external
+clients are in 'cpplib.h', and prefixed with 'cpp_'.  For historical
+reasons this is no longer quite true, but we should strive to stick to
+it.
+
+   We are striving to reduce the information exposed in 'cpplib.h' to
+the bare minimum necessary, and then to keep it there.  This makes clear
+exactly what external clients are entitled to assume, and allows us to
+change internals in the future without worrying whether library clients
+are perhaps relying on some kind of undocumented implementation-specific
+behavior.
+
+
+File: cppinternals.info,  Node: Lexer,  Next: Hash Nodes,  Prev: Conventions,  Up: Top
+
+The Lexer
+*********
+
+Overview
+========
+
+The lexer is contained in the file 'lex.c'.  It is a hand-coded lexer,
+and not implemented as a state machine.  It can understand C, C++ and
+Objective-C source code, and has been extended to allow reasonably
+successful preprocessing of assembly language.  The lexer does not make
+an initial pass to strip out trigraphs and escaped newlines, but handles
+them as they are encountered in a single pass of the input file.  It
+returns preprocessing tokens individually, not a line at a time.
+
+   It is mostly transparent to users of the library, since the library's
+interface for obtaining the next token, 'cpp_get_token', takes care of
+lexing new tokens, handling directives, and expanding macros as
+necessary.  However, the lexer does expose some functionality so that
+clients of the library can easily spell a given token, such as
+'cpp_spell_token' and 'cpp_token_len'.  These functions are useful when
+generating diagnostics, and for emitting the preprocessed output.
+
+Lexing a token
+==============
+
+Lexing of an individual token is handled by '_cpp_lex_direct' and its
+subroutines.  In its current form the code is quite complicated, with
+read ahead characters and such-like, since it strives to not step back
+in the character stream in preparation for handling non-ASCII file
+encodings.  The current plan is to convert any such files to UTF-8
+before processing them.  This complexity is therefore unnecessary and
+will be removed, so I'll not discuss it further here.
+
+   The job of '_cpp_lex_direct' is simply to lex a token.  It is not
+responsible for issues like directive handling, returning lookahead
+tokens directly, multiple-include optimization, or conditional block
+skipping.  It necessarily has a minor ro^le to play in memory management
+of lexed lines.  I discuss these issues in a separate section (*note
+Lexing a line::).
+
+   The lexer places the token it lexes into storage pointed to by the
+variable 'cur_token', and then increments it.  This variable is
+important for correct diagnostic positioning.  Unless a specific line
+and column are passed to the diagnostic routines, they will examine the
+'line' and 'col' values of the token just before the location that
+'cur_token' points to, and use that location to report the diagnostic.
+
+   The lexer does not consider whitespace to be a token in its own
+right.  If whitespace (other than a new line) precedes a token, it sets
+the 'PREV_WHITE' bit in the token's flags.  Each token has its 'line'
+and 'col' variables set to the line and column of the first character of
+the token.  This line number is the line number in the translation unit,
+and can be converted to a source (file, line) pair using the line map
+code.
+
+   The first token on a logical, i.e. unescaped, line has the flag 'BOL'
+set for beginning-of-line.  This flag is intended for internal use, both
+to distinguish a '#' that begins a directive from one that doesn't, and
+to generate a call-back to clients that want to be notified about the
+start of every non-directive line with tokens on it.  Clients cannot
+reliably determine this for themselves: the first token might be a
+macro, and the tokens of a macro expansion do not have the 'BOL' flag
+set.  The macro expansion may even be empty, and the next token on the
+line certainly won't have the 'BOL' flag set.
+
+   New lines are treated specially; exactly how the lexer handles them
+is context-dependent.  The C standard mandates that directives are
+terminated by the first unescaped newline character, even if it appears
+in the middle of a macro expansion.  Therefore, if the state variable
+'in_directive' is set, the lexer returns a 'CPP_EOF' token, which is
+normally used to indicate end-of-file, to indicate end-of-directive.  In
+a directive a 'CPP_EOF' token never means end-of-file.  Conveniently, if
+the caller was 'collect_args', it already handles 'CPP_EOF' as if it
+were end-of-file, and reports an error about an unterminated macro
+argument list.
+
+   The C standard also specifies that a new line in the middle of the
+arguments to a macro is treated as whitespace.  This white space is
+important in case the macro argument is stringified.  The state variable
+'parsing_args' is nonzero when the preprocessor is collecting the
+arguments to a macro call.  It is set to 1 when looking for the opening
+parenthesis to a function-like macro, and 2 when collecting the actual
+arguments up to the closing parenthesis, since these two cases need to
+be distinguished sometimes.  One such time is here: the lexer sets the
+'PREV_WHITE' flag of a token if it meets a new line when 'parsing_args'
+is set to 2.  It doesn't set it if it meets a new line when
+'parsing_args' is 1, since then code like
+
+     #define foo() bar
+     foo
+     baz
+
+would be output with an erroneous space before 'baz':
+
+     foo
+      baz
+
+   This is a good example of the subtlety of getting token spacing
+correct in the preprocessor; there are plenty of tests in the testsuite
+for corner cases like this.
+
+   The lexer is written to treat each of '\r', '\n', '\r\n' and '\n\r'
+as a single new line indicator.  This allows it to transparently
+preprocess MS-DOS, Macintosh and Unix files without their needing to
+pass through a special filter beforehand.
+
+   We also decided to treat a backslash, either '\' or the trigraph
+'??/', separated from one of the above newline indicators by non-comment
+whitespace only, as intending to escape the newline.  It tends to be a
+typing mistake, and cannot reasonably be mistaken for anything else in
+any of the C-family grammars.  Since handling it this way is not
+strictly conforming to the ISO standard, the library issues a warning
+wherever it encounters it.
+
+   Handling newlines like this is made simpler by doing it in one place
+only.  The function 'handle_newline' takes care of all newline
+characters, and 'skip_escaped_newlines' takes care of arbitrarily long
+sequences of escaped newlines, deferring to 'handle_newline' to handle
+the newlines themselves.
+
+   The most painful aspect of lexing ISO-standard C and C++ is handling
+trigraphs and backlash-escaped newlines.  Trigraphs are processed before
+any interpretation of the meaning of a character is made, and
+unfortunately there is a trigraph representation for a backslash, so it
+is possible for the trigraph '??/' to introduce an escaped newline.
+
+   Escaped newlines are tedious because theoretically they can occur
+anywhere--between the '+' and '=' of the '+=' token, within the
+characters of an identifier, and even between the '*' and '/' that
+terminates a comment.  Moreover, you cannot be sure there is just
+one--there might be an arbitrarily long sequence of them.
+
+   So, for example, the routine that lexes a number, 'parse_number',
+cannot assume that it can scan forwards until the first non-number
+character and be done with it, because this could be the '\' introducing
+an escaped newline, or the '?' introducing the trigraph sequence that
+represents the '\' of an escaped newline.  If it encounters a '?' or
+'\', it calls 'skip_escaped_newlines' to skip over any potential escaped
+newlines before checking whether the number has been finished.
+
+   Similarly code in the main body of '_cpp_lex_direct' cannot simply
+check for a '=' after a '+' character to determine whether it has a '+='
+token; it needs to be prepared for an escaped newline of some sort.
+Such cases use the function 'get_effective_char', which returns the
+first character after any intervening escaped newlines.
+
+   The lexer needs to keep track of the correct column position,
+including counting tabs as specified by the '-ftabstop=' option.  This
+should be done even within C-style comments; they can appear in the
+middle of a line, and we want to report diagnostics in the correct
+position for text appearing after the end of the comment.
+
+   Some identifiers, such as '__VA_ARGS__' and poisoned identifiers, may
+be invalid and require a diagnostic.  However, if they appear in a macro
+expansion we don't want to complain with each use of the macro.  It is
+therefore best to catch them during the lexing stage, in
+'parse_identifier'.  In both cases, whether a diagnostic is needed or
+not is dependent upon the lexer's state.  For example, we don't want to
+issue a diagnostic for re-poisoning a poisoned identifier, or for using
+'__VA_ARGS__' in the expansion of a variable-argument macro.  Therefore
+'parse_identifier' makes use of state flags to determine whether a
+diagnostic is appropriate.  Since we change state on a per-token basis,
+and don't lex whole lines at a time, this is not a problem.
+
+   Another place where state flags are used to change behavior is whilst
+lexing header names.  Normally, a '<' would be lexed as a single token.
+After a '#include' directive, though, it should be lexed as a single
+token as far as the nearest '>' character.  Note that we don't allow the
+terminators of header names to be escaped; the first '"' or '>'
+terminates the header name.
+
+   Interpretation of some character sequences depends upon whether we
+are lexing C, C++ or Objective-C, and on the revision of the standard in
+force.  For example, '::' is a single token in C++, but in C it is two
+separate ':' tokens and almost certainly a syntax error.  Such cases are
+handled by '_cpp_lex_direct' based upon command-line flags stored in the
+'cpp_options' structure.
+
+   Once a token has been lexed, it leads an independent existence.  The
+spelling of numbers, identifiers and strings is copied to permanent
+storage from the original input buffer, so a token remains valid and
+correct even if its source buffer is freed with '_cpp_pop_buffer'.  The
+storage holding the spellings of such tokens remains until the client
+program calls cpp_destroy, probably at the end of the translation unit.
+
+Lexing a line
+=============
+
+When the preprocessor was changed to return pointers to tokens, one
+feature I wanted was some sort of guarantee regarding how long a
+returned pointer remains valid.  This is important to the stand-alone
+preprocessor, the future direction of the C family front ends, and even
+to cpplib itself internally.
+
+   Occasionally the preprocessor wants to be able to peek ahead in the
+token stream.  For example, after the name of a function-like macro, it
+wants to check the next token to see if it is an opening parenthesis.
+Another example is that, after reading the first few tokens of a
+'#pragma' directive and not recognizing it as a registered pragma, it
+wants to backtrack and allow the user-defined handler for unknown
+pragmas to access the full '#pragma' token stream.  The stand-alone
+preprocessor wants to be able to test the current token with the
+previous one to see if a space needs to be inserted to preserve their
+separate tokenization upon re-lexing (paste avoidance), so it needs to
+be sure the pointer to the previous token is still valid.  The
+recursive-descent C++ parser wants to be able to perform tentative
+parsing arbitrarily far ahead in the token stream, and then to be able
+to jump back to a prior position in that stream if necessary.
+
+   The rule I chose, which is fairly natural, is to arrange that the
+preprocessor lex all tokens on a line consecutively into a token buffer,
+which I call a "token run", and when meeting an unescaped new line
+(newlines within comments do not count either), to start lexing back at
+the beginning of the run.  Note that we do _not_ lex a line of tokens at
+once; if we did that 'parse_identifier' would not have state flags
+available to warn about invalid identifiers (*note Invalid
+identifiers::).
+
+   In other words, accessing tokens that appeared earlier in the current
+line is valid, but since each logical line overwrites the tokens of the
+previous line, tokens from prior lines are unavailable.  In particular,
+since a directive only occupies a single logical line, this means that
+the directive handlers like the '#pragma' handler can jump around in the
+directive's tokens if necessary.
+
+   Two issues remain: what about tokens that arise from macro
+expansions, and what happens when we have a long line that overflows the
+token run?
+
+   Since we promise clients that we preserve the validity of pointers
+that we have already returned for tokens that appeared earlier in the
+line, we cannot reallocate the run.  Instead, on overflow it is expanded
+by chaining a new token run on to the end of the existing one.
+
+   The tokens forming a macro's replacement list are collected by the
+'#define' handler, and placed in storage that is only freed by
+'cpp_destroy'.  So if a macro is expanded in the line of tokens, the
+pointers to the tokens of its expansion that are returned will always
+remain valid.  However, macros are a little trickier than that, since
+they give rise to three sources of fresh tokens.  They are the built-in
+macros like '__LINE__', and the '#' and '##' operators for
+stringification and token pasting.  I handled this by allocating space
+for these tokens from the lexer's token run chain.  This means they
+automatically receive the same lifetime guarantees as lexed tokens, and
+we don't need to concern ourselves with freeing them.
+
+   Lexing into a line of tokens solves some of the token memory
+management issues, but not all.  The opening parenthesis after a
+function-like macro name might lie on a different line, and the front
+ends definitely want the ability to look ahead past the end of the
+current line.  So cpplib only moves back to the start of the token run
+at the end of a line if the variable 'keep_tokens' is zero.
+Line-buffering is quite natural for the preprocessor, and as a result
+the only time cpplib needs to increment this variable is whilst looking
+for the opening parenthesis to, and reading the arguments of, a
+function-like macro.  In the near future cpplib will export an interface
+to increment and decrement this variable, so that clients can share full
+control over the lifetime of token pointers too.
+
+   The routine '_cpp_lex_token' handles moving to new token runs,
+calling '_cpp_lex_direct' to lex new tokens, or returning
+previously-lexed tokens if we stepped back in the token stream.  It also
+checks each token for the 'BOL' flag, which might indicate a directive
+that needs to be handled, or require a start-of-line call-back to be
+made.  '_cpp_lex_token' also handles skipping over tokens in failed
+conditional blocks, and invalidates the control macro of the
+multiple-include optimization if a token was successfully lexed outside
+a directive.  In other words, its callers do not need to concern
+themselves with such issues.
+
+
+File: cppinternals.info,  Node: Hash Nodes,  Next: Macro Expansion,  Prev: Lexer,  Up: Top
+
+Hash Nodes
+**********
+
+When cpplib encounters an "identifier", it generates a hash code for it
+and stores it in the hash table.  By "identifier" we mean tokens with
+type 'CPP_NAME'; this includes identifiers in the usual C sense, as well
+as keywords, directive names, macro names and so on.  For example, all
+of 'pragma', 'int', 'foo' and '__GNUC__' are identifiers and hashed when
+lexed.
+
+   Each node in the hash table contain various information about the
+identifier it represents.  For example, its length and type.  At any one
+time, each identifier falls into exactly one of three categories:
+
+   * Macros
+
+     These have been declared to be macros, either on the command line
+     or with '#define'.  A few, such as '__TIME__' are built-ins entered
+     in the hash table during initialization.  The hash node for a
+     normal macro points to a structure with more information about the
+     macro, such as whether it is function-like, how many arguments it
+     takes, and its expansion.  Built-in macros are flagged as special,
+     and instead contain an enum indicating which of the various
+     built-in macros it is.
+
+   * Assertions
+
+     Assertions are in a separate namespace to macros.  To enforce this,
+     cpp actually prepends a '#' character before hashing and entering
+     it in the hash table.  An assertion's node points to a chain of
+     answers to that assertion.
+
+   * Void
+
+     Everything else falls into this category--an identifier that is not
+     currently a macro, or a macro that has since been undefined with
+     '#undef'.
+
+     When preprocessing C++, this category also includes the named
+     operators, such as 'xor'.  In expressions these behave like the
+     operators they represent, but in contexts where the spelling of a
+     token matters they are spelt differently.  This spelling
+     distinction is relevant when they are operands of the stringizing
+     and pasting macro operators '#' and '##'.  Named operator hash
+     nodes are flagged, both to catch the spelling distinction and to
+     prevent them from being defined as macros.
+
+   The same identifiers share the same hash node.  Since each identifier
+token, after lexing, contains a pointer to its hash node, this is used
+to provide rapid lookup of various information.  For example, when
+parsing a '#define' statement, CPP flags each argument's identifier hash
+node with the index of that argument.  This makes duplicated argument
+checking an O(1) operation for each argument.  Similarly, for each
+identifier in the macro's expansion, lookup to see if it is an argument,
+and which argument it is, is also an O(1) operation.  Further, each
+directive name, such as 'endif', has an associated directive enum stored
+in its hash node, so that directive lookup is also O(1).
+
+
+File: cppinternals.info,  Node: Macro Expansion,  Next: Token Spacing,  Prev: Hash Nodes,  Up: Top
+
+Macro Expansion Algorithm
+*************************
+
+Macro expansion is a tricky operation, fraught with nasty corner cases
+and situations that render what you thought was a nifty way to optimize
+the preprocessor's expansion algorithm wrong in quite subtle ways.
+
+   I strongly recommend you have a good grasp of how the C and C++
+standards require macros to be expanded before diving into this section,
+let alone the code!.  If you don't have a clear mental picture of how
+things like nested macro expansion, stringification and token pasting
+are supposed to work, damage to your sanity can quickly result.
+
+Internal representation of macros
+=================================
+
+The preprocessor stores macro expansions in tokenized form.  This saves
+repeated lexing passes during expansion, at the cost of a small increase
+in memory consumption on average.  The tokens are stored contiguously in
+memory, so a pointer to the first one and a token count is all you need
+to get the replacement list of a macro.
+
+   If the macro is a function-like macro the preprocessor also stores
+its parameters, in the form of an ordered list of pointers to the hash
+table entry of each parameter's identifier.  Further, in the macro's
+stored expansion each occurrence of a parameter is replaced with a
+special token of type 'CPP_MACRO_ARG'.  Each such token holds the index
+of the parameter it represents in the parameter list, which allows rapid
+replacement of parameters with their arguments during expansion.
+Despite this optimization it is still necessary to store the original
+parameters to the macro, both for dumping with e.g., '-dD', and to warn
+about non-trivial macro redefinitions when the parameter names have
+changed.
+
+Macro expansion overview
+========================
+
+The preprocessor maintains a "context stack", implemented as a linked
+list of 'cpp_context' structures, which together represent the macro
+expansion state at any one time.  The 'struct cpp_reader' member
+variable 'context' points to the current top of this stack.  The top
+normally holds the unexpanded replacement list of the innermost macro
+under expansion, except when cpplib is about to pre-expand an argument,
+in which case it holds that argument's unexpanded tokens.
+
+   When there are no macros under expansion, cpplib is in "base
+context".  All contexts other than the base context contain a contiguous
+list of tokens delimited by a starting and ending token.  When not in
+base context, cpplib obtains the next token from the list of the top
+context.  If there are no tokens left in the list, it pops that context
+off the stack, and subsequent ones if necessary, until an unexhausted
+context is found or it returns to base context.  In base context, cpplib
+reads tokens directly from the lexer.
+
+   If it encounters an identifier that is both a macro and enabled for
+expansion, cpplib prepares to push a new context for that macro on the
+stack by calling the routine 'enter_macro_context'.  When this routine
+returns, the new context will contain the unexpanded tokens of the
+replacement list of that macro.  In the case of function-like macros,
+'enter_macro_context' also replaces any parameters in the replacement
+list, stored as 'CPP_MACRO_ARG' tokens, with the appropriate macro
+argument.  If the standard requires that the parameter be replaced with
+its expanded argument, the argument will have been fully macro expanded
+first.
+
+   'enter_macro_context' also handles special macros like '__LINE__'.
+Although these macros expand to a single token which cannot contain any
+further macros, for reasons of token spacing (*note Token Spacing::) and
+simplicity of implementation, cpplib handles these special macros by
+pushing a context containing just that one token.
+
+   The final thing that 'enter_macro_context' does before returning is
+to mark the macro disabled for expansion (except for special macros like
+'__TIME__').  The macro is re-enabled when its context is later popped
+from the context stack, as described above.  This strict ordering
+ensures that a macro is disabled whilst its expansion is being scanned,
+but that it is _not_ disabled whilst any arguments to it are being
+expanded.
+
+Scanning the replacement list for macros to expand
+==================================================
+
+The C standard states that, after any parameters have been replaced with
+their possibly-expanded arguments, the replacement list is scanned for
+nested macros.  Further, any identifiers in the replacement list that
+are not expanded during this scan are never again eligible for expansion
+in the future, if the reason they were not expanded is that the macro in
+question was disabled.
+
+   Clearly this latter condition can only apply to tokens resulting from
+argument pre-expansion.  Other tokens never have an opportunity to be
+re-tested for expansion.  It is possible for identifiers that are
+function-like macros to not expand initially but to expand during a
+later scan.  This occurs when the identifier is the last token of an
+argument (and therefore originally followed by a comma or a closing
+parenthesis in its macro's argument list), and when it replaces its
+parameter in the macro's replacement list, the subsequent token happens
+to be an opening parenthesis (itself possibly the first token of an
+argument).
+
+   It is important to note that when cpplib reads the last token of a
+given context, that context still remains on the stack.  Only when
+looking for the _next_ token do we pop it off the stack and drop to a
+lower context.  This makes backing up by one token easy, but more
+importantly ensures that the macro corresponding to the current context
+is still disabled when we are considering the last token of its
+replacement list for expansion (or indeed expanding it).  As an example,
+which illustrates many of the points above, consider
+
+     #define foo(x) bar x
+     foo(foo) (2)
+
+which fully expands to 'bar foo (2)'.  During pre-expansion of the
+argument, 'foo' does not expand even though the macro is enabled, since
+it has no following parenthesis [pre-expansion of an argument only uses
+tokens from that argument; it cannot take tokens from whatever follows
+the macro invocation].  This still leaves the argument token 'foo'
+eligible for future expansion.  Then, when re-scanning after argument
+replacement, the token 'foo' is rejected for expansion, and marked
+ineligible for future expansion, since the macro is now disabled.  It is
+disabled because the replacement list 'bar foo' of the macro is still on
+the context stack.
+
+   If instead the algorithm looked for an opening parenthesis first and
+then tested whether the macro were disabled it would be subtly wrong.
+In the example above, the replacement list of 'foo' would be popped in
+the process of finding the parenthesis, re-enabling 'foo' and expanding
+it a second time.
+
+Looking for a function-like macro's opening parenthesis
+=======================================================
+
+Function-like macros only expand when immediately followed by a
+parenthesis.  To do this cpplib needs to temporarily disable macros and
+read the next token.  Unfortunately, because of spacing issues (*note
+Token Spacing::), there can be fake padding tokens in-between, and if
+the next real token is not a parenthesis cpplib needs to be able to back
+up that one token as well as retain the information in any intervening
+padding tokens.
+
+   Backing up more than one token when macros are involved is not
+permitted by cpplib, because in general it might involve issues like
+restoring popped contexts onto the context stack, which are too hard.
+Instead, searching for the parenthesis is handled by a special function,
+'funlike_invocation_p', which remembers padding information as it reads
+tokens.  If the next real token is not an opening parenthesis, it backs
+up that one token, and then pushes an extra context just containing the
+padding information if necessary.
+
+Marking tokens ineligible for future expansion
+==============================================
+
+As discussed above, cpplib needs a way of marking tokens as
+unexpandable.  Since the tokens cpplib handles are read-only once they
+have been lexed, it instead makes a copy of the token and adds the flag
+'NO_EXPAND' to the copy.
+
+   For efficiency and to simplify memory management by avoiding having
+to remember to free these tokens, they are allocated as temporary tokens
+from the lexer's current token run (*note Lexing a line::) using the
+function '_cpp_temp_token'.  The tokens are then re-used once the
+current line of tokens has been read in.
+
+   This might sound unsafe.  However, tokens runs are not re-used at the
+end of a line if it happens to be in the middle of a macro argument
+list, and cpplib only wants to back-up more than one lexer token in
+situations where no macro expansion is involved, so the optimization is
+safe.
+
+
+File: cppinternals.info,  Node: Token Spacing,  Next: Line Numbering,  Prev: Macro Expansion,  Up: Top
+
+Token Spacing
+*************
+
+First, consider an issue that only concerns the stand-alone
+preprocessor: there needs to be a guarantee that re-reading its
+preprocessed output results in an identical token stream.  Without
+taking special measures, this might not be the case because of macro
+substitution.  For example:
+
+     #define PLUS +
+     #define EMPTY
+     #define f(x) =x=
+     +PLUS -EMPTY- PLUS+ f(=)
+             ==> + + - - + + = = =
+     _not_
+             ==> ++ -- ++ ===
+
+   One solution would be to simply insert a space between all adjacent
+tokens.  However, we would like to keep space insertion to a minimum,
+both for aesthetic reasons and because it causes problems for people who
+still try to abuse the preprocessor for things like Fortran source and
+Makefiles.
+
+   For now, just notice that when tokens are added (or removed, as shown
+by the 'EMPTY' example) from the original lexed token stream, we need to
+check for accidental token pasting.  We call this "paste avoidance".
+Token addition and removal can only occur because of macro expansion,
+but accidental pasting can occur in many places: both before and after
+each macro replacement, each argument replacement, and additionally each
+token created by the '#' and '##' operators.
+
+   Look at how the preprocessor gets whitespace output correct normally.
+The 'cpp_token' structure contains a flags byte, and one of those flags
+is 'PREV_WHITE'.  This is flagged by the lexer, and indicates that the
+token was preceded by whitespace of some form other than a new line.
+The stand-alone preprocessor can use this flag to decide whether to
+insert a space between tokens in the output.
+
+   Now consider the result of the following macro expansion:
+
+     #define add(x, y, z) x + y +z;
+     sum = add (1,2, 3);
+             ==> sum = 1 + 2 +3;
+
+   The interesting thing here is that the tokens '1' and '2' are output
+with a preceding space, and '3' is output without a preceding space, but
+when lexed none of these tokens had that property.  Careful
+consideration reveals that '1' gets its preceding whitespace from the
+space preceding 'add' in the macro invocation, _not_ replacement list.
+'2' gets its whitespace from the space preceding the parameter 'y' in
+the macro replacement list, and '3' has no preceding space because
+parameter 'z' has none in the replacement list.
+
+   Once lexed, tokens are effectively fixed and cannot be altered, since
+pointers to them might be held in many places, in particular by
+in-progress macro expansions.  So instead of modifying the two tokens
+above, the preprocessor inserts a special token, which I call a "padding
+token", into the token stream to indicate that spacing of the subsequent
+token is special.  The preprocessor inserts padding tokens in front of
+every macro expansion and expanded macro argument.  These point to a
+"source token" from which the subsequent real token should inherit its
+spacing.  In the above example, the source tokens are 'add' in the macro
+invocation, and 'y' and 'z' in the macro replacement list, respectively.
+
+   It is quite easy to get multiple padding tokens in a row, for example
+if a macro's first replacement token expands straight into another
+macro.
+
+     #define foo bar
+     #define bar baz
+     [foo]
+             ==> [baz]
+
+   Here, two padding tokens are generated with sources the 'foo' token
+between the brackets, and the 'bar' token from foo's replacement list,
+respectively.  Clearly the first padding token is the one to use, so the
+output code should contain a rule that the first padding token in a
+sequence is the one that matters.
+
+   But what if a macro expansion is left?  Adjusting the above example
+slightly:
+
+     #define foo bar
+     #define bar EMPTY baz
+     #define EMPTY
+     [foo] EMPTY;
+             ==> [ baz] ;
+
+   As shown, now there should be a space before 'baz' and the semicolon
+in the output.
+
+   The rules we decided above fail for 'baz': we generate three padding
+tokens, one per macro invocation, before the token 'baz'.  We would then
+have it take its spacing from the first of these, which carries source
+token 'foo' with no leading space.
+
+   It is vital that cpplib get spacing correct in these examples since
+any of these macro expansions could be stringified, where spacing
+matters.
+
+   So, this demonstrates that not just entering macro and argument
+expansions, but leaving them requires special handling too.  I made
+cpplib insert a padding token with a 'NULL' source token when leaving
+macro expansions, as well as after each replaced argument in a macro's
+replacement list.  It also inserts appropriate padding tokens on either
+side of tokens created by the '#' and '##' operators.  I expanded the
+rule so that, if we see a padding token with a 'NULL' source token,
+_and_ that source token has no leading space, then we behave as if we
+have seen no padding tokens at all.  A quick check shows this rule will
+then get the above example correct as well.
+
+   Now a relationship with paste avoidance is apparent: we have to be
+careful about paste avoidance in exactly the same locations we have
+padding tokens in order to get white space correct.  This makes
+implementation of paste avoidance easy: wherever the stand-alone
+preprocessor is fixing up spacing because of padding tokens, and it
+turns out that no space is needed, it has to take the extra step to
+check that a space is not needed after all to avoid an accidental paste.
+The function 'cpp_avoid_paste' advises whether a space is required
+between two consecutive tokens.  To avoid excessive spacing, it tries
+hard to only require a space if one is likely to be necessary, but for
+reasons of efficiency it is slightly conservative and might recommend a
+space where one is not strictly needed.
+
+
+File: cppinternals.info,  Node: Line Numbering,  Next: Guard Macros,  Prev: Token Spacing,  Up: Top
+
+Line numbering
+**************
+
+Just which line number anyway?
+==============================
+
+There are three reasonable requirements a cpplib client might have for
+the line number of a token passed to it:
+
+   * The source line it was lexed on.
+   * The line it is output on.  This can be different to the line it was
+     lexed on if, for example, there are intervening escaped newlines or
+     C-style comments.  For example:
+
+          foo /* A long
+          comment */ bar \
+          baz
+          =>
+          foo bar baz
+
+   * If the token results from a macro expansion, the line of the macro
+     name, or possibly the line of the closing parenthesis in the case
+     of function-like macro expansion.
+
+   The 'cpp_token' structure contains 'line' and 'col' members.  The
+lexer fills these in with the line and column of the first character of
+the token.  Consequently, but maybe unexpectedly, a token from the
+replacement list of a macro expansion carries the location of the token
+within the '#define' directive, because cpplib expands a macro by
+returning pointers to the tokens in its replacement list.  The current
+implementation of cpplib assigns tokens created from built-in macros and
+the '#' and '##' operators the location of the most recently lexed
+token.  This is a because they are allocated from the lexer's token
+runs, and because of the way the diagnostic routines infer the
+appropriate location to report.
+
+   The diagnostic routines in cpplib display the location of the most
+recently _lexed_ token, unless they are passed a specific line and
+column to report.  For diagnostics regarding tokens that arise from
+macro expansions, it might also be helpful for the user to see the
+original location in the macro definition that the token came from.
+Since that is exactly the information each token carries, such an
+enhancement could be made relatively easily in future.
+
+   The stand-alone preprocessor faces a similar problem when determining
+the correct line to output the token on: the position attached to a
+token is fairly useless if the token came from a macro expansion.  All
+tokens on a logical line should be output on its first physical line, so
+the token's reported location is also wrong if it is part of a physical
+line other than the first.
+
+   To solve these issues, cpplib provides a callback that is generated
+whenever it lexes a preprocessing token that starts a new logical line
+other than a directive.  It passes this token (which may be a 'CPP_EOF'
+token indicating the end of the translation unit) to the callback
+routine, which can then use the line and column of this token to produce
+correct output.
+
+Representation of line numbers
+==============================
+
+As mentioned above, cpplib stores with each token the line number that
+it was lexed on.  In fact, this number is not the number of the line in
+the source file, but instead bears more resemblance to the number of the
+line in the translation unit.
+
+   The preprocessor maintains a monotonic increasing line count, which
+is incremented at every new line character (and also at the end of any
+buffer that does not end in a new line).  Since a line number of zero is
+useful to indicate certain special states and conditions, this variable
+starts counting from one.
+
+   This variable therefore uniquely enumerates each line in the
+translation unit.  With some simple infrastructure, it is straight
+forward to map from this to the original source file and line number
+pair, saving space whenever line number information needs to be saved.
+The code the implements this mapping lies in the files 'line-map.c' and
+'line-map.h'.
+
+   Command-line macros and assertions are implemented by pushing a
+buffer containing the right hand side of an equivalent '#define' or
+'#assert' directive.  Some built-in macros are handled similarly.  Since
+these are all processed before the first line of the main input file, it
+will typically have an assigned line closer to twenty than to one.
+
+
+File: cppinternals.info,  Node: Guard Macros,  Next: Files,  Prev: Line Numbering,  Up: Top
+
+The Multiple-Include Optimization
+*********************************
+
+Header files are often of the form
+
+     #ifndef FOO
+     #define FOO
+     ...
+     #endif
+
+to prevent the compiler from processing them more than once.  The
+preprocessor notices such header files, so that if the header file
+appears in a subsequent '#include' directive and 'FOO' is defined, then
+it is ignored and it doesn't preprocess or even re-open the file a
+second time.  This is referred to as the "multiple include
+optimization".
+
+   Under what circumstances is such an optimization valid?  If the file
+were included a second time, it can only be optimized away if that
+inclusion would result in no tokens to return, and no relevant
+directives to process.  Therefore the current implementation imposes
+requirements and makes some allowances as follows:
+
+  1. There must be no tokens outside the controlling '#if'-'#endif'
+     pair, but whitespace and comments are permitted.
+
+  2. There must be no directives outside the controlling directive pair,
+     but the "null directive" (a line containing nothing other than a
+     single '#' and possibly whitespace) is permitted.
+
+  3. The opening directive must be of the form
+
+          #ifndef FOO
+
+     or
+
+          #if !defined FOO     [equivalently, #if !defined(FOO)]
+
+  4. In the second form above, the tokens forming the '#if' expression
+     must have come directly from the source file--no macro expansion
+     must have been involved.  This is because macro definitions can
+     change, and tracking whether or not a relevant change has been made
+     is not worth the implementation cost.
+
+  5. There can be no '#else' or '#elif' directives at the outer
+     conditional block level, because they would probably contain
+     something of interest to a subsequent pass.
+
+   First, when pushing a new file on the buffer stack,
+'_stack_include_file' sets the controlling macro 'mi_cmacro' to 'NULL',
+and sets 'mi_valid' to 'true'.  This indicates that the preprocessor has
+not yet encountered anything that would invalidate the multiple-include
+optimization.  As described in the next few paragraphs, these two
+variables having these values effectively indicates top-of-file.
+
+   When about to return a token that is not part of a directive,
+'_cpp_lex_token' sets 'mi_valid' to 'false'.  This enforces the
+constraint that tokens outside the controlling conditional block
+invalidate the optimization.
+
+   The 'do_if', when appropriate, and 'do_ifndef' directive handlers
+pass the controlling macro to the function 'push_conditional'.  cpplib
+maintains a stack of nested conditional blocks, and after processing
+every opening conditional this function pushes an 'if_stack' structure
+onto the stack.  In this structure it records the controlling macro for
+the block, provided there is one and we're at top-of-file (as described
+above).  If an '#elif' or '#else' directive is encountered, the
+controlling macro for that block is cleared to 'NULL'.  Otherwise, it
+survives until the '#endif' closing the block, upon which 'do_endif'
+sets 'mi_valid' to true and stores the controlling macro in 'mi_cmacro'.
+
+   '_cpp_handle_directive' clears 'mi_valid' when processing any
+directive other than an opening conditional and the null directive.
+With this, and requiring top-of-file to record a controlling macro, and
+no '#else' or '#elif' for it to survive and be copied to 'mi_cmacro' by
+'do_endif', we have enforced the absence of directives outside the main
+conditional block for the optimization to be on.
+
+   Note that whilst we are inside the conditional block, 'mi_valid' is
+likely to be reset to 'false', but this does not matter since the
+closing '#endif' restores it to 'true' if appropriate.
+
+   Finally, since '_cpp_lex_direct' pops the file off the buffer stack
+at 'EOF' without returning a token, if the '#endif' directive was not
+followed by any tokens, 'mi_valid' is 'true' and '_cpp_pop_file_buffer'
+remembers the controlling macro associated with the file.  Subsequent
+calls to 'stack_include_file' result in no buffer being pushed if the
+controlling macro is defined, effecting the optimization.
+
+   A quick word on how we handle the
+
+     #if !defined FOO
+
+case.  '_cpp_parse_expr' and 'parse_defined' take steps to see whether
+the three stages '!', 'defined-expression' and 'end-of-directive' occur
+in order in a '#if' expression.  If so, they return the guard macro to
+'do_if' in the variable 'mi_ind_cmacro', and otherwise set it to 'NULL'.
+'enter_macro_context' sets 'mi_valid' to false, so if a macro was
+expanded whilst parsing any part of the expression, then the top-of-file
+test in 'push_conditional' fails and the optimization is turned off.
+
+
+File: cppinternals.info,  Node: Files,  Next: Concept Index,  Prev: Guard Macros,  Up: Top
+
+File Handling
+*************
+
+Fairly obviously, the file handling code of cpplib resides in the file
+'files.c'.  It takes care of the details of file searching, opening,
+reading and caching, for both the main source file and all the headers
+it recursively includes.
+
+   The basic strategy is to minimize the number of system calls.  On
+many systems, the basic 'open ()' and 'fstat ()' system calls can be
+quite expensive.  For every '#include'-d file, we need to try all the
+directories in the search path until we find a match.  Some projects,
+such as glibc, pass twenty or thirty include paths on the command line,
+so this can rapidly become time consuming.
+
+   For a header file we have not encountered before we have little
+choice but to do this.  However, it is often the case that the same
+headers are repeatedly included, and in these cases we try to avoid
+repeating the filesystem queries whilst searching for the correct file.
+
+   For each file we try to open, we store the constructed path in a
+splay tree.  This path first undergoes simplification by the function
+'_cpp_simplify_pathname'.  For example, '/usr/include/bits/../foo.h' is
+simplified to '/usr/include/foo.h' before we enter it in the splay tree
+and try to 'open ()' the file.  CPP will then find subsequent uses of
+'foo.h', even as '/usr/include/foo.h', in the splay tree and save system
+calls.
+
+   Further, it is likely the file contents have also been cached, saving
+a 'read ()' system call.  We don't bother caching the contents of header
+files that are re-inclusion protected, and whose re-inclusion macro is
+defined when we leave the header file for the first time.  If the host
+supports it, we try to map suitably large files into memory, rather than
+reading them in directly.
+
+   The include paths are internally stored on a null-terminated
+singly-linked list, starting with the '"header.h"' directory search
+chain, which then links into the '<header.h>' directory chain.
+
+   Files included with the '<foo.h>' syntax start the lookup directly in
+the second half of this chain.  However, files included with the
+'"foo.h"' syntax start at the beginning of the chain, but with one extra
+directory prepended.  This is the directory of the current file; the one
+containing the '#include' directive.  Prepending this directory on a
+per-file basis is handled by the function 'search_from'.
+
+   Note that a header included with a directory component, such as
+'#include "mydir/foo.h"' and opened as '/usr/local/include/mydir/foo.h',
+will have the complete path minus the basename 'foo.h' as the current
+directory.
+
+   Enough information is stored in the splay tree that CPP can
+immediately tell whether it can skip the header file because of the
+multiple include optimization, whether the file didn't exist or couldn't
+be opened for some reason, or whether the header was flagged not to be
+re-used, as it is with the obsolete '#import' directive.
+
+   For the benefit of MS-DOS filesystems with an 8.3 filename
+limitation, CPP offers the ability to treat various include file names
+as aliases for the real header files with shorter names.  The map from
+one to the other is found in a special file called 'header.gcc', stored
+in the command line (or system) include directories to which the mapping
+applies.  This may be higher up the directory tree than the full path to
+the file minus the base name.
+
+
+File: cppinternals.info,  Node: Concept Index,  Prev: Files,  Up: Top
+
+Concept Index
+*************
+
+
+* Menu:
+
+* assertions:                            Hash Nodes.          (line   6)
+* controlling macros:                    Guard Macros.        (line   6)
+* escaped newlines:                      Lexer.               (line   5)
+* files:                                 Files.               (line   6)
+* guard macros:                          Guard Macros.        (line   6)
+* hash table:                            Hash Nodes.          (line   6)
+* header files:                          Conventions.         (line   6)
+* identifiers:                           Hash Nodes.          (line   6)
+* interface:                             Conventions.         (line   6)
+* lexer:                                 Lexer.               (line   6)
+* line numbers:                          Line Numbering.      (line   5)
+* macro expansion:                       Macro Expansion.     (line   6)
+* macro representation (internal):       Macro Expansion.     (line  19)
+* macros:                                Hash Nodes.          (line   6)
+* multiple-include optimization:         Guard Macros.        (line   6)
+* named operators:                       Hash Nodes.          (line   6)
+* newlines:                              Lexer.               (line   6)
+* paste avoidance:                       Token Spacing.       (line   6)
+* spacing:                               Token Spacing.       (line   6)
+* token run:                             Lexer.               (line 191)
+* token spacing:                         Token Spacing.       (line   6)
+
+
+
+Tag Table:
+Node: Top905
+Node: Conventions2590
+Node: Lexer3532
+Ref: Invalid identifiers11447
+Ref: Lexing a line13397
+Node: Hash Nodes18170
+Node: Macro Expansion21049
+Node: Token Spacing29997
+Node: Line Numbering35854
+Node: Guard Macros39939
+Node: Files44730
+Node: Concept Index48196
+
+End Tag Table
diff --git a/gcc-4.9/gcc/doc/extend.texi b/gcc-4.9/gcc/doc/extend.texi
index 986cc94e3..347a94a3a 100644
--- a/gcc-4.9/gcc/doc/extend.texi
+++ b/gcc-4.9/gcc/doc/extend.texi
@@ -1592,6 +1592,18 @@ Jumping or breaking out of the scope of the array name deallocates the
 storage.  Jumping into the scope is not allowed; you get an error
 message for it.
 
+@cindex variable-length array in a structure
+As an extension, GCC accepts variable-length arrays as a member of
+a structure or a union.  For example:
+
+@smallexample
+void
+foo (int n)
+@{
+  struct S @{ int x[n]; @};
+@}
+@end smallexample
+
 @cindex @code{alloca} vs variable-length arrays
 You can use the function @code{alloca} to get an effect much like
 variable-length arrays.  The function @code{alloca} is available in
@@ -1967,6 +1979,9 @@ Another syntax that has the same meaning, obsolete since GCC 2.5, is
 struct point p = @{ y: yvalue, x: xvalue @};
 @end smallexample
 
+Omitted field members are implicitly initialized the same as objects
+that have static storage duration.
+
 @cindex designators
 The @samp{[@var{index}]} or @samp{.@var{fieldname}} is known as a
 @dfn{designator}.  You can also use a designator (or the obsolete colon
@@ -6343,7 +6358,7 @@ int foo ()
   int *y = &x;
   int result;
   asm ("magic stuff accessing an 'int' pointed to by '%1'"
-       : "=&d" (r) : "a" (y), "m" (*y));
+       : "=&d" (result) : "a" (y), "m" (*y));
   return result;
 @}
 @end smallexample
@@ -8963,7 +8978,7 @@ Similar to @code{__builtin_nans}, except the return type is @code{float}.
 Similar to @code{__builtin_nans}, except the return type is @code{long double}.
 @end deftypefn
 
-@deftypefn {Built-in Function} int __builtin_ffs (unsigned int x)
+@deftypefn {Built-in Function} int __builtin_ffs (int x)
 Returns one plus the index of the least significant 1-bit of @var{x}, or
 if @var{x} is zero, returns zero.
 @end deftypefn
@@ -8993,9 +9008,9 @@ Returns the parity of @var{x}, i.e.@: the number of 1-bits in @var{x}
 modulo 2.
 @end deftypefn
 
-@deftypefn {Built-in Function} int __builtin_ffsl (unsigned long)
+@deftypefn {Built-in Function} int __builtin_ffsl (long)
 Similar to @code{__builtin_ffs}, except the argument type is
-@code{unsigned long}.
+@code{long}.
 @end deftypefn
 
 @deftypefn {Built-in Function} int __builtin_clzl (unsigned long)
@@ -9023,9 +9038,9 @@ Similar to @code{__builtin_parity}, except the argument type is
 @code{unsigned long}.
 @end deftypefn
 
-@deftypefn {Built-in Function} int __builtin_ffsll (unsigned long long)
+@deftypefn {Built-in Function} int __builtin_ffsll (long long)
 Similar to @code{__builtin_ffs}, except the argument type is
-@code{unsigned long long}.
+@code{long long}.
 @end deftypefn
 
 @deftypefn {Built-in Function} int __builtin_clzll (unsigned long long)
@@ -14844,6 +14859,35 @@ void vec_vsx_st (vector unsigned char, int, unsigned char *);
 void vec_vsx_st (vector bool char, int, vector bool char *);
 void vec_vsx_st (vector bool char, int, unsigned char *);
 void vec_vsx_st (vector bool char, int, signed char *);
+
+vector double vec_xxpermdi (vector double, vector double, int);
+vector float vec_xxpermdi (vector float, vector float, int);
+vector long long vec_xxpermdi (vector long long, vector long long, int);
+vector unsigned long long vec_xxpermdi (vector unsigned long long,
+                                        vector unsigned long long, int);
+vector int vec_xxpermdi (vector int, vector int, int);
+vector unsigned int vec_xxpermdi (vector unsigned int,
+                                  vector unsigned int, int);
+vector short vec_xxpermdi (vector short, vector short, int);
+vector unsigned short vec_xxpermdi (vector unsigned short,
+                                    vector unsigned short, int);
+vector signed char vec_xxpermdi (vector signed char, vector signed char, int);
+vector unsigned char vec_xxpermdi (vector unsigned char,
+                                   vector unsigned char, int);
+
+vector double vec_xxsldi (vector double, vector double, int);
+vector float vec_xxsldi (vector float, vector float, int);
+vector long long vec_xxsldi (vector long long, vector long long, int);
+vector unsigned long long vec_xxsldi (vector unsigned long long,
+                                      vector unsigned long long, int);
+vector int vec_xxsldi (vector int, vector int, int);
+vector unsigned int vec_xxsldi (vector unsigned int, vector unsigned int, int);
+vector short vec_xxsldi (vector short, vector short, int);
+vector unsigned short vec_xxsldi (vector unsigned short,
+                                  vector unsigned short, int);
+vector signed char vec_xxsldi (vector signed char, vector signed char, int);
+vector unsigned char vec_xxsldi (vector unsigned char,
+                                 vector unsigned char, int);
 @end smallexample
 
 Note that the @samp{vec_ld} and @samp{vec_st} built-in functions always
@@ -15031,6 +15075,9 @@ vector unsigned long long vec_vaddudm (vector bool unsigned long long,
 vector unsigned long long vec_vaddudm (vector unsigned long long,
                                        vector bool unsigned long long);
 
+vector long long vec_vbpermq (vector signed char, vector signed char);
+vector long long vec_vbpermq (vector unsigned char, vector unsigned char);
+
 vector long long vec_vclz (vector long long);
 vector unsigned long long vec_vclz (vector unsigned long long);
 vector int vec_vclz (vector int);
@@ -15052,6 +15099,9 @@ vector unsigned short vec_vclzh (vector unsigned short);
 vector int vec_vclzw (vector int);
 vector unsigned int vec_vclzw (vector int);
 
+vector signed char vec_vgbbd (vector signed char);
+vector unsigned char vec_vgbbd (vector unsigned char);
+
 vector long long vec_vmaxsd (vector long long, vector long long);
 
 vector unsigned long long vec_vmaxud (vector unsigned long long,
@@ -17495,6 +17545,10 @@ unimportant.
 A redeclaration of a function or class must not add new ABI tags,
 since doing so would change the mangled name.
 
+The ABI tags apply to a name, so all instantiations and
+specializations of a template have the same tags.  The attribute will
+be ignored if applied to an explicit specialization or instantiation.
+
 The @option{-Wabi-tag} flag enables a warning about a class which does
 not have all the ABI tags used by its subobjects and virtual functions; for users with code
 that needs to coexist with an earlier ABI, using this option can help
diff --git a/gcc-4.9/gcc/doc/fsf-funding.7 b/gcc-4.9/gcc/doc/fsf-funding.7
new file mode 100644
index 000000000..9e91dee51
--- /dev/null
+++ b/gcc-4.9/gcc/doc/fsf-funding.7
@@ -0,0 +1,193 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "FSF-FUNDING 7"
+.TH FSF-FUNDING 7 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+fsf\-funding \- Funding Free Software
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+.SS "Funding Free Software"
+.IX Subsection "Funding Free Software"
+If you want to have more free software a few years from now, it makes
+sense for you to help encourage people to contribute funds for its
+development.  The most effective approach known is to encourage
+commercial redistributors to donate.
+.PP
+Users of free software systems can boost the pace of development by
+encouraging for-a-fee distributors to donate part of their selling price
+to free software developers\-\-\-the Free Software Foundation, and others.
+.PP
+The way to convince distributors to do this is to demand it and expect
+it from them.  So when you compare distributors, judge them partly by
+how much they give to free software development.  Show distributors
+they must compete to be the one who gives the most.
+.PP
+To make this approach work, you must insist on numbers that you can
+compare, such as, \*(L"We will donate ten dollars to the Frobnitz project
+for each disk sold.\*(R"  Don't be satisfied with a vague promise, such as
+\&\*(L"A portion of the profits are donated,\*(R" since it doesn't give a basis
+for comparison.
+.PP
+Even a precise fraction \*(L"of the profits from this disk\*(R" is not very
+meaningful, since creative accounting and unrelated business decisions
+can greatly alter what fraction of the sales price counts as profit.
+If the price you pay is \f(CW$50\fR, ten percent of the profit is probably
+less than a dollar; it might be a few cents, or nothing at all.
+.PP
+Some redistributors do development work themselves.  This is useful too;
+but to keep everyone honest, you need to inquire how much they do, and
+what kind.  Some kinds of development make much more long-term
+difference than others.  For example, maintaining a separate version of
+a program contributes very little; maintaining the standard version of a
+program for the whole community contributes much.  Easy new ports
+contribute little, since someone else would surely do them; difficult
+ports such as adding a new \s-1CPU\s0 to the \s-1GNU\s0 Compiler Collection contribute more;
+major new features or packages contribute the most.
+.PP
+By establishing the idea that supporting further development is \*(L"the
+proper thing to do\*(R" when distributing free software for a fee, we can
+assure a steady flow of resources into making more free software.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7).
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 1994 Free Software Foundation, Inc.
+Verbatim copying and redistribution of this section is permitted
+without royalty; alteration is not permitted.
diff --git a/gcc-4.9/gcc/doc/g++.1 b/gcc-4.9/gcc/doc/g++.1
new file mode 100644
index 000000000..1ed57fcbb
--- /dev/null
+++ b/gcc-4.9/gcc/doc/g++.1
@@ -0,0 +1,21501 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GCC 1"
+.TH GCC 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gcc \- GNU project C and C++ compiler
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+gcc [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR] [\fB\-std=\fR\fIstandard\fR]
+    [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
+    [\fB\-W\fR\fIwarn\fR...] [\fB\-Wpedantic\fR]
+    [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
+    [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
+    [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine-option\fR...]
+    [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
+.PP
+Only the most useful options are listed here; see below for the
+remainder.  \fBg++\fR accepts mostly the same options as \fBgcc\fR.
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+When you invoke \s-1GCC,\s0 it normally does preprocessing, compilation,
+assembly and linking.  The \*(L"overall options\*(R" allow you to stop this
+process at an intermediate stage.  For example, the \fB\-c\fR option
+says not to run the linker.  Then the output consists of object files
+output by the assembler.
+.PP
+Other options are passed on to one stage of processing.  Some options
+control the preprocessor and others the compiler itself.  Yet other
+options control the assembler and linker; most of these are not
+documented here, since you rarely need to use any of them.
+.PP
+Most of the command-line options that you can use with \s-1GCC\s0 are useful
+for C programs; when an option is only useful with another language
+(usually \*(C+), the explanation says so explicitly.  If the description
+for a particular option does not mention a source language, you can use
+that option with all supported languages.
+.PP
+The \fBgcc\fR program accepts options and file names as operands.  Many
+options have multi-letter names; therefore multiple single-letter options
+may \fInot\fR be grouped: \fB\-dv\fR is very different from \fB\-d\ \-v\fR.
+.PP
+You can mix options and other arguments.  For the most part, the order
+you use doesn't matter.  Order does matter when you use several
+options of the same kind; for example, if you specify \fB\-L\fR more
+than once, the directories are searched in the order specified.  Also,
+the placement of the \fB\-l\fR option is significant.
+.PP
+Many options have long names starting with \fB\-f\fR or with
+\&\fB\-W\fR\-\-\-for example,
+\&\fB\-fmove\-loop\-invariants\fR, \fB\-Wformat\fR and so on.  Most of
+these have both positive and negative forms; the negative form of
+\&\fB\-ffoo\fR is \fB\-fno\-foo\fR.  This manual documents
+only one of these two forms, whichever one is not the default.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.SS "Option Summary"
+.IX Subsection "Option Summary"
+Here is a summary of all the options, grouped by type.  Explanations are
+in the following sections.
+.IP "\fIOverall Options\fR" 4
+.IX Item "Overall Options"
+\&\fB\-c  \-S  \-E  \-o\fR \fIfile\fR  \fB\-no\-canonical\-prefixes  
+\&\-pipe  \-pass\-exit\-codes  
+\&\-x\fR \fIlanguage\fR  \fB\-v  \-###  \-\-help\fR[\fB=\fR\fIclass\fR[\fB,...\fR]]  \fB\-\-target\-help  
+\&\-\-version \-wrapper @\fR\fIfile\fR \fB\-fplugin=\fR\fIfile\fR \fB\-fplugin\-arg\-\fR\fIname\fR\fB=\fR\fIarg\fR  
+\&\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] \fB\-fada\-spec\-parent=\fR\fIunit\fR \fB\-fdump\-go\-spec=\fR\fIfile\fR
+.IP "\fIC Language Options\fR" 4
+.IX Item "C Language Options"
+\&\fB\-ansi  \-std=\fR\fIstandard\fR  \fB\-fgnu89\-inline 
+\&\-aux\-info\fR \fIfilename\fR \fB\-fallow\-parameterless\-variadic\-functions 
+\&\-fno\-asm  \-fno\-builtin  \-fno\-builtin\-\fR\fIfunction\fR 
+\&\fB\-fhosted  \-ffreestanding \-fopenmp \-fopenmp\-simd \-fms\-extensions 
+\&\-fplan9\-extensions \-trigraphs  \-traditional  \-traditional\-cpp 
+\&\-fallow\-single\-precision  \-fcond\-mismatch \-flax\-vector\-conversions 
+\&\-fsigned\-bitfields  \-fsigned\-char 
+\&\-funsigned\-bitfields  \-funsigned\-char\fR
+.IP "\fI\*(C+ Language Options\fR" 4
+.IX Item " Language Options"
+\&\fB\-fabi\-version=\fR\fIn\fR  \fB\-fno\-access\-control  \-fcheck\-new 
+\&\-fconstexpr\-depth=\fR\fIn\fR  \fB\-ffriend\-injection 
+\&\-fno\-elide\-constructors 
+\&\-fno\-enforce\-eh\-specs 
+\&\-ffor\-scope  \-fno\-for\-scope  \-fno\-gnu\-keywords 
+\&\-fno\-implicit\-templates 
+\&\-fno\-implicit\-inline\-templates 
+\&\-fno\-implement\-inlines  \-fms\-extensions 
+\&\-fno\-nonansi\-builtins  \-fnothrow\-opt  \-fno\-operator\-names 
+\&\-fno\-optional\-diags  \-fpermissive 
+\&\-fno\-pretty\-templates 
+\&\-frepo  \-fno\-rtti  \-fstats  \-ftemplate\-backtrace\-limit=\fR\fIn\fR 
+\&\fB\-ftemplate\-depth=\fR\fIn\fR 
+\&\fB\-fno\-threadsafe\-statics \-fuse\-cxa\-atexit  \-fno\-weak  \-nostdinc++ 
+\&\-fvisibility\-inlines\-hidden 
+\&\-fvtable\-verify=\fR\fIstd|preinit|none\fR 
+\&\fB\-fvtv\-counts \-fvtv\-debug 
+\&\-fvisibility\-ms\-compat 
+\&\-fext\-numeric\-literals 
+\&\-Wabi  \-Wconversion\-null  \-Wctor\-dtor\-privacy 
+\&\-Wdelete\-non\-virtual\-dtor \-Wliteral\-suffix \-Wnarrowing 
+\&\-Wnoexcept \-Wnon\-virtual\-dtor  \-Wreorder 
+\&\-Weffc++  \-Wstrict\-null\-sentinel 
+\&\-Wno\-non\-template\-friend  \-Wold\-style\-cast 
+\&\-Woverloaded\-virtual  \-Wno\-pmf\-conversions 
+\&\-Wsign\-promo\fR
+.IP "\fIObjective-C and Objective\-\*(C+ Language Options\fR" 4
+.IX Item "Objective-C and Objective- Language Options"
+\&\fB\-fconstant\-string\-class=\fR\fIclass-name\fR 
+\&\fB\-fgnu\-runtime  \-fnext\-runtime 
+\&\-fno\-nil\-receivers 
+\&\-fobjc\-abi\-version=\fR\fIn\fR 
+\&\fB\-fobjc\-call\-cxx\-cdtors 
+\&\-fobjc\-direct\-dispatch 
+\&\-fobjc\-exceptions 
+\&\-fobjc\-gc 
+\&\-fobjc\-nilcheck 
+\&\-fobjc\-std=objc1 
+\&\-freplace\-objc\-classes 
+\&\-fzero\-link 
+\&\-gen\-decls 
+\&\-Wassign\-intercept 
+\&\-Wno\-protocol  \-Wselector 
+\&\-Wstrict\-selector\-match 
+\&\-Wundeclared\-selector\fR
+.IP "\fILanguage Independent Options\fR" 4
+.IX Item "Language Independent Options"
+\&\fB\-fmessage\-length=\fR\fIn\fR  
+\&\fB\-fdiagnostics\-show\-location=\fR[\fBonce\fR|\fBevery-line\fR]  
+\&\fB\-fdiagnostics\-color=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]  
+\&\fB\-fno\-diagnostics\-show\-option \-fno\-diagnostics\-show\-caret\fR
+.IP "\fIWarning Options\fR" 4
+.IX Item "Warning Options"
+\&\fB\-fsyntax\-only  \-fmax\-errors=\fR\fIn\fR  \fB\-Wpedantic 
+\&\-pedantic\-errors 
+\&\-w  \-Wextra  \-Wall  \-Waddress  \-Waggregate\-return  
+\&\-Waggressive\-loop\-optimizations \-Warray\-bounds 
+\&\-Wno\-attributes \-Wno\-builtin\-macro\-redefined 
+\&\-Wc++\-compat \-Wc++11\-compat \-Wcast\-align  \-Wcast\-qual  
+\&\-Wchar\-subscripts \-Wclobbered  \-Wcomment \-Wconditionally\-supported  
+\&\-Wconversion \-Wcoverage\-mismatch \-Wdate\-time \-Wdelete\-incomplete \-Wno\-cpp  
+\&\-Wno\-deprecated \-Wno\-deprecated\-declarations \-Wdisabled\-optimization  
+\&\-Wno\-div\-by\-zero \-Wdouble\-promotion \-Wempty\-body  \-Wenum\-compare 
+\&\-Wno\-endif\-labels \-Werror  \-Werror=* 
+\&\-Wfatal\-errors  \-Wfloat\-equal  \-Wformat  \-Wformat=2 
+\&\-Wno\-format\-contains\-nul \-Wno\-format\-extra\-args \-Wformat\-nonliteral 
+\&\-Wformat\-security  \-Wformat\-y2k 
+\&\-Wframe\-larger\-than=\fR\fIlen\fR \fB\-Wno\-free\-nonheap\-object \-Wjump\-misses\-init 
+\&\-Wignored\-qualifiers 
+\&\-Wimplicit  \-Wimplicit\-function\-declaration  \-Wimplicit\-int 
+\&\-Winit\-self  \-Winline \-Wmaybe\-uninitialized 
+\&\-Wno\-int\-to\-pointer\-cast \-Wno\-invalid\-offsetof 
+\&\-Winvalid\-pch \-Wlarger\-than=\fR\fIlen\fR  \fB\-Wunsafe\-loop\-optimizations 
+\&\-Wlogical\-op \-Wlong\-long 
+\&\-Wmain \-Wmaybe\-uninitialized \-Wmissing\-braces  \-Wmissing\-field\-initializers 
+\&\-Wmissing\-include\-dirs 
+\&\-Wno\-multichar  \-Wnonnull  \-Wno\-overflow \-Wopenmp\-simd 
+\&\-Woverlength\-strings  \-Wpacked  \-Wpacked\-bitfield\-compat  \-Wpadded 
+\&\-Wparentheses  \-Wpedantic\-ms\-format \-Wno\-pedantic\-ms\-format 
+\&\-Wpointer\-arith  \-Wno\-pointer\-to\-int\-cast 
+\&\-Wredundant\-decls  \-Wno\-return\-local\-addr 
+\&\-Wreturn\-type  \-Wsequence\-point  \-Wshadow 
+\&\-Wsign\-compare  \-Wsign\-conversion \-Wfloat\-conversion 
+\&\-Wsizeof\-pointer\-memaccess 
+\&\-Wstack\-protector \-Wstack\-usage=\fR\fIlen\fR \fB\-Wstrict\-aliasing 
+\&\-Wstrict\-aliasing=n  \-Wstrict\-overflow \-Wstrict\-overflow=\fR\fIn\fR 
+\&\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR|\fBformat\fR] 
+\&\fB\-Wmissing\-format\-attribute 
+\&\-Wswitch  \-Wswitch\-default  \-Wswitch\-enum \-Wsync\-nand 
+\&\-Wsystem\-headers  \-Wtrampolines  \-Wtrigraphs  \-Wtype\-limits  \-Wundef 
+\&\-Wuninitialized  \-Wunknown\-pragmas  \-Wno\-pragmas 
+\&\-Wunsuffixed\-float\-constants  \-Wunused  \-Wunused\-function 
+\&\-Wunused\-label  \-Wunused\-local\-typedefs \-Wunused\-parameter 
+\&\-Wno\-unused\-result \-Wunused\-value  \-Wunused\-variable 
+\&\-Wunused\-but\-set\-parameter \-Wunused\-but\-set\-variable 
+\&\-Wuseless\-cast \-Wvariadic\-macros \-Wvector\-operation\-performance 
+\&\-Wvla \-Wvolatile\-register\-var  \-Wwrite\-strings \-Wzero\-as\-null\-pointer\-constant\fR
+.IP "\fIC and Objective-C-only Warning Options\fR" 4
+.IX Item "C and Objective-C-only Warning Options"
+\&\fB\-Wbad\-function\-cast  \-Wmissing\-declarations 
+\&\-Wmissing\-parameter\-type  \-Wmissing\-prototypes  \-Wnested\-externs 
+\&\-Wold\-style\-declaration  \-Wold\-style\-definition 
+\&\-Wstrict\-prototypes  \-Wtraditional  \-Wtraditional\-conversion 
+\&\-Wdeclaration\-after\-statement \-Wpointer\-sign\fR
+.IP "\fIDebugging Options\fR" 4
+.IX Item "Debugging Options"
+\&\fB\-d\fR\fIletters\fR  \fB\-dumpspecs  \-dumpmachine  \-dumpversion 
+\&\-fsanitize=\fR\fIstyle\fR 
+\&\fB\-fdbg\-cnt\-list \-fdbg\-cnt=\fR\fIcounter-value-list\fR 
+\&\fB\-fdisable\-ipa\-\fR\fIpass_name\fR 
+\&\fB\-fdisable\-rtl\-\fR\fIpass_name\fR 
+\&\fB\-fdisable\-rtl\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR 
+\&\fB\-fdisable\-tree\-\fR\fIpass_name\fR 
+\&\fB\-fdisable\-tree\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR 
+\&\fB\-fdump\-noaddr \-fdump\-unnumbered \-fdump\-unnumbered\-links 
+\&\-fdump\-translation\-unit\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-class\-hierarchy\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-ipa\-all \-fdump\-ipa\-cgraph \-fdump\-ipa\-inline 
+\&\-fdump\-passes 
+\&\-fdump\-statistics 
+\&\-fdump\-tree\-all 
+\&\-fdump\-tree\-original\fR[\fB\-\fR\fIn\fR]  
+\&\fB\-fdump\-tree\-optimized\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-cfg \-fdump\-tree\-alias 
+\&\-fdump\-tree\-ch 
+\&\-fdump\-tree\-ssa\fR[\fB\-\fR\fIn\fR] \fB\-fdump\-tree\-pre\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-ccp\fR[\fB\-\fR\fIn\fR] \fB\-fdump\-tree\-dce\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-gimple\fR[\fB\-raw\fR] 
+\&\fB\-fdump\-tree\-dom\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-dse\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-phiprop\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-phiopt\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-forwprop\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-copyrename\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-nrv \-fdump\-tree\-vect 
+\&\-fdump\-tree\-sink 
+\&\-fdump\-tree\-sra\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-forwprop\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-fre\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-vtable\-verify 
+\&\-fdump\-tree\-vrp\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-storeccp\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-final\-insns=\fR\fIfile\fR 
+\&\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]  \fB\-fcompare\-debug\-second 
+\&\-feliminate\-dwarf2\-dups \-fno\-eliminate\-unused\-debug\-types 
+\&\-feliminate\-unused\-debug\-symbols \-femit\-class\-debug\-always 
+\&\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR 
+\&\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR 
+\&\fB\-fdebug\-types\-section \-fmem\-report\-wpa 
+\&\-fmem\-report \-fpre\-ipa\-mem\-report \-fpost\-ipa\-mem\-report \-fprofile\-arcs 
+\&\-fopt\-info 
+\&\-fopt\-info\-\fR\fIoptions\fR[\fB=\fR\fIfile\fR] 
+\&\fB\-frandom\-seed=\fR\fIstring\fR \fB\-fsched\-verbose=\fR\fIn\fR 
+\&\fB\-fsel\-sched\-verbose \-fsel\-sched\-dump\-cfg \-fsel\-sched\-pipelining\-verbose 
+\&\-fstack\-usage  \-ftest\-coverage  \-ftime\-report \-fvar\-tracking 
+\&\-fvar\-tracking\-assignments  \-fvar\-tracking\-assignments\-toggle 
+\&\-g  \-g\fR\fIlevel\fR  \fB\-gtoggle  \-gcoff  \-gdwarf\-\fR\fIversion\fR 
+\&\fB\-ggdb  \-grecord\-gcc\-switches  \-gno\-record\-gcc\-switches 
+\&\-gstabs  \-gstabs+  \-gstrict\-dwarf  \-gno\-strict\-dwarf 
+\&\-gvms  \-gxcoff  \-gxcoff+ 
+\&\-fno\-merge\-debug\-strings \-fno\-dwarf2\-cfi\-asm 
+\&\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 
+\&\fB\-femit\-struct\-debug\-baseonly \-femit\-struct\-debug\-reduced 
+\&\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR] 
+\&\fB\-p  \-pg  \-print\-file\-name=\fR\fIlibrary\fR  \fB\-print\-libgcc\-file\-name 
+\&\-print\-multi\-directory  \-print\-multi\-lib  \-print\-multi\-os\-directory 
+\&\-print\-prog\-name=\fR\fIprogram\fR  \fB\-print\-search\-dirs  \-Q 
+\&\-print\-sysroot \-print\-sysroot\-headers\-suffix 
+\&\-save\-temps \-save\-temps=cwd \-save\-temps=obj \-time\fR[\fB=\fR\fIfile\fR]
+.IP "\fIOptimization Options\fR" 4
+.IX Item "Optimization Options"
+\&\fB\-faggressive\-loop\-optimizations \-falign\-functions[=\fR\fIn\fR\fB] 
+\&\-falign\-jumps[=\fR\fIn\fR\fB] 
+\&\-falign\-labels[=\fR\fIn\fR\fB] \-falign\-loops[=\fR\fIn\fR\fB] 
+\&\-fassociative\-math \-fauto\-inc\-dec \-fbranch\-probabilities 
+\&\-fbranch\-target\-load\-optimize \-fbranch\-target\-load\-optimize2 
+\&\-fbtr\-bb\-exclusive \-fcaller\-saves 
+\&\-fcheck\-data\-deps \-fcombine\-stack\-adjustments \-fconserve\-stack 
+\&\-fcompare\-elim \-fcprop\-registers \-fcrossjumping 
+\&\-fcse\-follow\-jumps \-fcse\-skip\-blocks \-fcx\-fortran\-rules 
+\&\-fcx\-limited\-range 
+\&\-fdata\-sections \-fdce \-fdelayed\-branch 
+\&\-fdelete\-null\-pointer\-checks \-fdevirtualize \-fdevirtualize\-speculatively \-fdse 
+\&\-fearly\-inlining \-fipa\-sra \-fexpensive\-optimizations \-ffat\-lto\-objects 
+\&\-ffast\-math \-ffinite\-math\-only \-ffloat\-store \-fexcess\-precision=\fR\fIstyle\fR 
+\&\fB\-fforward\-propagate \-ffp\-contract=\fR\fIstyle\fR \fB\-ffunction\-sections 
+\&\-fgcse \-fgcse\-after\-reload \-fgcse\-las \-fgcse\-lm \-fgraphite\-identity 
+\&\-fgcse\-sm \-fhoist\-adjacent\-loads \-fif\-conversion 
+\&\-fif\-conversion2 \-findirect\-inlining 
+\&\-finline\-functions \-finline\-functions\-called\-once \-finline\-limit=\fR\fIn\fR 
+\&\fB\-finline\-small\-functions \-fipa\-cp \-fipa\-cp\-clone 
+\&\-fipa\-pta \-fipa\-profile \-fipa\-pure\-const \-fipa\-reference 
+\&\-fira\-algorithm=\fR\fIalgorithm\fR 
+\&\fB\-fira\-region=\fR\fIregion\fR \fB\-fira\-hoist\-pressure 
+\&\-fira\-loop\-pressure \-fno\-ira\-share\-save\-slots 
+\&\-fno\-ira\-share\-spill\-slots \-fira\-verbose=\fR\fIn\fR 
+\&\fB\-fisolate\-erroneous\-paths\-dereference \-fisolate\-erroneous\-paths\-attribute
+\&\-fivopts \-fkeep\-inline\-functions \-fkeep\-static\-consts \-flive\-range\-shrinkage 
+\&\-floop\-block \-floop\-interchange \-floop\-strip\-mine \-floop\-nest\-optimize 
+\&\-floop\-parallelize\-all \-flto \-flto\-compression\-level 
+\&\-flto\-partition=\fR\fIalg\fR \fB\-flto\-report \-flto\-report\-wpa \-fmerge\-all\-constants 
+\&\-fmerge\-constants \-fmodulo\-sched \-fmodulo\-sched\-allow\-regmoves 
+\&\-fmove\-loop\-invariants \-fno\-branch\-count\-reg 
+\&\-fno\-defer\-pop \-fno\-function\-cse \-fno\-guess\-branch\-probability 
+\&\-fno\-inline \-fno\-math\-errno \-fno\-peephole \-fno\-peephole2 
+\&\-fno\-sched\-interblock \-fno\-sched\-spec \-fno\-signed\-zeros 
+\&\-fno\-toplevel\-reorder \-fno\-trapping\-math \-fno\-zero\-initialized\-in\-bss 
+\&\-fomit\-frame\-pointer \-foptimize\-sibling\-calls 
+\&\-fpartial\-inlining \-fpeel\-loops \-fpredictive\-commoning 
+\&\-fprefetch\-loop\-arrays \-fprofile\-report 
+\&\-fprofile\-correction \-fprofile\-dir=\fR\fIpath\fR \fB\-fprofile\-generate 
+\&\-fprofile\-generate=\fR\fIpath\fR 
+\&\fB\-fprofile\-use \-fprofile\-use=\fR\fIpath\fR \fB\-fprofile\-values \-fprofile\-reorder\-functions 
+\&\-freciprocal\-math \-free \-frename\-registers \-freorder\-blocks 
+\&\-freorder\-blocks\-and\-partition \-freorder\-functions 
+\&\-frerun\-cse\-after\-loop \-freschedule\-modulo\-scheduled\-loops 
+\&\-frounding\-math \-fsched2\-use\-superblocks \-fsched\-pressure 
+\&\-fsched\-spec\-load \-fsched\-spec\-load\-dangerous 
+\&\-fsched\-stalled\-insns\-dep[=\fR\fIn\fR\fB] \-fsched\-stalled\-insns[=\fR\fIn\fR\fB] 
+\&\-fsched\-group\-heuristic \-fsched\-critical\-path\-heuristic 
+\&\-fsched\-spec\-insn\-heuristic \-fsched\-rank\-heuristic 
+\&\-fsched\-last\-insn\-heuristic \-fsched\-dep\-count\-heuristic 
+\&\-fschedule\-insns \-fschedule\-insns2 \-fsection\-anchors 
+\&\-fselective\-scheduling \-fselective\-scheduling2 
+\&\-fsel\-sched\-pipelining \-fsel\-sched\-pipelining\-outer\-loops 
+\&\-fshrink\-wrap \-fsignaling\-nans \-fsingle\-precision\-constant 
+\&\-fsplit\-ivs\-in\-unroller \-fsplit\-wide\-types \-fstack\-protector 
+\&\-fstack\-protector\-all \-fstack\-protector\-strong \-fstrict\-aliasing 
+\&\-fstrict\-overflow \-fthread\-jumps \-ftracer \-ftree\-bit\-ccp 
+\&\-ftree\-builtin\-call\-dce \-ftree\-ccp \-ftree\-ch 
+\&\-ftree\-coalesce\-inline\-vars \-ftree\-coalesce\-vars \-ftree\-copy\-prop 
+\&\-ftree\-copyrename \-ftree\-dce \-ftree\-dominator\-opts \-ftree\-dse 
+\&\-ftree\-forwprop \-ftree\-fre \-ftree\-loop\-if\-convert 
+\&\-ftree\-loop\-if\-convert\-stores \-ftree\-loop\-im 
+\&\-ftree\-phiprop \-ftree\-loop\-distribution \-ftree\-loop\-distribute\-patterns 
+\&\-ftree\-loop\-ivcanon \-ftree\-loop\-linear \-ftree\-loop\-optimize 
+\&\-ftree\-loop\-vectorize 
+\&\-ftree\-parallelize\-loops=\fR\fIn\fR \fB\-ftree\-pre \-ftree\-partial\-pre \-ftree\-pta 
+\&\-ftree\-reassoc \-ftree\-sink \-ftree\-slsr \-ftree\-sra 
+\&\-ftree\-switch\-conversion \-ftree\-tail\-merge \-ftree\-ter 
+\&\-ftree\-vectorize \-ftree\-vrp 
+\&\-funit\-at\-a\-time \-funroll\-all\-loops \-funroll\-loops 
+\&\-funsafe\-loop\-optimizations \-funsafe\-math\-optimizations \-funswitch\-loops 
+\&\-fvariable\-expansion\-in\-unroller \-fvect\-cost\-model \-fvpt \-fweb 
+\&\-fwhole\-program \-fwpa \-fuse\-ld=\fR\fIlinker\fR \fB\-fuse\-linker\-plugin 
+\&\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR
+\&\fB\-O  \-O0  \-O1  \-O2  \-O3  \-Os \-Ofast \-Og\fR
+.IP "\fIPreprocessor Options\fR" 4
+.IX Item "Preprocessor Options"
+\&\fB\-A\fR\fIquestion\fR\fB=\fR\fIanswer\fR 
+\&\fB\-A\-\fR\fIquestion\fR[\fB=\fR\fIanswer\fR] 
+\&\fB\-C  \-dD  \-dI  \-dM  \-dN 
+\&\-D\fR\fImacro\fR[\fB=\fR\fIdefn\fR]  \fB\-E  \-H 
+\&\-idirafter\fR \fIdir\fR 
+\&\fB\-include\fR \fIfile\fR  \fB\-imacros\fR \fIfile\fR 
+\&\fB\-iprefix\fR \fIfile\fR  \fB\-iwithprefix\fR \fIdir\fR 
+\&\fB\-iwithprefixbefore\fR \fIdir\fR  \fB\-isystem\fR \fIdir\fR 
+\&\fB\-imultilib\fR \fIdir\fR \fB\-isysroot\fR \fIdir\fR 
+\&\fB\-M  \-MM  \-MF  \-MG  \-MP  \-MQ  \-MT  \-nostdinc  
+\&\-P  \-fdebug\-cpp \-ftrack\-macro\-expansion \-fworking\-directory 
+\&\-remap \-trigraphs  \-undef  \-U\fR\fImacro\fR  
+\&\fB\-Wp,\fR\fIoption\fR \fB\-Xpreprocessor\fR \fIoption\fR \fB\-no\-integrated\-cpp\fR
+.IP "\fIAssembler Option\fR" 4
+.IX Item "Assembler Option"
+\&\fB\-Wa,\fR\fIoption\fR  \fB\-Xassembler\fR \fIoption\fR
+.IP "\fILinker Options\fR" 4
+.IX Item "Linker Options"
+\&\fIobject-file-name\fR  \fB\-l\fR\fIlibrary\fR 
+\&\fB\-nostartfiles  \-nodefaultlibs  \-nostdlib \-pie \-rdynamic 
+\&\-s  \-static \-static\-libgcc \-static\-libstdc++ 
+\&\-static\-libasan \-static\-libtsan \-static\-liblsan \-static\-libubsan 
+\&\-shared \-shared\-libgcc  \-symbolic 
+\&\-T\fR \fIscript\fR  \fB\-Wl,\fR\fIoption\fR  \fB\-Xlinker\fR \fIoption\fR 
+\&\fB\-u\fR \fIsymbol\fR
+.IP "\fIDirectory Options\fR" 4
+.IX Item "Directory Options"
+\&\fB\-B\fR\fIprefix\fR \fB\-I\fR\fIdir\fR \fB\-iplugindir=\fR\fIdir\fR 
+\&\fB\-iquote\fR\fIdir\fR \fB\-L\fR\fIdir\fR \fB\-specs=\fR\fIfile\fR \fB\-I\- 
+\&\-\-sysroot=\fR\fIdir\fR \fB\-\-no\-sysroot\-suffix\fR
+.IP "\fIMachine Dependent Options\fR" 4
+.IX Item "Machine Dependent Options"
+\&\fIAArch64 Options\fR
+\&\fB\-mabi=\fR\fIname\fR  \fB\-mbig\-endian  \-mlittle\-endian 
+\&\-mgeneral\-regs\-only 
+\&\-mcmodel=tiny  \-mcmodel=small  \-mcmodel=large 
+\&\-mstrict\-align 
+\&\-momit\-leaf\-frame\-pointer  \-mno\-omit\-leaf\-frame\-pointer 
+\&\-mtls\-dialect=desc  \-mtls\-dialect=traditional 
+\&\-march=\fR\fIname\fR  \fB\-mcpu=\fR\fIname\fR  \fB\-mtune=\fR\fIname\fR
+.Sp
+\&\fIAdapteva Epiphany Options\fR
+\&\fB\-mhalf\-reg\-file \-mprefer\-short\-insn\-regs 
+\&\-mbranch\-cost=\fR\fInum\fR \fB\-mcmove \-mnops=\fR\fInum\fR \fB\-msoft\-cmpsf 
+\&\-msplit\-lohi \-mpost\-inc \-mpost\-modify \-mstack\-offset=\fR\fInum\fR 
+\&\fB\-mround\-nearest \-mlong\-calls \-mshort\-calls \-msmall16 
+\&\-mfp\-mode=\fR\fImode\fR \fB\-mvect\-double \-max\-vect\-align=\fR\fInum\fR 
+\&\fB\-msplit\-vecmove\-early \-m1reg\-\fR\fIreg\fR
+.Sp
+\&\fI\s-1ARC\s0 Options\fR
+\&\fB\-mbarrel\-shifter 
+\&\-mcpu=\fR\fIcpu\fR \fB\-mA6 \-mARC600 \-mA7 \-mARC700 
+\&\-mdpfp \-mdpfp\-compact \-mdpfp\-fast \-mno\-dpfp\-lrsr 
+\&\-mea \-mno\-mpy \-mmul32x16 \-mmul64 
+\&\-mnorm \-mspfp \-mspfp\-compact \-mspfp\-fast \-msimd \-msoft\-float \-mswap 
+\&\-mcrc \-mdsp\-packa \-mdvbf \-mlock \-mmac\-d16 \-mmac\-24 \-mrtsc \-mswape 
+\&\-mtelephony \-mxy \-misize \-mannotate\-align \-marclinux \-marclinux_prof 
+\&\-mepilogue\-cfi \-mlong\-calls \-mmedium\-calls \-msdata 
+\&\-mucb\-mcount \-mvolatile\-cache 
+\&\-malign\-call \-mauto\-modify\-reg \-mbbit\-peephole \-mno\-brcc 
+\&\-mcase\-vector\-pcrel \-mcompact\-casesi \-mno\-cond\-exec \-mearly\-cbranchsi 
+\&\-mexpand\-adddi \-mindexed\-loads \-mlra \-mlra\-priority\-none 
+\&\-mlra\-priority\-compact mlra-priority-noncompact \-mno\-millicode 
+\&\-mmixed\-code \-mq\-class \-mRcq \-mRcw \-msize\-level=\fR\fIlevel\fR 
+\&\fB\-mtune=\fR\fIcpu\fR \fB\-mmultcost=\fR\fInum\fR \fB\-munalign\-prob\-threshold=\fR\fIprobability\fR
+.Sp
+\&\fI\s-1ARM\s0 Options\fR
+\&\fB\-mapcs\-frame  \-mno\-apcs\-frame 
+\&\-mabi=\fR\fIname\fR 
+\&\fB\-mapcs\-stack\-check  \-mno\-apcs\-stack\-check 
+\&\-mapcs\-float  \-mno\-apcs\-float 
+\&\-mapcs\-reentrant  \-mno\-apcs\-reentrant 
+\&\-msched\-prolog  \-mno\-sched\-prolog 
+\&\-mlittle\-endian  \-mbig\-endian  \-mwords\-little\-endian 
+\&\-mfloat\-abi=\fR\fIname\fR 
+\&\fB\-mfp16\-format=\fR\fIname\fR
+\&\fB\-mthumb\-interwork  \-mno\-thumb\-interwork 
+\&\-mcpu=\fR\fIname\fR  \fB\-march=\fR\fIname\fR  \fB\-mfpu=\fR\fIname\fR  
+\&\fB\-mstructure\-size\-boundary=\fR\fIn\fR 
+\&\fB\-mabort\-on\-noreturn 
+\&\-mlong\-calls  \-mno\-long\-calls 
+\&\-msingle\-pic\-base  \-mno\-single\-pic\-base 
+\&\-mpic\-register=\fR\fIreg\fR 
+\&\fB\-mnop\-fun\-dllimport 
+\&\-mpoke\-function\-name 
+\&\-mthumb  \-marm 
+\&\-mtpcs\-frame  \-mtpcs\-leaf\-frame 
+\&\-mcaller\-super\-interworking  \-mcallee\-super\-interworking 
+\&\-mtp=\fR\fIname\fR \fB\-mtls\-dialect=\fR\fIdialect\fR 
+\&\fB\-mword\-relocations 
+\&\-mfix\-cortex\-m3\-ldrd 
+\&\-munaligned\-access 
+\&\-mneon\-for\-64bits 
+\&\-mslow\-flash\-data 
+\&\-mrestrict\-it\fR
+.Sp
+\&\fI\s-1AVR\s0 Options\fR
+\&\fB\-mmcu=\fR\fImcu\fR \fB\-maccumulate\-args \-mbranch\-cost=\fR\fIcost\fR 
+\&\fB\-mcall\-prologues \-mint8 \-mno\-interrupts \-mrelax 
+\&\-mstrict\-X \-mtiny\-stack \-Waddr\-space\-convert\fR
+.Sp
+\&\fIBlackfin Options\fR
+\&\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR] 
+\&\fB\-msim \-momit\-leaf\-frame\-pointer  \-mno\-omit\-leaf\-frame\-pointer 
+\&\-mspecld\-anomaly  \-mno\-specld\-anomaly  \-mcsync\-anomaly  \-mno\-csync\-anomaly 
+\&\-mlow\-64k \-mno\-low64k  \-mstack\-check\-l1  \-mid\-shared\-library 
+\&\-mno\-id\-shared\-library  \-mshared\-library\-id=\fR\fIn\fR 
+\&\fB\-mleaf\-id\-shared\-library  \-mno\-leaf\-id\-shared\-library 
+\&\-msep\-data  \-mno\-sep\-data  \-mlong\-calls  \-mno\-long\-calls 
+\&\-mfast\-fp \-minline\-plt \-mmulticore  \-mcorea  \-mcoreb  \-msdram 
+\&\-micplb\fR
+.Sp
+\&\fIC6X Options\fR
+\&\fB\-mbig\-endian  \-mlittle\-endian \-march=\fR\fIcpu\fR 
+\&\fB\-msim \-msdata=\fR\fIsdata-type\fR
+.Sp
+\&\fI\s-1CRIS\s0 Options\fR
+\&\fB\-mcpu=\fR\fIcpu\fR  \fB\-march=\fR\fIcpu\fR  \fB\-mtune=\fR\fIcpu\fR 
+\&\fB\-mmax\-stack\-frame=\fR\fIn\fR  \fB\-melinux\-stacksize=\fR\fIn\fR 
+\&\fB\-metrax4  \-metrax100  \-mpdebug  \-mcc\-init  \-mno\-side\-effects 
+\&\-mstack\-align  \-mdata\-align  \-mconst\-align 
+\&\-m32\-bit  \-m16\-bit  \-m8\-bit  \-mno\-prologue\-epilogue  \-mno\-gotplt 
+\&\-melf  \-maout  \-melinux  \-mlinux  \-sim  \-sim2 
+\&\-mmul\-bug\-workaround  \-mno\-mul\-bug\-workaround\fR
+.Sp
+\&\fI\s-1CR16\s0 Options\fR
+\&\fB\-mmac 
+\&\-mcr16cplus \-mcr16c 
+\&\-msim \-mint32 \-mbit\-ops
+\&\-mdata\-model=\fR\fImodel\fR
+.Sp
+\&\fIDarwin Options\fR
+\&\fB\-all_load  \-allowable_client  \-arch  \-arch_errors_fatal 
+\&\-arch_only  \-bind_at_load  \-bundle  \-bundle_loader 
+\&\-client_name  \-compatibility_version  \-current_version 
+\&\-dead_strip 
+\&\-dependency\-file  \-dylib_file  \-dylinker_install_name 
+\&\-dynamic  \-dynamiclib  \-exported_symbols_list 
+\&\-filelist  \-flat_namespace  \-force_cpusubtype_ALL 
+\&\-force_flat_namespace  \-headerpad_max_install_names 
+\&\-iframework 
+\&\-image_base  \-init  \-install_name  \-keep_private_externs 
+\&\-multi_module  \-multiply_defined  \-multiply_defined_unused 
+\&\-noall_load   \-no_dead_strip_inits_and_terms 
+\&\-nofixprebinding \-nomultidefs  \-noprebind  \-noseglinkedit 
+\&\-pagezero_size  \-prebind  \-prebind_all_twolevel_modules 
+\&\-private_bundle  \-read_only_relocs  \-sectalign 
+\&\-sectobjectsymbols  \-whyload  \-seg1addr 
+\&\-sectcreate  \-sectobjectsymbols  \-sectorder 
+\&\-segaddr \-segs_read_only_addr \-segs_read_write_addr 
+\&\-seg_addr_table  \-seg_addr_table_filename  \-seglinkedit 
+\&\-segprot  \-segs_read_only_addr  \-segs_read_write_addr 
+\&\-single_module  \-static  \-sub_library  \-sub_umbrella 
+\&\-twolevel_namespace  \-umbrella  \-undefined 
+\&\-unexported_symbols_list  \-weak_reference_mismatches 
+\&\-whatsloaded \-F \-gused \-gfull \-mmacosx\-version\-min=\fR\fIversion\fR 
+\&\fB\-mkernel \-mone\-byte\-bool\fR
+.Sp
+\&\fI\s-1DEC\s0 Alpha Options\fR
+\&\fB\-mno\-fp\-regs  \-msoft\-float 
+\&\-mieee  \-mieee\-with\-inexact  \-mieee\-conformant 
+\&\-mfp\-trap\-mode=\fR\fImode\fR  \fB\-mfp\-rounding\-mode=\fR\fImode\fR 
+\&\fB\-mtrap\-precision=\fR\fImode\fR  \fB\-mbuild\-constants 
+\&\-mcpu=\fR\fIcpu-type\fR  \fB\-mtune=\fR\fIcpu-type\fR 
+\&\fB\-mbwx  \-mmax  \-mfix  \-mcix 
+\&\-mfloat\-vax  \-mfloat\-ieee 
+\&\-mexplicit\-relocs  \-msmall\-data  \-mlarge\-data 
+\&\-msmall\-text  \-mlarge\-text 
+\&\-mmemory\-latency=\fR\fItime\fR
+.Sp
+\&\fI\s-1FR30\s0 Options\fR
+\&\fB\-msmall\-model \-mno\-lsim\fR
+.Sp
+\&\fI\s-1FRV\s0 Options\fR
+\&\fB\-mgpr\-32  \-mgpr\-64  \-mfpr\-32  \-mfpr\-64 
+\&\-mhard\-float  \-msoft\-float 
+\&\-malloc\-cc  \-mfixed\-cc  \-mdword  \-mno\-dword 
+\&\-mdouble  \-mno\-double 
+\&\-mmedia  \-mno\-media  \-mmuladd  \-mno\-muladd 
+\&\-mfdpic  \-minline\-plt \-mgprel\-ro  \-multilib\-library\-pic 
+\&\-mlinked\-fp  \-mlong\-calls  \-malign\-labels 
+\&\-mlibrary\-pic  \-macc\-4  \-macc\-8 
+\&\-mpack  \-mno\-pack  \-mno\-eflags  \-mcond\-move  \-mno\-cond\-move 
+\&\-moptimize\-membar \-mno\-optimize\-membar 
+\&\-mscc  \-mno\-scc  \-mcond\-exec  \-mno\-cond\-exec 
+\&\-mvliw\-branch  \-mno\-vliw\-branch 
+\&\-mmulti\-cond\-exec  \-mno\-multi\-cond\-exec  \-mnested\-cond\-exec 
+\&\-mno\-nested\-cond\-exec  \-mtomcat\-stats 
+\&\-mTLS \-mtls 
+\&\-mcpu=\fR\fIcpu\fR
+.Sp
+\&\fIGNU/Linux Options\fR
+\&\fB\-mglibc \-muclibc \-mbionic \-mandroid 
+\&\-tno\-android\-cc \-tno\-android\-ld\fR
+.Sp
+\&\fIH8/300 Options\fR
+\&\fB\-mrelax  \-mh  \-ms  \-mn  \-mexr \-mno\-exr  \-mint32  \-malign\-300\fR
+.Sp
+\&\fI\s-1HPPA\s0 Options\fR
+\&\fB\-march=\fR\fIarchitecture-type\fR 
+\&\fB\-mdisable\-fpregs  \-mdisable\-indexing 
+\&\-mfast\-indirect\-calls  \-mgas  \-mgnu\-ld   \-mhp\-ld 
+\&\-mfixed\-range=\fR\fIregister-range\fR 
+\&\fB\-mjump\-in\-delay \-mlinker\-opt \-mlong\-calls 
+\&\-mlong\-load\-store  \-mno\-disable\-fpregs 
+\&\-mno\-disable\-indexing  \-mno\-fast\-indirect\-calls  \-mno\-gas 
+\&\-mno\-jump\-in\-delay  \-mno\-long\-load\-store 
+\&\-mno\-portable\-runtime  \-mno\-soft\-float 
+\&\-mno\-space\-regs  \-msoft\-float  \-mpa\-risc\-1\-0 
+\&\-mpa\-risc\-1\-1  \-mpa\-risc\-2\-0  \-mportable\-runtime 
+\&\-mschedule=\fR\fIcpu-type\fR  \fB\-mspace\-regs  \-msio  \-mwsio 
+\&\-munix=\fR\fIunix-std\fR  \fB\-nolibdld  \-static  \-threads\fR
+.Sp
+\&\fIi386 and x86\-64 Options\fR
+\&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-march=\fR\fIcpu-type\fR 
+\&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR \fB\-mdump\-tune\-features \-mno\-default 
+\&\-mfpmath=\fR\fIunit\fR 
+\&\fB\-masm=\fR\fIdialect\fR  \fB\-mno\-fancy\-math\-387 
+\&\-mno\-fp\-ret\-in\-387  \-msoft\-float 
+\&\-mno\-wide\-multiply  \-mrtd  \-malign\-double 
+\&\-mpreferred\-stack\-boundary=\fR\fInum\fR 
+\&\fB\-mincoming\-stack\-boundary=\fR\fInum\fR 
+\&\fB\-mcld \-mcx16 \-msahf \-mmovbe \-mcrc32 
+\&\-mrecip \-mrecip=\fR\fIopt\fR 
+\&\fB\-mvzeroupper \-mprefer\-avx128 
+\&\-mmmx  \-msse  \-msse2 \-msse3 \-mssse3 \-msse4.1 \-msse4.2 \-msse4 \-mavx 
+\&\-mavx2 \-mavx512f \-mavx512pf \-mavx512er \-mavx512cd \-msha 
+\&\-maes \-mpclmul \-mfsgsbase \-mrdrnd \-mf16c \-mfma \-mprefetchwt1 
+\&\-msse4a \-m3dnow \-mpopcnt \-mabm \-mbmi \-mtbm \-mfma4 \-mxop \-mlzcnt 
+\&\-mbmi2 \-mfxsr \-mxsave \-mxsaveopt \-mrtm \-mlwp \-mthreads 
+\&\-mno\-align\-stringops  \-minline\-all\-stringops 
+\&\-minline\-stringops\-dynamically \-mstringop\-strategy=\fR\fIalg\fR 
+\&\fB\-mmemcpy\-strategy=\fR\fIstrategy\fR \fB\-mmemset\-strategy=\fR\fIstrategy\fR
+\&\fB\-mpush\-args  \-maccumulate\-outgoing\-args  \-m128bit\-long\-double 
+\&\-m96bit\-long\-double \-mlong\-double\-64 \-mlong\-double\-80 \-mlong\-double\-128 
+\&\-mregparm=\fR\fInum\fR  \fB\-msseregparm 
+\&\-mveclibabi=\fR\fItype\fR \fB\-mvect8\-ret\-in\-mem 
+\&\-mpc32 \-mpc64 \-mpc80 \-mstackrealign 
+\&\-momit\-leaf\-frame\-pointer  \-mno\-red\-zone \-mno\-tls\-direct\-seg\-refs 
+\&\-mcmodel=\fR\fIcode-model\fR \fB\-mabi=\fR\fIname\fR \fB\-maddress\-mode=\fR\fImode\fR 
+\&\fB\-m32 \-m64 \-mx32 \-m16 \-mlarge\-data\-threshold=\fR\fInum\fR 
+\&\fB\-msse2avx \-mfentry \-m8bit\-idiv 
+\&\-mavx256\-split\-unaligned\-load \-mavx256\-split\-unaligned\-store 
+\&\-mstack\-protector\-guard=\fR\fIguard\fR
+.Sp
+\&\fIi386 and x86\-64 Windows Options\fR
+\&\fB\-mconsole \-mcygwin \-mno\-cygwin \-mdll 
+\&\-mnop\-fun\-dllimport \-mthread 
+\&\-municode \-mwin32 \-mwindows \-fno\-set\-stack\-executable\fR
+.Sp
+\&\fI\s-1IA\-64\s0 Options\fR
+\&\fB\-mbig\-endian  \-mlittle\-endian  \-mgnu\-as  \-mgnu\-ld  \-mno\-pic 
+\&\-mvolatile\-asm\-stop  \-mregister\-names  \-msdata \-mno\-sdata 
+\&\-mconstant\-gp  \-mauto\-pic  \-mfused\-madd 
+\&\-minline\-float\-divide\-min\-latency 
+\&\-minline\-float\-divide\-max\-throughput 
+\&\-mno\-inline\-float\-divide 
+\&\-minline\-int\-divide\-min\-latency 
+\&\-minline\-int\-divide\-max\-throughput  
+\&\-mno\-inline\-int\-divide 
+\&\-minline\-sqrt\-min\-latency \-minline\-sqrt\-max\-throughput 
+\&\-mno\-inline\-sqrt 
+\&\-mdwarf2\-asm \-mearly\-stop\-bits 
+\&\-mfixed\-range=\fR\fIregister-range\fR \fB\-mtls\-size=\fR\fItls-size\fR 
+\&\fB\-mtune=\fR\fIcpu-type\fR \fB\-milp32 \-mlp64 
+\&\-msched\-br\-data\-spec \-msched\-ar\-data\-spec \-msched\-control\-spec 
+\&\-msched\-br\-in\-data\-spec \-msched\-ar\-in\-data\-spec \-msched\-in\-control\-spec 
+\&\-msched\-spec\-ldc \-msched\-spec\-control\-ldc 
+\&\-msched\-prefer\-non\-data\-spec\-insns \-msched\-prefer\-non\-control\-spec\-insns 
+\&\-msched\-stop\-bits\-after\-every\-cycle \-msched\-count\-spec\-in\-critical\-path 
+\&\-msel\-sched\-dont\-check\-control\-spec \-msched\-fp\-mem\-deps\-zero\-cost 
+\&\-msched\-max\-memory\-insns\-hard\-limit \-msched\-max\-memory\-insns=\fR\fImax-insns\fR
+.Sp
+\&\fI\s-1LM32\s0 Options\fR
+\&\fB\-mbarrel\-shift\-enabled \-mdivide\-enabled \-mmultiply\-enabled 
+\&\-msign\-extend\-enabled \-muser\-enabled\fR
+.Sp
+\&\fIM32R/D Options\fR
+\&\fB\-m32r2 \-m32rx \-m32r 
+\&\-mdebug 
+\&\-malign\-loops \-mno\-align\-loops 
+\&\-missue\-rate=\fR\fInumber\fR 
+\&\fB\-mbranch\-cost=\fR\fInumber\fR 
+\&\fB\-mmodel=\fR\fIcode-size-model-type\fR 
+\&\fB\-msdata=\fR\fIsdata-type\fR 
+\&\fB\-mno\-flush\-func \-mflush\-func=\fR\fIname\fR 
+\&\fB\-mno\-flush\-trap \-mflush\-trap=\fR\fInumber\fR 
+\&\fB\-G\fR \fInum\fR
+.Sp
+\&\fIM32C Options\fR
+\&\fB\-mcpu=\fR\fIcpu\fR \fB\-msim \-memregs=\fR\fInumber\fR
+.Sp
+\&\fIM680x0 Options\fR
+\&\fB\-march=\fR\fIarch\fR  \fB\-mcpu=\fR\fIcpu\fR  \fB\-mtune=\fR\fItune\fR
+\&\fB\-m68000  \-m68020  \-m68020\-40  \-m68020\-60  \-m68030  \-m68040 
+\&\-m68060  \-mcpu32  \-m5200  \-m5206e  \-m528x  \-m5307  \-m5407 
+\&\-mcfv4e  \-mbitfield  \-mno\-bitfield  \-mc68000  \-mc68020 
+\&\-mnobitfield  \-mrtd  \-mno\-rtd  \-mdiv  \-mno\-div  \-mshort 
+\&\-mno\-short  \-mhard\-float  \-m68881  \-msoft\-float  \-mpcrel 
+\&\-malign\-int  \-mstrict\-align  \-msep\-data  \-mno\-sep\-data 
+\&\-mshared\-library\-id=n  \-mid\-shared\-library  \-mno\-id\-shared\-library 
+\&\-mxgot \-mno\-xgot\fR
+.Sp
+\&\fIMCore Options\fR
+\&\fB\-mhardlit  \-mno\-hardlit  \-mdiv  \-mno\-div  \-mrelax\-immediates 
+\&\-mno\-relax\-immediates  \-mwide\-bitfields  \-mno\-wide\-bitfields 
+\&\-m4byte\-functions  \-mno\-4byte\-functions  \-mcallgraph\-data 
+\&\-mno\-callgraph\-data  \-mslow\-bytes  \-mno\-slow\-bytes  \-mno\-lsim 
+\&\-mlittle\-endian  \-mbig\-endian  \-m210  \-m340  \-mstack\-increment\fR
+.Sp
+\&\fIMeP Options\fR
+\&\fB\-mabsdiff \-mall\-opts \-maverage \-mbased=\fR\fIn\fR \fB\-mbitops 
+\&\-mc=\fR\fIn\fR \fB\-mclip \-mconfig=\fR\fIname\fR \fB\-mcop \-mcop32 \-mcop64 \-mivc2 
+\&\-mdc \-mdiv \-meb \-mel \-mio\-volatile \-ml \-mleadz \-mm \-mminmax 
+\&\-mmult \-mno\-opts \-mrepeat \-ms \-msatur \-msdram \-msim \-msimnovec \-mtf 
+\&\-mtiny=\fR\fIn\fR
+.Sp
+\&\fIMicroBlaze Options\fR
+\&\fB\-msoft\-float \-mhard\-float \-msmall\-divides \-mcpu=\fR\fIcpu\fR 
+\&\fB\-mmemcpy \-mxl\-soft\-mul \-mxl\-soft\-div \-mxl\-barrel\-shift 
+\&\-mxl\-pattern\-compare \-mxl\-stack\-check \-mxl\-gp\-opt \-mno\-clearbss 
+\&\-mxl\-multiply\-high \-mxl\-float\-convert \-mxl\-float\-sqrt 
+\&\-mbig\-endian \-mlittle\-endian \-mxl\-reorder \-mxl\-mode\-\fR\fIapp-model\fR
+.Sp
+\&\fI\s-1MIPS\s0 Options\fR
+\&\fB\-EL  \-EB  \-march=\fR\fIarch\fR  \fB\-mtune=\fR\fIarch\fR 
+\&\fB\-mips1  \-mips2  \-mips3  \-mips4  \-mips32  \-mips32r2 
+\&\-mips64  \-mips64r2 
+\&\-mips16  \-mno\-mips16  \-mflip\-mips16 
+\&\-minterlink\-compressed \-mno\-interlink\-compressed 
+\&\-minterlink\-mips16  \-mno\-interlink\-mips16 
+\&\-mabi=\fR\fIabi\fR  \fB\-mabicalls  \-mno\-abicalls 
+\&\-mshared  \-mno\-shared  \-mplt  \-mno\-plt  \-mxgot  \-mno\-xgot 
+\&\-mgp32  \-mgp64  \-mfp32  \-mfp64  \-mhard\-float  \-msoft\-float 
+\&\-mno\-float  \-msingle\-float  \-mdouble\-float 
+\&\-mabs=\fR\fImode\fR  \fB\-mnan=\fR\fIencoding\fR 
+\&\fB\-mdsp  \-mno\-dsp  \-mdspr2  \-mno\-dspr2 
+\&\-mmcu \-mmno\-mcu 
+\&\-meva \-mno\-eva 
+\&\-mvirt \-mno\-virt 
+\&\-mmicromips \-mno\-micromips 
+\&\-mfpu=\fR\fIfpu-type\fR 
+\&\fB\-msmartmips  \-mno\-smartmips 
+\&\-mpaired\-single  \-mno\-paired\-single  \-mdmx  \-mno\-mdmx 
+\&\-mips3d  \-mno\-mips3d  \-mmt  \-mno\-mt  \-mllsc  \-mno\-llsc 
+\&\-mlong64  \-mlong32  \-msym32  \-mno\-sym32 
+\&\-G\fR\fInum\fR  \fB\-mlocal\-sdata  \-mno\-local\-sdata 
+\&\-mextern\-sdata  \-mno\-extern\-sdata  \-mgpopt  \-mno\-gopt 
+\&\-membedded\-data  \-mno\-embedded\-data 
+\&\-muninit\-const\-in\-rodata  \-mno\-uninit\-const\-in\-rodata 
+\&\-mcode\-readable=\fR\fIsetting\fR 
+\&\fB\-msplit\-addresses  \-mno\-split\-addresses 
+\&\-mexplicit\-relocs  \-mno\-explicit\-relocs 
+\&\-mcheck\-zero\-division  \-mno\-check\-zero\-division 
+\&\-mdivide\-traps  \-mdivide\-breaks 
+\&\-mmemcpy  \-mno\-memcpy  \-mlong\-calls  \-mno\-long\-calls 
+\&\-mmad \-mno\-mad \-mimadd \-mno\-imadd \-mfused\-madd  \-mno\-fused\-madd  \-nocpp 
+\&\-mfix\-24k \-mno\-fix\-24k 
+\&\-mfix\-r4000  \-mno\-fix\-r4000  \-mfix\-r4400  \-mno\-fix\-r4400 
+\&\-mfix\-r10000 \-mno\-fix\-r10000  \-mfix\-rm7000 \-mno\-fix\-rm7000 
+\&\-mfix\-vr4120  \-mno\-fix\-vr4120 
+\&\-mfix\-vr4130  \-mno\-fix\-vr4130  \-mfix\-sb1  \-mno\-fix\-sb1 
+\&\-mflush\-func=\fR\fIfunc\fR  \fB\-mno\-flush\-func 
+\&\-mbranch\-cost=\fR\fInum\fR  \fB\-mbranch\-likely  \-mno\-branch\-likely 
+\&\-mfp\-exceptions \-mno\-fp\-exceptions 
+\&\-mvr4130\-align \-mno\-vr4130\-align \-msynci \-mno\-synci 
+\&\-mrelax\-pic\-calls \-mno\-relax\-pic\-calls \-mmcount\-ra\-address\fR
+.Sp
+\&\fI\s-1MMIX\s0 Options\fR
+\&\fB\-mlibfuncs  \-mno\-libfuncs  \-mepsilon  \-mno\-epsilon  \-mabi=gnu 
+\&\-mabi=mmixware  \-mzero\-extend  \-mknuthdiv  \-mtoplevel\-symbols 
+\&\-melf  \-mbranch\-predict  \-mno\-branch\-predict  \-mbase\-addresses 
+\&\-mno\-base\-addresses  \-msingle\-exit  \-mno\-single\-exit\fR
+.Sp
+\&\fI\s-1MN10300\s0 Options\fR
+\&\fB\-mmult\-bug  \-mno\-mult\-bug 
+\&\-mno\-am33 \-mam33 \-mam33\-2 \-mam34 
+\&\-mtune=\fR\fIcpu-type\fR 
+\&\fB\-mreturn\-pointer\-on\-d0 
+\&\-mno\-crt0  \-mrelax \-mliw \-msetlb\fR
+.Sp
+\&\fIMoxie Options\fR
+\&\fB\-meb \-mel \-mno\-crt0\fR
+.Sp
+\&\fI\s-1MSP430\s0 Options\fR
+\&\fB\-msim \-masm\-hex \-mmcu= \-mcpu= \-mlarge \-msmall \-mrelax\fR
+.Sp
+\&\fI\s-1NDS32\s0 Options\fR
+\&\fB\-mbig\-endian \-mlittle\-endian 
+\&\-mreduced\-regs \-mfull\-regs 
+\&\-mcmov \-mno\-cmov 
+\&\-mperf\-ext \-mno\-perf\-ext 
+\&\-mv3push \-mno\-v3push 
+\&\-m16bit \-mno\-16bit 
+\&\-mgp\-direct \-mno\-gp\-direct 
+\&\-misr\-vector\-size=\fR\fInum\fR 
+\&\fB\-mcache\-block\-size=\fR\fInum\fR 
+\&\fB\-march=\fR\fIarch\fR 
+\&\fB\-mforce\-fp\-as\-gp \-mforbid\-fp\-as\-gp 
+\&\-mex9 \-mctor\-dtor \-mrelax\fR
+.Sp
+\&\fINios \s-1II\s0 Options\fR
+\&\fB\-G\fR \fInum\fR \fB\-mgpopt \-mno\-gpopt \-mel \-meb 
+\&\-mno\-bypass\-cache \-mbypass\-cache 
+\&\-mno\-cache\-volatile \-mcache\-volatile 
+\&\-mno\-fast\-sw\-div \-mfast\-sw\-div 
+\&\-mhw\-mul \-mno\-hw\-mul \-mhw\-mulx \-mno\-hw\-mulx \-mno\-hw\-div \-mhw\-div 
+\&\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR \fB\-mno\-custom\-\fR\fIinsn\fR 
+\&\fB\-mcustom\-fpu\-cfg=\fR\fIname\fR 
+\&\fB\-mhal \-msmallc \-msys\-crt0=\fR\fIname\fR \fB\-msys\-lib=\fR\fIname\fR
+.Sp
+\&\fI\s-1PDP\-11\s0 Options\fR
+\&\fB\-mfpu  \-msoft\-float  \-mac0  \-mno\-ac0  \-m40  \-m45  \-m10 
+\&\-mbcopy  \-mbcopy\-builtin  \-mint32  \-mno\-int16 
+\&\-mint16  \-mno\-int32  \-mfloat32  \-mno\-float64 
+\&\-mfloat64  \-mno\-float32  \-mabshi  \-mno\-abshi 
+\&\-mbranch\-expensive  \-mbranch\-cheap 
+\&\-munix\-asm  \-mdec\-asm\fR
+.Sp
+\&\fIpicoChip Options\fR
+\&\fB\-mae=\fR\fIae_type\fR \fB\-mvliw\-lookahead=\fR\fIN\fR 
+\&\fB\-msymbol\-as\-address \-mno\-inefficient\-warnings\fR
+.Sp
+\&\fIPowerPC Options\fR
+See \s-1RS/6000\s0 and PowerPC Options.
+.Sp
+\&\fI\s-1RL78\s0 Options\fR
+\&\fB\-msim \-mmul=none \-mmul=g13 \-mmul=rl78\fR
+.Sp
+\&\fI\s-1RS/6000\s0 and PowerPC Options\fR
+\&\fB\-mcpu=\fR\fIcpu-type\fR 
+\&\fB\-mtune=\fR\fIcpu-type\fR 
+\&\fB\-mcmodel=\fR\fIcode-model\fR 
+\&\fB\-mpowerpc64 
+\&\-maltivec  \-mno\-altivec 
+\&\-mpowerpc\-gpopt  \-mno\-powerpc\-gpopt 
+\&\-mpowerpc\-gfxopt  \-mno\-powerpc\-gfxopt 
+\&\-mmfcrf  \-mno\-mfcrf  \-mpopcntb  \-mno\-popcntb \-mpopcntd \-mno\-popcntd 
+\&\-mfprnd  \-mno\-fprnd 
+\&\-mcmpb \-mno\-cmpb \-mmfpgpr \-mno\-mfpgpr \-mhard\-dfp \-mno\-hard\-dfp 
+\&\-mfull\-toc   \-mminimal\-toc  \-mno\-fp\-in\-toc  \-mno\-sum\-in\-toc 
+\&\-m64  \-m32  \-mxl\-compat  \-mno\-xl\-compat  \-mpe 
+\&\-malign\-power  \-malign\-natural 
+\&\-msoft\-float  \-mhard\-float  \-mmultiple  \-mno\-multiple 
+\&\-msingle\-float \-mdouble\-float \-msimple\-fpu 
+\&\-mstring  \-mno\-string  \-mupdate  \-mno\-update 
+\&\-mavoid\-indexed\-addresses  \-mno\-avoid\-indexed\-addresses 
+\&\-mfused\-madd  \-mno\-fused\-madd  \-mbit\-align  \-mno\-bit\-align 
+\&\-mstrict\-align  \-mno\-strict\-align  \-mrelocatable 
+\&\-mno\-relocatable  \-mrelocatable\-lib  \-mno\-relocatable\-lib 
+\&\-mtoc  \-mno\-toc  \-mlittle  \-mlittle\-endian  \-mbig  \-mbig\-endian 
+\&\-mdynamic\-no\-pic  \-maltivec \-mswdiv  \-msingle\-pic\-base 
+\&\-mprioritize\-restricted\-insns=\fR\fIpriority\fR 
+\&\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR 
+\&\fB\-minsert\-sched\-nops=\fR\fIscheme\fR 
+\&\fB\-mcall\-sysv  \-mcall\-netbsd 
+\&\-maix\-struct\-return  \-msvr4\-struct\-return 
+\&\-mabi=\fR\fIabi-type\fR \fB\-msecure\-plt \-mbss\-plt 
+\&\-mblock\-move\-inline\-limit=\fR\fInum\fR 
+\&\fB\-misel \-mno\-isel 
+\&\-misel=yes  \-misel=no 
+\&\-mspe \-mno\-spe 
+\&\-mspe=yes  \-mspe=no 
+\&\-mpaired 
+\&\-mgen\-cell\-microcode \-mwarn\-cell\-microcode 
+\&\-mvrsave \-mno\-vrsave 
+\&\-mmulhw \-mno\-mulhw 
+\&\-mdlmzb \-mno\-dlmzb 
+\&\-mfloat\-gprs=yes  \-mfloat\-gprs=no \-mfloat\-gprs=single \-mfloat\-gprs=double 
+\&\-mprototype  \-mno\-prototype 
+\&\-msim  \-mmvme  \-mads  \-myellowknife  \-memb  \-msdata 
+\&\-msdata=\fR\fIopt\fR  \fB\-mvxworks  \-G\fR \fInum\fR  \fB\-pthread 
+\&\-mrecip \-mrecip=\fR\fIopt\fR \fB\-mno\-recip \-mrecip\-precision 
+\&\-mno\-recip\-precision 
+\&\-mveclibabi=\fR\fItype\fR \fB\-mfriz \-mno\-friz 
+\&\-mpointers\-to\-nested\-functions \-mno\-pointers\-to\-nested\-functions 
+\&\-msave\-toc\-indirect \-mno\-save\-toc\-indirect 
+\&\-mpower8\-fusion \-mno\-mpower8\-fusion \-mpower8\-vector \-mno\-power8\-vector 
+\&\-mcrypto \-mno\-crypto \-mdirect\-move \-mno\-direct\-move 
+\&\-mquad\-memory \-mno\-quad\-memory 
+\&\-mquad\-memory\-atomic \-mno\-quad\-memory\-atomic 
+\&\-mcompat\-align\-parm \-mno\-compat\-align\-parm\fR
+.Sp
+\&\fI\s-1RX\s0 Options\fR
+\&\fB\-m64bit\-doubles  \-m32bit\-doubles  \-fpu  \-nofpu
+\&\-mcpu=
+\&\-mbig\-endian\-data \-mlittle\-endian\-data 
+\&\-msmall\-data 
+\&\-msim  \-mno\-sim
+\&\-mas100\-syntax \-mno\-as100\-syntax
+\&\-mrelax
+\&\-mmax\-constant\-size=
+\&\-mint\-register=
+\&\-mpid
+\&\-mno\-warn\-multiple\-fast\-interrupts
+\&\-msave\-acc\-in\-interrupts\fR
+.Sp
+\&\fIS/390 and zSeries Options\fR
+\&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-march=\fR\fIcpu-type\fR 
+\&\fB\-mhard\-float  \-msoft\-float  \-mhard\-dfp \-mno\-hard\-dfp 
+\&\-mlong\-double\-64 \-mlong\-double\-128 
+\&\-mbackchain  \-mno\-backchain \-mpacked\-stack  \-mno\-packed\-stack 
+\&\-msmall\-exec  \-mno\-small\-exec  \-mmvcle \-mno\-mvcle 
+\&\-m64  \-m31  \-mdebug  \-mno\-debug  \-mesa  \-mzarch 
+\&\-mtpf\-trace \-mno\-tpf\-trace  \-mfused\-madd  \-mno\-fused\-madd 
+\&\-mwarn\-framesize  \-mwarn\-dynamicstack  \-mstack\-size \-mstack\-guard 
+\&\-mhotpatch[=\fR\fIhalfwords\fR\fB] \-mno\-hotpatch\fR
+.Sp
+\&\fIScore Options\fR
+\&\fB\-meb \-mel 
+\&\-mnhwloop 
+\&\-muls 
+\&\-mmac 
+\&\-mscore5 \-mscore5u \-mscore7 \-mscore7d\fR
+.Sp
+\&\fI\s-1SH\s0 Options\fR
+\&\fB\-m1  \-m2  \-m2e 
+\&\-m2a\-nofpu \-m2a\-single\-only \-m2a\-single \-m2a 
+\&\-m3  \-m3e 
+\&\-m4\-nofpu  \-m4\-single\-only  \-m4\-single  \-m4 
+\&\-m4a\-nofpu \-m4a\-single\-only \-m4a\-single \-m4a \-m4al 
+\&\-m5\-64media  \-m5\-64media\-nofpu 
+\&\-m5\-32media  \-m5\-32media\-nofpu 
+\&\-m5\-compact  \-m5\-compact\-nofpu 
+\&\-mb  \-ml  \-mdalign  \-mrelax 
+\&\-mbigtable \-mfmovd \-mhitachi \-mrenesas \-mno\-renesas \-mnomacsave 
+\&\-mieee \-mno\-ieee \-mbitops  \-misize  \-minline\-ic_invalidate \-mpadstruct 
+\&\-mspace \-mprefergot  \-musermode \-multcost=\fR\fInumber\fR \fB\-mdiv=\fR\fIstrategy\fR 
+\&\fB\-mdivsi3_libfunc=\fR\fIname\fR \fB\-mfixed\-range=\fR\fIregister-range\fR 
+\&\fB\-mindexed\-addressing \-mgettrcost=\fR\fInumber\fR \fB\-mpt\-fixed 
+\&\-maccumulate\-outgoing\-args \-minvalid\-symbols 
+\&\-matomic\-model=\fR\fIatomic-model\fR 
+\&\fB\-mbranch\-cost=\fR\fInum\fR \fB\-mzdcbranch \-mno\-zdcbranch 
+\&\-mfused\-madd \-mno\-fused\-madd \-mfsca \-mno\-fsca \-mfsrra \-mno\-fsrra 
+\&\-mpretend\-cmove \-mtas\fR
+.Sp
+\&\fISolaris 2 Options\fR
+\&\fB\-mimpure\-text  \-mno\-impure\-text 
+\&\-pthreads \-pthread\fR
+.Sp
+\&\fI\s-1SPARC\s0 Options\fR
+\&\fB\-mcpu=\fR\fIcpu-type\fR 
+\&\fB\-mtune=\fR\fIcpu-type\fR 
+\&\fB\-mcmodel=\fR\fIcode-model\fR 
+\&\fB\-mmemory\-model=\fR\fImem-model\fR 
+\&\fB\-m32  \-m64  \-mapp\-regs  \-mno\-app\-regs 
+\&\-mfaster\-structs  \-mno\-faster\-structs  \-mflat  \-mno\-flat 
+\&\-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float 
+\&\-mhard\-quad\-float  \-msoft\-quad\-float 
+\&\-mstack\-bias  \-mno\-stack\-bias 
+\&\-munaligned\-doubles  \-mno\-unaligned\-doubles 
+\&\-mv8plus  \-mno\-v8plus  \-mvis  \-mno\-vis 
+\&\-mvis2  \-mno\-vis2  \-mvis3  \-mno\-vis3 
+\&\-mcbcond \-mno\-cbcond 
+\&\-mfmaf  \-mno\-fmaf  \-mpopc  \-mno\-popc 
+\&\-mfix\-at697f \-mfix\-ut699\fR
+.Sp
+\&\fI\s-1SPU\s0 Options\fR
+\&\fB\-mwarn\-reloc \-merror\-reloc 
+\&\-msafe\-dma \-munsafe\-dma 
+\&\-mbranch\-hints 
+\&\-msmall\-mem \-mlarge\-mem \-mstdmain 
+\&\-mfixed\-range=\fR\fIregister-range\fR 
+\&\fB\-mea32 \-mea64 
+\&\-maddress\-space\-conversion \-mno\-address\-space\-conversion 
+\&\-mcache\-size=\fR\fIcache-size\fR 
+\&\fB\-matomic\-updates \-mno\-atomic\-updates\fR
+.Sp
+\&\fISystem V Options\fR
+\&\fB\-Qy  \-Qn  \-YP,\fR\fIpaths\fR  \fB\-Ym,\fR\fIdir\fR
+.Sp
+\&\fITILE-Gx Options\fR
+\&\fB\-mcpu=CPU \-m32 \-m64 \-mbig\-endian \-mlittle\-endian 
+\&\-mcmodel=\fR\fIcode-model\fR
+.Sp
+\&\fITILEPro Options\fR
+\&\fB\-mcpu=\fR\fIcpu\fR \fB\-m32\fR
+.Sp
+\&\fIV850 Options\fR
+\&\fB\-mlong\-calls  \-mno\-long\-calls  \-mep  \-mno\-ep 
+\&\-mprolog\-function  \-mno\-prolog\-function  \-mspace 
+\&\-mtda=\fR\fIn\fR  \fB\-msda=\fR\fIn\fR  \fB\-mzda=\fR\fIn\fR 
+\&\fB\-mapp\-regs  \-mno\-app\-regs 
+\&\-mdisable\-callt  \-mno\-disable\-callt 
+\&\-mv850e2v3 \-mv850e2 \-mv850e1 \-mv850es 
+\&\-mv850e \-mv850 \-mv850e3v5 
+\&\-mloop 
+\&\-mrelax 
+\&\-mlong\-jumps 
+\&\-msoft\-float 
+\&\-mhard\-float 
+\&\-mgcc\-abi 
+\&\-mrh850\-abi 
+\&\-mbig\-switch\fR
+.Sp
+\&\fI\s-1VAX\s0 Options\fR
+\&\fB\-mg  \-mgnu  \-munix\fR
+.Sp
+\&\fI\s-1VMS\s0 Options\fR
+\&\fB\-mvms\-return\-codes \-mdebug\-main=\fR\fIprefix\fR \fB\-mmalloc64 
+\&\-mpointer\-size=\fR\fIsize\fR
+.Sp
+\&\fIVxWorks Options\fR
+\&\fB\-mrtp  \-non\-static  \-Bstatic  \-Bdynamic 
+\&\-Xbind\-lazy  \-Xbind\-now\fR
+.Sp
+\&\fIx86\-64 Options\fR
+See i386 and x86\-64 Options.
+.Sp
+\&\fIXstormy16 Options\fR
+\&\fB\-msim\fR
+.Sp
+\&\fIXtensa Options\fR
+\&\fB\-mconst16 \-mno\-const16 
+\&\-mfused\-madd  \-mno\-fused\-madd 
+\&\-mforce\-no\-pic 
+\&\-mserialize\-volatile  \-mno\-serialize\-volatile 
+\&\-mtext\-section\-literals  \-mno\-text\-section\-literals 
+\&\-mtarget\-align  \-mno\-target\-align 
+\&\-mlongcalls  \-mno\-longcalls\fR
+.Sp
+\&\fIzSeries Options\fR
+See S/390 and zSeries Options.
+.IP "\fICode Generation Options\fR" 4
+.IX Item "Code Generation Options"
+\&\fB\-fcall\-saved\-\fR\fIreg\fR  \fB\-fcall\-used\-\fR\fIreg\fR 
+\&\fB\-ffixed\-\fR\fIreg\fR  \fB\-fexceptions 
+\&\-fnon\-call\-exceptions  \-fdelete\-dead\-exceptions  \-funwind\-tables 
+\&\-fasynchronous\-unwind\-tables 
+\&\-fno\-gnu\-unique 
+\&\-finhibit\-size\-directive  \-finstrument\-functions 
+\&\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,... 
+\&\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,... 
+\&\-fno\-common  \-fno\-ident 
+\&\-fpcc\-struct\-return  \-fpic  \-fPIC \-fpie \-fPIE 
+\&\-fno\-jump\-tables 
+\&\-frecord\-gcc\-switches 
+\&\-freg\-struct\-return  \-fshort\-enums 
+\&\-fshort\-double  \-fshort\-wchar 
+\&\-fverbose\-asm  \-fpack\-struct[=\fR\fIn\fR\fB]  \-fstack\-check 
+\&\-fstack\-limit\-register=\fR\fIreg\fR  \fB\-fstack\-limit\-symbol=\fR\fIsym\fR 
+\&\fB\-fno\-stack\-limit \-fsplit\-stack 
+\&\-fleading\-underscore  \-ftls\-model=\fR\fImodel\fR 
+\&\fB\-fstack\-reuse=\fR\fIreuse_level\fR 
+\&\fB\-ftrapv  \-fwrapv  \-fbounds\-check 
+\&\-fvisibility \-fstrict\-volatile\-bitfields \-fsync\-libcalls\fR
+.SS "Options Controlling the Kind of Output"
+.IX Subsection "Options Controlling the Kind of Output"
+Compilation can involve up to four stages: preprocessing, compilation
+proper, assembly and linking, always in that order.  \s-1GCC\s0 is capable of
+preprocessing and compiling several files either into several
+assembler input files, or into one assembler input file; then each
+assembler input file produces an object file, and linking combines all
+the object files (those newly compiled, and those specified as input)
+into an executable file.
+.PP
+For any given input file, the file name suffix determines what kind of
+compilation is done:
+.IP "\fIfile\fR\fB.c\fR" 4
+.IX Item "file.c"
+C source code that must be preprocessed.
+.IP "\fIfile\fR\fB.i\fR" 4
+.IX Item "file.i"
+C source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.ii\fR" 4
+.IX Item "file.ii"
+\&\*(C+ source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.m\fR" 4
+.IX Item "file.m"
+Objective-C source code.  Note that you must link with the \fIlibobjc\fR
+library to make an Objective-C program work.
+.IP "\fIfile\fR\fB.mi\fR" 4
+.IX Item "file.mi"
+Objective-C source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.mm\fR" 4
+.IX Item "file.mm"
+.PD 0
+.IP "\fIfile\fR\fB.M\fR" 4
+.IX Item "file.M"
+.PD
+Objective\-\*(C+ source code.  Note that you must link with the \fIlibobjc\fR
+library to make an Objective\-\*(C+ program work.  Note that \fB.M\fR refers
+to a literal capital M.
+.IP "\fIfile\fR\fB.mii\fR" 4
+.IX Item "file.mii"
+Objective\-\*(C+ source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.h\fR" 4
+.IX Item "file.h"
+C, \*(C+, Objective-C or Objective\-\*(C+ header file to be turned into a
+precompiled header (default), or C, \*(C+ header file to be turned into an
+Ada spec (via the \fB\-fdump\-ada\-spec\fR switch).
+.IP "\fIfile\fR\fB.cc\fR" 4
+.IX Item "file.cc"
+.PD 0
+.IP "\fIfile\fR\fB.cp\fR" 4
+.IX Item "file.cp"
+.IP "\fIfile\fR\fB.cxx\fR" 4
+.IX Item "file.cxx"
+.IP "\fIfile\fR\fB.cpp\fR" 4
+.IX Item "file.cpp"
+.IP "\fIfile\fR\fB.CPP\fR" 4
+.IX Item "file.CPP"
+.IP "\fIfile\fR\fB.c++\fR" 4
+.IX Item "file.c++"
+.IP "\fIfile\fR\fB.C\fR" 4
+.IX Item "file.C"
+.PD
+\&\*(C+ source code that must be preprocessed.  Note that in \fB.cxx\fR,
+the last two letters must both be literally \fBx\fR.  Likewise,
+\&\fB.C\fR refers to a literal capital C.
+.IP "\fIfile\fR\fB.mm\fR" 4
+.IX Item "file.mm"
+.PD 0
+.IP "\fIfile\fR\fB.M\fR" 4
+.IX Item "file.M"
+.PD
+Objective\-\*(C+ source code that must be preprocessed.
+.IP "\fIfile\fR\fB.mii\fR" 4
+.IX Item "file.mii"
+Objective\-\*(C+ source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.hh\fR" 4
+.IX Item "file.hh"
+.PD 0
+.IP "\fIfile\fR\fB.H\fR" 4
+.IX Item "file.H"
+.IP "\fIfile\fR\fB.hp\fR" 4
+.IX Item "file.hp"
+.IP "\fIfile\fR\fB.hxx\fR" 4
+.IX Item "file.hxx"
+.IP "\fIfile\fR\fB.hpp\fR" 4
+.IX Item "file.hpp"
+.IP "\fIfile\fR\fB.HPP\fR" 4
+.IX Item "file.HPP"
+.IP "\fIfile\fR\fB.h++\fR" 4
+.IX Item "file.h++"
+.IP "\fIfile\fR\fB.tcc\fR" 4
+.IX Item "file.tcc"
+.PD
+\&\*(C+ header file to be turned into a precompiled header or Ada spec.
+.IP "\fIfile\fR\fB.f\fR" 4
+.IX Item "file.f"
+.PD 0
+.IP "\fIfile\fR\fB.for\fR" 4
+.IX Item "file.for"
+.IP "\fIfile\fR\fB.ftn\fR" 4
+.IX Item "file.ftn"
+.PD
+Fixed form Fortran source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.F\fR" 4
+.IX Item "file.F"
+.PD 0
+.IP "\fIfile\fR\fB.FOR\fR" 4
+.IX Item "file.FOR"
+.IP "\fIfile\fR\fB.fpp\fR" 4
+.IX Item "file.fpp"
+.IP "\fIfile\fR\fB.FPP\fR" 4
+.IX Item "file.FPP"
+.IP "\fIfile\fR\fB.FTN\fR" 4
+.IX Item "file.FTN"
+.PD
+Fixed form Fortran source code that must be preprocessed (with the traditional
+preprocessor).
+.IP "\fIfile\fR\fB.f90\fR" 4
+.IX Item "file.f90"
+.PD 0
+.IP "\fIfile\fR\fB.f95\fR" 4
+.IX Item "file.f95"
+.IP "\fIfile\fR\fB.f03\fR" 4
+.IX Item "file.f03"
+.IP "\fIfile\fR\fB.f08\fR" 4
+.IX Item "file.f08"
+.PD
+Free form Fortran source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.F90\fR" 4
+.IX Item "file.F90"
+.PD 0
+.IP "\fIfile\fR\fB.F95\fR" 4
+.IX Item "file.F95"
+.IP "\fIfile\fR\fB.F03\fR" 4
+.IX Item "file.F03"
+.IP "\fIfile\fR\fB.F08\fR" 4
+.IX Item "file.F08"
+.PD
+Free form Fortran source code that must be preprocessed (with the
+traditional preprocessor).
+.IP "\fIfile\fR\fB.go\fR" 4
+.IX Item "file.go"
+Go source code.
+.IP "\fIfile\fR\fB.ads\fR" 4
+.IX Item "file.ads"
+Ada source code file that contains a library unit declaration (a
+declaration of a package, subprogram, or generic, or a generic
+instantiation), or a library unit renaming declaration (a package,
+generic, or subprogram renaming declaration).  Such files are also
+called \fIspecs\fR.
+.IP "\fIfile\fR\fB.adb\fR" 4
+.IX Item "file.adb"
+Ada source code file containing a library unit body (a subprogram or
+package body).  Such files are also called \fIbodies\fR.
+.IP "\fIfile\fR\fB.s\fR" 4
+.IX Item "file.s"
+Assembler code.
+.IP "\fIfile\fR\fB.S\fR" 4
+.IX Item "file.S"
+.PD 0
+.IP "\fIfile\fR\fB.sx\fR" 4
+.IX Item "file.sx"
+.PD
+Assembler code that must be preprocessed.
+.IP "\fIother\fR" 4
+.IX Item "other"
+An object file to be fed straight into linking.
+Any file name with no recognized suffix is treated this way.
+.PP
+You can specify the input language explicitly with the \fB\-x\fR option:
+.IP "\fB\-x\fR \fIlanguage\fR" 4
+.IX Item "-x language"
+Specify explicitly the \fIlanguage\fR for the following input files
+(rather than letting the compiler choose a default based on the file
+name suffix).  This option applies to all following input files until
+the next \fB\-x\fR option.  Possible values for \fIlanguage\fR are:
+.Sp
+.Vb 9
+\&        c  c\-header  cpp\-output
+\&        c++  c++\-header  c++\-cpp\-output
+\&        objective\-c  objective\-c\-header  objective\-c\-cpp\-output
+\&        objective\-c++ objective\-c++\-header objective\-c++\-cpp\-output
+\&        assembler  assembler\-with\-cpp
+\&        ada
+\&        f77  f77\-cpp\-input f95  f95\-cpp\-input
+\&        go
+\&        java
+.Ve
+.IP "\fB\-x none\fR" 4
+.IX Item "-x none"
+Turn off any specification of a language, so that subsequent files are
+handled according to their file name suffixes (as they are if \fB\-x\fR
+has not been used at all).
+.IP "\fB\-pass\-exit\-codes\fR" 4
+.IX Item "-pass-exit-codes"
+Normally the \fBgcc\fR program exits with the code of 1 if any
+phase of the compiler returns a non-success return code.  If you specify
+\&\fB\-pass\-exit\-codes\fR, the \fBgcc\fR program instead returns with
+the numerically highest error produced by any phase returning an error
+indication.  The C, \*(C+, and Fortran front ends return 4 if an internal
+compiler error is encountered.
+.PP
+If you only want some of the stages of compilation, you can use
+\&\fB\-x\fR (or filename suffixes) to tell \fBgcc\fR where to start, and
+one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where
+\&\fBgcc\fR is to stop.  Note that some combinations (for example,
+\&\fB\-x cpp-output \-E\fR) instruct \fBgcc\fR to do nothing at all.
+.IP "\fB\-c\fR" 4
+.IX Item "-c"
+Compile or assemble the source files, but do not link.  The linking
+stage simply is not done.  The ultimate output is in the form of an
+object file for each source file.
+.Sp
+By default, the object file name for a source file is made by replacing
+the suffix \fB.c\fR, \fB.i\fR, \fB.s\fR, etc., with \fB.o\fR.
+.Sp
+Unrecognized input files, not requiring compilation or assembly, are
+ignored.
+.IP "\fB\-S\fR" 4
+.IX Item "-S"
+Stop after the stage of compilation proper; do not assemble.  The output
+is in the form of an assembler code file for each non-assembler input
+file specified.
+.Sp
+By default, the assembler file name for a source file is made by
+replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR.
+.Sp
+Input files that don't require compilation are ignored.
+.IP "\fB\-E\fR" 4
+.IX Item "-E"
+Stop after the preprocessing stage; do not run the compiler proper.  The
+output is in the form of preprocessed source code, which is sent to the
+standard output.
+.Sp
+Input files that don't require preprocessing are ignored.
+.IP "\fB\-o\fR \fIfile\fR" 4
+.IX Item "-o file"
+Place output in file \fIfile\fR.  This applies to whatever
+sort of output is being produced, whether it be an executable file,
+an object file, an assembler file or preprocessed C code.
+.Sp
+If \fB\-o\fR is not specified, the default is to put an executable
+file in \fIa.out\fR, the object file for
+\&\fI\fIsource\fI.\fIsuffix\fI\fR in \fI\fIsource\fI.o\fR, its
+assembler file in \fI\fIsource\fI.s\fR, a precompiled header file in
+\&\fI\fIsource\fI.\fIsuffix\fI.gch\fR, and all preprocessed C source on
+standard output.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+Print (on standard error output) the commands executed to run the stages
+of compilation.  Also print the version number of the compiler driver
+program and of the preprocessor and the compiler proper.
+.IP "\fB\-###\fR" 4
+.IX Item "-###"
+Like \fB\-v\fR except the commands are not executed and arguments
+are quoted unless they contain only alphanumeric characters or \f(CW\*(C`./\-_\*(C'\fR.
+This is useful for shell scripts to capture the driver-generated command lines.
+.IP "\fB\-pipe\fR" 4
+.IX Item "-pipe"
+Use pipes rather than temporary files for communication between the
+various stages of compilation.  This fails to work on some systems where
+the assembler is unable to read from a pipe; but the \s-1GNU\s0 assembler has
+no trouble.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+Print (on the standard output) a description of the command-line options
+understood by \fBgcc\fR.  If the \fB\-v\fR option is also specified
+then \fB\-\-help\fR is also passed on to the various processes
+invoked by \fBgcc\fR, so that they can display the command-line options
+they accept.  If the \fB\-Wextra\fR option has also been specified
+(prior to the \fB\-\-help\fR option), then command-line options that
+have no documentation associated with them are also displayed.
+.IP "\fB\-\-target\-help\fR" 4
+.IX Item "--target-help"
+Print (on the standard output) a description of target-specific command-line
+options for each tool.  For some targets extra target-specific
+information may also be printed.
+.IP "\fB\-\-help={\fR\fIclass\fR|[\fB^\fR]\fIqualifier\fR\fB}\fR[\fB,...\fR]" 4
+.IX Item "--help={class|[^]qualifier}[,...]"
+Print (on the standard output) a description of the command-line
+options understood by the compiler that fit into all specified classes
+and qualifiers.  These are the supported classes:
+.RS 4
+.IP "\fBoptimizers\fR" 4
+.IX Item "optimizers"
+Display all of the optimization options supported by the
+compiler.
+.IP "\fBwarnings\fR" 4
+.IX Item "warnings"
+Display all of the options controlling warning messages
+produced by the compiler.
+.IP "\fBtarget\fR" 4
+.IX Item "target"
+Display target-specific options.  Unlike the
+\&\fB\-\-target\-help\fR option however, target-specific options of the
+linker and assembler are not displayed.  This is because those
+tools do not currently support the extended \fB\-\-help=\fR syntax.
+.IP "\fBparams\fR" 4
+.IX Item "params"
+Display the values recognized by the \fB\-\-param\fR
+option.
+.IP "\fIlanguage\fR" 4
+.IX Item "language"
+Display the options supported for \fIlanguage\fR, where
+\&\fIlanguage\fR is the name of one of the languages supported in this
+version of \s-1GCC.\s0
+.IP "\fBcommon\fR" 4
+.IX Item "common"
+Display the options that are common to all languages.
+.RE
+.RS 4
+.Sp
+These are the supported qualifiers:
+.IP "\fBundocumented\fR" 4
+.IX Item "undocumented"
+Display only those options that are undocumented.
+.IP "\fBjoined\fR" 4
+.IX Item "joined"
+Display options taking an argument that appears after an equal
+sign in the same continuous piece of text, such as:
+\&\fB\-\-help=target\fR.
+.IP "\fBseparate\fR" 4
+.IX Item "separate"
+Display options taking an argument that appears as a separate word
+following the original option, such as: \fB\-o output-file\fR.
+.RE
+.RS 4
+.Sp
+Thus for example to display all the undocumented target-specific
+switches supported by the compiler, use:
+.Sp
+.Vb 1
+\&        \-\-help=target,undocumented
+.Ve
+.Sp
+The sense of a qualifier can be inverted by prefixing it with the
+\&\fB^\fR character, so for example to display all binary warning
+options (i.e., ones that are either on or off and that do not take an
+argument) that have a description, use:
+.Sp
+.Vb 1
+\&        \-\-help=warnings,^joined,^undocumented
+.Ve
+.Sp
+The argument to \fB\-\-help=\fR should not consist solely of inverted
+qualifiers.
+.Sp
+Combining several classes is possible, although this usually
+restricts the output so much that there is nothing to display.  One
+case where it does work, however, is when one of the classes is
+\&\fItarget\fR.  For example, to display all the target-specific
+optimization options, use:
+.Sp
+.Vb 1
+\&        \-\-help=target,optimizers
+.Ve
+.Sp
+The \fB\-\-help=\fR option can be repeated on the command line.  Each
+successive use displays its requested class of options, skipping
+those that have already been displayed.
+.Sp
+If the \fB\-Q\fR option appears on the command line before the
+\&\fB\-\-help=\fR option, then the descriptive text displayed by
+\&\fB\-\-help=\fR is changed.  Instead of describing the displayed
+options, an indication is given as to whether the option is enabled,
+disabled or set to a specific value (assuming that the compiler
+knows this at the point where the \fB\-\-help=\fR option is used).
+.Sp
+Here is a truncated example from the \s-1ARM\s0 port of \fBgcc\fR:
+.Sp
+.Vb 5
+\&          % gcc \-Q \-mabi=2 \-\-help=target \-c
+\&          The following options are target specific:
+\&          \-mabi=                                2
+\&          \-mabort\-on\-noreturn                   [disabled]
+\&          \-mapcs                                [disabled]
+.Ve
+.Sp
+The output is sensitive to the effects of previous command-line
+options, so for example it is possible to find out which optimizations
+are enabled at \fB\-O2\fR by using:
+.Sp
+.Vb 1
+\&        \-Q \-O2 \-\-help=optimizers
+.Ve
+.Sp
+Alternatively you can discover which binary optimizations are enabled
+by \fB\-O3\fR by using:
+.Sp
+.Vb 3
+\&        gcc \-c \-Q \-O3 \-\-help=optimizers > /tmp/O3\-opts
+\&        gcc \-c \-Q \-O2 \-\-help=optimizers > /tmp/O2\-opts
+\&        diff /tmp/O2\-opts /tmp/O3\-opts | grep enabled
+.Ve
+.RE
+.IP "\fB\-no\-canonical\-prefixes\fR" 4
+.IX Item "-no-canonical-prefixes"
+Do not expand any symbolic links, resolve references to \fB/../\fR
+or \fB/./\fR, or make the path absolute when generating a relative
+prefix.
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+Display the version number and copyrights of the invoked \s-1GCC.\s0
+.IP "\fB\-wrapper\fR" 4
+.IX Item "-wrapper"
+Invoke all subcommands under a wrapper program.  The name of the
+wrapper program and its parameters are passed as a comma separated
+list.
+.Sp
+.Vb 1
+\&        gcc \-c t.c \-wrapper gdb,\-\-args
+.Ve
+.Sp
+This invokes all subprograms of \fBgcc\fR under
+\&\fBgdb \-\-args\fR, thus the invocation of \fBcc1\fR is
+\&\fBgdb \-\-args cc1 ...\fR.
+.IP "\fB\-fplugin=\fR\fIname\fR\fB.so\fR" 4
+.IX Item "-fplugin=name.so"
+Load the plugin code in file \fIname\fR.so, assumed to be a
+shared object to be dlopen'd by the compiler.  The base name of
+the shared object file is used to identify the plugin for the
+purposes of argument parsing (See
+\&\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR below).
+Each plugin should define the callback functions specified in the
+Plugins \s-1API.\s0
+.IP "\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR" 4
+.IX Item "-fplugin-arg-name-key=value"
+Define an argument called \fIkey\fR with a value of \fIvalue\fR
+for the plugin called \fIname\fR.
+.IP "\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR]" 4
+.IX Item "-fdump-ada-spec[-slim]"
+For C and \*(C+ source and include files, generate corresponding Ada specs.
+.IP "\fB\-fada\-spec\-parent=\fR\fIunit\fR" 4
+.IX Item "-fada-spec-parent=unit"
+In conjunction with \fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] above, generate
+Ada specs as child units of parent \fIunit\fR.
+.IP "\fB\-fdump\-go\-spec=\fR\fIfile\fR" 4
+.IX Item "-fdump-go-spec=file"
+For input files in any language, generate corresponding Go
+declarations in \fIfile\fR.  This generates Go \f(CW\*(C`const\*(C'\fR,
+\&\f(CW\*(C`type\*(C'\fR, \f(CW\*(C`var\*(C'\fR, and \f(CW\*(C`func\*(C'\fR declarations which may be a
+useful way to start writing a Go interface to code written in some
+other language.
+.IP "\fB@\fR\fIfile\fR" 4
+.IX Item "@file"
+Read command-line options from \fIfile\fR.  The options read are
+inserted in place of the original @\fIfile\fR option.  If \fIfile\fR
+does not exist, or cannot be read, then the option will be treated
+literally, and not removed.
+.Sp
+Options in \fIfile\fR are separated by whitespace.  A whitespace
+character may be included in an option by surrounding the entire
+option in either single or double quotes.  Any character (including a
+backslash) may be included by prefixing the character to be included
+with a backslash.  The \fIfile\fR may itself contain additional
+@\fIfile\fR options; any such options will be processed recursively.
+.SS "Compiling \*(C+ Programs"
+.IX Subsection "Compiling Programs"
+\&\*(C+ source files conventionally use one of the suffixes \fB.C\fR,
+\&\fB.cc\fR, \fB.cpp\fR, \fB.CPP\fR, \fB.c++\fR, \fB.cp\fR, or
+\&\fB.cxx\fR; \*(C+ header files often use \fB.hh\fR, \fB.hpp\fR,
+\&\fB.H\fR, or (for shared template code) \fB.tcc\fR; and
+preprocessed \*(C+ files use the suffix \fB.ii\fR.  \s-1GCC\s0 recognizes
+files with these names and compiles them as \*(C+ programs even if you
+call the compiler the same way as for compiling C programs (usually
+with the name \fBgcc\fR).
+.PP
+However, the use of \fBgcc\fR does not add the \*(C+ library.
+\&\fBg++\fR is a program that calls \s-1GCC\s0 and automatically specifies linking
+against the \*(C+ library.  It treats \fB.c\fR,
+\&\fB.h\fR and \fB.i\fR files as \*(C+ source files instead of C source
+files unless \fB\-x\fR is used.  This program is also useful when
+precompiling a C header file with a \fB.h\fR extension for use in \*(C+
+compilations.  On many systems, \fBg++\fR is also installed with
+the name \fBc++\fR.
+.PP
+When you compile \*(C+ programs, you may specify many of the same
+command-line options that you use for compiling programs in any
+language; or command-line options meaningful for C and related
+languages; or options that are meaningful only for \*(C+ programs.
+.SS "Options Controlling C Dialect"
+.IX Subsection "Options Controlling C Dialect"
+The following options control the dialect of C (or languages derived
+from C, such as \*(C+, Objective-C and Objective\-\*(C+) that the compiler
+accepts:
+.IP "\fB\-ansi\fR" 4
+.IX Item "-ansi"
+In C mode, this is equivalent to \fB\-std=c90\fR. In \*(C+ mode, it is
+equivalent to \fB\-std=c++98\fR.
+.Sp
+This turns off certain features of \s-1GCC\s0 that are incompatible with \s-1ISO
+C90 \s0(when compiling C code), or of standard \*(C+ (when compiling \*(C+ code),
+such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, and
+predefined macros such as \f(CW\*(C`unix\*(C'\fR and \f(CW\*(C`vax\*(C'\fR that identify the
+type of system you are using.  It also enables the undesirable and
+rarely used \s-1ISO\s0 trigraph feature.  For the C compiler,
+it disables recognition of \*(C+ style \fB//\fR comments as well as
+the \f(CW\*(C`inline\*(C'\fR keyword.
+.Sp
+The alternate keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_extension_\|_\*(C'\fR,
+\&\f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR continue to work despite
+\&\fB\-ansi\fR.  You would not want to use them in an \s-1ISO C\s0 program, of
+course, but it is useful to put them in header files that might be included
+in compilations done with \fB\-ansi\fR.  Alternate predefined macros
+such as \f(CW\*(C`_\|_unix_\|_\*(C'\fR and \f(CW\*(C`_\|_vax_\|_\*(C'\fR are also available, with or
+without \fB\-ansi\fR.
+.Sp
+The \fB\-ansi\fR option does not cause non-ISO programs to be
+rejected gratuitously.  For that, \fB\-Wpedantic\fR is required in
+addition to \fB\-ansi\fR.
+.Sp
+The macro \f(CW\*(C`_\|_STRICT_ANSI_\|_\*(C'\fR is predefined when the \fB\-ansi\fR
+option is used.  Some header files may notice this macro and refrain
+from declaring certain functions or defining certain macros that the
+\&\s-1ISO\s0 standard doesn't call for; this is to avoid interfering with any
+programs that might use these names for other things.
+.Sp
+Functions that are normally built in but do not have semantics
+defined by \s-1ISO C \s0(such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in
+functions when \fB\-ansi\fR is used.
+.IP "\fB\-std=\fR" 4
+.IX Item "-std="
+Determine the language standard.   This option
+is currently only supported when compiling C or \*(C+.
+.Sp
+The compiler can accept several base standards, such as \fBc90\fR or
+\&\fBc++98\fR, and \s-1GNU\s0 dialects of those standards, such as
+\&\fBgnu90\fR or \fBgnu++98\fR.  When a base standard is specified, the
+compiler accepts all programs following that standard plus those
+using \s-1GNU\s0 extensions that do not contradict it.  For example,
+\&\fB\-std=c90\fR turns off certain features of \s-1GCC\s0 that are
+incompatible with \s-1ISO C90,\s0 such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR
+keywords, but not other \s-1GNU\s0 extensions that do not have a meaning in
+\&\s-1ISO C90,\s0 such as omitting the middle term of a \f(CW\*(C`?:\*(C'\fR
+expression. On the other hand, when a \s-1GNU\s0 dialect of a standard is
+specified, all features supported by the compiler are enabled, even when
+those features change the meaning of the base standard.  As a result, some
+strict-conforming programs may be rejected.  The particular standard
+is used by \fB\-Wpedantic\fR to identify which features are \s-1GNU\s0
+extensions given that version of the standard. For example
+\&\fB\-std=gnu90 \-Wpedantic\fR warns about \*(C+ style \fB//\fR
+comments, while \fB\-std=gnu99 \-Wpedantic\fR does not.
+.Sp
+A value for this option must be provided; possible values are
+.RS 4
+.IP "\fBc90\fR" 4
+.IX Item "c90"
+.PD 0
+.IP "\fBc89\fR" 4
+.IX Item "c89"
+.IP "\fBiso9899:1990\fR" 4
+.IX Item "iso9899:1990"
+.PD
+Support all \s-1ISO C90\s0 programs (certain \s-1GNU\s0 extensions that conflict
+with \s-1ISO C90\s0 are disabled). Same as \fB\-ansi\fR for C code.
+.IP "\fBiso9899:199409\fR" 4
+.IX Item "iso9899:199409"
+\&\s-1ISO C90\s0 as modified in amendment 1.
+.IP "\fBc99\fR" 4
+.IX Item "c99"
+.PD 0
+.IP "\fBc9x\fR" 4
+.IX Item "c9x"
+.IP "\fBiso9899:1999\fR" 4
+.IX Item "iso9899:1999"
+.IP "\fBiso9899:199x\fR" 4
+.IX Item "iso9899:199x"
+.PD
+\&\s-1ISO C99. \s0 This standard is substantially completely supported, modulo
+bugs, extended identifiers (supported except for corner cases when
+\&\fB\-fextended\-identifiers\fR is used) and floating-point issues
+(mainly but not entirely relating to optional C99 features from
+Annexes F and G).  See
+<\fBhttp://gcc.gnu.org/c99status.html\fR> for more information.  The
+names \fBc9x\fR and \fBiso9899:199x\fR are deprecated.
+.IP "\fBc11\fR" 4
+.IX Item "c11"
+.PD 0
+.IP "\fBc1x\fR" 4
+.IX Item "c1x"
+.IP "\fBiso9899:2011\fR" 4
+.IX Item "iso9899:2011"
+.PD
+\&\s-1ISO C11,\s0 the 2011 revision of the \s-1ISO C\s0 standard.  This standard is
+substantially completely supported, modulo bugs, extended identifiers
+(supported except for corner cases when
+\&\fB\-fextended\-identifiers\fR is used), floating-point issues
+(mainly but not entirely relating to optional C11 features from
+Annexes F and G) and the optional Annexes K (Bounds-checking
+interfaces) and L (Analyzability).  The name \fBc1x\fR is deprecated.
+.IP "\fBgnu90\fR" 4
+.IX Item "gnu90"
+.PD 0
+.IP "\fBgnu89\fR" 4
+.IX Item "gnu89"
+.PD
+\&\s-1GNU\s0 dialect of \s-1ISO C90 \s0(including some C99 features). This
+is the default for C code.
+.IP "\fBgnu99\fR" 4
+.IX Item "gnu99"
+.PD 0
+.IP "\fBgnu9x\fR" 4
+.IX Item "gnu9x"
+.PD
+\&\s-1GNU\s0 dialect of \s-1ISO C99. \s0 The name \fBgnu9x\fR is deprecated.
+.IP "\fBgnu11\fR" 4
+.IX Item "gnu11"
+.PD 0
+.IP "\fBgnu1x\fR" 4
+.IX Item "gnu1x"
+.PD
+\&\s-1GNU\s0 dialect of \s-1ISO C11. \s0 This is intended to become the default in a
+future release of \s-1GCC. \s0 The name \fBgnu1x\fR is deprecated.
+.IP "\fBc++98\fR" 4
+.IX Item "c++98"
+.PD 0
+.IP "\fBc++03\fR" 4
+.IX Item "c++03"
+.PD
+The 1998 \s-1ISO \*(C+\s0 standard plus the 2003 technical corrigendum and some
+additional defect reports. Same as \fB\-ansi\fR for \*(C+ code.
+.IP "\fBgnu++98\fR" 4
+.IX Item "gnu++98"
+.PD 0
+.IP "\fBgnu++03\fR" 4
+.IX Item "gnu++03"
+.PD
+\&\s-1GNU\s0 dialect of \fB\-std=c++98\fR.  This is the default for
+\&\*(C+ code.
+.IP "\fBc++11\fR" 4
+.IX Item "c++11"
+.PD 0
+.IP "\fBc++0x\fR" 4
+.IX Item "c++0x"
+.PD
+The 2011 \s-1ISO \*(C+\s0 standard plus amendments.
+The name \fBc++0x\fR is deprecated.
+.IP "\fBgnu++11\fR" 4
+.IX Item "gnu++11"
+.PD 0
+.IP "\fBgnu++0x\fR" 4
+.IX Item "gnu++0x"
+.PD
+\&\s-1GNU\s0 dialect of \fB\-std=c++11\fR.
+The name \fBgnu++0x\fR is deprecated.
+.IP "\fBc++1y\fR" 4
+.IX Item "c++1y"
+The next revision of the \s-1ISO \*(C+\s0 standard, tentatively planned for
+2014.  Support is highly experimental, and will almost certainly
+change in incompatible ways in future releases.
+.IP "\fBgnu++1y\fR" 4
+.IX Item "gnu++1y"
+\&\s-1GNU\s0 dialect of \fB\-std=c++1y\fR.  Support is highly experimental,
+and will almost certainly change in incompatible ways in future
+releases.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fgnu89\-inline\fR" 4
+.IX Item "-fgnu89-inline"
+The option \fB\-fgnu89\-inline\fR tells \s-1GCC\s0 to use the traditional
+\&\s-1GNU\s0 semantics for \f(CW\*(C`inline\*(C'\fR functions when in C99 mode.
+  This option
+is accepted and ignored by \s-1GCC\s0 versions 4.1.3 up to but not including
+4.3.  In \s-1GCC\s0 versions 4.3 and later it changes the behavior of \s-1GCC\s0 in
+C99 mode.  Using this option is roughly equivalent to adding the
+\&\f(CW\*(C`gnu_inline\*(C'\fR function attribute to all inline functions.
+.Sp
+The option \fB\-fno\-gnu89\-inline\fR explicitly tells \s-1GCC\s0 to use the
+C99 semantics for \f(CW\*(C`inline\*(C'\fR when in C99 or gnu99 mode (i.e., it
+specifies the default behavior).  This option was first supported in
+\&\s-1GCC 4.3. \s0 This option is not supported in \fB\-std=c90\fR or
+\&\fB\-std=gnu90\fR mode.
+.Sp
+The preprocessor macros \f(CW\*(C`_\|_GNUC_GNU_INLINE_\|_\*(C'\fR and
+\&\f(CW\*(C`_\|_GNUC_STDC_INLINE_\|_\*(C'\fR may be used to check which semantics are
+in effect for \f(CW\*(C`inline\*(C'\fR functions.
+.IP "\fB\-aux\-info\fR \fIfilename\fR" 4
+.IX Item "-aux-info filename"
+Output to the given filename prototyped declarations for all functions
+declared and/or defined in a translation unit, including those in header
+files.  This option is silently ignored in any language other than C.
+.Sp
+Besides declarations, the file indicates, in comments, the origin of
+each declaration (source file and line), whether the declaration was
+implicit, prototyped or unprototyped (\fBI\fR, \fBN\fR for new or
+\&\fBO\fR for old, respectively, in the first character after the line
+number and the colon), and whether it came from a declaration or a
+definition (\fBC\fR or \fBF\fR, respectively, in the following
+character).  In the case of function definitions, a K&R\-style list of
+arguments followed by their declarations is also provided, inside
+comments, after the declaration.
+.IP "\fB\-fallow\-parameterless\-variadic\-functions\fR" 4
+.IX Item "-fallow-parameterless-variadic-functions"
+Accept variadic functions without named parameters.
+.Sp
+Although it is possible to define such a function, this is not very
+useful as it is not possible to read the arguments.  This is only
+supported for C as this construct is allowed by \*(C+.
+.IP "\fB\-fno\-asm\fR" 4
+.IX Item "-fno-asm"
+Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a
+keyword, so that code can use these words as identifiers.  You can use
+the keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR
+instead.  \fB\-ansi\fR implies \fB\-fno\-asm\fR.
+.Sp
+In \*(C+, this switch only affects the \f(CW\*(C`typeof\*(C'\fR keyword, since
+\&\f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`inline\*(C'\fR are standard keywords.  You may want to
+use the \fB\-fno\-gnu\-keywords\fR flag instead, which has the same
+effect.  In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this
+switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, since
+\&\f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO C99.\s0
+.IP "\fB\-fno\-builtin\fR" 4
+.IX Item "-fno-builtin"
+.PD 0
+.IP "\fB\-fno\-builtin\-\fR\fIfunction\fR" 4
+.IX Item "-fno-builtin-function"
+.PD
+Don't recognize built-in functions that do not begin with
+\&\fB_\|_builtin_\fR as prefix.
+.Sp
+\&\s-1GCC\s0 normally generates special code to handle certain built-in functions
+more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
+instructions which adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
+may become inline copy loops.  The resulting code is often both smaller
+and faster, but since the function calls no longer appear as such, you
+cannot set a breakpoint on those calls, nor can you change the behavior
+of the functions by linking with a different library.  In addition,
+when a function is recognized as a built-in function, \s-1GCC\s0 may use
+information about that function to warn about problems with calls to
+that function, or to generate more efficient code, even if the
+resulting code still contains calls to that function.  For example,
+warnings are given with \fB\-Wformat\fR for bad calls to
+\&\f(CW\*(C`printf\*(C'\fR when \f(CW\*(C`printf\*(C'\fR is built in and \f(CW\*(C`strlen\*(C'\fR is
+known not to modify global memory.
+.Sp
+With the \fB\-fno\-builtin\-\fR\fIfunction\fR option
+only the built-in function \fIfunction\fR is
+disabled.  \fIfunction\fR must not begin with \fB_\|_builtin_\fR.  If a
+function is named that is not built-in in this version of \s-1GCC,\s0 this
+option is ignored.  There is no corresponding
+\&\fB\-fbuiltin\-\fR\fIfunction\fR option; if you wish to enable
+built-in functions selectively when using \fB\-fno\-builtin\fR or
+\&\fB\-ffreestanding\fR, you may define macros such as:
+.Sp
+.Vb 2
+\&        #define abs(n)          _\|_builtin_abs ((n))
+\&        #define strcpy(d, s)    _\|_builtin_strcpy ((d), (s))
+.Ve
+.IP "\fB\-fhosted\fR" 4
+.IX Item "-fhosted"
+Assert that compilation targets a hosted environment.  This implies
+\&\fB\-fbuiltin\fR.  A hosted environment is one in which the
+entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return
+type of \f(CW\*(C`int\*(C'\fR.  Examples are nearly everything except a kernel.
+This is equivalent to \fB\-fno\-freestanding\fR.
+.IP "\fB\-ffreestanding\fR" 4
+.IX Item "-ffreestanding"
+Assert that compilation targets a freestanding environment.  This
+implies \fB\-fno\-builtin\fR.  A freestanding environment
+is one in which the standard library may not exist, and program startup may
+not necessarily be at \f(CW\*(C`main\*(C'\fR.  The most obvious example is an \s-1OS\s0 kernel.
+This is equivalent to \fB\-fno\-hosted\fR.
+.IP "\fB\-fopenmp\fR" 4
+.IX Item "-fopenmp"
+Enable handling of OpenMP directives \f(CW\*(C`#pragma omp\*(C'\fR in C/\*(C+ and
+\&\f(CW\*(C`!$omp\*(C'\fR in Fortran.  When \fB\-fopenmp\fR is specified, the
+compiler generates parallel code according to the OpenMP Application
+Program Interface v4.0 <\fBhttp://www.openmp.org/\fR>.  This option
+implies \fB\-pthread\fR, and thus is only supported on targets that
+have support for \fB\-pthread\fR. \fB\-fopenmp\fR implies
+\&\fB\-fopenmp\-simd\fR.
+.IP "\fB\-fopenmp\-simd\fR" 4
+.IX Item "-fopenmp-simd"
+Enable handling of OpenMP's \s-1SIMD\s0 directives with \f(CW\*(C`#pragma omp\*(C'\fR
+in C/\*(C+ and \f(CW\*(C`!$omp\*(C'\fR in Fortran. Other OpenMP directives
+are ignored.
+.IP "\fB\-fcilkplus\fR" 4
+.IX Item "-fcilkplus"
+Enable the usage of Cilk Plus language extension features for C/\*(C+.
+When the option \fB\-fcilkplus\fR is specified, enable the usage of
+the Cilk Plus Language extension features for C/\*(C+.  The present
+implementation follows \s-1ABI\s0 version 1.2.  This is an experimental
+feature that is only partially complete, and whose interface may
+change in future versions of \s-1GCC\s0 as the official specification
+changes.  Currently, all features but \f(CW\*(C`_Cilk_for\*(C'\fR have been
+implemented.
+.IP "\fB\-fgnu\-tm\fR" 4
+.IX Item "-fgnu-tm"
+When the option \fB\-fgnu\-tm\fR is specified, the compiler
+generates code for the Linux variant of Intel's current Transactional
+Memory \s-1ABI\s0 specification document (Revision 1.1, May 6 2009).  This is
+an experimental feature whose interface may change in future versions
+of \s-1GCC,\s0 as the official specification changes.  Please note that not
+all architectures are supported for this feature.
+.Sp
+For more information on \s-1GCC\s0's support for transactional memory,
+.Sp
+Note that the transactional memory feature is not supported with
+non-call exceptions (\fB\-fnon\-call\-exceptions\fR).
+.IP "\fB\-fms\-extensions\fR" 4
+.IX Item "-fms-extensions"
+Accept some non-standard constructs used in Microsoft header files.
+.Sp
+In \*(C+ code, this allows member names in structures to be similar
+to previous types declarations.
+.Sp
+.Vb 4
+\&        typedef int UOW;
+\&        struct ABC {
+\&          UOW UOW;
+\&        };
+.Ve
+.Sp
+Some cases of unnamed fields in structures and unions are only
+accepted with this option.
+.Sp
+Note that this option is off for all targets but i?86 and x86_64
+targets using ms-abi.
+.IP "\fB\-fplan9\-extensions\fR" 4
+.IX Item "-fplan9-extensions"
+Accept some non-standard constructs used in Plan 9 code.
+.Sp
+This enables \fB\-fms\-extensions\fR, permits passing pointers to
+structures with anonymous fields to functions that expect pointers to
+elements of the type of the field, and permits referring to anonymous
+fields declared using a typedef.    This is only
+supported for C, not \*(C+.
+.IP "\fB\-trigraphs\fR" 4
+.IX Item "-trigraphs"
+Support \s-1ISO C\s0 trigraphs.  The \fB\-ansi\fR option (and \fB\-std\fR
+options for strict \s-1ISO C\s0 conformance) implies \fB\-trigraphs\fR.
+.IP "\fB\-traditional\fR" 4
+.IX Item "-traditional"
+.PD 0
+.IP "\fB\-traditional\-cpp\fR" 4
+.IX Item "-traditional-cpp"
+.PD
+Formerly, these options caused \s-1GCC\s0 to attempt to emulate a pre-standard
+C compiler.  They are now only supported with the \fB\-E\fR switch.
+The preprocessor continues to support a pre-standard mode.  See the \s-1GNU
+CPP\s0 manual for details.
+.IP "\fB\-fcond\-mismatch\fR" 4
+.IX Item "-fcond-mismatch"
+Allow conditional expressions with mismatched types in the second and
+third arguments.  The value of such an expression is void.  This option
+is not supported for \*(C+.
+.IP "\fB\-flax\-vector\-conversions\fR" 4
+.IX Item "-flax-vector-conversions"
+Allow implicit conversions between vectors with differing numbers of
+elements and/or incompatible element types.  This option should not be
+used for new code.
+.IP "\fB\-funsigned\-char\fR" 4
+.IX Item "-funsigned-char"
+Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR.
+.Sp
+Each kind of machine has a default for what \f(CW\*(C`char\*(C'\fR should
+be.  It is either like \f(CW\*(C`unsigned char\*(C'\fR by default or like
+\&\f(CW\*(C`signed char\*(C'\fR by default.
+.Sp
+Ideally, a portable program should always use \f(CW\*(C`signed char\*(C'\fR or
+\&\f(CW\*(C`unsigned char\*(C'\fR when it depends on the signedness of an object.
+But many programs have been written to use plain \f(CW\*(C`char\*(C'\fR and
+expect it to be signed, or expect it to be unsigned, depending on the
+machines they were written for.  This option, and its inverse, let you
+make such a program work with the opposite default.
+.Sp
+The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of
+\&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior
+is always just like one of those two.
+.IP "\fB\-fsigned\-char\fR" 4
+.IX Item "-fsigned-char"
+Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR.
+.Sp
+Note that this is equivalent to \fB\-fno\-unsigned\-char\fR, which is
+the negative form of \fB\-funsigned\-char\fR.  Likewise, the option
+\&\fB\-fno\-signed\-char\fR is equivalent to \fB\-funsigned\-char\fR.
+.IP "\fB\-fsigned\-bitfields\fR" 4
+.IX Item "-fsigned-bitfields"
+.PD 0
+.IP "\fB\-funsigned\-bitfields\fR" 4
+.IX Item "-funsigned-bitfields"
+.IP "\fB\-fno\-signed\-bitfields\fR" 4
+.IX Item "-fno-signed-bitfields"
+.IP "\fB\-fno\-unsigned\-bitfields\fR" 4
+.IX Item "-fno-unsigned-bitfields"
+.PD
+These options control whether a bit-field is signed or unsigned, when the
+declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR.  By
+default, such a bit-field is signed, because this is consistent: the
+basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
+.SS "Options Controlling \*(C+ Dialect"
+.IX Subsection "Options Controlling Dialect"
+This section describes the command-line options that are only meaningful
+for \*(C+ programs.  You can also use most of the \s-1GNU\s0 compiler options
+regardless of what language your program is in.  For example, you
+might compile a file \f(CW\*(C`firstClass.C\*(C'\fR like this:
+.PP
+.Vb 1
+\&        g++ \-g \-frepo \-O \-c firstClass.C
+.Ve
+.PP
+In this example, only \fB\-frepo\fR is an option meant
+only for \*(C+ programs; you can use the other options with any
+language supported by \s-1GCC.\s0
+.PP
+Here is a list of options that are \fIonly\fR for compiling \*(C+ programs:
+.IP "\fB\-fabi\-version=\fR\fIn\fR" 4
+.IX Item "-fabi-version=n"
+Use version \fIn\fR of the \*(C+ \s-1ABI. \s0 The default is version 2.
+.Sp
+Version 0 refers to the version conforming most closely to
+the \*(C+ \s-1ABI\s0 specification.  Therefore, the \s-1ABI\s0 obtained using version 0
+will change in different versions of G++ as \s-1ABI\s0 bugs are fixed.
+.Sp
+Version 1 is the version of the \*(C+ \s-1ABI\s0 that first appeared in G++ 3.2.
+.Sp
+Version 2 is the version of the \*(C+ \s-1ABI\s0 that first appeared in G++ 3.4.
+.Sp
+Version 3 corrects an error in mangling a constant address as a
+template argument.
+.Sp
+Version 4, which first appeared in G++ 4.5, implements a standard
+mangling for vector types.
+.Sp
+Version 5, which first appeared in G++ 4.6, corrects the mangling of
+attribute const/volatile on function pointer types, decltype of a
+plain decl, and use of a function parameter in the declaration of
+another parameter.
+.Sp
+Version 6, which first appeared in G++ 4.7, corrects the promotion
+behavior of \*(C+11 scoped enums and the mangling of template argument
+packs, const/static_cast, prefix ++ and \-\-, and a class scope function
+used as a template argument.
+.Sp
+See also \fB\-Wabi\fR.
+.IP "\fB\-fno\-access\-control\fR" 4
+.IX Item "-fno-access-control"
+Turn off all access checking.  This switch is mainly useful for working
+around bugs in the access control code.
+.IP "\fB\-fcheck\-new\fR" 4
+.IX Item "-fcheck-new"
+Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non-null
+before attempting to modify the storage allocated.  This check is
+normally unnecessary because the \*(C+ standard specifies that
+\&\f(CW\*(C`operator new\*(C'\fR only returns \f(CW0\fR if it is declared
+\&\fB\f(BIthrow()\fB\fR, in which case the compiler always checks the
+return value even without this option.  In all other cases, when
+\&\f(CW\*(C`operator new\*(C'\fR has a non-empty exception specification, memory
+exhaustion is signalled by throwing \f(CW\*(C`std::bad_alloc\*(C'\fR.  See also
+\&\fBnew (nothrow)\fR.
+.IP "\fB\-fconstexpr\-depth=\fR\fIn\fR" 4
+.IX Item "-fconstexpr-depth=n"
+Set the maximum nested evaluation depth for \*(C+11 constexpr functions
+to \fIn\fR.  A limit is needed to detect endless recursion during
+constant expression evaluation.  The minimum specified by the standard
+is 512.
+.IP "\fB\-fdeduce\-init\-list\fR" 4
+.IX Item "-fdeduce-init-list"
+Enable deduction of a template type parameter as
+\&\f(CW\*(C`std::initializer_list\*(C'\fR from a brace-enclosed initializer list, i.e.
+.Sp
+.Vb 4
+\&        template <class T> auto forward(T t) \-> decltype (realfn (t))
+\&        {
+\&          return realfn (t);
+\&        }
+\&        
+\&        void f()
+\&        {
+\&          forward({1,2}); // call forward<std::initializer_list<int>>
+\&        }
+.Ve
+.Sp
+This deduction was implemented as a possible extension to the
+originally proposed semantics for the \*(C+11 standard, but was not part
+of the final standard, so it is disabled by default.  This option is
+deprecated, and may be removed in a future version of G++.
+.IP "\fB\-ffriend\-injection\fR" 4
+.IX Item "-ffriend-injection"
+Inject friend functions into the enclosing namespace, so that they are
+visible outside the scope of the class in which they are declared.
+Friend functions were documented to work this way in the old Annotated
+\&\*(C+ Reference Manual, and versions of G++ before 4.1 always worked
+that way.  However, in \s-1ISO \*(C+\s0 a friend function that is not declared
+in an enclosing scope can only be found using argument dependent
+lookup.  This option causes friends to be injected as they were in
+earlier releases.
+.Sp
+This option is for compatibility, and may be removed in a future
+release of G++.
+.IP "\fB\-fno\-elide\-constructors\fR" 4
+.IX Item "-fno-elide-constructors"
+The \*(C+ standard allows an implementation to omit creating a temporary
+that is only used to initialize another object of the same type.
+Specifying this option disables that optimization, and forces G++ to
+call the copy constructor in all cases.
+.IP "\fB\-fno\-enforce\-eh\-specs\fR" 4
+.IX Item "-fno-enforce-eh-specs"
+Don't generate code to check for violation of exception specifications
+at run time.  This option violates the \*(C+ standard, but may be useful
+for reducing code size in production builds, much like defining
+\&\fB\s-1NDEBUG\s0\fR.  This does not give user code permission to throw
+exceptions in violation of the exception specifications; the compiler
+still optimizes based on the specifications, so throwing an
+unexpected exception results in undefined behavior at run time.
+.IP "\fB\-fextern\-tls\-init\fR" 4
+.IX Item "-fextern-tls-init"
+.PD 0
+.IP "\fB\-fno\-extern\-tls\-init\fR" 4
+.IX Item "-fno-extern-tls-init"
+.PD
+The \*(C+11 and OpenMP standards allow \fBthread_local\fR and
+\&\fBthreadprivate\fR variables to have dynamic (runtime)
+initialization.  To support this, any use of such a variable goes
+through a wrapper function that performs any necessary initialization.
+When the use and definition of the variable are in the same
+translation unit, this overhead can be optimized away, but when the
+use is in a different translation unit there is significant overhead
+even if the variable doesn't actually need dynamic initialization.  If
+the programmer can be sure that no use of the variable in a
+non-defining \s-1TU\s0 needs to trigger dynamic initialization (either
+because the variable is statically initialized, or a use of the
+variable in the defining \s-1TU\s0 will be executed before any uses in
+another \s-1TU\s0), they can avoid this overhead with the
+\&\fB\-fno\-extern\-tls\-init\fR option.
+.Sp
+On targets that support symbol aliases, the default is
+\&\fB\-fextern\-tls\-init\fR.  On targets that do not support symbol
+aliases, the default is \fB\-fno\-extern\-tls\-init\fR.
+.IP "\fB\-ffor\-scope\fR" 4
+.IX Item "-ffor-scope"
+.PD 0
+.IP "\fB\-fno\-for\-scope\fR" 4
+.IX Item "-fno-for-scope"
+.PD
+If \fB\-ffor\-scope\fR is specified, the scope of variables declared in
+a \fIfor-init-statement\fR is limited to the \fBfor\fR loop itself,
+as specified by the \*(C+ standard.
+If \fB\-fno\-for\-scope\fR is specified, the scope of variables declared in
+a \fIfor-init-statement\fR extends to the end of the enclosing scope,
+as was the case in old versions of G++, and other (traditional)
+implementations of \*(C+.
+.Sp
+If neither flag is given, the default is to follow the standard,
+but to allow and give a warning for old-style code that would
+otherwise be invalid, or have different behavior.
+.IP "\fB\-fno\-gnu\-keywords\fR" 4
+.IX Item "-fno-gnu-keywords"
+Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this
+word as an identifier.  You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead.
+\&\fB\-ansi\fR implies \fB\-fno\-gnu\-keywords\fR.
+.IP "\fB\-fno\-implicit\-templates\fR" 4
+.IX Item "-fno-implicit-templates"
+Never emit code for non-inline templates that are instantiated
+implicitly (i.e. by use); only emit code for explicit instantiations.
+.IP "\fB\-fno\-implicit\-inline\-templates\fR" 4
+.IX Item "-fno-implicit-inline-templates"
+Don't emit code for implicit instantiations of inline templates, either.
+The default is to handle inlines differently so that compiles with and
+without optimization need the same set of explicit instantiations.
+.IP "\fB\-fno\-implement\-inlines\fR" 4
+.IX Item "-fno-implement-inlines"
+To save space, do not emit out-of-line copies of inline functions
+controlled by \fB#pragma implementation\fR.  This causes linker
+errors if these functions are not inlined everywhere they are called.
+.IP "\fB\-fms\-extensions\fR" 4
+.IX Item "-fms-extensions"
+Disable Wpedantic warnings about constructs used in \s-1MFC,\s0 such as implicit
+int and getting a pointer to member function via non-standard syntax.
+.IP "\fB\-fno\-nonansi\-builtins\fR" 4
+.IX Item "-fno-nonansi-builtins"
+Disable built-in declarations of functions that are not mandated by
+\&\s-1ANSI/ISO C. \s0 These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
+\&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
+.IP "\fB\-fnothrow\-opt\fR" 4
+.IX Item "-fnothrow-opt"
+Treat a \f(CW\*(C`throw()\*(C'\fR exception specification as if it were a
+\&\f(CW\*(C`noexcept\*(C'\fR specification to reduce or eliminate the text size
+overhead relative to a function with no exception specification.  If
+the function has local variables of types with non-trivial
+destructors, the exception specification actually makes the
+function smaller because the \s-1EH\s0 cleanups for those variables can be
+optimized away.  The semantic effect is that an exception thrown out of
+a function with such an exception specification results in a call
+to \f(CW\*(C`terminate\*(C'\fR rather than \f(CW\*(C`unexpected\*(C'\fR.
+.IP "\fB\-fno\-operator\-names\fR" 4
+.IX Item "-fno-operator-names"
+Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR,
+\&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as
+synonyms as keywords.
+.IP "\fB\-fno\-optional\-diags\fR" 4
+.IX Item "-fno-optional-diags"
+Disable diagnostics that the standard says a compiler does not need to
+issue.  Currently, the only such diagnostic issued by G++ is the one for
+a name having multiple meanings within a class.
+.IP "\fB\-fpermissive\fR" 4
+.IX Item "-fpermissive"
+Downgrade some diagnostics about nonconformant code from errors to
+warnings.  Thus, using \fB\-fpermissive\fR allows some
+nonconforming code to compile.
+.IP "\fB\-fno\-pretty\-templates\fR" 4
+.IX Item "-fno-pretty-templates"
+When an error message refers to a specialization of a function
+template, the compiler normally prints the signature of the
+template followed by the template arguments and any typedefs or
+typenames in the signature (e.g. \f(CW\*(C`void f(T) [with T = int]\*(C'\fR
+rather than \f(CW\*(C`void f(int)\*(C'\fR) so that it's clear which template is
+involved.  When an error message refers to a specialization of a class
+template, the compiler omits any template arguments that match
+the default template arguments for that template.  If either of these
+behaviors make it harder to understand the error message rather than
+easier, you can use \fB\-fno\-pretty\-templates\fR to disable them.
+.IP "\fB\-frepo\fR" 4
+.IX Item "-frepo"
+Enable automatic template instantiation at link time.  This option also
+implies \fB\-fno\-implicit\-templates\fR.
+.IP "\fB\-fno\-rtti\fR" 4
+.IX Item "-fno-rtti"
+Disable generation of information about every class with virtual
+functions for use by the \*(C+ run-time type identification features
+(\fBdynamic_cast\fR and \fBtypeid\fR).  If you don't use those parts
+of the language, you can save some space by using this flag.  Note that
+exception handling uses the same information, but G++ generates it as
+needed. The \fBdynamic_cast\fR operator can still be used for casts that
+do not require run-time type information, i.e. casts to \f(CW\*(C`void *\*(C'\fR or to
+unambiguous base classes.
+.IP "\fB\-fstats\fR" 4
+.IX Item "-fstats"
+Emit statistics about front-end processing at the end of the compilation.
+This information is generally only useful to the G++ development team.
+.IP "\fB\-fstrict\-enums\fR" 4
+.IX Item "-fstrict-enums"
+Allow the compiler to optimize using the assumption that a value of
+enumerated type can only be one of the values of the enumeration (as
+defined in the \*(C+ standard; basically, a value that can be
+represented in the minimum number of bits needed to represent all the
+enumerators).  This assumption may not be valid if the program uses a
+cast to convert an arbitrary integer value to the enumerated type.
+.IP "\fB\-ftemplate\-backtrace\-limit=\fR\fIn\fR" 4
+.IX Item "-ftemplate-backtrace-limit=n"
+Set the maximum number of template instantiation notes for a single
+warning or error to \fIn\fR.  The default value is 10.
+.IP "\fB\-ftemplate\-depth=\fR\fIn\fR" 4
+.IX Item "-ftemplate-depth=n"
+Set the maximum instantiation depth for template classes to \fIn\fR.
+A limit on the template instantiation depth is needed to detect
+endless recursions during template class instantiation.  \s-1ANSI/ISO \*(C+\s0
+conforming programs must not rely on a maximum depth greater than 17
+(changed to 1024 in \*(C+11).  The default value is 900, as the compiler
+can run out of stack space before hitting 1024 in some situations.
+.IP "\fB\-fno\-threadsafe\-statics\fR" 4
+.IX Item "-fno-threadsafe-statics"
+Do not emit the extra code to use the routines specified in the \*(C+
+\&\s-1ABI\s0 for thread-safe initialization of local statics.  You can use this
+option to reduce code size slightly in code that doesn't need to be
+thread-safe.
+.IP "\fB\-fuse\-cxa\-atexit\fR" 4
+.IX Item "-fuse-cxa-atexit"
+Register destructors for objects with static storage duration with the
+\&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function.
+This option is required for fully standards-compliant handling of static
+destructors, but only works if your C library supports
+\&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR.
+.IP "\fB\-fno\-use\-cxa\-get\-exception\-ptr\fR" 4
+.IX Item "-fno-use-cxa-get-exception-ptr"
+Don't use the \f(CW\*(C`_\|_cxa_get_exception_ptr\*(C'\fR runtime routine.  This
+causes \f(CW\*(C`std::uncaught_exception\*(C'\fR to be incorrect, but is necessary
+if the runtime routine is not available.
+.IP "\fB\-fvisibility\-inlines\-hidden\fR" 4
+.IX Item "-fvisibility-inlines-hidden"
+This switch declares that the user does not attempt to compare
+pointers to inline functions or methods where the addresses of the two functions
+are taken in different shared objects.
+.Sp
+The effect of this is that \s-1GCC\s0 may, effectively, mark inline methods with
+\&\f(CW\*(C`_\|_attribute_\|_ ((visibility ("hidden")))\*(C'\fR so that they do not
+appear in the export table of a \s-1DSO\s0 and do not require a \s-1PLT\s0 indirection
+when used within the \s-1DSO. \s0 Enabling this option can have a dramatic effect
+on load and link times of a \s-1DSO\s0 as it massively reduces the size of the
+dynamic export table when the library makes heavy use of templates.
+.Sp
+The behavior of this switch is not quite the same as marking the
+methods as hidden directly, because it does not affect static variables
+local to the function or cause the compiler to deduce that
+the function is defined in only one shared object.
+.Sp
+You may mark a method as having a visibility explicitly to negate the
+effect of the switch for that method.  For example, if you do want to
+compare pointers to a particular inline method, you might mark it as
+having default visibility.  Marking the enclosing class with explicit
+visibility has no effect.
+.Sp
+Explicitly instantiated inline methods are unaffected by this option
+as their linkage might otherwise cross a shared library boundary.
+.IP "\fB\-fvisibility\-ms\-compat\fR" 4
+.IX Item "-fvisibility-ms-compat"
+This flag attempts to use visibility settings to make \s-1GCC\s0's \*(C+
+linkage model compatible with that of Microsoft Visual Studio.
+.Sp
+The flag makes these changes to \s-1GCC\s0's linkage model:
+.RS 4
+.IP "1." 4
+It sets the default visibility to \f(CW\*(C`hidden\*(C'\fR, like
+\&\fB\-fvisibility=hidden\fR.
+.IP "2." 4
+Types, but not their members, are not hidden by default.
+.IP "3." 4
+The One Definition Rule is relaxed for types without explicit
+visibility specifications that are defined in more than one
+shared object: those declarations are permitted if they are
+permitted when this option is not used.
+.RE
+.RS 4
+.Sp
+In new code it is better to use \fB\-fvisibility=hidden\fR and
+export those classes that are intended to be externally visible.
+Unfortunately it is possible for code to rely, perhaps accidentally,
+on the Visual Studio behavior.
+.Sp
+Among the consequences of these changes are that static data members
+of the same type with the same name but defined in different shared
+objects are different, so changing one does not change the other;
+and that pointers to function members defined in different shared
+objects may not compare equal.  When this flag is given, it is a
+violation of the \s-1ODR\s0 to define types with the same name differently.
+.RE
+.IP "\fB\-fvtable\-verify=\fR\fIstd|preinit|none\fR" 4
+.IX Item "-fvtable-verify=std|preinit|none"
+Turn on (or off, if using \fB\-fvtable\-verify=none\fR) the security
+feature that verifies at runtime, for every virtual call that is made, that
+the vtable pointer through which the call is made is valid for the type of
+the object, and has not been corrupted or overwritten.  If an invalid vtable
+pointer is detected (at runtime), an error is reported and execution of the
+program is immediately halted.
+.Sp
+This option causes runtime data structures to be built, at program start up,
+for verifying the vtable pointers.  The options \f(CW\*(C`std\*(C'\fR and \f(CW\*(C`preinit\*(C'\fR
+control the timing of when these data structures are built.  In both cases the
+data structures are built before execution reaches 'main'.  The
+\&\fB\-fvtable\-verify=std\fR causes these data structure to be built after the
+shared libraries have been loaded and initialized.
+\&\fB\-fvtable\-verify=preinit\fR causes them to be built before the shared
+libraries have been loaded and initialized.
+.Sp
+If this option appears multiple times in the compiler line, with different
+values specified, 'none' will take highest priority over both 'std' and
+\&'preinit'; 'preinit' will take priority over 'std'.
+.IP "\fB\-fvtv\-debug\fR" 4
+.IX Item "-fvtv-debug"
+Causes debug versions of the runtime functions for the vtable verification 
+feature to be called.  This assumes the \fB\-fvtable\-verify=std\fR or
+\&\fB\-fvtable\-verify=preinit\fR has been used.  This flag will also cause the
+compiler to keep track of which vtable pointers it found for each class, and
+record that information in the file \*(L"vtv_set_ptr_data.log\*(R", in the dump
+file directory on the user's machine.
+.Sp
+Note:  This feature \s-1APPENDS\s0 data to the log file. If you want a fresh log
+file, be sure to delete any existing one.
+.IP "\fB\-fvtv\-counts\fR" 4
+.IX Item "-fvtv-counts"
+This is a debugging flag.  When used in conjunction with
+\&\fB\-fvtable\-verify=std\fR or \fB\-fvtable\-verify=preinit\fR, this
+causes the compiler to keep track of the total number of virtual calls
+it encountered and the number of verifications it inserted.  It also
+counts the number of calls to certain runtime library functions
+that it inserts.  This information, for each compilation unit, is written
+to a file named \*(L"vtv_count_data.log\*(R", in the dump_file directory on
+the user's machine.   It also counts the size of the vtable pointer sets
+for each class, and writes this information to \*(L"vtv_class_set_sizes.log\*(R"
+in the same directory.
+.Sp
+Note:  This feature \s-1APPENDS\s0 data to the log files.  To get a fresh log
+files, be sure to delete any existing ones.
+.IP "\fB\-fno\-weak\fR" 4
+.IX Item "-fno-weak"
+Do not use weak symbol support, even if it is provided by the linker.
+By default, G++ uses weak symbols if they are available.  This
+option exists only for testing, and should not be used by end-users;
+it results in inferior code and has no benefits.  This option may
+be removed in a future release of G++.
+.IP "\fB\-nostdinc++\fR" 4
+.IX Item "-nostdinc++"
+Do not search for header files in the standard directories specific to
+\&\*(C+, but do still search the other standard directories.  (This option
+is used when building the \*(C+ library.)
+.PP
+In addition, these optimization, warning, and code generation options
+have meanings only for \*(C+ programs:
+.IP "\fB\-Wabi\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wabi (C, Objective-C, and Objective- only)"
+Warn when G++ generates code that is probably not compatible with the
+vendor-neutral \*(C+ \s-1ABI. \s0 Although an effort has been made to warn about
+all such cases, there are probably some cases that are not warned about,
+even though G++ is generating incompatible code.  There may also be
+cases where warnings are emitted even though the code that is generated
+is compatible.
+.Sp
+You should rewrite your code to avoid these warnings if you are
+concerned about the fact that code generated by G++ may not be binary
+compatible with code generated by other compilers.
+.Sp
+The known incompatibilities in \fB\-fabi\-version=2\fR (the default) include:
+.RS 4
+.IP "\(bu" 4
+A template with a non-type template parameter of reference type is
+mangled incorrectly:
+.Sp
+.Vb 3
+\&        extern int N;
+\&        template <int &> struct S {};
+\&        void n (S<N>) {2}
+.Ve
+.Sp
+This is fixed in \fB\-fabi\-version=3\fR.
+.IP "\(bu" 4
+\&\s-1SIMD\s0 vector types declared using \f(CW\*(C`_\|_attribute ((vector_size))\*(C'\fR are
+mangled in a non-standard way that does not allow for overloading of
+functions taking vectors of different sizes.
+.Sp
+The mangling is changed in \fB\-fabi\-version=4\fR.
+.RE
+.RS 4
+.Sp
+The known incompatibilities in \fB\-fabi\-version=1\fR include:
+.IP "\(bu" 4
+Incorrect handling of tail-padding for bit-fields.  G++ may attempt to
+pack data into the same byte as a base class.  For example:
+.Sp
+.Vb 2
+\&        struct A { virtual void f(); int f1 : 1; };
+\&        struct B : public A { int f2 : 1; };
+.Ve
+.Sp
+In this case, G++ places \f(CW\*(C`B::f2\*(C'\fR into the same byte
+as \f(CW\*(C`A::f1\*(C'\fR; other compilers do not.  You can avoid this problem
+by explicitly padding \f(CW\*(C`A\*(C'\fR so that its size is a multiple of the
+byte size on your platform; that causes G++ and other compilers to
+lay out \f(CW\*(C`B\*(C'\fR identically.
+.IP "\(bu" 4
+Incorrect handling of tail-padding for virtual bases.  G++ does not use
+tail padding when laying out virtual bases.  For example:
+.Sp
+.Vb 3
+\&        struct A { virtual void f(); char c1; };
+\&        struct B { B(); char c2; };
+\&        struct C : public A, public virtual B {};
+.Ve
+.Sp
+In this case, G++ does not place \f(CW\*(C`B\*(C'\fR into the tail-padding for
+\&\f(CW\*(C`A\*(C'\fR; other compilers do.  You can avoid this problem by
+explicitly padding \f(CW\*(C`A\*(C'\fR so that its size is a multiple of its
+alignment (ignoring virtual base classes); that causes G++ and other
+compilers to lay out \f(CW\*(C`C\*(C'\fR identically.
+.IP "\(bu" 4
+Incorrect handling of bit-fields with declared widths greater than that
+of their underlying types, when the bit-fields appear in a union.  For
+example:
+.Sp
+.Vb 1
+\&        union U { int i : 4096; };
+.Ve
+.Sp
+Assuming that an \f(CW\*(C`int\*(C'\fR does not have 4096 bits, G++ makes the
+union too small by the number of bits in an \f(CW\*(C`int\*(C'\fR.
+.IP "\(bu" 4
+Empty classes can be placed at incorrect offsets.  For example:
+.Sp
+.Vb 1
+\&        struct A {};
+\&        
+\&        struct B {
+\&          A a;
+\&          virtual void f ();
+\&        };
+\&        
+\&        struct C : public B, public A {};
+.Ve
+.Sp
+G++ places the \f(CW\*(C`A\*(C'\fR base class of \f(CW\*(C`C\*(C'\fR at a nonzero offset;
+it should be placed at offset zero.  G++ mistakenly believes that the
+\&\f(CW\*(C`A\*(C'\fR data member of \f(CW\*(C`B\*(C'\fR is already at offset zero.
+.IP "\(bu" 4
+Names of template functions whose types involve \f(CW\*(C`typename\*(C'\fR or
+template template parameters can be mangled incorrectly.
+.Sp
+.Vb 2
+\&        template <typename Q>
+\&        void f(typename Q::X) {}
+\&        
+\&        template <template <typename> class Q>
+\&        void f(typename Q<int>::X) {}
+.Ve
+.Sp
+Instantiations of these templates may be mangled incorrectly.
+.RE
+.RS 4
+.Sp
+It also warns about psABI-related changes.  The known psABI changes at this
+point include:
+.IP "\(bu" 4
+For SysV/x86\-64, unions with \f(CW\*(C`long double\*(C'\fR members are 
+passed in memory as specified in psABI.  For example:
+.Sp
+.Vb 4
+\&        union U {
+\&          long double ld;
+\&          int i;
+\&        };
+.Ve
+.Sp
+\&\f(CW\*(C`union U\*(C'\fR is always passed in memory.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wctor\-dtor\-privacy\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wctor-dtor-privacy ( and Objective- only)"
+Warn when a class seems unusable because all the constructors or
+destructors in that class are private, and it has neither friends nor
+public static member functions.  Also warn if there are no non-private
+methods, and there's at least one private member function that isn't
+a constructor or destructor.
+.IP "\fB\-Wdelete\-non\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wdelete-non-virtual-dtor ( and Objective- only)"
+Warn when \fBdelete\fR is used to destroy an instance of a class that
+has virtual functions and non-virtual destructor. It is unsafe to delete
+an instance of a derived class through a pointer to a base class if the
+base class does not have a virtual destructor.  This warning is enabled
+by \fB\-Wall\fR.
+.IP "\fB\-Wliteral\-suffix\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wliteral-suffix ( and Objective- only)"
+Warn when a string or character literal is followed by a ud-suffix which does
+not begin with an underscore.  As a conforming extension, \s-1GCC\s0 treats such
+suffixes as separate preprocessing tokens in order to maintain backwards
+compatibility with code that uses formatting macros from \f(CW\*(C`<inttypes.h>\*(C'\fR.
+For example:
+.Sp
+.Vb 3
+\&        #define _\|_STDC_FORMAT_MACROS
+\&        #include <inttypes.h>
+\&        #include <stdio.h>
+\&        
+\&        int main() {
+\&          int64_t i64 = 123;
+\&          printf("My int64: %"PRId64"\en", i64);
+\&        }
+.Ve
+.Sp
+In this case, \f(CW\*(C`PRId64\*(C'\fR is treated as a separate preprocessing token.
+.Sp
+This warning is enabled by default.
+.IP "\fB\-Wnarrowing\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wnarrowing ( and Objective- only)"
+Warn when a narrowing conversion prohibited by \*(C+11 occurs within
+\&\fB{ }\fR, e.g.
+.Sp
+.Vb 1
+\&        int i = { 2.2 }; // error: narrowing from double to int
+.Ve
+.Sp
+This flag is included in \fB\-Wall\fR and \fB\-Wc++11\-compat\fR.
+.Sp
+With \fB\-std=c++11\fR, \fB\-Wno\-narrowing\fR suppresses the diagnostic
+required by the standard.  Note that this does not affect the meaning
+of well-formed code; narrowing conversions are still considered
+ill-formed in \s-1SFINAE\s0 context.
+.IP "\fB\-Wnoexcept\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wnoexcept ( and Objective- only)"
+Warn when a noexcept-expression evaluates to false because of a call
+to a function that does not have a non-throwing exception
+specification (i.e. \fB\f(BIthrow()\fB\fR or \fBnoexcept\fR) but is known by
+the compiler to never throw an exception.
+.IP "\fB\-Wnon\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wnon-virtual-dtor ( and Objective- only)"
+Warn when a class has virtual functions and an accessible non-virtual
+destructor itself or in an accessible polymorphic base class, in which
+case it is possible but unsafe to delete an instance of a derived
+class through a pointer to the class itself or base class.  This
+warning is automatically enabled if \fB\-Weffc++\fR is specified.
+.IP "\fB\-Wreorder\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wreorder ( and Objective- only)"
+Warn when the order of member initializers given in the code does not
+match the order in which they must be executed.  For instance:
+.Sp
+.Vb 5
+\&        struct A {
+\&          int i;
+\&          int j;
+\&          A(): j (0), i (1) { }
+\&        };
+.Ve
+.Sp
+The compiler rearranges the member initializers for \fBi\fR
+and \fBj\fR to match the declaration order of the members, emitting
+a warning to that effect.  This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-fext\-numeric\-literals\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-fext-numeric-literals ( and Objective- only)"
+Accept imaginary, fixed-point, or machine-defined
+literal number suffixes as \s-1GNU\s0 extensions.
+When this option is turned off these suffixes are treated
+as \*(C+11 user-defined literal numeric suffixes.
+This is on by default for all pre\-\*(C+11 dialects and all \s-1GNU\s0 dialects:
+\&\fB\-std=c++98\fR, \fB\-std=gnu++98\fR, \fB\-std=gnu++11\fR,
+\&\fB\-std=gnu++1y\fR.
+This option is off by default
+for \s-1ISO \*(C+11\s0 onwards (\fB\-std=c++11\fR, ...).
+.PP
+The following \fB\-W...\fR options are not affected by \fB\-Wall\fR.
+.IP "\fB\-Weffc++\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Weffc++ ( and Objective- only)"
+Warn about violations of the following style guidelines from Scott Meyers'
+\&\fIEffective \*(C+\fR series of books:
+.RS 4
+.IP "\(bu" 4
+Define a copy constructor and an assignment operator for classes
+with dynamically-allocated memory.
+.IP "\(bu" 4
+Prefer initialization to assignment in constructors.
+.IP "\(bu" 4
+Have \f(CW\*(C`operator=\*(C'\fR return a reference to \f(CW*this\fR.
+.IP "\(bu" 4
+Don't try to return a reference when you must return an object.
+.IP "\(bu" 4
+Distinguish between prefix and postfix forms of increment and
+decrement operators.
+.IP "\(bu" 4
+Never overload \f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, or \f(CW\*(C`,\*(C'\fR.
+.RE
+.RS 4
+.Sp
+This option also enables \fB\-Wnon\-virtual\-dtor\fR, which is also
+one of the effective \*(C+ recommendations.  However, the check is
+extended to warn about the lack of virtual destructor in accessible
+non-polymorphic bases classes too.
+.Sp
+When selecting this option, be aware that the standard library
+headers do not obey all of these guidelines; use \fBgrep \-v\fR
+to filter out those warnings.
+.RE
+.IP "\fB\-Wstrict\-null\-sentinel\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wstrict-null-sentinel ( and Objective- only)"
+Warn about the use of an uncasted \f(CW\*(C`NULL\*(C'\fR as sentinel.  When
+compiling only with \s-1GCC\s0 this is a valid sentinel, as \f(CW\*(C`NULL\*(C'\fR is defined
+to \f(CW\*(C`_\|_null\*(C'\fR.  Although it is a null pointer constant rather than a
+null pointer, it is guaranteed to be of the same size as a pointer.
+But this use is not portable across different compilers.
+.IP "\fB\-Wno\-non\-template\-friend\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-non-template-friend ( and Objective- only)"
+Disable warnings when non-templatized friend functions are declared
+within a template.  Since the advent of explicit template specification
+support in G++, if the name of the friend is an unqualified-id (i.e.,
+\&\fBfriend foo(int)\fR), the \*(C+ language specification demands that the
+friend declare or define an ordinary, nontemplate function.  (Section
+14.5.3).  Before G++ implemented explicit specification, unqualified-ids
+could be interpreted as a particular specialization of a templatized
+function.  Because this non-conforming behavior is no longer the default
+behavior for G++, \fB\-Wnon\-template\-friend\fR allows the compiler to
+check existing code for potential trouble spots and is on by default.
+This new compiler behavior can be turned off with
+\&\fB\-Wno\-non\-template\-friend\fR, which keeps the conformant compiler code
+but disables the helpful warning.
+.IP "\fB\-Wold\-style\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wold-style-cast ( and Objective- only)"
+Warn if an old-style (C\-style) cast to a non-void type is used within
+a \*(C+ program.  The new-style casts (\fBdynamic_cast\fR,
+\&\fBstatic_cast\fR, \fBreinterpret_cast\fR, and \fBconst_cast\fR) are
+less vulnerable to unintended effects and much easier to search for.
+.IP "\fB\-Woverloaded\-virtual\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Woverloaded-virtual ( and Objective- only)"
+Warn when a function declaration hides virtual functions from a
+base class.  For example, in:
+.Sp
+.Vb 3
+\&        struct A {
+\&          virtual void f();
+\&        };
+\&        
+\&        struct B: public A {
+\&          void f(int);
+\&        };
+.Ve
+.Sp
+the \f(CW\*(C`A\*(C'\fR class version of \f(CW\*(C`f\*(C'\fR is hidden in \f(CW\*(C`B\*(C'\fR, and code
+like:
+.Sp
+.Vb 2
+\&        B* b;
+\&        b\->f();
+.Ve
+.Sp
+fails to compile.
+.IP "\fB\-Wno\-pmf\-conversions\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-pmf-conversions ( and Objective- only)"
+Disable the diagnostic for converting a bound pointer to member function
+to a plain pointer.
+.IP "\fB\-Wsign\-promo\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wsign-promo ( and Objective- only)"
+Warn when overload resolution chooses a promotion from unsigned or
+enumerated type to a signed type, over a conversion to an unsigned type of
+the same size.  Previous versions of G++ tried to preserve
+unsignedness, but the standard mandates the current behavior.
+.SS "Options Controlling Objective-C and Objective\-\*(C+ Dialects"
+.IX Subsection "Options Controlling Objective-C and Objective- Dialects"
+(\s-1NOTE:\s0 This manual does not describe the Objective-C and Objective\-\*(C+
+languages themselves.
+.PP
+This section describes the command-line options that are only meaningful
+for Objective-C and Objective\-\*(C+ programs.  You can also use most of
+the language-independent \s-1GNU\s0 compiler options.
+For example, you might compile a file \f(CW\*(C`some_class.m\*(C'\fR like this:
+.PP
+.Vb 1
+\&        gcc \-g \-fgnu\-runtime \-O \-c some_class.m
+.Ve
+.PP
+In this example, \fB\-fgnu\-runtime\fR is an option meant only for
+Objective-C and Objective\-\*(C+ programs; you can use the other options with
+any language supported by \s-1GCC.\s0
+.PP
+Note that since Objective-C is an extension of the C language, Objective-C
+compilations may also use options specific to the C front-end (e.g.,
+\&\fB\-Wtraditional\fR).  Similarly, Objective\-\*(C+ compilations may use
+\&\*(C+\-specific options (e.g., \fB\-Wabi\fR).
+.PP
+Here is a list of options that are \fIonly\fR for compiling Objective-C
+and Objective\-\*(C+ programs:
+.IP "\fB\-fconstant\-string\-class=\fR\fIclass-name\fR" 4
+.IX Item "-fconstant-string-class=class-name"
+Use \fIclass-name\fR as the name of the class to instantiate for each
+literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR.  The default
+class name is \f(CW\*(C`NXConstantString\*(C'\fR if the \s-1GNU\s0 runtime is being used, and
+\&\f(CW\*(C`NSConstantString\*(C'\fR if the NeXT runtime is being used (see below).  The
+\&\fB\-fconstant\-cfstrings\fR option, if also present, overrides the
+\&\fB\-fconstant\-string\-class\fR setting and cause \f(CW\*(C`@"..."\*(C'\fR literals
+to be laid out as constant CoreFoundation strings.
+.IP "\fB\-fgnu\-runtime\fR" 4
+.IX Item "-fgnu-runtime"
+Generate object code compatible with the standard \s-1GNU\s0 Objective-C
+runtime.  This is the default for most types of systems.
+.IP "\fB\-fnext\-runtime\fR" 4
+.IX Item "-fnext-runtime"
+Generate output compatible with the NeXT runtime.  This is the default
+for NeXT-based systems, including Darwin and Mac \s-1OS X. \s0 The macro
+\&\f(CW\*(C`_\|_NEXT_RUNTIME_\|_\*(C'\fR is predefined if (and only if) this option is
+used.
+.IP "\fB\-fno\-nil\-receivers\fR" 4
+.IX Item "-fno-nil-receivers"
+Assume that all Objective-C message dispatches (\f(CW\*(C`[receiver
+message:arg]\*(C'\fR) in this translation unit ensure that the receiver is
+not \f(CW\*(C`nil\*(C'\fR.  This allows for more efficient entry points in the
+runtime to be used.  This option is only available in conjunction with
+the NeXT runtime and \s-1ABI\s0 version 0 or 1.
+.IP "\fB\-fobjc\-abi\-version=\fR\fIn\fR" 4
+.IX Item "-fobjc-abi-version=n"
+Use version \fIn\fR of the Objective-C \s-1ABI\s0 for the selected runtime.
+This option is currently supported only for the NeXT runtime.  In that
+case, Version 0 is the traditional (32\-bit) \s-1ABI\s0 without support for
+properties and other Objective-C 2.0 additions.  Version 1 is the
+traditional (32\-bit) \s-1ABI\s0 with support for properties and other
+Objective-C 2.0 additions.  Version 2 is the modern (64\-bit) \s-1ABI. \s0 If
+nothing is specified, the default is Version 0 on 32\-bit target
+machines, and Version 2 on 64\-bit target machines.
+.IP "\fB\-fobjc\-call\-cxx\-cdtors\fR" 4
+.IX Item "-fobjc-call-cxx-cdtors"
+For each Objective-C class, check if any of its instance variables is a
+\&\*(C+ object with a non-trivial default constructor.  If so, synthesize a
+special \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR instance method which runs
+non-trivial default constructors on any such instance variables, in order,
+and then return \f(CW\*(C`self\*(C'\fR.  Similarly, check if any instance variable
+is a \*(C+ object with a non-trivial destructor, and if so, synthesize a
+special \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR method which runs
+all such default destructors, in reverse order.
+.Sp
+The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR
+methods thusly generated only operate on instance variables
+declared in the current Objective-C class, and not those inherited
+from superclasses.  It is the responsibility of the Objective-C
+runtime to invoke all such methods in an object's inheritance
+hierarchy.  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR methods are invoked
+by the runtime immediately after a new object instance is allocated;
+the \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods are invoked immediately
+before the runtime deallocates an object instance.
+.Sp
+As of this writing, only the NeXT runtime on Mac \s-1OS X 10.4\s0 and later has
+support for invoking the \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and
+\&\f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods.
+.IP "\fB\-fobjc\-direct\-dispatch\fR" 4
+.IX Item "-fobjc-direct-dispatch"
+Allow fast jumps to the message dispatcher.  On Darwin this is
+accomplished via the comm page.
+.IP "\fB\-fobjc\-exceptions\fR" 4
+.IX Item "-fobjc-exceptions"
+Enable syntactic support for structured exception handling in
+Objective-C, similar to what is offered by \*(C+ and Java.  This option
+is required to use the Objective-C keywords \f(CW@try\fR,
+\&\f(CW@throw\fR, \f(CW@catch\fR, \f(CW@finally\fR and
+\&\f(CW@synchronized\fR.  This option is available with both the \s-1GNU\s0
+runtime and the NeXT runtime (but not available in conjunction with
+the NeXT runtime on Mac \s-1OS X 10.2\s0 and earlier).
+.IP "\fB\-fobjc\-gc\fR" 4
+.IX Item "-fobjc-gc"
+Enable garbage collection (\s-1GC\s0) in Objective-C and Objective\-\*(C+
+programs.  This option is only available with the NeXT runtime; the
+\&\s-1GNU\s0 runtime has a different garbage collection implementation that
+does not require special compiler flags.
+.IP "\fB\-fobjc\-nilcheck\fR" 4
+.IX Item "-fobjc-nilcheck"
+For the NeXT runtime with version 2 of the \s-1ABI,\s0 check for a nil
+receiver in method invocations before doing the actual method call.
+This is the default and can be disabled using
+\&\fB\-fno\-objc\-nilcheck\fR.  Class methods and super calls are never
+checked for nil in this way no matter what this flag is set to.
+Currently this flag does nothing when the \s-1GNU\s0 runtime, or an older
+version of the NeXT runtime \s-1ABI,\s0 is used.
+.IP "\fB\-fobjc\-std=objc1\fR" 4
+.IX Item "-fobjc-std=objc1"
+Conform to the language syntax of Objective-C 1.0, the language
+recognized by \s-1GCC 4.0. \s0 This only affects the Objective-C additions to
+the C/\*(C+ language; it does not affect conformance to C/\*(C+ standards,
+which is controlled by the separate C/\*(C+ dialect option flags.  When
+this option is used with the Objective-C or Objective\-\*(C+ compiler,
+any Objective-C syntax that is not recognized by \s-1GCC 4.0\s0 is rejected.
+This is useful if you need to make sure that your Objective-C code can
+be compiled with older versions of \s-1GCC.\s0
+.IP "\fB\-freplace\-objc\-classes\fR" 4
+.IX Item "-freplace-objc-classes"
+Emit a special marker instructing \fB\f(BIld\fB\|(1)\fR not to statically link in
+the resulting object file, and allow \fB\f(BIdyld\fB\|(1)\fR to load it in at
+run time instead.  This is used in conjunction with the Fix-and-Continue
+debugging mode, where the object file in question may be recompiled and
+dynamically reloaded in the course of program execution, without the need
+to restart the program itself.  Currently, Fix-and-Continue functionality
+is only available in conjunction with the NeXT runtime on Mac \s-1OS X 10.3\s0
+and later.
+.IP "\fB\-fzero\-link\fR" 4
+.IX Item "-fzero-link"
+When compiling for the NeXT runtime, the compiler ordinarily replaces calls
+to \f(CW\*(C`objc_getClass("...")\*(C'\fR (when the name of the class is known at
+compile time) with static class references that get initialized at load time,
+which improves run-time performance.  Specifying the \fB\-fzero\-link\fR flag
+suppresses this behavior and causes calls to \f(CW\*(C`objc_getClass("...")\*(C'\fR
+to be retained.  This is useful in Zero-Link debugging mode, since it allows
+for individual class implementations to be modified during program execution.
+The \s-1GNU\s0 runtime currently always retains calls to \f(CW\*(C`objc_get_class("...")\*(C'\fR
+regardless of command-line options.
+.IP "\fB\-gen\-decls\fR" 4
+.IX Item "-gen-decls"
+Dump interface declarations for all classes seen in the source file to a
+file named \fI\fIsourcename\fI.decl\fR.
+.IP "\fB\-Wassign\-intercept\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wassign-intercept (Objective-C and Objective- only)"
+Warn whenever an Objective-C assignment is being intercepted by the
+garbage collector.
+.IP "\fB\-Wno\-protocol\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-protocol (Objective-C and Objective- only)"
+If a class is declared to implement a protocol, a warning is issued for
+every method in the protocol that is not implemented by the class.  The
+default behavior is to issue a warning for every method not explicitly
+implemented in the class, even if a method implementation is inherited
+from the superclass.  If you use the \fB\-Wno\-protocol\fR option, then
+methods inherited from the superclass are considered to be implemented,
+and no warning is issued for them.
+.IP "\fB\-Wselector\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wselector (Objective-C and Objective- only)"
+Warn if multiple methods of different types for the same selector are
+found during compilation.  The check is performed on the list of methods
+in the final stage of compilation.  Additionally, a check is performed
+for each selector appearing in a \f(CW\*(C`@selector(...)\*(C'\fR
+expression, and a corresponding method for that selector has been found
+during compilation.  Because these checks scan the method table only at
+the end of compilation, these warnings are not produced if the final
+stage of compilation is not reached, for example because an error is
+found during compilation, or because the \fB\-fsyntax\-only\fR option is
+being used.
+.IP "\fB\-Wstrict\-selector\-match\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wstrict-selector-match (Objective-C and Objective- only)"
+Warn if multiple methods with differing argument and/or return types are
+found for a given selector when attempting to send a message using this
+selector to a receiver of type \f(CW\*(C`id\*(C'\fR or \f(CW\*(C`Class\*(C'\fR.  When this flag
+is off (which is the default behavior), the compiler omits such warnings
+if any differences found are confined to types that share the same size
+and alignment.
+.IP "\fB\-Wundeclared\-selector\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wundeclared-selector (Objective-C and Objective- only)"
+Warn if a \f(CW\*(C`@selector(...)\*(C'\fR expression referring to an
+undeclared selector is found.  A selector is considered undeclared if no
+method with that name has been declared before the
+\&\f(CW\*(C`@selector(...)\*(C'\fR expression, either explicitly in an
+\&\f(CW@interface\fR or \f(CW@protocol\fR declaration, or implicitly in
+an \f(CW@implementation\fR section.  This option always performs its
+checks as soon as a \f(CW\*(C`@selector(...)\*(C'\fR expression is found,
+while \fB\-Wselector\fR only performs its checks in the final stage of
+compilation.  This also enforces the coding style convention
+that methods and selectors must be declared before being used.
+.IP "\fB\-print\-objc\-runtime\-info\fR" 4
+.IX Item "-print-objc-runtime-info"
+Generate C header describing the largest structure that is passed by
+value, if any.
+.SS "Options to Control Diagnostic Messages Formatting"
+.IX Subsection "Options to Control Diagnostic Messages Formatting"
+Traditionally, diagnostic messages have been formatted irrespective of
+the output device's aspect (e.g. its width, ...).  You can use the
+options described below
+to control the formatting algorithm for diagnostic messages, 
+e.g. how many characters per line, how often source location
+information should be reported.  Note that some language front ends may not
+honor these options.
+.IP "\fB\-fmessage\-length=\fR\fIn\fR" 4
+.IX Item "-fmessage-length=n"
+Try to format error messages so that they fit on lines of about \fIn\fR
+characters.  The default is 72 characters for \fBg++\fR and 0 for the rest of
+the front ends supported by \s-1GCC. \s0 If \fIn\fR is zero, then no
+line-wrapping is done; each error message appears on a single
+line.
+.IP "\fB\-fdiagnostics\-show\-location=once\fR" 4
+.IX Item "-fdiagnostics-show-location=once"
+Only meaningful in line-wrapping mode.  Instructs the diagnostic messages
+reporter to emit source location information \fIonce\fR; that is, in
+case the message is too long to fit on a single physical line and has to
+be wrapped, the source location won't be emitted (as prefix) again,
+over and over, in subsequent continuation lines.  This is the default
+behavior.
+.IP "\fB\-fdiagnostics\-show\-location=every\-line\fR" 4
+.IX Item "-fdiagnostics-show-location=every-line"
+Only meaningful in line-wrapping mode.  Instructs the diagnostic
+messages reporter to emit the same source location information (as
+prefix) for physical lines that result from the process of breaking
+a message which is too long to fit on a single line.
+.IP "\fB\-fdiagnostics\-color[=\fR\fI\s-1WHEN\s0\fR\fB]\fR" 4
+.IX Item "-fdiagnostics-color[=WHEN]"
+.PD 0
+.IP "\fB\-fno\-diagnostics\-color\fR" 4
+.IX Item "-fno-diagnostics-color"
+.PD
+Use color in diagnostics.  \fI\s-1WHEN\s0\fR is \fBnever\fR, \fBalways\fR,
+or \fBauto\fR.  The default is \fBnever\fR if \fB\s-1GCC_COLORS\s0\fR environment
+variable isn't present in the environment, and \fBauto\fR otherwise.
+\&\fBauto\fR means to use color only when the standard error is a terminal.
+The forms \fB\-fdiagnostics\-color\fR and \fB\-fno\-diagnostics\-color\fR are
+aliases for \fB\-fdiagnostics\-color=always\fR and
+\&\fB\-fdiagnostics\-color=never\fR, respectively.
+.Sp
+The colors are defined by the environment variable \fB\s-1GCC_COLORS\s0\fR.
+Its value is a colon-separated list of capabilities and Select Graphic
+Rendition (\s-1SGR\s0) substrings. \s-1SGR\s0 commands are interpreted by the
+terminal or terminal emulator.  (See the section in the documentation
+of your text terminal for permitted values and their meanings as
+character attributes.)  These substring values are integers in decimal
+representation and can be concatenated with semicolons.
+Common values to concatenate include
+\&\fB1\fR for bold,
+\&\fB4\fR for underline,
+\&\fB5\fR for blink,
+\&\fB7\fR for inverse,
+\&\fB39\fR for default foreground color,
+\&\fB30\fR to \fB37\fR for foreground colors,
+\&\fB90\fR to \fB97\fR for 16\-color mode foreground colors,
+\&\fB38;5;0\fR to \fB38;5;255\fR
+for 88\-color and 256\-color modes foreground colors,
+\&\fB49\fR for default background color,
+\&\fB40\fR to \fB47\fR for background colors,
+\&\fB100\fR to \fB107\fR for 16\-color mode background colors,
+and \fB48;5;0\fR to \fB48;5;255\fR
+for 88\-color and 256\-color modes background colors.
+.Sp
+The default \fB\s-1GCC_COLORS\s0\fR is
+\&\fBerror=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01\fR
+where \fB01;31\fR is bold red, \fB01;35\fR is bold magenta,
+\&\fB01;36\fR is bold cyan, \fB01;32\fR is bold green and
+\&\fB01\fR is bold. Setting \fB\s-1GCC_COLORS\s0\fR to the empty
+string disables colors.
+Supported capabilities are as follows.
+.RS 4
+.ie n .IP """error=""" 4
+.el .IP "\f(CWerror=\fR" 4
+.IX Item "error="
+\&\s-1SGR\s0 substring for error: markers.
+.ie n .IP """warning=""" 4
+.el .IP "\f(CWwarning=\fR" 4
+.IX Item "warning="
+\&\s-1SGR\s0 substring for warning: markers.
+.ie n .IP """note=""" 4
+.el .IP "\f(CWnote=\fR" 4
+.IX Item "note="
+\&\s-1SGR\s0 substring for note: markers.
+.ie n .IP """caret=""" 4
+.el .IP "\f(CWcaret=\fR" 4
+.IX Item "caret="
+\&\s-1SGR\s0 substring for caret line.
+.ie n .IP """locus=""" 4
+.el .IP "\f(CWlocus=\fR" 4
+.IX Item "locus="
+\&\s-1SGR\s0 substring for location information, \fBfile:line\fR or
+\&\fBfile:line:column\fR etc.
+.ie n .IP """quote=""" 4
+.el .IP "\f(CWquote=\fR" 4
+.IX Item "quote="
+\&\s-1SGR\s0 substring for information printed within quotes.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fno\-diagnostics\-show\-option\fR" 4
+.IX Item "-fno-diagnostics-show-option"
+By default, each diagnostic emitted includes text indicating the
+command-line option that directly controls the diagnostic (if such an
+option is known to the diagnostic machinery).  Specifying the
+\&\fB\-fno\-diagnostics\-show\-option\fR flag suppresses that behavior.
+.IP "\fB\-fno\-diagnostics\-show\-caret\fR" 4
+.IX Item "-fno-diagnostics-show-caret"
+By default, each diagnostic emitted includes the original source line
+and a caret '^' indicating the column.  This option suppresses this
+information.
+.SS "Options to Request or Suppress Warnings"
+.IX Subsection "Options to Request or Suppress Warnings"
+Warnings are diagnostic messages that report constructions that
+are not inherently erroneous but that are risky or suggest there
+may have been an error.
+.PP
+The following language-independent options do not enable specific
+warnings but control the kinds of diagnostics produced by \s-1GCC.\s0
+.IP "\fB\-fsyntax\-only\fR" 4
+.IX Item "-fsyntax-only"
+Check the code for syntax errors, but don't do anything beyond that.
+.IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
+.IX Item "-fmax-errors=n"
+Limits the maximum number of error messages to \fIn\fR, at which point
+\&\s-1GCC\s0 bails out rather than attempting to continue processing the source
+code.  If \fIn\fR is 0 (the default), there is no limit on the number
+of error messages produced.  If \fB\-Wfatal\-errors\fR is also
+specified, then \fB\-Wfatal\-errors\fR takes precedence over this
+option.
+.IP "\fB\-w\fR" 4
+.IX Item "-w"
+Inhibit all warning messages.
+.IP "\fB\-Werror\fR" 4
+.IX Item "-Werror"
+Make all warnings into errors.
+.IP "\fB\-Werror=\fR" 4
+.IX Item "-Werror="
+Make the specified warning into an error.  The specifier for a warning
+is appended; for example \fB\-Werror=switch\fR turns the warnings
+controlled by \fB\-Wswitch\fR into errors.  This switch takes a
+negative form, to be used to negate \fB\-Werror\fR for specific
+warnings; for example \fB\-Wno\-error=switch\fR makes
+\&\fB\-Wswitch\fR warnings not be errors, even when \fB\-Werror\fR
+is in effect.
+.Sp
+The warning message for each controllable warning includes the
+option that controls the warning.  That option can then be used with
+\&\fB\-Werror=\fR and \fB\-Wno\-error=\fR as described above.
+(Printing of the option in the warning message can be disabled using the
+\&\fB\-fno\-diagnostics\-show\-option\fR flag.)
+.Sp
+Note that specifying \fB\-Werror=\fR\fIfoo\fR automatically implies
+\&\fB\-W\fR\fIfoo\fR.  However, \fB\-Wno\-error=\fR\fIfoo\fR does not
+imply anything.
+.IP "\fB\-Wfatal\-errors\fR" 4
+.IX Item "-Wfatal-errors"
+This option causes the compiler to abort compilation on the first error
+occurred rather than trying to keep going and printing further error
+messages.
+.PP
+You can request many specific warnings with options beginning with
+\&\fB\-W\fR, for example \fB\-Wimplicit\fR to request warnings on
+implicit declarations.  Each of these specific warning options also
+has a negative form beginning \fB\-Wno\-\fR to turn off warnings; for
+example, \fB\-Wno\-implicit\fR.  This manual lists only one of the
+two forms, whichever is not the default.  For further
+language-specific options also refer to \fB\*(C+ Dialect Options\fR and
+\&\fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
+.PP
+When an unrecognized warning option is requested (e.g.,
+\&\fB\-Wunknown\-warning\fR), \s-1GCC\s0 emits a diagnostic stating
+that the option is not recognized.  However, if the \fB\-Wno\-\fR form
+is used, the behavior is slightly different: no diagnostic is
+produced for \fB\-Wno\-unknown\-warning\fR unless other diagnostics
+are being produced.  This allows the use of new \fB\-Wno\-\fR options
+with old compilers, but if something goes wrong, the compiler
+warns that an unrecognized option is present.
+.IP "\fB\-Wpedantic\fR" 4
+.IX Item "-Wpedantic"
+.PD 0
+.IP "\fB\-pedantic\fR" 4
+.IX Item "-pedantic"
+.PD
+Issue all the warnings demanded by strict \s-1ISO C\s0 and \s-1ISO \*(C+\s0;
+reject all programs that use forbidden extensions, and some other
+programs that do not follow \s-1ISO C\s0 and \s-1ISO \*(C+. \s0 For \s-1ISO C,\s0 follows the
+version of the \s-1ISO C\s0 standard specified by any \fB\-std\fR option used.
+.Sp
+Valid \s-1ISO C\s0 and \s-1ISO \*(C+\s0 programs should compile properly with or without
+this option (though a rare few require \fB\-ansi\fR or a
+\&\fB\-std\fR option specifying the required version of \s-1ISO C\s0).  However,
+without this option, certain \s-1GNU\s0 extensions and traditional C and \*(C+
+features are supported as well.  With this option, they are rejected.
+.Sp
+\&\fB\-Wpedantic\fR does not cause warning messages for use of the
+alternate keywords whose names begin and end with \fB_\|_\fR.  Pedantic
+warnings are also disabled in the expression that follows
+\&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.  However, only system header files should use
+these escape routes; application programs should avoid them.
+.Sp
+Some users try to use \fB\-Wpedantic\fR to check programs for strict \s-1ISO
+C\s0 conformance.  They soon find that it does not do quite what they want:
+it finds some non-ISO practices, but not all\-\-\-only those for which
+\&\s-1ISO C \s0\fIrequires\fR a diagnostic, and some others for which
+diagnostics have been added.
+.Sp
+A feature to report any failure to conform to \s-1ISO C\s0 might be useful in
+some instances, but would require considerable additional work and would
+be quite different from \fB\-Wpedantic\fR.  We don't have plans to
+support such a feature in the near future.
+.Sp
+Where the standard specified with \fB\-std\fR represents a \s-1GNU\s0
+extended dialect of C, such as \fBgnu90\fR or \fBgnu99\fR, there is a
+corresponding \fIbase standard\fR, the version of \s-1ISO C\s0 on which the \s-1GNU\s0
+extended dialect is based.  Warnings from \fB\-Wpedantic\fR are given
+where they are required by the base standard.  (It does not make sense
+for such warnings to be given only for features not in the specified \s-1GNU
+C\s0 dialect, since by definition the \s-1GNU\s0 dialects of C include all
+features the compiler supports with the given option, and there would be
+nothing to warn about.)
+.IP "\fB\-pedantic\-errors\fR" 4
+.IX Item "-pedantic-errors"
+Like \fB\-Wpedantic\fR, except that errors are produced rather than
+warnings.
+.IP "\fB\-Wall\fR" 4
+.IX Item "-Wall"
+This enables all the warnings about constructions that some users
+consider questionable, and that are easy to avoid (or modify to
+prevent the warning), even in conjunction with macros.  This also
+enables some language-specific warnings described in \fB\*(C+ Dialect
+Options\fR and \fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
+.Sp
+\&\fB\-Wall\fR turns on the following warning flags:
+.Sp
+\&\fB\-Waddress   
+\&\-Warray\-bounds\fR (only with\fB \fR\fB\-O2\fR)  
+\&\fB\-Wc++11\-compat  
+\&\-Wchar\-subscripts  
+\&\-Wenum\-compare\fR (in C/ObjC; this is on by default in \*(C+) 
+\&\fB\-Wimplicit\-int\fR (C and Objective-C only) 
+\&\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only) 
+\&\fB\-Wcomment  
+\&\-Wformat   
+\&\-Wmain\fR (only for C/ObjC and unless\fB \fR\fB\-ffreestanding\fR)  
+\&\fB\-Wmaybe\-uninitialized 
+\&\-Wmissing\-braces\fR (only for C/ObjC) 
+\&\fB\-Wnonnull  
+\&\-Wopenmp\-simd 
+\&\-Wparentheses  
+\&\-Wpointer\-sign  
+\&\-Wreorder   
+\&\-Wreturn\-type  
+\&\-Wsequence\-point  
+\&\-Wsign\-compare\fR (only in \*(C+)  
+\&\fB\-Wstrict\-aliasing  
+\&\-Wstrict\-overflow=1  
+\&\-Wswitch  
+\&\-Wtrigraphs  
+\&\-Wuninitialized  
+\&\-Wunknown\-pragmas  
+\&\-Wunused\-function  
+\&\-Wunused\-label     
+\&\-Wunused\-value     
+\&\-Wunused\-variable  
+\&\-Wvolatile\-register\-var\fR
+.Sp
+Note that some warning flags are not implied by \fB\-Wall\fR.  Some of
+them warn about constructions that users generally do not consider
+questionable, but which occasionally you might wish to check for;
+others warn about constructions that are necessary or hard to avoid in
+some cases, and there is no simple way to modify the code to suppress
+the warning. Some of them are enabled by \fB\-Wextra\fR but many of
+them must be enabled individually.
+.IP "\fB\-Wextra\fR" 4
+.IX Item "-Wextra"
+This enables some extra warning flags that are not enabled by
+\&\fB\-Wall\fR. (This option used to be called \fB\-W\fR.  The older
+name is still supported, but the newer name is more descriptive.)
+.Sp
+\&\fB\-Wclobbered  
+\&\-Wempty\-body  
+\&\-Wignored\-qualifiers 
+\&\-Wmissing\-field\-initializers  
+\&\-Wmissing\-parameter\-type\fR (C only)  
+\&\fB\-Wold\-style\-declaration\fR (C only)  
+\&\fB\-Woverride\-init  
+\&\-Wsign\-compare  
+\&\-Wtype\-limits  
+\&\-Wuninitialized  
+\&\-Wunused\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR) 
+\&\fB\-Wunused\-but\-set\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)  \fB \fR
+.Sp
+The option \fB\-Wextra\fR also prints warning messages for the
+following cases:
+.RS 4
+.IP "\(bu" 4
+A pointer is compared against integer zero with \fB<\fR, \fB<=\fR,
+\&\fB>\fR, or \fB>=\fR.
+.IP "\(bu" 4
+(\*(C+ only) An enumerator and a non-enumerator both appear in a
+conditional expression.
+.IP "\(bu" 4
+(\*(C+ only) Ambiguous virtual bases.
+.IP "\(bu" 4
+(\*(C+ only) Subscripting an array that has been declared \fBregister\fR.
+.IP "\(bu" 4
+(\*(C+ only) Taking the address of a variable that has been declared
+\&\fBregister\fR.
+.IP "\(bu" 4
+(\*(C+ only) A base class is not initialized in a derived class's copy
+constructor.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wchar\-subscripts\fR" 4
+.IX Item "-Wchar-subscripts"
+Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR.  This is a common cause
+of error, as programmers often forget that this type is signed on some
+machines.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wcomment\fR" 4
+.IX Item "-Wcomment"
+Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
+comment, or whenever a Backslash-Newline appears in a \fB//\fR comment.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wno\-coverage\-mismatch\fR" 4
+.IX Item "-Wno-coverage-mismatch"
+Warn if feedback profiles do not match when using the
+\&\fB\-fprofile\-use\fR option.
+If a source file is changed between compiling with \fB\-fprofile\-gen\fR and
+with \fB\-fprofile\-use\fR, the files with the profile feedback can fail
+to match the source file and \s-1GCC\s0 cannot use the profile feedback
+information.  By default, this warning is enabled and is treated as an
+error.  \fB\-Wno\-coverage\-mismatch\fR can be used to disable the
+warning or \fB\-Wno\-error=coverage\-mismatch\fR can be used to
+disable the error.  Disabling the error for this warning can result in
+poorly optimized code and is useful only in the
+case of very minor changes such as bug fixes to an existing code-base.
+Completely disabling the warning is not recommended.
+.IP "\fB\-Wno\-cpp\fR" 4
+.IX Item "-Wno-cpp"
+(C, Objective-C, \*(C+, Objective\-\*(C+ and Fortran only)
+.Sp
+Suppress warning messages emitted by \f(CW\*(C`#warning\*(C'\fR directives.
+.IP "\fB\-Wdouble\-promotion\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wdouble-promotion (C, , Objective-C and Objective- only)"
+Give a warning when a value of type \f(CW\*(C`float\*(C'\fR is implicitly
+promoted to \f(CW\*(C`double\*(C'\fR.  CPUs with a 32\-bit \*(L"single-precision\*(R"
+floating-point unit implement \f(CW\*(C`float\*(C'\fR in hardware, but emulate
+\&\f(CW\*(C`double\*(C'\fR in software.  On such a machine, doing computations
+using \f(CW\*(C`double\*(C'\fR values is much more expensive because of the
+overhead required for software emulation.
+.Sp
+It is easy to accidentally do computations with \f(CW\*(C`double\*(C'\fR because
+floating-point literals are implicitly of type \f(CW\*(C`double\*(C'\fR.  For
+example, in:
+.Sp
+.Vb 4
+\&        float area(float radius)
+\&        {
+\&           return 3.14159 * radius * radius;
+\&        }
+.Ve
+.Sp
+the compiler performs the entire computation with \f(CW\*(C`double\*(C'\fR
+because the floating-point literal is a \f(CW\*(C`double\*(C'\fR.
+.IP "\fB\-Wformat\fR" 4
+.IX Item "-Wformat"
+.PD 0
+.IP "\fB\-Wformat=\fR\fIn\fR" 4
+.IX Item "-Wformat=n"
+.PD
+Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that
+the arguments supplied have types appropriate to the format string
+specified, and that the conversions specified in the format string make
+sense.  This includes standard functions, and others specified by format
+attributes, in the \f(CW\*(C`printf\*(C'\fR,
+\&\f(CW\*(C`scanf\*(C'\fR, \f(CW\*(C`strftime\*(C'\fR and \f(CW\*(C`strfmon\*(C'\fR (an X/Open extension,
+not in the C standard) families (or other target-specific families).
+Which functions are checked without format attributes having been
+specified depends on the standard version selected, and such checks of
+functions without the attribute specified are disabled by
+\&\fB\-ffreestanding\fR or \fB\-fno\-builtin\fR.
+.Sp
+The formats are checked against the format features supported by \s-1GNU\s0
+libc version 2.2.  These include all \s-1ISO C90\s0 and C99 features, as well
+as features from the Single Unix Specification and some \s-1BSD\s0 and \s-1GNU\s0
+extensions.  Other library implementations may not support all these
+features; \s-1GCC\s0 does not support warning about features that go beyond a
+particular library's limitations.  However, if \fB\-Wpedantic\fR is used
+with \fB\-Wformat\fR, warnings are given about format features not
+in the selected standard version (but not for \f(CW\*(C`strfmon\*(C'\fR formats,
+since those are not in any version of the C standard).
+.RS 4
+.IP "\fB\-Wformat=1\fR" 4
+.IX Item "-Wformat=1"
+.PD 0
+.IP "\fB\-Wformat\fR" 4
+.IX Item "-Wformat"
+.PD
+Option \fB\-Wformat\fR is equivalent to \fB\-Wformat=1\fR, and
+\&\fB\-Wno\-format\fR is equivalent to \fB\-Wformat=0\fR.  Since
+\&\fB\-Wformat\fR also checks for null format arguments for several
+functions, \fB\-Wformat\fR also implies \fB\-Wnonnull\fR.  Some
+aspects of this level of format checking can be disabled by the
+options: \fB\-Wno\-format\-contains\-nul\fR,
+\&\fB\-Wno\-format\-extra\-args\fR, and \fB\-Wno\-format\-zero\-length\fR.
+\&\fB\-Wformat\fR is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wno\-format\-contains\-nul\fR" 4
+.IX Item "-Wno-format-contains-nul"
+If \fB\-Wformat\fR is specified, do not warn about format strings that
+contain \s-1NUL\s0 bytes.
+.IP "\fB\-Wno\-format\-extra\-args\fR" 4
+.IX Item "-Wno-format-extra-args"
+If \fB\-Wformat\fR is specified, do not warn about excess arguments to a
+\&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function.  The C standard specifies
+that such arguments are ignored.
+.Sp
+Where the unused arguments lie between used arguments that are
+specified with \fB$\fR operand number specifications, normally
+warnings are still given, since the implementation could not know what
+type to pass to \f(CW\*(C`va_arg\*(C'\fR to skip the unused arguments.  However,
+in the case of \f(CW\*(C`scanf\*(C'\fR formats, this option suppresses the
+warning if the unused arguments are all pointers, since the Single
+Unix Specification says that such unused arguments are allowed.
+.IP "\fB\-Wno\-format\-zero\-length\fR" 4
+.IX Item "-Wno-format-zero-length"
+If \fB\-Wformat\fR is specified, do not warn about zero-length formats.
+The C standard specifies that zero-length formats are allowed.
+.IP "\fB\-Wformat=2\fR" 4
+.IX Item "-Wformat=2"
+Enable \fB\-Wformat\fR plus additional format checks.  Currently
+equivalent to \fB\-Wformat \-Wformat\-nonliteral \-Wformat\-security
+\&\-Wformat\-y2k\fR.
+.IP "\fB\-Wformat\-nonliteral\fR" 4
+.IX Item "-Wformat-nonliteral"
+If \fB\-Wformat\fR is specified, also warn if the format string is not a
+string literal and so cannot be checked, unless the format function
+takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR.
+.IP "\fB\-Wformat\-security\fR" 4
+.IX Item "-Wformat-security"
+If \fB\-Wformat\fR is specified, also warn about uses of format
+functions that represent possible security problems.  At present, this
+warns about calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR functions where the
+format string is not a string literal and there are no format arguments,
+as in \f(CW\*(C`printf (foo);\*(C'\fR.  This may be a security hole if the format
+string came from untrusted input and contains \fB\f(CB%n\fB\fR.  (This is
+currently a subset of what \fB\-Wformat\-nonliteral\fR warns about, but
+in future warnings may be added to \fB\-Wformat\-security\fR that are not
+included in \fB\-Wformat\-nonliteral\fR.)
+.IP "\fB\-Wformat\-y2k\fR" 4
+.IX Item "-Wformat-y2k"
+If \fB\-Wformat\fR is specified, also warn about \f(CW\*(C`strftime\*(C'\fR
+formats that may yield only a two-digit year.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wnonnull\fR" 4
+.IX Item "-Wnonnull"
+Warn about passing a null pointer for arguments marked as
+requiring a non-null value by the \f(CW\*(C`nonnull\*(C'\fR function attribute.
+.Sp
+\&\fB\-Wnonnull\fR is included in \fB\-Wall\fR and \fB\-Wformat\fR.  It
+can be disabled with the \fB\-Wno\-nonnull\fR option.
+.IP "\fB\-Winit\-self\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Winit-self (C, , Objective-C and Objective- only)"
+Warn about uninitialized variables that are initialized with themselves.
+Note this option can only be used with the \fB\-Wuninitialized\fR option.
+.Sp
+For example, \s-1GCC\s0 warns about \f(CW\*(C`i\*(C'\fR being uninitialized in the
+following snippet only when \fB\-Winit\-self\fR has been specified:
+.Sp
+.Vb 5
+\&        int f()
+\&        {
+\&          int i = i;
+\&          return i;
+\&        }
+.Ve
+.Sp
+This warning is enabled by \fB\-Wall\fR in \*(C+.
+.IP "\fB\-Wimplicit\-int\fR (C and Objective-C only)" 4
+.IX Item "-Wimplicit-int (C and Objective-C only)"
+Warn when a declaration does not specify a type.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only)" 4
+.IX Item "-Wimplicit-function-declaration (C and Objective-C only)"
+Give a warning whenever a function is used before being declared. In
+C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this warning is
+enabled by default and it is made into an error by
+\&\fB\-pedantic\-errors\fR. This warning is also enabled by
+\&\fB\-Wall\fR.
+.IP "\fB\-Wimplicit\fR (C and Objective-C only)" 4
+.IX Item "-Wimplicit (C and Objective-C only)"
+Same as \fB\-Wimplicit\-int\fR and \fB\-Wimplicit\-function\-declaration\fR.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wignored\-qualifiers\fR (C and \*(C+ only)" 4
+.IX Item "-Wignored-qualifiers (C and only)"
+Warn if the return type of a function has a type qualifier
+such as \f(CW\*(C`const\*(C'\fR.  For \s-1ISO C\s0 such a type qualifier has no effect,
+since the value returned by a function is not an lvalue.
+For \*(C+, the warning is only emitted for scalar types or \f(CW\*(C`void\*(C'\fR.
+\&\s-1ISO C\s0 prohibits qualified \f(CW\*(C`void\*(C'\fR return types on function
+definitions, so such return types always receive a warning
+even without this option.
+.Sp
+This warning is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wmain\fR" 4
+.IX Item "-Wmain"
+Warn if the type of \fBmain\fR is suspicious.  \fBmain\fR should be
+a function with external linkage, returning int, taking either zero
+arguments, two, or three arguments of appropriate types.  This warning
+is enabled by default in \*(C+ and is enabled by either \fB\-Wall\fR
+or \fB\-Wpedantic\fR.
+.IP "\fB\-Wmissing\-braces\fR" 4
+.IX Item "-Wmissing-braces"
+Warn if an aggregate or union initializer is not fully bracketed.  In
+the following example, the initializer for \fBa\fR is not fully
+bracketed, but that for \fBb\fR is fully bracketed.  This warning is
+enabled by \fB\-Wall\fR in C.
+.Sp
+.Vb 2
+\&        int a[2][2] = { 0, 1, 2, 3 };
+\&        int b[2][2] = { { 0, 1 }, { 2, 3 } };
+.Ve
+.Sp
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wmissing\-include\-dirs\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wmissing-include-dirs (C, , Objective-C and Objective- only)"
+Warn if a user-supplied include directory does not exist.
+.IP "\fB\-Wparentheses\fR" 4
+.IX Item "-Wparentheses"
+Warn if parentheses are omitted in certain contexts, such
+as when there is an assignment in a context where a truth value
+is expected, or when operators are nested whose precedence people
+often get confused about.
+.Sp
+Also warn if a comparison like \fBx<=y<=z\fR appears; this is
+equivalent to \fB(x<=y ? 1 : 0) <= z\fR, which is a different
+interpretation from that of ordinary mathematical notation.
+.Sp
+Also warn about constructions where there may be confusion to which
+\&\f(CW\*(C`if\*(C'\fR statement an \f(CW\*(C`else\*(C'\fR branch belongs.  Here is an example of
+such a case:
+.Sp
+.Vb 7
+\&        {
+\&          if (a)
+\&            if (b)
+\&              foo ();
+\&          else
+\&            bar ();
+\&        }
+.Ve
+.Sp
+In C/\*(C+, every \f(CW\*(C`else\*(C'\fR branch belongs to the innermost possible
+\&\f(CW\*(C`if\*(C'\fR statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR.  This is
+often not what the programmer expected, as illustrated in the above
+example by indentation the programmer chose.  When there is the
+potential for this confusion, \s-1GCC\s0 issues a warning when this flag
+is specified.  To eliminate the warning, add explicit braces around
+the innermost \f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR
+can belong to the enclosing \f(CW\*(C`if\*(C'\fR.  The resulting code
+looks like this:
+.Sp
+.Vb 9
+\&        {
+\&          if (a)
+\&            {
+\&              if (b)
+\&                foo ();
+\&              else
+\&                bar ();
+\&            }
+\&        }
+.Ve
+.Sp
+Also warn for dangerous uses of the \s-1GNU\s0 extension to
+\&\f(CW\*(C`?:\*(C'\fR with omitted middle operand. When the condition
+in the \f(CW\*(C`?\*(C'\fR: operator is a boolean expression, the omitted value is
+always 1.  Often programmers expect it to be a value computed
+inside the conditional expression instead.
+.Sp
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wsequence\-point\fR" 4
+.IX Item "-Wsequence-point"
+Warn about code that may have undefined semantics because of violations
+of sequence point rules in the C and \*(C+ standards.
+.Sp
+The C and \*(C+ standards define the order in which expressions in a C/\*(C+
+program are evaluated in terms of \fIsequence points\fR, which represent
+a partial ordering between the execution of parts of the program: those
+executed before the sequence point, and those executed after it.  These
+occur after the evaluation of a full expression (one which is not part
+of a larger expression), after the evaluation of the first operand of a
+\&\f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, \f(CW\*(C`? :\*(C'\fR or \f(CW\*(C`,\*(C'\fR (comma) operator, before a
+function is called (but after the evaluation of its arguments and the
+expression denoting the called function), and in certain other places.
+Other than as expressed by the sequence point rules, the order of
+evaluation of subexpressions of an expression is not specified.  All
+these rules describe only a partial order rather than a total order,
+since, for example, if two functions are called within one expression
+with no sequence point between them, the order in which the functions
+are called is not specified.  However, the standards committee have
+ruled that function calls do not overlap.
+.Sp
+It is not specified when between sequence points modifications to the
+values of objects take effect.  Programs whose behavior depends on this
+have undefined behavior; the C and \*(C+ standards specify that \*(L"Between
+the previous and next sequence point an object shall have its stored
+value modified at most once by the evaluation of an expression.
+Furthermore, the prior value shall be read only to determine the value
+to be stored.\*(R".  If a program breaks these rules, the results on any
+particular implementation are entirely unpredictable.
+.Sp
+Examples of code with undefined behavior are \f(CW\*(C`a = a++;\*(C'\fR, \f(CW\*(C`a[n]
+= b[n++]\*(C'\fR and \f(CW\*(C`a[i++] = i;\*(C'\fR.  Some more complicated cases are not
+diagnosed by this option, and it may give an occasional false positive
+result, but in general it has been found fairly effective at detecting
+this sort of problem in programs.
+.Sp
+The standard is worded confusingly, therefore there is some debate
+over the precise meaning of the sequence point rules in subtle cases.
+Links to discussions of the problem, including proposed formal
+definitions, may be found on the \s-1GCC\s0 readings page, at
+<\fBhttp://gcc.gnu.org/readings.html\fR>.
+.Sp
+This warning is enabled by \fB\-Wall\fR for C and \*(C+.
+.IP "\fB\-Wno\-return\-local\-addr\fR" 4
+.IX Item "-Wno-return-local-addr"
+Do not warn about returning a pointer (or in \*(C+, a reference) to a
+variable that goes out of scope after the function returns.
+.IP "\fB\-Wreturn\-type\fR" 4
+.IX Item "-Wreturn-type"
+Warn whenever a function is defined with a return type that defaults
+to \f(CW\*(C`int\*(C'\fR.  Also warn about any \f(CW\*(C`return\*(C'\fR statement with no
+return value in a function whose return type is not \f(CW\*(C`void\*(C'\fR
+(falling off the end of the function body is considered returning
+without a value), and about a \f(CW\*(C`return\*(C'\fR statement with an
+expression in a function whose return type is \f(CW\*(C`void\*(C'\fR.
+.Sp
+For \*(C+, a function without return type always produces a diagnostic
+message, even when \fB\-Wno\-return\-type\fR is specified.  The only
+exceptions are \fBmain\fR and functions defined in system headers.
+.Sp
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wswitch\fR" 4
+.IX Item "-Wswitch"
+Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
+and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
+enumeration.  (The presence of a \f(CW\*(C`default\*(C'\fR label prevents this
+warning.)  \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also
+provoke warnings when this option is used (even if there is a
+\&\f(CW\*(C`default\*(C'\fR label).
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wswitch\-default\fR" 4
+.IX Item "-Wswitch-default"
+Warn whenever a \f(CW\*(C`switch\*(C'\fR statement does not have a \f(CW\*(C`default\*(C'\fR
+case.
+.IP "\fB\-Wswitch\-enum\fR" 4
+.IX Item "-Wswitch-enum"
+Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
+and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
+enumeration.  \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also
+provoke warnings when this option is used.  The only difference
+between \fB\-Wswitch\fR and this option is that this option gives a
+warning about an omitted enumeration code even if there is a
+\&\f(CW\*(C`default\*(C'\fR label.
+.IP "\fB\-Wsync\-nand\fR (C and \*(C+ only)" 4
+.IX Item "-Wsync-nand (C and only)"
+Warn when \f(CW\*(C`_\|_sync_fetch_and_nand\*(C'\fR and \f(CW\*(C`_\|_sync_nand_and_fetch\*(C'\fR
+built-in functions are used.  These functions changed semantics in \s-1GCC 4.4.\s0
+.IP "\fB\-Wtrigraphs\fR" 4
+.IX Item "-Wtrigraphs"
+Warn if any trigraphs are encountered that might change the meaning of
+the program (trigraphs within comments are not warned about).
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-but\-set\-parameter\fR" 4
+.IX Item "-Wunused-but-set-parameter"
+Warn whenever a function parameter is assigned to, but otherwise unused
+(aside from its declaration).
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.Sp
+This warning is also enabled by \fB\-Wunused\fR together with
+\&\fB\-Wextra\fR.
+.IP "\fB\-Wunused\-but\-set\-variable\fR" 4
+.IX Item "-Wunused-but-set-variable"
+Warn whenever a local variable is assigned to, but otherwise unused
+(aside from its declaration).
+This warning is enabled by \fB\-Wall\fR.
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.Sp
+This warning is also enabled by \fB\-Wunused\fR, which is enabled
+by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-function\fR" 4
+.IX Item "-Wunused-function"
+Warn whenever a static function is declared but not defined or a
+non-inline static function is unused.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-label\fR" 4
+.IX Item "-Wunused-label"
+Warn whenever a label is declared but not used.
+This warning is enabled by \fB\-Wall\fR.
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.IP "\fB\-Wunused\-local\-typedefs\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wunused-local-typedefs (C, Objective-C, and Objective- only)"
+Warn when a typedef locally defined in a function is not used.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-parameter\fR" 4
+.IX Item "-Wunused-parameter"
+Warn whenever a function parameter is unused aside from its declaration.
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.IP "\fB\-Wno\-unused\-result\fR" 4
+.IX Item "-Wno-unused-result"
+Do not warn if a caller of a function marked with attribute
+\&\f(CW\*(C`warn_unused_result\*(C'\fR does not use
+its return value. The default is \fB\-Wunused\-result\fR.
+.IP "\fB\-Wunused\-variable\fR" 4
+.IX Item "-Wunused-variable"
+Warn whenever a local variable or non-constant static variable is unused
+aside from its declaration.
+This warning is enabled by \fB\-Wall\fR.
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.IP "\fB\-Wunused\-value\fR" 4
+.IX Item "-Wunused-value"
+Warn whenever a statement computes a result that is explicitly not
+used. To suppress this warning cast the unused expression to
+\&\fBvoid\fR. This includes an expression-statement or the left-hand
+side of a comma expression that contains no side effects. For example,
+an expression such as \fBx[i,j]\fR causes a warning, while
+\&\fBx[(void)i,j]\fR does not.
+.Sp
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wunused\fR" 4
+.IX Item "-Wunused"
+All the above \fB\-Wunused\fR options combined.
+.Sp
+In order to get a warning about an unused function parameter, you must
+either specify \fB\-Wextra \-Wunused\fR (note that \fB\-Wall\fR implies
+\&\fB\-Wunused\fR), or separately specify \fB\-Wunused\-parameter\fR.
+.IP "\fB\-Wuninitialized\fR" 4
+.IX Item "-Wuninitialized"
+Warn if an automatic variable is used without first being initialized
+or if a variable may be clobbered by a \f(CW\*(C`setjmp\*(C'\fR call. In \*(C+,
+warn if a non-static reference or non-static \fBconst\fR member
+appears in a class without constructors.
+.Sp
+If you want to warn about code that uses the uninitialized value of the
+variable in its own initializer, use the \fB\-Winit\-self\fR option.
+.Sp
+These warnings occur for individual uninitialized or clobbered
+elements of structure, union or array variables as well as for
+variables that are uninitialized or clobbered as a whole.  They do
+not occur for variables or elements declared \f(CW\*(C`volatile\*(C'\fR.  Because
+these warnings depend on optimization, the exact variables or elements
+for which there are warnings depends on the precise optimization
+options and version of \s-1GCC\s0 used.
+.Sp
+Note that there may be no warning about a variable that is used only
+to compute a value that itself is never used, because such
+computations may be deleted by data flow analysis before the warnings
+are printed.
+.IP "\fB\-Wmaybe\-uninitialized\fR" 4
+.IX Item "-Wmaybe-uninitialized"
+For an automatic variable, if there exists a path from the function
+entry to a use of the variable that is initialized, but there exist
+some other paths for which the variable is not initialized, the compiler
+emits a warning if it cannot prove the uninitialized paths are not
+executed at run time. These warnings are made optional because \s-1GCC\s0 is
+not smart enough to see all the reasons why the code might be correct
+in spite of appearing to have an error.  Here is one example of how
+this can happen:
+.Sp
+.Vb 12
+\&        {
+\&          int x;
+\&          switch (y)
+\&            {
+\&            case 1: x = 1;
+\&              break;
+\&            case 2: x = 4;
+\&              break;
+\&            case 3: x = 5;
+\&            }
+\&          foo (x);
+\&        }
+.Ve
+.Sp
+If the value of \f(CW\*(C`y\*(C'\fR is always 1, 2 or 3, then \f(CW\*(C`x\*(C'\fR is
+always initialized, but \s-1GCC\s0 doesn't know this. To suppress the
+warning, you need to provide a default case with \fIassert\fR\|(0) or
+similar code.
+.Sp
+This option also warns when a non-volatile automatic variable might be
+changed by a call to \f(CW\*(C`longjmp\*(C'\fR.  These warnings as well are possible
+only in optimizing compilation.
+.Sp
+The compiler sees only the calls to \f(CW\*(C`setjmp\*(C'\fR.  It cannot know
+where \f(CW\*(C`longjmp\*(C'\fR will be called; in fact, a signal handler could
+call it at any point in the code.  As a result, you may get a warning
+even when there is in fact no problem because \f(CW\*(C`longjmp\*(C'\fR cannot
+in fact be called at the place that would cause a problem.
+.Sp
+Some spurious warnings can be avoided if you declare all the functions
+you use that never return as \f(CW\*(C`noreturn\*(C'\fR.
+.Sp
+This warning is enabled by \fB\-Wall\fR or \fB\-Wextra\fR.
+.IP "\fB\-Wunknown\-pragmas\fR" 4
+.IX Item "-Wunknown-pragmas"
+Warn when a \f(CW\*(C`#pragma\*(C'\fR directive is encountered that is not understood by 
+\&\s-1GCC. \s0 If this command-line option is used, warnings are even issued
+for unknown pragmas in system header files.  This is not the case if
+the warnings are only enabled by the \fB\-Wall\fR command-line option.
+.IP "\fB\-Wno\-pragmas\fR" 4
+.IX Item "-Wno-pragmas"
+Do not warn about misuses of pragmas, such as incorrect parameters,
+invalid syntax, or conflicts between pragmas.  See also
+\&\fB\-Wunknown\-pragmas\fR.
+.IP "\fB\-Wstrict\-aliasing\fR" 4
+.IX Item "-Wstrict-aliasing"
+This option is only active when \fB\-fstrict\-aliasing\fR is active.
+It warns about code that might break the strict aliasing rules that the
+compiler is using for optimization.  The warning does not catch all
+cases, but does attempt to catch the more common pitfalls.  It is
+included in \fB\-Wall\fR.
+It is equivalent to \fB\-Wstrict\-aliasing=3\fR
+.IP "\fB\-Wstrict\-aliasing=n\fR" 4
+.IX Item "-Wstrict-aliasing=n"
+This option is only active when \fB\-fstrict\-aliasing\fR is active.
+It warns about code that might break the strict aliasing rules that the
+compiler is using for optimization.
+Higher levels correspond to higher accuracy (fewer false positives).
+Higher levels also correspond to more effort, similar to the way \fB\-O\fR 
+works.
+\&\fB\-Wstrict\-aliasing\fR is equivalent to \fB\-Wstrict\-aliasing=3\fR.
+.Sp
+Level 1: Most aggressive, quick, least accurate.
+Possibly useful when higher levels
+do not warn but \fB\-fstrict\-aliasing\fR still breaks the code, as it has very few
+false negatives.  However, it has many false positives.
+Warns for all pointer conversions between possibly incompatible types,
+even if never dereferenced.  Runs in the front end only.
+.Sp
+Level 2: Aggressive, quick, not too precise.
+May still have many false positives (not as many as level 1 though),
+and few false negatives (but possibly more than level 1).
+Unlike level 1, it only warns when an address is taken.  Warns about
+incomplete types.  Runs in the front end only.
+.Sp
+Level 3 (default for \fB\-Wstrict\-aliasing\fR):
+Should have very few false positives and few false
+negatives.  Slightly slower than levels 1 or 2 when optimization is enabled.
+Takes care of the common pun+dereference pattern in the front end:
+\&\f(CW\*(C`*(int*)&some_float\*(C'\fR.
+If optimization is enabled, it also runs in the back end, where it deals
+with multiple statement cases using flow-sensitive points-to information.
+Only warns when the converted pointer is dereferenced.
+Does not warn about incomplete types.
+.IP "\fB\-Wstrict\-overflow\fR" 4
+.IX Item "-Wstrict-overflow"
+.PD 0
+.IP "\fB\-Wstrict\-overflow=\fR\fIn\fR" 4
+.IX Item "-Wstrict-overflow=n"
+.PD
+This option is only active when \fB\-fstrict\-overflow\fR is active.
+It warns about cases where the compiler optimizes based on the
+assumption that signed overflow does not occur.  Note that it does not
+warn about all cases where the code might overflow: it only warns
+about cases where the compiler implements some optimization.  Thus
+this warning depends on the optimization level.
+.Sp
+An optimization that assumes that signed overflow does not occur is
+perfectly safe if the values of the variables involved are such that
+overflow never does, in fact, occur.  Therefore this warning can
+easily give a false positive: a warning about code that is not
+actually a problem.  To help focus on important issues, several
+warning levels are defined.  No warnings are issued for the use of
+undefined signed overflow when estimating how many iterations a loop
+requires, in particular when determining whether a loop will be
+executed at all.
+.RS 4
+.IP "\fB\-Wstrict\-overflow=1\fR" 4
+.IX Item "-Wstrict-overflow=1"
+Warn about cases that are both questionable and easy to avoid.  For
+example,  with \fB\-fstrict\-overflow\fR, the compiler simplifies
+\&\f(CW\*(C`x + 1 > x\*(C'\fR to \f(CW1\fR.  This level of
+\&\fB\-Wstrict\-overflow\fR is enabled by \fB\-Wall\fR; higher levels
+are not, and must be explicitly requested.
+.IP "\fB\-Wstrict\-overflow=2\fR" 4
+.IX Item "-Wstrict-overflow=2"
+Also warn about other cases where a comparison is simplified to a
+constant.  For example: \f(CW\*(C`abs (x) >= 0\*(C'\fR.  This can only be
+simplified when \fB\-fstrict\-overflow\fR is in effect, because
+\&\f(CW\*(C`abs (INT_MIN)\*(C'\fR overflows to \f(CW\*(C`INT_MIN\*(C'\fR, which is less than
+zero.  \fB\-Wstrict\-overflow\fR (with no level) is the same as
+\&\fB\-Wstrict\-overflow=2\fR.
+.IP "\fB\-Wstrict\-overflow=3\fR" 4
+.IX Item "-Wstrict-overflow=3"
+Also warn about other cases where a comparison is simplified.  For
+example: \f(CW\*(C`x + 1 > 1\*(C'\fR is simplified to \f(CW\*(C`x > 0\*(C'\fR.
+.IP "\fB\-Wstrict\-overflow=4\fR" 4
+.IX Item "-Wstrict-overflow=4"
+Also warn about other simplifications not covered by the above cases.
+For example: \f(CW\*(C`(x * 10) / 5\*(C'\fR is simplified to \f(CW\*(C`x * 2\*(C'\fR.
+.IP "\fB\-Wstrict\-overflow=5\fR" 4
+.IX Item "-Wstrict-overflow=5"
+Also warn about cases where the compiler reduces the magnitude of a
+constant involved in a comparison.  For example: \f(CW\*(C`x + 2 > y\*(C'\fR is
+simplified to \f(CW\*(C`x + 1 >= y\*(C'\fR.  This is reported only at the
+highest warning level because this simplification applies to many
+comparisons, so this warning level gives a very large number of
+false positives.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR|\fBformat\fR]" 4
+.IX Item "-Wsuggest-attribute=[pure|const|noreturn|format]"
+Warn for cases where adding an attribute may be beneficial. The
+attributes currently supported are listed below.
+.RS 4
+.IP "\fB\-Wsuggest\-attribute=pure\fR" 4
+.IX Item "-Wsuggest-attribute=pure"
+.PD 0
+.IP "\fB\-Wsuggest\-attribute=const\fR" 4
+.IX Item "-Wsuggest-attribute=const"
+.IP "\fB\-Wsuggest\-attribute=noreturn\fR" 4
+.IX Item "-Wsuggest-attribute=noreturn"
+.PD
+Warn about functions that might be candidates for attributes
+\&\f(CW\*(C`pure\*(C'\fR, \f(CW\*(C`const\*(C'\fR or \f(CW\*(C`noreturn\*(C'\fR.  The compiler only warns for
+functions visible in other compilation units or (in the case of \f(CW\*(C`pure\*(C'\fR and
+\&\f(CW\*(C`const\*(C'\fR) if it cannot prove that the function returns normally. A function
+returns normally if it doesn't contain an infinite loop or return abnormally
+by throwing, calling \f(CW\*(C`abort()\*(C'\fR or trapping.  This analysis requires option
+\&\fB\-fipa\-pure\-const\fR, which is enabled by default at \fB\-O\fR and
+higher.  Higher optimization levels improve the accuracy of the analysis.
+.IP "\fB\-Wsuggest\-attribute=format\fR" 4
+.IX Item "-Wsuggest-attribute=format"
+.PD 0
+.IP "\fB\-Wmissing\-format\-attribute\fR" 4
+.IX Item "-Wmissing-format-attribute"
+.PD
+Warn about function pointers that might be candidates for \f(CW\*(C`format\*(C'\fR
+attributes.  Note these are only possible candidates, not absolute ones.
+\&\s-1GCC\s0 guesses that function pointers with \f(CW\*(C`format\*(C'\fR attributes that
+are used in assignment, initialization, parameter passing or return
+statements should have a corresponding \f(CW\*(C`format\*(C'\fR attribute in the
+resulting type.  I.e. the left-hand side of the assignment or
+initialization, the type of the parameter variable, or the return type
+of the containing function respectively should also have a \f(CW\*(C`format\*(C'\fR
+attribute to avoid the warning.
+.Sp
+\&\s-1GCC\s0 also warns about function definitions that might be
+candidates for \f(CW\*(C`format\*(C'\fR attributes.  Again, these are only
+possible candidates.  \s-1GCC\s0 guesses that \f(CW\*(C`format\*(C'\fR attributes
+might be appropriate for any function that calls a function like
+\&\f(CW\*(C`vprintf\*(C'\fR or \f(CW\*(C`vscanf\*(C'\fR, but this might not always be the
+case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are
+appropriate may not be detected.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Warray\-bounds\fR" 4
+.IX Item "-Warray-bounds"
+This option is only active when \fB\-ftree\-vrp\fR is active
+(default for \fB\-O2\fR and above). It warns about subscripts to arrays
+that are always out of bounds. This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wno\-div\-by\-zero\fR" 4
+.IX Item "-Wno-div-by-zero"
+Do not warn about compile-time integer division by zero.  Floating-point
+division by zero is not warned about, as it can be a legitimate way of
+obtaining infinities and NaNs.
+.IP "\fB\-Wsystem\-headers\fR" 4
+.IX Item "-Wsystem-headers"
+Print warning messages for constructs found in system header files.
+Warnings from system headers are normally suppressed, on the assumption
+that they usually do not indicate real problems and would only make the
+compiler output harder to read.  Using this command-line option tells
+\&\s-1GCC\s0 to emit warnings from system headers as if they occurred in user
+code.  However, note that using \fB\-Wall\fR in conjunction with this
+option does \fInot\fR warn about unknown pragmas in system
+headers\-\-\-for that, \fB\-Wunknown\-pragmas\fR must also be used.
+.IP "\fB\-Wtrampolines\fR" 4
+.IX Item "-Wtrampolines"
+.Vb 1
+\& Warn about trampolines generated for pointers to nested functions.
+\&
+\& A trampoline is a small piece of data or code that is created at run
+\& time on the stack when the address of a nested function is taken, and
+\& is used to call the nested function indirectly.  For some targets, it
+\& is made up of data only and thus requires no special treatment.  But,
+\& for most targets, it is made up of code and thus requires the stack
+\& to be made executable in order for the program to work properly.
+.Ve
+.IP "\fB\-Wfloat\-equal\fR" 4
+.IX Item "-Wfloat-equal"
+Warn if floating-point values are used in equality comparisons.
+.Sp
+The idea behind this is that sometimes it is convenient (for the
+programmer) to consider floating-point values as approximations to
+infinitely precise real numbers.  If you are doing this, then you need
+to compute (by analyzing the code, or in some other way) the maximum or
+likely maximum error that the computation introduces, and allow for it
+when performing comparisons (and when producing output, but that's a
+different problem).  In particular, instead of testing for equality, you
+should check to see whether the two values have ranges that overlap; and
+this is done with the relational operators, so equality comparisons are
+probably mistaken.
+.IP "\fB\-Wtraditional\fR (C and Objective-C only)" 4
+.IX Item "-Wtraditional (C and Objective-C only)"
+Warn about certain constructs that behave differently in traditional and
+\&\s-1ISO C. \s0 Also warn about \s-1ISO C\s0 constructs that have no traditional C
+equivalent, and/or problematic constructs that should be avoided.
+.RS 4
+.IP "\(bu" 4
+Macro parameters that appear within string literals in the macro body.
+In traditional C macro replacement takes place within string literals,
+but in \s-1ISO C\s0 it does not.
+.IP "\(bu" 4
+In traditional C, some preprocessor directives did not exist.
+Traditional preprocessors only considered a line to be a directive
+if the \fB#\fR appeared in column 1 on the line.  Therefore
+\&\fB\-Wtraditional\fR warns about directives that traditional C
+understands but ignores because the \fB#\fR does not appear as the
+first character on the line.  It also suggests you hide directives like
+\&\fB#pragma\fR not understood by traditional C by indenting them.  Some
+traditional implementations do not recognize \fB#elif\fR, so this option
+suggests avoiding it altogether.
+.IP "\(bu" 4
+A function-like macro that appears without arguments.
+.IP "\(bu" 4
+The unary plus operator.
+.IP "\(bu" 4
+The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating-point
+constant suffixes.  (Traditional C does support the \fBL\fR suffix on integer
+constants.)  Note, these suffixes appear in macros defined in the system
+headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`<limits.h>\*(C'\fR.
+Use of these macros in user code might normally lead to spurious
+warnings, however \s-1GCC\s0's integrated preprocessor has enough context to
+avoid warning in these cases.
+.IP "\(bu" 4
+A function declared external in one block and then used after the end of
+the block.
+.IP "\(bu" 4
+A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR.
+.IP "\(bu" 4
+A non\-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one.
+This construct is not accepted by some traditional C compilers.
+.IP "\(bu" 4
+The \s-1ISO\s0 type of an integer constant has a different width or
+signedness from its traditional type.  This warning is only issued if
+the base of the constant is ten.  I.e. hexadecimal or octal values, which
+typically represent bit patterns, are not warned about.
+.IP "\(bu" 4
+Usage of \s-1ISO\s0 string concatenation is detected.
+.IP "\(bu" 4
+Initialization of automatic aggregates.
+.IP "\(bu" 4
+Identifier conflicts with labels.  Traditional C lacks a separate
+namespace for labels.
+.IP "\(bu" 4
+Initialization of unions.  If the initializer is zero, the warning is
+omitted.  This is done under the assumption that the zero initializer in
+user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing
+initializer warnings and relies on default initialization to zero in the
+traditional C case.
+.IP "\(bu" 4
+Conversions by prototypes between fixed/floating\-point values and vice
+versa.  The absence of these prototypes when compiling with traditional
+C causes serious problems.  This is a subset of the possible
+conversion warnings; for the full set use \fB\-Wtraditional\-conversion\fR.
+.IP "\(bu" 4
+Use of \s-1ISO C\s0 style function definitions.  This warning intentionally is
+\&\fInot\fR issued for prototype declarations or variadic functions
+because these \s-1ISO C\s0 features appear in your code when using
+libiberty's traditional C compatibility macros, \f(CW\*(C`PARAMS\*(C'\fR and
+\&\f(CW\*(C`VPARAMS\*(C'\fR.  This warning is also bypassed for nested functions
+because that feature is already a \s-1GCC\s0 extension and thus not relevant to
+traditional C compatibility.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wtraditional\-conversion\fR (C and Objective-C only)" 4
+.IX Item "-Wtraditional-conversion (C and Objective-C only)"
+Warn if a prototype causes a type conversion that is different from what
+would happen to the same argument in the absence of a prototype.  This
+includes conversions of fixed point to floating and vice versa, and
+conversions changing the width or signedness of a fixed-point argument
+except when the same as the default promotion.
+.IP "\fB\-Wdeclaration\-after\-statement\fR (C and Objective-C only)" 4
+.IX Item "-Wdeclaration-after-statement (C and Objective-C only)"
+Warn when a declaration is found after a statement in a block.  This
+construct, known from \*(C+, was introduced with \s-1ISO C99\s0 and is by default
+allowed in \s-1GCC. \s0 It is not supported by \s-1ISO C90\s0 and was not supported by
+\&\s-1GCC\s0 versions before \s-1GCC 3.0.  \s0
+.IP "\fB\-Wundef\fR" 4
+.IX Item "-Wundef"
+Warn if an undefined identifier is evaluated in an \fB#if\fR directive.
+.IP "\fB\-Wno\-endif\-labels\fR" 4
+.IX Item "-Wno-endif-labels"
+Do not warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
+.IP "\fB\-Wshadow\fR" 4
+.IX Item "-Wshadow"
+Warn whenever a local variable or type declaration shadows another variable,
+parameter, type, or class member (in \*(C+), or whenever a built-in function
+is shadowed. Note that in \*(C+, the compiler warns if a local variable
+shadows an explicit typedef, but not if it shadows a struct/class/enum.
+.IP "\fB\-Wlarger\-than=\fR\fIlen\fR" 4
+.IX Item "-Wlarger-than=len"
+Warn whenever an object of larger than \fIlen\fR bytes is defined.
+.IP "\fB\-Wframe\-larger\-than=\fR\fIlen\fR" 4
+.IX Item "-Wframe-larger-than=len"
+Warn if the size of a function frame is larger than \fIlen\fR bytes.
+The computation done to determine the stack frame size is approximate
+and not conservative.
+The actual requirements may be somewhat greater than \fIlen\fR
+even if you do not get a warning.  In addition, any space allocated
+via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related constructs
+is not included by the compiler when determining
+whether or not to issue a warning.
+.IP "\fB\-Wno\-free\-nonheap\-object\fR" 4
+.IX Item "-Wno-free-nonheap-object"
+Do not warn when attempting to free an object that was not allocated
+on the heap.
+.IP "\fB\-Wstack\-usage=\fR\fIlen\fR" 4
+.IX Item "-Wstack-usage=len"
+Warn if the stack usage of a function might be larger than \fIlen\fR bytes.
+The computation done to determine the stack usage is conservative.
+Any space allocated via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related
+constructs is included by the compiler when determining whether or not to
+issue a warning.
+.Sp
+The message is in keeping with the output of \fB\-fstack\-usage\fR.
+.RS 4
+.IP "\(bu" 4
+If the stack usage is fully static but exceeds the specified amount, it's:
+.Sp
+.Vb 1
+\&          warning: stack usage is 1120 bytes
+.Ve
+.IP "\(bu" 4
+If the stack usage is (partly) dynamic but bounded, it's:
+.Sp
+.Vb 1
+\&          warning: stack usage might be 1648 bytes
+.Ve
+.IP "\(bu" 4
+If the stack usage is (partly) dynamic and not bounded, it's:
+.Sp
+.Vb 1
+\&          warning: stack usage might be unbounded
+.Ve
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wunsafe\-loop\-optimizations\fR" 4
+.IX Item "-Wunsafe-loop-optimizations"
+Warn if the loop cannot be optimized because the compiler cannot
+assume anything on the bounds of the loop indices.  With
+\&\fB\-funsafe\-loop\-optimizations\fR warn if the compiler makes
+such assumptions.
+.IP "\fB\-Wno\-pedantic\-ms\-format\fR (MinGW targets only)" 4
+.IX Item "-Wno-pedantic-ms-format (MinGW targets only)"
+When used in combination with \fB\-Wformat\fR
+and \fB\-pedantic\fR without \s-1GNU\s0 extensions, this option
+disables the warnings about non-ISO \f(CW\*(C`printf\*(C'\fR / \f(CW\*(C`scanf\*(C'\fR format
+width specifiers \f(CW\*(C`I32\*(C'\fR, \f(CW\*(C`I64\*(C'\fR, and \f(CW\*(C`I\*(C'\fR used on Windows targets,
+which depend on the \s-1MS\s0 runtime.
+.IP "\fB\-Wpointer\-arith\fR" 4
+.IX Item "-Wpointer-arith"
+Warn about anything that depends on the \*(L"size of\*(R" a function type or
+of \f(CW\*(C`void\*(C'\fR.  \s-1GNU C\s0 assigns these types a size of 1, for
+convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers
+to functions.  In \*(C+, warn also when an arithmetic operation involves
+\&\f(CW\*(C`NULL\*(C'\fR.  This warning is also enabled by \fB\-Wpedantic\fR.
+.IP "\fB\-Wtype\-limits\fR" 4
+.IX Item "-Wtype-limits"
+Warn if a comparison is always true or always false due to the limited
+range of the data type, but do not warn for constant expressions.  For
+example, warn if an unsigned variable is compared against zero with
+\&\fB<\fR or \fB>=\fR.  This warning is also enabled by
+\&\fB\-Wextra\fR.
+.IP "\fB\-Wbad\-function\-cast\fR (C and Objective-C only)" 4
+.IX Item "-Wbad-function-cast (C and Objective-C only)"
+Warn whenever a function call is cast to a non-matching type.
+For example, warn if \f(CW\*(C`int malloc()\*(C'\fR is cast to \f(CW\*(C`anything *\*(C'\fR.
+.IP "\fB\-Wc++\-compat\fR (C and Objective-C only)" 4
+.IX Item "-Wc++-compat (C and Objective-C only)"
+Warn about \s-1ISO C\s0 constructs that are outside of the common subset of
+\&\s-1ISO C\s0 and \s-1ISO \*(C+,\s0 e.g. request for implicit conversion from
+\&\f(CW\*(C`void *\*(C'\fR to a pointer to non\-\f(CW\*(C`void\*(C'\fR type.
+.IP "\fB\-Wc++11\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wc++11-compat ( and Objective- only)"
+Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 1998\s0
+and \s-1ISO \*(C+ 2011,\s0 e.g., identifiers in \s-1ISO \*(C+ 1998\s0 that are keywords
+in \s-1ISO \*(C+ 2011. \s0 This warning turns on \fB\-Wnarrowing\fR and is
+enabled by \fB\-Wall\fR.
+.IP "\fB\-Wcast\-qual\fR" 4
+.IX Item "-Wcast-qual"
+Warn whenever a pointer is cast so as to remove a type qualifier from
+the target type.  For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast
+to an ordinary \f(CW\*(C`char *\*(C'\fR.
+.Sp
+Also warn when making a cast that introduces a type qualifier in an
+unsafe way.  For example, casting \f(CW\*(C`char **\*(C'\fR to \f(CW\*(C`const char **\*(C'\fR
+is unsafe, as in this example:
+.Sp
+.Vb 6
+\&          /* p is char ** value.  */
+\&          const char **q = (const char **) p;
+\&          /* Assignment of readonly string to const char * is OK.  */
+\&          *q = "string";
+\&          /* Now char** pointer points to read\-only memory.  */
+\&          **p = \*(Aqb\*(Aq;
+.Ve
+.IP "\fB\-Wcast\-align\fR" 4
+.IX Item "-Wcast-align"
+Warn whenever a pointer is cast such that the required alignment of the
+target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
+an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at
+two\- or four-byte boundaries.
+.IP "\fB\-Wwrite\-strings\fR" 4
+.IX Item "-Wwrite-strings"
+When compiling C, give string constants the type \f(CW\*(C`const
+char[\f(CIlength\f(CW]\*(C'\fR so that copying the address of one into a
+non\-\f(CW\*(C`const\*(C'\fR \f(CW\*(C`char *\*(C'\fR pointer produces a warning.  These
+warnings help you find at compile time code that can try to write
+into a string constant, but only if you have been very careful about
+using \f(CW\*(C`const\*(C'\fR in declarations and prototypes.  Otherwise, it is
+just a nuisance. This is why we did not make \fB\-Wall\fR request
+these warnings.
+.Sp
+When compiling \*(C+, warn about the deprecated conversion from string
+literals to \f(CW\*(C`char *\*(C'\fR.  This warning is enabled by default for \*(C+
+programs.
+.IP "\fB\-Wclobbered\fR" 4
+.IX Item "-Wclobbered"
+Warn for variables that might be changed by \fBlongjmp\fR or
+\&\fBvfork\fR.  This warning is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wconditionally\-supported\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wconditionally-supported ( and Objective- only)"
+Warn for conditionally-supported (\*(C+11 [intro.defs]) constructs.
+.IP "\fB\-Wconversion\fR" 4
+.IX Item "-Wconversion"
+Warn for implicit conversions that may alter a value. This includes
+conversions between real and integer, like \f(CW\*(C`abs (x)\*(C'\fR when
+\&\f(CW\*(C`x\*(C'\fR is \f(CW\*(C`double\*(C'\fR; conversions between signed and unsigned,
+like \f(CW\*(C`unsigned ui = \-1\*(C'\fR; and conversions to smaller types, like
+\&\f(CW\*(C`sqrtf (M_PI)\*(C'\fR. Do not warn for explicit casts like \f(CW\*(C`abs
+((int) x)\*(C'\fR and \f(CW\*(C`ui = (unsigned) \-1\*(C'\fR, or if the value is not
+changed by the conversion like in \f(CW\*(C`abs (2.0)\*(C'\fR.  Warnings about
+conversions between signed and unsigned integers can be disabled by
+using \fB\-Wno\-sign\-conversion\fR.
+.Sp
+For \*(C+, also warn for confusing overload resolution for user-defined
+conversions; and conversions that never use a type conversion
+operator: conversions to \f(CW\*(C`void\*(C'\fR, the same type, a base class or a
+reference to them. Warnings about conversions between signed and
+unsigned integers are disabled by default in \*(C+ unless
+\&\fB\-Wsign\-conversion\fR is explicitly enabled.
+.IP "\fB\-Wno\-conversion\-null\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-conversion-null ( and Objective- only)"
+Do not warn for conversions between \f(CW\*(C`NULL\*(C'\fR and non-pointer
+types. \fB\-Wconversion\-null\fR is enabled by default.
+.IP "\fB\-Wzero\-as\-null\-pointer\-constant\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wzero-as-null-pointer-constant ( and Objective- only)"
+Warn when a literal '0' is used as null pointer constant.  This can
+be useful to facilitate the conversion to \f(CW\*(C`nullptr\*(C'\fR in \*(C+11.
+.IP "\fB\-Wdate\-time\fR" 4
+.IX Item "-Wdate-time"
+Warn when macros \f(CW\*(C`_\|_TIME_\|_\*(C'\fR, \f(CW\*(C`_\|_DATE_\|_\*(C'\fR or \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR
+are encountered as they might prevent bit-wise-identical reproducible
+compilations.
+.IP "\fB\-Wdelete\-incomplete\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wdelete-incomplete ( and Objective- only)"
+Warn when deleting a pointer to incomplete type, which may cause
+undefined behavior at runtime.  This warning is enabled by default.
+.IP "\fB\-Wuseless\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wuseless-cast ( and Objective- only)"
+Warn when an expression is casted to its own type.
+.IP "\fB\-Wempty\-body\fR" 4
+.IX Item "-Wempty-body"
+Warn if an empty body occurs in an \fBif\fR, \fBelse\fR or \fBdo
+while\fR statement.  This warning is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wenum\-compare\fR" 4
+.IX Item "-Wenum-compare"
+Warn about a comparison between values of different enumerated types.
+In \*(C+ enumeral mismatches in conditional expressions are also
+diagnosed and the warning is enabled by default.  In C this warning is 
+enabled by \fB\-Wall\fR.
+.IP "\fB\-Wjump\-misses\-init\fR (C, Objective-C only)" 4
+.IX Item "-Wjump-misses-init (C, Objective-C only)"
+Warn if a \f(CW\*(C`goto\*(C'\fR statement or a \f(CW\*(C`switch\*(C'\fR statement jumps
+forward across the initialization of a variable, or jumps backward to a
+label after the variable has been initialized.  This only warns about
+variables that are initialized when they are declared.  This warning is
+only supported for C and Objective-C; in \*(C+ this sort of branch is an
+error in any case.
+.Sp
+\&\fB\-Wjump\-misses\-init\fR is included in \fB\-Wc++\-compat\fR.  It
+can be disabled with the \fB\-Wno\-jump\-misses\-init\fR option.
+.IP "\fB\-Wsign\-compare\fR" 4
+.IX Item "-Wsign-compare"
+Warn when a comparison between signed and unsigned values could produce
+an incorrect result when the signed value is converted to unsigned.
+This warning is also enabled by \fB\-Wextra\fR; to get the other warnings
+of \fB\-Wextra\fR without this warning, use \fB\-Wextra \-Wno\-sign\-compare\fR.
+.IP "\fB\-Wsign\-conversion\fR" 4
+.IX Item "-Wsign-conversion"
+Warn for implicit conversions that may change the sign of an integer
+value, like assigning a signed integer expression to an unsigned
+integer variable. An explicit cast silences the warning. In C, this
+option is enabled also by \fB\-Wconversion\fR.
+.IP "\fB\-Wfloat\-conversion\fR" 4
+.IX Item "-Wfloat-conversion"
+Warn for implicit conversions that reduce the precision of a real value.
+This includes conversions from real to integer, and from higher precision
+real to lower precision real values.  This option is also enabled by
+\&\fB\-Wconversion\fR.
+.IP "\fB\-Wsizeof\-pointer\-memaccess\fR" 4
+.IX Item "-Wsizeof-pointer-memaccess"
+Warn for suspicious length parameters to certain string and memory built-in
+functions if the argument uses \f(CW\*(C`sizeof\*(C'\fR.  This warning warns e.g.
+about \f(CW\*(C`memset (ptr, 0, sizeof (ptr));\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is not an array,
+but a pointer, and suggests a possible fix, or about
+\&\f(CW\*(C`memcpy (&foo, ptr, sizeof (&foo));\*(C'\fR.  This warning is enabled by
+\&\fB\-Wall\fR.
+.IP "\fB\-Waddress\fR" 4
+.IX Item "-Waddress"
+Warn about suspicious uses of memory addresses. These include using
+the address of a function in a conditional expression, such as
+\&\f(CW\*(C`void func(void); if (func)\*(C'\fR, and comparisons against the memory
+address of a string literal, such as \f(CW\*(C`if (x == "abc")\*(C'\fR.  Such
+uses typically indicate a programmer error: the address of a function
+always evaluates to true, so their use in a conditional usually
+indicate that the programmer forgot the parentheses in a function
+call; and comparisons against string literals result in unspecified
+behavior and are not portable in C, so they usually indicate that the
+programmer intended to use \f(CW\*(C`strcmp\*(C'\fR.  This warning is enabled by
+\&\fB\-Wall\fR.
+.IP "\fB\-Wlogical\-op\fR" 4
+.IX Item "-Wlogical-op"
+Warn about suspicious uses of logical operators in expressions.
+This includes using logical operators in contexts where a
+bit-wise operator is likely to be expected.
+.IP "\fB\-Waggregate\-return\fR" 4
+.IX Item "-Waggregate-return"
+Warn if any functions that return structures or unions are defined or
+called.  (In languages where you can return an array, this also elicits
+a warning.)
+.IP "\fB\-Wno\-aggressive\-loop\-optimizations\fR" 4
+.IX Item "-Wno-aggressive-loop-optimizations"
+Warn if in a loop with constant number of iterations the compiler detects
+undefined behavior in some statement during one or more of the iterations.
+.IP "\fB\-Wno\-attributes\fR" 4
+.IX Item "-Wno-attributes"
+Do not warn if an unexpected \f(CW\*(C`_\|_attribute_\|_\*(C'\fR is used, such as
+unrecognized attributes, function attributes applied to variables,
+etc.  This does not stop errors for incorrect use of supported
+attributes.
+.IP "\fB\-Wno\-builtin\-macro\-redefined\fR" 4
+.IX Item "-Wno-builtin-macro-redefined"
+Do not warn if certain built-in macros are redefined.  This suppresses
+warnings for redefinition of \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR, \f(CW\*(C`_\|_TIME_\|_\*(C'\fR,
+\&\f(CW\*(C`_\|_DATE_\|_\*(C'\fR, \f(CW\*(C`_\|_FILE_\|_\*(C'\fR, and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR.
+.IP "\fB\-Wstrict\-prototypes\fR (C and Objective-C only)" 4
+.IX Item "-Wstrict-prototypes (C and Objective-C only)"
+Warn if a function is declared or defined without specifying the
+argument types.  (An old-style function definition is permitted without
+a warning if preceded by a declaration that specifies the argument
+types.)
+.IP "\fB\-Wold\-style\-declaration\fR (C and Objective-C only)" 4
+.IX Item "-Wold-style-declaration (C and Objective-C only)"
+Warn for obsolescent usages, according to the C Standard, in a
+declaration. For example, warn if storage-class specifiers like
+\&\f(CW\*(C`static\*(C'\fR are not the first things in a declaration.  This warning
+is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wold\-style\-definition\fR (C and Objective-C only)" 4
+.IX Item "-Wold-style-definition (C and Objective-C only)"
+Warn if an old-style function definition is used.  A warning is given
+even if there is a previous prototype.
+.IP "\fB\-Wmissing\-parameter\-type\fR (C and Objective-C only)" 4
+.IX Item "-Wmissing-parameter-type (C and Objective-C only)"
+A function parameter is declared without a type specifier in K&R\-style
+functions:
+.Sp
+.Vb 1
+\&        void foo(bar) { }
+.Ve
+.Sp
+This warning is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wmissing\-prototypes\fR (C and Objective-C only)" 4
+.IX Item "-Wmissing-prototypes (C and Objective-C only)"
+Warn if a global function is defined without a previous prototype
+declaration.  This warning is issued even if the definition itself
+provides a prototype.  Use this option to detect global functions
+that do not have a matching prototype declaration in a header file.
+This option is not valid for \*(C+ because all function declarations
+provide prototypes and a non-matching declaration will declare an
+overload rather than conflict with an earlier declaration.
+Use \fB\-Wmissing\-declarations\fR to detect missing declarations in \*(C+.
+.IP "\fB\-Wmissing\-declarations\fR" 4
+.IX Item "-Wmissing-declarations"
+Warn if a global function is defined without a previous declaration.
+Do so even if the definition itself provides a prototype.
+Use this option to detect global functions that are not declared in
+header files.  In C, no warnings are issued for functions with previous
+non-prototype declarations; use \fB\-Wmissing\-prototype\fR to detect
+missing prototypes.  In \*(C+, no warnings are issued for function templates,
+or for inline functions, or for functions in anonymous namespaces.
+.IP "\fB\-Wmissing\-field\-initializers\fR" 4
+.IX Item "-Wmissing-field-initializers"
+Warn if a structure's initializer has some fields missing.  For
+example, the following code causes such a warning, because
+\&\f(CW\*(C`x.h\*(C'\fR is implicitly zero:
+.Sp
+.Vb 2
+\&        struct s { int f, g, h; };
+\&        struct s x = { 3, 4 };
+.Ve
+.Sp
+This option does not warn about designated initializers, so the following
+modification does not trigger a warning:
+.Sp
+.Vb 2
+\&        struct s { int f, g, h; };
+\&        struct s x = { .f = 3, .g = 4 };
+.Ve
+.Sp
+This warning is included in \fB\-Wextra\fR.  To get other \fB\-Wextra\fR
+warnings without this one, use \fB\-Wextra \-Wno\-missing\-field\-initializers\fR.
+.IP "\fB\-Wno\-multichar\fR" 4
+.IX Item "-Wno-multichar"
+Do not warn if a multicharacter constant (\fB'\s-1FOOF\s0'\fR) is used.
+Usually they indicate a typo in the user's code, as they have
+implementation-defined values, and should not be used in portable code.
+.IP "\fB\-Wnormalized=<none|id|nfc|nfkc>\fR" 4
+.IX Item "-Wnormalized=<none|id|nfc|nfkc>"
+In \s-1ISO C\s0 and \s-1ISO \*(C+,\s0 two identifiers are different if they are
+different sequences of characters.  However, sometimes when characters
+outside the basic \s-1ASCII\s0 character set are used, you can have two
+different character sequences that look the same.  To avoid confusion,
+the \s-1ISO 10646\s0 standard sets out some \fInormalization rules\fR which
+when applied ensure that two sequences that look the same are turned into
+the same sequence.  \s-1GCC\s0 can warn you if you are using identifiers that
+have not been normalized; this option controls that warning.
+.Sp
+There are four levels of warning supported by \s-1GCC. \s0 The default is
+\&\fB\-Wnormalized=nfc\fR, which warns about any identifier that is
+not in the \s-1ISO 10646 \*(L"C\*(R"\s0 normalized form, \fI\s-1NFC\s0\fR.  \s-1NFC\s0 is the
+recommended form for most uses.
+.Sp
+Unfortunately, there are some characters allowed in identifiers by
+\&\s-1ISO C\s0 and \s-1ISO \*(C+\s0 that, when turned into \s-1NFC,\s0 are not allowed in 
+identifiers.  That is, there's no way to use these symbols in portable
+\&\s-1ISO C\s0 or \*(C+ and have all your identifiers in \s-1NFC.
+\&\s0\fB\-Wnormalized=id\fR suppresses the warning for these characters.
+It is hoped that future versions of the standards involved will correct
+this, which is why this option is not the default.
+.Sp
+You can switch the warning off for all characters by writing
+\&\fB\-Wnormalized=none\fR.  You should only do this if you
+are using some other normalization scheme (like \*(L"D\*(R"), because
+otherwise you can easily create bugs that are literally impossible to see.
+.Sp
+Some characters in \s-1ISO 10646\s0 have distinct meanings but look identical
+in some fonts or display methodologies, especially once formatting has
+been applied.  For instance \f(CW\*(C`\eu207F\*(C'\fR, \*(L"\s-1SUPERSCRIPT LATIN SMALL
+LETTER N\*(R",\s0 displays just like a regular \f(CW\*(C`n\*(C'\fR that has been
+placed in a superscript.  \s-1ISO 10646\s0 defines the \fI\s-1NFKC\s0\fR
+normalization scheme to convert all these into a standard form as
+well, and \s-1GCC\s0 warns if your code is not in \s-1NFKC\s0 if you use
+\&\fB\-Wnormalized=nfkc\fR.  This warning is comparable to warning
+about every identifier that contains the letter O because it might be
+confused with the digit 0, and so is not the default, but may be
+useful as a local coding convention if the programming environment 
+cannot be fixed to display these characters distinctly.
+.IP "\fB\-Wno\-deprecated\fR" 4
+.IX Item "-Wno-deprecated"
+Do not warn about usage of deprecated features.
+.IP "\fB\-Wno\-deprecated\-declarations\fR" 4
+.IX Item "-Wno-deprecated-declarations"
+Do not warn about uses of functions,
+variables, and types marked as deprecated by using the \f(CW\*(C`deprecated\*(C'\fR
+attribute.
+.IP "\fB\-Wno\-overflow\fR" 4
+.IX Item "-Wno-overflow"
+Do not warn about compile-time overflow in constant expressions.
+.IP "\fB\-Wopenmp\-simd\fR" 4
+.IX Item "-Wopenmp-simd"
+Warn if the vectorizer cost model overrides the OpenMP or the Cilk Plus
+simd directive set by user.  The \fB\-fsimd\-cost\-model=unlimited\fR can
+be used to relax the cost model.
+.IP "\fB\-Woverride\-init\fR (C and Objective-C only)" 4
+.IX Item "-Woverride-init (C and Objective-C only)"
+Warn if an initialized field without side effects is overridden when
+using designated initializers.
+.Sp
+This warning is included in \fB\-Wextra\fR.  To get other
+\&\fB\-Wextra\fR warnings without this one, use \fB\-Wextra
+\&\-Wno\-override\-init\fR.
+.IP "\fB\-Wpacked\fR" 4
+.IX Item "-Wpacked"
+Warn if a structure is given the packed attribute, but the packed
+attribute has no effect on the layout or size of the structure.
+Such structures may be mis-aligned for little benefit.  For
+instance, in this code, the variable \f(CW\*(C`f.x\*(C'\fR in \f(CW\*(C`struct bar\*(C'\fR
+is misaligned even though \f(CW\*(C`struct bar\*(C'\fR does not itself
+have the packed attribute:
+.Sp
+.Vb 8
+\&        struct foo {
+\&          int x;
+\&          char a, b, c, d;
+\&        } _\|_attribute_\|_((packed));
+\&        struct bar {
+\&          char z;
+\&          struct foo f;
+\&        };
+.Ve
+.IP "\fB\-Wpacked\-bitfield\-compat\fR" 4
+.IX Item "-Wpacked-bitfield-compat"
+The 4.1, 4.2 and 4.3 series of \s-1GCC\s0 ignore the \f(CW\*(C`packed\*(C'\fR attribute
+on bit-fields of type \f(CW\*(C`char\*(C'\fR.  This has been fixed in \s-1GCC 4.4\s0 but
+the change can lead to differences in the structure layout.  \s-1GCC\s0
+informs you when the offset of such a field has changed in \s-1GCC 4.4.\s0
+For example there is no longer a 4\-bit padding between field \f(CW\*(C`a\*(C'\fR
+and \f(CW\*(C`b\*(C'\fR in this structure:
+.Sp
+.Vb 5
+\&        struct foo
+\&        {
+\&          char a:4;
+\&          char b:8;
+\&        } _\|_attribute_\|_ ((packed));
+.Ve
+.Sp
+This warning is enabled by default.  Use
+\&\fB\-Wno\-packed\-bitfield\-compat\fR to disable this warning.
+.IP "\fB\-Wpadded\fR" 4
+.IX Item "-Wpadded"
+Warn if padding is included in a structure, either to align an element
+of the structure or to align the whole structure.  Sometimes when this
+happens it is possible to rearrange the fields of the structure to
+reduce the padding and so make the structure smaller.
+.IP "\fB\-Wredundant\-decls\fR" 4
+.IX Item "-Wredundant-decls"
+Warn if anything is declared more than once in the same scope, even in
+cases where multiple declaration is valid and changes nothing.
+.IP "\fB\-Wnested\-externs\fR (C and Objective-C only)" 4
+.IX Item "-Wnested-externs (C and Objective-C only)"
+Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function.
+.IP "\fB\-Wno\-inherited\-variadic\-ctor\fR" 4
+.IX Item "-Wno-inherited-variadic-ctor"
+Suppress warnings about use of \*(C+11 inheriting constructors when the
+base class inherited from has a C variadic constructor; the warning is
+on by default because the ellipsis is not inherited.
+.IP "\fB\-Winline\fR" 4
+.IX Item "-Winline"
+Warn if a function that is declared as inline cannot be inlined.
+Even with this option, the compiler does not warn about failures to
+inline functions declared in system headers.
+.Sp
+The compiler uses a variety of heuristics to determine whether or not
+to inline a function.  For example, the compiler takes into account
+the size of the function being inlined and the amount of inlining
+that has already been done in the current function.  Therefore,
+seemingly insignificant changes in the source program can cause the
+warnings produced by \fB\-Winline\fR to appear or disappear.
+.IP "\fB\-Wno\-invalid\-offsetof\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-invalid-offsetof ( and Objective- only)"
+Suppress warnings from applying the \fBoffsetof\fR macro to a non-POD
+type.  According to the 1998 \s-1ISO \*(C+\s0 standard, applying \fBoffsetof\fR
+to a non-POD type is undefined.  In existing \*(C+ implementations,
+however, \fBoffsetof\fR typically gives meaningful results even when
+applied to certain kinds of non-POD types (such as a simple
+\&\fBstruct\fR that fails to be a \s-1POD\s0 type only by virtue of having a
+constructor).  This flag is for users who are aware that they are
+writing nonportable code and who have deliberately chosen to ignore the
+warning about it.
+.Sp
+The restrictions on \fBoffsetof\fR may be relaxed in a future version
+of the \*(C+ standard.
+.IP "\fB\-Wno\-int\-to\-pointer\-cast\fR" 4
+.IX Item "-Wno-int-to-pointer-cast"
+Suppress warnings from casts to pointer type of an integer of a
+different size. In \*(C+, casting to a pointer type of smaller size is
+an error. \fBWint-to-pointer-cast\fR is enabled by default.
+.IP "\fB\-Wno\-pointer\-to\-int\-cast\fR (C and Objective-C only)" 4
+.IX Item "-Wno-pointer-to-int-cast (C and Objective-C only)"
+Suppress warnings from casts from a pointer to an integer type of a
+different size.
+.IP "\fB\-Winvalid\-pch\fR" 4
+.IX Item "-Winvalid-pch"
+Warn if a precompiled header is found in
+the search path but can't be used.
+.IP "\fB\-Wlong\-long\fR" 4
+.IX Item "-Wlong-long"
+Warn if \fBlong long\fR type is used.  This is enabled by either
+\&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR in \s-1ISO C90\s0 and \*(C+98
+modes.  To inhibit the warning messages, use \fB\-Wno\-long\-long\fR.
+.IP "\fB\-Wvariadic\-macros\fR" 4
+.IX Item "-Wvariadic-macros"
+Warn if variadic macros are used in pedantic \s-1ISO C90\s0 mode, or the \s-1GNU\s0
+alternate syntax when in pedantic \s-1ISO C99\s0 mode.  This is default.
+To inhibit the warning messages, use \fB\-Wno\-variadic\-macros\fR.
+.IP "\fB\-Wvarargs\fR" 4
+.IX Item "-Wvarargs"
+Warn upon questionable usage of the macros used to handle variable
+arguments like \fBva_start\fR.  This is default.  To inhibit the
+warning messages, use \fB\-Wno\-varargs\fR.
+.IP "\fB\-Wvector\-operation\-performance\fR" 4
+.IX Item "-Wvector-operation-performance"
+Warn if vector operation is not implemented via \s-1SIMD\s0 capabilities of the
+architecture.  Mainly useful for the performance tuning.
+Vector operation can be implemented \f(CW\*(C`piecewise\*(C'\fR, which means that the
+scalar operation is performed on every vector element; 
+\&\f(CW\*(C`in parallel\*(C'\fR, which means that the vector operation is implemented
+using scalars of wider type, which normally is more performance efficient;
+and \f(CW\*(C`as a single scalar\*(C'\fR, which means that vector fits into a
+scalar type.
+.IP "\fB\-Wno\-virtual\-move\-assign\fR" 4
+.IX Item "-Wno-virtual-move-assign"
+Suppress warnings about inheriting from a virtual base with a
+non-trivial \*(C+11 move assignment operator.  This is dangerous because
+if the virtual base is reachable along more than one path, it will be
+moved multiple times, which can mean both objects end up in the
+moved-from state.  If the move assignment operator is written to avoid
+moving from a moved-from object, this warning can be disabled.
+.IP "\fB\-Wvla\fR" 4
+.IX Item "-Wvla"
+Warn if variable length array is used in the code.
+\&\fB\-Wno\-vla\fR prevents the \fB\-Wpedantic\fR warning of
+the variable length array.
+.IP "\fB\-Wvolatile\-register\-var\fR" 4
+.IX Item "-Wvolatile-register-var"
+Warn if a register variable is declared volatile.  The volatile
+modifier does not inhibit all optimizations that may eliminate reads
+and/or writes to register variables.  This warning is enabled by
+\&\fB\-Wall\fR.
+.IP "\fB\-Wdisabled\-optimization\fR" 4
+.IX Item "-Wdisabled-optimization"
+Warn if a requested optimization pass is disabled.  This warning does
+not generally indicate that there is anything wrong with your code; it
+merely indicates that \s-1GCC\s0's optimizers are unable to handle the code
+effectively.  Often, the problem is that your code is too big or too
+complex; \s-1GCC\s0 refuses to optimize programs when the optimization
+itself is likely to take inordinate amounts of time.
+.IP "\fB\-Wpointer\-sign\fR (C and Objective-C only)" 4
+.IX Item "-Wpointer-sign (C and Objective-C only)"
+Warn for pointer argument passing or assignment with different signedness.
+This option is only supported for C and Objective-C.  It is implied by
+\&\fB\-Wall\fR and by \fB\-Wpedantic\fR, which can be disabled with
+\&\fB\-Wno\-pointer\-sign\fR.
+.IP "\fB\-Wstack\-protector\fR" 4
+.IX Item "-Wstack-protector"
+This option is only active when \fB\-fstack\-protector\fR is active.  It
+warns about functions that are not protected against stack smashing.
+.IP "\fB\-Woverlength\-strings\fR" 4
+.IX Item "-Woverlength-strings"
+Warn about string constants that are longer than the \*(L"minimum
+maximum\*(R" length specified in the C standard.  Modern compilers
+generally allow string constants that are much longer than the
+standard's minimum limit, but very portable programs should avoid
+using longer strings.
+.Sp
+The limit applies \fIafter\fR string constant concatenation, and does
+not count the trailing \s-1NUL. \s0 In C90, the limit was 509 characters; in
+C99, it was raised to 4095.  \*(C+98 does not specify a normative
+minimum maximum, so we do not diagnose overlength strings in \*(C+.
+.Sp
+This option is implied by \fB\-Wpedantic\fR, and can be disabled with
+\&\fB\-Wno\-overlength\-strings\fR.
+.IP "\fB\-Wunsuffixed\-float\-constants\fR (C and Objective-C only)" 4
+.IX Item "-Wunsuffixed-float-constants (C and Objective-C only)"
+Issue a warning for any floating constant that does not have
+a suffix.  When used together with \fB\-Wsystem\-headers\fR it
+warns about such constants in system header files.  This can be useful
+when preparing code to use with the \f(CW\*(C`FLOAT_CONST_DECIMAL64\*(C'\fR pragma
+from the decimal floating-point extension to C99.
+.SS "Options for Debugging Your Program or \s-1GCC\s0"
+.IX Subsection "Options for Debugging Your Program or GCC"
+\&\s-1GCC\s0 has various special options that are used for debugging
+either your program or \s-1GCC:\s0
+.IP "\fB\-g\fR" 4
+.IX Item "-g"
+Produce debugging information in the operating system's native format
+(stabs, \s-1COFF, XCOFF,\s0 or \s-1DWARF 2\s0).  \s-1GDB\s0 can work with this debugging
+information.
+.Sp
+On most systems that use stabs format, \fB\-g\fR enables use of extra
+debugging information that only \s-1GDB\s0 can use; this extra information
+makes debugging work better in \s-1GDB\s0 but probably makes other debuggers
+crash or
+refuse to read the program.  If you want to control for certain whether
+to generate the extra information, use \fB\-gstabs+\fR, \fB\-gstabs\fR,
+\&\fB\-gxcoff+\fR, \fB\-gxcoff\fR, or \fB\-gvms\fR (see below).
+.Sp
+\&\s-1GCC\s0 allows you to use \fB\-g\fR with
+\&\fB\-O\fR.  The shortcuts taken by optimized code may occasionally
+produce surprising results: some variables you declared may not exist
+at all; flow of control may briefly move where you did not expect it;
+some statements may not be executed because they compute constant
+results or their values are already at hand; some statements may
+execute in different places because they have been moved out of loops.
+.Sp
+Nevertheless it proves possible to debug optimized output.  This makes
+it reasonable to use the optimizer for programs that might have bugs.
+.Sp
+The following options are useful when \s-1GCC\s0 is generated with the
+capability for more than one debugging format.
+.IP "\fB\-gsplit\-dwarf\fR" 4
+.IX Item "-gsplit-dwarf"
+Separate as much dwarf debugging information as possible into a
+separate output file with the extension .dwo.  This option allows
+the build system to avoid linking files with debug information.  To
+be useful, this option requires a debugger capable of reading .dwo
+files.
+.IP "\fB\-ggdb\fR" 4
+.IX Item "-ggdb"
+Produce debugging information for use by \s-1GDB. \s0 This means to use the
+most expressive format available (\s-1DWARF 2,\s0 stabs, or the native format
+if neither of those are supported), including \s-1GDB\s0 extensions if at all
+possible.
+.IP "\fB\-gpubnames\fR" 4
+.IX Item "-gpubnames"
+Generate dwarf .debug_pubnames and .debug_pubtypes sections.
+.IP "\fB\-ggnu\-pubnames\fR" 4
+.IX Item "-ggnu-pubnames"
+Generate .debug_pubnames and .debug_pubtypes sections in a format
+suitable for conversion into a \s-1GDB\s0 index.  This option is only useful
+with a linker that can produce \s-1GDB\s0 index version 7.
+.IP "\fB\-gstabs\fR" 4
+.IX Item "-gstabs"
+Produce debugging information in stabs format (if that is supported),
+without \s-1GDB\s0 extensions.  This is the format used by \s-1DBX\s0 on most \s-1BSD\s0
+systems.  On \s-1MIPS,\s0 Alpha and System V Release 4 systems this option
+produces stabs debugging output that is not understood by \s-1DBX\s0 or \s-1SDB.\s0
+On System V Release 4 systems this option requires the \s-1GNU\s0 assembler.
+.IP "\fB\-feliminate\-unused\-debug\-symbols\fR" 4
+.IX Item "-feliminate-unused-debug-symbols"
+Produce debugging information in stabs format (if that is supported),
+for only symbols that are actually used.
+.IP "\fB\-femit\-class\-debug\-always\fR" 4
+.IX Item "-femit-class-debug-always"
+Instead of emitting debugging information for a \*(C+ class in only one
+object file, emit it in all object files using the class.  This option
+should be used only with debuggers that are unable to handle the way \s-1GCC\s0
+normally emits debugging information for classes because using this
+option increases the size of debugging information by as much as a
+factor of two.
+.IP "\fB\-fdebug\-types\-section\fR" 4
+.IX Item "-fdebug-types-section"
+When using \s-1DWARF\s0 Version 4 or higher, type DIEs can be put into
+their own \f(CW\*(C`.debug_types\*(C'\fR section instead of making them part of the
+\&\f(CW\*(C`.debug_info\*(C'\fR section.  It is more efficient to put them in a separate
+comdat sections since the linker can then remove duplicates.
+But not all \s-1DWARF\s0 consumers support \f(CW\*(C`.debug_types\*(C'\fR sections yet
+and on some objects \f(CW\*(C`.debug_types\*(C'\fR produces larger instead of smaller
+debugging information.
+.IP "\fB\-gstabs+\fR" 4
+.IX Item "-gstabs+"
+Produce debugging information in stabs format (if that is supported),
+using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0).  The
+use of these extensions is likely to make other debuggers crash or
+refuse to read the program.
+.IP "\fB\-gcoff\fR" 4
+.IX Item "-gcoff"
+Produce debugging information in \s-1COFF\s0 format (if that is supported).
+This is the format used by \s-1SDB\s0 on most System V systems prior to
+System V Release 4.
+.IP "\fB\-gxcoff\fR" 4
+.IX Item "-gxcoff"
+Produce debugging information in \s-1XCOFF\s0 format (if that is supported).
+This is the format used by the \s-1DBX\s0 debugger on \s-1IBM RS/6000\s0 systems.
+.IP "\fB\-gxcoff+\fR" 4
+.IX Item "-gxcoff+"
+Produce debugging information in \s-1XCOFF\s0 format (if that is supported),
+using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0).  The
+use of these extensions is likely to make other debuggers crash or
+refuse to read the program, and may cause assemblers other than the \s-1GNU\s0
+assembler (\s-1GAS\s0) to fail with an error.
+.IP "\fB\-gdwarf\-\fR\fIversion\fR" 4
+.IX Item "-gdwarf-version"
+Produce debugging information in \s-1DWARF\s0 format (if that is supported).
+The value of \fIversion\fR may be either 2, 3 or 4; the default version
+for most targets is 4.
+.Sp
+Note that with \s-1DWARF\s0 Version 2, some ports require and always
+use some non-conflicting \s-1DWARF 3\s0 extensions in the unwind tables.
+.Sp
+Version 4 may require \s-1GDB 7.0\s0 and \fB\-fvar\-tracking\-assignments\fR
+for maximum benefit.
+.IP "\fB\-grecord\-gcc\-switches\fR" 4
+.IX Item "-grecord-gcc-switches"
+This switch causes the command-line options used to invoke the
+compiler that may affect code generation to be appended to the
+DW_AT_producer attribute in \s-1DWARF\s0 debugging information.  The options
+are concatenated with spaces separating them from each other and from
+the compiler version.  See also \fB\-frecord\-gcc\-switches\fR for another
+way of storing compiler options into the object file.  This is the default.
+.IP "\fB\-gno\-record\-gcc\-switches\fR" 4
+.IX Item "-gno-record-gcc-switches"
+Disallow appending command-line options to the DW_AT_producer attribute
+in \s-1DWARF\s0 debugging information.
+.IP "\fB\-gstrict\-dwarf\fR" 4
+.IX Item "-gstrict-dwarf"
+Disallow using extensions of later \s-1DWARF\s0 standard version than selected
+with \fB\-gdwarf\-\fR\fIversion\fR.  On most targets using non-conflicting
+\&\s-1DWARF\s0 extensions from later standard versions is allowed.
+.IP "\fB\-gno\-strict\-dwarf\fR" 4
+.IX Item "-gno-strict-dwarf"
+Allow using extensions of later \s-1DWARF\s0 standard version than selected with
+\&\fB\-gdwarf\-\fR\fIversion\fR.
+.IP "\fB\-gvms\fR" 4
+.IX Item "-gvms"
+Produce debugging information in Alpha/VMS debug format (if that is
+supported).  This is the format used by \s-1DEBUG\s0 on Alpha/VMS systems.
+.IP "\fB\-g\fR\fIlevel\fR" 4
+.IX Item "-glevel"
+.PD 0
+.IP "\fB\-ggdb\fR\fIlevel\fR" 4
+.IX Item "-ggdblevel"
+.IP "\fB\-gstabs\fR\fIlevel\fR" 4
+.IX Item "-gstabslevel"
+.IP "\fB\-gcoff\fR\fIlevel\fR" 4
+.IX Item "-gcofflevel"
+.IP "\fB\-gxcoff\fR\fIlevel\fR" 4
+.IX Item "-gxcofflevel"
+.IP "\fB\-gvms\fR\fIlevel\fR" 4
+.IX Item "-gvmslevel"
+.PD
+Request debugging information and also use \fIlevel\fR to specify how
+much information.  The default level is 2.
+.Sp
+Level 0 produces no debug information at all.  Thus, \fB\-g0\fR negates
+\&\fB\-g\fR.
+.Sp
+Level 1 produces minimal information, enough for making backtraces in
+parts of the program that you don't plan to debug.  This includes
+descriptions of functions and external variables, and line number
+tables, but no information about local variables.
+.Sp
+Level 3 includes extra information, such as all the macro definitions
+present in the program.  Some debuggers support macro expansion when
+you use \fB\-g3\fR.
+.Sp
+\&\fB\-gdwarf\-2\fR does not accept a concatenated debug level, because
+\&\s-1GCC\s0 used to support an option \fB\-gdwarf\fR that meant to generate
+debug information in version 1 of the \s-1DWARF\s0 format (which is very
+different from version 2), and it would have been too confusing.  That
+debug format is long obsolete, but the option cannot be changed now.
+Instead use an additional \fB\-g\fR\fIlevel\fR option to change the
+debug level for \s-1DWARF.\s0
+.IP "\fB\-gtoggle\fR" 4
+.IX Item "-gtoggle"
+Turn off generation of debug info, if leaving out this option
+generates it, or turn it on at level 2 otherwise.  The position of this
+argument in the command line does not matter; it takes effect after all
+other options are processed, and it does so only once, no matter how
+many times it is given.  This is mainly intended to be used with
+\&\fB\-fcompare\-debug\fR.
+.IP "\fB\-fsanitize=address\fR" 4
+.IX Item "-fsanitize=address"
+Enable AddressSanitizer, a fast memory error detector.
+Memory access instructions will be instrumented to detect
+out-of-bounds and use-after-free bugs.
+See <\fBhttp://code.google.com/p/address\-sanitizer/\fR> for
+more details.  The run-time behavior can be influenced using the
+\&\fB\s-1ASAN_OPTIONS\s0\fR environment variable; see
+<\fBhttps://code.google.com/p/address\-sanitizer/wiki/Flags#Run\-time_flags\fR> for
+a list of supported options.
+.IP "\fB\-fsanitize=thread\fR" 4
+.IX Item "-fsanitize=thread"
+Enable ThreadSanitizer, a fast data race detector.
+Memory access instructions will be instrumented to detect
+data race bugs.  See <\fBhttp://code.google.com/p/thread\-sanitizer/\fR> for more
+details. The run-time behavior can be influenced using the \fB\s-1TSAN_OPTIONS\s0\fR
+environment variable; see
+<\fBhttps://code.google.com/p/thread\-sanitizer/wiki/Flags\fR> for a list of
+supported options.
+.IP "\fB\-fsanitize=leak\fR" 4
+.IX Item "-fsanitize=leak"
+Enable LeakSanitizer, a memory leak detector.
+This option only matters for linking of executables and if neither
+\&\fB\-fsanitize=address\fR nor \fB\-fsanitize=thread\fR is used.  In that
+case it will link the executable against a library that overrides \f(CW\*(C`malloc\*(C'\fR
+and other allocator functions.  See
+<\fBhttps://code.google.com/p/address\-sanitizer/wiki/LeakSanitizer\fR> for more
+details.  The run-time behavior can be influenced using the
+\&\fB\s-1LSAN_OPTIONS\s0\fR environment variable.
+.IP "\fB\-fsanitize=undefined\fR" 4
+.IX Item "-fsanitize=undefined"
+Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
+Various computations will be instrumented to detect undefined behavior
+at runtime.  Current suboptions are:
+.RS 4
+.IP "\fB\-fsanitize=shift\fR" 4
+.IX Item "-fsanitize=shift"
+This option enables checking that the result of a shift operation is
+not undefined.  Note that what exactly is considered undefined differs
+slightly between C and \*(C+, as well as between \s-1ISO C90\s0 and C99, etc.
+.IP "\fB\-fsanitize=integer\-divide\-by\-zero\fR" 4
+.IX Item "-fsanitize=integer-divide-by-zero"
+Detect integer division by zero as well as \f(CW\*(C`INT_MIN / \-1\*(C'\fR division.
+.IP "\fB\-fsanitize=unreachable\fR" 4
+.IX Item "-fsanitize=unreachable"
+With this option, the compiler will turn the \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR
+call into a diagnostics message call instead.  When reaching the
+\&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR call, the behavior is undefined.
+.IP "\fB\-fsanitize=vla\-bound\fR" 4
+.IX Item "-fsanitize=vla-bound"
+This option instructs the compiler to check that the size of a variable
+length array is positive.  This option does not have any effect in
+\&\fB\-std=c++1y\fR mode, as the standard requires the exception be thrown
+instead.
+.IP "\fB\-fsanitize=null\fR" 4
+.IX Item "-fsanitize=null"
+This option enables pointer checking.  Particularly, the application
+built with this option turned on will issue an error message when it
+tries to dereference a \s-1NULL\s0 pointer, or if a reference (possibly an
+rvalue reference) is bound to a \s-1NULL\s0 pointer.
+.IP "\fB\-fsanitize=return\fR" 4
+.IX Item "-fsanitize=return"
+This option enables return statement checking.  Programs
+built with this option turned on will issue an error message
+when the end of a non-void function is reached without actually
+returning a value.  This option works in \*(C+ only.
+.IP "\fB\-fsanitize=signed\-integer\-overflow\fR" 4
+.IX Item "-fsanitize=signed-integer-overflow"
+This option enables signed integer overflow checking.  We check that
+the result of \f(CW\*(C`+\*(C'\fR, \f(CW\*(C`*\*(C'\fR, and both unary and binary \f(CW\*(C`\-\*(C'\fR
+does not overflow in the signed arithmetics.  Note, integer promotion
+rules must be taken into account.  That is, the following is not an
+overflow:
+.Sp
+.Vb 2
+\&        signed char a = SCHAR_MAX;
+\&        a++;
+.Ve
+.RE
+.RS 4
+.Sp
+While \fB\-ftrapv\fR causes traps for signed overflows to be emitted,
+\&\fB\-fsanitize=undefined\fR gives a diagnostic message.
+This currently works only for the C family of languages.
+.RE
+.IP "\fB\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]" 4
+.IX Item "-fdump-final-insns[=file]"
+Dump the final internal representation (\s-1RTL\s0) to \fIfile\fR.  If the
+optional argument is omitted (or if \fIfile\fR is \f(CW\*(C`.\*(C'\fR), the name
+of the dump file is determined by appending \f(CW\*(C`.gkd\*(C'\fR to the
+compilation output file name.
+.IP "\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]" 4
+.IX Item "-fcompare-debug[=opts]"
+If no error occurs during compilation, run the compiler a second time,
+adding \fIopts\fR and \fB\-fcompare\-debug\-second\fR to the arguments
+passed to the second compilation.  Dump the final internal
+representation in both compilations, and print an error if they differ.
+.Sp
+If the equal sign is omitted, the default \fB\-gtoggle\fR is used.
+.Sp
+The environment variable \fB\s-1GCC_COMPARE_DEBUG\s0\fR, if defined, non-empty
+and nonzero, implicitly enables \fB\-fcompare\-debug\fR.  If
+\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR is defined to a string starting with a dash,
+then it is used for \fIopts\fR, otherwise the default \fB\-gtoggle\fR
+is used.
+.Sp
+\&\fB\-fcompare\-debug=\fR, with the equal sign but without \fIopts\fR,
+is equivalent to \fB\-fno\-compare\-debug\fR, which disables the dumping
+of the final representation and the second compilation, preventing even
+\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR from taking effect.
+.Sp
+To verify full coverage during \fB\-fcompare\-debug\fR testing, set
+\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR to say \fB\-fcompare\-debug\-not\-overridden\fR,
+which \s-1GCC\s0 rejects as an invalid option in any actual compilation
+(rather than preprocessing, assembly or linking).  To get just a
+warning, setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR to \fB\-w%n\-fcompare\-debug
+not overridden\fR will do.
+.IP "\fB\-fcompare\-debug\-second\fR" 4
+.IX Item "-fcompare-debug-second"
+This option is implicitly passed to the compiler for the second
+compilation requested by \fB\-fcompare\-debug\fR, along with options to
+silence warnings, and omitting other options that would cause
+side-effect compiler outputs to files or to the standard output.  Dump
+files and preserved temporary files are renamed so as to contain the
+\&\f(CW\*(C`.gk\*(C'\fR additional extension during the second compilation, to avoid
+overwriting those generated by the first.
+.Sp
+When this option is passed to the compiler driver, it causes the
+\&\fIfirst\fR compilation to be skipped, which makes it useful for little
+other than debugging the compiler proper.
+.IP "\fB\-feliminate\-dwarf2\-dups\fR" 4
+.IX Item "-feliminate-dwarf2-dups"
+Compress \s-1DWARF 2\s0 debugging information by eliminating duplicated
+information about each symbol.  This option only makes sense when
+generating \s-1DWARF 2\s0 debugging information with \fB\-gdwarf\-2\fR.
+.IP "\fB\-femit\-struct\-debug\-baseonly\fR" 4
+.IX Item "-femit-struct-debug-baseonly"
+Emit debug information for struct-like types
+only when the base name of the compilation source file
+matches the base name of file in which the struct is defined.
+.Sp
+This option substantially reduces the size of debugging information,
+but at significant potential loss in type information to the debugger.
+See \fB\-femit\-struct\-debug\-reduced\fR for a less aggressive option.
+See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
+.Sp
+This option works only with \s-1DWARF 2.\s0
+.IP "\fB\-femit\-struct\-debug\-reduced\fR" 4
+.IX Item "-femit-struct-debug-reduced"
+Emit debug information for struct-like types
+only when the base name of the compilation source file
+matches the base name of file in which the type is defined,
+unless the struct is a template or defined in a system header.
+.Sp
+This option significantly reduces the size of debugging information,
+with some potential loss in type information to the debugger.
+See \fB\-femit\-struct\-debug\-baseonly\fR for a more aggressive option.
+See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
+.Sp
+This option works only with \s-1DWARF 2.\s0
+.IP "\fB\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]" 4
+.IX Item "-femit-struct-debug-detailed[=spec-list]"
+Specify the struct-like types
+for which the compiler generates debug information.
+The intent is to reduce duplicate struct debug information
+between different object files within the same program.
+.Sp
+This option is a detailed version of
+\&\fB\-femit\-struct\-debug\-reduced\fR and \fB\-femit\-struct\-debug\-baseonly\fR,
+which serves for most needs.
+.Sp
+A specification has the syntax[\fBdir:\fR|\fBind:\fR][\fBord:\fR|\fBgen:\fR](\fBany\fR|\fBsys\fR|\fBbase\fR|\fBnone\fR)
+.Sp
+The optional first word limits the specification to
+structs that are used directly (\fBdir:\fR) or used indirectly (\fBind:\fR).
+A struct type is used directly when it is the type of a variable, member.
+Indirect uses arise through pointers to structs.
+That is, when use of an incomplete struct is valid, the use is indirect.
+An example is
+\&\fBstruct one direct; struct two * indirect;\fR.
+.Sp
+The optional second word limits the specification to
+ordinary structs (\fBord:\fR) or generic structs (\fBgen:\fR).
+Generic structs are a bit complicated to explain.
+For \*(C+, these are non-explicit specializations of template classes,
+or non-template classes within the above.
+Other programming languages have generics,
+but \fB\-femit\-struct\-debug\-detailed\fR does not yet implement them.
+.Sp
+The third word specifies the source files for those
+structs for which the compiler should emit debug information.
+The values \fBnone\fR and \fBany\fR have the normal meaning.
+The value \fBbase\fR means that
+the base of name of the file in which the type declaration appears
+must match the base of the name of the main compilation file.
+In practice, this means that when compiling \fIfoo.c\fR, debug information
+is generated for types declared in that file and \fIfoo.h\fR,
+but not other header files.
+The value \fBsys\fR means those types satisfying \fBbase\fR
+or declared in system or compiler headers.
+.Sp
+You may need to experiment to determine the best settings for your application.
+.Sp
+The default is \fB\-femit\-struct\-debug\-detailed=all\fR.
+.Sp
+This option works only with \s-1DWARF 2.\s0
+.IP "\fB\-fno\-merge\-debug\-strings\fR" 4
+.IX Item "-fno-merge-debug-strings"
+Direct the linker to not merge together strings in the debugging
+information that are identical in different object files.  Merging is
+not supported by all assemblers or linkers.  Merging decreases the size
+of the debug information in the output file at the cost of increasing
+link processing time.  Merging is enabled by default.
+.IP "\fB\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
+.IX Item "-fdebug-prefix-map=old=new"
+When compiling files in directory \fI\fIold\fI\fR, record debugging
+information describing them as in \fI\fInew\fI\fR instead.
+.IP "\fB\-fno\-dwarf2\-cfi\-asm\fR" 4
+.IX Item "-fno-dwarf2-cfi-asm"
+Emit \s-1DWARF 2\s0 unwind info as compiler generated \f(CW\*(C`.eh_frame\*(C'\fR section
+instead of using \s-1GAS \s0\f(CW\*(C`.cfi_*\*(C'\fR directives.
+.IP "\fB\-p\fR" 4
+.IX Item "-p"
+Generate extra code to write profile information suitable for the
+analysis program \fBprof\fR.  You must use this option when compiling
+the source files you want data about, and you must also use it when
+linking.
+.IP "\fB\-pg\fR" 4
+.IX Item "-pg"
+Generate extra code to write profile information suitable for the
+analysis program \fBgprof\fR.  You must use this option when compiling
+the source files you want data about, and you must also use it when
+linking.
+.IP "\fB\-Q\fR" 4
+.IX Item "-Q"
+Makes the compiler print out each function name as it is compiled, and
+print some statistics about each pass when it finishes.
+.IP "\fB\-ftime\-report\fR" 4
+.IX Item "-ftime-report"
+Makes the compiler print some statistics about the time consumed by each
+pass when it finishes.
+.IP "\fB\-fmem\-report\fR" 4
+.IX Item "-fmem-report"
+Makes the compiler print some statistics about permanent memory
+allocation when it finishes.
+.IP "\fB\-fmem\-report\-wpa\fR" 4
+.IX Item "-fmem-report-wpa"
+Makes the compiler print some statistics about permanent memory
+allocation for the \s-1WPA\s0 phase only.
+.IP "\fB\-fpre\-ipa\-mem\-report\fR" 4
+.IX Item "-fpre-ipa-mem-report"
+.PD 0
+.IP "\fB\-fpost\-ipa\-mem\-report\fR" 4
+.IX Item "-fpost-ipa-mem-report"
+.PD
+Makes the compiler print some statistics about permanent memory
+allocation before or after interprocedural optimization.
+.IP "\fB\-fprofile\-report\fR" 4
+.IX Item "-fprofile-report"
+Makes the compiler print some statistics about consistency of the
+(estimated) profile and effect of individual passes.
+.IP "\fB\-fstack\-usage\fR" 4
+.IX Item "-fstack-usage"
+Makes the compiler output stack usage information for the program, on a
+per-function basis.  The filename for the dump is made by appending
+\&\fI.su\fR to the \fIauxname\fR.  \fIauxname\fR is generated from the name of
+the output file, if explicitly specified and it is not an executable,
+otherwise it is the basename of the source file.  An entry is made up
+of three fields:
+.RS 4
+.IP "\(bu" 4
+The name of the function.
+.IP "\(bu" 4
+A number of bytes.
+.IP "\(bu" 4
+One or more qualifiers: \f(CW\*(C`static\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`bounded\*(C'\fR.
+.RE
+.RS 4
+.Sp
+The qualifier \f(CW\*(C`static\*(C'\fR means that the function manipulates the stack
+statically: a fixed number of bytes are allocated for the frame on function
+entry and released on function exit; no stack adjustments are otherwise made
+in the function.  The second field is this fixed number of bytes.
+.Sp
+The qualifier \f(CW\*(C`dynamic\*(C'\fR means that the function manipulates the stack
+dynamically: in addition to the static allocation described above, stack
+adjustments are made in the body of the function, for example to push/pop
+arguments around function calls.  If the qualifier \f(CW\*(C`bounded\*(C'\fR is also
+present, the amount of these adjustments is bounded at compile time and
+the second field is an upper bound of the total amount of stack used by
+the function.  If it is not present, the amount of these adjustments is
+not bounded at compile time and the second field only represents the
+bounded part.
+.RE
+.IP "\fB\-fprofile\-arcs\fR" 4
+.IX Item "-fprofile-arcs"
+Add code so that program flow \fIarcs\fR are instrumented.  During
+execution the program records how many times each branch and call is
+executed and how many times it is taken or returns.  When the compiled
+program exits it saves this data to a file called
+\&\fI\fIauxname\fI.gcda\fR for each source file.  The data may be used for
+profile-directed optimizations (\fB\-fbranch\-probabilities\fR), or for
+test coverage analysis (\fB\-ftest\-coverage\fR).  Each object file's
+\&\fIauxname\fR is generated from the name of the output file, if
+explicitly specified and it is not the final executable, otherwise it is
+the basename of the source file.  In both cases any suffix is removed
+(e.g. \fIfoo.gcda\fR for input file \fIdir/foo.c\fR, or
+\&\fIdir/foo.gcda\fR for output file specified as \fB\-o dir/foo.o\fR).
+.IP "\fB\-\-coverage\fR" 4
+.IX Item "--coverage"
+This option is used to compile and link code instrumented for coverage
+analysis.  The option is a synonym for \fB\-fprofile\-arcs\fR
+\&\fB\-ftest\-coverage\fR (when compiling) and \fB\-lgcov\fR (when
+linking).  See the documentation for those options for more details.
+.RS 4
+.IP "\(bu" 4
+Compile the source files with \fB\-fprofile\-arcs\fR plus optimization
+and code generation options.  For test coverage analysis, use the
+additional \fB\-ftest\-coverage\fR option.  You do not need to profile
+every source file in a program.
+.IP "\(bu" 4
+Link your object files with \fB\-lgcov\fR or \fB\-fprofile\-arcs\fR
+(the latter implies the former).
+.IP "\(bu" 4
+Run the program on a representative workload to generate the arc profile
+information.  This may be repeated any number of times.  You can run
+concurrent instances of your program, and provided that the file system
+supports locking, the data files will be correctly updated.  Also
+\&\f(CW\*(C`fork\*(C'\fR calls are detected and correctly handled (double counting
+will not happen).
+.IP "\(bu" 4
+For profile-directed optimizations, compile the source files again with
+the same optimization and code generation options plus
+\&\fB\-fbranch\-probabilities\fR.
+.IP "\(bu" 4
+For test coverage analysis, use \fBgcov\fR to produce human readable
+information from the \fI.gcno\fR and \fI.gcda\fR files.  Refer to the
+\&\fBgcov\fR documentation for further information.
+.RE
+.RS 4
+.Sp
+With \fB\-fprofile\-arcs\fR, for each function of your program \s-1GCC\s0
+creates a program flow graph, then finds a spanning tree for the graph.
+Only arcs that are not on the spanning tree have to be instrumented: the
+compiler adds code to count the number of times that these arcs are
+executed.  When an arc is the only exit or only entrance to a block, the
+instrumentation code can be added to the block; otherwise, a new basic
+block must be created to hold the instrumentation code.
+.RE
+.IP "\fB\-ftest\-coverage\fR" 4
+.IX Item "-ftest-coverage"
+Produce a notes file that the \fBgcov\fR code-coverage utility can use to
+show program coverage.  Each source file's note file is called
+\&\fI\fIauxname\fI.gcno\fR.  Refer to the \fB\-fprofile\-arcs\fR option
+above for a description of \fIauxname\fR and instructions on how to
+generate test coverage data.  Coverage data matches the source files
+more closely if you do not optimize.
+.IP "\fB\-fdbg\-cnt\-list\fR" 4
+.IX Item "-fdbg-cnt-list"
+Print the name and the counter upper bound for all debug counters.
+.IP "\fB\-fdbg\-cnt=\fR\fIcounter-value-list\fR" 4
+.IX Item "-fdbg-cnt=counter-value-list"
+Set the internal debug counter upper bound.  \fIcounter-value-list\fR
+is a comma-separated list of \fIname\fR:\fIvalue\fR pairs
+which sets the upper bound of each debug counter \fIname\fR to \fIvalue\fR.
+All debug counters have the initial upper bound of \f(CW\*(C`UINT_MAX\*(C'\fR;
+thus \f(CW\*(C`dbg_cnt()\*(C'\fR returns true always unless the upper bound
+is set by this option.
+For example, with \fB\-fdbg\-cnt=dce:10,tail_call:0\fR,
+\&\f(CW\*(C`dbg_cnt(dce)\*(C'\fR returns true only for first 10 invocations.
+.IP "\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR" 4
+.IX Item "-fenable-kind-pass"
+.PD 0
+.IP "\fB\-fdisable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fdisable-kind-pass=range-list"
+.PD
+This is a set of options that are used to explicitly disable/enable
+optimization passes.  These options are intended for use for debugging \s-1GCC.\s0
+Compiler users should use regular options for enabling/disabling
+passes instead.
+.RS 4
+.IP "\fB\-fdisable\-ipa\-\fR\fIpass\fR" 4
+.IX Item "-fdisable-ipa-pass"
+Disable \s-1IPA\s0 pass \fIpass\fR. \fIpass\fR is the pass name.  If the same pass is
+statically invoked in the compiler multiple times, the pass name should be
+appended with a sequential number starting from 1.
+.IP "\fB\-fdisable\-rtl\-\fR\fIpass\fR" 4
+.IX Item "-fdisable-rtl-pass"
+.PD 0
+.IP "\fB\-fdisable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fdisable-rtl-pass=range-list"
+.PD
+Disable \s-1RTL\s0 pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
+statically invoked in the compiler multiple times, the pass name should be
+appended with a sequential number starting from 1.  \fIrange-list\fR is a 
+comma-separated list of function ranges or assembler names.  Each range is a number
+pair separated by a colon.  The range is inclusive in both ends.  If the range
+is trivial, the number pair can be simplified as a single number.  If the
+function's call graph node's \fIuid\fR falls within one of the specified ranges,
+the \fIpass\fR is disabled for that function.  The \fIuid\fR is shown in the
+function header of a dump file, and the pass names can be dumped by using
+option \fB\-fdump\-passes\fR.
+.IP "\fB\-fdisable\-tree\-\fR\fIpass\fR" 4
+.IX Item "-fdisable-tree-pass"
+.PD 0
+.IP "\fB\-fdisable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fdisable-tree-pass=range-list"
+.PD
+Disable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description of
+option arguments.
+.IP "\fB\-fenable\-ipa\-\fR\fIpass\fR" 4
+.IX Item "-fenable-ipa-pass"
+Enable \s-1IPA\s0 pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
+statically invoked in the compiler multiple times, the pass name should be
+appended with a sequential number starting from 1.
+.IP "\fB\-fenable\-rtl\-\fR\fIpass\fR" 4
+.IX Item "-fenable-rtl-pass"
+.PD 0
+.IP "\fB\-fenable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fenable-rtl-pass=range-list"
+.PD
+Enable \s-1RTL\s0 pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for option argument
+description and examples.
+.IP "\fB\-fenable\-tree\-\fR\fIpass\fR" 4
+.IX Item "-fenable-tree-pass"
+.PD 0
+.IP "\fB\-fenable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fenable-tree-pass=range-list"
+.PD
+Enable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description
+of option arguments.
+.RE
+.RS 4
+.Sp
+Here are some examples showing uses of these options.
+.Sp
+.Vb 10
+\&        # disable ccp1 for all functions
+\&           \-fdisable\-tree\-ccp1
+\&        # disable complete unroll for function whose cgraph node uid is 1
+\&           \-fenable\-tree\-cunroll=1
+\&        # disable gcse2 for functions at the following ranges [1,1],
+\&        # [300,400], and [400,1000]
+\&        # disable gcse2 for functions foo and foo2
+\&           \-fdisable\-rtl\-gcse2=foo,foo2
+\&        # disable early inlining
+\&           \-fdisable\-tree\-einline
+\&        # disable ipa inlining
+\&           \-fdisable\-ipa\-inline
+\&        # enable tree full unroll
+\&           \-fenable\-tree\-unroll
+.Ve
+.RE
+.IP "\fB\-d\fR\fIletters\fR" 4
+.IX Item "-dletters"
+.PD 0
+.IP "\fB\-fdump\-rtl\-\fR\fIpass\fR" 4
+.IX Item "-fdump-rtl-pass"
+.IP "\fB\-fdump\-rtl\-\fR\fIpass\fR\fB=\fR\fIfilename\fR" 4
+.IX Item "-fdump-rtl-pass=filename"
+.PD
+Says to make debugging dumps during compilation at times specified by
+\&\fIletters\fR.  This is used for debugging the RTL-based passes of the
+compiler.  The file names for most of the dumps are made by appending
+a pass number and a word to the \fIdumpname\fR, and the files are
+created in the directory of the output file. In case of
+\&\fB=\fR\fIfilename\fR option, the dump is output on the given file
+instead of the pass numbered dump files. Note that the pass number is
+computed statically as passes get registered into the pass manager.
+Thus the numbering is not related to the dynamic order of execution of
+passes.  In particular, a pass installed by a plugin could have a
+number over 200 even if it executed quite early.  \fIdumpname\fR is
+generated from the name of the output file, if explicitly specified
+and it is not an executable, otherwise it is the basename of the
+source file. These switches may have different effects when
+\&\fB\-E\fR is used for preprocessing.
+.Sp
+Debug dumps can be enabled with a \fB\-fdump\-rtl\fR switch or some
+\&\fB\-d\fR option \fIletters\fR.  Here are the possible
+letters for use in \fIpass\fR and \fIletters\fR, and their meanings:
+.RS 4
+.IP "\fB\-fdump\-rtl\-alignments\fR" 4
+.IX Item "-fdump-rtl-alignments"
+Dump after branch alignments have been computed.
+.IP "\fB\-fdump\-rtl\-asmcons\fR" 4
+.IX Item "-fdump-rtl-asmcons"
+Dump after fixing rtl statements that have unsatisfied in/out constraints.
+.IP "\fB\-fdump\-rtl\-auto_inc_dec\fR" 4
+.IX Item "-fdump-rtl-auto_inc_dec"
+Dump after auto-inc-dec discovery.  This pass is only run on
+architectures that have auto inc or auto dec instructions.
+.IP "\fB\-fdump\-rtl\-barriers\fR" 4
+.IX Item "-fdump-rtl-barriers"
+Dump after cleaning up the barrier instructions.
+.IP "\fB\-fdump\-rtl\-bbpart\fR" 4
+.IX Item "-fdump-rtl-bbpart"
+Dump after partitioning hot and cold basic blocks.
+.IP "\fB\-fdump\-rtl\-bbro\fR" 4
+.IX Item "-fdump-rtl-bbro"
+Dump after block reordering.
+.IP "\fB\-fdump\-rtl\-btl1\fR" 4
+.IX Item "-fdump-rtl-btl1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-btl2\fR" 4
+.IX Item "-fdump-rtl-btl2"
+.PD
+\&\fB\-fdump\-rtl\-btl1\fR and \fB\-fdump\-rtl\-btl2\fR enable dumping
+after the two branch
+target load optimization passes.
+.IP "\fB\-fdump\-rtl\-bypass\fR" 4
+.IX Item "-fdump-rtl-bypass"
+Dump after jump bypassing and control flow optimizations.
+.IP "\fB\-fdump\-rtl\-combine\fR" 4
+.IX Item "-fdump-rtl-combine"
+Dump after the \s-1RTL\s0 instruction combination pass.
+.IP "\fB\-fdump\-rtl\-compgotos\fR" 4
+.IX Item "-fdump-rtl-compgotos"
+Dump after duplicating the computed gotos.
+.IP "\fB\-fdump\-rtl\-ce1\fR" 4
+.IX Item "-fdump-rtl-ce1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-ce2\fR" 4
+.IX Item "-fdump-rtl-ce2"
+.IP "\fB\-fdump\-rtl\-ce3\fR" 4
+.IX Item "-fdump-rtl-ce3"
+.PD
+\&\fB\-fdump\-rtl\-ce1\fR, \fB\-fdump\-rtl\-ce2\fR, and
+\&\fB\-fdump\-rtl\-ce3\fR enable dumping after the three
+if conversion passes.
+.IP "\fB\-fdump\-rtl\-cprop_hardreg\fR" 4
+.IX Item "-fdump-rtl-cprop_hardreg"
+Dump after hard register copy propagation.
+.IP "\fB\-fdump\-rtl\-csa\fR" 4
+.IX Item "-fdump-rtl-csa"
+Dump after combining stack adjustments.
+.IP "\fB\-fdump\-rtl\-cse1\fR" 4
+.IX Item "-fdump-rtl-cse1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-cse2\fR" 4
+.IX Item "-fdump-rtl-cse2"
+.PD
+\&\fB\-fdump\-rtl\-cse1\fR and \fB\-fdump\-rtl\-cse2\fR enable dumping after
+the two common subexpression elimination passes.
+.IP "\fB\-fdump\-rtl\-dce\fR" 4
+.IX Item "-fdump-rtl-dce"
+Dump after the standalone dead code elimination passes.
+.IP "\fB\-fdump\-rtl\-dbr\fR" 4
+.IX Item "-fdump-rtl-dbr"
+Dump after delayed branch scheduling.
+.IP "\fB\-fdump\-rtl\-dce1\fR" 4
+.IX Item "-fdump-rtl-dce1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-dce2\fR" 4
+.IX Item "-fdump-rtl-dce2"
+.PD
+\&\fB\-fdump\-rtl\-dce1\fR and \fB\-fdump\-rtl\-dce2\fR enable dumping after
+the two dead store elimination passes.
+.IP "\fB\-fdump\-rtl\-eh\fR" 4
+.IX Item "-fdump-rtl-eh"
+Dump after finalization of \s-1EH\s0 handling code.
+.IP "\fB\-fdump\-rtl\-eh_ranges\fR" 4
+.IX Item "-fdump-rtl-eh_ranges"
+Dump after conversion of \s-1EH\s0 handling range regions.
+.IP "\fB\-fdump\-rtl\-expand\fR" 4
+.IX Item "-fdump-rtl-expand"
+Dump after \s-1RTL\s0 generation.
+.IP "\fB\-fdump\-rtl\-fwprop1\fR" 4
+.IX Item "-fdump-rtl-fwprop1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-fwprop2\fR" 4
+.IX Item "-fdump-rtl-fwprop2"
+.PD
+\&\fB\-fdump\-rtl\-fwprop1\fR and \fB\-fdump\-rtl\-fwprop2\fR enable
+dumping after the two forward propagation passes.
+.IP "\fB\-fdump\-rtl\-gcse1\fR" 4
+.IX Item "-fdump-rtl-gcse1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-gcse2\fR" 4
+.IX Item "-fdump-rtl-gcse2"
+.PD
+\&\fB\-fdump\-rtl\-gcse1\fR and \fB\-fdump\-rtl\-gcse2\fR enable dumping
+after global common subexpression elimination.
+.IP "\fB\-fdump\-rtl\-init\-regs\fR" 4
+.IX Item "-fdump-rtl-init-regs"
+Dump after the initialization of the registers.
+.IP "\fB\-fdump\-rtl\-initvals\fR" 4
+.IX Item "-fdump-rtl-initvals"
+Dump after the computation of the initial value sets.
+.IP "\fB\-fdump\-rtl\-into_cfglayout\fR" 4
+.IX Item "-fdump-rtl-into_cfglayout"
+Dump after converting to cfglayout mode.
+.IP "\fB\-fdump\-rtl\-ira\fR" 4
+.IX Item "-fdump-rtl-ira"
+Dump after iterated register allocation.
+.IP "\fB\-fdump\-rtl\-jump\fR" 4
+.IX Item "-fdump-rtl-jump"
+Dump after the second jump optimization.
+.IP "\fB\-fdump\-rtl\-loop2\fR" 4
+.IX Item "-fdump-rtl-loop2"
+\&\fB\-fdump\-rtl\-loop2\fR enables dumping after the rtl
+loop optimization passes.
+.IP "\fB\-fdump\-rtl\-mach\fR" 4
+.IX Item "-fdump-rtl-mach"
+Dump after performing the machine dependent reorganization pass, if that
+pass exists.
+.IP "\fB\-fdump\-rtl\-mode_sw\fR" 4
+.IX Item "-fdump-rtl-mode_sw"
+Dump after removing redundant mode switches.
+.IP "\fB\-fdump\-rtl\-rnreg\fR" 4
+.IX Item "-fdump-rtl-rnreg"
+Dump after register renumbering.
+.IP "\fB\-fdump\-rtl\-outof_cfglayout\fR" 4
+.IX Item "-fdump-rtl-outof_cfglayout"
+Dump after converting from cfglayout mode.
+.IP "\fB\-fdump\-rtl\-peephole2\fR" 4
+.IX Item "-fdump-rtl-peephole2"
+Dump after the peephole pass.
+.IP "\fB\-fdump\-rtl\-postreload\fR" 4
+.IX Item "-fdump-rtl-postreload"
+Dump after post-reload optimizations.
+.IP "\fB\-fdump\-rtl\-pro_and_epilogue\fR" 4
+.IX Item "-fdump-rtl-pro_and_epilogue"
+Dump after generating the function prologues and epilogues.
+.IP "\fB\-fdump\-rtl\-sched1\fR" 4
+.IX Item "-fdump-rtl-sched1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-sched2\fR" 4
+.IX Item "-fdump-rtl-sched2"
+.PD
+\&\fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR enable dumping
+after the basic block scheduling passes.
+.IP "\fB\-fdump\-rtl\-ree\fR" 4
+.IX Item "-fdump-rtl-ree"
+Dump after sign/zero extension elimination.
+.IP "\fB\-fdump\-rtl\-seqabstr\fR" 4
+.IX Item "-fdump-rtl-seqabstr"
+Dump after common sequence discovery.
+.IP "\fB\-fdump\-rtl\-shorten\fR" 4
+.IX Item "-fdump-rtl-shorten"
+Dump after shortening branches.
+.IP "\fB\-fdump\-rtl\-sibling\fR" 4
+.IX Item "-fdump-rtl-sibling"
+Dump after sibling call optimizations.
+.IP "\fB\-fdump\-rtl\-split1\fR" 4
+.IX Item "-fdump-rtl-split1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-split2\fR" 4
+.IX Item "-fdump-rtl-split2"
+.IP "\fB\-fdump\-rtl\-split3\fR" 4
+.IX Item "-fdump-rtl-split3"
+.IP "\fB\-fdump\-rtl\-split4\fR" 4
+.IX Item "-fdump-rtl-split4"
+.IP "\fB\-fdump\-rtl\-split5\fR" 4
+.IX Item "-fdump-rtl-split5"
+.PD
+\&\fB\-fdump\-rtl\-split1\fR, \fB\-fdump\-rtl\-split2\fR,
+\&\fB\-fdump\-rtl\-split3\fR, \fB\-fdump\-rtl\-split4\fR and
+\&\fB\-fdump\-rtl\-split5\fR enable dumping after five rounds of
+instruction splitting.
+.IP "\fB\-fdump\-rtl\-sms\fR" 4
+.IX Item "-fdump-rtl-sms"
+Dump after modulo scheduling.  This pass is only run on some
+architectures.
+.IP "\fB\-fdump\-rtl\-stack\fR" 4
+.IX Item "-fdump-rtl-stack"
+Dump after conversion from \s-1GCC\s0's \*(L"flat register file\*(R" registers to the
+x87's stack-like registers.  This pass is only run on x86 variants.
+.IP "\fB\-fdump\-rtl\-subreg1\fR" 4
+.IX Item "-fdump-rtl-subreg1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-subreg2\fR" 4
+.IX Item "-fdump-rtl-subreg2"
+.PD
+\&\fB\-fdump\-rtl\-subreg1\fR and \fB\-fdump\-rtl\-subreg2\fR enable dumping after
+the two subreg expansion passes.
+.IP "\fB\-fdump\-rtl\-unshare\fR" 4
+.IX Item "-fdump-rtl-unshare"
+Dump after all rtl has been unshared.
+.IP "\fB\-fdump\-rtl\-vartrack\fR" 4
+.IX Item "-fdump-rtl-vartrack"
+Dump after variable tracking.
+.IP "\fB\-fdump\-rtl\-vregs\fR" 4
+.IX Item "-fdump-rtl-vregs"
+Dump after converting virtual registers to hard registers.
+.IP "\fB\-fdump\-rtl\-web\fR" 4
+.IX Item "-fdump-rtl-web"
+Dump after live range splitting.
+.IP "\fB\-fdump\-rtl\-regclass\fR" 4
+.IX Item "-fdump-rtl-regclass"
+.PD 0
+.IP "\fB\-fdump\-rtl\-subregs_of_mode_init\fR" 4
+.IX Item "-fdump-rtl-subregs_of_mode_init"
+.IP "\fB\-fdump\-rtl\-subregs_of_mode_finish\fR" 4
+.IX Item "-fdump-rtl-subregs_of_mode_finish"
+.IP "\fB\-fdump\-rtl\-dfinit\fR" 4
+.IX Item "-fdump-rtl-dfinit"
+.IP "\fB\-fdump\-rtl\-dfinish\fR" 4
+.IX Item "-fdump-rtl-dfinish"
+.PD
+These dumps are defined but always produce empty files.
+.IP "\fB\-da\fR" 4
+.IX Item "-da"
+.PD 0
+.IP "\fB\-fdump\-rtl\-all\fR" 4
+.IX Item "-fdump-rtl-all"
+.PD
+Produce all the dumps listed above.
+.IP "\fB\-dA\fR" 4
+.IX Item "-dA"
+Annotate the assembler output with miscellaneous debugging information.
+.IP "\fB\-dD\fR" 4
+.IX Item "-dD"
+Dump all macro definitions, at the end of preprocessing, in addition to
+normal output.
+.IP "\fB\-dH\fR" 4
+.IX Item "-dH"
+Produce a core dump whenever an error occurs.
+.IP "\fB\-dp\fR" 4
+.IX Item "-dp"
+Annotate the assembler output with a comment indicating which
+pattern and alternative is used.  The length of each instruction is
+also printed.
+.IP "\fB\-dP\fR" 4
+.IX Item "-dP"
+Dump the \s-1RTL\s0 in the assembler output as a comment before each instruction.
+Also turns on \fB\-dp\fR annotation.
+.IP "\fB\-dx\fR" 4
+.IX Item "-dx"
+Just generate \s-1RTL\s0 for a function instead of compiling it.  Usually used
+with \fB\-fdump\-rtl\-expand\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fdump\-noaddr\fR" 4
+.IX Item "-fdump-noaddr"
+When doing debugging dumps, suppress address output.  This makes it more
+feasible to use diff on debugging dumps for compiler invocations with
+different compiler binaries and/or different
+text / bss / data / heap / stack / dso start locations.
+.IP "\fB\-fdump\-unnumbered\fR" 4
+.IX Item "-fdump-unnumbered"
+When doing debugging dumps, suppress instruction numbers and address output.
+This makes it more feasible to use diff on debugging dumps for compiler
+invocations with different options, in particular with and without
+\&\fB\-g\fR.
+.IP "\fB\-fdump\-unnumbered\-links\fR" 4
+.IX Item "-fdump-unnumbered-links"
+When doing debugging dumps (see \fB\-d\fR option above), suppress
+instruction numbers for the links to the previous and next instructions
+in a sequence.
+.IP "\fB\-fdump\-translation\-unit\fR (\*(C+ only)" 4
+.IX Item "-fdump-translation-unit ( only)"
+.PD 0
+.IP "\fB\-fdump\-translation\-unit\-\fR\fIoptions\fR\fB \fR(\*(C+ only)" 4
+.IX Item "-fdump-translation-unit-options ( only)"
+.PD
+Dump a representation of the tree structure for the entire translation
+unit to a file.  The file name is made by appending \fI.tu\fR to the
+source file name, and the file is created in the same directory as the
+output file.  If the \fB\-\fR\fIoptions\fR form is used, \fIoptions\fR
+controls the details of the dump as described for the
+\&\fB\-fdump\-tree\fR options.
+.IP "\fB\-fdump\-class\-hierarchy\fR (\*(C+ only)" 4
+.IX Item "-fdump-class-hierarchy ( only)"
+.PD 0
+.IP "\fB\-fdump\-class\-hierarchy\-\fR\fIoptions\fR\fB \fR(\*(C+ only)" 4
+.IX Item "-fdump-class-hierarchy-options ( only)"
+.PD
+Dump a representation of each class's hierarchy and virtual function
+table layout to a file.  The file name is made by appending
+\&\fI.class\fR to the source file name, and the file is created in the
+same directory as the output file.  If the \fB\-\fR\fIoptions\fR form
+is used, \fIoptions\fR controls the details of the dump as described
+for the \fB\-fdump\-tree\fR options.
+.IP "\fB\-fdump\-ipa\-\fR\fIswitch\fR" 4
+.IX Item "-fdump-ipa-switch"
+Control the dumping at various stages of inter-procedural analysis
+language tree to a file.  The file name is generated by appending a
+switch specific suffix to the source file name, and the file is created
+in the same directory as the output file.  The following dumps are
+possible:
+.RS 4
+.IP "\fBall\fR" 4
+.IX Item "all"
+Enables all inter-procedural analysis dumps.
+.IP "\fBcgraph\fR" 4
+.IX Item "cgraph"
+Dumps information about call-graph optimization, unused function removal,
+and inlining decisions.
+.IP "\fBinline\fR" 4
+.IX Item "inline"
+Dump after function inlining.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fdump\-passes\fR" 4
+.IX Item "-fdump-passes"
+Dump the list of optimization passes that are turned on and off by
+the current command-line options.
+.IP "\fB\-fdump\-statistics\-\fR\fIoption\fR" 4
+.IX Item "-fdump-statistics-option"
+Enable and control dumping of pass statistics in a separate file.  The
+file name is generated by appending a suffix ending in
+\&\fB.statistics\fR to the source file name, and the file is created in
+the same directory as the output file.  If the \fB\-\fR\fIoption\fR
+form is used, \fB\-stats\fR causes counters to be summed over the
+whole compilation unit while \fB\-details\fR dumps every event as
+the passes generate them.  The default with no option is to sum
+counters for each function compiled.
+.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR" 4
+.IX Item "-fdump-tree-switch"
+.PD 0
+.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
+.IX Item "-fdump-tree-switch-options"
+.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
+.IX Item "-fdump-tree-switch-options=filename"
+.PD
+Control the dumping at various stages of processing the intermediate
+language tree to a file.  The file name is generated by appending a
+switch-specific suffix to the source file name, and the file is
+created in the same directory as the output file. In case of
+\&\fB=\fR\fIfilename\fR option, the dump is output on the given file
+instead of the auto named dump files.  If the \fB\-\fR\fIoptions\fR
+form is used, \fIoptions\fR is a list of \fB\-\fR separated options
+which control the details of the dump.  Not all options are applicable
+to all dumps; those that are not meaningful are ignored.  The
+following options are available
+.RS 4
+.IP "\fBaddress\fR" 4
+.IX Item "address"
+Print the address of each node.  Usually this is not meaningful as it
+changes according to the environment and source file.  Its primary use
+is for tying up a dump file with a debug environment.
+.IP "\fBasmname\fR" 4
+.IX Item "asmname"
+If \f(CW\*(C`DECL_ASSEMBLER_NAME\*(C'\fR has been set for a given decl, use that
+in the dump instead of \f(CW\*(C`DECL_NAME\*(C'\fR.  Its primary use is ease of
+use working backward from mangled names in the assembly file.
+.IP "\fBslim\fR" 4
+.IX Item "slim"
+When dumping front-end intermediate representations, inhibit dumping
+of members of a scope or body of a function merely because that scope
+has been reached.  Only dump such items when they are directly reachable
+by some other path.
+.Sp
+When dumping pretty-printed trees, this option inhibits dumping the
+bodies of control structures.
+.Sp
+When dumping \s-1RTL,\s0 print the \s-1RTL\s0 in slim (condensed) form instead of
+the default LISP-like representation.
+.IP "\fBraw\fR" 4
+.IX Item "raw"
+Print a raw representation of the tree.  By default, trees are
+pretty-printed into a C\-like representation.
+.IP "\fBdetails\fR" 4
+.IX Item "details"
+Enable more detailed dumps (not honored by every dump option). Also
+include information from the optimization passes.
+.IP "\fBstats\fR" 4
+.IX Item "stats"
+Enable dumping various statistics about the pass (not honored by every dump
+option).
+.IP "\fBblocks\fR" 4
+.IX Item "blocks"
+Enable showing basic block boundaries (disabled in raw dumps).
+.IP "\fBgraph\fR" 4
+.IX Item "graph"
+For each of the other indicated dump files (\fB\-fdump\-rtl\-\fR\fIpass\fR),
+dump a representation of the control flow graph suitable for viewing with
+GraphViz to \fI\fIfile\fI.\fIpassid\fI.\fIpass\fI.dot\fR.  Each function in
+the file is pretty-printed as a subgraph, so that GraphViz can render them
+all in a single plot.
+.Sp
+This option currently only works for \s-1RTL\s0 dumps, and the \s-1RTL\s0 is always
+dumped in slim form.
+.IP "\fBvops\fR" 4
+.IX Item "vops"
+Enable showing virtual operands for every statement.
+.IP "\fBlineno\fR" 4
+.IX Item "lineno"
+Enable showing line numbers for statements.
+.IP "\fBuid\fR" 4
+.IX Item "uid"
+Enable showing the unique \s-1ID \s0(\f(CW\*(C`DECL_UID\*(C'\fR) for each variable.
+.IP "\fBverbose\fR" 4
+.IX Item "verbose"
+Enable showing the tree dump for each statement.
+.IP "\fBeh\fR" 4
+.IX Item "eh"
+Enable showing the \s-1EH\s0 region number holding each statement.
+.IP "\fBscev\fR" 4
+.IX Item "scev"
+Enable showing scalar evolution analysis details.
+.IP "\fBoptimized\fR" 4
+.IX Item "optimized"
+Enable showing optimization information (only available in certain
+passes).
+.IP "\fBmissed\fR" 4
+.IX Item "missed"
+Enable showing missed optimization information (only available in certain
+passes).
+.IP "\fBnotes\fR" 4
+.IX Item "notes"
+Enable other detailed optimization information (only available in
+certain passes).
+.IP "\fB=\fR\fIfilename\fR" 4
+.IX Item "=filename"
+Instead of an auto named dump file, output into the given file
+name. The file names \fIstdout\fR and \fIstderr\fR are treated
+specially and are considered already open standard streams. For
+example,
+.Sp
+.Vb 2
+\&        gcc \-O2 \-ftree\-vectorize \-fdump\-tree\-vect\-blocks=foo.dump
+\&             \-fdump\-tree\-pre=stderr file.c
+.Ve
+.Sp
+outputs vectorizer dump into \fIfoo.dump\fR, while the \s-1PRE\s0 dump is
+output on to \fIstderr\fR. If two conflicting dump filenames are
+given for the same pass, then the latter option overrides the earlier
+one.
+.IP "\fBall\fR" 4
+.IX Item "all"
+Turn on all options, except \fBraw\fR, \fBslim\fR, \fBverbose\fR
+and \fBlineno\fR.
+.IP "\fBoptall\fR" 4
+.IX Item "optall"
+Turn on all optimization options, i.e., \fBoptimized\fR,
+\&\fBmissed\fR, and \fBnote\fR.
+.RE
+.RS 4
+.Sp
+The following tree dumps are possible:
+.IP "\fBoriginal\fR" 4
+.IX Item "original"
+Dump before any tree based optimization, to \fI\fIfile\fI.original\fR.
+.IP "\fBoptimized\fR" 4
+.IX Item "optimized"
+Dump after all tree based optimization, to \fI\fIfile\fI.optimized\fR.
+.IP "\fBgimple\fR" 4
+.IX Item "gimple"
+Dump each function before and after the gimplification pass to a file.  The
+file name is made by appending \fI.gimple\fR to the source file name.
+.IP "\fBcfg\fR" 4
+.IX Item "cfg"
+Dump the control flow graph of each function to a file.  The file name is
+made by appending \fI.cfg\fR to the source file name.
+.IP "\fBch\fR" 4
+.IX Item "ch"
+Dump each function after copying loop headers.  The file name is made by
+appending \fI.ch\fR to the source file name.
+.IP "\fBssa\fR" 4
+.IX Item "ssa"
+Dump \s-1SSA\s0 related information to a file.  The file name is made by appending
+\&\fI.ssa\fR to the source file name.
+.IP "\fBalias\fR" 4
+.IX Item "alias"
+Dump aliasing information for each function.  The file name is made by
+appending \fI.alias\fR to the source file name.
+.IP "\fBccp\fR" 4
+.IX Item "ccp"
+Dump each function after \s-1CCP. \s0 The file name is made by appending
+\&\fI.ccp\fR to the source file name.
+.IP "\fBstoreccp\fR" 4
+.IX Item "storeccp"
+Dump each function after STORE-CCP.  The file name is made by appending
+\&\fI.storeccp\fR to the source file name.
+.IP "\fBpre\fR" 4
+.IX Item "pre"
+Dump trees after partial redundancy elimination.  The file name is made
+by appending \fI.pre\fR to the source file name.
+.IP "\fBfre\fR" 4
+.IX Item "fre"
+Dump trees after full redundancy elimination.  The file name is made
+by appending \fI.fre\fR to the source file name.
+.IP "\fBcopyprop\fR" 4
+.IX Item "copyprop"
+Dump trees after copy propagation.  The file name is made
+by appending \fI.copyprop\fR to the source file name.
+.IP "\fBstore_copyprop\fR" 4
+.IX Item "store_copyprop"
+Dump trees after store copy-propagation.  The file name is made
+by appending \fI.store_copyprop\fR to the source file name.
+.IP "\fBdce\fR" 4
+.IX Item "dce"
+Dump each function after dead code elimination.  The file name is made by
+appending \fI.dce\fR to the source file name.
+.IP "\fBsra\fR" 4
+.IX Item "sra"
+Dump each function after performing scalar replacement of aggregates.  The
+file name is made by appending \fI.sra\fR to the source file name.
+.IP "\fBsink\fR" 4
+.IX Item "sink"
+Dump each function after performing code sinking.  The file name is made
+by appending \fI.sink\fR to the source file name.
+.IP "\fBdom\fR" 4
+.IX Item "dom"
+Dump each function after applying dominator tree optimizations.  The file
+name is made by appending \fI.dom\fR to the source file name.
+.IP "\fBdse\fR" 4
+.IX Item "dse"
+Dump each function after applying dead store elimination.  The file
+name is made by appending \fI.dse\fR to the source file name.
+.IP "\fBphiopt\fR" 4
+.IX Item "phiopt"
+Dump each function after optimizing \s-1PHI\s0 nodes into straightline code.  The file
+name is made by appending \fI.phiopt\fR to the source file name.
+.IP "\fBforwprop\fR" 4
+.IX Item "forwprop"
+Dump each function after forward propagating single use variables.  The file
+name is made by appending \fI.forwprop\fR to the source file name.
+.IP "\fBcopyrename\fR" 4
+.IX Item "copyrename"
+Dump each function after applying the copy rename optimization.  The file
+name is made by appending \fI.copyrename\fR to the source file name.
+.IP "\fBnrv\fR" 4
+.IX Item "nrv"
+Dump each function after applying the named return value optimization on
+generic trees.  The file name is made by appending \fI.nrv\fR to the source
+file name.
+.IP "\fBvect\fR" 4
+.IX Item "vect"
+Dump each function after applying vectorization of loops.  The file name is
+made by appending \fI.vect\fR to the source file name.
+.IP "\fBslp\fR" 4
+.IX Item "slp"
+Dump each function after applying vectorization of basic blocks.  The file name
+is made by appending \fI.slp\fR to the source file name.
+.IP "\fBvrp\fR" 4
+.IX Item "vrp"
+Dump each function after Value Range Propagation (\s-1VRP\s0).  The file name
+is made by appending \fI.vrp\fR to the source file name.
+.IP "\fBall\fR" 4
+.IX Item "all"
+Enable all the available tree dumps with the flags provided in this option.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fopt\-info\fR" 4
+.IX Item "-fopt-info"
+.PD 0
+.IP "\fB\-fopt\-info\-\fR\fIoptions\fR" 4
+.IX Item "-fopt-info-options"
+.IP "\fB\-fopt\-info\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
+.IX Item "-fopt-info-options=filename"
+.PD
+Controls optimization dumps from various optimization passes. If the
+\&\fB\-\fR\fIoptions\fR form is used, \fIoptions\fR is a list of
+\&\fB\-\fR separated options to select the dump details and
+optimizations.  If \fIoptions\fR is not specified, it defaults to
+\&\fBoptimized\fR for details and \fBoptall\fR for optimization
+groups. If the \fIfilename\fR is not specified, it defaults to
+\&\fIstderr\fR. Note that the output \fIfilename\fR will be overwritten
+in case of multiple translation units. If a combined output from
+multiple translation units is desired, \fIstderr\fR should be used
+instead.
+.Sp
+The options can be divided into two groups, 1) options describing the
+verbosity of the dump, and 2) options describing which optimizations
+should be included. The options from both the groups can be freely
+mixed as they are non-overlapping. However, in case of any conflicts,
+the latter options override the earlier options on the command
+line. Though multiple \-fopt\-info options are accepted, only one of
+them can have \fB=filename\fR. If other filenames are provided then
+all but the first one are ignored.
+.Sp
+The dump verbosity has the following options
+.RS 4
+.IP "\fBoptimized\fR" 4
+.IX Item "optimized"
+Print information when an optimization is successfully applied. It is
+up to a pass to decide which information is relevant. For example, the
+vectorizer passes print the source location of loops which got
+successfully vectorized.
+.IP "\fBmissed\fR" 4
+.IX Item "missed"
+Print information about missed optimizations. Individual passes
+control which information to include in the output. For example,
+.Sp
+.Vb 1
+\&        gcc \-O2 \-ftree\-vectorize \-fopt\-info\-vec\-missed
+.Ve
+.Sp
+will print information about missed optimization opportunities from
+vectorization passes on stderr.
+.IP "\fBnote\fR" 4
+.IX Item "note"
+Print verbose information about optimizations, such as certain
+transformations, more detailed messages about decisions etc.
+.IP "\fBall\fR" 4
+.IX Item "all"
+Print detailed optimization information. This includes
+\&\fIoptimized\fR, \fImissed\fR, and \fInote\fR.
+.RE
+.RS 4
+.Sp
+The second set of options describes a group of optimizations and may
+include one or more of the following.
+.IP "\fBipa\fR" 4
+.IX Item "ipa"
+Enable dumps from all interprocedural optimizations.
+.IP "\fBloop\fR" 4
+.IX Item "loop"
+Enable dumps from all loop optimizations.
+.IP "\fBinline\fR" 4
+.IX Item "inline"
+Enable dumps from all inlining optimizations.
+.IP "\fBvec\fR" 4
+.IX Item "vec"
+Enable dumps from all vectorization optimizations.
+.IP "\fBoptall\fR" 4
+.IX Item "optall"
+Enable dumps from all optimizations. This is a superset of
+the optimization groups listed above.
+.RE
+.RS 4
+.Sp
+For example,
+.Sp
+.Vb 1
+\&        gcc \-O3 \-fopt\-info\-missed=missed.all
+.Ve
+.Sp
+outputs missed optimization report from all the passes into
+\&\fImissed.all\fR.
+.Sp
+As another example,
+.Sp
+.Vb 1
+\&        gcc \-O3 \-fopt\-info\-inline\-optimized\-missed=inline.txt
+.Ve
+.Sp
+will output information about missed optimizations as well as
+optimized locations from all the inlining passes into
+\&\fIinline.txt\fR.
+.Sp
+If the \fIfilename\fR is provided, then the dumps from all the
+applicable optimizations are concatenated into the \fIfilename\fR.
+Otherwise the dump is output onto \fIstderr\fR. If \fIoptions\fR is
+omitted, it defaults to \fBall-optall\fR, which means dump all
+available optimization info from all the passes. In the following
+example, all optimization info is output on to \fIstderr\fR.
+.Sp
+.Vb 1
+\&        gcc \-O3 \-fopt\-info
+.Ve
+.Sp
+Note that \fB\-fopt\-info\-vec\-missed\fR behaves the same as
+\&\fB\-fopt\-info\-missed\-vec\fR.
+.Sp
+As another example, consider
+.Sp
+.Vb 1
+\&        gcc \-fopt\-info\-vec\-missed=vec.miss \-fopt\-info\-loop\-optimized=loop.opt
+.Ve
+.Sp
+Here the two output filenames \fIvec.miss\fR and \fIloop.opt\fR are
+in conflict since only one output file is allowed. In this case, only
+the first option takes effect and the subsequent options are
+ignored. Thus only the \fIvec.miss\fR is produced which contains
+dumps from the vectorizer about missed opportunities.
+.RE
+.IP "\fB\-frandom\-seed=\fR\fIstring\fR" 4
+.IX Item "-frandom-seed=string"
+This option provides a seed that \s-1GCC\s0 uses in place of
+random numbers in generating certain symbol names
+that have to be different in every compiled file.  It is also used to
+place unique stamps in coverage data files and the object files that
+produce them.  You can use the \fB\-frandom\-seed\fR option to produce
+reproducibly identical object files.
+.Sp
+The \fIstring\fR should be different for every file you compile.
+.IP "\fB\-fsched\-verbose=\fR\fIn\fR" 4
+.IX Item "-fsched-verbose=n"
+On targets that use instruction scheduling, this option controls the
+amount of debugging output the scheduler prints.  This information is
+written to standard error, unless \fB\-fdump\-rtl\-sched1\fR or
+\&\fB\-fdump\-rtl\-sched2\fR is specified, in which case it is output
+to the usual dump listing file, \fI.sched1\fR or \fI.sched2\fR
+respectively.  However for \fIn\fR greater than nine, the output is
+always printed to standard error.
+.Sp
+For \fIn\fR greater than zero, \fB\-fsched\-verbose\fR outputs the
+same information as \fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR.
+For \fIn\fR greater than one, it also output basic block probabilities,
+detailed ready list information and unit/insn info.  For \fIn\fR greater
+than two, it includes \s-1RTL\s0 at abort point, control-flow and regions info.
+And for \fIn\fR over four, \fB\-fsched\-verbose\fR also includes
+dependence info.
+.IP "\fB\-save\-temps\fR" 4
+.IX Item "-save-temps"
+.PD 0
+.IP "\fB\-save\-temps=cwd\fR" 4
+.IX Item "-save-temps=cwd"
+.PD
+Store the usual \*(L"temporary\*(R" intermediate files permanently; place them
+in the current directory and name them based on the source file.  Thus,
+compiling \fIfoo.c\fR with \fB\-c \-save\-temps\fR produces files
+\&\fIfoo.i\fR and \fIfoo.s\fR, as well as \fIfoo.o\fR.  This creates a
+preprocessed \fIfoo.i\fR output file even though the compiler now
+normally uses an integrated preprocessor.
+.Sp
+When used in combination with the \fB\-x\fR command-line option,
+\&\fB\-save\-temps\fR is sensible enough to avoid over writing an
+input source file with the same extension as an intermediate file.
+The corresponding intermediate file may be obtained by renaming the
+source file before using \fB\-save\-temps\fR.
+.Sp
+If you invoke \s-1GCC\s0 in parallel, compiling several different source
+files that share a common base name in different subdirectories or the
+same source file compiled for multiple output destinations, it is
+likely that the different parallel compilers will interfere with each
+other, and overwrite the temporary files.  For instance:
+.Sp
+.Vb 2
+\&        gcc \-save\-temps \-o outdir1/foo.o indir1/foo.c&
+\&        gcc \-save\-temps \-o outdir2/foo.o indir2/foo.c&
+.Ve
+.Sp
+may result in \fIfoo.i\fR and \fIfoo.o\fR being written to
+simultaneously by both compilers.
+.IP "\fB\-save\-temps=obj\fR" 4
+.IX Item "-save-temps=obj"
+Store the usual \*(L"temporary\*(R" intermediate files permanently.  If the
+\&\fB\-o\fR option is used, the temporary files are based on the
+object file.  If the \fB\-o\fR option is not used, the
+\&\fB\-save\-temps=obj\fR switch behaves like \fB\-save\-temps\fR.
+.Sp
+For example:
+.Sp
+.Vb 3
+\&        gcc \-save\-temps=obj \-c foo.c
+\&        gcc \-save\-temps=obj \-c bar.c \-o dir/xbar.o
+\&        gcc \-save\-temps=obj foobar.c \-o dir2/yfoobar
+.Ve
+.Sp
+creates \fIfoo.i\fR, \fIfoo.s\fR, \fIdir/xbar.i\fR,
+\&\fIdir/xbar.s\fR, \fIdir2/yfoobar.i\fR, \fIdir2/yfoobar.s\fR, and
+\&\fIdir2/yfoobar.o\fR.
+.IP "\fB\-time\fR[\fB=\fR\fIfile\fR]" 4
+.IX Item "-time[=file]"
+Report the \s-1CPU\s0 time taken by each subprocess in the compilation
+sequence.  For C source files, this is the compiler proper and assembler
+(plus the linker if linking is done).
+.Sp
+Without the specification of an output file, the output looks like this:
+.Sp
+.Vb 2
+\&        # cc1 0.12 0.01
+\&        # as 0.00 0.01
+.Ve
+.Sp
+The first number on each line is the \*(L"user time\*(R", that is time spent
+executing the program itself.  The second number is \*(L"system time\*(R",
+time spent executing operating system routines on behalf of the program.
+Both numbers are in seconds.
+.Sp
+With the specification of an output file, the output is appended to the
+named file, and it looks like this:
+.Sp
+.Vb 2
+\&        0.12 0.01 cc1 <options>
+\&        0.00 0.01 as <options>
+.Ve
+.Sp
+The \*(L"user time\*(R" and the \*(L"system time\*(R" are moved before the program
+name, and the options passed to the program are displayed, so that one
+can later tell what file was being compiled, and with which options.
+.IP "\fB\-fvar\-tracking\fR" 4
+.IX Item "-fvar-tracking"
+Run variable tracking pass.  It computes where variables are stored at each
+position in code.  Better debugging information is then generated
+(if the debugging information format supports this information).
+.Sp
+It is enabled by default when compiling with optimization (\fB\-Os\fR,
+\&\fB\-O\fR, \fB\-O2\fR, ...), debugging information (\fB\-g\fR) and
+the debug info format supports it.
+.IP "\fB\-fvar\-tracking\-assignments\fR" 4
+.IX Item "-fvar-tracking-assignments"
+Annotate assignments to user variables early in the compilation and
+attempt to carry the annotations over throughout the compilation all the
+way to the end, in an attempt to improve debug information while
+optimizing.  Use of \fB\-gdwarf\-4\fR is recommended along with it.
+.Sp
+It can be enabled even if var-tracking is disabled, in which case
+annotations are created and maintained, but discarded at the end.
+.IP "\fB\-fvar\-tracking\-assignments\-toggle\fR" 4
+.IX Item "-fvar-tracking-assignments-toggle"
+Toggle \fB\-fvar\-tracking\-assignments\fR, in the same way that
+\&\fB\-gtoggle\fR toggles \fB\-g\fR.
+.IP "\fB\-print\-file\-name=\fR\fIlibrary\fR" 4
+.IX Item "-print-file-name=library"
+Print the full absolute name of the library file \fIlibrary\fR that
+would be used when linking\-\-\-and don't do anything else.  With this
+option, \s-1GCC\s0 does not compile or link anything; it just prints the
+file name.
+.IP "\fB\-print\-multi\-directory\fR" 4
+.IX Item "-print-multi-directory"
+Print the directory name corresponding to the multilib selected by any
+other switches present in the command line.  This directory is supposed
+to exist in \fB\s-1GCC_EXEC_PREFIX\s0\fR.
+.IP "\fB\-print\-multi\-lib\fR" 4
+.IX Item "-print-multi-lib"
+Print the mapping from multilib directory names to compiler switches
+that enable them.  The directory name is separated from the switches by
+\&\fB;\fR, and each switch starts with an \fB@\fR instead of the
+\&\fB\-\fR, without spaces between multiple switches.  This is supposed to
+ease shell processing.
+.IP "\fB\-print\-multi\-os\-directory\fR" 4
+.IX Item "-print-multi-os-directory"
+Print the path to \s-1OS\s0 libraries for the selected
+multilib, relative to some \fIlib\fR subdirectory.  If \s-1OS\s0 libraries are
+present in the \fIlib\fR subdirectory and no multilibs are used, this is
+usually just \fI.\fR, if \s-1OS\s0 libraries are present in \fIlib\fIsuffix\fI\fR
+sibling directories this prints e.g. \fI../lib64\fR, \fI../lib\fR or
+\&\fI../lib32\fR, or if \s-1OS\s0 libraries are present in \fIlib/\fIsubdir\fI\fR
+subdirectories it prints e.g. \fIamd64\fR, \fIsparcv9\fR or \fIev6\fR.
+.IP "\fB\-print\-multiarch\fR" 4
+.IX Item "-print-multiarch"
+Print the path to \s-1OS\s0 libraries for the selected multiarch,
+relative to some \fIlib\fR subdirectory.
+.IP "\fB\-print\-prog\-name=\fR\fIprogram\fR" 4
+.IX Item "-print-prog-name=program"
+Like \fB\-print\-file\-name\fR, but searches for a program such as \fBcpp\fR.
+.IP "\fB\-print\-libgcc\-file\-name\fR" 4
+.IX Item "-print-libgcc-file-name"
+Same as \fB\-print\-file\-name=libgcc.a\fR.
+.Sp
+This is useful when you use \fB\-nostdlib\fR or \fB\-nodefaultlibs\fR
+but you do want to link with \fIlibgcc.a\fR.  You can do:
+.Sp
+.Vb 1
+\&        gcc \-nostdlib <files>... \`gcc \-print\-libgcc\-file\-name\`
+.Ve
+.IP "\fB\-print\-search\-dirs\fR" 4
+.IX Item "-print-search-dirs"
+Print the name of the configured installation directory and a list of
+program and library directories \fBgcc\fR searches\-\-\-and don't do anything else.
+.Sp
+This is useful when \fBgcc\fR prints the error message
+\&\fBinstallation problem, cannot exec cpp0: No such file or directory\fR.
+To resolve this you either need to put \fIcpp0\fR and the other compiler
+components where \fBgcc\fR expects to find them, or you can set the environment
+variable \fB\s-1GCC_EXEC_PREFIX\s0\fR to the directory where you installed them.
+Don't forget the trailing \fB/\fR.
+.IP "\fB\-print\-sysroot\fR" 4
+.IX Item "-print-sysroot"
+Print the target sysroot directory that is used during
+compilation.  This is the target sysroot specified either at configure
+time or using the \fB\-\-sysroot\fR option, possibly with an extra
+suffix that depends on compilation options.  If no target sysroot is
+specified, the option prints nothing.
+.IP "\fB\-print\-sysroot\-headers\-suffix\fR" 4
+.IX Item "-print-sysroot-headers-suffix"
+Print the suffix added to the target sysroot when searching for
+headers, or give an error if the compiler is not configured with such
+a suffix\-\-\-and don't do anything else.
+.IP "\fB\-dumpmachine\fR" 4
+.IX Item "-dumpmachine"
+Print the compiler's target machine (for example,
+\&\fBi686\-pc\-linux\-gnu\fR)\-\-\-and don't do anything else.
+.IP "\fB\-dumpversion\fR" 4
+.IX Item "-dumpversion"
+Print the compiler version (for example, \fB3.0\fR)\-\-\-and don't do
+anything else.
+.IP "\fB\-dumpspecs\fR" 4
+.IX Item "-dumpspecs"
+Print the compiler's built-in specs\-\-\-and don't do anything else.  (This
+is used when \s-1GCC\s0 itself is being built.)
+.IP "\fB\-fno\-eliminate\-unused\-debug\-types\fR" 4
+.IX Item "-fno-eliminate-unused-debug-types"
+Normally, when producing \s-1DWARF 2\s0 output, \s-1GCC\s0 avoids producing debug symbol 
+output for types that are nowhere used in the source file being compiled.
+Sometimes it is useful to have \s-1GCC\s0 emit debugging
+information for all types declared in a compilation
+unit, regardless of whether or not they are actually used
+in that compilation unit, for example 
+if, in the debugger, you want to cast a value to a type that is
+not actually used in your program (but is declared).  More often,
+however, this results in a significant amount of wasted space.
+.SS "Options That Control Optimization"
+.IX Subsection "Options That Control Optimization"
+These options control various sorts of optimizations.
+.PP
+Without any optimization option, the compiler's goal is to reduce the
+cost of compilation and to make debugging produce the expected
+results.  Statements are independent: if you stop the program with a
+breakpoint between statements, you can then assign a new value to any
+variable or change the program counter to any other statement in the
+function and get exactly the results you expect from the source
+code.
+.PP
+Turning on optimization flags makes the compiler attempt to improve
+the performance and/or code size at the expense of compilation time
+and possibly the ability to debug the program.
+.PP
+The compiler performs optimization based on the knowledge it has of the
+program.  Compiling multiple files at once to a single output file mode allows
+the compiler to use information gained from all of the files when compiling
+each of them.
+.PP
+Not all optimizations are controlled directly by a flag.  Only
+optimizations that have a flag are listed in this section.
+.PP
+Most optimizations are only enabled if an \fB\-O\fR level is set on
+the command line.  Otherwise they are disabled, even if individual
+optimization flags are specified.
+.PP
+Depending on the target and how \s-1GCC\s0 was configured, a slightly different
+set of optimizations may be enabled at each \fB\-O\fR level than
+those listed here.  You can invoke \s-1GCC\s0 with \fB\-Q \-\-help=optimizers\fR
+to find out the exact set of optimizations that are enabled at each level.
+.IP "\fB\-O\fR" 4
+.IX Item "-O"
+.PD 0
+.IP "\fB\-O1\fR" 4
+.IX Item "-O1"
+.PD
+Optimize.  Optimizing compilation takes somewhat more time, and a lot
+more memory for a large function.
+.Sp
+With \fB\-O\fR, the compiler tries to reduce code size and execution
+time, without performing any optimizations that take a great deal of
+compilation time.
+.Sp
+\&\fB\-O\fR turns on the following optimization flags:
+.Sp
+\&\fB\-fauto\-inc\-dec 
+\&\-fcompare\-elim 
+\&\-fcprop\-registers 
+\&\-fdce 
+\&\-fdefer\-pop 
+\&\-fdelayed\-branch 
+\&\-fdse 
+\&\-fguess\-branch\-probability 
+\&\-fif\-conversion2 
+\&\-fif\-conversion 
+\&\-fipa\-pure\-const 
+\&\-fipa\-profile 
+\&\-fipa\-reference 
+\&\-fmerge\-constants
+\&\-fsplit\-wide\-types 
+\&\-ftree\-bit\-ccp 
+\&\-ftree\-builtin\-call\-dce 
+\&\-ftree\-ccp 
+\&\-ftree\-ch 
+\&\-ftree\-copyrename 
+\&\-ftree\-dce 
+\&\-ftree\-dominator\-opts 
+\&\-ftree\-dse 
+\&\-ftree\-forwprop 
+\&\-ftree\-fre 
+\&\-ftree\-phiprop 
+\&\-ftree\-slsr 
+\&\-ftree\-sra 
+\&\-ftree\-pta 
+\&\-ftree\-ter 
+\&\-funit\-at\-a\-time\fR
+.Sp
+\&\fB\-O\fR also turns on \fB\-fomit\-frame\-pointer\fR on machines
+where doing so does not interfere with debugging.
+.IP "\fB\-O2\fR" 4
+.IX Item "-O2"
+Optimize even more.  \s-1GCC\s0 performs nearly all supported optimizations
+that do not involve a space-speed tradeoff.
+As compared to \fB\-O\fR, this option increases both compilation time
+and the performance of the generated code.
+.Sp
+\&\fB\-O2\fR turns on all optimization flags specified by \fB\-O\fR.  It
+also turns on the following optimization flags:
+\&\fB\-fthread\-jumps 
+\&\-falign\-functions  \-falign\-jumps 
+\&\-falign\-loops  \-falign\-labels 
+\&\-fcaller\-saves 
+\&\-fcrossjumping 
+\&\-fcse\-follow\-jumps  \-fcse\-skip\-blocks 
+\&\-fdelete\-null\-pointer\-checks 
+\&\-fdevirtualize \-fdevirtualize\-speculatively 
+\&\-fexpensive\-optimizations 
+\&\-fgcse  \-fgcse\-lm  
+\&\-fhoist\-adjacent\-loads 
+\&\-finline\-small\-functions 
+\&\-findirect\-inlining 
+\&\-fipa\-sra 
+\&\-fisolate\-erroneous\-paths\-dereference 
+\&\-foptimize\-sibling\-calls 
+\&\-fpartial\-inlining 
+\&\-fpeephole2 
+\&\-freorder\-blocks  \-freorder\-functions 
+\&\-frerun\-cse\-after\-loop  
+\&\-fsched\-interblock  \-fsched\-spec 
+\&\-fschedule\-insns  \-fschedule\-insns2 
+\&\-fstrict\-aliasing \-fstrict\-overflow 
+\&\-ftree\-switch\-conversion \-ftree\-tail\-merge 
+\&\-ftree\-pre 
+\&\-ftree\-vrp\fR
+.Sp
+Please note the warning under \fB\-fgcse\fR about
+invoking \fB\-O2\fR on programs that use computed gotos.
+.IP "\fB\-O3\fR" 4
+.IX Item "-O3"
+Optimize yet more.  \fB\-O3\fR turns on all optimizations specified
+by \fB\-O2\fR and also turns on the \fB\-finline\-functions\fR,
+\&\fB\-funswitch\-loops\fR, \fB\-fpredictive\-commoning\fR,
+\&\fB\-fgcse\-after\-reload\fR, \fB\-ftree\-loop\-vectorize\fR,
+\&\fB\-ftree\-slp\-vectorize\fR, \fB\-fvect\-cost\-model\fR,
+\&\fB\-ftree\-partial\-pre\fR and \fB\-fipa\-cp\-clone\fR options.
+.IP "\fB\-O0\fR" 4
+.IX Item "-O0"
+Reduce compilation time and make debugging produce the expected
+results.  This is the default.
+.IP "\fB\-Os\fR" 4
+.IX Item "-Os"
+Optimize for size.  \fB\-Os\fR enables all \fB\-O2\fR optimizations that
+do not typically increase code size.  It also performs further
+optimizations designed to reduce code size.
+.Sp
+\&\fB\-Os\fR disables the following optimization flags:
+\&\fB\-falign\-functions  \-falign\-jumps  \-falign\-loops 
+\&\-falign\-labels  \-freorder\-blocks  \-freorder\-blocks\-and\-partition 
+\&\-fprefetch\-loop\-arrays\fR
+.IP "\fB\-Ofast\fR" 4
+.IX Item "-Ofast"
+Disregard strict standards compliance.  \fB\-Ofast\fR enables all
+\&\fB\-O3\fR optimizations.  It also enables optimizations that are not
+valid for all standard-compliant programs.
+It turns on \fB\-ffast\-math\fR and the Fortran-specific
+\&\fB\-fno\-protect\-parens\fR and \fB\-fstack\-arrays\fR.
+.IP "\fB\-Og\fR" 4
+.IX Item "-Og"
+Optimize debugging experience.  \fB\-Og\fR enables optimizations
+that do not interfere with debugging. It should be the optimization
+level of choice for the standard edit-compile-debug cycle, offering
+a reasonable level of optimization while maintaining fast compilation
+and a good debugging experience.
+.Sp
+If you use multiple \fB\-O\fR options, with or without level numbers,
+the last such option is the one that is effective.
+.PP
+Options of the form \fB\-f\fR\fIflag\fR specify machine-independent
+flags.  Most flags have both positive and negative forms; the negative
+form of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In the table
+below, only one of the forms is listed\-\-\-the one you typically 
+use.  You can figure out the other form by either removing \fBno\-\fR
+or adding it.
+.PP
+The following options control specific optimizations.  They are either
+activated by \fB\-O\fR options or are related to ones that are.  You
+can use the following flags in the rare cases when \*(L"fine-tuning\*(R" of
+optimizations to be performed is desired.
+.IP "\fB\-fno\-defer\-pop\fR" 4
+.IX Item "-fno-defer-pop"
+Always pop the arguments to each function call as soon as that function
+returns.  For machines that must pop arguments after a function call,
+the compiler normally lets arguments accumulate on the stack for several
+function calls and pops them all at once.
+.Sp
+Disabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fforward\-propagate\fR" 4
+.IX Item "-fforward-propagate"
+Perform a forward propagation pass on \s-1RTL. \s0 The pass tries to combine two
+instructions and checks if the result can be simplified.  If loop unrolling
+is active, two passes are performed and the second is scheduled after
+loop unrolling.
+.Sp
+This option is enabled by default at optimization levels \fB\-O\fR,
+\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-ffp\-contract=\fR\fIstyle\fR" 4
+.IX Item "-ffp-contract=style"
+\&\fB\-ffp\-contract=off\fR disables floating-point expression contraction.
+\&\fB\-ffp\-contract=fast\fR enables floating-point expression contraction
+such as forming of fused multiply-add operations if the target has
+native support for them.
+\&\fB\-ffp\-contract=on\fR enables floating-point expression contraction
+if allowed by the language standard.  This is currently not implemented
+and treated equal to \fB\-ffp\-contract=off\fR.
+.Sp
+The default is \fB\-ffp\-contract=fast\fR.
+.IP "\fB\-fomit\-frame\-pointer\fR" 4
+.IX Item "-fomit-frame-pointer"
+Don't keep the frame pointer in a register for functions that
+don't need one.  This avoids the instructions to save, set up and
+restore frame pointers; it also makes an extra register available
+in many functions.  \fBIt also makes debugging impossible on
+some machines.\fR
+.Sp
+On some machines, such as the \s-1VAX,\s0 this flag has no effect, because
+the standard calling sequence automatically handles the frame pointer
+and nothing is saved by pretending it doesn't exist.  The
+machine-description macro \f(CW\*(C`FRAME_POINTER_REQUIRED\*(C'\fR controls
+whether a target machine supports this flag.
+.Sp
+Starting with \s-1GCC\s0 version 4.6, the default setting (when not optimizing for
+size) for 32\-bit GNU/Linux x86 and 32\-bit Darwin x86 targets has been changed to
+\&\fB\-fomit\-frame\-pointer\fR.  The default can be reverted to
+\&\fB\-fno\-omit\-frame\-pointer\fR by configuring \s-1GCC\s0 with the
+\&\fB\-\-enable\-frame\-pointer\fR configure option.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-foptimize\-sibling\-calls\fR" 4
+.IX Item "-foptimize-sibling-calls"
+Optimize sibling and tail recursive calls.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fno\-inline\fR" 4
+.IX Item "-fno-inline"
+Do not expand any functions inline apart from those marked with
+the \f(CW\*(C`always_inline\*(C'\fR attribute.  This is the default when not
+optimizing.
+.Sp
+Single functions can be exempted from inlining by marking them
+with the \f(CW\*(C`noinline\*(C'\fR attribute.
+.IP "\fB\-finline\-small\-functions\fR" 4
+.IX Item "-finline-small-functions"
+Integrate functions into their callers when their body is smaller than expected
+function call code (so overall size of program gets smaller).  The compiler
+heuristically decides which functions are simple enough to be worth integrating
+in this way.  This inlining applies to all functions, even those not declared
+inline.
+.Sp
+Enabled at level \fB\-O2\fR.
+.IP "\fB\-findirect\-inlining\fR" 4
+.IX Item "-findirect-inlining"
+Inline also indirect calls that are discovered to be known at compile
+time thanks to previous inlining.  This option has any effect only
+when inlining itself is turned on by the \fB\-finline\-functions\fR
+or \fB\-finline\-small\-functions\fR options.
+.Sp
+Enabled at level \fB\-O2\fR.
+.IP "\fB\-finline\-functions\fR" 4
+.IX Item "-finline-functions"
+Consider all functions for inlining, even if they are not declared inline.
+The compiler heuristically decides which functions are worth integrating
+in this way.
+.Sp
+If all calls to a given function are integrated, and the function is
+declared \f(CW\*(C`static\*(C'\fR, then the function is normally not output as
+assembler code in its own right.
+.Sp
+Enabled at level \fB\-O3\fR.
+.IP "\fB\-finline\-functions\-called\-once\fR" 4
+.IX Item "-finline-functions-called-once"
+Consider all \f(CW\*(C`static\*(C'\fR functions called once for inlining into their
+caller even if they are not marked \f(CW\*(C`inline\*(C'\fR.  If a call to a given
+function is integrated, then the function is not output as assembler code
+in its own right.
+.Sp
+Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
+.IP "\fB\-fearly\-inlining\fR" 4
+.IX Item "-fearly-inlining"
+Inline functions marked by \f(CW\*(C`always_inline\*(C'\fR and functions whose body seems
+smaller than the function call overhead early before doing
+\&\fB\-fprofile\-generate\fR instrumentation and real inlining pass.  Doing so
+makes profiling significantly cheaper and usually inlining faster on programs
+having large chains of nested wrapper functions.
+.Sp
+Enabled by default.
+.IP "\fB\-fipa\-sra\fR" 4
+.IX Item "-fipa-sra"
+Perform interprocedural scalar replacement of aggregates, removal of
+unused parameters and replacement of parameters passed by reference
+by parameters passed by value.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
+.IP "\fB\-finline\-limit=\fR\fIn\fR" 4
+.IX Item "-finline-limit=n"
+By default, \s-1GCC\s0 limits the size of functions that can be inlined.  This flag
+allows coarse control of this limit.  \fIn\fR is the size of functions that
+can be inlined in number of pseudo instructions.
+.Sp
+Inlining is actually controlled by a number of parameters, which may be
+specified individually by using \fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR.
+The \fB\-finline\-limit=\fR\fIn\fR option sets some of these parameters
+as follows:
+.RS 4
+.IP "\fBmax-inline-insns-single\fR" 4
+.IX Item "max-inline-insns-single"
+is set to \fIn\fR/2.
+.IP "\fBmax-inline-insns-auto\fR" 4
+.IX Item "max-inline-insns-auto"
+is set to \fIn\fR/2.
+.RE
+.RS 4
+.Sp
+See below for a documentation of the individual
+parameters controlling inlining and for the defaults of these parameters.
+.Sp
+\&\fINote:\fR there may be no value to \fB\-finline\-limit\fR that results
+in default behavior.
+.Sp
+\&\fINote:\fR pseudo instruction represents, in this particular context, an
+abstract measurement of function's size.  In no way does it represent a count
+of assembly instructions and as such its exact meaning might change from one
+release to an another.
+.RE
+.IP "\fB\-fno\-keep\-inline\-dllexport\fR" 4
+.IX Item "-fno-keep-inline-dllexport"
+This is a more fine-grained version of \fB\-fkeep\-inline\-functions\fR,
+which applies only to functions that are declared using the \f(CW\*(C`dllexport\*(C'\fR
+attribute or declspec
+.IP "\fB\-fkeep\-inline\-functions\fR" 4
+.IX Item "-fkeep-inline-functions"
+In C, emit \f(CW\*(C`static\*(C'\fR functions that are declared \f(CW\*(C`inline\*(C'\fR
+into the object file, even if the function has been inlined into all
+of its callers.  This switch does not affect functions using the
+\&\f(CW\*(C`extern inline\*(C'\fR extension in \s-1GNU C90. \s0 In \*(C+, emit any and all
+inline functions into the object file.
+.IP "\fB\-fkeep\-static\-consts\fR" 4
+.IX Item "-fkeep-static-consts"
+Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn't turned
+on, even if the variables aren't referenced.
+.Sp
+\&\s-1GCC\s0 enables this option by default.  If you want to force the compiler to
+check if a variable is referenced, regardless of whether or not
+optimization is turned on, use the \fB\-fno\-keep\-static\-consts\fR option.
+.IP "\fB\-fmerge\-constants\fR" 4
+.IX Item "-fmerge-constants"
+Attempt to merge identical constants (string constants and floating-point
+constants) across compilation units.
+.Sp
+This option is the default for optimized compilation if the assembler and
+linker support it.  Use \fB\-fno\-merge\-constants\fR to inhibit this
+behavior.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fmerge\-all\-constants\fR" 4
+.IX Item "-fmerge-all-constants"
+Attempt to merge identical constants and identical variables.
+.Sp
+This option implies \fB\-fmerge\-constants\fR.  In addition to
+\&\fB\-fmerge\-constants\fR this considers e.g. even constant initialized
+arrays or initialized constant variables with integral or floating-point
+types.  Languages like C or \*(C+ require each variable, including multiple
+instances of the same variable in recursive calls, to have distinct locations,
+so using this option results in non-conforming
+behavior.
+.IP "\fB\-fmodulo\-sched\fR" 4
+.IX Item "-fmodulo-sched"
+Perform swing modulo scheduling immediately before the first scheduling
+pass.  This pass looks at innermost loops and reorders their
+instructions by overlapping different iterations.
+.IP "\fB\-fmodulo\-sched\-allow\-regmoves\fR" 4
+.IX Item "-fmodulo-sched-allow-regmoves"
+Perform more aggressive SMS-based modulo scheduling with register moves
+allowed.  By setting this flag certain anti-dependences edges are
+deleted, which triggers the generation of reg-moves based on the
+life-range analysis.  This option is effective only with
+\&\fB\-fmodulo\-sched\fR enabled.
+.IP "\fB\-fno\-branch\-count\-reg\fR" 4
+.IX Item "-fno-branch-count-reg"
+Do not use \*(L"decrement and branch\*(R" instructions on a count register,
+but instead generate a sequence of instructions that decrement a
+register, compare it against zero, then branch based upon the result.
+This option is only meaningful on architectures that support such
+instructions, which include x86, PowerPC, \s-1IA\-64\s0 and S/390.
+.Sp
+The default is \fB\-fbranch\-count\-reg\fR.
+.IP "\fB\-fno\-function\-cse\fR" 4
+.IX Item "-fno-function-cse"
+Do not put function addresses in registers; make each instruction that
+calls a constant function contain the function's address explicitly.
+.Sp
+This option results in less efficient code, but some strange hacks
+that alter the assembler output may be confused by the optimizations
+performed when this option is not used.
+.Sp
+The default is \fB\-ffunction\-cse\fR
+.IP "\fB\-fno\-zero\-initialized\-in\-bss\fR" 4
+.IX Item "-fno-zero-initialized-in-bss"
+If the target supports a \s-1BSS\s0 section, \s-1GCC\s0 by default puts variables that
+are initialized to zero into \s-1BSS. \s0 This can save space in the resulting
+code.
+.Sp
+This option turns off this behavior because some programs explicitly
+rely on variables going to the data section\-\-\-e.g., so that the
+resulting executable can find the beginning of that section and/or make
+assumptions based on that.
+.Sp
+The default is \fB\-fzero\-initialized\-in\-bss\fR.
+.IP "\fB\-fthread\-jumps\fR" 4
+.IX Item "-fthread-jumps"
+Perform optimizations that check to see if a jump branches to a
+location where another comparison subsumed by the first is found.  If
+so, the first branch is redirected to either the destination of the
+second branch or a point immediately following it, depending on whether
+the condition is known to be true or false.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fsplit\-wide\-types\fR" 4
+.IX Item "-fsplit-wide-types"
+When using a type that occupies multiple registers, such as \f(CW\*(C`long
+long\*(C'\fR on a 32\-bit system, split the registers apart and allocate them
+independently.  This normally generates better code for those types,
+but may make debugging more difficult.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR,
+\&\fB\-Os\fR.
+.IP "\fB\-fcse\-follow\-jumps\fR" 4
+.IX Item "-fcse-follow-jumps"
+In common subexpression elimination (\s-1CSE\s0), scan through jump instructions
+when the target of the jump is not reached by any other path.  For
+example, when \s-1CSE\s0 encounters an \f(CW\*(C`if\*(C'\fR statement with an
+\&\f(CW\*(C`else\*(C'\fR clause, \s-1CSE\s0 follows the jump when the condition
+tested is false.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fcse\-skip\-blocks\fR" 4
+.IX Item "-fcse-skip-blocks"
+This is similar to \fB\-fcse\-follow\-jumps\fR, but causes \s-1CSE\s0 to
+follow jumps that conditionally skip over blocks.  When \s-1CSE\s0
+encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause,
+\&\fB\-fcse\-skip\-blocks\fR causes \s-1CSE\s0 to follow the jump around the
+body of the \f(CW\*(C`if\*(C'\fR.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-frerun\-cse\-after\-loop\fR" 4
+.IX Item "-frerun-cse-after-loop"
+Re-run common subexpression elimination after loop optimizations are
+performed.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fgcse\fR" 4
+.IX Item "-fgcse"
+Perform a global common subexpression elimination pass.
+This pass also performs global constant and copy propagation.
+.Sp
+\&\fINote:\fR When compiling a program using computed gotos, a \s-1GCC\s0
+extension, you may get better run-time performance if you disable
+the global common subexpression elimination pass by adding
+\&\fB\-fno\-gcse\fR to the command line.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fgcse\-lm\fR" 4
+.IX Item "-fgcse-lm"
+When \fB\-fgcse\-lm\fR is enabled, global common subexpression elimination
+attempts to move loads that are only killed by stores into themselves.  This
+allows a loop containing a load/store sequence to be changed to a load outside
+the loop, and a copy/store within the loop.
+.Sp
+Enabled by default when \fB\-fgcse\fR is enabled.
+.IP "\fB\-fgcse\-sm\fR" 4
+.IX Item "-fgcse-sm"
+When \fB\-fgcse\-sm\fR is enabled, a store motion pass is run after
+global common subexpression elimination.  This pass attempts to move
+stores out of loops.  When used in conjunction with \fB\-fgcse\-lm\fR,
+loops containing a load/store sequence can be changed to a load before
+the loop and a store after the loop.
+.Sp
+Not enabled at any optimization level.
+.IP "\fB\-fgcse\-las\fR" 4
+.IX Item "-fgcse-las"
+When \fB\-fgcse\-las\fR is enabled, the global common subexpression
+elimination pass eliminates redundant loads that come after stores to the
+same memory location (both partial and full redundancies).
+.Sp
+Not enabled at any optimization level.
+.IP "\fB\-fgcse\-after\-reload\fR" 4
+.IX Item "-fgcse-after-reload"
+When \fB\-fgcse\-after\-reload\fR is enabled, a redundant load elimination
+pass is performed after reload.  The purpose of this pass is to clean up
+redundant spilling.
+.IP "\fB\-faggressive\-loop\-optimizations\fR" 4
+.IX Item "-faggressive-loop-optimizations"
+This option tells the loop optimizer to use language constraints to
+derive bounds for the number of iterations of a loop.  This assumes that
+loop code does not invoke undefined behavior by for example causing signed
+integer overflows or out-of-bound array accesses.  The bounds for the
+number of iterations of a loop are used to guide loop unrolling and peeling
+and loop exit test optimizations.
+This option is enabled by default.
+.IP "\fB\-funsafe\-loop\-optimizations\fR" 4
+.IX Item "-funsafe-loop-optimizations"
+This option tells the loop optimizer to assume that loop indices do not
+overflow, and that loops with nontrivial exit condition are not
+infinite.  This enables a wider range of loop optimizations even if
+the loop optimizer itself cannot prove that these assumptions are valid.
+If you use \fB\-Wunsafe\-loop\-optimizations\fR, the compiler warns you
+if it finds this kind of loop.
+.IP "\fB\-fcrossjumping\fR" 4
+.IX Item "-fcrossjumping"
+Perform cross-jumping transformation.
+This transformation unifies equivalent code and saves code size.  The
+resulting code may or may not perform better than without cross-jumping.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fauto\-inc\-dec\fR" 4
+.IX Item "-fauto-inc-dec"
+Combine increments or decrements of addresses with memory accesses.
+This pass is always skipped on architectures that do not have
+instructions to support this.  Enabled by default at \fB\-O\fR and
+higher on architectures that support this.
+.IP "\fB\-fdce\fR" 4
+.IX Item "-fdce"
+Perform dead code elimination (\s-1DCE\s0) on \s-1RTL.\s0
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fdse\fR" 4
+.IX Item "-fdse"
+Perform dead store elimination (\s-1DSE\s0) on \s-1RTL.\s0
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fif\-conversion\fR" 4
+.IX Item "-fif-conversion"
+Attempt to transform conditional jumps into branch-less equivalents.  This
+includes use of conditional moves, min, max, set flags and abs instructions, and
+some tricks doable by standard arithmetics.  The use of conditional execution
+on chips where it is available is controlled by \f(CW\*(C`if\-conversion2\*(C'\fR.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fif\-conversion2\fR" 4
+.IX Item "-fif-conversion2"
+Use conditional execution (where available) to transform conditional jumps into
+branch-less equivalents.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fdeclone\-ctor\-dtor\fR" 4
+.IX Item "-fdeclone-ctor-dtor"
+The \*(C+ \s-1ABI\s0 requires multiple entry points for constructors and
+destructors: one for a base subobject, one for a complete object, and
+one for a virtual destructor that calls operator delete afterwards.
+For a hierarchy with virtual bases, the base and complete variants are
+clones, which means two copies of the function.  With this option, the
+base and complete variants are changed to be thunks that call a common
+implementation.
+.Sp
+Enabled by \fB\-Os\fR.
+.IP "\fB\-fdelete\-null\-pointer\-checks\fR" 4
+.IX Item "-fdelete-null-pointer-checks"
+Assume that programs cannot safely dereference null pointers, and that
+no code or data element resides there.  This enables simple constant
+folding optimizations at all optimization levels.  In addition, other
+optimization passes in \s-1GCC\s0 use this flag to control global dataflow
+analyses that eliminate useless checks for null pointers; these assume
+that if a pointer is checked after it has already been dereferenced,
+it cannot be null.
+.Sp
+Note however that in some environments this assumption is not true.
+Use \fB\-fno\-delete\-null\-pointer\-checks\fR to disable this optimization
+for programs that depend on that behavior.
+.Sp
+Some targets, especially embedded ones, disable this option at all levels.
+Otherwise it is enabled at all levels: \fB\-O0\fR, \fB\-O1\fR,
+\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.  Passes that use the information
+are enabled independently at different optimization levels.
+.IP "\fB\-fdevirtualize\fR" 4
+.IX Item "-fdevirtualize"
+Attempt to convert calls to virtual functions to direct calls.  This
+is done both within a procedure and interprocedurally as part of
+indirect inlining (\f(CW\*(C`\-findirect\-inlining\*(C'\fR) and interprocedural constant
+propagation (\fB\-fipa\-cp\fR).
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fdevirtualize\-speculatively\fR" 4
+.IX Item "-fdevirtualize-speculatively"
+Attempt to convert calls to virtual functions to speculative direct calls.
+Based on the analysis of the type inheritance graph, determine for a given call
+the set of likely targets. If the set is small, preferably of size 1, change
+the call into an conditional deciding on direct and indirect call.  The
+speculative calls enable more optimizations, such as inlining.  When they seem
+useless after further optimization, they are converted back into original form.
+.IP "\fB\-fexpensive\-optimizations\fR" 4
+.IX Item "-fexpensive-optimizations"
+Perform a number of minor optimizations that are relatively expensive.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-free\fR" 4
+.IX Item "-free"
+Attempt to remove redundant extension instructions.  This is especially
+helpful for the x86\-64 architecture, which implicitly zero-extends in 64\-bit
+registers after writing to their lower 32\-bit half.
+.Sp
+Enabled for AArch64 and x86 at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-flive\-range\-shrinkage\fR" 4
+.IX Item "-flive-range-shrinkage"
+Attempt to decrease register pressure through register live range
+shrinkage.  This is helpful for fast processors with small or moderate
+size register sets.
+.IP "\fB\-fira\-algorithm=\fR\fIalgorithm\fR" 4
+.IX Item "-fira-algorithm=algorithm"
+Use the specified coloring algorithm for the integrated register
+allocator.  The \fIalgorithm\fR argument can be \fBpriority\fR, which
+specifies Chow's priority coloring, or \fB\s-1CB\s0\fR, which specifies
+Chaitin-Briggs coloring.  Chaitin-Briggs coloring is not implemented
+for all architectures, but for those targets that do support it, it is
+the default because it generates better code.
+.IP "\fB\-fira\-region=\fR\fIregion\fR" 4
+.IX Item "-fira-region=region"
+Use specified regions for the integrated register allocator.  The
+\&\fIregion\fR argument should be one of the following:
+.RS 4
+.IP "\fBall\fR" 4
+.IX Item "all"
+Use all loops as register allocation regions.
+This can give the best results for machines with a small and/or
+irregular register set.
+.IP "\fBmixed\fR" 4
+.IX Item "mixed"
+Use all loops except for loops with small register pressure 
+as the regions.  This value usually gives
+the best results in most cases and for most architectures,
+and is enabled by default when compiling with optimization for speed
+(\fB\-O\fR, \fB\-O2\fR, ...).
+.IP "\fBone\fR" 4
+.IX Item "one"
+Use all functions as a single region.  
+This typically results in the smallest code size, and is enabled by default for
+\&\fB\-Os\fR or \fB\-O0\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fira\-hoist\-pressure\fR" 4
+.IX Item "-fira-hoist-pressure"
+Use \s-1IRA\s0 to evaluate register pressure in the code hoisting pass for
+decisions to hoist expressions.  This option usually results in smaller
+code, but it can slow the compiler down.
+.Sp
+This option is enabled at level \fB\-Os\fR for all targets.
+.IP "\fB\-fira\-loop\-pressure\fR" 4
+.IX Item "-fira-loop-pressure"
+Use \s-1IRA\s0 to evaluate register pressure in loops for decisions to move
+loop invariants.  This option usually results in generation
+of faster and smaller code on machines with large register files (>= 32
+registers), but it can slow the compiler down.
+.Sp
+This option is enabled at level \fB\-O3\fR for some targets.
+.IP "\fB\-fno\-ira\-share\-save\-slots\fR" 4
+.IX Item "-fno-ira-share-save-slots"
+Disable sharing of stack slots used for saving call-used hard
+registers living through a call.  Each hard register gets a
+separate stack slot, and as a result function stack frames are
+larger.
+.IP "\fB\-fno\-ira\-share\-spill\-slots\fR" 4
+.IX Item "-fno-ira-share-spill-slots"
+Disable sharing of stack slots allocated for pseudo-registers.  Each
+pseudo-register that does not get a hard register gets a separate
+stack slot, and as a result function stack frames are larger.
+.IP "\fB\-fira\-verbose=\fR\fIn\fR" 4
+.IX Item "-fira-verbose=n"
+Control the verbosity of the dump file for the integrated register allocator.
+The default value is 5.  If the value \fIn\fR is greater or equal to 10,
+the dump output is sent to stderr using the same format as \fIn\fR minus 10.
+.IP "\fB\-fdelayed\-branch\fR" 4
+.IX Item "-fdelayed-branch"
+If supported for the target machine, attempt to reorder instructions
+to exploit instruction slots available after delayed branch
+instructions.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fschedule\-insns\fR" 4
+.IX Item "-fschedule-insns"
+If supported for the target machine, attempt to reorder instructions to
+eliminate execution stalls due to required data being unavailable.  This
+helps machines that have slow floating point or memory load instructions
+by allowing other instructions to be issued until the result of the load
+or floating-point instruction is required.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-fschedule\-insns2\fR" 4
+.IX Item "-fschedule-insns2"
+Similar to \fB\-fschedule\-insns\fR, but requests an additional pass of
+instruction scheduling after register allocation has been done.  This is
+especially useful on machines with a relatively small number of
+registers and where memory load instructions take more than one cycle.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fno\-sched\-interblock\fR" 4
+.IX Item "-fno-sched-interblock"
+Don't schedule instructions across basic blocks.  This is normally
+enabled by default when scheduling before register allocation, i.e.
+with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fno\-sched\-spec\fR" 4
+.IX Item "-fno-sched-spec"
+Don't allow speculative motion of non-load instructions.  This is normally
+enabled by default when scheduling before register allocation, i.e.
+with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-pressure\fR" 4
+.IX Item "-fsched-pressure"
+Enable register pressure sensitive insn scheduling before register
+allocation.  This only makes sense when scheduling before register
+allocation is enabled, i.e. with \fB\-fschedule\-insns\fR or at
+\&\fB\-O2\fR or higher.  Usage of this option can improve the
+generated code and decrease its size by preventing register pressure
+increase above the number of available hard registers and subsequent
+spills in register allocation.
+.IP "\fB\-fsched\-spec\-load\fR" 4
+.IX Item "-fsched-spec-load"
+Allow speculative motion of some load instructions.  This only makes
+sense when scheduling before register allocation, i.e. with
+\&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-spec\-load\-dangerous\fR" 4
+.IX Item "-fsched-spec-load-dangerous"
+Allow speculative motion of more load instructions.  This only makes
+sense when scheduling before register allocation, i.e. with
+\&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-stalled\-insns\fR" 4
+.IX Item "-fsched-stalled-insns"
+.PD 0
+.IP "\fB\-fsched\-stalled\-insns=\fR\fIn\fR" 4
+.IX Item "-fsched-stalled-insns=n"
+.PD
+Define how many insns (if any) can be moved prematurely from the queue
+of stalled insns into the ready list during the second scheduling pass.
+\&\fB\-fno\-sched\-stalled\-insns\fR means that no insns are moved
+prematurely, \fB\-fsched\-stalled\-insns=0\fR means there is no limit
+on how many queued insns can be moved prematurely.
+\&\fB\-fsched\-stalled\-insns\fR without a value is equivalent to
+\&\fB\-fsched\-stalled\-insns=1\fR.
+.IP "\fB\-fsched\-stalled\-insns\-dep\fR" 4
+.IX Item "-fsched-stalled-insns-dep"
+.PD 0
+.IP "\fB\-fsched\-stalled\-insns\-dep=\fR\fIn\fR" 4
+.IX Item "-fsched-stalled-insns-dep=n"
+.PD
+Define how many insn groups (cycles) are examined for a dependency
+on a stalled insn that is a candidate for premature removal from the queue
+of stalled insns.  This has an effect only during the second scheduling pass,
+and only if \fB\-fsched\-stalled\-insns\fR is used.
+\&\fB\-fno\-sched\-stalled\-insns\-dep\fR is equivalent to
+\&\fB\-fsched\-stalled\-insns\-dep=0\fR.
+\&\fB\-fsched\-stalled\-insns\-dep\fR without a value is equivalent to
+\&\fB\-fsched\-stalled\-insns\-dep=1\fR.
+.IP "\fB\-fsched2\-use\-superblocks\fR" 4
+.IX Item "-fsched2-use-superblocks"
+When scheduling after register allocation, use superblock scheduling.
+This allows motion across basic block boundaries,
+resulting in faster schedules.  This option is experimental, as not all machine
+descriptions used by \s-1GCC\s0 model the \s-1CPU\s0 closely enough to avoid unreliable
+results from the algorithm.
+.Sp
+This only makes sense when scheduling after register allocation, i.e. with
+\&\fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-group\-heuristic\fR" 4
+.IX Item "-fsched-group-heuristic"
+Enable the group heuristic in the scheduler.  This heuristic favors
+the instruction that belongs to a schedule group.  This is enabled
+by default when scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
+or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-critical\-path\-heuristic\fR" 4
+.IX Item "-fsched-critical-path-heuristic"
+Enable the critical-path heuristic in the scheduler.  This heuristic favors
+instructions on the critical path.  This is enabled by default when
+scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
+or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-spec\-insn\-heuristic\fR" 4
+.IX Item "-fsched-spec-insn-heuristic"
+Enable the speculative instruction heuristic in the scheduler.  This
+heuristic favors speculative instructions with greater dependency weakness.
+This is enabled by default when scheduling is enabled, i.e.
+with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR
+or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-rank\-heuristic\fR" 4
+.IX Item "-fsched-rank-heuristic"
+Enable the rank heuristic in the scheduler.  This heuristic favors
+the instruction belonging to a basic block with greater size or frequency.
+This is enabled by default when scheduling is enabled, i.e.
+with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
+at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-last\-insn\-heuristic\fR" 4
+.IX Item "-fsched-last-insn-heuristic"
+Enable the last-instruction heuristic in the scheduler.  This heuristic
+favors the instruction that is less dependent on the last instruction
+scheduled.  This is enabled by default when scheduling is enabled,
+i.e. with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
+at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-dep\-count\-heuristic\fR" 4
+.IX Item "-fsched-dep-count-heuristic"
+Enable the dependent-count heuristic in the scheduler.  This heuristic
+favors the instruction that has more instructions depending on it.
+This is enabled by default when scheduling is enabled, i.e.
+with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
+at \fB\-O2\fR or higher.
+.IP "\fB\-freschedule\-modulo\-scheduled\-loops\fR" 4
+.IX Item "-freschedule-modulo-scheduled-loops"
+Modulo scheduling is performed before traditional scheduling.  If a loop
+is modulo scheduled, later scheduling passes may change its schedule.  
+Use this option to control that behavior.
+.IP "\fB\-fselective\-scheduling\fR" 4
+.IX Item "-fselective-scheduling"
+Schedule instructions using selective scheduling algorithm.  Selective
+scheduling runs instead of the first scheduler pass.
+.IP "\fB\-fselective\-scheduling2\fR" 4
+.IX Item "-fselective-scheduling2"
+Schedule instructions using selective scheduling algorithm.  Selective
+scheduling runs instead of the second scheduler pass.
+.IP "\fB\-fsel\-sched\-pipelining\fR" 4
+.IX Item "-fsel-sched-pipelining"
+Enable software pipelining of innermost loops during selective scheduling.
+This option has no effect unless one of \fB\-fselective\-scheduling\fR or
+\&\fB\-fselective\-scheduling2\fR is turned on.
+.IP "\fB\-fsel\-sched\-pipelining\-outer\-loops\fR" 4
+.IX Item "-fsel-sched-pipelining-outer-loops"
+When pipelining loops during selective scheduling, also pipeline outer loops.
+This option has no effect unless \fB\-fsel\-sched\-pipelining\fR is turned on.
+.IP "\fB\-fshrink\-wrap\fR" 4
+.IX Item "-fshrink-wrap"
+Emit function prologues only before parts of the function that need it,
+rather than at the top of the function.  This flag is enabled by default at
+\&\fB\-O\fR and higher.
+.IP "\fB\-fcaller\-saves\fR" 4
+.IX Item "-fcaller-saves"
+Enable allocation of values to registers that are clobbered by
+function calls, by emitting extra instructions to save and restore the
+registers around such calls.  Such allocation is done only when it
+seems to result in better code.
+.Sp
+This option is always enabled by default on certain machines, usually
+those which have no call-preserved registers to use instead.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fcombine\-stack\-adjustments\fR" 4
+.IX Item "-fcombine-stack-adjustments"
+Tracks stack adjustments (pushes and pops) and stack memory references
+and then tries to find ways to combine them.
+.Sp
+Enabled by default at \fB\-O1\fR and higher.
+.IP "\fB\-fconserve\-stack\fR" 4
+.IX Item "-fconserve-stack"
+Attempt to minimize stack usage.  The compiler attempts to use less
+stack space, even if that makes the program slower.  This option
+implies setting the \fBlarge-stack-frame\fR parameter to 100
+and the \fBlarge-stack-frame-growth\fR parameter to 400.
+.IP "\fB\-ftree\-reassoc\fR" 4
+.IX Item "-ftree-reassoc"
+Perform reassociation on trees.  This flag is enabled by default
+at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-pre\fR" 4
+.IX Item "-ftree-pre"
+Perform partial redundancy elimination (\s-1PRE\s0) on trees.  This flag is
+enabled by default at \fB\-O2\fR and \fB\-O3\fR.
+.IP "\fB\-ftree\-partial\-pre\fR" 4
+.IX Item "-ftree-partial-pre"
+Make partial redundancy elimination (\s-1PRE\s0) more aggressive.  This flag is
+enabled by default at \fB\-O3\fR.
+.IP "\fB\-ftree\-forwprop\fR" 4
+.IX Item "-ftree-forwprop"
+Perform forward propagation on trees.  This flag is enabled by default
+at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-fre\fR" 4
+.IX Item "-ftree-fre"
+Perform full redundancy elimination (\s-1FRE\s0) on trees.  The difference
+between \s-1FRE\s0 and \s-1PRE\s0 is that \s-1FRE\s0 only considers expressions
+that are computed on all paths leading to the redundant computation.
+This analysis is faster than \s-1PRE,\s0 though it exposes fewer redundancies.
+This flag is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-phiprop\fR" 4
+.IX Item "-ftree-phiprop"
+Perform hoisting of loads from conditional pointers on trees.  This
+pass is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fhoist\-adjacent\-loads\fR" 4
+.IX Item "-fhoist-adjacent-loads"
+Speculatively hoist loads from both branches of an if-then-else if the
+loads are from adjacent locations in the same structure and the target
+architecture has a conditional move instruction.  This flag is enabled
+by default at \fB\-O2\fR and higher.
+.IP "\fB\-ftree\-copy\-prop\fR" 4
+.IX Item "-ftree-copy-prop"
+Perform copy propagation on trees.  This pass eliminates unnecessary
+copy operations.  This flag is enabled by default at \fB\-O\fR and
+higher.
+.IP "\fB\-fipa\-pure\-const\fR" 4
+.IX Item "-fipa-pure-const"
+Discover which functions are pure or constant.
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fipa\-reference\fR" 4
+.IX Item "-fipa-reference"
+Discover which static variables do not escape the
+compilation unit.
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fipa\-pta\fR" 4
+.IX Item "-fipa-pta"
+Perform interprocedural pointer analysis and interprocedural modification
+and reference analysis.  This option can cause excessive memory and
+compile-time usage on large compilation units.  It is not enabled by
+default at any optimization level.
+.IP "\fB\-fipa\-profile\fR" 4
+.IX Item "-fipa-profile"
+Perform interprocedural profile propagation.  The functions called only from
+cold functions are marked as cold. Also functions executed once (such as
+\&\f(CW\*(C`cold\*(C'\fR, \f(CW\*(C`noreturn\*(C'\fR, static constructors or destructors) are identified. Cold
+functions and loop less parts of functions executed once are then optimized for
+size.
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fipa\-cp\fR" 4
+.IX Item "-fipa-cp"
+Perform interprocedural constant propagation.
+This optimization analyzes the program to determine when values passed
+to functions are constants and then optimizes accordingly.
+This optimization can substantially increase performance
+if the application has constants passed to functions.
+This flag is enabled by default at \fB\-O2\fR, \fB\-Os\fR and \fB\-O3\fR.
+.IP "\fB\-fipa\-cp\-clone\fR" 4
+.IX Item "-fipa-cp-clone"
+Perform function cloning to make interprocedural constant propagation stronger.
+When enabled, interprocedural constant propagation performs function cloning
+when externally visible function can be called with constant arguments.
+Because this optimization can create multiple copies of functions,
+it may significantly increase code size
+(see \fB\-\-param ipcp\-unit\-growth=\fR\fIvalue\fR).
+This flag is enabled by default at \fB\-O3\fR.
+.IP "\fB\-fisolate\-erroneous\-paths\-dereference\fR" 4
+.IX Item "-fisolate-erroneous-paths-dereference"
+Detect paths which trigger erroneous or undefined behaviour due to
+dereferencing a \s-1NULL\s0 pointer.  Isolate those paths from the main control
+flow and turn the statement with erroneous or undefined behaviour into a trap.
+.IP "\fB\-fisolate\-erroneous\-paths\-attribute\fR" 4
+.IX Item "-fisolate-erroneous-paths-attribute"
+Detect paths which trigger erroneous or undefined behaviour due a \s-1NULL\s0 value
+being used in a way which is forbidden by a \f(CW\*(C`returns_nonnull\*(C'\fR or \f(CW\*(C`nonnull\*(C'\fR
+attribute.  Isolate those paths from the main control flow and turn the
+statement with erroneous or undefined behaviour into a trap.  This is not
+currently enabled, but may be enabled by \f(CW\*(C`\-O2\*(C'\fR in the future.
+.IP "\fB\-ftree\-sink\fR" 4
+.IX Item "-ftree-sink"
+Perform forward store motion  on trees.  This flag is
+enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-bit\-ccp\fR" 4
+.IX Item "-ftree-bit-ccp"
+Perform sparse conditional bit constant propagation on trees and propagate
+pointer alignment information.
+This pass only operates on local scalar variables and is enabled by default
+at \fB\-O\fR and higher.  It requires that \fB\-ftree\-ccp\fR is enabled.
+.IP "\fB\-ftree\-ccp\fR" 4
+.IX Item "-ftree-ccp"
+Perform sparse conditional constant propagation (\s-1CCP\s0) on trees.  This
+pass only operates on local scalar variables and is enabled by default
+at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-switch\-conversion\fR" 4
+.IX Item "-ftree-switch-conversion"
+Perform conversion of simple initializations in a switch to
+initializations from a scalar array.  This flag is enabled by default
+at \fB\-O2\fR and higher.
+.IP "\fB\-ftree\-tail\-merge\fR" 4
+.IX Item "-ftree-tail-merge"
+Look for identical code sequences.  When found, replace one with a jump to the
+other.  This optimization is known as tail merging or cross jumping.  This flag
+is enabled by default at \fB\-O2\fR and higher.  The compilation time
+in this pass can
+be limited using \fBmax-tail-merge-comparisons\fR parameter and
+\&\fBmax-tail-merge-iterations\fR parameter.
+.IP "\fB\-ftree\-dce\fR" 4
+.IX Item "-ftree-dce"
+Perform dead code elimination (\s-1DCE\s0) on trees.  This flag is enabled by
+default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-builtin\-call\-dce\fR" 4
+.IX Item "-ftree-builtin-call-dce"
+Perform conditional dead code elimination (\s-1DCE\s0) for calls to built-in functions
+that may set \f(CW\*(C`errno\*(C'\fR but are otherwise side-effect free.  This flag is
+enabled by default at \fB\-O2\fR and higher if \fB\-Os\fR is not also
+specified.
+.IP "\fB\-ftree\-dominator\-opts\fR" 4
+.IX Item "-ftree-dominator-opts"
+Perform a variety of simple scalar cleanups (constant/copy
+propagation, redundancy elimination, range propagation and expression
+simplification) based on a dominator tree traversal.  This also
+performs jump threading (to reduce jumps to jumps). This flag is
+enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-dse\fR" 4
+.IX Item "-ftree-dse"
+Perform dead store elimination (\s-1DSE\s0) on trees.  A dead store is a store into
+a memory location that is later overwritten by another store without
+any intervening loads.  In this case the earlier store can be deleted.  This
+flag is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-ch\fR" 4
+.IX Item "-ftree-ch"
+Perform loop header copying on trees.  This is beneficial since it increases
+effectiveness of code motion optimizations.  It also saves one jump.  This flag
+is enabled by default at \fB\-O\fR and higher.  It is not enabled
+for \fB\-Os\fR, since it usually increases code size.
+.IP "\fB\-ftree\-loop\-optimize\fR" 4
+.IX Item "-ftree-loop-optimize"
+Perform loop optimizations on trees.  This flag is enabled by default
+at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-loop\-linear\fR" 4
+.IX Item "-ftree-loop-linear"
+Perform loop interchange transformations on tree.  Same as
+\&\fB\-floop\-interchange\fR.  To use this code transformation, \s-1GCC\s0 has
+to be configured with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to
+enable the Graphite loop transformation infrastructure.
+.IP "\fB\-floop\-interchange\fR" 4
+.IX Item "-floop-interchange"
+Perform loop interchange transformations on loops.  Interchanging two
+nested loops switches the inner and outer loops.  For example, given a
+loop like:
+.Sp
+.Vb 5
+\&        DO J = 1, M
+\&          DO I = 1, N
+\&            A(J, I) = A(J, I) * C
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+loop interchange transforms the loop as if it were written:
+.Sp
+.Vb 5
+\&        DO I = 1, N
+\&          DO J = 1, M
+\&            A(J, I) = A(J, I) * C
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+which can be beneficial when \f(CW\*(C`N\*(C'\fR is larger than the caches,
+because in Fortran, the elements of an array are stored in memory
+contiguously by column, and the original loop iterates over rows,
+potentially creating at each access a cache miss.  This optimization
+applies to all the languages supported by \s-1GCC\s0 and is not limited to
+Fortran.  To use this code transformation, \s-1GCC\s0 has to be configured
+with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to enable the
+Graphite loop transformation infrastructure.
+.IP "\fB\-floop\-strip\-mine\fR" 4
+.IX Item "-floop-strip-mine"
+Perform loop strip mining transformations on loops.  Strip mining
+splits a loop into two nested loops.  The outer loop has strides
+equal to the strip size and the inner loop has strides of the
+original loop within a strip.  The strip length can be changed
+using the \fBloop-block-tile-size\fR parameter.  For example,
+given a loop like:
+.Sp
+.Vb 3
+\&        DO I = 1, N
+\&          A(I) = A(I) + C
+\&        ENDDO
+.Ve
+.Sp
+loop strip mining transforms the loop as if it were written:
+.Sp
+.Vb 5
+\&        DO II = 1, N, 51
+\&          DO I = II, min (II + 50, N)
+\&            A(I) = A(I) + C
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+This optimization applies to all the languages supported by \s-1GCC\s0 and is
+not limited to Fortran.  To use this code transformation, \s-1GCC\s0 has to
+be configured with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to
+enable the Graphite loop transformation infrastructure.
+.IP "\fB\-floop\-block\fR" 4
+.IX Item "-floop-block"
+Perform loop blocking transformations on loops.  Blocking strip mines
+each loop in the loop nest such that the memory accesses of the
+element loops fit inside caches.  The strip length can be changed
+using the \fBloop-block-tile-size\fR parameter.  For example, given
+a loop like:
+.Sp
+.Vb 5
+\&        DO I = 1, N
+\&          DO J = 1, M
+\&            A(J, I) = B(I) + C(J)
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+loop blocking transforms the loop as if it were written:
+.Sp
+.Vb 9
+\&        DO II = 1, N, 51
+\&          DO JJ = 1, M, 51
+\&            DO I = II, min (II + 50, N)
+\&              DO J = JJ, min (JJ + 50, M)
+\&                A(J, I) = B(I) + C(J)
+\&              ENDDO
+\&            ENDDO
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+which can be beneficial when \f(CW\*(C`M\*(C'\fR is larger than the caches,
+because the innermost loop iterates over a smaller amount of data
+which can be kept in the caches.  This optimization applies to all the
+languages supported by \s-1GCC\s0 and is not limited to Fortran.  To use this
+code transformation, \s-1GCC\s0 has to be configured with \fB\-\-with\-ppl\fR
+and \fB\-\-with\-cloog\fR to enable the Graphite loop transformation
+infrastructure.
+.IP "\fB\-fgraphite\-identity\fR" 4
+.IX Item "-fgraphite-identity"
+Enable the identity transformation for graphite.  For every SCoP we generate
+the polyhedral representation and transform it back to gimple.  Using
+\&\fB\-fgraphite\-identity\fR we can check the costs or benefits of the
+\&\s-1GIMPLE \-\s0> \s-1GRAPHITE \-\s0> \s-1GIMPLE\s0 transformation.  Some minimal optimizations
+are also performed by the code generator CLooG, like index splitting and
+dead code elimination in loops.
+.IP "\fB\-floop\-nest\-optimize\fR" 4
+.IX Item "-floop-nest-optimize"
+Enable the \s-1ISL\s0 based loop nest optimizer.  This is a generic loop nest
+optimizer based on the Pluto optimization algorithms.  It calculates a loop
+structure optimized for data-locality and parallelism.  This option
+is experimental.
+.IP "\fB\-floop\-parallelize\-all\fR" 4
+.IX Item "-floop-parallelize-all"
+Use the Graphite data dependence analysis to identify loops that can
+be parallelized.  Parallelize all the loops that can be analyzed to
+not contain loop carried dependences without checking that it is
+profitable to parallelize the loops.
+.IP "\fB\-fcheck\-data\-deps\fR" 4
+.IX Item "-fcheck-data-deps"
+Compare the results of several data dependence analyzers.  This option
+is used for debugging the data dependence analyzers.
+.IP "\fB\-ftree\-loop\-if\-convert\fR" 4
+.IX Item "-ftree-loop-if-convert"
+Attempt to transform conditional jumps in the innermost loops to
+branch-less equivalents.  The intent is to remove control-flow from
+the innermost loops in order to improve the ability of the
+vectorization pass to handle these loops.  This is enabled by default
+if vectorization is enabled.
+.IP "\fB\-ftree\-loop\-if\-convert\-stores\fR" 4
+.IX Item "-ftree-loop-if-convert-stores"
+Attempt to also if-convert conditional jumps containing memory writes.
+This transformation can be unsafe for multi-threaded programs as it
+transforms conditional memory writes into unconditional memory writes.
+For example,
+.Sp
+.Vb 3
+\&        for (i = 0; i < N; i++)
+\&          if (cond)
+\&            A[i] = expr;
+.Ve
+.Sp
+is transformed to
+.Sp
+.Vb 2
+\&        for (i = 0; i < N; i++)
+\&          A[i] = cond ? expr : A[i];
+.Ve
+.Sp
+potentially producing data races.
+.IP "\fB\-ftree\-loop\-distribution\fR" 4
+.IX Item "-ftree-loop-distribution"
+Perform loop distribution.  This flag can improve cache performance on
+big loop bodies and allow further loop optimizations, like
+parallelization or vectorization, to take place.  For example, the loop
+.Sp
+.Vb 4
+\&        DO I = 1, N
+\&          A(I) = B(I) + C
+\&          D(I) = E(I) * F
+\&        ENDDO
+.Ve
+.Sp
+is transformed to
+.Sp
+.Vb 6
+\&        DO I = 1, N
+\&           A(I) = B(I) + C
+\&        ENDDO
+\&        DO I = 1, N
+\&           D(I) = E(I) * F
+\&        ENDDO
+.Ve
+.IP "\fB\-ftree\-loop\-distribute\-patterns\fR" 4
+.IX Item "-ftree-loop-distribute-patterns"
+Perform loop distribution of patterns that can be code generated with
+calls to a library.  This flag is enabled by default at \fB\-O3\fR.
+.Sp
+This pass distributes the initialization loops and generates a call to
+memset zero.  For example, the loop
+.Sp
+.Vb 4
+\&        DO I = 1, N
+\&          A(I) = 0
+\&          B(I) = A(I) + I
+\&        ENDDO
+.Ve
+.Sp
+is transformed to
+.Sp
+.Vb 6
+\&        DO I = 1, N
+\&           A(I) = 0
+\&        ENDDO
+\&        DO I = 1, N
+\&           B(I) = A(I) + I
+\&        ENDDO
+.Ve
+.Sp
+and the initialization loop is transformed into a call to memset zero.
+.IP "\fB\-ftree\-loop\-im\fR" 4
+.IX Item "-ftree-loop-im"
+Perform loop invariant motion on trees.  This pass moves only invariants that
+are hard to handle at \s-1RTL\s0 level (function calls, operations that expand to
+nontrivial sequences of insns).  With \fB\-funswitch\-loops\fR it also moves
+operands of conditions that are invariant out of the loop, so that we can use
+just trivial invariantness analysis in loop unswitching.  The pass also includes
+store motion.
+.IP "\fB\-ftree\-loop\-ivcanon\fR" 4
+.IX Item "-ftree-loop-ivcanon"
+Create a canonical counter for number of iterations in loops for which
+determining number of iterations requires complicated analysis.  Later
+optimizations then may determine the number easily.  Useful especially
+in connection with unrolling.
+.IP "\fB\-fivopts\fR" 4
+.IX Item "-fivopts"
+Perform induction variable optimizations (strength reduction, induction
+variable merging and induction variable elimination) on trees.
+.IP "\fB\-ftree\-parallelize\-loops=n\fR" 4
+.IX Item "-ftree-parallelize-loops=n"
+Parallelize loops, i.e., split their iteration space to run in n threads.
+This is only possible for loops whose iterations are independent
+and can be arbitrarily reordered.  The optimization is only
+profitable on multiprocessor machines, for loops that are CPU-intensive,
+rather than constrained e.g. by memory bandwidth.  This option
+implies \fB\-pthread\fR, and thus is only supported on targets
+that have support for \fB\-pthread\fR.
+.IP "\fB\-ftree\-pta\fR" 4
+.IX Item "-ftree-pta"
+Perform function-local points-to analysis on trees.  This flag is
+enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-sra\fR" 4
+.IX Item "-ftree-sra"
+Perform scalar replacement of aggregates.  This pass replaces structure
+references with scalars to prevent committing structures to memory too
+early.  This flag is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-copyrename\fR" 4
+.IX Item "-ftree-copyrename"
+Perform copy renaming on trees.  This pass attempts to rename compiler
+temporaries to other variables at copy locations, usually resulting in
+variable names which more closely resemble the original variables.  This flag
+is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-coalesce\-inlined\-vars\fR" 4
+.IX Item "-ftree-coalesce-inlined-vars"
+Tell the copyrename pass (see \fB\-ftree\-copyrename\fR) to attempt to
+combine small user-defined variables too, but only if they were inlined
+from other functions.  It is a more limited form of
+\&\fB\-ftree\-coalesce\-vars\fR.  This may harm debug information of such
+inlined variables, but it will keep variables of the inlined-into
+function apart from each other, such that they are more likely to
+contain the expected values in a debugging session.  This was the
+default in \s-1GCC\s0 versions older than 4.7.
+.IP "\fB\-ftree\-coalesce\-vars\fR" 4
+.IX Item "-ftree-coalesce-vars"
+Tell the copyrename pass (see \fB\-ftree\-copyrename\fR) to attempt to
+combine small user-defined variables too, instead of just compiler
+temporaries.  This may severely limit the ability to debug an optimized
+program compiled with \fB\-fno\-var\-tracking\-assignments\fR.  In the
+negated form, this flag prevents \s-1SSA\s0 coalescing of user variables,
+including inlined ones.  This option is enabled by default.
+.IP "\fB\-ftree\-ter\fR" 4
+.IX Item "-ftree-ter"
+Perform temporary expression replacement during the \s-1SSA\-\s0>normal phase.  Single
+use/single def temporaries are replaced at their use location with their
+defining expression.  This results in non-GIMPLE code, but gives the expanders
+much more complex trees to work on resulting in better \s-1RTL\s0 generation.  This is
+enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-slsr\fR" 4
+.IX Item "-ftree-slsr"
+Perform straight-line strength reduction on trees.  This recognizes related
+expressions involving multiplications and replaces them by less expensive
+calculations when possible.  This is enabled by default at \fB\-O\fR and
+higher.
+.IP "\fB\-ftree\-vectorize\fR" 4
+.IX Item "-ftree-vectorize"
+Perform vectorization on trees. This flag enables \fB\-ftree\-loop\-vectorize\fR
+and \fB\-ftree\-slp\-vectorize\fR if not explicitly specified.
+.IP "\fB\-ftree\-loop\-vectorize\fR" 4
+.IX Item "-ftree-loop-vectorize"
+Perform loop vectorization on trees. This flag is enabled by default at
+\&\fB\-O3\fR and when \fB\-ftree\-vectorize\fR is enabled.
+.IP "\fB\-ftree\-slp\-vectorize\fR" 4
+.IX Item "-ftree-slp-vectorize"
+Perform basic block vectorization on trees. This flag is enabled by default at
+\&\fB\-O3\fR and when \fB\-ftree\-vectorize\fR is enabled.
+.IP "\fB\-fvect\-cost\-model=\fR\fImodel\fR" 4
+.IX Item "-fvect-cost-model=model"
+Alter the cost model used for vectorization.  The \fImodel\fR argument
+should be one of \f(CW\*(C`unlimited\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR or \f(CW\*(C`cheap\*(C'\fR.
+With the \f(CW\*(C`unlimited\*(C'\fR model the vectorized code-path is assumed
+to be profitable while with the \f(CW\*(C`dynamic\*(C'\fR model a runtime check
+will guard the vectorized code-path to enable it only for iteration
+counts that will likely execute faster than when executing the original
+scalar loop.  The \f(CW\*(C`cheap\*(C'\fR model will disable vectorization of
+loops where doing so would be cost prohibitive for example due to
+required runtime checks for data dependence or alignment but otherwise
+is equal to the \f(CW\*(C`dynamic\*(C'\fR model.
+The default cost model depends on other optimization flags and is
+either \f(CW\*(C`dynamic\*(C'\fR or \f(CW\*(C`cheap\*(C'\fR.
+.IP "\fB\-fsimd\-cost\-model=\fR\fImodel\fR" 4
+.IX Item "-fsimd-cost-model=model"
+Alter the cost model used for vectorization of loops marked with the OpenMP
+or Cilk Plus simd directive.  The \fImodel\fR argument should be one of
+\&\f(CW\*(C`unlimited\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`cheap\*(C'\fR.  All values of \fImodel\fR
+have the same meaning as described in \fB\-fvect\-cost\-model\fR and by
+default a cost model defined with \fB\-fvect\-cost\-model\fR is used.
+.IP "\fB\-ftree\-vrp\fR" 4
+.IX Item "-ftree-vrp"
+Perform Value Range Propagation on trees.  This is similar to the
+constant propagation pass, but instead of values, ranges of values are
+propagated.  This allows the optimizers to remove unnecessary range
+checks like array bound checks and null pointer checks.  This is
+enabled by default at \fB\-O2\fR and higher.  Null pointer check
+elimination is only done if \fB\-fdelete\-null\-pointer\-checks\fR is
+enabled.
+.IP "\fB\-ftracer\fR" 4
+.IX Item "-ftracer"
+Perform tail duplication to enlarge superblock size.  This transformation
+simplifies the control flow of the function allowing other optimizations to do
+a better job.
+.IP "\fB\-funroll\-loops\fR" 4
+.IX Item "-funroll-loops"
+Unroll loops whose number of iterations can be determined at compile
+time or upon entry to the loop.  \fB\-funroll\-loops\fR implies
+\&\fB\-frerun\-cse\-after\-loop\fR.  This option makes code larger,
+and may or may not make it run faster.
+.IP "\fB\-funroll\-all\-loops\fR" 4
+.IX Item "-funroll-all-loops"
+Unroll all loops, even if their number of iterations is uncertain when
+the loop is entered.  This usually makes programs run more slowly.
+\&\fB\-funroll\-all\-loops\fR implies the same options as
+\&\fB\-funroll\-loops\fR,
+.IP "\fB\-fsplit\-ivs\-in\-unroller\fR" 4
+.IX Item "-fsplit-ivs-in-unroller"
+Enables expression of values of induction variables in later iterations
+of the unrolled loop using the value in the first iteration.  This breaks
+long dependency chains, thus improving efficiency of the scheduling passes.
+.Sp
+A combination of \fB\-fweb\fR and \s-1CSE\s0 is often sufficient to obtain the
+same effect.  However, that is not reliable in cases where the loop body
+is more complicated than a single basic block.  It also does not work at all
+on some architectures due to restrictions in the \s-1CSE\s0 pass.
+.Sp
+This optimization is enabled by default.
+.IP "\fB\-fvariable\-expansion\-in\-unroller\fR" 4
+.IX Item "-fvariable-expansion-in-unroller"
+With this option, the compiler creates multiple copies of some
+local variables when unrolling a loop, which can result in superior code.
+.IP "\fB\-fpartial\-inlining\fR" 4
+.IX Item "-fpartial-inlining"
+Inline parts of functions.  This option has any effect only
+when inlining itself is turned on by the \fB\-finline\-functions\fR
+or \fB\-finline\-small\-functions\fR options.
+.Sp
+Enabled at level \fB\-O2\fR.
+.IP "\fB\-fpredictive\-commoning\fR" 4
+.IX Item "-fpredictive-commoning"
+Perform predictive commoning optimization, i.e., reusing computations
+(especially memory loads and stores) performed in previous
+iterations of loops.
+.Sp
+This option is enabled at level \fB\-O3\fR.
+.IP "\fB\-fprefetch\-loop\-arrays\fR" 4
+.IX Item "-fprefetch-loop-arrays"
+If supported by the target machine, generate instructions to prefetch
+memory to improve the performance of loops that access large arrays.
+.Sp
+This option may generate better or worse code; results are highly
+dependent on the structure of loops within the source code.
+.Sp
+Disabled at level \fB\-Os\fR.
+.IP "\fB\-fno\-peephole\fR" 4
+.IX Item "-fno-peephole"
+.PD 0
+.IP "\fB\-fno\-peephole2\fR" 4
+.IX Item "-fno-peephole2"
+.PD
+Disable any machine-specific peephole optimizations.  The difference
+between \fB\-fno\-peephole\fR and \fB\-fno\-peephole2\fR is in how they
+are implemented in the compiler; some targets use one, some use the
+other, a few use both.
+.Sp
+\&\fB\-fpeephole\fR is enabled by default.
+\&\fB\-fpeephole2\fR enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fno\-guess\-branch\-probability\fR" 4
+.IX Item "-fno-guess-branch-probability"
+Do not guess branch probabilities using heuristics.
+.Sp
+\&\s-1GCC\s0 uses heuristics to guess branch probabilities if they are
+not provided by profiling feedback (\fB\-fprofile\-arcs\fR).  These
+heuristics are based on the control flow graph.  If some branch probabilities
+are specified by \fB_\|_builtin_expect\fR, then the heuristics are
+used to guess branch probabilities for the rest of the control flow graph,
+taking the \fB_\|_builtin_expect\fR info into account.  The interactions
+between the heuristics and \fB_\|_builtin_expect\fR can be complex, and in
+some cases, it may be useful to disable the heuristics so that the effects
+of \fB_\|_builtin_expect\fR are easier to understand.
+.Sp
+The default is \fB\-fguess\-branch\-probability\fR at levels
+\&\fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-freorder\-blocks\fR" 4
+.IX Item "-freorder-blocks"
+Reorder basic blocks in the compiled function in order to reduce number of
+taken branches and improve code locality.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-freorder\-blocks\-and\-partition\fR" 4
+.IX Item "-freorder-blocks-and-partition"
+In addition to reordering basic blocks in the compiled function, in order
+to reduce number of taken branches, partitions hot and cold basic blocks
+into separate sections of the assembly and .o files, to improve
+paging and cache locality performance.
+.Sp
+This optimization is automatically turned off in the presence of
+exception handling, for linkonce sections, for functions with a user-defined
+section attribute and on any architecture that does not support named
+sections.
+.Sp
+Enabled for x86 at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-freorder\-functions\fR" 4
+.IX Item "-freorder-functions"
+Reorder functions in the object file in order to
+improve code locality.  This is implemented by using special
+subsections \f(CW\*(C`.text.hot\*(C'\fR for most frequently executed functions and
+\&\f(CW\*(C`.text.unlikely\*(C'\fR for unlikely executed functions.  Reordering is done by
+the linker so object file format must support named sections and linker must
+place them in a reasonable way.
+.Sp
+Also profile feedback must be available to make this option effective.  See
+\&\fB\-fprofile\-arcs\fR for details.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fstrict\-aliasing\fR" 4
+.IX Item "-fstrict-aliasing"
+Allow the compiler to assume the strictest aliasing rules applicable to
+the language being compiled.  For C (and \*(C+), this activates
+optimizations based on the type of expressions.  In particular, an
+object of one type is assumed never to reside at the same address as an
+object of a different type, unless the types are almost the same.  For
+example, an \f(CW\*(C`unsigned int\*(C'\fR can alias an \f(CW\*(C`int\*(C'\fR, but not a
+\&\f(CW\*(C`void*\*(C'\fR or a \f(CW\*(C`double\*(C'\fR.  A character type may alias any other
+type.
+.Sp
+Pay special attention to code like this:
+.Sp
+.Vb 4
+\&        union a_union {
+\&          int i;
+\&          double d;
+\&        };
+\&        
+\&        int f() {
+\&          union a_union t;
+\&          t.d = 3.0;
+\&          return t.i;
+\&        }
+.Ve
+.Sp
+The practice of reading from a different union member than the one most
+recently written to (called \*(L"type-punning\*(R") is common.  Even with
+\&\fB\-fstrict\-aliasing\fR, type-punning is allowed, provided the memory
+is accessed through the union type.  So, the code above works as
+expected.    However, this code might not:
+.Sp
+.Vb 7
+\&        int f() {
+\&          union a_union t;
+\&          int* ip;
+\&          t.d = 3.0;
+\&          ip = &t.i;
+\&          return *ip;
+\&        }
+.Ve
+.Sp
+Similarly, access by taking the address, casting the resulting pointer
+and dereferencing the result has undefined behavior, even if the cast
+uses a union type, e.g.:
+.Sp
+.Vb 4
+\&        int f() {
+\&          double d = 3.0;
+\&          return ((union a_union *) &d)\->i;
+\&        }
+.Ve
+.Sp
+The \fB\-fstrict\-aliasing\fR option is enabled at levels
+\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fstrict\-overflow\fR" 4
+.IX Item "-fstrict-overflow"
+Allow the compiler to assume strict signed overflow rules, depending
+on the language being compiled.  For C (and \*(C+) this means that
+overflow when doing arithmetic with signed numbers is undefined, which
+means that the compiler may assume that it does not happen.  This
+permits various optimizations.  For example, the compiler assumes
+that an expression like \f(CW\*(C`i + 10 > i\*(C'\fR is always true for
+signed \f(CW\*(C`i\*(C'\fR.  This assumption is only valid if signed overflow is
+undefined, as the expression is false if \f(CW\*(C`i + 10\*(C'\fR overflows when
+using twos complement arithmetic.  When this option is in effect any
+attempt to determine whether an operation on signed numbers 
+overflows must be written carefully to not actually involve overflow.
+.Sp
+This option also allows the compiler to assume strict pointer
+semantics: given a pointer to an object, if adding an offset to that
+pointer does not produce a pointer to the same object, the addition is
+undefined.  This permits the compiler to conclude that \f(CW\*(C`p + u >
+p\*(C'\fR is always true for a pointer \f(CW\*(C`p\*(C'\fR and unsigned integer
+\&\f(CW\*(C`u\*(C'\fR.  This assumption is only valid because pointer wraparound is
+undefined, as the expression is false if \f(CW\*(C`p + u\*(C'\fR overflows using
+twos complement arithmetic.
+.Sp
+See also the \fB\-fwrapv\fR option.  Using \fB\-fwrapv\fR means
+that integer signed overflow is fully defined: it wraps.  When
+\&\fB\-fwrapv\fR is used, there is no difference between
+\&\fB\-fstrict\-overflow\fR and \fB\-fno\-strict\-overflow\fR for
+integers.  With \fB\-fwrapv\fR certain types of overflow are
+permitted.  For example, if the compiler gets an overflow when doing
+arithmetic on constants, the overflowed value can still be used with
+\&\fB\-fwrapv\fR, but not otherwise.
+.Sp
+The \fB\-fstrict\-overflow\fR option is enabled at levels
+\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-falign\-functions\fR" 4
+.IX Item "-falign-functions"
+.PD 0
+.IP "\fB\-falign\-functions=\fR\fIn\fR" 4
+.IX Item "-falign-functions=n"
+.PD
+Align the start of functions to the next power-of-two greater than
+\&\fIn\fR, skipping up to \fIn\fR bytes.  For instance,
+\&\fB\-falign\-functions=32\fR aligns functions to the next 32\-byte
+boundary, but \fB\-falign\-functions=24\fR aligns to the next
+32\-byte boundary only if this can be done by skipping 23 bytes or less.
+.Sp
+\&\fB\-fno\-align\-functions\fR and \fB\-falign\-functions=1\fR are
+equivalent and mean that functions are not aligned.
+.Sp
+Some assemblers only support this flag when \fIn\fR is a power of two;
+in that case, it is rounded up.
+.Sp
+If \fIn\fR is not specified or is zero, use a machine-dependent default.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-falign\-labels\fR" 4
+.IX Item "-falign-labels"
+.PD 0
+.IP "\fB\-falign\-labels=\fR\fIn\fR" 4
+.IX Item "-falign-labels=n"
+.PD
+Align all branch targets to a power-of-two boundary, skipping up to
+\&\fIn\fR bytes like \fB\-falign\-functions\fR.  This option can easily
+make code slower, because it must insert dummy operations for when the
+branch target is reached in the usual flow of the code.
+.Sp
+\&\fB\-fno\-align\-labels\fR and \fB\-falign\-labels=1\fR are
+equivalent and mean that labels are not aligned.
+.Sp
+If \fB\-falign\-loops\fR or \fB\-falign\-jumps\fR are applicable and
+are greater than this value, then their values are used instead.
+.Sp
+If \fIn\fR is not specified or is zero, use a machine-dependent default
+which is very likely to be \fB1\fR, meaning no alignment.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-falign\-loops\fR" 4
+.IX Item "-falign-loops"
+.PD 0
+.IP "\fB\-falign\-loops=\fR\fIn\fR" 4
+.IX Item "-falign-loops=n"
+.PD
+Align loops to a power-of-two boundary, skipping up to \fIn\fR bytes
+like \fB\-falign\-functions\fR.  If the loops are
+executed many times, this makes up for any execution of the dummy
+operations.
+.Sp
+\&\fB\-fno\-align\-loops\fR and \fB\-falign\-loops=1\fR are
+equivalent and mean that loops are not aligned.
+.Sp
+If \fIn\fR is not specified or is zero, use a machine-dependent default.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-falign\-jumps\fR" 4
+.IX Item "-falign-jumps"
+.PD 0
+.IP "\fB\-falign\-jumps=\fR\fIn\fR" 4
+.IX Item "-falign-jumps=n"
+.PD
+Align branch targets to a power-of-two boundary, for branch targets
+where the targets can only be reached by jumping, skipping up to \fIn\fR
+bytes like \fB\-falign\-functions\fR.  In this case, no dummy operations
+need be executed.
+.Sp
+\&\fB\-fno\-align\-jumps\fR and \fB\-falign\-jumps=1\fR are
+equivalent and mean that loops are not aligned.
+.Sp
+If \fIn\fR is not specified or is zero, use a machine-dependent default.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-funit\-at\-a\-time\fR" 4
+.IX Item "-funit-at-a-time"
+This option is left for compatibility reasons. \fB\-funit\-at\-a\-time\fR
+has no effect, while \fB\-fno\-unit\-at\-a\-time\fR implies
+\&\fB\-fno\-toplevel\-reorder\fR and \fB\-fno\-section\-anchors\fR.
+.Sp
+Enabled by default.
+.IP "\fB\-fno\-toplevel\-reorder\fR" 4
+.IX Item "-fno-toplevel-reorder"
+Do not reorder top-level functions, variables, and \f(CW\*(C`asm\*(C'\fR
+statements.  Output them in the same order that they appear in the
+input file.  When this option is used, unreferenced static variables
+are not removed.  This option is intended to support existing code
+that relies on a particular ordering.  For new code, it is better to
+use attributes when possible.
+.Sp
+Enabled at level \fB\-O0\fR.  When disabled explicitly, it also implies
+\&\fB\-fno\-section\-anchors\fR, which is otherwise enabled at \fB\-O0\fR on some
+targets.
+.IP "\fB\-fweb\fR" 4
+.IX Item "-fweb"
+Constructs webs as commonly used for register allocation purposes and assign
+each web individual pseudo register.  This allows the register allocation pass
+to operate on pseudos directly, but also strengthens several other optimization
+passes, such as \s-1CSE,\s0 loop optimizer and trivial dead code remover.  It can,
+however, make debugging impossible, since variables no longer stay in a
+\&\*(L"home register\*(R".
+.Sp
+Enabled by default with \fB\-funroll\-loops\fR.
+.IP "\fB\-fwhole\-program\fR" 4
+.IX Item "-fwhole-program"
+Assume that the current compilation unit represents the whole program being
+compiled.  All public functions and variables with the exception of \f(CW\*(C`main\*(C'\fR
+and those merged by attribute \f(CW\*(C`externally_visible\*(C'\fR become static functions
+and in effect are optimized more aggressively by interprocedural optimizers.
+.Sp
+This option should not be used in combination with \f(CW\*(C`\-flto\*(C'\fR.
+Instead relying on a linker plugin should provide safer and more precise
+information.
+.IP "\fB\-flto[=\fR\fIn\fR\fB]\fR" 4
+.IX Item "-flto[=n]"
+This option runs the standard link-time optimizer.  When invoked
+with source code, it generates \s-1GIMPLE \s0(one of \s-1GCC\s0's internal
+representations) and writes it to special \s-1ELF\s0 sections in the object
+file.  When the object files are linked together, all the function
+bodies are read from these \s-1ELF\s0 sections and instantiated as if they
+had been part of the same translation unit.
+.Sp
+To use the link-time optimizer, \fB\-flto\fR and optimization
+options should be specified at compile time and during the final link.
+For example:
+.Sp
+.Vb 3
+\&        gcc \-c \-O2 \-flto foo.c
+\&        gcc \-c \-O2 \-flto bar.c
+\&        gcc \-o myprog \-flto \-O2 foo.o bar.o
+.Ve
+.Sp
+The first two invocations to \s-1GCC\s0 save a bytecode representation
+of \s-1GIMPLE\s0 into special \s-1ELF\s0 sections inside \fIfoo.o\fR and
+\&\fIbar.o\fR.  The final invocation reads the \s-1GIMPLE\s0 bytecode from
+\&\fIfoo.o\fR and \fIbar.o\fR, merges the two files into a single
+internal image, and compiles the result as usual.  Since both
+\&\fIfoo.o\fR and \fIbar.o\fR are merged into a single image, this
+causes all the interprocedural analyses and optimizations in \s-1GCC\s0 to
+work across the two files as if they were a single one.  This means,
+for example, that the inliner is able to inline functions in
+\&\fIbar.o\fR into functions in \fIfoo.o\fR and vice-versa.
+.Sp
+Another (simpler) way to enable link-time optimization is:
+.Sp
+.Vb 1
+\&        gcc \-o myprog \-flto \-O2 foo.c bar.c
+.Ve
+.Sp
+The above generates bytecode for \fIfoo.c\fR and \fIbar.c\fR,
+merges them together into a single \s-1GIMPLE\s0 representation and optimizes
+them as usual to produce \fImyprog\fR.
+.Sp
+The only important thing to keep in mind is that to enable link-time
+optimizations you need to use the \s-1GCC\s0 driver to perform the link-step.
+\&\s-1GCC\s0 then automatically performs link-time optimization if any of the
+objects involved were compiled with the \fB\-flto\fR.  You generally
+should specify the optimization options to be used for link-time
+optimization though \s-1GCC\s0 will try to be clever at guessing an
+optimization level to use from the options used at compile-time
+if you fail to specify one at link-time.  You can always override
+the automatic decision to do link-time optimization at link-time
+by passing \fB\-fno\-lto\fR to the link command.
+.Sp
+To make whole program optimization effective, it is necessary to make
+certain whole program assumptions.  The compiler needs to know
+what functions and variables can be accessed by libraries and runtime
+outside of the link-time optimized unit.  When supported by the linker,
+the linker plugin (see \fB\-fuse\-linker\-plugin\fR) passes information
+to the compiler about used and externally visible symbols.  When
+the linker plugin is not available, \fB\-fwhole\-program\fR should be
+used to allow the compiler to make these assumptions, which leads
+to more aggressive optimization decisions.
+.Sp
+When \fB\-fuse\-linker\-plugin\fR is not enabled then, when a file is
+compiled with \fB\-flto\fR, the generated object file is larger than
+a regular object file because it contains \s-1GIMPLE\s0 bytecodes and the usual
+final code (see \fB\-ffat\-lto\-objects\fR.  This means that
+object files with \s-1LTO\s0 information can be linked as normal object
+files; if \fB\-fno\-lto\fR is passed to the linker, no
+interprocedural optimizations are applied.  Note that when
+\&\fB\-fno\-fat\-lto\-objects\fR is enabled the compile-stage is faster
+but you cannot perform a regular, non-LTO link on them.
+.Sp
+Additionally, the optimization flags used to compile individual files
+are not necessarily related to those used at link time.  For instance,
+.Sp
+.Vb 3
+\&        gcc \-c \-O0 \-ffat\-lto\-objects \-flto foo.c
+\&        gcc \-c \-O0 \-ffat\-lto\-objects \-flto bar.c
+\&        gcc \-o myprog \-O3 foo.o bar.o
+.Ve
+.Sp
+This produces individual object files with unoptimized assembler
+code, but the resulting binary \fImyprog\fR is optimized at
+\&\fB\-O3\fR.  If, instead, the final binary is generated with
+\&\fB\-fno\-lto\fR, then \fImyprog\fR is not optimized.
+.Sp
+When producing the final binary, \s-1GCC\s0 only
+applies link-time optimizations to those files that contain bytecode.
+Therefore, you can mix and match object files and libraries with
+\&\s-1GIMPLE\s0 bytecodes and final object code.  \s-1GCC\s0 automatically selects
+which files to optimize in \s-1LTO\s0 mode and which files to link without
+further processing.
+.Sp
+There are some code generation flags preserved by \s-1GCC\s0 when
+generating bytecodes, as they need to be used during the final link
+stage.  Generally options specified at link-time override those
+specified at compile-time.
+.Sp
+If you do not specify an optimization level option \fB\-O\fR at
+link-time then \s-1GCC\s0 will compute one based on the optimization levels
+used when compiling the object files.  The highest optimization
+level will win here.
+.Sp
+Currently, the following options and their setting are take from
+the first object file that explicitely specified it: 
+\&\fB\-fPIC\fR, \fB\-fpic\fR, \fB\-fpie\fR, \fB\-fcommon\fR,
+\&\fB\-fexceptions\fR, \fB\-fnon\-call\-exceptions\fR, \fB\-fgnu\-tm\fR
+and all the \fB\-m\fR target flags.
+.Sp
+Certain \s-1ABI\s0 changing flags are required to match in all compilation-units
+and trying to override this at link-time with a conflicting value
+is ignored.  This includes options such as \fB\-freg\-struct\-return\fR
+and \fB\-fpcc\-struct\-return\fR.
+.Sp
+Other options such as \fB\-ffp\-contract\fR, \fB\-fno\-strict\-overflow\fR,
+\&\fB\-fwrapv\fR, \fB\-fno\-trapv\fR or \fB\-fno\-strict\-aliasing\fR
+are passed through to the link stage and merged conservatively for
+conflicting translation units.  Specifically
+\&\fB\-fno\-strict\-overflow\fR, \fB\-fwrapv\fR and \fB\-fno\-trapv\fR take
+precedence and for example \fB\-ffp\-contract=off\fR takes precedence
+over \fB\-ffp\-contract=fast\fR.  You can override them at linke-time.
+.Sp
+It is recommended that you compile all the files participating in the
+same link with the same options and also specify those options at
+link time.
+.Sp
+If \s-1LTO\s0 encounters objects with C linkage declared with incompatible
+types in separate translation units to be linked together (undefined
+behavior according to \s-1ISO C99 6.2.7\s0), a non-fatal diagnostic may be
+issued.  The behavior is still undefined at run time.  Similar
+diagnostics may be raised for other languages.
+.Sp
+Another feature of \s-1LTO\s0 is that it is possible to apply interprocedural
+optimizations on files written in different languages:
+.Sp
+.Vb 4
+\&        gcc \-c \-flto foo.c
+\&        g++ \-c \-flto bar.cc
+\&        gfortran \-c \-flto baz.f90
+\&        g++ \-o myprog \-flto \-O3 foo.o bar.o baz.o \-lgfortran
+.Ve
+.Sp
+Notice that the final link is done with \fBg++\fR to get the \*(C+
+runtime libraries and \fB\-lgfortran\fR is added to get the Fortran
+runtime libraries.  In general, when mixing languages in \s-1LTO\s0 mode, you
+should use the same link command options as when mixing languages in a
+regular (non-LTO) compilation.
+.Sp
+If object files containing \s-1GIMPLE\s0 bytecode are stored in a library archive, say
+\&\fIlibfoo.a\fR, it is possible to extract and use them in an \s-1LTO\s0 link if you
+are using a linker with plugin support.  To create static libraries suitable
+for \s-1LTO,\s0 use \fBgcc-ar\fR and \fBgcc-ranlib\fR instead of \fBar\fR
+and \f(CW\*(C`ranlib\*(C'\fR; to show the symbols of object files with \s-1GIMPLE\s0 bytecode, use
+\&\fBgcc-nm\fR.  Those commands require that \fBar\fR, \fBranlib\fR
+and \fBnm\fR have been compiled with plugin support.  At link time, use the the
+flag \fB\-fuse\-linker\-plugin\fR to ensure that the library participates in
+the \s-1LTO\s0 optimization process:
+.Sp
+.Vb 1
+\&        gcc \-o myprog \-O2 \-flto \-fuse\-linker\-plugin a.o b.o \-lfoo
+.Ve
+.Sp
+With the linker plugin enabled, the linker extracts the needed
+\&\s-1GIMPLE\s0 files from \fIlibfoo.a\fR and passes them on to the running \s-1GCC\s0
+to make them part of the aggregated \s-1GIMPLE\s0 image to be optimized.
+.Sp
+If you are not using a linker with plugin support and/or do not
+enable the linker plugin, then the objects inside \fIlibfoo.a\fR
+are extracted and linked as usual, but they do not participate
+in the \s-1LTO\s0 optimization process.  In order to make a static library suitable
+for both \s-1LTO\s0 optimization and usual linkage, compile its object files with
+\&\fB\-flto\fR \f(CW\*(C`\-ffat\-lto\-objects\*(C'\fR.
+.Sp
+Link-time optimizations do not require the presence of the whole program to
+operate.  If the program does not require any symbols to be exported, it is
+possible to combine \fB\-flto\fR and \fB\-fwhole\-program\fR to allow
+the interprocedural optimizers to use more aggressive assumptions which may
+lead to improved optimization opportunities.
+Use of \fB\-fwhole\-program\fR is not needed when linker plugin is
+active (see \fB\-fuse\-linker\-plugin\fR).
+.Sp
+The current implementation of \s-1LTO\s0 makes no
+attempt to generate bytecode that is portable between different
+types of hosts.  The bytecode files are versioned and there is a
+strict version check, so bytecode files generated in one version of
+\&\s-1GCC\s0 will not work with an older or newer version of \s-1GCC.\s0
+.Sp
+Link-time optimization does not work well with generation of debugging
+information.  Combining \fB\-flto\fR with
+\&\fB\-g\fR is currently experimental and expected to produce unexpected
+results.
+.Sp
+If you specify the optional \fIn\fR, the optimization and code
+generation done at link time is executed in parallel using \fIn\fR
+parallel jobs by utilizing an installed \fBmake\fR program.  The
+environment variable \fB\s-1MAKE\s0\fR may be used to override the program
+used.  The default value for \fIn\fR is 1.
+.Sp
+You can also specify \fB\-flto=jobserver\fR to use \s-1GNU\s0 make's
+job server mode to determine the number of parallel jobs. This
+is useful when the Makefile calling \s-1GCC\s0 is already executing in parallel.
+You must prepend a \fB+\fR to the command recipe in the parent Makefile
+for this to work.  This option likely only works if \fB\s-1MAKE\s0\fR is
+\&\s-1GNU\s0 make.
+.IP "\fB\-flto\-partition=\fR\fIalg\fR" 4
+.IX Item "-flto-partition=alg"
+Specify the partitioning algorithm used by the link-time optimizer.
+The value is either \f(CW\*(C`1to1\*(C'\fR to specify a partitioning mirroring
+the original source files or \f(CW\*(C`balanced\*(C'\fR to specify partitioning
+into equally sized chunks (whenever possible) or \f(CW\*(C`max\*(C'\fR to create
+new partition for every symbol where possible.  Specifying \f(CW\*(C`none\*(C'\fR
+as an algorithm disables partitioning and streaming completely. 
+The default value is \f(CW\*(C`balanced\*(C'\fR. While \f(CW\*(C`1to1\*(C'\fR can be used
+as an workaround for various code ordering issues, the \f(CW\*(C`max\*(C'\fR
+partitioning is intended for internal testing only.
+.IP "\fB\-flto\-compression\-level=\fR\fIn\fR" 4
+.IX Item "-flto-compression-level=n"
+This option specifies the level of compression used for intermediate
+language written to \s-1LTO\s0 object files, and is only meaningful in
+conjunction with \s-1LTO\s0 mode (\fB\-flto\fR).  Valid
+values are 0 (no compression) to 9 (maximum compression).  Values
+outside this range are clamped to either 0 or 9.  If the option is not
+given, a default balanced compression setting is used.
+.IP "\fB\-flto\-report\fR" 4
+.IX Item "-flto-report"
+Prints a report with internal details on the workings of the link-time
+optimizer.  The contents of this report vary from version to version.
+It is meant to be useful to \s-1GCC\s0 developers when processing object
+files in \s-1LTO\s0 mode (via \fB\-flto\fR).
+.Sp
+Disabled by default.
+.IP "\fB\-flto\-report\-wpa\fR" 4
+.IX Item "-flto-report-wpa"
+Like \fB\-flto\-report\fR, but only print for the \s-1WPA\s0 phase of Link
+Time Optimization.
+.IP "\fB\-fuse\-linker\-plugin\fR" 4
+.IX Item "-fuse-linker-plugin"
+Enables the use of a linker plugin during link-time optimization.  This
+option relies on plugin support in the linker, which is available in gold
+or in \s-1GNU\s0 ld 2.21 or newer.
+.Sp
+This option enables the extraction of object files with \s-1GIMPLE\s0 bytecode out
+of library archives. This improves the quality of optimization by exposing
+more code to the link-time optimizer.  This information specifies what
+symbols can be accessed externally (by non-LTO object or during dynamic
+linking).  Resulting code quality improvements on binaries (and shared
+libraries that use hidden visibility) are similar to \f(CW\*(C`\-fwhole\-program\*(C'\fR.
+See \fB\-flto\fR for a description of the effect of this flag and how to
+use it.
+.Sp
+This option is enabled by default when \s-1LTO\s0 support in \s-1GCC\s0 is enabled
+and \s-1GCC\s0 was configured for use with
+a linker supporting plugins (\s-1GNU\s0 ld 2.21 or newer or gold).
+.IP "\fB\-ffat\-lto\-objects\fR" 4
+.IX Item "-ffat-lto-objects"
+Fat \s-1LTO\s0 objects are object files that contain both the intermediate language
+and the object code. This makes them usable for both \s-1LTO\s0 linking and normal
+linking. This option is effective only when compiling with \fB\-flto\fR
+and is ignored at link time.
+.Sp
+\&\fB\-fno\-fat\-lto\-objects\fR improves compilation time over plain \s-1LTO,\s0 but
+requires the complete toolchain to be aware of \s-1LTO.\s0 It requires a linker with
+linker plugin support for basic functionality.  Additionally,
+\&\fBnm\fR, \fBar\fR and \fBranlib\fR
+need to support linker plugins to allow a full-featured build environment
+(capable of building static libraries etc).  \s-1GCC\s0 provides the \fBgcc-ar\fR,
+\&\fBgcc-nm\fR, \fBgcc-ranlib\fR wrappers to pass the right options
+to these tools. With non fat \s-1LTO\s0 makefiles need to be modified to use them.
+.Sp
+The default is \fB\-fno\-fat\-lto\-objects\fR on targets with linker plugin
+support.
+.IP "\fB\-fcompare\-elim\fR" 4
+.IX Item "-fcompare-elim"
+After register allocation and post-register allocation instruction splitting,
+identify arithmetic instructions that compute processor flags similar to a
+comparison operation based on that arithmetic.  If possible, eliminate the
+explicit comparison operation.
+.Sp
+This pass only applies to certain targets that cannot explicitly represent
+the comparison operation before register allocation is complete.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fuse\-ld=bfd\fR" 4
+.IX Item "-fuse-ld=bfd"
+Use the \fBbfd\fR linker instead of the default linker.
+.IP "\fB\-fuse\-ld=gold\fR" 4
+.IX Item "-fuse-ld=gold"
+Use the \fBgold\fR linker instead of the default linker.
+.IP "\fB\-fcprop\-registers\fR" 4
+.IX Item "-fcprop-registers"
+After register allocation and post-register allocation instruction splitting,
+perform a copy-propagation pass to try to reduce scheduling dependencies
+and occasionally eliminate the copy.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fprofile\-correction\fR" 4
+.IX Item "-fprofile-correction"
+Profiles collected using an instrumented binary for multi-threaded programs may
+be inconsistent due to missed counter updates. When this option is specified,
+\&\s-1GCC\s0 uses heuristics to correct or smooth out such inconsistencies. By
+default, \s-1GCC\s0 emits an error message when an inconsistent profile is detected.
+.IP "\fB\-fprofile\-dir=\fR\fIpath\fR" 4
+.IX Item "-fprofile-dir=path"
+Set the directory to search for the profile data files in to \fIpath\fR.
+This option affects only the profile data generated by
+\&\fB\-fprofile\-generate\fR, \fB\-ftest\-coverage\fR, \fB\-fprofile\-arcs\fR
+and used by \fB\-fprofile\-use\fR and \fB\-fbranch\-probabilities\fR
+and its related options.  Both absolute and relative paths can be used.
+By default, \s-1GCC\s0 uses the current directory as \fIpath\fR, thus the
+profile data file appears in the same directory as the object file.
+.IP "\fB\-fprofile\-generate\fR" 4
+.IX Item "-fprofile-generate"
+.PD 0
+.IP "\fB\-fprofile\-generate=\fR\fIpath\fR" 4
+.IX Item "-fprofile-generate=path"
+.PD
+Enable options usually used for instrumenting application to produce
+profile useful for later recompilation with profile feedback based
+optimization.  You must use \fB\-fprofile\-generate\fR both when
+compiling and when linking your program.
+.Sp
+The following options are enabled: \f(CW\*(C`\-fprofile\-arcs\*(C'\fR, \f(CW\*(C`\-fprofile\-values\*(C'\fR, \f(CW\*(C`\-fvpt\*(C'\fR.
+.Sp
+If \fIpath\fR is specified, \s-1GCC\s0 looks at the \fIpath\fR to find
+the profile feedback data files. See \fB\-fprofile\-dir\fR.
+.IP "\fB\-fprofile\-use\fR" 4
+.IX Item "-fprofile-use"
+.PD 0
+.IP "\fB\-fprofile\-use=\fR\fIpath\fR" 4
+.IX Item "-fprofile-use=path"
+.PD
+Enable profile feedback directed optimizations, and optimizations
+generally profitable only with profile feedback available.
+.Sp
+The following options are enabled: \f(CW\*(C`\-fbranch\-probabilities\*(C'\fR, \f(CW\*(C`\-fvpt\*(C'\fR,
+\&\f(CW\*(C`\-funroll\-loops\*(C'\fR, \f(CW\*(C`\-fpeel\-loops\*(C'\fR, \f(CW\*(C`\-ftracer\*(C'\fR, \f(CW\*(C`\-ftree\-vectorize\*(C'\fR,
+\&\f(CW\*(C`ftree\-loop\-distribute\-patterns\*(C'\fR
+.Sp
+By default, \s-1GCC\s0 emits an error message if the feedback profiles do not
+match the source code.  This error can be turned into a warning by using
+\&\fB\-Wcoverage\-mismatch\fR.  Note this may result in poorly optimized
+code.
+.Sp
+If \fIpath\fR is specified, \s-1GCC\s0 looks at the \fIpath\fR to find
+the profile feedback data files. See \fB\-fprofile\-dir\fR.
+.PP
+The following options control compiler behavior regarding floating-point 
+arithmetic.  These options trade off between speed and
+correctness.  All must be specifically enabled.
+.IP "\fB\-ffloat\-store\fR" 4
+.IX Item "-ffloat-store"
+Do not store floating-point variables in registers, and inhibit other
+options that might change whether a floating-point value is taken from a
+register or memory.
+.Sp
+This option prevents undesirable excess precision on machines such as
+the 68000 where the floating registers (of the 68881) keep more
+precision than a \f(CW\*(C`double\*(C'\fR is supposed to have.  Similarly for the
+x86 architecture.  For most programs, the excess precision does only
+good, but a few programs rely on the precise definition of \s-1IEEE\s0 floating
+point.  Use \fB\-ffloat\-store\fR for such programs, after modifying
+them to store all pertinent intermediate computations into variables.
+.IP "\fB\-fexcess\-precision=\fR\fIstyle\fR" 4
+.IX Item "-fexcess-precision=style"
+This option allows further control over excess precision on machines
+where floating-point registers have more precision than the \s-1IEEE
+\&\s0\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR types and the processor does not
+support operations rounding to those types.  By default,
+\&\fB\-fexcess\-precision=fast\fR is in effect; this means that
+operations are carried out in the precision of the registers and that
+it is unpredictable when rounding to the types specified in the source
+code takes place.  When compiling C, if
+\&\fB\-fexcess\-precision=standard\fR is specified then excess
+precision follows the rules specified in \s-1ISO C99\s0; in particular,
+both casts and assignments cause values to be rounded to their
+semantic types (whereas \fB\-ffloat\-store\fR only affects
+assignments).  This option is enabled by default for C if a strict
+conformance option such as \fB\-std=c99\fR is used.
+.Sp
+\&\fB\-fexcess\-precision=standard\fR is not implemented for languages
+other than C, and has no effect if
+\&\fB\-funsafe\-math\-optimizations\fR or \fB\-ffast\-math\fR is
+specified.  On the x86, it also has no effect if \fB\-mfpmath=sse\fR
+or \fB\-mfpmath=sse+387\fR is specified; in the former case, \s-1IEEE\s0
+semantics apply without excess precision, and in the latter, rounding
+is unpredictable.
+.IP "\fB\-ffast\-math\fR" 4
+.IX Item "-ffast-math"
+Sets \fB\-fno\-math\-errno\fR, \fB\-funsafe\-math\-optimizations\fR,
+\&\fB\-ffinite\-math\-only\fR, \fB\-fno\-rounding\-math\fR,
+\&\fB\-fno\-signaling\-nans\fR and \fB\-fcx\-limited\-range\fR.
+.Sp
+This option causes the preprocessor macro \f(CW\*(C`_\|_FAST_MATH_\|_\*(C'\fR to be defined.
+.Sp
+This option is not turned on by any \fB\-O\fR option besides
+\&\fB\-Ofast\fR since it can result in incorrect output for programs
+that depend on an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications
+for math functions. It may, however, yield faster code for programs
+that do not require the guarantees of these specifications.
+.IP "\fB\-fno\-math\-errno\fR" 4
+.IX Item "-fno-math-errno"
+Do not set \f(CW\*(C`errno\*(C'\fR after calling math functions that are executed
+with a single instruction, e.g., \f(CW\*(C`sqrt\*(C'\fR.  A program that relies on
+\&\s-1IEEE\s0 exceptions for math error handling may want to use this flag
+for speed while maintaining \s-1IEEE\s0 arithmetic compatibility.
+.Sp
+This option is not turned on by any \fB\-O\fR option since
+it can result in incorrect output for programs that depend on
+an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
+math functions. It may, however, yield faster code for programs
+that do not require the guarantees of these specifications.
+.Sp
+The default is \fB\-fmath\-errno\fR.
+.Sp
+On Darwin systems, the math library never sets \f(CW\*(C`errno\*(C'\fR.  There is
+therefore no reason for the compiler to consider the possibility that
+it might, and \fB\-fno\-math\-errno\fR is the default.
+.IP "\fB\-funsafe\-math\-optimizations\fR" 4
+.IX Item "-funsafe-math-optimizations"
+Allow optimizations for floating-point arithmetic that (a) assume
+that arguments and results are valid and (b) may violate \s-1IEEE\s0 or
+\&\s-1ANSI\s0 standards.  When used at link-time, it may include libraries
+or startup files that change the default \s-1FPU\s0 control word or other
+similar optimizations.
+.Sp
+This option is not turned on by any \fB\-O\fR option since
+it can result in incorrect output for programs that depend on
+an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
+math functions. It may, however, yield faster code for programs
+that do not require the guarantees of these specifications.
+Enables \fB\-fno\-signed\-zeros\fR, \fB\-fno\-trapping\-math\fR,
+\&\fB\-fassociative\-math\fR and \fB\-freciprocal\-math\fR.
+.Sp
+The default is \fB\-fno\-unsafe\-math\-optimizations\fR.
+.IP "\fB\-fassociative\-math\fR" 4
+.IX Item "-fassociative-math"
+Allow re-association of operands in series of floating-point operations.
+This violates the \s-1ISO C\s0 and \*(C+ language standard by possibly changing
+computation result.  \s-1NOTE:\s0 re-ordering may change the sign of zero as
+well as ignore NaNs and inhibit or create underflow or overflow (and
+thus cannot be used on code that relies on rounding behavior like
+\&\f(CW\*(C`(x + 2**52) \- 2**52\*(C'\fR.  May also reorder floating-point comparisons
+and thus may not be used when ordered comparisons are required.
+This option requires that both \fB\-fno\-signed\-zeros\fR and
+\&\fB\-fno\-trapping\-math\fR be in effect.  Moreover, it doesn't make
+much sense with \fB\-frounding\-math\fR. For Fortran the option
+is automatically enabled when both \fB\-fno\-signed\-zeros\fR and
+\&\fB\-fno\-trapping\-math\fR are in effect.
+.Sp
+The default is \fB\-fno\-associative\-math\fR.
+.IP "\fB\-freciprocal\-math\fR" 4
+.IX Item "-freciprocal-math"
+Allow the reciprocal of a value to be used instead of dividing by
+the value if this enables optimizations.  For example \f(CW\*(C`x / y\*(C'\fR
+can be replaced with \f(CW\*(C`x * (1/y)\*(C'\fR, which is useful if \f(CW\*(C`(1/y)\*(C'\fR
+is subject to common subexpression elimination.  Note that this loses
+precision and increases the number of flops operating on the value.
+.Sp
+The default is \fB\-fno\-reciprocal\-math\fR.
+.IP "\fB\-ffinite\-math\-only\fR" 4
+.IX Item "-ffinite-math-only"
+Allow optimizations for floating-point arithmetic that assume
+that arguments and results are not NaNs or +\-Infs.
+.Sp
+This option is not turned on by any \fB\-O\fR option since
+it can result in incorrect output for programs that depend on
+an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
+math functions. It may, however, yield faster code for programs
+that do not require the guarantees of these specifications.
+.Sp
+The default is \fB\-fno\-finite\-math\-only\fR.
+.IP "\fB\-fno\-signed\-zeros\fR" 4
+.IX Item "-fno-signed-zeros"
+Allow optimizations for floating-point arithmetic that ignore the
+signedness of zero.  \s-1IEEE\s0 arithmetic specifies the behavior of
+distinct +0.0 and \-0.0 values, which then prohibits simplification
+of expressions such as x+0.0 or 0.0*x (even with \fB\-ffinite\-math\-only\fR).
+This option implies that the sign of a zero result isn't significant.
+.Sp
+The default is \fB\-fsigned\-zeros\fR.
+.IP "\fB\-fno\-trapping\-math\fR" 4
+.IX Item "-fno-trapping-math"
+Compile code assuming that floating-point operations cannot generate
+user-visible traps.  These traps include division by zero, overflow,
+underflow, inexact result and invalid operation.  This option requires
+that \fB\-fno\-signaling\-nans\fR be in effect.  Setting this option may
+allow faster code if one relies on \*(L"non-stop\*(R" \s-1IEEE\s0 arithmetic, for example.
+.Sp
+This option should never be turned on by any \fB\-O\fR option since
+it can result in incorrect output for programs that depend on
+an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
+math functions.
+.Sp
+The default is \fB\-ftrapping\-math\fR.
+.IP "\fB\-frounding\-math\fR" 4
+.IX Item "-frounding-math"
+Disable transformations and optimizations that assume default floating-point
+rounding behavior.  This is round-to-zero for all floating point
+to integer conversions, and round-to-nearest for all other arithmetic
+truncations.  This option should be specified for programs that change
+the \s-1FP\s0 rounding mode dynamically, or that may be executed with a
+non-default rounding mode.  This option disables constant folding of
+floating-point expressions at compile time (which may be affected by
+rounding mode) and arithmetic transformations that are unsafe in the
+presence of sign-dependent rounding modes.
+.Sp
+The default is \fB\-fno\-rounding\-math\fR.
+.Sp
+This option is experimental and does not currently guarantee to
+disable all \s-1GCC\s0 optimizations that are affected by rounding mode.
+Future versions of \s-1GCC\s0 may provide finer control of this setting
+using C99's \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command-line option
+will be used to specify the default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
+.IP "\fB\-fsignaling\-nans\fR" 4
+.IX Item "-fsignaling-nans"
+Compile code assuming that \s-1IEEE\s0 signaling NaNs may generate user-visible
+traps during floating-point operations.  Setting this option disables
+optimizations that may change the number of exceptions visible with
+signaling NaNs.  This option implies \fB\-ftrapping\-math\fR.
+.Sp
+This option causes the preprocessor macro \f(CW\*(C`_\|_SUPPORT_SNAN_\|_\*(C'\fR to
+be defined.
+.Sp
+The default is \fB\-fno\-signaling\-nans\fR.
+.Sp
+This option is experimental and does not currently guarantee to
+disable all \s-1GCC\s0 optimizations that affect signaling NaN behavior.
+.IP "\fB\-fsingle\-precision\-constant\fR" 4
+.IX Item "-fsingle-precision-constant"
+Treat floating-point constants as single precision instead of
+implicitly converting them to double-precision constants.
+.IP "\fB\-fcx\-limited\-range\fR" 4
+.IX Item "-fcx-limited-range"
+When enabled, this option states that a range reduction step is not
+needed when performing complex division.  Also, there is no checking
+whether the result of a complex multiplication or division is \f(CW\*(C`NaN
++ I*NaN\*(C'\fR, with an attempt to rescue the situation in that case.  The
+default is \fB\-fno\-cx\-limited\-range\fR, but is enabled by
+\&\fB\-ffast\-math\fR.
+.Sp
+This option controls the default setting of the \s-1ISO C99
+\&\s0\f(CW\*(C`CX_LIMITED_RANGE\*(C'\fR pragma.  Nevertheless, the option applies to
+all languages.
+.IP "\fB\-fcx\-fortran\-rules\fR" 4
+.IX Item "-fcx-fortran-rules"
+Complex multiplication and division follow Fortran rules.  Range
+reduction is done as part of complex division, but there is no checking
+whether the result of a complex multiplication or division is \f(CW\*(C`NaN
++ I*NaN\*(C'\fR, with an attempt to rescue the situation in that case.
+.Sp
+The default is \fB\-fno\-cx\-fortran\-rules\fR.
+.PP
+The following options control optimizations that may improve
+performance, but are not enabled by any \fB\-O\fR options.  This
+section includes experimental options that may produce broken code.
+.IP "\fB\-fbranch\-probabilities\fR" 4
+.IX Item "-fbranch-probabilities"
+After running a program compiled with \fB\-fprofile\-arcs\fR, you can compile it a second time using
+\&\fB\-fbranch\-probabilities\fR, to improve optimizations based on
+the number of times each branch was taken.  When a program
+compiled with \fB\-fprofile\-arcs\fR exits, it saves arc execution
+counts to a file called \fI\fIsourcename\fI.gcda\fR for each source
+file.  The information in this data file is very dependent on the
+structure of the generated code, so you must use the same source code
+and the same optimization options for both compilations.
+.Sp
+With \fB\-fbranch\-probabilities\fR, \s-1GCC\s0 puts a
+\&\fB\s-1REG_BR_PROB\s0\fR note on each \fB\s-1JUMP_INSN\s0\fR and \fB\s-1CALL_INSN\s0\fR.
+These can be used to improve optimization.  Currently, they are only
+used in one place: in \fIreorg.c\fR, instead of guessing which path a
+branch is most likely to take, the \fB\s-1REG_BR_PROB\s0\fR values are used to
+exactly determine which path is taken more often.
+.IP "\fB\-fprofile\-values\fR" 4
+.IX Item "-fprofile-values"
+If combined with \fB\-fprofile\-arcs\fR, it adds code so that some
+data about values of expressions in the program is gathered.
+.Sp
+With \fB\-fbranch\-probabilities\fR, it reads back the data gathered
+from profiling values of expressions for usage in optimizations.
+.Sp
+Enabled with \fB\-fprofile\-generate\fR and \fB\-fprofile\-use\fR.
+.IP "\fB\-fprofile\-reorder\-functions\fR" 4
+.IX Item "-fprofile-reorder-functions"
+Function reordering based on profile instrumentation collects
+first time of execution of a function and orders these functions
+in ascending order.
+.Sp
+Enabled with \fB\-fprofile\-use\fR.
+.IP "\fB\-fvpt\fR" 4
+.IX Item "-fvpt"
+If combined with \fB\-fprofile\-arcs\fR, this option instructs the compiler
+to add code to gather information about values of expressions.
+.Sp
+With \fB\-fbranch\-probabilities\fR, it reads back the data gathered
+and actually performs the optimizations based on them.
+Currently the optimizations include specialization of division operations
+using the knowledge about the value of the denominator.
+.IP "\fB\-frename\-registers\fR" 4
+.IX Item "-frename-registers"
+Attempt to avoid false dependencies in scheduled code by making use
+of registers left over after register allocation.  This optimization
+most benefits processors with lots of registers.  Depending on the
+debug information format adopted by the target, however, it can
+make debugging impossible, since variables no longer stay in
+a \*(L"home register\*(R".
+.Sp
+Enabled by default with \fB\-funroll\-loops\fR and \fB\-fpeel\-loops\fR.
+.IP "\fB\-ftracer\fR" 4
+.IX Item "-ftracer"
+Perform tail duplication to enlarge superblock size.  This transformation
+simplifies the control flow of the function allowing other optimizations to do
+a better job.
+.Sp
+Enabled with \fB\-fprofile\-use\fR.
+.IP "\fB\-funroll\-loops\fR" 4
+.IX Item "-funroll-loops"
+Unroll loops whose number of iterations can be determined at compile time or
+upon entry to the loop.  \fB\-funroll\-loops\fR implies
+\&\fB\-frerun\-cse\-after\-loop\fR, \fB\-fweb\fR and \fB\-frename\-registers\fR.
+It also turns on complete loop peeling (i.e. complete removal of loops with
+a small constant number of iterations).  This option makes code larger, and may
+or may not make it run faster.
+.Sp
+Enabled with \fB\-fprofile\-use\fR.
+.IP "\fB\-funroll\-all\-loops\fR" 4
+.IX Item "-funroll-all-loops"
+Unroll all loops, even if their number of iterations is uncertain when
+the loop is entered.  This usually makes programs run more slowly.
+\&\fB\-funroll\-all\-loops\fR implies the same options as
+\&\fB\-funroll\-loops\fR.
+.IP "\fB\-fpeel\-loops\fR" 4
+.IX Item "-fpeel-loops"
+Peels loops for which there is enough information that they do not
+roll much (from profile feedback).  It also turns on complete loop peeling
+(i.e. complete removal of loops with small constant number of iterations).
+.Sp
+Enabled with \fB\-fprofile\-use\fR.
+.IP "\fB\-fmove\-loop\-invariants\fR" 4
+.IX Item "-fmove-loop-invariants"
+Enables the loop invariant motion pass in the \s-1RTL\s0 loop optimizer.  Enabled
+at level \fB\-O1\fR
+.IP "\fB\-funswitch\-loops\fR" 4
+.IX Item "-funswitch-loops"
+Move branches with loop invariant conditions out of the loop, with duplicates
+of the loop on both branches (modified according to result of the condition).
+.IP "\fB\-ffunction\-sections\fR" 4
+.IX Item "-ffunction-sections"
+.PD 0
+.IP "\fB\-fdata\-sections\fR" 4
+.IX Item "-fdata-sections"
+.PD
+Place each function or data item into its own section in the output
+file if the target supports arbitrary sections.  The name of the
+function or the name of the data item determines the section's name
+in the output file.
+.Sp
+Use these options on systems where the linker can perform optimizations
+to improve locality of reference in the instruction space.  Most systems
+using the \s-1ELF\s0 object format and \s-1SPARC\s0 processors running Solaris 2 have
+linkers with such optimizations.  \s-1AIX\s0 may have these optimizations in
+the future.
+.Sp
+Only use these options when there are significant benefits from doing
+so.  When you specify these options, the assembler and linker
+create larger object and executable files and are also slower.
+You cannot use \f(CW\*(C`gprof\*(C'\fR on all systems if you
+specify this option, and you may have problems with debugging if
+you specify both this option and \fB\-g\fR.
+.IP "\fB\-fbranch\-target\-load\-optimize\fR" 4
+.IX Item "-fbranch-target-load-optimize"
+Perform branch target register load optimization before prologue / epilogue
+threading.
+The use of target registers can typically be exposed only during reload,
+thus hoisting loads out of loops and doing inter-block scheduling needs
+a separate optimization pass.
+.IP "\fB\-fbranch\-target\-load\-optimize2\fR" 4
+.IX Item "-fbranch-target-load-optimize2"
+Perform branch target register load optimization after prologue / epilogue
+threading.
+.IP "\fB\-fbtr\-bb\-exclusive\fR" 4
+.IX Item "-fbtr-bb-exclusive"
+When performing branch target register load optimization, don't reuse
+branch target registers within any basic block.
+.IP "\fB\-fstack\-protector\fR" 4
+.IX Item "-fstack-protector"
+Emit extra code to check for buffer overflows, such as stack smashing
+attacks.  This is done by adding a guard variable to functions with
+vulnerable objects.  This includes functions that call \f(CW\*(C`alloca\*(C'\fR, and
+functions with buffers larger than 8 bytes.  The guards are initialized
+when a function is entered and then checked when the function exits.
+If a guard check fails, an error message is printed and the program exits.
+.IP "\fB\-fstack\-protector\-all\fR" 4
+.IX Item "-fstack-protector-all"
+Like \fB\-fstack\-protector\fR except that all functions are protected.
+.IP "\fB\-fstack\-protector\-strong\fR" 4
+.IX Item "-fstack-protector-strong"
+Like \fB\-fstack\-protector\fR but includes additional functions to
+be protected \-\-\- those that have local array definitions, or have
+references to local frame addresses.
+.IP "\fB\-fsection\-anchors\fR" 4
+.IX Item "-fsection-anchors"
+Try to reduce the number of symbolic address calculations by using
+shared \*(L"anchor\*(R" symbols to address nearby objects.  This transformation
+can help to reduce the number of \s-1GOT\s0 entries and \s-1GOT\s0 accesses on some
+targets.
+.Sp
+For example, the implementation of the following function \f(CW\*(C`foo\*(C'\fR:
+.Sp
+.Vb 2
+\&        static int a, b, c;
+\&        int foo (void) { return a + b + c; }
+.Ve
+.Sp
+usually calculates the addresses of all three variables, but if you
+compile it with \fB\-fsection\-anchors\fR, it accesses the variables
+from a common anchor point instead.  The effect is similar to the
+following pseudocode (which isn't valid C):
+.Sp
+.Vb 5
+\&        int foo (void)
+\&        {
+\&          register int *xr = &x;
+\&          return xr[&a \- &x] + xr[&b \- &x] + xr[&c \- &x];
+\&        }
+.Ve
+.Sp
+Not all targets support this option.
+.IP "\fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4
+.IX Item "--param name=value"
+In some places, \s-1GCC\s0 uses various constants to control the amount of
+optimization that is done.  For example, \s-1GCC\s0 does not inline functions
+that contain more than a certain number of instructions.  You can
+control some of these constants on the command line using the
+\&\fB\-\-param\fR option.
+.Sp
+The names of specific parameters, and the meaning of the values, are
+tied to the internals of the compiler, and are subject to change
+without notice in future releases.
+.Sp
+In each case, the \fIvalue\fR is an integer.  The allowable choices for
+\&\fIname\fR are:
+.RS 4
+.IP "\fBpredictable-branch-outcome\fR" 4
+.IX Item "predictable-branch-outcome"
+When branch is predicted to be taken with probability lower than this threshold
+(in percent), then it is considered well predictable. The default is 10.
+.IP "\fBmax-crossjump-edges\fR" 4
+.IX Item "max-crossjump-edges"
+The maximum number of incoming edges to consider for cross-jumping.
+The algorithm used by \fB\-fcrossjumping\fR is O(N^2) in
+the number of edges incoming to each block.  Increasing values mean
+more aggressive optimization, making the compilation time increase with
+probably small improvement in executable size.
+.IP "\fBmin-crossjump-insns\fR" 4
+.IX Item "min-crossjump-insns"
+The minimum number of instructions that must be matched at the end
+of two blocks before cross-jumping is performed on them.  This
+value is ignored in the case where all instructions in the block being
+cross-jumped from are matched.  The default value is 5.
+.IP "\fBmax-grow-copy-bb-insns\fR" 4
+.IX Item "max-grow-copy-bb-insns"
+The maximum code size expansion factor when copying basic blocks
+instead of jumping.  The expansion is relative to a jump instruction.
+The default value is 8.
+.IP "\fBmax-goto-duplication-insns\fR" 4
+.IX Item "max-goto-duplication-insns"
+The maximum number of instructions to duplicate to a block that jumps
+to a computed goto.  To avoid O(N^2) behavior in a number of
+passes, \s-1GCC\s0 factors computed gotos early in the compilation process,
+and unfactors them as late as possible.  Only computed jumps at the
+end of a basic blocks with no more than max-goto-duplication-insns are
+unfactored.  The default value is 8.
+.IP "\fBmax-delay-slot-insn-search\fR" 4
+.IX Item "max-delay-slot-insn-search"
+The maximum number of instructions to consider when looking for an
+instruction to fill a delay slot.  If more than this arbitrary number of
+instructions are searched, the time savings from filling the delay slot
+are minimal, so stop searching.  Increasing values mean more
+aggressive optimization, making the compilation time increase with probably
+small improvement in execution time.
+.IP "\fBmax-delay-slot-live-search\fR" 4
+.IX Item "max-delay-slot-live-search"
+When trying to fill delay slots, the maximum number of instructions to
+consider when searching for a block with valid live register
+information.  Increasing this arbitrarily chosen value means more
+aggressive optimization, increasing the compilation time.  This parameter
+should be removed when the delay slot code is rewritten to maintain the
+control-flow graph.
+.IP "\fBmax-gcse-memory\fR" 4
+.IX Item "max-gcse-memory"
+The approximate maximum amount of memory that can be allocated in
+order to perform the global common subexpression elimination
+optimization.  If more memory than specified is required, the
+optimization is not done.
+.IP "\fBmax-gcse-insertion-ratio\fR" 4
+.IX Item "max-gcse-insertion-ratio"
+If the ratio of expression insertions to deletions is larger than this value
+for any expression, then \s-1RTL PRE\s0 inserts or removes the expression and thus
+leaves partially redundant computations in the instruction stream.  The default value is 20.
+.IP "\fBmax-pending-list-length\fR" 4
+.IX Item "max-pending-list-length"
+The maximum number of pending dependencies scheduling allows
+before flushing the current state and starting over.  Large functions
+with few branches or calls can create excessively large lists which
+needlessly consume memory and resources.
+.IP "\fBmax-modulo-backtrack-attempts\fR" 4
+.IX Item "max-modulo-backtrack-attempts"
+The maximum number of backtrack attempts the scheduler should make
+when modulo scheduling a loop.  Larger values can exponentially increase
+compilation time.
+.IP "\fBmax-inline-insns-single\fR" 4
+.IX Item "max-inline-insns-single"
+Several parameters control the tree inliner used in \s-1GCC.\s0
+This number sets the maximum number of instructions (counted in \s-1GCC\s0's
+internal representation) in a single function that the tree inliner
+considers for inlining.  This only affects functions declared
+inline and methods implemented in a class declaration (\*(C+).
+The default value is 400.
+.IP "\fBmax-inline-insns-auto\fR" 4
+.IX Item "max-inline-insns-auto"
+When you use \fB\-finline\-functions\fR (included in \fB\-O3\fR),
+a lot of functions that would otherwise not be considered for inlining
+by the compiler are investigated.  To those functions, a different
+(more restrictive) limit compared to functions declared inline can
+be applied.
+The default value is 40.
+.IP "\fBinline-min-speedup\fR" 4
+.IX Item "inline-min-speedup"
+When estimated performance improvement of caller + callee runtime exceeds this
+threshold (in precent), the function can be inlined regardless the limit on
+\&\fB\-\-param max-inline-insns-single\fR and \fB\-\-param
+max-inline-insns-auto\fR.
+.IP "\fBlarge-function-insns\fR" 4
+.IX Item "large-function-insns"
+The limit specifying really large functions.  For functions larger than this
+limit after inlining, inlining is constrained by
+\&\fB\-\-param large-function-growth\fR.  This parameter is useful primarily
+to avoid extreme compilation time caused by non-linear algorithms used by the
+back end.
+The default value is 2700.
+.IP "\fBlarge-function-growth\fR" 4
+.IX Item "large-function-growth"
+Specifies maximal growth of large function caused by inlining in percents.
+The default value is 100 which limits large function growth to 2.0 times
+the original size.
+.IP "\fBlarge-unit-insns\fR" 4
+.IX Item "large-unit-insns"
+The limit specifying large translation unit.  Growth caused by inlining of
+units larger than this limit is limited by \fB\-\-param inline-unit-growth\fR.
+For small units this might be too tight.
+For example, consider a unit consisting of function A
+that is inline and B that just calls A three times.  If B is small relative to
+A, the growth of unit is 300\e% and yet such inlining is very sane.  For very
+large units consisting of small inlineable functions, however, the overall unit
+growth limit is needed to avoid exponential explosion of code size.  Thus for
+smaller units, the size is increased to \fB\-\-param large-unit-insns\fR
+before applying \fB\-\-param inline-unit-growth\fR.  The default is 10000.
+.IP "\fBinline-unit-growth\fR" 4
+.IX Item "inline-unit-growth"
+Specifies maximal overall growth of the compilation unit caused by inlining.
+The default value is 30 which limits unit growth to 1.3 times the original
+size.
+.IP "\fBipcp-unit-growth\fR" 4
+.IX Item "ipcp-unit-growth"
+Specifies maximal overall growth of the compilation unit caused by
+interprocedural constant propagation.  The default value is 10 which limits
+unit growth to 1.1 times the original size.
+.IP "\fBlarge-stack-frame\fR" 4
+.IX Item "large-stack-frame"
+The limit specifying large stack frames.  While inlining the algorithm is trying
+to not grow past this limit too much.  The default value is 256 bytes.
+.IP "\fBlarge-stack-frame-growth\fR" 4
+.IX Item "large-stack-frame-growth"
+Specifies maximal growth of large stack frames caused by inlining in percents.
+The default value is 1000 which limits large stack frame growth to 11 times
+the original size.
+.IP "\fBmax-inline-insns-recursive\fR" 4
+.IX Item "max-inline-insns-recursive"
+.PD 0
+.IP "\fBmax-inline-insns-recursive-auto\fR" 4
+.IX Item "max-inline-insns-recursive-auto"
+.PD
+Specifies the maximum number of instructions an out-of-line copy of a
+self-recursive inline
+function can grow into by performing recursive inlining.
+.Sp
+For functions declared inline, \fB\-\-param max-inline-insns-recursive\fR is
+taken into account.  For functions not declared inline, recursive inlining
+happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
+enabled and \fB\-\-param max-inline-insns-recursive-auto\fR is used.  The
+default value is 450.
+.IP "\fBmax-inline-recursive-depth\fR" 4
+.IX Item "max-inline-recursive-depth"
+.PD 0
+.IP "\fBmax-inline-recursive-depth-auto\fR" 4
+.IX Item "max-inline-recursive-depth-auto"
+.PD
+Specifies the maximum recursion depth used for recursive inlining.
+.Sp
+For functions declared inline, \fB\-\-param max-inline-recursive-depth\fR is
+taken into account.  For functions not declared inline, recursive inlining
+happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
+enabled and \fB\-\-param max-inline-recursive-depth-auto\fR is used.  The
+default value is 8.
+.IP "\fBmin-inline-recursive-probability\fR" 4
+.IX Item "min-inline-recursive-probability"
+Recursive inlining is profitable only for function having deep recursion
+in average and can hurt for function having little recursion depth by
+increasing the prologue size or complexity of function body to other
+optimizers.
+.Sp
+When profile feedback is available (see \fB\-fprofile\-generate\fR) the actual
+recursion depth can be guessed from probability that function recurses via a
+given call expression.  This parameter limits inlining only to call expressions
+whose probability exceeds the given threshold (in percents).
+The default value is 10.
+.IP "\fBearly-inlining-insns\fR" 4
+.IX Item "early-inlining-insns"
+Specify growth that the early inliner can make.  In effect it increases
+the amount of inlining for code having a large abstraction penalty.
+The default value is 10.
+.IP "\fBmax-early-inliner-iterations\fR" 4
+.IX Item "max-early-inliner-iterations"
+.PD 0
+.IP "\fBmax-early-inliner-iterations\fR" 4
+.IX Item "max-early-inliner-iterations"
+.PD
+Limit of iterations of the early inliner.  This basically bounds
+the number of nested indirect calls the early inliner can resolve.
+Deeper chains are still handled by late inlining.
+.IP "\fBcomdat-sharing-probability\fR" 4
+.IX Item "comdat-sharing-probability"
+.PD 0
+.IP "\fBcomdat-sharing-probability\fR" 4
+.IX Item "comdat-sharing-probability"
+.PD
+Probability (in percent) that \*(C+ inline function with comdat visibility
+are shared across multiple compilation units.  The default value is 20.
+.IP "\fBmin-vect-loop-bound\fR" 4
+.IX Item "min-vect-loop-bound"
+The minimum number of iterations under which loops are not vectorized
+when \fB\-ftree\-vectorize\fR is used.  The number of iterations after
+vectorization needs to be greater than the value specified by this option
+to allow vectorization.  The default value is 0.
+.IP "\fBgcse-cost-distance-ratio\fR" 4
+.IX Item "gcse-cost-distance-ratio"
+Scaling factor in calculation of maximum distance an expression
+can be moved by \s-1GCSE\s0 optimizations.  This is currently supported only in the
+code hoisting pass.  The bigger the ratio, the more aggressive code hoisting
+is with simple expressions, i.e., the expressions that have cost
+less than \fBgcse-unrestricted-cost\fR.  Specifying 0 disables
+hoisting of simple expressions.  The default value is 10.
+.IP "\fBgcse-unrestricted-cost\fR" 4
+.IX Item "gcse-unrestricted-cost"
+Cost, roughly measured as the cost of a single typical machine
+instruction, at which \s-1GCSE\s0 optimizations do not constrain
+the distance an expression can travel.  This is currently
+supported only in the code hoisting pass.  The lesser the cost,
+the more aggressive code hoisting is.  Specifying 0 
+allows all expressions to travel unrestricted distances.
+The default value is 3.
+.IP "\fBmax-hoist-depth\fR" 4
+.IX Item "max-hoist-depth"
+The depth of search in the dominator tree for expressions to hoist.
+This is used to avoid quadratic behavior in hoisting algorithm.
+The value of 0 does not limit on the search, but may slow down compilation
+of huge functions.  The default value is 30.
+.IP "\fBmax-tail-merge-comparisons\fR" 4
+.IX Item "max-tail-merge-comparisons"
+The maximum amount of similar bbs to compare a bb with.  This is used to
+avoid quadratic behavior in tree tail merging.  The default value is 10.
+.IP "\fBmax-tail-merge-iterations\fR" 4
+.IX Item "max-tail-merge-iterations"
+The maximum amount of iterations of the pass over the function.  This is used to
+limit compilation time in tree tail merging.  The default value is 2.
+.IP "\fBmax-unrolled-insns\fR" 4
+.IX Item "max-unrolled-insns"
+The maximum number of instructions that a loop may have to be unrolled.
+If a loop is unrolled, this parameter also determines how many times
+the loop code is unrolled.
+.IP "\fBmax-average-unrolled-insns\fR" 4
+.IX Item "max-average-unrolled-insns"
+The maximum number of instructions biased by probabilities of their execution
+that a loop may have to be unrolled.  If a loop is unrolled,
+this parameter also determines how many times the loop code is unrolled.
+.IP "\fBmax-unroll-times\fR" 4
+.IX Item "max-unroll-times"
+The maximum number of unrollings of a single loop.
+.IP "\fBmax-peeled-insns\fR" 4
+.IX Item "max-peeled-insns"
+The maximum number of instructions that a loop may have to be peeled.
+If a loop is peeled, this parameter also determines how many times
+the loop code is peeled.
+.IP "\fBmax-peel-times\fR" 4
+.IX Item "max-peel-times"
+The maximum number of peelings of a single loop.
+.IP "\fBmax-peel-branches\fR" 4
+.IX Item "max-peel-branches"
+The maximum number of branches on the hot path through the peeled sequence.
+.IP "\fBmax-completely-peeled-insns\fR" 4
+.IX Item "max-completely-peeled-insns"
+The maximum number of insns of a completely peeled loop.
+.IP "\fBmax-completely-peel-times\fR" 4
+.IX Item "max-completely-peel-times"
+The maximum number of iterations of a loop to be suitable for complete peeling.
+.IP "\fBmax-completely-peel-loop-nest-depth\fR" 4
+.IX Item "max-completely-peel-loop-nest-depth"
+The maximum depth of a loop nest suitable for complete peeling.
+.IP "\fBmax-unswitch-insns\fR" 4
+.IX Item "max-unswitch-insns"
+The maximum number of insns of an unswitched loop.
+.IP "\fBmax-unswitch-level\fR" 4
+.IX Item "max-unswitch-level"
+The maximum number of branches unswitched in a single loop.
+.IP "\fBlim-expensive\fR" 4
+.IX Item "lim-expensive"
+The minimum cost of an expensive expression in the loop invariant motion.
+.IP "\fBiv-consider-all-candidates-bound\fR" 4
+.IX Item "iv-consider-all-candidates-bound"
+Bound on number of candidates for induction variables, below which
+all candidates are considered for each use in induction variable
+optimizations.  If there are more candidates than this,
+only the most relevant ones are considered to avoid quadratic time complexity.
+.IP "\fBiv-max-considered-uses\fR" 4
+.IX Item "iv-max-considered-uses"
+The induction variable optimizations give up on loops that contain more
+induction variable uses.
+.IP "\fBiv-always-prune-cand-set-bound\fR" 4
+.IX Item "iv-always-prune-cand-set-bound"
+If the number of candidates in the set is smaller than this value,
+always try to remove unnecessary ivs from the set
+when adding a new one.
+.IP "\fBscev-max-expr-size\fR" 4
+.IX Item "scev-max-expr-size"
+Bound on size of expressions used in the scalar evolutions analyzer.
+Large expressions slow the analyzer.
+.IP "\fBscev-max-expr-complexity\fR" 4
+.IX Item "scev-max-expr-complexity"
+Bound on the complexity of the expressions in the scalar evolutions analyzer.
+Complex expressions slow the analyzer.
+.IP "\fBomega-max-vars\fR" 4
+.IX Item "omega-max-vars"
+The maximum number of variables in an Omega constraint system.
+The default value is 128.
+.IP "\fBomega-max-geqs\fR" 4
+.IX Item "omega-max-geqs"
+The maximum number of inequalities in an Omega constraint system.
+The default value is 256.
+.IP "\fBomega-max-eqs\fR" 4
+.IX Item "omega-max-eqs"
+The maximum number of equalities in an Omega constraint system.
+The default value is 128.
+.IP "\fBomega-max-wild-cards\fR" 4
+.IX Item "omega-max-wild-cards"
+The maximum number of wildcard variables that the Omega solver is
+able to insert.  The default value is 18.
+.IP "\fBomega-hash-table-size\fR" 4
+.IX Item "omega-hash-table-size"
+The size of the hash table in the Omega solver.  The default value is
+550.
+.IP "\fBomega-max-keys\fR" 4
+.IX Item "omega-max-keys"
+The maximal number of keys used by the Omega solver.  The default
+value is 500.
+.IP "\fBomega-eliminate-redundant-constraints\fR" 4
+.IX Item "omega-eliminate-redundant-constraints"
+When set to 1, use expensive methods to eliminate all redundant
+constraints.  The default value is 0.
+.IP "\fBvect-max-version-for-alignment-checks\fR" 4
+.IX Item "vect-max-version-for-alignment-checks"
+The maximum number of run-time checks that can be performed when
+doing loop versioning for alignment in the vectorizer.
+.IP "\fBvect-max-version-for-alias-checks\fR" 4
+.IX Item "vect-max-version-for-alias-checks"
+The maximum number of run-time checks that can be performed when
+doing loop versioning for alias in the vectorizer.
+.IP "\fBvect-max-peeling-for-alignment\fR" 4
+.IX Item "vect-max-peeling-for-alignment"
+The maximum number of loop peels to enhance access alignment
+for vectorizer. Value \-1 means 'no limit'.
+.IP "\fBmax-iterations-to-track\fR" 4
+.IX Item "max-iterations-to-track"
+The maximum number of iterations of a loop the brute-force algorithm
+for analysis of the number of iterations of the loop tries to evaluate.
+.IP "\fBhot-bb-count-ws-permille\fR" 4
+.IX Item "hot-bb-count-ws-permille"
+A basic block profile count is considered hot if it contributes to 
+the given permillage (i.e. 0...1000) of the entire profiled execution.
+.IP "\fBhot-bb-frequency-fraction\fR" 4
+.IX Item "hot-bb-frequency-fraction"
+Select fraction of the entry block frequency of executions of basic block in
+function given basic block needs to have to be considered hot.
+.IP "\fBmax-predicted-iterations\fR" 4
+.IX Item "max-predicted-iterations"
+The maximum number of loop iterations we predict statically.  This is useful
+in cases where a function contains a single loop with known bound and
+another loop with unknown bound.
+The known number of iterations is predicted correctly, while
+the unknown number of iterations average to roughly 10.  This means that the
+loop without bounds appears artificially cold relative to the other one.
+.IP "\fBbuiltin-expect-probability\fR" 4
+.IX Item "builtin-expect-probability"
+Control the probability of the expression having the specified value. This
+parameter takes a percentage (i.e. 0 ... 100) as input.
+The default probability of 90 is obtained empirically.
+.IP "\fBalign-threshold\fR" 4
+.IX Item "align-threshold"
+Select fraction of the maximal frequency of executions of a basic block in
+a function to align the basic block.
+.IP "\fBalign-loop-iterations\fR" 4
+.IX Item "align-loop-iterations"
+A loop expected to iterate at least the selected number of iterations is
+aligned.
+.IP "\fBtracer-dynamic-coverage\fR" 4
+.IX Item "tracer-dynamic-coverage"
+.PD 0
+.IP "\fBtracer-dynamic-coverage-feedback\fR" 4
+.IX Item "tracer-dynamic-coverage-feedback"
+.PD
+This value is used to limit superblock formation once the given percentage of
+executed instructions is covered.  This limits unnecessary code size
+expansion.
+.Sp
+The \fBtracer-dynamic-coverage-feedback\fR is used only when profile
+feedback is available.  The real profiles (as opposed to statically estimated
+ones) are much less balanced allowing the threshold to be larger value.
+.IP "\fBtracer-max-code-growth\fR" 4
+.IX Item "tracer-max-code-growth"
+Stop tail duplication once code growth has reached given percentage.  This is
+a rather artificial limit, as most of the duplicates are eliminated later in
+cross jumping, so it may be set to much higher values than is the desired code
+growth.
+.IP "\fBtracer-min-branch-ratio\fR" 4
+.IX Item "tracer-min-branch-ratio"
+Stop reverse growth when the reverse probability of best edge is less than this
+threshold (in percent).
+.IP "\fBtracer-min-branch-ratio\fR" 4
+.IX Item "tracer-min-branch-ratio"
+.PD 0
+.IP "\fBtracer-min-branch-ratio-feedback\fR" 4
+.IX Item "tracer-min-branch-ratio-feedback"
+.PD
+Stop forward growth if the best edge has probability lower than this
+threshold.
+.Sp
+Similarly to \fBtracer-dynamic-coverage\fR two values are present, one for
+compilation for profile feedback and one for compilation without.  The value
+for compilation with profile feedback needs to be more conservative (higher) in
+order to make tracer effective.
+.IP "\fBmax-cse-path-length\fR" 4
+.IX Item "max-cse-path-length"
+The maximum number of basic blocks on path that \s-1CSE\s0 considers.
+The default is 10.
+.IP "\fBmax-cse-insns\fR" 4
+.IX Item "max-cse-insns"
+The maximum number of instructions \s-1CSE\s0 processes before flushing.
+The default is 1000.
+.IP "\fBggc-min-expand\fR" 4
+.IX Item "ggc-min-expand"
+\&\s-1GCC\s0 uses a garbage collector to manage its own memory allocation.  This
+parameter specifies the minimum percentage by which the garbage
+collector's heap should be allowed to expand between collections.
+Tuning this may improve compilation speed; it has no effect on code
+generation.
+.Sp
+The default is 30% + 70% * (\s-1RAM/1GB\s0) with an upper bound of 100% when
+\&\s-1RAM \s0>= 1GB.  If \f(CW\*(C`getrlimit\*(C'\fR is available, the notion of \*(L"\s-1RAM\*(R"\s0 is
+the smallest of actual \s-1RAM\s0 and \f(CW\*(C`RLIMIT_DATA\*(C'\fR or \f(CW\*(C`RLIMIT_AS\*(C'\fR.  If
+\&\s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a particular platform, the lower
+bound of 30% is used.  Setting this parameter and
+\&\fBggc-min-heapsize\fR to zero causes a full collection to occur at
+every opportunity.  This is extremely slow, but can be useful for
+debugging.
+.IP "\fBggc-min-heapsize\fR" 4
+.IX Item "ggc-min-heapsize"
+Minimum size of the garbage collector's heap before it begins bothering
+to collect garbage.  The first collection occurs after the heap expands
+by \fBggc-min-expand\fR% beyond \fBggc-min-heapsize\fR.  Again,
+tuning this may improve compilation speed, and has no effect on code
+generation.
+.Sp
+The default is the smaller of \s-1RAM/8, RLIMIT_RSS,\s0 or a limit that
+tries to ensure that \s-1RLIMIT_DATA\s0 or \s-1RLIMIT_AS\s0 are not exceeded, but
+with a lower bound of 4096 (four megabytes) and an upper bound of
+131072 (128 megabytes).  If \s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a
+particular platform, the lower bound is used.  Setting this parameter
+very large effectively disables garbage collection.  Setting this
+parameter and \fBggc-min-expand\fR to zero causes a full collection
+to occur at every opportunity.
+.IP "\fBmax-reload-search-insns\fR" 4
+.IX Item "max-reload-search-insns"
+The maximum number of instruction reload should look backward for equivalent
+register.  Increasing values mean more aggressive optimization, making the
+compilation time increase with probably slightly better performance.
+The default value is 100.
+.IP "\fBmax-cselib-memory-locations\fR" 4
+.IX Item "max-cselib-memory-locations"
+The maximum number of memory locations cselib should take into account.
+Increasing values mean more aggressive optimization, making the compilation time
+increase with probably slightly better performance.  The default value is 500.
+.IP "\fBreorder-blocks-duplicate\fR" 4
+.IX Item "reorder-blocks-duplicate"
+.PD 0
+.IP "\fBreorder-blocks-duplicate-feedback\fR" 4
+.IX Item "reorder-blocks-duplicate-feedback"
+.PD
+Used by the basic block reordering pass to decide whether to use unconditional
+branch or duplicate the code on its destination.  Code is duplicated when its
+estimated size is smaller than this value multiplied by the estimated size of
+unconditional jump in the hot spots of the program.
+.Sp
+The \fBreorder-block-duplicate-feedback\fR is used only when profile
+feedback is available.  It may be set to higher values than
+\&\fBreorder-block-duplicate\fR since information about the hot spots is more
+accurate.
+.IP "\fBmax-sched-ready-insns\fR" 4
+.IX Item "max-sched-ready-insns"
+The maximum number of instructions ready to be issued the scheduler should
+consider at any given time during the first scheduling pass.  Increasing
+values mean more thorough searches, making the compilation time increase
+with probably little benefit.  The default value is 100.
+.IP "\fBmax-sched-region-blocks\fR" 4
+.IX Item "max-sched-region-blocks"
+The maximum number of blocks in a region to be considered for
+interblock scheduling.  The default value is 10.
+.IP "\fBmax-pipeline-region-blocks\fR" 4
+.IX Item "max-pipeline-region-blocks"
+The maximum number of blocks in a region to be considered for
+pipelining in the selective scheduler.  The default value is 15.
+.IP "\fBmax-sched-region-insns\fR" 4
+.IX Item "max-sched-region-insns"
+The maximum number of insns in a region to be considered for
+interblock scheduling.  The default value is 100.
+.IP "\fBmax-pipeline-region-insns\fR" 4
+.IX Item "max-pipeline-region-insns"
+The maximum number of insns in a region to be considered for
+pipelining in the selective scheduler.  The default value is 200.
+.IP "\fBmin-spec-prob\fR" 4
+.IX Item "min-spec-prob"
+The minimum probability (in percents) of reaching a source block
+for interblock speculative scheduling.  The default value is 40.
+.IP "\fBmax-sched-extend-regions-iters\fR" 4
+.IX Item "max-sched-extend-regions-iters"
+The maximum number of iterations through \s-1CFG\s0 to extend regions.
+A value of 0 (the default) disables region extensions.
+.IP "\fBmax-sched-insn-conflict-delay\fR" 4
+.IX Item "max-sched-insn-conflict-delay"
+The maximum conflict delay for an insn to be considered for speculative motion.
+The default value is 3.
+.IP "\fBsched-spec-prob-cutoff\fR" 4
+.IX Item "sched-spec-prob-cutoff"
+The minimal probability of speculation success (in percents), so that
+speculative insns are scheduled.
+The default value is 40.
+.IP "\fBsched-spec-state-edge-prob-cutoff\fR" 4
+.IX Item "sched-spec-state-edge-prob-cutoff"
+The minimum probability an edge must have for the scheduler to save its
+state across it.
+The default value is 10.
+.IP "\fBsched-mem-true-dep-cost\fR" 4
+.IX Item "sched-mem-true-dep-cost"
+Minimal distance (in \s-1CPU\s0 cycles) between store and load targeting same
+memory locations.  The default value is 1.
+.IP "\fBselsched-max-lookahead\fR" 4
+.IX Item "selsched-max-lookahead"
+The maximum size of the lookahead window of selective scheduling.  It is a
+depth of search for available instructions.
+The default value is 50.
+.IP "\fBselsched-max-sched-times\fR" 4
+.IX Item "selsched-max-sched-times"
+The maximum number of times that an instruction is scheduled during
+selective scheduling.  This is the limit on the number of iterations
+through which the instruction may be pipelined.  The default value is 2.
+.IP "\fBselsched-max-insns-to-rename\fR" 4
+.IX Item "selsched-max-insns-to-rename"
+The maximum number of best instructions in the ready list that are considered
+for renaming in the selective scheduler.  The default value is 2.
+.IP "\fBsms-min-sc\fR" 4
+.IX Item "sms-min-sc"
+The minimum value of stage count that swing modulo scheduler
+generates.  The default value is 2.
+.IP "\fBmax-last-value-rtl\fR" 4
+.IX Item "max-last-value-rtl"
+The maximum size measured as number of RTLs that can be recorded in an expression
+in combiner for a pseudo register as last known value of that register.  The default
+is 10000.
+.IP "\fBinteger-share-limit\fR" 4
+.IX Item "integer-share-limit"
+Small integer constants can use a shared data structure, reducing the
+compiler's memory usage and increasing its speed.  This sets the maximum
+value of a shared integer constant.  The default value is 256.
+.IP "\fBssp-buffer-size\fR" 4
+.IX Item "ssp-buffer-size"
+The minimum size of buffers (i.e. arrays) that receive stack smashing
+protection when \fB\-fstack\-protection\fR is used.
+.IP "\fBmin-size-for-stack-sharing\fR" 4
+.IX Item "min-size-for-stack-sharing"
+The minimum size of variables taking part in stack slot sharing when not
+optimizing. The default value is 32.
+.IP "\fBmax-jump-thread-duplication-stmts\fR" 4
+.IX Item "max-jump-thread-duplication-stmts"
+Maximum number of statements allowed in a block that needs to be
+duplicated when threading jumps.
+.IP "\fBmax-fields-for-field-sensitive\fR" 4
+.IX Item "max-fields-for-field-sensitive"
+Maximum number of fields in a structure treated in
+a field sensitive manner during pointer analysis.  The default is zero
+for \fB\-O0\fR and \fB\-O1\fR,
+and 100 for \fB\-Os\fR, \fB\-O2\fR, and \fB\-O3\fR.
+.IP "\fBprefetch-latency\fR" 4
+.IX Item "prefetch-latency"
+Estimate on average number of instructions that are executed before
+prefetch finishes.  The distance prefetched ahead is proportional
+to this constant.  Increasing this number may also lead to less
+streams being prefetched (see \fBsimultaneous-prefetches\fR).
+.IP "\fBsimultaneous-prefetches\fR" 4
+.IX Item "simultaneous-prefetches"
+Maximum number of prefetches that can run at the same time.
+.IP "\fBl1\-cache\-line\-size\fR" 4
+.IX Item "l1-cache-line-size"
+The size of cache line in L1 cache, in bytes.
+.IP "\fBl1\-cache\-size\fR" 4
+.IX Item "l1-cache-size"
+The size of L1 cache, in kilobytes.
+.IP "\fBl2\-cache\-size\fR" 4
+.IX Item "l2-cache-size"
+The size of L2 cache, in kilobytes.
+.IP "\fBmin-insn-to-prefetch-ratio\fR" 4
+.IX Item "min-insn-to-prefetch-ratio"
+The minimum ratio between the number of instructions and the
+number of prefetches to enable prefetching in a loop.
+.IP "\fBprefetch-min-insn-to-mem-ratio\fR" 4
+.IX Item "prefetch-min-insn-to-mem-ratio"
+The minimum ratio between the number of instructions and the
+number of memory references to enable prefetching in a loop.
+.IP "\fBuse-canonical-types\fR" 4
+.IX Item "use-canonical-types"
+Whether the compiler should use the \*(L"canonical\*(R" type system.  By
+default, this should always be 1, which uses a more efficient internal
+mechanism for comparing types in \*(C+ and Objective\-\*(C+.  However, if
+bugs in the canonical type system are causing compilation failures,
+set this value to 0 to disable canonical types.
+.IP "\fBswitch-conversion-max-branch-ratio\fR" 4
+.IX Item "switch-conversion-max-branch-ratio"
+Switch initialization conversion refuses to create arrays that are
+bigger than \fBswitch-conversion-max-branch-ratio\fR times the number of
+branches in the switch.
+.IP "\fBmax-partial-antic-length\fR" 4
+.IX Item "max-partial-antic-length"
+Maximum length of the partial antic set computed during the tree
+partial redundancy elimination optimization (\fB\-ftree\-pre\fR) when
+optimizing at \fB\-O3\fR and above.  For some sorts of source code
+the enhanced partial redundancy elimination optimization can run away,
+consuming all of the memory available on the host machine.  This
+parameter sets a limit on the length of the sets that are computed,
+which prevents the runaway behavior.  Setting a value of 0 for
+this parameter allows an unlimited set length.
+.IP "\fBsccvn-max-scc-size\fR" 4
+.IX Item "sccvn-max-scc-size"
+Maximum size of a strongly connected component (\s-1SCC\s0) during \s-1SCCVN\s0
+processing.  If this limit is hit, \s-1SCCVN\s0 processing for the whole
+function is not done and optimizations depending on it are
+disabled.  The default maximum \s-1SCC\s0 size is 10000.
+.IP "\fBsccvn-max-alias-queries-per-access\fR" 4
+.IX Item "sccvn-max-alias-queries-per-access"
+Maximum number of alias-oracle queries we perform when looking for
+redundancies for loads and stores.  If this limit is hit the search
+is aborted and the load or store is not considered redundant.  The
+number of queries is algorithmically limited to the number of
+stores on all paths from the load to the function entry.
+The default maxmimum number of queries is 1000.
+.IP "\fBira-max-loops-num\fR" 4
+.IX Item "ira-max-loops-num"
+\&\s-1IRA\s0 uses regional register allocation by default.  If a function
+contains more loops than the number given by this parameter, only at most
+the given number of the most frequently-executed loops form regions
+for regional register allocation.  The default value of the
+parameter is 100.
+.IP "\fBira-max-conflict-table-size\fR" 4
+.IX Item "ira-max-conflict-table-size"
+Although \s-1IRA\s0 uses a sophisticated algorithm to compress the conflict
+table, the table can still require excessive amounts of memory for
+huge functions.  If the conflict table for a function could be more
+than the size in \s-1MB\s0 given by this parameter, the register allocator
+instead uses a faster, simpler, and lower-quality
+algorithm that does not require building a pseudo-register conflict table.  
+The default value of the parameter is 2000.
+.IP "\fBira-loop-reserved-regs\fR" 4
+.IX Item "ira-loop-reserved-regs"
+\&\s-1IRA\s0 can be used to evaluate more accurate register pressure in loops
+for decisions to move loop invariants (see \fB\-O3\fR).  The number
+of available registers reserved for some other purposes is given
+by this parameter.  The default value of the parameter is 2, which is
+the minimal number of registers needed by typical instructions.
+This value is the best found from numerous experiments.
+.IP "\fBloop-invariant-max-bbs-in-loop\fR" 4
+.IX Item "loop-invariant-max-bbs-in-loop"
+Loop invariant motion can be very expensive, both in compilation time and
+in amount of needed compile-time memory, with very large loops.  Loops
+with more basic blocks than this parameter won't have loop invariant
+motion optimization performed on them.  The default value of the
+parameter is 1000 for \fB\-O1\fR and 10000 for \fB\-O2\fR and above.
+.IP "\fBloop-max-datarefs-for-datadeps\fR" 4
+.IX Item "loop-max-datarefs-for-datadeps"
+Building data dapendencies is expensive for very large loops.  This
+parameter limits the number of data references in loops that are
+considered for data dependence analysis.  These large loops are no
+handled by the optimizations using loop data dependencies.
+The default value is 1000.
+.IP "\fBmax-vartrack-size\fR" 4
+.IX Item "max-vartrack-size"
+Sets a maximum number of hash table slots to use during variable
+tracking dataflow analysis of any function.  If this limit is exceeded
+with variable tracking at assignments enabled, analysis for that
+function is retried without it, after removing all debug insns from
+the function.  If the limit is exceeded even without debug insns, var
+tracking analysis is completely disabled for the function.  Setting
+the parameter to zero makes it unlimited.
+.IP "\fBmax-vartrack-expr-depth\fR" 4
+.IX Item "max-vartrack-expr-depth"
+Sets a maximum number of recursion levels when attempting to map
+variable names or debug temporaries to value expressions.  This trades
+compilation time for more complete debug information.  If this is set too
+low, value expressions that are available and could be represented in
+debug information may end up not being used; setting this higher may
+enable the compiler to find more complex debug expressions, but compile
+time and memory use may grow.  The default is 12.
+.IP "\fBmin-nondebug-insn-uid\fR" 4
+.IX Item "min-nondebug-insn-uid"
+Use uids starting at this parameter for nondebug insns.  The range below
+the parameter is reserved exclusively for debug insns created by
+\&\fB\-fvar\-tracking\-assignments\fR, but debug insns may get
+(non-overlapping) uids above it if the reserved range is exhausted.
+.IP "\fBipa-sra-ptr-growth-factor\fR" 4
+.IX Item "ipa-sra-ptr-growth-factor"
+IPA-SRA replaces a pointer to an aggregate with one or more new
+parameters only when their cumulative size is less or equal to
+\&\fBipa-sra-ptr-growth-factor\fR times the size of the original
+pointer parameter.
+.IP "\fBtm-max-aggregate-size\fR" 4
+.IX Item "tm-max-aggregate-size"
+When making copies of thread-local variables in a transaction, this
+parameter specifies the size in bytes after which variables are
+saved with the logging functions as opposed to save/restore code
+sequence pairs.  This option only applies when using
+\&\fB\-fgnu\-tm\fR.
+.IP "\fBgraphite-max-nb-scop-params\fR" 4
+.IX Item "graphite-max-nb-scop-params"
+To avoid exponential effects in the Graphite loop transforms, the
+number of parameters in a Static Control Part (SCoP) is bounded.  The
+default value is 10 parameters.  A variable whose value is unknown at
+compilation time and defined outside a SCoP is a parameter of the SCoP.
+.IP "\fBgraphite-max-bbs-per-function\fR" 4
+.IX Item "graphite-max-bbs-per-function"
+To avoid exponential effects in the detection of SCoPs, the size of
+the functions analyzed by Graphite is bounded.  The default value is
+100 basic blocks.
+.IP "\fBloop-block-tile-size\fR" 4
+.IX Item "loop-block-tile-size"
+Loop blocking or strip mining transforms, enabled with
+\&\fB\-floop\-block\fR or \fB\-floop\-strip\-mine\fR, strip mine each
+loop in the loop nest by a given number of iterations.  The strip
+length can be changed using the \fBloop-block-tile-size\fR
+parameter.  The default value is 51 iterations.
+.IP "\fBipa-cp-value-list-size\fR" 4
+.IX Item "ipa-cp-value-list-size"
+IPA-CP attempts to track all possible values and types passed to a function's
+parameter in order to propagate them and perform devirtualization.
+\&\fBipa-cp-value-list-size\fR is the maximum number of values and types it
+stores per one formal parameter of a function.
+.IP "\fBlto-partitions\fR" 4
+.IX Item "lto-partitions"
+Specify desired number of partitions produced during \s-1WHOPR\s0 compilation.
+The number of partitions should exceed the number of CPUs used for compilation.
+The default value is 32.
+.IP "\fBlto-minpartition\fR" 4
+.IX Item "lto-minpartition"
+Size of minimal partition for \s-1WHOPR \s0(in estimated instructions).
+This prevents expenses of splitting very small programs into too many
+partitions.
+.IP "\fBcxx-max-namespaces-for-diagnostic-help\fR" 4
+.IX Item "cxx-max-namespaces-for-diagnostic-help"
+The maximum number of namespaces to consult for suggestions when \*(C+
+name lookup fails for an identifier.  The default is 1000.
+.IP "\fBsink-frequency-threshold\fR" 4
+.IX Item "sink-frequency-threshold"
+The maximum relative execution frequency (in percents) of the target block
+relative to a statement's original block to allow statement sinking of a
+statement.  Larger numbers result in more aggressive statement sinking.
+The default value is 75.  A small positive adjustment is applied for
+statements with memory operands as those are even more profitable so sink.
+.IP "\fBmax-stores-to-sink\fR" 4
+.IX Item "max-stores-to-sink"
+The maximum number of conditional stores paires that can be sunk.  Set to 0
+if either vectorization (\fB\-ftree\-vectorize\fR) or if-conversion
+(\fB\-ftree\-loop\-if\-convert\fR) is disabled.  The default is 2.
+.IP "\fBallow-load-data-races\fR" 4
+.IX Item "allow-load-data-races"
+Allow optimizers to introduce new data races on loads.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the \fB\-fmemory\-model=\fR option.
+.IP "\fBallow-store-data-races\fR" 4
+.IX Item "allow-store-data-races"
+Allow optimizers to introduce new data races on stores.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the \fB\-fmemory\-model=\fR option.
+.IP "\fBallow-packed-load-data-races\fR" 4
+.IX Item "allow-packed-load-data-races"
+Allow optimizers to introduce new data races on packed data loads.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the \fB\-fmemory\-model=\fR option.
+.IP "\fBallow-packed-store-data-races\fR" 4
+.IX Item "allow-packed-store-data-races"
+Allow optimizers to introduce new data races on packed data stores.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the \fB\-fmemory\-model=\fR option.
+.IP "\fBcase-values-threshold\fR" 4
+.IX Item "case-values-threshold"
+The smallest number of different values for which it is best to use a
+jump-table instead of a tree of conditional branches.  If the value is
+0, use the default for the machine.  The default is 0.
+.IP "\fBtree-reassoc-width\fR" 4
+.IX Item "tree-reassoc-width"
+Set the maximum number of instructions executed in parallel in
+reassociated tree. This parameter overrides target dependent
+heuristics used by default if has non zero value.
+.IP "\fBsched-pressure-algorithm\fR" 4
+.IX Item "sched-pressure-algorithm"
+Choose between the two available implementations of
+\&\fB\-fsched\-pressure\fR.  Algorithm 1 is the original implementation
+and is the more likely to prevent instructions from being reordered.
+Algorithm 2 was designed to be a compromise between the relatively
+conservative approach taken by algorithm 1 and the rather aggressive
+approach taken by the default scheduler.  It relies more heavily on
+having a regular register file and accurate register pressure classes.
+See \fIhaifa\-sched.c\fR in the \s-1GCC\s0 sources for more details.
+.Sp
+The default choice depends on the target.
+.IP "\fBmax-slsr-cand-scan\fR" 4
+.IX Item "max-slsr-cand-scan"
+Set the maximum number of existing candidates that will be considered when
+seeking a basis for a new straight-line strength reduction candidate.
+.IP "\fBasan-globals\fR" 4
+.IX Item "asan-globals"
+Enable buffer overflow detection for global objects.  This kind
+of protection is enabled by default if you are using
+\&\fB\-fsanitize=address\fR option.
+To disable global objects protection use \fB\-\-param asan\-globals=0\fR.
+.IP "\fBasan-stack\fR" 4
+.IX Item "asan-stack"
+Enable buffer overflow detection for stack objects.  This kind of
+protection is enabled by default when using\fB\-fsanitize=address\fR.
+To disable stack protection use \fB\-\-param asan\-stack=0\fR option.
+.IP "\fBasan-instrument-reads\fR" 4
+.IX Item "asan-instrument-reads"
+Enable buffer overflow detection for memory reads.  This kind of
+protection is enabled by default when using \fB\-fsanitize=address\fR.
+To disable memory reads protection use
+\&\fB\-\-param asan\-instrument\-reads=0\fR.
+.IP "\fBasan-instrument-writes\fR" 4
+.IX Item "asan-instrument-writes"
+Enable buffer overflow detection for memory writes.  This kind of
+protection is enabled by default when using \fB\-fsanitize=address\fR.
+To disable memory writes protection use
+\&\fB\-\-param asan\-instrument\-writes=0\fR option.
+.IP "\fBasan-memintrin\fR" 4
+.IX Item "asan-memintrin"
+Enable detection for built-in functions.  This kind of protection
+is enabled by default when using \fB\-fsanitize=address\fR.
+To disable built-in functions protection use
+\&\fB\-\-param asan\-memintrin=0\fR.
+.IP "\fBasan-use-after-return\fR" 4
+.IX Item "asan-use-after-return"
+Enable detection of use-after-return.  This kind of protection
+is enabled by default when using \fB\-fsanitize=address\fR option.
+To disable use-after-return detection use 
+\&\fB\-\-param asan\-use\-after\-return=0\fR.
+.RE
+.RS 4
+.RE
+.SS "Options Controlling the Preprocessor"
+.IX Subsection "Options Controlling the Preprocessor"
+These options control the C preprocessor, which is run on each C source
+file before actual compilation.
+.PP
+If you use the \fB\-E\fR option, nothing is done except preprocessing.
+Some of these options make sense only together with \fB\-E\fR because
+they cause the preprocessor output to be unsuitable for actual
+compilation.
+.IP "\fB\-Wp,\fR\fIoption\fR" 4
+.IX Item "-Wp,option"
+You can use \fB\-Wp,\fR\fIoption\fR to bypass the compiler driver
+and pass \fIoption\fR directly through to the preprocessor.  If
+\&\fIoption\fR contains commas, it is split into multiple options at the
+commas.  However, many options are modified, translated or interpreted
+by the compiler driver before being passed to the preprocessor, and
+\&\fB\-Wp\fR forcibly bypasses this phase.  The preprocessor's direct
+interface is undocumented and subject to change, so whenever possible
+you should avoid using \fB\-Wp\fR and let the driver handle the
+options instead.
+.IP "\fB\-Xpreprocessor\fR \fIoption\fR" 4
+.IX Item "-Xpreprocessor option"
+Pass \fIoption\fR as an option to the preprocessor.  You can use this to
+supply system-specific preprocessor options that \s-1GCC\s0 does not 
+recognize.
+.Sp
+If you want to pass an option that takes an argument, you must use
+\&\fB\-Xpreprocessor\fR twice, once for the option and once for the argument.
+.IP "\fB\-no\-integrated\-cpp\fR" 4
+.IX Item "-no-integrated-cpp"
+Perform preprocessing as a separate pass before compilation.
+By default, \s-1GCC\s0 performs preprocessing as an integrated part of
+input tokenization and parsing.
+If this option is provided, the appropriate language front end
+(\fBcc1\fR, \fBcc1plus\fR, or \fBcc1obj\fR for C, \*(C+,
+and Objective-C, respectively) is instead invoked twice,
+once for preprocessing only and once for actual compilation
+of the preprocessed input.
+This option may be useful in conjunction with the \fB\-B\fR or
+\&\fB\-wrapper\fR options to specify an alternate preprocessor or
+perform additional processing of the program source between
+normal preprocessing and compilation.
+.IP "\fB\-D\fR \fIname\fR" 4
+.IX Item "-D name"
+Predefine \fIname\fR as a macro, with definition \f(CW1\fR.
+.IP "\fB\-D\fR \fIname\fR\fB=\fR\fIdefinition\fR" 4
+.IX Item "-D name=definition"
+The contents of \fIdefinition\fR are tokenized and processed as if
+they appeared during translation phase three in a \fB#define\fR
+directive.  In particular, the definition will be truncated by
+embedded newline characters.
+.Sp
+If you are invoking the preprocessor from a shell or shell-like
+program you may need to use the shell's quoting syntax to protect
+characters such as spaces that have a meaning in the shell syntax.
+.Sp
+If you wish to define a function-like macro on the command line, write
+its argument list with surrounding parentheses before the equals sign
+(if any).  Parentheses are meaningful to most shells, so you will need
+to quote the option.  With \fBsh\fR and \fBcsh\fR,
+\&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
+.Sp
+\&\fB\-D\fR and \fB\-U\fR options are processed in the order they
+are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
+\&\fB\-include\fR \fIfile\fR options are processed after all
+\&\fB\-D\fR and \fB\-U\fR options.
+.IP "\fB\-U\fR \fIname\fR" 4
+.IX Item "-U name"
+Cancel any previous definition of \fIname\fR, either built in or
+provided with a \fB\-D\fR option.
+.IP "\fB\-undef\fR" 4
+.IX Item "-undef"
+Do not predefine any system-specific or GCC-specific macros.  The
+standard predefined macros remain defined.
+.IP "\fB\-I\fR \fIdir\fR" 4
+.IX Item "-I dir"
+Add the directory \fIdir\fR to the list of directories to be searched
+for header files.
+Directories named by \fB\-I\fR are searched before the standard
+system include directories.  If the directory \fIdir\fR is a standard
+system include directory, the option is ignored to ensure that the
+default search order for system directories and the special treatment
+of system headers are not defeated
+\&.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-o\fR \fIfile\fR" 4
+.IX Item "-o file"
+Write output to \fIfile\fR.  This is the same as specifying \fIfile\fR
+as the second non-option argument to \fBcpp\fR.  \fBgcc\fR has a
+different interpretation of a second non-option argument, so you must
+use \fB\-o\fR to specify the output file.
+.IP "\fB\-Wall\fR" 4
+.IX Item "-Wall"
+Turns on all optional warnings which are desirable for normal code.
+At present this is \fB\-Wcomment\fR, \fB\-Wtrigraphs\fR,
+\&\fB\-Wmultichar\fR and a warning about integer promotion causing a
+change of sign in \f(CW\*(C`#if\*(C'\fR expressions.  Note that many of the
+preprocessor's warnings are on by default and have no options to
+control them.
+.IP "\fB\-Wcomment\fR" 4
+.IX Item "-Wcomment"
+.PD 0
+.IP "\fB\-Wcomments\fR" 4
+.IX Item "-Wcomments"
+.PD
+Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
+comment, or whenever a backslash-newline appears in a \fB//\fR comment.
+(Both forms have the same effect.)
+.IP "\fB\-Wtrigraphs\fR" 4
+.IX Item "-Wtrigraphs"
+Most trigraphs in comments cannot affect the meaning of the program.
+However, a trigraph that would form an escaped newline (\fB??/\fR at
+the end of a line) can, by changing where the comment begins or ends.
+Therefore, only trigraphs that would form escaped newlines produce
+warnings inside a comment.
+.Sp
+This option is implied by \fB\-Wall\fR.  If \fB\-Wall\fR is not
+given, this option is still enabled unless trigraphs are enabled.  To
+get trigraph conversion without warnings, but get the other
+\&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
+.IP "\fB\-Wtraditional\fR" 4
+.IX Item "-Wtraditional"
+Warn about certain constructs that behave differently in traditional and
+\&\s-1ISO C. \s0 Also warn about \s-1ISO C\s0 constructs that have no traditional C
+equivalent, and problematic constructs which should be avoided.
+.IP "\fB\-Wundef\fR" 4
+.IX Item "-Wundef"
+Warn whenever an identifier which is not a macro is encountered in an
+\&\fB#if\fR directive, outside of \fBdefined\fR.  Such identifiers are
+replaced with zero.
+.IP "\fB\-Wunused\-macros\fR" 4
+.IX Item "-Wunused-macros"
+Warn about macros defined in the main file that are unused.  A macro
+is \fIused\fR if it is expanded or tested for existence at least once.
+The preprocessor will also warn if the macro has not been used at the
+time it is redefined or undefined.
+.Sp
+Built-in macros, macros defined on the command line, and macros
+defined in include files are not warned about.
+.Sp
+\&\fINote:\fR If a macro is actually used, but only used in skipped
+conditional blocks, then \s-1CPP\s0 will report it as unused.  To avoid the
+warning in such a case, you might improve the scope of the macro's
+definition by, for example, moving it into the first skipped block.
+Alternatively, you could provide a dummy use with something like:
+.Sp
+.Vb 2
+\&        #if defined the_macro_causing_the_warning
+\&        #endif
+.Ve
+.IP "\fB\-Wendif\-labels\fR" 4
+.IX Item "-Wendif-labels"
+Warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
+This usually happens in code of the form
+.Sp
+.Vb 5
+\&        #if FOO
+\&        ...
+\&        #else FOO
+\&        ...
+\&        #endif FOO
+.Ve
+.Sp
+The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments, but often are not
+in older programs.  This warning is on by default.
+.IP "\fB\-Werror\fR" 4
+.IX Item "-Werror"
+Make all warnings into hard errors.  Source code which triggers warnings
+will be rejected.
+.IP "\fB\-Wsystem\-headers\fR" 4
+.IX Item "-Wsystem-headers"
+Issue warnings for code in system headers.  These are normally unhelpful
+in finding bugs in your own code, therefore suppressed.  If you are
+responsible for the system library, you may want to see them.
+.IP "\fB\-w\fR" 4
+.IX Item "-w"
+Suppress all warnings, including those which \s-1GNU CPP\s0 issues by default.
+.IP "\fB\-pedantic\fR" 4
+.IX Item "-pedantic"
+Issue all the mandatory diagnostics listed in the C standard.  Some of
+them are left out by default, since they trigger frequently on harmless
+code.
+.IP "\fB\-pedantic\-errors\fR" 4
+.IX Item "-pedantic-errors"
+Issue all the mandatory diagnostics, and make all mandatory diagnostics
+into errors.  This includes mandatory diagnostics that \s-1GCC\s0 issues
+without \fB\-pedantic\fR but treats as warnings.
+.IP "\fB\-M\fR" 4
+.IX Item "-M"
+Instead of outputting the result of preprocessing, output a rule
+suitable for \fBmake\fR describing the dependencies of the main
+source file.  The preprocessor outputs one \fBmake\fR rule containing
+the object file name for that source file, a colon, and the names of all
+the included files, including those coming from \fB\-include\fR or
+\&\fB\-imacros\fR command line options.
+.Sp
+Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
+object file name consists of the name of the source file with any
+suffix replaced with object file suffix and with any leading directory
+parts removed.  If there are many included files then the rule is
+split into several lines using \fB\e\fR\-newline.  The rule has no
+commands.
+.Sp
+This option does not suppress the preprocessor's debug output, such as
+\&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
+rules you should explicitly specify the dependency output file with
+\&\fB\-MF\fR, or use an environment variable like
+\&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR.  Debug output
+will still be sent to the regular output stream as normal.
+.Sp
+Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
+warnings with an implicit \fB\-w\fR.
+.IP "\fB\-MM\fR" 4
+.IX Item "-MM"
+Like \fB\-M\fR but do not mention header files that are found in
+system header directories, nor header files that are included,
+directly or indirectly, from such a header.
+.Sp
+This implies that the choice of angle brackets or double quotes in an
+\&\fB#include\fR directive does not in itself determine whether that
+header will appear in \fB\-MM\fR dependency output.  This is a
+slight change in semantics from \s-1GCC\s0 versions 3.0 and earlier.
+.IP "\fB\-MF\fR \fIfile\fR" 4
+.IX Item "-MF file"
+When used with \fB\-M\fR or \fB\-MM\fR, specifies a
+file to write the dependencies to.  If no \fB\-MF\fR switch is given
+the preprocessor sends the rules to the same place it would have sent
+preprocessed output.
+.Sp
+When used with the driver options \fB\-MD\fR or \fB\-MMD\fR,
+\&\fB\-MF\fR overrides the default dependency output file.
+.IP "\fB\-MG\fR" 4
+.IX Item "-MG"
+In conjunction with an option such as \fB\-M\fR requesting
+dependency generation, \fB\-MG\fR assumes missing header files are
+generated files and adds them to the dependency list without raising
+an error.  The dependency filename is taken directly from the
+\&\f(CW\*(C`#include\*(C'\fR directive without prepending any path.  \fB\-MG\fR
+also suppresses preprocessed output, as a missing header file renders
+this useless.
+.Sp
+This feature is used in automatic updating of makefiles.
+.IP "\fB\-MP\fR" 4
+.IX Item "-MP"
+This option instructs \s-1CPP\s0 to add a phony target for each dependency
+other than the main file, causing each to depend on nothing.  These
+dummy rules work around errors \fBmake\fR gives if you remove header
+files without updating the \fIMakefile\fR to match.
+.Sp
+This is typical output:
+.Sp
+.Vb 1
+\&        test.o: test.c test.h
+\&        
+\&        test.h:
+.Ve
+.IP "\fB\-MT\fR \fItarget\fR" 4
+.IX Item "-MT target"
+Change the target of the rule emitted by dependency generation.  By
+default \s-1CPP\s0 takes the name of the main input file, deletes any
+directory components and any file suffix such as \fB.c\fR, and
+appends the platform's usual object suffix.  The result is the target.
+.Sp
+An \fB\-MT\fR option will set the target to be exactly the string you
+specify.  If you want multiple targets, you can specify them as a single
+argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
+.Sp
+For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
+.Sp
+.Vb 1
+\&        $(objpfx)foo.o: foo.c
+.Ve
+.IP "\fB\-MQ\fR \fItarget\fR" 4
+.IX Item "-MQ target"
+Same as \fB\-MT\fR, but it quotes any characters which are special to
+Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR gives
+.Sp
+.Vb 1
+\&        $$(objpfx)foo.o: foo.c
+.Ve
+.Sp
+The default target is automatically quoted, as if it were given with
+\&\fB\-MQ\fR.
+.IP "\fB\-MD\fR" 4
+.IX Item "-MD"
+\&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
+\&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
+whether an \fB\-o\fR option is given.  If it is, the driver uses its
+argument but with a suffix of \fI.d\fR, otherwise it takes the name
+of the input file, removes any directory components and suffix, and
+applies a \fI.d\fR suffix.
+.Sp
+If \fB\-MD\fR is used in conjunction with \fB\-E\fR, any
+\&\fB\-o\fR switch is understood to specify the dependency output file, but if used without \fB\-E\fR, each \fB\-o\fR
+is understood to specify a target object file.
+.Sp
+Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
+a dependency output file as a side-effect of the compilation process.
+.IP "\fB\-MMD\fR" 4
+.IX Item "-MMD"
+Like \fB\-MD\fR except mention only user header files, not system
+header files.
+.IP "\fB\-fpch\-deps\fR" 4
+.IX Item "-fpch-deps"
+When using precompiled headers, this flag
+will cause the dependency-output flags to also list the files from the
+precompiled header's dependencies.  If not specified only the
+precompiled header would be listed and not the files that were used to
+create it because those files are not consulted when a precompiled
+header is used.
+.IP "\fB\-fpch\-preprocess\fR" 4
+.IX Item "-fpch-preprocess"
+This option allows use of a precompiled header together with \fB\-E\fR.  It inserts a special \f(CW\*(C`#pragma\*(C'\fR,
+\&\f(CW\*(C`#pragma GCC pch_preprocess "\f(CIfilename\f(CW"\*(C'\fR in the output to mark
+the place where the precompiled header was found, and its \fIfilename\fR.
+When \fB\-fpreprocessed\fR is in use, \s-1GCC\s0 recognizes this \f(CW\*(C`#pragma\*(C'\fR
+and loads the \s-1PCH.\s0
+.Sp
+This option is off by default, because the resulting preprocessed output
+is only really suitable as input to \s-1GCC. \s0 It is switched on by
+\&\fB\-save\-temps\fR.
+.Sp
+You should not write this \f(CW\*(C`#pragma\*(C'\fR in your own code, but it is
+safe to edit the filename if the \s-1PCH\s0 file is available in a different
+location.  The filename may be absolute or it may be relative to \s-1GCC\s0's
+current directory.
+.IP "\fB\-x c\fR" 4
+.IX Item "-x c"
+.PD 0
+.IP "\fB\-x c++\fR" 4
+.IX Item "-x c++"
+.IP "\fB\-x objective-c\fR" 4
+.IX Item "-x objective-c"
+.IP "\fB\-x assembler-with-cpp\fR" 4
+.IX Item "-x assembler-with-cpp"
+.PD
+Specify the source language: C, \*(C+, Objective-C, or assembly.  This has
+nothing to do with standards conformance or extensions; it merely
+selects which base syntax to expect.  If you give none of these options,
+cpp will deduce the language from the extension of the source file:
+\&\fB.c\fR, \fB.cc\fR, \fB.m\fR, or \fB.S\fR.  Some other common
+extensions for \*(C+ and assembly are also recognized.  If cpp does not
+recognize the extension, it will treat the file as C; this is the most
+generic mode.
+.Sp
+\&\fINote:\fR Previous versions of cpp accepted a \fB\-lang\fR option
+which selected both the language and the standards conformance level.
+This option has been removed, because it conflicts with the \fB\-l\fR
+option.
+.IP "\fB\-std=\fR\fIstandard\fR" 4
+.IX Item "-std=standard"
+.PD 0
+.IP "\fB\-ansi\fR" 4
+.IX Item "-ansi"
+.PD
+Specify the standard to which the code should conform.  Currently \s-1CPP\s0
+knows about C and \*(C+ standards; others may be added in the future.
+.Sp
+\&\fIstandard\fR
+may be one of:
+.RS 4
+.ie n .IP """c90""" 4
+.el .IP "\f(CWc90\fR" 4
+.IX Item "c90"
+.PD 0
+.ie n .IP """c89""" 4
+.el .IP "\f(CWc89\fR" 4
+.IX Item "c89"
+.ie n .IP """iso9899:1990""" 4
+.el .IP "\f(CWiso9899:1990\fR" 4
+.IX Item "iso9899:1990"
+.PD
+The \s-1ISO C\s0 standard from 1990.  \fBc90\fR is the customary shorthand for
+this version of the standard.
+.Sp
+The \fB\-ansi\fR option is equivalent to \fB\-std=c90\fR.
+.ie n .IP """iso9899:199409""" 4
+.el .IP "\f(CWiso9899:199409\fR" 4
+.IX Item "iso9899:199409"
+The 1990 C standard, as amended in 1994.
+.ie n .IP """iso9899:1999""" 4
+.el .IP "\f(CWiso9899:1999\fR" 4
+.IX Item "iso9899:1999"
+.PD 0
+.ie n .IP """c99""" 4
+.el .IP "\f(CWc99\fR" 4
+.IX Item "c99"
+.ie n .IP """iso9899:199x""" 4
+.el .IP "\f(CWiso9899:199x\fR" 4
+.IX Item "iso9899:199x"
+.ie n .IP """c9x""" 4
+.el .IP "\f(CWc9x\fR" 4
+.IX Item "c9x"
+.PD
+The revised \s-1ISO C\s0 standard, published in December 1999.  Before
+publication, this was known as C9X.
+.ie n .IP """iso9899:2011""" 4
+.el .IP "\f(CWiso9899:2011\fR" 4
+.IX Item "iso9899:2011"
+.PD 0
+.ie n .IP """c11""" 4
+.el .IP "\f(CWc11\fR" 4
+.IX Item "c11"
+.ie n .IP """c1x""" 4
+.el .IP "\f(CWc1x\fR" 4
+.IX Item "c1x"
+.PD
+The revised \s-1ISO C\s0 standard, published in December 2011.  Before
+publication, this was known as C1X.
+.ie n .IP """gnu90""" 4
+.el .IP "\f(CWgnu90\fR" 4
+.IX Item "gnu90"
+.PD 0
+.ie n .IP """gnu89""" 4
+.el .IP "\f(CWgnu89\fR" 4
+.IX Item "gnu89"
+.PD
+The 1990 C standard plus \s-1GNU\s0 extensions.  This is the default.
+.ie n .IP """gnu99""" 4
+.el .IP "\f(CWgnu99\fR" 4
+.IX Item "gnu99"
+.PD 0
+.ie n .IP """gnu9x""" 4
+.el .IP "\f(CWgnu9x\fR" 4
+.IX Item "gnu9x"
+.PD
+The 1999 C standard plus \s-1GNU\s0 extensions.
+.ie n .IP """gnu11""" 4
+.el .IP "\f(CWgnu11\fR" 4
+.IX Item "gnu11"
+.PD 0
+.ie n .IP """gnu1x""" 4
+.el .IP "\f(CWgnu1x\fR" 4
+.IX Item "gnu1x"
+.PD
+The 2011 C standard plus \s-1GNU\s0 extensions.
+.ie n .IP """c++98""" 4
+.el .IP "\f(CWc++98\fR" 4
+.IX Item "c++98"
+The 1998 \s-1ISO \*(C+\s0 standard plus amendments.
+.ie n .IP """gnu++98""" 4
+.el .IP "\f(CWgnu++98\fR" 4
+.IX Item "gnu++98"
+The same as \fB\-std=c++98\fR plus \s-1GNU\s0 extensions.  This is the
+default for \*(C+ code.
+.RE
+.RS 4
+.RE
+.IP "\fB\-I\-\fR" 4
+.IX Item "-I-"
+Split the include path.  Any directories specified with \fB\-I\fR
+options before \fB\-I\-\fR are searched only for headers requested with
+\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
+\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR.  If additional directories are
+specified with \fB\-I\fR options after the \fB\-I\-\fR, those
+directories are searched for all \fB#include\fR directives.
+.Sp
+In addition, \fB\-I\-\fR inhibits the use of the directory of the current
+file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
+This option has been deprecated.
+.IP "\fB\-nostdinc\fR" 4
+.IX Item "-nostdinc"
+Do not search the standard system directories for header files.
+Only the directories you have specified with \fB\-I\fR options
+(and the directory of the current file, if appropriate) are searched.
+.IP "\fB\-nostdinc++\fR" 4
+.IX Item "-nostdinc++"
+Do not search for header files in the \*(C+\-specific standard directories,
+but do still search the other standard directories.  (This option is
+used when building the \*(C+ library.)
+.IP "\fB\-include\fR \fIfile\fR" 4
+.IX Item "-include file"
+Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
+line of the primary source file.  However, the first directory searched
+for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
+the directory containing the main source file.  If not found there, it
+is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
+chain as normal.
+.Sp
+If multiple \fB\-include\fR options are given, the files are included
+in the order they appear on the command line.
+.IP "\fB\-imacros\fR \fIfile\fR" 4
+.IX Item "-imacros file"
+Exactly like \fB\-include\fR, except that any output produced by
+scanning \fIfile\fR is thrown away.  Macros it defines remain defined.
+This allows you to acquire all the macros from a header without also
+processing its declarations.
+.Sp
+All files specified by \fB\-imacros\fR are processed before all files
+specified by \fB\-include\fR.
+.IP "\fB\-idirafter\fR \fIdir\fR" 4
+.IX Item "-idirafter dir"
+Search \fIdir\fR for header files, but do it \fIafter\fR all
+directories specified with \fB\-I\fR and the standard system directories
+have been exhausted.  \fIdir\fR is treated as a system include directory.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-iprefix\fR \fIprefix\fR" 4
+.IX Item "-iprefix prefix"
+Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
+options.  If the prefix represents a directory, you should include the
+final \fB/\fR.
+.IP "\fB\-iwithprefix\fR \fIdir\fR" 4
+.IX Item "-iwithprefix dir"
+.PD 0
+.IP "\fB\-iwithprefixbefore\fR \fIdir\fR" 4
+.IX Item "-iwithprefixbefore dir"
+.PD
+Append \fIdir\fR to the prefix specified previously with
+\&\fB\-iprefix\fR, and add the resulting directory to the include search
+path.  \fB\-iwithprefixbefore\fR puts it in the same place \fB\-I\fR
+would; \fB\-iwithprefix\fR puts it where \fB\-idirafter\fR would.
+.IP "\fB\-isysroot\fR \fIdir\fR" 4
+.IX Item "-isysroot dir"
+This option is like the \fB\-\-sysroot\fR option, but applies only to
+header files (except for Darwin targets, where it applies to both header
+files and libraries).  See the \fB\-\-sysroot\fR option for more
+information.
+.IP "\fB\-imultilib\fR \fIdir\fR" 4
+.IX Item "-imultilib dir"
+Use \fIdir\fR as a subdirectory of the directory containing
+target-specific \*(C+ headers.
+.IP "\fB\-isystem\fR \fIdir\fR" 4
+.IX Item "-isystem dir"
+Search \fIdir\fR for header files, after all directories specified by
+\&\fB\-I\fR but before the standard system directories.  Mark it
+as a system directory, so that it gets the same special treatment as
+is applied to the standard system directories.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-iquote\fR \fIdir\fR" 4
+.IX Item "-iquote dir"
+Search \fIdir\fR only for header files requested with
+\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
+\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR, before all directories specified by
+\&\fB\-I\fR and before the standard system directories.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-fdirectives\-only\fR" 4
+.IX Item "-fdirectives-only"
+When preprocessing, handle directives, but do not expand macros.
+.Sp
+The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
+options.
+.Sp
+With \fB\-E\fR, preprocessing is limited to the handling of directives
+such as \f(CW\*(C`#define\*(C'\fR, \f(CW\*(C`#ifdef\*(C'\fR, and \f(CW\*(C`#error\*(C'\fR.  Other
+preprocessor operations, such as macro expansion and trigraph
+conversion are not performed.  In addition, the \fB\-dD\fR option is
+implicitly enabled.
+.Sp
+With \fB\-fpreprocessed\fR, predefinition of command line and most
+builtin macros is disabled.  Macros such as \f(CW\*(C`_\|_LINE_\|_\*(C'\fR, which are
+contextually dependent, are handled normally.  This enables compilation of
+files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
+.Sp
+With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
+\&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
+files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
+.IP "\fB\-fdollars\-in\-identifiers\fR" 4
+.IX Item "-fdollars-in-identifiers"
+Accept \fB$\fR in identifiers.
+.IP "\fB\-fextended\-identifiers\fR" 4
+.IX Item "-fextended-identifiers"
+Accept universal character names in identifiers.  This option is
+experimental; in a future version of \s-1GCC,\s0 it will be enabled by
+default for C99 and \*(C+.
+.IP "\fB\-fno\-canonical\-system\-headers\fR" 4
+.IX Item "-fno-canonical-system-headers"
+When preprocessing, do not shorten system header paths with canonicalization.
+.IP "\fB\-fpreprocessed\fR" 4
+.IX Item "-fpreprocessed"
+Indicate to the preprocessor that the input file has already been
+preprocessed.  This suppresses things like macro expansion, trigraph
+conversion, escaped newline splicing, and processing of most directives.
+The preprocessor still recognizes and removes comments, so that you can
+pass a file preprocessed with \fB\-C\fR to the compiler without
+problems.  In this mode the integrated preprocessor is little more than
+a tokenizer for the front ends.
+.Sp
+\&\fB\-fpreprocessed\fR is implicit if the input file has one of the
+extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
+extensions that \s-1GCC\s0 uses for preprocessed files created by
+\&\fB\-save\-temps\fR.
+.IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
+.IX Item "-ftabstop=width"
+Set the distance between tab stops.  This helps the preprocessor report
+correct column numbers in warnings or errors, even if tabs appear on the
+line.  If the value is less than 1 or greater than 100, the option is
+ignored.  The default is 8.
+.IP "\fB\-fdebug\-cpp\fR" 4
+.IX Item "-fdebug-cpp"
+This option is only useful for debugging \s-1GCC. \s0 When used with
+\&\fB\-E\fR, dumps debugging information about location maps.  Every
+token in the output is preceded by the dump of the map its location
+belongs to.  The dump of the map holding the location of a token would
+be:
+.Sp
+.Vb 1
+\&        {"P":F</file/path>;"F":F</includer/path>;"L":<line_num>;"C":<col_num>;"S":<system_header_p>;"M":<map_address>;"E":<macro_expansion_p>,"loc":<location>}
+.Ve
+.Sp
+When used without \fB\-E\fR, this option has no effect.
+.IP "\fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR]" 4
+.IX Item "-ftrack-macro-expansion[=level]"
+Track locations of tokens across macro expansions. This allows the
+compiler to emit diagnostic about the current macro expansion stack
+when a compilation error occurs in a macro expansion. Using this
+option makes the preprocessor and the compiler consume more
+memory. The \fIlevel\fR parameter can be used to choose the level of
+precision of token location tracking thus decreasing the memory
+consumption if necessary. Value \fB0\fR of \fIlevel\fR de-activates
+this option just as if no \fB\-ftrack\-macro\-expansion\fR was present
+on the command line. Value \fB1\fR tracks tokens locations in a
+degraded mode for the sake of minimal memory overhead. In this mode
+all tokens resulting from the expansion of an argument of a
+function-like macro have the same location. Value \fB2\fR tracks
+tokens locations completely. This value is the most memory hungry.
+When this option is given no argument, the default parameter value is
+\&\fB2\fR.
+.Sp
+Note that \-ftrack\-macro\-expansion=2 is activated by default.
+.IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
+.IX Item "-fexec-charset=charset"
+Set the execution character set, used for string and character
+constants.  The default is \s-1UTF\-8.  \s0\fIcharset\fR can be any encoding
+supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
+.IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
+.IX Item "-fwide-exec-charset=charset"
+Set the wide execution character set, used for wide string and
+character constants.  The default is \s-1UTF\-32\s0 or \s-1UTF\-16,\s0 whichever
+corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR.  As with
+\&\fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
+by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
+problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
+.IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
+.IX Item "-finput-charset=charset"
+Set the input character set, used for translation from the character
+set of the input file to the source character set used by \s-1GCC. \s0 If the
+locale does not specify, or \s-1GCC\s0 cannot get this information from the
+locale, the default is \s-1UTF\-8. \s0 This can be overridden by either the locale
+or this command line option.  Currently the command line option takes
+precedence if there's a conflict.  \fIcharset\fR can be any encoding
+supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
+.IP "\fB\-fworking\-directory\fR" 4
+.IX Item "-fworking-directory"
+Enable generation of linemarkers in the preprocessor output that will
+let the compiler know the current working directory at the time of
+preprocessing.  When this option is enabled, the preprocessor will
+emit, after the initial linemarker, a second linemarker with the
+current working directory followed by two slashes.  \s-1GCC\s0 will use this
+directory, when it's present in the preprocessed input, as the
+directory emitted as the current working directory in some debugging
+information formats.  This option is implicitly enabled if debugging
+information is enabled, but this can be inhibited with the negated
+form \fB\-fno\-working\-directory\fR.  If the \fB\-P\fR flag is
+present in the command line, this option has no effect, since no
+\&\f(CW\*(C`#line\*(C'\fR directives are emitted whatsoever.
+.IP "\fB\-fno\-show\-column\fR" 4
+.IX Item "-fno-show-column"
+Do not print column numbers in diagnostics.  This may be necessary if
+diagnostics are being scanned by a program that does not understand the
+column numbers, such as \fBdejagnu\fR.
+.IP "\fB\-A\fR \fIpredicate\fR\fB=\fR\fIanswer\fR" 4
+.IX Item "-A predicate=answer"
+Make an assertion with the predicate \fIpredicate\fR and answer
+\&\fIanswer\fR.  This form is preferred to the older form \fB\-A\fR
+\&\fIpredicate\fR\fB(\fR\fIanswer\fR\fB)\fR, which is still supported, because
+it does not use shell special characters.
+.IP "\fB\-A \-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
+.IX Item "-A -predicate=answer"
+Cancel an assertion with the predicate \fIpredicate\fR and answer
+\&\fIanswer\fR.
+.IP "\fB\-dCHARS\fR" 4
+.IX Item "-dCHARS"
+\&\fI\s-1CHARS\s0\fR is a sequence of one or more of the following characters,
+and must not be preceded by a space.  Other characters are interpreted
+by the compiler proper, or reserved for future versions of \s-1GCC,\s0 and so
+are silently ignored.  If you specify characters whose behavior
+conflicts, the result is undefined.
+.RS 4
+.IP "\fBM\fR" 4
+.IX Item "M"
+Instead of the normal output, generate a list of \fB#define\fR
+directives for all the macros defined during the execution of the
+preprocessor, including predefined macros.  This gives you a way of
+finding out what is predefined in your version of the preprocessor.
+Assuming you have no file \fIfoo.h\fR, the command
+.Sp
+.Vb 1
+\&        touch foo.h; cpp \-dM foo.h
+.Ve
+.Sp
+will show all the predefined macros.
+.Sp
+If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
+interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
+.IP "\fBD\fR" 4
+.IX Item "D"
+Like \fBM\fR except in two respects: it does \fInot\fR include the
+predefined macros, and it outputs \fIboth\fR the \fB#define\fR
+directives and the result of preprocessing.  Both kinds of output go to
+the standard output file.
+.IP "\fBN\fR" 4
+.IX Item "N"
+Like \fBD\fR, but emit only the macro names, not their expansions.
+.IP "\fBI\fR" 4
+.IX Item "I"
+Output \fB#include\fR directives in addition to the result of
+preprocessing.
+.IP "\fBU\fR" 4
+.IX Item "U"
+Like \fBD\fR except that only macros that are expanded, or whose
+definedness is tested in preprocessor directives, are output; the
+output is delayed until the use or test of the macro; and
+\&\fB#undef\fR directives are also output for macros tested but
+undefined at the time.
+.RE
+.RS 4
+.RE
+.IP "\fB\-P\fR" 4
+.IX Item "-P"
+Inhibit generation of linemarkers in the output from the preprocessor.
+This might be useful when running the preprocessor on something that is
+not C code, and will be sent to a program which might be confused by the
+linemarkers.
+.IP "\fB\-C\fR" 4
+.IX Item "-C"
+Do not discard comments.  All comments are passed through to the output
+file, except for comments in processed directives, which are deleted
+along with the directive.
+.Sp
+You should be prepared for side effects when using \fB\-C\fR; it
+causes the preprocessor to treat comments as tokens in their own right.
+For example, comments appearing at the start of what would be a
+directive line have the effect of turning that line into an ordinary
+source line, since the first token on the line is no longer a \fB#\fR.
+.IP "\fB\-CC\fR" 4
+.IX Item "-CC"
+Do not discard comments, including during macro expansion.  This is
+like \fB\-C\fR, except that comments contained within macros are
+also passed through to the output file where the macro is expanded.
+.Sp
+In addition to the side-effects of the \fB\-C\fR option, the
+\&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
+to be converted to C\-style comments.  This is to prevent later use
+of that macro from inadvertently commenting out the remainder of
+the source line.
+.Sp
+The \fB\-CC\fR option is generally used to support lint comments.
+.IP "\fB\-traditional\-cpp\fR" 4
+.IX Item "-traditional-cpp"
+Try to imitate the behavior of old-fashioned C preprocessors, as
+opposed to \s-1ISO C\s0 preprocessors.
+.IP "\fB\-trigraphs\fR" 4
+.IX Item "-trigraphs"
+Process trigraph sequences.
+These are three-character sequences, all starting with \fB??\fR, that
+are defined by \s-1ISO C\s0 to stand for single characters.  For example,
+\&\fB??/\fR stands for \fB\e\fR, so \fB'??/n'\fR is a character
+constant for a newline.  By default, \s-1GCC\s0 ignores trigraphs, but in
+standard-conforming modes it converts them.  See the \fB\-std\fR and
+\&\fB\-ansi\fR options.
+.Sp
+The nine trigraphs and their replacements are
+.Sp
+.Vb 2
+\&        Trigraph:       ??(  ??)  ??<  ??>  ??=  ??/  ??\*(Aq  ??!  ??\-
+\&        Replacement:      [    ]    {    }    #    \e    ^    |    ~
+.Ve
+.IP "\fB\-remap\fR" 4
+.IX Item "-remap"
+Enable special code to work around file systems which only permit very
+short file names, such as MS-DOS.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+.PD 0
+.IP "\fB\-\-target\-help\fR" 4
+.IX Item "--target-help"
+.PD
+Print text describing all the command line options instead of
+preprocessing anything.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+Verbose mode.  Print out \s-1GNU CPP\s0's version number at the beginning of
+execution, and report the final form of the include path.
+.IP "\fB\-H\fR" 4
+.IX Item "-H"
+Print the name of each header file used, in addition to other normal
+activities.  Each name is indented to show how deep in the
+\&\fB#include\fR stack it is.  Precompiled header files are also
+printed, even if they are found to be invalid; an invalid precompiled
+header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
+.IP "\fB\-version\fR" 4
+.IX Item "-version"
+.PD 0
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+.PD
+Print out \s-1GNU CPP\s0's version number.  With one dash, proceed to
+preprocess as normal.  With two dashes, exit immediately.
+.SS "Passing Options to the Assembler"
+.IX Subsection "Passing Options to the Assembler"
+You can pass options to the assembler.
+.IP "\fB\-Wa,\fR\fIoption\fR" 4
+.IX Item "-Wa,option"
+Pass \fIoption\fR as an option to the assembler.  If \fIoption\fR
+contains commas, it is split into multiple options at the commas.
+.IP "\fB\-Xassembler\fR \fIoption\fR" 4
+.IX Item "-Xassembler option"
+Pass \fIoption\fR as an option to the assembler.  You can use this to
+supply system-specific assembler options that \s-1GCC\s0 does not
+recognize.
+.Sp
+If you want to pass an option that takes an argument, you must use
+\&\fB\-Xassembler\fR twice, once for the option and once for the argument.
+.SS "Options for Linking"
+.IX Subsection "Options for Linking"
+These options come into play when the compiler links object files into
+an executable output file.  They are meaningless if the compiler is
+not doing a link step.
+.IP "\fIobject-file-name\fR" 4
+.IX Item "object-file-name"
+A file name that does not end in a special recognized suffix is
+considered to name an object file or library.  (Object files are
+distinguished from libraries by the linker according to the file
+contents.)  If linking is done, these object files are used as input
+to the linker.
+.IP "\fB\-c\fR" 4
+.IX Item "-c"
+.PD 0
+.IP "\fB\-S\fR" 4
+.IX Item "-S"
+.IP "\fB\-E\fR" 4
+.IX Item "-E"
+.PD
+If any of these options is used, then the linker is not run, and
+object file names should not be used as arguments.
+.IP "\fB\-l\fR\fIlibrary\fR" 4
+.IX Item "-llibrary"
+.PD 0
+.IP "\fB\-l\fR \fIlibrary\fR" 4
+.IX Item "-l library"
+.PD
+Search the library named \fIlibrary\fR when linking.  (The second
+alternative with the library as a separate argument is only for
+\&\s-1POSIX\s0 compliance and is not recommended.)
+.Sp
+It makes a difference where in the command you write this option; the
+linker searches and processes libraries and object files in the order they
+are specified.  Thus, \fBfoo.o \-lz bar.o\fR searches library \fBz\fR
+after file \fIfoo.o\fR but before \fIbar.o\fR.  If \fIbar.o\fR refers
+to functions in \fBz\fR, those functions may not be loaded.
+.Sp
+The linker searches a standard list of directories for the library,
+which is actually a file named \fIlib\fIlibrary\fI.a\fR.  The linker
+then uses this file as if it had been specified precisely by name.
+.Sp
+The directories searched include several standard system directories
+plus any that you specify with \fB\-L\fR.
+.Sp
+Normally the files found this way are library files\-\-\-archive files
+whose members are object files.  The linker handles an archive file by
+scanning through it for members which define symbols that have so far
+been referenced but not defined.  But if the file that is found is an
+ordinary object file, it is linked in the usual fashion.  The only
+difference between using an \fB\-l\fR option and specifying a file name
+is that \fB\-l\fR surrounds \fIlibrary\fR with \fBlib\fR and \fB.a\fR
+and searches several directories.
+.IP "\fB\-lobjc\fR" 4
+.IX Item "-lobjc"
+You need this special case of the \fB\-l\fR option in order to
+link an Objective-C or Objective\-\*(C+ program.
+.IP "\fB\-nostartfiles\fR" 4
+.IX Item "-nostartfiles"
+Do not use the standard system startup files when linking.
+The standard system libraries are used normally, unless \fB\-nostdlib\fR
+or \fB\-nodefaultlibs\fR is used.
+.IP "\fB\-nodefaultlibs\fR" 4
+.IX Item "-nodefaultlibs"
+Do not use the standard system libraries when linking.
+Only the libraries you specify are passed to the linker, and options
+specifying linkage of the system libraries, such as \f(CW\*(C`\-static\-libgcc\*(C'\fR
+or \f(CW\*(C`\-shared\-libgcc\*(C'\fR, are ignored.  
+The standard startup files are used normally, unless \fB\-nostartfiles\fR
+is used.
+.Sp
+The compiler may generate calls to \f(CW\*(C`memcmp\*(C'\fR,
+\&\f(CW\*(C`memset\*(C'\fR, \f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR.
+These entries are usually resolved by entries in
+libc.  These entry points should be supplied through some other
+mechanism when this option is specified.
+.IP "\fB\-nostdlib\fR" 4
+.IX Item "-nostdlib"
+Do not use the standard system startup files or libraries when linking.
+No startup files and only the libraries you specify are passed to
+the linker, and options specifying linkage of the system libraries, such as
+\&\f(CW\*(C`\-static\-libgcc\*(C'\fR or \f(CW\*(C`\-shared\-libgcc\*(C'\fR, are ignored.
+.Sp
+The compiler may generate calls to \f(CW\*(C`memcmp\*(C'\fR, \f(CW\*(C`memset\*(C'\fR,
+\&\f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR.
+These entries are usually resolved by entries in
+libc.  These entry points should be supplied through some other
+mechanism when this option is specified.
+.Sp
+One of the standard libraries bypassed by \fB\-nostdlib\fR and
+\&\fB\-nodefaultlibs\fR is \fIlibgcc.a\fR, a library of internal subroutines
+which \s-1GCC\s0 uses to overcome shortcomings of particular machines, or special
+needs for some languages.
+.Sp
+In most cases, you need \fIlibgcc.a\fR even when you want to avoid
+other standard libraries.  In other words, when you specify \fB\-nostdlib\fR
+or \fB\-nodefaultlibs\fR you should usually specify \fB\-lgcc\fR as well.
+This ensures that you have no unresolved references to internal \s-1GCC\s0
+library subroutines.
+(An example of such an internal subroutine is \fB_\|_main\fR, used to ensure \*(C+
+constructors are called.)
+.IP "\fB\-pie\fR" 4
+.IX Item "-pie"
+Produce a position independent executable on targets that support it.
+For predictable results, you must also specify the same set of options
+used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR,
+or model suboptions) when you specify this linker option.
+.IP "\fB\-rdynamic\fR" 4
+.IX Item "-rdynamic"
+Pass the flag \fB\-export\-dynamic\fR to the \s-1ELF\s0 linker, on targets
+that support it. This instructs the linker to add all symbols, not
+only used ones, to the dynamic symbol table. This option is needed
+for some uses of \f(CW\*(C`dlopen\*(C'\fR or to allow obtaining backtraces
+from within a program.
+.IP "\fB\-s\fR" 4
+.IX Item "-s"
+Remove all symbol table and relocation information from the executable.
+.IP "\fB\-static\fR" 4
+.IX Item "-static"
+On systems that support dynamic linking, this prevents linking with the shared
+libraries.  On other systems, this option has no effect.
+.IP "\fB\-shared\fR" 4
+.IX Item "-shared"
+Produce a shared object which can then be linked with other objects to
+form an executable.  Not all systems support this option.  For predictable
+results, you must also specify the same set of options used for compilation
+(\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions) when
+you specify this linker option.[1]
+.IP "\fB\-shared\-libgcc\fR" 4
+.IX Item "-shared-libgcc"
+.PD 0
+.IP "\fB\-static\-libgcc\fR" 4
+.IX Item "-static-libgcc"
+.PD
+On systems that provide \fIlibgcc\fR as a shared library, these options
+force the use of either the shared or static version, respectively.
+If no shared version of \fIlibgcc\fR was built when the compiler was
+configured, these options have no effect.
+.Sp
+There are several situations in which an application should use the
+shared \fIlibgcc\fR instead of the static version.  The most common
+of these is when the application wishes to throw and catch exceptions
+across different shared libraries.  In that case, each of the libraries
+as well as the application itself should use the shared \fIlibgcc\fR.
+.Sp
+Therefore, the G++ and \s-1GCJ\s0 drivers automatically add
+\&\fB\-shared\-libgcc\fR whenever you build a shared library or a main
+executable, because \*(C+ and Java programs typically use exceptions, so
+this is the right thing to do.
+.Sp
+If, instead, you use the \s-1GCC\s0 driver to create shared libraries, you may
+find that they are not always linked with the shared \fIlibgcc\fR.
+If \s-1GCC\s0 finds, at its configuration time, that you have a non-GNU linker
+or a \s-1GNU\s0 linker that does not support option \fB\-\-eh\-frame\-hdr\fR,
+it links the shared version of \fIlibgcc\fR into shared libraries
+by default.  Otherwise, it takes advantage of the linker and optimizes
+away the linking with the shared version of \fIlibgcc\fR, linking with
+the static version of libgcc by default.  This allows exceptions to
+propagate through such shared libraries, without incurring relocation
+costs at library load time.
+.Sp
+However, if a library or main executable is supposed to throw or catch
+exceptions, you must link it using the G++ or \s-1GCJ\s0 driver, as appropriate
+for the languages used in the program, or using the option
+\&\fB\-shared\-libgcc\fR, such that it is linked with the shared
+\&\fIlibgcc\fR.
+.IP "\fB\-static\-libasan\fR" 4
+.IX Item "-static-libasan"
+When the \fB\-fsanitize=address\fR option is used to link a program,
+the \s-1GCC\s0 driver automatically links against \fBlibasan\fR.  If
+\&\fIlibasan\fR is available as a shared library, and the \fB\-static\fR
+option is not used, then this links against the shared version of
+\&\fIlibasan\fR.  The \fB\-static\-libasan\fR option directs the \s-1GCC\s0
+driver to link \fIlibasan\fR statically, without necessarily linking
+other libraries statically.
+.IP "\fB\-static\-libtsan\fR" 4
+.IX Item "-static-libtsan"
+When the \fB\-fsanitize=thread\fR option is used to link a program,
+the \s-1GCC\s0 driver automatically links against \fBlibtsan\fR.  If
+\&\fIlibtsan\fR is available as a shared library, and the \fB\-static\fR
+option is not used, then this links against the shared version of
+\&\fIlibtsan\fR.  The \fB\-static\-libtsan\fR option directs the \s-1GCC\s0
+driver to link \fIlibtsan\fR statically, without necessarily linking
+other libraries statically.
+.IP "\fB\-static\-liblsan\fR" 4
+.IX Item "-static-liblsan"
+When the \fB\-fsanitize=leak\fR option is used to link a program,
+the \s-1GCC\s0 driver automatically links against \fBliblsan\fR.  If
+\&\fIliblsan\fR is available as a shared library, and the \fB\-static\fR
+option is not used, then this links against the shared version of
+\&\fIliblsan\fR.  The \fB\-static\-liblsan\fR option directs the \s-1GCC\s0
+driver to link \fIliblsan\fR statically, without necessarily linking
+other libraries statically.
+.IP "\fB\-static\-libubsan\fR" 4
+.IX Item "-static-libubsan"
+When the \fB\-fsanitize=undefined\fR option is used to link a program,
+the \s-1GCC\s0 driver automatically links against \fBlibubsan\fR.  If
+\&\fIlibubsan\fR is available as a shared library, and the \fB\-static\fR
+option is not used, then this links against the shared version of
+\&\fIlibubsan\fR.  The \fB\-static\-libubsan\fR option directs the \s-1GCC\s0
+driver to link \fIlibubsan\fR statically, without necessarily linking
+other libraries statically.
+.IP "\fB\-static\-libstdc++\fR" 4
+.IX Item "-static-libstdc++"
+When the \fBg++\fR program is used to link a \*(C+ program, it
+normally automatically links against \fBlibstdc++\fR.  If
+\&\fIlibstdc++\fR is available as a shared library, and the
+\&\fB\-static\fR option is not used, then this links against the
+shared version of \fIlibstdc++\fR.  That is normally fine.  However, it
+is sometimes useful to freeze the version of \fIlibstdc++\fR used by
+the program without going all the way to a fully static link.  The
+\&\fB\-static\-libstdc++\fR option directs the \fBg++\fR driver to
+link \fIlibstdc++\fR statically, without necessarily linking other
+libraries statically.
+.IP "\fB\-symbolic\fR" 4
+.IX Item "-symbolic"
+Bind references to global symbols when building a shared object.  Warn
+about any unresolved references (unless overridden by the link editor
+option \fB\-Xlinker \-z \-Xlinker defs\fR).  Only a few systems support
+this option.
+.IP "\fB\-T\fR \fIscript\fR" 4
+.IX Item "-T script"
+Use \fIscript\fR as the linker script.  This option is supported by most
+systems using the \s-1GNU\s0 linker.  On some targets, such as bare-board
+targets without an operating system, the \fB\-T\fR option may be required
+when linking to avoid references to undefined symbols.
+.IP "\fB\-Xlinker\fR \fIoption\fR" 4
+.IX Item "-Xlinker option"
+Pass \fIoption\fR as an option to the linker.  You can use this to
+supply system-specific linker options that \s-1GCC\s0 does not recognize.
+.Sp
+If you want to pass an option that takes a separate argument, you must use
+\&\fB\-Xlinker\fR twice, once for the option and once for the argument.
+For example, to pass \fB\-assert definitions\fR, you must write
+\&\fB\-Xlinker \-assert \-Xlinker definitions\fR.  It does not work to write
+\&\fB\-Xlinker \*(L"\-assert definitions\*(R"\fR, because this passes the entire
+string as a single argument, which is not what the linker expects.
+.Sp
+When using the \s-1GNU\s0 linker, it is usually more convenient to pass
+arguments to linker options using the \fIoption\fR\fB=\fR\fIvalue\fR
+syntax than as separate arguments.  For example, you can specify
+\&\fB\-Xlinker \-Map=output.map\fR rather than
+\&\fB\-Xlinker \-Map \-Xlinker output.map\fR.  Other linkers may not support
+this syntax for command-line options.
+.IP "\fB\-Wl,\fR\fIoption\fR" 4
+.IX Item "-Wl,option"
+Pass \fIoption\fR as an option to the linker.  If \fIoption\fR contains
+commas, it is split into multiple options at the commas.  You can use this
+syntax to pass an argument to the option.
+For example, \fB\-Wl,\-Map,output.map\fR passes \fB\-Map output.map\fR to the
+linker.  When using the \s-1GNU\s0 linker, you can also get the same effect with
+\&\fB\-Wl,\-Map=output.map\fR.
+.IP "\fB\-u\fR \fIsymbol\fR" 4
+.IX Item "-u symbol"
+Pretend the symbol \fIsymbol\fR is undefined, to force linking of
+library modules to define it.  You can use \fB\-u\fR multiple times with
+different symbols to force loading of additional library modules.
+.SS "Options for Directory Search"
+.IX Subsection "Options for Directory Search"
+These options specify directories to search for header files, for
+libraries and for parts of the compiler:
+.IP "\fB\-I\fR\fIdir\fR" 4
+.IX Item "-Idir"
+Add the directory \fIdir\fR to the head of the list of directories to be
+searched for header files.  This can be used to override a system header
+file, substituting your own version, since these directories are
+searched before the system header file directories.  However, you should
+not use this option to add directories that contain vendor-supplied
+system header files (use \fB\-isystem\fR for that).  If you use more than
+one \fB\-I\fR option, the directories are scanned in left-to-right
+order; the standard system directories come after.
+.Sp
+If a standard system include directory, or a directory specified with
+\&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
+option is ignored.  The directory is still searched but as a
+system directory at its normal position in the system include chain.
+This is to ensure that \s-1GCC\s0's procedure to fix buggy system headers and
+the ordering for the \f(CW\*(C`include_next\*(C'\fR directive are not inadvertently changed.
+If you really need to change the search order for system directories,
+use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
+.IP "\fB\-iplugindir=\fR\fIdir\fR" 4
+.IX Item "-iplugindir=dir"
+Set the directory to search for plugins that are passed
+by \fB\-fplugin=\fR\fIname\fR instead of
+\&\fB\-fplugin=\fR\fIpath\fR\fB/\fR\fIname\fR\fB.so\fR.  This option is not meant
+to be used by the user, but only passed by the driver.
+.IP "\fB\-iquote\fR\fIdir\fR" 4
+.IX Item "-iquotedir"
+Add the directory \fIdir\fR to the head of the list of directories to
+be searched for header files only for the case of \fB#include
+"\fR\fIfile\fR\fB"\fR; they are not searched for \fB#include <\fR\fIfile\fR\fB>\fR,
+otherwise just like \fB\-I\fR.
+.IP "\fB\-L\fR\fIdir\fR" 4
+.IX Item "-Ldir"
+Add directory \fIdir\fR to the list of directories to be searched
+for \fB\-l\fR.
+.IP "\fB\-B\fR\fIprefix\fR" 4
+.IX Item "-Bprefix"
+This option specifies where to find the executables, libraries,
+include files, and data files of the compiler itself.
+.Sp
+The compiler driver program runs one or more of the subprograms
+\&\fBcpp\fR, \fBcc1\fR, \fBas\fR and \fBld\fR.  It tries
+\&\fIprefix\fR as a prefix for each program it tries to run, both with and
+without \fImachine\fR\fB/\fR\fIversion\fR\fB/\fR.
+.Sp
+For each subprogram to be run, the compiler driver first tries the
+\&\fB\-B\fR prefix, if any.  If that name is not found, or if \fB\-B\fR
+is not specified, the driver tries two standard prefixes, 
+\&\fI/usr/lib/gcc/\fR and \fI/usr/local/lib/gcc/\fR.  If neither of
+those results in a file name that is found, the unmodified program
+name is searched for using the directories specified in your
+\&\fB\s-1PATH\s0\fR environment variable.
+.Sp
+The compiler checks to see if the path provided by the \fB\-B\fR
+refers to a directory, and if necessary it adds a directory
+separator character at the end of the path.
+.Sp
+\&\fB\-B\fR prefixes that effectively specify directory names also apply
+to libraries in the linker, because the compiler translates these
+options into \fB\-L\fR options for the linker.  They also apply to
+include files in the preprocessor, because the compiler translates these
+options into \fB\-isystem\fR options for the preprocessor.  In this case,
+the compiler appends \fBinclude\fR to the prefix.
+.Sp
+The runtime support file \fIlibgcc.a\fR can also be searched for using
+the \fB\-B\fR prefix, if needed.  If it is not found there, the two
+standard prefixes above are tried, and that is all.  The file is left
+out of the link if it is not found by those means.
+.Sp
+Another way to specify a prefix much like the \fB\-B\fR prefix is to use
+the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR.
+.Sp
+As a special kludge, if the path provided by \fB\-B\fR is
+\&\fI[dir/]stage\fIN\fI/\fR, where \fIN\fR is a number in the range 0 to
+9, then it is replaced by \fI[dir/]include\fR.  This is to help
+with boot-strapping the compiler.
+.IP "\fB\-specs=\fR\fIfile\fR" 4
+.IX Item "-specs=file"
+Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR
+file, in order to override the defaults which the \fBgcc\fR driver
+program uses when determining what switches to pass to \fBcc1\fR,
+\&\fBcc1plus\fR, \fBas\fR, \fBld\fR, etc.  More than one
+\&\fB\-specs=\fR\fIfile\fR can be specified on the command line, and they
+are processed in order, from left to right.
+.IP "\fB\-\-sysroot=\fR\fIdir\fR" 4
+.IX Item "--sysroot=dir"
+Use \fIdir\fR as the logical root directory for headers and libraries.
+For example, if the compiler normally searches for headers in
+\&\fI/usr/include\fR and libraries in \fI/usr/lib\fR, it instead
+searches \fI\fIdir\fI/usr/include\fR and \fI\fIdir\fI/usr/lib\fR.
+.Sp
+If you use both this option and the \fB\-isysroot\fR option, then
+the \fB\-\-sysroot\fR option applies to libraries, but the
+\&\fB\-isysroot\fR option applies to header files.
+.Sp
+The \s-1GNU\s0 linker (beginning with version 2.16) has the necessary support
+for this option.  If your linker does not support this option, the
+header file aspect of \fB\-\-sysroot\fR still works, but the
+library aspect does not.
+.IP "\fB\-\-no\-sysroot\-suffix\fR" 4
+.IX Item "--no-sysroot-suffix"
+For some targets, a suffix is added to the root directory specified
+with \fB\-\-sysroot\fR, depending on the other options used, so that
+headers may for example be found in
+\&\fI\fIdir\fI/\fIsuffix\fI/usr/include\fR instead of
+\&\fI\fIdir\fI/usr/include\fR.  This option disables the addition of
+such a suffix.
+.IP "\fB\-I\-\fR" 4
+.IX Item "-I-"
+This option has been deprecated.  Please use \fB\-iquote\fR instead for
+\&\fB\-I\fR directories before the \fB\-I\-\fR and remove the \fB\-I\-\fR.
+Any directories you specify with \fB\-I\fR options before the \fB\-I\-\fR
+option are searched only for the case of \fB#include "\fR\fIfile\fR\fB"\fR;
+they are not searched for \fB#include <\fR\fIfile\fR\fB>\fR.
+.Sp
+If additional directories are specified with \fB\-I\fR options after
+the \fB\-I\-\fR, these directories are searched for all \fB#include\fR
+directives.  (Ordinarily \fIall\fR \fB\-I\fR directories are used
+this way.)
+.Sp
+In addition, the \fB\-I\-\fR option inhibits the use of the current
+directory (where the current input file came from) as the first search
+directory for \fB#include "\fR\fIfile\fR\fB"\fR.  There is no way to
+override this effect of \fB\-I\-\fR.  With \fB\-I.\fR you can specify
+searching the directory that is current when the compiler is
+invoked.  That is not exactly the same as what the preprocessor does
+by default, but it is often satisfactory.
+.Sp
+\&\fB\-I\-\fR does not inhibit the use of the standard system directories
+for header files.  Thus, \fB\-I\-\fR and \fB\-nostdinc\fR are
+independent.
+.SS "Specifying Target Machine and Compiler Version"
+.IX Subsection "Specifying Target Machine and Compiler Version"
+The usual way to run \s-1GCC\s0 is to run the executable called \fBgcc\fR, or
+\&\fImachine\fR\fB\-gcc\fR when cross-compiling, or
+\&\fImachine\fR\fB\-gcc\-\fR\fIversion\fR to run a version other than the
+one that was installed last.
+.SS "Hardware Models and Configurations"
+.IX Subsection "Hardware Models and Configurations"
+Each target machine types can have its own
+special options, starting with \fB\-m\fR, to choose among various
+hardware models or configurations\-\-\-for example, 68010 vs 68020,
+floating coprocessor or none.  A single installed version of the
+compiler can compile for any model or configuration, according to the
+options specified.
+.PP
+Some configurations of the compiler also support additional special
+options, usually for compatibility with other compilers on the same
+platform.
+.PP
+\fIAArch64 Options\fR
+.IX Subsection "AArch64 Options"
+.PP
+These options are defined for AArch64 implementations:
+.IP "\fB\-mabi=\fR\fIname\fR" 4
+.IX Item "-mabi=name"
+Generate code for the specified data model.  Permissible values
+are \fBilp32\fR for SysV-like data model where int, long int and pointer
+are 32\-bit, and \fBlp64\fR for SysV-like data model where int is 32\-bit,
+but long int and pointer are 64\-bit.
+.Sp
+The default depends on the specific target configuration.  Note that
+the \s-1LP64\s0 and \s-1ILP32\s0 ABIs are not link-compatible; you must compile your
+entire program with the same \s-1ABI,\s0 and link with a compatible set of libraries.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate big-endian code.  This is the default when \s-1GCC\s0 is configured for an
+\&\fBaarch64_be\-*\-*\fR target.
+.IP "\fB\-mgeneral\-regs\-only\fR" 4
+.IX Item "-mgeneral-regs-only"
+Generate code which uses only the general registers.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate little-endian code.  This is the default when \s-1GCC\s0 is configured for an
+\&\fBaarch64\-*\-*\fR but not an \fBaarch64_be\-*\-*\fR target.
+.IP "\fB\-mcmodel=tiny\fR" 4
+.IX Item "-mcmodel=tiny"
+Generate code for the tiny code model.  The program and its statically defined
+symbols must be within 1GB of each other.  Pointers are 64 bits.  Programs can
+be statically or dynamically linked.  This model is not fully implemented and
+mostly treated as \fBsmall\fR.
+.IP "\fB\-mcmodel=small\fR" 4
+.IX Item "-mcmodel=small"
+Generate code for the small code model.  The program and its statically defined
+symbols must be within 4GB of each other.  Pointers are 64 bits.  Programs can
+be statically or dynamically linked.  This is the default code model.
+.IP "\fB\-mcmodel=large\fR" 4
+.IX Item "-mcmodel=large"
+Generate code for the large code model.  This makes no assumptions about
+addresses and sizes of sections.  Pointers are 64 bits.  Programs can be
+statically linked only.
+.IP "\fB\-mstrict\-align\fR" 4
+.IX Item "-mstrict-align"
+Do not assume that unaligned memory references will be handled by the system.
+.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
+.IX Item "-momit-leaf-frame-pointer"
+.PD 0
+.IP "\fB\-mno\-omit\-leaf\-frame\-pointer\fR" 4
+.IX Item "-mno-omit-leaf-frame-pointer"
+.PD
+Omit or keep the frame pointer in leaf functions.  The former behaviour is the
+default.
+.IP "\fB\-mtls\-dialect=desc\fR" 4
+.IX Item "-mtls-dialect=desc"
+Use \s-1TLS\s0 descriptors as the thread-local storage mechanism for dynamic accesses
+of \s-1TLS\s0 variables.  This is the default.
+.IP "\fB\-mtls\-dialect=traditional\fR" 4
+.IX Item "-mtls-dialect=traditional"
+Use traditional \s-1TLS\s0 as the thread-local storage mechanism for dynamic accesses
+of \s-1TLS\s0 variables.
+.IP "\fB\-march=\fR\fIname\fR" 4
+.IX Item "-march=name"
+Specify the name of the target architecture, optionally suffixed by one or
+more feature modifiers.  This option has the form
+\&\fB\-march=\fR\fIarch\fR{\fB+\fR[\fBno\fR]\fIfeature\fR}*, where the
+only permissible value for \fIarch\fR is \fBarmv8\-a\fR.  The permissible
+values for \fIfeature\fR are documented in the sub-section below.
+.Sp
+Where conflicting feature modifiers are specified, the right-most feature is
+used.
+.Sp
+\&\s-1GCC\s0 uses this name to determine what kind of instructions it can emit when
+generating assembly code.
+.Sp
+Where \fB\-march\fR is specified without either of \fB\-mtune\fR
+or \fB\-mcpu\fR also being specified, the code will be tuned to perform
+well across a range of target processors implementing the target
+architecture.
+.IP "\fB\-mtune=\fR\fIname\fR" 4
+.IX Item "-mtune=name"
+Specify the name of the target processor for which \s-1GCC\s0 should tune the
+performance of the code.  Permissible values for this option are:
+\&\fBgeneric\fR, \fBcortex\-a53\fR, \fBcortex\-a57\fR.
+.Sp
+Additionally, this option can specify that \s-1GCC\s0 should tune the performance
+of the code for a big.LITTLE system.  The only permissible value is
+\&\fBcortex\-a57.cortex\-a53\fR.
+.Sp
+Where none of \fB\-mtune=\fR, \fB\-mcpu=\fR or \fB\-march=\fR
+are specified, the code will be tuned to perform well across a range
+of target processors.
+.Sp
+This option cannot be suffixed by feature modifiers.
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Specify the name of the target processor, optionally suffixed by one or more
+feature modifiers.  This option has the form
+\&\fB\-mcpu=\fR\fIcpu\fR{\fB+\fR[\fBno\fR]\fIfeature\fR}*, where the
+permissible values for \fIcpu\fR are the same as those available for
+\&\fB\-mtune\fR.
+.Sp
+The permissible values for \fIfeature\fR are documented in the sub-section
+below.
+.Sp
+Where conflicting feature modifiers are specified, the right-most feature is
+used.
+.Sp
+\&\s-1GCC\s0 uses this name to determine what kind of instructions it can emit when
+generating assembly code (as if by \fB\-march\fR) and to determine
+the target processor for which to tune for performance (as if
+by \fB\-mtune\fR).  Where this option is used in conjunction
+with \fB\-march\fR or \fB\-mtune\fR, those options take precedence
+over the appropriate part of this option.
+.PP
+\fB\-march\fR and \fB\-mcpu\fR feature modifiers
+.IX Subsection "-march and -mcpu feature modifiers"
+.PP
+Feature modifiers used with \fB\-march\fR and \fB\-mcpu\fR can be one
+the following:
+.IP "\fBcrc\fR" 4
+.IX Item "crc"
+Enable \s-1CRC\s0 extension.
+.IP "\fBcrypto\fR" 4
+.IX Item "crypto"
+Enable Crypto extension.  This implies Advanced \s-1SIMD\s0 is enabled.
+.IP "\fBfp\fR" 4
+.IX Item "fp"
+Enable floating-point instructions.
+.IP "\fBsimd\fR" 4
+.IX Item "simd"
+Enable Advanced \s-1SIMD\s0 instructions.  This implies floating-point instructions
+are enabled.  This is the default for all current possible values for options
+\&\fB\-march\fR and \fB\-mcpu=\fR.
+.PP
+\fIAdapteva Epiphany Options\fR
+.IX Subsection "Adapteva Epiphany Options"
+.PP
+These \fB\-m\fR options are defined for Adapteva Epiphany:
+.IP "\fB\-mhalf\-reg\-file\fR" 4
+.IX Item "-mhalf-reg-file"
+Don't allocate any register in the range \f(CW\*(C`r32\*(C'\fR...\f(CW\*(C`r63\*(C'\fR.
+That allows code to run on hardware variants that lack these registers.
+.IP "\fB\-mprefer\-short\-insn\-regs\fR" 4
+.IX Item "-mprefer-short-insn-regs"
+Preferrentially allocate registers that allow short instruction generation.
+This can result in increased instruction count, so this may either reduce or
+increase overall code size.
+.IP "\fB\-mbranch\-cost=\fR\fInum\fR" 4
+.IX Item "-mbranch-cost=num"
+Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
+This cost is only a heuristic and is not guaranteed to produce
+consistent results across releases.
+.IP "\fB\-mcmove\fR" 4
+.IX Item "-mcmove"
+Enable the generation of conditional moves.
+.IP "\fB\-mnops=\fR\fInum\fR" 4
+.IX Item "-mnops=num"
+Emit \fInum\fR NOPs before every other generated instruction.
+.IP "\fB\-mno\-soft\-cmpsf\fR" 4
+.IX Item "-mno-soft-cmpsf"
+For single-precision floating-point comparisons, emit an \f(CW\*(C`fsub\*(C'\fR instruction
+and test the flags.  This is faster than a software comparison, but can
+get incorrect results in the presence of NaNs, or when two different small
+numbers are compared such that their difference is calculated as zero.
+The default is \fB\-msoft\-cmpsf\fR, which uses slower, but IEEE-compliant,
+software comparisons.
+.IP "\fB\-mstack\-offset=\fR\fInum\fR" 4
+.IX Item "-mstack-offset=num"
+Set the offset between the top of the stack and the stack pointer.
+E.g., a value of 8 means that the eight bytes in the range \f(CW\*(C`sp+0...sp+7\*(C'\fR
+can be used by leaf functions without stack allocation.
+Values other than \fB8\fR or \fB16\fR are untested and unlikely to work.
+Note also that this option changes the \s-1ABI\s0; compiling a program with a
+different stack offset than the libraries have been compiled with
+generally does not work.
+This option can be useful if you want to evaluate if a different stack
+offset would give you better code, but to actually use a different stack
+offset to build working programs, it is recommended to configure the
+toolchain with the appropriate \fB\-\-with\-stack\-offset=\fR\fInum\fR option.
+.IP "\fB\-mno\-round\-nearest\fR" 4
+.IX Item "-mno-round-nearest"
+Make the scheduler assume that the rounding mode has been set to
+truncating.  The default is \fB\-mround\-nearest\fR.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+If not otherwise specified by an attribute, assume all calls might be beyond
+the offset range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, and therefore load the
+function address into a register before performing a (otherwise direct) call.
+This is the default.
+.IP "\fB\-mshort\-calls\fR" 4
+.IX Item "-mshort-calls"
+If not otherwise specified by an attribute, assume all direct calls are
+in the range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, so use these instructions
+for direct calls.  The default is \fB\-mlong\-calls\fR.
+.IP "\fB\-msmall16\fR" 4
+.IX Item "-msmall16"
+Assume addresses can be loaded as 16\-bit unsigned values.  This does not
+apply to function addresses for which \fB\-mlong\-calls\fR semantics
+are in effect.
+.IP "\fB\-mfp\-mode=\fR\fImode\fR" 4
+.IX Item "-mfp-mode=mode"
+Set the prevailing mode of the floating-point unit.
+This determines the floating-point mode that is provided and expected
+at function call and return time.  Making this mode match the mode you
+predominantly need at function start can make your programs smaller and
+faster by avoiding unnecessary mode switches.
+.Sp
+\&\fImode\fR can be set to one the following values:
+.RS 4
+.IP "\fBcaller\fR" 4
+.IX Item "caller"
+Any mode at function entry is valid, and retained or restored when
+the function returns, and when it calls other functions.
+This mode is useful for compiling libraries or other compilation units
+you might want to incorporate into different programs with different
+prevailing \s-1FPU\s0 modes, and the convenience of being able to use a single
+object file outweighs the size and speed overhead for any extra
+mode switching that might be needed, compared with what would be needed
+with a more specific choice of prevailing \s-1FPU\s0 mode.
+.IP "\fBtruncate\fR" 4
+.IX Item "truncate"
+This is the mode used for floating-point calculations with
+truncating (i.e. round towards zero) rounding mode.  That includes
+conversion from floating point to integer.
+.IP "\fBround-nearest\fR" 4
+.IX Item "round-nearest"
+This is the mode used for floating-point calculations with
+round-to-nearest-or-even rounding mode.
+.IP "\fBint\fR" 4
+.IX Item "int"
+This is the mode used to perform integer calculations in the \s-1FPU,\s0 e.g.
+integer multiply, or integer multiply-and-accumulate.
+.RE
+.RS 4
+.Sp
+The default is \fB\-mfp\-mode=caller\fR
+.RE
+.IP "\fB\-mnosplit\-lohi\fR" 4
+.IX Item "-mnosplit-lohi"
+.PD 0
+.IP "\fB\-mno\-postinc\fR" 4
+.IX Item "-mno-postinc"
+.IP "\fB\-mno\-postmodify\fR" 4
+.IX Item "-mno-postmodify"
+.PD
+Code generation tweaks that disable, respectively, splitting of 32\-bit
+loads, generation of post-increment addresses, and generation of
+post-modify addresses.  The defaults are \fBmsplit-lohi\fR,
+\&\fB\-mpost\-inc\fR, and \fB\-mpost\-modify\fR.
+.IP "\fB\-mnovect\-double\fR" 4
+.IX Item "-mnovect-double"
+Change the preferred \s-1SIMD\s0 mode to SImode.  The default is
+\&\fB\-mvect\-double\fR, which uses DImode as preferred \s-1SIMD\s0 mode.
+.IP "\fB\-max\-vect\-align=\fR\fInum\fR" 4
+.IX Item "-max-vect-align=num"
+The maximum alignment for \s-1SIMD\s0 vector mode types.
+\&\fInum\fR may be 4 or 8.  The default is 8.
+Note that this is an \s-1ABI\s0 change, even though many library function
+interfaces are unaffected if they don't use \s-1SIMD\s0 vector modes
+in places that affect size and/or alignment of relevant types.
+.IP "\fB\-msplit\-vecmove\-early\fR" 4
+.IX Item "-msplit-vecmove-early"
+Split vector moves into single word moves before reload.  In theory this
+can give better register allocation, but so far the reverse seems to be
+generally the case.
+.IP "\fB\-m1reg\-\fR\fIreg\fR" 4
+.IX Item "-m1reg-reg"
+Specify a register to hold the constant \-1, which makes loading small negative
+constants and certain bitmasks faster.
+Allowable values for \fIreg\fR are \fBr43\fR and \fBr63\fR,
+which specify use of that register as a fixed register,
+and \fBnone\fR, which means that no register is used for this
+purpose.  The default is \fB\-m1reg\-none\fR.
+.PP
+\fI\s-1ARC\s0 Options\fR
+.IX Subsection "ARC Options"
+.PP
+The following options control the architecture variant for which code
+is being compiled:
+.IP "\fB\-mbarrel\-shifter\fR" 4
+.IX Item "-mbarrel-shifter"
+Generate instructions supported by barrel shifter.  This is the default
+unless \fB\-mcpu=ARC601\fR is in effect.
+.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
+.IX Item "-mcpu=cpu"
+Set architecture type, register usage, and instruction scheduling
+parameters for \fIcpu\fR.  There are also shortcut alias options
+available for backward compatibility and convenience.  Supported
+values for \fIcpu\fR are
+.RS 4
+.IP "\fB\s-1ARC600\s0\fR" 4
+.IX Item "ARC600"
+Compile for \s-1ARC600. \s0 Aliases: \fB\-mA6\fR, \fB\-mARC600\fR.
+.IP "\fB\s-1ARC601\s0\fR" 4
+.IX Item "ARC601"
+Compile for \s-1ARC601. \s0 Alias: \fB\-mARC601\fR.
+.IP "\fB\s-1ARC700\s0\fR" 4
+.IX Item "ARC700"
+Compile for \s-1ARC700. \s0 Aliases: \fB\-mA7\fR, \fB\-mARC700\fR.
+This is the default when configured with \fB\-\-with\-cpu=arc700\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mdpfp\fR" 4
+.IX Item "-mdpfp"
+.PD 0
+.IP "\fB\-mdpfp\-compact\fR" 4
+.IX Item "-mdpfp-compact"
+.PD
+\&\s-1FPX:\s0 Generate Double Precision \s-1FPX\s0 instructions, tuned for the compact
+implementation.
+.IP "\fB\-mdpfp\-fast\fR" 4
+.IX Item "-mdpfp-fast"
+\&\s-1FPX:\s0 Generate Double Precision \s-1FPX\s0 instructions, tuned for the fast
+implementation.
+.IP "\fB\-mno\-dpfp\-lrsr\fR" 4
+.IX Item "-mno-dpfp-lrsr"
+Disable \s-1LR\s0 and \s-1SR\s0 instructions from using \s-1FPX\s0 extension aux registers.
+.IP "\fB\-mea\fR" 4
+.IX Item "-mea"
+Generate Extended arithmetic instructions.  Currently only
+\&\f(CW\*(C`divaw\*(C'\fR, \f(CW\*(C`adds\*(C'\fR, \f(CW\*(C`subs\*(C'\fR, and \f(CW\*(C`sat16\*(C'\fR are
+supported.  This is always enabled for \fB\-mcpu=ARC700\fR.
+.IP "\fB\-mno\-mpy\fR" 4
+.IX Item "-mno-mpy"
+Do not generate mpy instructions for \s-1ARC700.\s0
+.IP "\fB\-mmul32x16\fR" 4
+.IX Item "-mmul32x16"
+Generate 32x16 bit multiply and mac instructions.
+.IP "\fB\-mmul64\fR" 4
+.IX Item "-mmul64"
+Generate mul64 and mulu64 instructions.  Only valid for \fB\-mcpu=ARC600\fR.
+.IP "\fB\-mnorm\fR" 4
+.IX Item "-mnorm"
+Generate norm instruction.  This is the default if \fB\-mcpu=ARC700\fR
+is in effect.
+.IP "\fB\-mspfp\fR" 4
+.IX Item "-mspfp"
+.PD 0
+.IP "\fB\-mspfp\-compact\fR" 4
+.IX Item "-mspfp-compact"
+.PD
+\&\s-1FPX:\s0 Generate Single Precision \s-1FPX\s0 instructions, tuned for the compact
+implementation.
+.IP "\fB\-mspfp\-fast\fR" 4
+.IX Item "-mspfp-fast"
+\&\s-1FPX:\s0 Generate Single Precision \s-1FPX\s0 instructions, tuned for the fast
+implementation.
+.IP "\fB\-msimd\fR" 4
+.IX Item "-msimd"
+Enable generation of \s-1ARC SIMD\s0 instructions via target-specific
+builtins.  Only valid for \fB\-mcpu=ARC700\fR.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+This option ignored; it is provided for compatibility purposes only.
+Software floating point code is emitted by default, and this default
+can overridden by \s-1FPX\s0 options; \fBmspfp\fR, \fBmspfp-compact\fR, or
+\&\fBmspfp-fast\fR for single precision, and \fBmdpfp\fR,
+\&\fBmdpfp-compact\fR, or \fBmdpfp-fast\fR for double precision.
+.IP "\fB\-mswap\fR" 4
+.IX Item "-mswap"
+Generate swap instructions.
+.PP
+The following options are passed through to the assembler, and also
+define preprocessor macro symbols.
+.IP "\fB\-mdsp\-packa\fR" 4
+.IX Item "-mdsp-packa"
+Passed down to the assembler to enable the \s-1DSP\s0 Pack A extensions.
+Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdsp_packa\*(C'\fR.
+.IP "\fB\-mdvbf\fR" 4
+.IX Item "-mdvbf"
+Passed down to the assembler to enable the dual viterbi butterfly
+extension.  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdvbf\*(C'\fR.
+.IP "\fB\-mlock\fR" 4
+.IX Item "-mlock"
+Passed down to the assembler to enable the Locked Load/Store
+Conditional extension.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xlock\*(C'\fR.
+.IP "\fB\-mmac\-d16\fR" 4
+.IX Item "-mmac-d16"
+Passed down to the assembler.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xxmac_d16\*(C'\fR.
+.IP "\fB\-mmac\-24\fR" 4
+.IX Item "-mmac-24"
+Passed down to the assembler.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xxmac_24\*(C'\fR.
+.IP "\fB\-mrtsc\fR" 4
+.IX Item "-mrtsc"
+Passed down to the assembler to enable the 64\-bit Time-Stamp Counter
+extension instruction.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xrtsc\*(C'\fR.
+.IP "\fB\-mswape\fR" 4
+.IX Item "-mswape"
+Passed down to the assembler to enable the swap byte ordering
+extension instruction.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xswape\*(C'\fR.
+.IP "\fB\-mtelephony\fR" 4
+.IX Item "-mtelephony"
+Passed down to the assembler to enable dual and single operand
+instructions for telephony.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xtelephony\*(C'\fR.
+.IP "\fB\-mxy\fR" 4
+.IX Item "-mxy"
+Passed down to the assembler to enable the \s-1XY\s0 Memory extension.  Also
+sets the preprocessor symbol \f(CW\*(C`_\|_Xxy\*(C'\fR.
+.PP
+The following options control how the assembly code is annotated:
+.IP "\fB\-misize\fR" 4
+.IX Item "-misize"
+Annotate assembler instructions with estimated addresses.
+.IP "\fB\-mannotate\-align\fR" 4
+.IX Item "-mannotate-align"
+Explain what alignment considerations lead to the decision to make an
+instruction short or long.
+.PP
+The following options are passed through to the linker:
+.IP "\fB\-marclinux\fR" 4
+.IX Item "-marclinux"
+Passed through to the linker, to specify use of the \f(CW\*(C`arclinux\*(C'\fR emulation.
+This option is enabled by default in tool chains built for
+\&\f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets
+when profiling is not requested.
+.IP "\fB\-marclinux_prof\fR" 4
+.IX Item "-marclinux_prof"
+Passed through to the linker, to specify use of the
+\&\f(CW\*(C`arclinux_prof\*(C'\fR emulation.  This option is enabled by default in
+tool chains built for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and
+\&\f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets when profiling is requested.
+.PP
+The following options control the semantics of generated code:
+.IP "\fB\-mepilogue\-cfi\fR" 4
+.IX Item "-mepilogue-cfi"
+Enable generation of call frame information for epilogues.
+.IP "\fB\-mno\-epilogue\-cfi\fR" 4
+.IX Item "-mno-epilogue-cfi"
+Disable generation of call frame information for epilogues.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+Generate call insns as register indirect calls, thus providing access
+to the full 32\-bit address range.
+.IP "\fB\-mmedium\-calls\fR" 4
+.IX Item "-mmedium-calls"
+Don't use less than 25 bit addressing range for calls, which is the
+offset available for an unconditional branch-and-link
+instruction.  Conditional execution of function calls is suppressed, to
+allow use of the 25\-bit range, rather than the 21\-bit range with
+conditional branch-and-link.  This is the default for tool chains built
+for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets.
+.IP "\fB\-mno\-sdata\fR" 4
+.IX Item "-mno-sdata"
+Do not generate sdata references.  This is the default for tool chains
+built for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR
+targets.
+.IP "\fB\-mucb\-mcount\fR" 4
+.IX Item "-mucb-mcount"
+Instrument with mcount calls as used in \s-1UCB\s0 code.  I.e. do the
+counting in the callee, not the caller.  By default \s-1ARC\s0 instrumentation
+counts in the caller.
+.IP "\fB\-mvolatile\-cache\fR" 4
+.IX Item "-mvolatile-cache"
+Use ordinarily cached memory accesses for volatile references.  This is the
+default.
+.IP "\fB\-mno\-volatile\-cache\fR" 4
+.IX Item "-mno-volatile-cache"
+Enable cache bypass for volatile references.
+.PP
+The following options fine tune code generation:
+.IP "\fB\-malign\-call\fR" 4
+.IX Item "-malign-call"
+Do alignment optimizations for call instructions.
+.IP "\fB\-mauto\-modify\-reg\fR" 4
+.IX Item "-mauto-modify-reg"
+Enable the use of pre/post modify with register displacement.
+.IP "\fB\-mbbit\-peephole\fR" 4
+.IX Item "-mbbit-peephole"
+Enable bbit peephole2.
+.IP "\fB\-mno\-brcc\fR" 4
+.IX Item "-mno-brcc"
+This option disables a target-specific pass in \fIarc_reorg\fR to
+generate \f(CW\*(C`BRcc\*(C'\fR instructions.  It has no effect on \f(CW\*(C`BRcc\*(C'\fR
+generation driven by the combiner pass.
+.IP "\fB\-mcase\-vector\-pcrel\fR" 4
+.IX Item "-mcase-vector-pcrel"
+Use pc-relative switch case tables \- this enables case table shortening.
+This is the default for \fB\-Os\fR.
+.IP "\fB\-mcompact\-casesi\fR" 4
+.IX Item "-mcompact-casesi"
+Enable compact casesi pattern.
+This is the default for \fB\-Os\fR.
+.IP "\fB\-mno\-cond\-exec\fR" 4
+.IX Item "-mno-cond-exec"
+Disable ARCompact specific pass to generate conditional execution instructions.
+Due to delay slot scheduling and interactions between operand numbers,
+literal sizes, instruction lengths, and the support for conditional execution,
+the target-independent pass to generate conditional execution is often lacking,
+so the \s-1ARC\s0 port has kept a special pass around that tries to find more
+conditional execution generating opportunities after register allocation,
+branch shortening, and delay slot scheduling have been done.  This pass
+generally, but not always, improves performance and code size, at the cost of
+extra compilation time, which is why there is an option to switch it off.
+If you have a problem with call instructions exceeding their allowable
+offset range because they are conditionalized, you should consider using
+\&\fB\-mmedium\-calls\fR instead.
+.IP "\fB\-mearly\-cbranchsi\fR" 4
+.IX Item "-mearly-cbranchsi"
+Enable pre-reload use of the cbranchsi pattern.
+.IP "\fB\-mexpand\-adddi\fR" 4
+.IX Item "-mexpand-adddi"
+Expand \f(CW\*(C`adddi3\*(C'\fR and \f(CW\*(C`subdi3\*(C'\fR at rtl generation time into
+\&\f(CW\*(C`add.f\*(C'\fR, \f(CW\*(C`adc\*(C'\fR etc.
+.IP "\fB\-mindexed\-loads\fR" 4
+.IX Item "-mindexed-loads"
+Enable the use of indexed loads.  This can be problematic because some
+optimizers will then assume the that indexed stores exist, which is not
+the case.
+.IP "\fB\-mlra\fR" 4
+.IX Item "-mlra"
+Enable Local Register Allocation.  This is still experimental for \s-1ARC,\s0
+so by default the compiler uses standard reload
+(i.e. \fB\-mno\-lra\fR).
+.IP "\fB\-mlra\-priority\-none\fR" 4
+.IX Item "-mlra-priority-none"
+Don't indicate any priority for target registers.
+.IP "\fB\-mlra\-priority\-compact\fR" 4
+.IX Item "-mlra-priority-compact"
+Indicate target register priority for r0..r3 / r12..r15.
+.IP "\fB\-mlra\-priority\-noncompact\fR" 4
+.IX Item "-mlra-priority-noncompact"
+Reduce target regsiter priority for r0..r3 / r12..r15.
+.IP "\fB\-mno\-millicode\fR" 4
+.IX Item "-mno-millicode"
+When optimizing for size (using \fB\-Os\fR), prologues and epilogues
+that have to save or restore a large number of registers are often
+shortened by using call to a special function in libgcc; this is
+referred to as a \fImillicode\fR call.  As these calls can pose
+performance issues, and/or cause linking issues when linking in a
+nonstandard way, this option is provided to turn off millicode call
+generation.
+.IP "\fB\-mmixed\-code\fR" 4
+.IX Item "-mmixed-code"
+Tweak register allocation to help 16\-bit instruction generation.
+This generally has the effect of decreasing the average instruction size
+while increasing the instruction count.
+.IP "\fB\-mq\-class\fR" 4
+.IX Item "-mq-class"
+Enable 'q' instruction alternatives.
+This is the default for \fB\-Os\fR.
+.IP "\fB\-mRcq\fR" 4
+.IX Item "-mRcq"
+Enable Rcq constraint handling \- most short code generation depends on this.
+This is the default.
+.IP "\fB\-mRcw\fR" 4
+.IX Item "-mRcw"
+Enable Rcw constraint handling \- ccfsm condexec mostly depends on this.
+This is the default.
+.IP "\fB\-msize\-level=\fR\fIlevel\fR" 4
+.IX Item "-msize-level=level"
+Fine-tune size optimization with regards to instruction lengths and alignment.
+The recognized values for \fIlevel\fR are:
+.RS 4
+.IP "\fB0\fR" 4
+.IX Item "0"
+No size optimization.  This level is deprecated and treated like \fB1\fR.
+.IP "\fB1\fR" 4
+.IX Item "1"
+Short instructions are used opportunistically.
+.IP "\fB2\fR" 4
+.IX Item "2"
+In addition, alignment of loops and of code after barriers are dropped.
+.IP "\fB3\fR" 4
+.IX Item "3"
+In addition, optional data alignment is dropped, and the option \fBOs\fR is enabled.
+.RE
+.RS 4
+.Sp
+This defaults to \fB3\fR when \fB\-Os\fR is in effect.  Otherwise,
+the behavior when this is not set is equivalent to level \fB1\fR.
+.RE
+.IP "\fB\-mtune=\fR\fIcpu\fR" 4
+.IX Item "-mtune=cpu"
+Set instruction scheduling parameters for \fIcpu\fR, overriding any implied
+by \fB\-mcpu=\fR.
+.Sp
+Supported values for \fIcpu\fR are
+.RS 4
+.IP "\fB\s-1ARC600\s0\fR" 4
+.IX Item "ARC600"
+Tune for \s-1ARC600\s0 cpu.
+.IP "\fB\s-1ARC601\s0\fR" 4
+.IX Item "ARC601"
+Tune for \s-1ARC601\s0 cpu.
+.IP "\fB\s-1ARC700\s0\fR" 4
+.IX Item "ARC700"
+Tune for \s-1ARC700\s0 cpu with standard multiplier block.
+.IP "\fBARC700\-xmac\fR" 4
+.IX Item "ARC700-xmac"
+Tune for \s-1ARC700\s0 cpu with \s-1XMAC\s0 block.
+.IP "\fB\s-1ARC725D\s0\fR" 4
+.IX Item "ARC725D"
+Tune for \s-1ARC725D\s0 cpu.
+.IP "\fB\s-1ARC750D\s0\fR" 4
+.IX Item "ARC750D"
+Tune for \s-1ARC750D\s0 cpu.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mmultcost=\fR\fInum\fR" 4
+.IX Item "-mmultcost=num"
+Cost to assume for a multiply instruction, with \fB4\fR being equal to a
+normal instruction.
+.IP "\fB\-munalign\-prob\-threshold=\fR\fIprobability\fR" 4
+.IX Item "-munalign-prob-threshold=probability"
+Set probability threshold for unaligning branches.
+When tuning for \fB\s-1ARC700\s0\fR and optimizing for speed, branches without
+filled delay slot are preferably emitted unaligned and long, unless
+profiling indicates that the probability for the branch to be taken
+is below \fIprobability\fR.  
+The default is (\s-1REG_BR_PROB_BASE/2\s0), i.e. 5000.
+.PP
+The following options are maintained for backward compatibility, but
+are now deprecated and will be removed in a future release:
+.IP "\fB\-margonaut\fR" 4
+.IX Item "-margonaut"
+Obsolete \s-1FPX.\s0
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+.PD 0
+.IP "\fB\-EB\fR" 4
+.IX Item "-EB"
+.PD
+Compile code for big endian targets.  Use of these options is now
+deprecated.  Users wanting big-endian code, should use the
+\&\f(CW\*(C`arceb\-elf32\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets when
+building the tool chain, for which big-endian is the default.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+.PD 0
+.IP "\fB\-EL\fR" 4
+.IX Item "-EL"
+.PD
+Compile code for little endian targets.  Use of these options is now
+deprecated.  Users wanting little-endian code should use the
+\&\f(CW\*(C`arc\-elf32\*(C'\fR and \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR targets when
+building the tool chain, for which little-endian is the default.
+.IP "\fB\-mbarrel_shifter\fR" 4
+.IX Item "-mbarrel_shifter"
+Replaced by \fB\-mbarrel\-shifter\fR
+.IP "\fB\-mdpfp_compact\fR" 4
+.IX Item "-mdpfp_compact"
+Replaced by \fB\-mdpfp\-compact\fR
+.IP "\fB\-mdpfp_fast\fR" 4
+.IX Item "-mdpfp_fast"
+Replaced by \fB\-mdpfp\-fast\fR
+.IP "\fB\-mdsp_packa\fR" 4
+.IX Item "-mdsp_packa"
+Replaced by \fB\-mdsp\-packa\fR
+.IP "\fB\-mEA\fR" 4
+.IX Item "-mEA"
+Replaced by \fB\-mea\fR
+.IP "\fB\-mmac_24\fR" 4
+.IX Item "-mmac_24"
+Replaced by \fB\-mmac\-24\fR
+.IP "\fB\-mmac_d16\fR" 4
+.IX Item "-mmac_d16"
+Replaced by \fB\-mmac\-d16\fR
+.IP "\fB\-mspfp_compact\fR" 4
+.IX Item "-mspfp_compact"
+Replaced by \fB\-mspfp\-compact\fR
+.IP "\fB\-mspfp_fast\fR" 4
+.IX Item "-mspfp_fast"
+Replaced by \fB\-mspfp\-fast\fR
+.IP "\fB\-mtune=\fR\fIcpu\fR" 4
+.IX Item "-mtune=cpu"
+Values \fBarc600\fR, \fBarc601\fR, \fBarc700\fR and
+\&\fBarc700\-xmac\fR for \fIcpu\fR are replaced by \fB\s-1ARC600\s0\fR,
+\&\fB\s-1ARC601\s0\fR, \fB\s-1ARC700\s0\fR and \fBARC700\-xmac\fR respectively
+.IP "\fB\-multcost=\fR\fInum\fR" 4
+.IX Item "-multcost=num"
+Replaced by \fB\-mmultcost\fR.
+.PP
+\fI\s-1ARM\s0 Options\fR
+.IX Subsection "ARM Options"
+.PP
+These \fB\-m\fR options are defined for Advanced \s-1RISC\s0 Machines (\s-1ARM\s0)
+architectures:
+.IP "\fB\-mabi=\fR\fIname\fR" 4
+.IX Item "-mabi=name"
+Generate code for the specified \s-1ABI. \s0 Permissible values are: \fBapcs-gnu\fR,
+\&\fBatpcs\fR, \fBaapcs\fR, \fBaapcs-linux\fR and \fBiwmmxt\fR.
+.IP "\fB\-mapcs\-frame\fR" 4
+.IX Item "-mapcs-frame"
+Generate a stack frame that is compliant with the \s-1ARM\s0 Procedure Call
+Standard for all functions, even if this is not strictly necessary for
+correct execution of the code.  Specifying \fB\-fomit\-frame\-pointer\fR
+with this option causes the stack frames not to be generated for
+leaf functions.  The default is \fB\-mno\-apcs\-frame\fR.
+.IP "\fB\-mapcs\fR" 4
+.IX Item "-mapcs"
+This is a synonym for \fB\-mapcs\-frame\fR.
+.IP "\fB\-mthumb\-interwork\fR" 4
+.IX Item "-mthumb-interwork"
+Generate code that supports calling between the \s-1ARM\s0 and Thumb
+instruction sets.  Without this option, on pre\-v5 architectures, the
+two instruction sets cannot be reliably used inside one program.  The
+default is \fB\-mno\-thumb\-interwork\fR, since slightly larger code
+is generated when \fB\-mthumb\-interwork\fR is specified.  In \s-1AAPCS\s0
+configurations this option is meaningless.
+.IP "\fB\-mno\-sched\-prolog\fR" 4
+.IX Item "-mno-sched-prolog"
+Prevent the reordering of instructions in the function prologue, or the
+merging of those instruction with the instructions in the function's
+body.  This means that all functions start with a recognizable set
+of instructions (or in fact one of a choice from a small set of
+different function prologues), and this information can be used to
+locate the start of functions inside an executable piece of code.  The
+default is \fB\-msched\-prolog\fR.
+.IP "\fB\-mfloat\-abi=\fR\fIname\fR" 4
+.IX Item "-mfloat-abi=name"
+Specifies which floating-point \s-1ABI\s0 to use.  Permissible values
+are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
+.Sp
+Specifying \fBsoft\fR causes \s-1GCC\s0 to generate output containing
+library calls for floating-point operations.
+\&\fBsoftfp\fR allows the generation of code using hardware floating-point
+instructions, but still uses the soft-float calling conventions.
+\&\fBhard\fR allows generation of floating-point instructions
+and uses FPU-specific calling conventions.
+.Sp
+The default depends on the specific target configuration.  Note that
+the hard-float and soft-float ABIs are not link-compatible; you must
+compile your entire program with the same \s-1ABI,\s0 and link with a
+compatible set of libraries.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code for a processor running in little-endian mode.  This is
+the default for all standard configurations.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code for a processor running in big-endian mode; the default is
+to compile code for a little-endian processor.
+.IP "\fB\-mwords\-little\-endian\fR" 4
+.IX Item "-mwords-little-endian"
+This option only applies when generating code for big-endian processors.
+Generate code for a little-endian word order but a big-endian byte
+order.  That is, a byte order of the form \fB32107654\fR.  Note: this
+option should only be used if you require compatibility with code for
+big-endian \s-1ARM\s0 processors generated by versions of the compiler prior to
+2.8.  This option is now deprecated.
+.IP "\fB\-march=\fR\fIname\fR" 4
+.IX Item "-march=name"
+This specifies the name of the target \s-1ARM\s0 architecture.  \s-1GCC\s0 uses this
+name to determine what kind of instructions it can emit when generating
+assembly code.  This option can be used in conjunction with or instead
+of the \fB\-mcpu=\fR option.  Permissible names are: \fBarmv2\fR,
+\&\fBarmv2a\fR, \fBarmv3\fR, \fBarmv3m\fR, \fBarmv4\fR, \fBarmv4t\fR,
+\&\fBarmv5\fR, \fBarmv5t\fR, \fBarmv5e\fR, \fBarmv5te\fR,
+\&\fBarmv6\fR, \fBarmv6j\fR,
+\&\fBarmv6t2\fR, \fBarmv6z\fR, \fBarmv6zk\fR, \fBarmv6\-m\fR,
+\&\fBarmv7\fR, \fBarmv7\-a\fR, \fBarmv7\-r\fR, \fBarmv7\-m\fR, \fBarmv7e\-m\fR,
+\&\fBarmv7ve\fR, \fBarmv8\-a\fR, \fBarmv8\-a+crc\fR,
+\&\fBiwmmxt\fR, \fBiwmmxt2\fR, \fBep9312\fR.
+.Sp
+\&\fB\-march=armv7ve\fR is the armv7\-a architecture with virtualization
+extensions.
+.Sp
+\&\fB\-march=armv8\-a+crc\fR enables code generation for the ARMv8\-A
+architecture together with the optional \s-1CRC32\s0 extensions.
+.Sp
+\&\fB\-march=native\fR causes the compiler to auto-detect the architecture
+of the build computer.  At present, this feature is only supported on
+Linux, and not all architectures are recognized.  If the auto-detect is
+unsuccessful the option has no effect.
+.IP "\fB\-mtune=\fR\fIname\fR" 4
+.IX Item "-mtune=name"
+This option specifies the name of the target \s-1ARM\s0 processor for
+which \s-1GCC\s0 should tune the performance of the code.
+For some \s-1ARM\s0 implementations better performance can be obtained by using
+this option.
+Permissible names are: \fBarm2\fR, \fBarm250\fR,
+\&\fBarm3\fR, \fBarm6\fR, \fBarm60\fR, \fBarm600\fR, \fBarm610\fR,
+\&\fBarm620\fR, \fBarm7\fR, \fBarm7m\fR, \fBarm7d\fR, \fBarm7dm\fR,
+\&\fBarm7di\fR, \fBarm7dmi\fR, \fBarm70\fR, \fBarm700\fR,
+\&\fBarm700i\fR, \fBarm710\fR, \fBarm710c\fR, \fBarm7100\fR,
+\&\fBarm720\fR,
+\&\fBarm7500\fR, \fBarm7500fe\fR, \fBarm7tdmi\fR, \fBarm7tdmi\-s\fR,
+\&\fBarm710t\fR, \fBarm720t\fR, \fBarm740t\fR,
+\&\fBstrongarm\fR, \fBstrongarm110\fR, \fBstrongarm1100\fR,
+\&\fBstrongarm1110\fR,
+\&\fBarm8\fR, \fBarm810\fR, \fBarm9\fR, \fBarm9e\fR, \fBarm920\fR,
+\&\fBarm920t\fR, \fBarm922t\fR, \fBarm946e\-s\fR, \fBarm966e\-s\fR,
+\&\fBarm968e\-s\fR, \fBarm926ej\-s\fR, \fBarm940t\fR, \fBarm9tdmi\fR,
+\&\fBarm10tdmi\fR, \fBarm1020t\fR, \fBarm1026ej\-s\fR,
+\&\fBarm10e\fR, \fBarm1020e\fR, \fBarm1022e\fR,
+\&\fBarm1136j\-s\fR, \fBarm1136jf\-s\fR, \fBmpcore\fR, \fBmpcorenovfp\fR,
+\&\fBarm1156t2\-s\fR, \fBarm1156t2f\-s\fR, \fBarm1176jz\-s\fR, \fBarm1176jzf\-s\fR,
+\&\fBcortex\-a5\fR, \fBcortex\-a7\fR, \fBcortex\-a8\fR, \fBcortex\-a9\fR,
+\&\fBcortex\-a12\fR, \fBcortex\-a15\fR, \fBcortex\-a53\fR, \fBcortex\-a57\fR,
+\&\fBcortex\-r4\fR,
+\&\fBcortex\-r4f\fR, \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-m4\fR,
+\&\fBcortex\-m3\fR,
+\&\fBcortex\-m1\fR,
+\&\fBcortex\-m0\fR,
+\&\fBcortex\-m0plus\fR,
+\&\fBmarvell\-pj4\fR,
+\&\fBxscale\fR, \fBiwmmxt\fR, \fBiwmmxt2\fR, \fBep9312\fR,
+\&\fBfa526\fR, \fBfa626\fR,
+\&\fBfa606te\fR, \fBfa626te\fR, \fBfmp626\fR, \fBfa726te\fR.
+.Sp
+Additionally, this option can specify that \s-1GCC\s0 should tune the performance
+of the code for a big.LITTLE system.  Permissible names are:
+\&\fBcortex\-a15.cortex\-a7\fR, \fBcortex\-a57.cortex\-a53\fR.
+.Sp
+\&\fB\-mtune=generic\-\fR\fIarch\fR specifies that \s-1GCC\s0 should tune the
+performance for a blend of processors within architecture \fIarch\fR.
+The aim is to generate code that run well on the current most popular
+processors, balancing between optimizations that benefit some CPUs in the
+range, and avoiding performance pitfalls of other CPUs.  The effects of
+this option may change in future \s-1GCC\s0 versions as \s-1CPU\s0 models come and go.
+.Sp
+\&\fB\-mtune=native\fR causes the compiler to auto-detect the \s-1CPU\s0
+of the build computer.  At present, this feature is only supported on
+Linux, and not all architectures are recognized.  If the auto-detect is
+unsuccessful the option has no effect.
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+This specifies the name of the target \s-1ARM\s0 processor.  \s-1GCC\s0 uses this name
+to derive the name of the target \s-1ARM\s0 architecture (as if specified
+by \fB\-march\fR) and the \s-1ARM\s0 processor type for which to tune for
+performance (as if specified by \fB\-mtune\fR).  Where this option
+is used in conjunction with \fB\-march\fR or \fB\-mtune\fR,
+those options take precedence over the appropriate part of this option.
+.Sp
+Permissible names for this option are the same as those for
+\&\fB\-mtune\fR.
+.Sp
+\&\fB\-mcpu=generic\-\fR\fIarch\fR is also permissible, and is
+equivalent to \fB\-march=\fR\fIarch\fR \fB\-mtune=generic\-\fR\fIarch\fR.
+See \fB\-mtune\fR for more information.
+.Sp
+\&\fB\-mcpu=native\fR causes the compiler to auto-detect the \s-1CPU\s0
+of the build computer.  At present, this feature is only supported on
+Linux, and not all architectures are recognized.  If the auto-detect is
+unsuccessful the option has no effect.
+.IP "\fB\-mfpu=\fR\fIname\fR" 4
+.IX Item "-mfpu=name"
+This specifies what floating-point hardware (or hardware emulation) is
+available on the target.  Permissible names are: \fBvfp\fR, \fBvfpv3\fR,
+\&\fBvfpv3\-fp16\fR, \fBvfpv3\-d16\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3xd\fR,
+\&\fBvfpv3xd\-fp16\fR, \fBneon\fR, \fBneon\-fp16\fR, \fBvfpv4\fR,
+\&\fBvfpv4\-d16\fR, \fBfpv4\-sp\-d16\fR, \fBneon\-vfpv4\fR,
+\&\fBfp\-armv8\fR, \fBneon\-fp\-armv8\fR, and \fBcrypto\-neon\-fp\-armv8\fR.
+.Sp
+If \fB\-msoft\-float\fR is specified this specifies the format of
+floating-point values.
+.Sp
+If the selected floating-point hardware includes the \s-1NEON\s0 extension
+(e.g. \fB\-mfpu\fR=\fBneon\fR), note that floating-point
+operations are not generated by \s-1GCC\s0's auto-vectorization pass unless
+\&\fB\-funsafe\-math\-optimizations\fR is also specified.  This is
+because \s-1NEON\s0 hardware does not fully implement the \s-1IEEE 754\s0 standard for
+floating-point arithmetic (in particular denormal values are treated as
+zero), so the use of \s-1NEON\s0 instructions may lead to a loss of precision.
+.IP "\fB\-mfp16\-format=\fR\fIname\fR" 4
+.IX Item "-mfp16-format=name"
+Specify the format of the \f(CW\*(C`_\|_fp16\*(C'\fR half-precision floating-point type.
+Permissible names are \fBnone\fR, \fBieee\fR, and \fBalternative\fR;
+the default is \fBnone\fR, in which case the \f(CW\*(C`_\|_fp16\*(C'\fR type is not
+defined.
+.IP "\fB\-mstructure\-size\-boundary=\fR\fIn\fR" 4
+.IX Item "-mstructure-size-boundary=n"
+The sizes of all structures and unions are rounded up to a multiple
+of the number of bits set by this option.  Permissible values are 8, 32
+and 64.  The default value varies for different toolchains.  For the \s-1COFF\s0
+targeted toolchain the default value is 8.  A value of 64 is only allowed
+if the underlying \s-1ABI\s0 supports it.
+.Sp
+Specifying a larger number can produce faster, more efficient code, but
+can also increase the size of the program.  Different values are potentially
+incompatible.  Code compiled with one value cannot necessarily expect to
+work with code or libraries compiled with another value, if they exchange
+information using structures or unions.
+.IP "\fB\-mabort\-on\-noreturn\fR" 4
+.IX Item "-mabort-on-noreturn"
+Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a
+\&\f(CW\*(C`noreturn\*(C'\fR function.  It is executed if the function tries to
+return.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+.PD 0
+.IP "\fB\-mno\-long\-calls\fR" 4
+.IX Item "-mno-long-calls"
+.PD
+Tells the compiler to perform function calls by first loading the
+address of the function into a register and then performing a subroutine
+call on this register.  This switch is needed if the target function
+lies outside of the 64\-megabyte addressing range of the offset-based
+version of subroutine call instruction.
+.Sp
+Even if this switch is enabled, not all function calls are turned
+into long calls.  The heuristic is that static functions, functions
+that have the \fBshort-call\fR attribute, functions that are inside
+the scope of a \fB#pragma no_long_calls\fR directive, and functions whose
+definitions have already been compiled within the current compilation
+unit are not turned into long calls.  The exceptions to this rule are
+that weak function definitions, functions with the \fBlong-call\fR
+attribute or the \fBsection\fR attribute, and functions that are within
+the scope of a \fB#pragma long_calls\fR directive are always
+turned into long calls.
+.Sp
+This feature is not enabled by default.  Specifying
+\&\fB\-mno\-long\-calls\fR restores the default behavior, as does
+placing the function calls within the scope of a \fB#pragma
+long_calls_off\fR directive.  Note these switches have no effect on how
+the compiler generates code to handle function calls via function
+pointers.
+.IP "\fB\-msingle\-pic\-base\fR" 4
+.IX Item "-msingle-pic-base"
+Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
+loading it in the prologue for each function.  The runtime system is
+responsible for initializing this register with an appropriate value
+before execution begins.
+.IP "\fB\-mpic\-register=\fR\fIreg\fR" 4
+.IX Item "-mpic-register=reg"
+Specify the register to be used for \s-1PIC\s0 addressing.
+For standard \s-1PIC\s0 base case, the default will be any suitable register
+determined by compiler.  For single \s-1PIC\s0 base case, the default is
+\&\fBR9\fR if target is \s-1EABI\s0 based or stack-checking is enabled,
+otherwise the default is \fBR10\fR.
+.IP "\fB\-mpic\-data\-is\-text\-relative\fR" 4
+.IX Item "-mpic-data-is-text-relative"
+Assume that each data segments are relative to text segment at load time.
+Therefore, it permits addressing data using PC-relative operations.
+This option is on by default for targets other than VxWorks \s-1RTP.\s0
+.IP "\fB\-mpoke\-function\-name\fR" 4
+.IX Item "-mpoke-function-name"
+Write the name of each function into the text section, directly
+preceding the function prologue.  The generated code is similar to this:
+.Sp
+.Vb 9
+\&             t0
+\&                 .ascii "arm_poke_function_name", 0
+\&                 .align
+\&             t1
+\&                 .word 0xff000000 + (t1 \- t0)
+\&             arm_poke_function_name
+\&                 mov     ip, sp
+\&                 stmfd   sp!, {fp, ip, lr, pc}
+\&                 sub     fp, ip, #4
+.Ve
+.Sp
+When performing a stack backtrace, code can inspect the value of
+\&\f(CW\*(C`pc\*(C'\fR stored at \f(CW\*(C`fp + 0\*(C'\fR.  If the trace function then looks at
+location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that
+there is a function name embedded immediately preceding this location
+and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR.
+.IP "\fB\-mthumb\fR" 4
+.IX Item "-mthumb"
+.PD 0
+.IP "\fB\-marm\fR" 4
+.IX Item "-marm"
+.PD
+Select between generating code that executes in \s-1ARM\s0 and Thumb
+states.  The default for most configurations is to generate code
+that executes in \s-1ARM\s0 state, but the default can be changed by
+configuring \s-1GCC\s0 with the \fB\-\-with\-mode=\fR\fIstate\fR
+configure option.
+.IP "\fB\-mtpcs\-frame\fR" 4
+.IX Item "-mtpcs-frame"
+Generate a stack frame that is compliant with the Thumb Procedure Call
+Standard for all non-leaf functions.  (A leaf function is one that does
+not call any other functions.)  The default is \fB\-mno\-tpcs\-frame\fR.
+.IP "\fB\-mtpcs\-leaf\-frame\fR" 4
+.IX Item "-mtpcs-leaf-frame"
+Generate a stack frame that is compliant with the Thumb Procedure Call
+Standard for all leaf functions.  (A leaf function is one that does
+not call any other functions.)  The default is \fB\-mno\-apcs\-leaf\-frame\fR.
+.IP "\fB\-mcallee\-super\-interworking\fR" 4
+.IX Item "-mcallee-super-interworking"
+Gives all externally visible functions in the file being compiled an \s-1ARM\s0
+instruction set header which switches to Thumb mode before executing the
+rest of the function.  This allows these functions to be called from
+non-interworking code.  This option is not valid in \s-1AAPCS\s0 configurations
+because interworking is enabled by default.
+.IP "\fB\-mcaller\-super\-interworking\fR" 4
+.IX Item "-mcaller-super-interworking"
+Allows calls via function pointers (including virtual functions) to
+execute correctly regardless of whether the target code has been
+compiled for interworking or not.  There is a small overhead in the cost
+of executing a function pointer if this option is enabled.  This option
+is not valid in \s-1AAPCS\s0 configurations because interworking is enabled
+by default.
+.IP "\fB\-mtp=\fR\fIname\fR" 4
+.IX Item "-mtp=name"
+Specify the access model for the thread local storage pointer.  The valid
+models are \fBsoft\fR, which generates calls to \f(CW\*(C`_\|_aeabi_read_tp\*(C'\fR,
+\&\fBcp15\fR, which fetches the thread pointer from \f(CW\*(C`cp15\*(C'\fR directly
+(supported in the arm6k architecture), and \fBauto\fR, which uses the
+best available method for the selected processor.  The default setting is
+\&\fBauto\fR.
+.IP "\fB\-mtls\-dialect=\fR\fIdialect\fR" 4
+.IX Item "-mtls-dialect=dialect"
+Specify the dialect to use for accessing thread local storage.  Two
+\&\fIdialect\fRs are supported\-\-\-\fBgnu\fR and \fBgnu2\fR.  The
+\&\fBgnu\fR dialect selects the original \s-1GNU\s0 scheme for supporting
+local and global dynamic \s-1TLS\s0 models.  The \fBgnu2\fR dialect
+selects the \s-1GNU\s0 descriptor scheme, which provides better performance
+for shared libraries.  The \s-1GNU\s0 descriptor scheme is compatible with
+the original scheme, but does require new assembler, linker and
+library support.  Initial and local exec \s-1TLS\s0 models are unaffected by
+this option and always use the original scheme.
+.IP "\fB\-mword\-relocations\fR" 4
+.IX Item "-mword-relocations"
+Only generate absolute relocations on word-sized values (i.e. R_ARM_ABS32).
+This is enabled by default on targets (uClinux, SymbianOS) where the runtime
+loader imposes this restriction, and when \fB\-fpic\fR or \fB\-fPIC\fR
+is specified.
+.IP "\fB\-mfix\-cortex\-m3\-ldrd\fR" 4
+.IX Item "-mfix-cortex-m3-ldrd"
+Some Cortex\-M3 cores can cause data corruption when \f(CW\*(C`ldrd\*(C'\fR instructions
+with overlapping destination and base registers are used.  This option avoids
+generating these instructions.  This option is enabled by default when
+\&\fB\-mcpu=cortex\-m3\fR is specified.
+.IP "\fB\-munaligned\-access\fR" 4
+.IX Item "-munaligned-access"
+.PD 0
+.IP "\fB\-mno\-unaligned\-access\fR" 4
+.IX Item "-mno-unaligned-access"
+.PD
+Enables (or disables) reading and writing of 16\- and 32\- bit values
+from addresses that are not 16\- or 32\- bit aligned.  By default
+unaligned access is disabled for all pre\-ARMv6 and all ARMv6\-M
+architectures, and enabled for all other architectures.  If unaligned
+access is not enabled then words in packed data structures will be
+accessed a byte at a time.
+.Sp
+The \s-1ARM\s0 attribute \f(CW\*(C`Tag_CPU_unaligned_access\*(C'\fR will be set in the
+generated object file to either true or false, depending upon the
+setting of this option.  If unaligned access is enabled then the
+preprocessor symbol \f(CW\*(C`_\|_ARM_FEATURE_UNALIGNED\*(C'\fR will also be
+defined.
+.IP "\fB\-mneon\-for\-64bits\fR" 4
+.IX Item "-mneon-for-64bits"
+Enables using Neon to handle scalar 64\-bits operations. This is
+disabled by default since the cost of moving data from core registers
+to Neon is high.
+.IP "\fB\-mslow\-flash\-data\fR" 4
+.IX Item "-mslow-flash-data"
+Assume loading data from flash is slower than fetching instruction.
+Therefore literal load is minimized for better performance.
+This option is only supported when compiling for ARMv7 M\-profile and
+off by default.
+.IP "\fB\-mrestrict\-it\fR" 4
+.IX Item "-mrestrict-it"
+Restricts generation of \s-1IT\s0 blocks to conform to the rules of ARMv8.
+\&\s-1IT\s0 blocks can only contain a single 16\-bit instruction from a select
+set of instructions. This option is on by default for ARMv8 Thumb mode.
+.PP
+\fI\s-1AVR\s0 Options\fR
+.IX Subsection "AVR Options"
+.PP
+These options are defined for \s-1AVR\s0 implementations:
+.IP "\fB\-mmcu=\fR\fImcu\fR" 4
+.IX Item "-mmcu=mcu"
+Specify Atmel \s-1AVR\s0 instruction set architectures (\s-1ISA\s0) or \s-1MCU\s0 type.
+.Sp
+The default for this option is@tie{}\f(CW\*(C`avr2\*(C'\fR.
+.Sp
+\&\s-1GCC\s0 supports the following \s-1AVR\s0 devices and ISAs:
+.RS 4
+.ie n .IP """avr2""" 4
+.el .IP "\f(CWavr2\fR" 4
+.IX Item "avr2"
+\&\*(L"Classic\*(R" devices with up to 8@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`attiny22\*(C'\fR, \f(CW\*(C`attiny26\*(C'\fR, \f(CW\*(C`at90c8534\*(C'\fR, \f(CW\*(C`at90s2313\*(C'\fR, \f(CW\*(C`at90s2323\*(C'\fR, \f(CW\*(C`at90s2333\*(C'\fR, \f(CW\*(C`at90s2343\*(C'\fR, \f(CW\*(C`at90s4414\*(C'\fR, \f(CW\*(C`at90s4433\*(C'\fR, \f(CW\*(C`at90s4434\*(C'\fR, \f(CW\*(C`at90s8515\*(C'\fR, \f(CW\*(C`at90s8535\*(C'\fR.
+.ie n .IP """avr25""" 4
+.el .IP "\f(CWavr25\fR" 4
+.IX Item "avr25"
+\&\*(L"Classic\*(R" devices with up to 8@tie{}KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`ata5272\*(C'\fR, \f(CW\*(C`ata6289\*(C'\fR, \f(CW\*(C`attiny13\*(C'\fR, \f(CW\*(C`attiny13a\*(C'\fR, \f(CW\*(C`attiny2313\*(C'\fR, \f(CW\*(C`attiny2313a\*(C'\fR, \f(CW\*(C`attiny24\*(C'\fR, \f(CW\*(C`attiny24a\*(C'\fR, \f(CW\*(C`attiny25\*(C'\fR, \f(CW\*(C`attiny261\*(C'\fR, \f(CW\*(C`attiny261a\*(C'\fR, \f(CW\*(C`attiny43u\*(C'\fR, \f(CW\*(C`attiny4313\*(C'\fR, \f(CW\*(C`attiny44\*(C'\fR, \f(CW\*(C`attiny44a\*(C'\fR, \f(CW\*(C`attiny45\*(C'\fR, \f(CW\*(C`attiny461\*(C'\fR, \f(CW\*(C`attiny461a\*(C'\fR, \f(CW\*(C`attiny48\*(C'\fR, \f(CW\*(C`attiny84\*(C'\fR, \f(CW\*(C`attiny84a\*(C'\fR, \f(CW\*(C`attiny85\*(C'\fR, \f(CW\*(C`attiny861\*(C'\fR, \f(CW\*(C`attiny861a\*(C'\fR, \f(CW\*(C`attiny87\*(C'\fR, \f(CW\*(C`attiny88\*(C'\fR, \f(CW\*(C`at86rf401\*(C'\fR.
+.ie n .IP """avr3""" 4
+.el .IP "\f(CWavr3\fR" 4
+.IX Item "avr3"
+\&\*(L"Classic\*(R" devices with 16@tie{}KiB up to 64@tie{}KiB of  program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`at43usb355\*(C'\fR, \f(CW\*(C`at76c711\*(C'\fR.
+.ie n .IP """avr31""" 4
+.el .IP "\f(CWavr31\fR" 4
+.IX Item "avr31"
+\&\*(L"Classic\*(R" devices with 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmega103\*(C'\fR, \f(CW\*(C`at43usb320\*(C'\fR.
+.ie n .IP """avr35""" 4
+.el .IP "\f(CWavr35\fR" 4
+.IX Item "avr35"
+\&\*(L"Classic\*(R" devices with 16@tie{}KiB up to 64@tie{}KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`ata5505\*(C'\fR, \f(CW\*(C`atmega16u2\*(C'\fR, \f(CW\*(C`atmega32u2\*(C'\fR, \f(CW\*(C`atmega8u2\*(C'\fR, \f(CW\*(C`attiny1634\*(C'\fR, \f(CW\*(C`attiny167\*(C'\fR, \f(CW\*(C`at90usb162\*(C'\fR, \f(CW\*(C`at90usb82\*(C'\fR.
+.ie n .IP """avr4""" 4
+.el .IP "\f(CWavr4\fR" 4
+.IX Item "avr4"
+\&\*(L"Enhanced\*(R" devices with up to 8@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`ata6285\*(C'\fR, \f(CW\*(C`ata6286\*(C'\fR, \f(CW\*(C`atmega48\*(C'\fR, \f(CW\*(C`atmega48a\*(C'\fR, \f(CW\*(C`atmega48p\*(C'\fR, \f(CW\*(C`atmega48pa\*(C'\fR, \f(CW\*(C`atmega8\*(C'\fR, \f(CW\*(C`atmega8a\*(C'\fR, \f(CW\*(C`atmega8hva\*(C'\fR, \f(CW\*(C`atmega8515\*(C'\fR, \f(CW\*(C`atmega8535\*(C'\fR, \f(CW\*(C`atmega88\*(C'\fR, \f(CW\*(C`atmega88a\*(C'\fR, \f(CW\*(C`atmega88p\*(C'\fR, \f(CW\*(C`atmega88pa\*(C'\fR, \f(CW\*(C`at90pwm1\*(C'\fR, \f(CW\*(C`at90pwm2\*(C'\fR, \f(CW\*(C`at90pwm2b\*(C'\fR, \f(CW\*(C`at90pwm3\*(C'\fR, \f(CW\*(C`at90pwm3b\*(C'\fR, \f(CW\*(C`at90pwm81\*(C'\fR.
+.ie n .IP """avr5""" 4
+.el .IP "\f(CWavr5\fR" 4
+.IX Item "avr5"
+\&\*(L"Enhanced\*(R" devices with 16@tie{}KiB up to 64@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`ata5790\*(C'\fR, \f(CW\*(C`ata5790n\*(C'\fR, \f(CW\*(C`ata5795\*(C'\fR, \f(CW\*(C`atmega16\*(C'\fR, \f(CW\*(C`atmega16a\*(C'\fR, \f(CW\*(C`atmega16hva\*(C'\fR, \f(CW\*(C`atmega16hva2\*(C'\fR, \f(CW\*(C`atmega16hvb\*(C'\fR, \f(CW\*(C`atmega16hvbrevb\*(C'\fR, \f(CW\*(C`atmega16m1\*(C'\fR, \f(CW\*(C`atmega16u4\*(C'\fR, \f(CW\*(C`atmega161\*(C'\fR, \f(CW\*(C`atmega162\*(C'\fR, \f(CW\*(C`atmega163\*(C'\fR, \f(CW\*(C`atmega164a\*(C'\fR, \f(CW\*(C`atmega164p\*(C'\fR, \f(CW\*(C`atmega164pa\*(C'\fR, \f(CW\*(C`atmega165\*(C'\fR, \f(CW\*(C`atmega165a\*(C'\fR, \f(CW\*(C`atmega165p\*(C'\fR, \f(CW\*(C`atmega165pa\*(C'\fR, \f(CW\*(C`atmega168\*(C'\fR, \f(CW\*(C`atmega168a\*(C'\fR, \f(CW\*(C`atmega168p\*(C'\fR, \f(CW\*(C`atmega168pa\*(C'\fR, \f(CW\*(C`atmega169\*(C'\fR, \f(CW\*(C`atmega169a\*(C'\fR, \f(CW\*(C`atmega169p\*(C'\fR, \f(CW\*(C`atmega169pa\*(C'\fR, \f(CW\*(C`atmega26hvg\*(C'\fR, \f(CW\*(C`atmega32\*(C'\fR, \f(CW\*(C`atmega32a\*(C'\fR, \f(CW\*(C`atmega32c1\*(C'\fR, \f(CW\*(C`atmega32hvb\*(C'\fR, \f(CW\*(C`atmega32hvbrevb\*(C'\fR, \f(CW\*(C`atmega32m1\*(C'\fR, \f(CW\*(C`atmega32u4\*(C'\fR, \f(CW\*(C`atmega32u6\*(C'\fR, \f(CW\*(C`atmega323\*(C'\fR, \f(CW\*(C`atmega324a\*(C'\fR, \f(CW\*(C`atmega324p\*(C'\fR, \f(CW\*(C`atmega324pa\*(C'\fR, \f(CW\*(C`atmega325\*(C'\fR, \f(CW\*(C`atmega325a\*(C'\fR, \f(CW\*(C`atmega325p\*(C'\fR, \f(CW\*(C`atmega3250\*(C'\fR, \f(CW\*(C`atmega3250a\*(C'\fR, \f(CW\*(C`atmega3250p\*(C'\fR, \f(CW\*(C`atmega3250pa\*(C'\fR, \f(CW\*(C`atmega328\*(C'\fR, \f(CW\*(C`atmega328p\*(C'\fR, \f(CW\*(C`atmega329\*(C'\fR, \f(CW\*(C`atmega329a\*(C'\fR, \f(CW\*(C`atmega329p\*(C'\fR, \f(CW\*(C`atmega329pa\*(C'\fR, \f(CW\*(C`atmega3290\*(C'\fR, \f(CW\*(C`atmega3290a\*(C'\fR, \f(CW\*(C`atmega3290p\*(C'\fR, \f(CW\*(C`atmega3290pa\*(C'\fR, \f(CW\*(C`atmega406\*(C'\fR, \f(CW\*(C`atmega48hvf\*(C'\fR, \f(CW\*(C`atmega64\*(C'\fR, \f(CW\*(C`atmega64a\*(C'\fR, \f(CW\*(C`atmega64c1\*(C'\fR, \f(CW\*(C`atmega64hve\*(C'\fR, \f(CW\*(C`atmega64m1\*(C'\fR, \f(CW\*(C`atmega64rfa2\*(C'\fR, \f(CW\*(C`atmega64rfr2\*(C'\fR, \f(CW\*(C`atmega640\*(C'\fR, \f(CW\*(C`atmega644\*(C'\fR, \f(CW\*(C`atmega644a\*(C'\fR, \f(CW\*(C`atmega644p\*(C'\fR, \f(CW\*(C`atmega644pa\*(C'\fR, \f(CW\*(C`atmega645\*(C'\fR, \f(CW\*(C`atmega645a\*(C'\fR, \f(CW\*(C`atmega645p\*(C'\fR, \f(CW\*(C`atmega6450\*(C'\fR, \f(CW\*(C`atmega6450a\*(C'\fR, \f(CW\*(C`atmega6450p\*(C'\fR, \f(CW\*(C`atmega649\*(C'\fR, \f(CW\*(C`atmega649a\*(C'\fR, \f(CW\*(C`atmega649p\*(C'\fR, \f(CW\*(C`atmega6490\*(C'\fR, \f(CW\*(C`atmega6490a\*(C'\fR, \f(CW\*(C`atmega6490p\*(C'\fR, \f(CW\*(C`at90can32\*(C'\fR, \f(CW\*(C`at90can64\*(C'\fR, \f(CW\*(C`at90pwm161\*(C'\fR, \f(CW\*(C`at90pwm216\*(C'\fR, \f(CW\*(C`at90pwm316\*(C'\fR, \f(CW\*(C`at90scr100\*(C'\fR, \f(CW\*(C`at90usb646\*(C'\fR, \f(CW\*(C`at90usb647\*(C'\fR, \f(CW\*(C`at94k\*(C'\fR, \f(CW\*(C`m3000\*(C'\fR.
+.ie n .IP """avr51""" 4
+.el .IP "\f(CWavr51\fR" 4
+.IX Item "avr51"
+\&\*(L"Enhanced\*(R" devices with 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmega128\*(C'\fR, \f(CW\*(C`atmega128a\*(C'\fR, \f(CW\*(C`atmega128rfa1\*(C'\fR, \f(CW\*(C`atmega1280\*(C'\fR, \f(CW\*(C`atmega1281\*(C'\fR, \f(CW\*(C`atmega1284\*(C'\fR, \f(CW\*(C`atmega1284p\*(C'\fR, \f(CW\*(C`at90can128\*(C'\fR, \f(CW\*(C`at90usb1286\*(C'\fR, \f(CW\*(C`at90usb1287\*(C'\fR.
+.ie n .IP """avr6""" 4
+.el .IP "\f(CWavr6\fR" 4
+.IX Item "avr6"
+\&\*(L"Enhanced\*(R" devices with 3\-byte \s-1PC,\s0 i.e. with more than 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmega2560\*(C'\fR, \f(CW\*(C`atmega2561\*(C'\fR.
+.ie n .IP """avrxmega2""" 4
+.el .IP "\f(CWavrxmega2\fR" 4
+.IX Item "avrxmega2"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 8@tie{}KiB and up to 64@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmxt112sl\*(C'\fR, \f(CW\*(C`atmxt224\*(C'\fR, \f(CW\*(C`atmxt224e\*(C'\fR, \f(CW\*(C`atmxt336s\*(C'\fR, \f(CW\*(C`atxmega16a4\*(C'\fR, \f(CW\*(C`atxmega16a4u\*(C'\fR, \f(CW\*(C`atxmega16c4\*(C'\fR, \f(CW\*(C`atxmega16d4\*(C'\fR, \f(CW\*(C`atxmega32a4\*(C'\fR, \f(CW\*(C`atxmega32a4u\*(C'\fR, \f(CW\*(C`atxmega32c4\*(C'\fR, \f(CW\*(C`atxmega32d4\*(C'\fR, \f(CW\*(C`atxmega32e5\*(C'\fR, \f(CW\*(C`atxmega32x1\*(C'\fR.
+.ie n .IP """avrxmega4""" 4
+.el .IP "\f(CWavrxmega4\fR" 4
+.IX Item "avrxmega4"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atxmega64a3\*(C'\fR, \f(CW\*(C`atxmega64a3u\*(C'\fR, \f(CW\*(C`atxmega64a4u\*(C'\fR, \f(CW\*(C`atxmega64b1\*(C'\fR, \f(CW\*(C`atxmega64b3\*(C'\fR, \f(CW\*(C`atxmega64c3\*(C'\fR, \f(CW\*(C`atxmega64d3\*(C'\fR, \f(CW\*(C`atxmega64d4\*(C'\fR.
+.ie n .IP """avrxmega5""" 4
+.el .IP "\f(CWavrxmega5\fR" 4
+.IX Item "avrxmega5"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory and more than 64@tie{}KiB of \s-1RAM.
+\&\s0\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atxmega64a1\*(C'\fR, \f(CW\*(C`atxmega64a1u\*(C'\fR.
+.ie n .IP """avrxmega6""" 4
+.el .IP "\f(CWavrxmega6\fR" 4
+.IX Item "avrxmega6"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmxt540s\*(C'\fR, \f(CW\*(C`atmxt540sreva\*(C'\fR, \f(CW\*(C`atxmega128a3\*(C'\fR, \f(CW\*(C`atxmega128a3u\*(C'\fR, \f(CW\*(C`atxmega128b1\*(C'\fR, \f(CW\*(C`atxmega128b3\*(C'\fR, \f(CW\*(C`atxmega128c3\*(C'\fR, \f(CW\*(C`atxmega128d3\*(C'\fR, \f(CW\*(C`atxmega128d4\*(C'\fR, \f(CW\*(C`atxmega192a3\*(C'\fR, \f(CW\*(C`atxmega192a3u\*(C'\fR, \f(CW\*(C`atxmega192c3\*(C'\fR, \f(CW\*(C`atxmega192d3\*(C'\fR, \f(CW\*(C`atxmega256a3\*(C'\fR, \f(CW\*(C`atxmega256a3b\*(C'\fR, \f(CW\*(C`atxmega256a3bu\*(C'\fR, \f(CW\*(C`atxmega256a3u\*(C'\fR, \f(CW\*(C`atxmega256c3\*(C'\fR, \f(CW\*(C`atxmega256d3\*(C'\fR, \f(CW\*(C`atxmega384c3\*(C'\fR, \f(CW\*(C`atxmega384d3\*(C'\fR.
+.ie n .IP """avrxmega7""" 4
+.el .IP "\f(CWavrxmega7\fR" 4
+.IX Item "avrxmega7"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 128@tie{}KiB of program memory and more than 64@tie{}KiB of \s-1RAM.
+\&\s0\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atxmega128a1\*(C'\fR, \f(CW\*(C`atxmega128a1u\*(C'\fR, \f(CW\*(C`atxmega128a4u\*(C'\fR.
+.ie n .IP """avr1""" 4
+.el .IP "\f(CWavr1\fR" 4
+.IX Item "avr1"
+This \s-1ISA\s0 is implemented by the minimal \s-1AVR\s0 core and supported for assembler only.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`attiny11\*(C'\fR, \f(CW\*(C`attiny12\*(C'\fR, \f(CW\*(C`attiny15\*(C'\fR, \f(CW\*(C`attiny28\*(C'\fR, \f(CW\*(C`at90s1200\*(C'\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-maccumulate\-args\fR" 4
+.IX Item "-maccumulate-args"
+Accumulate outgoing function arguments and acquire/release the needed
+stack space for outgoing function arguments once in function
+prologue/epilogue.  Without this option, outgoing arguments are pushed
+before calling a function and popped afterwards.
+.Sp
+Popping the arguments after the function call can be expensive on
+\&\s-1AVR\s0 so that accumulating the stack space might lead to smaller
+executables because arguments need not to be removed from the
+stack after such a function call.
+.Sp
+This option can lead to reduced code size for functions that perform
+several calls to functions that get their arguments on the stack like
+calls to printf-like functions.
+.IP "\fB\-mbranch\-cost=\fR\fIcost\fR" 4
+.IX Item "-mbranch-cost=cost"
+Set the branch costs for conditional branch instructions to
+\&\fIcost\fR.  Reasonable values for \fIcost\fR are small, non-negative
+integers. The default branch cost is 0.
+.IP "\fB\-mcall\-prologues\fR" 4
+.IX Item "-mcall-prologues"
+Functions prologues/epilogues are expanded as calls to appropriate
+subroutines.  Code size is smaller.
+.IP "\fB\-mint8\fR" 4
+.IX Item "-mint8"
+Assume \f(CW\*(C`int\*(C'\fR to be 8\-bit integer.  This affects the sizes of all types: a
+\&\f(CW\*(C`char\*(C'\fR is 1 byte, an \f(CW\*(C`int\*(C'\fR is 1 byte, a \f(CW\*(C`long\*(C'\fR is 2 bytes,
+and \f(CW\*(C`long long\*(C'\fR is 4 bytes.  Please note that this option does not
+conform to the C standards, but it results in smaller code
+size.
+.IP "\fB\-mno\-interrupts\fR" 4
+.IX Item "-mno-interrupts"
+Generated code is not compatible with hardware interrupts.
+Code size is smaller.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Try to replace \f(CW\*(C`CALL\*(C'\fR resp. \f(CW\*(C`JMP\*(C'\fR instruction by the shorter
+\&\f(CW\*(C`RCALL\*(C'\fR resp. \f(CW\*(C`RJMP\*(C'\fR instruction if applicable.
+Setting \f(CW\*(C`\-mrelax\*(C'\fR just adds the \f(CW\*(C`\-\-relax\*(C'\fR option to the
+linker command line when the linker is called.
+.Sp
+Jump relaxing is performed by the linker because jump offsets are not
+known before code is located. Therefore, the assembler code generated by the
+compiler is the same, but the instructions in the executable may
+differ from instructions in the assembler code.
+.Sp
+Relaxing must be turned on if linker stubs are needed, see the
+section on \f(CW\*(C`EIND\*(C'\fR and linker stubs below.
+.IP "\fB\-msp8\fR" 4
+.IX Item "-msp8"
+Treat the stack pointer register as an 8\-bit register,
+i.e. assume the high byte of the stack pointer is zero.
+In general, you don't need to set this option by hand.
+.Sp
+This option is used internally by the compiler to select and
+build multilibs for architectures \f(CW\*(C`avr2\*(C'\fR and \f(CW\*(C`avr25\*(C'\fR.
+These architectures mix devices with and without \f(CW\*(C`SPH\*(C'\fR.
+For any setting other than \f(CW\*(C`\-mmcu=avr2\*(C'\fR or \f(CW\*(C`\-mmcu=avr25\*(C'\fR
+the compiler driver will add or remove this option from the compiler
+proper's command line, because the compiler then knows if the device
+or architecture has an 8\-bit stack pointer and thus no \f(CW\*(C`SPH\*(C'\fR
+register or not.
+.IP "\fB\-mstrict\-X\fR" 4
+.IX Item "-mstrict-X"
+Use address register \f(CW\*(C`X\*(C'\fR in a way proposed by the hardware.  This means
+that \f(CW\*(C`X\*(C'\fR is only used in indirect, post-increment or
+pre-decrement addressing.
+.Sp
+Without this option, the \f(CW\*(C`X\*(C'\fR register may be used in the same way
+as \f(CW\*(C`Y\*(C'\fR or \f(CW\*(C`Z\*(C'\fR which then is emulated by additional
+instructions.  
+For example, loading a value with \f(CW\*(C`X+const\*(C'\fR addressing with a
+small non-negative \f(CW\*(C`const < 64\*(C'\fR to a register \fIRn\fR is
+performed as
+.Sp
+.Vb 3
+\&        adiw r26, const   ; X += const
+\&        ld   <Rn>, X        ; <Rn> = *X
+\&        sbiw r26, const   ; X \-= const
+.Ve
+.IP "\fB\-mtiny\-stack\fR" 4
+.IX Item "-mtiny-stack"
+Only change the lower 8@tie{}bits of the stack pointer.
+.IP "\fB\-Waddr\-space\-convert\fR" 4
+.IX Item "-Waddr-space-convert"
+Warn about conversions between address spaces in the case where the
+resulting address space is not contained in the incoming address space.
+.PP
+\f(CW\*(C`EIND\*(C'\fR and Devices with more than 128 Ki Bytes of Flash
+.IX Subsection "EIND and Devices with more than 128 Ki Bytes of Flash"
+.PP
+Pointers in the implementation are 16@tie{}bits wide.
+The address of a function or label is represented as word address so
+that indirect jumps and calls can target any code address in the
+range of 64@tie{}Ki words.
+.PP
+In order to facilitate indirect jump on devices with more than 128@tie{}Ki
+bytes of program memory space, there is a special function register called
+\&\f(CW\*(C`EIND\*(C'\fR that serves as most significant part of the target address
+when \f(CW\*(C`EICALL\*(C'\fR or \f(CW\*(C`EIJMP\*(C'\fR instructions are used.
+.PP
+Indirect jumps and calls on these devices are handled as follows by
+the compiler and are subject to some limitations:
+.IP "\(bu" 4
+The compiler never sets \f(CW\*(C`EIND\*(C'\fR.
+.IP "\(bu" 4
+The compiler uses \f(CW\*(C`EIND\*(C'\fR implicitely in \f(CW\*(C`EICALL\*(C'\fR/\f(CW\*(C`EIJMP\*(C'\fR
+instructions or might read \f(CW\*(C`EIND\*(C'\fR directly in order to emulate an
+indirect call/jump by means of a \f(CW\*(C`RET\*(C'\fR instruction.
+.IP "\(bu" 4
+The compiler assumes that \f(CW\*(C`EIND\*(C'\fR never changes during the startup
+code or during the application. In particular, \f(CW\*(C`EIND\*(C'\fR is not
+saved/restored in function or interrupt service routine
+prologue/epilogue.
+.IP "\(bu" 4
+For indirect calls to functions and computed goto, the linker
+generates \fIstubs\fR. Stubs are jump pads sometimes also called
+\&\fItrampolines\fR. Thus, the indirect call/jump jumps to such a stub.
+The stub contains a direct jump to the desired address.
+.IP "\(bu" 4
+Linker relaxation must be turned on so that the linker will generate
+the stubs correctly an all situaltion. See the compiler option
+\&\f(CW\*(C`\-mrelax\*(C'\fR and the linler option \f(CW\*(C`\-\-relax\*(C'\fR.
+There are corner cases where the linker is supposed to generate stubs
+but aborts without relaxation and without a helpful error message.
+.IP "\(bu" 4
+The default linker script is arranged for code with \f(CW\*(C`EIND = 0\*(C'\fR.
+If code is supposed to work for a setup with \f(CW\*(C`EIND != 0\*(C'\fR, a custom
+linker script has to be used in order to place the sections whose
+name start with \f(CW\*(C`.trampolines\*(C'\fR into the segment where \f(CW\*(C`EIND\*(C'\fR
+points to.
+.IP "\(bu" 4
+The startup code from libgcc never sets \f(CW\*(C`EIND\*(C'\fR.
+Notice that startup code is a blend of code from libgcc and AVR-LibC.
+For the impact of AVR-LibC on \f(CW\*(C`EIND\*(C'\fR, see the
+AVR-LibC\ user\ manual (\f(CW\*(C`http://nongnu.org/avr\-libc/user\-manual/\*(C'\fR).
+.IP "\(bu" 4
+It is legitimate for user-specific startup code to set up \f(CW\*(C`EIND\*(C'\fR
+early, for example by means of initialization code located in
+section \f(CW\*(C`.init3\*(C'\fR. Such code runs prior to general startup code
+that initializes \s-1RAM\s0 and calls constructors, but after the bit
+of startup code from AVR-LibC that sets \f(CW\*(C`EIND\*(C'\fR to the segment
+where the vector table is located.
+.Sp
+.Vb 1
+\&        #include <avr/io.h>
+\&        
+\&        static void
+\&        _\|_attribute_\|_((section(".init3"),naked,used,no_instrument_function))
+\&        init3_set_eind (void)
+\&        {
+\&          _\|_asm volatile ("ldi r24,pm_hh8(_\|_trampolines_start)\en\et"
+\&                          "out %i0,r24" :: "n" (&EIND) : "r24","memory");
+\&        }
+.Ve
+.Sp
+The \f(CW\*(C`_\|_trampolines_start\*(C'\fR symbol is defined in the linker script.
+.IP "\(bu" 4
+Stubs are generated automatically by the linker if
+the following two conditions are met:
+.RS 4
+.ie n .IP "\-<The address of a label is taken by means of the ""gs"" modifier>" 4
+.el .IP "\-<The address of a label is taken by means of the \f(CWgs\fR modifier>" 4
+.IX Item "-<The address of a label is taken by means of the gs modifier>"
+(short for \fIgenerate stubs\fR) like so:
+.Sp
+.Vb 2
+\&        LDI r24, lo8(gs(<func>))
+\&        LDI r25, hi8(gs(<func>))
+.Ve
+.IP "\-<The final location of that label is in a code segment>" 4
+.IX Item "-<The final location of that label is in a code segment>"
+\&\fIoutside\fR the segment where the stubs are located.
+.RE
+.RS 4
+.RE
+.IP "\(bu" 4
+The compiler emits such \f(CW\*(C`gs\*(C'\fR modifiers for code labels in the
+following situations:
+.RS 4
+.IP "\-<Taking address of a function or code label.>" 4
+.IX Item "-<Taking address of a function or code label.>"
+.PD 0
+.IP "\-<Computed goto.>" 4
+.IX Item "-<Computed goto.>"
+.IP "\-<If prologue-save function is used, see \fB\-mcall\-prologues\fR>" 4
+.IX Item "-<If prologue-save function is used, see -mcall-prologues>"
+.PD
+command-line option.
+.IP "\-<Switch/case dispatch tables. If you do not want such dispatch>" 4
+.IX Item "-<Switch/case dispatch tables. If you do not want such dispatch>"
+tables you can specify the \fB\-fno\-jump\-tables\fR command-line option.
+.IP "\-<C and \*(C+ constructors/destructors called during startup/shutdown.>" 4
+.IX Item "-<C and constructors/destructors called during startup/shutdown.>"
+.PD 0
+.ie n .IP "\-<If the tools hit a ""gs()"" modifier explained above.>" 4
+.el .IP "\-<If the tools hit a \f(CWgs()\fR modifier explained above.>" 4
+.IX Item "-<If the tools hit a gs() modifier explained above.>"
+.RE
+.RS 4
+.RE
+.IP "\(bu" 4
+.PD
+Jumping to non-symbolic addresses like so is \fInot\fR supported:
+.Sp
+.Vb 5
+\&        int main (void)
+\&        {
+\&            /* Call function at word address 0x2 */
+\&            return ((int(*)(void)) 0x2)();
+\&        }
+.Ve
+.Sp
+Instead, a stub has to be set up, i.e. the function has to be called
+through a symbol (\f(CW\*(C`func_4\*(C'\fR in the example):
+.Sp
+.Vb 3
+\&        int main (void)
+\&        {
+\&            extern int func_4 (void);
+\&        
+\&            /* Call function at byte address 0x4 */
+\&            return func_4();
+\&        }
+.Ve
+.Sp
+and the application be linked with \f(CW\*(C`\-Wl,\-\-defsym,func_4=0x4\*(C'\fR.
+Alternatively, \f(CW\*(C`func_4\*(C'\fR can be defined in the linker script.
+.PP
+Handling of the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR and \f(CW\*(C`RAMPZ\*(C'\fR Special Function Registers
+.IX Subsection "Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers"
+.PP
+Some \s-1AVR\s0 devices support memories larger than the 64@tie{}KiB range
+that can be accessed with 16\-bit pointers.  To access memory locations
+outside this 64@tie{}KiB range, the contentent of a \f(CW\*(C`RAMP\*(C'\fR
+register is used as high part of the address:
+The \f(CW\*(C`X\*(C'\fR, \f(CW\*(C`Y\*(C'\fR, \f(CW\*(C`Z\*(C'\fR address register is concatenated
+with the \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR, \f(CW\*(C`RAMPZ\*(C'\fR special function
+register, respectively, to get a wide address. Similarly,
+\&\f(CW\*(C`RAMPD\*(C'\fR is used together with direct addressing.
+.IP "\(bu" 4
+The startup code initializes the \f(CW\*(C`RAMP\*(C'\fR special function
+registers with zero.
+.IP "\(bu" 4
+If a \fB\s-1AVR\s0 Named Address Spaces,named address space\fR other than
+generic or \f(CW\*(C`_\|_flash\*(C'\fR is used, then \f(CW\*(C`RAMPZ\*(C'\fR is set
+as needed before the operation.
+.IP "\(bu" 4
+If the device supports \s-1RAM\s0 larger than 64@tie{}KiB and the compiler
+needs to change \f(CW\*(C`RAMPZ\*(C'\fR to accomplish an operation, \f(CW\*(C`RAMPZ\*(C'\fR
+is reset to zero after the operation.
+.IP "\(bu" 4
+If the device comes with a specific \f(CW\*(C`RAMP\*(C'\fR register, the \s-1ISR\s0
+prologue/epilogue saves/restores that \s-1SFR\s0 and initializes it with
+zero in case the \s-1ISR\s0 code might (implicitly) use it.
+.IP "\(bu" 4
+\&\s-1RAM\s0 larger than 64@tie{}KiB is not supported by \s-1GCC\s0 for \s-1AVR\s0 targets.
+If you use inline assembler to read from locations outside the
+16\-bit address range and change one of the \f(CW\*(C`RAMP\*(C'\fR registers,
+you must reset it to zero after the access.
+.PP
+\s-1AVR\s0 Built-in Macros
+.IX Subsection "AVR Built-in Macros"
+.PP
+\&\s-1GCC\s0 defines several built-in macros so that the user code can test
+for the presence or absence of features.  Almost any of the following
+built-in macros are deduced from device capabilities and thus
+triggered by the \f(CW\*(C`\-mmcu=\*(C'\fR command-line option.
+.PP
+For even more AVR-specific built-in macros see
+\&\fB\s-1AVR\s0 Named Address Spaces\fR and \fB\s-1AVR\s0 Built-in Functions\fR.
+.ie n .IP """_\|_AVR_ARCH_\|_""" 4
+.el .IP "\f(CW_\|_AVR_ARCH_\|_\fR" 4
+.IX Item "__AVR_ARCH__"
+Build-in macro that resolves to a decimal number that identifies the
+architecture and depends on the \f(CW\*(C`\-mmcu=\f(CImcu\f(CW\*(C'\fR option.
+Possible values are:
+.Sp
+\&\f(CW2\fR, \f(CW25\fR, \f(CW3\fR, \f(CW31\fR, \f(CW35\fR,
+\&\f(CW4\fR, \f(CW5\fR, \f(CW51\fR, \f(CW6\fR, \f(CW102\fR, \f(CW104\fR,
+\&\f(CW105\fR, \f(CW106\fR, \f(CW107\fR
+.Sp
+for \fImcu\fR=\f(CW\*(C`avr2\*(C'\fR, \f(CW\*(C`avr25\*(C'\fR, \f(CW\*(C`avr3\*(C'\fR,
+\&\f(CW\*(C`avr31\*(C'\fR, \f(CW\*(C`avr35\*(C'\fR, \f(CW\*(C`avr4\*(C'\fR, \f(CW\*(C`avr5\*(C'\fR, \f(CW\*(C`avr51\*(C'\fR,
+\&\f(CW\*(C`avr6\*(C'\fR, \f(CW\*(C`avrxmega2\*(C'\fR, \f(CW\*(C`avrxmega4\*(C'\fR, \f(CW\*(C`avrxmega5\*(C'\fR,
+\&\f(CW\*(C`avrxmega6\*(C'\fR, \f(CW\*(C`avrxmega7\*(C'\fR, respectively.
+If \fImcu\fR specifies a device, this built-in macro is set
+accordingly. For example, with \f(CW\*(C`\-mmcu=atmega8\*(C'\fR the macro will be
+defined to \f(CW4\fR.
+.ie n .IP """_\|_AVR_\f(CIDevice\f(CW_\|_""" 4
+.el .IP "\f(CW_\|_AVR_\f(CIDevice\f(CW_\|_\fR" 4
+.IX Item "__AVR_Device__"
+Setting \f(CW\*(C`\-mmcu=\f(CIdevice\f(CW\*(C'\fR defines this built-in macro which reflects
+the device's name. For example, \f(CW\*(C`\-mmcu=atmega8\*(C'\fR defines the
+built-in macro \f(CW\*(C`_\|_AVR_ATmega8_\|_\*(C'\fR, \f(CW\*(C`\-mmcu=attiny261a\*(C'\fR defines
+\&\f(CW\*(C`_\|_AVR_ATtiny261A_\|_\*(C'\fR, etc.
+.Sp
+The built-in macros' names follow
+the scheme \f(CW\*(C`_\|_AVR_\f(CIDevice\f(CW_\|_\*(C'\fR where \fIDevice\fR is
+the device name as from the \s-1AVR\s0 user manual. The difference between
+\&\fIDevice\fR in the built-in macro and \fIdevice\fR in
+\&\f(CW\*(C`\-mmcu=\f(CIdevice\f(CW\*(C'\fR is that the latter is always lowercase.
+.Sp
+If \fIdevice\fR is not a device but only a core architecture like
+\&\f(CW\*(C`avr51\*(C'\fR, this macro will not be defined.
+.ie n .IP """_\|_AVR_XMEGA_\|_""" 4
+.el .IP "\f(CW_\|_AVR_XMEGA_\|_\fR" 4
+.IX Item "__AVR_XMEGA__"
+The device / architecture belongs to the \s-1XMEGA\s0 family of devices.
+.ie n .IP """_\|_AVR_HAVE_ELPM_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_ELPM_\|_\fR" 4
+.IX Item "__AVR_HAVE_ELPM__"
+The device has the the \f(CW\*(C`ELPM\*(C'\fR instruction.
+.ie n .IP """_\|_AVR_HAVE_ELPMX_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_ELPMX_\|_\fR" 4
+.IX Item "__AVR_HAVE_ELPMX__"
+The device has the \f(CW\*(C`ELPM R\f(CIn\f(CW,Z\*(C'\fR and \f(CW\*(C`ELPM
+R\f(CIn\f(CW,Z+\*(C'\fR instructions.
+.ie n .IP """_\|_AVR_HAVE_MOVW_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_MOVW_\|_\fR" 4
+.IX Item "__AVR_HAVE_MOVW__"
+The device has the \f(CW\*(C`MOVW\*(C'\fR instruction to perform 16\-bit
+register-register moves.
+.ie n .IP """_\|_AVR_HAVE_LPMX_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_LPMX_\|_\fR" 4
+.IX Item "__AVR_HAVE_LPMX__"
+The device has the \f(CW\*(C`LPM R\f(CIn\f(CW,Z\*(C'\fR and
+\&\f(CW\*(C`LPM R\f(CIn\f(CW,Z+\*(C'\fR instructions.
+.ie n .IP """_\|_AVR_HAVE_MUL_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_MUL_\|_\fR" 4
+.IX Item "__AVR_HAVE_MUL__"
+The device has a hardware multiplier.
+.ie n .IP """_\|_AVR_HAVE_JMP_CALL_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_JMP_CALL_\|_\fR" 4
+.IX Item "__AVR_HAVE_JMP_CALL__"
+The device has the \f(CW\*(C`JMP\*(C'\fR and \f(CW\*(C`CALL\*(C'\fR instructions.
+This is the case for devices with at least 16@tie{}KiB of program
+memory.
+.ie n .IP """_\|_AVR_HAVE_EIJMP_EICALL_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_EIJMP_EICALL_\|_\fR" 4
+.IX Item "__AVR_HAVE_EIJMP_EICALL__"
+.PD 0
+.ie n .IP """_\|_AVR_3_BYTE_PC_\|_""" 4
+.el .IP "\f(CW_\|_AVR_3_BYTE_PC_\|_\fR" 4
+.IX Item "__AVR_3_BYTE_PC__"
+.PD
+The device has the \f(CW\*(C`EIJMP\*(C'\fR and \f(CW\*(C`EICALL\*(C'\fR instructions.
+This is the case for devices with more than 128@tie{}KiB of program memory.
+This also means that the program counter
+(\s-1PC\s0) is 3@tie{}bytes wide.
+.ie n .IP """_\|_AVR_2_BYTE_PC_\|_""" 4
+.el .IP "\f(CW_\|_AVR_2_BYTE_PC_\|_\fR" 4
+.IX Item "__AVR_2_BYTE_PC__"
+The program counter (\s-1PC\s0) is 2@tie{}bytes wide. This is the case for devices
+with up to 128@tie{}KiB of program memory.
+.ie n .IP """_\|_AVR_HAVE_8BIT_SP_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_8BIT_SP_\|_\fR" 4
+.IX Item "__AVR_HAVE_8BIT_SP__"
+.PD 0
+.ie n .IP """_\|_AVR_HAVE_16BIT_SP_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_16BIT_SP_\|_\fR" 4
+.IX Item "__AVR_HAVE_16BIT_SP__"
+.PD
+The stack pointer (\s-1SP\s0) register is treated as 8\-bit respectively
+16\-bit register by the compiler.
+The definition of these macros is affected by \f(CW\*(C`\-mtiny\-stack\*(C'\fR.
+.ie n .IP """_\|_AVR_HAVE_SPH_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_SPH_\|_\fR" 4
+.IX Item "__AVR_HAVE_SPH__"
+.PD 0
+.ie n .IP """_\|_AVR_SP8_\|_""" 4
+.el .IP "\f(CW_\|_AVR_SP8_\|_\fR" 4
+.IX Item "__AVR_SP8__"
+.PD
+The device has the \s-1SPH \s0(high part of stack pointer) special function
+register or has an 8\-bit stack pointer, respectively.
+The definition of these macros is affected by \f(CW\*(C`\-mmcu=\*(C'\fR and
+in the cases of \f(CW\*(C`\-mmcu=avr2\*(C'\fR and \f(CW\*(C`\-mmcu=avr25\*(C'\fR also
+by \f(CW\*(C`\-msp8\*(C'\fR.
+.ie n .IP """_\|_AVR_HAVE_RAMPD_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_RAMPD_\|_\fR" 4
+.IX Item "__AVR_HAVE_RAMPD__"
+.PD 0
+.ie n .IP """_\|_AVR_HAVE_RAMPX_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_RAMPX_\|_\fR" 4
+.IX Item "__AVR_HAVE_RAMPX__"
+.ie n .IP """_\|_AVR_HAVE_RAMPY_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_RAMPY_\|_\fR" 4
+.IX Item "__AVR_HAVE_RAMPY__"
+.ie n .IP """_\|_AVR_HAVE_RAMPZ_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_RAMPZ_\|_\fR" 4
+.IX Item "__AVR_HAVE_RAMPZ__"
+.PD
+The device has the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR,
+\&\f(CW\*(C`RAMPZ\*(C'\fR special function register, respectively.
+.ie n .IP """_\|_NO_INTERRUPTS_\|_""" 4
+.el .IP "\f(CW_\|_NO_INTERRUPTS_\|_\fR" 4
+.IX Item "__NO_INTERRUPTS__"
+This macro reflects the \f(CW\*(C`\-mno\-interrupts\*(C'\fR command line option.
+.ie n .IP """_\|_AVR_ERRATA_SKIP_\|_""" 4
+.el .IP "\f(CW_\|_AVR_ERRATA_SKIP_\|_\fR" 4
+.IX Item "__AVR_ERRATA_SKIP__"
+.PD 0
+.ie n .IP """_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_""" 4
+.el .IP "\f(CW_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_\fR" 4
+.IX Item "__AVR_ERRATA_SKIP_JMP_CALL__"
+.PD
+Some \s-1AVR\s0 devices (\s-1AT90S8515,\s0 ATmega103) must not skip 32\-bit
+instructions because of a hardware erratum.  Skip instructions are
+\&\f(CW\*(C`SBRS\*(C'\fR, \f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR and \f(CW\*(C`CPSE\*(C'\fR.
+The second macro is only defined if \f(CW\*(C`_\|_AVR_HAVE_JMP_CALL_\|_\*(C'\fR is also
+set.
+.ie n .IP """_\|_AVR_ISA_RMW_\|_""" 4
+.el .IP "\f(CW_\|_AVR_ISA_RMW_\|_\fR" 4
+.IX Item "__AVR_ISA_RMW__"
+The device has Read-Modify-Write instructions (\s-1XCH, LAC, LAS\s0 and \s-1LAT\s0).
+.ie n .IP """_\|_AVR_SFR_OFFSET_\|_=\f(CIoffset\f(CW""" 4
+.el .IP "\f(CW_\|_AVR_SFR_OFFSET_\|_=\f(CIoffset\f(CW\fR" 4
+.IX Item "__AVR_SFR_OFFSET__=offset"
+Instructions that can address I/O special function registers directly
+like \f(CW\*(C`IN\*(C'\fR, \f(CW\*(C`OUT\*(C'\fR, \f(CW\*(C`SBI\*(C'\fR, etc. may use a different
+address as if addressed by an instruction to access \s-1RAM\s0 like \f(CW\*(C`LD\*(C'\fR
+or \f(CW\*(C`STS\*(C'\fR. This offset depends on the device architecture and has
+to be subtracted from the \s-1RAM\s0 address in order to get the
+respective I/O@tie{}address.
+.ie n .IP """_\|_WITH_AVRLIBC_\|_""" 4
+.el .IP "\f(CW_\|_WITH_AVRLIBC_\|_\fR" 4
+.IX Item "__WITH_AVRLIBC__"
+The compiler is configured to be used together with AVR-Libc.
+See the \f(CW\*(C`\-\-with\-avrlibc\*(C'\fR configure option.
+.PP
+\fIBlackfin Options\fR
+.IX Subsection "Blackfin Options"
+.IP "\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR]" 4
+.IX Item "-mcpu=cpu[-sirevision]"
+Specifies the name of the target Blackfin processor.  Currently, \fIcpu\fR
+can be one of \fBbf512\fR, \fBbf514\fR, \fBbf516\fR, \fBbf518\fR,
+\&\fBbf522\fR, \fBbf523\fR, \fBbf524\fR, \fBbf525\fR, \fBbf526\fR,
+\&\fBbf527\fR, \fBbf531\fR, \fBbf532\fR, \fBbf533\fR,
+\&\fBbf534\fR, \fBbf536\fR, \fBbf537\fR, \fBbf538\fR, \fBbf539\fR,
+\&\fBbf542\fR, \fBbf544\fR, \fBbf547\fR, \fBbf548\fR, \fBbf549\fR,
+\&\fBbf542m\fR, \fBbf544m\fR, \fBbf547m\fR, \fBbf548m\fR, \fBbf549m\fR,
+\&\fBbf561\fR, \fBbf592\fR.
+.Sp
+The optional \fIsirevision\fR specifies the silicon revision of the target
+Blackfin processor.  Any workarounds available for the targeted silicon revision
+are enabled.  If \fIsirevision\fR is \fBnone\fR, no workarounds are enabled.
+If \fIsirevision\fR is \fBany\fR, all workarounds for the targeted processor
+are enabled.  The \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR macro is defined to two
+hexadecimal digits representing the major and minor numbers in the silicon
+revision.  If \fIsirevision\fR is \fBnone\fR, the \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR
+is not defined.  If \fIsirevision\fR is \fBany\fR, the
+\&\f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR is defined to be \f(CW0xffff\fR.
+If this optional \fIsirevision\fR is not used, \s-1GCC\s0 assumes the latest known
+silicon revision of the targeted Blackfin processor.
+.Sp
+\&\s-1GCC\s0 defines a preprocessor macro for the specified \fIcpu\fR.
+For the \fBbfin-elf\fR toolchain, this option causes the hardware \s-1BSP\s0
+provided by libgloss to be linked in if \fB\-msim\fR is not given.
+.Sp
+Without this option, \fBbf532\fR is used as the processor by default.
+.Sp
+Note that support for \fBbf561\fR is incomplete.  For \fBbf561\fR,
+only the preprocessor macro is defined.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Specifies that the program will be run on the simulator.  This causes
+the simulator \s-1BSP\s0 provided by libgloss to be linked in.  This option
+has effect only for \fBbfin-elf\fR toolchain.
+Certain other options, such as \fB\-mid\-shared\-library\fR and
+\&\fB\-mfdpic\fR, imply \fB\-msim\fR.
+.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
+.IX Item "-momit-leaf-frame-pointer"
+Don't keep the frame pointer in a register for leaf functions.  This
+avoids the instructions to save, set up and restore frame pointers and
+makes an extra register available in leaf functions.  The option
+\&\fB\-fomit\-frame\-pointer\fR removes the frame pointer for all functions,
+which might make debugging harder.
+.IP "\fB\-mspecld\-anomaly\fR" 4
+.IX Item "-mspecld-anomaly"
+When enabled, the compiler ensures that the generated code does not
+contain speculative loads after jump instructions. If this option is used,
+\&\f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_LOADS\*(C'\fR is defined.
+.IP "\fB\-mno\-specld\-anomaly\fR" 4
+.IX Item "-mno-specld-anomaly"
+Don't generate extra code to prevent speculative loads from occurring.
+.IP "\fB\-mcsync\-anomaly\fR" 4
+.IX Item "-mcsync-anomaly"
+When enabled, the compiler ensures that the generated code does not
+contain \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions too soon after conditional branches.
+If this option is used, \f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_SYNCS\*(C'\fR is defined.
+.IP "\fB\-mno\-csync\-anomaly\fR" 4
+.IX Item "-mno-csync-anomaly"
+Don't generate extra code to prevent \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions from
+occurring too soon after a conditional branch.
+.IP "\fB\-mlow\-64k\fR" 4
+.IX Item "-mlow-64k"
+When enabled, the compiler is free to take advantage of the knowledge that
+the entire program fits into the low 64k of memory.
+.IP "\fB\-mno\-low\-64k\fR" 4
+.IX Item "-mno-low-64k"
+Assume that the program is arbitrarily large.  This is the default.
+.IP "\fB\-mstack\-check\-l1\fR" 4
+.IX Item "-mstack-check-l1"
+Do stack checking using information placed into L1 scratchpad memory by the
+uClinux kernel.
+.IP "\fB\-mid\-shared\-library\fR" 4
+.IX Item "-mid-shared-library"
+Generate code that supports shared libraries via the library \s-1ID\s0 method.
+This allows for execute in place and shared libraries in an environment
+without virtual memory management.  This option implies \fB\-fPIC\fR.
+With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
+.IP "\fB\-mno\-id\-shared\-library\fR" 4
+.IX Item "-mno-id-shared-library"
+Generate code that doesn't assume ID-based shared libraries are being used.
+This is the default.
+.IP "\fB\-mleaf\-id\-shared\-library\fR" 4
+.IX Item "-mleaf-id-shared-library"
+Generate code that supports shared libraries via the library \s-1ID\s0 method,
+but assumes that this library or executable won't link against any other
+\&\s-1ID\s0 shared libraries.  That allows the compiler to use faster code for jumps
+and calls.
+.IP "\fB\-mno\-leaf\-id\-shared\-library\fR" 4
+.IX Item "-mno-leaf-id-shared-library"
+Do not assume that the code being compiled won't link against any \s-1ID\s0 shared
+libraries.  Slower code is generated for jump and call insns.
+.IP "\fB\-mshared\-library\-id=n\fR" 4
+.IX Item "-mshared-library-id=n"
+Specifies the identification number of the ID-based shared library being
+compiled.  Specifying a value of 0 generates more compact code; specifying
+other values forces the allocation of that number to the current
+library but is no more space\- or time-efficient than omitting this option.
+.IP "\fB\-msep\-data\fR" 4
+.IX Item "-msep-data"
+Generate code that allows the data segment to be located in a different
+area of memory from the text segment.  This allows for execute in place in
+an environment without virtual memory management by eliminating relocations
+against the text section.
+.IP "\fB\-mno\-sep\-data\fR" 4
+.IX Item "-mno-sep-data"
+Generate code that assumes that the data segment follows the text segment.
+This is the default.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+.PD 0
+.IP "\fB\-mno\-long\-calls\fR" 4
+.IX Item "-mno-long-calls"
+.PD
+Tells the compiler to perform function calls by first loading the
+address of the function into a register and then performing a subroutine
+call on this register.  This switch is needed if the target function
+lies outside of the 24\-bit addressing range of the offset-based
+version of subroutine call instruction.
+.Sp
+This feature is not enabled by default.  Specifying
+\&\fB\-mno\-long\-calls\fR restores the default behavior.  Note these
+switches have no effect on how the compiler generates code to handle
+function calls via function pointers.
+.IP "\fB\-mfast\-fp\fR" 4
+.IX Item "-mfast-fp"
+Link with the fast floating-point library. This library relaxes some of
+the \s-1IEEE\s0 floating-point standard's rules for checking inputs against
+Not-a-Number (\s-1NAN\s0), in the interest of performance.
+.IP "\fB\-minline\-plt\fR" 4
+.IX Item "-minline-plt"
+Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
+not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
+.IP "\fB\-mmulticore\fR" 4
+.IX Item "-mmulticore"
+Build a standalone application for multicore Blackfin processors. 
+This option causes proper start files and link scripts supporting 
+multicore to be used, and defines the macro \f(CW\*(C`_\|_BFIN_MULTICORE\*(C'\fR. 
+It can only be used with \fB\-mcpu=bf561\fR[\fB\-\fR\fIsirevision\fR].
+.Sp
+This option can be used with \fB\-mcorea\fR or \fB\-mcoreb\fR, which
+selects the one-application-per-core programming model.  Without
+\&\fB\-mcorea\fR or \fB\-mcoreb\fR, the single\-application/dual\-core
+programming model is used. In this model, the main function of Core B
+should be named as \f(CW\*(C`coreb_main\*(C'\fR.
+.Sp
+If this option is not used, the single-core application programming
+model is used.
+.IP "\fB\-mcorea\fR" 4
+.IX Item "-mcorea"
+Build a standalone application for Core A of \s-1BF561\s0 when using
+the one-application-per-core programming model. Proper start files
+and link scripts are used to support Core A, and the macro
+\&\f(CW\*(C`_\|_BFIN_COREA\*(C'\fR is defined.
+This option can only be used in conjunction with \fB\-mmulticore\fR.
+.IP "\fB\-mcoreb\fR" 4
+.IX Item "-mcoreb"
+Build a standalone application for Core B of \s-1BF561\s0 when using
+the one-application-per-core programming model. Proper start files
+and link scripts are used to support Core B, and the macro
+\&\f(CW\*(C`_\|_BFIN_COREB\*(C'\fR is defined. When this option is used, \f(CW\*(C`coreb_main\*(C'\fR
+should be used instead of \f(CW\*(C`main\*(C'\fR. 
+This option can only be used in conjunction with \fB\-mmulticore\fR.
+.IP "\fB\-msdram\fR" 4
+.IX Item "-msdram"
+Build a standalone application for \s-1SDRAM.\s0 Proper start files and
+link scripts are used to put the application into \s-1SDRAM,\s0 and the macro
+\&\f(CW\*(C`_\|_BFIN_SDRAM\*(C'\fR is defined.
+The loader should initialize \s-1SDRAM\s0 before loading the application.
+.IP "\fB\-micplb\fR" 4
+.IX Item "-micplb"
+Assume that ICPLBs are enabled at run time.  This has an effect on certain
+anomaly workarounds.  For Linux targets, the default is to assume ICPLBs
+are enabled; for standalone applications the default is off.
+.PP
+\fIC6X Options\fR
+.IX Subsection "C6X Options"
+.IP "\fB\-march=\fR\fIname\fR" 4
+.IX Item "-march=name"
+This specifies the name of the target architecture.  \s-1GCC\s0 uses this
+name to determine what kind of instructions it can emit when generating
+assembly code.  Permissible names are: \fBc62x\fR,
+\&\fBc64x\fR, \fBc64x+\fR, \fBc67x\fR, \fBc67x+\fR, \fBc674x\fR.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code for a big-endian target.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code for a little-endian target.  This is the default.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Choose startup files and linker script suitable for the simulator.
+.IP "\fB\-msdata=default\fR" 4
+.IX Item "-msdata=default"
+Put small global and static data in the \fB.neardata\fR section,
+which is pointed to by register \f(CW\*(C`B14\*(C'\fR.  Put small uninitialized
+global and static data in the \fB.bss\fR section, which is adjacent
+to the \fB.neardata\fR section.  Put small read-only data into the
+\&\fB.rodata\fR section.  The corresponding sections used for large
+pieces of data are \fB.fardata\fR, \fB.far\fR and \fB.const\fR.
+.IP "\fB\-msdata=all\fR" 4
+.IX Item "-msdata=all"
+Put all data, not just small objects, into the sections reserved for
+small data, and use addressing relative to the \f(CW\*(C`B14\*(C'\fR register to
+access them.
+.IP "\fB\-msdata=none\fR" 4
+.IX Item "-msdata=none"
+Make no use of the sections reserved for small data, and use absolute
+addresses to access all data.  Put all initialized global and static
+data in the \fB.fardata\fR section, and all uninitialized data in the
+\&\fB.far\fR section.  Put all constant data into the \fB.const\fR
+section.
+.PP
+\fI\s-1CRIS\s0 Options\fR
+.IX Subsection "CRIS Options"
+.PP
+These options are defined specifically for the \s-1CRIS\s0 ports.
+.IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
+.IX Item "-march=architecture-type"
+.PD 0
+.IP "\fB\-mcpu=\fR\fIarchitecture-type\fR" 4
+.IX Item "-mcpu=architecture-type"
+.PD
+Generate code for the specified architecture.  The choices for
+\&\fIarchitecture-type\fR are \fBv3\fR, \fBv8\fR and \fBv10\fR for
+respectively \s-1ETRAX\s0\ 4, \s-1ETRAX\s0\ 100, and \s-1ETRAX\s0\ 100\ \s-1LX.\s0
+Default is \fBv0\fR except for cris-axis-linux-gnu, where the default is
+\&\fBv10\fR.
+.IP "\fB\-mtune=\fR\fIarchitecture-type\fR" 4
+.IX Item "-mtune=architecture-type"
+Tune to \fIarchitecture-type\fR everything applicable about the generated
+code, except for the \s-1ABI\s0 and the set of available instructions.  The
+choices for \fIarchitecture-type\fR are the same as for
+\&\fB\-march=\fR\fIarchitecture-type\fR.
+.IP "\fB\-mmax\-stack\-frame=\fR\fIn\fR" 4
+.IX Item "-mmax-stack-frame=n"
+Warn when the stack frame of a function exceeds \fIn\fR bytes.
+.IP "\fB\-metrax4\fR" 4
+.IX Item "-metrax4"
+.PD 0
+.IP "\fB\-metrax100\fR" 4
+.IX Item "-metrax100"
+.PD
+The options \fB\-metrax4\fR and \fB\-metrax100\fR are synonyms for
+\&\fB\-march=v3\fR and \fB\-march=v8\fR respectively.
+.IP "\fB\-mmul\-bug\-workaround\fR" 4
+.IX Item "-mmul-bug-workaround"
+.PD 0
+.IP "\fB\-mno\-mul\-bug\-workaround\fR" 4
+.IX Item "-mno-mul-bug-workaround"
+.PD
+Work around a bug in the \f(CW\*(C`muls\*(C'\fR and \f(CW\*(C`mulu\*(C'\fR instructions for \s-1CPU\s0
+models where it applies.  This option is active by default.
+.IP "\fB\-mpdebug\fR" 4
+.IX Item "-mpdebug"
+Enable CRIS-specific verbose debug-related information in the assembly
+code.  This option also has the effect of turning off the \fB#NO_APP\fR
+formatted-code indicator to the assembler at the beginning of the
+assembly file.
+.IP "\fB\-mcc\-init\fR" 4
+.IX Item "-mcc-init"
+Do not use condition-code results from previous instruction; always emit
+compare and test instructions before use of condition codes.
+.IP "\fB\-mno\-side\-effects\fR" 4
+.IX Item "-mno-side-effects"
+Do not emit instructions with side effects in addressing modes other than
+post-increment.
+.IP "\fB\-mstack\-align\fR" 4
+.IX Item "-mstack-align"
+.PD 0
+.IP "\fB\-mno\-stack\-align\fR" 4
+.IX Item "-mno-stack-align"
+.IP "\fB\-mdata\-align\fR" 4
+.IX Item "-mdata-align"
+.IP "\fB\-mno\-data\-align\fR" 4
+.IX Item "-mno-data-align"
+.IP "\fB\-mconst\-align\fR" 4
+.IX Item "-mconst-align"
+.IP "\fB\-mno\-const\-align\fR" 4
+.IX Item "-mno-const-align"
+.PD
+These options (\fBno\-\fR options) arrange (eliminate arrangements) for the
+stack frame, individual data and constants to be aligned for the maximum
+single data access size for the chosen \s-1CPU\s0 model.  The default is to
+arrange for 32\-bit alignment.  \s-1ABI\s0 details such as structure layout are
+not affected by these options.
+.IP "\fB\-m32\-bit\fR" 4
+.IX Item "-m32-bit"
+.PD 0
+.IP "\fB\-m16\-bit\fR" 4
+.IX Item "-m16-bit"
+.IP "\fB\-m8\-bit\fR" 4
+.IX Item "-m8-bit"
+.PD
+Similar to the stack\- data\- and const-align options above, these options
+arrange for stack frame, writable data and constants to all be 32\-bit,
+16\-bit or 8\-bit aligned.  The default is 32\-bit alignment.
+.IP "\fB\-mno\-prologue\-epilogue\fR" 4
+.IX Item "-mno-prologue-epilogue"
+.PD 0
+.IP "\fB\-mprologue\-epilogue\fR" 4
+.IX Item "-mprologue-epilogue"
+.PD
+With \fB\-mno\-prologue\-epilogue\fR, the normal function prologue and
+epilogue which set up the stack frame are omitted and no return
+instructions or return sequences are generated in the code.  Use this
+option only together with visual inspection of the compiled code: no
+warnings or errors are generated when call-saved registers must be saved,
+or storage for local variables needs to be allocated.
+.IP "\fB\-mno\-gotplt\fR" 4
+.IX Item "-mno-gotplt"
+.PD 0
+.IP "\fB\-mgotplt\fR" 4
+.IX Item "-mgotplt"
+.PD
+With \fB\-fpic\fR and \fB\-fPIC\fR, don't generate (do generate)
+instruction sequences that load addresses for functions from the \s-1PLT\s0 part
+of the \s-1GOT\s0 rather than (traditional on other architectures) calls to the
+\&\s-1PLT. \s0 The default is \fB\-mgotplt\fR.
+.IP "\fB\-melf\fR" 4
+.IX Item "-melf"
+Legacy no-op option only recognized with the cris-axis-elf and
+cris-axis-linux-gnu targets.
+.IP "\fB\-mlinux\fR" 4
+.IX Item "-mlinux"
+Legacy no-op option only recognized with the cris-axis-linux-gnu target.
+.IP "\fB\-sim\fR" 4
+.IX Item "-sim"
+This option, recognized for the cris-axis-elf, arranges
+to link with input-output functions from a simulator library.  Code,
+initialized data and zero-initialized data are allocated consecutively.
+.IP "\fB\-sim2\fR" 4
+.IX Item "-sim2"
+Like \fB\-sim\fR, but pass linker options to locate initialized data at
+0x40000000 and zero-initialized data at 0x80000000.
+.PP
+\fI\s-1CR16\s0 Options\fR
+.IX Subsection "CR16 Options"
+.PP
+These options are defined specifically for the \s-1CR16\s0 ports.
+.IP "\fB\-mmac\fR" 4
+.IX Item "-mmac"
+Enable the use of multiply-accumulate instructions. Disabled by default.
+.IP "\fB\-mcr16cplus\fR" 4
+.IX Item "-mcr16cplus"
+.PD 0
+.IP "\fB\-mcr16c\fR" 4
+.IX Item "-mcr16c"
+.PD
+Generate code for \s-1CR16C\s0 or \s-1CR16C+\s0 architecture. \s-1CR16C+\s0 architecture 
+is default.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Links the library libsim.a which is in compatible with simulator. Applicable
+to \s-1ELF\s0 compiler only.
+.IP "\fB\-mint32\fR" 4
+.IX Item "-mint32"
+Choose integer type as 32\-bit wide.
+.IP "\fB\-mbit\-ops\fR" 4
+.IX Item "-mbit-ops"
+Generates \f(CW\*(C`sbit\*(C'\fR/\f(CW\*(C`cbit\*(C'\fR instructions for bit manipulations.
+.IP "\fB\-mdata\-model=\fR\fImodel\fR" 4
+.IX Item "-mdata-model=model"
+Choose a data model. The choices for \fImodel\fR are \fBnear\fR,
+\&\fBfar\fR or \fBmedium\fR. \fBmedium\fR is default.
+However, \fBfar\fR is not valid with \fB\-mcr16c\fR, as the
+\&\s-1CR16C\s0 architecture does not support the far data model.
+.PP
+\fIDarwin Options\fR
+.IX Subsection "Darwin Options"
+.PP
+These options are defined for all architectures running the Darwin operating
+system.
+.PP
+\&\s-1FSF GCC\s0 on Darwin does not create \*(L"fat\*(R" object files; it creates
+an object file for the single architecture that \s-1GCC\s0 was built to
+target.  Apple's \s-1GCC\s0 on Darwin does create \*(L"fat\*(R" files if multiple
+\&\fB\-arch\fR options are used; it does so by running the compiler or
+linker multiple times and joining the results together with
+\&\fIlipo\fR.
+.PP
+The subtype of the file created (like \fBppc7400\fR or \fBppc970\fR or
+\&\fBi686\fR) is determined by the flags that specify the \s-1ISA\s0
+that \s-1GCC\s0 is targeting, like \fB\-mcpu\fR or \fB\-march\fR.  The
+\&\fB\-force_cpusubtype_ALL\fR option can be used to override this.
+.PP
+The Darwin tools vary in their behavior when presented with an \s-1ISA\s0
+mismatch.  The assembler, \fIas\fR, only permits instructions to
+be used that are valid for the subtype of the file it is generating,
+so you cannot put 64\-bit instructions in a \fBppc750\fR object file.
+The linker for shared libraries, \fI/usr/bin/libtool\fR, fails
+and prints an error if asked to create a shared library with a less
+restrictive subtype than its input files (for instance, trying to put
+a \fBppc970\fR object file in a \fBppc7400\fR library).  The linker
+for executables, \fBld\fR, quietly gives the executable the most
+restrictive subtype of any of its input files.
+.IP "\fB\-F\fR\fIdir\fR" 4
+.IX Item "-Fdir"
+Add the framework directory \fIdir\fR to the head of the list of
+directories to be searched for header files.  These directories are
+interleaved with those specified by \fB\-I\fR options and are
+scanned in a left-to-right order.
+.Sp
+A framework directory is a directory with frameworks in it.  A
+framework is a directory with a \fIHeaders\fR and/or
+\&\fIPrivateHeaders\fR directory contained directly in it that ends
+in \fI.framework\fR.  The name of a framework is the name of this
+directory excluding the \fI.framework\fR.  Headers associated with
+the framework are found in one of those two directories, with
+\&\fIHeaders\fR being searched first.  A subframework is a framework
+directory that is in a framework's \fIFrameworks\fR directory.
+Includes of subframework headers can only appear in a header of a
+framework that contains the subframework, or in a sibling subframework
+header.  Two subframeworks are siblings if they occur in the same
+framework.  A subframework should not have the same name as a
+framework; a warning is issued if this is violated.  Currently a
+subframework cannot have subframeworks; in the future, the mechanism
+may be extended to support this.  The standard frameworks can be found
+in \fI/System/Library/Frameworks\fR and
+\&\fI/Library/Frameworks\fR.  An example include looks like
+\&\f(CW\*(C`#include <Framework/header.h>\*(C'\fR, where \fIFramework\fR denotes
+the name of the framework and \fIheader.h\fR is found in the
+\&\fIPrivateHeaders\fR or \fIHeaders\fR directory.
+.IP "\fB\-iframework\fR\fIdir\fR" 4
+.IX Item "-iframeworkdir"
+Like \fB\-F\fR except the directory is a treated as a system
+directory.  The main difference between this \fB\-iframework\fR and
+\&\fB\-F\fR is that with \fB\-iframework\fR the compiler does not
+warn about constructs contained within header files found via
+\&\fIdir\fR.  This option is valid only for the C family of languages.
+.IP "\fB\-gused\fR" 4
+.IX Item "-gused"
+Emit debugging information for symbols that are used.  For stabs
+debugging format, this enables \fB\-feliminate\-unused\-debug\-symbols\fR.
+This is by default \s-1ON.\s0
+.IP "\fB\-gfull\fR" 4
+.IX Item "-gfull"
+Emit debugging information for all symbols and types.
+.IP "\fB\-mmacosx\-version\-min=\fR\fIversion\fR" 4
+.IX Item "-mmacosx-version-min=version"
+The earliest version of MacOS X that this executable will run on
+is \fIversion\fR.  Typical values of \fIversion\fR include \f(CW10.1\fR,
+\&\f(CW10.2\fR, and \f(CW10.3.9\fR.
+.Sp
+If the compiler was built to use the system's headers by default,
+then the default for this option is the system version on which the
+compiler is running, otherwise the default is to make choices that
+are compatible with as many systems and code bases as possible.
+.IP "\fB\-mkernel\fR" 4
+.IX Item "-mkernel"
+Enable kernel development mode.  The \fB\-mkernel\fR option sets
+\&\fB\-static\fR, \fB\-fno\-common\fR, \fB\-fno\-cxa\-atexit\fR,
+\&\fB\-fno\-exceptions\fR, \fB\-fno\-non\-call\-exceptions\fR,
+\&\fB\-fapple\-kext\fR, \fB\-fno\-weak\fR and \fB\-fno\-rtti\fR where
+applicable.  This mode also sets \fB\-mno\-altivec\fR,
+\&\fB\-msoft\-float\fR, \fB\-fno\-builtin\fR and
+\&\fB\-mlong\-branch\fR for PowerPC targets.
+.IP "\fB\-mone\-byte\-bool\fR" 4
+.IX Item "-mone-byte-bool"
+Override the defaults for \fBbool\fR so that \fBsizeof(bool)==1\fR.
+By default \fBsizeof(bool)\fR is \fB4\fR when compiling for
+Darwin/PowerPC and \fB1\fR when compiling for Darwin/x86, so this
+option has no effect on x86.
+.Sp
+\&\fBWarning:\fR The \fB\-mone\-byte\-bool\fR switch causes \s-1GCC\s0
+to generate code that is not binary compatible with code generated
+without that switch.  Using this switch may require recompiling all
+other modules in a program, including system libraries.  Use this
+switch to conform to a non-default data model.
+.IP "\fB\-mfix\-and\-continue\fR" 4
+.IX Item "-mfix-and-continue"
+.PD 0
+.IP "\fB\-ffix\-and\-continue\fR" 4
+.IX Item "-ffix-and-continue"
+.IP "\fB\-findirect\-data\fR" 4
+.IX Item "-findirect-data"
+.PD
+Generate code suitable for fast turnaround development, such as to
+allow \s-1GDB\s0 to dynamically load \f(CW\*(C`.o\*(C'\fR files into already-running
+programs.  \fB\-findirect\-data\fR and \fB\-ffix\-and\-continue\fR
+are provided for backwards compatibility.
+.IP "\fB\-all_load\fR" 4
+.IX Item "-all_load"
+Loads all members of static archive libraries.
+See man \fIld\fR\|(1) for more information.
+.IP "\fB\-arch_errors_fatal\fR" 4
+.IX Item "-arch_errors_fatal"
+Cause the errors having to do with files that have the wrong architecture
+to be fatal.
+.IP "\fB\-bind_at_load\fR" 4
+.IX Item "-bind_at_load"
+Causes the output file to be marked such that the dynamic linker will
+bind all undefined references when the file is loaded or launched.
+.IP "\fB\-bundle\fR" 4
+.IX Item "-bundle"
+Produce a Mach-o bundle format file.
+See man \fIld\fR\|(1) for more information.
+.IP "\fB\-bundle_loader\fR \fIexecutable\fR" 4
+.IX Item "-bundle_loader executable"
+This option specifies the \fIexecutable\fR that will load the build
+output file being linked.  See man \fIld\fR\|(1) for more information.
+.IP "\fB\-dynamiclib\fR" 4
+.IX Item "-dynamiclib"
+When passed this option, \s-1GCC\s0 produces a dynamic library instead of
+an executable when linking, using the Darwin \fIlibtool\fR command.
+.IP "\fB\-force_cpusubtype_ALL\fR" 4
+.IX Item "-force_cpusubtype_ALL"
+This causes \s-1GCC\s0's output file to have the \fI\s-1ALL\s0\fR subtype, instead of
+one controlled by the \fB\-mcpu\fR or \fB\-march\fR option.
+.IP "\fB\-allowable_client\fR  \fIclient_name\fR" 4
+.IX Item "-allowable_client client_name"
+.PD 0
+.IP "\fB\-client_name\fR" 4
+.IX Item "-client_name"
+.IP "\fB\-compatibility_version\fR" 4
+.IX Item "-compatibility_version"
+.IP "\fB\-current_version\fR" 4
+.IX Item "-current_version"
+.IP "\fB\-dead_strip\fR" 4
+.IX Item "-dead_strip"
+.IP "\fB\-dependency\-file\fR" 4
+.IX Item "-dependency-file"
+.IP "\fB\-dylib_file\fR" 4
+.IX Item "-dylib_file"
+.IP "\fB\-dylinker_install_name\fR" 4
+.IX Item "-dylinker_install_name"
+.IP "\fB\-dynamic\fR" 4
+.IX Item "-dynamic"
+.IP "\fB\-exported_symbols_list\fR" 4
+.IX Item "-exported_symbols_list"
+.IP "\fB\-filelist\fR" 4
+.IX Item "-filelist"
+.IP "\fB\-flat_namespace\fR" 4
+.IX Item "-flat_namespace"
+.IP "\fB\-force_flat_namespace\fR" 4
+.IX Item "-force_flat_namespace"
+.IP "\fB\-headerpad_max_install_names\fR" 4
+.IX Item "-headerpad_max_install_names"
+.IP "\fB\-image_base\fR" 4
+.IX Item "-image_base"
+.IP "\fB\-init\fR" 4
+.IX Item "-init"
+.IP "\fB\-install_name\fR" 4
+.IX Item "-install_name"
+.IP "\fB\-keep_private_externs\fR" 4
+.IX Item "-keep_private_externs"
+.IP "\fB\-multi_module\fR" 4
+.IX Item "-multi_module"
+.IP "\fB\-multiply_defined\fR" 4
+.IX Item "-multiply_defined"
+.IP "\fB\-multiply_defined_unused\fR" 4
+.IX Item "-multiply_defined_unused"
+.IP "\fB\-noall_load\fR" 4
+.IX Item "-noall_load"
+.IP "\fB\-no_dead_strip_inits_and_terms\fR" 4
+.IX Item "-no_dead_strip_inits_and_terms"
+.IP "\fB\-nofixprebinding\fR" 4
+.IX Item "-nofixprebinding"
+.IP "\fB\-nomultidefs\fR" 4
+.IX Item "-nomultidefs"
+.IP "\fB\-noprebind\fR" 4
+.IX Item "-noprebind"
+.IP "\fB\-noseglinkedit\fR" 4
+.IX Item "-noseglinkedit"
+.IP "\fB\-pagezero_size\fR" 4
+.IX Item "-pagezero_size"
+.IP "\fB\-prebind\fR" 4
+.IX Item "-prebind"
+.IP "\fB\-prebind_all_twolevel_modules\fR" 4
+.IX Item "-prebind_all_twolevel_modules"
+.IP "\fB\-private_bundle\fR" 4
+.IX Item "-private_bundle"
+.IP "\fB\-read_only_relocs\fR" 4
+.IX Item "-read_only_relocs"
+.IP "\fB\-sectalign\fR" 4
+.IX Item "-sectalign"
+.IP "\fB\-sectobjectsymbols\fR" 4
+.IX Item "-sectobjectsymbols"
+.IP "\fB\-whyload\fR" 4
+.IX Item "-whyload"
+.IP "\fB\-seg1addr\fR" 4
+.IX Item "-seg1addr"
+.IP "\fB\-sectcreate\fR" 4
+.IX Item "-sectcreate"
+.IP "\fB\-sectobjectsymbols\fR" 4
+.IX Item "-sectobjectsymbols"
+.IP "\fB\-sectorder\fR" 4
+.IX Item "-sectorder"
+.IP "\fB\-segaddr\fR" 4
+.IX Item "-segaddr"
+.IP "\fB\-segs_read_only_addr\fR" 4
+.IX Item "-segs_read_only_addr"
+.IP "\fB\-segs_read_write_addr\fR" 4
+.IX Item "-segs_read_write_addr"
+.IP "\fB\-seg_addr_table\fR" 4
+.IX Item "-seg_addr_table"
+.IP "\fB\-seg_addr_table_filename\fR" 4
+.IX Item "-seg_addr_table_filename"
+.IP "\fB\-seglinkedit\fR" 4
+.IX Item "-seglinkedit"
+.IP "\fB\-segprot\fR" 4
+.IX Item "-segprot"
+.IP "\fB\-segs_read_only_addr\fR" 4
+.IX Item "-segs_read_only_addr"
+.IP "\fB\-segs_read_write_addr\fR" 4
+.IX Item "-segs_read_write_addr"
+.IP "\fB\-single_module\fR" 4
+.IX Item "-single_module"
+.IP "\fB\-static\fR" 4
+.IX Item "-static"
+.IP "\fB\-sub_library\fR" 4
+.IX Item "-sub_library"
+.IP "\fB\-sub_umbrella\fR" 4
+.IX Item "-sub_umbrella"
+.IP "\fB\-twolevel_namespace\fR" 4
+.IX Item "-twolevel_namespace"
+.IP "\fB\-umbrella\fR" 4
+.IX Item "-umbrella"
+.IP "\fB\-undefined\fR" 4
+.IX Item "-undefined"
+.IP "\fB\-unexported_symbols_list\fR" 4
+.IX Item "-unexported_symbols_list"
+.IP "\fB\-weak_reference_mismatches\fR" 4
+.IX Item "-weak_reference_mismatches"
+.IP "\fB\-whatsloaded\fR" 4
+.IX Item "-whatsloaded"
+.PD
+These options are passed to the Darwin linker.  The Darwin linker man page
+describes them in detail.
+.PP
+\fI\s-1DEC\s0 Alpha Options\fR
+.IX Subsection "DEC Alpha Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha implementations:
+.IP "\fB\-mno\-soft\-float\fR" 4
+.IX Item "-mno-soft-float"
+.PD 0
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD
+Use (do not use) the hardware floating-point instructions for
+floating-point operations.  When \fB\-msoft\-float\fR is specified,
+functions in \fIlibgcc.a\fR are used to perform floating-point
+operations.  Unless they are replaced by routines that emulate the
+floating-point operations, or compiled in such a way as to call such
+emulations routines, these routines issue floating-point
+operations.   If you are compiling for an Alpha without floating-point
+operations, you must ensure that the library is built so as not to call
+them.
+.Sp
+Note that Alpha implementations without floating-point operations are
+required to have floating-point registers.
+.IP "\fB\-mfp\-reg\fR" 4
+.IX Item "-mfp-reg"
+.PD 0
+.IP "\fB\-mno\-fp\-regs\fR" 4
+.IX Item "-mno-fp-regs"
+.PD
+Generate code that uses (does not use) the floating-point register set.
+\&\fB\-mno\-fp\-regs\fR implies \fB\-msoft\-float\fR.  If the floating-point
+register set is not used, floating-point operands are passed in integer
+registers as if they were integers and floating-point results are passed
+in \f(CW$0\fR instead of \f(CW$f0\fR.  This is a non-standard calling sequence,
+so any function with a floating-point argument or return value called by code
+compiled with \fB\-mno\-fp\-regs\fR must also be compiled with that
+option.
+.Sp
+A typical use of this option is building a kernel that does not use,
+and hence need not save and restore, any floating-point registers.
+.IP "\fB\-mieee\fR" 4
+.IX Item "-mieee"
+The Alpha architecture implements floating-point hardware optimized for
+maximum performance.  It is mostly compliant with the \s-1IEEE\s0 floating-point
+standard.  However, for full compliance, software assistance is
+required.  This option generates code fully IEEE-compliant code
+\&\fIexcept\fR that the \fIinexact-flag\fR is not maintained (see below).
+If this option is turned on, the preprocessor macro \f(CW\*(C`_IEEE_FP\*(C'\fR is
+defined during compilation.  The resulting code is less efficient but is
+able to correctly support denormalized numbers and exceptional \s-1IEEE\s0
+values such as not-a-number and plus/minus infinity.  Other Alpha
+compilers call this option \fB\-ieee_with_no_inexact\fR.
+.IP "\fB\-mieee\-with\-inexact\fR" 4
+.IX Item "-mieee-with-inexact"
+This is like \fB\-mieee\fR except the generated code also maintains
+the \s-1IEEE \s0\fIinexact-flag\fR.  Turning on this option causes the
+generated code to implement fully-compliant \s-1IEEE\s0 math.  In addition to
+\&\f(CW\*(C`_IEEE_FP\*(C'\fR, \f(CW\*(C`_IEEE_FP_EXACT\*(C'\fR is defined as a preprocessor
+macro.  On some Alpha implementations the resulting code may execute
+significantly slower than the code generated by default.  Since there is
+very little code that depends on the \fIinexact-flag\fR, you should
+normally not specify this option.  Other Alpha compilers call this
+option \fB\-ieee_with_inexact\fR.
+.IP "\fB\-mfp\-trap\-mode=\fR\fItrap-mode\fR" 4
+.IX Item "-mfp-trap-mode=trap-mode"
+This option controls what floating-point related traps are enabled.
+Other Alpha compilers call this option \fB\-fptm\fR \fItrap-mode\fR.
+The trap mode can be set to one of four values:
+.RS 4
+.IP "\fBn\fR" 4
+.IX Item "n"
+This is the default (normal) setting.  The only traps that are enabled
+are the ones that cannot be disabled in software (e.g., division by zero
+trap).
+.IP "\fBu\fR" 4
+.IX Item "u"
+In addition to the traps enabled by \fBn\fR, underflow traps are enabled
+as well.
+.IP "\fBsu\fR" 4
+.IX Item "su"
+Like \fBu\fR, but the instructions are marked to be safe for software
+completion (see Alpha architecture manual for details).
+.IP "\fBsui\fR" 4
+.IX Item "sui"
+Like \fBsu\fR, but inexact traps are enabled as well.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mfp\-rounding\-mode=\fR\fIrounding-mode\fR" 4
+.IX Item "-mfp-rounding-mode=rounding-mode"
+Selects the \s-1IEEE\s0 rounding mode.  Other Alpha compilers call this option
+\&\fB\-fprm\fR \fIrounding-mode\fR.  The \fIrounding-mode\fR can be one
+of:
+.RS 4
+.IP "\fBn\fR" 4
+.IX Item "n"
+Normal \s-1IEEE\s0 rounding mode.  Floating-point numbers are rounded towards
+the nearest machine number or towards the even machine number in case
+of a tie.
+.IP "\fBm\fR" 4
+.IX Item "m"
+Round towards minus infinity.
+.IP "\fBc\fR" 4
+.IX Item "c"
+Chopped rounding mode.  Floating-point numbers are rounded towards zero.
+.IP "\fBd\fR" 4
+.IX Item "d"
+Dynamic rounding mode.  A field in the floating-point control register
+(\fIfpcr\fR, see Alpha architecture reference manual) controls the
+rounding mode in effect.  The C library initializes this register for
+rounding towards plus infinity.  Thus, unless your program modifies the
+\&\fIfpcr\fR, \fBd\fR corresponds to round towards plus infinity.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mtrap\-precision=\fR\fItrap-precision\fR" 4
+.IX Item "-mtrap-precision=trap-precision"
+In the Alpha architecture, floating-point traps are imprecise.  This
+means without software assistance it is impossible to recover from a
+floating trap and program execution normally needs to be terminated.
+\&\s-1GCC\s0 can generate code that can assist operating system trap handlers
+in determining the exact location that caused a floating-point trap.
+Depending on the requirements of an application, different levels of
+precisions can be selected:
+.RS 4
+.IP "\fBp\fR" 4
+.IX Item "p"
+Program precision.  This option is the default and means a trap handler
+can only identify which program caused a floating-point exception.
+.IP "\fBf\fR" 4
+.IX Item "f"
+Function precision.  The trap handler can determine the function that
+caused a floating-point exception.
+.IP "\fBi\fR" 4
+.IX Item "i"
+Instruction precision.  The trap handler can determine the exact
+instruction that caused a floating-point exception.
+.RE
+.RS 4
+.Sp
+Other Alpha compilers provide the equivalent options called
+\&\fB\-scope_safe\fR and \fB\-resumption_safe\fR.
+.RE
+.IP "\fB\-mieee\-conformant\fR" 4
+.IX Item "-mieee-conformant"
+This option marks the generated code as \s-1IEEE\s0 conformant.  You must not
+use this option unless you also specify \fB\-mtrap\-precision=i\fR and either
+\&\fB\-mfp\-trap\-mode=su\fR or \fB\-mfp\-trap\-mode=sui\fR.  Its only effect
+is to emit the line \fB.eflag 48\fR in the function prologue of the
+generated assembly file.
+.IP "\fB\-mbuild\-constants\fR" 4
+.IX Item "-mbuild-constants"
+Normally \s-1GCC\s0 examines a 32\- or 64\-bit integer constant to
+see if it can construct it from smaller constants in two or three
+instructions.  If it cannot, it outputs the constant as a literal and
+generates code to load it from the data segment at run time.
+.Sp
+Use this option to require \s-1GCC\s0 to construct \fIall\fR integer constants
+using code, even if it takes more instructions (the maximum is six).
+.Sp
+You typically use this option to build a shared library dynamic
+loader.  Itself a shared library, it must relocate itself in memory
+before it can find the variables and constants in its own data segment.
+.IP "\fB\-mbwx\fR" 4
+.IX Item "-mbwx"
+.PD 0
+.IP "\fB\-mno\-bwx\fR" 4
+.IX Item "-mno-bwx"
+.IP "\fB\-mcix\fR" 4
+.IX Item "-mcix"
+.IP "\fB\-mno\-cix\fR" 4
+.IX Item "-mno-cix"
+.IP "\fB\-mfix\fR" 4
+.IX Item "-mfix"
+.IP "\fB\-mno\-fix\fR" 4
+.IX Item "-mno-fix"
+.IP "\fB\-mmax\fR" 4
+.IX Item "-mmax"
+.IP "\fB\-mno\-max\fR" 4
+.IX Item "-mno-max"
+.PD
+Indicate whether \s-1GCC\s0 should generate code to use the optional \s-1BWX,
+CIX, FIX\s0 and \s-1MAX\s0 instruction sets.  The default is to use the instruction
+sets supported by the \s-1CPU\s0 type specified via \fB\-mcpu=\fR option or that
+of the \s-1CPU\s0 on which \s-1GCC\s0 was built if none is specified.
+.IP "\fB\-mfloat\-vax\fR" 4
+.IX Item "-mfloat-vax"
+.PD 0
+.IP "\fB\-mfloat\-ieee\fR" 4
+.IX Item "-mfloat-ieee"
+.PD
+Generate code that uses (does not use) \s-1VAX F\s0 and G floating-point
+arithmetic instead of \s-1IEEE\s0 single and double precision.
+.IP "\fB\-mexplicit\-relocs\fR" 4
+.IX Item "-mexplicit-relocs"
+.PD 0
+.IP "\fB\-mno\-explicit\-relocs\fR" 4
+.IX Item "-mno-explicit-relocs"
+.PD
+Older Alpha assemblers provided no way to generate symbol relocations
+except via assembler macros.  Use of these macros does not allow
+optimal instruction scheduling.  \s-1GNU\s0 binutils as of version 2.12
+supports a new syntax that allows the compiler to explicitly mark
+which relocations should apply to which instructions.  This option
+is mostly useful for debugging, as \s-1GCC\s0 detects the capabilities of
+the assembler when it is built and sets the default accordingly.
+.IP "\fB\-msmall\-data\fR" 4
+.IX Item "-msmall-data"
+.PD 0
+.IP "\fB\-mlarge\-data\fR" 4
+.IX Item "-mlarge-data"
+.PD
+When \fB\-mexplicit\-relocs\fR is in effect, static data is
+accessed via \fIgp-relative\fR relocations.  When \fB\-msmall\-data\fR
+is used, objects 8 bytes long or smaller are placed in a \fIsmall data area\fR
+(the \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR sections) and are accessed via
+16\-bit relocations off of the \f(CW$gp\fR register.  This limits the
+size of the small data area to 64KB, but allows the variables to be
+directly accessed via a single instruction.
+.Sp
+The default is \fB\-mlarge\-data\fR.  With this option the data area
+is limited to just below 2GB.  Programs that require more than 2GB of
+data must use \f(CW\*(C`malloc\*(C'\fR or \f(CW\*(C`mmap\*(C'\fR to allocate the data in the
+heap instead of in the program's data segment.
+.Sp
+When generating code for shared libraries, \fB\-fpic\fR implies
+\&\fB\-msmall\-data\fR and \fB\-fPIC\fR implies \fB\-mlarge\-data\fR.
+.IP "\fB\-msmall\-text\fR" 4
+.IX Item "-msmall-text"
+.PD 0
+.IP "\fB\-mlarge\-text\fR" 4
+.IX Item "-mlarge-text"
+.PD
+When \fB\-msmall\-text\fR is used, the compiler assumes that the
+code of the entire program (or shared library) fits in 4MB, and is
+thus reachable with a branch instruction.  When \fB\-msmall\-data\fR
+is used, the compiler can assume that all local symbols share the
+same \f(CW$gp\fR value, and thus reduce the number of instructions
+required for a function call from 4 to 1.
+.Sp
+The default is \fB\-mlarge\-text\fR.
+.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
+.IX Item "-mcpu=cpu_type"
+Set the instruction set and instruction scheduling parameters for
+machine type \fIcpu_type\fR.  You can specify either the \fB\s-1EV\s0\fR
+style name or the corresponding chip number.  \s-1GCC\s0 supports scheduling
+parameters for the \s-1EV4, EV5\s0 and \s-1EV6\s0 family of processors and
+chooses the default values for the instruction set from the processor
+you specify.  If you do not specify a processor type, \s-1GCC\s0 defaults
+to the processor on which the compiler was built.
+.Sp
+Supported values for \fIcpu_type\fR are
+.RS 4
+.IP "\fBev4\fR" 4
+.IX Item "ev4"
+.PD 0
+.IP "\fBev45\fR" 4
+.IX Item "ev45"
+.IP "\fB21064\fR" 4
+.IX Item "21064"
+.PD
+Schedules as an \s-1EV4\s0 and has no instruction set extensions.
+.IP "\fBev5\fR" 4
+.IX Item "ev5"
+.PD 0
+.IP "\fB21164\fR" 4
+.IX Item "21164"
+.PD
+Schedules as an \s-1EV5\s0 and has no instruction set extensions.
+.IP "\fBev56\fR" 4
+.IX Item "ev56"
+.PD 0
+.IP "\fB21164a\fR" 4
+.IX Item "21164a"
+.PD
+Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 extension.
+.IP "\fBpca56\fR" 4
+.IX Item "pca56"
+.PD 0
+.IP "\fB21164pc\fR" 4
+.IX Item "21164pc"
+.IP "\fB21164PC\fR" 4
+.IX Item "21164PC"
+.PD
+Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 and \s-1MAX\s0 extensions.
+.IP "\fBev6\fR" 4
+.IX Item "ev6"
+.PD 0
+.IP "\fB21264\fR" 4
+.IX Item "21264"
+.PD
+Schedules as an \s-1EV6\s0 and supports the \s-1BWX, FIX,\s0 and \s-1MAX\s0 extensions.
+.IP "\fBev67\fR" 4
+.IX Item "ev67"
+.PD 0
+.IP "\fB21264a\fR" 4
+.IX Item "21264a"
+.PD
+Schedules as an \s-1EV6\s0 and supports the \s-1BWX, CIX, FIX,\s0 and \s-1MAX\s0 extensions.
+.RE
+.RS 4
+.Sp
+Native toolchains also support the value \fBnative\fR,
+which selects the best architecture option for the host processor.
+\&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
+the processor.
+.RE
+.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
+.IX Item "-mtune=cpu_type"
+Set only the instruction scheduling parameters for machine type
+\&\fIcpu_type\fR.  The instruction set is not changed.
+.Sp
+Native toolchains also support the value \fBnative\fR,
+which selects the best architecture option for the host processor.
+\&\fB\-mtune=native\fR has no effect if \s-1GCC\s0 does not recognize
+the processor.
+.IP "\fB\-mmemory\-latency=\fR\fItime\fR" 4
+.IX Item "-mmemory-latency=time"
+Sets the latency the scheduler should assume for typical memory
+references as seen by the application.  This number is highly
+dependent on the memory access patterns used by the application
+and the size of the external cache on the machine.
+.Sp
+Valid options for \fItime\fR are
+.RS 4
+.IP "\fInumber\fR" 4
+.IX Item "number"
+A decimal number representing clock cycles.
+.IP "\fBL1\fR" 4
+.IX Item "L1"
+.PD 0
+.IP "\fBL2\fR" 4
+.IX Item "L2"
+.IP "\fBL3\fR" 4
+.IX Item "L3"
+.IP "\fBmain\fR" 4
+.IX Item "main"
+.PD
+The compiler contains estimates of the number of clock cycles for
+\&\*(L"typical\*(R" \s-1EV4 & EV5\s0 hardware for the Level 1, 2 & 3 caches
+(also called Dcache, Scache, and Bcache), as well as to main memory.
+Note that L3 is only valid for \s-1EV5.\s0
+.RE
+.RS 4
+.RE
+.PP
+\fI\s-1FR30\s0 Options\fR
+.IX Subsection "FR30 Options"
+.PP
+These options are defined specifically for the \s-1FR30\s0 port.
+.IP "\fB\-msmall\-model\fR" 4
+.IX Item "-msmall-model"
+Use the small address space model.  This can produce smaller code, but
+it does assume that all symbolic values and addresses fit into a
+20\-bit range.
+.IP "\fB\-mno\-lsim\fR" 4
+.IX Item "-mno-lsim"
+Assume that runtime support has been provided and so there is no need
+to include the simulator library (\fIlibsim.a\fR) on the linker
+command line.
+.PP
+\fI\s-1FRV\s0 Options\fR
+.IX Subsection "FRV Options"
+.IP "\fB\-mgpr\-32\fR" 4
+.IX Item "-mgpr-32"
+Only use the first 32 general-purpose registers.
+.IP "\fB\-mgpr\-64\fR" 4
+.IX Item "-mgpr-64"
+Use all 64 general-purpose registers.
+.IP "\fB\-mfpr\-32\fR" 4
+.IX Item "-mfpr-32"
+Use only the first 32 floating-point registers.
+.IP "\fB\-mfpr\-64\fR" 4
+.IX Item "-mfpr-64"
+Use all 64 floating-point registers.
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+Use hardware instructions for floating-point operations.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Use library routines for floating-point operations.
+.IP "\fB\-malloc\-cc\fR" 4
+.IX Item "-malloc-cc"
+Dynamically allocate condition code registers.
+.IP "\fB\-mfixed\-cc\fR" 4
+.IX Item "-mfixed-cc"
+Do not try to dynamically allocate condition code registers, only
+use \f(CW\*(C`icc0\*(C'\fR and \f(CW\*(C`fcc0\*(C'\fR.
+.IP "\fB\-mdword\fR" 4
+.IX Item "-mdword"
+Change \s-1ABI\s0 to use double word insns.
+.IP "\fB\-mno\-dword\fR" 4
+.IX Item "-mno-dword"
+Do not use double word instructions.
+.IP "\fB\-mdouble\fR" 4
+.IX Item "-mdouble"
+Use floating-point double instructions.
+.IP "\fB\-mno\-double\fR" 4
+.IX Item "-mno-double"
+Do not use floating-point double instructions.
+.IP "\fB\-mmedia\fR" 4
+.IX Item "-mmedia"
+Use media instructions.
+.IP "\fB\-mno\-media\fR" 4
+.IX Item "-mno-media"
+Do not use media instructions.
+.IP "\fB\-mmuladd\fR" 4
+.IX Item "-mmuladd"
+Use multiply and add/subtract instructions.
+.IP "\fB\-mno\-muladd\fR" 4
+.IX Item "-mno-muladd"
+Do not use multiply and add/subtract instructions.
+.IP "\fB\-mfdpic\fR" 4
+.IX Item "-mfdpic"
+Select the \s-1FDPIC ABI,\s0 which uses function descriptors to represent
+pointers to functions.  Without any PIC/PIE\-related options, it
+implies \fB\-fPIE\fR.  With \fB\-fpic\fR or \fB\-fpie\fR, it
+assumes \s-1GOT\s0 entries and small data are within a 12\-bit range from the
+\&\s-1GOT\s0 base address; with \fB\-fPIC\fR or \fB\-fPIE\fR, \s-1GOT\s0 offsets
+are computed with 32 bits.
+With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
+.IP "\fB\-minline\-plt\fR" 4
+.IX Item "-minline-plt"
+Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
+not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
+It's enabled by default if optimizing for speed and compiling for
+shared libraries (i.e., \fB\-fPIC\fR or \fB\-fpic\fR), or when an
+optimization option such as \fB\-O3\fR or above is present in the
+command line.
+.IP "\fB\-mTLS\fR" 4
+.IX Item "-mTLS"
+Assume a large \s-1TLS\s0 segment when generating thread-local code.
+.IP "\fB\-mtls\fR" 4
+.IX Item "-mtls"
+Do not assume a large \s-1TLS\s0 segment when generating thread-local code.
+.IP "\fB\-mgprel\-ro\fR" 4
+.IX Item "-mgprel-ro"
+Enable the use of \f(CW\*(C`GPREL\*(C'\fR relocations in the \s-1FDPIC ABI\s0 for data
+that is known to be in read-only sections.  It's enabled by default,
+except for \fB\-fpic\fR or \fB\-fpie\fR: even though it may help
+make the global offset table smaller, it trades 1 instruction for 4.
+With \fB\-fPIC\fR or \fB\-fPIE\fR, it trades 3 instructions for 4,
+one of which may be shared by multiple symbols, and it avoids the need
+for a \s-1GOT\s0 entry for the referenced symbol, so it's more likely to be a
+win.  If it is not, \fB\-mno\-gprel\-ro\fR can be used to disable it.
+.IP "\fB\-multilib\-library\-pic\fR" 4
+.IX Item "-multilib-library-pic"
+Link with the (library, not \s-1FD\s0) pic libraries.  It's implied by
+\&\fB\-mlibrary\-pic\fR, as well as by \fB\-fPIC\fR and
+\&\fB\-fpic\fR without \fB\-mfdpic\fR.  You should never have to use
+it explicitly.
+.IP "\fB\-mlinked\-fp\fR" 4
+.IX Item "-mlinked-fp"
+Follow the \s-1EABI\s0 requirement of always creating a frame pointer whenever
+a stack frame is allocated.  This option is enabled by default and can
+be disabled with \fB\-mno\-linked\-fp\fR.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+Use indirect addressing to call functions outside the current
+compilation unit.  This allows the functions to be placed anywhere
+within the 32\-bit address space.
+.IP "\fB\-malign\-labels\fR" 4
+.IX Item "-malign-labels"
+Try to align labels to an 8\-byte boundary by inserting NOPs into the
+previous packet.  This option only has an effect when \s-1VLIW\s0 packing
+is enabled.  It doesn't create new packets; it merely adds NOPs to
+existing ones.
+.IP "\fB\-mlibrary\-pic\fR" 4
+.IX Item "-mlibrary-pic"
+Generate position-independent \s-1EABI\s0 code.
+.IP "\fB\-macc\-4\fR" 4
+.IX Item "-macc-4"
+Use only the first four media accumulator registers.
+.IP "\fB\-macc\-8\fR" 4
+.IX Item "-macc-8"
+Use all eight media accumulator registers.
+.IP "\fB\-mpack\fR" 4
+.IX Item "-mpack"
+Pack \s-1VLIW\s0 instructions.
+.IP "\fB\-mno\-pack\fR" 4
+.IX Item "-mno-pack"
+Do not pack \s-1VLIW\s0 instructions.
+.IP "\fB\-mno\-eflags\fR" 4
+.IX Item "-mno-eflags"
+Do not mark \s-1ABI\s0 switches in e_flags.
+.IP "\fB\-mcond\-move\fR" 4
+.IX Item "-mcond-move"
+Enable the use of conditional-move instructions (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-cond\-move\fR" 4
+.IX Item "-mno-cond-move"
+Disable the use of conditional-move instructions.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mscc\fR" 4
+.IX Item "-mscc"
+Enable the use of conditional set instructions (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-scc\fR" 4
+.IX Item "-mno-scc"
+Disable the use of conditional set instructions.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mcond\-exec\fR" 4
+.IX Item "-mcond-exec"
+Enable the use of conditional execution (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-cond\-exec\fR" 4
+.IX Item "-mno-cond-exec"
+Disable the use of conditional execution.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mvliw\-branch\fR" 4
+.IX Item "-mvliw-branch"
+Run a pass to pack branches into \s-1VLIW\s0 instructions (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-vliw\-branch\fR" 4
+.IX Item "-mno-vliw-branch"
+Do not run a pass to pack branches into \s-1VLIW\s0 instructions.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mmulti\-cond\-exec\fR" 4
+.IX Item "-mmulti-cond-exec"
+Enable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution
+(default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-multi\-cond\-exec\fR" 4
+.IX Item "-mno-multi-cond-exec"
+Disable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mnested\-cond\-exec\fR" 4
+.IX Item "-mnested-cond-exec"
+Enable nested conditional execution optimizations (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-nested\-cond\-exec\fR" 4
+.IX Item "-mno-nested-cond-exec"
+Disable nested conditional execution optimizations.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-moptimize\-membar\fR" 4
+.IX Item "-moptimize-membar"
+This switch removes redundant \f(CW\*(C`membar\*(C'\fR instructions from the
+compiler-generated code.  It is enabled by default.
+.IP "\fB\-mno\-optimize\-membar\fR" 4
+.IX Item "-mno-optimize-membar"
+This switch disables the automatic removal of redundant \f(CW\*(C`membar\*(C'\fR
+instructions from the generated code.
+.IP "\fB\-mtomcat\-stats\fR" 4
+.IX Item "-mtomcat-stats"
+Cause gas to print out tomcat statistics.
+.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
+.IX Item "-mcpu=cpu"
+Select the processor type for which to generate code.  Possible values are
+\&\fBfrv\fR, \fBfr550\fR, \fBtomcat\fR, \fBfr500\fR, \fBfr450\fR,
+\&\fBfr405\fR, \fBfr400\fR, \fBfr300\fR and \fBsimple\fR.
+.PP
+\fIGNU/Linux Options\fR
+.IX Subsection "GNU/Linux Options"
+.PP
+These \fB\-m\fR options are defined for GNU/Linux targets:
+.IP "\fB\-mglibc\fR" 4
+.IX Item "-mglibc"
+Use the \s-1GNU C\s0 library.  This is the default except
+on \fB*\-*\-linux\-*uclibc*\fR and \fB*\-*\-linux\-*android*\fR targets.
+.IP "\fB\-muclibc\fR" 4
+.IX Item "-muclibc"
+Use uClibc C library.  This is the default on
+\&\fB*\-*\-linux\-*uclibc*\fR targets.
+.IP "\fB\-mbionic\fR" 4
+.IX Item "-mbionic"
+Use Bionic C library.  This is the default on
+\&\fB*\-*\-linux\-*android*\fR targets.
+.IP "\fB\-mandroid\fR" 4
+.IX Item "-mandroid"
+Compile code compatible with Android platform.  This is the default on
+\&\fB*\-*\-linux\-*android*\fR targets.
+.Sp
+When compiling, this option enables \fB\-mbionic\fR, \fB\-fPIC\fR,
+\&\fB\-fno\-exceptions\fR and \fB\-fno\-rtti\fR by default.  When linking,
+this option makes the \s-1GCC\s0 driver pass Android-specific options to the linker.
+Finally, this option causes the preprocessor macro \f(CW\*(C`_\|_ANDROID_\|_\*(C'\fR
+to be defined.
+.IP "\fB\-tno\-android\-cc\fR" 4
+.IX Item "-tno-android-cc"
+Disable compilation effects of \fB\-mandroid\fR, i.e., do not enable
+\&\fB\-mbionic\fR, \fB\-fPIC\fR, \fB\-fno\-exceptions\fR and
+\&\fB\-fno\-rtti\fR by default.
+.IP "\fB\-tno\-android\-ld\fR" 4
+.IX Item "-tno-android-ld"
+Disable linking effects of \fB\-mandroid\fR, i.e., pass standard Linux
+linking options to the linker.
+.PP
+\fIH8/300 Options\fR
+.IX Subsection "H8/300 Options"
+.PP
+These \fB\-m\fR options are defined for the H8/300 implementations:
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Shorten some address references at link time, when possible; uses the
+linker option \fB\-relax\fR.
+.IP "\fB\-mh\fR" 4
+.IX Item "-mh"
+Generate code for the H8/300H.
+.IP "\fB\-ms\fR" 4
+.IX Item "-ms"
+Generate code for the H8S.
+.IP "\fB\-mn\fR" 4
+.IX Item "-mn"
+Generate code for the H8S and H8/300H in the normal mode.  This switch
+must be used either with \fB\-mh\fR or \fB\-ms\fR.
+.IP "\fB\-ms2600\fR" 4
+.IX Item "-ms2600"
+Generate code for the H8S/2600.  This switch must be used with \fB\-ms\fR.
+.IP "\fB\-mexr\fR" 4
+.IX Item "-mexr"
+Extended registers are stored on stack before execution of function
+with monitor attribute. Default option is \fB\-mexr\fR.
+This option is valid only for H8S targets.
+.IP "\fB\-mno\-exr\fR" 4
+.IX Item "-mno-exr"
+Extended registers are not stored on stack before execution of function 
+with monitor attribute. Default option is \fB\-mno\-exr\fR. 
+This option is valid only for H8S targets.
+.IP "\fB\-mint32\fR" 4
+.IX Item "-mint32"
+Make \f(CW\*(C`int\*(C'\fR data 32 bits by default.
+.IP "\fB\-malign\-300\fR" 4
+.IX Item "-malign-300"
+On the H8/300H and H8S, use the same alignment rules as for the H8/300.
+The default for the H8/300H and H8S is to align longs and floats on
+4\-byte boundaries.
+\&\fB\-malign\-300\fR causes them to be aligned on 2\-byte boundaries.
+This option has no effect on the H8/300.
+.PP
+\fI\s-1HPPA\s0 Options\fR
+.IX Subsection "HPPA Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1HPPA\s0 family of computers:
+.IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
+.IX Item "-march=architecture-type"
+Generate code for the specified architecture.  The choices for
+\&\fIarchitecture-type\fR are \fB1.0\fR for \s-1PA 1.0, \s0\fB1.1\fR for \s-1PA
+1.1,\s0 and \fB2.0\fR for \s-1PA 2.0\s0 processors.  Refer to
+\&\fI/usr/lib/sched.models\fR on an HP-UX system to determine the proper
+architecture option for your machine.  Code compiled for lower numbered
+architectures runs on higher numbered architectures, but not the
+other way around.
+.IP "\fB\-mpa\-risc\-1\-0\fR" 4
+.IX Item "-mpa-risc-1-0"
+.PD 0
+.IP "\fB\-mpa\-risc\-1\-1\fR" 4
+.IX Item "-mpa-risc-1-1"
+.IP "\fB\-mpa\-risc\-2\-0\fR" 4
+.IX Item "-mpa-risc-2-0"
+.PD
+Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively.
+.IP "\fB\-mjump\-in\-delay\fR" 4
+.IX Item "-mjump-in-delay"
+Fill delay slots of function calls with unconditional jump instructions
+by modifying the return pointer for the function call to be the target
+of the conditional jump.
+.IP "\fB\-mdisable\-fpregs\fR" 4
+.IX Item "-mdisable-fpregs"
+Prevent floating-point registers from being used in any manner.  This is
+necessary for compiling kernels that perform lazy context switching of
+floating-point registers.  If you use this option and attempt to perform
+floating-point operations, the compiler aborts.
+.IP "\fB\-mdisable\-indexing\fR" 4
+.IX Item "-mdisable-indexing"
+Prevent the compiler from using indexing address modes.  This avoids some
+rather obscure problems when compiling \s-1MIG\s0 generated code under \s-1MACH.\s0
+.IP "\fB\-mno\-space\-regs\fR" 4
+.IX Item "-mno-space-regs"
+Generate code that assumes the target has no space registers.  This allows
+\&\s-1GCC\s0 to generate faster indirect calls and use unscaled index address modes.
+.Sp
+Such code is suitable for level 0 \s-1PA\s0 systems and kernels.
+.IP "\fB\-mfast\-indirect\-calls\fR" 4
+.IX Item "-mfast-indirect-calls"
+Generate code that assumes calls never cross space boundaries.  This
+allows \s-1GCC\s0 to emit code that performs faster indirect calls.
+.Sp
+This option does not work in the presence of shared libraries or nested
+functions.
+.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
+.IX Item "-mfixed-range=register-range"
+Generate code treating the given register range as fixed registers.
+A fixed register is one that the register allocator cannot use.  This is
+useful when compiling kernel code.  A register range is specified as
+two registers separated by a dash.  Multiple register ranges can be
+specified separated by a comma.
+.IP "\fB\-mlong\-load\-store\fR" 4
+.IX Item "-mlong-load-store"
+Generate 3\-instruction load and store sequences as sometimes required by
+the HP-UX 10 linker.  This is equivalent to the \fB+k\fR option to
+the \s-1HP\s0 compilers.
+.IP "\fB\-mportable\-runtime\fR" 4
+.IX Item "-mportable-runtime"
+Use the portable calling conventions proposed by \s-1HP\s0 for \s-1ELF\s0 systems.
+.IP "\fB\-mgas\fR" 4
+.IX Item "-mgas"
+Enable the use of assembler directives only \s-1GAS\s0 understands.
+.IP "\fB\-mschedule=\fR\fIcpu-type\fR" 4
+.IX Item "-mschedule=cpu-type"
+Schedule code according to the constraints for the machine type
+\&\fIcpu-type\fR.  The choices for \fIcpu-type\fR are \fB700\fR
+\&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, \fB7300\fR and \fB8000\fR.  Refer
+to \fI/usr/lib/sched.models\fR on an HP-UX system to determine the
+proper scheduling option for your machine.  The default scheduling is
+\&\fB8000\fR.
+.IP "\fB\-mlinker\-opt\fR" 4
+.IX Item "-mlinker-opt"
+Enable the optimization pass in the HP-UX linker.  Note this makes symbolic
+debugging impossible.  It also triggers a bug in the HP-UX 8 and HP-UX 9
+linkers in which they give bogus error messages when linking some programs.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Generate output containing library calls for floating point.
+\&\fBWarning:\fR the requisite libraries are not available for all \s-1HPPA\s0
+targets.  Normally the facilities of the machine's usual C compiler are
+used, but this cannot be done directly in cross-compilation.  You must make
+your own arrangements to provide suitable library functions for
+cross-compilation.
+.Sp
+\&\fB\-msoft\-float\fR changes the calling convention in the output file;
+therefore, it is only useful if you compile \fIall\fR of a program with
+this option.  In particular, you need to compile \fIlibgcc.a\fR, the
+library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
+this to work.
+.IP "\fB\-msio\fR" 4
+.IX Item "-msio"
+Generate the predefine, \f(CW\*(C`_SIO\*(C'\fR, for server \s-1IO. \s0 The default is
+\&\fB\-mwsio\fR.  This generates the predefines, \f(CW\*(C`_\|_hp9000s700\*(C'\fR,
+\&\f(CW\*(C`_\|_hp9000s700_\|_\*(C'\fR and \f(CW\*(C`_WSIO\*(C'\fR, for workstation \s-1IO. \s0 These
+options are available under HP-UX and HI-UX.
+.IP "\fB\-mgnu\-ld\fR" 4
+.IX Item "-mgnu-ld"
+Use options specific to \s-1GNU \s0\fBld\fR.
+This passes \fB\-shared\fR to \fBld\fR when
+building a shared library.  It is the default when \s-1GCC\s0 is configured,
+explicitly or implicitly, with the \s-1GNU\s0 linker.  This option does not
+affect which \fBld\fR is called; it only changes what parameters
+are passed to that \fBld\fR.
+The \fBld\fR that is called is determined by the
+\&\fB\-\-with\-ld\fR configure option, \s-1GCC\s0's program search path, and
+finally by the user's \fB\s-1PATH\s0\fR.  The linker used by \s-1GCC\s0 can be printed
+using \fBwhich `gcc \-print\-prog\-name=ld`\fR.  This option is only available
+on the 64\-bit HP-UX \s-1GCC,\s0 i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
+.IP "\fB\-mhp\-ld\fR" 4
+.IX Item "-mhp-ld"
+Use options specific to \s-1HP \s0\fBld\fR.
+This passes \fB\-b\fR to \fBld\fR when building
+a shared library and passes \fB+Accept TypeMismatch\fR to \fBld\fR on all
+links.  It is the default when \s-1GCC\s0 is configured, explicitly or
+implicitly, with the \s-1HP\s0 linker.  This option does not affect
+which \fBld\fR is called; it only changes what parameters are passed to that
+\&\fBld\fR.
+The \fBld\fR that is called is determined by the \fB\-\-with\-ld\fR
+configure option, \s-1GCC\s0's program search path, and finally by the user's
+\&\fB\s-1PATH\s0\fR.  The linker used by \s-1GCC\s0 can be printed using \fBwhich
+`gcc \-print\-prog\-name=ld`\fR.  This option is only available on the 64\-bit
+HP-UX \s-1GCC,\s0 i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+Generate code that uses long call sequences.  This ensures that a call
+is always able to reach linker generated stubs.  The default is to generate
+long calls only when the distance from the call site to the beginning
+of the function or translation unit, as the case may be, exceeds a
+predefined limit set by the branch type being used.  The limits for
+normal calls are 7,600,000 and 240,000 bytes, respectively for the
+\&\s-1PA 2.0\s0 and \s-1PA 1.X\s0 architectures.  Sibcalls are always limited at
+240,000 bytes.
+.Sp
+Distances are measured from the beginning of functions when using the
+\&\fB\-ffunction\-sections\fR option, or when using the \fB\-mgas\fR
+and \fB\-mno\-portable\-runtime\fR options together under HP-UX with
+the \s-1SOM\s0 linker.
+.Sp
+It is normally not desirable to use this option as it degrades
+performance.  However, it may be useful in large applications,
+particularly when partial linking is used to build the application.
+.Sp
+The types of long calls used depends on the capabilities of the
+assembler and linker, and the type of code being generated.  The
+impact on systems that support long absolute calls, and long pic
+symbol-difference or pc-relative calls should be relatively small.
+However, an indirect call is used on 32\-bit \s-1ELF\s0 systems in pic code
+and it is quite long.
+.IP "\fB\-munix=\fR\fIunix-std\fR" 4
+.IX Item "-munix=unix-std"
+Generate compiler predefines and select a startfile for the specified
+\&\s-1UNIX\s0 standard.  The choices for \fIunix-std\fR are \fB93\fR, \fB95\fR
+and \fB98\fR.  \fB93\fR is supported on all HP-UX versions.  \fB95\fR
+is available on HP-UX 10.10 and later.  \fB98\fR is available on HP-UX
+11.11 and later.  The default values are \fB93\fR for HP-UX 10.00,
+\&\fB95\fR for HP-UX 10.10 though to 11.00, and \fB98\fR for HP-UX 11.11
+and later.
+.Sp
+\&\fB\-munix=93\fR provides the same predefines as \s-1GCC 3.3\s0 and 3.4.
+\&\fB\-munix=95\fR provides additional predefines for \f(CW\*(C`XOPEN_UNIX\*(C'\fR
+and \f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, and the startfile \fIunix95.o\fR.
+\&\fB\-munix=98\fR provides additional predefines for \f(CW\*(C`_XOPEN_UNIX\*(C'\fR,
+\&\f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, \f(CW\*(C`_INCLUDE_\|_STDC_A1_SOURCE\*(C'\fR and
+\&\f(CW\*(C`_INCLUDE_XOPEN_SOURCE_500\*(C'\fR, and the startfile \fIunix98.o\fR.
+.Sp
+It is \fIimportant\fR to note that this option changes the interfaces
+for various library routines.  It also affects the operational behavior
+of the C library.  Thus, \fIextreme\fR care is needed in using this
+option.
+.Sp
+Library code that is intended to operate with more than one \s-1UNIX\s0
+standard must test, set and restore the variable \fI_\|_xpg4_extended_mask\fR
+as appropriate.  Most \s-1GNU\s0 software doesn't provide this capability.
+.IP "\fB\-nolibdld\fR" 4
+.IX Item "-nolibdld"
+Suppress the generation of link options to search libdld.sl when the
+\&\fB\-static\fR option is specified on HP-UX 10 and later.
+.IP "\fB\-static\fR" 4
+.IX Item "-static"
+The HP-UX implementation of setlocale in libc has a dependency on
+libdld.sl.  There isn't an archive version of libdld.sl.  Thus,
+when the \fB\-static\fR option is specified, special link options
+are needed to resolve this dependency.
+.Sp
+On HP-UX 10 and later, the \s-1GCC\s0 driver adds the necessary options to
+link with libdld.sl when the \fB\-static\fR option is specified.
+This causes the resulting binary to be dynamic.  On the 64\-bit port,
+the linkers generate dynamic binaries by default in any case.  The
+\&\fB\-nolibdld\fR option can be used to prevent the \s-1GCC\s0 driver from
+adding these link options.
+.IP "\fB\-threads\fR" 4
+.IX Item "-threads"
+Add support for multithreading with the \fIdce thread\fR library
+under HP-UX.  This option sets flags for both the preprocessor and
+linker.
+.PP
+\fIIntel 386 and \s-1AMD\s0 x86\-64 Options\fR
+.IX Subsection "Intel 386 and AMD x86-64 Options"
+.PP
+These \fB\-m\fR options are defined for the i386 and x86\-64 family of
+computers:
+.IP "\fB\-march=\fR\fIcpu-type\fR" 4
+.IX Item "-march=cpu-type"
+Generate instructions for the machine type \fIcpu-type\fR.  In contrast to
+\&\fB\-mtune=\fR\fIcpu-type\fR, which merely tunes the generated code 
+for the specified \fIcpu-type\fR, \fB\-march=\fR\fIcpu-type\fR allows \s-1GCC\s0
+to generate code that may not run at all on processors other than the one
+indicated.  Specifying \fB\-march=\fR\fIcpu-type\fR implies 
+\&\fB\-mtune=\fR\fIcpu-type\fR.
+.Sp
+The choices for \fIcpu-type\fR are:
+.RS 4
+.IP "\fBnative\fR" 4
+.IX Item "native"
+This selects the \s-1CPU\s0 to generate code for at compilation time by determining
+the processor type of the compiling machine.  Using \fB\-march=native\fR
+enables all instruction subsets supported by the local machine (hence
+the result might not run on different machines).  Using \fB\-mtune=native\fR
+produces code optimized for the local machine under the constraints
+of the selected instruction set.
+.IP "\fBi386\fR" 4
+.IX Item "i386"
+Original Intel i386 \s-1CPU.\s0
+.IP "\fBi486\fR" 4
+.IX Item "i486"
+Intel i486 \s-1CPU.  \s0(No scheduling is implemented for this chip.)
+.IP "\fBi586\fR" 4
+.IX Item "i586"
+.PD 0
+.IP "\fBpentium\fR" 4
+.IX Item "pentium"
+.PD
+Intel Pentium \s-1CPU\s0 with no \s-1MMX\s0 support.
+.IP "\fBpentium-mmx\fR" 4
+.IX Item "pentium-mmx"
+Intel Pentium \s-1MMX CPU,\s0 based on Pentium core with \s-1MMX\s0 instruction set support.
+.IP "\fBpentiumpro\fR" 4
+.IX Item "pentiumpro"
+Intel Pentium Pro \s-1CPU.\s0
+.IP "\fBi686\fR" 4
+.IX Item "i686"
+When used with \fB\-march\fR, the Pentium Pro
+instruction set is used, so the code runs on all i686 family chips.
+When used with \fB\-mtune\fR, it has the same meaning as \fBgeneric\fR.
+.IP "\fBpentium2\fR" 4
+.IX Item "pentium2"
+Intel Pentium \s-1II CPU,\s0 based on Pentium Pro core with \s-1MMX\s0 instruction set
+support.
+.IP "\fBpentium3\fR" 4
+.IX Item "pentium3"
+.PD 0
+.IP "\fBpentium3m\fR" 4
+.IX Item "pentium3m"
+.PD
+Intel Pentium \s-1III CPU,\s0 based on Pentium Pro core with \s-1MMX\s0 and \s-1SSE\s0 instruction
+set support.
+.IP "\fBpentium-m\fR" 4
+.IX Item "pentium-m"
+Intel Pentium M; low-power version of Intel Pentium \s-1III CPU\s0
+with \s-1MMX, SSE\s0 and \s-1SSE2\s0 instruction set support.  Used by Centrino notebooks.
+.IP "\fBpentium4\fR" 4
+.IX Item "pentium4"
+.PD 0
+.IP "\fBpentium4m\fR" 4
+.IX Item "pentium4m"
+.PD
+Intel Pentium 4 \s-1CPU\s0 with \s-1MMX, SSE\s0 and \s-1SSE2\s0 instruction set support.
+.IP "\fBprescott\fR" 4
+.IX Item "prescott"
+Improved version of Intel Pentium 4 \s-1CPU\s0 with \s-1MMX, SSE, SSE2\s0 and \s-1SSE3\s0 instruction
+set support.
+.IP "\fBnocona\fR" 4
+.IX Item "nocona"
+Improved version of Intel Pentium 4 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE,
+SSE2\s0 and \s-1SSE3\s0 instruction set support.
+.IP "\fBcore2\fR" 4
+.IX Item "core2"
+Intel Core 2 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
+instruction set support.
+.IP "\fBnehalem\fR" 4
+.IX Item "nehalem"
+Intel Nehalem \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2\s0 and \s-1POPCNT\s0 instruction set support.
+.IP "\fBwestmere\fR" 4
+.IX Item "westmere"
+Intel Westmere \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AES\s0 and \s-1PCLMUL\s0 instruction set support.
+.IP "\fBsandybridge\fR" 4
+.IX Item "sandybridge"
+Intel Sandy Bridge \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AVX, AES\s0 and \s-1PCLMUL\s0 instruction set support.
+.IP "\fBivybridge\fR" 4
+.IX Item "ivybridge"
+Intel Ivy Bridge \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AVX, AES, PCLMUL, FSGSBASE, RDRND\s0 and F16C
+instruction set support.
+.IP "\fBhaswell\fR" 4
+.IX Item "haswell"
+Intel Haswell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA,
+BMI, BMI2\s0 and F16C instruction set support.
+.IP "\fBbroadwell\fR" 4
+.IX Item "broadwell"
+Intel Broadwell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA,
+BMI, BMI2, F16C, RDSEED, ADCX\s0 and \s-1PREFETCHW\s0 instruction set support.
+.IP "\fBbonnell\fR" 4
+.IX Item "bonnell"
+Intel Bonnell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
+instruction set support.
+.IP "\fBsilvermont\fR" 4
+.IX Item "silvermont"
+Intel Silvermont \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AES, PCLMUL\s0 and \s-1RDRND\s0 instruction set support.
+.IP "\fBk6\fR" 4
+.IX Item "k6"
+\&\s-1AMD K6 CPU\s0 with \s-1MMX\s0 instruction set support.
+.IP "\fBk6\-2\fR" 4
+.IX Item "k6-2"
+.PD 0
+.IP "\fBk6\-3\fR" 4
+.IX Item "k6-3"
+.PD
+Improved versions of \s-1AMD K6 CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
+.IP "\fBathlon\fR" 4
+.IX Item "athlon"
+.PD 0
+.IP "\fBathlon-tbird\fR" 4
+.IX Item "athlon-tbird"
+.PD
+\&\s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX,\s0 3dNOW!, enhanced 3DNow! and \s-1SSE\s0 prefetch instructions
+support.
+.IP "\fBathlon\-4\fR" 4
+.IX Item "athlon-4"
+.PD 0
+.IP "\fBathlon-xp\fR" 4
+.IX Item "athlon-xp"
+.IP "\fBathlon-mp\fR" 4
+.IX Item "athlon-mp"
+.PD
+Improved \s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX,\s0 3DNow!, enhanced 3DNow! and full \s-1SSE\s0
+instruction set support.
+.IP "\fBk8\fR" 4
+.IX Item "k8"
+.PD 0
+.IP "\fBopteron\fR" 4
+.IX Item "opteron"
+.IP "\fBathlon64\fR" 4
+.IX Item "athlon64"
+.IP "\fBathlon-fx\fR" 4
+.IX Item "athlon-fx"
+.PD
+Processors based on the \s-1AMD K8\s0 core with x86\-64 instruction set support,
+including the \s-1AMD\s0 Opteron, Athlon 64, and Athlon 64 \s-1FX\s0 processors.
+(This supersets \s-1MMX, SSE, SSE2,\s0 3DNow!, enhanced 3DNow! and 64\-bit
+instruction set extensions.)
+.IP "\fBk8\-sse3\fR" 4
+.IX Item "k8-sse3"
+.PD 0
+.IP "\fBopteron\-sse3\fR" 4
+.IX Item "opteron-sse3"
+.IP "\fBathlon64\-sse3\fR" 4
+.IX Item "athlon64-sse3"
+.PD
+Improved versions of \s-1AMD K8\s0 cores with \s-1SSE3\s0 instruction set support.
+.IP "\fBamdfam10\fR" 4
+.IX Item "amdfam10"
+.PD 0
+.IP "\fBbarcelona\fR" 4
+.IX Item "barcelona"
+.PD
+CPUs based on \s-1AMD\s0 Family 10h cores with x86\-64 instruction set support.  (This
+supersets \s-1MMX, SSE, SSE2, SSE3, SSE4A,\s0 3DNow!, enhanced 3DNow!, \s-1ABM\s0 and 64\-bit
+instruction set extensions.)
+.IP "\fBbdver1\fR" 4
+.IX Item "bdver1"
+CPUs based on \s-1AMD\s0 Family 15h cores with x86\-64 instruction set support.  (This
+supersets \s-1FMA4, AVX, XOP, LWP, AES, PCL_MUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
+SSSE3, SSE4.1, SSE4.2, ABM\s0 and 64\-bit instruction set extensions.)
+.IP "\fBbdver2\fR" 4
+.IX Item "bdver2"
+\&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
+supersets \s-1BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCL_MUL, CX16, MMX,
+SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM\s0 and 64\-bit instruction set 
+extensions.)
+.IP "\fBbdver3\fR" 4
+.IX Item "bdver3"
+\&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
+supersets \s-1BMI, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, XOP, LWP, AES, 
+PCL_MUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM\s0 and 
+64\-bit instruction set extensions.
+.IP "\fBbdver4\fR" 4
+.IX Item "bdver4"
+\&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
+supersets \s-1BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP, 
+AES, PCL_MUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, 
+SSE4.2, ABM\s0 and 64\-bit instruction set extensions.
+.IP "\fBbtver1\fR" 4
+.IX Item "btver1"
+CPUs based on \s-1AMD\s0 Family 14h cores with x86\-64 instruction set support.  (This
+supersets \s-1MMX, SSE, SSE2, SSE3, SSSE3, SSE4A, CX16, ABM\s0 and 64\-bit
+instruction set extensions.)
+.IP "\fBbtver2\fR" 4
+.IX Item "btver2"
+CPUs based on \s-1AMD\s0 Family 16h cores with x86\-64 instruction set support. This
+includes \s-1MOVBE, F16C, BMI, AVX, PCL_MUL, AES, SSE4.2, SSE4.1, CX16, ABM,
+SSE4A, SSSE3, SSE3, SSE2, SSE, MMX\s0 and 64\-bit instruction set extensions.
+.IP "\fBwinchip\-c6\fR" 4
+.IX Item "winchip-c6"
+\&\s-1IDT\s0 WinChip C6 \s-1CPU,\s0 dealt in same way as i486 with additional \s-1MMX\s0 instruction
+set support.
+.IP "\fBwinchip2\fR" 4
+.IX Item "winchip2"
+\&\s-1IDT\s0 WinChip 2 \s-1CPU,\s0 dealt in same way as i486 with additional \s-1MMX\s0 and 3DNow!
+instruction set support.
+.IP "\fBc3\fR" 4
+.IX Item "c3"
+\&\s-1VIA C3 CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.  (No scheduling is
+implemented for this chip.)
+.IP "\fBc3\-2\fR" 4
+.IX Item "c3-2"
+\&\s-1VIA C3\-2 \s0(Nehemiah/C5XL) \s-1CPU\s0 with \s-1MMX\s0 and \s-1SSE\s0 instruction set support.
+(No scheduling is
+implemented for this chip.)
+.IP "\fBgeode\fR" 4
+.IX Item "geode"
+\&\s-1AMD\s0 Geode embedded processor with \s-1MMX\s0 and 3DNow! instruction set support.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
+.IX Item "-mtune=cpu-type"
+Tune to \fIcpu-type\fR everything applicable about the generated code, except
+for the \s-1ABI\s0 and the set of available instructions.  
+While picking a specific \fIcpu-type\fR schedules things appropriately
+for that particular chip, the compiler does not generate any code that
+cannot run on the default machine type unless you use a
+\&\fB\-march=\fR\fIcpu-type\fR option.
+For example, if \s-1GCC\s0 is configured for i686\-pc\-linux\-gnu
+then \fB\-mtune=pentium4\fR generates code that is tuned for Pentium 4
+but still runs on i686 machines.
+.Sp
+The choices for \fIcpu-type\fR are the same as for \fB\-march\fR.
+In addition, \fB\-mtune\fR supports 2 extra choices for \fIcpu-type\fR:
+.RS 4
+.IP "\fBgeneric\fR" 4
+.IX Item "generic"
+Produce code optimized for the most common \s-1IA32/AMD64/EM64T\s0 processors.
+If you know the \s-1CPU\s0 on which your code will run, then you should use
+the corresponding \fB\-mtune\fR or \fB\-march\fR option instead of
+\&\fB\-mtune=generic\fR.  But, if you do not know exactly what \s-1CPU\s0 users
+of your application will have, then you should use this option.
+.Sp
+As new processors are deployed in the marketplace, the behavior of this
+option will change.  Therefore, if you upgrade to a newer version of
+\&\s-1GCC,\s0 code generation controlled by this option will change to reflect
+the processors
+that are most common at the time that version of \s-1GCC\s0 is released.
+.Sp
+There is no \fB\-march=generic\fR option because \fB\-march\fR
+indicates the instruction set the compiler can use, and there is no
+generic instruction set applicable to all processors.  In contrast,
+\&\fB\-mtune\fR indicates the processor (or, in this case, collection of
+processors) for which the code is optimized.
+.IP "\fBintel\fR" 4
+.IX Item "intel"
+Produce code optimized for the most current Intel processors, which are
+Haswell and Silvermont for this version of \s-1GCC. \s0 If you know the \s-1CPU\s0
+on which your code will run, then you should use the corresponding
+\&\fB\-mtune\fR or \fB\-march\fR option instead of \fB\-mtune=intel\fR.
+But, if you want your application performs better on both Haswell and
+Silvermont, then you should use this option.
+.Sp
+As new Intel processors are deployed in the marketplace, the behavior of
+this option will change.  Therefore, if you upgrade to a newer version of
+\&\s-1GCC,\s0 code generation controlled by this option will change to reflect
+the most current Intel processors at the time that version of \s-1GCC\s0 is
+released.
+.Sp
+There is no \fB\-march=intel\fR option because \fB\-march\fR indicates
+the instruction set the compiler can use, and there is no common
+instruction set applicable to all processors.  In contrast,
+\&\fB\-mtune\fR indicates the processor (or, in this case, collection of
+processors) for which the code is optimized.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
+.IX Item "-mcpu=cpu-type"
+A deprecated synonym for \fB\-mtune\fR.
+.IP "\fB\-mfpmath=\fR\fIunit\fR" 4
+.IX Item "-mfpmath=unit"
+Generate floating-point arithmetic for selected unit \fIunit\fR.  The choices
+for \fIunit\fR are:
+.RS 4
+.IP "\fB387\fR" 4
+.IX Item "387"
+Use the standard 387 floating-point coprocessor present on the majority of chips and
+emulated otherwise.  Code compiled with this option runs almost everywhere.
+The temporary results are computed in 80\-bit precision instead of the precision
+specified by the type, resulting in slightly different results compared to most
+of other chips.  See \fB\-ffloat\-store\fR for more detailed description.
+.Sp
+This is the default choice for i386 compiler.
+.IP "\fBsse\fR" 4
+.IX Item "sse"
+Use scalar floating-point instructions present in the \s-1SSE\s0 instruction set.
+This instruction set is supported by Pentium \s-1III\s0 and newer chips,
+and in the \s-1AMD\s0 line
+by Athlon\-4, Athlon \s-1XP\s0 and Athlon \s-1MP\s0 chips.  The earlier version of the \s-1SSE\s0
+instruction set supports only single-precision arithmetic, thus the double and
+extended-precision arithmetic are still done using 387.  A later version, present
+only in Pentium 4 and \s-1AMD\s0 x86\-64 chips, supports double-precision
+arithmetic too.
+.Sp
+For the i386 compiler, you must use \fB\-march=\fR\fIcpu-type\fR, \fB\-msse\fR
+or \fB\-msse2\fR switches to enable \s-1SSE\s0 extensions and make this option
+effective.  For the x86\-64 compiler, these extensions are enabled by default.
+.Sp
+The resulting code should be considerably faster in the majority of cases and avoid
+the numerical instability problems of 387 code, but may break some existing
+code that expects temporaries to be 80 bits.
+.Sp
+This is the default choice for the x86\-64 compiler.
+.IP "\fBsse,387\fR" 4
+.IX Item "sse,387"
+.PD 0
+.IP "\fBsse+387\fR" 4
+.IX Item "sse+387"
+.IP "\fBboth\fR" 4
+.IX Item "both"
+.PD
+Attempt to utilize both instruction sets at once.  This effectively doubles the
+amount of available registers, and on chips with separate execution units for
+387 and \s-1SSE\s0 the execution resources too.  Use this option with care, as it is
+still experimental, because the \s-1GCC\s0 register allocator does not model separate
+functional units well, resulting in unstable performance.
+.RE
+.RS 4
+.RE
+.IP "\fB\-masm=\fR\fIdialect\fR" 4
+.IX Item "-masm=dialect"
+Output assembly instructions using selected \fIdialect\fR.  Supported
+choices are \fBintel\fR or \fBatt\fR (the default).  Darwin does
+not support \fBintel\fR.
+.IP "\fB\-mieee\-fp\fR" 4
+.IX Item "-mieee-fp"
+.PD 0
+.IP "\fB\-mno\-ieee\-fp\fR" 4
+.IX Item "-mno-ieee-fp"
+.PD
+Control whether or not the compiler uses \s-1IEEE\s0 floating-point
+comparisons.  These correctly handle the case where the result of a
+comparison is unordered.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Generate output containing library calls for floating point.
+.Sp
+\&\fBWarning:\fR the requisite libraries are not part of \s-1GCC.\s0
+Normally the facilities of the machine's usual C compiler are used, but
+this can't be done directly in cross-compilation.  You must make your
+own arrangements to provide suitable library functions for
+cross-compilation.
+.Sp
+On machines where a function returns floating-point results in the 80387
+register stack, some floating-point opcodes may be emitted even if
+\&\fB\-msoft\-float\fR is used.
+.IP "\fB\-mno\-fp\-ret\-in\-387\fR" 4
+.IX Item "-mno-fp-ret-in-387"
+Do not use the \s-1FPU\s0 registers for return values of functions.
+.Sp
+The usual calling convention has functions return values of types
+\&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR in an \s-1FPU\s0 register, even if there
+is no \s-1FPU. \s0 The idea is that the operating system should emulate
+an \s-1FPU.\s0
+.Sp
+The option \fB\-mno\-fp\-ret\-in\-387\fR causes such values to be returned
+in ordinary \s-1CPU\s0 registers instead.
+.IP "\fB\-mno\-fancy\-math\-387\fR" 4
+.IX Item "-mno-fancy-math-387"
+Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and
+\&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387.  Specify this option to avoid
+generating those instructions.  This option is the default on FreeBSD,
+OpenBSD and NetBSD.  This option is overridden when \fB\-march\fR
+indicates that the target \s-1CPU\s0 always has an \s-1FPU\s0 and so the
+instruction does not need emulation.  These
+instructions are not generated unless you also use the
+\&\fB\-funsafe\-math\-optimizations\fR switch.
+.IP "\fB\-malign\-double\fR" 4
+.IX Item "-malign-double"
+.PD 0
+.IP "\fB\-mno\-align\-double\fR" 4
+.IX Item "-mno-align-double"
+.PD
+Control whether \s-1GCC\s0 aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and
+\&\f(CW\*(C`long long\*(C'\fR variables on a two-word boundary or a one-word
+boundary.  Aligning \f(CW\*(C`double\*(C'\fR variables on a two-word boundary
+produces code that runs somewhat faster on a Pentium at the
+expense of more memory.
+.Sp
+On x86\-64, \fB\-malign\-double\fR is enabled by default.
+.Sp
+\&\fBWarning:\fR if you use the \fB\-malign\-double\fR switch,
+structures containing the above types are aligned differently than
+the published application binary interface specifications for the 386
+and are not binary compatible with structures in code compiled
+without that switch.
+.IP "\fB\-m96bit\-long\-double\fR" 4
+.IX Item "-m96bit-long-double"
+.PD 0
+.IP "\fB\-m128bit\-long\-double\fR" 4
+.IX Item "-m128bit-long-double"
+.PD
+These switches control the size of \f(CW\*(C`long double\*(C'\fR type.  The i386
+application binary interface specifies the size to be 96 bits,
+so \fB\-m96bit\-long\-double\fR is the default in 32\-bit mode.
+.Sp
+Modern architectures (Pentium and newer) prefer \f(CW\*(C`long double\*(C'\fR
+to be aligned to an 8\- or 16\-byte boundary.  In arrays or structures
+conforming to the \s-1ABI,\s0 this is not possible.  So specifying
+\&\fB\-m128bit\-long\-double\fR aligns \f(CW\*(C`long double\*(C'\fR
+to a 16\-byte boundary by padding the \f(CW\*(C`long double\*(C'\fR with an additional
+32\-bit zero.
+.Sp
+In the x86\-64 compiler, \fB\-m128bit\-long\-double\fR is the default choice as
+its \s-1ABI\s0 specifies that \f(CW\*(C`long double\*(C'\fR is aligned on 16\-byte boundary.
+.Sp
+Notice that neither of these options enable any extra precision over the x87
+standard of 80 bits for a \f(CW\*(C`long double\*(C'\fR.
+.Sp
+\&\fBWarning:\fR if you override the default value for your target \s-1ABI,\s0 this
+changes the size of 
+structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
+as well as modifying the function calling convention for functions taking
+\&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary-compatible
+with code compiled without that switch.
+.IP "\fB\-mlong\-double\-64\fR" 4
+.IX Item "-mlong-double-64"
+.PD 0
+.IP "\fB\-mlong\-double\-80\fR" 4
+.IX Item "-mlong-double-80"
+.IP "\fB\-mlong\-double\-128\fR" 4
+.IX Item "-mlong-double-128"
+.PD
+These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
+of 64 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
+type. This is the default for 32\-bit Bionic C library.  A size
+of 128 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the
+\&\f(CW\*(C`_\|_float128\*(C'\fR type. This is the default for 64\-bit Bionic C library.
+.Sp
+\&\fBWarning:\fR if you override the default value for your target \s-1ABI,\s0 this
+changes the size of
+structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
+as well as modifying the function calling convention for functions taking
+\&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary-compatible
+with code compiled without that switch.
+.IP "\fB\-mlarge\-data\-threshold=\fR\fIthreshold\fR" 4
+.IX Item "-mlarge-data-threshold=threshold"
+When \fB\-mcmodel=medium\fR is specified, data objects larger than
+\&\fIthreshold\fR are placed in the large data section.  This value must be the
+same across all objects linked into the binary, and defaults to 65535.
+.IP "\fB\-mrtd\fR" 4
+.IX Item "-mrtd"
+Use a different function-calling convention, in which functions that
+take a fixed number of arguments return with the \f(CW\*(C`ret \f(CInum\f(CW\*(C'\fR
+instruction, which pops their arguments while returning.  This saves one
+instruction in the caller since there is no need to pop the arguments
+there.
+.Sp
+You can specify that an individual function is called with this calling
+sequence with the function attribute \fBstdcall\fR.  You can also
+override the \fB\-mrtd\fR option by using the function attribute
+\&\fBcdecl\fR.
+.Sp
+\&\fBWarning:\fR this calling convention is incompatible with the one
+normally used on Unix, so you cannot use it if you need to call
+libraries compiled with the Unix compiler.
+.Sp
+Also, you must provide function prototypes for all functions that
+take variable numbers of arguments (including \f(CW\*(C`printf\*(C'\fR);
+otherwise incorrect code is generated for calls to those
+functions.
+.Sp
+In addition, seriously incorrect code results if you call a
+function with too many arguments.  (Normally, extra arguments are
+harmlessly ignored.)
+.IP "\fB\-mregparm=\fR\fInum\fR" 4
+.IX Item "-mregparm=num"
+Control how many registers are used to pass integer arguments.  By
+default, no registers are used to pass arguments, and at most 3
+registers can be used.  You can control this behavior for a specific
+function by using the function attribute \fBregparm\fR.
+.Sp
+\&\fBWarning:\fR if you use this switch, and
+\&\fInum\fR is nonzero, then you must build all modules with the same
+value, including any libraries.  This includes the system libraries and
+startup modules.
+.IP "\fB\-msseregparm\fR" 4
+.IX Item "-msseregparm"
+Use \s-1SSE\s0 register passing conventions for float and double arguments
+and return values.  You can control this behavior for a specific
+function by using the function attribute \fBsseregparm\fR.
+.Sp
+\&\fBWarning:\fR if you use this switch then you must build all
+modules with the same value, including any libraries.  This includes
+the system libraries and startup modules.
+.IP "\fB\-mvect8\-ret\-in\-mem\fR" 4
+.IX Item "-mvect8-ret-in-mem"
+Return 8\-byte vectors in memory instead of \s-1MMX\s0 registers.  This is the
+default on Solaris@tie{}8 and 9 and VxWorks to match the \s-1ABI\s0 of the Sun
+Studio compilers until version 12.  Later compiler versions (starting
+with Studio 12 Update@tie{}1) follow the \s-1ABI\s0 used by other x86 targets, which
+is the default on Solaris@tie{}10 and later.  \fIOnly\fR use this option if
+you need to remain compatible with existing code produced by those
+previous compiler versions or older versions of \s-1GCC.\s0
+.IP "\fB\-mpc32\fR" 4
+.IX Item "-mpc32"
+.PD 0
+.IP "\fB\-mpc64\fR" 4
+.IX Item "-mpc64"
+.IP "\fB\-mpc80\fR" 4
+.IX Item "-mpc80"
+.PD
+Set 80387 floating-point precision to 32, 64 or 80 bits.  When \fB\-mpc32\fR
+is specified, the significands of results of floating-point operations are
+rounded to 24 bits (single precision); \fB\-mpc64\fR rounds the
+significands of results of floating-point operations to 53 bits (double
+precision) and \fB\-mpc80\fR rounds the significands of results of
+floating-point operations to 64 bits (extended double precision), which is
+the default.  When this option is used, floating-point operations in higher
+precisions are not available to the programmer without setting the \s-1FPU\s0
+control word explicitly.
+.Sp
+Setting the rounding of floating-point operations to less than the default
+80 bits can speed some programs by 2% or more.  Note that some mathematical
+libraries assume that extended-precision (80\-bit) floating-point operations
+are enabled by default; routines in such libraries could suffer significant
+loss of accuracy, typically through so-called \*(L"catastrophic cancellation\*(R",
+when this option is used to set the precision to less than extended precision.
+.IP "\fB\-mstackrealign\fR" 4
+.IX Item "-mstackrealign"
+Realign the stack at entry.  On the Intel x86, the \fB\-mstackrealign\fR
+option generates an alternate prologue and epilogue that realigns the
+run-time stack if necessary.  This supports mixing legacy codes that keep
+4\-byte stack alignment with modern codes that keep 16\-byte stack alignment for
+\&\s-1SSE\s0 compatibility.  See also the attribute \f(CW\*(C`force_align_arg_pointer\*(C'\fR,
+applicable to individual functions.
+.IP "\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR" 4
+.IX Item "-mpreferred-stack-boundary=num"
+Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
+byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
+the default is 4 (16 bytes or 128 bits).
+.Sp
+\&\fBWarning:\fR When generating code for the x86\-64 architecture with
+\&\s-1SSE\s0 extensions disabled, \fB\-mpreferred\-stack\-boundary=3\fR can be
+used to keep the stack boundary aligned to 8 byte boundary.  Since
+x86\-64 \s-1ABI\s0 require 16 byte stack alignment, this is \s-1ABI\s0 incompatible and
+intended to be used in controlled environment where stack space is
+important limitation.  This option will lead to wrong code when functions
+compiled with 16 byte stack alignment (such as functions from a standard
+library) are called with misaligned stack.  In this case, \s-1SSE\s0
+instructions may lead to misaligned memory access traps.  In addition,
+variable arguments will be handled incorrectly for 16 byte aligned
+objects (including x87 long double and _\|_int128), leading to wrong
+results.  You must build all modules with
+\&\fB\-mpreferred\-stack\-boundary=3\fR, including any libraries.  This
+includes the system libraries and startup modules.
+.IP "\fB\-mincoming\-stack\-boundary=\fR\fInum\fR" 4
+.IX Item "-mincoming-stack-boundary=num"
+Assume the incoming stack is aligned to a 2 raised to \fInum\fR byte
+boundary.  If \fB\-mincoming\-stack\-boundary\fR is not specified,
+the one specified by \fB\-mpreferred\-stack\-boundary\fR is used.
+.Sp
+On Pentium and Pentium Pro, \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long double\*(C'\fR values
+should be aligned to an 8\-byte boundary (see \fB\-malign\-double\fR) or
+suffer significant run time performance penalties.  On Pentium \s-1III,\s0 the
+Streaming \s-1SIMD\s0 Extension (\s-1SSE\s0) data type \f(CW\*(C`_\|_m128\*(C'\fR may not work
+properly if it is not 16\-byte aligned.
+.Sp
+To ensure proper alignment of this values on the stack, the stack boundary
+must be as aligned as that required by any value stored on the stack.
+Further, every function must be generated such that it keeps the stack
+aligned.  Thus calling a function compiled with a higher preferred
+stack boundary from a function compiled with a lower preferred stack
+boundary most likely misaligns the stack.  It is recommended that
+libraries that use callbacks always use the default setting.
+.Sp
+This extra alignment does consume extra stack space, and generally
+increases code size.  Code that is sensitive to stack space usage, such
+as embedded systems and operating system kernels, may want to reduce the
+preferred alignment to \fB\-mpreferred\-stack\-boundary=2\fR.
+.IP "\fB\-mmmx\fR" 4
+.IX Item "-mmmx"
+.PD 0
+.IP "\fB\-mno\-mmx\fR" 4
+.IX Item "-mno-mmx"
+.IP "\fB\-msse\fR" 4
+.IX Item "-msse"
+.IP "\fB\-mno\-sse\fR" 4
+.IX Item "-mno-sse"
+.IP "\fB\-msse2\fR" 4
+.IX Item "-msse2"
+.IP "\fB\-mno\-sse2\fR" 4
+.IX Item "-mno-sse2"
+.IP "\fB\-msse3\fR" 4
+.IX Item "-msse3"
+.IP "\fB\-mno\-sse3\fR" 4
+.IX Item "-mno-sse3"
+.IP "\fB\-mssse3\fR" 4
+.IX Item "-mssse3"
+.IP "\fB\-mno\-ssse3\fR" 4
+.IX Item "-mno-ssse3"
+.IP "\fB\-msse4.1\fR" 4
+.IX Item "-msse4.1"
+.IP "\fB\-mno\-sse4.1\fR" 4
+.IX Item "-mno-sse4.1"
+.IP "\fB\-msse4.2\fR" 4
+.IX Item "-msse4.2"
+.IP "\fB\-mno\-sse4.2\fR" 4
+.IX Item "-mno-sse4.2"
+.IP "\fB\-msse4\fR" 4
+.IX Item "-msse4"
+.IP "\fB\-mno\-sse4\fR" 4
+.IX Item "-mno-sse4"
+.IP "\fB\-mavx\fR" 4
+.IX Item "-mavx"
+.IP "\fB\-mno\-avx\fR" 4
+.IX Item "-mno-avx"
+.IP "\fB\-mavx2\fR" 4
+.IX Item "-mavx2"
+.IP "\fB\-mno\-avx2\fR" 4
+.IX Item "-mno-avx2"
+.IP "\fB\-mavx512f\fR" 4
+.IX Item "-mavx512f"
+.IP "\fB\-mno\-avx512f\fR" 4
+.IX Item "-mno-avx512f"
+.IP "\fB\-mavx512pf\fR" 4
+.IX Item "-mavx512pf"
+.IP "\fB\-mno\-avx512pf\fR" 4
+.IX Item "-mno-avx512pf"
+.IP "\fB\-mavx512er\fR" 4
+.IX Item "-mavx512er"
+.IP "\fB\-mno\-avx512er\fR" 4
+.IX Item "-mno-avx512er"
+.IP "\fB\-mavx512cd\fR" 4
+.IX Item "-mavx512cd"
+.IP "\fB\-mno\-avx512cd\fR" 4
+.IX Item "-mno-avx512cd"
+.IP "\fB\-msha\fR" 4
+.IX Item "-msha"
+.IP "\fB\-mno\-sha\fR" 4
+.IX Item "-mno-sha"
+.IP "\fB\-maes\fR" 4
+.IX Item "-maes"
+.IP "\fB\-mno\-aes\fR" 4
+.IX Item "-mno-aes"
+.IP "\fB\-mpclmul\fR" 4
+.IX Item "-mpclmul"
+.IP "\fB\-mno\-pclmul\fR" 4
+.IX Item "-mno-pclmul"
+.IP "\fB\-mfsgsbase\fR" 4
+.IX Item "-mfsgsbase"
+.IP "\fB\-mno\-fsgsbase\fR" 4
+.IX Item "-mno-fsgsbase"
+.IP "\fB\-mrdrnd\fR" 4
+.IX Item "-mrdrnd"
+.IP "\fB\-mno\-rdrnd\fR" 4
+.IX Item "-mno-rdrnd"
+.IP "\fB\-mf16c\fR" 4
+.IX Item "-mf16c"
+.IP "\fB\-mno\-f16c\fR" 4
+.IX Item "-mno-f16c"
+.IP "\fB\-mfma\fR" 4
+.IX Item "-mfma"
+.IP "\fB\-mno\-fma\fR" 4
+.IX Item "-mno-fma"
+.IP "\fB\-mprefetchwt1\fR" 4
+.IX Item "-mprefetchwt1"
+.IP "\fB\-mno\-prefetchwt1\fR" 4
+.IX Item "-mno-prefetchwt1"
+.IP "\fB\-msse4a\fR" 4
+.IX Item "-msse4a"
+.IP "\fB\-mno\-sse4a\fR" 4
+.IX Item "-mno-sse4a"
+.IP "\fB\-mfma4\fR" 4
+.IX Item "-mfma4"
+.IP "\fB\-mno\-fma4\fR" 4
+.IX Item "-mno-fma4"
+.IP "\fB\-mxop\fR" 4
+.IX Item "-mxop"
+.IP "\fB\-mno\-xop\fR" 4
+.IX Item "-mno-xop"
+.IP "\fB\-mlwp\fR" 4
+.IX Item "-mlwp"
+.IP "\fB\-mno\-lwp\fR" 4
+.IX Item "-mno-lwp"
+.IP "\fB\-m3dnow\fR" 4
+.IX Item "-m3dnow"
+.IP "\fB\-mno\-3dnow\fR" 4
+.IX Item "-mno-3dnow"
+.IP "\fB\-mpopcnt\fR" 4
+.IX Item "-mpopcnt"
+.IP "\fB\-mno\-popcnt\fR" 4
+.IX Item "-mno-popcnt"
+.IP "\fB\-mabm\fR" 4
+.IX Item "-mabm"
+.IP "\fB\-mno\-abm\fR" 4
+.IX Item "-mno-abm"
+.IP "\fB\-mbmi\fR" 4
+.IX Item "-mbmi"
+.IP "\fB\-mbmi2\fR" 4
+.IX Item "-mbmi2"
+.IP "\fB\-mno\-bmi\fR" 4
+.IX Item "-mno-bmi"
+.IP "\fB\-mno\-bmi2\fR" 4
+.IX Item "-mno-bmi2"
+.IP "\fB\-mlzcnt\fR" 4
+.IX Item "-mlzcnt"
+.IP "\fB\-mno\-lzcnt\fR" 4
+.IX Item "-mno-lzcnt"
+.IP "\fB\-mfxsr\fR" 4
+.IX Item "-mfxsr"
+.IP "\fB\-mxsave\fR" 4
+.IX Item "-mxsave"
+.IP "\fB\-mxsaveopt\fR" 4
+.IX Item "-mxsaveopt"
+.IP "\fB\-mrtm\fR" 4
+.IX Item "-mrtm"
+.IP "\fB\-mtbm\fR" 4
+.IX Item "-mtbm"
+.IP "\fB\-mno\-tbm\fR" 4
+.IX Item "-mno-tbm"
+.PD
+These switches enable or disable the use of instructions in the \s-1MMX, SSE,
+SSE2, SSE3, SSSE3, SSE4.1, AVX, AVX2, AVX512F, AVX512PF, AVX512ER, AVX512CD,
+SHA, AES, PCLMUL, FSGSBASE, RDRND, F16C, FMA, SSE4A, FMA4, XOP, LWP, ABM,
+BMI, BMI2, FXSR, XSAVE, XSAVEOPT, LZCNT, RTM,\s0 or 3DNow!
+extended instruction sets.
+These extensions are also available as built-in functions: see
+\&\fBX86 Built-in Functions\fR, for details of the functions enabled and
+disabled by these switches.
+.Sp
+To generate \s-1SSE/SSE2\s0 instructions automatically from floating-point
+code (as opposed to 387 instructions), see \fB\-mfpmath=sse\fR.
+.Sp
+\&\s-1GCC\s0 depresses SSEx instructions when \fB\-mavx\fR is used. Instead, it
+generates new \s-1AVX\s0 instructions or \s-1AVX\s0 equivalence for all SSEx instructions
+when needed.
+.Sp
+These options enable \s-1GCC\s0 to use these extended instructions in
+generated code, even without \fB\-mfpmath=sse\fR.  Applications that
+perform run-time \s-1CPU\s0 detection must compile separate files for each
+supported architecture, using the appropriate flags.  In particular,
+the file containing the \s-1CPU\s0 detection code should be compiled without
+these options.
+.IP "\fB\-mdump\-tune\-features\fR" 4
+.IX Item "-mdump-tune-features"
+This option instructs \s-1GCC\s0 to dump the names of the x86 performance 
+tuning features and default settings. The names can be used in 
+\&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR.
+.IP "\fB\-mtune\-ctrl=\fR\fIfeature-list\fR" 4
+.IX Item "-mtune-ctrl=feature-list"
+This option is used to do fine grain control of x86 code generation features.
+\&\fIfeature-list\fR is a comma separated list of \fIfeature\fR names. See also
+\&\fB\-mdump\-tune\-features\fR. When specified, the \fIfeature\fR will be turned
+on if it is not preceded with \f(CW\*(C`^\*(C'\fR, otherwise, it will be turned off. 
+\&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR is intended to be used by \s-1GCC\s0
+developers. Using it may lead to code paths not covered by testing and can
+potentially result in compiler ICEs or runtime errors.
+.IP "\fB\-mno\-default\fR" 4
+.IX Item "-mno-default"
+This option instructs \s-1GCC\s0 to turn off all tunable features. See also 
+\&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR and \fB\-mdump\-tune\-features\fR.
+.IP "\fB\-mcld\fR" 4
+.IX Item "-mcld"
+This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`cld\*(C'\fR instruction in the prologue
+of functions that use string instructions.  String instructions depend on
+the \s-1DF\s0 flag to select between autoincrement or autodecrement mode.  While the
+\&\s-1ABI\s0 specifies the \s-1DF\s0 flag to be cleared on function entry, some operating
+systems violate this specification by not clearing the \s-1DF\s0 flag in their
+exception dispatchers.  The exception handler can be invoked with the \s-1DF\s0 flag
+set, which leads to wrong direction mode when string instructions are used.
+This option can be enabled by default on 32\-bit x86 targets by configuring
+\&\s-1GCC\s0 with the \fB\-\-enable\-cld\fR configure option.  Generation of \f(CW\*(C`cld\*(C'\fR
+instructions can be suppressed with the \fB\-mno\-cld\fR compiler option
+in this case.
+.IP "\fB\-mvzeroupper\fR" 4
+.IX Item "-mvzeroupper"
+This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`vzeroupper\*(C'\fR instruction
+before a transfer of control flow out of the function to minimize
+the \s-1AVX\s0 to \s-1SSE\s0 transition penalty as well as remove unnecessary \f(CW\*(C`zeroupper\*(C'\fR
+intrinsics.
+.IP "\fB\-mprefer\-avx128\fR" 4
+.IX Item "-mprefer-avx128"
+This option instructs \s-1GCC\s0 to use 128\-bit \s-1AVX\s0 instructions instead of
+256\-bit \s-1AVX\s0 instructions in the auto-vectorizer.
+.IP "\fB\-mcx16\fR" 4
+.IX Item "-mcx16"
+This option enables \s-1GCC\s0 to generate \f(CW\*(C`CMPXCHG16B\*(C'\fR instructions.
+\&\f(CW\*(C`CMPXCHG16B\*(C'\fR allows for atomic operations on 128\-bit double quadword
+(or oword) data types.  
+This is useful for high-resolution counters that can be updated
+by multiple processors (or cores).  This instruction is generated as part of
+atomic built-in functions: see \fB_\|_sync Builtins\fR or
+\&\fB_\|_atomic Builtins\fR for details.
+.IP "\fB\-msahf\fR" 4
+.IX Item "-msahf"
+This option enables generation of \f(CW\*(C`SAHF\*(C'\fR instructions in 64\-bit code.
+Early Intel Pentium 4 CPUs with Intel 64 support,
+prior to the introduction of Pentium 4 G1 step in December 2005,
+lacked the \f(CW\*(C`LAHF\*(C'\fR and \f(CW\*(C`SAHF\*(C'\fR instructions
+which were supported by \s-1AMD64.\s0
+These are load and store instructions, respectively, for certain status flags.
+In 64\-bit mode, the \f(CW\*(C`SAHF\*(C'\fR instruction is used to optimize \f(CW\*(C`fmod\*(C'\fR,
+\&\f(CW\*(C`drem\*(C'\fR, and \f(CW\*(C`remainder\*(C'\fR built-in functions;
+see \fBOther Builtins\fR for details.
+.IP "\fB\-mmovbe\fR" 4
+.IX Item "-mmovbe"
+This option enables use of the \f(CW\*(C`movbe\*(C'\fR instruction to implement
+\&\f(CW\*(C`_\|_builtin_bswap32\*(C'\fR and \f(CW\*(C`_\|_builtin_bswap64\*(C'\fR.
+.IP "\fB\-mcrc32\fR" 4
+.IX Item "-mcrc32"
+This option enables built-in functions \f(CW\*(C`_\|_builtin_ia32_crc32qi\*(C'\fR,
+\&\f(CW\*(C`_\|_builtin_ia32_crc32hi\*(C'\fR, \f(CW\*(C`_\|_builtin_ia32_crc32si\*(C'\fR and
+\&\f(CW\*(C`_\|_builtin_ia32_crc32di\*(C'\fR to generate the \f(CW\*(C`crc32\*(C'\fR machine instruction.
+.IP "\fB\-mrecip\fR" 4
+.IX Item "-mrecip"
+This option enables use of \f(CW\*(C`RCPSS\*(C'\fR and \f(CW\*(C`RSQRTSS\*(C'\fR instructions
+(and their vectorized variants \f(CW\*(C`RCPPS\*(C'\fR and \f(CW\*(C`RSQRTPS\*(C'\fR)
+with an additional Newton-Raphson step
+to increase precision instead of \f(CW\*(C`DIVSS\*(C'\fR and \f(CW\*(C`SQRTSS\*(C'\fR
+(and their vectorized
+variants) for single-precision floating-point arguments.  These instructions
+are generated only when \fB\-funsafe\-math\-optimizations\fR is enabled
+together with \fB\-finite\-math\-only\fR and \fB\-fno\-trapping\-math\fR.
+Note that while the throughput of the sequence is higher than the throughput
+of the non-reciprocal instruction, the precision of the sequence can be
+decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
+.Sp
+Note that \s-1GCC\s0 implements \f(CW\*(C`1.0f/sqrtf(\f(CIx\f(CW)\*(C'\fR in terms of \f(CW\*(C`RSQRTSS\*(C'\fR
+(or \f(CW\*(C`RSQRTPS\*(C'\fR) already with \fB\-ffast\-math\fR (or the above option
+combination), and doesn't need \fB\-mrecip\fR.
+.Sp
+Also note that \s-1GCC\s0 emits the above sequence with additional Newton-Raphson step
+for vectorized single-float division and vectorized \f(CW\*(C`sqrtf(\f(CIx\f(CW)\*(C'\fR
+already with \fB\-ffast\-math\fR (or the above option combination), and
+doesn't need \fB\-mrecip\fR.
+.IP "\fB\-mrecip=\fR\fIopt\fR" 4
+.IX Item "-mrecip=opt"
+This option controls which reciprocal estimate instructions
+may be used.  \fIopt\fR is a comma-separated list of options, which may
+be preceded by a \fB!\fR to invert the option:
+.RS 4
+.IP "\fBall\fR" 4
+.IX Item "all"
+Enable all estimate instructions.
+.IP "\fBdefault\fR" 4
+.IX Item "default"
+Enable the default instructions, equivalent to \fB\-mrecip\fR.
+.IP "\fBnone\fR" 4
+.IX Item "none"
+Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
+.IP "\fBdiv\fR" 4
+.IX Item "div"
+Enable the approximation for scalar division.
+.IP "\fBvec-div\fR" 4
+.IX Item "vec-div"
+Enable the approximation for vectorized division.
+.IP "\fBsqrt\fR" 4
+.IX Item "sqrt"
+Enable the approximation for scalar square root.
+.IP "\fBvec-sqrt\fR" 4
+.IX Item "vec-sqrt"
+Enable the approximation for vectorized square root.
+.RE
+.RS 4
+.Sp
+So, for example, \fB\-mrecip=all,!sqrt\fR enables
+all of the reciprocal approximations, except for square root.
+.RE
+.IP "\fB\-mveclibabi=\fR\fItype\fR" 4
+.IX Item "-mveclibabi=type"
+Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
+external library.  Supported values for \fItype\fR are \fBsvml\fR 
+for the Intel short
+vector math library and \fBacml\fR for the \s-1AMD\s0 math core library.
+To use this option, both \fB\-ftree\-vectorize\fR and
+\&\fB\-funsafe\-math\-optimizations\fR have to be enabled, and an \s-1SVML\s0 or \s-1ACML \s0
+ABI-compatible library must be specified at link time.
+.Sp
+\&\s-1GCC\s0 currently emits calls to \f(CW\*(C`vmldExp2\*(C'\fR,
+\&\f(CW\*(C`vmldLn2\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldPow2\*(C'\fR,
+\&\f(CW\*(C`vmldTanh2\*(C'\fR, \f(CW\*(C`vmldTan2\*(C'\fR, \f(CW\*(C`vmldAtan2\*(C'\fR, \f(CW\*(C`vmldAtanh2\*(C'\fR,
+\&\f(CW\*(C`vmldCbrt2\*(C'\fR, \f(CW\*(C`vmldSinh2\*(C'\fR, \f(CW\*(C`vmldSin2\*(C'\fR, \f(CW\*(C`vmldAsinh2\*(C'\fR,
+\&\f(CW\*(C`vmldAsin2\*(C'\fR, \f(CW\*(C`vmldCosh2\*(C'\fR, \f(CW\*(C`vmldCos2\*(C'\fR, \f(CW\*(C`vmldAcosh2\*(C'\fR,
+\&\f(CW\*(C`vmldAcos2\*(C'\fR, \f(CW\*(C`vmlsExp4\*(C'\fR, \f(CW\*(C`vmlsLn4\*(C'\fR, \f(CW\*(C`vmlsLog104\*(C'\fR,
+\&\f(CW\*(C`vmlsLog104\*(C'\fR, \f(CW\*(C`vmlsPow4\*(C'\fR, \f(CW\*(C`vmlsTanh4\*(C'\fR, \f(CW\*(C`vmlsTan4\*(C'\fR,
+\&\f(CW\*(C`vmlsAtan4\*(C'\fR, \f(CW\*(C`vmlsAtanh4\*(C'\fR, \f(CW\*(C`vmlsCbrt4\*(C'\fR, \f(CW\*(C`vmlsSinh4\*(C'\fR,
+\&\f(CW\*(C`vmlsSin4\*(C'\fR, \f(CW\*(C`vmlsAsinh4\*(C'\fR, \f(CW\*(C`vmlsAsin4\*(C'\fR, \f(CW\*(C`vmlsCosh4\*(C'\fR,
+\&\f(CW\*(C`vmlsCos4\*(C'\fR, \f(CW\*(C`vmlsAcosh4\*(C'\fR and \f(CW\*(C`vmlsAcos4\*(C'\fR for corresponding
+function type when \fB\-mveclibabi=svml\fR is used, and \f(CW\*(C`_\|_vrd2_sin\*(C'\fR,
+\&\f(CW\*(C`_\|_vrd2_cos\*(C'\fR, \f(CW\*(C`_\|_vrd2_exp\*(C'\fR, \f(CW\*(C`_\|_vrd2_log\*(C'\fR, \f(CW\*(C`_\|_vrd2_log2\*(C'\fR,
+\&\f(CW\*(C`_\|_vrd2_log10\*(C'\fR, \f(CW\*(C`_\|_vrs4_sinf\*(C'\fR, \f(CW\*(C`_\|_vrs4_cosf\*(C'\fR,
+\&\f(CW\*(C`_\|_vrs4_expf\*(C'\fR, \f(CW\*(C`_\|_vrs4_logf\*(C'\fR, \f(CW\*(C`_\|_vrs4_log2f\*(C'\fR,
+\&\f(CW\*(C`_\|_vrs4_log10f\*(C'\fR and \f(CW\*(C`_\|_vrs4_powf\*(C'\fR for the corresponding function type
+when \fB\-mveclibabi=acml\fR is used.
+.IP "\fB\-mabi=\fR\fIname\fR" 4
+.IX Item "-mabi=name"
+Generate code for the specified calling convention.  Permissible values
+are \fBsysv\fR for the \s-1ABI\s0 used on GNU/Linux and other systems, and
+\&\fBms\fR for the Microsoft \s-1ABI. \s0 The default is to use the Microsoft
+\&\s-1ABI\s0 when targeting Microsoft Windows and the SysV \s-1ABI\s0 on all other systems.
+You can control this behavior for a specific function by
+using the function attribute \fBms_abi\fR/\fBsysv_abi\fR.
+.IP "\fB\-mtls\-dialect=\fR\fItype\fR" 4
+.IX Item "-mtls-dialect=type"
+Generate code to access thread-local storage using the \fBgnu\fR or
+\&\fBgnu2\fR conventions.  \fBgnu\fR is the conservative default;
+\&\fBgnu2\fR is more efficient, but it may add compile\- and run-time
+requirements that cannot be satisfied on all systems.
+.IP "\fB\-mpush\-args\fR" 4
+.IX Item "-mpush-args"
+.PD 0
+.IP "\fB\-mno\-push\-args\fR" 4
+.IX Item "-mno-push-args"
+.PD
+Use \s-1PUSH\s0 operations to store outgoing parameters.  This method is shorter
+and usually equally fast as method using \s-1SUB/MOV\s0 operations and is enabled
+by default.  In some cases disabling it may improve performance because of
+improved scheduling and reduced dependencies.
+.IP "\fB\-maccumulate\-outgoing\-args\fR" 4
+.IX Item "-maccumulate-outgoing-args"
+If enabled, the maximum amount of space required for outgoing arguments is
+computed in the function prologue.  This is faster on most modern CPUs
+because of reduced dependencies, improved scheduling and reduced stack usage
+when the preferred stack boundary is not equal to 2.  The drawback is a notable
+increase in code size.  This switch implies \fB\-mno\-push\-args\fR.
+.IP "\fB\-mthreads\fR" 4
+.IX Item "-mthreads"
+Support thread-safe exception handling on MinGW.  Programs that rely
+on thread-safe exception handling must compile and link all code with the
+\&\fB\-mthreads\fR option.  When compiling, \fB\-mthreads\fR defines
+\&\f(CW\*(C`\-D_MT\*(C'\fR; when linking, it links in a special thread helper library
+\&\fB\-lmingwthrd\fR which cleans up per-thread exception-handling data.
+.IP "\fB\-mno\-align\-stringops\fR" 4
+.IX Item "-mno-align-stringops"
+Do not align the destination of inlined string operations.  This switch reduces
+code size and improves performance in case the destination is already aligned,
+but \s-1GCC\s0 doesn't know about it.
+.IP "\fB\-minline\-all\-stringops\fR" 4
+.IX Item "-minline-all-stringops"
+By default \s-1GCC\s0 inlines string operations only when the destination is 
+known to be aligned to least a 4\-byte boundary.  
+This enables more inlining and increases code
+size, but may improve performance of code that depends on fast
+\&\f(CW\*(C`memcpy\*(C'\fR, \f(CW\*(C`strlen\*(C'\fR,
+and \f(CW\*(C`memset\*(C'\fR for short lengths.
+.IP "\fB\-minline\-stringops\-dynamically\fR" 4
+.IX Item "-minline-stringops-dynamically"
+For string operations of unknown size, use run-time checks with
+inline code for small blocks and a library call for large blocks.
+.IP "\fB\-mstringop\-strategy=\fR\fIalg\fR" 4
+.IX Item "-mstringop-strategy=alg"
+Override the internal decision heuristic for the particular algorithm to use
+for inlining string operations.  The allowed values for \fIalg\fR are:
+.RS 4
+.IP "\fBrep_byte\fR" 4
+.IX Item "rep_byte"
+.PD 0
+.IP "\fBrep_4byte\fR" 4
+.IX Item "rep_4byte"
+.IP "\fBrep_8byte\fR" 4
+.IX Item "rep_8byte"
+.PD
+Expand using i386 \f(CW\*(C`rep\*(C'\fR prefix of the specified size.
+.IP "\fBbyte_loop\fR" 4
+.IX Item "byte_loop"
+.PD 0
+.IP "\fBloop\fR" 4
+.IX Item "loop"
+.IP "\fBunrolled_loop\fR" 4
+.IX Item "unrolled_loop"
+.PD
+Expand into an inline loop.
+.IP "\fBlibcall\fR" 4
+.IX Item "libcall"
+Always use a library call.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mmemcpy\-strategy=\fR\fIstrategy\fR" 4
+.IX Item "-mmemcpy-strategy=strategy"
+Override the internal decision heuristic to decide if \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR
+should be inlined and what inline algorithm to use when the expected size
+of the copy operation is known. \fIstrategy\fR 
+is a comma-separated list of \fIalg\fR:\fImax_size\fR:\fIdest_align\fR triplets. 
+\&\fIalg\fR is specified in \fB\-mstringop\-strategy\fR, \fImax_size\fR specifies
+the max byte size with which inline algorithm \fIalg\fR is allowed.  For the last
+triplet, the \fImax_size\fR must be \f(CW\*(C`\-1\*(C'\fR. The \fImax_size\fR of the triplets
+in the list must be specified in increasing order.  The minimal byte size for 
+\&\fIalg\fR is \f(CW0\fR for the first triplet and \f(CW\*(C`\f(CImax_size\f(CW + 1\*(C'\fR of the 
+preceding range.
+.IP "\fB\-mmemset\-strategy=\fR\fIstrategy\fR" 4
+.IX Item "-mmemset-strategy=strategy"
+The option is similar to \fB\-mmemcpy\-strategy=\fR except that it is to control
+\&\f(CW\*(C`_\|_builtin_memset\*(C'\fR expansion.
+.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
+.IX Item "-momit-leaf-frame-pointer"
+Don't keep the frame pointer in a register for leaf functions.  This
+avoids the instructions to save, set up, and restore frame pointers and
+makes an extra register available in leaf functions.  The option
+\&\fB\-fomit\-leaf\-frame\-pointer\fR removes the frame pointer for leaf functions,
+which might make debugging harder.
+.IP "\fB\-mtls\-direct\-seg\-refs\fR" 4
+.IX Item "-mtls-direct-seg-refs"
+.PD 0
+.IP "\fB\-mno\-tls\-direct\-seg\-refs\fR" 4
+.IX Item "-mno-tls-direct-seg-refs"
+.PD
+Controls whether \s-1TLS\s0 variables may be accessed with offsets from the
+\&\s-1TLS\s0 segment register (\f(CW%gs\fR for 32\-bit, \f(CW%fs\fR for 64\-bit),
+or whether the thread base pointer must be added.  Whether or not this
+is valid depends on the operating system, and whether it maps the
+segment to cover the entire \s-1TLS\s0 area.
+.Sp
+For systems that use the \s-1GNU C\s0 Library, the default is on.
+.IP "\fB\-msse2avx\fR" 4
+.IX Item "-msse2avx"
+.PD 0
+.IP "\fB\-mno\-sse2avx\fR" 4
+.IX Item "-mno-sse2avx"
+.PD
+Specify that the assembler should encode \s-1SSE\s0 instructions with \s-1VEX\s0
+prefix.  The option \fB\-mavx\fR turns this on by default.
+.IP "\fB\-mfentry\fR" 4
+.IX Item "-mfentry"
+.PD 0
+.IP "\fB\-mno\-fentry\fR" 4
+.IX Item "-mno-fentry"
+.PD
+If profiling is active (\fB\-pg\fR), put the profiling
+counter call before the prologue.
+Note: On x86 architectures the attribute \f(CW\*(C`ms_hook_prologue\*(C'\fR
+isn't possible at the moment for \fB\-mfentry\fR and \fB\-pg\fR.
+.IP "\fB\-m8bit\-idiv\fR" 4
+.IX Item "-m8bit-idiv"
+.PD 0
+.IP "\fB\-mno\-8bit\-idiv\fR" 4
+.IX Item "-mno-8bit-idiv"
+.PD
+On some processors, like Intel Atom, 8\-bit unsigned integer divide is
+much faster than 32\-bit/64\-bit integer divide.  This option generates a
+run-time check.  If both dividend and divisor are within range of 0
+to 255, 8\-bit unsigned integer divide is used instead of
+32\-bit/64\-bit integer divide.
+.IP "\fB\-mavx256\-split\-unaligned\-load\fR" 4
+.IX Item "-mavx256-split-unaligned-load"
+.PD 0
+.IP "\fB\-mavx256\-split\-unaligned\-store\fR" 4
+.IX Item "-mavx256-split-unaligned-store"
+.PD
+Split 32\-byte \s-1AVX\s0 unaligned load and store.
+.IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
+.IX Item "-mstack-protector-guard=guard"
+Generate stack protection code using canary at \fIguard\fR.  Supported
+locations are \fBglobal\fR for global canary or \fBtls\fR for per-thread
+canary in the \s-1TLS\s0 block (the default).  This option has effect only when
+\&\fB\-fstack\-protector\fR or \fB\-fstack\-protector\-all\fR is specified.
+.PP
+These \fB\-m\fR switches are supported in addition to the above
+on x86\-64 processors in 64\-bit environments.
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+.PD 0
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.IP "\fB\-mx32\fR" 4
+.IX Item "-mx32"
+.IP "\fB\-m16\fR" 4
+.IX Item "-m16"
+.PD
+Generate code for a 16\-bit, 32\-bit or 64\-bit environment.
+The \fB\-m32\fR option sets \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, and pointer types
+to 32 bits, and
+generates code that runs on any i386 system.
+.Sp
+The \fB\-m64\fR option sets \f(CW\*(C`int\*(C'\fR to 32 bits and \f(CW\*(C`long\*(C'\fR and pointer
+types to 64 bits, and generates code for the x86\-64 architecture.
+For Darwin only the \fB\-m64\fR option also turns off the \fB\-fno\-pic\fR
+and \fB\-mdynamic\-no\-pic\fR options.
+.Sp
+The \fB\-mx32\fR option sets \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, and pointer types
+to 32 bits, and
+generates code for the x86\-64 architecture.
+.Sp
+The \fB\-m16\fR option is the same as \fB\-m32\fR, except for that
+it outputs the \f(CW\*(C`.code16gcc\*(C'\fR assembly directive at the beginning of
+the assembly output so that the binary can run in 16\-bit mode.
+.IP "\fB\-mno\-red\-zone\fR" 4
+.IX Item "-mno-red-zone"
+Do not use a so-called \*(L"red zone\*(R" for x86\-64 code.  The red zone is mandated
+by the x86\-64 \s-1ABI\s0; it is a 128\-byte area beyond the location of the
+stack pointer that is not modified by signal or interrupt handlers
+and therefore can be used for temporary data without adjusting the stack
+pointer.  The flag \fB\-mno\-red\-zone\fR disables this red zone.
+.IP "\fB\-mcmodel=small\fR" 4
+.IX Item "-mcmodel=small"
+Generate code for the small code model: the program and its symbols must
+be linked in the lower 2 \s-1GB\s0 of the address space.  Pointers are 64 bits.
+Programs can be statically or dynamically linked.  This is the default
+code model.
+.IP "\fB\-mcmodel=kernel\fR" 4
+.IX Item "-mcmodel=kernel"
+Generate code for the kernel code model.  The kernel runs in the
+negative 2 \s-1GB\s0 of the address space.
+This model has to be used for Linux kernel code.
+.IP "\fB\-mcmodel=medium\fR" 4
+.IX Item "-mcmodel=medium"
+Generate code for the medium model: the program is linked in the lower 2
+\&\s-1GB\s0 of the address space.  Small symbols are also placed there.  Symbols
+with sizes larger than \fB\-mlarge\-data\-threshold\fR are put into
+large data or \s-1BSS\s0 sections and can be located above 2GB.  Programs can
+be statically or dynamically linked.
+.IP "\fB\-mcmodel=large\fR" 4
+.IX Item "-mcmodel=large"
+Generate code for the large model.  This model makes no assumptions
+about addresses and sizes of sections.
+.IP "\fB\-maddress\-mode=long\fR" 4
+.IX Item "-maddress-mode=long"
+Generate code for long address mode.  This is only supported for 64\-bit
+and x32 environments.  It is the default address mode for 64\-bit
+environments.
+.IP "\fB\-maddress\-mode=short\fR" 4
+.IX Item "-maddress-mode=short"
+Generate code for short address mode.  This is only supported for 32\-bit
+and x32 environments.  It is the default address mode for 32\-bit and
+x32 environments.
+.PP
+\fIi386 and x86\-64 Windows Options\fR
+.IX Subsection "i386 and x86-64 Windows Options"
+.PP
+These additional options are available for Microsoft Windows targets:
+.IP "\fB\-mconsole\fR" 4
+.IX Item "-mconsole"
+This option
+specifies that a console application is to be generated, by
+instructing the linker to set the \s-1PE\s0 header subsystem type
+required for console applications.
+This option is available for Cygwin and MinGW targets and is
+enabled by default on those targets.
+.IP "\fB\-mdll\fR" 4
+.IX Item "-mdll"
+This option is available for Cygwin and MinGW targets.  It
+specifies that a DLL\-\-\-a dynamic link library\-\-\-is to be
+generated, enabling the selection of the required runtime
+startup object and entry point.
+.IP "\fB\-mnop\-fun\-dllimport\fR" 4
+.IX Item "-mnop-fun-dllimport"
+This option is available for Cygwin and MinGW targets.  It
+specifies that the \f(CW\*(C`dllimport\*(C'\fR attribute should be ignored.
+.IP "\fB\-mthread\fR" 4
+.IX Item "-mthread"
+This option is available for MinGW targets. It specifies
+that MinGW-specific thread support is to be used.
+.IP "\fB\-municode\fR" 4
+.IX Item "-municode"
+This option is available for MinGW\-w64 targets.  It causes
+the \f(CW\*(C`UNICODE\*(C'\fR preprocessor macro to be predefined, and
+chooses Unicode-capable runtime startup code.
+.IP "\fB\-mwin32\fR" 4
+.IX Item "-mwin32"
+This option is available for Cygwin and MinGW targets.  It
+specifies that the typical Microsoft Windows predefined macros are to
+be set in the pre-processor, but does not influence the choice
+of runtime library/startup code.
+.IP "\fB\-mwindows\fR" 4
+.IX Item "-mwindows"
+This option is available for Cygwin and MinGW targets.  It
+specifies that a \s-1GUI\s0 application is to be generated by
+instructing the linker to set the \s-1PE\s0 header subsystem type
+appropriately.
+.IP "\fB\-fno\-set\-stack\-executable\fR" 4
+.IX Item "-fno-set-stack-executable"
+This option is available for MinGW targets. It specifies that
+the executable flag for the stack used by nested functions isn't
+set. This is necessary for binaries running in kernel mode of
+Microsoft Windows, as there the User32 \s-1API,\s0 which is used to set executable
+privileges, isn't available.
+.IP "\fB\-fwritable\-relocated\-rdata\fR" 4
+.IX Item "-fwritable-relocated-rdata"
+This option is available for MinGW and Cygwin targets.  It specifies
+that relocated-data in read-only section is put into .data
+section.  This is a necessary for older runtimes not supporting
+modification of .rdata sections for pseudo-relocation.
+.IP "\fB\-mpe\-aligned\-commons\fR" 4
+.IX Item "-mpe-aligned-commons"
+This option is available for Cygwin and MinGW targets.  It
+specifies that the \s-1GNU\s0 extension to the \s-1PE\s0 file format that
+permits the correct alignment of \s-1COMMON\s0 variables should be
+used when generating code.  It is enabled by default if
+\&\s-1GCC\s0 detects that the target assembler found during configuration
+supports the feature.
+.PP
+See also under \fBi386 and x86\-64 Options\fR for standard options.
+.PP
+\fI\s-1IA\-64\s0 Options\fR
+.IX Subsection "IA-64 Options"
+.PP
+These are the \fB\-m\fR options defined for the Intel \s-1IA\-64\s0 architecture.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code for a big-endian target.  This is the default for HP-UX.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code for a little-endian target.  This is the default for \s-1AIX5\s0
+and GNU/Linux.
+.IP "\fB\-mgnu\-as\fR" 4
+.IX Item "-mgnu-as"
+.PD 0
+.IP "\fB\-mno\-gnu\-as\fR" 4
+.IX Item "-mno-gnu-as"
+.PD
+Generate (or don't) code for the \s-1GNU\s0 assembler.  This is the default.
+.IP "\fB\-mgnu\-ld\fR" 4
+.IX Item "-mgnu-ld"
+.PD 0
+.IP "\fB\-mno\-gnu\-ld\fR" 4
+.IX Item "-mno-gnu-ld"
+.PD
+Generate (or don't) code for the \s-1GNU\s0 linker.  This is the default.
+.IP "\fB\-mno\-pic\fR" 4
+.IX Item "-mno-pic"
+Generate code that does not use a global pointer register.  The result
+is not position independent code, and violates the \s-1IA\-64 ABI.\s0
+.IP "\fB\-mvolatile\-asm\-stop\fR" 4
+.IX Item "-mvolatile-asm-stop"
+.PD 0
+.IP "\fB\-mno\-volatile\-asm\-stop\fR" 4
+.IX Item "-mno-volatile-asm-stop"
+.PD
+Generate (or don't) a stop bit immediately before and after volatile asm
+statements.
+.IP "\fB\-mregister\-names\fR" 4
+.IX Item "-mregister-names"
+.PD 0
+.IP "\fB\-mno\-register\-names\fR" 4
+.IX Item "-mno-register-names"
+.PD
+Generate (or don't) \fBin\fR, \fBloc\fR, and \fBout\fR register names for
+the stacked registers.  This may make assembler output more readable.
+.IP "\fB\-mno\-sdata\fR" 4
+.IX Item "-mno-sdata"
+.PD 0
+.IP "\fB\-msdata\fR" 4
+.IX Item "-msdata"
+.PD
+Disable (or enable) optimizations that use the small data section.  This may
+be useful for working around optimizer bugs.
+.IP "\fB\-mconstant\-gp\fR" 4
+.IX Item "-mconstant-gp"
+Generate code that uses a single constant global pointer value.  This is
+useful when compiling kernel code.
+.IP "\fB\-mauto\-pic\fR" 4
+.IX Item "-mauto-pic"
+Generate code that is self-relocatable.  This implies \fB\-mconstant\-gp\fR.
+This is useful when compiling firmware code.
+.IP "\fB\-minline\-float\-divide\-min\-latency\fR" 4
+.IX Item "-minline-float-divide-min-latency"
+Generate code for inline divides of floating-point values
+using the minimum latency algorithm.
+.IP "\fB\-minline\-float\-divide\-max\-throughput\fR" 4
+.IX Item "-minline-float-divide-max-throughput"
+Generate code for inline divides of floating-point values
+using the maximum throughput algorithm.
+.IP "\fB\-mno\-inline\-float\-divide\fR" 4
+.IX Item "-mno-inline-float-divide"
+Do not generate inline code for divides of floating-point values.
+.IP "\fB\-minline\-int\-divide\-min\-latency\fR" 4
+.IX Item "-minline-int-divide-min-latency"
+Generate code for inline divides of integer values
+using the minimum latency algorithm.
+.IP "\fB\-minline\-int\-divide\-max\-throughput\fR" 4
+.IX Item "-minline-int-divide-max-throughput"
+Generate code for inline divides of integer values
+using the maximum throughput algorithm.
+.IP "\fB\-mno\-inline\-int\-divide\fR" 4
+.IX Item "-mno-inline-int-divide"
+Do not generate inline code for divides of integer values.
+.IP "\fB\-minline\-sqrt\-min\-latency\fR" 4
+.IX Item "-minline-sqrt-min-latency"
+Generate code for inline square roots
+using the minimum latency algorithm.
+.IP "\fB\-minline\-sqrt\-max\-throughput\fR" 4
+.IX Item "-minline-sqrt-max-throughput"
+Generate code for inline square roots
+using the maximum throughput algorithm.
+.IP "\fB\-mno\-inline\-sqrt\fR" 4
+.IX Item "-mno-inline-sqrt"
+Do not generate inline code for \f(CW\*(C`sqrt\*(C'\fR.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Do (don't) generate code that uses the fused multiply/add or multiply/subtract
+instructions.  The default is to use these instructions.
+.IP "\fB\-mno\-dwarf2\-asm\fR" 4
+.IX Item "-mno-dwarf2-asm"
+.PD 0
+.IP "\fB\-mdwarf2\-asm\fR" 4
+.IX Item "-mdwarf2-asm"
+.PD
+Don't (or do) generate assembler code for the \s-1DWARF 2\s0 line number debugging
+info.  This may be useful when not using the \s-1GNU\s0 assembler.
+.IP "\fB\-mearly\-stop\-bits\fR" 4
+.IX Item "-mearly-stop-bits"
+.PD 0
+.IP "\fB\-mno\-early\-stop\-bits\fR" 4
+.IX Item "-mno-early-stop-bits"
+.PD
+Allow stop bits to be placed earlier than immediately preceding the
+instruction that triggered the stop bit.  This can improve instruction
+scheduling, but does not always do so.
+.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
+.IX Item "-mfixed-range=register-range"
+Generate code treating the given register range as fixed registers.
+A fixed register is one that the register allocator cannot use.  This is
+useful when compiling kernel code.  A register range is specified as
+two registers separated by a dash.  Multiple register ranges can be
+specified separated by a comma.
+.IP "\fB\-mtls\-size=\fR\fItls-size\fR" 4
+.IX Item "-mtls-size=tls-size"
+Specify bit size of immediate \s-1TLS\s0 offsets.  Valid values are 14, 22, and
+64.
+.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
+.IX Item "-mtune=cpu-type"
+Tune the instruction scheduling for a particular \s-1CPU,\s0 Valid values are
+\&\fBitanium\fR, \fBitanium1\fR, \fBmerced\fR, \fBitanium2\fR,
+and \fBmckinley\fR.
+.IP "\fB\-milp32\fR" 4
+.IX Item "-milp32"
+.PD 0
+.IP "\fB\-mlp64\fR" 4
+.IX Item "-mlp64"
+.PD
+Generate code for a 32\-bit or 64\-bit environment.
+The 32\-bit environment sets int, long and pointer to 32 bits.
+The 64\-bit environment sets int to 32 bits and long and pointer
+to 64 bits.  These are HP-UX specific flags.
+.IP "\fB\-mno\-sched\-br\-data\-spec\fR" 4
+.IX Item "-mno-sched-br-data-spec"
+.PD 0
+.IP "\fB\-msched\-br\-data\-spec\fR" 4
+.IX Item "-msched-br-data-spec"
+.PD
+(Dis/En)able data speculative scheduling before reload.
+This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
+the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
+The default is 'disable'.
+.IP "\fB\-msched\-ar\-data\-spec\fR" 4
+.IX Item "-msched-ar-data-spec"
+.PD 0
+.IP "\fB\-mno\-sched\-ar\-data\-spec\fR" 4
+.IX Item "-mno-sched-ar-data-spec"
+.PD
+(En/Dis)able data speculative scheduling after reload.
+This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
+the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
+The default is 'enable'.
+.IP "\fB\-mno\-sched\-control\-spec\fR" 4
+.IX Item "-mno-sched-control-spec"
+.PD 0
+.IP "\fB\-msched\-control\-spec\fR" 4
+.IX Item "-msched-control-spec"
+.PD
+(Dis/En)able control speculative scheduling.  This feature is
+available only during region scheduling (i.e. before reload).
+This results in generation of the \f(CW\*(C`ld.s\*(C'\fR instructions and
+the corresponding check instructions \f(CW\*(C`chk.s\*(C'\fR.
+The default is 'disable'.
+.IP "\fB\-msched\-br\-in\-data\-spec\fR" 4
+.IX Item "-msched-br-in-data-spec"
+.PD 0
+.IP "\fB\-mno\-sched\-br\-in\-data\-spec\fR" 4
+.IX Item "-mno-sched-br-in-data-spec"
+.PD
+(En/Dis)able speculative scheduling of the instructions that
+are dependent on the data speculative loads before reload.
+This is effective only with \fB\-msched\-br\-data\-spec\fR enabled.
+The default is 'enable'.
+.IP "\fB\-msched\-ar\-in\-data\-spec\fR" 4
+.IX Item "-msched-ar-in-data-spec"
+.PD 0
+.IP "\fB\-mno\-sched\-ar\-in\-data\-spec\fR" 4
+.IX Item "-mno-sched-ar-in-data-spec"
+.PD
+(En/Dis)able speculative scheduling of the instructions that
+are dependent on the data speculative loads after reload.
+This is effective only with \fB\-msched\-ar\-data\-spec\fR enabled.
+The default is 'enable'.
+.IP "\fB\-msched\-in\-control\-spec\fR" 4
+.IX Item "-msched-in-control-spec"
+.PD 0
+.IP "\fB\-mno\-sched\-in\-control\-spec\fR" 4
+.IX Item "-mno-sched-in-control-spec"
+.PD
+(En/Dis)able speculative scheduling of the instructions that
+are dependent on the control speculative loads.
+This is effective only with \fB\-msched\-control\-spec\fR enabled.
+The default is 'enable'.
+.IP "\fB\-mno\-sched\-prefer\-non\-data\-spec\-insns\fR" 4
+.IX Item "-mno-sched-prefer-non-data-spec-insns"
+.PD 0
+.IP "\fB\-msched\-prefer\-non\-data\-spec\-insns\fR" 4
+.IX Item "-msched-prefer-non-data-spec-insns"
+.PD
+If enabled, data-speculative instructions are chosen for schedule
+only if there are no other choices at the moment.  This makes
+the use of the data speculation much more conservative.
+The default is 'disable'.
+.IP "\fB\-mno\-sched\-prefer\-non\-control\-spec\-insns\fR" 4
+.IX Item "-mno-sched-prefer-non-control-spec-insns"
+.PD 0
+.IP "\fB\-msched\-prefer\-non\-control\-spec\-insns\fR" 4
+.IX Item "-msched-prefer-non-control-spec-insns"
+.PD
+If enabled, control-speculative instructions are chosen for schedule
+only if there are no other choices at the moment.  This makes
+the use of the control speculation much more conservative.
+The default is 'disable'.
+.IP "\fB\-mno\-sched\-count\-spec\-in\-critical\-path\fR" 4
+.IX Item "-mno-sched-count-spec-in-critical-path"
+.PD 0
+.IP "\fB\-msched\-count\-spec\-in\-critical\-path\fR" 4
+.IX Item "-msched-count-spec-in-critical-path"
+.PD
+If enabled, speculative dependencies are considered during
+computation of the instructions priorities.  This makes the use of the
+speculation a bit more conservative.
+The default is 'disable'.
+.IP "\fB\-msched\-spec\-ldc\fR" 4
+.IX Item "-msched-spec-ldc"
+Use a simple data speculation check.  This option is on by default.
+.IP "\fB\-msched\-control\-spec\-ldc\fR" 4
+.IX Item "-msched-control-spec-ldc"
+Use a simple check for control speculation.  This option is on by default.
+.IP "\fB\-msched\-stop\-bits\-after\-every\-cycle\fR" 4
+.IX Item "-msched-stop-bits-after-every-cycle"
+Place a stop bit after every cycle when scheduling.  This option is on
+by default.
+.IP "\fB\-msched\-fp\-mem\-deps\-zero\-cost\fR" 4
+.IX Item "-msched-fp-mem-deps-zero-cost"
+Assume that floating-point stores and loads are not likely to cause a conflict
+when placed into the same instruction group.  This option is disabled by
+default.
+.IP "\fB\-msel\-sched\-dont\-check\-control\-spec\fR" 4
+.IX Item "-msel-sched-dont-check-control-spec"
+Generate checks for control speculation in selective scheduling.
+This flag is disabled by default.
+.IP "\fB\-msched\-max\-memory\-insns=\fR\fImax-insns\fR" 4
+.IX Item "-msched-max-memory-insns=max-insns"
+Limit on the number of memory insns per instruction group, giving lower
+priority to subsequent memory insns attempting to schedule in the same
+instruction group. Frequently useful to prevent cache bank conflicts.
+The default value is 1.
+.IP "\fB\-msched\-max\-memory\-insns\-hard\-limit\fR" 4
+.IX Item "-msched-max-memory-insns-hard-limit"
+Makes the limit specified by \fBmsched-max-memory-insns\fR a hard limit,
+disallowing more than that number in an instruction group.
+Otherwise, the limit is \*(L"soft\*(R", meaning that non-memory operations
+are preferred when the limit is reached, but memory operations may still
+be scheduled.
+.PP
+\fI\s-1LM32\s0 Options\fR
+.IX Subsection "LM32 Options"
+.PP
+These \fB\-m\fR options are defined for the LatticeMico32 architecture:
+.IP "\fB\-mbarrel\-shift\-enabled\fR" 4
+.IX Item "-mbarrel-shift-enabled"
+Enable barrel-shift instructions.
+.IP "\fB\-mdivide\-enabled\fR" 4
+.IX Item "-mdivide-enabled"
+Enable divide and modulus instructions.
+.IP "\fB\-mmultiply\-enabled\fR" 4
+.IX Item "-mmultiply-enabled"
+Enable multiply instructions.
+.IP "\fB\-msign\-extend\-enabled\fR" 4
+.IX Item "-msign-extend-enabled"
+Enable sign extend instructions.
+.IP "\fB\-muser\-enabled\fR" 4
+.IX Item "-muser-enabled"
+Enable user-defined instructions.
+.PP
+\fIM32C Options\fR
+.IX Subsection "M32C Options"
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Select the \s-1CPU\s0 for which code is generated.  \fIname\fR may be one of
+\&\fBr8c\fR for the R8C/Tiny series, \fBm16c\fR for the M16C (up to
+/60) series, \fBm32cm\fR for the M16C/80 series, or \fBm32c\fR for
+the M32C/80 series.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Specifies that the program will be run on the simulator.  This causes
+an alternate runtime library to be linked in which supports, for
+example, file I/O.  You must not use this option when generating
+programs that will run on real hardware; you must provide your own
+runtime library for whatever I/O functions are needed.
+.IP "\fB\-memregs=\fR\fInumber\fR" 4
+.IX Item "-memregs=number"
+Specifies the number of memory-based pseudo-registers \s-1GCC\s0 uses
+during code generation.  These pseudo-registers are used like real
+registers, so there is a tradeoff between \s-1GCC\s0's ability to fit the
+code into available registers, and the performance penalty of using
+memory instead of registers.  Note that all modules in a program must
+be compiled with the same value for this option.  Because of that, you
+must not use this option with \s-1GCC\s0's default runtime libraries.
+.PP
+\fIM32R/D Options\fR
+.IX Subsection "M32R/D Options"
+.PP
+These \fB\-m\fR options are defined for Renesas M32R/D architectures:
+.IP "\fB\-m32r2\fR" 4
+.IX Item "-m32r2"
+Generate code for the M32R/2.
+.IP "\fB\-m32rx\fR" 4
+.IX Item "-m32rx"
+Generate code for the M32R/X.
+.IP "\fB\-m32r\fR" 4
+.IX Item "-m32r"
+Generate code for the M32R.  This is the default.
+.IP "\fB\-mmodel=small\fR" 4
+.IX Item "-mmodel=small"
+Assume all objects live in the lower 16MB of memory (so that their addresses
+can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines
+are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
+This is the default.
+.Sp
+The addressability of a particular object can be set with the
+\&\f(CW\*(C`model\*(C'\fR attribute.
+.IP "\fB\-mmodel=medium\fR" 4
+.IX Item "-mmodel=medium"
+Assume objects may be anywhere in the 32\-bit address space (the compiler
+generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
+assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
+.IP "\fB\-mmodel=large\fR" 4
+.IX Item "-mmodel=large"
+Assume objects may be anywhere in the 32\-bit address space (the compiler
+generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
+assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction
+(the compiler generates the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR
+instruction sequence).
+.IP "\fB\-msdata=none\fR" 4
+.IX Item "-msdata=none"
+Disable use of the small data area.  Variables are put into
+one of \fB.data\fR, \fB.bss\fR, or \fB.rodata\fR (unless the
+\&\f(CW\*(C`section\*(C'\fR attribute has been specified).
+This is the default.
+.Sp
+The small data area consists of sections \fB.sdata\fR and \fB.sbss\fR.
+Objects may be explicitly put in the small data area with the
+\&\f(CW\*(C`section\*(C'\fR attribute using one of these sections.
+.IP "\fB\-msdata=sdata\fR" 4
+.IX Item "-msdata=sdata"
+Put small global and static data in the small data area, but do not
+generate special code to reference them.
+.IP "\fB\-msdata=use\fR" 4
+.IX Item "-msdata=use"
+Put small global and static data in the small data area, and generate
+special instructions to reference them.
+.IP "\fB\-G\fR \fInum\fR" 4
+.IX Item "-G num"
+Put global and static objects less than or equal to \fInum\fR bytes
+into the small data or \s-1BSS\s0 sections instead of the normal data or \s-1BSS\s0
+sections.  The default value of \fInum\fR is 8.
+The \fB\-msdata\fR option must be set to one of \fBsdata\fR or \fBuse\fR
+for this option to have any effect.
+.Sp
+All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
+Compiling with different values of \fInum\fR may or may not work; if it
+doesn't the linker gives an error message\-\-\-incorrect code is not
+generated.
+.IP "\fB\-mdebug\fR" 4
+.IX Item "-mdebug"
+Makes the M32R\-specific code in the compiler display some statistics
+that might help in debugging programs.
+.IP "\fB\-malign\-loops\fR" 4
+.IX Item "-malign-loops"
+Align all loops to a 32\-byte boundary.
+.IP "\fB\-mno\-align\-loops\fR" 4
+.IX Item "-mno-align-loops"
+Do not enforce a 32\-byte alignment for loops.  This is the default.
+.IP "\fB\-missue\-rate=\fR\fInumber\fR" 4
+.IX Item "-missue-rate=number"
+Issue \fInumber\fR instructions per cycle.  \fInumber\fR can only be 1
+or 2.
+.IP "\fB\-mbranch\-cost=\fR\fInumber\fR" 4
+.IX Item "-mbranch-cost=number"
+\&\fInumber\fR can only be 1 or 2.  If it is 1 then branches are
+preferred over conditional code, if it is 2, then the opposite applies.
+.IP "\fB\-mflush\-trap=\fR\fInumber\fR" 4
+.IX Item "-mflush-trap=number"
+Specifies the trap number to use to flush the cache.  The default is
+12.  Valid numbers are between 0 and 15 inclusive.
+.IP "\fB\-mno\-flush\-trap\fR" 4
+.IX Item "-mno-flush-trap"
+Specifies that the cache cannot be flushed by using a trap.
+.IP "\fB\-mflush\-func=\fR\fIname\fR" 4
+.IX Item "-mflush-func=name"
+Specifies the name of the operating system function to call to flush
+the cache.  The default is \fI_flush_cache\fR, but a function call
+is only used if a trap is not available.
+.IP "\fB\-mno\-flush\-func\fR" 4
+.IX Item "-mno-flush-func"
+Indicates that there is no \s-1OS\s0 function for flushing the cache.
+.PP
+\fIM680x0 Options\fR
+.IX Subsection "M680x0 Options"
+.PP
+These are the \fB\-m\fR options defined for M680x0 and ColdFire processors.
+The default settings depend on which architecture was selected when
+the compiler was configured; the defaults for the most common choices
+are given below.
+.IP "\fB\-march=\fR\fIarch\fR" 4
+.IX Item "-march=arch"
+Generate code for a specific M680x0 or ColdFire instruction set
+architecture.  Permissible values of \fIarch\fR for M680x0
+architectures are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
+\&\fB68030\fR, \fB68040\fR, \fB68060\fR and \fBcpu32\fR.  ColdFire
+architectures are selected according to Freescale's \s-1ISA\s0 classification
+and the permissible values are: \fBisaa\fR, \fBisaaplus\fR,
+\&\fBisab\fR and \fBisac\fR.
+.Sp
+\&\s-1GCC\s0 defines a macro \fB_\|_mcf\fR\fIarch\fR\fB_\|_\fR whenever it is generating
+code for a ColdFire target.  The \fIarch\fR in this macro is one of the
+\&\fB\-march\fR arguments given above.
+.Sp
+When used together, \fB\-march\fR and \fB\-mtune\fR select code
+that runs on a family of similar processors but that is optimized
+for a particular microarchitecture.
+.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
+.IX Item "-mcpu=cpu"
+Generate code for a specific M680x0 or ColdFire processor.
+The M680x0 \fIcpu\fRs are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
+\&\fB68030\fR, \fB68040\fR, \fB68060\fR, \fB68302\fR, \fB68332\fR
+and \fBcpu32\fR.  The ColdFire \fIcpu\fRs are given by the table
+below, which also classifies the CPUs into families:
+.RS 4
+.IP "Family : \fB\-mcpu\fR arguments" 4
+.IX Item "Family : -mcpu arguments"
+.PD 0
+.IP "\fB51\fR : \fB51\fR \fB51ac\fR \fB51ag\fR \fB51cn\fR \fB51em\fR \fB51je\fR \fB51jf\fR \fB51jg\fR \fB51jm\fR \fB51mm\fR \fB51qe\fR \fB51qm\fR" 4
+.IX Item "51 : 51 51ac 51ag 51cn 51em 51je 51jf 51jg 51jm 51mm 51qe 51qm"
+.IP "\fB5206\fR : \fB5202\fR \fB5204\fR \fB5206\fR" 4
+.IX Item "5206 : 5202 5204 5206"
+.IP "\fB5206e\fR : \fB5206e\fR" 4
+.IX Item "5206e : 5206e"
+.IP "\fB5208\fR : \fB5207\fR \fB5208\fR" 4
+.IX Item "5208 : 5207 5208"
+.IP "\fB5211a\fR : \fB5210a\fR \fB5211a\fR" 4
+.IX Item "5211a : 5210a 5211a"
+.IP "\fB5213\fR : \fB5211\fR \fB5212\fR \fB5213\fR" 4
+.IX Item "5213 : 5211 5212 5213"
+.IP "\fB5216\fR : \fB5214\fR \fB5216\fR" 4
+.IX Item "5216 : 5214 5216"
+.IP "\fB52235\fR : \fB52230\fR \fB52231\fR \fB52232\fR \fB52233\fR \fB52234\fR \fB52235\fR" 4
+.IX Item "52235 : 52230 52231 52232 52233 52234 52235"
+.IP "\fB5225\fR : \fB5224\fR \fB5225\fR" 4
+.IX Item "5225 : 5224 5225"
+.IP "\fB52259\fR : \fB52252\fR \fB52254\fR \fB52255\fR \fB52256\fR \fB52258\fR \fB52259\fR" 4
+.IX Item "52259 : 52252 52254 52255 52256 52258 52259"
+.IP "\fB5235\fR : \fB5232\fR \fB5233\fR \fB5234\fR \fB5235\fR \fB523x\fR" 4
+.IX Item "5235 : 5232 5233 5234 5235 523x"
+.IP "\fB5249\fR : \fB5249\fR" 4
+.IX Item "5249 : 5249"
+.IP "\fB5250\fR : \fB5250\fR" 4
+.IX Item "5250 : 5250"
+.IP "\fB5271\fR : \fB5270\fR \fB5271\fR" 4
+.IX Item "5271 : 5270 5271"
+.IP "\fB5272\fR : \fB5272\fR" 4
+.IX Item "5272 : 5272"
+.IP "\fB5275\fR : \fB5274\fR \fB5275\fR" 4
+.IX Item "5275 : 5274 5275"
+.IP "\fB5282\fR : \fB5280\fR \fB5281\fR \fB5282\fR \fB528x\fR" 4
+.IX Item "5282 : 5280 5281 5282 528x"
+.IP "\fB53017\fR : \fB53011\fR \fB53012\fR \fB53013\fR \fB53014\fR \fB53015\fR \fB53016\fR \fB53017\fR" 4
+.IX Item "53017 : 53011 53012 53013 53014 53015 53016 53017"
+.IP "\fB5307\fR : \fB5307\fR" 4
+.IX Item "5307 : 5307"
+.IP "\fB5329\fR : \fB5327\fR \fB5328\fR \fB5329\fR \fB532x\fR" 4
+.IX Item "5329 : 5327 5328 5329 532x"
+.IP "\fB5373\fR : \fB5372\fR \fB5373\fR \fB537x\fR" 4
+.IX Item "5373 : 5372 5373 537x"
+.IP "\fB5407\fR : \fB5407\fR" 4
+.IX Item "5407 : 5407"
+.IP "\fB5475\fR : \fB5470\fR \fB5471\fR \fB5472\fR \fB5473\fR \fB5474\fR \fB5475\fR \fB547x\fR \fB5480\fR \fB5481\fR \fB5482\fR \fB5483\fR \fB5484\fR \fB5485\fR" 4
+.IX Item "5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485"
+.RE
+.RS 4
+.PD
+.Sp
+\&\fB\-mcpu=\fR\fIcpu\fR overrides \fB\-march=\fR\fIarch\fR if
+\&\fIarch\fR is compatible with \fIcpu\fR.  Other combinations of
+\&\fB\-mcpu\fR and \fB\-march\fR are rejected.
+.Sp
+\&\s-1GCC\s0 defines the macro \fB_\|_mcf_cpu_\fR\fIcpu\fR when ColdFire target
+\&\fIcpu\fR is selected.  It also defines \fB_\|_mcf_family_\fR\fIfamily\fR,
+where the value of \fIfamily\fR is given by the table above.
+.RE
+.IP "\fB\-mtune=\fR\fItune\fR" 4
+.IX Item "-mtune=tune"
+Tune the code for a particular microarchitecture within the
+constraints set by \fB\-march\fR and \fB\-mcpu\fR.
+The M680x0 microarchitectures are: \fB68000\fR, \fB68010\fR,
+\&\fB68020\fR, \fB68030\fR, \fB68040\fR, \fB68060\fR
+and \fBcpu32\fR.  The ColdFire microarchitectures
+are: \fBcfv1\fR, \fBcfv2\fR, \fBcfv3\fR, \fBcfv4\fR and \fBcfv4e\fR.
+.Sp
+You can also use \fB\-mtune=68020\-40\fR for code that needs
+to run relatively well on 68020, 68030 and 68040 targets.
+\&\fB\-mtune=68020\-60\fR is similar but includes 68060 targets
+as well.  These two options select the same tuning decisions as
+\&\fB\-m68020\-40\fR and \fB\-m68020\-60\fR respectively.
+.Sp
+\&\s-1GCC\s0 defines the macros \fB_\|_mc\fR\fIarch\fR and \fB_\|_mc\fR\fIarch\fR\fB_\|_\fR
+when tuning for 680x0 architecture \fIarch\fR.  It also defines
+\&\fBmc\fR\fIarch\fR unless either \fB\-ansi\fR or a non-GNU \fB\-std\fR
+option is used.  If \s-1GCC\s0 is tuning for a range of architectures,
+as selected by \fB\-mtune=68020\-40\fR or \fB\-mtune=68020\-60\fR,
+it defines the macros for every architecture in the range.
+.Sp
+\&\s-1GCC\s0 also defines the macro \fB_\|_m\fR\fIuarch\fR\fB_\|_\fR when tuning for
+ColdFire microarchitecture \fIuarch\fR, where \fIuarch\fR is one
+of the arguments given above.
+.IP "\fB\-m68000\fR" 4
+.IX Item "-m68000"
+.PD 0
+.IP "\fB\-mc68000\fR" 4
+.IX Item "-mc68000"
+.PD
+Generate output for a 68000.  This is the default
+when the compiler is configured for 68000\-based systems.
+It is equivalent to \fB\-march=68000\fR.
+.Sp
+Use this option for microcontrollers with a 68000 or \s-1EC000\s0 core,
+including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
+.IP "\fB\-m68010\fR" 4
+.IX Item "-m68010"
+Generate output for a 68010.  This is the default
+when the compiler is configured for 68010\-based systems.
+It is equivalent to \fB\-march=68010\fR.
+.IP "\fB\-m68020\fR" 4
+.IX Item "-m68020"
+.PD 0
+.IP "\fB\-mc68020\fR" 4
+.IX Item "-mc68020"
+.PD
+Generate output for a 68020.  This is the default
+when the compiler is configured for 68020\-based systems.
+It is equivalent to \fB\-march=68020\fR.
+.IP "\fB\-m68030\fR" 4
+.IX Item "-m68030"
+Generate output for a 68030.  This is the default when the compiler is
+configured for 68030\-based systems.  It is equivalent to
+\&\fB\-march=68030\fR.
+.IP "\fB\-m68040\fR" 4
+.IX Item "-m68040"
+Generate output for a 68040.  This is the default when the compiler is
+configured for 68040\-based systems.  It is equivalent to
+\&\fB\-march=68040\fR.
+.Sp
+This option inhibits the use of 68881/68882 instructions that have to be
+emulated by software on the 68040.  Use this option if your 68040 does not
+have code to emulate those instructions.
+.IP "\fB\-m68060\fR" 4
+.IX Item "-m68060"
+Generate output for a 68060.  This is the default when the compiler is
+configured for 68060\-based systems.  It is equivalent to
+\&\fB\-march=68060\fR.
+.Sp
+This option inhibits the use of 68020 and 68881/68882 instructions that
+have to be emulated by software on the 68060.  Use this option if your 68060
+does not have code to emulate those instructions.
+.IP "\fB\-mcpu32\fR" 4
+.IX Item "-mcpu32"
+Generate output for a \s-1CPU32. \s0 This is the default
+when the compiler is configured for CPU32\-based systems.
+It is equivalent to \fB\-march=cpu32\fR.
+.Sp
+Use this option for microcontrollers with a
+\&\s-1CPU32\s0 or \s-1CPU32+\s0 core, including the 68330, 68331, 68332, 68333, 68334,
+68336, 68340, 68341, 68349 and 68360.
+.IP "\fB\-m5200\fR" 4
+.IX Item "-m5200"
+Generate output for a 520X ColdFire \s-1CPU. \s0 This is the default
+when the compiler is configured for 520X\-based systems.
+It is equivalent to \fB\-mcpu=5206\fR, and is now deprecated
+in favor of that option.
+.Sp
+Use this option for microcontroller with a 5200 core, including
+the \s-1MCF5202, MCF5203, MCF5204\s0 and \s-1MCF5206.\s0
+.IP "\fB\-m5206e\fR" 4
+.IX Item "-m5206e"
+Generate output for a 5206e ColdFire \s-1CPU. \s0 The option is now
+deprecated in favor of the equivalent \fB\-mcpu=5206e\fR.
+.IP "\fB\-m528x\fR" 4
+.IX Item "-m528x"
+Generate output for a member of the ColdFire 528X family.
+The option is now deprecated in favor of the equivalent
+\&\fB\-mcpu=528x\fR.
+.IP "\fB\-m5307\fR" 4
+.IX Item "-m5307"
+Generate output for a ColdFire 5307 \s-1CPU. \s0 The option is now deprecated
+in favor of the equivalent \fB\-mcpu=5307\fR.
+.IP "\fB\-m5407\fR" 4
+.IX Item "-m5407"
+Generate output for a ColdFire 5407 \s-1CPU. \s0 The option is now deprecated
+in favor of the equivalent \fB\-mcpu=5407\fR.
+.IP "\fB\-mcfv4e\fR" 4
+.IX Item "-mcfv4e"
+Generate output for a ColdFire V4e family \s-1CPU \s0(e.g. 547x/548x).
+This includes use of hardware floating-point instructions.
+The option is equivalent to \fB\-mcpu=547x\fR, and is now
+deprecated in favor of that option.
+.IP "\fB\-m68020\-40\fR" 4
+.IX Item "-m68020-40"
+Generate output for a 68040, without using any of the new instructions.
+This results in code that can run relatively efficiently on either a
+68020/68881 or a 68030 or a 68040.  The generated code does use the
+68881 instructions that are emulated on the 68040.
+.Sp
+The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-40\fR.
+.IP "\fB\-m68020\-60\fR" 4
+.IX Item "-m68020-60"
+Generate output for a 68060, without using any of the new instructions.
+This results in code that can run relatively efficiently on either a
+68020/68881 or a 68030 or a 68040.  The generated code does use the
+68881 instructions that are emulated on the 68060.
+.Sp
+The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-60\fR.
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD 0
+.IP "\fB\-m68881\fR" 4
+.IX Item "-m68881"
+.PD
+Generate floating-point instructions.  This is the default for 68020
+and above, and for ColdFire devices that have an \s-1FPU. \s0 It defines the
+macro \fB_\|_HAVE_68881_\|_\fR on M680x0 targets and \fB_\|_mcffpu_\|_\fR
+on ColdFire targets.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Do not generate floating-point instructions; use library calls instead.
+This is the default for 68000, 68010, and 68832 targets.  It is also
+the default for ColdFire devices that have no \s-1FPU.\s0
+.IP "\fB\-mdiv\fR" 4
+.IX Item "-mdiv"
+.PD 0
+.IP "\fB\-mno\-div\fR" 4
+.IX Item "-mno-div"
+.PD
+Generate (do not generate) ColdFire hardware divide and remainder
+instructions.  If \fB\-march\fR is used without \fB\-mcpu\fR,
+the default is \*(L"on\*(R" for ColdFire architectures and \*(L"off\*(R" for M680x0
+architectures.  Otherwise, the default is taken from the target \s-1CPU
+\&\s0(either the default \s-1CPU,\s0 or the one specified by \fB\-mcpu\fR).  For
+example, the default is \*(L"off\*(R" for \fB\-mcpu=5206\fR and \*(L"on\*(R" for
+\&\fB\-mcpu=5206e\fR.
+.Sp
+\&\s-1GCC\s0 defines the macro \fB_\|_mcfhwdiv_\|_\fR when this option is enabled.
+.IP "\fB\-mshort\fR" 4
+.IX Item "-mshort"
+Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
+Additionally, parameters passed on the stack are also aligned to a
+16\-bit boundary even on targets whose \s-1API\s0 mandates promotion to 32\-bit.
+.IP "\fB\-mno\-short\fR" 4
+.IX Item "-mno-short"
+Do not consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide.  This is the default.
+.IP "\fB\-mnobitfield\fR" 4
+.IX Item "-mnobitfield"
+.PD 0
+.IP "\fB\-mno\-bitfield\fR" 4
+.IX Item "-mno-bitfield"
+.PD
+Do not use the bit-field instructions.  The \fB\-m68000\fR, \fB\-mcpu32\fR
+and \fB\-m5200\fR options imply \fB\-mnobitfield\fR.
+.IP "\fB\-mbitfield\fR" 4
+.IX Item "-mbitfield"
+Do use the bit-field instructions.  The \fB\-m68020\fR option implies
+\&\fB\-mbitfield\fR.  This is the default if you use a configuration
+designed for a 68020.
+.IP "\fB\-mrtd\fR" 4
+.IX Item "-mrtd"
+Use a different function-calling convention, in which functions
+that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR
+instruction, which pops their arguments while returning.  This
+saves one instruction in the caller since there is no need to pop
+the arguments there.
+.Sp
+This calling convention is incompatible with the one normally
+used on Unix, so you cannot use it if you need to call libraries
+compiled with the Unix compiler.
+.Sp
+Also, you must provide function prototypes for all functions that
+take variable numbers of arguments (including \f(CW\*(C`printf\*(C'\fR);
+otherwise incorrect code is generated for calls to those
+functions.
+.Sp
+In addition, seriously incorrect code results if you call a
+function with too many arguments.  (Normally, extra arguments are
+harmlessly ignored.)
+.Sp
+The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030,
+68040, 68060 and \s-1CPU32\s0 processors, but not by the 68000 or 5200.
+.IP "\fB\-mno\-rtd\fR" 4
+.IX Item "-mno-rtd"
+Do not use the calling conventions selected by \fB\-mrtd\fR.
+This is the default.
+.IP "\fB\-malign\-int\fR" 4
+.IX Item "-malign-int"
+.PD 0
+.IP "\fB\-mno\-align\-int\fR" 4
+.IX Item "-mno-align-int"
+.PD
+Control whether \s-1GCC\s0 aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR,
+\&\f(CW\*(C`float\*(C'\fR, \f(CW\*(C`double\*(C'\fR, and \f(CW\*(C`long double\*(C'\fR variables on a 32\-bit
+boundary (\fB\-malign\-int\fR) or a 16\-bit boundary (\fB\-mno\-align\-int\fR).
+Aligning variables on 32\-bit boundaries produces code that runs somewhat
+faster on processors with 32\-bit busses at the expense of more memory.
+.Sp
+\&\fBWarning:\fR if you use the \fB\-malign\-int\fR switch, \s-1GCC\s0
+aligns structures containing the above types differently than
+most published application binary interface specifications for the m68k.
+.IP "\fB\-mpcrel\fR" 4
+.IX Item "-mpcrel"
+Use the pc-relative addressing mode of the 68000 directly, instead of
+using a global offset table.  At present, this option implies \fB\-fpic\fR,
+allowing at most a 16\-bit offset for pc-relative addressing.  \fB\-fPIC\fR is
+not presently supported with \fB\-mpcrel\fR, though this could be supported for
+68020 and higher processors.
+.IP "\fB\-mno\-strict\-align\fR" 4
+.IX Item "-mno-strict-align"
+.PD 0
+.IP "\fB\-mstrict\-align\fR" 4
+.IX Item "-mstrict-align"
+.PD
+Do not (do) assume that unaligned memory references are handled by
+the system.
+.IP "\fB\-msep\-data\fR" 4
+.IX Item "-msep-data"
+Generate code that allows the data segment to be located in a different
+area of memory from the text segment.  This allows for execute-in-place in
+an environment without virtual memory management.  This option implies
+\&\fB\-fPIC\fR.
+.IP "\fB\-mno\-sep\-data\fR" 4
+.IX Item "-mno-sep-data"
+Generate code that assumes that the data segment follows the text segment.
+This is the default.
+.IP "\fB\-mid\-shared\-library\fR" 4
+.IX Item "-mid-shared-library"
+Generate code that supports shared libraries via the library \s-1ID\s0 method.
+This allows for execute-in-place and shared libraries in an environment
+without virtual memory management.  This option implies \fB\-fPIC\fR.
+.IP "\fB\-mno\-id\-shared\-library\fR" 4
+.IX Item "-mno-id-shared-library"
+Generate code that doesn't assume ID-based shared libraries are being used.
+This is the default.
+.IP "\fB\-mshared\-library\-id=n\fR" 4
+.IX Item "-mshared-library-id=n"
+Specifies the identification number of the ID-based shared library being
+compiled.  Specifying a value of 0 generates more compact code; specifying
+other values forces the allocation of that number to the current
+library, but is no more space\- or time-efficient than omitting this option.
+.IP "\fB\-mxgot\fR" 4
+.IX Item "-mxgot"
+.PD 0
+.IP "\fB\-mno\-xgot\fR" 4
+.IX Item "-mno-xgot"
+.PD
+When generating position-independent code for ColdFire, generate code
+that works if the \s-1GOT\s0 has more than 8192 entries.  This code is
+larger and slower than code generated without this option.  On M680x0
+processors, this option is not needed; \fB\-fPIC\fR suffices.
+.Sp
+\&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT.\s0
+While this is relatively efficient, it only works if the \s-1GOT\s0
+is smaller than about 64k.  Anything larger causes the linker
+to report an error such as:
+.Sp
+.Vb 1
+\&        relocation truncated to fit: R_68K_GOT16O foobar
+.Ve
+.Sp
+If this happens, you should recompile your code with \fB\-mxgot\fR.
+It should then work with very large GOTs.  However, code generated with
+\&\fB\-mxgot\fR is less efficient, since it takes 4 instructions to fetch
+the value of a global symbol.
+.Sp
+Note that some linkers, including newer versions of the \s-1GNU\s0 linker,
+can create multiple GOTs and sort \s-1GOT\s0 entries.  If you have such a linker,
+you should only need to use \fB\-mxgot\fR when compiling a single
+object file that accesses more than 8192 \s-1GOT\s0 entries.  Very few do.
+.Sp
+These options have no effect unless \s-1GCC\s0 is generating
+position-independent code.
+.PP
+\fIMCore Options\fR
+.IX Subsection "MCore Options"
+.PP
+These are the \fB\-m\fR options defined for the Motorola M*Core
+processors.
+.IP "\fB\-mhardlit\fR" 4
+.IX Item "-mhardlit"
+.PD 0
+.IP "\fB\-mno\-hardlit\fR" 4
+.IX Item "-mno-hardlit"
+.PD
+Inline constants into the code stream if it can be done in two
+instructions or less.
+.IP "\fB\-mdiv\fR" 4
+.IX Item "-mdiv"
+.PD 0
+.IP "\fB\-mno\-div\fR" 4
+.IX Item "-mno-div"
+.PD
+Use the divide instruction.  (Enabled by default).
+.IP "\fB\-mrelax\-immediate\fR" 4
+.IX Item "-mrelax-immediate"
+.PD 0
+.IP "\fB\-mno\-relax\-immediate\fR" 4
+.IX Item "-mno-relax-immediate"
+.PD
+Allow arbitrary-sized immediates in bit operations.
+.IP "\fB\-mwide\-bitfields\fR" 4
+.IX Item "-mwide-bitfields"
+.PD 0
+.IP "\fB\-mno\-wide\-bitfields\fR" 4
+.IX Item "-mno-wide-bitfields"
+.PD
+Always treat bit-fields as \f(CW\*(C`int\*(C'\fR\-sized.
+.IP "\fB\-m4byte\-functions\fR" 4
+.IX Item "-m4byte-functions"
+.PD 0
+.IP "\fB\-mno\-4byte\-functions\fR" 4
+.IX Item "-mno-4byte-functions"
+.PD
+Force all functions to be aligned to a 4\-byte boundary.
+.IP "\fB\-mcallgraph\-data\fR" 4
+.IX Item "-mcallgraph-data"
+.PD 0
+.IP "\fB\-mno\-callgraph\-data\fR" 4
+.IX Item "-mno-callgraph-data"
+.PD
+Emit callgraph information.
+.IP "\fB\-mslow\-bytes\fR" 4
+.IX Item "-mslow-bytes"
+.PD 0
+.IP "\fB\-mno\-slow\-bytes\fR" 4
+.IX Item "-mno-slow-bytes"
+.PD
+Prefer word access when reading byte quantities.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+.PD 0
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+.PD
+Generate code for a little-endian target.
+.IP "\fB\-m210\fR" 4
+.IX Item "-m210"
+.PD 0
+.IP "\fB\-m340\fR" 4
+.IX Item "-m340"
+.PD
+Generate code for the 210 processor.
+.IP "\fB\-mno\-lsim\fR" 4
+.IX Item "-mno-lsim"
+Assume that runtime support has been provided and so omit the
+simulator library (\fIlibsim.a)\fR from the linker command line.
+.IP "\fB\-mstack\-increment=\fR\fIsize\fR" 4
+.IX Item "-mstack-increment=size"
+Set the maximum amount for a single stack increment operation.  Large
+values can increase the speed of programs that contain functions
+that need a large amount of stack space, but they can also trigger a
+segmentation fault if the stack is extended too much.  The default
+value is 0x1000.
+.PP
+\fIMeP Options\fR
+.IX Subsection "MeP Options"
+.IP "\fB\-mabsdiff\fR" 4
+.IX Item "-mabsdiff"
+Enables the \f(CW\*(C`abs\*(C'\fR instruction, which is the absolute difference
+between two registers.
+.IP "\fB\-mall\-opts\fR" 4
+.IX Item "-mall-opts"
+Enables all the optional instructions\-\-\-average, multiply, divide, bit
+operations, leading zero, absolute difference, min/max, clip, and
+saturation.
+.IP "\fB\-maverage\fR" 4
+.IX Item "-maverage"
+Enables the \f(CW\*(C`ave\*(C'\fR instruction, which computes the average of two
+registers.
+.IP "\fB\-mbased=\fR\fIn\fR" 4
+.IX Item "-mbased=n"
+Variables of size \fIn\fR bytes or smaller are placed in the
+\&\f(CW\*(C`.based\*(C'\fR section by default.  Based variables use the \f(CW$tp\fR
+register as a base register, and there is a 128\-byte limit to the
+\&\f(CW\*(C`.based\*(C'\fR section.
+.IP "\fB\-mbitops\fR" 4
+.IX Item "-mbitops"
+Enables the bit operation instructions\-\-\-bit test (\f(CW\*(C`btstm\*(C'\fR), set
+(\f(CW\*(C`bsetm\*(C'\fR), clear (\f(CW\*(C`bclrm\*(C'\fR), invert (\f(CW\*(C`bnotm\*(C'\fR), and
+test-and-set (\f(CW\*(C`tas\*(C'\fR).
+.IP "\fB\-mc=\fR\fIname\fR" 4
+.IX Item "-mc=name"
+Selects which section constant data is placed in.  \fIname\fR may
+be \f(CW\*(C`tiny\*(C'\fR, \f(CW\*(C`near\*(C'\fR, or \f(CW\*(C`far\*(C'\fR.
+.IP "\fB\-mclip\fR" 4
+.IX Item "-mclip"
+Enables the \f(CW\*(C`clip\*(C'\fR instruction.  Note that \f(CW\*(C`\-mclip\*(C'\fR is not
+useful unless you also provide \f(CW\*(C`\-mminmax\*(C'\fR.
+.IP "\fB\-mconfig=\fR\fIname\fR" 4
+.IX Item "-mconfig=name"
+Selects one of the built-in core configurations.  Each MeP chip has
+one or more modules in it; each module has a core \s-1CPU\s0 and a variety of
+coprocessors, optional instructions, and peripherals.  The
+\&\f(CW\*(C`MeP\-Integrator\*(C'\fR tool, not part of \s-1GCC,\s0 provides these
+configurations through this option; using this option is the same as
+using all the corresponding command-line options.  The default
+configuration is \f(CW\*(C`default\*(C'\fR.
+.IP "\fB\-mcop\fR" 4
+.IX Item "-mcop"
+Enables the coprocessor instructions.  By default, this is a 32\-bit
+coprocessor.  Note that the coprocessor is normally enabled via the
+\&\f(CW\*(C`\-mconfig=\*(C'\fR option.
+.IP "\fB\-mcop32\fR" 4
+.IX Item "-mcop32"
+Enables the 32\-bit coprocessor's instructions.
+.IP "\fB\-mcop64\fR" 4
+.IX Item "-mcop64"
+Enables the 64\-bit coprocessor's instructions.
+.IP "\fB\-mivc2\fR" 4
+.IX Item "-mivc2"
+Enables \s-1IVC2\s0 scheduling.  \s-1IVC2\s0 is a 64\-bit \s-1VLIW\s0 coprocessor.
+.IP "\fB\-mdc\fR" 4
+.IX Item "-mdc"
+Causes constant variables to be placed in the \f(CW\*(C`.near\*(C'\fR section.
+.IP "\fB\-mdiv\fR" 4
+.IX Item "-mdiv"
+Enables the \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions.
+.IP "\fB\-meb\fR" 4
+.IX Item "-meb"
+Generate big-endian code.
+.IP "\fB\-mel\fR" 4
+.IX Item "-mel"
+Generate little-endian code.
+.IP "\fB\-mio\-volatile\fR" 4
+.IX Item "-mio-volatile"
+Tells the compiler that any variable marked with the \f(CW\*(C`io\*(C'\fR
+attribute is to be considered volatile.
+.IP "\fB\-ml\fR" 4
+.IX Item "-ml"
+Causes variables to be assigned to the \f(CW\*(C`.far\*(C'\fR section by default.
+.IP "\fB\-mleadz\fR" 4
+.IX Item "-mleadz"
+Enables the \f(CW\*(C`leadz\*(C'\fR (leading zero) instruction.
+.IP "\fB\-mm\fR" 4
+.IX Item "-mm"
+Causes variables to be assigned to the \f(CW\*(C`.near\*(C'\fR section by default.
+.IP "\fB\-mminmax\fR" 4
+.IX Item "-mminmax"
+Enables the \f(CW\*(C`min\*(C'\fR and \f(CW\*(C`max\*(C'\fR instructions.
+.IP "\fB\-mmult\fR" 4
+.IX Item "-mmult"
+Enables the multiplication and multiply-accumulate instructions.
+.IP "\fB\-mno\-opts\fR" 4
+.IX Item "-mno-opts"
+Disables all the optional instructions enabled by \f(CW\*(C`\-mall\-opts\*(C'\fR.
+.IP "\fB\-mrepeat\fR" 4
+.IX Item "-mrepeat"
+Enables the \f(CW\*(C`repeat\*(C'\fR and \f(CW\*(C`erepeat\*(C'\fR instructions, used for
+low-overhead looping.
+.IP "\fB\-ms\fR" 4
+.IX Item "-ms"
+Causes all variables to default to the \f(CW\*(C`.tiny\*(C'\fR section.  Note
+that there is a 65536\-byte limit to this section.  Accesses to these
+variables use the \f(CW%gp\fR base register.
+.IP "\fB\-msatur\fR" 4
+.IX Item "-msatur"
+Enables the saturation instructions.  Note that the compiler does not
+currently generate these itself, but this option is included for
+compatibility with other tools, like \f(CW\*(C`as\*(C'\fR.
+.IP "\fB\-msdram\fR" 4
+.IX Item "-msdram"
+Link the SDRAM-based runtime instead of the default ROM-based runtime.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Link the simulator run-time libraries.
+.IP "\fB\-msimnovec\fR" 4
+.IX Item "-msimnovec"
+Link the simulator runtime libraries, excluding built-in support
+for reset and exception vectors and tables.
+.IP "\fB\-mtf\fR" 4
+.IX Item "-mtf"
+Causes all functions to default to the \f(CW\*(C`.far\*(C'\fR section.  Without
+this option, functions default to the \f(CW\*(C`.near\*(C'\fR section.
+.IP "\fB\-mtiny=\fR\fIn\fR" 4
+.IX Item "-mtiny=n"
+Variables that are \fIn\fR bytes or smaller are allocated to the
+\&\f(CW\*(C`.tiny\*(C'\fR section.  These variables use the \f(CW$gp\fR base
+register.  The default for this option is 4, but note that there's a
+65536\-byte limit to the \f(CW\*(C`.tiny\*(C'\fR section.
+.PP
+\fIMicroBlaze Options\fR
+.IX Subsection "MicroBlaze Options"
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Use software emulation for floating point (default).
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+Use hardware floating-point instructions.
+.IP "\fB\-mmemcpy\fR" 4
+.IX Item "-mmemcpy"
+Do not optimize block moves, use \f(CW\*(C`memcpy\*(C'\fR.
+.IP "\fB\-mno\-clearbss\fR" 4
+.IX Item "-mno-clearbss"
+This option is deprecated.  Use \fB\-fno\-zero\-initialized\-in\-bss\fR instead.
+.IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
+.IX Item "-mcpu=cpu-type"
+Use features of, and schedule code for, the given \s-1CPU.\s0
+Supported values are in the format \fBv\fR\fIX\fR\fB.\fR\fI\s-1YY\s0\fR\fB.\fR\fIZ\fR,
+where \fIX\fR is a major version, \fI\s-1YY\s0\fR is the minor version, and
+\&\fIZ\fR is compatibility code.  Example values are \fBv3.00.a\fR,
+\&\fBv4.00.b\fR, \fBv5.00.a\fR, \fBv5.00.b\fR, \fBv5.00.b\fR, \fBv6.00.a\fR.
+.IP "\fB\-mxl\-soft\-mul\fR" 4
+.IX Item "-mxl-soft-mul"
+Use software multiply emulation (default).
+.IP "\fB\-mxl\-soft\-div\fR" 4
+.IX Item "-mxl-soft-div"
+Use software emulation for divides (default).
+.IP "\fB\-mxl\-barrel\-shift\fR" 4
+.IX Item "-mxl-barrel-shift"
+Use the hardware barrel shifter.
+.IP "\fB\-mxl\-pattern\-compare\fR" 4
+.IX Item "-mxl-pattern-compare"
+Use pattern compare instructions.
+.IP "\fB\-msmall\-divides\fR" 4
+.IX Item "-msmall-divides"
+Use table lookup optimization for small signed integer divisions.
+.IP "\fB\-mxl\-stack\-check\fR" 4
+.IX Item "-mxl-stack-check"
+This option is deprecated.  Use \fB\-fstack\-check\fR instead.
+.IP "\fB\-mxl\-gp\-opt\fR" 4
+.IX Item "-mxl-gp-opt"
+Use GP-relative \f(CW\*(C`.sdata\*(C'\fR/\f(CW\*(C`.sbss\*(C'\fR sections.
+.IP "\fB\-mxl\-multiply\-high\fR" 4
+.IX Item "-mxl-multiply-high"
+Use multiply high instructions for high part of 32x32 multiply.
+.IP "\fB\-mxl\-float\-convert\fR" 4
+.IX Item "-mxl-float-convert"
+Use hardware floating-point conversion instructions.
+.IP "\fB\-mxl\-float\-sqrt\fR" 4
+.IX Item "-mxl-float-sqrt"
+Use hardware floating-point square root instruction.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code for a big-endian target.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code for a little-endian target.
+.IP "\fB\-mxl\-reorder\fR" 4
+.IX Item "-mxl-reorder"
+Use reorder instructions (swap and byte reversed load/store).
+.IP "\fB\-mxl\-mode\-\fR\fIapp-model\fR" 4
+.IX Item "-mxl-mode-app-model"
+Select application model \fIapp-model\fR.  Valid models are
+.RS 4
+.IP "\fBexecutable\fR" 4
+.IX Item "executable"
+normal executable (default), uses startup code \fIcrt0.o\fR.
+.IP "\fBxmdstub\fR" 4
+.IX Item "xmdstub"
+for use with Xilinx Microprocessor Debugger (\s-1XMD\s0) based
+software intrusive debug agent called xmdstub. This uses startup file
+\&\fIcrt1.o\fR and sets the start address of the program to 0x800.
+.IP "\fBbootstrap\fR" 4
+.IX Item "bootstrap"
+for applications that are loaded using a bootloader.
+This model uses startup file \fIcrt2.o\fR which does not contain a processor
+reset vector handler. This is suitable for transferring control on a
+processor reset to the bootloader rather than the application.
+.IP "\fBnovectors\fR" 4
+.IX Item "novectors"
+for applications that do not require any of the
+MicroBlaze vectors. This option may be useful for applications running
+within a monitoring application. This model uses \fIcrt3.o\fR as a startup file.
+.RE
+.RS 4
+.Sp
+Option \fB\-xl\-mode\-\fR\fIapp-model\fR is a deprecated alias for
+\&\fB\-mxl\-mode\-\fR\fIapp-model\fR.
+.RE
+.PP
+\fI\s-1MIPS\s0 Options\fR
+.IX Subsection "MIPS Options"
+.IP "\fB\-EB\fR" 4
+.IX Item "-EB"
+Generate big-endian code.
+.IP "\fB\-EL\fR" 4
+.IX Item "-EL"
+Generate little-endian code.  This is the default for \fBmips*el\-*\-*\fR
+configurations.
+.IP "\fB\-march=\fR\fIarch\fR" 4
+.IX Item "-march=arch"
+Generate code that runs on \fIarch\fR, which can be the name of a
+generic \s-1MIPS ISA,\s0 or the name of a particular processor.
+The \s-1ISA\s0 names are:
+\&\fBmips1\fR, \fBmips2\fR, \fBmips3\fR, \fBmips4\fR,
+\&\fBmips32\fR, \fBmips32r2\fR, \fBmips64\fR and \fBmips64r2\fR.
+The processor names are:
+\&\fB4kc\fR, \fB4km\fR, \fB4kp\fR, \fB4ksc\fR,
+\&\fB4kec\fR, \fB4kem\fR, \fB4kep\fR, \fB4ksd\fR,
+\&\fB5kc\fR, \fB5kf\fR,
+\&\fB20kc\fR,
+\&\fB24kc\fR, \fB24kf2_1\fR, \fB24kf1_1\fR,
+\&\fB24kec\fR, \fB24kef2_1\fR, \fB24kef1_1\fR,
+\&\fB34kc\fR, \fB34kf2_1\fR, \fB34kf1_1\fR, \fB34kn\fR,
+\&\fB74kc\fR, \fB74kf2_1\fR, \fB74kf1_1\fR, \fB74kf3_2\fR,
+\&\fB1004kc\fR, \fB1004kf2_1\fR, \fB1004kf1_1\fR,
+\&\fBloongson2e\fR, \fBloongson2f\fR, \fBloongson3a\fR,
+\&\fBm4k\fR,
+\&\fBm14k\fR, \fBm14kc\fR, \fBm14ke\fR, \fBm14kec\fR,
+\&\fBocteon\fR, \fBocteon+\fR, \fBocteon2\fR,
+\&\fBorion\fR,
+\&\fBr2000\fR, \fBr3000\fR, \fBr3900\fR, \fBr4000\fR, \fBr4400\fR,
+\&\fBr4600\fR, \fBr4650\fR, \fBr4700\fR, \fBr6000\fR, \fBr8000\fR,
+\&\fBrm7000\fR, \fBrm9000\fR,
+\&\fBr10000\fR, \fBr12000\fR, \fBr14000\fR, \fBr16000\fR,
+\&\fBsb1\fR,
+\&\fBsr71000\fR,
+\&\fBvr4100\fR, \fBvr4111\fR, \fBvr4120\fR, \fBvr4130\fR, \fBvr4300\fR,
+\&\fBvr5000\fR, \fBvr5400\fR, \fBvr5500\fR,
+\&\fBxlr\fR and \fBxlp\fR.
+The special value \fBfrom-abi\fR selects the
+most compatible architecture for the selected \s-1ABI \s0(that is,
+\&\fBmips1\fR for 32\-bit ABIs and \fBmips3\fR for 64\-bit ABIs).
+.Sp
+The native Linux/GNU toolchain also supports the value \fBnative\fR,
+which selects the best architecture option for the host processor.
+\&\fB\-march=native\fR has no effect if \s-1GCC\s0 does not recognize
+the processor.
+.Sp
+In processor names, a final \fB000\fR can be abbreviated as \fBk\fR
+(for example, \fB\-march=r2k\fR).  Prefixes are optional, and
+\&\fBvr\fR may be written \fBr\fR.
+.Sp
+Names of the form \fIn\fR\fBf2_1\fR refer to processors with
+FPUs clocked at half the rate of the core, names of the form
+\&\fIn\fR\fBf1_1\fR refer to processors with FPUs clocked at the same
+rate as the core, and names of the form \fIn\fR\fBf3_2\fR refer to
+processors with FPUs clocked a ratio of 3:2 with respect to the core.
+For compatibility reasons, \fIn\fR\fBf\fR is accepted as a synonym
+for \fIn\fR\fBf2_1\fR while \fIn\fR\fBx\fR and \fIb\fR\fBfx\fR are
+accepted as synonyms for \fIn\fR\fBf1_1\fR.
+.Sp
+\&\s-1GCC\s0 defines two macros based on the value of this option.  The first
+is \fB_MIPS_ARCH\fR, which gives the name of target architecture, as
+a string.  The second has the form \fB_MIPS_ARCH_\fR\fIfoo\fR,
+where \fIfoo\fR is the capitalized value of \fB_MIPS_ARCH\fR.
+For example, \fB\-march=r2000\fR sets \fB_MIPS_ARCH\fR
+to \fB\*(L"r2000\*(R"\fR and defines the macro \fB_MIPS_ARCH_R2000\fR.
+.Sp
+Note that the \fB_MIPS_ARCH\fR macro uses the processor names given
+above.  In other words, it has the full prefix and does not
+abbreviate \fB000\fR as \fBk\fR.  In the case of \fBfrom-abi\fR,
+the macro names the resolved architecture (either \fB\*(L"mips1\*(R"\fR or
+\&\fB\*(L"mips3\*(R"\fR).  It names the default architecture when no
+\&\fB\-march\fR option is given.
+.IP "\fB\-mtune=\fR\fIarch\fR" 4
+.IX Item "-mtune=arch"
+Optimize for \fIarch\fR.  Among other things, this option controls
+the way instructions are scheduled, and the perceived cost of arithmetic
+operations.  The list of \fIarch\fR values is the same as for
+\&\fB\-march\fR.
+.Sp
+When this option is not used, \s-1GCC\s0 optimizes for the processor
+specified by \fB\-march\fR.  By using \fB\-march\fR and
+\&\fB\-mtune\fR together, it is possible to generate code that
+runs on a family of processors, but optimize the code for one
+particular member of that family.
+.Sp
+\&\fB\-mtune\fR defines the macros \fB_MIPS_TUNE\fR and
+\&\fB_MIPS_TUNE_\fR\fIfoo\fR, which work in the same way as the
+\&\fB\-march\fR ones described above.
+.IP "\fB\-mips1\fR" 4
+.IX Item "-mips1"
+Equivalent to \fB\-march=mips1\fR.
+.IP "\fB\-mips2\fR" 4
+.IX Item "-mips2"
+Equivalent to \fB\-march=mips2\fR.
+.IP "\fB\-mips3\fR" 4
+.IX Item "-mips3"
+Equivalent to \fB\-march=mips3\fR.
+.IP "\fB\-mips4\fR" 4
+.IX Item "-mips4"
+Equivalent to \fB\-march=mips4\fR.
+.IP "\fB\-mips32\fR" 4
+.IX Item "-mips32"
+Equivalent to \fB\-march=mips32\fR.
+.IP "\fB\-mips32r2\fR" 4
+.IX Item "-mips32r2"
+Equivalent to \fB\-march=mips32r2\fR.
+.IP "\fB\-mips64\fR" 4
+.IX Item "-mips64"
+Equivalent to \fB\-march=mips64\fR.
+.IP "\fB\-mips64r2\fR" 4
+.IX Item "-mips64r2"
+Equivalent to \fB\-march=mips64r2\fR.
+.IP "\fB\-mips16\fR" 4
+.IX Item "-mips16"
+.PD 0
+.IP "\fB\-mno\-mips16\fR" 4
+.IX Item "-mno-mips16"
+.PD
+Generate (do not generate) \s-1MIPS16\s0 code.  If \s-1GCC\s0 is targeting a
+\&\s-1MIPS32\s0 or \s-1MIPS64\s0 architecture, it makes use of the MIPS16e \s-1ASE.\s0
+.Sp
+\&\s-1MIPS16\s0 code generation can also be controlled on a per-function basis
+by means of \f(CW\*(C`mips16\*(C'\fR and \f(CW\*(C`nomips16\*(C'\fR attributes.
+.IP "\fB\-mflip\-mips16\fR" 4
+.IX Item "-mflip-mips16"
+Generate \s-1MIPS16\s0 code on alternating functions.  This option is provided
+for regression testing of mixed MIPS16/non\-MIPS16 code generation, and is
+not intended for ordinary use in compiling user code.
+.IP "\fB\-minterlink\-compressed\fR" 4
+.IX Item "-minterlink-compressed"
+.PD 0
+.IP "\fB\-mno\-interlink\-compressed\fR" 4
+.IX Item "-mno-interlink-compressed"
+.PD
+Require (do not require) that code using the standard (uncompressed) \s-1MIPS ISA\s0
+be link-compatible with \s-1MIPS16\s0 and microMIPS code, and vice versa.
+.Sp
+For example, code using the standard \s-1ISA\s0 encoding cannot jump directly
+to \s-1MIPS16\s0 or microMIPS code; it must either use a call or an indirect jump.
+\&\fB\-minterlink\-compressed\fR therefore disables direct jumps unless \s-1GCC\s0
+knows that the target of the jump is not compressed.
+.IP "\fB\-minterlink\-mips16\fR" 4
+.IX Item "-minterlink-mips16"
+.PD 0
+.IP "\fB\-mno\-interlink\-mips16\fR" 4
+.IX Item "-mno-interlink-mips16"
+.PD
+Aliases of \fB\-minterlink\-compressed\fR and
+\&\fB\-mno\-interlink\-compressed\fR.  These options predate the microMIPS \s-1ASE\s0
+and are retained for backwards compatibility.
+.IP "\fB\-mabi=32\fR" 4
+.IX Item "-mabi=32"
+.PD 0
+.IP "\fB\-mabi=o64\fR" 4
+.IX Item "-mabi=o64"
+.IP "\fB\-mabi=n32\fR" 4
+.IX Item "-mabi=n32"
+.IP "\fB\-mabi=64\fR" 4
+.IX Item "-mabi=64"
+.IP "\fB\-mabi=eabi\fR" 4
+.IX Item "-mabi=eabi"
+.PD
+Generate code for the given \s-1ABI.\s0
+.Sp
+Note that the \s-1EABI\s0 has a 32\-bit and a 64\-bit variant.  \s-1GCC\s0 normally
+generates 64\-bit code when you select a 64\-bit architecture, but you
+can use \fB\-mgp32\fR to get 32\-bit code instead.
+.Sp
+For information about the O64 \s-1ABI,\s0 see
+<\fBhttp://gcc.gnu.org/projects/mipso64\-abi.html\fR>.
+.Sp
+\&\s-1GCC\s0 supports a variant of the o32 \s-1ABI\s0 in which floating-point registers
+are 64 rather than 32 bits wide.  You can select this combination with
+\&\fB\-mabi=32\fR \fB\-mfp64\fR.  This \s-1ABI\s0 relies on the \f(CW\*(C`mthc1\*(C'\fR
+and \f(CW\*(C`mfhc1\*(C'\fR instructions and is therefore only supported for
+\&\s-1MIPS32R2\s0 processors.
+.Sp
+The register assignments for arguments and return values remain the
+same, but each scalar value is passed in a single 64\-bit register
+rather than a pair of 32\-bit registers.  For example, scalar
+floating-point values are returned in \fB\f(CB$f0\fB\fR only, not a
+\&\fB\f(CB$f0\fB\fR/\fB\f(CB$f1\fB\fR pair.  The set of call-saved registers also
+remains the same, but all 64 bits are saved.
+.IP "\fB\-mabicalls\fR" 4
+.IX Item "-mabicalls"
+.PD 0
+.IP "\fB\-mno\-abicalls\fR" 4
+.IX Item "-mno-abicalls"
+.PD
+Generate (do not generate) code that is suitable for SVR4\-style
+dynamic objects.  \fB\-mabicalls\fR is the default for SVR4\-based
+systems.
+.IP "\fB\-mshared\fR" 4
+.IX Item "-mshared"
+.PD 0
+.IP "\fB\-mno\-shared\fR" 4
+.IX Item "-mno-shared"
+.PD
+Generate (do not generate) code that is fully position-independent,
+and that can therefore be linked into shared libraries.  This option
+only affects \fB\-mabicalls\fR.
+.Sp
+All \fB\-mabicalls\fR code has traditionally been position-independent,
+regardless of options like \fB\-fPIC\fR and \fB\-fpic\fR.  However,
+as an extension, the \s-1GNU\s0 toolchain allows executables to use absolute
+accesses for locally-binding symbols.  It can also use shorter \s-1GP\s0
+initialization sequences and generate direct calls to locally-defined
+functions.  This mode is selected by \fB\-mno\-shared\fR.
+.Sp
+\&\fB\-mno\-shared\fR depends on binutils 2.16 or higher and generates
+objects that can only be linked by the \s-1GNU\s0 linker.  However, the option
+does not affect the \s-1ABI\s0 of the final executable; it only affects the \s-1ABI\s0
+of relocatable objects.  Using \fB\-mno\-shared\fR generally makes
+executables both smaller and quicker.
+.Sp
+\&\fB\-mshared\fR is the default.
+.IP "\fB\-mplt\fR" 4
+.IX Item "-mplt"
+.PD 0
+.IP "\fB\-mno\-plt\fR" 4
+.IX Item "-mno-plt"
+.PD
+Assume (do not assume) that the static and dynamic linkers
+support PLTs and copy relocations.  This option only affects
+\&\fB\-mno\-shared \-mabicalls\fR.  For the n64 \s-1ABI,\s0 this option
+has no effect without \fB\-msym32\fR.
+.Sp
+You can make \fB\-mplt\fR the default by configuring
+\&\s-1GCC\s0 with \fB\-\-with\-mips\-plt\fR.  The default is
+\&\fB\-mno\-plt\fR otherwise.
+.IP "\fB\-mxgot\fR" 4
+.IX Item "-mxgot"
+.PD 0
+.IP "\fB\-mno\-xgot\fR" 4
+.IX Item "-mno-xgot"
+.PD
+Lift (do not lift) the usual restrictions on the size of the global
+offset table.
+.Sp
+\&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT.\s0
+While this is relatively efficient, it only works if the \s-1GOT\s0
+is smaller than about 64k.  Anything larger causes the linker
+to report an error such as:
+.Sp
+.Vb 1
+\&        relocation truncated to fit: R_MIPS_GOT16 foobar
+.Ve
+.Sp
+If this happens, you should recompile your code with \fB\-mxgot\fR.
+This works with very large GOTs, although the code is also
+less efficient, since it takes three instructions to fetch the
+value of a global symbol.
+.Sp
+Note that some linkers can create multiple GOTs.  If you have such a
+linker, you should only need to use \fB\-mxgot\fR when a single object
+file accesses more than 64k's worth of \s-1GOT\s0 entries.  Very few do.
+.Sp
+These options have no effect unless \s-1GCC\s0 is generating position
+independent code.
+.IP "\fB\-mgp32\fR" 4
+.IX Item "-mgp32"
+Assume that general-purpose registers are 32 bits wide.
+.IP "\fB\-mgp64\fR" 4
+.IX Item "-mgp64"
+Assume that general-purpose registers are 64 bits wide.
+.IP "\fB\-mfp32\fR" 4
+.IX Item "-mfp32"
+Assume that floating-point registers are 32 bits wide.
+.IP "\fB\-mfp64\fR" 4
+.IX Item "-mfp64"
+Assume that floating-point registers are 64 bits wide.
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+Use floating-point coprocessor instructions.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Do not use floating-point coprocessor instructions.  Implement
+floating-point calculations using library calls instead.
+.IP "\fB\-mno\-float\fR" 4
+.IX Item "-mno-float"
+Equivalent to \fB\-msoft\-float\fR, but additionally asserts that the
+program being compiled does not perform any floating-point operations.
+This option is presently supported only by some bare-metal \s-1MIPS\s0
+configurations, where it may select a special set of libraries
+that lack all floating-point support (including, for example, the
+floating-point \f(CW\*(C`printf\*(C'\fR formats).  
+If code compiled with \f(CW\*(C`\-mno\-float\*(C'\fR accidentally contains
+floating-point operations, it is likely to suffer a link-time
+or run-time failure.
+.IP "\fB\-msingle\-float\fR" 4
+.IX Item "-msingle-float"
+Assume that the floating-point coprocessor only supports single-precision
+operations.
+.IP "\fB\-mdouble\-float\fR" 4
+.IX Item "-mdouble-float"
+Assume that the floating-point coprocessor supports double-precision
+operations.  This is the default.
+.IP "\fB\-mabs=2008\fR" 4
+.IX Item "-mabs=2008"
+.PD 0
+.IP "\fB\-mabs=legacy\fR" 4
+.IX Item "-mabs=legacy"
+.PD
+These options control the treatment of the special not-a-number (NaN)
+\&\s-1IEEE 754\s0 floating-point data with the \f(CW\*(C`abs.\f(CIfmt\f(CW\*(C'\fR and
+\&\f(CW\*(C`neg.\f(CIfmt\f(CW\*(C'\fR machine instructions.
+.Sp
+By default or when the \fB\-mabs=legacy\fR is used the legacy
+treatment is selected.  In this case these instructions are considered
+arithmetic and avoided where correct operation is required and the
+input operand might be a NaN.  A longer sequence of instructions that
+manipulate the sign bit of floating-point datum manually is used
+instead unless the \fB\-ffinite\-math\-only\fR option has also been
+specified.
+.Sp
+The \fB\-mabs=2008\fR option selects the \s-1IEEE 754\-2008\s0 treatment.  In
+this case these instructions are considered non-arithmetic and therefore
+operating correctly in all cases, including in particular where the
+input operand is a NaN.  These instructions are therefore always used
+for the respective operations.
+.IP "\fB\-mnan=2008\fR" 4
+.IX Item "-mnan=2008"
+.PD 0
+.IP "\fB\-mnan=legacy\fR" 4
+.IX Item "-mnan=legacy"
+.PD
+These options control the encoding of the special not-a-number (NaN)
+\&\s-1IEEE 754\s0 floating-point data.
+.Sp
+The \fB\-mnan=legacy\fR option selects the legacy encoding.  In this
+case quiet NaNs (qNaNs) are denoted by the first bit of their trailing
+significand field being 0, whereas signalling NaNs (sNaNs) are denoted
+by the first bit of their trailing significand field being 1.
+.Sp
+The \fB\-mnan=2008\fR option selects the \s-1IEEE 754\-2008\s0 encoding.  In
+this case qNaNs are denoted by the first bit of their trailing
+significand field being 1, whereas sNaNs are denoted by the first bit of
+their trailing significand field being 0.
+.Sp
+The default is \fB\-mnan=legacy\fR unless \s-1GCC\s0 has been configured with
+\&\fB\-\-with\-nan=2008\fR.
+.IP "\fB\-mllsc\fR" 4
+.IX Item "-mllsc"
+.PD 0
+.IP "\fB\-mno\-llsc\fR" 4
+.IX Item "-mno-llsc"
+.PD
+Use (do not use) \fBll\fR, \fBsc\fR, and \fBsync\fR instructions to
+implement atomic memory built-in functions.  When neither option is
+specified, \s-1GCC\s0 uses the instructions if the target architecture
+supports them.
+.Sp
+\&\fB\-mllsc\fR is useful if the runtime environment can emulate the
+instructions and \fB\-mno\-llsc\fR can be useful when compiling for
+nonstandard ISAs.  You can make either option the default by
+configuring \s-1GCC\s0 with \fB\-\-with\-llsc\fR and \fB\-\-without\-llsc\fR
+respectively.  \fB\-\-with\-llsc\fR is the default for some
+configurations; see the installation documentation for details.
+.IP "\fB\-mdsp\fR" 4
+.IX Item "-mdsp"
+.PD 0
+.IP "\fB\-mno\-dsp\fR" 4
+.IX Item "-mno-dsp"
+.PD
+Use (do not use) revision 1 of the \s-1MIPS DSP ASE.
+ \s0 This option defines the
+preprocessor macro \fB_\|_mips_dsp\fR.  It also defines
+\&\fB_\|_mips_dsp_rev\fR to 1.
+.IP "\fB\-mdspr2\fR" 4
+.IX Item "-mdspr2"
+.PD 0
+.IP "\fB\-mno\-dspr2\fR" 4
+.IX Item "-mno-dspr2"
+.PD
+Use (do not use) revision 2 of the \s-1MIPS DSP ASE.
+ \s0 This option defines the
+preprocessor macros \fB_\|_mips_dsp\fR and \fB_\|_mips_dspr2\fR.
+It also defines \fB_\|_mips_dsp_rev\fR to 2.
+.IP "\fB\-msmartmips\fR" 4
+.IX Item "-msmartmips"
+.PD 0
+.IP "\fB\-mno\-smartmips\fR" 4
+.IX Item "-mno-smartmips"
+.PD
+Use (do not use) the \s-1MIPS\s0 SmartMIPS \s-1ASE.\s0
+.IP "\fB\-mpaired\-single\fR" 4
+.IX Item "-mpaired-single"
+.PD 0
+.IP "\fB\-mno\-paired\-single\fR" 4
+.IX Item "-mno-paired-single"
+.PD
+Use (do not use) paired-single floating-point instructions.
+  This option requires
+hardware floating-point support to be enabled.
+.IP "\fB\-mdmx\fR" 4
+.IX Item "-mdmx"
+.PD 0
+.IP "\fB\-mno\-mdmx\fR" 4
+.IX Item "-mno-mdmx"
+.PD
+Use (do not use) \s-1MIPS\s0 Digital Media Extension instructions.
+This option can only be used when generating 64\-bit code and requires
+hardware floating-point support to be enabled.
+.IP "\fB\-mips3d\fR" 4
+.IX Item "-mips3d"
+.PD 0
+.IP "\fB\-mno\-mips3d\fR" 4
+.IX Item "-mno-mips3d"
+.PD
+Use (do not use) the \s-1MIPS\-3D ASE.  \s0
+The option \fB\-mips3d\fR implies \fB\-mpaired\-single\fR.
+.IP "\fB\-mmicromips\fR" 4
+.IX Item "-mmicromips"
+.PD 0
+.IP "\fB\-mno\-micromips\fR" 4
+.IX Item "-mno-micromips"
+.PD
+Generate (do not generate) microMIPS code.
+.Sp
+MicroMIPS code generation can also be controlled on a per-function basis
+by means of \f(CW\*(C`micromips\*(C'\fR and \f(CW\*(C`nomicromips\*(C'\fR attributes.
+.IP "\fB\-mmt\fR" 4
+.IX Item "-mmt"
+.PD 0
+.IP "\fB\-mno\-mt\fR" 4
+.IX Item "-mno-mt"
+.PD
+Use (do not use) \s-1MT\s0 Multithreading instructions.
+.IP "\fB\-mmcu\fR" 4
+.IX Item "-mmcu"
+.PD 0
+.IP "\fB\-mno\-mcu\fR" 4
+.IX Item "-mno-mcu"
+.PD
+Use (do not use) the \s-1MIPS MCU ASE\s0 instructions.
+.IP "\fB\-meva\fR" 4
+.IX Item "-meva"
+.PD 0
+.IP "\fB\-mno\-eva\fR" 4
+.IX Item "-mno-eva"
+.PD
+Use (do not use) the \s-1MIPS\s0 Enhanced Virtual Addressing instructions.
+.IP "\fB\-mvirt\fR" 4
+.IX Item "-mvirt"
+.PD 0
+.IP "\fB\-mno\-virt\fR" 4
+.IX Item "-mno-virt"
+.PD
+Use (do not use) the \s-1MIPS\s0 Virtualization Application Specific instructions.
+.IP "\fB\-mlong64\fR" 4
+.IX Item "-mlong64"
+Force \f(CW\*(C`long\*(C'\fR types to be 64 bits wide.  See \fB\-mlong32\fR for
+an explanation of the default and the way that the pointer size is
+determined.
+.IP "\fB\-mlong32\fR" 4
+.IX Item "-mlong32"
+Force \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`int\*(C'\fR, and pointer types to be 32 bits wide.
+.Sp
+The default size of \f(CW\*(C`int\*(C'\fRs, \f(CW\*(C`long\*(C'\fRs and pointers depends on
+the \s-1ABI. \s0 All the supported ABIs use 32\-bit \f(CW\*(C`int\*(C'\fRs.  The n64 \s-1ABI\s0
+uses 64\-bit \f(CW\*(C`long\*(C'\fRs, as does the 64\-bit \s-1EABI\s0; the others use
+32\-bit \f(CW\*(C`long\*(C'\fRs.  Pointers are the same size as \f(CW\*(C`long\*(C'\fRs,
+or the same size as integer registers, whichever is smaller.
+.IP "\fB\-msym32\fR" 4
+.IX Item "-msym32"
+.PD 0
+.IP "\fB\-mno\-sym32\fR" 4
+.IX Item "-mno-sym32"
+.PD
+Assume (do not assume) that all symbols have 32\-bit values, regardless
+of the selected \s-1ABI. \s0 This option is useful in combination with
+\&\fB\-mabi=64\fR and \fB\-mno\-abicalls\fR because it allows \s-1GCC\s0
+to generate shorter and faster references to symbolic addresses.
+.IP "\fB\-G\fR \fInum\fR" 4
+.IX Item "-G num"
+Put definitions of externally-visible data in a small data section
+if that data is no bigger than \fInum\fR bytes.  \s-1GCC\s0 can then generate
+more efficient accesses to the data; see \fB\-mgpopt\fR for details.
+.Sp
+The default \fB\-G\fR option depends on the configuration.
+.IP "\fB\-mlocal\-sdata\fR" 4
+.IX Item "-mlocal-sdata"
+.PD 0
+.IP "\fB\-mno\-local\-sdata\fR" 4
+.IX Item "-mno-local-sdata"
+.PD
+Extend (do not extend) the \fB\-G\fR behavior to local data too,
+such as to static variables in C.  \fB\-mlocal\-sdata\fR is the
+default for all configurations.
+.Sp
+If the linker complains that an application is using too much small data,
+you might want to try rebuilding the less performance-critical parts with
+\&\fB\-mno\-local\-sdata\fR.  You might also want to build large
+libraries with \fB\-mno\-local\-sdata\fR, so that the libraries leave
+more room for the main program.
+.IP "\fB\-mextern\-sdata\fR" 4
+.IX Item "-mextern-sdata"
+.PD 0
+.IP "\fB\-mno\-extern\-sdata\fR" 4
+.IX Item "-mno-extern-sdata"
+.PD
+Assume (do not assume) that externally-defined data is in
+a small data section if the size of that data is within the \fB\-G\fR limit.
+\&\fB\-mextern\-sdata\fR is the default for all configurations.
+.Sp
+If you compile a module \fIMod\fR with \fB\-mextern\-sdata\fR \fB\-G\fR
+\&\fInum\fR \fB\-mgpopt\fR, and \fIMod\fR references a variable \fIVar\fR
+that is no bigger than \fInum\fR bytes, you must make sure that \fIVar\fR
+is placed in a small data section.  If \fIVar\fR is defined by another
+module, you must either compile that module with a high-enough
+\&\fB\-G\fR setting or attach a \f(CW\*(C`section\*(C'\fR attribute to \fIVar\fR's
+definition.  If \fIVar\fR is common, you must link the application
+with a high-enough \fB\-G\fR setting.
+.Sp
+The easiest way of satisfying these restrictions is to compile
+and link every module with the same \fB\-G\fR option.  However,
+you may wish to build a library that supports several different
+small data limits.  You can do this by compiling the library with
+the highest supported \fB\-G\fR setting and additionally using
+\&\fB\-mno\-extern\-sdata\fR to stop the library from making assumptions
+about externally-defined data.
+.IP "\fB\-mgpopt\fR" 4
+.IX Item "-mgpopt"
+.PD 0
+.IP "\fB\-mno\-gpopt\fR" 4
+.IX Item "-mno-gpopt"
+.PD
+Use (do not use) GP-relative accesses for symbols that are known to be
+in a small data section; see \fB\-G\fR, \fB\-mlocal\-sdata\fR and
+\&\fB\-mextern\-sdata\fR.  \fB\-mgpopt\fR is the default for all
+configurations.
+.Sp
+\&\fB\-mno\-gpopt\fR is useful for cases where the \f(CW$gp\fR register
+might not hold the value of \f(CW\*(C`_gp\*(C'\fR.  For example, if the code is
+part of a library that might be used in a boot monitor, programs that
+call boot monitor routines pass an unknown value in \f(CW$gp\fR.
+(In such situations, the boot monitor itself is usually compiled
+with \fB\-G0\fR.)
+.Sp
+\&\fB\-mno\-gpopt\fR implies \fB\-mno\-local\-sdata\fR and
+\&\fB\-mno\-extern\-sdata\fR.
+.IP "\fB\-membedded\-data\fR" 4
+.IX Item "-membedded-data"
+.PD 0
+.IP "\fB\-mno\-embedded\-data\fR" 4
+.IX Item "-mno-embedded-data"
+.PD
+Allocate variables to the read-only data section first if possible, then
+next in the small data section if possible, otherwise in data.  This gives
+slightly slower code than the default, but reduces the amount of \s-1RAM\s0 required
+when executing, and thus may be preferred for some embedded systems.
+.IP "\fB\-muninit\-const\-in\-rodata\fR" 4
+.IX Item "-muninit-const-in-rodata"
+.PD 0
+.IP "\fB\-mno\-uninit\-const\-in\-rodata\fR" 4
+.IX Item "-mno-uninit-const-in-rodata"
+.PD
+Put uninitialized \f(CW\*(C`const\*(C'\fR variables in the read-only data section.
+This option is only meaningful in conjunction with \fB\-membedded\-data\fR.
+.IP "\fB\-mcode\-readable=\fR\fIsetting\fR" 4
+.IX Item "-mcode-readable=setting"
+Specify whether \s-1GCC\s0 may generate code that reads from executable sections.
+There are three possible settings:
+.RS 4
+.IP "\fB\-mcode\-readable=yes\fR" 4
+.IX Item "-mcode-readable=yes"
+Instructions may freely access executable sections.  This is the
+default setting.
+.IP "\fB\-mcode\-readable=pcrel\fR" 4
+.IX Item "-mcode-readable=pcrel"
+\&\s-1MIPS16\s0 PC-relative load instructions can access executable sections,
+but other instructions must not do so.  This option is useful on 4KSc
+and 4KSd processors when the code TLBs have the Read Inhibit bit set.
+It is also useful on processors that can be configured to have a dual
+instruction/data \s-1SRAM\s0 interface and that, like the M4K, automatically
+redirect PC-relative loads to the instruction \s-1RAM.\s0
+.IP "\fB\-mcode\-readable=no\fR" 4
+.IX Item "-mcode-readable=no"
+Instructions must not access executable sections.  This option can be
+useful on targets that are configured to have a dual instruction/data
+\&\s-1SRAM\s0 interface but that (unlike the M4K) do not automatically redirect
+PC-relative loads to the instruction \s-1RAM.\s0
+.RE
+.RS 4
+.RE
+.IP "\fB\-msplit\-addresses\fR" 4
+.IX Item "-msplit-addresses"
+.PD 0
+.IP "\fB\-mno\-split\-addresses\fR" 4
+.IX Item "-mno-split-addresses"
+.PD
+Enable (disable) use of the \f(CW\*(C`%hi()\*(C'\fR and \f(CW\*(C`%lo()\*(C'\fR assembler
+relocation operators.  This option has been superseded by
+\&\fB\-mexplicit\-relocs\fR but is retained for backwards compatibility.
+.IP "\fB\-mexplicit\-relocs\fR" 4
+.IX Item "-mexplicit-relocs"
+.PD 0
+.IP "\fB\-mno\-explicit\-relocs\fR" 4
+.IX Item "-mno-explicit-relocs"
+.PD
+Use (do not use) assembler relocation operators when dealing with symbolic
+addresses.  The alternative, selected by \fB\-mno\-explicit\-relocs\fR,
+is to use assembler macros instead.
+.Sp
+\&\fB\-mexplicit\-relocs\fR is the default if \s-1GCC\s0 was configured
+to use an assembler that supports relocation operators.
+.IP "\fB\-mcheck\-zero\-division\fR" 4
+.IX Item "-mcheck-zero-division"
+.PD 0
+.IP "\fB\-mno\-check\-zero\-division\fR" 4
+.IX Item "-mno-check-zero-division"
+.PD
+Trap (do not trap) on integer division by zero.
+.Sp
+The default is \fB\-mcheck\-zero\-division\fR.
+.IP "\fB\-mdivide\-traps\fR" 4
+.IX Item "-mdivide-traps"
+.PD 0
+.IP "\fB\-mdivide\-breaks\fR" 4
+.IX Item "-mdivide-breaks"
+.PD
+\&\s-1MIPS\s0 systems check for division by zero by generating either a
+conditional trap or a break instruction.  Using traps results in
+smaller code, but is only supported on \s-1MIPS II\s0 and later.  Also, some
+versions of the Linux kernel have a bug that prevents trap from
+generating the proper signal (\f(CW\*(C`SIGFPE\*(C'\fR).  Use \fB\-mdivide\-traps\fR to
+allow conditional traps on architectures that support them and
+\&\fB\-mdivide\-breaks\fR to force the use of breaks.
+.Sp
+The default is usually \fB\-mdivide\-traps\fR, but this can be
+overridden at configure time using \fB\-\-with\-divide=breaks\fR.
+Divide-by-zero checks can be completely disabled using
+\&\fB\-mno\-check\-zero\-division\fR.
+.IP "\fB\-mmemcpy\fR" 4
+.IX Item "-mmemcpy"
+.PD 0
+.IP "\fB\-mno\-memcpy\fR" 4
+.IX Item "-mno-memcpy"
+.PD
+Force (do not force) the use of \f(CW\*(C`memcpy()\*(C'\fR for non-trivial block
+moves.  The default is \fB\-mno\-memcpy\fR, which allows \s-1GCC\s0 to inline
+most constant-sized copies.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+.PD 0
+.IP "\fB\-mno\-long\-calls\fR" 4
+.IX Item "-mno-long-calls"
+.PD
+Disable (do not disable) use of the \f(CW\*(C`jal\*(C'\fR instruction.  Calling
+functions using \f(CW\*(C`jal\*(C'\fR is more efficient but requires the caller
+and callee to be in the same 256 megabyte segment.
+.Sp
+This option has no effect on abicalls code.  The default is
+\&\fB\-mno\-long\-calls\fR.
+.IP "\fB\-mmad\fR" 4
+.IX Item "-mmad"
+.PD 0
+.IP "\fB\-mno\-mad\fR" 4
+.IX Item "-mno-mad"
+.PD
+Enable (disable) use of the \f(CW\*(C`mad\*(C'\fR, \f(CW\*(C`madu\*(C'\fR and \f(CW\*(C`mul\*(C'\fR
+instructions, as provided by the R4650 \s-1ISA.\s0
+.IP "\fB\-mimadd\fR" 4
+.IX Item "-mimadd"
+.PD 0
+.IP "\fB\-mno\-imadd\fR" 4
+.IX Item "-mno-imadd"
+.PD
+Enable (disable) use of the \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR integer
+instructions.  The default is \fB\-mimadd\fR on architectures
+that support \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR except for the 74k 
+architecture where it was found to generate slower code.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Enable (disable) use of the floating-point multiply-accumulate
+instructions, when they are available.  The default is
+\&\fB\-mfused\-madd\fR.
+.Sp
+On the R8000 \s-1CPU\s0 when multiply-accumulate instructions are used,
+the intermediate product is calculated to infinite precision
+and is not subject to the \s-1FCSR\s0 Flush to Zero bit.  This may be
+undesirable in some circumstances.  On other processors the result
+is numerically identical to the equivalent computation using
+separate multiply, add, subtract and negate instructions.
+.IP "\fB\-nocpp\fR" 4
+.IX Item "-nocpp"
+Tell the \s-1MIPS\s0 assembler to not run its preprocessor over user
+assembler files (with a \fB.s\fR suffix) when assembling them.
+.IP "\fB\-mfix\-24k\fR" 4
+.IX Item "-mfix-24k"
+.PD 0
+.IP "\fB\-mno\-fix\-24k\fR" 4
+.IX Item "-mno-fix-24k"
+.PD
+Work around the 24K E48 (lost data on stores during refill) errata.
+The workarounds are implemented by the assembler rather than by \s-1GCC.\s0
+.IP "\fB\-mfix\-r4000\fR" 4
+.IX Item "-mfix-r4000"
+.PD 0
+.IP "\fB\-mno\-fix\-r4000\fR" 4
+.IX Item "-mno-fix-r4000"
+.PD
+Work around certain R4000 \s-1CPU\s0 errata:
+.RS 4
+.IP "\-" 4
+A double-word or a variable shift may give an incorrect result if executed
+immediately after starting an integer division.
+.IP "\-" 4
+A double-word or a variable shift may give an incorrect result if executed
+while an integer multiplication is in progress.
+.IP "\-" 4
+An integer division may give an incorrect result if started in a delay slot
+of a taken branch or a jump.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mfix\-r4400\fR" 4
+.IX Item "-mfix-r4400"
+.PD 0
+.IP "\fB\-mno\-fix\-r4400\fR" 4
+.IX Item "-mno-fix-r4400"
+.PD
+Work around certain R4400 \s-1CPU\s0 errata:
+.RS 4
+.IP "\-" 4
+A double-word or a variable shift may give an incorrect result if executed
+immediately after starting an integer division.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mfix\-r10000\fR" 4
+.IX Item "-mfix-r10000"
+.PD 0
+.IP "\fB\-mno\-fix\-r10000\fR" 4
+.IX Item "-mno-fix-r10000"
+.PD
+Work around certain R10000 errata:
+.RS 4
+.IP "\-" 4
+\&\f(CW\*(C`ll\*(C'\fR/\f(CW\*(C`sc\*(C'\fR sequences may not behave atomically on revisions
+prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
+.RE
+.RS 4
+.Sp
+This option can only be used if the target architecture supports
+branch-likely instructions.  \fB\-mfix\-r10000\fR is the default when
+\&\fB\-march=r10000\fR is used; \fB\-mno\-fix\-r10000\fR is the default
+otherwise.
+.RE
+.IP "\fB\-mfix\-rm7000\fR" 4
+.IX Item "-mfix-rm7000"
+.PD 0
+.IP "\fB\-mno\-fix\-rm7000\fR" 4
+.IX Item "-mno-fix-rm7000"
+.PD
+Work around the \s-1RM7000 \s0\f(CW\*(C`dmult\*(C'\fR/\f(CW\*(C`dmultu\*(C'\fR errata.  The
+workarounds are implemented by the assembler rather than by \s-1GCC.\s0
+.IP "\fB\-mfix\-vr4120\fR" 4
+.IX Item "-mfix-vr4120"
+.PD 0
+.IP "\fB\-mno\-fix\-vr4120\fR" 4
+.IX Item "-mno-fix-vr4120"
+.PD
+Work around certain \s-1VR4120\s0 errata:
+.RS 4
+.IP "\-" 4
+\&\f(CW\*(C`dmultu\*(C'\fR does not always produce the correct result.
+.IP "\-" 4
+\&\f(CW\*(C`div\*(C'\fR and \f(CW\*(C`ddiv\*(C'\fR do not always produce the correct result if one
+of the operands is negative.
+.RE
+.RS 4
+.Sp
+The workarounds for the division errata rely on special functions in
+\&\fIlibgcc.a\fR.  At present, these functions are only provided by
+the \f(CW\*(C`mips64vr*\-elf\*(C'\fR configurations.
+.Sp
+Other \s-1VR4120\s0 errata require a \s-1NOP\s0 to be inserted between certain pairs of
+instructions.  These errata are handled by the assembler, not by \s-1GCC\s0 itself.
+.RE
+.IP "\fB\-mfix\-vr4130\fR" 4
+.IX Item "-mfix-vr4130"
+Work around the \s-1VR4130 \s0\f(CW\*(C`mflo\*(C'\fR/\f(CW\*(C`mfhi\*(C'\fR errata.  The
+workarounds are implemented by the assembler rather than by \s-1GCC,\s0
+although \s-1GCC\s0 avoids using \f(CW\*(C`mflo\*(C'\fR and \f(CW\*(C`mfhi\*(C'\fR if the
+\&\s-1VR4130 \s0\f(CW\*(C`macc\*(C'\fR, \f(CW\*(C`macchi\*(C'\fR, \f(CW\*(C`dmacc\*(C'\fR and \f(CW\*(C`dmacchi\*(C'\fR
+instructions are available instead.
+.IP "\fB\-mfix\-sb1\fR" 4
+.IX Item "-mfix-sb1"
+.PD 0
+.IP "\fB\-mno\-fix\-sb1\fR" 4
+.IX Item "-mno-fix-sb1"
+.PD
+Work around certain \s-1SB\-1 CPU\s0 core errata.
+(This flag currently works around the \s-1SB\-1\s0 revision 2
+\&\*(L"F1\*(R" and \*(L"F2\*(R" floating-point errata.)
+.IP "\fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR" 4
+.IX Item "-mr10k-cache-barrier=setting"
+Specify whether \s-1GCC\s0 should insert cache barriers to avoid the
+side-effects of speculation on R10K processors.
+.Sp
+In common with many processors, the R10K tries to predict the outcome
+of a conditional branch and speculatively executes instructions from
+the \*(L"taken\*(R" branch.  It later aborts these instructions if the
+predicted outcome is wrong.  However, on the R10K, even aborted
+instructions can have side effects.
+.Sp
+This problem only affects kernel stores and, depending on the system,
+kernel loads.  As an example, a speculatively-executed store may load
+the target memory into cache and mark the cache line as dirty, even if
+the store itself is later aborted.  If a \s-1DMA\s0 operation writes to the
+same area of memory before the \*(L"dirty\*(R" line is flushed, the cached
+data overwrites the DMA-ed data.  See the R10K processor manual
+for a full description, including other potential problems.
+.Sp
+One workaround is to insert cache barrier instructions before every memory
+access that might be speculatively executed and that might have side
+effects even if aborted.  \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR
+controls \s-1GCC\s0's implementation of this workaround.  It assumes that
+aborted accesses to any byte in the following regions does not have
+side effects:
+.RS 4
+.IP "1." 4
+the memory occupied by the current function's stack frame;
+.IP "2." 4
+the memory occupied by an incoming stack argument;
+.IP "3." 4
+the memory occupied by an object with a link-time-constant address.
+.RE
+.RS 4
+.Sp
+It is the kernel's responsibility to ensure that speculative
+accesses to these regions are indeed safe.
+.Sp
+If the input program contains a function declaration such as:
+.Sp
+.Vb 1
+\&        void foo (void);
+.Ve
+.Sp
+then the implementation of \f(CW\*(C`foo\*(C'\fR must allow \f(CW\*(C`j foo\*(C'\fR and
+\&\f(CW\*(C`jal foo\*(C'\fR to be executed speculatively.  \s-1GCC\s0 honors this
+restriction for functions it compiles itself.  It expects non-GCC
+functions (such as hand-written assembly code) to do the same.
+.Sp
+The option has three forms:
+.IP "\fB\-mr10k\-cache\-barrier=load\-store\fR" 4
+.IX Item "-mr10k-cache-barrier=load-store"
+Insert a cache barrier before a load or store that might be
+speculatively executed and that might have side effects even
+if aborted.
+.IP "\fB\-mr10k\-cache\-barrier=store\fR" 4
+.IX Item "-mr10k-cache-barrier=store"
+Insert a cache barrier before a store that might be speculatively
+executed and that might have side effects even if aborted.
+.IP "\fB\-mr10k\-cache\-barrier=none\fR" 4
+.IX Item "-mr10k-cache-barrier=none"
+Disable the insertion of cache barriers.  This is the default setting.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mflush\-func=\fR\fIfunc\fR" 4
+.IX Item "-mflush-func=func"
+.PD 0
+.IP "\fB\-mno\-flush\-func\fR" 4
+.IX Item "-mno-flush-func"
+.PD
+Specifies the function to call to flush the I and D caches, or to not
+call any such function.  If called, the function must take the same
+arguments as the common \f(CW\*(C`_flush_func()\*(C'\fR, that is, the address of the
+memory range for which the cache is being flushed, the size of the
+memory range, and the number 3 (to flush both caches).  The default
+depends on the target \s-1GCC\s0 was configured for, but commonly is either
+\&\fB_flush_func\fR or \fB_\|_cpu_flush\fR.
+.IP "\fBmbranch\-cost=\fR\fInum\fR" 4
+.IX Item "mbranch-cost=num"
+Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
+This cost is only a heuristic and is not guaranteed to produce
+consistent results across releases.  A zero cost redundantly selects
+the default, which is based on the \fB\-mtune\fR setting.
+.IP "\fB\-mbranch\-likely\fR" 4
+.IX Item "-mbranch-likely"
+.PD 0
+.IP "\fB\-mno\-branch\-likely\fR" 4
+.IX Item "-mno-branch-likely"
+.PD
+Enable or disable use of Branch Likely instructions, regardless of the
+default for the selected architecture.  By default, Branch Likely
+instructions may be generated if they are supported by the selected
+architecture.  An exception is for the \s-1MIPS32\s0 and \s-1MIPS64\s0 architectures
+and processors that implement those architectures; for those, Branch
+Likely instructions are not be generated by default because the \s-1MIPS32\s0
+and \s-1MIPS64\s0 architectures specifically deprecate their use.
+.IP "\fB\-mfp\-exceptions\fR" 4
+.IX Item "-mfp-exceptions"
+.PD 0
+.IP "\fB\-mno\-fp\-exceptions\fR" 4
+.IX Item "-mno-fp-exceptions"
+.PD
+Specifies whether \s-1FP\s0 exceptions are enabled.  This affects how
+\&\s-1FP\s0 instructions are scheduled for some processors.
+The default is that \s-1FP\s0 exceptions are
+enabled.
+.Sp
+For instance, on the \s-1SB\-1,\s0 if \s-1FP\s0 exceptions are disabled, and we are emitting
+64\-bit code, then we can use both \s-1FP\s0 pipes.  Otherwise, we can only use one
+\&\s-1FP\s0 pipe.
+.IP "\fB\-mvr4130\-align\fR" 4
+.IX Item "-mvr4130-align"
+.PD 0
+.IP "\fB\-mno\-vr4130\-align\fR" 4
+.IX Item "-mno-vr4130-align"
+.PD
+The \s-1VR4130\s0 pipeline is two-way superscalar, but can only issue two
+instructions together if the first one is 8\-byte aligned.  When this
+option is enabled, \s-1GCC\s0 aligns pairs of instructions that it
+thinks should execute in parallel.
+.Sp
+This option only has an effect when optimizing for the \s-1VR4130.\s0
+It normally makes code faster, but at the expense of making it bigger.
+It is enabled by default at optimization level \fB\-O3\fR.
+.IP "\fB\-msynci\fR" 4
+.IX Item "-msynci"
+.PD 0
+.IP "\fB\-mno\-synci\fR" 4
+.IX Item "-mno-synci"
+.PD
+Enable (disable) generation of \f(CW\*(C`synci\*(C'\fR instructions on
+architectures that support it.  The \f(CW\*(C`synci\*(C'\fR instructions (if
+enabled) are generated when \f(CW\*(C`_\|_builtin_\|_\|_clear_cache()\*(C'\fR is
+compiled.
+.Sp
+This option defaults to \f(CW\*(C`\-mno\-synci\*(C'\fR, but the default can be
+overridden by configuring with \f(CW\*(C`\-\-with\-synci\*(C'\fR.
+.Sp
+When compiling code for single processor systems, it is generally safe
+to use \f(CW\*(C`synci\*(C'\fR.  However, on many multi-core (\s-1SMP\s0) systems, it
+does not invalidate the instruction caches on all cores and may lead
+to undefined behavior.
+.IP "\fB\-mrelax\-pic\-calls\fR" 4
+.IX Item "-mrelax-pic-calls"
+.PD 0
+.IP "\fB\-mno\-relax\-pic\-calls\fR" 4
+.IX Item "-mno-relax-pic-calls"
+.PD
+Try to turn \s-1PIC\s0 calls that are normally dispatched via register
+\&\f(CW$25\fR into direct calls.  This is only possible if the linker can
+resolve the destination at link-time and if the destination is within
+range for a direct call.
+.Sp
+\&\fB\-mrelax\-pic\-calls\fR is the default if \s-1GCC\s0 was configured to use
+an assembler and a linker that support the \f(CW\*(C`.reloc\*(C'\fR assembly
+directive and \f(CW\*(C`\-mexplicit\-relocs\*(C'\fR is in effect.  With
+\&\f(CW\*(C`\-mno\-explicit\-relocs\*(C'\fR, this optimization can be performed by the
+assembler and the linker alone without help from the compiler.
+.IP "\fB\-mmcount\-ra\-address\fR" 4
+.IX Item "-mmcount-ra-address"
+.PD 0
+.IP "\fB\-mno\-mcount\-ra\-address\fR" 4
+.IX Item "-mno-mcount-ra-address"
+.PD
+Emit (do not emit) code that allows \f(CW\*(C`_mcount\*(C'\fR to modify the
+calling function's return address.  When enabled, this option extends
+the usual \f(CW\*(C`_mcount\*(C'\fR interface with a new \fIra-address\fR
+parameter, which has type \f(CW\*(C`intptr_t *\*(C'\fR and is passed in register
+\&\f(CW$12\fR.  \f(CW\*(C`_mcount\*(C'\fR can then modify the return address by
+doing both of the following:
+.RS 4
+.IP "\(bu" 4
+Returning the new address in register \f(CW$31\fR.
+.IP "\(bu" 4
+Storing the new address in \f(CW\*(C`*\f(CIra\-address\f(CW\*(C'\fR,
+if \fIra-address\fR is nonnull.
+.RE
+.RS 4
+.Sp
+The default is \fB\-mno\-mcount\-ra\-address\fR.
+.RE
+.PP
+\fI\s-1MMIX\s0 Options\fR
+.IX Subsection "MMIX Options"
+.PP
+These options are defined for the \s-1MMIX:\s0
+.IP "\fB\-mlibfuncs\fR" 4
+.IX Item "-mlibfuncs"
+.PD 0
+.IP "\fB\-mno\-libfuncs\fR" 4
+.IX Item "-mno-libfuncs"
+.PD
+Specify that intrinsic library functions are being compiled, passing all
+values in registers, no matter the size.
+.IP "\fB\-mepsilon\fR" 4
+.IX Item "-mepsilon"
+.PD 0
+.IP "\fB\-mno\-epsilon\fR" 4
+.IX Item "-mno-epsilon"
+.PD
+Generate floating-point comparison instructions that compare with respect
+to the \f(CW\*(C`rE\*(C'\fR epsilon register.
+.IP "\fB\-mabi=mmixware\fR" 4
+.IX Item "-mabi=mmixware"
+.PD 0
+.IP "\fB\-mabi=gnu\fR" 4
+.IX Item "-mabi=gnu"
+.PD
+Generate code that passes function parameters and return values that (in
+the called function) are seen as registers \f(CW$0\fR and up, as opposed to
+the \s-1GNU ABI\s0 which uses global registers \f(CW$231\fR and up.
+.IP "\fB\-mzero\-extend\fR" 4
+.IX Item "-mzero-extend"
+.PD 0
+.IP "\fB\-mno\-zero\-extend\fR" 4
+.IX Item "-mno-zero-extend"
+.PD
+When reading data from memory in sizes shorter than 64 bits, use (do not
+use) zero-extending load instructions by default, rather than
+sign-extending ones.
+.IP "\fB\-mknuthdiv\fR" 4
+.IX Item "-mknuthdiv"
+.PD 0
+.IP "\fB\-mno\-knuthdiv\fR" 4
+.IX Item "-mno-knuthdiv"
+.PD
+Make the result of a division yielding a remainder have the same sign as
+the divisor.  With the default, \fB\-mno\-knuthdiv\fR, the sign of the
+remainder follows the sign of the dividend.  Both methods are
+arithmetically valid, the latter being almost exclusively used.
+.IP "\fB\-mtoplevel\-symbols\fR" 4
+.IX Item "-mtoplevel-symbols"
+.PD 0
+.IP "\fB\-mno\-toplevel\-symbols\fR" 4
+.IX Item "-mno-toplevel-symbols"
+.PD
+Prepend (do not prepend) a \fB:\fR to all global symbols, so the assembly
+code can be used with the \f(CW\*(C`PREFIX\*(C'\fR assembly directive.
+.IP "\fB\-melf\fR" 4
+.IX Item "-melf"
+Generate an executable in the \s-1ELF\s0 format, rather than the default
+\&\fBmmo\fR format used by the \fBmmix\fR simulator.
+.IP "\fB\-mbranch\-predict\fR" 4
+.IX Item "-mbranch-predict"
+.PD 0
+.IP "\fB\-mno\-branch\-predict\fR" 4
+.IX Item "-mno-branch-predict"
+.PD
+Use (do not use) the probable-branch instructions, when static branch
+prediction indicates a probable branch.
+.IP "\fB\-mbase\-addresses\fR" 4
+.IX Item "-mbase-addresses"
+.PD 0
+.IP "\fB\-mno\-base\-addresses\fR" 4
+.IX Item "-mno-base-addresses"
+.PD
+Generate (do not generate) code that uses \fIbase addresses\fR.  Using a
+base address automatically generates a request (handled by the assembler
+and the linker) for a constant to be set up in a global register.  The
+register is used for one or more base address requests within the range 0
+to 255 from the value held in the register.  The generally leads to short
+and fast code, but the number of different data items that can be
+addressed is limited.  This means that a program that uses lots of static
+data may require \fB\-mno\-base\-addresses\fR.
+.IP "\fB\-msingle\-exit\fR" 4
+.IX Item "-msingle-exit"
+.PD 0
+.IP "\fB\-mno\-single\-exit\fR" 4
+.IX Item "-mno-single-exit"
+.PD
+Force (do not force) generated code to have a single exit point in each
+function.
+.PP
+\fI\s-1MN10300\s0 Options\fR
+.IX Subsection "MN10300 Options"
+.PP
+These \fB\-m\fR options are defined for Matsushita \s-1MN10300\s0 architectures:
+.IP "\fB\-mmult\-bug\fR" 4
+.IX Item "-mmult-bug"
+Generate code to avoid bugs in the multiply instructions for the \s-1MN10300\s0
+processors.  This is the default.
+.IP "\fB\-mno\-mult\-bug\fR" 4
+.IX Item "-mno-mult-bug"
+Do not generate code to avoid bugs in the multiply instructions for the
+\&\s-1MN10300\s0 processors.
+.IP "\fB\-mam33\fR" 4
+.IX Item "-mam33"
+Generate code using features specific to the \s-1AM33\s0 processor.
+.IP "\fB\-mno\-am33\fR" 4
+.IX Item "-mno-am33"
+Do not generate code using features specific to the \s-1AM33\s0 processor.  This
+is the default.
+.IP "\fB\-mam33\-2\fR" 4
+.IX Item "-mam33-2"
+Generate code using features specific to the \s-1AM33/2.0\s0 processor.
+.IP "\fB\-mam34\fR" 4
+.IX Item "-mam34"
+Generate code using features specific to the \s-1AM34\s0 processor.
+.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
+.IX Item "-mtune=cpu-type"
+Use the timing characteristics of the indicated \s-1CPU\s0 type when
+scheduling instructions.  This does not change the targeted processor
+type.  The \s-1CPU\s0 type must be one of \fBmn10300\fR, \fBam33\fR,
+\&\fBam33\-2\fR or \fBam34\fR.
+.IP "\fB\-mreturn\-pointer\-on\-d0\fR" 4
+.IX Item "-mreturn-pointer-on-d0"
+When generating a function that returns a pointer, return the pointer
+in both \f(CW\*(C`a0\*(C'\fR and \f(CW\*(C`d0\*(C'\fR.  Otherwise, the pointer is returned
+only in \f(CW\*(C`a0\*(C'\fR, and attempts to call such functions without a prototype
+result in errors.  Note that this option is on by default; use
+\&\fB\-mno\-return\-pointer\-on\-d0\fR to disable it.
+.IP "\fB\-mno\-crt0\fR" 4
+.IX Item "-mno-crt0"
+Do not link in the C run-time initialization object file.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Indicate to the linker that it should perform a relaxation optimization pass
+to shorten branches, calls and absolute memory addresses.  This option only
+has an effect when used on the command line for the final link step.
+.Sp
+This option makes symbolic debugging impossible.
+.IP "\fB\-mliw\fR" 4
+.IX Item "-mliw"
+Allow the compiler to generate \fILong Instruction Word\fR
+instructions if the target is the \fB\s-1AM33\s0\fR or later.  This is the
+default.  This option defines the preprocessor macro \fB_\|_LIW_\|_\fR.
+.IP "\fB\-mnoliw\fR" 4
+.IX Item "-mnoliw"
+Do not allow the compiler to generate \fILong Instruction Word\fR
+instructions.  This option defines the preprocessor macro
+\&\fB_\|_NO_LIW_\|_\fR.
+.IP "\fB\-msetlb\fR" 4
+.IX Item "-msetlb"
+Allow the compiler to generate the \fI\s-1SETLB\s0\fR and \fILcc\fR
+instructions if the target is the \fB\s-1AM33\s0\fR or later.  This is the
+default.  This option defines the preprocessor macro \fB_\|_SETLB_\|_\fR.
+.IP "\fB\-mnosetlb\fR" 4
+.IX Item "-mnosetlb"
+Do not allow the compiler to generate \fI\s-1SETLB\s0\fR or \fILcc\fR
+instructions.  This option defines the preprocessor macro
+\&\fB_\|_NO_SETLB_\|_\fR.
+.PP
+\fIMoxie Options\fR
+.IX Subsection "Moxie Options"
+.IP "\fB\-meb\fR" 4
+.IX Item "-meb"
+Generate big-endian code.  This is the default for \fBmoxie\-*\-*\fR
+configurations.
+.IP "\fB\-mel\fR" 4
+.IX Item "-mel"
+Generate little-endian code.
+.IP "\fB\-mno\-crt0\fR" 4
+.IX Item "-mno-crt0"
+Do not link in the C run-time initialization object file.
+.PP
+\fI\s-1MSP430\s0 Options\fR
+.IX Subsection "MSP430 Options"
+.PP
+These options are defined for the \s-1MSP430:\s0
+.IP "\fB\-masm\-hex\fR" 4
+.IX Item "-masm-hex"
+Force assembly output to always use hex constants.  Normally such
+constants are signed decimals, but this option is available for
+testsuite and/or aesthetic purposes.
+.IP "\fB\-mmcu=\fR" 4
+.IX Item "-mmcu="
+Select the \s-1MCU\s0 to target.  This is used to create a C preprocessor
+symbol based upon the \s-1MCU\s0 name, converted to upper case and pre\- and
+post\- fixed with \f(CW\*(C`_\|_\*(C'\fR.  This in turn will be used by the
+\&\f(CW\*(C`msp430.h\*(C'\fR header file to select an \s-1MCU\s0 specific supplimentary
+header file.
+.Sp
+The option also sets the \s-1ISA\s0 to use.  If the \s-1MCU\s0 name is one that is
+known to only support the 430 \s-1ISA\s0 then that is selected, otherwise the
+430X \s-1ISA\s0 is selected.  A generic \s-1MCU\s0 name of \f(CW\*(C`msp430\*(C'\fR can also be
+used to select the 430 \s-1ISA. \s0 Similarly the generic \f(CW\*(C`msp430x\*(C'\fR \s-1MCU\s0
+name will select the 430X \s-1ISA.\s0
+.Sp
+In addition an \s-1MCU\s0 specific linker script will be added to the linker
+command line.  The script's name is the name of the \s-1MCU\s0 with
+\&\f(CW\*(C`.ld\*(C'\fR appended.  Thus specifying \fB\-mmcu=xxx\fR on the gcc
+command line will define the C preprocessor symbol \f(CW\*(C`_\|_XXX_\|_\*(C'\fR and
+cause the linker to search for a script called \fIxxx.ld\fR.
+.Sp
+This option is also passed on to the assembler.
+.IP "\fB\-mcpu=\fR" 4
+.IX Item "-mcpu="
+Specifies the \s-1ISA\s0 to use.  Accepted values are \f(CW\*(C`msp430\*(C'\fR,
+\&\f(CW\*(C`msp430x\*(C'\fR and \f(CW\*(C`msp430xv2\*(C'\fR.  This option is deprecated.  The
+\&\fB\-mmcu=\fR option should be used to select the \s-1ISA.\s0
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Link to the simulator runtime libraries and linker script.  Overrides
+any scripts that would be selected by the \fB\-mmcu=\fR option.
+.IP "\fB\-mlarge\fR" 4
+.IX Item "-mlarge"
+Use large-model addressing (20\-bit pointers, 32\-bit \f(CW\*(C`size_t\*(C'\fR).
+.IP "\fB\-msmall\fR" 4
+.IX Item "-msmall"
+Use small-model addressing (16\-bit pointers, 16\-bit \f(CW\*(C`size_t\*(C'\fR).
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+This option is passed to the assembler and linker, and allows the
+linker to perform certain optimizations that cannot be done until
+the final link.
+.PP
+\fI\s-1NDS32\s0 Options\fR
+.IX Subsection "NDS32 Options"
+.PP
+These options are defined for \s-1NDS32\s0 implementations:
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code in big-endian mode.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code in little-endian mode.
+.IP "\fB\-mreduced\-regs\fR" 4
+.IX Item "-mreduced-regs"
+Use reduced-set registers for register allocation.
+.IP "\fB\-mfull\-regs\fR" 4
+.IX Item "-mfull-regs"
+Use full-set registers for register allocation.
+.IP "\fB\-mcmov\fR" 4
+.IX Item "-mcmov"
+Generate conditional move instructions.
+.IP "\fB\-mno\-cmov\fR" 4
+.IX Item "-mno-cmov"
+Do not generate conditional move instructions.
+.IP "\fB\-mperf\-ext\fR" 4
+.IX Item "-mperf-ext"
+Generate performance extension instructions.
+.IP "\fB\-mno\-perf\-ext\fR" 4
+.IX Item "-mno-perf-ext"
+Do not generate performance extension instructions.
+.IP "\fB\-mv3push\fR" 4
+.IX Item "-mv3push"
+Generate v3 push25/pop25 instructions.
+.IP "\fB\-mno\-v3push\fR" 4
+.IX Item "-mno-v3push"
+Do not generate v3 push25/pop25 instructions.
+.IP "\fB\-m16\-bit\fR" 4
+.IX Item "-m16-bit"
+Generate 16\-bit instructions.
+.IP "\fB\-mno\-16\-bit\fR" 4
+.IX Item "-mno-16-bit"
+Do not generate 16\-bit instructions.
+.IP "\fB\-mgp\-direct\fR" 4
+.IX Item "-mgp-direct"
+Generate \s-1GP\s0 base instructions directly.
+.IP "\fB\-mno\-gp\-direct\fR" 4
+.IX Item "-mno-gp-direct"
+Do no generate \s-1GP\s0 base instructions directly.
+.IP "\fB\-misr\-vector\-size=\fR\fInum\fR" 4
+.IX Item "-misr-vector-size=num"
+Specify the size of each interrupt vector, which must be 4 or 16.
+.IP "\fB\-mcache\-block\-size=\fR\fInum\fR" 4
+.IX Item "-mcache-block-size=num"
+Specify the size of each cache block,
+which must be a power of 2 between 4 and 512.
+.IP "\fB\-march=\fR\fIarch\fR" 4
+.IX Item "-march=arch"
+Specify the name of the target architecture.
+.IP "\fB\-mforce\-fp\-as\-gp\fR" 4
+.IX Item "-mforce-fp-as-gp"
+Prevent \f(CW$fp\fR being allocated during register allocation so that compiler
+is able to force performing fp-as-gp optimization.
+.IP "\fB\-mforbid\-fp\-as\-gp\fR" 4
+.IX Item "-mforbid-fp-as-gp"
+Forbid using \f(CW$fp\fR to access static and global variables.
+This option strictly forbids fp-as-gp optimization
+regardless of \fB\-mforce\-fp\-as\-gp\fR.
+.IP "\fB\-mex9\fR" 4
+.IX Item "-mex9"
+Use special directives to guide linker doing ex9 optimization.
+.IP "\fB\-mctor\-dtor\fR" 4
+.IX Item "-mctor-dtor"
+Enable constructor/destructor feature.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Guide linker to relax instructions.
+.PP
+\fINios \s-1II\s0 Options\fR
+.IX Subsection "Nios II Options"
+.PP
+These are the options defined for the Altera Nios \s-1II\s0 processor.
+.IP "\fB\-G\fR \fInum\fR" 4
+.IX Item "-G num"
+Put global and static objects less than or equal to \fInum\fR bytes
+into the small data or \s-1BSS\s0 sections instead of the normal data or \s-1BSS\s0
+sections.  The default value of \fInum\fR is 8.
+.IP "\fB\-mgpopt\fR" 4
+.IX Item "-mgpopt"
+.PD 0
+.IP "\fB\-mno\-gpopt\fR" 4
+.IX Item "-mno-gpopt"
+.PD
+Generate (do not generate) GP-relative accesses for objects in the
+small data or \s-1BSS\s0 sections.  The default is \fB\-mgpopt\fR except
+when \fB\-fpic\fR or \fB\-fPIC\fR is specified to generate
+position-independent code.  Note that the Nios \s-1II ABI\s0 does not permit
+GP-relative accesses from shared libraries.
+.Sp
+You may need to specify \fB\-mno\-gpopt\fR explicitly when building
+programs that include large amounts of small data, including large
+\&\s-1GOT\s0 data sections.  In this case, the 16\-bit offset for GP-relative
+addressing may not be large enough to allow access to the entire 
+small data section.
+.IP "\fB\-mel\fR" 4
+.IX Item "-mel"
+.PD 0
+.IP "\fB\-meb\fR" 4
+.IX Item "-meb"
+.PD
+Generate little-endian (default) or big-endian (experimental) code,
+respectively.
+.IP "\fB\-mbypass\-cache\fR" 4
+.IX Item "-mbypass-cache"
+.PD 0
+.IP "\fB\-mno\-bypass\-cache\fR" 4
+.IX Item "-mno-bypass-cache"
+.PD
+Force all load and store instructions to always bypass cache by 
+using I/O variants of the instructions. The default is not to
+bypass the cache.
+.IP "\fB\-mno\-cache\-volatile\fR" 4
+.IX Item "-mno-cache-volatile"
+.PD 0
+.IP "\fB\-mcache\-volatile\fR" 4
+.IX Item "-mcache-volatile"
+.PD
+Volatile memory access bypass the cache using the I/O variants of 
+the load and store instructions. The default is not to bypass the cache.
+.IP "\fB\-mno\-fast\-sw\-div\fR" 4
+.IX Item "-mno-fast-sw-div"
+.PD 0
+.IP "\fB\-mfast\-sw\-div\fR" 4
+.IX Item "-mfast-sw-div"
+.PD
+Do not use table-based fast divide for small numbers. The default 
+is to use the fast divide at \fB\-O3\fR and above.
+.IP "\fB\-mno\-hw\-mul\fR" 4
+.IX Item "-mno-hw-mul"
+.PD 0
+.IP "\fB\-mhw\-mul\fR" 4
+.IX Item "-mhw-mul"
+.IP "\fB\-mno\-hw\-mulx\fR" 4
+.IX Item "-mno-hw-mulx"
+.IP "\fB\-mhw\-mulx\fR" 4
+.IX Item "-mhw-mulx"
+.IP "\fB\-mno\-hw\-div\fR" 4
+.IX Item "-mno-hw-div"
+.IP "\fB\-mhw\-div\fR" 4
+.IX Item "-mhw-div"
+.PD
+Enable or disable emitting \f(CW\*(C`mul\*(C'\fR, \f(CW\*(C`mulx\*(C'\fR and \f(CW\*(C`div\*(C'\fR family of 
+instructions by the compiler. The default is to emit \f(CW\*(C`mul\*(C'\fR
+and not emit \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`mulx\*(C'\fR.
+.IP "\fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR" 4
+.IX Item "-mcustom-insn=N"
+.PD 0
+.IP "\fB\-mno\-custom\-\fR\fIinsn\fR" 4
+.IX Item "-mno-custom-insn"
+.PD
+Each \fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR option enables use of a
+custom instruction with encoding \fIN\fR when generating code that uses 
+\&\fIinsn\fR.  For example, \f(CW\*(C`\-mcustom\-fadds=253\*(C'\fR generates custom
+instruction 253 for single-precision floating-point add operations instead
+of the default behavior of using a library call.
+.Sp
+The following values of \fIinsn\fR are supported.  Except as otherwise
+noted, floating-point operations are expected to be implemented with
+normal \s-1IEEE 754\s0 semantics and correspond directly to the C operators or the
+equivalent \s-1GCC\s0 built-in functions.
+.Sp
+Single-precision floating point:
+.RS 4
+.IP "\fBfadds\fR, \fBfsubs\fR, \fBfdivs\fR, \fBfmuls\fR" 4
+.IX Item "fadds, fsubs, fdivs, fmuls"
+Binary arithmetic operations.
+.IP "\fBfnegs\fR" 4
+.IX Item "fnegs"
+Unary negation.
+.IP "\fBfabss\fR" 4
+.IX Item "fabss"
+Unary absolute value.
+.IP "\fBfcmpeqs\fR, \fBfcmpges\fR, \fBfcmpgts\fR, \fBfcmples\fR, \fBfcmplts\fR, \fBfcmpnes\fR" 4
+.IX Item "fcmpeqs, fcmpges, fcmpgts, fcmples, fcmplts, fcmpnes"
+Comparison operations.
+.IP "\fBfmins\fR, \fBfmaxs\fR" 4
+.IX Item "fmins, fmaxs"
+Floating-point minimum and maximum.  These instructions are only
+generated if \fB\-ffinite\-math\-only\fR is specified.
+.IP "\fBfsqrts\fR" 4
+.IX Item "fsqrts"
+Unary square root operation.
+.IP "\fBfcoss\fR, \fBfsins\fR, \fBftans\fR, \fBfatans\fR, \fBfexps\fR, \fBflogs\fR" 4
+.IX Item "fcoss, fsins, ftans, fatans, fexps, flogs"
+Floating-point trigonometric and exponential functions.  These instructions
+are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
+.RE
+.RS 4
+.Sp
+Double-precision floating point:
+.IP "\fBfaddd\fR, \fBfsubd\fR, \fBfdivd\fR, \fBfmuld\fR" 4
+.IX Item "faddd, fsubd, fdivd, fmuld"
+Binary arithmetic operations.
+.IP "\fBfnegd\fR" 4
+.IX Item "fnegd"
+Unary negation.
+.IP "\fBfabsd\fR" 4
+.IX Item "fabsd"
+Unary absolute value.
+.IP "\fBfcmpeqd\fR, \fBfcmpged\fR, \fBfcmpgtd\fR, \fBfcmpled\fR, \fBfcmpltd\fR, \fBfcmpned\fR" 4
+.IX Item "fcmpeqd, fcmpged, fcmpgtd, fcmpled, fcmpltd, fcmpned"
+Comparison operations.
+.IP "\fBfmind\fR, \fBfmaxd\fR" 4
+.IX Item "fmind, fmaxd"
+Double-precision minimum and maximum.  These instructions are only
+generated if \fB\-ffinite\-math\-only\fR is specified.
+.IP "\fBfsqrtd\fR" 4
+.IX Item "fsqrtd"
+Unary square root operation.
+.IP "\fBfcosd\fR, \fBfsind\fR, \fBftand\fR, \fBfatand\fR, \fBfexpd\fR, \fBflogd\fR" 4
+.IX Item "fcosd, fsind, ftand, fatand, fexpd, flogd"
+Double-precision trigonometric and exponential functions.  These instructions
+are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
+.RE
+.RS 4
+.Sp
+Conversions:
+.IP "\fBfextsd\fR" 4
+.IX Item "fextsd"
+Conversion from single precision to double precision.
+.IP "\fBftruncds\fR" 4
+.IX Item "ftruncds"
+Conversion from double precision to single precision.
+.IP "\fBfixsi\fR, \fBfixsu\fR, \fBfixdi\fR, \fBfixdu\fR" 4
+.IX Item "fixsi, fixsu, fixdi, fixdu"
+Conversion from floating point to signed or unsigned integer types, with
+truncation towards zero.
+.IP "\fBfloatis\fR, \fBfloatus\fR, \fBfloatid\fR, \fBfloatud\fR" 4
+.IX Item "floatis, floatus, floatid, floatud"
+Conversion from signed or unsigned integer types to floating-point types.
+.RE
+.RS 4
+.Sp
+In addition, all of the following transfer instructions for internal
+registers X and Y must be provided to use any of the double-precision
+floating-point instructions.  Custom instructions taking two
+double-precision source operands expect the first operand in the
+64\-bit register X.  The other operand (or only operand of a unary
+operation) is given to the custom arithmetic instruction with the
+least significant half in source register \fIsrc1\fR and the most
+significant half in \fIsrc2\fR.  A custom instruction that returns a
+double-precision result returns the most significant 32 bits in the
+destination register and the other half in 32\-bit register Y.  
+\&\s-1GCC\s0 automatically generates the necessary code sequences to write
+register X and/or read register Y when double-precision floating-point
+instructions are used.
+.IP "\fBfwrx\fR" 4
+.IX Item "fwrx"
+Write \fIsrc1\fR into the least significant half of X and \fIsrc2\fR into
+the most significant half of X.
+.IP "\fBfwry\fR" 4
+.IX Item "fwry"
+Write \fIsrc1\fR into Y.
+.IP "\fBfrdxhi\fR, \fBfrdxlo\fR" 4
+.IX Item "frdxhi, frdxlo"
+Read the most or least (respectively) significant half of X and store it in
+\&\fIdest\fR.
+.IP "\fBfrdy\fR" 4
+.IX Item "frdy"
+Read the value of Y and store it into \fIdest\fR.
+.RE
+.RS 4
+.Sp
+Note that you can gain more local control over generation of Nios \s-1II\s0 custom
+instructions by using the \f(CW\*(C`target("custom\-\f(CIinsn\f(CW=\f(CIN\f(CW")\*(C'\fR
+and \f(CW\*(C`target("no\-custom\-\f(CIinsn\f(CW")\*(C'\fR function attributes
+or pragmas.
+.RE
+.IP "\fB\-mcustom\-fpu\-cfg=\fR\fIname\fR" 4
+.IX Item "-mcustom-fpu-cfg=name"
+This option enables a predefined, named set of custom instruction encodings
+(see \fB\-mcustom\-\fR\fIinsn\fR above).  
+Currently, the following sets are defined:
+.Sp
+\&\fB\-mcustom\-fpu\-cfg=60\-1\fR is equivalent to:
+\&\fB\-mcustom\-fmuls=252 
+\&\-mcustom\-fadds=253 
+\&\-mcustom\-fsubs=254 
+\&\-fsingle\-precision\-constant\fR
+.Sp
+\&\fB\-mcustom\-fpu\-cfg=60\-2\fR is equivalent to:
+\&\fB\-mcustom\-fmuls=252 
+\&\-mcustom\-fadds=253 
+\&\-mcustom\-fsubs=254 
+\&\-mcustom\-fdivs=255 
+\&\-fsingle\-precision\-constant\fR
+.Sp
+\&\fB\-mcustom\-fpu\-cfg=72\-3\fR is equivalent to:
+\&\fB\-mcustom\-floatus=243 
+\&\-mcustom\-fixsi=244 
+\&\-mcustom\-floatis=245 
+\&\-mcustom\-fcmpgts=246 
+\&\-mcustom\-fcmples=249 
+\&\-mcustom\-fcmpeqs=250 
+\&\-mcustom\-fcmpnes=251 
+\&\-mcustom\-fmuls=252 
+\&\-mcustom\-fadds=253 
+\&\-mcustom\-fsubs=254 
+\&\-mcustom\-fdivs=255 
+\&\-fsingle\-precision\-constant\fR
+.Sp
+Custom instruction assignments given by individual
+\&\fB\-mcustom\-\fR\fIinsn\fR\fB=\fR options override those given by
+\&\fB\-mcustom\-fpu\-cfg=\fR, regardless of the
+order of the options on the command line.
+.Sp
+Note that you can gain more local control over selection of a \s-1FPU\s0
+configuration by using the \f(CW\*(C`target("custom\-fpu\-cfg=\f(CIname\f(CW")\*(C'\fR
+function attribute
+or pragma.
+.PP
+These additional \fB\-m\fR options are available for the Altera Nios \s-1II
+ELF \s0(bare-metal) target:
+.IP "\fB\-mhal\fR" 4
+.IX Item "-mhal"
+Link with \s-1HAL BSP. \s0 This suppresses linking with the GCC-provided C runtime
+startup and termination code, and is typically used in conjunction with
+\&\fB\-msys\-crt0=\fR to specify the location of the alternate startup code
+provided by the \s-1HAL BSP.\s0
+.IP "\fB\-msmallc\fR" 4
+.IX Item "-msmallc"
+Link with a limited version of the C library, \fB\-lsmallc\fR, rather than
+Newlib.
+.IP "\fB\-msys\-crt0=\fR\fIstartfile\fR" 4
+.IX Item "-msys-crt0=startfile"
+\&\fIstartfile\fR is the file name of the startfile (crt0) to use 
+when linking.  This option is only useful in conjunction with \fB\-mhal\fR.
+.IP "\fB\-msys\-lib=\fR\fIsystemlib\fR" 4
+.IX Item "-msys-lib=systemlib"
+\&\fIsystemlib\fR is the library name of the library that provides
+low-level system calls required by the C library,
+e.g. \f(CW\*(C`read\*(C'\fR and \f(CW\*(C`write\*(C'\fR.
+This option is typically used to link with a library provided by a \s-1HAL BSP.\s0
+.PP
+\fI\s-1PDP\-11\s0 Options\fR
+.IX Subsection "PDP-11 Options"
+.PP
+These options are defined for the \s-1PDP\-11:\s0
+.IP "\fB\-mfpu\fR" 4
+.IX Item "-mfpu"
+Use hardware \s-1FPP\s0 floating point.  This is the default.  (\s-1FIS\s0 floating
+point on the \s-1PDP\-11/40\s0 is not supported.)
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Do not use hardware floating point.
+.IP "\fB\-mac0\fR" 4
+.IX Item "-mac0"
+Return floating-point results in ac0 (fr0 in Unix assembler syntax).
+.IP "\fB\-mno\-ac0\fR" 4
+.IX Item "-mno-ac0"
+Return floating-point results in memory.  This is the default.
+.IP "\fB\-m40\fR" 4
+.IX Item "-m40"
+Generate code for a \s-1PDP\-11/40.\s0
+.IP "\fB\-m45\fR" 4
+.IX Item "-m45"
+Generate code for a \s-1PDP\-11/45. \s0 This is the default.
+.IP "\fB\-m10\fR" 4
+.IX Item "-m10"
+Generate code for a \s-1PDP\-11/10.\s0
+.IP "\fB\-mbcopy\-builtin\fR" 4
+.IX Item "-mbcopy-builtin"
+Use inline \f(CW\*(C`movmemhi\*(C'\fR patterns for copying memory.  This is the
+default.
+.IP "\fB\-mbcopy\fR" 4
+.IX Item "-mbcopy"
+Do not use inline \f(CW\*(C`movmemhi\*(C'\fR patterns for copying memory.
+.IP "\fB\-mint16\fR" 4
+.IX Item "-mint16"
+.PD 0
+.IP "\fB\-mno\-int32\fR" 4
+.IX Item "-mno-int32"
+.PD
+Use 16\-bit \f(CW\*(C`int\*(C'\fR.  This is the default.
+.IP "\fB\-mint32\fR" 4
+.IX Item "-mint32"
+.PD 0
+.IP "\fB\-mno\-int16\fR" 4
+.IX Item "-mno-int16"
+.PD
+Use 32\-bit \f(CW\*(C`int\*(C'\fR.
+.IP "\fB\-mfloat64\fR" 4
+.IX Item "-mfloat64"
+.PD 0
+.IP "\fB\-mno\-float32\fR" 4
+.IX Item "-mno-float32"
+.PD
+Use 64\-bit \f(CW\*(C`float\*(C'\fR.  This is the default.
+.IP "\fB\-mfloat32\fR" 4
+.IX Item "-mfloat32"
+.PD 0
+.IP "\fB\-mno\-float64\fR" 4
+.IX Item "-mno-float64"
+.PD
+Use 32\-bit \f(CW\*(C`float\*(C'\fR.
+.IP "\fB\-mabshi\fR" 4
+.IX Item "-mabshi"
+Use \f(CW\*(C`abshi2\*(C'\fR pattern.  This is the default.
+.IP "\fB\-mno\-abshi\fR" 4
+.IX Item "-mno-abshi"
+Do not use \f(CW\*(C`abshi2\*(C'\fR pattern.
+.IP "\fB\-mbranch\-expensive\fR" 4
+.IX Item "-mbranch-expensive"
+Pretend that branches are expensive.  This is for experimenting with
+code generation only.
+.IP "\fB\-mbranch\-cheap\fR" 4
+.IX Item "-mbranch-cheap"
+Do not pretend that branches are expensive.  This is the default.
+.IP "\fB\-munix\-asm\fR" 4
+.IX Item "-munix-asm"
+Use Unix assembler syntax.  This is the default when configured for
+\&\fBpdp11\-*\-bsd\fR.
+.IP "\fB\-mdec\-asm\fR" 4
+.IX Item "-mdec-asm"
+Use \s-1DEC\s0 assembler syntax.  This is the default when configured for any
+\&\s-1PDP\-11\s0 target other than \fBpdp11\-*\-bsd\fR.
+.PP
+\fIpicoChip Options\fR
+.IX Subsection "picoChip Options"
+.PP
+These \fB\-m\fR options are defined for picoChip implementations:
+.IP "\fB\-mae=\fR\fIae_type\fR" 4
+.IX Item "-mae=ae_type"
+Set the instruction set, register set, and instruction scheduling
+parameters for array element type \fIae_type\fR.  Supported values
+for \fIae_type\fR are \fB\s-1ANY\s0\fR, \fB\s-1MUL\s0\fR, and \fB\s-1MAC\s0\fR.
+.Sp
+\&\fB\-mae=ANY\fR selects a completely generic \s-1AE\s0 type.  Code
+generated with this option runs on any of the other \s-1AE\s0 types.  The
+code is not as efficient as it would be if compiled for a specific
+\&\s-1AE\s0 type, and some types of operation (e.g., multiplication) do not
+work properly on all types of \s-1AE.\s0
+.Sp
+\&\fB\-mae=MUL\fR selects a \s-1MUL AE\s0 type.  This is the most useful \s-1AE\s0 type
+for compiled code, and is the default.
+.Sp
+\&\fB\-mae=MAC\fR selects a DSP-style \s-1MAC AE. \s0 Code compiled with this
+option may suffer from poor performance of byte (char) manipulation,
+since the \s-1DSP AE\s0 does not provide hardware support for byte load/stores.
+.IP "\fB\-msymbol\-as\-address\fR" 4
+.IX Item "-msymbol-as-address"
+Enable the compiler to directly use a symbol name as an address in a
+load/store instruction, without first loading it into a
+register.  Typically, the use of this option generates larger
+programs, which run faster than when the option isn't used.  However, the
+results vary from program to program, so it is left as a user option,
+rather than being permanently enabled.
+.IP "\fB\-mno\-inefficient\-warnings\fR" 4
+.IX Item "-mno-inefficient-warnings"
+Disables warnings about the generation of inefficient code.  These
+warnings can be generated, for example, when compiling code that
+performs byte-level memory operations on the \s-1MAC AE\s0 type.  The \s-1MAC AE\s0 has
+no hardware support for byte-level memory operations, so all byte
+load/stores must be synthesized from word load/store operations.  This is
+inefficient and a warning is generated to indicate
+that you should rewrite the code to avoid byte operations, or to target
+an \s-1AE\s0 type that has the necessary hardware support.  This option disables
+these warnings.
+.PP
+\fIPowerPC Options\fR
+.IX Subsection "PowerPC Options"
+.PP
+These are listed under
+.PP
+\fI\s-1RL78\s0 Options\fR
+.IX Subsection "RL78 Options"
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Links in additional target libraries to support operation within a
+simulator.
+.IP "\fB\-mmul=none\fR" 4
+.IX Item "-mmul=none"
+.PD 0
+.IP "\fB\-mmul=g13\fR" 4
+.IX Item "-mmul=g13"
+.IP "\fB\-mmul=rl78\fR" 4
+.IX Item "-mmul=rl78"
+.PD
+Specifies the type of hardware multiplication support to be used.  The
+default is \f(CW\*(C`none\*(C'\fR, which uses software multiplication functions.
+The \f(CW\*(C`g13\*(C'\fR option is for the hardware multiply/divide peripheral
+only on the \s-1RL78/G13\s0 targets.  The \f(CW\*(C`rl78\*(C'\fR option is for the
+standard hardware multiplication defined in the \s-1RL78\s0 software manual.
+.PP
+\fI\s-1IBM RS/6000\s0 and PowerPC Options\fR
+.IX Subsection "IBM RS/6000 and PowerPC Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1IBM RS/6000\s0 and PowerPC:
+.IP "\fB\-mpowerpc\-gpopt\fR" 4
+.IX Item "-mpowerpc-gpopt"
+.PD 0
+.IP "\fB\-mno\-powerpc\-gpopt\fR" 4
+.IX Item "-mno-powerpc-gpopt"
+.IP "\fB\-mpowerpc\-gfxopt\fR" 4
+.IX Item "-mpowerpc-gfxopt"
+.IP "\fB\-mno\-powerpc\-gfxopt\fR" 4
+.IX Item "-mno-powerpc-gfxopt"
+.IP "\fB\-mpowerpc64\fR" 4
+.IX Item "-mpowerpc64"
+.IP "\fB\-mno\-powerpc64\fR" 4
+.IX Item "-mno-powerpc64"
+.IP "\fB\-mmfcrf\fR" 4
+.IX Item "-mmfcrf"
+.IP "\fB\-mno\-mfcrf\fR" 4
+.IX Item "-mno-mfcrf"
+.IP "\fB\-mpopcntb\fR" 4
+.IX Item "-mpopcntb"
+.IP "\fB\-mno\-popcntb\fR" 4
+.IX Item "-mno-popcntb"
+.IP "\fB\-mpopcntd\fR" 4
+.IX Item "-mpopcntd"
+.IP "\fB\-mno\-popcntd\fR" 4
+.IX Item "-mno-popcntd"
+.IP "\fB\-mfprnd\fR" 4
+.IX Item "-mfprnd"
+.IP "\fB\-mno\-fprnd\fR" 4
+.IX Item "-mno-fprnd"
+.IP "\fB\-mcmpb\fR" 4
+.IX Item "-mcmpb"
+.IP "\fB\-mno\-cmpb\fR" 4
+.IX Item "-mno-cmpb"
+.IP "\fB\-mmfpgpr\fR" 4
+.IX Item "-mmfpgpr"
+.IP "\fB\-mno\-mfpgpr\fR" 4
+.IX Item "-mno-mfpgpr"
+.IP "\fB\-mhard\-dfp\fR" 4
+.IX Item "-mhard-dfp"
+.IP "\fB\-mno\-hard\-dfp\fR" 4
+.IX Item "-mno-hard-dfp"
+.PD
+You use these options to specify which instructions are available on the
+processor you are using.  The default value of these options is
+determined when configuring \s-1GCC. \s0 Specifying the
+\&\fB\-mcpu=\fR\fIcpu_type\fR overrides the specification of these
+options.  We recommend you use the \fB\-mcpu=\fR\fIcpu_type\fR option
+rather than the options listed above.
+.Sp
+Specifying \fB\-mpowerpc\-gpopt\fR allows
+\&\s-1GCC\s0 to use the optional PowerPC architecture instructions in the
+General Purpose group, including floating-point square root.  Specifying
+\&\fB\-mpowerpc\-gfxopt\fR allows \s-1GCC\s0 to
+use the optional PowerPC architecture instructions in the Graphics
+group, including floating-point select.
+.Sp
+The \fB\-mmfcrf\fR option allows \s-1GCC\s0 to generate the move from
+condition register field instruction implemented on the \s-1POWER4\s0
+processor and other processors that support the PowerPC V2.01
+architecture.
+The \fB\-mpopcntb\fR option allows \s-1GCC\s0 to generate the popcount and
+double-precision \s-1FP\s0 reciprocal estimate instruction implemented on the
+\&\s-1POWER5\s0 processor and other processors that support the PowerPC V2.02
+architecture.
+The \fB\-mpopcntd\fR option allows \s-1GCC\s0 to generate the popcount
+instruction implemented on the \s-1POWER7\s0 processor and other processors
+that support the PowerPC V2.06 architecture.
+The \fB\-mfprnd\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 round to
+integer instructions implemented on the \s-1POWER5+\s0 processor and other
+processors that support the PowerPC V2.03 architecture.
+The \fB\-mcmpb\fR option allows \s-1GCC\s0 to generate the compare bytes
+instruction implemented on the \s-1POWER6\s0 processor and other processors
+that support the PowerPC V2.05 architecture.
+The \fB\-mmfpgpr\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 move to/from
+general-purpose register instructions implemented on the \s-1POWER6X\s0
+processor and other processors that support the extended PowerPC V2.05
+architecture.
+The \fB\-mhard\-dfp\fR option allows \s-1GCC\s0 to generate the decimal
+floating-point instructions implemented on some \s-1POWER\s0 processors.
+.Sp
+The \fB\-mpowerpc64\fR option allows \s-1GCC\s0 to generate the additional
+64\-bit instructions that are found in the full PowerPC64 architecture
+and to treat GPRs as 64\-bit, doubleword quantities.  \s-1GCC\s0 defaults to
+\&\fB\-mno\-powerpc64\fR.
+.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
+.IX Item "-mcpu=cpu_type"
+Set architecture type, register usage, and
+instruction scheduling parameters for machine type \fIcpu_type\fR.
+Supported values for \fIcpu_type\fR are \fB401\fR, \fB403\fR,
+\&\fB405\fR, \fB405fp\fR, \fB440\fR, \fB440fp\fR, \fB464\fR, \fB464fp\fR,
+\&\fB476\fR, \fB476fp\fR, \fB505\fR, \fB601\fR, \fB602\fR, \fB603\fR,
+\&\fB603e\fR, \fB604\fR, \fB604e\fR, \fB620\fR, \fB630\fR, \fB740\fR,
+\&\fB7400\fR, \fB7450\fR, \fB750\fR, \fB801\fR, \fB821\fR, \fB823\fR,
+\&\fB860\fR, \fB970\fR, \fB8540\fR, \fBa2\fR, \fBe300c2\fR,
+\&\fBe300c3\fR, \fBe500mc\fR, \fBe500mc64\fR, \fBe5500\fR,
+\&\fBe6500\fR, \fBec603e\fR, \fBG3\fR, \fBG4\fR, \fBG5\fR,
+\&\fBtitan\fR, \fBpower3\fR, \fBpower4\fR, \fBpower5\fR, \fBpower5+\fR,
+\&\fBpower6\fR, \fBpower6x\fR, \fBpower7\fR, \fBpower8\fR, \fBpowerpc\fR,
+\&\fBpowerpc64\fR, and \fBrs64\fR.
+.Sp
+\&\fB\-mcpu=powerpc\fR, and \fB\-mcpu=powerpc64\fR specify pure 32\-bit
+PowerPC and 64\-bit PowerPC architecture machine
+types, with an appropriate, generic processor model assumed for
+scheduling purposes.
+.Sp
+The other options specify a specific processor.  Code generated under
+those options runs best on that processor, and may not run at all on
+others.
+.Sp
+The \fB\-mcpu\fR options automatically enable or disable the
+following options:
+.Sp
+\&\fB\-maltivec  \-mfprnd  \-mhard\-float  \-mmfcrf  \-mmultiple 
+\&\-mpopcntb \-mpopcntd  \-mpowerpc64 
+\&\-mpowerpc\-gpopt  \-mpowerpc\-gfxopt  \-msingle\-float \-mdouble\-float 
+\&\-msimple\-fpu \-mstring  \-mmulhw  \-mdlmzb  \-mmfpgpr \-mvsx 
+\&\-mcrypto \-mdirect\-move \-mpower8\-fusion \-mpower8\-vector 
+\&\-mquad\-memory \-mquad\-memory\-atomic\fR
+.Sp
+The particular options set for any particular \s-1CPU\s0 varies between
+compiler versions, depending on what setting seems to produce optimal
+code for that \s-1CPU\s0; it doesn't necessarily reflect the actual hardware's
+capabilities.  If you wish to set an individual option to a particular
+value, you may specify it after the \fB\-mcpu\fR option, like
+\&\fB\-mcpu=970 \-mno\-altivec\fR.
+.Sp
+On \s-1AIX,\s0 the \fB\-maltivec\fR and \fB\-mpowerpc64\fR options are
+not enabled or disabled by the \fB\-mcpu\fR option at present because
+\&\s-1AIX\s0 does not have full support for these options.  You may still
+enable or disable them individually if you're sure it'll work in your
+environment.
+.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
+.IX Item "-mtune=cpu_type"
+Set the instruction scheduling parameters for machine type
+\&\fIcpu_type\fR, but do not set the architecture type or register usage,
+as \fB\-mcpu=\fR\fIcpu_type\fR does.  The same
+values for \fIcpu_type\fR are used for \fB\-mtune\fR as for
+\&\fB\-mcpu\fR.  If both are specified, the code generated uses the
+architecture and registers set by \fB\-mcpu\fR, but the
+scheduling parameters set by \fB\-mtune\fR.
+.IP "\fB\-mcmodel=small\fR" 4
+.IX Item "-mcmodel=small"
+Generate PowerPC64 code for the small model: The \s-1TOC\s0 is limited to
+64k.
+.IP "\fB\-mcmodel=medium\fR" 4
+.IX Item "-mcmodel=medium"
+Generate PowerPC64 code for the medium model: The \s-1TOC\s0 and other static
+data may be up to a total of 4G in size.
+.IP "\fB\-mcmodel=large\fR" 4
+.IX Item "-mcmodel=large"
+Generate PowerPC64 code for the large model: The \s-1TOC\s0 may be up to 4G
+in size.  Other data and code is only limited by the 64\-bit address
+space.
+.IP "\fB\-maltivec\fR" 4
+.IX Item "-maltivec"
+.PD 0
+.IP "\fB\-mno\-altivec\fR" 4
+.IX Item "-mno-altivec"
+.PD
+Generate code that uses (does not use) AltiVec instructions, and also
+enable the use of built-in functions that allow more direct access to
+the AltiVec instruction set.  You may also need to set
+\&\fB\-mabi=altivec\fR to adjust the current \s-1ABI\s0 with AltiVec \s-1ABI\s0
+enhancements.
+.Sp
+When \fB\-maltivec\fR is used, rather than \fB\-maltivec=le\fR or
+\&\fB\-maltivec=be\fR, the element order for Altivec intrinsics such
+as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and \f(CW\*(C`vec_insert\*(C'\fR will
+match array element order corresponding to the endianness of the
+target.  That is, element zero identifies the leftmost element in a
+vector register when targeting a big-endian platform, and identifies
+the rightmost element in a vector register when targeting a
+little-endian platform.
+.IP "\fB\-maltivec=be\fR" 4
+.IX Item "-maltivec=be"
+Generate Altivec instructions using big-endian element order,
+regardless of whether the target is big\- or little-endian.  This is
+the default when targeting a big-endian platform.
+.Sp
+The element order is used to interpret element numbers in Altivec
+intrinsics such as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and
+\&\f(CW\*(C`vec_insert\*(C'\fR.  By default, these will match array element order
+corresponding to the endianness for the target.
+.IP "\fB\-maltivec=le\fR" 4
+.IX Item "-maltivec=le"
+Generate Altivec instructions using little-endian element order,
+regardless of whether the target is big\- or little-endian.  This is
+the default when targeting a little-endian platform.  This option is
+currently ignored when targeting a big-endian platform.
+.Sp
+The element order is used to interpret element numbers in Altivec
+intrinsics such as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and
+\&\f(CW\*(C`vec_insert\*(C'\fR.  By default, these will match array element order
+corresponding to the endianness for the target.
+.IP "\fB\-mvrsave\fR" 4
+.IX Item "-mvrsave"
+.PD 0
+.IP "\fB\-mno\-vrsave\fR" 4
+.IX Item "-mno-vrsave"
+.PD
+Generate \s-1VRSAVE\s0 instructions when generating AltiVec code.
+.IP "\fB\-mgen\-cell\-microcode\fR" 4
+.IX Item "-mgen-cell-microcode"
+Generate Cell microcode instructions.
+.IP "\fB\-mwarn\-cell\-microcode\fR" 4
+.IX Item "-mwarn-cell-microcode"
+Warn when a Cell microcode instruction is emitted.  An example
+of a Cell microcode instruction is a variable shift.
+.IP "\fB\-msecure\-plt\fR" 4
+.IX Item "-msecure-plt"
+Generate code that allows \fBld\fR and \fBld.so\fR
+to build executables and shared
+libraries with non-executable \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR sections.
+This is a PowerPC
+32\-bit \s-1SYSV ABI\s0 option.
+.IP "\fB\-mbss\-plt\fR" 4
+.IX Item "-mbss-plt"
+Generate code that uses a \s-1BSS \s0\f(CW\*(C`.plt\*(C'\fR section that \fBld.so\fR
+fills in, and
+requires \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR
+sections that are both writable and executable.
+This is a PowerPC 32\-bit \s-1SYSV ABI\s0 option.
+.IP "\fB\-misel\fR" 4
+.IX Item "-misel"
+.PD 0
+.IP "\fB\-mno\-isel\fR" 4
+.IX Item "-mno-isel"
+.PD
+This switch enables or disables the generation of \s-1ISEL\s0 instructions.
+.IP "\fB\-misel=\fR\fIyes/no\fR" 4
+.IX Item "-misel=yes/no"
+This switch has been deprecated.  Use \fB\-misel\fR and
+\&\fB\-mno\-isel\fR instead.
+.IP "\fB\-mspe\fR" 4
+.IX Item "-mspe"
+.PD 0
+.IP "\fB\-mno\-spe\fR" 4
+.IX Item "-mno-spe"
+.PD
+This switch enables or disables the generation of \s-1SPE\s0 simd
+instructions.
+.IP "\fB\-mpaired\fR" 4
+.IX Item "-mpaired"
+.PD 0
+.IP "\fB\-mno\-paired\fR" 4
+.IX Item "-mno-paired"
+.PD
+This switch enables or disables the generation of \s-1PAIRED\s0 simd
+instructions.
+.IP "\fB\-mspe=\fR\fIyes/no\fR" 4
+.IX Item "-mspe=yes/no"
+This option has been deprecated.  Use \fB\-mspe\fR and
+\&\fB\-mno\-spe\fR instead.
+.IP "\fB\-mvsx\fR" 4
+.IX Item "-mvsx"
+.PD 0
+.IP "\fB\-mno\-vsx\fR" 4
+.IX Item "-mno-vsx"
+.PD
+Generate code that uses (does not use) vector/scalar (\s-1VSX\s0)
+instructions, and also enable the use of built-in functions that allow
+more direct access to the \s-1VSX\s0 instruction set.
+.IP "\fB\-mcrypto\fR" 4
+.IX Item "-mcrypto"
+.PD 0
+.IP "\fB\-mno\-crypto\fR" 4
+.IX Item "-mno-crypto"
+.PD
+Enable the use (disable) of the built-in functions that allow direct
+access to the cryptographic instructions that were added in version
+2.07 of the PowerPC \s-1ISA.\s0
+.IP "\fB\-mdirect\-move\fR" 4
+.IX Item "-mdirect-move"
+.PD 0
+.IP "\fB\-mno\-direct\-move\fR" 4
+.IX Item "-mno-direct-move"
+.PD
+Generate code that uses (does not use) the instructions to move data
+between the general purpose registers and the vector/scalar (\s-1VSX\s0)
+registers that were added in version 2.07 of the PowerPC \s-1ISA.\s0
+.IP "\fB\-mpower8\-fusion\fR" 4
+.IX Item "-mpower8-fusion"
+.PD 0
+.IP "\fB\-mno\-power8\-fusion\fR" 4
+.IX Item "-mno-power8-fusion"
+.PD
+Generate code that keeps (does not keeps) some integer operations
+adjacent so that the instructions can be fused together on power8 and
+later processors.
+.IP "\fB\-mpower8\-vector\fR" 4
+.IX Item "-mpower8-vector"
+.PD 0
+.IP "\fB\-mno\-power8\-vector\fR" 4
+.IX Item "-mno-power8-vector"
+.PD
+Generate code that uses (does not use) the vector and scalar
+instructions that were added in version 2.07 of the PowerPC \s-1ISA. \s0 Also
+enable the use of built-in functions that allow more direct access to
+the vector instructions.
+.IP "\fB\-mquad\-memory\fR" 4
+.IX Item "-mquad-memory"
+.PD 0
+.IP "\fB\-mno\-quad\-memory\fR" 4
+.IX Item "-mno-quad-memory"
+.PD
+Generate code that uses (does not use) the non-atomic quad word memory
+instructions.  The \fB\-mquad\-memory\fR option requires use of
+64\-bit mode.
+.IP "\fB\-mquad\-memory\-atomic\fR" 4
+.IX Item "-mquad-memory-atomic"
+.PD 0
+.IP "\fB\-mno\-quad\-memory\-atomic\fR" 4
+.IX Item "-mno-quad-memory-atomic"
+.PD
+Generate code that uses (does not use) the atomic quad word memory
+instructions.  The \fB\-mquad\-memory\-atomic\fR option requires use of
+64\-bit mode.
+.IP "\fB\-mfloat\-gprs=\fR\fIyes/single/double/no\fR" 4
+.IX Item "-mfloat-gprs=yes/single/double/no"
+.PD 0
+.IP "\fB\-mfloat\-gprs\fR" 4
+.IX Item "-mfloat-gprs"
+.PD
+This switch enables or disables the generation of floating-point
+operations on the general-purpose registers for architectures that
+support it.
+.Sp
+The argument \fIyes\fR or \fIsingle\fR enables the use of
+single-precision floating-point operations.
+.Sp
+The argument \fIdouble\fR enables the use of single and
+double-precision floating-point operations.
+.Sp
+The argument \fIno\fR disables floating-point operations on the
+general-purpose registers.
+.Sp
+This option is currently only available on the MPC854x.
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+.PD 0
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.PD
+Generate code for 32\-bit or 64\-bit environments of Darwin and \s-1SVR4\s0
+targets (including GNU/Linux).  The 32\-bit environment sets int, long
+and pointer to 32 bits and generates code that runs on any PowerPC
+variant.  The 64\-bit environment sets int to 32 bits and long and
+pointer to 64 bits, and generates code for PowerPC64, as for
+\&\fB\-mpowerpc64\fR.
+.IP "\fB\-mfull\-toc\fR" 4
+.IX Item "-mfull-toc"
+.PD 0
+.IP "\fB\-mno\-fp\-in\-toc\fR" 4
+.IX Item "-mno-fp-in-toc"
+.IP "\fB\-mno\-sum\-in\-toc\fR" 4
+.IX Item "-mno-sum-in-toc"
+.IP "\fB\-mminimal\-toc\fR" 4
+.IX Item "-mminimal-toc"
+.PD
+Modify generation of the \s-1TOC \s0(Table Of Contents), which is created for
+every executable file.  The \fB\-mfull\-toc\fR option is selected by
+default.  In that case, \s-1GCC\s0 allocates at least one \s-1TOC\s0 entry for
+each unique non-automatic variable reference in your program.  \s-1GCC\s0
+also places floating-point constants in the \s-1TOC. \s0 However, only
+16,384 entries are available in the \s-1TOC.\s0
+.Sp
+If you receive a linker error message that saying you have overflowed
+the available \s-1TOC\s0 space, you can reduce the amount of \s-1TOC\s0 space used
+with the \fB\-mno\-fp\-in\-toc\fR and \fB\-mno\-sum\-in\-toc\fR options.
+\&\fB\-mno\-fp\-in\-toc\fR prevents \s-1GCC\s0 from putting floating-point
+constants in the \s-1TOC\s0 and \fB\-mno\-sum\-in\-toc\fR forces \s-1GCC\s0 to
+generate code to calculate the sum of an address and a constant at
+run time instead of putting that sum into the \s-1TOC. \s0 You may specify one
+or both of these options.  Each causes \s-1GCC\s0 to produce very slightly
+slower and larger code at the expense of conserving \s-1TOC\s0 space.
+.Sp
+If you still run out of space in the \s-1TOC\s0 even when you specify both of
+these options, specify \fB\-mminimal\-toc\fR instead.  This option causes
+\&\s-1GCC\s0 to make only one \s-1TOC\s0 entry for every file.  When you specify this
+option, \s-1GCC\s0 produces code that is slower and larger but which
+uses extremely little \s-1TOC\s0 space.  You may wish to use this option
+only on files that contain less frequently-executed code.
+.IP "\fB\-maix64\fR" 4
+.IX Item "-maix64"
+.PD 0
+.IP "\fB\-maix32\fR" 4
+.IX Item "-maix32"
+.PD
+Enable 64\-bit \s-1AIX ABI\s0 and calling convention: 64\-bit pointers, 64\-bit
+\&\f(CW\*(C`long\*(C'\fR type, and the infrastructure needed to support them.
+Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR,
+while \fB\-maix32\fR disables the 64\-bit \s-1ABI\s0 and
+implies \fB\-mno\-powerpc64\fR.  \s-1GCC\s0 defaults to \fB\-maix32\fR.
+.IP "\fB\-mxl\-compat\fR" 4
+.IX Item "-mxl-compat"
+.PD 0
+.IP "\fB\-mno\-xl\-compat\fR" 4
+.IX Item "-mno-xl-compat"
+.PD
+Produce code that conforms more closely to \s-1IBM XL\s0 compiler semantics
+when using AIX-compatible \s-1ABI. \s0 Pass floating-point arguments to
+prototyped functions beyond the register save area (\s-1RSA\s0) on the stack
+in addition to argument FPRs.  Do not assume that most significant
+double in 128\-bit long double value is properly rounded when comparing
+values and converting to double.  Use \s-1XL\s0 symbol names for long double
+support routines.
+.Sp
+The \s-1AIX\s0 calling convention was extended but not initially documented to
+handle an obscure K&R C case of calling a function that takes the
+address of its arguments with fewer arguments than declared.  \s-1IBM XL\s0
+compilers access floating-point arguments that do not fit in the
+\&\s-1RSA\s0 from the stack when a subroutine is compiled without
+optimization.  Because always storing floating-point arguments on the
+stack is inefficient and rarely needed, this option is not enabled by
+default and only is necessary when calling subroutines compiled by \s-1IBM
+XL\s0 compilers without optimization.
+.IP "\fB\-mpe\fR" 4
+.IX Item "-mpe"
+Support \fI\s-1IBM RS/6000 SP\s0\fR \fIParallel Environment\fR (\s-1PE\s0).  Link an
+application written to use message passing with special startup code to
+enable the application to run.  The system must have \s-1PE\s0 installed in the
+standard location (\fI/usr/lpp/ppe.poe/\fR), or the \fIspecs\fR file
+must be overridden with the \fB\-specs=\fR option to specify the
+appropriate directory location.  The Parallel Environment does not
+support threads, so the \fB\-mpe\fR option and the \fB\-pthread\fR
+option are incompatible.
+.IP "\fB\-malign\-natural\fR" 4
+.IX Item "-malign-natural"
+.PD 0
+.IP "\fB\-malign\-power\fR" 4
+.IX Item "-malign-power"
+.PD
+On \s-1AIX,\s0 32\-bit Darwin, and 64\-bit PowerPC GNU/Linux, the option
+\&\fB\-malign\-natural\fR overrides the ABI-defined alignment of larger
+types, such as floating-point doubles, on their natural size-based boundary.
+The option \fB\-malign\-power\fR instructs \s-1GCC\s0 to follow the ABI-specified
+alignment rules.  \s-1GCC\s0 defaults to the standard alignment defined in the \s-1ABI.\s0
+.Sp
+On 64\-bit Darwin, natural alignment is the default, and \fB\-malign\-power\fR
+is not supported.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD 0
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD
+Generate code that does not use (uses) the floating-point register set.
+Software floating-point emulation is provided if you use the
+\&\fB\-msoft\-float\fR option, and pass the option to \s-1GCC\s0 when linking.
+.IP "\fB\-msingle\-float\fR" 4
+.IX Item "-msingle-float"
+.PD 0
+.IP "\fB\-mdouble\-float\fR" 4
+.IX Item "-mdouble-float"
+.PD
+Generate code for single\- or double-precision floating-point operations.
+\&\fB\-mdouble\-float\fR implies \fB\-msingle\-float\fR.
+.IP "\fB\-msimple\-fpu\fR" 4
+.IX Item "-msimple-fpu"
+Do not generate \f(CW\*(C`sqrt\*(C'\fR and \f(CW\*(C`div\*(C'\fR instructions for hardware
+floating-point unit.
+.IP "\fB\-mfpu=\fR\fIname\fR" 4
+.IX Item "-mfpu=name"
+Specify type of floating-point unit.  Valid values for \fIname\fR are
+\&\fBsp_lite\fR (equivalent to \fB\-msingle\-float \-msimple\-fpu\fR),
+\&\fBdp_lite\fR (equivalent to \fB\-mdouble\-float \-msimple\-fpu\fR),
+\&\fBsp_full\fR (equivalent to \fB\-msingle\-float\fR),
+and \fBdp_full\fR (equivalent to \fB\-mdouble\-float\fR).
+.IP "\fB\-mxilinx\-fpu\fR" 4
+.IX Item "-mxilinx-fpu"
+Perform optimizations for the floating-point unit on Xilinx \s-1PPC 405/440.\s0
+.IP "\fB\-mmultiple\fR" 4
+.IX Item "-mmultiple"
+.PD 0
+.IP "\fB\-mno\-multiple\fR" 4
+.IX Item "-mno-multiple"
+.PD
+Generate code that uses (does not use) the load multiple word
+instructions and the store multiple word instructions.  These
+instructions are generated by default on \s-1POWER\s0 systems, and not
+generated on PowerPC systems.  Do not use \fB\-mmultiple\fR on little-endian
+PowerPC systems, since those instructions do not work when the
+processor is in little-endian mode.  The exceptions are \s-1PPC740\s0 and
+\&\s-1PPC750\s0 which permit these instructions in little-endian mode.
+.IP "\fB\-mstring\fR" 4
+.IX Item "-mstring"
+.PD 0
+.IP "\fB\-mno\-string\fR" 4
+.IX Item "-mno-string"
+.PD
+Generate code that uses (does not use) the load string instructions
+and the store string word instructions to save multiple registers and
+do small block moves.  These instructions are generated by default on
+\&\s-1POWER\s0 systems, and not generated on PowerPC systems.  Do not use
+\&\fB\-mstring\fR on little-endian PowerPC systems, since those
+instructions do not work when the processor is in little-endian mode.
+The exceptions are \s-1PPC740\s0 and \s-1PPC750\s0 which permit these instructions
+in little-endian mode.
+.IP "\fB\-mupdate\fR" 4
+.IX Item "-mupdate"
+.PD 0
+.IP "\fB\-mno\-update\fR" 4
+.IX Item "-mno-update"
+.PD
+Generate code that uses (does not use) the load or store instructions
+that update the base register to the address of the calculated memory
+location.  These instructions are generated by default.  If you use
+\&\fB\-mno\-update\fR, there is a small window between the time that the
+stack pointer is updated and the address of the previous frame is
+stored, which means code that walks the stack frame across interrupts or
+signals may get corrupted data.
+.IP "\fB\-mavoid\-indexed\-addresses\fR" 4
+.IX Item "-mavoid-indexed-addresses"
+.PD 0
+.IP "\fB\-mno\-avoid\-indexed\-addresses\fR" 4
+.IX Item "-mno-avoid-indexed-addresses"
+.PD
+Generate code that tries to avoid (not avoid) the use of indexed load
+or store instructions. These instructions can incur a performance
+penalty on Power6 processors in certain situations, such as when
+stepping through large arrays that cross a 16M boundary.  This option
+is enabled by default when targeting Power6 and disabled otherwise.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Generate code that uses (does not use) the floating-point multiply and
+accumulate instructions.  These instructions are generated by default
+if hardware floating point is used.  The machine-dependent
+\&\fB\-mfused\-madd\fR option is now mapped to the machine-independent
+\&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
+mapped to \fB\-ffp\-contract=off\fR.
+.IP "\fB\-mmulhw\fR" 4
+.IX Item "-mmulhw"
+.PD 0
+.IP "\fB\-mno\-mulhw\fR" 4
+.IX Item "-mno-mulhw"
+.PD
+Generate code that uses (does not use) the half-word multiply and
+multiply-accumulate instructions on the \s-1IBM 405, 440, 464\s0 and 476 processors.
+These instructions are generated by default when targeting those
+processors.
+.IP "\fB\-mdlmzb\fR" 4
+.IX Item "-mdlmzb"
+.PD 0
+.IP "\fB\-mno\-dlmzb\fR" 4
+.IX Item "-mno-dlmzb"
+.PD
+Generate code that uses (does not use) the string-search \fBdlmzb\fR
+instruction on the \s-1IBM 405, 440, 464\s0 and 476 processors.  This instruction is
+generated by default when targeting those processors.
+.IP "\fB\-mno\-bit\-align\fR" 4
+.IX Item "-mno-bit-align"
+.PD 0
+.IP "\fB\-mbit\-align\fR" 4
+.IX Item "-mbit-align"
+.PD
+On System V.4 and embedded PowerPC systems do not (do) force structures
+and unions that contain bit-fields to be aligned to the base type of the
+bit-field.
+.Sp
+For example, by default a structure containing nothing but 8
+\&\f(CW\*(C`unsigned\*(C'\fR bit-fields of length 1 is aligned to a 4\-byte
+boundary and has a size of 4 bytes.  By using \fB\-mno\-bit\-align\fR,
+the structure is aligned to a 1\-byte boundary and is 1 byte in
+size.
+.IP "\fB\-mno\-strict\-align\fR" 4
+.IX Item "-mno-strict-align"
+.PD 0
+.IP "\fB\-mstrict\-align\fR" 4
+.IX Item "-mstrict-align"
+.PD
+On System V.4 and embedded PowerPC systems do not (do) assume that
+unaligned memory references are handled by the system.
+.IP "\fB\-mrelocatable\fR" 4
+.IX Item "-mrelocatable"
+.PD 0
+.IP "\fB\-mno\-relocatable\fR" 4
+.IX Item "-mno-relocatable"
+.PD
+Generate code that allows (does not allow) a static executable to be
+relocated to a different address at run time.  A simple embedded
+PowerPC system loader should relocate the entire contents of
+\&\f(CW\*(C`.got2\*(C'\fR and 4\-byte locations listed in the \f(CW\*(C`.fixup\*(C'\fR section,
+a table of 32\-bit addresses generated by this option.  For this to
+work, all objects linked together must be compiled with
+\&\fB\-mrelocatable\fR or \fB\-mrelocatable\-lib\fR.
+\&\fB\-mrelocatable\fR code aligns the stack to an 8\-byte boundary.
+.IP "\fB\-mrelocatable\-lib\fR" 4
+.IX Item "-mrelocatable-lib"
+.PD 0
+.IP "\fB\-mno\-relocatable\-lib\fR" 4
+.IX Item "-mno-relocatable-lib"
+.PD
+Like \fB\-mrelocatable\fR, \fB\-mrelocatable\-lib\fR generates a
+\&\f(CW\*(C`.fixup\*(C'\fR section to allow static executables to be relocated at
+run time, but \fB\-mrelocatable\-lib\fR does not use the smaller stack
+alignment of \fB\-mrelocatable\fR.  Objects compiled with
+\&\fB\-mrelocatable\-lib\fR may be linked with objects compiled with
+any combination of the \fB\-mrelocatable\fR options.
+.IP "\fB\-mno\-toc\fR" 4
+.IX Item "-mno-toc"
+.PD 0
+.IP "\fB\-mtoc\fR" 4
+.IX Item "-mtoc"
+.PD
+On System V.4 and embedded PowerPC systems do not (do) assume that
+register 2 contains a pointer to a global area pointing to the addresses
+used in the program.
+.IP "\fB\-mlittle\fR" 4
+.IX Item "-mlittle"
+.PD 0
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+.PD
+On System V.4 and embedded PowerPC systems compile code for the
+processor in little-endian mode.  The \fB\-mlittle\-endian\fR option is
+the same as \fB\-mlittle\fR.
+.IP "\fB\-mbig\fR" 4
+.IX Item "-mbig"
+.PD 0
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+.PD
+On System V.4 and embedded PowerPC systems compile code for the
+processor in big-endian mode.  The \fB\-mbig\-endian\fR option is
+the same as \fB\-mbig\fR.
+.IP "\fB\-mdynamic\-no\-pic\fR" 4
+.IX Item "-mdynamic-no-pic"
+On Darwin and Mac \s-1OS X\s0 systems, compile code so that it is not
+relocatable, but that its external references are relocatable.  The
+resulting code is suitable for applications, but not shared
+libraries.
+.IP "\fB\-msingle\-pic\-base\fR" 4
+.IX Item "-msingle-pic-base"
+Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
+loading it in the prologue for each function.  The runtime system is
+responsible for initializing this register with an appropriate value
+before execution begins.
+.IP "\fB\-mprioritize\-restricted\-insns=\fR\fIpriority\fR" 4
+.IX Item "-mprioritize-restricted-insns=priority"
+This option controls the priority that is assigned to
+dispatch-slot restricted instructions during the second scheduling
+pass.  The argument \fIpriority\fR takes the value \fB0\fR, \fB1\fR,
+or \fB2\fR to assign no, highest, or second-highest (respectively) 
+priority to dispatch-slot restricted
+instructions.
+.IP "\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR" 4
+.IX Item "-msched-costly-dep=dependence_type"
+This option controls which dependences are considered costly
+by the target during instruction scheduling.  The argument
+\&\fIdependence_type\fR takes one of the following values:
+.RS 4
+.IP "\fBno\fR" 4
+.IX Item "no"
+No dependence is costly.
+.IP "\fBall\fR" 4
+.IX Item "all"
+All dependences are costly.
+.IP "\fBtrue_store_to_load\fR" 4
+.IX Item "true_store_to_load"
+A true dependence from store to load is costly.
+.IP "\fBstore_to_load\fR" 4
+.IX Item "store_to_load"
+Any dependence from store to load is costly.
+.IP "\fInumber\fR" 4
+.IX Item "number"
+Any dependence for which the latency is greater than or equal to 
+\&\fInumber\fR is costly.
+.RE
+.RS 4
+.RE
+.IP "\fB\-minsert\-sched\-nops=\fR\fIscheme\fR" 4
+.IX Item "-minsert-sched-nops=scheme"
+This option controls which \s-1NOP\s0 insertion scheme is used during
+the second scheduling pass.  The argument \fIscheme\fR takes one of the
+following values:
+.RS 4
+.IP "\fBno\fR" 4
+.IX Item "no"
+Don't insert NOPs.
+.IP "\fBpad\fR" 4
+.IX Item "pad"
+Pad with NOPs any dispatch group that has vacant issue slots,
+according to the scheduler's grouping.
+.IP "\fBregroup_exact\fR" 4
+.IX Item "regroup_exact"
+Insert NOPs to force costly dependent insns into
+separate groups.  Insert exactly as many NOPs as needed to force an insn
+to a new group, according to the estimated processor grouping.
+.IP "\fInumber\fR" 4
+.IX Item "number"
+Insert NOPs to force costly dependent insns into
+separate groups.  Insert \fInumber\fR NOPs to force an insn to a new group.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mcall\-sysv\fR" 4
+.IX Item "-mcall-sysv"
+On System V.4 and embedded PowerPC systems compile code using calling
+conventions that adhere to the March 1995 draft of the System V
+Application Binary Interface, PowerPC processor supplement.  This is the
+default unless you configured \s-1GCC\s0 using \fBpowerpc\-*\-eabiaix\fR.
+.IP "\fB\-mcall\-sysv\-eabi\fR" 4
+.IX Item "-mcall-sysv-eabi"
+.PD 0
+.IP "\fB\-mcall\-eabi\fR" 4
+.IX Item "-mcall-eabi"
+.PD
+Specify both \fB\-mcall\-sysv\fR and \fB\-meabi\fR options.
+.IP "\fB\-mcall\-sysv\-noeabi\fR" 4
+.IX Item "-mcall-sysv-noeabi"
+Specify both \fB\-mcall\-sysv\fR and \fB\-mno\-eabi\fR options.
+.IP "\fB\-mcall\-aixdesc\fR" 4
+.IX Item "-mcall-aixdesc"
+On System V.4 and embedded PowerPC systems compile code for the \s-1AIX\s0
+operating system.
+.IP "\fB\-mcall\-linux\fR" 4
+.IX Item "-mcall-linux"
+On System V.4 and embedded PowerPC systems compile code for the
+Linux-based \s-1GNU\s0 system.
+.IP "\fB\-mcall\-freebsd\fR" 4
+.IX Item "-mcall-freebsd"
+On System V.4 and embedded PowerPC systems compile code for the
+FreeBSD operating system.
+.IP "\fB\-mcall\-netbsd\fR" 4
+.IX Item "-mcall-netbsd"
+On System V.4 and embedded PowerPC systems compile code for the
+NetBSD operating system.
+.IP "\fB\-mcall\-openbsd\fR" 4
+.IX Item "-mcall-openbsd"
+On System V.4 and embedded PowerPC systems compile code for the
+OpenBSD operating system.
+.IP "\fB\-maix\-struct\-return\fR" 4
+.IX Item "-maix-struct-return"
+Return all structures in memory (as specified by the \s-1AIX ABI\s0).
+.IP "\fB\-msvr4\-struct\-return\fR" 4
+.IX Item "-msvr4-struct-return"
+Return structures smaller than 8 bytes in registers (as specified by the
+\&\s-1SVR4 ABI\s0).
+.IP "\fB\-mabi=\fR\fIabi-type\fR" 4
+.IX Item "-mabi=abi-type"
+Extend the current \s-1ABI\s0 with a particular extension, or remove such extension.
+Valid values are \fIaltivec\fR, \fIno-altivec\fR, \fIspe\fR,
+\&\fIno-spe\fR, \fIibmlongdouble\fR, \fIieeelongdouble\fR,
+\&\fIelfv1\fR, \fIelfv2\fR.
+.IP "\fB\-mabi=spe\fR" 4
+.IX Item "-mabi=spe"
+Extend the current \s-1ABI\s0 with \s-1SPE ABI\s0 extensions.  This does not change
+the default \s-1ABI,\s0 instead it adds the \s-1SPE ABI\s0 extensions to the current
+\&\s-1ABI.\s0
+.IP "\fB\-mabi=no\-spe\fR" 4
+.IX Item "-mabi=no-spe"
+Disable Book-E \s-1SPE ABI\s0 extensions for the current \s-1ABI.\s0
+.IP "\fB\-mabi=ibmlongdouble\fR" 4
+.IX Item "-mabi=ibmlongdouble"
+Change the current \s-1ABI\s0 to use \s-1IBM\s0 extended-precision long double.
+This is a PowerPC 32\-bit \s-1SYSV ABI\s0 option.
+.IP "\fB\-mabi=ieeelongdouble\fR" 4
+.IX Item "-mabi=ieeelongdouble"
+Change the current \s-1ABI\s0 to use \s-1IEEE\s0 extended-precision long double.
+This is a PowerPC 32\-bit Linux \s-1ABI\s0 option.
+.IP "\fB\-mabi=elfv1\fR" 4
+.IX Item "-mabi=elfv1"
+Change the current \s-1ABI\s0 to use the ELFv1 \s-1ABI.\s0
+This is the default \s-1ABI\s0 for big-endian PowerPC 64\-bit Linux.
+Overriding the default \s-1ABI\s0 requires special system support and is
+likely to fail in spectacular ways.
+.IP "\fB\-mabi=elfv2\fR" 4
+.IX Item "-mabi=elfv2"
+Change the current \s-1ABI\s0 to use the ELFv2 \s-1ABI.\s0
+This is the default \s-1ABI\s0 for little-endian PowerPC 64\-bit Linux.
+Overriding the default \s-1ABI\s0 requires special system support and is
+likely to fail in spectacular ways.
+.IP "\fB\-mprototype\fR" 4
+.IX Item "-mprototype"
+.PD 0
+.IP "\fB\-mno\-prototype\fR" 4
+.IX Item "-mno-prototype"
+.PD
+On System V.4 and embedded PowerPC systems assume that all calls to
+variable argument functions are properly prototyped.  Otherwise, the
+compiler must insert an instruction before every non-prototyped call to
+set or clear bit 6 of the condition code register (\fI\s-1CR\s0\fR) to
+indicate whether floating-point values are passed in the floating-point
+registers in case the function takes variable arguments.  With
+\&\fB\-mprototype\fR, only calls to prototyped variable argument functions
+set or clear the bit.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+On embedded PowerPC systems, assume that the startup module is called
+\&\fIsim\-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and
+\&\fIlibc.a\fR.  This is the default for \fBpowerpc\-*\-eabisim\fR
+configurations.
+.IP "\fB\-mmvme\fR" 4
+.IX Item "-mmvme"
+On embedded PowerPC systems, assume that the startup module is called
+\&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and
+\&\fIlibc.a\fR.
+.IP "\fB\-mads\fR" 4
+.IX Item "-mads"
+On embedded PowerPC systems, assume that the startup module is called
+\&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and
+\&\fIlibc.a\fR.
+.IP "\fB\-myellowknife\fR" 4
+.IX Item "-myellowknife"
+On embedded PowerPC systems, assume that the startup module is called
+\&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and
+\&\fIlibc.a\fR.
+.IP "\fB\-mvxworks\fR" 4
+.IX Item "-mvxworks"
+On System V.4 and embedded PowerPC systems, specify that you are
+compiling for a VxWorks system.
+.IP "\fB\-memb\fR" 4
+.IX Item "-memb"
+On embedded PowerPC systems, set the \fI\s-1PPC_EMB\s0\fR bit in the \s-1ELF\s0 flags
+header to indicate that \fBeabi\fR extended relocations are used.
+.IP "\fB\-meabi\fR" 4
+.IX Item "-meabi"
+.PD 0
+.IP "\fB\-mno\-eabi\fR" 4
+.IX Item "-mno-eabi"
+.PD
+On System V.4 and embedded PowerPC systems do (do not) adhere to the
+Embedded Applications Binary Interface (\s-1EABI\s0), which is a set of
+modifications to the System V.4 specifications.  Selecting \fB\-meabi\fR
+means that the stack is aligned to an 8\-byte boundary, a function
+\&\f(CW\*(C`_\|_eabi\*(C'\fR is called from \f(CW\*(C`main\*(C'\fR to set up the \s-1EABI\s0
+environment, and the \fB\-msdata\fR option can use both \f(CW\*(C`r2\*(C'\fR and
+\&\f(CW\*(C`r13\*(C'\fR to point to two separate small data areas.  Selecting
+\&\fB\-mno\-eabi\fR means that the stack is aligned to a 16\-byte boundary,
+no \s-1EABI\s0 initialization function is called from \f(CW\*(C`main\*(C'\fR, and the
+\&\fB\-msdata\fR option only uses \f(CW\*(C`r13\*(C'\fR to point to a single
+small data area.  The \fB\-meabi\fR option is on by default if you
+configured \s-1GCC\s0 using one of the \fBpowerpc*\-*\-eabi*\fR options.
+.IP "\fB\-msdata=eabi\fR" 4
+.IX Item "-msdata=eabi"
+On System V.4 and embedded PowerPC systems, put small initialized
+\&\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata2\fR section, which
+is pointed to by register \f(CW\*(C`r2\*(C'\fR.  Put small initialized
+non\-\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata\fR section,
+which is pointed to by register \f(CW\*(C`r13\*(C'\fR.  Put small uninitialized
+global and static data in the \fB.sbss\fR section, which is adjacent to
+the \fB.sdata\fR section.  The \fB\-msdata=eabi\fR option is
+incompatible with the \fB\-mrelocatable\fR option.  The
+\&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option.
+.IP "\fB\-msdata=sysv\fR" 4
+.IX Item "-msdata=sysv"
+On System V.4 and embedded PowerPC systems, put small global and static
+data in the \fB.sdata\fR section, which is pointed to by register
+\&\f(CW\*(C`r13\*(C'\fR.  Put small uninitialized global and static data in the
+\&\fB.sbss\fR section, which is adjacent to the \fB.sdata\fR section.
+The \fB\-msdata=sysv\fR option is incompatible with the
+\&\fB\-mrelocatable\fR option.
+.IP "\fB\-msdata=default\fR" 4
+.IX Item "-msdata=default"
+.PD 0
+.IP "\fB\-msdata\fR" 4
+.IX Item "-msdata"
+.PD
+On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used,
+compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the
+same as \fB\-msdata=sysv\fR.
+.IP "\fB\-msdata=data\fR" 4
+.IX Item "-msdata=data"
+On System V.4 and embedded PowerPC systems, put small global
+data in the \fB.sdata\fR section.  Put small uninitialized global
+data in the \fB.sbss\fR section.  Do not use register \f(CW\*(C`r13\*(C'\fR
+to address small data however.  This is the default behavior unless
+other \fB\-msdata\fR options are used.
+.IP "\fB\-msdata=none\fR" 4
+.IX Item "-msdata=none"
+.PD 0
+.IP "\fB\-mno\-sdata\fR" 4
+.IX Item "-mno-sdata"
+.PD
+On embedded PowerPC systems, put all initialized global and static data
+in the \fB.data\fR section, and all uninitialized data in the
+\&\fB.bss\fR section.
+.IP "\fB\-mblock\-move\-inline\-limit=\fR\fInum\fR" 4
+.IX Item "-mblock-move-inline-limit=num"
+Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure
+copies) less than or equal to \fInum\fR bytes.  The minimum value for
+\&\fInum\fR is 32 bytes on 32\-bit targets and 64 bytes on 64\-bit
+targets.  The default value is target-specific.
+.IP "\fB\-G\fR \fInum\fR" 4
+.IX Item "-G num"
+On embedded PowerPC systems, put global and static items less than or
+equal to \fInum\fR bytes into the small data or \s-1BSS\s0 sections instead of
+the normal data or \s-1BSS\s0 section.  By default, \fInum\fR is 8.  The
+\&\fB\-G\fR \fInum\fR switch is also passed to the linker.
+All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
+.IP "\fB\-mregnames\fR" 4
+.IX Item "-mregnames"
+.PD 0
+.IP "\fB\-mno\-regnames\fR" 4
+.IX Item "-mno-regnames"
+.PD
+On System V.4 and embedded PowerPC systems do (do not) emit register
+names in the assembly language output using symbolic forms.
+.IP "\fB\-mlongcall\fR" 4
+.IX Item "-mlongcall"
+.PD 0
+.IP "\fB\-mno\-longcall\fR" 4
+.IX Item "-mno-longcall"
+.PD
+By default assume that all calls are far away so that a longer and more
+expensive calling sequence is required.  This is required for calls
+farther than 32 megabytes (33,554,432 bytes) from the current location.
+A short call is generated if the compiler knows
+the call cannot be that far away.  This setting can be overridden by
+the \f(CW\*(C`shortcall\*(C'\fR function attribute, or by \f(CW\*(C`#pragma
+longcall(0)\*(C'\fR.
+.Sp
+Some linkers are capable of detecting out-of-range calls and generating
+glue code on the fly.  On these systems, long calls are unnecessary and
+generate slower code.  As of this writing, the \s-1AIX\s0 linker can do this,
+as can the \s-1GNU\s0 linker for PowerPC/64.  It is planned to add this feature
+to the \s-1GNU\s0 linker for 32\-bit PowerPC systems as well.
+.Sp
+On Darwin/PPC systems, \f(CW\*(C`#pragma longcall\*(C'\fR generates \f(CW\*(C`jbsr
+callee, L42\*(C'\fR, plus a \fIbranch island\fR (glue code).  The two target
+addresses represent the callee and the branch island.  The
+Darwin/PPC linker prefers the first address and generates a \f(CW\*(C`bl
+callee\*(C'\fR if the \s-1PPC \s0\f(CW\*(C`bl\*(C'\fR instruction reaches the callee directly;
+otherwise, the linker generates \f(CW\*(C`bl L42\*(C'\fR to call the branch
+island.  The branch island is appended to the body of the
+calling function; it computes the full 32\-bit address of the callee
+and jumps to it.
+.Sp
+On Mach-O (Darwin) systems, this option directs the compiler emit to
+the glue for every direct call, and the Darwin linker decides whether
+to use or discard it.
+.Sp
+In the future, \s-1GCC\s0 may ignore all longcall specifications
+when the linker is known to generate glue.
+.IP "\fB\-mtls\-markers\fR" 4
+.IX Item "-mtls-markers"
+.PD 0
+.IP "\fB\-mno\-tls\-markers\fR" 4
+.IX Item "-mno-tls-markers"
+.PD
+Mark (do not mark) calls to \f(CW\*(C`_\|_tls_get_addr\*(C'\fR with a relocation
+specifying the function argument.  The relocation allows the linker to
+reliably associate function call with argument setup instructions for
+\&\s-1TLS\s0 optimization, which in turn allows \s-1GCC\s0 to better schedule the
+sequence.
+.IP "\fB\-pthread\fR" 4
+.IX Item "-pthread"
+Adds support for multithreading with the \fIpthreads\fR library.
+This option sets flags for both the preprocessor and linker.
+.IP "\fB\-mrecip\fR" 4
+.IX Item "-mrecip"
+.PD 0
+.IP "\fB\-mno\-recip\fR" 4
+.IX Item "-mno-recip"
+.PD
+This option enables use of the reciprocal estimate and
+reciprocal square root estimate instructions with additional
+Newton-Raphson steps to increase precision instead of doing a divide or
+square root and divide for floating-point arguments.  You should use
+the \fB\-ffast\-math\fR option when using \fB\-mrecip\fR (or at
+least \fB\-funsafe\-math\-optimizations\fR,
+\&\fB\-finite\-math\-only\fR, \fB\-freciprocal\-math\fR and
+\&\fB\-fno\-trapping\-math\fR).  Note that while the throughput of the
+sequence is generally higher than the throughput of the non-reciprocal
+instruction, the precision of the sequence can be decreased by up to 2
+ulp (i.e. the inverse of 1.0 equals 0.99999994) for reciprocal square
+roots.
+.IP "\fB\-mrecip=\fR\fIopt\fR" 4
+.IX Item "-mrecip=opt"
+This option controls which reciprocal estimate instructions
+may be used.  \fIopt\fR is a comma-separated list of options, which may
+be preceded by a \f(CW\*(C`!\*(C'\fR to invert the option:
+\&\f(CW\*(C`all\*(C'\fR: enable all estimate instructions,
+\&\f(CW\*(C`default\*(C'\fR: enable the default instructions, equivalent to \fB\-mrecip\fR,
+\&\f(CW\*(C`none\*(C'\fR: disable all estimate instructions, equivalent to \fB\-mno\-recip\fR;
+\&\f(CW\*(C`div\*(C'\fR: enable the reciprocal approximation instructions for both single and double precision;
+\&\f(CW\*(C`divf\*(C'\fR: enable the single-precision reciprocal approximation instructions;
+\&\f(CW\*(C`divd\*(C'\fR: enable the double-precision reciprocal approximation instructions;
+\&\f(CW\*(C`rsqrt\*(C'\fR: enable the reciprocal square root approximation instructions for both single and double precision;
+\&\f(CW\*(C`rsqrtf\*(C'\fR: enable the single-precision reciprocal square root approximation instructions;
+\&\f(CW\*(C`rsqrtd\*(C'\fR: enable the double-precision reciprocal square root approximation instructions;
+.Sp
+So, for example, \fB\-mrecip=all,!rsqrtd\fR enables
+all of the reciprocal estimate instructions, except for the
+\&\f(CW\*(C`FRSQRTE\*(C'\fR, \f(CW\*(C`XSRSQRTEDP\*(C'\fR, and \f(CW\*(C`XVRSQRTEDP\*(C'\fR instructions
+which handle the double-precision reciprocal square root calculations.
+.IP "\fB\-mrecip\-precision\fR" 4
+.IX Item "-mrecip-precision"
+.PD 0
+.IP "\fB\-mno\-recip\-precision\fR" 4
+.IX Item "-mno-recip-precision"
+.PD
+Assume (do not assume) that the reciprocal estimate instructions
+provide higher-precision estimates than is mandated by the PowerPC
+\&\s-1ABI. \s0 Selecting \fB\-mcpu=power6\fR, \fB\-mcpu=power7\fR or
+\&\fB\-mcpu=power8\fR automatically selects \fB\-mrecip\-precision\fR.
+The double-precision square root estimate instructions are not generated by
+default on low-precision machines, since they do not provide an
+estimate that converges after three steps.
+.IP "\fB\-mveclibabi=\fR\fItype\fR" 4
+.IX Item "-mveclibabi=type"
+Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
+external library.  The only type supported at present is \f(CW\*(C`mass\*(C'\fR,
+which specifies to use \s-1IBM\s0's Mathematical Acceleration Subsystem
+(\s-1MASS\s0) libraries for vectorizing intrinsics using external libraries.
+\&\s-1GCC\s0 currently emits calls to \f(CW\*(C`acosd2\*(C'\fR, \f(CW\*(C`acosf4\*(C'\fR,
+\&\f(CW\*(C`acoshd2\*(C'\fR, \f(CW\*(C`acoshf4\*(C'\fR, \f(CW\*(C`asind2\*(C'\fR, \f(CW\*(C`asinf4\*(C'\fR,
+\&\f(CW\*(C`asinhd2\*(C'\fR, \f(CW\*(C`asinhf4\*(C'\fR, \f(CW\*(C`atan2d2\*(C'\fR, \f(CW\*(C`atan2f4\*(C'\fR,
+\&\f(CW\*(C`atand2\*(C'\fR, \f(CW\*(C`atanf4\*(C'\fR, \f(CW\*(C`atanhd2\*(C'\fR, \f(CW\*(C`atanhf4\*(C'\fR,
+\&\f(CW\*(C`cbrtd2\*(C'\fR, \f(CW\*(C`cbrtf4\*(C'\fR, \f(CW\*(C`cosd2\*(C'\fR, \f(CW\*(C`cosf4\*(C'\fR,
+\&\f(CW\*(C`coshd2\*(C'\fR, \f(CW\*(C`coshf4\*(C'\fR, \f(CW\*(C`erfcd2\*(C'\fR, \f(CW\*(C`erfcf4\*(C'\fR,
+\&\f(CW\*(C`erfd2\*(C'\fR, \f(CW\*(C`erff4\*(C'\fR, \f(CW\*(C`exp2d2\*(C'\fR, \f(CW\*(C`exp2f4\*(C'\fR,
+\&\f(CW\*(C`expd2\*(C'\fR, \f(CW\*(C`expf4\*(C'\fR, \f(CW\*(C`expm1d2\*(C'\fR, \f(CW\*(C`expm1f4\*(C'\fR,
+\&\f(CW\*(C`hypotd2\*(C'\fR, \f(CW\*(C`hypotf4\*(C'\fR, \f(CW\*(C`lgammad2\*(C'\fR, \f(CW\*(C`lgammaf4\*(C'\fR,
+\&\f(CW\*(C`log10d2\*(C'\fR, \f(CW\*(C`log10f4\*(C'\fR, \f(CW\*(C`log1pd2\*(C'\fR, \f(CW\*(C`log1pf4\*(C'\fR,
+\&\f(CW\*(C`log2d2\*(C'\fR, \f(CW\*(C`log2f4\*(C'\fR, \f(CW\*(C`logd2\*(C'\fR, \f(CW\*(C`logf4\*(C'\fR,
+\&\f(CW\*(C`powd2\*(C'\fR, \f(CW\*(C`powf4\*(C'\fR, \f(CW\*(C`sind2\*(C'\fR, \f(CW\*(C`sinf4\*(C'\fR, \f(CW\*(C`sinhd2\*(C'\fR,
+\&\f(CW\*(C`sinhf4\*(C'\fR, \f(CW\*(C`sqrtd2\*(C'\fR, \f(CW\*(C`sqrtf4\*(C'\fR, \f(CW\*(C`tand2\*(C'\fR,
+\&\f(CW\*(C`tanf4\*(C'\fR, \f(CW\*(C`tanhd2\*(C'\fR, and \f(CW\*(C`tanhf4\*(C'\fR when generating code
+for power7.  Both \fB\-ftree\-vectorize\fR and
+\&\fB\-funsafe\-math\-optimizations\fR must also be enabled.  The \s-1MASS\s0
+libraries must be specified at link time.
+.IP "\fB\-mfriz\fR" 4
+.IX Item "-mfriz"
+.PD 0
+.IP "\fB\-mno\-friz\fR" 4
+.IX Item "-mno-friz"
+.PD
+Generate (do not generate) the \f(CW\*(C`friz\*(C'\fR instruction when the
+\&\fB\-funsafe\-math\-optimizations\fR option is used to optimize
+rounding of floating-point values to 64\-bit integer and back to floating
+point.  The \f(CW\*(C`friz\*(C'\fR instruction does not return the same value if
+the floating-point number is too large to fit in an integer.
+.IP "\fB\-mpointers\-to\-nested\-functions\fR" 4
+.IX Item "-mpointers-to-nested-functions"
+.PD 0
+.IP "\fB\-mno\-pointers\-to\-nested\-functions\fR" 4
+.IX Item "-mno-pointers-to-nested-functions"
+.PD
+Generate (do not generate) code to load up the static chain register
+(\fIr11\fR) when calling through a pointer on \s-1AIX\s0 and 64\-bit Linux
+systems where a function pointer points to a 3\-word descriptor giving
+the function address, \s-1TOC\s0 value to be loaded in register \fIr2\fR, and
+static chain value to be loaded in register \fIr11\fR.  The
+\&\fB\-mpointers\-to\-nested\-functions\fR is on by default.  You cannot
+call through pointers to nested functions or pointers
+to functions compiled in other languages that use the static chain if
+you use the \fB\-mno\-pointers\-to\-nested\-functions\fR.
+.IP "\fB\-msave\-toc\-indirect\fR" 4
+.IX Item "-msave-toc-indirect"
+.PD 0
+.IP "\fB\-mno\-save\-toc\-indirect\fR" 4
+.IX Item "-mno-save-toc-indirect"
+.PD
+Generate (do not generate) code to save the \s-1TOC\s0 value in the reserved
+stack location in the function prologue if the function calls through
+a pointer on \s-1AIX\s0 and 64\-bit Linux systems.  If the \s-1TOC\s0 value is not
+saved in the prologue, it is saved just before the call through the
+pointer.  The \fB\-mno\-save\-toc\-indirect\fR option is the default.
+.IP "\fB\-mcompat\-align\-parm\fR" 4
+.IX Item "-mcompat-align-parm"
+.PD 0
+.IP "\fB\-mno\-compat\-align\-parm\fR" 4
+.IX Item "-mno-compat-align-parm"
+.PD
+Generate (do not generate) code to pass structure parameters with a
+maximum alignment of 64 bits, for compatibility with older versions
+of \s-1GCC.\s0
+.Sp
+Older versions of \s-1GCC \s0(prior to 4.9.0) incorrectly did not align a
+structure parameter on a 128\-bit boundary when that structure contained
+a member requiring 128\-bit alignment.  This is corrected in more
+recent versions of \s-1GCC. \s0 This option may be used to generate code
+that is compatible with functions compiled with older versions of
+\&\s-1GCC.\s0
+.Sp
+The \fB\-mno\-compat\-align\-parm\fR option is the default.
+.PP
+\fI\s-1RX\s0 Options\fR
+.IX Subsection "RX Options"
+.PP
+These command-line options are defined for \s-1RX\s0 targets:
+.IP "\fB\-m64bit\-doubles\fR" 4
+.IX Item "-m64bit-doubles"
+.PD 0
+.IP "\fB\-m32bit\-doubles\fR" 4
+.IX Item "-m32bit-doubles"
+.PD
+Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
+or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
+\&\fB\-m32bit\-doubles\fR.  \fINote\fR \s-1RX\s0 floating-point hardware only
+works on 32\-bit values, which is why the default is
+\&\fB\-m32bit\-doubles\fR.
+.IP "\fB\-fpu\fR" 4
+.IX Item "-fpu"
+.PD 0
+.IP "\fB\-nofpu\fR" 4
+.IX Item "-nofpu"
+.PD
+Enables (\fB\-fpu\fR) or disables (\fB\-nofpu\fR) the use of \s-1RX\s0
+floating-point hardware.  The default is enabled for the \fI\s-1RX600\s0\fR
+series and disabled for the \fI\s-1RX200\s0\fR series.
+.Sp
+Floating-point instructions are only generated for 32\-bit floating-point 
+values, however, so the \s-1FPU\s0 hardware is not used for doubles if the
+\&\fB\-m64bit\-doubles\fR option is used.
+.Sp
+\&\fINote\fR If the \fB\-fpu\fR option is enabled then
+\&\fB\-funsafe\-math\-optimizations\fR is also enabled automatically.
+This is because the \s-1RX FPU\s0 instructions are themselves unsafe.
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Selects the type of \s-1RX CPU\s0 to be targeted.  Currently three types are
+supported, the generic \fI\s-1RX600\s0\fR and \fI\s-1RX200\s0\fR series hardware and
+the specific \fI\s-1RX610\s0\fR \s-1CPU. \s0 The default is \fI\s-1RX600\s0\fR.
+.Sp
+The only difference between \fI\s-1RX600\s0\fR and \fI\s-1RX610\s0\fR is that the
+\&\fI\s-1RX610\s0\fR does not support the \f(CW\*(C`MVTIPL\*(C'\fR instruction.
+.Sp
+The \fI\s-1RX200\s0\fR series does not have a hardware floating-point unit
+and so \fB\-nofpu\fR is enabled by default when this type is
+selected.
+.IP "\fB\-mbig\-endian\-data\fR" 4
+.IX Item "-mbig-endian-data"
+.PD 0
+.IP "\fB\-mlittle\-endian\-data\fR" 4
+.IX Item "-mlittle-endian-data"
+.PD
+Store data (but not code) in the big-endian format.  The default is
+\&\fB\-mlittle\-endian\-data\fR, i.e. to store data in the little-endian
+format.
+.IP "\fB\-msmall\-data\-limit=\fR\fIN\fR" 4
+.IX Item "-msmall-data-limit=N"
+Specifies the maximum size in bytes of global and static variables
+which can be placed into the small data area.  Using the small data
+area can lead to smaller and faster code, but the size of area is
+limited and it is up to the programmer to ensure that the area does
+not overflow.  Also when the small data area is used one of the \s-1RX\s0's
+registers (usually \f(CW\*(C`r13\*(C'\fR) is reserved for use pointing to this
+area, so it is no longer available for use by the compiler.  This
+could result in slower and/or larger code if variables are pushed onto
+the stack instead of being held in this register.
+.Sp
+Note, common variables (variables that have not been initialized) and
+constants are not placed into the small data area as they are assigned
+to other sections in the output executable.
+.Sp
+The default value is zero, which disables this feature.  Note, this
+feature is not enabled by default with higher optimization levels
+(\fB\-O2\fR etc) because of the potentially detrimental effects of
+reserving a register.  It is up to the programmer to experiment and
+discover whether this feature is of benefit to their program.  See the
+description of the \fB\-mpid\fR option for a description of how the
+actual register to hold the small data area pointer is chosen.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+.PD 0
+.IP "\fB\-mno\-sim\fR" 4
+.IX Item "-mno-sim"
+.PD
+Use the simulator runtime.  The default is to use the libgloss
+board-specific runtime.
+.IP "\fB\-mas100\-syntax\fR" 4
+.IX Item "-mas100-syntax"
+.PD 0
+.IP "\fB\-mno\-as100\-syntax\fR" 4
+.IX Item "-mno-as100-syntax"
+.PD
+When generating assembler output use a syntax that is compatible with
+Renesas's \s-1AS100\s0 assembler.  This syntax can also be handled by the \s-1GAS\s0
+assembler, but it has some restrictions so it is not generated by default.
+.IP "\fB\-mmax\-constant\-size=\fR\fIN\fR" 4
+.IX Item "-mmax-constant-size=N"
+Specifies the maximum size, in bytes, of a constant that can be used as
+an operand in a \s-1RX\s0 instruction.  Although the \s-1RX\s0 instruction set does
+allow constants of up to 4 bytes in length to be used in instructions,
+a longer value equates to a longer instruction.  Thus in some
+circumstances it can be beneficial to restrict the size of constants
+that are used in instructions.  Constants that are too big are instead
+placed into a constant pool and referenced via register indirection.
+.Sp
+The value \fIN\fR can be between 0 and 4.  A value of 0 (the default)
+or 4 means that constants of any size are allowed.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Enable linker relaxation.  Linker relaxation is a process whereby the
+linker attempts to reduce the size of a program by finding shorter
+versions of various instructions.  Disabled by default.
+.IP "\fB\-mint\-register=\fR\fIN\fR" 4
+.IX Item "-mint-register=N"
+Specify the number of registers to reserve for fast interrupt handler
+functions.  The value \fIN\fR can be between 0 and 4.  A value of 1
+means that register \f(CW\*(C`r13\*(C'\fR is reserved for the exclusive use
+of fast interrupt handlers.  A value of 2 reserves \f(CW\*(C`r13\*(C'\fR and
+\&\f(CW\*(C`r12\*(C'\fR.  A value of 3 reserves \f(CW\*(C`r13\*(C'\fR, \f(CW\*(C`r12\*(C'\fR and
+\&\f(CW\*(C`r11\*(C'\fR, and a value of 4 reserves \f(CW\*(C`r13\*(C'\fR through \f(CW\*(C`r10\*(C'\fR.
+A value of 0, the default, does not reserve any registers.
+.IP "\fB\-msave\-acc\-in\-interrupts\fR" 4
+.IX Item "-msave-acc-in-interrupts"
+Specifies that interrupt handler functions should preserve the
+accumulator register.  This is only necessary if normal code might use
+the accumulator register, for example because it performs 64\-bit
+multiplications.  The default is to ignore the accumulator as this
+makes the interrupt handlers faster.
+.IP "\fB\-mpid\fR" 4
+.IX Item "-mpid"
+.PD 0
+.IP "\fB\-mno\-pid\fR" 4
+.IX Item "-mno-pid"
+.PD
+Enables the generation of position independent data.  When enabled any
+access to constant data is done via an offset from a base address
+held in a register.  This allows the location of constant data to be
+determined at run time without requiring the executable to be
+relocated, which is a benefit to embedded applications with tight
+memory constraints.  Data that can be modified is not affected by this
+option.
+.Sp
+Note, using this feature reserves a register, usually \f(CW\*(C`r13\*(C'\fR, for
+the constant data base address.  This can result in slower and/or
+larger code, especially in complicated functions.
+.Sp
+The actual register chosen to hold the constant data base address
+depends upon whether the \fB\-msmall\-data\-limit\fR and/or the
+\&\fB\-mint\-register\fR command-line options are enabled.  Starting
+with register \f(CW\*(C`r13\*(C'\fR and proceeding downwards, registers are
+allocated first to satisfy the requirements of \fB\-mint\-register\fR,
+then \fB\-mpid\fR and finally \fB\-msmall\-data\-limit\fR.  Thus it
+is possible for the small data area register to be \f(CW\*(C`r8\*(C'\fR if both
+\&\fB\-mint\-register=4\fR and \fB\-mpid\fR are specified on the
+command line.
+.Sp
+By default this feature is not enabled.  The default can be restored
+via the \fB\-mno\-pid\fR command-line option.
+.IP "\fB\-mno\-warn\-multiple\-fast\-interrupts\fR" 4
+.IX Item "-mno-warn-multiple-fast-interrupts"
+.PD 0
+.IP "\fB\-mwarn\-multiple\-fast\-interrupts\fR" 4
+.IX Item "-mwarn-multiple-fast-interrupts"
+.PD
+Prevents \s-1GCC\s0 from issuing a warning message if it finds more than one
+fast interrupt handler when it is compiling a file.  The default is to
+issue a warning for each extra fast interrupt handler found, as the \s-1RX\s0
+only supports one such interrupt.
+.PP
+\&\fINote:\fR The generic \s-1GCC\s0 command-line option \fB\-ffixed\-\fR\fIreg\fR
+has special significance to the \s-1RX\s0 port when used with the
+\&\f(CW\*(C`interrupt\*(C'\fR function attribute.  This attribute indicates a
+function intended to process fast interrupts.  \s-1GCC\s0 ensures
+that it only uses the registers \f(CW\*(C`r10\*(C'\fR, \f(CW\*(C`r11\*(C'\fR, \f(CW\*(C`r12\*(C'\fR
+and/or \f(CW\*(C`r13\*(C'\fR and only provided that the normal use of the
+corresponding registers have been restricted via the
+\&\fB\-ffixed\-\fR\fIreg\fR or \fB\-mint\-register\fR command-line
+options.
+.PP
+\fIS/390 and zSeries Options\fR
+.IX Subsection "S/390 and zSeries Options"
+.PP
+These are the \fB\-m\fR options defined for the S/390 and zSeries architecture.
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD 0
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD
+Use (do not use) the hardware floating-point instructions and registers
+for floating-point operations.  When \fB\-msoft\-float\fR is specified,
+functions in \fIlibgcc.a\fR are used to perform floating-point
+operations.  When \fB\-mhard\-float\fR is specified, the compiler
+generates \s-1IEEE\s0 floating-point instructions.  This is the default.
+.IP "\fB\-mhard\-dfp\fR" 4
+.IX Item "-mhard-dfp"
+.PD 0
+.IP "\fB\-mno\-hard\-dfp\fR" 4
+.IX Item "-mno-hard-dfp"
+.PD
+Use (do not use) the hardware decimal-floating-point instructions for
+decimal-floating-point operations.  When \fB\-mno\-hard\-dfp\fR is
+specified, functions in \fIlibgcc.a\fR are used to perform
+decimal-floating-point operations.  When \fB\-mhard\-dfp\fR is
+specified, the compiler generates decimal-floating-point hardware
+instructions.  This is the default for \fB\-march=z9\-ec\fR or higher.
+.IP "\fB\-mlong\-double\-64\fR" 4
+.IX Item "-mlong-double-64"
+.PD 0
+.IP "\fB\-mlong\-double\-128\fR" 4
+.IX Item "-mlong-double-128"
+.PD
+These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
+of 64 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
+type. This is the default.
+.IP "\fB\-mbackchain\fR" 4
+.IX Item "-mbackchain"
+.PD 0
+.IP "\fB\-mno\-backchain\fR" 4
+.IX Item "-mno-backchain"
+.PD
+Store (do not store) the address of the caller's frame as backchain pointer
+into the callee's stack frame.
+A backchain may be needed to allow debugging using tools that do not understand
+\&\s-1DWARF 2\s0 call frame information.
+When \fB\-mno\-packed\-stack\fR is in effect, the backchain pointer is stored
+at the bottom of the stack frame; when \fB\-mpacked\-stack\fR is in effect,
+the backchain is placed into the topmost word of the 96/160 byte register
+save area.
+.Sp
+In general, code compiled with \fB\-mbackchain\fR is call-compatible with
+code compiled with \fB\-mmo\-backchain\fR; however, use of the backchain
+for debugging purposes usually requires that the whole binary is built with
+\&\fB\-mbackchain\fR.  Note that the combination of \fB\-mbackchain\fR,
+\&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported.  In order
+to build a linux kernel use \fB\-msoft\-float\fR.
+.Sp
+The default is to not maintain the backchain.
+.IP "\fB\-mpacked\-stack\fR" 4
+.IX Item "-mpacked-stack"
+.PD 0
+.IP "\fB\-mno\-packed\-stack\fR" 4
+.IX Item "-mno-packed-stack"
+.PD
+Use (do not use) the packed stack layout.  When \fB\-mno\-packed\-stack\fR is
+specified, the compiler uses the all fields of the 96/160 byte register save
+area only for their default purpose; unused fields still take up stack space.
+When \fB\-mpacked\-stack\fR is specified, register save slots are densely
+packed at the top of the register save area; unused space is reused for other
+purposes, allowing for more efficient use of the available stack space.
+However, when \fB\-mbackchain\fR is also in effect, the topmost word of
+the save area is always used to store the backchain, and the return address
+register is always saved two words below the backchain.
+.Sp
+As long as the stack frame backchain is not used, code generated with
+\&\fB\-mpacked\-stack\fR is call-compatible with code generated with
+\&\fB\-mno\-packed\-stack\fR.  Note that some non-FSF releases of \s-1GCC 2.95\s0 for
+S/390 or zSeries generated code that uses the stack frame backchain at run
+time, not just for debugging purposes.  Such code is not call-compatible
+with code compiled with \fB\-mpacked\-stack\fR.  Also, note that the
+combination of \fB\-mbackchain\fR,
+\&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported.  In order
+to build a linux kernel use \fB\-msoft\-float\fR.
+.Sp
+The default is to not use the packed stack layout.
+.IP "\fB\-msmall\-exec\fR" 4
+.IX Item "-msmall-exec"
+.PD 0
+.IP "\fB\-mno\-small\-exec\fR" 4
+.IX Item "-mno-small-exec"
+.PD
+Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction
+to do subroutine calls.
+This only works reliably if the total executable size does not
+exceed 64k.  The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead,
+which does not have this limitation.
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.PD 0
+.IP "\fB\-m31\fR" 4
+.IX Item "-m31"
+.PD
+When \fB\-m31\fR is specified, generate code compliant to the
+GNU/Linux for S/390 \s-1ABI. \s0 When \fB\-m64\fR is specified, generate
+code compliant to the GNU/Linux for zSeries \s-1ABI. \s0 This allows \s-1GCC\s0 in
+particular to generate 64\-bit instructions.  For the \fBs390\fR
+targets, the default is \fB\-m31\fR, while the \fBs390x\fR
+targets default to \fB\-m64\fR.
+.IP "\fB\-mzarch\fR" 4
+.IX Item "-mzarch"
+.PD 0
+.IP "\fB\-mesa\fR" 4
+.IX Item "-mesa"
+.PD
+When \fB\-mzarch\fR is specified, generate code using the
+instructions available on z/Architecture.
+When \fB\-mesa\fR is specified, generate code using the
+instructions available on \s-1ESA/390. \s0 Note that \fB\-mesa\fR is
+not possible with \fB\-m64\fR.
+When generating code compliant to the GNU/Linux for S/390 \s-1ABI,\s0
+the default is \fB\-mesa\fR.  When generating code compliant
+to the GNU/Linux for zSeries \s-1ABI,\s0 the default is \fB\-mzarch\fR.
+.IP "\fB\-mmvcle\fR" 4
+.IX Item "-mmvcle"
+.PD 0
+.IP "\fB\-mno\-mvcle\fR" 4
+.IX Item "-mno-mvcle"
+.PD
+Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction
+to perform block moves.  When \fB\-mno\-mvcle\fR is specified,
+use a \f(CW\*(C`mvc\*(C'\fR loop instead.  This is the default unless optimizing for
+size.
+.IP "\fB\-mdebug\fR" 4
+.IX Item "-mdebug"
+.PD 0
+.IP "\fB\-mno\-debug\fR" 4
+.IX Item "-mno-debug"
+.PD
+Print (or do not print) additional debug information when compiling.
+The default is to not print debug information.
+.IP "\fB\-march=\fR\fIcpu-type\fR" 4
+.IX Item "-march=cpu-type"
+Generate code that runs on \fIcpu-type\fR, which is the name of a system
+representing a certain processor type.  Possible values for
+\&\fIcpu-type\fR are \fBg5\fR, \fBg6\fR, \fBz900\fR, \fBz990\fR,
+\&\fBz9\-109\fR, \fBz9\-ec\fR and \fBz10\fR.
+When generating code using the instructions available on z/Architecture,
+the default is \fB\-march=z900\fR.  Otherwise, the default is
+\&\fB\-march=g5\fR.
+.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
+.IX Item "-mtune=cpu-type"
+Tune to \fIcpu-type\fR everything applicable about the generated code,
+except for the \s-1ABI\s0 and the set of available instructions.
+The list of \fIcpu-type\fR values is the same as for \fB\-march\fR.
+The default is the value used for \fB\-march\fR.
+.IP "\fB\-mtpf\-trace\fR" 4
+.IX Item "-mtpf-trace"
+.PD 0
+.IP "\fB\-mno\-tpf\-trace\fR" 4
+.IX Item "-mno-tpf-trace"
+.PD
+Generate code that adds (does not add) in \s-1TPF OS\s0 specific branches to trace
+routines in the operating system.  This option is off by default, even
+when compiling for the \s-1TPF OS.\s0
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Generate code that uses (does not use) the floating-point multiply and
+accumulate instructions.  These instructions are generated by default if
+hardware floating point is used.
+.IP "\fB\-mwarn\-framesize=\fR\fIframesize\fR" 4
+.IX Item "-mwarn-framesize=framesize"
+Emit a warning if the current function exceeds the given frame size.  Because
+this is a compile-time check it doesn't need to be a real problem when the program
+runs.  It is intended to identify functions that most probably cause
+a stack overflow.  It is useful to be used in an environment with limited stack
+size e.g. the linux kernel.
+.IP "\fB\-mwarn\-dynamicstack\fR" 4
+.IX Item "-mwarn-dynamicstack"
+Emit a warning if the function calls \f(CW\*(C`alloca\*(C'\fR or uses dynamically-sized
+arrays.  This is generally a bad idea with a limited stack size.
+.IP "\fB\-mstack\-guard=\fR\fIstack-guard\fR" 4
+.IX Item "-mstack-guard=stack-guard"
+.PD 0
+.IP "\fB\-mstack\-size=\fR\fIstack-size\fR" 4
+.IX Item "-mstack-size=stack-size"
+.PD
+If these options are provided the S/390 back end emits additional instructions in
+the function prologue that trigger a trap if the stack size is \fIstack-guard\fR
+bytes above the \fIstack-size\fR (remember that the stack on S/390 grows downward).
+If the \fIstack-guard\fR option is omitted the smallest power of 2 larger than
+the frame size of the compiled function is chosen.
+These options are intended to be used to help debugging stack overflow problems.
+The additionally emitted code causes only little overhead and hence can also be
+used in production-like systems without greater performance degradation.  The given
+values have to be exact powers of 2 and \fIstack-size\fR has to be greater than
+\&\fIstack-guard\fR without exceeding 64k.
+In order to be efficient the extra code makes the assumption that the stack starts
+at an address aligned to the value given by \fIstack-size\fR.
+The \fIstack-guard\fR option can only be used in conjunction with \fIstack-size\fR.
+.IP "\fB\-mhotpatch[=\fR\fIhalfwords\fR\fB]\fR" 4
+.IX Item "-mhotpatch[=halfwords]"
+.PD 0
+.IP "\fB\-mno\-hotpatch\fR" 4
+.IX Item "-mno-hotpatch"
+.PD
+If the hotpatch option is enabled, a \*(L"hot-patching\*(R" function
+prologue is generated for all functions in the compilation unit.
+The funtion label is prepended with the given number of two-byte
+Nop instructions (\fIhalfwords\fR, maximum 1000000) or 12 Nop
+instructions if no argument is present.  Functions with a
+hot-patching prologue are never inlined automatically, and a
+hot-patching prologue is never generated for functions functions
+that are explicitly inline.
+.Sp
+This option can be overridden for individual functions with the
+\&\f(CW\*(C`hotpatch\*(C'\fR attribute.
+.PP
+\fIScore Options\fR
+.IX Subsection "Score Options"
+.PP
+These options are defined for Score implementations:
+.IP "\fB\-meb\fR" 4
+.IX Item "-meb"
+Compile code for big-endian mode.  This is the default.
+.IP "\fB\-mel\fR" 4
+.IX Item "-mel"
+Compile code for little-endian mode.
+.IP "\fB\-mnhwloop\fR" 4
+.IX Item "-mnhwloop"
+Disable generation of \f(CW\*(C`bcnz\*(C'\fR instructions.
+.IP "\fB\-muls\fR" 4
+.IX Item "-muls"
+Enable generation of unaligned load and store instructions.
+.IP "\fB\-mmac\fR" 4
+.IX Item "-mmac"
+Enable the use of multiply-accumulate instructions. Disabled by default.
+.IP "\fB\-mscore5\fR" 4
+.IX Item "-mscore5"
+Specify the \s-1SCORE5\s0 as the target architecture.
+.IP "\fB\-mscore5u\fR" 4
+.IX Item "-mscore5u"
+Specify the \s-1SCORE5U\s0 of the target architecture.
+.IP "\fB\-mscore7\fR" 4
+.IX Item "-mscore7"
+Specify the \s-1SCORE7\s0 as the target architecture. This is the default.
+.IP "\fB\-mscore7d\fR" 4
+.IX Item "-mscore7d"
+Specify the \s-1SCORE7D\s0 as the target architecture.
+.PP
+\fI\s-1SH\s0 Options\fR
+.IX Subsection "SH Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1SH\s0 implementations:
+.IP "\fB\-m1\fR" 4
+.IX Item "-m1"
+Generate code for the \s-1SH1.\s0
+.IP "\fB\-m2\fR" 4
+.IX Item "-m2"
+Generate code for the \s-1SH2.\s0
+.IP "\fB\-m2e\fR" 4
+.IX Item "-m2e"
+Generate code for the SH2e.
+.IP "\fB\-m2a\-nofpu\fR" 4
+.IX Item "-m2a-nofpu"
+Generate code for the SH2a without \s-1FPU,\s0 or for a SH2a\-FPU in such a way
+that the floating-point unit is not used.
+.IP "\fB\-m2a\-single\-only\fR" 4
+.IX Item "-m2a-single-only"
+Generate code for the SH2a\-FPU, in such a way that no double-precision
+floating-point operations are used.
+.IP "\fB\-m2a\-single\fR" 4
+.IX Item "-m2a-single"
+Generate code for the SH2a\-FPU assuming the floating-point unit is in
+single-precision mode by default.
+.IP "\fB\-m2a\fR" 4
+.IX Item "-m2a"
+Generate code for the SH2a\-FPU assuming the floating-point unit is in
+double-precision mode by default.
+.IP "\fB\-m3\fR" 4
+.IX Item "-m3"
+Generate code for the \s-1SH3.\s0
+.IP "\fB\-m3e\fR" 4
+.IX Item "-m3e"
+Generate code for the SH3e.
+.IP "\fB\-m4\-nofpu\fR" 4
+.IX Item "-m4-nofpu"
+Generate code for the \s-1SH4\s0 without a floating-point unit.
+.IP "\fB\-m4\-single\-only\fR" 4
+.IX Item "-m4-single-only"
+Generate code for the \s-1SH4\s0 with a floating-point unit that only
+supports single-precision arithmetic.
+.IP "\fB\-m4\-single\fR" 4
+.IX Item "-m4-single"
+Generate code for the \s-1SH4\s0 assuming the floating-point unit is in
+single-precision mode by default.
+.IP "\fB\-m4\fR" 4
+.IX Item "-m4"
+Generate code for the \s-1SH4.\s0
+.IP "\fB\-m4a\-nofpu\fR" 4
+.IX Item "-m4a-nofpu"
+Generate code for the SH4al\-dsp, or for a SH4a in such a way that the
+floating-point unit is not used.
+.IP "\fB\-m4a\-single\-only\fR" 4
+.IX Item "-m4a-single-only"
+Generate code for the SH4a, in such a way that no double-precision
+floating-point operations are used.
+.IP "\fB\-m4a\-single\fR" 4
+.IX Item "-m4a-single"
+Generate code for the SH4a assuming the floating-point unit is in
+single-precision mode by default.
+.IP "\fB\-m4a\fR" 4
+.IX Item "-m4a"
+Generate code for the SH4a.
+.IP "\fB\-m4al\fR" 4
+.IX Item "-m4al"
+Same as \fB\-m4a\-nofpu\fR, except that it implicitly passes
+\&\fB\-dsp\fR to the assembler.  \s-1GCC\s0 doesn't generate any \s-1DSP\s0
+instructions at the moment.
+.IP "\fB\-mb\fR" 4
+.IX Item "-mb"
+Compile code for the processor in big-endian mode.
+.IP "\fB\-ml\fR" 4
+.IX Item "-ml"
+Compile code for the processor in little-endian mode.
+.IP "\fB\-mdalign\fR" 4
+.IX Item "-mdalign"
+Align doubles at 64\-bit boundaries.  Note that this changes the calling
+conventions, and thus some functions from the standard C library do
+not work unless you recompile it first with \fB\-mdalign\fR.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Shorten some address references at link time, when possible; uses the
+linker option \fB\-relax\fR.
+.IP "\fB\-mbigtable\fR" 4
+.IX Item "-mbigtable"
+Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
+16\-bit offsets.
+.IP "\fB\-mbitops\fR" 4
+.IX Item "-mbitops"
+Enable the use of bit manipulation instructions on \s-1SH2A.\s0
+.IP "\fB\-mfmovd\fR" 4
+.IX Item "-mfmovd"
+Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR.  Check \fB\-mdalign\fR for
+alignment constraints.
+.IP "\fB\-mhitachi\fR" 4
+.IX Item "-mhitachi"
+Comply with the calling conventions defined by Renesas.
+.IP "\fB\-mrenesas\fR" 4
+.IX Item "-mrenesas"
+Comply with the calling conventions defined by Renesas.
+.IP "\fB\-mno\-renesas\fR" 4
+.IX Item "-mno-renesas"
+Comply with the calling conventions defined for \s-1GCC\s0 before the Renesas
+conventions were available.  This option is the default for all
+targets of the \s-1SH\s0 toolchain.
+.IP "\fB\-mnomacsave\fR" 4
+.IX Item "-mnomacsave"
+Mark the \f(CW\*(C`MAC\*(C'\fR register as call-clobbered, even if
+\&\fB\-mhitachi\fR is given.
+.IP "\fB\-mieee\fR" 4
+.IX Item "-mieee"
+.PD 0
+.IP "\fB\-mno\-ieee\fR" 4
+.IX Item "-mno-ieee"
+.PD
+Control the \s-1IEEE\s0 compliance of floating-point comparisons, which affects the
+handling of cases where the result of a comparison is unordered.  By default
+\&\fB\-mieee\fR is implicitly enabled.  If \fB\-ffinite\-math\-only\fR is
+enabled \fB\-mno\-ieee\fR is implicitly set, which results in faster
+floating-point greater-equal and less-equal comparisons.  The implcit settings
+can be overridden by specifying either \fB\-mieee\fR or \fB\-mno\-ieee\fR.
+.IP "\fB\-minline\-ic_invalidate\fR" 4
+.IX Item "-minline-ic_invalidate"
+Inline code to invalidate instruction cache entries after setting up
+nested function trampolines.
+This option has no effect if \fB\-musermode\fR is in effect and the selected
+code generation option (e.g. \fB\-m4\fR) does not allow the use of the \f(CW\*(C`icbi\*(C'\fR
+instruction.
+If the selected code generation option does not allow the use of the \f(CW\*(C`icbi\*(C'\fR
+instruction, and \fB\-musermode\fR is not in effect, the inlined code
+manipulates the instruction cache address array directly with an associative
+write.  This not only requires privileged mode at run time, but it also
+fails if the cache line had been mapped via the \s-1TLB\s0 and has become unmapped.
+.IP "\fB\-misize\fR" 4
+.IX Item "-misize"
+Dump instruction size and location in the assembly code.
+.IP "\fB\-mpadstruct\fR" 4
+.IX Item "-mpadstruct"
+This option is deprecated.  It pads structures to multiple of 4 bytes,
+which is incompatible with the \s-1SH ABI.\s0
+.IP "\fB\-matomic\-model=\fR\fImodel\fR" 4
+.IX Item "-matomic-model=model"
+Sets the model of atomic operations and additional parameters as a comma
+separated list.  For details on the atomic built-in functions see
+\&\fB_\|_atomic Builtins\fR.  The following models and parameters are supported:
+.RS 4
+.IP "\fBnone\fR" 4
+.IX Item "none"
+Disable compiler generated atomic sequences and emit library calls for atomic
+operations.  This is the default if the target is not \f(CW\*(C`sh\-*\-linux*\*(C'\fR.
+.IP "\fBsoft-gusa\fR" 4
+.IX Item "soft-gusa"
+Generate GNU/Linux compatible gUSA software atomic sequences for the atomic
+built-in functions.  The generated atomic sequences require additional support
+from the interrupt/exception handling code of the system and are only suitable
+for SH3* and SH4* single-core systems.  This option is enabled by default when
+the target is \f(CW\*(C`sh\-*\-linux*\*(C'\fR and SH3* or SH4*.  When the target is \s-1SH4A,\s0
+this option will also partially utilize the hardware atomic instructions
+\&\f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR to create more efficient code, unless
+\&\fBstrict\fR is specified.
+.IP "\fBsoft-tcb\fR" 4
+.IX Item "soft-tcb"
+Generate software atomic sequences that use a variable in the thread control
+block.  This is a variation of the gUSA sequences which can also be used on
+SH1* and SH2* targets.  The generated atomic sequences require additional
+support from the interrupt/exception handling code of the system and are only
+suitable for single-core systems.  When using this model, the \fBgbr\-offset=\fR
+parameter has to be specified as well.
+.IP "\fBsoft-imask\fR" 4
+.IX Item "soft-imask"
+Generate software atomic sequences that temporarily disable interrupts by
+setting \f(CW\*(C`SR.IMASK = 1111\*(C'\fR.  This model works only when the program runs
+in privileged mode and is only suitable for single-core systems.  Additional
+support from the interrupt/exception handling code of the system is not
+required.  This model is enabled by default when the target is
+\&\f(CW\*(C`sh\-*\-linux*\*(C'\fR and SH1* or SH2*.
+.IP "\fBhard-llcs\fR" 4
+.IX Item "hard-llcs"
+Generate hardware atomic sequences using the \f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR
+instructions only.  This is only available on \s-1SH4A\s0 and is suitable for
+multi-core systems.  Since the hardware instructions support only 32 bit atomic
+variables access to 8 or 16 bit variables is emulated with 32 bit accesses.
+Code compiled with this option will also be compatible with other software
+atomic model interrupt/exception handling systems if executed on an \s-1SH4A\s0
+system.  Additional support from the interrupt/exception handling code of the
+system is not required for this model.
+.IP "\fBgbr\-offset=\fR" 4
+.IX Item "gbr-offset="
+This parameter specifies the offset in bytes of the variable in the thread
+control block structure that should be used by the generated atomic sequences
+when the \fBsoft-tcb\fR model has been selected.  For other models this
+parameter is ignored.  The specified value must be an integer multiple of four
+and in the range 0\-1020.
+.IP "\fBstrict\fR" 4
+.IX Item "strict"
+This parameter prevents mixed usage of multiple atomic models, even though they
+would be compatible, and will make the compiler generate atomic sequences of the
+specified model only.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mtas\fR" 4
+.IX Item "-mtas"
+Generate the \f(CW\*(C`tas.b\*(C'\fR opcode for \f(CW\*(C`_\|_atomic_test_and_set\*(C'\fR.
+Notice that depending on the particular hardware and software configuration
+this can degrade overall performance due to the operand cache line flushes
+that are implied by the \f(CW\*(C`tas.b\*(C'\fR instruction.  On multi-core \s-1SH4A\s0
+processors the \f(CW\*(C`tas.b\*(C'\fR instruction must be used with caution since it
+can result in data corruption for certain cache configurations.
+.IP "\fB\-mspace\fR" 4
+.IX Item "-mspace"
+Optimize for space instead of speed.  Implied by \fB\-Os\fR.
+.IP "\fB\-mprefergot\fR" 4
+.IX Item "-mprefergot"
+When generating position-independent code, emit function calls using
+the Global Offset Table instead of the Procedure Linkage Table.
+.IP "\fB\-musermode\fR" 4
+.IX Item "-musermode"
+Don't generate privileged mode only code.  This option
+implies \fB\-mno\-inline\-ic_invalidate\fR
+if the inlined code would not work in user mode.
+This is the default when the target is \f(CW\*(C`sh\-*\-linux*\*(C'\fR.
+.IP "\fB\-multcost=\fR\fInumber\fR" 4
+.IX Item "-multcost=number"
+Set the cost to assume for a multiply insn.
+.IP "\fB\-mdiv=\fR\fIstrategy\fR" 4
+.IX Item "-mdiv=strategy"
+Set the division strategy to be used for integer division operations.
+For SHmedia \fIstrategy\fR can be one of:
+.RS 4
+.IP "\fBfp\fR" 4
+.IX Item "fp"
+Performs the operation in floating point.  This has a very high latency,
+but needs only a few instructions, so it might be a good choice if
+your code has enough easily-exploitable \s-1ILP\s0 to allow the compiler to
+schedule the floating-point instructions together with other instructions.
+Division by zero causes a floating-point exception.
+.IP "\fBinv\fR" 4
+.IX Item "inv"
+Uses integer operations to calculate the inverse of the divisor,
+and then multiplies the dividend with the inverse.  This strategy allows
+\&\s-1CSE\s0 and hoisting of the inverse calculation.  Division by zero calculates
+an unspecified result, but does not trap.
+.IP "\fBinv:minlat\fR" 4
+.IX Item "inv:minlat"
+A variant of \fBinv\fR where, if no \s-1CSE\s0 or hoisting opportunities
+have been found, or if the entire operation has been hoisted to the same
+place, the last stages of the inverse calculation are intertwined with the
+final multiply to reduce the overall latency, at the expense of using a few
+more instructions, and thus offering fewer scheduling opportunities with
+other code.
+.IP "\fBcall\fR" 4
+.IX Item "call"
+Calls a library function that usually implements the \fBinv:minlat\fR
+strategy.
+This gives high code density for \f(CW\*(C`m5\-*media\-nofpu\*(C'\fR compilations.
+.IP "\fBcall2\fR" 4
+.IX Item "call2"
+Uses a different entry point of the same library function, where it
+assumes that a pointer to a lookup table has already been set up, which
+exposes the pointer load to \s-1CSE\s0 and code hoisting optimizations.
+.IP "\fBinv:call\fR" 4
+.IX Item "inv:call"
+.PD 0
+.IP "\fBinv:call2\fR" 4
+.IX Item "inv:call2"
+.IP "\fBinv:fp\fR" 4
+.IX Item "inv:fp"
+.PD
+Use the \fBinv\fR algorithm for initial
+code generation, but if the code stays unoptimized, revert to the \fBcall\fR,
+\&\fBcall2\fR, or \fBfp\fR strategies, respectively.  Note that the
+potentially-trapping side effect of division by zero is carried by a
+separate instruction, so it is possible that all the integer instructions
+are hoisted out, but the marker for the side effect stays where it is.
+A recombination to floating-point operations or a call is not possible
+in that case.
+.IP "\fBinv20u\fR" 4
+.IX Item "inv20u"
+.PD 0
+.IP "\fBinv20l\fR" 4
+.IX Item "inv20l"
+.PD
+Variants of the \fBinv:minlat\fR strategy.  In the case
+that the inverse calculation is not separated from the multiply, they speed
+up division where the dividend fits into 20 bits (plus sign where applicable)
+by inserting a test to skip a number of operations in this case; this test
+slows down the case of larger dividends.  \fBinv20u\fR assumes the case of a such
+a small dividend to be unlikely, and \fBinv20l\fR assumes it to be likely.
+.RE
+.RS 4
+.Sp
+For targets other than SHmedia \fIstrategy\fR can be one of:
+.IP "\fBcall\-div1\fR" 4
+.IX Item "call-div1"
+Calls a library function that uses the single-step division instruction
+\&\f(CW\*(C`div1\*(C'\fR to perform the operation.  Division by zero calculates an
+unspecified result and does not trap.  This is the default except for \s-1SH4,
+SH2A\s0 and SHcompact.
+.IP "\fBcall-fp\fR" 4
+.IX Item "call-fp"
+Calls a library function that performs the operation in double precision
+floating point.  Division by zero causes a floating-point exception.  This is
+the default for SHcompact with \s-1FPU. \s0 Specifying this for targets that do not
+have a double precision \s-1FPU\s0 will default to \f(CW\*(C`call\-div1\*(C'\fR.
+.IP "\fBcall-table\fR" 4
+.IX Item "call-table"
+Calls a library function that uses a lookup table for small divisors and
+the \f(CW\*(C`div1\*(C'\fR instruction with case distinction for larger divisors.  Division
+by zero calculates an unspecified result and does not trap.  This is the default
+for \s-1SH4. \s0 Specifying this for targets that do not have dynamic shift
+instructions will default to \f(CW\*(C`call\-div1\*(C'\fR.
+.RE
+.RS 4
+.Sp
+When a division strategy has not been specified the default strategy will be
+selected based on the current target.  For \s-1SH2A\s0 the default strategy is to
+use the \f(CW\*(C`divs\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions instead of library function
+calls.
+.RE
+.IP "\fB\-maccumulate\-outgoing\-args\fR" 4
+.IX Item "-maccumulate-outgoing-args"
+Reserve space once for outgoing arguments in the function prologue rather
+than around each call.  Generally beneficial for performance and size.  Also
+needed for unwinding to avoid changing the stack frame around conditional code.
+.IP "\fB\-mdivsi3_libfunc=\fR\fIname\fR" 4
+.IX Item "-mdivsi3_libfunc=name"
+Set the name of the library function used for 32\-bit signed division to
+\&\fIname\fR.
+This only affects the name used in the \fBcall\fR and \fBinv:call\fR
+division strategies, and the compiler still expects the same
+sets of input/output/clobbered registers as if this option were not present.
+.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
+.IX Item "-mfixed-range=register-range"
+Generate code treating the given register range as fixed registers.
+A fixed register is one that the register allocator can not use.  This is
+useful when compiling kernel code.  A register range is specified as
+two registers separated by a dash.  Multiple register ranges can be
+specified separated by a comma.
+.IP "\fB\-mindexed\-addressing\fR" 4
+.IX Item "-mindexed-addressing"
+Enable the use of the indexed addressing mode for SHmedia32/SHcompact.
+This is only safe if the hardware and/or \s-1OS\s0 implement 32\-bit wrap-around
+semantics for the indexed addressing mode.  The architecture allows the
+implementation of processors with 64\-bit \s-1MMU,\s0 which the \s-1OS\s0 could use to
+get 32\-bit addressing, but since no current hardware implementation supports
+this or any other way to make the indexed addressing mode safe to use in
+the 32\-bit \s-1ABI,\s0 the default is \fB\-mno\-indexed\-addressing\fR.
+.IP "\fB\-mgettrcost=\fR\fInumber\fR" 4
+.IX Item "-mgettrcost=number"
+Set the cost assumed for the \f(CW\*(C`gettr\*(C'\fR instruction to \fInumber\fR.
+The default is 2 if \fB\-mpt\-fixed\fR is in effect, 100 otherwise.
+.IP "\fB\-mpt\-fixed\fR" 4
+.IX Item "-mpt-fixed"
+Assume \f(CW\*(C`pt*\*(C'\fR instructions won't trap.  This generally generates
+better-scheduled code, but is unsafe on current hardware.
+The current architecture
+definition says that \f(CW\*(C`ptabs\*(C'\fR and \f(CW\*(C`ptrel\*(C'\fR trap when the target 
+anded with 3 is 3.
+This has the unintentional effect of making it unsafe to schedule these
+instructions before a branch, or hoist them out of a loop.  For example,
+\&\f(CW\*(C`_\|_do_global_ctors\*(C'\fR, a part of \fIlibgcc\fR
+that runs constructors at program
+startup, calls functions in a list which is delimited by \-1.  With the
+\&\fB\-mpt\-fixed\fR option, the \f(CW\*(C`ptabs\*(C'\fR is done before testing against \-1.
+That means that all the constructors run a bit more quickly, but when
+the loop comes to the end of the list, the program crashes because \f(CW\*(C`ptabs\*(C'\fR
+loads \-1 into a target register.
+.Sp
+Since this option is unsafe for any
+hardware implementing the current architecture specification, the default
+is \fB\-mno\-pt\-fixed\fR.  Unless specified explicitly with 
+\&\fB\-mgettrcost\fR, \fB\-mno\-pt\-fixed\fR also implies \fB\-mgettrcost=100\fR;
+this deters register allocation from using target registers for storing
+ordinary integers.
+.IP "\fB\-minvalid\-symbols\fR" 4
+.IX Item "-minvalid-symbols"
+Assume symbols might be invalid.  Ordinary function symbols generated by
+the compiler are always valid to load with
+\&\f(CW\*(C`movi\*(C'\fR/\f(CW\*(C`shori\*(C'\fR/\f(CW\*(C`ptabs\*(C'\fR or
+\&\f(CW\*(C`movi\*(C'\fR/\f(CW\*(C`shori\*(C'\fR/\f(CW\*(C`ptrel\*(C'\fR,
+but with assembler and/or linker tricks it is possible
+to generate symbols that cause \f(CW\*(C`ptabs\*(C'\fR or \f(CW\*(C`ptrel\*(C'\fR to trap.
+This option is only meaningful when \fB\-mno\-pt\-fixed\fR is in effect.
+It prevents cross-basic-block \s-1CSE,\s0 hoisting and most scheduling
+of symbol loads.  The default is \fB\-mno\-invalid\-symbols\fR.
+.IP "\fB\-mbranch\-cost=\fR\fInum\fR" 4
+.IX Item "-mbranch-cost=num"
+Assume \fInum\fR to be the cost for a branch instruction.  Higher numbers
+make the compiler try to generate more branch-free code if possible.  
+If not specified the value is selected depending on the processor type that
+is being compiled for.
+.IP "\fB\-mzdcbranch\fR" 4
+.IX Item "-mzdcbranch"
+.PD 0
+.IP "\fB\-mno\-zdcbranch\fR" 4
+.IX Item "-mno-zdcbranch"
+.PD
+Assume (do not assume) that zero displacement conditional branch instructions
+\&\f(CW\*(C`bt\*(C'\fR and \f(CW\*(C`bf\*(C'\fR are fast.  If \fB\-mzdcbranch\fR is specified, the
+compiler will try to prefer zero displacement branch code sequences.  This is
+enabled by default when generating code for \s-1SH4\s0 and \s-1SH4A. \s0 It can be explicitly
+disabled by specifying \fB\-mno\-zdcbranch\fR.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Generate code that uses (does not use) the floating-point multiply and
+accumulate instructions.  These instructions are generated by default
+if hardware floating point is used.  The machine-dependent
+\&\fB\-mfused\-madd\fR option is now mapped to the machine-independent
+\&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
+mapped to \fB\-ffp\-contract=off\fR.
+.IP "\fB\-mfsca\fR" 4
+.IX Item "-mfsca"
+.PD 0
+.IP "\fB\-mno\-fsca\fR" 4
+.IX Item "-mno-fsca"
+.PD
+Allow or disallow the compiler to emit the \f(CW\*(C`fsca\*(C'\fR instruction for sine
+and cosine approximations.  The option \f(CW\*(C`\-mfsca\*(C'\fR must be used in
+combination with \f(CW\*(C`\-funsafe\-math\-optimizations\*(C'\fR.  It is enabled by default
+when generating code for \s-1SH4A. \s0 Using \f(CW\*(C`\-mno\-fsca\*(C'\fR disables sine and cosine
+approximations even if \f(CW\*(C`\-funsafe\-math\-optimizations\*(C'\fR is in effect.
+.IP "\fB\-mfsrra\fR" 4
+.IX Item "-mfsrra"
+.PD 0
+.IP "\fB\-mno\-fsrra\fR" 4
+.IX Item "-mno-fsrra"
+.PD
+Allow or disallow the compiler to emit the \f(CW\*(C`fsrra\*(C'\fR instruction for
+reciprocal square root approximations.  The option \f(CW\*(C`\-mfsrra\*(C'\fR must be used
+in combination with \f(CW\*(C`\-funsafe\-math\-optimizations\*(C'\fR and
+\&\f(CW\*(C`\-ffinite\-math\-only\*(C'\fR.  It is enabled by default when generating code for
+\&\s-1SH4A. \s0 Using \f(CW\*(C`\-mno\-fsrra\*(C'\fR disables reciprocal square root approximations
+even if \f(CW\*(C`\-funsafe\-math\-optimizations\*(C'\fR and \f(CW\*(C`\-ffinite\-math\-only\*(C'\fR are
+in effect.
+.IP "\fB\-mpretend\-cmove\fR" 4
+.IX Item "-mpretend-cmove"
+Prefer zero-displacement conditional branches for conditional move instruction
+patterns.  This can result in faster code on the \s-1SH4\s0 processor.
+.PP
+\fISolaris 2 Options\fR
+.IX Subsection "Solaris 2 Options"
+.PP
+These \fB\-m\fR options are supported on Solaris 2:
+.IP "\fB\-mimpure\-text\fR" 4
+.IX Item "-mimpure-text"
+\&\fB\-mimpure\-text\fR, used in addition to \fB\-shared\fR, tells
+the compiler to not pass \fB\-z text\fR to the linker when linking a
+shared object.  Using this option, you can link position-dependent
+code into a shared object.
+.Sp
+\&\fB\-mimpure\-text\fR suppresses the \*(L"relocations remain against
+allocatable but non-writable sections\*(R" linker error message.
+However, the necessary relocations trigger copy-on-write, and the
+shared object is not actually shared across processes.  Instead of
+using \fB\-mimpure\-text\fR, you should compile all source code with
+\&\fB\-fpic\fR or \fB\-fPIC\fR.
+.PP
+These switches are supported in addition to the above on Solaris 2:
+.IP "\fB\-pthreads\fR" 4
+.IX Item "-pthreads"
+Add support for multithreading using the \s-1POSIX\s0 threads library.  This
+option sets flags for both the preprocessor and linker.  This option does
+not affect the thread safety of object code produced  by the compiler or
+that of libraries supplied with it.
+.IP "\fB\-pthread\fR" 4
+.IX Item "-pthread"
+This is a synonym for \fB\-pthreads\fR.
+.PP
+\fI\s-1SPARC\s0 Options\fR
+.IX Subsection "SPARC Options"
+.PP
+These \fB\-m\fR options are supported on the \s-1SPARC:\s0
+.IP "\fB\-mno\-app\-regs\fR" 4
+.IX Item "-mno-app-regs"
+.PD 0
+.IP "\fB\-mapp\-regs\fR" 4
+.IX Item "-mapp-regs"
+.PD
+Specify \fB\-mapp\-regs\fR to generate output using the global registers
+2 through 4, which the \s-1SPARC SVR4 ABI\s0 reserves for applications.  Like the
+global register 1, each global register 2 through 4 is then treated as an
+allocable register that is clobbered by function calls.  This is the default.
+.Sp
+To be fully \s-1SVR4\s0 ABI-compliant at the cost of some performance loss,
+specify \fB\-mno\-app\-regs\fR.  You should compile libraries and system
+software with this option.
+.IP "\fB\-mflat\fR" 4
+.IX Item "-mflat"
+.PD 0
+.IP "\fB\-mno\-flat\fR" 4
+.IX Item "-mno-flat"
+.PD
+With \fB\-mflat\fR, the compiler does not generate save/restore instructions
+and uses a \*(L"flat\*(R" or single register window model.  This model is compatible
+with the regular register window model.  The local registers and the input
+registers (0\-\-5) are still treated as \*(L"call-saved\*(R" registers and are
+saved on the stack as needed.
+.Sp
+With \fB\-mno\-flat\fR (the default), the compiler generates save/restore
+instructions (except for leaf functions).  This is the normal operating mode.
+.IP "\fB\-mfpu\fR" 4
+.IX Item "-mfpu"
+.PD 0
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD
+Generate output containing floating-point instructions.  This is the
+default.
+.IP "\fB\-mno\-fpu\fR" 4
+.IX Item "-mno-fpu"
+.PD 0
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD
+Generate output containing library calls for floating point.
+\&\fBWarning:\fR the requisite libraries are not available for all \s-1SPARC\s0
+targets.  Normally the facilities of the machine's usual C compiler are
+used, but this cannot be done directly in cross-compilation.  You must make
+your own arrangements to provide suitable library functions for
+cross-compilation.  The embedded targets \fBsparc\-*\-aout\fR and
+\&\fBsparclite\-*\-*\fR do provide software floating-point support.
+.Sp
+\&\fB\-msoft\-float\fR changes the calling convention in the output file;
+therefore, it is only useful if you compile \fIall\fR of a program with
+this option.  In particular, you need to compile \fIlibgcc.a\fR, the
+library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
+this to work.
+.IP "\fB\-mhard\-quad\-float\fR" 4
+.IX Item "-mhard-quad-float"
+Generate output containing quad-word (long double) floating-point
+instructions.
+.IP "\fB\-msoft\-quad\-float\fR" 4
+.IX Item "-msoft-quad-float"
+Generate output containing library calls for quad-word (long double)
+floating-point instructions.  The functions called are those specified
+in the \s-1SPARC ABI. \s0 This is the default.
+.Sp
+As of this writing, there are no \s-1SPARC\s0 implementations that have hardware
+support for the quad-word floating-point instructions.  They all invoke
+a trap handler for one of these instructions, and then the trap handler
+emulates the effect of the instruction.  Because of the trap handler overhead,
+this is much slower than calling the \s-1ABI\s0 library routines.  Thus the
+\&\fB\-msoft\-quad\-float\fR option is the default.
+.IP "\fB\-mno\-unaligned\-doubles\fR" 4
+.IX Item "-mno-unaligned-doubles"
+.PD 0
+.IP "\fB\-munaligned\-doubles\fR" 4
+.IX Item "-munaligned-doubles"
+.PD
+Assume that doubles have 8\-byte alignment.  This is the default.
+.Sp
+With \fB\-munaligned\-doubles\fR, \s-1GCC\s0 assumes that doubles have 8\-byte
+alignment only if they are contained in another type, or if they have an
+absolute address.  Otherwise, it assumes they have 4\-byte alignment.
+Specifying this option avoids some rare compatibility problems with code
+generated by other compilers.  It is not the default because it results
+in a performance loss, especially for floating-point code.
+.IP "\fB\-mno\-faster\-structs\fR" 4
+.IX Item "-mno-faster-structs"
+.PD 0
+.IP "\fB\-mfaster\-structs\fR" 4
+.IX Item "-mfaster-structs"
+.PD
+With \fB\-mfaster\-structs\fR, the compiler assumes that structures
+should have 8\-byte alignment.  This enables the use of pairs of
+\&\f(CW\*(C`ldd\*(C'\fR and \f(CW\*(C`std\*(C'\fR instructions for copies in structure
+assignment, in place of twice as many \f(CW\*(C`ld\*(C'\fR and \f(CW\*(C`st\*(C'\fR pairs.
+However, the use of this changed alignment directly violates the \s-1SPARC
+ABI. \s0 Thus, it's intended only for use on targets where the developer
+acknowledges that their resulting code is not directly in line with
+the rules of the \s-1ABI.\s0
+.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
+.IX Item "-mcpu=cpu_type"
+Set the instruction set, register set, and instruction scheduling parameters
+for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
+\&\fBv7\fR, \fBcypress\fR, \fBv8\fR, \fBsupersparc\fR, \fBhypersparc\fR,
+\&\fBleon\fR, \fBleon3\fR, \fBsparclite\fR, \fBf930\fR, \fBf934\fR,
+\&\fBsparclite86x\fR, \fBsparclet\fR, \fBtsc701\fR, \fBv9\fR,
+\&\fBultrasparc\fR, \fBultrasparc3\fR, \fBniagara\fR, \fBniagara2\fR,
+\&\fBniagara3\fR and \fBniagara4\fR.
+.Sp
+Native Solaris and GNU/Linux toolchains also support the value \fBnative\fR,
+which selects the best architecture option for the host processor.
+\&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
+the processor.
+.Sp
+Default instruction scheduling parameters are used for values that select
+an architecture and not an implementation.  These are \fBv7\fR, \fBv8\fR,
+\&\fBsparclite\fR, \fBsparclet\fR, \fBv9\fR.
+.Sp
+Here is a list of each supported architecture and their supported
+implementations.
+.RS 4
+.IP "v7" 4
+.IX Item "v7"
+cypress
+.IP "v8" 4
+.IX Item "v8"
+supersparc, hypersparc, leon, leon3
+.IP "sparclite" 4
+.IX Item "sparclite"
+f930, f934, sparclite86x
+.IP "sparclet" 4
+.IX Item "sparclet"
+tsc701
+.IP "v9" 4
+.IX Item "v9"
+ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4
+.RE
+.RS 4
+.Sp
+By default (unless configured otherwise), \s-1GCC\s0 generates code for the V7
+variant of the \s-1SPARC\s0 architecture.  With \fB\-mcpu=cypress\fR, the compiler
+additionally optimizes it for the Cypress \s-1CY7C602\s0 chip, as used in the
+SPARCStation/SPARCServer 3xx series.  This is also appropriate for the older
+SPARCStation 1, 2, \s-1IPX\s0 etc.
+.Sp
+With \fB\-mcpu=v8\fR, \s-1GCC\s0 generates code for the V8 variant of the \s-1SPARC\s0
+architecture.  The only difference from V7 code is that the compiler emits
+the integer multiply and integer divide instructions which exist in \s-1SPARC\-V8\s0
+but not in \s-1SPARC\-V7. \s0 With \fB\-mcpu=supersparc\fR, the compiler additionally
+optimizes it for the SuperSPARC chip, as used in the SPARCStation 10, 1000 and
+2000 series.
+.Sp
+With \fB\-mcpu=sparclite\fR, \s-1GCC\s0 generates code for the SPARClite variant of
+the \s-1SPARC\s0 architecture.  This adds the integer multiply, integer divide step
+and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClite but not in \s-1SPARC\-V7.\s0
+With \fB\-mcpu=f930\fR, the compiler additionally optimizes it for the
+Fujitsu \s-1MB86930\s0 chip, which is the original SPARClite, with no \s-1FPU. \s0 With
+\&\fB\-mcpu=f934\fR, the compiler additionally optimizes it for the Fujitsu
+\&\s-1MB86934\s0 chip, which is the more recent SPARClite with \s-1FPU.\s0
+.Sp
+With \fB\-mcpu=sparclet\fR, \s-1GCC\s0 generates code for the SPARClet variant of
+the \s-1SPARC\s0 architecture.  This adds the integer multiply, multiply/accumulate,
+integer divide step and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClet
+but not in \s-1SPARC\-V7. \s0 With \fB\-mcpu=tsc701\fR, the compiler additionally
+optimizes it for the \s-1TEMIC\s0 SPARClet chip.
+.Sp
+With \fB\-mcpu=v9\fR, \s-1GCC\s0 generates code for the V9 variant of the \s-1SPARC\s0
+architecture.  This adds 64\-bit integer and floating-point move instructions,
+3 additional floating-point condition code registers and conditional move
+instructions.  With \fB\-mcpu=ultrasparc\fR, the compiler additionally
+optimizes it for the Sun UltraSPARC I/II/IIi chips.  With
+\&\fB\-mcpu=ultrasparc3\fR, the compiler additionally optimizes it for the
+Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+ chips.  With
+\&\fB\-mcpu=niagara\fR, the compiler additionally optimizes it for
+Sun UltraSPARC T1 chips.  With \fB\-mcpu=niagara2\fR, the compiler
+additionally optimizes it for Sun UltraSPARC T2 chips. With
+\&\fB\-mcpu=niagara3\fR, the compiler additionally optimizes it for Sun
+UltraSPARC T3 chips.  With \fB\-mcpu=niagara4\fR, the compiler
+additionally optimizes it for Sun UltraSPARC T4 chips.
+.RE
+.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
+.IX Item "-mtune=cpu_type"
+Set the instruction scheduling parameters for machine type
+\&\fIcpu_type\fR, but do not set the instruction set or register set that the
+option \fB\-mcpu=\fR\fIcpu_type\fR does.
+.Sp
+The same values for \fB\-mcpu=\fR\fIcpu_type\fR can be used for
+\&\fB\-mtune=\fR\fIcpu_type\fR, but the only useful values are those
+that select a particular \s-1CPU\s0 implementation.  Those are \fBcypress\fR,
+\&\fBsupersparc\fR, \fBhypersparc\fR, \fBleon\fR, \fBleon3\fR, \fBf930\fR,
+\&\fBf934\fR, \fBsparclite86x\fR, \fBtsc701\fR, \fBultrasparc\fR,
+\&\fBultrasparc3\fR, \fBniagara\fR, \fBniagara2\fR, \fBniagara3\fR and
+\&\fBniagara4\fR.  With native Solaris and GNU/Linux toolchains, \fBnative\fR
+can also be used.
+.IP "\fB\-mv8plus\fR" 4
+.IX Item "-mv8plus"
+.PD 0
+.IP "\fB\-mno\-v8plus\fR" 4
+.IX Item "-mno-v8plus"
+.PD
+With \fB\-mv8plus\fR, \s-1GCC\s0 generates code for the \s-1SPARC\-V8+ ABI. \s0 The
+difference from the V8 \s-1ABI\s0 is that the global and out registers are
+considered 64 bits wide.  This is enabled by default on Solaris in 32\-bit
+mode for all \s-1SPARC\-V9\s0 processors.
+.IP "\fB\-mvis\fR" 4
+.IX Item "-mvis"
+.PD 0
+.IP "\fB\-mno\-vis\fR" 4
+.IX Item "-mno-vis"
+.PD
+With \fB\-mvis\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
+Visual Instruction Set extensions.  The default is \fB\-mno\-vis\fR.
+.IP "\fB\-mvis2\fR" 4
+.IX Item "-mvis2"
+.PD 0
+.IP "\fB\-mno\-vis2\fR" 4
+.IX Item "-mno-vis2"
+.PD
+With \fB\-mvis2\fR, \s-1GCC\s0 generates code that takes advantage of
+version 2.0 of the UltraSPARC Visual Instruction Set extensions.  The
+default is \fB\-mvis2\fR when targeting a cpu that supports such
+instructions, such as UltraSPARC-III and later.  Setting \fB\-mvis2\fR
+also sets \fB\-mvis\fR.
+.IP "\fB\-mvis3\fR" 4
+.IX Item "-mvis3"
+.PD 0
+.IP "\fB\-mno\-vis3\fR" 4
+.IX Item "-mno-vis3"
+.PD
+With \fB\-mvis3\fR, \s-1GCC\s0 generates code that takes advantage of
+version 3.0 of the UltraSPARC Visual Instruction Set extensions.  The
+default is \fB\-mvis3\fR when targeting a cpu that supports such
+instructions, such as niagara\-3 and later.  Setting \fB\-mvis3\fR
+also sets \fB\-mvis2\fR and \fB\-mvis\fR.
+.IP "\fB\-mcbcond\fR" 4
+.IX Item "-mcbcond"
+.PD 0
+.IP "\fB\-mno\-cbcond\fR" 4
+.IX Item "-mno-cbcond"
+.PD
+With \fB\-mcbcond\fR, \s-1GCC\s0 generates code that takes advantage of
+compare-and-branch instructions, as defined in the Sparc Architecture 2011.
+The default is \fB\-mcbcond\fR when targeting a cpu that supports such
+instructions, such as niagara\-4 and later.
+.IP "\fB\-mpopc\fR" 4
+.IX Item "-mpopc"
+.PD 0
+.IP "\fB\-mno\-popc\fR" 4
+.IX Item "-mno-popc"
+.PD
+With \fB\-mpopc\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
+population count instruction.  The default is \fB\-mpopc\fR
+when targeting a cpu that supports such instructions, such as Niagara\-2 and
+later.
+.IP "\fB\-mfmaf\fR" 4
+.IX Item "-mfmaf"
+.PD 0
+.IP "\fB\-mno\-fmaf\fR" 4
+.IX Item "-mno-fmaf"
+.PD
+With \fB\-mfmaf\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
+Fused Multiply-Add Floating-point extensions.  The default is \fB\-mfmaf\fR
+when targeting a cpu that supports such instructions, such as Niagara\-3 and
+later.
+.IP "\fB\-mfix\-at697f\fR" 4
+.IX Item "-mfix-at697f"
+Enable the documented workaround for the single erratum of the Atmel \s-1AT697F\s0
+processor (which corresponds to erratum #13 of the \s-1AT697E\s0 processor).
+.IP "\fB\-mfix\-ut699\fR" 4
+.IX Item "-mfix-ut699"
+Enable the documented workarounds for the floating-point errata and the data
+cache nullify errata of the \s-1UT699\s0 processor.
+.PP
+These \fB\-m\fR options are supported in addition to the above
+on \s-1SPARC\-V9\s0 processors in 64\-bit environments:
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+.PD 0
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.PD
+Generate code for a 32\-bit or 64\-bit environment.
+The 32\-bit environment sets int, long and pointer to 32 bits.
+The 64\-bit environment sets int to 32 bits and long and pointer
+to 64 bits.
+.IP "\fB\-mcmodel=\fR\fIwhich\fR" 4
+.IX Item "-mcmodel=which"
+Set the code model to one of
+.RS 4
+.IP "\fBmedlow\fR" 4
+.IX Item "medlow"
+The Medium/Low code model: 64\-bit addresses, programs
+must be linked in the low 32 bits of memory.  Programs can be statically
+or dynamically linked.
+.IP "\fBmedmid\fR" 4
+.IX Item "medmid"
+The Medium/Middle code model: 64\-bit addresses, programs
+must be linked in the low 44 bits of memory, the text and data segments must
+be less than 2GB in size and the data segment must be located within 2GB of
+the text segment.
+.IP "\fBmedany\fR" 4
+.IX Item "medany"
+The Medium/Anywhere code model: 64\-bit addresses, programs
+may be linked anywhere in memory, the text and data segments must be less
+than 2GB in size and the data segment must be located within 2GB of the
+text segment.
+.IP "\fBembmedany\fR" 4
+.IX Item "embmedany"
+The Medium/Anywhere code model for embedded systems:
+64\-bit addresses, the text and data segments must be less than 2GB in
+size, both starting anywhere in memory (determined at link time).  The
+global register \f(CW%g4\fR points to the base of the data segment.  Programs
+are statically linked and \s-1PIC\s0 is not supported.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mmemory\-model=\fR\fImem-model\fR" 4
+.IX Item "-mmemory-model=mem-model"
+Set the memory model in force on the processor to one of
+.RS 4
+.IP "\fBdefault\fR" 4
+.IX Item "default"
+The default memory model for the processor and operating system.
+.IP "\fBrmo\fR" 4
+.IX Item "rmo"
+Relaxed Memory Order
+.IP "\fBpso\fR" 4
+.IX Item "pso"
+Partial Store Order
+.IP "\fBtso\fR" 4
+.IX Item "tso"
+Total Store Order
+.IP "\fBsc\fR" 4
+.IX Item "sc"
+Sequential Consistency
+.RE
+.RS 4
+.Sp
+These memory models are formally defined in Appendix D of the Sparc V9
+architecture manual, as set in the processor's \f(CW\*(C`PSTATE.MM\*(C'\fR field.
+.RE
+.IP "\fB\-mstack\-bias\fR" 4
+.IX Item "-mstack-bias"
+.PD 0
+.IP "\fB\-mno\-stack\-bias\fR" 4
+.IX Item "-mno-stack-bias"
+.PD
+With \fB\-mstack\-bias\fR, \s-1GCC\s0 assumes that the stack pointer, and
+frame pointer if present, are offset by \-2047 which must be added back
+when making stack frame references.  This is the default in 64\-bit mode.
+Otherwise, assume no such offset is present.
+.PP
+\fI\s-1SPU\s0 Options\fR
+.IX Subsection "SPU Options"
+.PP
+These \fB\-m\fR options are supported on the \s-1SPU:\s0
+.IP "\fB\-mwarn\-reloc\fR" 4
+.IX Item "-mwarn-reloc"
+.PD 0
+.IP "\fB\-merror\-reloc\fR" 4
+.IX Item "-merror-reloc"
+.PD
+The loader for \s-1SPU\s0 does not handle dynamic relocations.  By default, \s-1GCC\s0
+gives an error when it generates code that requires a dynamic
+relocation.  \fB\-mno\-error\-reloc\fR disables the error,
+\&\fB\-mwarn\-reloc\fR generates a warning instead.
+.IP "\fB\-msafe\-dma\fR" 4
+.IX Item "-msafe-dma"
+.PD 0
+.IP "\fB\-munsafe\-dma\fR" 4
+.IX Item "-munsafe-dma"
+.PD
+Instructions that initiate or test completion of \s-1DMA\s0 must not be
+reordered with respect to loads and stores of the memory that is being
+accessed.
+With \fB\-munsafe\-dma\fR you must use the \f(CW\*(C`volatile\*(C'\fR keyword to protect
+memory accesses, but that can lead to inefficient code in places where the
+memory is known to not change.  Rather than mark the memory as volatile,
+you can use \fB\-msafe\-dma\fR to tell the compiler to treat
+the \s-1DMA\s0 instructions as potentially affecting all memory.
+.IP "\fB\-mbranch\-hints\fR" 4
+.IX Item "-mbranch-hints"
+By default, \s-1GCC\s0 generates a branch hint instruction to avoid
+pipeline stalls for always-taken or probably-taken branches.  A hint
+is not generated closer than 8 instructions away from its branch.
+There is little reason to disable them, except for debugging purposes,
+or to make an object a little bit smaller.
+.IP "\fB\-msmall\-mem\fR" 4
+.IX Item "-msmall-mem"
+.PD 0
+.IP "\fB\-mlarge\-mem\fR" 4
+.IX Item "-mlarge-mem"
+.PD
+By default, \s-1GCC\s0 generates code assuming that addresses are never larger
+than 18 bits.  With \fB\-mlarge\-mem\fR code is generated that assumes
+a full 32\-bit address.
+.IP "\fB\-mstdmain\fR" 4
+.IX Item "-mstdmain"
+By default, \s-1GCC\s0 links against startup code that assumes the SPU-style
+main function interface (which has an unconventional parameter list).
+With \fB\-mstdmain\fR, \s-1GCC\s0 links your program against startup
+code that assumes a C99\-style interface to \f(CW\*(C`main\*(C'\fR, including a
+local copy of \f(CW\*(C`argv\*(C'\fR strings.
+.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
+.IX Item "-mfixed-range=register-range"
+Generate code treating the given register range as fixed registers.
+A fixed register is one that the register allocator cannot use.  This is
+useful when compiling kernel code.  A register range is specified as
+two registers separated by a dash.  Multiple register ranges can be
+specified separated by a comma.
+.IP "\fB\-mea32\fR" 4
+.IX Item "-mea32"
+.PD 0
+.IP "\fB\-mea64\fR" 4
+.IX Item "-mea64"
+.PD
+Compile code assuming that pointers to the \s-1PPU\s0 address space accessed
+via the \f(CW\*(C`_\|_ea\*(C'\fR named address space qualifier are either 32 or 64
+bits wide.  The default is 32 bits.  As this is an ABI-changing option,
+all object code in an executable must be compiled with the same setting.
+.IP "\fB\-maddress\-space\-conversion\fR" 4
+.IX Item "-maddress-space-conversion"
+.PD 0
+.IP "\fB\-mno\-address\-space\-conversion\fR" 4
+.IX Item "-mno-address-space-conversion"
+.PD
+Allow/disallow treating the \f(CW\*(C`_\|_ea\*(C'\fR address space as superset
+of the generic address space.  This enables explicit type casts
+between \f(CW\*(C`_\|_ea\*(C'\fR and generic pointer as well as implicit
+conversions of generic pointers to \f(CW\*(C`_\|_ea\*(C'\fR pointers.  The
+default is to allow address space pointer conversions.
+.IP "\fB\-mcache\-size=\fR\fIcache-size\fR" 4
+.IX Item "-mcache-size=cache-size"
+This option controls the version of libgcc that the compiler links to an
+executable and selects a software-managed cache for accessing variables
+in the \f(CW\*(C`_\|_ea\*(C'\fR address space with a particular cache size.  Possible
+options for \fIcache-size\fR are \fB8\fR, \fB16\fR, \fB32\fR, \fB64\fR
+and \fB128\fR.  The default cache size is 64KB.
+.IP "\fB\-matomic\-updates\fR" 4
+.IX Item "-matomic-updates"
+.PD 0
+.IP "\fB\-mno\-atomic\-updates\fR" 4
+.IX Item "-mno-atomic-updates"
+.PD
+This option controls the version of libgcc that the compiler links to an
+executable and selects whether atomic updates to the software-managed
+cache of PPU-side variables are used.  If you use atomic updates, changes
+to a \s-1PPU\s0 variable from \s-1SPU\s0 code using the \f(CW\*(C`_\|_ea\*(C'\fR named address space
+qualifier do not interfere with changes to other \s-1PPU\s0 variables residing
+in the same cache line from \s-1PPU\s0 code.  If you do not use atomic updates,
+such interference may occur; however, writing back cache lines is
+more efficient.  The default behavior is to use atomic updates.
+.IP "\fB\-mdual\-nops\fR" 4
+.IX Item "-mdual-nops"
+.PD 0
+.IP "\fB\-mdual\-nops=\fR\fIn\fR" 4
+.IX Item "-mdual-nops=n"
+.PD
+By default, \s-1GCC\s0 inserts nops to increase dual issue when it expects
+it to increase performance.  \fIn\fR can be a value from 0 to 10.  A
+smaller \fIn\fR inserts fewer nops.  10 is the default, 0 is the
+same as \fB\-mno\-dual\-nops\fR.  Disabled with \fB\-Os\fR.
+.IP "\fB\-mhint\-max\-nops=\fR\fIn\fR" 4
+.IX Item "-mhint-max-nops=n"
+Maximum number of nops to insert for a branch hint.  A branch hint must
+be at least 8 instructions away from the branch it is affecting.  \s-1GCC\s0
+inserts up to \fIn\fR nops to enforce this, otherwise it does not
+generate the branch hint.
+.IP "\fB\-mhint\-max\-distance=\fR\fIn\fR" 4
+.IX Item "-mhint-max-distance=n"
+The encoding of the branch hint instruction limits the hint to be within
+256 instructions of the branch it is affecting.  By default, \s-1GCC\s0 makes
+sure it is within 125.
+.IP "\fB\-msafe\-hints\fR" 4
+.IX Item "-msafe-hints"
+Work around a hardware bug that causes the \s-1SPU\s0 to stall indefinitely.
+By default, \s-1GCC\s0 inserts the \f(CW\*(C`hbrp\*(C'\fR instruction to make sure
+this stall won't happen.
+.PP
+\fIOptions for System V\fR
+.IX Subsection "Options for System V"
+.PP
+These additional options are available on System V Release 4 for
+compatibility with other compilers on those systems:
+.IP "\fB\-G\fR" 4
+.IX Item "-G"
+Create a shared object.
+It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead.
+.IP "\fB\-Qy\fR" 4
+.IX Item "-Qy"
+Identify the versions of each tool used by the compiler, in a
+\&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output.
+.IP "\fB\-Qn\fR" 4
+.IX Item "-Qn"
+Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is
+the default).
+.IP "\fB\-YP,\fR\fIdirs\fR" 4
+.IX Item "-YP,dirs"
+Search the directories \fIdirs\fR, and no others, for libraries
+specified with \fB\-l\fR.
+.IP "\fB\-Ym,\fR\fIdir\fR" 4
+.IX Item "-Ym,dir"
+Look in the directory \fIdir\fR to find the M4 preprocessor.
+The assembler uses this option.
+.PP
+\fITILE-Gx Options\fR
+.IX Subsection "TILE-Gx Options"
+.PP
+These \fB\-m\fR options are supported on the TILE-Gx:
+.IP "\fB\-mcmodel=small\fR" 4
+.IX Item "-mcmodel=small"
+Generate code for the small model.  The distance for direct calls is
+limited to 500M in either direction.  PC-relative addresses are 32
+bits.  Absolute addresses support the full address range.
+.IP "\fB\-mcmodel=large\fR" 4
+.IX Item "-mcmodel=large"
+Generate code for the large model.  There is no limitation on call
+distance, pc-relative addresses, or absolute addresses.
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Selects the type of \s-1CPU\s0 to be targeted.  Currently the only supported
+type is \fBtilegx\fR.
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+.PD 0
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.PD
+Generate code for a 32\-bit or 64\-bit environment.  The 32\-bit
+environment sets int, long, and pointer to 32 bits.  The 64\-bit
+environment sets int to 32 bits and long and pointer to 64 bits.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+.PD 0
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+.PD
+Generate code in big/little endian mode, respectively.
+.PP
+\fITILEPro Options\fR
+.IX Subsection "TILEPro Options"
+.PP
+These \fB\-m\fR options are supported on the TILEPro:
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Selects the type of \s-1CPU\s0 to be targeted.  Currently the only supported
+type is \fBtilepro\fR.
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+Generate code for a 32\-bit environment, which sets int, long, and
+pointer to 32 bits.  This is the only supported behavior so the flag
+is essentially ignored.
+.PP
+\fIV850 Options\fR
+.IX Subsection "V850 Options"
+.PP
+These \fB\-m\fR options are defined for V850 implementations:
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+.PD 0
+.IP "\fB\-mno\-long\-calls\fR" 4
+.IX Item "-mno-long-calls"
+.PD
+Treat all calls as being far away (near).  If calls are assumed to be
+far away, the compiler always loads the function's address into a
+register, and calls indirect through the pointer.
+.IP "\fB\-mno\-ep\fR" 4
+.IX Item "-mno-ep"
+.PD 0
+.IP "\fB\-mep\fR" 4
+.IX Item "-mep"
+.PD
+Do not optimize (do optimize) basic blocks that use the same index
+pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and
+use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions.  The \fB\-mep\fR
+option is on by default if you optimize.
+.IP "\fB\-mno\-prolog\-function\fR" 4
+.IX Item "-mno-prolog-function"
+.PD 0
+.IP "\fB\-mprolog\-function\fR" 4
+.IX Item "-mprolog-function"
+.PD
+Do not use (do use) external functions to save and restore registers
+at the prologue and epilogue of a function.  The external functions
+are slower, but use less code space if more than one function saves
+the same number of registers.  The \fB\-mprolog\-function\fR option
+is on by default if you optimize.
+.IP "\fB\-mspace\fR" 4
+.IX Item "-mspace"
+Try to make the code as small as possible.  At present, this just turns
+on the \fB\-mep\fR and \fB\-mprolog\-function\fR options.
+.IP "\fB\-mtda=\fR\fIn\fR" 4
+.IX Item "-mtda=n"
+Put static or global variables whose size is \fIn\fR bytes or less into
+the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to.  The tiny data
+area can hold up to 256 bytes in total (128 bytes for byte references).
+.IP "\fB\-msda=\fR\fIn\fR" 4
+.IX Item "-msda=n"
+Put static or global variables whose size is \fIn\fR bytes or less into
+the small data area that register \f(CW\*(C`gp\*(C'\fR points to.  The small data
+area can hold up to 64 kilobytes.
+.IP "\fB\-mzda=\fR\fIn\fR" 4
+.IX Item "-mzda=n"
+Put static or global variables whose size is \fIn\fR bytes or less into
+the first 32 kilobytes of memory.
+.IP "\fB\-mv850\fR" 4
+.IX Item "-mv850"
+Specify that the target processor is the V850.
+.IP "\fB\-mv850e3v5\fR" 4
+.IX Item "-mv850e3v5"
+Specify that the target processor is the V850E3V5.  The preprocessor
+constant \fB_\|_v850e3v5_\|_\fR is defined if this option is used.
+.IP "\fB\-mv850e2v4\fR" 4
+.IX Item "-mv850e2v4"
+Specify that the target processor is the V850E3V5.  This is an alias for
+the \fB\-mv850e3v5\fR option.
+.IP "\fB\-mv850e2v3\fR" 4
+.IX Item "-mv850e2v3"
+Specify that the target processor is the V850E2V3.  The preprocessor
+constant \fB_\|_v850e2v3_\|_\fR is defined if this option is used.
+.IP "\fB\-mv850e2\fR" 4
+.IX Item "-mv850e2"
+Specify that the target processor is the V850E2.  The preprocessor
+constant \fB_\|_v850e2_\|_\fR is defined if this option is used.
+.IP "\fB\-mv850e1\fR" 4
+.IX Item "-mv850e1"
+Specify that the target processor is the V850E1.  The preprocessor
+constants \fB_\|_v850e1_\|_\fR and \fB_\|_v850e_\|_\fR are defined if
+this option is used.
+.IP "\fB\-mv850es\fR" 4
+.IX Item "-mv850es"
+Specify that the target processor is the V850ES.  This is an alias for
+the \fB\-mv850e1\fR option.
+.IP "\fB\-mv850e\fR" 4
+.IX Item "-mv850e"
+Specify that the target processor is the V850E.  The preprocessor
+constant \fB_\|_v850e_\|_\fR is defined if this option is used.
+.Sp
+If neither \fB\-mv850\fR nor \fB\-mv850e\fR nor \fB\-mv850e1\fR
+nor \fB\-mv850e2\fR nor \fB\-mv850e2v3\fR nor \fB\-mv850e3v5\fR
+are defined then a default target processor is chosen and the
+relevant \fB_\|_v850*_\|_\fR preprocessor constant is defined.
+.Sp
+The preprocessor constants \fB_\|_v850\fR and \fB_\|_v851_\|_\fR are always
+defined, regardless of which processor variant is the target.
+.IP "\fB\-mdisable\-callt\fR" 4
+.IX Item "-mdisable-callt"
+.PD 0
+.IP "\fB\-mno\-disable\-callt\fR" 4
+.IX Item "-mno-disable-callt"
+.PD
+This option suppresses generation of the \f(CW\*(C`CALLT\*(C'\fR instruction for the
+v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the v850
+architecture.
+.Sp
+This option is enabled by default when the \s-1RH850 ABI\s0 is
+in use (see \fB\-mrh850\-abi\fR), and disabled by default when the
+\&\s-1GCC ABI\s0 is in use.  If \f(CW\*(C`CALLT\*(C'\fR instructions are being generated
+then the C preprocessor symbol \f(CW\*(C`_\|_V850_CALLT_\|_\*(C'\fR will be defined.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+.PD 0
+.IP "\fB\-mno\-relax\fR" 4
+.IX Item "-mno-relax"
+.PD
+Pass on (or do not pass on) the \fB\-mrelax\fR command line option
+to the assembler.
+.IP "\fB\-mlong\-jumps\fR" 4
+.IX Item "-mlong-jumps"
+.PD 0
+.IP "\fB\-mno\-long\-jumps\fR" 4
+.IX Item "-mno-long-jumps"
+.PD
+Disable (or re-enable) the generation of PC-relative jump instructions.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD 0
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD
+Disable (or re-enable) the generation of hardware floating point
+instructions.  This option is only significant when the target
+architecture is \fBV850E2V3\fR or higher.  If hardware floating point
+instructions are being generated then the C preprocessor symbol
+\&\f(CW\*(C`_\|_FPU_OK_\|_\*(C'\fR will be defined, otherwise the symbol
+\&\f(CW\*(C`_\|_NO_FPU_\|_\*(C'\fR will be defined.
+.IP "\fB\-mloop\fR" 4
+.IX Item "-mloop"
+Enables the use of the e3v5 \s-1LOOP\s0 instruction.  The use of this
+instruction is not enabled by default when the e3v5 architecture is
+selected because its use is still experimental.
+.IP "\fB\-mrh850\-abi\fR" 4
+.IX Item "-mrh850-abi"
+.PD 0
+.IP "\fB\-mghs\fR" 4
+.IX Item "-mghs"
+.PD
+Enables support for the \s-1RH850\s0 version of the V850 \s-1ABI. \s0 This is the
+default.  With this version of the \s-1ABI\s0 the following rules apply:
+.RS 4
+.IP "\(bu" 4
+Integer sized structures and unions are returned via a memory pointer
+rather than a register.
+.IP "\(bu" 4
+Large structures and unions (more than 8 bytes in size) are passed by
+value.
+.IP "\(bu" 4
+Functions are aligned to 16\-bit boundaries.
+.IP "\(bu" 4
+The \fB\-m8byte\-align\fR command line option is supported.
+.IP "\(bu" 4
+The \fB\-mdisable\-callt\fR command line option is enabled by
+default.  The \fB\-mno\-disable\-callt\fR command line option is not
+supported.
+.RE
+.RS 4
+.Sp
+When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
+\&\f(CW\*(C`_\|_V850_RH850_ABI_\|_\*(C'\fR is defined.
+.RE
+.IP "\fB\-mgcc\-abi\fR" 4
+.IX Item "-mgcc-abi"
+Enables support for the old \s-1GCC\s0 version of the V850 \s-1ABI. \s0 With this
+version of the \s-1ABI\s0 the following rules apply:
+.RS 4
+.IP "\(bu" 4
+Integer sized structures and unions are returned in register \f(CW\*(C`r10\*(C'\fR.
+.IP "\(bu" 4
+Large structures and unions (more than 8 bytes in size) are passed by
+reference.
+.IP "\(bu" 4
+Functions are aligned to 32\-bit boundaries, unless optimizing for
+size.
+.IP "\(bu" 4
+The \fB\-m8byte\-align\fR command line option is not supported.
+.IP "\(bu" 4
+The \fB\-mdisable\-callt\fR command line option is supported but not
+enabled by default.
+.RE
+.RS 4
+.Sp
+When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
+\&\f(CW\*(C`_\|_V850_GCC_ABI_\|_\*(C'\fR is defined.
+.RE
+.IP "\fB\-m8byte\-align\fR" 4
+.IX Item "-m8byte-align"
+.PD 0
+.IP "\fB\-mno\-8byte\-align\fR" 4
+.IX Item "-mno-8byte-align"
+.PD
+Enables support for \f(CW\*(C`doubles\*(C'\fR and \f(CW\*(C`long long\*(C'\fR types to be
+aligned on 8\-byte boundaries.  The default is to restrict the
+alignment of all objects to at most 4\-bytes.  When
+\&\fB\-m8byte\-align\fR is in effect the C preprocessor symbol
+\&\f(CW\*(C`_\|_V850_8BYTE_ALIGN_\|_\*(C'\fR will be defined.
+.IP "\fB\-mbig\-switch\fR" 4
+.IX Item "-mbig-switch"
+Generate code suitable for big switch tables.  Use this option only if
+the assembler/linker complain about out of range branches within a switch
+table.
+.IP "\fB\-mapp\-regs\fR" 4
+.IX Item "-mapp-regs"
+This option causes r2 and r5 to be used in the code generated by
+the compiler.  This setting is the default.
+.IP "\fB\-mno\-app\-regs\fR" 4
+.IX Item "-mno-app-regs"
+This option causes r2 and r5 to be treated as fixed registers.
+.PP
+\fI\s-1VAX\s0 Options\fR
+.IX Subsection "VAX Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1VAX:\s0
+.IP "\fB\-munix\fR" 4
+.IX Item "-munix"
+Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on)
+that the Unix assembler for the \s-1VAX\s0 cannot handle across long
+ranges.
+.IP "\fB\-mgnu\fR" 4
+.IX Item "-mgnu"
+Do output those jump instructions, on the assumption that the
+\&\s-1GNU\s0 assembler is being used.
+.IP "\fB\-mg\fR" 4
+.IX Item "-mg"
+Output code for G\-format floating-point numbers instead of D\-format.
+.PP
+\fI\s-1VMS\s0 Options\fR
+.IX Subsection "VMS Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1VMS\s0 implementations:
+.IP "\fB\-mvms\-return\-codes\fR" 4
+.IX Item "-mvms-return-codes"
+Return \s-1VMS\s0 condition codes from \f(CW\*(C`main\*(C'\fR. The default is to return POSIX-style
+condition (e.g. error) codes.
+.IP "\fB\-mdebug\-main=\fR\fIprefix\fR" 4
+.IX Item "-mdebug-main=prefix"
+Flag the first routine whose name starts with \fIprefix\fR as the main
+routine for the debugger.
+.IP "\fB\-mmalloc64\fR" 4
+.IX Item "-mmalloc64"
+Default to 64\-bit memory allocation routines.
+.IP "\fB\-mpointer\-size=\fR\fIsize\fR" 4
+.IX Item "-mpointer-size=size"
+Set the default size of pointers. Possible options for \fIsize\fR are
+\&\fB32\fR or \fBshort\fR for 32 bit pointers, \fB64\fR or \fBlong\fR
+for 64 bit pointers, and \fBno\fR for supporting only 32 bit pointers.
+The later option disables \f(CW\*(C`pragma pointer_size\*(C'\fR.
+.PP
+\fIVxWorks Options\fR
+.IX Subsection "VxWorks Options"
+.PP
+The options in this section are defined for all VxWorks targets.
+Options specific to the target hardware are listed with the other
+options for that target.
+.IP "\fB\-mrtp\fR" 4
+.IX Item "-mrtp"
+\&\s-1GCC\s0 can generate code for both VxWorks kernels and real time processes
+(RTPs).  This option switches from the former to the latter.  It also
+defines the preprocessor macro \f(CW\*(C`_\|_RTP_\|_\*(C'\fR.
+.IP "\fB\-non\-static\fR" 4
+.IX Item "-non-static"
+Link an \s-1RTP\s0 executable against shared libraries rather than static
+libraries.  The options \fB\-static\fR and \fB\-shared\fR can
+also be used for RTPs; \fB\-static\fR
+is the default.
+.IP "\fB\-Bstatic\fR" 4
+.IX Item "-Bstatic"
+.PD 0
+.IP "\fB\-Bdynamic\fR" 4
+.IX Item "-Bdynamic"
+.PD
+These options are passed down to the linker.  They are defined for
+compatibility with Diab.
+.IP "\fB\-Xbind\-lazy\fR" 4
+.IX Item "-Xbind-lazy"
+Enable lazy binding of function calls.  This option is equivalent to
+\&\fB\-Wl,\-z,now\fR and is defined for compatibility with Diab.
+.IP "\fB\-Xbind\-now\fR" 4
+.IX Item "-Xbind-now"
+Disable lazy binding of function calls.  This option is the default and
+is defined for compatibility with Diab.
+.PP
+\fIx86\-64 Options\fR
+.IX Subsection "x86-64 Options"
+.PP
+These are listed under
+.PP
+\fIXstormy16 Options\fR
+.IX Subsection "Xstormy16 Options"
+.PP
+These options are defined for Xstormy16:
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Choose startup files and linker script suitable for the simulator.
+.PP
+\fIXtensa Options\fR
+.IX Subsection "Xtensa Options"
+.PP
+These options are supported for Xtensa targets:
+.IP "\fB\-mconst16\fR" 4
+.IX Item "-mconst16"
+.PD 0
+.IP "\fB\-mno\-const16\fR" 4
+.IX Item "-mno-const16"
+.PD
+Enable or disable use of \f(CW\*(C`CONST16\*(C'\fR instructions for loading
+constant values.  The \f(CW\*(C`CONST16\*(C'\fR instruction is currently not a
+standard option from Tensilica.  When enabled, \f(CW\*(C`CONST16\*(C'\fR
+instructions are always used in place of the standard \f(CW\*(C`L32R\*(C'\fR
+instructions.  The use of \f(CW\*(C`CONST16\*(C'\fR is enabled by default only if
+the \f(CW\*(C`L32R\*(C'\fR instruction is not available.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Enable or disable use of fused multiply/add and multiply/subtract
+instructions in the floating-point option.  This has no effect if the
+floating-point option is not also enabled.  Disabling fused multiply/add
+and multiply/subtract instructions forces the compiler to use separate
+instructions for the multiply and add/subtract operations.  This may be
+desirable in some cases where strict \s-1IEEE\s0 754\-compliant results are
+required: the fused multiply add/subtract instructions do not round the
+intermediate result, thereby producing results with \fImore\fR bits of
+precision than specified by the \s-1IEEE\s0 standard.  Disabling fused multiply
+add/subtract instructions also ensures that the program output is not
+sensitive to the compiler's ability to combine multiply and add/subtract
+operations.
+.IP "\fB\-mserialize\-volatile\fR" 4
+.IX Item "-mserialize-volatile"
+.PD 0
+.IP "\fB\-mno\-serialize\-volatile\fR" 4
+.IX Item "-mno-serialize-volatile"
+.PD
+When this option is enabled, \s-1GCC\s0 inserts \f(CW\*(C`MEMW\*(C'\fR instructions before
+\&\f(CW\*(C`volatile\*(C'\fR memory references to guarantee sequential consistency.
+The default is \fB\-mserialize\-volatile\fR.  Use
+\&\fB\-mno\-serialize\-volatile\fR to omit the \f(CW\*(C`MEMW\*(C'\fR instructions.
+.IP "\fB\-mforce\-no\-pic\fR" 4
+.IX Item "-mforce-no-pic"
+For targets, like GNU/Linux, where all user-mode Xtensa code must be
+position-independent code (\s-1PIC\s0), this option disables \s-1PIC\s0 for compiling
+kernel code.
+.IP "\fB\-mtext\-section\-literals\fR" 4
+.IX Item "-mtext-section-literals"
+.PD 0
+.IP "\fB\-mno\-text\-section\-literals\fR" 4
+.IX Item "-mno-text-section-literals"
+.PD
+Control the treatment of literal pools.  The default is
+\&\fB\-mno\-text\-section\-literals\fR, which places literals in a separate
+section in the output file.  This allows the literal pool to be placed
+in a data \s-1RAM/ROM,\s0 and it also allows the linker to combine literal
+pools from separate object files to remove redundant literals and
+improve code size.  With \fB\-mtext\-section\-literals\fR, the literals
+are interspersed in the text section in order to keep them as close as
+possible to their references.  This may be necessary for large assembly
+files.
+.IP "\fB\-mtarget\-align\fR" 4
+.IX Item "-mtarget-align"
+.PD 0
+.IP "\fB\-mno\-target\-align\fR" 4
+.IX Item "-mno-target-align"
+.PD
+When this option is enabled, \s-1GCC\s0 instructs the assembler to
+automatically align instructions to reduce branch penalties at the
+expense of some code density.  The assembler attempts to widen density
+instructions to align branch targets and the instructions following call
+instructions.  If there are not enough preceding safe density
+instructions to align a target, no widening is performed.  The
+default is \fB\-mtarget\-align\fR.  These options do not affect the
+treatment of auto-aligned instructions like \f(CW\*(C`LOOP\*(C'\fR, which the
+assembler always aligns, either by widening density instructions or
+by inserting \s-1NOP\s0 instructions.
+.IP "\fB\-mlongcalls\fR" 4
+.IX Item "-mlongcalls"
+.PD 0
+.IP "\fB\-mno\-longcalls\fR" 4
+.IX Item "-mno-longcalls"
+.PD
+When this option is enabled, \s-1GCC\s0 instructs the assembler to translate
+direct calls to indirect calls unless it can determine that the target
+of a direct call is in the range allowed by the call instruction.  This
+translation typically occurs for calls to functions in other source
+files.  Specifically, the assembler translates a direct \f(CW\*(C`CALL\*(C'\fR
+instruction into an \f(CW\*(C`L32R\*(C'\fR followed by a \f(CW\*(C`CALLX\*(C'\fR instruction.
+The default is \fB\-mno\-longcalls\fR.  This option should be used in
+programs where the call target can potentially be out of range.  This
+option is implemented in the assembler, not the compiler, so the
+assembly code generated by \s-1GCC\s0 still shows direct call
+instructions\-\-\-look at the disassembled object code to see the actual
+instructions.  Note that the assembler uses an indirect call for
+every cross-file call, not just those that really are out of range.
+.PP
+\fIzSeries Options\fR
+.IX Subsection "zSeries Options"
+.PP
+These are listed under
+.SS "Options for Code Generation Conventions"
+.IX Subsection "Options for Code Generation Conventions"
+These machine-independent options control the interface conventions
+used in code generation.
+.PP
+Most of them have both positive and negative forms; the negative form
+of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In the table below, only
+one of the forms is listed\-\-\-the one that is not the default.  You
+can figure out the other form by either removing \fBno\-\fR or adding
+it.
+.IP "\fB\-fbounds\-check\fR" 4
+.IX Item "-fbounds-check"
+For front ends that support it, generate additional code to check that
+indices used to access arrays are within the declared range.  This is
+currently only supported by the Java and Fortran front ends, where
+this option defaults to true and false respectively.
+.IP "\fB\-fstack\-reuse=\fR\fIreuse-level\fR" 4
+.IX Item "-fstack-reuse=reuse-level"
+This option controls stack space reuse for user declared local/auto variables
+and compiler generated temporaries.  \fIreuse_level\fR can be \fBall\fR,
+\&\fBnamed_vars\fR, or \fBnone\fR. \fBall\fR enables stack reuse for all
+local variables and temporaries, \fBnamed_vars\fR enables the reuse only for
+user defined local variables with names, and \fBnone\fR disables stack reuse
+completely. The default value is \fBall\fR. The option is needed when the
+program extends the lifetime of a scoped local variable or a compiler generated
+temporary beyond the end point defined by the language.  When a lifetime of
+a variable ends, and if the variable lives in memory, the optimizing compiler
+has the freedom to reuse its stack space with other temporaries or scoped
+local variables whose live range does not overlap with it. Legacy code extending
+local lifetime will likely to break with the stack reuse optimization.
+.Sp
+For example,
+.Sp
+.Vb 3
+\&           int *p;
+\&           {
+\&             int local1;
+\&        
+\&             p = &local1;
+\&             local1 = 10;
+\&             ....
+\&           }
+\&           {
+\&              int local2;
+\&              local2 = 20;
+\&              ...
+\&           }
+\&        
+\&           if (*p == 10)  // out of scope use of local1
+\&             {
+\&        
+\&             }
+.Ve
+.Sp
+Another example:
+.Sp
+.Vb 6
+\&           struct A
+\&           {
+\&               A(int k) : i(k), j(k) { }
+\&               int i;
+\&               int j;
+\&           };
+\&        
+\&           A *ap;
+\&        
+\&           void foo(const A& ar)
+\&           {
+\&              ap = &ar;
+\&           }
+\&        
+\&           void bar()
+\&           {
+\&              foo(A(10)); // temp object\*(Aqs lifetime ends when foo returns
+\&        
+\&              {
+\&                A a(20);
+\&                ....
+\&              }
+\&              ap\->i+= 10;  // ap references out of scope temp whose space
+\&                           // is reused with a. What is the value of ap\->i?
+\&           }
+.Ve
+.Sp
+The lifetime of a compiler generated temporary is well defined by the \*(C+
+standard. When a lifetime of a temporary ends, and if the temporary lives
+in memory, the optimizing compiler has the freedom to reuse its stack
+space with other temporaries or scoped local variables whose live range
+does not overlap with it. However some of the legacy code relies on
+the behavior of older compilers in which temporaries' stack space is
+not reused, the aggressive stack reuse can lead to runtime errors. This
+option is used to control the temporary stack reuse optimization.
+.IP "\fB\-ftrapv\fR" 4
+.IX Item "-ftrapv"
+This option generates traps for signed overflow on addition, subtraction,
+multiplication operations.
+.IP "\fB\-fwrapv\fR" 4
+.IX Item "-fwrapv"
+This option instructs the compiler to assume that signed arithmetic
+overflow of addition, subtraction and multiplication wraps around
+using twos-complement representation.  This flag enables some optimizations
+and disables others.  This option is enabled by default for the Java
+front end, as required by the Java language specification.
+.IP "\fB\-fexceptions\fR" 4
+.IX Item "-fexceptions"
+Enable exception handling.  Generates extra code needed to propagate
+exceptions.  For some targets, this implies \s-1GCC\s0 generates frame
+unwind information for all functions, which can produce significant data
+size overhead, although it does not affect execution.  If you do not
+specify this option, \s-1GCC\s0 enables it by default for languages like
+\&\*(C+ that normally require exception handling, and disables it for
+languages like C that do not normally require it.  However, you may need
+to enable this option when compiling C code that needs to interoperate
+properly with exception handlers written in \*(C+.  You may also wish to
+disable this option if you are compiling older \*(C+ programs that don't
+use exception handling.
+.IP "\fB\-fnon\-call\-exceptions\fR" 4
+.IX Item "-fnon-call-exceptions"
+Generate code that allows trapping instructions to throw exceptions.
+Note that this requires platform-specific runtime support that does
+not exist everywhere.  Moreover, it only allows \fItrapping\fR
+instructions to throw exceptions, i.e. memory references or floating-point
+instructions.  It does not allow exceptions to be thrown from
+arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR.
+.IP "\fB\-fdelete\-dead\-exceptions\fR" 4
+.IX Item "-fdelete-dead-exceptions"
+Consider that instructions that may throw exceptions but don't otherwise
+contribute to the execution of the program can be optimized away.
+This option is enabled by default for the Ada front end, as permitted by
+the Ada language specification.
+Optimization passes that cause dead exceptions to be removed are enabled independently at different optimization levels.
+.IP "\fB\-funwind\-tables\fR" 4
+.IX Item "-funwind-tables"
+Similar to \fB\-fexceptions\fR, except that it just generates any needed
+static data, but does not affect the generated code in any other way.
+You normally do not need to enable this option; instead, a language processor
+that needs this handling enables it on your behalf.
+.IP "\fB\-fasynchronous\-unwind\-tables\fR" 4
+.IX Item "-fasynchronous-unwind-tables"
+Generate unwind table in \s-1DWARF 2\s0 format, if supported by target machine.  The
+table is exact at each instruction boundary, so it can be used for stack
+unwinding from asynchronous events (such as debugger or garbage collector).
+.IP "\fB\-fno\-gnu\-unique\fR" 4
+.IX Item "-fno-gnu-unique"
+On systems with recent \s-1GNU\s0 assembler and C library, the \*(C+ compiler
+uses the \f(CW\*(C`STB_GNU_UNIQUE\*(C'\fR binding to make sure that definitions
+of template static data members and static local variables in inline
+functions are unique even in the presence of \f(CW\*(C`RTLD_LOCAL\*(C'\fR; this
+is necessary to avoid problems with a library used by two different
+\&\f(CW\*(C`RTLD_LOCAL\*(C'\fR plugins depending on a definition in one of them and
+therefore disagreeing with the other one about the binding of the
+symbol.  But this causes \f(CW\*(C`dlclose\*(C'\fR to be ignored for affected
+DSOs; if your program relies on reinitialization of a \s-1DSO\s0 via
+\&\f(CW\*(C`dlclose\*(C'\fR and \f(CW\*(C`dlopen\*(C'\fR, you can use
+\&\fB\-fno\-gnu\-unique\fR.
+.IP "\fB\-fpcc\-struct\-return\fR" 4
+.IX Item "-fpcc-struct-return"
+Return \*(L"short\*(R" \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like
+longer ones, rather than in registers.  This convention is less
+efficient, but it has the advantage of allowing intercallability between
+GCC-compiled files and files compiled with other compilers, particularly
+the Portable C Compiler (pcc).
+.Sp
+The precise convention for returning structures in memory depends
+on the target configuration macros.
+.Sp
+Short structures and unions are those whose size and alignment match
+that of some integer type.
+.Sp
+\&\fBWarning:\fR code compiled with the \fB\-fpcc\-struct\-return\fR
+switch is not binary compatible with code compiled with the
+\&\fB\-freg\-struct\-return\fR switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-freg\-struct\-return\fR" 4
+.IX Item "-freg-struct-return"
+Return \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in registers when possible.
+This is more efficient for small structures than
+\&\fB\-fpcc\-struct\-return\fR.
+.Sp
+If you specify neither \fB\-fpcc\-struct\-return\fR nor
+\&\fB\-freg\-struct\-return\fR, \s-1GCC\s0 defaults to whichever convention is
+standard for the target.  If there is no standard convention, \s-1GCC\s0
+defaults to \fB\-fpcc\-struct\-return\fR, except on targets where \s-1GCC\s0 is
+the principal compiler.  In those cases, we can choose the standard, and
+we chose the more efficient register return alternative.
+.Sp
+\&\fBWarning:\fR code compiled with the \fB\-freg\-struct\-return\fR
+switch is not binary compatible with code compiled with the
+\&\fB\-fpcc\-struct\-return\fR switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-fshort\-enums\fR" 4
+.IX Item "-fshort-enums"
+Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the
+declared range of possible values.  Specifically, the \f(CW\*(C`enum\*(C'\fR type
+is equivalent to the smallest integer type that has enough room.
+.Sp
+\&\fBWarning:\fR the \fB\-fshort\-enums\fR switch causes \s-1GCC\s0 to generate
+code that is not binary compatible with code generated without that switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-fshort\-double\fR" 4
+.IX Item "-fshort-double"
+Use the same size for \f(CW\*(C`double\*(C'\fR as for \f(CW\*(C`float\*(C'\fR.
+.Sp
+\&\fBWarning:\fR the \fB\-fshort\-double\fR switch causes \s-1GCC\s0 to generate
+code that is not binary compatible with code generated without that switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-fshort\-wchar\fR" 4
+.IX Item "-fshort-wchar"
+Override the underlying type for \fBwchar_t\fR to be \fBshort
+unsigned int\fR instead of the default for the target.  This option is
+useful for building programs to run under \s-1WINE.\s0
+.Sp
+\&\fBWarning:\fR the \fB\-fshort\-wchar\fR switch causes \s-1GCC\s0 to generate
+code that is not binary compatible with code generated without that switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-fno\-common\fR" 4
+.IX Item "-fno-common"
+In C code, controls the placement of uninitialized global variables.
+Unix C compilers have traditionally permitted multiple definitions of
+such variables in different compilation units by placing the variables
+in a common block.
+This is the behavior specified by \fB\-fcommon\fR, and is the default
+for \s-1GCC\s0 on most targets.
+On the other hand, this behavior is not required by \s-1ISO C,\s0 and on some
+targets may carry a speed or code size penalty on variable references.
+The \fB\-fno\-common\fR option specifies that the compiler should place
+uninitialized global variables in the data section of the object file,
+rather than generating them as common blocks.
+This has the effect that if the same variable is declared
+(without \f(CW\*(C`extern\*(C'\fR) in two different compilations,
+you get a multiple-definition error when you link them.
+In this case, you must compile with \fB\-fcommon\fR instead.
+Compiling with \fB\-fno\-common\fR is useful on targets for which
+it provides better performance, or if you wish to verify that the
+program will work on other systems that always treat uninitialized
+variable declarations this way.
+.IP "\fB\-fno\-ident\fR" 4
+.IX Item "-fno-ident"
+Ignore the \fB#ident\fR directive.
+.IP "\fB\-finhibit\-size\-directive\fR" 4
+.IX Item "-finhibit-size-directive"
+Don't output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that
+would cause trouble if the function is split in the middle, and the
+two halves are placed at locations far apart in memory.  This option is
+used when compiling \fIcrtstuff.c\fR; you should not need to use it
+for anything else.
+.IP "\fB\-fverbose\-asm\fR" 4
+.IX Item "-fverbose-asm"
+Put extra commentary information in the generated assembly code to
+make it more readable.  This option is generally only of use to those
+who actually need to read the generated assembly code (perhaps while
+debugging the compiler itself).
+.Sp
+\&\fB\-fno\-verbose\-asm\fR, the default, causes the
+extra information to be omitted and is useful when comparing two assembler
+files.
+.IP "\fB\-frecord\-gcc\-switches\fR" 4
+.IX Item "-frecord-gcc-switches"
+This switch causes the command line used to invoke the
+compiler to be recorded into the object file that is being created.
+This switch is only implemented on some targets and the exact format
+of the recording is target and binary file format dependent, but it
+usually takes the form of a section containing \s-1ASCII\s0 text.  This
+switch is related to the \fB\-fverbose\-asm\fR switch, but that
+switch only records information in the assembler output file as
+comments, so it never reaches the object file.
+See also \fB\-grecord\-gcc\-switches\fR for another
+way of storing compiler options into the object file.
+.IP "\fB\-fpic\fR" 4
+.IX Item "-fpic"
+Generate position-independent code (\s-1PIC\s0) suitable for use in a shared
+library, if supported for the target machine.  Such code accesses all
+constant addresses through a global offset table (\s-1GOT\s0).  The dynamic
+loader resolves the \s-1GOT\s0 entries when the program starts (the dynamic
+loader is not part of \s-1GCC\s0; it is part of the operating system).  If
+the \s-1GOT\s0 size for the linked executable exceeds a machine-specific
+maximum size, you get an error message from the linker indicating that
+\&\fB\-fpic\fR does not work; in that case, recompile with \fB\-fPIC\fR
+instead.  (These maximums are 8k on the \s-1SPARC\s0 and 32k
+on the m68k and \s-1RS/6000. \s0 The 386 has no such limit.)
+.Sp
+Position-independent code requires special support, and therefore works
+only on certain machines.  For the 386, \s-1GCC\s0 supports \s-1PIC\s0 for System V
+but not for the Sun 386i.  Code generated for the \s-1IBM RS/6000\s0 is always
+position-independent.
+.Sp
+When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
+are defined to 1.
+.IP "\fB\-fPIC\fR" 4
+.IX Item "-fPIC"
+If supported for the target machine, emit position-independent code,
+suitable for dynamic linking and avoiding any limit on the size of the
+global offset table.  This option makes a difference on the m68k,
+PowerPC and \s-1SPARC.\s0
+.Sp
+Position-independent code requires special support, and therefore works
+only on certain machines.
+.Sp
+When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
+are defined to 2.
+.IP "\fB\-fpie\fR" 4
+.IX Item "-fpie"
+.PD 0
+.IP "\fB\-fPIE\fR" 4
+.IX Item "-fPIE"
+.PD
+These options are similar to \fB\-fpic\fR and \fB\-fPIC\fR, but
+generated position independent code can be only linked into executables.
+Usually these options are used when \fB\-pie\fR \s-1GCC\s0 option is
+used during linking.
+.Sp
+\&\fB\-fpie\fR and \fB\-fPIE\fR both define the macros
+\&\f(CW\*(C`_\|_pie_\|_\*(C'\fR and \f(CW\*(C`_\|_PIE_\|_\*(C'\fR.  The macros have the value 1
+for \fB\-fpie\fR and 2 for \fB\-fPIE\fR.
+.IP "\fB\-fno\-jump\-tables\fR" 4
+.IX Item "-fno-jump-tables"
+Do not use jump tables for switch statements even where it would be
+more efficient than other code generation strategies.  This option is
+of use in conjunction with \fB\-fpic\fR or \fB\-fPIC\fR for
+building code that forms part of a dynamic linker and cannot
+reference the address of a jump table.  On some targets, jump tables
+do not require a \s-1GOT\s0 and this option is not needed.
+.IP "\fB\-ffixed\-\fR\fIreg\fR" 4
+.IX Item "-ffixed-reg"
+Treat the register named \fIreg\fR as a fixed register; generated code
+should never refer to it (except perhaps as a stack pointer, frame
+pointer or in some other fixed role).
+.Sp
+\&\fIreg\fR must be the name of a register.  The register names accepted
+are machine-specific and are defined in the \f(CW\*(C`REGISTER_NAMES\*(C'\fR
+macro in the machine description macro file.
+.Sp
+This flag does not have a negative form, because it specifies a
+three-way choice.
+.IP "\fB\-fcall\-used\-\fR\fIreg\fR" 4
+.IX Item "-fcall-used-reg"
+Treat the register named \fIreg\fR as an allocable register that is
+clobbered by function calls.  It may be allocated for temporaries or
+variables that do not live across a call.  Functions compiled this way
+do not save and restore the register \fIreg\fR.
+.Sp
+It is an error to use this flag with the frame pointer or stack pointer.
+Use of this flag for other registers that have fixed pervasive roles in
+the machine's execution model produces disastrous results.
+.Sp
+This flag does not have a negative form, because it specifies a
+three-way choice.
+.IP "\fB\-fcall\-saved\-\fR\fIreg\fR" 4
+.IX Item "-fcall-saved-reg"
+Treat the register named \fIreg\fR as an allocable register saved by
+functions.  It may be allocated even for temporaries or variables that
+live across a call.  Functions compiled this way save and restore
+the register \fIreg\fR if they use it.
+.Sp
+It is an error to use this flag with the frame pointer or stack pointer.
+Use of this flag for other registers that have fixed pervasive roles in
+the machine's execution model produces disastrous results.
+.Sp
+A different sort of disaster results from the use of this flag for
+a register in which function values may be returned.
+.Sp
+This flag does not have a negative form, because it specifies a
+three-way choice.
+.IP "\fB\-fpack\-struct[=\fR\fIn\fR\fB]\fR" 4
+.IX Item "-fpack-struct[=n]"
+Without a value specified, pack all structure members together without
+holes.  When a value is specified (which must be a small power of two), pack
+structure members according to this value, representing the maximum
+alignment (that is, objects with default alignment requirements larger than
+this are output potentially unaligned at the next fitting location.
+.Sp
+\&\fBWarning:\fR the \fB\-fpack\-struct\fR switch causes \s-1GCC\s0 to generate
+code that is not binary compatible with code generated without that switch.
+Additionally, it makes the code suboptimal.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-finstrument\-functions\fR" 4
+.IX Item "-finstrument-functions"
+Generate instrumentation calls for entry and exit to functions.  Just
+after function entry and just before function exit, the following
+profiling functions are called with the address of the current
+function and its call site.  (On some platforms,
+\&\f(CW\*(C`_\|_builtin_return_address\*(C'\fR does not work beyond the current
+function, so the call site information may not be available to the
+profiling functions otherwise.)
+.Sp
+.Vb 4
+\&        void _\|_cyg_profile_func_enter (void *this_fn,
+\&                                       void *call_site);
+\&        void _\|_cyg_profile_func_exit  (void *this_fn,
+\&                                       void *call_site);
+.Ve
+.Sp
+The first argument is the address of the start of the current function,
+which may be looked up exactly in the symbol table.
+.Sp
+This instrumentation is also done for functions expanded inline in other
+functions.  The profiling calls indicate where, conceptually, the
+inline function is entered and exited.  This means that addressable
+versions of such functions must be available.  If all your uses of a
+function are expanded inline, this may mean an additional expansion of
+code size.  If you use \fBextern inline\fR in your C code, an
+addressable version of such functions must be provided.  (This is
+normally the case anyway, but if you get lucky and the optimizer always
+expands the functions inline, you might have gotten away without
+providing static copies.)
+.Sp
+A function may be given the attribute \f(CW\*(C`no_instrument_function\*(C'\fR, in
+which case this instrumentation is not done.  This can be used, for
+example, for the profiling functions listed above, high-priority
+interrupt routines, and any functions from which the profiling functions
+cannot safely be called (perhaps signal handlers, if the profiling
+routines generate output or allocate memory).
+.IP "\fB\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...\fR" 4
+.IX Item "-finstrument-functions-exclude-file-list=file,file,..."
+Set the list of functions that are excluded from instrumentation (see
+the description of \f(CW\*(C`\-finstrument\-functions\*(C'\fR).  If the file that
+contains a function definition matches with one of \fIfile\fR, then
+that function is not instrumented.  The match is done on substrings:
+if the \fIfile\fR parameter is a substring of the file name, it is
+considered to be a match.
+.Sp
+For example:
+.Sp
+.Vb 1
+\&        \-finstrument\-functions\-exclude\-file\-list=/bits/stl,include/sys
+.Ve
+.Sp
+excludes any inline function defined in files whose pathnames
+contain \f(CW\*(C`/bits/stl\*(C'\fR or \f(CW\*(C`include/sys\*(C'\fR.
+.Sp
+If, for some reason, you want to include letter \f(CW\*(Aq,\*(Aq\fR in one of
+\&\fIsym\fR, write \f(CW\*(Aq,\*(Aq\fR. For example,
+\&\f(CW\*(C`\-finstrument\-functions\-exclude\-file\-list=\*(Aq,,tmp\*(Aq\*(C'\fR
+(note the single quote surrounding the option).
+.IP "\fB\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...\fR" 4
+.IX Item "-finstrument-functions-exclude-function-list=sym,sym,..."
+This is similar to \f(CW\*(C`\-finstrument\-functions\-exclude\-file\-list\*(C'\fR,
+but this option sets the list of function names to be excluded from
+instrumentation.  The function name to be matched is its user-visible
+name, such as \f(CW\*(C`vector<int> blah(const vector<int> &)\*(C'\fR, not the
+internal mangled name (e.g., \f(CW\*(C`_Z4blahRSt6vectorIiSaIiEE\*(C'\fR).  The
+match is done on substrings: if the \fIsym\fR parameter is a substring
+of the function name, it is considered to be a match.  For C99 and \*(C+
+extended identifiers, the function name must be given in \s-1UTF\-8,\s0 not
+using universal character names.
+.IP "\fB\-fstack\-check\fR" 4
+.IX Item "-fstack-check"
+Generate code to verify that you do not go beyond the boundary of the
+stack.  You should specify this flag if you are running in an
+environment with multiple threads, but you only rarely need to specify it in
+a single-threaded environment since stack overflow is automatically
+detected on nearly all systems if there is only one stack.
+.Sp
+Note that this switch does not actually cause checking to be done; the
+operating system or the language runtime must do that.  The switch causes
+generation of code to ensure that they see the stack being extended.
+.Sp
+You can additionally specify a string parameter: \f(CW\*(C`no\*(C'\fR means no
+checking, \f(CW\*(C`generic\*(C'\fR means force the use of old-style checking,
+\&\f(CW\*(C`specific\*(C'\fR means use the best checking method and is equivalent
+to bare \fB\-fstack\-check\fR.
+.Sp
+Old-style checking is a generic mechanism that requires no specific
+target support in the compiler but comes with the following drawbacks:
+.RS 4
+.IP "1." 4
+Modified allocation strategy for large objects: they are always
+allocated dynamically if their size exceeds a fixed threshold.
+.IP "2." 4
+Fixed limit on the size of the static frame of functions: when it is
+topped by a particular function, stack checking is not reliable and
+a warning is issued by the compiler.
+.IP "3." 4
+Inefficiency: because of both the modified allocation strategy and the
+generic implementation, code performance is hampered.
+.RE
+.RS 4
+.Sp
+Note that old-style stack checking is also the fallback method for
+\&\f(CW\*(C`specific\*(C'\fR if no target support has been added in the compiler.
+.RE
+.IP "\fB\-fstack\-limit\-register=\fR\fIreg\fR" 4
+.IX Item "-fstack-limit-register=reg"
+.PD 0
+.IP "\fB\-fstack\-limit\-symbol=\fR\fIsym\fR" 4
+.IX Item "-fstack-limit-symbol=sym"
+.IP "\fB\-fno\-stack\-limit\fR" 4
+.IX Item "-fno-stack-limit"
+.PD
+Generate code to ensure that the stack does not grow beyond a certain value,
+either the value of a register or the address of a symbol.  If a larger
+stack is required, a signal is raised at run time.  For most targets,
+the signal is raised before the stack overruns the boundary, so
+it is possible to catch the signal without taking special precautions.
+.Sp
+For instance, if the stack starts at absolute address \fB0x80000000\fR
+and grows downwards, you can use the flags
+\&\fB\-fstack\-limit\-symbol=_\|_stack_limit\fR and
+\&\fB\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR to enforce a stack limit
+of 128KB.  Note that this may only work with the \s-1GNU\s0 linker.
+.IP "\fB\-fsplit\-stack\fR" 4
+.IX Item "-fsplit-stack"
+Generate code to automatically split the stack before it overflows.
+The resulting program has a discontiguous stack which can only
+overflow if the program is unable to allocate any more memory.  This
+is most useful when running threaded programs, as it is no longer
+necessary to calculate a good stack size to use for each thread.  This
+is currently only implemented for the i386 and x86_64 back ends running
+GNU/Linux.
+.Sp
+When code compiled with \fB\-fsplit\-stack\fR calls code compiled
+without \fB\-fsplit\-stack\fR, there may not be much stack space
+available for the latter code to run.  If compiling all code,
+including library code, with \fB\-fsplit\-stack\fR is not an option,
+then the linker can fix up these calls so that the code compiled
+without \fB\-fsplit\-stack\fR always has a large stack.  Support for
+this is implemented in the gold linker in \s-1GNU\s0 binutils release 2.21
+and later.
+.IP "\fB\-fleading\-underscore\fR" 4
+.IX Item "-fleading-underscore"
+This option and its counterpart, \fB\-fno\-leading\-underscore\fR, forcibly
+change the way C symbols are represented in the object file.  One use
+is to help link with legacy assembly code.
+.Sp
+\&\fBWarning:\fR the \fB\-fleading\-underscore\fR switch causes \s-1GCC\s0 to
+generate code that is not binary compatible with code generated without that
+switch.  Use it to conform to a non-default application binary interface.
+Not all targets provide complete support for this switch.
+.IP "\fB\-ftls\-model=\fR\fImodel\fR" 4
+.IX Item "-ftls-model=model"
+Alter the thread-local storage model to be used.
+The \fImodel\fR argument should be one of \f(CW\*(C`global\-dynamic\*(C'\fR,
+\&\f(CW\*(C`local\-dynamic\*(C'\fR, \f(CW\*(C`initial\-exec\*(C'\fR or \f(CW\*(C`local\-exec\*(C'\fR.
+Note that the choice is subject to optimization: the compiler may use
+a more efficient model for symbols not visible outside of the translation
+unit, or if \fB\-fpic\fR is not given on the command line.
+.Sp
+The default without \fB\-fpic\fR is \f(CW\*(C`initial\-exec\*(C'\fR; with
+\&\fB\-fpic\fR the default is \f(CW\*(C`global\-dynamic\*(C'\fR.
+.IP "\fB\-fvisibility=\fR\fIdefault|internal|hidden|protected\fR" 4
+.IX Item "-fvisibility=default|internal|hidden|protected"
+Set the default \s-1ELF\s0 image symbol visibility to the specified option\-\-\-all
+symbols are marked with this unless overridden within the code.
+Using this feature can very substantially improve linking and
+load times of shared object libraries, produce more optimized
+code, provide near-perfect \s-1API\s0 export and prevent symbol clashes.
+It is \fBstrongly\fR recommended that you use this in any shared objects
+you distribute.
+.Sp
+Despite the nomenclature, \f(CW\*(C`default\*(C'\fR always means public; i.e.,
+available to be linked against from outside the shared object.
+\&\f(CW\*(C`protected\*(C'\fR and \f(CW\*(C`internal\*(C'\fR are pretty useless in real-world
+usage so the only other commonly used option is \f(CW\*(C`hidden\*(C'\fR.
+The default if \fB\-fvisibility\fR isn't specified is
+\&\f(CW\*(C`default\*(C'\fR, i.e., make every
+symbol public\-\-\-this causes the same behavior as previous versions of
+\&\s-1GCC.\s0
+.Sp
+A good explanation of the benefits offered by ensuring \s-1ELF\s0
+symbols have the correct visibility is given by \*(L"How To Write
+Shared Libraries\*(R" by Ulrich Drepper (which can be found at
+<\fBhttp://people.redhat.com/~drepper/\fR>)\-\-\-however a superior
+solution made possible by this option to marking things hidden when
+the default is public is to make the default hidden and mark things
+public.  This is the norm with DLLs on Windows and with \fB\-fvisibility=hidden\fR
+and \f(CW\*(C`_\|_attribute_\|_ ((visibility("default")))\*(C'\fR instead of
+\&\f(CW\*(C`_\|_declspec(dllexport)\*(C'\fR you get almost identical semantics with
+identical syntax.  This is a great boon to those working with
+cross-platform projects.
+.Sp
+For those adding visibility support to existing code, you may find
+\&\fB#pragma \s-1GCC\s0 visibility\fR of use.  This works by you enclosing
+the declarations you wish to set visibility for with (for example)
+\&\fB#pragma \s-1GCC\s0 visibility push(hidden)\fR and
+\&\fB#pragma \s-1GCC\s0 visibility pop\fR.
+Bear in mind that symbol visibility should be viewed \fBas
+part of the \s-1API\s0 interface contract\fR and thus all new code should
+always specify visibility when it is not the default; i.e., declarations
+only for use within the local \s-1DSO\s0 should \fBalways\fR be marked explicitly
+as hidden as so to avoid \s-1PLT\s0 indirection overheads\-\-\-making this
+abundantly clear also aids readability and self-documentation of the code.
+Note that due to \s-1ISO \*(C+\s0 specification requirements, \f(CW\*(C`operator new\*(C'\fR and
+\&\f(CW\*(C`operator delete\*(C'\fR must always be of default visibility.
+.Sp
+Be aware that headers from outside your project, in particular system
+headers and headers from any other library you use, may not be
+expecting to be compiled with visibility other than the default.  You
+may need to explicitly say \fB#pragma \s-1GCC\s0 visibility push(default)\fR
+before including any such headers.
+.Sp
+\&\fBextern\fR declarations are not affected by \fB\-fvisibility\fR, so
+a lot of code can be recompiled with \fB\-fvisibility=hidden\fR with
+no modifications.  However, this means that calls to \f(CW\*(C`extern\*(C'\fR
+functions with no explicit visibility use the \s-1PLT,\s0 so it is more
+effective to use \f(CW\*(C`_\|_attribute ((visibility))\*(C'\fR and/or
+\&\f(CW\*(C`#pragma GCC visibility\*(C'\fR to tell the compiler which \f(CW\*(C`extern\*(C'\fR
+declarations should be treated as hidden.
+.Sp
+Note that \fB\-fvisibility\fR does affect \*(C+ vague linkage
+entities. This means that, for instance, an exception class that is
+be thrown between DSOs must be explicitly marked with default
+visibility so that the \fBtype_info\fR nodes are unified between
+the DSOs.
+.Sp
+An overview of these techniques, their benefits and how to use them
+is at <\fBhttp://gcc.gnu.org/wiki/Visibility\fR>.
+.IP "\fB\-fstrict\-volatile\-bitfields\fR" 4
+.IX Item "-fstrict-volatile-bitfields"
+This option should be used if accesses to volatile bit-fields (or other
+structure fields, although the compiler usually honors those types
+anyway) should use a single access of the width of the
+field's type, aligned to a natural alignment if possible.  For
+example, targets with memory-mapped peripheral registers might require
+all such accesses to be 16 bits wide; with this flag you can
+declare all peripheral bit-fields as \f(CW\*(C`unsigned short\*(C'\fR (assuming short
+is 16 bits on these targets) to force \s-1GCC\s0 to use 16\-bit accesses
+instead of, perhaps, a more efficient 32\-bit access.
+.Sp
+If this option is disabled, the compiler uses the most efficient
+instruction.  In the previous example, that might be a 32\-bit load
+instruction, even though that accesses bytes that do not contain
+any portion of the bit-field, or memory-mapped registers unrelated to
+the one being updated.
+.Sp
+In some cases, such as when the \f(CW\*(C`packed\*(C'\fR attribute is applied to a 
+structure field, it may not be possible to access the field with a single
+read or write that is correctly aligned for the target machine.  In this
+case \s-1GCC\s0 falls back to generating multiple accesses rather than code that 
+will fault or truncate the result at run time.
+.Sp
+Note:  Due to restrictions of the C/\*(C+11 memory model, write accesses are
+not allowed to touch non bit-field members.  It is therefore recommended
+to define all bits of the field's type as bit-field members.
+.Sp
+The default value of this option is determined by the application binary
+interface for the target processor.
+.IP "\fB\-fsync\-libcalls\fR" 4
+.IX Item "-fsync-libcalls"
+This option controls whether any out-of-line instance of the \f(CW\*(C`_\|_sync\*(C'\fR
+family of functions may be used to implement the \*(C+11 \f(CW\*(C`_\|_atomic\*(C'\fR
+family of functions.
+.Sp
+The default value of this option is enabled, thus the only useful form
+of the option is \fB\-fno\-sync\-libcalls\fR.  This option is used in
+the implementation of the \fIlibatomic\fR runtime library.
+.SH "ENVIRONMENT"
+.IX Header "ENVIRONMENT"
+This section describes several environment variables that affect how \s-1GCC\s0
+operates.  Some of them work by specifying directories or prefixes to use
+when searching for various kinds of files.  Some are used to specify other
+aspects of the compilation environment.
+.PP
+Note that you can also specify places to search using options such as
+\&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR.  These
+take precedence over places specified using environment variables, which
+in turn take precedence over those specified by the configuration of \s-1GCC.\s0
+.IP "\fB\s-1LANG\s0\fR" 4
+.IX Item "LANG"
+.PD 0
+.IP "\fB\s-1LC_CTYPE\s0\fR" 4
+.IX Item "LC_CTYPE"
+.IP "\fB\s-1LC_MESSAGES\s0\fR" 4
+.IX Item "LC_MESSAGES"
+.IP "\fB\s-1LC_ALL\s0\fR" 4
+.IX Item "LC_ALL"
+.PD
+These environment variables control the way that \s-1GCC\s0 uses
+localization information which allows \s-1GCC\s0 to work with different
+national conventions.  \s-1GCC\s0 inspects the locale categories
+\&\fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR if it has been configured to do
+so.  These locale categories can be set to any value supported by your
+installation.  A typical value is \fBen_GB.UTF\-8\fR for English in the United
+Kingdom encoded in \s-1UTF\-8.\s0
+.Sp
+The \fB\s-1LC_CTYPE\s0\fR environment variable specifies character
+classification.  \s-1GCC\s0 uses it to determine the character boundaries in
+a string; this is needed for some multibyte encodings that contain quote
+and escape characters that are otherwise interpreted as a string
+end or escape.
+.Sp
+The \fB\s-1LC_MESSAGES\s0\fR environment variable specifies the language to
+use in diagnostic messages.
+.Sp
+If the \fB\s-1LC_ALL\s0\fR environment variable is set, it overrides the value
+of \fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR; otherwise, \fB\s-1LC_CTYPE\s0\fR
+and \fB\s-1LC_MESSAGES\s0\fR default to the value of the \fB\s-1LANG\s0\fR
+environment variable.  If none of these variables are set, \s-1GCC\s0
+defaults to traditional C English behavior.
+.IP "\fB\s-1TMPDIR\s0\fR" 4
+.IX Item "TMPDIR"
+If \fB\s-1TMPDIR\s0\fR is set, it specifies the directory to use for temporary
+files.  \s-1GCC\s0 uses temporary files to hold the output of one stage of
+compilation which is to be used as input to the next stage: for example,
+the output of the preprocessor, which is the input to the compiler
+proper.
+.IP "\fB\s-1GCC_COMPARE_DEBUG\s0\fR" 4
+.IX Item "GCC_COMPARE_DEBUG"
+Setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR is nearly equivalent to passing
+\&\fB\-fcompare\-debug\fR to the compiler driver.  See the documentation
+of this option for more details.
+.IP "\fB\s-1GCC_EXEC_PREFIX\s0\fR" 4
+.IX Item "GCC_EXEC_PREFIX"
+If \fB\s-1GCC_EXEC_PREFIX\s0\fR is set, it specifies a prefix to use in the
+names of the subprograms executed by the compiler.  No slash is added
+when this prefix is combined with the name of a subprogram, but you can
+specify a prefix that ends with a slash if you wish.
+.Sp
+If \fB\s-1GCC_EXEC_PREFIX\s0\fR is not set, \s-1GCC\s0 attempts to figure out
+an appropriate prefix to use based on the pathname it is invoked with.
+.Sp
+If \s-1GCC\s0 cannot find the subprogram using the specified prefix, it
+tries looking in the usual places for the subprogram.
+.Sp
+The default value of \fB\s-1GCC_EXEC_PREFIX\s0\fR is
+\&\fI\fIprefix\fI/lib/gcc/\fR where \fIprefix\fR is the prefix to
+the installed compiler. In many cases \fIprefix\fR is the value
+of \f(CW\*(C`prefix\*(C'\fR when you ran the \fIconfigure\fR script.
+.Sp
+Other prefixes specified with \fB\-B\fR take precedence over this prefix.
+.Sp
+This prefix is also used for finding files such as \fIcrt0.o\fR that are
+used for linking.
+.Sp
+In addition, the prefix is used in an unusual way in finding the
+directories to search for header files.  For each of the standard
+directories whose name normally begins with \fB/usr/local/lib/gcc\fR
+(more precisely, with the value of \fB\s-1GCC_INCLUDE_DIR\s0\fR), \s-1GCC\s0 tries
+replacing that beginning with the specified prefix to produce an
+alternate directory name.  Thus, with \fB\-Bfoo/\fR, \s-1GCC\s0 searches
+\&\fIfoo/bar\fR just before it searches the standard directory 
+\&\fI/usr/local/lib/bar\fR.
+If a standard directory begins with the configured
+\&\fIprefix\fR then the value of \fIprefix\fR is replaced by
+\&\fB\s-1GCC_EXEC_PREFIX\s0\fR when looking for header files.
+.IP "\fB\s-1COMPILER_PATH\s0\fR" 4
+.IX Item "COMPILER_PATH"
+The value of \fB\s-1COMPILER_PATH\s0\fR is a colon-separated list of
+directories, much like \fB\s-1PATH\s0\fR.  \s-1GCC\s0 tries the directories thus
+specified when searching for subprograms, if it can't find the
+subprograms using \fB\s-1GCC_EXEC_PREFIX\s0\fR.
+.IP "\fB\s-1LIBRARY_PATH\s0\fR" 4
+.IX Item "LIBRARY_PATH"
+The value of \fB\s-1LIBRARY_PATH\s0\fR is a colon-separated list of
+directories, much like \fB\s-1PATH\s0\fR.  When configured as a native compiler,
+\&\s-1GCC\s0 tries the directories thus specified when searching for special
+linker files, if it can't find them using \fB\s-1GCC_EXEC_PREFIX\s0\fR.  Linking
+using \s-1GCC\s0 also uses these directories when searching for ordinary
+libraries for the \fB\-l\fR option (but directories specified with
+\&\fB\-L\fR come first).
+.IP "\fB\s-1LANG\s0\fR" 4
+.IX Item "LANG"
+This variable is used to pass locale information to the compiler.  One way in
+which this information is used is to determine the character set to be used
+when character literals, string literals and comments are parsed in C and \*(C+.
+When the compiler is configured to allow multibyte characters,
+the following values for \fB\s-1LANG\s0\fR are recognized:
+.RS 4
+.IP "\fBC\-JIS\fR" 4
+.IX Item "C-JIS"
+Recognize \s-1JIS\s0 characters.
+.IP "\fBC\-SJIS\fR" 4
+.IX Item "C-SJIS"
+Recognize \s-1SJIS\s0 characters.
+.IP "\fBC\-EUCJP\fR" 4
+.IX Item "C-EUCJP"
+Recognize \s-1EUCJP\s0 characters.
+.RE
+.RS 4
+.Sp
+If \fB\s-1LANG\s0\fR is not defined, or if it has some other value, then the
+compiler uses \f(CW\*(C`mblen\*(C'\fR and \f(CW\*(C`mbtowc\*(C'\fR as defined by the default locale to
+recognize and translate multibyte characters.
+.RE
+.PP
+Some additional environment variables affect the behavior of the
+preprocessor.
+.IP "\fB\s-1CPATH\s0\fR" 4
+.IX Item "CPATH"
+.PD 0
+.IP "\fBC_INCLUDE_PATH\fR" 4
+.IX Item "C_INCLUDE_PATH"
+.IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
+.IX Item "CPLUS_INCLUDE_PATH"
+.IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
+.IX Item "OBJC_INCLUDE_PATH"
+.PD
+Each variable's value is a list of directories separated by a special
+character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
+The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
+determined at \s-1GCC\s0 build time.  For Microsoft Windows-based targets it is a
+semicolon, and for almost all other targets it is a colon.
+.Sp
+\&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
+specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
+options on the command line.  This environment variable is used
+regardless of which language is being preprocessed.
+.Sp
+The remaining environment variables apply only when preprocessing the
+particular language indicated.  Each specifies a list of directories
+to be searched as if specified with \fB\-isystem\fR, but after any
+paths given with \fB\-isystem\fR options on the command line.
+.Sp
+In all these variables, an empty element instructs the compiler to
+search its current working directory.  Empty elements can appear at the
+beginning or end of a path.  For instance, if the value of
+\&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
+effect as \fB\-I.\ \-I/special/include\fR.
+.IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
+.IX Item "DEPENDENCIES_OUTPUT"
+If this variable is set, its value specifies how to output
+dependencies for Make based on the non-system header files processed
+by the compiler.  System header files are ignored in the dependency
+output.
+.Sp
+The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
+which case the Make rules are written to that file, guessing the target
+name from the source file name.  Or the value can have the form
+\&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
+file \fIfile\fR using \fItarget\fR as the target name.
+.Sp
+In other words, this environment variable is equivalent to combining
+the options \fB\-MM\fR and \fB\-MF\fR,
+with an optional \fB\-MT\fR switch too.
+.IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
+.IX Item "SUNPRO_DEPENDENCIES"
+This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
+except that system header files are not ignored, so it implies
+\&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
+main input file is omitted.
+.SH "BUGS"
+.IX Header "BUGS"
+For instructions on reporting bugs, see
+<\fBhttp://gcc.gnu.org/bugs.html\fR>.
+.SH "FOOTNOTES"
+.IX Header "FOOTNOTES"
+.IP "1." 4
+On some systems, \fBgcc \-shared\fR
+needs to build supplementary stub code for constructors to work.  On
+multi-libbed systems, \fBgcc \-shared\fR must select the correct support
+libraries to link against.  Failing to supply the correct flags may lead
+to subtle defects.  Supplying them in cases where they are not necessary
+is innocuous.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7),
+\&\fIcpp\fR\|(1), \fIgcov\fR\|(1), \fIas\fR\|(1), \fIld\fR\|(1), \fIgdb\fR\|(1), \fIadb\fR\|(1), \fIdbx\fR\|(1), \fIsdb\fR\|(1)
+and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIas\fR,
+\&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+See the Info entry for \fBgcc\fR, or
+<\fBhttp://gcc.gnu.org/onlinedocs/gcc/Contributors.html\fR>,
+for contributors to \s-1GCC.\s0
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 1988\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
+Free Software\*(R", 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 \fIgfdl\fR\|(7) man page.
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/gc-analyze.1 b/gcc-4.9/gcc/doc/gc-analyze.1
new file mode 100644
index 000000000..a446a65ef
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gc-analyze.1
@@ -0,0 +1,231 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GC-ANALYZE 1"
+.TH GC-ANALYZE 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gc\-analyze \- Analyze Garbage Collector (GC) memory dumps
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBgc-analyze\fR [\fB\s-1OPTION\s0\fR] ... [\fIfile\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBgc-analyze\fR prints an analysis of a \s-1GC\s0 memory dump to
+standard out.
+.PP
+The memory dumps may be created by calling
+\&\f(CW\*(C`gnu.gcj.util.GCInfo.enumerate(String namePrefix)\*(C'\fR from java
+code.  A memory dump will be created on an out of memory condition if
+\&\f(CW\*(C`gnu.gcj.util.GCInfo.setOOMDump(String namePrefix)\*(C'\fR is called
+before the out of memory occurs.
+.PP
+Running this program will create two files: \fITestDump001\fR and
+\&\fITestDump001.bytes\fR.
+.PP
+.Vb 2
+\&        import gnu.gcj.util.*;
+\&        import java.util.*;
+\&        
+\&        public class GCDumpTest
+\&        {
+\&            static public void main(String args[])
+\&            {
+\&                ArrayList<String> l = new ArrayList<String>(1000);
+\&        
+\&                for (int i = 1; i < 1500; i++) {
+\&                    l.add("This is string #" + i);
+\&                }
+\&                GCInfo.enumerate("TestDump");
+\&            }
+\&        }
+.Ve
+.PP
+The memory dump may then be displayed by running:
+.PP
+.Vb 1
+\&        gc\-analyze \-v TestDump001
+.Ve
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-\-verbose\fR" 4
+.IX Item "--verbose"
+.PD 0
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+.PD
+Verbose output.
+.IP "\fB\-p\fR \fItool-prefix\fR" 4
+.IX Item "-p tool-prefix"
+Prefix added to the names of the \fBnm\fR and \fBreadelf\fR commands.
+.IP "\fB\-d\fR \fIdirectory\fR" 4
+.IX Item "-d directory"
+Directory that contains the executable and shared libraries used when
+the dump was generated.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+Print a help message, then exit.
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+Print version information, then exit.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/gcc.1 b/gcc-4.9/gcc/doc/gcc.1
new file mode 100644
index 000000000..1ed57fcbb
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gcc.1
@@ -0,0 +1,21501 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GCC 1"
+.TH GCC 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gcc \- GNU project C and C++ compiler
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+gcc [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR] [\fB\-std=\fR\fIstandard\fR]
+    [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
+    [\fB\-W\fR\fIwarn\fR...] [\fB\-Wpedantic\fR]
+    [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
+    [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
+    [\fB\-f\fR\fIoption\fR...] [\fB\-m\fR\fImachine-option\fR...]
+    [\fB\-o\fR \fIoutfile\fR] [@\fIfile\fR] \fIinfile\fR...
+.PP
+Only the most useful options are listed here; see below for the
+remainder.  \fBg++\fR accepts mostly the same options as \fBgcc\fR.
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+When you invoke \s-1GCC,\s0 it normally does preprocessing, compilation,
+assembly and linking.  The \*(L"overall options\*(R" allow you to stop this
+process at an intermediate stage.  For example, the \fB\-c\fR option
+says not to run the linker.  Then the output consists of object files
+output by the assembler.
+.PP
+Other options are passed on to one stage of processing.  Some options
+control the preprocessor and others the compiler itself.  Yet other
+options control the assembler and linker; most of these are not
+documented here, since you rarely need to use any of them.
+.PP
+Most of the command-line options that you can use with \s-1GCC\s0 are useful
+for C programs; when an option is only useful with another language
+(usually \*(C+), the explanation says so explicitly.  If the description
+for a particular option does not mention a source language, you can use
+that option with all supported languages.
+.PP
+The \fBgcc\fR program accepts options and file names as operands.  Many
+options have multi-letter names; therefore multiple single-letter options
+may \fInot\fR be grouped: \fB\-dv\fR is very different from \fB\-d\ \-v\fR.
+.PP
+You can mix options and other arguments.  For the most part, the order
+you use doesn't matter.  Order does matter when you use several
+options of the same kind; for example, if you specify \fB\-L\fR more
+than once, the directories are searched in the order specified.  Also,
+the placement of the \fB\-l\fR option is significant.
+.PP
+Many options have long names starting with \fB\-f\fR or with
+\&\fB\-W\fR\-\-\-for example,
+\&\fB\-fmove\-loop\-invariants\fR, \fB\-Wformat\fR and so on.  Most of
+these have both positive and negative forms; the negative form of
+\&\fB\-ffoo\fR is \fB\-fno\-foo\fR.  This manual documents
+only one of these two forms, whichever one is not the default.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.SS "Option Summary"
+.IX Subsection "Option Summary"
+Here is a summary of all the options, grouped by type.  Explanations are
+in the following sections.
+.IP "\fIOverall Options\fR" 4
+.IX Item "Overall Options"
+\&\fB\-c  \-S  \-E  \-o\fR \fIfile\fR  \fB\-no\-canonical\-prefixes  
+\&\-pipe  \-pass\-exit\-codes  
+\&\-x\fR \fIlanguage\fR  \fB\-v  \-###  \-\-help\fR[\fB=\fR\fIclass\fR[\fB,...\fR]]  \fB\-\-target\-help  
+\&\-\-version \-wrapper @\fR\fIfile\fR \fB\-fplugin=\fR\fIfile\fR \fB\-fplugin\-arg\-\fR\fIname\fR\fB=\fR\fIarg\fR  
+\&\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] \fB\-fada\-spec\-parent=\fR\fIunit\fR \fB\-fdump\-go\-spec=\fR\fIfile\fR
+.IP "\fIC Language Options\fR" 4
+.IX Item "C Language Options"
+\&\fB\-ansi  \-std=\fR\fIstandard\fR  \fB\-fgnu89\-inline 
+\&\-aux\-info\fR \fIfilename\fR \fB\-fallow\-parameterless\-variadic\-functions 
+\&\-fno\-asm  \-fno\-builtin  \-fno\-builtin\-\fR\fIfunction\fR 
+\&\fB\-fhosted  \-ffreestanding \-fopenmp \-fopenmp\-simd \-fms\-extensions 
+\&\-fplan9\-extensions \-trigraphs  \-traditional  \-traditional\-cpp 
+\&\-fallow\-single\-precision  \-fcond\-mismatch \-flax\-vector\-conversions 
+\&\-fsigned\-bitfields  \-fsigned\-char 
+\&\-funsigned\-bitfields  \-funsigned\-char\fR
+.IP "\fI\*(C+ Language Options\fR" 4
+.IX Item " Language Options"
+\&\fB\-fabi\-version=\fR\fIn\fR  \fB\-fno\-access\-control  \-fcheck\-new 
+\&\-fconstexpr\-depth=\fR\fIn\fR  \fB\-ffriend\-injection 
+\&\-fno\-elide\-constructors 
+\&\-fno\-enforce\-eh\-specs 
+\&\-ffor\-scope  \-fno\-for\-scope  \-fno\-gnu\-keywords 
+\&\-fno\-implicit\-templates 
+\&\-fno\-implicit\-inline\-templates 
+\&\-fno\-implement\-inlines  \-fms\-extensions 
+\&\-fno\-nonansi\-builtins  \-fnothrow\-opt  \-fno\-operator\-names 
+\&\-fno\-optional\-diags  \-fpermissive 
+\&\-fno\-pretty\-templates 
+\&\-frepo  \-fno\-rtti  \-fstats  \-ftemplate\-backtrace\-limit=\fR\fIn\fR 
+\&\fB\-ftemplate\-depth=\fR\fIn\fR 
+\&\fB\-fno\-threadsafe\-statics \-fuse\-cxa\-atexit  \-fno\-weak  \-nostdinc++ 
+\&\-fvisibility\-inlines\-hidden 
+\&\-fvtable\-verify=\fR\fIstd|preinit|none\fR 
+\&\fB\-fvtv\-counts \-fvtv\-debug 
+\&\-fvisibility\-ms\-compat 
+\&\-fext\-numeric\-literals 
+\&\-Wabi  \-Wconversion\-null  \-Wctor\-dtor\-privacy 
+\&\-Wdelete\-non\-virtual\-dtor \-Wliteral\-suffix \-Wnarrowing 
+\&\-Wnoexcept \-Wnon\-virtual\-dtor  \-Wreorder 
+\&\-Weffc++  \-Wstrict\-null\-sentinel 
+\&\-Wno\-non\-template\-friend  \-Wold\-style\-cast 
+\&\-Woverloaded\-virtual  \-Wno\-pmf\-conversions 
+\&\-Wsign\-promo\fR
+.IP "\fIObjective-C and Objective\-\*(C+ Language Options\fR" 4
+.IX Item "Objective-C and Objective- Language Options"
+\&\fB\-fconstant\-string\-class=\fR\fIclass-name\fR 
+\&\fB\-fgnu\-runtime  \-fnext\-runtime 
+\&\-fno\-nil\-receivers 
+\&\-fobjc\-abi\-version=\fR\fIn\fR 
+\&\fB\-fobjc\-call\-cxx\-cdtors 
+\&\-fobjc\-direct\-dispatch 
+\&\-fobjc\-exceptions 
+\&\-fobjc\-gc 
+\&\-fobjc\-nilcheck 
+\&\-fobjc\-std=objc1 
+\&\-freplace\-objc\-classes 
+\&\-fzero\-link 
+\&\-gen\-decls 
+\&\-Wassign\-intercept 
+\&\-Wno\-protocol  \-Wselector 
+\&\-Wstrict\-selector\-match 
+\&\-Wundeclared\-selector\fR
+.IP "\fILanguage Independent Options\fR" 4
+.IX Item "Language Independent Options"
+\&\fB\-fmessage\-length=\fR\fIn\fR  
+\&\fB\-fdiagnostics\-show\-location=\fR[\fBonce\fR|\fBevery-line\fR]  
+\&\fB\-fdiagnostics\-color=\fR[\fBauto\fR|\fBnever\fR|\fBalways\fR]  
+\&\fB\-fno\-diagnostics\-show\-option \-fno\-diagnostics\-show\-caret\fR
+.IP "\fIWarning Options\fR" 4
+.IX Item "Warning Options"
+\&\fB\-fsyntax\-only  \-fmax\-errors=\fR\fIn\fR  \fB\-Wpedantic 
+\&\-pedantic\-errors 
+\&\-w  \-Wextra  \-Wall  \-Waddress  \-Waggregate\-return  
+\&\-Waggressive\-loop\-optimizations \-Warray\-bounds 
+\&\-Wno\-attributes \-Wno\-builtin\-macro\-redefined 
+\&\-Wc++\-compat \-Wc++11\-compat \-Wcast\-align  \-Wcast\-qual  
+\&\-Wchar\-subscripts \-Wclobbered  \-Wcomment \-Wconditionally\-supported  
+\&\-Wconversion \-Wcoverage\-mismatch \-Wdate\-time \-Wdelete\-incomplete \-Wno\-cpp  
+\&\-Wno\-deprecated \-Wno\-deprecated\-declarations \-Wdisabled\-optimization  
+\&\-Wno\-div\-by\-zero \-Wdouble\-promotion \-Wempty\-body  \-Wenum\-compare 
+\&\-Wno\-endif\-labels \-Werror  \-Werror=* 
+\&\-Wfatal\-errors  \-Wfloat\-equal  \-Wformat  \-Wformat=2 
+\&\-Wno\-format\-contains\-nul \-Wno\-format\-extra\-args \-Wformat\-nonliteral 
+\&\-Wformat\-security  \-Wformat\-y2k 
+\&\-Wframe\-larger\-than=\fR\fIlen\fR \fB\-Wno\-free\-nonheap\-object \-Wjump\-misses\-init 
+\&\-Wignored\-qualifiers 
+\&\-Wimplicit  \-Wimplicit\-function\-declaration  \-Wimplicit\-int 
+\&\-Winit\-self  \-Winline \-Wmaybe\-uninitialized 
+\&\-Wno\-int\-to\-pointer\-cast \-Wno\-invalid\-offsetof 
+\&\-Winvalid\-pch \-Wlarger\-than=\fR\fIlen\fR  \fB\-Wunsafe\-loop\-optimizations 
+\&\-Wlogical\-op \-Wlong\-long 
+\&\-Wmain \-Wmaybe\-uninitialized \-Wmissing\-braces  \-Wmissing\-field\-initializers 
+\&\-Wmissing\-include\-dirs 
+\&\-Wno\-multichar  \-Wnonnull  \-Wno\-overflow \-Wopenmp\-simd 
+\&\-Woverlength\-strings  \-Wpacked  \-Wpacked\-bitfield\-compat  \-Wpadded 
+\&\-Wparentheses  \-Wpedantic\-ms\-format \-Wno\-pedantic\-ms\-format 
+\&\-Wpointer\-arith  \-Wno\-pointer\-to\-int\-cast 
+\&\-Wredundant\-decls  \-Wno\-return\-local\-addr 
+\&\-Wreturn\-type  \-Wsequence\-point  \-Wshadow 
+\&\-Wsign\-compare  \-Wsign\-conversion \-Wfloat\-conversion 
+\&\-Wsizeof\-pointer\-memaccess 
+\&\-Wstack\-protector \-Wstack\-usage=\fR\fIlen\fR \fB\-Wstrict\-aliasing 
+\&\-Wstrict\-aliasing=n  \-Wstrict\-overflow \-Wstrict\-overflow=\fR\fIn\fR 
+\&\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR|\fBformat\fR] 
+\&\fB\-Wmissing\-format\-attribute 
+\&\-Wswitch  \-Wswitch\-default  \-Wswitch\-enum \-Wsync\-nand 
+\&\-Wsystem\-headers  \-Wtrampolines  \-Wtrigraphs  \-Wtype\-limits  \-Wundef 
+\&\-Wuninitialized  \-Wunknown\-pragmas  \-Wno\-pragmas 
+\&\-Wunsuffixed\-float\-constants  \-Wunused  \-Wunused\-function 
+\&\-Wunused\-label  \-Wunused\-local\-typedefs \-Wunused\-parameter 
+\&\-Wno\-unused\-result \-Wunused\-value  \-Wunused\-variable 
+\&\-Wunused\-but\-set\-parameter \-Wunused\-but\-set\-variable 
+\&\-Wuseless\-cast \-Wvariadic\-macros \-Wvector\-operation\-performance 
+\&\-Wvla \-Wvolatile\-register\-var  \-Wwrite\-strings \-Wzero\-as\-null\-pointer\-constant\fR
+.IP "\fIC and Objective-C-only Warning Options\fR" 4
+.IX Item "C and Objective-C-only Warning Options"
+\&\fB\-Wbad\-function\-cast  \-Wmissing\-declarations 
+\&\-Wmissing\-parameter\-type  \-Wmissing\-prototypes  \-Wnested\-externs 
+\&\-Wold\-style\-declaration  \-Wold\-style\-definition 
+\&\-Wstrict\-prototypes  \-Wtraditional  \-Wtraditional\-conversion 
+\&\-Wdeclaration\-after\-statement \-Wpointer\-sign\fR
+.IP "\fIDebugging Options\fR" 4
+.IX Item "Debugging Options"
+\&\fB\-d\fR\fIletters\fR  \fB\-dumpspecs  \-dumpmachine  \-dumpversion 
+\&\-fsanitize=\fR\fIstyle\fR 
+\&\fB\-fdbg\-cnt\-list \-fdbg\-cnt=\fR\fIcounter-value-list\fR 
+\&\fB\-fdisable\-ipa\-\fR\fIpass_name\fR 
+\&\fB\-fdisable\-rtl\-\fR\fIpass_name\fR 
+\&\fB\-fdisable\-rtl\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR 
+\&\fB\-fdisable\-tree\-\fR\fIpass_name\fR 
+\&\fB\-fdisable\-tree\-\fR\fIpass-name\fR\fB=\fR\fIrange-list\fR 
+\&\fB\-fdump\-noaddr \-fdump\-unnumbered \-fdump\-unnumbered\-links 
+\&\-fdump\-translation\-unit\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-class\-hierarchy\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-ipa\-all \-fdump\-ipa\-cgraph \-fdump\-ipa\-inline 
+\&\-fdump\-passes 
+\&\-fdump\-statistics 
+\&\-fdump\-tree\-all 
+\&\-fdump\-tree\-original\fR[\fB\-\fR\fIn\fR]  
+\&\fB\-fdump\-tree\-optimized\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-cfg \-fdump\-tree\-alias 
+\&\-fdump\-tree\-ch 
+\&\-fdump\-tree\-ssa\fR[\fB\-\fR\fIn\fR] \fB\-fdump\-tree\-pre\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-ccp\fR[\fB\-\fR\fIn\fR] \fB\-fdump\-tree\-dce\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-gimple\fR[\fB\-raw\fR] 
+\&\fB\-fdump\-tree\-dom\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-dse\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-phiprop\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-phiopt\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-forwprop\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-copyrename\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-nrv \-fdump\-tree\-vect 
+\&\-fdump\-tree\-sink 
+\&\-fdump\-tree\-sra\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-forwprop\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-fre\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-vtable\-verify 
+\&\-fdump\-tree\-vrp\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-tree\-storeccp\fR[\fB\-\fR\fIn\fR] 
+\&\fB\-fdump\-final\-insns=\fR\fIfile\fR 
+\&\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]  \fB\-fcompare\-debug\-second 
+\&\-feliminate\-dwarf2\-dups \-fno\-eliminate\-unused\-debug\-types 
+\&\-feliminate\-unused\-debug\-symbols \-femit\-class\-debug\-always 
+\&\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR 
+\&\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR 
+\&\fB\-fdebug\-types\-section \-fmem\-report\-wpa 
+\&\-fmem\-report \-fpre\-ipa\-mem\-report \-fpost\-ipa\-mem\-report \-fprofile\-arcs 
+\&\-fopt\-info 
+\&\-fopt\-info\-\fR\fIoptions\fR[\fB=\fR\fIfile\fR] 
+\&\fB\-frandom\-seed=\fR\fIstring\fR \fB\-fsched\-verbose=\fR\fIn\fR 
+\&\fB\-fsel\-sched\-verbose \-fsel\-sched\-dump\-cfg \-fsel\-sched\-pipelining\-verbose 
+\&\-fstack\-usage  \-ftest\-coverage  \-ftime\-report \-fvar\-tracking 
+\&\-fvar\-tracking\-assignments  \-fvar\-tracking\-assignments\-toggle 
+\&\-g  \-g\fR\fIlevel\fR  \fB\-gtoggle  \-gcoff  \-gdwarf\-\fR\fIversion\fR 
+\&\fB\-ggdb  \-grecord\-gcc\-switches  \-gno\-record\-gcc\-switches 
+\&\-gstabs  \-gstabs+  \-gstrict\-dwarf  \-gno\-strict\-dwarf 
+\&\-gvms  \-gxcoff  \-gxcoff+ 
+\&\-fno\-merge\-debug\-strings \-fno\-dwarf2\-cfi\-asm 
+\&\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR 
+\&\fB\-femit\-struct\-debug\-baseonly \-femit\-struct\-debug\-reduced 
+\&\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR] 
+\&\fB\-p  \-pg  \-print\-file\-name=\fR\fIlibrary\fR  \fB\-print\-libgcc\-file\-name 
+\&\-print\-multi\-directory  \-print\-multi\-lib  \-print\-multi\-os\-directory 
+\&\-print\-prog\-name=\fR\fIprogram\fR  \fB\-print\-search\-dirs  \-Q 
+\&\-print\-sysroot \-print\-sysroot\-headers\-suffix 
+\&\-save\-temps \-save\-temps=cwd \-save\-temps=obj \-time\fR[\fB=\fR\fIfile\fR]
+.IP "\fIOptimization Options\fR" 4
+.IX Item "Optimization Options"
+\&\fB\-faggressive\-loop\-optimizations \-falign\-functions[=\fR\fIn\fR\fB] 
+\&\-falign\-jumps[=\fR\fIn\fR\fB] 
+\&\-falign\-labels[=\fR\fIn\fR\fB] \-falign\-loops[=\fR\fIn\fR\fB] 
+\&\-fassociative\-math \-fauto\-inc\-dec \-fbranch\-probabilities 
+\&\-fbranch\-target\-load\-optimize \-fbranch\-target\-load\-optimize2 
+\&\-fbtr\-bb\-exclusive \-fcaller\-saves 
+\&\-fcheck\-data\-deps \-fcombine\-stack\-adjustments \-fconserve\-stack 
+\&\-fcompare\-elim \-fcprop\-registers \-fcrossjumping 
+\&\-fcse\-follow\-jumps \-fcse\-skip\-blocks \-fcx\-fortran\-rules 
+\&\-fcx\-limited\-range 
+\&\-fdata\-sections \-fdce \-fdelayed\-branch 
+\&\-fdelete\-null\-pointer\-checks \-fdevirtualize \-fdevirtualize\-speculatively \-fdse 
+\&\-fearly\-inlining \-fipa\-sra \-fexpensive\-optimizations \-ffat\-lto\-objects 
+\&\-ffast\-math \-ffinite\-math\-only \-ffloat\-store \-fexcess\-precision=\fR\fIstyle\fR 
+\&\fB\-fforward\-propagate \-ffp\-contract=\fR\fIstyle\fR \fB\-ffunction\-sections 
+\&\-fgcse \-fgcse\-after\-reload \-fgcse\-las \-fgcse\-lm \-fgraphite\-identity 
+\&\-fgcse\-sm \-fhoist\-adjacent\-loads \-fif\-conversion 
+\&\-fif\-conversion2 \-findirect\-inlining 
+\&\-finline\-functions \-finline\-functions\-called\-once \-finline\-limit=\fR\fIn\fR 
+\&\fB\-finline\-small\-functions \-fipa\-cp \-fipa\-cp\-clone 
+\&\-fipa\-pta \-fipa\-profile \-fipa\-pure\-const \-fipa\-reference 
+\&\-fira\-algorithm=\fR\fIalgorithm\fR 
+\&\fB\-fira\-region=\fR\fIregion\fR \fB\-fira\-hoist\-pressure 
+\&\-fira\-loop\-pressure \-fno\-ira\-share\-save\-slots 
+\&\-fno\-ira\-share\-spill\-slots \-fira\-verbose=\fR\fIn\fR 
+\&\fB\-fisolate\-erroneous\-paths\-dereference \-fisolate\-erroneous\-paths\-attribute
+\&\-fivopts \-fkeep\-inline\-functions \-fkeep\-static\-consts \-flive\-range\-shrinkage 
+\&\-floop\-block \-floop\-interchange \-floop\-strip\-mine \-floop\-nest\-optimize 
+\&\-floop\-parallelize\-all \-flto \-flto\-compression\-level 
+\&\-flto\-partition=\fR\fIalg\fR \fB\-flto\-report \-flto\-report\-wpa \-fmerge\-all\-constants 
+\&\-fmerge\-constants \-fmodulo\-sched \-fmodulo\-sched\-allow\-regmoves 
+\&\-fmove\-loop\-invariants \-fno\-branch\-count\-reg 
+\&\-fno\-defer\-pop \-fno\-function\-cse \-fno\-guess\-branch\-probability 
+\&\-fno\-inline \-fno\-math\-errno \-fno\-peephole \-fno\-peephole2 
+\&\-fno\-sched\-interblock \-fno\-sched\-spec \-fno\-signed\-zeros 
+\&\-fno\-toplevel\-reorder \-fno\-trapping\-math \-fno\-zero\-initialized\-in\-bss 
+\&\-fomit\-frame\-pointer \-foptimize\-sibling\-calls 
+\&\-fpartial\-inlining \-fpeel\-loops \-fpredictive\-commoning 
+\&\-fprefetch\-loop\-arrays \-fprofile\-report 
+\&\-fprofile\-correction \-fprofile\-dir=\fR\fIpath\fR \fB\-fprofile\-generate 
+\&\-fprofile\-generate=\fR\fIpath\fR 
+\&\fB\-fprofile\-use \-fprofile\-use=\fR\fIpath\fR \fB\-fprofile\-values \-fprofile\-reorder\-functions 
+\&\-freciprocal\-math \-free \-frename\-registers \-freorder\-blocks 
+\&\-freorder\-blocks\-and\-partition \-freorder\-functions 
+\&\-frerun\-cse\-after\-loop \-freschedule\-modulo\-scheduled\-loops 
+\&\-frounding\-math \-fsched2\-use\-superblocks \-fsched\-pressure 
+\&\-fsched\-spec\-load \-fsched\-spec\-load\-dangerous 
+\&\-fsched\-stalled\-insns\-dep[=\fR\fIn\fR\fB] \-fsched\-stalled\-insns[=\fR\fIn\fR\fB] 
+\&\-fsched\-group\-heuristic \-fsched\-critical\-path\-heuristic 
+\&\-fsched\-spec\-insn\-heuristic \-fsched\-rank\-heuristic 
+\&\-fsched\-last\-insn\-heuristic \-fsched\-dep\-count\-heuristic 
+\&\-fschedule\-insns \-fschedule\-insns2 \-fsection\-anchors 
+\&\-fselective\-scheduling \-fselective\-scheduling2 
+\&\-fsel\-sched\-pipelining \-fsel\-sched\-pipelining\-outer\-loops 
+\&\-fshrink\-wrap \-fsignaling\-nans \-fsingle\-precision\-constant 
+\&\-fsplit\-ivs\-in\-unroller \-fsplit\-wide\-types \-fstack\-protector 
+\&\-fstack\-protector\-all \-fstack\-protector\-strong \-fstrict\-aliasing 
+\&\-fstrict\-overflow \-fthread\-jumps \-ftracer \-ftree\-bit\-ccp 
+\&\-ftree\-builtin\-call\-dce \-ftree\-ccp \-ftree\-ch 
+\&\-ftree\-coalesce\-inline\-vars \-ftree\-coalesce\-vars \-ftree\-copy\-prop 
+\&\-ftree\-copyrename \-ftree\-dce \-ftree\-dominator\-opts \-ftree\-dse 
+\&\-ftree\-forwprop \-ftree\-fre \-ftree\-loop\-if\-convert 
+\&\-ftree\-loop\-if\-convert\-stores \-ftree\-loop\-im 
+\&\-ftree\-phiprop \-ftree\-loop\-distribution \-ftree\-loop\-distribute\-patterns 
+\&\-ftree\-loop\-ivcanon \-ftree\-loop\-linear \-ftree\-loop\-optimize 
+\&\-ftree\-loop\-vectorize 
+\&\-ftree\-parallelize\-loops=\fR\fIn\fR \fB\-ftree\-pre \-ftree\-partial\-pre \-ftree\-pta 
+\&\-ftree\-reassoc \-ftree\-sink \-ftree\-slsr \-ftree\-sra 
+\&\-ftree\-switch\-conversion \-ftree\-tail\-merge \-ftree\-ter 
+\&\-ftree\-vectorize \-ftree\-vrp 
+\&\-funit\-at\-a\-time \-funroll\-all\-loops \-funroll\-loops 
+\&\-funsafe\-loop\-optimizations \-funsafe\-math\-optimizations \-funswitch\-loops 
+\&\-fvariable\-expansion\-in\-unroller \-fvect\-cost\-model \-fvpt \-fweb 
+\&\-fwhole\-program \-fwpa \-fuse\-ld=\fR\fIlinker\fR \fB\-fuse\-linker\-plugin 
+\&\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR
+\&\fB\-O  \-O0  \-O1  \-O2  \-O3  \-Os \-Ofast \-Og\fR
+.IP "\fIPreprocessor Options\fR" 4
+.IX Item "Preprocessor Options"
+\&\fB\-A\fR\fIquestion\fR\fB=\fR\fIanswer\fR 
+\&\fB\-A\-\fR\fIquestion\fR[\fB=\fR\fIanswer\fR] 
+\&\fB\-C  \-dD  \-dI  \-dM  \-dN 
+\&\-D\fR\fImacro\fR[\fB=\fR\fIdefn\fR]  \fB\-E  \-H 
+\&\-idirafter\fR \fIdir\fR 
+\&\fB\-include\fR \fIfile\fR  \fB\-imacros\fR \fIfile\fR 
+\&\fB\-iprefix\fR \fIfile\fR  \fB\-iwithprefix\fR \fIdir\fR 
+\&\fB\-iwithprefixbefore\fR \fIdir\fR  \fB\-isystem\fR \fIdir\fR 
+\&\fB\-imultilib\fR \fIdir\fR \fB\-isysroot\fR \fIdir\fR 
+\&\fB\-M  \-MM  \-MF  \-MG  \-MP  \-MQ  \-MT  \-nostdinc  
+\&\-P  \-fdebug\-cpp \-ftrack\-macro\-expansion \-fworking\-directory 
+\&\-remap \-trigraphs  \-undef  \-U\fR\fImacro\fR  
+\&\fB\-Wp,\fR\fIoption\fR \fB\-Xpreprocessor\fR \fIoption\fR \fB\-no\-integrated\-cpp\fR
+.IP "\fIAssembler Option\fR" 4
+.IX Item "Assembler Option"
+\&\fB\-Wa,\fR\fIoption\fR  \fB\-Xassembler\fR \fIoption\fR
+.IP "\fILinker Options\fR" 4
+.IX Item "Linker Options"
+\&\fIobject-file-name\fR  \fB\-l\fR\fIlibrary\fR 
+\&\fB\-nostartfiles  \-nodefaultlibs  \-nostdlib \-pie \-rdynamic 
+\&\-s  \-static \-static\-libgcc \-static\-libstdc++ 
+\&\-static\-libasan \-static\-libtsan \-static\-liblsan \-static\-libubsan 
+\&\-shared \-shared\-libgcc  \-symbolic 
+\&\-T\fR \fIscript\fR  \fB\-Wl,\fR\fIoption\fR  \fB\-Xlinker\fR \fIoption\fR 
+\&\fB\-u\fR \fIsymbol\fR
+.IP "\fIDirectory Options\fR" 4
+.IX Item "Directory Options"
+\&\fB\-B\fR\fIprefix\fR \fB\-I\fR\fIdir\fR \fB\-iplugindir=\fR\fIdir\fR 
+\&\fB\-iquote\fR\fIdir\fR \fB\-L\fR\fIdir\fR \fB\-specs=\fR\fIfile\fR \fB\-I\- 
+\&\-\-sysroot=\fR\fIdir\fR \fB\-\-no\-sysroot\-suffix\fR
+.IP "\fIMachine Dependent Options\fR" 4
+.IX Item "Machine Dependent Options"
+\&\fIAArch64 Options\fR
+\&\fB\-mabi=\fR\fIname\fR  \fB\-mbig\-endian  \-mlittle\-endian 
+\&\-mgeneral\-regs\-only 
+\&\-mcmodel=tiny  \-mcmodel=small  \-mcmodel=large 
+\&\-mstrict\-align 
+\&\-momit\-leaf\-frame\-pointer  \-mno\-omit\-leaf\-frame\-pointer 
+\&\-mtls\-dialect=desc  \-mtls\-dialect=traditional 
+\&\-march=\fR\fIname\fR  \fB\-mcpu=\fR\fIname\fR  \fB\-mtune=\fR\fIname\fR
+.Sp
+\&\fIAdapteva Epiphany Options\fR
+\&\fB\-mhalf\-reg\-file \-mprefer\-short\-insn\-regs 
+\&\-mbranch\-cost=\fR\fInum\fR \fB\-mcmove \-mnops=\fR\fInum\fR \fB\-msoft\-cmpsf 
+\&\-msplit\-lohi \-mpost\-inc \-mpost\-modify \-mstack\-offset=\fR\fInum\fR 
+\&\fB\-mround\-nearest \-mlong\-calls \-mshort\-calls \-msmall16 
+\&\-mfp\-mode=\fR\fImode\fR \fB\-mvect\-double \-max\-vect\-align=\fR\fInum\fR 
+\&\fB\-msplit\-vecmove\-early \-m1reg\-\fR\fIreg\fR
+.Sp
+\&\fI\s-1ARC\s0 Options\fR
+\&\fB\-mbarrel\-shifter 
+\&\-mcpu=\fR\fIcpu\fR \fB\-mA6 \-mARC600 \-mA7 \-mARC700 
+\&\-mdpfp \-mdpfp\-compact \-mdpfp\-fast \-mno\-dpfp\-lrsr 
+\&\-mea \-mno\-mpy \-mmul32x16 \-mmul64 
+\&\-mnorm \-mspfp \-mspfp\-compact \-mspfp\-fast \-msimd \-msoft\-float \-mswap 
+\&\-mcrc \-mdsp\-packa \-mdvbf \-mlock \-mmac\-d16 \-mmac\-24 \-mrtsc \-mswape 
+\&\-mtelephony \-mxy \-misize \-mannotate\-align \-marclinux \-marclinux_prof 
+\&\-mepilogue\-cfi \-mlong\-calls \-mmedium\-calls \-msdata 
+\&\-mucb\-mcount \-mvolatile\-cache 
+\&\-malign\-call \-mauto\-modify\-reg \-mbbit\-peephole \-mno\-brcc 
+\&\-mcase\-vector\-pcrel \-mcompact\-casesi \-mno\-cond\-exec \-mearly\-cbranchsi 
+\&\-mexpand\-adddi \-mindexed\-loads \-mlra \-mlra\-priority\-none 
+\&\-mlra\-priority\-compact mlra-priority-noncompact \-mno\-millicode 
+\&\-mmixed\-code \-mq\-class \-mRcq \-mRcw \-msize\-level=\fR\fIlevel\fR 
+\&\fB\-mtune=\fR\fIcpu\fR \fB\-mmultcost=\fR\fInum\fR \fB\-munalign\-prob\-threshold=\fR\fIprobability\fR
+.Sp
+\&\fI\s-1ARM\s0 Options\fR
+\&\fB\-mapcs\-frame  \-mno\-apcs\-frame 
+\&\-mabi=\fR\fIname\fR 
+\&\fB\-mapcs\-stack\-check  \-mno\-apcs\-stack\-check 
+\&\-mapcs\-float  \-mno\-apcs\-float 
+\&\-mapcs\-reentrant  \-mno\-apcs\-reentrant 
+\&\-msched\-prolog  \-mno\-sched\-prolog 
+\&\-mlittle\-endian  \-mbig\-endian  \-mwords\-little\-endian 
+\&\-mfloat\-abi=\fR\fIname\fR 
+\&\fB\-mfp16\-format=\fR\fIname\fR
+\&\fB\-mthumb\-interwork  \-mno\-thumb\-interwork 
+\&\-mcpu=\fR\fIname\fR  \fB\-march=\fR\fIname\fR  \fB\-mfpu=\fR\fIname\fR  
+\&\fB\-mstructure\-size\-boundary=\fR\fIn\fR 
+\&\fB\-mabort\-on\-noreturn 
+\&\-mlong\-calls  \-mno\-long\-calls 
+\&\-msingle\-pic\-base  \-mno\-single\-pic\-base 
+\&\-mpic\-register=\fR\fIreg\fR 
+\&\fB\-mnop\-fun\-dllimport 
+\&\-mpoke\-function\-name 
+\&\-mthumb  \-marm 
+\&\-mtpcs\-frame  \-mtpcs\-leaf\-frame 
+\&\-mcaller\-super\-interworking  \-mcallee\-super\-interworking 
+\&\-mtp=\fR\fIname\fR \fB\-mtls\-dialect=\fR\fIdialect\fR 
+\&\fB\-mword\-relocations 
+\&\-mfix\-cortex\-m3\-ldrd 
+\&\-munaligned\-access 
+\&\-mneon\-for\-64bits 
+\&\-mslow\-flash\-data 
+\&\-mrestrict\-it\fR
+.Sp
+\&\fI\s-1AVR\s0 Options\fR
+\&\fB\-mmcu=\fR\fImcu\fR \fB\-maccumulate\-args \-mbranch\-cost=\fR\fIcost\fR 
+\&\fB\-mcall\-prologues \-mint8 \-mno\-interrupts \-mrelax 
+\&\-mstrict\-X \-mtiny\-stack \-Waddr\-space\-convert\fR
+.Sp
+\&\fIBlackfin Options\fR
+\&\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR] 
+\&\fB\-msim \-momit\-leaf\-frame\-pointer  \-mno\-omit\-leaf\-frame\-pointer 
+\&\-mspecld\-anomaly  \-mno\-specld\-anomaly  \-mcsync\-anomaly  \-mno\-csync\-anomaly 
+\&\-mlow\-64k \-mno\-low64k  \-mstack\-check\-l1  \-mid\-shared\-library 
+\&\-mno\-id\-shared\-library  \-mshared\-library\-id=\fR\fIn\fR 
+\&\fB\-mleaf\-id\-shared\-library  \-mno\-leaf\-id\-shared\-library 
+\&\-msep\-data  \-mno\-sep\-data  \-mlong\-calls  \-mno\-long\-calls 
+\&\-mfast\-fp \-minline\-plt \-mmulticore  \-mcorea  \-mcoreb  \-msdram 
+\&\-micplb\fR
+.Sp
+\&\fIC6X Options\fR
+\&\fB\-mbig\-endian  \-mlittle\-endian \-march=\fR\fIcpu\fR 
+\&\fB\-msim \-msdata=\fR\fIsdata-type\fR
+.Sp
+\&\fI\s-1CRIS\s0 Options\fR
+\&\fB\-mcpu=\fR\fIcpu\fR  \fB\-march=\fR\fIcpu\fR  \fB\-mtune=\fR\fIcpu\fR 
+\&\fB\-mmax\-stack\-frame=\fR\fIn\fR  \fB\-melinux\-stacksize=\fR\fIn\fR 
+\&\fB\-metrax4  \-metrax100  \-mpdebug  \-mcc\-init  \-mno\-side\-effects 
+\&\-mstack\-align  \-mdata\-align  \-mconst\-align 
+\&\-m32\-bit  \-m16\-bit  \-m8\-bit  \-mno\-prologue\-epilogue  \-mno\-gotplt 
+\&\-melf  \-maout  \-melinux  \-mlinux  \-sim  \-sim2 
+\&\-mmul\-bug\-workaround  \-mno\-mul\-bug\-workaround\fR
+.Sp
+\&\fI\s-1CR16\s0 Options\fR
+\&\fB\-mmac 
+\&\-mcr16cplus \-mcr16c 
+\&\-msim \-mint32 \-mbit\-ops
+\&\-mdata\-model=\fR\fImodel\fR
+.Sp
+\&\fIDarwin Options\fR
+\&\fB\-all_load  \-allowable_client  \-arch  \-arch_errors_fatal 
+\&\-arch_only  \-bind_at_load  \-bundle  \-bundle_loader 
+\&\-client_name  \-compatibility_version  \-current_version 
+\&\-dead_strip 
+\&\-dependency\-file  \-dylib_file  \-dylinker_install_name 
+\&\-dynamic  \-dynamiclib  \-exported_symbols_list 
+\&\-filelist  \-flat_namespace  \-force_cpusubtype_ALL 
+\&\-force_flat_namespace  \-headerpad_max_install_names 
+\&\-iframework 
+\&\-image_base  \-init  \-install_name  \-keep_private_externs 
+\&\-multi_module  \-multiply_defined  \-multiply_defined_unused 
+\&\-noall_load   \-no_dead_strip_inits_and_terms 
+\&\-nofixprebinding \-nomultidefs  \-noprebind  \-noseglinkedit 
+\&\-pagezero_size  \-prebind  \-prebind_all_twolevel_modules 
+\&\-private_bundle  \-read_only_relocs  \-sectalign 
+\&\-sectobjectsymbols  \-whyload  \-seg1addr 
+\&\-sectcreate  \-sectobjectsymbols  \-sectorder 
+\&\-segaddr \-segs_read_only_addr \-segs_read_write_addr 
+\&\-seg_addr_table  \-seg_addr_table_filename  \-seglinkedit 
+\&\-segprot  \-segs_read_only_addr  \-segs_read_write_addr 
+\&\-single_module  \-static  \-sub_library  \-sub_umbrella 
+\&\-twolevel_namespace  \-umbrella  \-undefined 
+\&\-unexported_symbols_list  \-weak_reference_mismatches 
+\&\-whatsloaded \-F \-gused \-gfull \-mmacosx\-version\-min=\fR\fIversion\fR 
+\&\fB\-mkernel \-mone\-byte\-bool\fR
+.Sp
+\&\fI\s-1DEC\s0 Alpha Options\fR
+\&\fB\-mno\-fp\-regs  \-msoft\-float 
+\&\-mieee  \-mieee\-with\-inexact  \-mieee\-conformant 
+\&\-mfp\-trap\-mode=\fR\fImode\fR  \fB\-mfp\-rounding\-mode=\fR\fImode\fR 
+\&\fB\-mtrap\-precision=\fR\fImode\fR  \fB\-mbuild\-constants 
+\&\-mcpu=\fR\fIcpu-type\fR  \fB\-mtune=\fR\fIcpu-type\fR 
+\&\fB\-mbwx  \-mmax  \-mfix  \-mcix 
+\&\-mfloat\-vax  \-mfloat\-ieee 
+\&\-mexplicit\-relocs  \-msmall\-data  \-mlarge\-data 
+\&\-msmall\-text  \-mlarge\-text 
+\&\-mmemory\-latency=\fR\fItime\fR
+.Sp
+\&\fI\s-1FR30\s0 Options\fR
+\&\fB\-msmall\-model \-mno\-lsim\fR
+.Sp
+\&\fI\s-1FRV\s0 Options\fR
+\&\fB\-mgpr\-32  \-mgpr\-64  \-mfpr\-32  \-mfpr\-64 
+\&\-mhard\-float  \-msoft\-float 
+\&\-malloc\-cc  \-mfixed\-cc  \-mdword  \-mno\-dword 
+\&\-mdouble  \-mno\-double 
+\&\-mmedia  \-mno\-media  \-mmuladd  \-mno\-muladd 
+\&\-mfdpic  \-minline\-plt \-mgprel\-ro  \-multilib\-library\-pic 
+\&\-mlinked\-fp  \-mlong\-calls  \-malign\-labels 
+\&\-mlibrary\-pic  \-macc\-4  \-macc\-8 
+\&\-mpack  \-mno\-pack  \-mno\-eflags  \-mcond\-move  \-mno\-cond\-move 
+\&\-moptimize\-membar \-mno\-optimize\-membar 
+\&\-mscc  \-mno\-scc  \-mcond\-exec  \-mno\-cond\-exec 
+\&\-mvliw\-branch  \-mno\-vliw\-branch 
+\&\-mmulti\-cond\-exec  \-mno\-multi\-cond\-exec  \-mnested\-cond\-exec 
+\&\-mno\-nested\-cond\-exec  \-mtomcat\-stats 
+\&\-mTLS \-mtls 
+\&\-mcpu=\fR\fIcpu\fR
+.Sp
+\&\fIGNU/Linux Options\fR
+\&\fB\-mglibc \-muclibc \-mbionic \-mandroid 
+\&\-tno\-android\-cc \-tno\-android\-ld\fR
+.Sp
+\&\fIH8/300 Options\fR
+\&\fB\-mrelax  \-mh  \-ms  \-mn  \-mexr \-mno\-exr  \-mint32  \-malign\-300\fR
+.Sp
+\&\fI\s-1HPPA\s0 Options\fR
+\&\fB\-march=\fR\fIarchitecture-type\fR 
+\&\fB\-mdisable\-fpregs  \-mdisable\-indexing 
+\&\-mfast\-indirect\-calls  \-mgas  \-mgnu\-ld   \-mhp\-ld 
+\&\-mfixed\-range=\fR\fIregister-range\fR 
+\&\fB\-mjump\-in\-delay \-mlinker\-opt \-mlong\-calls 
+\&\-mlong\-load\-store  \-mno\-disable\-fpregs 
+\&\-mno\-disable\-indexing  \-mno\-fast\-indirect\-calls  \-mno\-gas 
+\&\-mno\-jump\-in\-delay  \-mno\-long\-load\-store 
+\&\-mno\-portable\-runtime  \-mno\-soft\-float 
+\&\-mno\-space\-regs  \-msoft\-float  \-mpa\-risc\-1\-0 
+\&\-mpa\-risc\-1\-1  \-mpa\-risc\-2\-0  \-mportable\-runtime 
+\&\-mschedule=\fR\fIcpu-type\fR  \fB\-mspace\-regs  \-msio  \-mwsio 
+\&\-munix=\fR\fIunix-std\fR  \fB\-nolibdld  \-static  \-threads\fR
+.Sp
+\&\fIi386 and x86\-64 Options\fR
+\&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-march=\fR\fIcpu-type\fR 
+\&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR \fB\-mdump\-tune\-features \-mno\-default 
+\&\-mfpmath=\fR\fIunit\fR 
+\&\fB\-masm=\fR\fIdialect\fR  \fB\-mno\-fancy\-math\-387 
+\&\-mno\-fp\-ret\-in\-387  \-msoft\-float 
+\&\-mno\-wide\-multiply  \-mrtd  \-malign\-double 
+\&\-mpreferred\-stack\-boundary=\fR\fInum\fR 
+\&\fB\-mincoming\-stack\-boundary=\fR\fInum\fR 
+\&\fB\-mcld \-mcx16 \-msahf \-mmovbe \-mcrc32 
+\&\-mrecip \-mrecip=\fR\fIopt\fR 
+\&\fB\-mvzeroupper \-mprefer\-avx128 
+\&\-mmmx  \-msse  \-msse2 \-msse3 \-mssse3 \-msse4.1 \-msse4.2 \-msse4 \-mavx 
+\&\-mavx2 \-mavx512f \-mavx512pf \-mavx512er \-mavx512cd \-msha 
+\&\-maes \-mpclmul \-mfsgsbase \-mrdrnd \-mf16c \-mfma \-mprefetchwt1 
+\&\-msse4a \-m3dnow \-mpopcnt \-mabm \-mbmi \-mtbm \-mfma4 \-mxop \-mlzcnt 
+\&\-mbmi2 \-mfxsr \-mxsave \-mxsaveopt \-mrtm \-mlwp \-mthreads 
+\&\-mno\-align\-stringops  \-minline\-all\-stringops 
+\&\-minline\-stringops\-dynamically \-mstringop\-strategy=\fR\fIalg\fR 
+\&\fB\-mmemcpy\-strategy=\fR\fIstrategy\fR \fB\-mmemset\-strategy=\fR\fIstrategy\fR
+\&\fB\-mpush\-args  \-maccumulate\-outgoing\-args  \-m128bit\-long\-double 
+\&\-m96bit\-long\-double \-mlong\-double\-64 \-mlong\-double\-80 \-mlong\-double\-128 
+\&\-mregparm=\fR\fInum\fR  \fB\-msseregparm 
+\&\-mveclibabi=\fR\fItype\fR \fB\-mvect8\-ret\-in\-mem 
+\&\-mpc32 \-mpc64 \-mpc80 \-mstackrealign 
+\&\-momit\-leaf\-frame\-pointer  \-mno\-red\-zone \-mno\-tls\-direct\-seg\-refs 
+\&\-mcmodel=\fR\fIcode-model\fR \fB\-mabi=\fR\fIname\fR \fB\-maddress\-mode=\fR\fImode\fR 
+\&\fB\-m32 \-m64 \-mx32 \-m16 \-mlarge\-data\-threshold=\fR\fInum\fR 
+\&\fB\-msse2avx \-mfentry \-m8bit\-idiv 
+\&\-mavx256\-split\-unaligned\-load \-mavx256\-split\-unaligned\-store 
+\&\-mstack\-protector\-guard=\fR\fIguard\fR
+.Sp
+\&\fIi386 and x86\-64 Windows Options\fR
+\&\fB\-mconsole \-mcygwin \-mno\-cygwin \-mdll 
+\&\-mnop\-fun\-dllimport \-mthread 
+\&\-municode \-mwin32 \-mwindows \-fno\-set\-stack\-executable\fR
+.Sp
+\&\fI\s-1IA\-64\s0 Options\fR
+\&\fB\-mbig\-endian  \-mlittle\-endian  \-mgnu\-as  \-mgnu\-ld  \-mno\-pic 
+\&\-mvolatile\-asm\-stop  \-mregister\-names  \-msdata \-mno\-sdata 
+\&\-mconstant\-gp  \-mauto\-pic  \-mfused\-madd 
+\&\-minline\-float\-divide\-min\-latency 
+\&\-minline\-float\-divide\-max\-throughput 
+\&\-mno\-inline\-float\-divide 
+\&\-minline\-int\-divide\-min\-latency 
+\&\-minline\-int\-divide\-max\-throughput  
+\&\-mno\-inline\-int\-divide 
+\&\-minline\-sqrt\-min\-latency \-minline\-sqrt\-max\-throughput 
+\&\-mno\-inline\-sqrt 
+\&\-mdwarf2\-asm \-mearly\-stop\-bits 
+\&\-mfixed\-range=\fR\fIregister-range\fR \fB\-mtls\-size=\fR\fItls-size\fR 
+\&\fB\-mtune=\fR\fIcpu-type\fR \fB\-milp32 \-mlp64 
+\&\-msched\-br\-data\-spec \-msched\-ar\-data\-spec \-msched\-control\-spec 
+\&\-msched\-br\-in\-data\-spec \-msched\-ar\-in\-data\-spec \-msched\-in\-control\-spec 
+\&\-msched\-spec\-ldc \-msched\-spec\-control\-ldc 
+\&\-msched\-prefer\-non\-data\-spec\-insns \-msched\-prefer\-non\-control\-spec\-insns 
+\&\-msched\-stop\-bits\-after\-every\-cycle \-msched\-count\-spec\-in\-critical\-path 
+\&\-msel\-sched\-dont\-check\-control\-spec \-msched\-fp\-mem\-deps\-zero\-cost 
+\&\-msched\-max\-memory\-insns\-hard\-limit \-msched\-max\-memory\-insns=\fR\fImax-insns\fR
+.Sp
+\&\fI\s-1LM32\s0 Options\fR
+\&\fB\-mbarrel\-shift\-enabled \-mdivide\-enabled \-mmultiply\-enabled 
+\&\-msign\-extend\-enabled \-muser\-enabled\fR
+.Sp
+\&\fIM32R/D Options\fR
+\&\fB\-m32r2 \-m32rx \-m32r 
+\&\-mdebug 
+\&\-malign\-loops \-mno\-align\-loops 
+\&\-missue\-rate=\fR\fInumber\fR 
+\&\fB\-mbranch\-cost=\fR\fInumber\fR 
+\&\fB\-mmodel=\fR\fIcode-size-model-type\fR 
+\&\fB\-msdata=\fR\fIsdata-type\fR 
+\&\fB\-mno\-flush\-func \-mflush\-func=\fR\fIname\fR 
+\&\fB\-mno\-flush\-trap \-mflush\-trap=\fR\fInumber\fR 
+\&\fB\-G\fR \fInum\fR
+.Sp
+\&\fIM32C Options\fR
+\&\fB\-mcpu=\fR\fIcpu\fR \fB\-msim \-memregs=\fR\fInumber\fR
+.Sp
+\&\fIM680x0 Options\fR
+\&\fB\-march=\fR\fIarch\fR  \fB\-mcpu=\fR\fIcpu\fR  \fB\-mtune=\fR\fItune\fR
+\&\fB\-m68000  \-m68020  \-m68020\-40  \-m68020\-60  \-m68030  \-m68040 
+\&\-m68060  \-mcpu32  \-m5200  \-m5206e  \-m528x  \-m5307  \-m5407 
+\&\-mcfv4e  \-mbitfield  \-mno\-bitfield  \-mc68000  \-mc68020 
+\&\-mnobitfield  \-mrtd  \-mno\-rtd  \-mdiv  \-mno\-div  \-mshort 
+\&\-mno\-short  \-mhard\-float  \-m68881  \-msoft\-float  \-mpcrel 
+\&\-malign\-int  \-mstrict\-align  \-msep\-data  \-mno\-sep\-data 
+\&\-mshared\-library\-id=n  \-mid\-shared\-library  \-mno\-id\-shared\-library 
+\&\-mxgot \-mno\-xgot\fR
+.Sp
+\&\fIMCore Options\fR
+\&\fB\-mhardlit  \-mno\-hardlit  \-mdiv  \-mno\-div  \-mrelax\-immediates 
+\&\-mno\-relax\-immediates  \-mwide\-bitfields  \-mno\-wide\-bitfields 
+\&\-m4byte\-functions  \-mno\-4byte\-functions  \-mcallgraph\-data 
+\&\-mno\-callgraph\-data  \-mslow\-bytes  \-mno\-slow\-bytes  \-mno\-lsim 
+\&\-mlittle\-endian  \-mbig\-endian  \-m210  \-m340  \-mstack\-increment\fR
+.Sp
+\&\fIMeP Options\fR
+\&\fB\-mabsdiff \-mall\-opts \-maverage \-mbased=\fR\fIn\fR \fB\-mbitops 
+\&\-mc=\fR\fIn\fR \fB\-mclip \-mconfig=\fR\fIname\fR \fB\-mcop \-mcop32 \-mcop64 \-mivc2 
+\&\-mdc \-mdiv \-meb \-mel \-mio\-volatile \-ml \-mleadz \-mm \-mminmax 
+\&\-mmult \-mno\-opts \-mrepeat \-ms \-msatur \-msdram \-msim \-msimnovec \-mtf 
+\&\-mtiny=\fR\fIn\fR
+.Sp
+\&\fIMicroBlaze Options\fR
+\&\fB\-msoft\-float \-mhard\-float \-msmall\-divides \-mcpu=\fR\fIcpu\fR 
+\&\fB\-mmemcpy \-mxl\-soft\-mul \-mxl\-soft\-div \-mxl\-barrel\-shift 
+\&\-mxl\-pattern\-compare \-mxl\-stack\-check \-mxl\-gp\-opt \-mno\-clearbss 
+\&\-mxl\-multiply\-high \-mxl\-float\-convert \-mxl\-float\-sqrt 
+\&\-mbig\-endian \-mlittle\-endian \-mxl\-reorder \-mxl\-mode\-\fR\fIapp-model\fR
+.Sp
+\&\fI\s-1MIPS\s0 Options\fR
+\&\fB\-EL  \-EB  \-march=\fR\fIarch\fR  \fB\-mtune=\fR\fIarch\fR 
+\&\fB\-mips1  \-mips2  \-mips3  \-mips4  \-mips32  \-mips32r2 
+\&\-mips64  \-mips64r2 
+\&\-mips16  \-mno\-mips16  \-mflip\-mips16 
+\&\-minterlink\-compressed \-mno\-interlink\-compressed 
+\&\-minterlink\-mips16  \-mno\-interlink\-mips16 
+\&\-mabi=\fR\fIabi\fR  \fB\-mabicalls  \-mno\-abicalls 
+\&\-mshared  \-mno\-shared  \-mplt  \-mno\-plt  \-mxgot  \-mno\-xgot 
+\&\-mgp32  \-mgp64  \-mfp32  \-mfp64  \-mhard\-float  \-msoft\-float 
+\&\-mno\-float  \-msingle\-float  \-mdouble\-float 
+\&\-mabs=\fR\fImode\fR  \fB\-mnan=\fR\fIencoding\fR 
+\&\fB\-mdsp  \-mno\-dsp  \-mdspr2  \-mno\-dspr2 
+\&\-mmcu \-mmno\-mcu 
+\&\-meva \-mno\-eva 
+\&\-mvirt \-mno\-virt 
+\&\-mmicromips \-mno\-micromips 
+\&\-mfpu=\fR\fIfpu-type\fR 
+\&\fB\-msmartmips  \-mno\-smartmips 
+\&\-mpaired\-single  \-mno\-paired\-single  \-mdmx  \-mno\-mdmx 
+\&\-mips3d  \-mno\-mips3d  \-mmt  \-mno\-mt  \-mllsc  \-mno\-llsc 
+\&\-mlong64  \-mlong32  \-msym32  \-mno\-sym32 
+\&\-G\fR\fInum\fR  \fB\-mlocal\-sdata  \-mno\-local\-sdata 
+\&\-mextern\-sdata  \-mno\-extern\-sdata  \-mgpopt  \-mno\-gopt 
+\&\-membedded\-data  \-mno\-embedded\-data 
+\&\-muninit\-const\-in\-rodata  \-mno\-uninit\-const\-in\-rodata 
+\&\-mcode\-readable=\fR\fIsetting\fR 
+\&\fB\-msplit\-addresses  \-mno\-split\-addresses 
+\&\-mexplicit\-relocs  \-mno\-explicit\-relocs 
+\&\-mcheck\-zero\-division  \-mno\-check\-zero\-division 
+\&\-mdivide\-traps  \-mdivide\-breaks 
+\&\-mmemcpy  \-mno\-memcpy  \-mlong\-calls  \-mno\-long\-calls 
+\&\-mmad \-mno\-mad \-mimadd \-mno\-imadd \-mfused\-madd  \-mno\-fused\-madd  \-nocpp 
+\&\-mfix\-24k \-mno\-fix\-24k 
+\&\-mfix\-r4000  \-mno\-fix\-r4000  \-mfix\-r4400  \-mno\-fix\-r4400 
+\&\-mfix\-r10000 \-mno\-fix\-r10000  \-mfix\-rm7000 \-mno\-fix\-rm7000 
+\&\-mfix\-vr4120  \-mno\-fix\-vr4120 
+\&\-mfix\-vr4130  \-mno\-fix\-vr4130  \-mfix\-sb1  \-mno\-fix\-sb1 
+\&\-mflush\-func=\fR\fIfunc\fR  \fB\-mno\-flush\-func 
+\&\-mbranch\-cost=\fR\fInum\fR  \fB\-mbranch\-likely  \-mno\-branch\-likely 
+\&\-mfp\-exceptions \-mno\-fp\-exceptions 
+\&\-mvr4130\-align \-mno\-vr4130\-align \-msynci \-mno\-synci 
+\&\-mrelax\-pic\-calls \-mno\-relax\-pic\-calls \-mmcount\-ra\-address\fR
+.Sp
+\&\fI\s-1MMIX\s0 Options\fR
+\&\fB\-mlibfuncs  \-mno\-libfuncs  \-mepsilon  \-mno\-epsilon  \-mabi=gnu 
+\&\-mabi=mmixware  \-mzero\-extend  \-mknuthdiv  \-mtoplevel\-symbols 
+\&\-melf  \-mbranch\-predict  \-mno\-branch\-predict  \-mbase\-addresses 
+\&\-mno\-base\-addresses  \-msingle\-exit  \-mno\-single\-exit\fR
+.Sp
+\&\fI\s-1MN10300\s0 Options\fR
+\&\fB\-mmult\-bug  \-mno\-mult\-bug 
+\&\-mno\-am33 \-mam33 \-mam33\-2 \-mam34 
+\&\-mtune=\fR\fIcpu-type\fR 
+\&\fB\-mreturn\-pointer\-on\-d0 
+\&\-mno\-crt0  \-mrelax \-mliw \-msetlb\fR
+.Sp
+\&\fIMoxie Options\fR
+\&\fB\-meb \-mel \-mno\-crt0\fR
+.Sp
+\&\fI\s-1MSP430\s0 Options\fR
+\&\fB\-msim \-masm\-hex \-mmcu= \-mcpu= \-mlarge \-msmall \-mrelax\fR
+.Sp
+\&\fI\s-1NDS32\s0 Options\fR
+\&\fB\-mbig\-endian \-mlittle\-endian 
+\&\-mreduced\-regs \-mfull\-regs 
+\&\-mcmov \-mno\-cmov 
+\&\-mperf\-ext \-mno\-perf\-ext 
+\&\-mv3push \-mno\-v3push 
+\&\-m16bit \-mno\-16bit 
+\&\-mgp\-direct \-mno\-gp\-direct 
+\&\-misr\-vector\-size=\fR\fInum\fR 
+\&\fB\-mcache\-block\-size=\fR\fInum\fR 
+\&\fB\-march=\fR\fIarch\fR 
+\&\fB\-mforce\-fp\-as\-gp \-mforbid\-fp\-as\-gp 
+\&\-mex9 \-mctor\-dtor \-mrelax\fR
+.Sp
+\&\fINios \s-1II\s0 Options\fR
+\&\fB\-G\fR \fInum\fR \fB\-mgpopt \-mno\-gpopt \-mel \-meb 
+\&\-mno\-bypass\-cache \-mbypass\-cache 
+\&\-mno\-cache\-volatile \-mcache\-volatile 
+\&\-mno\-fast\-sw\-div \-mfast\-sw\-div 
+\&\-mhw\-mul \-mno\-hw\-mul \-mhw\-mulx \-mno\-hw\-mulx \-mno\-hw\-div \-mhw\-div 
+\&\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR \fB\-mno\-custom\-\fR\fIinsn\fR 
+\&\fB\-mcustom\-fpu\-cfg=\fR\fIname\fR 
+\&\fB\-mhal \-msmallc \-msys\-crt0=\fR\fIname\fR \fB\-msys\-lib=\fR\fIname\fR
+.Sp
+\&\fI\s-1PDP\-11\s0 Options\fR
+\&\fB\-mfpu  \-msoft\-float  \-mac0  \-mno\-ac0  \-m40  \-m45  \-m10 
+\&\-mbcopy  \-mbcopy\-builtin  \-mint32  \-mno\-int16 
+\&\-mint16  \-mno\-int32  \-mfloat32  \-mno\-float64 
+\&\-mfloat64  \-mno\-float32  \-mabshi  \-mno\-abshi 
+\&\-mbranch\-expensive  \-mbranch\-cheap 
+\&\-munix\-asm  \-mdec\-asm\fR
+.Sp
+\&\fIpicoChip Options\fR
+\&\fB\-mae=\fR\fIae_type\fR \fB\-mvliw\-lookahead=\fR\fIN\fR 
+\&\fB\-msymbol\-as\-address \-mno\-inefficient\-warnings\fR
+.Sp
+\&\fIPowerPC Options\fR
+See \s-1RS/6000\s0 and PowerPC Options.
+.Sp
+\&\fI\s-1RL78\s0 Options\fR
+\&\fB\-msim \-mmul=none \-mmul=g13 \-mmul=rl78\fR
+.Sp
+\&\fI\s-1RS/6000\s0 and PowerPC Options\fR
+\&\fB\-mcpu=\fR\fIcpu-type\fR 
+\&\fB\-mtune=\fR\fIcpu-type\fR 
+\&\fB\-mcmodel=\fR\fIcode-model\fR 
+\&\fB\-mpowerpc64 
+\&\-maltivec  \-mno\-altivec 
+\&\-mpowerpc\-gpopt  \-mno\-powerpc\-gpopt 
+\&\-mpowerpc\-gfxopt  \-mno\-powerpc\-gfxopt 
+\&\-mmfcrf  \-mno\-mfcrf  \-mpopcntb  \-mno\-popcntb \-mpopcntd \-mno\-popcntd 
+\&\-mfprnd  \-mno\-fprnd 
+\&\-mcmpb \-mno\-cmpb \-mmfpgpr \-mno\-mfpgpr \-mhard\-dfp \-mno\-hard\-dfp 
+\&\-mfull\-toc   \-mminimal\-toc  \-mno\-fp\-in\-toc  \-mno\-sum\-in\-toc 
+\&\-m64  \-m32  \-mxl\-compat  \-mno\-xl\-compat  \-mpe 
+\&\-malign\-power  \-malign\-natural 
+\&\-msoft\-float  \-mhard\-float  \-mmultiple  \-mno\-multiple 
+\&\-msingle\-float \-mdouble\-float \-msimple\-fpu 
+\&\-mstring  \-mno\-string  \-mupdate  \-mno\-update 
+\&\-mavoid\-indexed\-addresses  \-mno\-avoid\-indexed\-addresses 
+\&\-mfused\-madd  \-mno\-fused\-madd  \-mbit\-align  \-mno\-bit\-align 
+\&\-mstrict\-align  \-mno\-strict\-align  \-mrelocatable 
+\&\-mno\-relocatable  \-mrelocatable\-lib  \-mno\-relocatable\-lib 
+\&\-mtoc  \-mno\-toc  \-mlittle  \-mlittle\-endian  \-mbig  \-mbig\-endian 
+\&\-mdynamic\-no\-pic  \-maltivec \-mswdiv  \-msingle\-pic\-base 
+\&\-mprioritize\-restricted\-insns=\fR\fIpriority\fR 
+\&\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR 
+\&\fB\-minsert\-sched\-nops=\fR\fIscheme\fR 
+\&\fB\-mcall\-sysv  \-mcall\-netbsd 
+\&\-maix\-struct\-return  \-msvr4\-struct\-return 
+\&\-mabi=\fR\fIabi-type\fR \fB\-msecure\-plt \-mbss\-plt 
+\&\-mblock\-move\-inline\-limit=\fR\fInum\fR 
+\&\fB\-misel \-mno\-isel 
+\&\-misel=yes  \-misel=no 
+\&\-mspe \-mno\-spe 
+\&\-mspe=yes  \-mspe=no 
+\&\-mpaired 
+\&\-mgen\-cell\-microcode \-mwarn\-cell\-microcode 
+\&\-mvrsave \-mno\-vrsave 
+\&\-mmulhw \-mno\-mulhw 
+\&\-mdlmzb \-mno\-dlmzb 
+\&\-mfloat\-gprs=yes  \-mfloat\-gprs=no \-mfloat\-gprs=single \-mfloat\-gprs=double 
+\&\-mprototype  \-mno\-prototype 
+\&\-msim  \-mmvme  \-mads  \-myellowknife  \-memb  \-msdata 
+\&\-msdata=\fR\fIopt\fR  \fB\-mvxworks  \-G\fR \fInum\fR  \fB\-pthread 
+\&\-mrecip \-mrecip=\fR\fIopt\fR \fB\-mno\-recip \-mrecip\-precision 
+\&\-mno\-recip\-precision 
+\&\-mveclibabi=\fR\fItype\fR \fB\-mfriz \-mno\-friz 
+\&\-mpointers\-to\-nested\-functions \-mno\-pointers\-to\-nested\-functions 
+\&\-msave\-toc\-indirect \-mno\-save\-toc\-indirect 
+\&\-mpower8\-fusion \-mno\-mpower8\-fusion \-mpower8\-vector \-mno\-power8\-vector 
+\&\-mcrypto \-mno\-crypto \-mdirect\-move \-mno\-direct\-move 
+\&\-mquad\-memory \-mno\-quad\-memory 
+\&\-mquad\-memory\-atomic \-mno\-quad\-memory\-atomic 
+\&\-mcompat\-align\-parm \-mno\-compat\-align\-parm\fR
+.Sp
+\&\fI\s-1RX\s0 Options\fR
+\&\fB\-m64bit\-doubles  \-m32bit\-doubles  \-fpu  \-nofpu
+\&\-mcpu=
+\&\-mbig\-endian\-data \-mlittle\-endian\-data 
+\&\-msmall\-data 
+\&\-msim  \-mno\-sim
+\&\-mas100\-syntax \-mno\-as100\-syntax
+\&\-mrelax
+\&\-mmax\-constant\-size=
+\&\-mint\-register=
+\&\-mpid
+\&\-mno\-warn\-multiple\-fast\-interrupts
+\&\-msave\-acc\-in\-interrupts\fR
+.Sp
+\&\fIS/390 and zSeries Options\fR
+\&\fB\-mtune=\fR\fIcpu-type\fR  \fB\-march=\fR\fIcpu-type\fR 
+\&\fB\-mhard\-float  \-msoft\-float  \-mhard\-dfp \-mno\-hard\-dfp 
+\&\-mlong\-double\-64 \-mlong\-double\-128 
+\&\-mbackchain  \-mno\-backchain \-mpacked\-stack  \-mno\-packed\-stack 
+\&\-msmall\-exec  \-mno\-small\-exec  \-mmvcle \-mno\-mvcle 
+\&\-m64  \-m31  \-mdebug  \-mno\-debug  \-mesa  \-mzarch 
+\&\-mtpf\-trace \-mno\-tpf\-trace  \-mfused\-madd  \-mno\-fused\-madd 
+\&\-mwarn\-framesize  \-mwarn\-dynamicstack  \-mstack\-size \-mstack\-guard 
+\&\-mhotpatch[=\fR\fIhalfwords\fR\fB] \-mno\-hotpatch\fR
+.Sp
+\&\fIScore Options\fR
+\&\fB\-meb \-mel 
+\&\-mnhwloop 
+\&\-muls 
+\&\-mmac 
+\&\-mscore5 \-mscore5u \-mscore7 \-mscore7d\fR
+.Sp
+\&\fI\s-1SH\s0 Options\fR
+\&\fB\-m1  \-m2  \-m2e 
+\&\-m2a\-nofpu \-m2a\-single\-only \-m2a\-single \-m2a 
+\&\-m3  \-m3e 
+\&\-m4\-nofpu  \-m4\-single\-only  \-m4\-single  \-m4 
+\&\-m4a\-nofpu \-m4a\-single\-only \-m4a\-single \-m4a \-m4al 
+\&\-m5\-64media  \-m5\-64media\-nofpu 
+\&\-m5\-32media  \-m5\-32media\-nofpu 
+\&\-m5\-compact  \-m5\-compact\-nofpu 
+\&\-mb  \-ml  \-mdalign  \-mrelax 
+\&\-mbigtable \-mfmovd \-mhitachi \-mrenesas \-mno\-renesas \-mnomacsave 
+\&\-mieee \-mno\-ieee \-mbitops  \-misize  \-minline\-ic_invalidate \-mpadstruct 
+\&\-mspace \-mprefergot  \-musermode \-multcost=\fR\fInumber\fR \fB\-mdiv=\fR\fIstrategy\fR 
+\&\fB\-mdivsi3_libfunc=\fR\fIname\fR \fB\-mfixed\-range=\fR\fIregister-range\fR 
+\&\fB\-mindexed\-addressing \-mgettrcost=\fR\fInumber\fR \fB\-mpt\-fixed 
+\&\-maccumulate\-outgoing\-args \-minvalid\-symbols 
+\&\-matomic\-model=\fR\fIatomic-model\fR 
+\&\fB\-mbranch\-cost=\fR\fInum\fR \fB\-mzdcbranch \-mno\-zdcbranch 
+\&\-mfused\-madd \-mno\-fused\-madd \-mfsca \-mno\-fsca \-mfsrra \-mno\-fsrra 
+\&\-mpretend\-cmove \-mtas\fR
+.Sp
+\&\fISolaris 2 Options\fR
+\&\fB\-mimpure\-text  \-mno\-impure\-text 
+\&\-pthreads \-pthread\fR
+.Sp
+\&\fI\s-1SPARC\s0 Options\fR
+\&\fB\-mcpu=\fR\fIcpu-type\fR 
+\&\fB\-mtune=\fR\fIcpu-type\fR 
+\&\fB\-mcmodel=\fR\fIcode-model\fR 
+\&\fB\-mmemory\-model=\fR\fImem-model\fR 
+\&\fB\-m32  \-m64  \-mapp\-regs  \-mno\-app\-regs 
+\&\-mfaster\-structs  \-mno\-faster\-structs  \-mflat  \-mno\-flat 
+\&\-mfpu  \-mno\-fpu  \-mhard\-float  \-msoft\-float 
+\&\-mhard\-quad\-float  \-msoft\-quad\-float 
+\&\-mstack\-bias  \-mno\-stack\-bias 
+\&\-munaligned\-doubles  \-mno\-unaligned\-doubles 
+\&\-mv8plus  \-mno\-v8plus  \-mvis  \-mno\-vis 
+\&\-mvis2  \-mno\-vis2  \-mvis3  \-mno\-vis3 
+\&\-mcbcond \-mno\-cbcond 
+\&\-mfmaf  \-mno\-fmaf  \-mpopc  \-mno\-popc 
+\&\-mfix\-at697f \-mfix\-ut699\fR
+.Sp
+\&\fI\s-1SPU\s0 Options\fR
+\&\fB\-mwarn\-reloc \-merror\-reloc 
+\&\-msafe\-dma \-munsafe\-dma 
+\&\-mbranch\-hints 
+\&\-msmall\-mem \-mlarge\-mem \-mstdmain 
+\&\-mfixed\-range=\fR\fIregister-range\fR 
+\&\fB\-mea32 \-mea64 
+\&\-maddress\-space\-conversion \-mno\-address\-space\-conversion 
+\&\-mcache\-size=\fR\fIcache-size\fR 
+\&\fB\-matomic\-updates \-mno\-atomic\-updates\fR
+.Sp
+\&\fISystem V Options\fR
+\&\fB\-Qy  \-Qn  \-YP,\fR\fIpaths\fR  \fB\-Ym,\fR\fIdir\fR
+.Sp
+\&\fITILE-Gx Options\fR
+\&\fB\-mcpu=CPU \-m32 \-m64 \-mbig\-endian \-mlittle\-endian 
+\&\-mcmodel=\fR\fIcode-model\fR
+.Sp
+\&\fITILEPro Options\fR
+\&\fB\-mcpu=\fR\fIcpu\fR \fB\-m32\fR
+.Sp
+\&\fIV850 Options\fR
+\&\fB\-mlong\-calls  \-mno\-long\-calls  \-mep  \-mno\-ep 
+\&\-mprolog\-function  \-mno\-prolog\-function  \-mspace 
+\&\-mtda=\fR\fIn\fR  \fB\-msda=\fR\fIn\fR  \fB\-mzda=\fR\fIn\fR 
+\&\fB\-mapp\-regs  \-mno\-app\-regs 
+\&\-mdisable\-callt  \-mno\-disable\-callt 
+\&\-mv850e2v3 \-mv850e2 \-mv850e1 \-mv850es 
+\&\-mv850e \-mv850 \-mv850e3v5 
+\&\-mloop 
+\&\-mrelax 
+\&\-mlong\-jumps 
+\&\-msoft\-float 
+\&\-mhard\-float 
+\&\-mgcc\-abi 
+\&\-mrh850\-abi 
+\&\-mbig\-switch\fR
+.Sp
+\&\fI\s-1VAX\s0 Options\fR
+\&\fB\-mg  \-mgnu  \-munix\fR
+.Sp
+\&\fI\s-1VMS\s0 Options\fR
+\&\fB\-mvms\-return\-codes \-mdebug\-main=\fR\fIprefix\fR \fB\-mmalloc64 
+\&\-mpointer\-size=\fR\fIsize\fR
+.Sp
+\&\fIVxWorks Options\fR
+\&\fB\-mrtp  \-non\-static  \-Bstatic  \-Bdynamic 
+\&\-Xbind\-lazy  \-Xbind\-now\fR
+.Sp
+\&\fIx86\-64 Options\fR
+See i386 and x86\-64 Options.
+.Sp
+\&\fIXstormy16 Options\fR
+\&\fB\-msim\fR
+.Sp
+\&\fIXtensa Options\fR
+\&\fB\-mconst16 \-mno\-const16 
+\&\-mfused\-madd  \-mno\-fused\-madd 
+\&\-mforce\-no\-pic 
+\&\-mserialize\-volatile  \-mno\-serialize\-volatile 
+\&\-mtext\-section\-literals  \-mno\-text\-section\-literals 
+\&\-mtarget\-align  \-mno\-target\-align 
+\&\-mlongcalls  \-mno\-longcalls\fR
+.Sp
+\&\fIzSeries Options\fR
+See S/390 and zSeries Options.
+.IP "\fICode Generation Options\fR" 4
+.IX Item "Code Generation Options"
+\&\fB\-fcall\-saved\-\fR\fIreg\fR  \fB\-fcall\-used\-\fR\fIreg\fR 
+\&\fB\-ffixed\-\fR\fIreg\fR  \fB\-fexceptions 
+\&\-fnon\-call\-exceptions  \-fdelete\-dead\-exceptions  \-funwind\-tables 
+\&\-fasynchronous\-unwind\-tables 
+\&\-fno\-gnu\-unique 
+\&\-finhibit\-size\-directive  \-finstrument\-functions 
+\&\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,... 
+\&\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,... 
+\&\-fno\-common  \-fno\-ident 
+\&\-fpcc\-struct\-return  \-fpic  \-fPIC \-fpie \-fPIE 
+\&\-fno\-jump\-tables 
+\&\-frecord\-gcc\-switches 
+\&\-freg\-struct\-return  \-fshort\-enums 
+\&\-fshort\-double  \-fshort\-wchar 
+\&\-fverbose\-asm  \-fpack\-struct[=\fR\fIn\fR\fB]  \-fstack\-check 
+\&\-fstack\-limit\-register=\fR\fIreg\fR  \fB\-fstack\-limit\-symbol=\fR\fIsym\fR 
+\&\fB\-fno\-stack\-limit \-fsplit\-stack 
+\&\-fleading\-underscore  \-ftls\-model=\fR\fImodel\fR 
+\&\fB\-fstack\-reuse=\fR\fIreuse_level\fR 
+\&\fB\-ftrapv  \-fwrapv  \-fbounds\-check 
+\&\-fvisibility \-fstrict\-volatile\-bitfields \-fsync\-libcalls\fR
+.SS "Options Controlling the Kind of Output"
+.IX Subsection "Options Controlling the Kind of Output"
+Compilation can involve up to four stages: preprocessing, compilation
+proper, assembly and linking, always in that order.  \s-1GCC\s0 is capable of
+preprocessing and compiling several files either into several
+assembler input files, or into one assembler input file; then each
+assembler input file produces an object file, and linking combines all
+the object files (those newly compiled, and those specified as input)
+into an executable file.
+.PP
+For any given input file, the file name suffix determines what kind of
+compilation is done:
+.IP "\fIfile\fR\fB.c\fR" 4
+.IX Item "file.c"
+C source code that must be preprocessed.
+.IP "\fIfile\fR\fB.i\fR" 4
+.IX Item "file.i"
+C source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.ii\fR" 4
+.IX Item "file.ii"
+\&\*(C+ source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.m\fR" 4
+.IX Item "file.m"
+Objective-C source code.  Note that you must link with the \fIlibobjc\fR
+library to make an Objective-C program work.
+.IP "\fIfile\fR\fB.mi\fR" 4
+.IX Item "file.mi"
+Objective-C source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.mm\fR" 4
+.IX Item "file.mm"
+.PD 0
+.IP "\fIfile\fR\fB.M\fR" 4
+.IX Item "file.M"
+.PD
+Objective\-\*(C+ source code.  Note that you must link with the \fIlibobjc\fR
+library to make an Objective\-\*(C+ program work.  Note that \fB.M\fR refers
+to a literal capital M.
+.IP "\fIfile\fR\fB.mii\fR" 4
+.IX Item "file.mii"
+Objective\-\*(C+ source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.h\fR" 4
+.IX Item "file.h"
+C, \*(C+, Objective-C or Objective\-\*(C+ header file to be turned into a
+precompiled header (default), or C, \*(C+ header file to be turned into an
+Ada spec (via the \fB\-fdump\-ada\-spec\fR switch).
+.IP "\fIfile\fR\fB.cc\fR" 4
+.IX Item "file.cc"
+.PD 0
+.IP "\fIfile\fR\fB.cp\fR" 4
+.IX Item "file.cp"
+.IP "\fIfile\fR\fB.cxx\fR" 4
+.IX Item "file.cxx"
+.IP "\fIfile\fR\fB.cpp\fR" 4
+.IX Item "file.cpp"
+.IP "\fIfile\fR\fB.CPP\fR" 4
+.IX Item "file.CPP"
+.IP "\fIfile\fR\fB.c++\fR" 4
+.IX Item "file.c++"
+.IP "\fIfile\fR\fB.C\fR" 4
+.IX Item "file.C"
+.PD
+\&\*(C+ source code that must be preprocessed.  Note that in \fB.cxx\fR,
+the last two letters must both be literally \fBx\fR.  Likewise,
+\&\fB.C\fR refers to a literal capital C.
+.IP "\fIfile\fR\fB.mm\fR" 4
+.IX Item "file.mm"
+.PD 0
+.IP "\fIfile\fR\fB.M\fR" 4
+.IX Item "file.M"
+.PD
+Objective\-\*(C+ source code that must be preprocessed.
+.IP "\fIfile\fR\fB.mii\fR" 4
+.IX Item "file.mii"
+Objective\-\*(C+ source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.hh\fR" 4
+.IX Item "file.hh"
+.PD 0
+.IP "\fIfile\fR\fB.H\fR" 4
+.IX Item "file.H"
+.IP "\fIfile\fR\fB.hp\fR" 4
+.IX Item "file.hp"
+.IP "\fIfile\fR\fB.hxx\fR" 4
+.IX Item "file.hxx"
+.IP "\fIfile\fR\fB.hpp\fR" 4
+.IX Item "file.hpp"
+.IP "\fIfile\fR\fB.HPP\fR" 4
+.IX Item "file.HPP"
+.IP "\fIfile\fR\fB.h++\fR" 4
+.IX Item "file.h++"
+.IP "\fIfile\fR\fB.tcc\fR" 4
+.IX Item "file.tcc"
+.PD
+\&\*(C+ header file to be turned into a precompiled header or Ada spec.
+.IP "\fIfile\fR\fB.f\fR" 4
+.IX Item "file.f"
+.PD 0
+.IP "\fIfile\fR\fB.for\fR" 4
+.IX Item "file.for"
+.IP "\fIfile\fR\fB.ftn\fR" 4
+.IX Item "file.ftn"
+.PD
+Fixed form Fortran source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.F\fR" 4
+.IX Item "file.F"
+.PD 0
+.IP "\fIfile\fR\fB.FOR\fR" 4
+.IX Item "file.FOR"
+.IP "\fIfile\fR\fB.fpp\fR" 4
+.IX Item "file.fpp"
+.IP "\fIfile\fR\fB.FPP\fR" 4
+.IX Item "file.FPP"
+.IP "\fIfile\fR\fB.FTN\fR" 4
+.IX Item "file.FTN"
+.PD
+Fixed form Fortran source code that must be preprocessed (with the traditional
+preprocessor).
+.IP "\fIfile\fR\fB.f90\fR" 4
+.IX Item "file.f90"
+.PD 0
+.IP "\fIfile\fR\fB.f95\fR" 4
+.IX Item "file.f95"
+.IP "\fIfile\fR\fB.f03\fR" 4
+.IX Item "file.f03"
+.IP "\fIfile\fR\fB.f08\fR" 4
+.IX Item "file.f08"
+.PD
+Free form Fortran source code that should not be preprocessed.
+.IP "\fIfile\fR\fB.F90\fR" 4
+.IX Item "file.F90"
+.PD 0
+.IP "\fIfile\fR\fB.F95\fR" 4
+.IX Item "file.F95"
+.IP "\fIfile\fR\fB.F03\fR" 4
+.IX Item "file.F03"
+.IP "\fIfile\fR\fB.F08\fR" 4
+.IX Item "file.F08"
+.PD
+Free form Fortran source code that must be preprocessed (with the
+traditional preprocessor).
+.IP "\fIfile\fR\fB.go\fR" 4
+.IX Item "file.go"
+Go source code.
+.IP "\fIfile\fR\fB.ads\fR" 4
+.IX Item "file.ads"
+Ada source code file that contains a library unit declaration (a
+declaration of a package, subprogram, or generic, or a generic
+instantiation), or a library unit renaming declaration (a package,
+generic, or subprogram renaming declaration).  Such files are also
+called \fIspecs\fR.
+.IP "\fIfile\fR\fB.adb\fR" 4
+.IX Item "file.adb"
+Ada source code file containing a library unit body (a subprogram or
+package body).  Such files are also called \fIbodies\fR.
+.IP "\fIfile\fR\fB.s\fR" 4
+.IX Item "file.s"
+Assembler code.
+.IP "\fIfile\fR\fB.S\fR" 4
+.IX Item "file.S"
+.PD 0
+.IP "\fIfile\fR\fB.sx\fR" 4
+.IX Item "file.sx"
+.PD
+Assembler code that must be preprocessed.
+.IP "\fIother\fR" 4
+.IX Item "other"
+An object file to be fed straight into linking.
+Any file name with no recognized suffix is treated this way.
+.PP
+You can specify the input language explicitly with the \fB\-x\fR option:
+.IP "\fB\-x\fR \fIlanguage\fR" 4
+.IX Item "-x language"
+Specify explicitly the \fIlanguage\fR for the following input files
+(rather than letting the compiler choose a default based on the file
+name suffix).  This option applies to all following input files until
+the next \fB\-x\fR option.  Possible values for \fIlanguage\fR are:
+.Sp
+.Vb 9
+\&        c  c\-header  cpp\-output
+\&        c++  c++\-header  c++\-cpp\-output
+\&        objective\-c  objective\-c\-header  objective\-c\-cpp\-output
+\&        objective\-c++ objective\-c++\-header objective\-c++\-cpp\-output
+\&        assembler  assembler\-with\-cpp
+\&        ada
+\&        f77  f77\-cpp\-input f95  f95\-cpp\-input
+\&        go
+\&        java
+.Ve
+.IP "\fB\-x none\fR" 4
+.IX Item "-x none"
+Turn off any specification of a language, so that subsequent files are
+handled according to their file name suffixes (as they are if \fB\-x\fR
+has not been used at all).
+.IP "\fB\-pass\-exit\-codes\fR" 4
+.IX Item "-pass-exit-codes"
+Normally the \fBgcc\fR program exits with the code of 1 if any
+phase of the compiler returns a non-success return code.  If you specify
+\&\fB\-pass\-exit\-codes\fR, the \fBgcc\fR program instead returns with
+the numerically highest error produced by any phase returning an error
+indication.  The C, \*(C+, and Fortran front ends return 4 if an internal
+compiler error is encountered.
+.PP
+If you only want some of the stages of compilation, you can use
+\&\fB\-x\fR (or filename suffixes) to tell \fBgcc\fR where to start, and
+one of the options \fB\-c\fR, \fB\-S\fR, or \fB\-E\fR to say where
+\&\fBgcc\fR is to stop.  Note that some combinations (for example,
+\&\fB\-x cpp-output \-E\fR) instruct \fBgcc\fR to do nothing at all.
+.IP "\fB\-c\fR" 4
+.IX Item "-c"
+Compile or assemble the source files, but do not link.  The linking
+stage simply is not done.  The ultimate output is in the form of an
+object file for each source file.
+.Sp
+By default, the object file name for a source file is made by replacing
+the suffix \fB.c\fR, \fB.i\fR, \fB.s\fR, etc., with \fB.o\fR.
+.Sp
+Unrecognized input files, not requiring compilation or assembly, are
+ignored.
+.IP "\fB\-S\fR" 4
+.IX Item "-S"
+Stop after the stage of compilation proper; do not assemble.  The output
+is in the form of an assembler code file for each non-assembler input
+file specified.
+.Sp
+By default, the assembler file name for a source file is made by
+replacing the suffix \fB.c\fR, \fB.i\fR, etc., with \fB.s\fR.
+.Sp
+Input files that don't require compilation are ignored.
+.IP "\fB\-E\fR" 4
+.IX Item "-E"
+Stop after the preprocessing stage; do not run the compiler proper.  The
+output is in the form of preprocessed source code, which is sent to the
+standard output.
+.Sp
+Input files that don't require preprocessing are ignored.
+.IP "\fB\-o\fR \fIfile\fR" 4
+.IX Item "-o file"
+Place output in file \fIfile\fR.  This applies to whatever
+sort of output is being produced, whether it be an executable file,
+an object file, an assembler file or preprocessed C code.
+.Sp
+If \fB\-o\fR is not specified, the default is to put an executable
+file in \fIa.out\fR, the object file for
+\&\fI\fIsource\fI.\fIsuffix\fI\fR in \fI\fIsource\fI.o\fR, its
+assembler file in \fI\fIsource\fI.s\fR, a precompiled header file in
+\&\fI\fIsource\fI.\fIsuffix\fI.gch\fR, and all preprocessed C source on
+standard output.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+Print (on standard error output) the commands executed to run the stages
+of compilation.  Also print the version number of the compiler driver
+program and of the preprocessor and the compiler proper.
+.IP "\fB\-###\fR" 4
+.IX Item "-###"
+Like \fB\-v\fR except the commands are not executed and arguments
+are quoted unless they contain only alphanumeric characters or \f(CW\*(C`./\-_\*(C'\fR.
+This is useful for shell scripts to capture the driver-generated command lines.
+.IP "\fB\-pipe\fR" 4
+.IX Item "-pipe"
+Use pipes rather than temporary files for communication between the
+various stages of compilation.  This fails to work on some systems where
+the assembler is unable to read from a pipe; but the \s-1GNU\s0 assembler has
+no trouble.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+Print (on the standard output) a description of the command-line options
+understood by \fBgcc\fR.  If the \fB\-v\fR option is also specified
+then \fB\-\-help\fR is also passed on to the various processes
+invoked by \fBgcc\fR, so that they can display the command-line options
+they accept.  If the \fB\-Wextra\fR option has also been specified
+(prior to the \fB\-\-help\fR option), then command-line options that
+have no documentation associated with them are also displayed.
+.IP "\fB\-\-target\-help\fR" 4
+.IX Item "--target-help"
+Print (on the standard output) a description of target-specific command-line
+options for each tool.  For some targets extra target-specific
+information may also be printed.
+.IP "\fB\-\-help={\fR\fIclass\fR|[\fB^\fR]\fIqualifier\fR\fB}\fR[\fB,...\fR]" 4
+.IX Item "--help={class|[^]qualifier}[,...]"
+Print (on the standard output) a description of the command-line
+options understood by the compiler that fit into all specified classes
+and qualifiers.  These are the supported classes:
+.RS 4
+.IP "\fBoptimizers\fR" 4
+.IX Item "optimizers"
+Display all of the optimization options supported by the
+compiler.
+.IP "\fBwarnings\fR" 4
+.IX Item "warnings"
+Display all of the options controlling warning messages
+produced by the compiler.
+.IP "\fBtarget\fR" 4
+.IX Item "target"
+Display target-specific options.  Unlike the
+\&\fB\-\-target\-help\fR option however, target-specific options of the
+linker and assembler are not displayed.  This is because those
+tools do not currently support the extended \fB\-\-help=\fR syntax.
+.IP "\fBparams\fR" 4
+.IX Item "params"
+Display the values recognized by the \fB\-\-param\fR
+option.
+.IP "\fIlanguage\fR" 4
+.IX Item "language"
+Display the options supported for \fIlanguage\fR, where
+\&\fIlanguage\fR is the name of one of the languages supported in this
+version of \s-1GCC.\s0
+.IP "\fBcommon\fR" 4
+.IX Item "common"
+Display the options that are common to all languages.
+.RE
+.RS 4
+.Sp
+These are the supported qualifiers:
+.IP "\fBundocumented\fR" 4
+.IX Item "undocumented"
+Display only those options that are undocumented.
+.IP "\fBjoined\fR" 4
+.IX Item "joined"
+Display options taking an argument that appears after an equal
+sign in the same continuous piece of text, such as:
+\&\fB\-\-help=target\fR.
+.IP "\fBseparate\fR" 4
+.IX Item "separate"
+Display options taking an argument that appears as a separate word
+following the original option, such as: \fB\-o output-file\fR.
+.RE
+.RS 4
+.Sp
+Thus for example to display all the undocumented target-specific
+switches supported by the compiler, use:
+.Sp
+.Vb 1
+\&        \-\-help=target,undocumented
+.Ve
+.Sp
+The sense of a qualifier can be inverted by prefixing it with the
+\&\fB^\fR character, so for example to display all binary warning
+options (i.e., ones that are either on or off and that do not take an
+argument) that have a description, use:
+.Sp
+.Vb 1
+\&        \-\-help=warnings,^joined,^undocumented
+.Ve
+.Sp
+The argument to \fB\-\-help=\fR should not consist solely of inverted
+qualifiers.
+.Sp
+Combining several classes is possible, although this usually
+restricts the output so much that there is nothing to display.  One
+case where it does work, however, is when one of the classes is
+\&\fItarget\fR.  For example, to display all the target-specific
+optimization options, use:
+.Sp
+.Vb 1
+\&        \-\-help=target,optimizers
+.Ve
+.Sp
+The \fB\-\-help=\fR option can be repeated on the command line.  Each
+successive use displays its requested class of options, skipping
+those that have already been displayed.
+.Sp
+If the \fB\-Q\fR option appears on the command line before the
+\&\fB\-\-help=\fR option, then the descriptive text displayed by
+\&\fB\-\-help=\fR is changed.  Instead of describing the displayed
+options, an indication is given as to whether the option is enabled,
+disabled or set to a specific value (assuming that the compiler
+knows this at the point where the \fB\-\-help=\fR option is used).
+.Sp
+Here is a truncated example from the \s-1ARM\s0 port of \fBgcc\fR:
+.Sp
+.Vb 5
+\&          % gcc \-Q \-mabi=2 \-\-help=target \-c
+\&          The following options are target specific:
+\&          \-mabi=                                2
+\&          \-mabort\-on\-noreturn                   [disabled]
+\&          \-mapcs                                [disabled]
+.Ve
+.Sp
+The output is sensitive to the effects of previous command-line
+options, so for example it is possible to find out which optimizations
+are enabled at \fB\-O2\fR by using:
+.Sp
+.Vb 1
+\&        \-Q \-O2 \-\-help=optimizers
+.Ve
+.Sp
+Alternatively you can discover which binary optimizations are enabled
+by \fB\-O3\fR by using:
+.Sp
+.Vb 3
+\&        gcc \-c \-Q \-O3 \-\-help=optimizers > /tmp/O3\-opts
+\&        gcc \-c \-Q \-O2 \-\-help=optimizers > /tmp/O2\-opts
+\&        diff /tmp/O2\-opts /tmp/O3\-opts | grep enabled
+.Ve
+.RE
+.IP "\fB\-no\-canonical\-prefixes\fR" 4
+.IX Item "-no-canonical-prefixes"
+Do not expand any symbolic links, resolve references to \fB/../\fR
+or \fB/./\fR, or make the path absolute when generating a relative
+prefix.
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+Display the version number and copyrights of the invoked \s-1GCC.\s0
+.IP "\fB\-wrapper\fR" 4
+.IX Item "-wrapper"
+Invoke all subcommands under a wrapper program.  The name of the
+wrapper program and its parameters are passed as a comma separated
+list.
+.Sp
+.Vb 1
+\&        gcc \-c t.c \-wrapper gdb,\-\-args
+.Ve
+.Sp
+This invokes all subprograms of \fBgcc\fR under
+\&\fBgdb \-\-args\fR, thus the invocation of \fBcc1\fR is
+\&\fBgdb \-\-args cc1 ...\fR.
+.IP "\fB\-fplugin=\fR\fIname\fR\fB.so\fR" 4
+.IX Item "-fplugin=name.so"
+Load the plugin code in file \fIname\fR.so, assumed to be a
+shared object to be dlopen'd by the compiler.  The base name of
+the shared object file is used to identify the plugin for the
+purposes of argument parsing (See
+\&\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR below).
+Each plugin should define the callback functions specified in the
+Plugins \s-1API.\s0
+.IP "\fB\-fplugin\-arg\-\fR\fIname\fR\fB\-\fR\fIkey\fR\fB=\fR\fIvalue\fR" 4
+.IX Item "-fplugin-arg-name-key=value"
+Define an argument called \fIkey\fR with a value of \fIvalue\fR
+for the plugin called \fIname\fR.
+.IP "\fB\-fdump\-ada\-spec\fR[\fB\-slim\fR]" 4
+.IX Item "-fdump-ada-spec[-slim]"
+For C and \*(C+ source and include files, generate corresponding Ada specs.
+.IP "\fB\-fada\-spec\-parent=\fR\fIunit\fR" 4
+.IX Item "-fada-spec-parent=unit"
+In conjunction with \fB\-fdump\-ada\-spec\fR[\fB\-slim\fR] above, generate
+Ada specs as child units of parent \fIunit\fR.
+.IP "\fB\-fdump\-go\-spec=\fR\fIfile\fR" 4
+.IX Item "-fdump-go-spec=file"
+For input files in any language, generate corresponding Go
+declarations in \fIfile\fR.  This generates Go \f(CW\*(C`const\*(C'\fR,
+\&\f(CW\*(C`type\*(C'\fR, \f(CW\*(C`var\*(C'\fR, and \f(CW\*(C`func\*(C'\fR declarations which may be a
+useful way to start writing a Go interface to code written in some
+other language.
+.IP "\fB@\fR\fIfile\fR" 4
+.IX Item "@file"
+Read command-line options from \fIfile\fR.  The options read are
+inserted in place of the original @\fIfile\fR option.  If \fIfile\fR
+does not exist, or cannot be read, then the option will be treated
+literally, and not removed.
+.Sp
+Options in \fIfile\fR are separated by whitespace.  A whitespace
+character may be included in an option by surrounding the entire
+option in either single or double quotes.  Any character (including a
+backslash) may be included by prefixing the character to be included
+with a backslash.  The \fIfile\fR may itself contain additional
+@\fIfile\fR options; any such options will be processed recursively.
+.SS "Compiling \*(C+ Programs"
+.IX Subsection "Compiling Programs"
+\&\*(C+ source files conventionally use one of the suffixes \fB.C\fR,
+\&\fB.cc\fR, \fB.cpp\fR, \fB.CPP\fR, \fB.c++\fR, \fB.cp\fR, or
+\&\fB.cxx\fR; \*(C+ header files often use \fB.hh\fR, \fB.hpp\fR,
+\&\fB.H\fR, or (for shared template code) \fB.tcc\fR; and
+preprocessed \*(C+ files use the suffix \fB.ii\fR.  \s-1GCC\s0 recognizes
+files with these names and compiles them as \*(C+ programs even if you
+call the compiler the same way as for compiling C programs (usually
+with the name \fBgcc\fR).
+.PP
+However, the use of \fBgcc\fR does not add the \*(C+ library.
+\&\fBg++\fR is a program that calls \s-1GCC\s0 and automatically specifies linking
+against the \*(C+ library.  It treats \fB.c\fR,
+\&\fB.h\fR and \fB.i\fR files as \*(C+ source files instead of C source
+files unless \fB\-x\fR is used.  This program is also useful when
+precompiling a C header file with a \fB.h\fR extension for use in \*(C+
+compilations.  On many systems, \fBg++\fR is also installed with
+the name \fBc++\fR.
+.PP
+When you compile \*(C+ programs, you may specify many of the same
+command-line options that you use for compiling programs in any
+language; or command-line options meaningful for C and related
+languages; or options that are meaningful only for \*(C+ programs.
+.SS "Options Controlling C Dialect"
+.IX Subsection "Options Controlling C Dialect"
+The following options control the dialect of C (or languages derived
+from C, such as \*(C+, Objective-C and Objective\-\*(C+) that the compiler
+accepts:
+.IP "\fB\-ansi\fR" 4
+.IX Item "-ansi"
+In C mode, this is equivalent to \fB\-std=c90\fR. In \*(C+ mode, it is
+equivalent to \fB\-std=c++98\fR.
+.Sp
+This turns off certain features of \s-1GCC\s0 that are incompatible with \s-1ISO
+C90 \s0(when compiling C code), or of standard \*(C+ (when compiling \*(C+ code),
+such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, and
+predefined macros such as \f(CW\*(C`unix\*(C'\fR and \f(CW\*(C`vax\*(C'\fR that identify the
+type of system you are using.  It also enables the undesirable and
+rarely used \s-1ISO\s0 trigraph feature.  For the C compiler,
+it disables recognition of \*(C+ style \fB//\fR comments as well as
+the \f(CW\*(C`inline\*(C'\fR keyword.
+.Sp
+The alternate keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_extension_\|_\*(C'\fR,
+\&\f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR continue to work despite
+\&\fB\-ansi\fR.  You would not want to use them in an \s-1ISO C\s0 program, of
+course, but it is useful to put them in header files that might be included
+in compilations done with \fB\-ansi\fR.  Alternate predefined macros
+such as \f(CW\*(C`_\|_unix_\|_\*(C'\fR and \f(CW\*(C`_\|_vax_\|_\*(C'\fR are also available, with or
+without \fB\-ansi\fR.
+.Sp
+The \fB\-ansi\fR option does not cause non-ISO programs to be
+rejected gratuitously.  For that, \fB\-Wpedantic\fR is required in
+addition to \fB\-ansi\fR.
+.Sp
+The macro \f(CW\*(C`_\|_STRICT_ANSI_\|_\*(C'\fR is predefined when the \fB\-ansi\fR
+option is used.  Some header files may notice this macro and refrain
+from declaring certain functions or defining certain macros that the
+\&\s-1ISO\s0 standard doesn't call for; this is to avoid interfering with any
+programs that might use these names for other things.
+.Sp
+Functions that are normally built in but do not have semantics
+defined by \s-1ISO C \s0(such as \f(CW\*(C`alloca\*(C'\fR and \f(CW\*(C`ffs\*(C'\fR) are not built-in
+functions when \fB\-ansi\fR is used.
+.IP "\fB\-std=\fR" 4
+.IX Item "-std="
+Determine the language standard.   This option
+is currently only supported when compiling C or \*(C+.
+.Sp
+The compiler can accept several base standards, such as \fBc90\fR or
+\&\fBc++98\fR, and \s-1GNU\s0 dialects of those standards, such as
+\&\fBgnu90\fR or \fBgnu++98\fR.  When a base standard is specified, the
+compiler accepts all programs following that standard plus those
+using \s-1GNU\s0 extensions that do not contradict it.  For example,
+\&\fB\-std=c90\fR turns off certain features of \s-1GCC\s0 that are
+incompatible with \s-1ISO C90,\s0 such as the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR
+keywords, but not other \s-1GNU\s0 extensions that do not have a meaning in
+\&\s-1ISO C90,\s0 such as omitting the middle term of a \f(CW\*(C`?:\*(C'\fR
+expression. On the other hand, when a \s-1GNU\s0 dialect of a standard is
+specified, all features supported by the compiler are enabled, even when
+those features change the meaning of the base standard.  As a result, some
+strict-conforming programs may be rejected.  The particular standard
+is used by \fB\-Wpedantic\fR to identify which features are \s-1GNU\s0
+extensions given that version of the standard. For example
+\&\fB\-std=gnu90 \-Wpedantic\fR warns about \*(C+ style \fB//\fR
+comments, while \fB\-std=gnu99 \-Wpedantic\fR does not.
+.Sp
+A value for this option must be provided; possible values are
+.RS 4
+.IP "\fBc90\fR" 4
+.IX Item "c90"
+.PD 0
+.IP "\fBc89\fR" 4
+.IX Item "c89"
+.IP "\fBiso9899:1990\fR" 4
+.IX Item "iso9899:1990"
+.PD
+Support all \s-1ISO C90\s0 programs (certain \s-1GNU\s0 extensions that conflict
+with \s-1ISO C90\s0 are disabled). Same as \fB\-ansi\fR for C code.
+.IP "\fBiso9899:199409\fR" 4
+.IX Item "iso9899:199409"
+\&\s-1ISO C90\s0 as modified in amendment 1.
+.IP "\fBc99\fR" 4
+.IX Item "c99"
+.PD 0
+.IP "\fBc9x\fR" 4
+.IX Item "c9x"
+.IP "\fBiso9899:1999\fR" 4
+.IX Item "iso9899:1999"
+.IP "\fBiso9899:199x\fR" 4
+.IX Item "iso9899:199x"
+.PD
+\&\s-1ISO C99. \s0 This standard is substantially completely supported, modulo
+bugs, extended identifiers (supported except for corner cases when
+\&\fB\-fextended\-identifiers\fR is used) and floating-point issues
+(mainly but not entirely relating to optional C99 features from
+Annexes F and G).  See
+<\fBhttp://gcc.gnu.org/c99status.html\fR> for more information.  The
+names \fBc9x\fR and \fBiso9899:199x\fR are deprecated.
+.IP "\fBc11\fR" 4
+.IX Item "c11"
+.PD 0
+.IP "\fBc1x\fR" 4
+.IX Item "c1x"
+.IP "\fBiso9899:2011\fR" 4
+.IX Item "iso9899:2011"
+.PD
+\&\s-1ISO C11,\s0 the 2011 revision of the \s-1ISO C\s0 standard.  This standard is
+substantially completely supported, modulo bugs, extended identifiers
+(supported except for corner cases when
+\&\fB\-fextended\-identifiers\fR is used), floating-point issues
+(mainly but not entirely relating to optional C11 features from
+Annexes F and G) and the optional Annexes K (Bounds-checking
+interfaces) and L (Analyzability).  The name \fBc1x\fR is deprecated.
+.IP "\fBgnu90\fR" 4
+.IX Item "gnu90"
+.PD 0
+.IP "\fBgnu89\fR" 4
+.IX Item "gnu89"
+.PD
+\&\s-1GNU\s0 dialect of \s-1ISO C90 \s0(including some C99 features). This
+is the default for C code.
+.IP "\fBgnu99\fR" 4
+.IX Item "gnu99"
+.PD 0
+.IP "\fBgnu9x\fR" 4
+.IX Item "gnu9x"
+.PD
+\&\s-1GNU\s0 dialect of \s-1ISO C99. \s0 The name \fBgnu9x\fR is deprecated.
+.IP "\fBgnu11\fR" 4
+.IX Item "gnu11"
+.PD 0
+.IP "\fBgnu1x\fR" 4
+.IX Item "gnu1x"
+.PD
+\&\s-1GNU\s0 dialect of \s-1ISO C11. \s0 This is intended to become the default in a
+future release of \s-1GCC. \s0 The name \fBgnu1x\fR is deprecated.
+.IP "\fBc++98\fR" 4
+.IX Item "c++98"
+.PD 0
+.IP "\fBc++03\fR" 4
+.IX Item "c++03"
+.PD
+The 1998 \s-1ISO \*(C+\s0 standard plus the 2003 technical corrigendum and some
+additional defect reports. Same as \fB\-ansi\fR for \*(C+ code.
+.IP "\fBgnu++98\fR" 4
+.IX Item "gnu++98"
+.PD 0
+.IP "\fBgnu++03\fR" 4
+.IX Item "gnu++03"
+.PD
+\&\s-1GNU\s0 dialect of \fB\-std=c++98\fR.  This is the default for
+\&\*(C+ code.
+.IP "\fBc++11\fR" 4
+.IX Item "c++11"
+.PD 0
+.IP "\fBc++0x\fR" 4
+.IX Item "c++0x"
+.PD
+The 2011 \s-1ISO \*(C+\s0 standard plus amendments.
+The name \fBc++0x\fR is deprecated.
+.IP "\fBgnu++11\fR" 4
+.IX Item "gnu++11"
+.PD 0
+.IP "\fBgnu++0x\fR" 4
+.IX Item "gnu++0x"
+.PD
+\&\s-1GNU\s0 dialect of \fB\-std=c++11\fR.
+The name \fBgnu++0x\fR is deprecated.
+.IP "\fBc++1y\fR" 4
+.IX Item "c++1y"
+The next revision of the \s-1ISO \*(C+\s0 standard, tentatively planned for
+2014.  Support is highly experimental, and will almost certainly
+change in incompatible ways in future releases.
+.IP "\fBgnu++1y\fR" 4
+.IX Item "gnu++1y"
+\&\s-1GNU\s0 dialect of \fB\-std=c++1y\fR.  Support is highly experimental,
+and will almost certainly change in incompatible ways in future
+releases.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fgnu89\-inline\fR" 4
+.IX Item "-fgnu89-inline"
+The option \fB\-fgnu89\-inline\fR tells \s-1GCC\s0 to use the traditional
+\&\s-1GNU\s0 semantics for \f(CW\*(C`inline\*(C'\fR functions when in C99 mode.
+  This option
+is accepted and ignored by \s-1GCC\s0 versions 4.1.3 up to but not including
+4.3.  In \s-1GCC\s0 versions 4.3 and later it changes the behavior of \s-1GCC\s0 in
+C99 mode.  Using this option is roughly equivalent to adding the
+\&\f(CW\*(C`gnu_inline\*(C'\fR function attribute to all inline functions.
+.Sp
+The option \fB\-fno\-gnu89\-inline\fR explicitly tells \s-1GCC\s0 to use the
+C99 semantics for \f(CW\*(C`inline\*(C'\fR when in C99 or gnu99 mode (i.e., it
+specifies the default behavior).  This option was first supported in
+\&\s-1GCC 4.3. \s0 This option is not supported in \fB\-std=c90\fR or
+\&\fB\-std=gnu90\fR mode.
+.Sp
+The preprocessor macros \f(CW\*(C`_\|_GNUC_GNU_INLINE_\|_\*(C'\fR and
+\&\f(CW\*(C`_\|_GNUC_STDC_INLINE_\|_\*(C'\fR may be used to check which semantics are
+in effect for \f(CW\*(C`inline\*(C'\fR functions.
+.IP "\fB\-aux\-info\fR \fIfilename\fR" 4
+.IX Item "-aux-info filename"
+Output to the given filename prototyped declarations for all functions
+declared and/or defined in a translation unit, including those in header
+files.  This option is silently ignored in any language other than C.
+.Sp
+Besides declarations, the file indicates, in comments, the origin of
+each declaration (source file and line), whether the declaration was
+implicit, prototyped or unprototyped (\fBI\fR, \fBN\fR for new or
+\&\fBO\fR for old, respectively, in the first character after the line
+number and the colon), and whether it came from a declaration or a
+definition (\fBC\fR or \fBF\fR, respectively, in the following
+character).  In the case of function definitions, a K&R\-style list of
+arguments followed by their declarations is also provided, inside
+comments, after the declaration.
+.IP "\fB\-fallow\-parameterless\-variadic\-functions\fR" 4
+.IX Item "-fallow-parameterless-variadic-functions"
+Accept variadic functions without named parameters.
+.Sp
+Although it is possible to define such a function, this is not very
+useful as it is not possible to read the arguments.  This is only
+supported for C as this construct is allowed by \*(C+.
+.IP "\fB\-fno\-asm\fR" 4
+.IX Item "-fno-asm"
+Do not recognize \f(CW\*(C`asm\*(C'\fR, \f(CW\*(C`inline\*(C'\fR or \f(CW\*(C`typeof\*(C'\fR as a
+keyword, so that code can use these words as identifiers.  You can use
+the keywords \f(CW\*(C`_\|_asm_\|_\*(C'\fR, \f(CW\*(C`_\|_inline_\|_\*(C'\fR and \f(CW\*(C`_\|_typeof_\|_\*(C'\fR
+instead.  \fB\-ansi\fR implies \fB\-fno\-asm\fR.
+.Sp
+In \*(C+, this switch only affects the \f(CW\*(C`typeof\*(C'\fR keyword, since
+\&\f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`inline\*(C'\fR are standard keywords.  You may want to
+use the \fB\-fno\-gnu\-keywords\fR flag instead, which has the same
+effect.  In C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this
+switch only affects the \f(CW\*(C`asm\*(C'\fR and \f(CW\*(C`typeof\*(C'\fR keywords, since
+\&\f(CW\*(C`inline\*(C'\fR is a standard keyword in \s-1ISO C99.\s0
+.IP "\fB\-fno\-builtin\fR" 4
+.IX Item "-fno-builtin"
+.PD 0
+.IP "\fB\-fno\-builtin\-\fR\fIfunction\fR" 4
+.IX Item "-fno-builtin-function"
+.PD
+Don't recognize built-in functions that do not begin with
+\&\fB_\|_builtin_\fR as prefix.
+.Sp
+\&\s-1GCC\s0 normally generates special code to handle certain built-in functions
+more efficiently; for instance, calls to \f(CW\*(C`alloca\*(C'\fR may become single
+instructions which adjust the stack directly, and calls to \f(CW\*(C`memcpy\*(C'\fR
+may become inline copy loops.  The resulting code is often both smaller
+and faster, but since the function calls no longer appear as such, you
+cannot set a breakpoint on those calls, nor can you change the behavior
+of the functions by linking with a different library.  In addition,
+when a function is recognized as a built-in function, \s-1GCC\s0 may use
+information about that function to warn about problems with calls to
+that function, or to generate more efficient code, even if the
+resulting code still contains calls to that function.  For example,
+warnings are given with \fB\-Wformat\fR for bad calls to
+\&\f(CW\*(C`printf\*(C'\fR when \f(CW\*(C`printf\*(C'\fR is built in and \f(CW\*(C`strlen\*(C'\fR is
+known not to modify global memory.
+.Sp
+With the \fB\-fno\-builtin\-\fR\fIfunction\fR option
+only the built-in function \fIfunction\fR is
+disabled.  \fIfunction\fR must not begin with \fB_\|_builtin_\fR.  If a
+function is named that is not built-in in this version of \s-1GCC,\s0 this
+option is ignored.  There is no corresponding
+\&\fB\-fbuiltin\-\fR\fIfunction\fR option; if you wish to enable
+built-in functions selectively when using \fB\-fno\-builtin\fR or
+\&\fB\-ffreestanding\fR, you may define macros such as:
+.Sp
+.Vb 2
+\&        #define abs(n)          _\|_builtin_abs ((n))
+\&        #define strcpy(d, s)    _\|_builtin_strcpy ((d), (s))
+.Ve
+.IP "\fB\-fhosted\fR" 4
+.IX Item "-fhosted"
+Assert that compilation targets a hosted environment.  This implies
+\&\fB\-fbuiltin\fR.  A hosted environment is one in which the
+entire standard library is available, and in which \f(CW\*(C`main\*(C'\fR has a return
+type of \f(CW\*(C`int\*(C'\fR.  Examples are nearly everything except a kernel.
+This is equivalent to \fB\-fno\-freestanding\fR.
+.IP "\fB\-ffreestanding\fR" 4
+.IX Item "-ffreestanding"
+Assert that compilation targets a freestanding environment.  This
+implies \fB\-fno\-builtin\fR.  A freestanding environment
+is one in which the standard library may not exist, and program startup may
+not necessarily be at \f(CW\*(C`main\*(C'\fR.  The most obvious example is an \s-1OS\s0 kernel.
+This is equivalent to \fB\-fno\-hosted\fR.
+.IP "\fB\-fopenmp\fR" 4
+.IX Item "-fopenmp"
+Enable handling of OpenMP directives \f(CW\*(C`#pragma omp\*(C'\fR in C/\*(C+ and
+\&\f(CW\*(C`!$omp\*(C'\fR in Fortran.  When \fB\-fopenmp\fR is specified, the
+compiler generates parallel code according to the OpenMP Application
+Program Interface v4.0 <\fBhttp://www.openmp.org/\fR>.  This option
+implies \fB\-pthread\fR, and thus is only supported on targets that
+have support for \fB\-pthread\fR. \fB\-fopenmp\fR implies
+\&\fB\-fopenmp\-simd\fR.
+.IP "\fB\-fopenmp\-simd\fR" 4
+.IX Item "-fopenmp-simd"
+Enable handling of OpenMP's \s-1SIMD\s0 directives with \f(CW\*(C`#pragma omp\*(C'\fR
+in C/\*(C+ and \f(CW\*(C`!$omp\*(C'\fR in Fortran. Other OpenMP directives
+are ignored.
+.IP "\fB\-fcilkplus\fR" 4
+.IX Item "-fcilkplus"
+Enable the usage of Cilk Plus language extension features for C/\*(C+.
+When the option \fB\-fcilkplus\fR is specified, enable the usage of
+the Cilk Plus Language extension features for C/\*(C+.  The present
+implementation follows \s-1ABI\s0 version 1.2.  This is an experimental
+feature that is only partially complete, and whose interface may
+change in future versions of \s-1GCC\s0 as the official specification
+changes.  Currently, all features but \f(CW\*(C`_Cilk_for\*(C'\fR have been
+implemented.
+.IP "\fB\-fgnu\-tm\fR" 4
+.IX Item "-fgnu-tm"
+When the option \fB\-fgnu\-tm\fR is specified, the compiler
+generates code for the Linux variant of Intel's current Transactional
+Memory \s-1ABI\s0 specification document (Revision 1.1, May 6 2009).  This is
+an experimental feature whose interface may change in future versions
+of \s-1GCC,\s0 as the official specification changes.  Please note that not
+all architectures are supported for this feature.
+.Sp
+For more information on \s-1GCC\s0's support for transactional memory,
+.Sp
+Note that the transactional memory feature is not supported with
+non-call exceptions (\fB\-fnon\-call\-exceptions\fR).
+.IP "\fB\-fms\-extensions\fR" 4
+.IX Item "-fms-extensions"
+Accept some non-standard constructs used in Microsoft header files.
+.Sp
+In \*(C+ code, this allows member names in structures to be similar
+to previous types declarations.
+.Sp
+.Vb 4
+\&        typedef int UOW;
+\&        struct ABC {
+\&          UOW UOW;
+\&        };
+.Ve
+.Sp
+Some cases of unnamed fields in structures and unions are only
+accepted with this option.
+.Sp
+Note that this option is off for all targets but i?86 and x86_64
+targets using ms-abi.
+.IP "\fB\-fplan9\-extensions\fR" 4
+.IX Item "-fplan9-extensions"
+Accept some non-standard constructs used in Plan 9 code.
+.Sp
+This enables \fB\-fms\-extensions\fR, permits passing pointers to
+structures with anonymous fields to functions that expect pointers to
+elements of the type of the field, and permits referring to anonymous
+fields declared using a typedef.    This is only
+supported for C, not \*(C+.
+.IP "\fB\-trigraphs\fR" 4
+.IX Item "-trigraphs"
+Support \s-1ISO C\s0 trigraphs.  The \fB\-ansi\fR option (and \fB\-std\fR
+options for strict \s-1ISO C\s0 conformance) implies \fB\-trigraphs\fR.
+.IP "\fB\-traditional\fR" 4
+.IX Item "-traditional"
+.PD 0
+.IP "\fB\-traditional\-cpp\fR" 4
+.IX Item "-traditional-cpp"
+.PD
+Formerly, these options caused \s-1GCC\s0 to attempt to emulate a pre-standard
+C compiler.  They are now only supported with the \fB\-E\fR switch.
+The preprocessor continues to support a pre-standard mode.  See the \s-1GNU
+CPP\s0 manual for details.
+.IP "\fB\-fcond\-mismatch\fR" 4
+.IX Item "-fcond-mismatch"
+Allow conditional expressions with mismatched types in the second and
+third arguments.  The value of such an expression is void.  This option
+is not supported for \*(C+.
+.IP "\fB\-flax\-vector\-conversions\fR" 4
+.IX Item "-flax-vector-conversions"
+Allow implicit conversions between vectors with differing numbers of
+elements and/or incompatible element types.  This option should not be
+used for new code.
+.IP "\fB\-funsigned\-char\fR" 4
+.IX Item "-funsigned-char"
+Let the type \f(CW\*(C`char\*(C'\fR be unsigned, like \f(CW\*(C`unsigned char\*(C'\fR.
+.Sp
+Each kind of machine has a default for what \f(CW\*(C`char\*(C'\fR should
+be.  It is either like \f(CW\*(C`unsigned char\*(C'\fR by default or like
+\&\f(CW\*(C`signed char\*(C'\fR by default.
+.Sp
+Ideally, a portable program should always use \f(CW\*(C`signed char\*(C'\fR or
+\&\f(CW\*(C`unsigned char\*(C'\fR when it depends on the signedness of an object.
+But many programs have been written to use plain \f(CW\*(C`char\*(C'\fR and
+expect it to be signed, or expect it to be unsigned, depending on the
+machines they were written for.  This option, and its inverse, let you
+make such a program work with the opposite default.
+.Sp
+The type \f(CW\*(C`char\*(C'\fR is always a distinct type from each of
+\&\f(CW\*(C`signed char\*(C'\fR or \f(CW\*(C`unsigned char\*(C'\fR, even though its behavior
+is always just like one of those two.
+.IP "\fB\-fsigned\-char\fR" 4
+.IX Item "-fsigned-char"
+Let the type \f(CW\*(C`char\*(C'\fR be signed, like \f(CW\*(C`signed char\*(C'\fR.
+.Sp
+Note that this is equivalent to \fB\-fno\-unsigned\-char\fR, which is
+the negative form of \fB\-funsigned\-char\fR.  Likewise, the option
+\&\fB\-fno\-signed\-char\fR is equivalent to \fB\-funsigned\-char\fR.
+.IP "\fB\-fsigned\-bitfields\fR" 4
+.IX Item "-fsigned-bitfields"
+.PD 0
+.IP "\fB\-funsigned\-bitfields\fR" 4
+.IX Item "-funsigned-bitfields"
+.IP "\fB\-fno\-signed\-bitfields\fR" 4
+.IX Item "-fno-signed-bitfields"
+.IP "\fB\-fno\-unsigned\-bitfields\fR" 4
+.IX Item "-fno-unsigned-bitfields"
+.PD
+These options control whether a bit-field is signed or unsigned, when the
+declaration does not use either \f(CW\*(C`signed\*(C'\fR or \f(CW\*(C`unsigned\*(C'\fR.  By
+default, such a bit-field is signed, because this is consistent: the
+basic integer types such as \f(CW\*(C`int\*(C'\fR are signed types.
+.SS "Options Controlling \*(C+ Dialect"
+.IX Subsection "Options Controlling Dialect"
+This section describes the command-line options that are only meaningful
+for \*(C+ programs.  You can also use most of the \s-1GNU\s0 compiler options
+regardless of what language your program is in.  For example, you
+might compile a file \f(CW\*(C`firstClass.C\*(C'\fR like this:
+.PP
+.Vb 1
+\&        g++ \-g \-frepo \-O \-c firstClass.C
+.Ve
+.PP
+In this example, only \fB\-frepo\fR is an option meant
+only for \*(C+ programs; you can use the other options with any
+language supported by \s-1GCC.\s0
+.PP
+Here is a list of options that are \fIonly\fR for compiling \*(C+ programs:
+.IP "\fB\-fabi\-version=\fR\fIn\fR" 4
+.IX Item "-fabi-version=n"
+Use version \fIn\fR of the \*(C+ \s-1ABI. \s0 The default is version 2.
+.Sp
+Version 0 refers to the version conforming most closely to
+the \*(C+ \s-1ABI\s0 specification.  Therefore, the \s-1ABI\s0 obtained using version 0
+will change in different versions of G++ as \s-1ABI\s0 bugs are fixed.
+.Sp
+Version 1 is the version of the \*(C+ \s-1ABI\s0 that first appeared in G++ 3.2.
+.Sp
+Version 2 is the version of the \*(C+ \s-1ABI\s0 that first appeared in G++ 3.4.
+.Sp
+Version 3 corrects an error in mangling a constant address as a
+template argument.
+.Sp
+Version 4, which first appeared in G++ 4.5, implements a standard
+mangling for vector types.
+.Sp
+Version 5, which first appeared in G++ 4.6, corrects the mangling of
+attribute const/volatile on function pointer types, decltype of a
+plain decl, and use of a function parameter in the declaration of
+another parameter.
+.Sp
+Version 6, which first appeared in G++ 4.7, corrects the promotion
+behavior of \*(C+11 scoped enums and the mangling of template argument
+packs, const/static_cast, prefix ++ and \-\-, and a class scope function
+used as a template argument.
+.Sp
+See also \fB\-Wabi\fR.
+.IP "\fB\-fno\-access\-control\fR" 4
+.IX Item "-fno-access-control"
+Turn off all access checking.  This switch is mainly useful for working
+around bugs in the access control code.
+.IP "\fB\-fcheck\-new\fR" 4
+.IX Item "-fcheck-new"
+Check that the pointer returned by \f(CW\*(C`operator new\*(C'\fR is non-null
+before attempting to modify the storage allocated.  This check is
+normally unnecessary because the \*(C+ standard specifies that
+\&\f(CW\*(C`operator new\*(C'\fR only returns \f(CW0\fR if it is declared
+\&\fB\f(BIthrow()\fB\fR, in which case the compiler always checks the
+return value even without this option.  In all other cases, when
+\&\f(CW\*(C`operator new\*(C'\fR has a non-empty exception specification, memory
+exhaustion is signalled by throwing \f(CW\*(C`std::bad_alloc\*(C'\fR.  See also
+\&\fBnew (nothrow)\fR.
+.IP "\fB\-fconstexpr\-depth=\fR\fIn\fR" 4
+.IX Item "-fconstexpr-depth=n"
+Set the maximum nested evaluation depth for \*(C+11 constexpr functions
+to \fIn\fR.  A limit is needed to detect endless recursion during
+constant expression evaluation.  The minimum specified by the standard
+is 512.
+.IP "\fB\-fdeduce\-init\-list\fR" 4
+.IX Item "-fdeduce-init-list"
+Enable deduction of a template type parameter as
+\&\f(CW\*(C`std::initializer_list\*(C'\fR from a brace-enclosed initializer list, i.e.
+.Sp
+.Vb 4
+\&        template <class T> auto forward(T t) \-> decltype (realfn (t))
+\&        {
+\&          return realfn (t);
+\&        }
+\&        
+\&        void f()
+\&        {
+\&          forward({1,2}); // call forward<std::initializer_list<int>>
+\&        }
+.Ve
+.Sp
+This deduction was implemented as a possible extension to the
+originally proposed semantics for the \*(C+11 standard, but was not part
+of the final standard, so it is disabled by default.  This option is
+deprecated, and may be removed in a future version of G++.
+.IP "\fB\-ffriend\-injection\fR" 4
+.IX Item "-ffriend-injection"
+Inject friend functions into the enclosing namespace, so that they are
+visible outside the scope of the class in which they are declared.
+Friend functions were documented to work this way in the old Annotated
+\&\*(C+ Reference Manual, and versions of G++ before 4.1 always worked
+that way.  However, in \s-1ISO \*(C+\s0 a friend function that is not declared
+in an enclosing scope can only be found using argument dependent
+lookup.  This option causes friends to be injected as they were in
+earlier releases.
+.Sp
+This option is for compatibility, and may be removed in a future
+release of G++.
+.IP "\fB\-fno\-elide\-constructors\fR" 4
+.IX Item "-fno-elide-constructors"
+The \*(C+ standard allows an implementation to omit creating a temporary
+that is only used to initialize another object of the same type.
+Specifying this option disables that optimization, and forces G++ to
+call the copy constructor in all cases.
+.IP "\fB\-fno\-enforce\-eh\-specs\fR" 4
+.IX Item "-fno-enforce-eh-specs"
+Don't generate code to check for violation of exception specifications
+at run time.  This option violates the \*(C+ standard, but may be useful
+for reducing code size in production builds, much like defining
+\&\fB\s-1NDEBUG\s0\fR.  This does not give user code permission to throw
+exceptions in violation of the exception specifications; the compiler
+still optimizes based on the specifications, so throwing an
+unexpected exception results in undefined behavior at run time.
+.IP "\fB\-fextern\-tls\-init\fR" 4
+.IX Item "-fextern-tls-init"
+.PD 0
+.IP "\fB\-fno\-extern\-tls\-init\fR" 4
+.IX Item "-fno-extern-tls-init"
+.PD
+The \*(C+11 and OpenMP standards allow \fBthread_local\fR and
+\&\fBthreadprivate\fR variables to have dynamic (runtime)
+initialization.  To support this, any use of such a variable goes
+through a wrapper function that performs any necessary initialization.
+When the use and definition of the variable are in the same
+translation unit, this overhead can be optimized away, but when the
+use is in a different translation unit there is significant overhead
+even if the variable doesn't actually need dynamic initialization.  If
+the programmer can be sure that no use of the variable in a
+non-defining \s-1TU\s0 needs to trigger dynamic initialization (either
+because the variable is statically initialized, or a use of the
+variable in the defining \s-1TU\s0 will be executed before any uses in
+another \s-1TU\s0), they can avoid this overhead with the
+\&\fB\-fno\-extern\-tls\-init\fR option.
+.Sp
+On targets that support symbol aliases, the default is
+\&\fB\-fextern\-tls\-init\fR.  On targets that do not support symbol
+aliases, the default is \fB\-fno\-extern\-tls\-init\fR.
+.IP "\fB\-ffor\-scope\fR" 4
+.IX Item "-ffor-scope"
+.PD 0
+.IP "\fB\-fno\-for\-scope\fR" 4
+.IX Item "-fno-for-scope"
+.PD
+If \fB\-ffor\-scope\fR is specified, the scope of variables declared in
+a \fIfor-init-statement\fR is limited to the \fBfor\fR loop itself,
+as specified by the \*(C+ standard.
+If \fB\-fno\-for\-scope\fR is specified, the scope of variables declared in
+a \fIfor-init-statement\fR extends to the end of the enclosing scope,
+as was the case in old versions of G++, and other (traditional)
+implementations of \*(C+.
+.Sp
+If neither flag is given, the default is to follow the standard,
+but to allow and give a warning for old-style code that would
+otherwise be invalid, or have different behavior.
+.IP "\fB\-fno\-gnu\-keywords\fR" 4
+.IX Item "-fno-gnu-keywords"
+Do not recognize \f(CW\*(C`typeof\*(C'\fR as a keyword, so that code can use this
+word as an identifier.  You can use the keyword \f(CW\*(C`_\|_typeof_\|_\*(C'\fR instead.
+\&\fB\-ansi\fR implies \fB\-fno\-gnu\-keywords\fR.
+.IP "\fB\-fno\-implicit\-templates\fR" 4
+.IX Item "-fno-implicit-templates"
+Never emit code for non-inline templates that are instantiated
+implicitly (i.e. by use); only emit code for explicit instantiations.
+.IP "\fB\-fno\-implicit\-inline\-templates\fR" 4
+.IX Item "-fno-implicit-inline-templates"
+Don't emit code for implicit instantiations of inline templates, either.
+The default is to handle inlines differently so that compiles with and
+without optimization need the same set of explicit instantiations.
+.IP "\fB\-fno\-implement\-inlines\fR" 4
+.IX Item "-fno-implement-inlines"
+To save space, do not emit out-of-line copies of inline functions
+controlled by \fB#pragma implementation\fR.  This causes linker
+errors if these functions are not inlined everywhere they are called.
+.IP "\fB\-fms\-extensions\fR" 4
+.IX Item "-fms-extensions"
+Disable Wpedantic warnings about constructs used in \s-1MFC,\s0 such as implicit
+int and getting a pointer to member function via non-standard syntax.
+.IP "\fB\-fno\-nonansi\-builtins\fR" 4
+.IX Item "-fno-nonansi-builtins"
+Disable built-in declarations of functions that are not mandated by
+\&\s-1ANSI/ISO C. \s0 These include \f(CW\*(C`ffs\*(C'\fR, \f(CW\*(C`alloca\*(C'\fR, \f(CW\*(C`_exit\*(C'\fR,
+\&\f(CW\*(C`index\*(C'\fR, \f(CW\*(C`bzero\*(C'\fR, \f(CW\*(C`conjf\*(C'\fR, and other related functions.
+.IP "\fB\-fnothrow\-opt\fR" 4
+.IX Item "-fnothrow-opt"
+Treat a \f(CW\*(C`throw()\*(C'\fR exception specification as if it were a
+\&\f(CW\*(C`noexcept\*(C'\fR specification to reduce or eliminate the text size
+overhead relative to a function with no exception specification.  If
+the function has local variables of types with non-trivial
+destructors, the exception specification actually makes the
+function smaller because the \s-1EH\s0 cleanups for those variables can be
+optimized away.  The semantic effect is that an exception thrown out of
+a function with such an exception specification results in a call
+to \f(CW\*(C`terminate\*(C'\fR rather than \f(CW\*(C`unexpected\*(C'\fR.
+.IP "\fB\-fno\-operator\-names\fR" 4
+.IX Item "-fno-operator-names"
+Do not treat the operator name keywords \f(CW\*(C`and\*(C'\fR, \f(CW\*(C`bitand\*(C'\fR,
+\&\f(CW\*(C`bitor\*(C'\fR, \f(CW\*(C`compl\*(C'\fR, \f(CW\*(C`not\*(C'\fR, \f(CW\*(C`or\*(C'\fR and \f(CW\*(C`xor\*(C'\fR as
+synonyms as keywords.
+.IP "\fB\-fno\-optional\-diags\fR" 4
+.IX Item "-fno-optional-diags"
+Disable diagnostics that the standard says a compiler does not need to
+issue.  Currently, the only such diagnostic issued by G++ is the one for
+a name having multiple meanings within a class.
+.IP "\fB\-fpermissive\fR" 4
+.IX Item "-fpermissive"
+Downgrade some diagnostics about nonconformant code from errors to
+warnings.  Thus, using \fB\-fpermissive\fR allows some
+nonconforming code to compile.
+.IP "\fB\-fno\-pretty\-templates\fR" 4
+.IX Item "-fno-pretty-templates"
+When an error message refers to a specialization of a function
+template, the compiler normally prints the signature of the
+template followed by the template arguments and any typedefs or
+typenames in the signature (e.g. \f(CW\*(C`void f(T) [with T = int]\*(C'\fR
+rather than \f(CW\*(C`void f(int)\*(C'\fR) so that it's clear which template is
+involved.  When an error message refers to a specialization of a class
+template, the compiler omits any template arguments that match
+the default template arguments for that template.  If either of these
+behaviors make it harder to understand the error message rather than
+easier, you can use \fB\-fno\-pretty\-templates\fR to disable them.
+.IP "\fB\-frepo\fR" 4
+.IX Item "-frepo"
+Enable automatic template instantiation at link time.  This option also
+implies \fB\-fno\-implicit\-templates\fR.
+.IP "\fB\-fno\-rtti\fR" 4
+.IX Item "-fno-rtti"
+Disable generation of information about every class with virtual
+functions for use by the \*(C+ run-time type identification features
+(\fBdynamic_cast\fR and \fBtypeid\fR).  If you don't use those parts
+of the language, you can save some space by using this flag.  Note that
+exception handling uses the same information, but G++ generates it as
+needed. The \fBdynamic_cast\fR operator can still be used for casts that
+do not require run-time type information, i.e. casts to \f(CW\*(C`void *\*(C'\fR or to
+unambiguous base classes.
+.IP "\fB\-fstats\fR" 4
+.IX Item "-fstats"
+Emit statistics about front-end processing at the end of the compilation.
+This information is generally only useful to the G++ development team.
+.IP "\fB\-fstrict\-enums\fR" 4
+.IX Item "-fstrict-enums"
+Allow the compiler to optimize using the assumption that a value of
+enumerated type can only be one of the values of the enumeration (as
+defined in the \*(C+ standard; basically, a value that can be
+represented in the minimum number of bits needed to represent all the
+enumerators).  This assumption may not be valid if the program uses a
+cast to convert an arbitrary integer value to the enumerated type.
+.IP "\fB\-ftemplate\-backtrace\-limit=\fR\fIn\fR" 4
+.IX Item "-ftemplate-backtrace-limit=n"
+Set the maximum number of template instantiation notes for a single
+warning or error to \fIn\fR.  The default value is 10.
+.IP "\fB\-ftemplate\-depth=\fR\fIn\fR" 4
+.IX Item "-ftemplate-depth=n"
+Set the maximum instantiation depth for template classes to \fIn\fR.
+A limit on the template instantiation depth is needed to detect
+endless recursions during template class instantiation.  \s-1ANSI/ISO \*(C+\s0
+conforming programs must not rely on a maximum depth greater than 17
+(changed to 1024 in \*(C+11).  The default value is 900, as the compiler
+can run out of stack space before hitting 1024 in some situations.
+.IP "\fB\-fno\-threadsafe\-statics\fR" 4
+.IX Item "-fno-threadsafe-statics"
+Do not emit the extra code to use the routines specified in the \*(C+
+\&\s-1ABI\s0 for thread-safe initialization of local statics.  You can use this
+option to reduce code size slightly in code that doesn't need to be
+thread-safe.
+.IP "\fB\-fuse\-cxa\-atexit\fR" 4
+.IX Item "-fuse-cxa-atexit"
+Register destructors for objects with static storage duration with the
+\&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR function rather than the \f(CW\*(C`atexit\*(C'\fR function.
+This option is required for fully standards-compliant handling of static
+destructors, but only works if your C library supports
+\&\f(CW\*(C`_\|_cxa_atexit\*(C'\fR.
+.IP "\fB\-fno\-use\-cxa\-get\-exception\-ptr\fR" 4
+.IX Item "-fno-use-cxa-get-exception-ptr"
+Don't use the \f(CW\*(C`_\|_cxa_get_exception_ptr\*(C'\fR runtime routine.  This
+causes \f(CW\*(C`std::uncaught_exception\*(C'\fR to be incorrect, but is necessary
+if the runtime routine is not available.
+.IP "\fB\-fvisibility\-inlines\-hidden\fR" 4
+.IX Item "-fvisibility-inlines-hidden"
+This switch declares that the user does not attempt to compare
+pointers to inline functions or methods where the addresses of the two functions
+are taken in different shared objects.
+.Sp
+The effect of this is that \s-1GCC\s0 may, effectively, mark inline methods with
+\&\f(CW\*(C`_\|_attribute_\|_ ((visibility ("hidden")))\*(C'\fR so that they do not
+appear in the export table of a \s-1DSO\s0 and do not require a \s-1PLT\s0 indirection
+when used within the \s-1DSO. \s0 Enabling this option can have a dramatic effect
+on load and link times of a \s-1DSO\s0 as it massively reduces the size of the
+dynamic export table when the library makes heavy use of templates.
+.Sp
+The behavior of this switch is not quite the same as marking the
+methods as hidden directly, because it does not affect static variables
+local to the function or cause the compiler to deduce that
+the function is defined in only one shared object.
+.Sp
+You may mark a method as having a visibility explicitly to negate the
+effect of the switch for that method.  For example, if you do want to
+compare pointers to a particular inline method, you might mark it as
+having default visibility.  Marking the enclosing class with explicit
+visibility has no effect.
+.Sp
+Explicitly instantiated inline methods are unaffected by this option
+as their linkage might otherwise cross a shared library boundary.
+.IP "\fB\-fvisibility\-ms\-compat\fR" 4
+.IX Item "-fvisibility-ms-compat"
+This flag attempts to use visibility settings to make \s-1GCC\s0's \*(C+
+linkage model compatible with that of Microsoft Visual Studio.
+.Sp
+The flag makes these changes to \s-1GCC\s0's linkage model:
+.RS 4
+.IP "1." 4
+It sets the default visibility to \f(CW\*(C`hidden\*(C'\fR, like
+\&\fB\-fvisibility=hidden\fR.
+.IP "2." 4
+Types, but not their members, are not hidden by default.
+.IP "3." 4
+The One Definition Rule is relaxed for types without explicit
+visibility specifications that are defined in more than one
+shared object: those declarations are permitted if they are
+permitted when this option is not used.
+.RE
+.RS 4
+.Sp
+In new code it is better to use \fB\-fvisibility=hidden\fR and
+export those classes that are intended to be externally visible.
+Unfortunately it is possible for code to rely, perhaps accidentally,
+on the Visual Studio behavior.
+.Sp
+Among the consequences of these changes are that static data members
+of the same type with the same name but defined in different shared
+objects are different, so changing one does not change the other;
+and that pointers to function members defined in different shared
+objects may not compare equal.  When this flag is given, it is a
+violation of the \s-1ODR\s0 to define types with the same name differently.
+.RE
+.IP "\fB\-fvtable\-verify=\fR\fIstd|preinit|none\fR" 4
+.IX Item "-fvtable-verify=std|preinit|none"
+Turn on (or off, if using \fB\-fvtable\-verify=none\fR) the security
+feature that verifies at runtime, for every virtual call that is made, that
+the vtable pointer through which the call is made is valid for the type of
+the object, and has not been corrupted or overwritten.  If an invalid vtable
+pointer is detected (at runtime), an error is reported and execution of the
+program is immediately halted.
+.Sp
+This option causes runtime data structures to be built, at program start up,
+for verifying the vtable pointers.  The options \f(CW\*(C`std\*(C'\fR and \f(CW\*(C`preinit\*(C'\fR
+control the timing of when these data structures are built.  In both cases the
+data structures are built before execution reaches 'main'.  The
+\&\fB\-fvtable\-verify=std\fR causes these data structure to be built after the
+shared libraries have been loaded and initialized.
+\&\fB\-fvtable\-verify=preinit\fR causes them to be built before the shared
+libraries have been loaded and initialized.
+.Sp
+If this option appears multiple times in the compiler line, with different
+values specified, 'none' will take highest priority over both 'std' and
+\&'preinit'; 'preinit' will take priority over 'std'.
+.IP "\fB\-fvtv\-debug\fR" 4
+.IX Item "-fvtv-debug"
+Causes debug versions of the runtime functions for the vtable verification 
+feature to be called.  This assumes the \fB\-fvtable\-verify=std\fR or
+\&\fB\-fvtable\-verify=preinit\fR has been used.  This flag will also cause the
+compiler to keep track of which vtable pointers it found for each class, and
+record that information in the file \*(L"vtv_set_ptr_data.log\*(R", in the dump
+file directory on the user's machine.
+.Sp
+Note:  This feature \s-1APPENDS\s0 data to the log file. If you want a fresh log
+file, be sure to delete any existing one.
+.IP "\fB\-fvtv\-counts\fR" 4
+.IX Item "-fvtv-counts"
+This is a debugging flag.  When used in conjunction with
+\&\fB\-fvtable\-verify=std\fR or \fB\-fvtable\-verify=preinit\fR, this
+causes the compiler to keep track of the total number of virtual calls
+it encountered and the number of verifications it inserted.  It also
+counts the number of calls to certain runtime library functions
+that it inserts.  This information, for each compilation unit, is written
+to a file named \*(L"vtv_count_data.log\*(R", in the dump_file directory on
+the user's machine.   It also counts the size of the vtable pointer sets
+for each class, and writes this information to \*(L"vtv_class_set_sizes.log\*(R"
+in the same directory.
+.Sp
+Note:  This feature \s-1APPENDS\s0 data to the log files.  To get a fresh log
+files, be sure to delete any existing ones.
+.IP "\fB\-fno\-weak\fR" 4
+.IX Item "-fno-weak"
+Do not use weak symbol support, even if it is provided by the linker.
+By default, G++ uses weak symbols if they are available.  This
+option exists only for testing, and should not be used by end-users;
+it results in inferior code and has no benefits.  This option may
+be removed in a future release of G++.
+.IP "\fB\-nostdinc++\fR" 4
+.IX Item "-nostdinc++"
+Do not search for header files in the standard directories specific to
+\&\*(C+, but do still search the other standard directories.  (This option
+is used when building the \*(C+ library.)
+.PP
+In addition, these optimization, warning, and code generation options
+have meanings only for \*(C+ programs:
+.IP "\fB\-Wabi\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wabi (C, Objective-C, and Objective- only)"
+Warn when G++ generates code that is probably not compatible with the
+vendor-neutral \*(C+ \s-1ABI. \s0 Although an effort has been made to warn about
+all such cases, there are probably some cases that are not warned about,
+even though G++ is generating incompatible code.  There may also be
+cases where warnings are emitted even though the code that is generated
+is compatible.
+.Sp
+You should rewrite your code to avoid these warnings if you are
+concerned about the fact that code generated by G++ may not be binary
+compatible with code generated by other compilers.
+.Sp
+The known incompatibilities in \fB\-fabi\-version=2\fR (the default) include:
+.RS 4
+.IP "\(bu" 4
+A template with a non-type template parameter of reference type is
+mangled incorrectly:
+.Sp
+.Vb 3
+\&        extern int N;
+\&        template <int &> struct S {};
+\&        void n (S<N>) {2}
+.Ve
+.Sp
+This is fixed in \fB\-fabi\-version=3\fR.
+.IP "\(bu" 4
+\&\s-1SIMD\s0 vector types declared using \f(CW\*(C`_\|_attribute ((vector_size))\*(C'\fR are
+mangled in a non-standard way that does not allow for overloading of
+functions taking vectors of different sizes.
+.Sp
+The mangling is changed in \fB\-fabi\-version=4\fR.
+.RE
+.RS 4
+.Sp
+The known incompatibilities in \fB\-fabi\-version=1\fR include:
+.IP "\(bu" 4
+Incorrect handling of tail-padding for bit-fields.  G++ may attempt to
+pack data into the same byte as a base class.  For example:
+.Sp
+.Vb 2
+\&        struct A { virtual void f(); int f1 : 1; };
+\&        struct B : public A { int f2 : 1; };
+.Ve
+.Sp
+In this case, G++ places \f(CW\*(C`B::f2\*(C'\fR into the same byte
+as \f(CW\*(C`A::f1\*(C'\fR; other compilers do not.  You can avoid this problem
+by explicitly padding \f(CW\*(C`A\*(C'\fR so that its size is a multiple of the
+byte size on your platform; that causes G++ and other compilers to
+lay out \f(CW\*(C`B\*(C'\fR identically.
+.IP "\(bu" 4
+Incorrect handling of tail-padding for virtual bases.  G++ does not use
+tail padding when laying out virtual bases.  For example:
+.Sp
+.Vb 3
+\&        struct A { virtual void f(); char c1; };
+\&        struct B { B(); char c2; };
+\&        struct C : public A, public virtual B {};
+.Ve
+.Sp
+In this case, G++ does not place \f(CW\*(C`B\*(C'\fR into the tail-padding for
+\&\f(CW\*(C`A\*(C'\fR; other compilers do.  You can avoid this problem by
+explicitly padding \f(CW\*(C`A\*(C'\fR so that its size is a multiple of its
+alignment (ignoring virtual base classes); that causes G++ and other
+compilers to lay out \f(CW\*(C`C\*(C'\fR identically.
+.IP "\(bu" 4
+Incorrect handling of bit-fields with declared widths greater than that
+of their underlying types, when the bit-fields appear in a union.  For
+example:
+.Sp
+.Vb 1
+\&        union U { int i : 4096; };
+.Ve
+.Sp
+Assuming that an \f(CW\*(C`int\*(C'\fR does not have 4096 bits, G++ makes the
+union too small by the number of bits in an \f(CW\*(C`int\*(C'\fR.
+.IP "\(bu" 4
+Empty classes can be placed at incorrect offsets.  For example:
+.Sp
+.Vb 1
+\&        struct A {};
+\&        
+\&        struct B {
+\&          A a;
+\&          virtual void f ();
+\&        };
+\&        
+\&        struct C : public B, public A {};
+.Ve
+.Sp
+G++ places the \f(CW\*(C`A\*(C'\fR base class of \f(CW\*(C`C\*(C'\fR at a nonzero offset;
+it should be placed at offset zero.  G++ mistakenly believes that the
+\&\f(CW\*(C`A\*(C'\fR data member of \f(CW\*(C`B\*(C'\fR is already at offset zero.
+.IP "\(bu" 4
+Names of template functions whose types involve \f(CW\*(C`typename\*(C'\fR or
+template template parameters can be mangled incorrectly.
+.Sp
+.Vb 2
+\&        template <typename Q>
+\&        void f(typename Q::X) {}
+\&        
+\&        template <template <typename> class Q>
+\&        void f(typename Q<int>::X) {}
+.Ve
+.Sp
+Instantiations of these templates may be mangled incorrectly.
+.RE
+.RS 4
+.Sp
+It also warns about psABI-related changes.  The known psABI changes at this
+point include:
+.IP "\(bu" 4
+For SysV/x86\-64, unions with \f(CW\*(C`long double\*(C'\fR members are 
+passed in memory as specified in psABI.  For example:
+.Sp
+.Vb 4
+\&        union U {
+\&          long double ld;
+\&          int i;
+\&        };
+.Ve
+.Sp
+\&\f(CW\*(C`union U\*(C'\fR is always passed in memory.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wctor\-dtor\-privacy\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wctor-dtor-privacy ( and Objective- only)"
+Warn when a class seems unusable because all the constructors or
+destructors in that class are private, and it has neither friends nor
+public static member functions.  Also warn if there are no non-private
+methods, and there's at least one private member function that isn't
+a constructor or destructor.
+.IP "\fB\-Wdelete\-non\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wdelete-non-virtual-dtor ( and Objective- only)"
+Warn when \fBdelete\fR is used to destroy an instance of a class that
+has virtual functions and non-virtual destructor. It is unsafe to delete
+an instance of a derived class through a pointer to a base class if the
+base class does not have a virtual destructor.  This warning is enabled
+by \fB\-Wall\fR.
+.IP "\fB\-Wliteral\-suffix\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wliteral-suffix ( and Objective- only)"
+Warn when a string or character literal is followed by a ud-suffix which does
+not begin with an underscore.  As a conforming extension, \s-1GCC\s0 treats such
+suffixes as separate preprocessing tokens in order to maintain backwards
+compatibility with code that uses formatting macros from \f(CW\*(C`<inttypes.h>\*(C'\fR.
+For example:
+.Sp
+.Vb 3
+\&        #define _\|_STDC_FORMAT_MACROS
+\&        #include <inttypes.h>
+\&        #include <stdio.h>
+\&        
+\&        int main() {
+\&          int64_t i64 = 123;
+\&          printf("My int64: %"PRId64"\en", i64);
+\&        }
+.Ve
+.Sp
+In this case, \f(CW\*(C`PRId64\*(C'\fR is treated as a separate preprocessing token.
+.Sp
+This warning is enabled by default.
+.IP "\fB\-Wnarrowing\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wnarrowing ( and Objective- only)"
+Warn when a narrowing conversion prohibited by \*(C+11 occurs within
+\&\fB{ }\fR, e.g.
+.Sp
+.Vb 1
+\&        int i = { 2.2 }; // error: narrowing from double to int
+.Ve
+.Sp
+This flag is included in \fB\-Wall\fR and \fB\-Wc++11\-compat\fR.
+.Sp
+With \fB\-std=c++11\fR, \fB\-Wno\-narrowing\fR suppresses the diagnostic
+required by the standard.  Note that this does not affect the meaning
+of well-formed code; narrowing conversions are still considered
+ill-formed in \s-1SFINAE\s0 context.
+.IP "\fB\-Wnoexcept\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wnoexcept ( and Objective- only)"
+Warn when a noexcept-expression evaluates to false because of a call
+to a function that does not have a non-throwing exception
+specification (i.e. \fB\f(BIthrow()\fB\fR or \fBnoexcept\fR) but is known by
+the compiler to never throw an exception.
+.IP "\fB\-Wnon\-virtual\-dtor\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wnon-virtual-dtor ( and Objective- only)"
+Warn when a class has virtual functions and an accessible non-virtual
+destructor itself or in an accessible polymorphic base class, in which
+case it is possible but unsafe to delete an instance of a derived
+class through a pointer to the class itself or base class.  This
+warning is automatically enabled if \fB\-Weffc++\fR is specified.
+.IP "\fB\-Wreorder\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wreorder ( and Objective- only)"
+Warn when the order of member initializers given in the code does not
+match the order in which they must be executed.  For instance:
+.Sp
+.Vb 5
+\&        struct A {
+\&          int i;
+\&          int j;
+\&          A(): j (0), i (1) { }
+\&        };
+.Ve
+.Sp
+The compiler rearranges the member initializers for \fBi\fR
+and \fBj\fR to match the declaration order of the members, emitting
+a warning to that effect.  This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-fext\-numeric\-literals\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-fext-numeric-literals ( and Objective- only)"
+Accept imaginary, fixed-point, or machine-defined
+literal number suffixes as \s-1GNU\s0 extensions.
+When this option is turned off these suffixes are treated
+as \*(C+11 user-defined literal numeric suffixes.
+This is on by default for all pre\-\*(C+11 dialects and all \s-1GNU\s0 dialects:
+\&\fB\-std=c++98\fR, \fB\-std=gnu++98\fR, \fB\-std=gnu++11\fR,
+\&\fB\-std=gnu++1y\fR.
+This option is off by default
+for \s-1ISO \*(C+11\s0 onwards (\fB\-std=c++11\fR, ...).
+.PP
+The following \fB\-W...\fR options are not affected by \fB\-Wall\fR.
+.IP "\fB\-Weffc++\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Weffc++ ( and Objective- only)"
+Warn about violations of the following style guidelines from Scott Meyers'
+\&\fIEffective \*(C+\fR series of books:
+.RS 4
+.IP "\(bu" 4
+Define a copy constructor and an assignment operator for classes
+with dynamically-allocated memory.
+.IP "\(bu" 4
+Prefer initialization to assignment in constructors.
+.IP "\(bu" 4
+Have \f(CW\*(C`operator=\*(C'\fR return a reference to \f(CW*this\fR.
+.IP "\(bu" 4
+Don't try to return a reference when you must return an object.
+.IP "\(bu" 4
+Distinguish between prefix and postfix forms of increment and
+decrement operators.
+.IP "\(bu" 4
+Never overload \f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, or \f(CW\*(C`,\*(C'\fR.
+.RE
+.RS 4
+.Sp
+This option also enables \fB\-Wnon\-virtual\-dtor\fR, which is also
+one of the effective \*(C+ recommendations.  However, the check is
+extended to warn about the lack of virtual destructor in accessible
+non-polymorphic bases classes too.
+.Sp
+When selecting this option, be aware that the standard library
+headers do not obey all of these guidelines; use \fBgrep \-v\fR
+to filter out those warnings.
+.RE
+.IP "\fB\-Wstrict\-null\-sentinel\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wstrict-null-sentinel ( and Objective- only)"
+Warn about the use of an uncasted \f(CW\*(C`NULL\*(C'\fR as sentinel.  When
+compiling only with \s-1GCC\s0 this is a valid sentinel, as \f(CW\*(C`NULL\*(C'\fR is defined
+to \f(CW\*(C`_\|_null\*(C'\fR.  Although it is a null pointer constant rather than a
+null pointer, it is guaranteed to be of the same size as a pointer.
+But this use is not portable across different compilers.
+.IP "\fB\-Wno\-non\-template\-friend\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-non-template-friend ( and Objective- only)"
+Disable warnings when non-templatized friend functions are declared
+within a template.  Since the advent of explicit template specification
+support in G++, if the name of the friend is an unqualified-id (i.e.,
+\&\fBfriend foo(int)\fR), the \*(C+ language specification demands that the
+friend declare or define an ordinary, nontemplate function.  (Section
+14.5.3).  Before G++ implemented explicit specification, unqualified-ids
+could be interpreted as a particular specialization of a templatized
+function.  Because this non-conforming behavior is no longer the default
+behavior for G++, \fB\-Wnon\-template\-friend\fR allows the compiler to
+check existing code for potential trouble spots and is on by default.
+This new compiler behavior can be turned off with
+\&\fB\-Wno\-non\-template\-friend\fR, which keeps the conformant compiler code
+but disables the helpful warning.
+.IP "\fB\-Wold\-style\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wold-style-cast ( and Objective- only)"
+Warn if an old-style (C\-style) cast to a non-void type is used within
+a \*(C+ program.  The new-style casts (\fBdynamic_cast\fR,
+\&\fBstatic_cast\fR, \fBreinterpret_cast\fR, and \fBconst_cast\fR) are
+less vulnerable to unintended effects and much easier to search for.
+.IP "\fB\-Woverloaded\-virtual\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Woverloaded-virtual ( and Objective- only)"
+Warn when a function declaration hides virtual functions from a
+base class.  For example, in:
+.Sp
+.Vb 3
+\&        struct A {
+\&          virtual void f();
+\&        };
+\&        
+\&        struct B: public A {
+\&          void f(int);
+\&        };
+.Ve
+.Sp
+the \f(CW\*(C`A\*(C'\fR class version of \f(CW\*(C`f\*(C'\fR is hidden in \f(CW\*(C`B\*(C'\fR, and code
+like:
+.Sp
+.Vb 2
+\&        B* b;
+\&        b\->f();
+.Ve
+.Sp
+fails to compile.
+.IP "\fB\-Wno\-pmf\-conversions\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-pmf-conversions ( and Objective- only)"
+Disable the diagnostic for converting a bound pointer to member function
+to a plain pointer.
+.IP "\fB\-Wsign\-promo\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wsign-promo ( and Objective- only)"
+Warn when overload resolution chooses a promotion from unsigned or
+enumerated type to a signed type, over a conversion to an unsigned type of
+the same size.  Previous versions of G++ tried to preserve
+unsignedness, but the standard mandates the current behavior.
+.SS "Options Controlling Objective-C and Objective\-\*(C+ Dialects"
+.IX Subsection "Options Controlling Objective-C and Objective- Dialects"
+(\s-1NOTE:\s0 This manual does not describe the Objective-C and Objective\-\*(C+
+languages themselves.
+.PP
+This section describes the command-line options that are only meaningful
+for Objective-C and Objective\-\*(C+ programs.  You can also use most of
+the language-independent \s-1GNU\s0 compiler options.
+For example, you might compile a file \f(CW\*(C`some_class.m\*(C'\fR like this:
+.PP
+.Vb 1
+\&        gcc \-g \-fgnu\-runtime \-O \-c some_class.m
+.Ve
+.PP
+In this example, \fB\-fgnu\-runtime\fR is an option meant only for
+Objective-C and Objective\-\*(C+ programs; you can use the other options with
+any language supported by \s-1GCC.\s0
+.PP
+Note that since Objective-C is an extension of the C language, Objective-C
+compilations may also use options specific to the C front-end (e.g.,
+\&\fB\-Wtraditional\fR).  Similarly, Objective\-\*(C+ compilations may use
+\&\*(C+\-specific options (e.g., \fB\-Wabi\fR).
+.PP
+Here is a list of options that are \fIonly\fR for compiling Objective-C
+and Objective\-\*(C+ programs:
+.IP "\fB\-fconstant\-string\-class=\fR\fIclass-name\fR" 4
+.IX Item "-fconstant-string-class=class-name"
+Use \fIclass-name\fR as the name of the class to instantiate for each
+literal string specified with the syntax \f(CW\*(C`@"..."\*(C'\fR.  The default
+class name is \f(CW\*(C`NXConstantString\*(C'\fR if the \s-1GNU\s0 runtime is being used, and
+\&\f(CW\*(C`NSConstantString\*(C'\fR if the NeXT runtime is being used (see below).  The
+\&\fB\-fconstant\-cfstrings\fR option, if also present, overrides the
+\&\fB\-fconstant\-string\-class\fR setting and cause \f(CW\*(C`@"..."\*(C'\fR literals
+to be laid out as constant CoreFoundation strings.
+.IP "\fB\-fgnu\-runtime\fR" 4
+.IX Item "-fgnu-runtime"
+Generate object code compatible with the standard \s-1GNU\s0 Objective-C
+runtime.  This is the default for most types of systems.
+.IP "\fB\-fnext\-runtime\fR" 4
+.IX Item "-fnext-runtime"
+Generate output compatible with the NeXT runtime.  This is the default
+for NeXT-based systems, including Darwin and Mac \s-1OS X. \s0 The macro
+\&\f(CW\*(C`_\|_NEXT_RUNTIME_\|_\*(C'\fR is predefined if (and only if) this option is
+used.
+.IP "\fB\-fno\-nil\-receivers\fR" 4
+.IX Item "-fno-nil-receivers"
+Assume that all Objective-C message dispatches (\f(CW\*(C`[receiver
+message:arg]\*(C'\fR) in this translation unit ensure that the receiver is
+not \f(CW\*(C`nil\*(C'\fR.  This allows for more efficient entry points in the
+runtime to be used.  This option is only available in conjunction with
+the NeXT runtime and \s-1ABI\s0 version 0 or 1.
+.IP "\fB\-fobjc\-abi\-version=\fR\fIn\fR" 4
+.IX Item "-fobjc-abi-version=n"
+Use version \fIn\fR of the Objective-C \s-1ABI\s0 for the selected runtime.
+This option is currently supported only for the NeXT runtime.  In that
+case, Version 0 is the traditional (32\-bit) \s-1ABI\s0 without support for
+properties and other Objective-C 2.0 additions.  Version 1 is the
+traditional (32\-bit) \s-1ABI\s0 with support for properties and other
+Objective-C 2.0 additions.  Version 2 is the modern (64\-bit) \s-1ABI. \s0 If
+nothing is specified, the default is Version 0 on 32\-bit target
+machines, and Version 2 on 64\-bit target machines.
+.IP "\fB\-fobjc\-call\-cxx\-cdtors\fR" 4
+.IX Item "-fobjc-call-cxx-cdtors"
+For each Objective-C class, check if any of its instance variables is a
+\&\*(C+ object with a non-trivial default constructor.  If so, synthesize a
+special \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR instance method which runs
+non-trivial default constructors on any such instance variables, in order,
+and then return \f(CW\*(C`self\*(C'\fR.  Similarly, check if any instance variable
+is a \*(C+ object with a non-trivial destructor, and if so, synthesize a
+special \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR method which runs
+all such default destructors, in reverse order.
+.Sp
+The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR
+methods thusly generated only operate on instance variables
+declared in the current Objective-C class, and not those inherited
+from superclasses.  It is the responsibility of the Objective-C
+runtime to invoke all such methods in an object's inheritance
+hierarchy.  The \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR methods are invoked
+by the runtime immediately after a new object instance is allocated;
+the \f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods are invoked immediately
+before the runtime deallocates an object instance.
+.Sp
+As of this writing, only the NeXT runtime on Mac \s-1OS X 10.4\s0 and later has
+support for invoking the \f(CW\*(C`\- (id) .cxx_construct\*(C'\fR and
+\&\f(CW\*(C`\- (void) .cxx_destruct\*(C'\fR methods.
+.IP "\fB\-fobjc\-direct\-dispatch\fR" 4
+.IX Item "-fobjc-direct-dispatch"
+Allow fast jumps to the message dispatcher.  On Darwin this is
+accomplished via the comm page.
+.IP "\fB\-fobjc\-exceptions\fR" 4
+.IX Item "-fobjc-exceptions"
+Enable syntactic support for structured exception handling in
+Objective-C, similar to what is offered by \*(C+ and Java.  This option
+is required to use the Objective-C keywords \f(CW@try\fR,
+\&\f(CW@throw\fR, \f(CW@catch\fR, \f(CW@finally\fR and
+\&\f(CW@synchronized\fR.  This option is available with both the \s-1GNU\s0
+runtime and the NeXT runtime (but not available in conjunction with
+the NeXT runtime on Mac \s-1OS X 10.2\s0 and earlier).
+.IP "\fB\-fobjc\-gc\fR" 4
+.IX Item "-fobjc-gc"
+Enable garbage collection (\s-1GC\s0) in Objective-C and Objective\-\*(C+
+programs.  This option is only available with the NeXT runtime; the
+\&\s-1GNU\s0 runtime has a different garbage collection implementation that
+does not require special compiler flags.
+.IP "\fB\-fobjc\-nilcheck\fR" 4
+.IX Item "-fobjc-nilcheck"
+For the NeXT runtime with version 2 of the \s-1ABI,\s0 check for a nil
+receiver in method invocations before doing the actual method call.
+This is the default and can be disabled using
+\&\fB\-fno\-objc\-nilcheck\fR.  Class methods and super calls are never
+checked for nil in this way no matter what this flag is set to.
+Currently this flag does nothing when the \s-1GNU\s0 runtime, or an older
+version of the NeXT runtime \s-1ABI,\s0 is used.
+.IP "\fB\-fobjc\-std=objc1\fR" 4
+.IX Item "-fobjc-std=objc1"
+Conform to the language syntax of Objective-C 1.0, the language
+recognized by \s-1GCC 4.0. \s0 This only affects the Objective-C additions to
+the C/\*(C+ language; it does not affect conformance to C/\*(C+ standards,
+which is controlled by the separate C/\*(C+ dialect option flags.  When
+this option is used with the Objective-C or Objective\-\*(C+ compiler,
+any Objective-C syntax that is not recognized by \s-1GCC 4.0\s0 is rejected.
+This is useful if you need to make sure that your Objective-C code can
+be compiled with older versions of \s-1GCC.\s0
+.IP "\fB\-freplace\-objc\-classes\fR" 4
+.IX Item "-freplace-objc-classes"
+Emit a special marker instructing \fB\f(BIld\fB\|(1)\fR not to statically link in
+the resulting object file, and allow \fB\f(BIdyld\fB\|(1)\fR to load it in at
+run time instead.  This is used in conjunction with the Fix-and-Continue
+debugging mode, where the object file in question may be recompiled and
+dynamically reloaded in the course of program execution, without the need
+to restart the program itself.  Currently, Fix-and-Continue functionality
+is only available in conjunction with the NeXT runtime on Mac \s-1OS X 10.3\s0
+and later.
+.IP "\fB\-fzero\-link\fR" 4
+.IX Item "-fzero-link"
+When compiling for the NeXT runtime, the compiler ordinarily replaces calls
+to \f(CW\*(C`objc_getClass("...")\*(C'\fR (when the name of the class is known at
+compile time) with static class references that get initialized at load time,
+which improves run-time performance.  Specifying the \fB\-fzero\-link\fR flag
+suppresses this behavior and causes calls to \f(CW\*(C`objc_getClass("...")\*(C'\fR
+to be retained.  This is useful in Zero-Link debugging mode, since it allows
+for individual class implementations to be modified during program execution.
+The \s-1GNU\s0 runtime currently always retains calls to \f(CW\*(C`objc_get_class("...")\*(C'\fR
+regardless of command-line options.
+.IP "\fB\-gen\-decls\fR" 4
+.IX Item "-gen-decls"
+Dump interface declarations for all classes seen in the source file to a
+file named \fI\fIsourcename\fI.decl\fR.
+.IP "\fB\-Wassign\-intercept\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wassign-intercept (Objective-C and Objective- only)"
+Warn whenever an Objective-C assignment is being intercepted by the
+garbage collector.
+.IP "\fB\-Wno\-protocol\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-protocol (Objective-C and Objective- only)"
+If a class is declared to implement a protocol, a warning is issued for
+every method in the protocol that is not implemented by the class.  The
+default behavior is to issue a warning for every method not explicitly
+implemented in the class, even if a method implementation is inherited
+from the superclass.  If you use the \fB\-Wno\-protocol\fR option, then
+methods inherited from the superclass are considered to be implemented,
+and no warning is issued for them.
+.IP "\fB\-Wselector\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wselector (Objective-C and Objective- only)"
+Warn if multiple methods of different types for the same selector are
+found during compilation.  The check is performed on the list of methods
+in the final stage of compilation.  Additionally, a check is performed
+for each selector appearing in a \f(CW\*(C`@selector(...)\*(C'\fR
+expression, and a corresponding method for that selector has been found
+during compilation.  Because these checks scan the method table only at
+the end of compilation, these warnings are not produced if the final
+stage of compilation is not reached, for example because an error is
+found during compilation, or because the \fB\-fsyntax\-only\fR option is
+being used.
+.IP "\fB\-Wstrict\-selector\-match\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wstrict-selector-match (Objective-C and Objective- only)"
+Warn if multiple methods with differing argument and/or return types are
+found for a given selector when attempting to send a message using this
+selector to a receiver of type \f(CW\*(C`id\*(C'\fR or \f(CW\*(C`Class\*(C'\fR.  When this flag
+is off (which is the default behavior), the compiler omits such warnings
+if any differences found are confined to types that share the same size
+and alignment.
+.IP "\fB\-Wundeclared\-selector\fR (Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wundeclared-selector (Objective-C and Objective- only)"
+Warn if a \f(CW\*(C`@selector(...)\*(C'\fR expression referring to an
+undeclared selector is found.  A selector is considered undeclared if no
+method with that name has been declared before the
+\&\f(CW\*(C`@selector(...)\*(C'\fR expression, either explicitly in an
+\&\f(CW@interface\fR or \f(CW@protocol\fR declaration, or implicitly in
+an \f(CW@implementation\fR section.  This option always performs its
+checks as soon as a \f(CW\*(C`@selector(...)\*(C'\fR expression is found,
+while \fB\-Wselector\fR only performs its checks in the final stage of
+compilation.  This also enforces the coding style convention
+that methods and selectors must be declared before being used.
+.IP "\fB\-print\-objc\-runtime\-info\fR" 4
+.IX Item "-print-objc-runtime-info"
+Generate C header describing the largest structure that is passed by
+value, if any.
+.SS "Options to Control Diagnostic Messages Formatting"
+.IX Subsection "Options to Control Diagnostic Messages Formatting"
+Traditionally, diagnostic messages have been formatted irrespective of
+the output device's aspect (e.g. its width, ...).  You can use the
+options described below
+to control the formatting algorithm for diagnostic messages, 
+e.g. how many characters per line, how often source location
+information should be reported.  Note that some language front ends may not
+honor these options.
+.IP "\fB\-fmessage\-length=\fR\fIn\fR" 4
+.IX Item "-fmessage-length=n"
+Try to format error messages so that they fit on lines of about \fIn\fR
+characters.  The default is 72 characters for \fBg++\fR and 0 for the rest of
+the front ends supported by \s-1GCC. \s0 If \fIn\fR is zero, then no
+line-wrapping is done; each error message appears on a single
+line.
+.IP "\fB\-fdiagnostics\-show\-location=once\fR" 4
+.IX Item "-fdiagnostics-show-location=once"
+Only meaningful in line-wrapping mode.  Instructs the diagnostic messages
+reporter to emit source location information \fIonce\fR; that is, in
+case the message is too long to fit on a single physical line and has to
+be wrapped, the source location won't be emitted (as prefix) again,
+over and over, in subsequent continuation lines.  This is the default
+behavior.
+.IP "\fB\-fdiagnostics\-show\-location=every\-line\fR" 4
+.IX Item "-fdiagnostics-show-location=every-line"
+Only meaningful in line-wrapping mode.  Instructs the diagnostic
+messages reporter to emit the same source location information (as
+prefix) for physical lines that result from the process of breaking
+a message which is too long to fit on a single line.
+.IP "\fB\-fdiagnostics\-color[=\fR\fI\s-1WHEN\s0\fR\fB]\fR" 4
+.IX Item "-fdiagnostics-color[=WHEN]"
+.PD 0
+.IP "\fB\-fno\-diagnostics\-color\fR" 4
+.IX Item "-fno-diagnostics-color"
+.PD
+Use color in diagnostics.  \fI\s-1WHEN\s0\fR is \fBnever\fR, \fBalways\fR,
+or \fBauto\fR.  The default is \fBnever\fR if \fB\s-1GCC_COLORS\s0\fR environment
+variable isn't present in the environment, and \fBauto\fR otherwise.
+\&\fBauto\fR means to use color only when the standard error is a terminal.
+The forms \fB\-fdiagnostics\-color\fR and \fB\-fno\-diagnostics\-color\fR are
+aliases for \fB\-fdiagnostics\-color=always\fR and
+\&\fB\-fdiagnostics\-color=never\fR, respectively.
+.Sp
+The colors are defined by the environment variable \fB\s-1GCC_COLORS\s0\fR.
+Its value is a colon-separated list of capabilities and Select Graphic
+Rendition (\s-1SGR\s0) substrings. \s-1SGR\s0 commands are interpreted by the
+terminal or terminal emulator.  (See the section in the documentation
+of your text terminal for permitted values and their meanings as
+character attributes.)  These substring values are integers in decimal
+representation and can be concatenated with semicolons.
+Common values to concatenate include
+\&\fB1\fR for bold,
+\&\fB4\fR for underline,
+\&\fB5\fR for blink,
+\&\fB7\fR for inverse,
+\&\fB39\fR for default foreground color,
+\&\fB30\fR to \fB37\fR for foreground colors,
+\&\fB90\fR to \fB97\fR for 16\-color mode foreground colors,
+\&\fB38;5;0\fR to \fB38;5;255\fR
+for 88\-color and 256\-color modes foreground colors,
+\&\fB49\fR for default background color,
+\&\fB40\fR to \fB47\fR for background colors,
+\&\fB100\fR to \fB107\fR for 16\-color mode background colors,
+and \fB48;5;0\fR to \fB48;5;255\fR
+for 88\-color and 256\-color modes background colors.
+.Sp
+The default \fB\s-1GCC_COLORS\s0\fR is
+\&\fBerror=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01\fR
+where \fB01;31\fR is bold red, \fB01;35\fR is bold magenta,
+\&\fB01;36\fR is bold cyan, \fB01;32\fR is bold green and
+\&\fB01\fR is bold. Setting \fB\s-1GCC_COLORS\s0\fR to the empty
+string disables colors.
+Supported capabilities are as follows.
+.RS 4
+.ie n .IP """error=""" 4
+.el .IP "\f(CWerror=\fR" 4
+.IX Item "error="
+\&\s-1SGR\s0 substring for error: markers.
+.ie n .IP """warning=""" 4
+.el .IP "\f(CWwarning=\fR" 4
+.IX Item "warning="
+\&\s-1SGR\s0 substring for warning: markers.
+.ie n .IP """note=""" 4
+.el .IP "\f(CWnote=\fR" 4
+.IX Item "note="
+\&\s-1SGR\s0 substring for note: markers.
+.ie n .IP """caret=""" 4
+.el .IP "\f(CWcaret=\fR" 4
+.IX Item "caret="
+\&\s-1SGR\s0 substring for caret line.
+.ie n .IP """locus=""" 4
+.el .IP "\f(CWlocus=\fR" 4
+.IX Item "locus="
+\&\s-1SGR\s0 substring for location information, \fBfile:line\fR or
+\&\fBfile:line:column\fR etc.
+.ie n .IP """quote=""" 4
+.el .IP "\f(CWquote=\fR" 4
+.IX Item "quote="
+\&\s-1SGR\s0 substring for information printed within quotes.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fno\-diagnostics\-show\-option\fR" 4
+.IX Item "-fno-diagnostics-show-option"
+By default, each diagnostic emitted includes text indicating the
+command-line option that directly controls the diagnostic (if such an
+option is known to the diagnostic machinery).  Specifying the
+\&\fB\-fno\-diagnostics\-show\-option\fR flag suppresses that behavior.
+.IP "\fB\-fno\-diagnostics\-show\-caret\fR" 4
+.IX Item "-fno-diagnostics-show-caret"
+By default, each diagnostic emitted includes the original source line
+and a caret '^' indicating the column.  This option suppresses this
+information.
+.SS "Options to Request or Suppress Warnings"
+.IX Subsection "Options to Request or Suppress Warnings"
+Warnings are diagnostic messages that report constructions that
+are not inherently erroneous but that are risky or suggest there
+may have been an error.
+.PP
+The following language-independent options do not enable specific
+warnings but control the kinds of diagnostics produced by \s-1GCC.\s0
+.IP "\fB\-fsyntax\-only\fR" 4
+.IX Item "-fsyntax-only"
+Check the code for syntax errors, but don't do anything beyond that.
+.IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
+.IX Item "-fmax-errors=n"
+Limits the maximum number of error messages to \fIn\fR, at which point
+\&\s-1GCC\s0 bails out rather than attempting to continue processing the source
+code.  If \fIn\fR is 0 (the default), there is no limit on the number
+of error messages produced.  If \fB\-Wfatal\-errors\fR is also
+specified, then \fB\-Wfatal\-errors\fR takes precedence over this
+option.
+.IP "\fB\-w\fR" 4
+.IX Item "-w"
+Inhibit all warning messages.
+.IP "\fB\-Werror\fR" 4
+.IX Item "-Werror"
+Make all warnings into errors.
+.IP "\fB\-Werror=\fR" 4
+.IX Item "-Werror="
+Make the specified warning into an error.  The specifier for a warning
+is appended; for example \fB\-Werror=switch\fR turns the warnings
+controlled by \fB\-Wswitch\fR into errors.  This switch takes a
+negative form, to be used to negate \fB\-Werror\fR for specific
+warnings; for example \fB\-Wno\-error=switch\fR makes
+\&\fB\-Wswitch\fR warnings not be errors, even when \fB\-Werror\fR
+is in effect.
+.Sp
+The warning message for each controllable warning includes the
+option that controls the warning.  That option can then be used with
+\&\fB\-Werror=\fR and \fB\-Wno\-error=\fR as described above.
+(Printing of the option in the warning message can be disabled using the
+\&\fB\-fno\-diagnostics\-show\-option\fR flag.)
+.Sp
+Note that specifying \fB\-Werror=\fR\fIfoo\fR automatically implies
+\&\fB\-W\fR\fIfoo\fR.  However, \fB\-Wno\-error=\fR\fIfoo\fR does not
+imply anything.
+.IP "\fB\-Wfatal\-errors\fR" 4
+.IX Item "-Wfatal-errors"
+This option causes the compiler to abort compilation on the first error
+occurred rather than trying to keep going and printing further error
+messages.
+.PP
+You can request many specific warnings with options beginning with
+\&\fB\-W\fR, for example \fB\-Wimplicit\fR to request warnings on
+implicit declarations.  Each of these specific warning options also
+has a negative form beginning \fB\-Wno\-\fR to turn off warnings; for
+example, \fB\-Wno\-implicit\fR.  This manual lists only one of the
+two forms, whichever is not the default.  For further
+language-specific options also refer to \fB\*(C+ Dialect Options\fR and
+\&\fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
+.PP
+When an unrecognized warning option is requested (e.g.,
+\&\fB\-Wunknown\-warning\fR), \s-1GCC\s0 emits a diagnostic stating
+that the option is not recognized.  However, if the \fB\-Wno\-\fR form
+is used, the behavior is slightly different: no diagnostic is
+produced for \fB\-Wno\-unknown\-warning\fR unless other diagnostics
+are being produced.  This allows the use of new \fB\-Wno\-\fR options
+with old compilers, but if something goes wrong, the compiler
+warns that an unrecognized option is present.
+.IP "\fB\-Wpedantic\fR" 4
+.IX Item "-Wpedantic"
+.PD 0
+.IP "\fB\-pedantic\fR" 4
+.IX Item "-pedantic"
+.PD
+Issue all the warnings demanded by strict \s-1ISO C\s0 and \s-1ISO \*(C+\s0;
+reject all programs that use forbidden extensions, and some other
+programs that do not follow \s-1ISO C\s0 and \s-1ISO \*(C+. \s0 For \s-1ISO C,\s0 follows the
+version of the \s-1ISO C\s0 standard specified by any \fB\-std\fR option used.
+.Sp
+Valid \s-1ISO C\s0 and \s-1ISO \*(C+\s0 programs should compile properly with or without
+this option (though a rare few require \fB\-ansi\fR or a
+\&\fB\-std\fR option specifying the required version of \s-1ISO C\s0).  However,
+without this option, certain \s-1GNU\s0 extensions and traditional C and \*(C+
+features are supported as well.  With this option, they are rejected.
+.Sp
+\&\fB\-Wpedantic\fR does not cause warning messages for use of the
+alternate keywords whose names begin and end with \fB_\|_\fR.  Pedantic
+warnings are also disabled in the expression that follows
+\&\f(CW\*(C`_\|_extension_\|_\*(C'\fR.  However, only system header files should use
+these escape routes; application programs should avoid them.
+.Sp
+Some users try to use \fB\-Wpedantic\fR to check programs for strict \s-1ISO
+C\s0 conformance.  They soon find that it does not do quite what they want:
+it finds some non-ISO practices, but not all\-\-\-only those for which
+\&\s-1ISO C \s0\fIrequires\fR a diagnostic, and some others for which
+diagnostics have been added.
+.Sp
+A feature to report any failure to conform to \s-1ISO C\s0 might be useful in
+some instances, but would require considerable additional work and would
+be quite different from \fB\-Wpedantic\fR.  We don't have plans to
+support such a feature in the near future.
+.Sp
+Where the standard specified with \fB\-std\fR represents a \s-1GNU\s0
+extended dialect of C, such as \fBgnu90\fR or \fBgnu99\fR, there is a
+corresponding \fIbase standard\fR, the version of \s-1ISO C\s0 on which the \s-1GNU\s0
+extended dialect is based.  Warnings from \fB\-Wpedantic\fR are given
+where they are required by the base standard.  (It does not make sense
+for such warnings to be given only for features not in the specified \s-1GNU
+C\s0 dialect, since by definition the \s-1GNU\s0 dialects of C include all
+features the compiler supports with the given option, and there would be
+nothing to warn about.)
+.IP "\fB\-pedantic\-errors\fR" 4
+.IX Item "-pedantic-errors"
+Like \fB\-Wpedantic\fR, except that errors are produced rather than
+warnings.
+.IP "\fB\-Wall\fR" 4
+.IX Item "-Wall"
+This enables all the warnings about constructions that some users
+consider questionable, and that are easy to avoid (or modify to
+prevent the warning), even in conjunction with macros.  This also
+enables some language-specific warnings described in \fB\*(C+ Dialect
+Options\fR and \fBObjective-C and Objective\-\*(C+ Dialect Options\fR.
+.Sp
+\&\fB\-Wall\fR turns on the following warning flags:
+.Sp
+\&\fB\-Waddress   
+\&\-Warray\-bounds\fR (only with\fB \fR\fB\-O2\fR)  
+\&\fB\-Wc++11\-compat  
+\&\-Wchar\-subscripts  
+\&\-Wenum\-compare\fR (in C/ObjC; this is on by default in \*(C+) 
+\&\fB\-Wimplicit\-int\fR (C and Objective-C only) 
+\&\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only) 
+\&\fB\-Wcomment  
+\&\-Wformat   
+\&\-Wmain\fR (only for C/ObjC and unless\fB \fR\fB\-ffreestanding\fR)  
+\&\fB\-Wmaybe\-uninitialized 
+\&\-Wmissing\-braces\fR (only for C/ObjC) 
+\&\fB\-Wnonnull  
+\&\-Wopenmp\-simd 
+\&\-Wparentheses  
+\&\-Wpointer\-sign  
+\&\-Wreorder   
+\&\-Wreturn\-type  
+\&\-Wsequence\-point  
+\&\-Wsign\-compare\fR (only in \*(C+)  
+\&\fB\-Wstrict\-aliasing  
+\&\-Wstrict\-overflow=1  
+\&\-Wswitch  
+\&\-Wtrigraphs  
+\&\-Wuninitialized  
+\&\-Wunknown\-pragmas  
+\&\-Wunused\-function  
+\&\-Wunused\-label     
+\&\-Wunused\-value     
+\&\-Wunused\-variable  
+\&\-Wvolatile\-register\-var\fR
+.Sp
+Note that some warning flags are not implied by \fB\-Wall\fR.  Some of
+them warn about constructions that users generally do not consider
+questionable, but which occasionally you might wish to check for;
+others warn about constructions that are necessary or hard to avoid in
+some cases, and there is no simple way to modify the code to suppress
+the warning. Some of them are enabled by \fB\-Wextra\fR but many of
+them must be enabled individually.
+.IP "\fB\-Wextra\fR" 4
+.IX Item "-Wextra"
+This enables some extra warning flags that are not enabled by
+\&\fB\-Wall\fR. (This option used to be called \fB\-W\fR.  The older
+name is still supported, but the newer name is more descriptive.)
+.Sp
+\&\fB\-Wclobbered  
+\&\-Wempty\-body  
+\&\-Wignored\-qualifiers 
+\&\-Wmissing\-field\-initializers  
+\&\-Wmissing\-parameter\-type\fR (C only)  
+\&\fB\-Wold\-style\-declaration\fR (C only)  
+\&\fB\-Woverride\-init  
+\&\-Wsign\-compare  
+\&\-Wtype\-limits  
+\&\-Wuninitialized  
+\&\-Wunused\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR) 
+\&\fB\-Wunused\-but\-set\-parameter\fR (only with\fB \fR\fB\-Wunused\fR\fB \fRor\fB \fR\fB\-Wall\fR)  \fB \fR
+.Sp
+The option \fB\-Wextra\fR also prints warning messages for the
+following cases:
+.RS 4
+.IP "\(bu" 4
+A pointer is compared against integer zero with \fB<\fR, \fB<=\fR,
+\&\fB>\fR, or \fB>=\fR.
+.IP "\(bu" 4
+(\*(C+ only) An enumerator and a non-enumerator both appear in a
+conditional expression.
+.IP "\(bu" 4
+(\*(C+ only) Ambiguous virtual bases.
+.IP "\(bu" 4
+(\*(C+ only) Subscripting an array that has been declared \fBregister\fR.
+.IP "\(bu" 4
+(\*(C+ only) Taking the address of a variable that has been declared
+\&\fBregister\fR.
+.IP "\(bu" 4
+(\*(C+ only) A base class is not initialized in a derived class's copy
+constructor.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wchar\-subscripts\fR" 4
+.IX Item "-Wchar-subscripts"
+Warn if an array subscript has type \f(CW\*(C`char\*(C'\fR.  This is a common cause
+of error, as programmers often forget that this type is signed on some
+machines.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wcomment\fR" 4
+.IX Item "-Wcomment"
+Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
+comment, or whenever a Backslash-Newline appears in a \fB//\fR comment.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wno\-coverage\-mismatch\fR" 4
+.IX Item "-Wno-coverage-mismatch"
+Warn if feedback profiles do not match when using the
+\&\fB\-fprofile\-use\fR option.
+If a source file is changed between compiling with \fB\-fprofile\-gen\fR and
+with \fB\-fprofile\-use\fR, the files with the profile feedback can fail
+to match the source file and \s-1GCC\s0 cannot use the profile feedback
+information.  By default, this warning is enabled and is treated as an
+error.  \fB\-Wno\-coverage\-mismatch\fR can be used to disable the
+warning or \fB\-Wno\-error=coverage\-mismatch\fR can be used to
+disable the error.  Disabling the error for this warning can result in
+poorly optimized code and is useful only in the
+case of very minor changes such as bug fixes to an existing code-base.
+Completely disabling the warning is not recommended.
+.IP "\fB\-Wno\-cpp\fR" 4
+.IX Item "-Wno-cpp"
+(C, Objective-C, \*(C+, Objective\-\*(C+ and Fortran only)
+.Sp
+Suppress warning messages emitted by \f(CW\*(C`#warning\*(C'\fR directives.
+.IP "\fB\-Wdouble\-promotion\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wdouble-promotion (C, , Objective-C and Objective- only)"
+Give a warning when a value of type \f(CW\*(C`float\*(C'\fR is implicitly
+promoted to \f(CW\*(C`double\*(C'\fR.  CPUs with a 32\-bit \*(L"single-precision\*(R"
+floating-point unit implement \f(CW\*(C`float\*(C'\fR in hardware, but emulate
+\&\f(CW\*(C`double\*(C'\fR in software.  On such a machine, doing computations
+using \f(CW\*(C`double\*(C'\fR values is much more expensive because of the
+overhead required for software emulation.
+.Sp
+It is easy to accidentally do computations with \f(CW\*(C`double\*(C'\fR because
+floating-point literals are implicitly of type \f(CW\*(C`double\*(C'\fR.  For
+example, in:
+.Sp
+.Vb 4
+\&        float area(float radius)
+\&        {
+\&           return 3.14159 * radius * radius;
+\&        }
+.Ve
+.Sp
+the compiler performs the entire computation with \f(CW\*(C`double\*(C'\fR
+because the floating-point literal is a \f(CW\*(C`double\*(C'\fR.
+.IP "\fB\-Wformat\fR" 4
+.IX Item "-Wformat"
+.PD 0
+.IP "\fB\-Wformat=\fR\fIn\fR" 4
+.IX Item "-Wformat=n"
+.PD
+Check calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR, etc., to make sure that
+the arguments supplied have types appropriate to the format string
+specified, and that the conversions specified in the format string make
+sense.  This includes standard functions, and others specified by format
+attributes, in the \f(CW\*(C`printf\*(C'\fR,
+\&\f(CW\*(C`scanf\*(C'\fR, \f(CW\*(C`strftime\*(C'\fR and \f(CW\*(C`strfmon\*(C'\fR (an X/Open extension,
+not in the C standard) families (or other target-specific families).
+Which functions are checked without format attributes having been
+specified depends on the standard version selected, and such checks of
+functions without the attribute specified are disabled by
+\&\fB\-ffreestanding\fR or \fB\-fno\-builtin\fR.
+.Sp
+The formats are checked against the format features supported by \s-1GNU\s0
+libc version 2.2.  These include all \s-1ISO C90\s0 and C99 features, as well
+as features from the Single Unix Specification and some \s-1BSD\s0 and \s-1GNU\s0
+extensions.  Other library implementations may not support all these
+features; \s-1GCC\s0 does not support warning about features that go beyond a
+particular library's limitations.  However, if \fB\-Wpedantic\fR is used
+with \fB\-Wformat\fR, warnings are given about format features not
+in the selected standard version (but not for \f(CW\*(C`strfmon\*(C'\fR formats,
+since those are not in any version of the C standard).
+.RS 4
+.IP "\fB\-Wformat=1\fR" 4
+.IX Item "-Wformat=1"
+.PD 0
+.IP "\fB\-Wformat\fR" 4
+.IX Item "-Wformat"
+.PD
+Option \fB\-Wformat\fR is equivalent to \fB\-Wformat=1\fR, and
+\&\fB\-Wno\-format\fR is equivalent to \fB\-Wformat=0\fR.  Since
+\&\fB\-Wformat\fR also checks for null format arguments for several
+functions, \fB\-Wformat\fR also implies \fB\-Wnonnull\fR.  Some
+aspects of this level of format checking can be disabled by the
+options: \fB\-Wno\-format\-contains\-nul\fR,
+\&\fB\-Wno\-format\-extra\-args\fR, and \fB\-Wno\-format\-zero\-length\fR.
+\&\fB\-Wformat\fR is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wno\-format\-contains\-nul\fR" 4
+.IX Item "-Wno-format-contains-nul"
+If \fB\-Wformat\fR is specified, do not warn about format strings that
+contain \s-1NUL\s0 bytes.
+.IP "\fB\-Wno\-format\-extra\-args\fR" 4
+.IX Item "-Wno-format-extra-args"
+If \fB\-Wformat\fR is specified, do not warn about excess arguments to a
+\&\f(CW\*(C`printf\*(C'\fR or \f(CW\*(C`scanf\*(C'\fR format function.  The C standard specifies
+that such arguments are ignored.
+.Sp
+Where the unused arguments lie between used arguments that are
+specified with \fB$\fR operand number specifications, normally
+warnings are still given, since the implementation could not know what
+type to pass to \f(CW\*(C`va_arg\*(C'\fR to skip the unused arguments.  However,
+in the case of \f(CW\*(C`scanf\*(C'\fR formats, this option suppresses the
+warning if the unused arguments are all pointers, since the Single
+Unix Specification says that such unused arguments are allowed.
+.IP "\fB\-Wno\-format\-zero\-length\fR" 4
+.IX Item "-Wno-format-zero-length"
+If \fB\-Wformat\fR is specified, do not warn about zero-length formats.
+The C standard specifies that zero-length formats are allowed.
+.IP "\fB\-Wformat=2\fR" 4
+.IX Item "-Wformat=2"
+Enable \fB\-Wformat\fR plus additional format checks.  Currently
+equivalent to \fB\-Wformat \-Wformat\-nonliteral \-Wformat\-security
+\&\-Wformat\-y2k\fR.
+.IP "\fB\-Wformat\-nonliteral\fR" 4
+.IX Item "-Wformat-nonliteral"
+If \fB\-Wformat\fR is specified, also warn if the format string is not a
+string literal and so cannot be checked, unless the format function
+takes its format arguments as a \f(CW\*(C`va_list\*(C'\fR.
+.IP "\fB\-Wformat\-security\fR" 4
+.IX Item "-Wformat-security"
+If \fB\-Wformat\fR is specified, also warn about uses of format
+functions that represent possible security problems.  At present, this
+warns about calls to \f(CW\*(C`printf\*(C'\fR and \f(CW\*(C`scanf\*(C'\fR functions where the
+format string is not a string literal and there are no format arguments,
+as in \f(CW\*(C`printf (foo);\*(C'\fR.  This may be a security hole if the format
+string came from untrusted input and contains \fB\f(CB%n\fB\fR.  (This is
+currently a subset of what \fB\-Wformat\-nonliteral\fR warns about, but
+in future warnings may be added to \fB\-Wformat\-security\fR that are not
+included in \fB\-Wformat\-nonliteral\fR.)
+.IP "\fB\-Wformat\-y2k\fR" 4
+.IX Item "-Wformat-y2k"
+If \fB\-Wformat\fR is specified, also warn about \f(CW\*(C`strftime\*(C'\fR
+formats that may yield only a two-digit year.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wnonnull\fR" 4
+.IX Item "-Wnonnull"
+Warn about passing a null pointer for arguments marked as
+requiring a non-null value by the \f(CW\*(C`nonnull\*(C'\fR function attribute.
+.Sp
+\&\fB\-Wnonnull\fR is included in \fB\-Wall\fR and \fB\-Wformat\fR.  It
+can be disabled with the \fB\-Wno\-nonnull\fR option.
+.IP "\fB\-Winit\-self\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Winit-self (C, , Objective-C and Objective- only)"
+Warn about uninitialized variables that are initialized with themselves.
+Note this option can only be used with the \fB\-Wuninitialized\fR option.
+.Sp
+For example, \s-1GCC\s0 warns about \f(CW\*(C`i\*(C'\fR being uninitialized in the
+following snippet only when \fB\-Winit\-self\fR has been specified:
+.Sp
+.Vb 5
+\&        int f()
+\&        {
+\&          int i = i;
+\&          return i;
+\&        }
+.Ve
+.Sp
+This warning is enabled by \fB\-Wall\fR in \*(C+.
+.IP "\fB\-Wimplicit\-int\fR (C and Objective-C only)" 4
+.IX Item "-Wimplicit-int (C and Objective-C only)"
+Warn when a declaration does not specify a type.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wimplicit\-function\-declaration\fR (C and Objective-C only)" 4
+.IX Item "-Wimplicit-function-declaration (C and Objective-C only)"
+Give a warning whenever a function is used before being declared. In
+C99 mode (\fB\-std=c99\fR or \fB\-std=gnu99\fR), this warning is
+enabled by default and it is made into an error by
+\&\fB\-pedantic\-errors\fR. This warning is also enabled by
+\&\fB\-Wall\fR.
+.IP "\fB\-Wimplicit\fR (C and Objective-C only)" 4
+.IX Item "-Wimplicit (C and Objective-C only)"
+Same as \fB\-Wimplicit\-int\fR and \fB\-Wimplicit\-function\-declaration\fR.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wignored\-qualifiers\fR (C and \*(C+ only)" 4
+.IX Item "-Wignored-qualifiers (C and only)"
+Warn if the return type of a function has a type qualifier
+such as \f(CW\*(C`const\*(C'\fR.  For \s-1ISO C\s0 such a type qualifier has no effect,
+since the value returned by a function is not an lvalue.
+For \*(C+, the warning is only emitted for scalar types or \f(CW\*(C`void\*(C'\fR.
+\&\s-1ISO C\s0 prohibits qualified \f(CW\*(C`void\*(C'\fR return types on function
+definitions, so such return types always receive a warning
+even without this option.
+.Sp
+This warning is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wmain\fR" 4
+.IX Item "-Wmain"
+Warn if the type of \fBmain\fR is suspicious.  \fBmain\fR should be
+a function with external linkage, returning int, taking either zero
+arguments, two, or three arguments of appropriate types.  This warning
+is enabled by default in \*(C+ and is enabled by either \fB\-Wall\fR
+or \fB\-Wpedantic\fR.
+.IP "\fB\-Wmissing\-braces\fR" 4
+.IX Item "-Wmissing-braces"
+Warn if an aggregate or union initializer is not fully bracketed.  In
+the following example, the initializer for \fBa\fR is not fully
+bracketed, but that for \fBb\fR is fully bracketed.  This warning is
+enabled by \fB\-Wall\fR in C.
+.Sp
+.Vb 2
+\&        int a[2][2] = { 0, 1, 2, 3 };
+\&        int b[2][2] = { { 0, 1 }, { 2, 3 } };
+.Ve
+.Sp
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wmissing\-include\-dirs\fR (C, \*(C+, Objective-C and Objective\-\*(C+ only)" 4
+.IX Item "-Wmissing-include-dirs (C, , Objective-C and Objective- only)"
+Warn if a user-supplied include directory does not exist.
+.IP "\fB\-Wparentheses\fR" 4
+.IX Item "-Wparentheses"
+Warn if parentheses are omitted in certain contexts, such
+as when there is an assignment in a context where a truth value
+is expected, or when operators are nested whose precedence people
+often get confused about.
+.Sp
+Also warn if a comparison like \fBx<=y<=z\fR appears; this is
+equivalent to \fB(x<=y ? 1 : 0) <= z\fR, which is a different
+interpretation from that of ordinary mathematical notation.
+.Sp
+Also warn about constructions where there may be confusion to which
+\&\f(CW\*(C`if\*(C'\fR statement an \f(CW\*(C`else\*(C'\fR branch belongs.  Here is an example of
+such a case:
+.Sp
+.Vb 7
+\&        {
+\&          if (a)
+\&            if (b)
+\&              foo ();
+\&          else
+\&            bar ();
+\&        }
+.Ve
+.Sp
+In C/\*(C+, every \f(CW\*(C`else\*(C'\fR branch belongs to the innermost possible
+\&\f(CW\*(C`if\*(C'\fR statement, which in this example is \f(CW\*(C`if (b)\*(C'\fR.  This is
+often not what the programmer expected, as illustrated in the above
+example by indentation the programmer chose.  When there is the
+potential for this confusion, \s-1GCC\s0 issues a warning when this flag
+is specified.  To eliminate the warning, add explicit braces around
+the innermost \f(CW\*(C`if\*(C'\fR statement so there is no way the \f(CW\*(C`else\*(C'\fR
+can belong to the enclosing \f(CW\*(C`if\*(C'\fR.  The resulting code
+looks like this:
+.Sp
+.Vb 9
+\&        {
+\&          if (a)
+\&            {
+\&              if (b)
+\&                foo ();
+\&              else
+\&                bar ();
+\&            }
+\&        }
+.Ve
+.Sp
+Also warn for dangerous uses of the \s-1GNU\s0 extension to
+\&\f(CW\*(C`?:\*(C'\fR with omitted middle operand. When the condition
+in the \f(CW\*(C`?\*(C'\fR: operator is a boolean expression, the omitted value is
+always 1.  Often programmers expect it to be a value computed
+inside the conditional expression instead.
+.Sp
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wsequence\-point\fR" 4
+.IX Item "-Wsequence-point"
+Warn about code that may have undefined semantics because of violations
+of sequence point rules in the C and \*(C+ standards.
+.Sp
+The C and \*(C+ standards define the order in which expressions in a C/\*(C+
+program are evaluated in terms of \fIsequence points\fR, which represent
+a partial ordering between the execution of parts of the program: those
+executed before the sequence point, and those executed after it.  These
+occur after the evaluation of a full expression (one which is not part
+of a larger expression), after the evaluation of the first operand of a
+\&\f(CW\*(C`&&\*(C'\fR, \f(CW\*(C`||\*(C'\fR, \f(CW\*(C`? :\*(C'\fR or \f(CW\*(C`,\*(C'\fR (comma) operator, before a
+function is called (but after the evaluation of its arguments and the
+expression denoting the called function), and in certain other places.
+Other than as expressed by the sequence point rules, the order of
+evaluation of subexpressions of an expression is not specified.  All
+these rules describe only a partial order rather than a total order,
+since, for example, if two functions are called within one expression
+with no sequence point between them, the order in which the functions
+are called is not specified.  However, the standards committee have
+ruled that function calls do not overlap.
+.Sp
+It is not specified when between sequence points modifications to the
+values of objects take effect.  Programs whose behavior depends on this
+have undefined behavior; the C and \*(C+ standards specify that \*(L"Between
+the previous and next sequence point an object shall have its stored
+value modified at most once by the evaluation of an expression.
+Furthermore, the prior value shall be read only to determine the value
+to be stored.\*(R".  If a program breaks these rules, the results on any
+particular implementation are entirely unpredictable.
+.Sp
+Examples of code with undefined behavior are \f(CW\*(C`a = a++;\*(C'\fR, \f(CW\*(C`a[n]
+= b[n++]\*(C'\fR and \f(CW\*(C`a[i++] = i;\*(C'\fR.  Some more complicated cases are not
+diagnosed by this option, and it may give an occasional false positive
+result, but in general it has been found fairly effective at detecting
+this sort of problem in programs.
+.Sp
+The standard is worded confusingly, therefore there is some debate
+over the precise meaning of the sequence point rules in subtle cases.
+Links to discussions of the problem, including proposed formal
+definitions, may be found on the \s-1GCC\s0 readings page, at
+<\fBhttp://gcc.gnu.org/readings.html\fR>.
+.Sp
+This warning is enabled by \fB\-Wall\fR for C and \*(C+.
+.IP "\fB\-Wno\-return\-local\-addr\fR" 4
+.IX Item "-Wno-return-local-addr"
+Do not warn about returning a pointer (or in \*(C+, a reference) to a
+variable that goes out of scope after the function returns.
+.IP "\fB\-Wreturn\-type\fR" 4
+.IX Item "-Wreturn-type"
+Warn whenever a function is defined with a return type that defaults
+to \f(CW\*(C`int\*(C'\fR.  Also warn about any \f(CW\*(C`return\*(C'\fR statement with no
+return value in a function whose return type is not \f(CW\*(C`void\*(C'\fR
+(falling off the end of the function body is considered returning
+without a value), and about a \f(CW\*(C`return\*(C'\fR statement with an
+expression in a function whose return type is \f(CW\*(C`void\*(C'\fR.
+.Sp
+For \*(C+, a function without return type always produces a diagnostic
+message, even when \fB\-Wno\-return\-type\fR is specified.  The only
+exceptions are \fBmain\fR and functions defined in system headers.
+.Sp
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wswitch\fR" 4
+.IX Item "-Wswitch"
+Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
+and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
+enumeration.  (The presence of a \f(CW\*(C`default\*(C'\fR label prevents this
+warning.)  \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also
+provoke warnings when this option is used (even if there is a
+\&\f(CW\*(C`default\*(C'\fR label).
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wswitch\-default\fR" 4
+.IX Item "-Wswitch-default"
+Warn whenever a \f(CW\*(C`switch\*(C'\fR statement does not have a \f(CW\*(C`default\*(C'\fR
+case.
+.IP "\fB\-Wswitch\-enum\fR" 4
+.IX Item "-Wswitch-enum"
+Warn whenever a \f(CW\*(C`switch\*(C'\fR statement has an index of enumerated type
+and lacks a \f(CW\*(C`case\*(C'\fR for one or more of the named codes of that
+enumeration.  \f(CW\*(C`case\*(C'\fR labels outside the enumeration range also
+provoke warnings when this option is used.  The only difference
+between \fB\-Wswitch\fR and this option is that this option gives a
+warning about an omitted enumeration code even if there is a
+\&\f(CW\*(C`default\*(C'\fR label.
+.IP "\fB\-Wsync\-nand\fR (C and \*(C+ only)" 4
+.IX Item "-Wsync-nand (C and only)"
+Warn when \f(CW\*(C`_\|_sync_fetch_and_nand\*(C'\fR and \f(CW\*(C`_\|_sync_nand_and_fetch\*(C'\fR
+built-in functions are used.  These functions changed semantics in \s-1GCC 4.4.\s0
+.IP "\fB\-Wtrigraphs\fR" 4
+.IX Item "-Wtrigraphs"
+Warn if any trigraphs are encountered that might change the meaning of
+the program (trigraphs within comments are not warned about).
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-but\-set\-parameter\fR" 4
+.IX Item "-Wunused-but-set-parameter"
+Warn whenever a function parameter is assigned to, but otherwise unused
+(aside from its declaration).
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.Sp
+This warning is also enabled by \fB\-Wunused\fR together with
+\&\fB\-Wextra\fR.
+.IP "\fB\-Wunused\-but\-set\-variable\fR" 4
+.IX Item "-Wunused-but-set-variable"
+Warn whenever a local variable is assigned to, but otherwise unused
+(aside from its declaration).
+This warning is enabled by \fB\-Wall\fR.
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.Sp
+This warning is also enabled by \fB\-Wunused\fR, which is enabled
+by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-function\fR" 4
+.IX Item "-Wunused-function"
+Warn whenever a static function is declared but not defined or a
+non-inline static function is unused.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-label\fR" 4
+.IX Item "-Wunused-label"
+Warn whenever a label is declared but not used.
+This warning is enabled by \fB\-Wall\fR.
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.IP "\fB\-Wunused\-local\-typedefs\fR (C, Objective-C, \*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wunused-local-typedefs (C, Objective-C, and Objective- only)"
+Warn when a typedef locally defined in a function is not used.
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-parameter\fR" 4
+.IX Item "-Wunused-parameter"
+Warn whenever a function parameter is unused aside from its declaration.
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.IP "\fB\-Wno\-unused\-result\fR" 4
+.IX Item "-Wno-unused-result"
+Do not warn if a caller of a function marked with attribute
+\&\f(CW\*(C`warn_unused_result\*(C'\fR does not use
+its return value. The default is \fB\-Wunused\-result\fR.
+.IP "\fB\-Wunused\-variable\fR" 4
+.IX Item "-Wunused-variable"
+Warn whenever a local variable or non-constant static variable is unused
+aside from its declaration.
+This warning is enabled by \fB\-Wall\fR.
+.Sp
+To suppress this warning use the \fBunused\fR attribute.
+.IP "\fB\-Wunused\-value\fR" 4
+.IX Item "-Wunused-value"
+Warn whenever a statement computes a result that is explicitly not
+used. To suppress this warning cast the unused expression to
+\&\fBvoid\fR. This includes an expression-statement or the left-hand
+side of a comma expression that contains no side effects. For example,
+an expression such as \fBx[i,j]\fR causes a warning, while
+\&\fBx[(void)i,j]\fR does not.
+.Sp
+This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wunused\fR" 4
+.IX Item "-Wunused"
+All the above \fB\-Wunused\fR options combined.
+.Sp
+In order to get a warning about an unused function parameter, you must
+either specify \fB\-Wextra \-Wunused\fR (note that \fB\-Wall\fR implies
+\&\fB\-Wunused\fR), or separately specify \fB\-Wunused\-parameter\fR.
+.IP "\fB\-Wuninitialized\fR" 4
+.IX Item "-Wuninitialized"
+Warn if an automatic variable is used without first being initialized
+or if a variable may be clobbered by a \f(CW\*(C`setjmp\*(C'\fR call. In \*(C+,
+warn if a non-static reference or non-static \fBconst\fR member
+appears in a class without constructors.
+.Sp
+If you want to warn about code that uses the uninitialized value of the
+variable in its own initializer, use the \fB\-Winit\-self\fR option.
+.Sp
+These warnings occur for individual uninitialized or clobbered
+elements of structure, union or array variables as well as for
+variables that are uninitialized or clobbered as a whole.  They do
+not occur for variables or elements declared \f(CW\*(C`volatile\*(C'\fR.  Because
+these warnings depend on optimization, the exact variables or elements
+for which there are warnings depends on the precise optimization
+options and version of \s-1GCC\s0 used.
+.Sp
+Note that there may be no warning about a variable that is used only
+to compute a value that itself is never used, because such
+computations may be deleted by data flow analysis before the warnings
+are printed.
+.IP "\fB\-Wmaybe\-uninitialized\fR" 4
+.IX Item "-Wmaybe-uninitialized"
+For an automatic variable, if there exists a path from the function
+entry to a use of the variable that is initialized, but there exist
+some other paths for which the variable is not initialized, the compiler
+emits a warning if it cannot prove the uninitialized paths are not
+executed at run time. These warnings are made optional because \s-1GCC\s0 is
+not smart enough to see all the reasons why the code might be correct
+in spite of appearing to have an error.  Here is one example of how
+this can happen:
+.Sp
+.Vb 12
+\&        {
+\&          int x;
+\&          switch (y)
+\&            {
+\&            case 1: x = 1;
+\&              break;
+\&            case 2: x = 4;
+\&              break;
+\&            case 3: x = 5;
+\&            }
+\&          foo (x);
+\&        }
+.Ve
+.Sp
+If the value of \f(CW\*(C`y\*(C'\fR is always 1, 2 or 3, then \f(CW\*(C`x\*(C'\fR is
+always initialized, but \s-1GCC\s0 doesn't know this. To suppress the
+warning, you need to provide a default case with \fIassert\fR\|(0) or
+similar code.
+.Sp
+This option also warns when a non-volatile automatic variable might be
+changed by a call to \f(CW\*(C`longjmp\*(C'\fR.  These warnings as well are possible
+only in optimizing compilation.
+.Sp
+The compiler sees only the calls to \f(CW\*(C`setjmp\*(C'\fR.  It cannot know
+where \f(CW\*(C`longjmp\*(C'\fR will be called; in fact, a signal handler could
+call it at any point in the code.  As a result, you may get a warning
+even when there is in fact no problem because \f(CW\*(C`longjmp\*(C'\fR cannot
+in fact be called at the place that would cause a problem.
+.Sp
+Some spurious warnings can be avoided if you declare all the functions
+you use that never return as \f(CW\*(C`noreturn\*(C'\fR.
+.Sp
+This warning is enabled by \fB\-Wall\fR or \fB\-Wextra\fR.
+.IP "\fB\-Wunknown\-pragmas\fR" 4
+.IX Item "-Wunknown-pragmas"
+Warn when a \f(CW\*(C`#pragma\*(C'\fR directive is encountered that is not understood by 
+\&\s-1GCC. \s0 If this command-line option is used, warnings are even issued
+for unknown pragmas in system header files.  This is not the case if
+the warnings are only enabled by the \fB\-Wall\fR command-line option.
+.IP "\fB\-Wno\-pragmas\fR" 4
+.IX Item "-Wno-pragmas"
+Do not warn about misuses of pragmas, such as incorrect parameters,
+invalid syntax, or conflicts between pragmas.  See also
+\&\fB\-Wunknown\-pragmas\fR.
+.IP "\fB\-Wstrict\-aliasing\fR" 4
+.IX Item "-Wstrict-aliasing"
+This option is only active when \fB\-fstrict\-aliasing\fR is active.
+It warns about code that might break the strict aliasing rules that the
+compiler is using for optimization.  The warning does not catch all
+cases, but does attempt to catch the more common pitfalls.  It is
+included in \fB\-Wall\fR.
+It is equivalent to \fB\-Wstrict\-aliasing=3\fR
+.IP "\fB\-Wstrict\-aliasing=n\fR" 4
+.IX Item "-Wstrict-aliasing=n"
+This option is only active when \fB\-fstrict\-aliasing\fR is active.
+It warns about code that might break the strict aliasing rules that the
+compiler is using for optimization.
+Higher levels correspond to higher accuracy (fewer false positives).
+Higher levels also correspond to more effort, similar to the way \fB\-O\fR 
+works.
+\&\fB\-Wstrict\-aliasing\fR is equivalent to \fB\-Wstrict\-aliasing=3\fR.
+.Sp
+Level 1: Most aggressive, quick, least accurate.
+Possibly useful when higher levels
+do not warn but \fB\-fstrict\-aliasing\fR still breaks the code, as it has very few
+false negatives.  However, it has many false positives.
+Warns for all pointer conversions between possibly incompatible types,
+even if never dereferenced.  Runs in the front end only.
+.Sp
+Level 2: Aggressive, quick, not too precise.
+May still have many false positives (not as many as level 1 though),
+and few false negatives (but possibly more than level 1).
+Unlike level 1, it only warns when an address is taken.  Warns about
+incomplete types.  Runs in the front end only.
+.Sp
+Level 3 (default for \fB\-Wstrict\-aliasing\fR):
+Should have very few false positives and few false
+negatives.  Slightly slower than levels 1 or 2 when optimization is enabled.
+Takes care of the common pun+dereference pattern in the front end:
+\&\f(CW\*(C`*(int*)&some_float\*(C'\fR.
+If optimization is enabled, it also runs in the back end, where it deals
+with multiple statement cases using flow-sensitive points-to information.
+Only warns when the converted pointer is dereferenced.
+Does not warn about incomplete types.
+.IP "\fB\-Wstrict\-overflow\fR" 4
+.IX Item "-Wstrict-overflow"
+.PD 0
+.IP "\fB\-Wstrict\-overflow=\fR\fIn\fR" 4
+.IX Item "-Wstrict-overflow=n"
+.PD
+This option is only active when \fB\-fstrict\-overflow\fR is active.
+It warns about cases where the compiler optimizes based on the
+assumption that signed overflow does not occur.  Note that it does not
+warn about all cases where the code might overflow: it only warns
+about cases where the compiler implements some optimization.  Thus
+this warning depends on the optimization level.
+.Sp
+An optimization that assumes that signed overflow does not occur is
+perfectly safe if the values of the variables involved are such that
+overflow never does, in fact, occur.  Therefore this warning can
+easily give a false positive: a warning about code that is not
+actually a problem.  To help focus on important issues, several
+warning levels are defined.  No warnings are issued for the use of
+undefined signed overflow when estimating how many iterations a loop
+requires, in particular when determining whether a loop will be
+executed at all.
+.RS 4
+.IP "\fB\-Wstrict\-overflow=1\fR" 4
+.IX Item "-Wstrict-overflow=1"
+Warn about cases that are both questionable and easy to avoid.  For
+example,  with \fB\-fstrict\-overflow\fR, the compiler simplifies
+\&\f(CW\*(C`x + 1 > x\*(C'\fR to \f(CW1\fR.  This level of
+\&\fB\-Wstrict\-overflow\fR is enabled by \fB\-Wall\fR; higher levels
+are not, and must be explicitly requested.
+.IP "\fB\-Wstrict\-overflow=2\fR" 4
+.IX Item "-Wstrict-overflow=2"
+Also warn about other cases where a comparison is simplified to a
+constant.  For example: \f(CW\*(C`abs (x) >= 0\*(C'\fR.  This can only be
+simplified when \fB\-fstrict\-overflow\fR is in effect, because
+\&\f(CW\*(C`abs (INT_MIN)\*(C'\fR overflows to \f(CW\*(C`INT_MIN\*(C'\fR, which is less than
+zero.  \fB\-Wstrict\-overflow\fR (with no level) is the same as
+\&\fB\-Wstrict\-overflow=2\fR.
+.IP "\fB\-Wstrict\-overflow=3\fR" 4
+.IX Item "-Wstrict-overflow=3"
+Also warn about other cases where a comparison is simplified.  For
+example: \f(CW\*(C`x + 1 > 1\*(C'\fR is simplified to \f(CW\*(C`x > 0\*(C'\fR.
+.IP "\fB\-Wstrict\-overflow=4\fR" 4
+.IX Item "-Wstrict-overflow=4"
+Also warn about other simplifications not covered by the above cases.
+For example: \f(CW\*(C`(x * 10) / 5\*(C'\fR is simplified to \f(CW\*(C`x * 2\*(C'\fR.
+.IP "\fB\-Wstrict\-overflow=5\fR" 4
+.IX Item "-Wstrict-overflow=5"
+Also warn about cases where the compiler reduces the magnitude of a
+constant involved in a comparison.  For example: \f(CW\*(C`x + 2 > y\*(C'\fR is
+simplified to \f(CW\*(C`x + 1 >= y\*(C'\fR.  This is reported only at the
+highest warning level because this simplification applies to many
+comparisons, so this warning level gives a very large number of
+false positives.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wsuggest\-attribute=\fR[\fBpure\fR|\fBconst\fR|\fBnoreturn\fR|\fBformat\fR]" 4
+.IX Item "-Wsuggest-attribute=[pure|const|noreturn|format]"
+Warn for cases where adding an attribute may be beneficial. The
+attributes currently supported are listed below.
+.RS 4
+.IP "\fB\-Wsuggest\-attribute=pure\fR" 4
+.IX Item "-Wsuggest-attribute=pure"
+.PD 0
+.IP "\fB\-Wsuggest\-attribute=const\fR" 4
+.IX Item "-Wsuggest-attribute=const"
+.IP "\fB\-Wsuggest\-attribute=noreturn\fR" 4
+.IX Item "-Wsuggest-attribute=noreturn"
+.PD
+Warn about functions that might be candidates for attributes
+\&\f(CW\*(C`pure\*(C'\fR, \f(CW\*(C`const\*(C'\fR or \f(CW\*(C`noreturn\*(C'\fR.  The compiler only warns for
+functions visible in other compilation units or (in the case of \f(CW\*(C`pure\*(C'\fR and
+\&\f(CW\*(C`const\*(C'\fR) if it cannot prove that the function returns normally. A function
+returns normally if it doesn't contain an infinite loop or return abnormally
+by throwing, calling \f(CW\*(C`abort()\*(C'\fR or trapping.  This analysis requires option
+\&\fB\-fipa\-pure\-const\fR, which is enabled by default at \fB\-O\fR and
+higher.  Higher optimization levels improve the accuracy of the analysis.
+.IP "\fB\-Wsuggest\-attribute=format\fR" 4
+.IX Item "-Wsuggest-attribute=format"
+.PD 0
+.IP "\fB\-Wmissing\-format\-attribute\fR" 4
+.IX Item "-Wmissing-format-attribute"
+.PD
+Warn about function pointers that might be candidates for \f(CW\*(C`format\*(C'\fR
+attributes.  Note these are only possible candidates, not absolute ones.
+\&\s-1GCC\s0 guesses that function pointers with \f(CW\*(C`format\*(C'\fR attributes that
+are used in assignment, initialization, parameter passing or return
+statements should have a corresponding \f(CW\*(C`format\*(C'\fR attribute in the
+resulting type.  I.e. the left-hand side of the assignment or
+initialization, the type of the parameter variable, or the return type
+of the containing function respectively should also have a \f(CW\*(C`format\*(C'\fR
+attribute to avoid the warning.
+.Sp
+\&\s-1GCC\s0 also warns about function definitions that might be
+candidates for \f(CW\*(C`format\*(C'\fR attributes.  Again, these are only
+possible candidates.  \s-1GCC\s0 guesses that \f(CW\*(C`format\*(C'\fR attributes
+might be appropriate for any function that calls a function like
+\&\f(CW\*(C`vprintf\*(C'\fR or \f(CW\*(C`vscanf\*(C'\fR, but this might not always be the
+case, and some functions for which \f(CW\*(C`format\*(C'\fR attributes are
+appropriate may not be detected.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Warray\-bounds\fR" 4
+.IX Item "-Warray-bounds"
+This option is only active when \fB\-ftree\-vrp\fR is active
+(default for \fB\-O2\fR and above). It warns about subscripts to arrays
+that are always out of bounds. This warning is enabled by \fB\-Wall\fR.
+.IP "\fB\-Wno\-div\-by\-zero\fR" 4
+.IX Item "-Wno-div-by-zero"
+Do not warn about compile-time integer division by zero.  Floating-point
+division by zero is not warned about, as it can be a legitimate way of
+obtaining infinities and NaNs.
+.IP "\fB\-Wsystem\-headers\fR" 4
+.IX Item "-Wsystem-headers"
+Print warning messages for constructs found in system header files.
+Warnings from system headers are normally suppressed, on the assumption
+that they usually do not indicate real problems and would only make the
+compiler output harder to read.  Using this command-line option tells
+\&\s-1GCC\s0 to emit warnings from system headers as if they occurred in user
+code.  However, note that using \fB\-Wall\fR in conjunction with this
+option does \fInot\fR warn about unknown pragmas in system
+headers\-\-\-for that, \fB\-Wunknown\-pragmas\fR must also be used.
+.IP "\fB\-Wtrampolines\fR" 4
+.IX Item "-Wtrampolines"
+.Vb 1
+\& Warn about trampolines generated for pointers to nested functions.
+\&
+\& A trampoline is a small piece of data or code that is created at run
+\& time on the stack when the address of a nested function is taken, and
+\& is used to call the nested function indirectly.  For some targets, it
+\& is made up of data only and thus requires no special treatment.  But,
+\& for most targets, it is made up of code and thus requires the stack
+\& to be made executable in order for the program to work properly.
+.Ve
+.IP "\fB\-Wfloat\-equal\fR" 4
+.IX Item "-Wfloat-equal"
+Warn if floating-point values are used in equality comparisons.
+.Sp
+The idea behind this is that sometimes it is convenient (for the
+programmer) to consider floating-point values as approximations to
+infinitely precise real numbers.  If you are doing this, then you need
+to compute (by analyzing the code, or in some other way) the maximum or
+likely maximum error that the computation introduces, and allow for it
+when performing comparisons (and when producing output, but that's a
+different problem).  In particular, instead of testing for equality, you
+should check to see whether the two values have ranges that overlap; and
+this is done with the relational operators, so equality comparisons are
+probably mistaken.
+.IP "\fB\-Wtraditional\fR (C and Objective-C only)" 4
+.IX Item "-Wtraditional (C and Objective-C only)"
+Warn about certain constructs that behave differently in traditional and
+\&\s-1ISO C. \s0 Also warn about \s-1ISO C\s0 constructs that have no traditional C
+equivalent, and/or problematic constructs that should be avoided.
+.RS 4
+.IP "\(bu" 4
+Macro parameters that appear within string literals in the macro body.
+In traditional C macro replacement takes place within string literals,
+but in \s-1ISO C\s0 it does not.
+.IP "\(bu" 4
+In traditional C, some preprocessor directives did not exist.
+Traditional preprocessors only considered a line to be a directive
+if the \fB#\fR appeared in column 1 on the line.  Therefore
+\&\fB\-Wtraditional\fR warns about directives that traditional C
+understands but ignores because the \fB#\fR does not appear as the
+first character on the line.  It also suggests you hide directives like
+\&\fB#pragma\fR not understood by traditional C by indenting them.  Some
+traditional implementations do not recognize \fB#elif\fR, so this option
+suggests avoiding it altogether.
+.IP "\(bu" 4
+A function-like macro that appears without arguments.
+.IP "\(bu" 4
+The unary plus operator.
+.IP "\(bu" 4
+The \fBU\fR integer constant suffix, or the \fBF\fR or \fBL\fR floating-point
+constant suffixes.  (Traditional C does support the \fBL\fR suffix on integer
+constants.)  Note, these suffixes appear in macros defined in the system
+headers of most modern systems, e.g. the \fB_MIN\fR/\fB_MAX\fR macros in \f(CW\*(C`<limits.h>\*(C'\fR.
+Use of these macros in user code might normally lead to spurious
+warnings, however \s-1GCC\s0's integrated preprocessor has enough context to
+avoid warning in these cases.
+.IP "\(bu" 4
+A function declared external in one block and then used after the end of
+the block.
+.IP "\(bu" 4
+A \f(CW\*(C`switch\*(C'\fR statement has an operand of type \f(CW\*(C`long\*(C'\fR.
+.IP "\(bu" 4
+A non\-\f(CW\*(C`static\*(C'\fR function declaration follows a \f(CW\*(C`static\*(C'\fR one.
+This construct is not accepted by some traditional C compilers.
+.IP "\(bu" 4
+The \s-1ISO\s0 type of an integer constant has a different width or
+signedness from its traditional type.  This warning is only issued if
+the base of the constant is ten.  I.e. hexadecimal or octal values, which
+typically represent bit patterns, are not warned about.
+.IP "\(bu" 4
+Usage of \s-1ISO\s0 string concatenation is detected.
+.IP "\(bu" 4
+Initialization of automatic aggregates.
+.IP "\(bu" 4
+Identifier conflicts with labels.  Traditional C lacks a separate
+namespace for labels.
+.IP "\(bu" 4
+Initialization of unions.  If the initializer is zero, the warning is
+omitted.  This is done under the assumption that the zero initializer in
+user code appears conditioned on e.g. \f(CW\*(C`_\|_STDC_\|_\*(C'\fR to avoid missing
+initializer warnings and relies on default initialization to zero in the
+traditional C case.
+.IP "\(bu" 4
+Conversions by prototypes between fixed/floating\-point values and vice
+versa.  The absence of these prototypes when compiling with traditional
+C causes serious problems.  This is a subset of the possible
+conversion warnings; for the full set use \fB\-Wtraditional\-conversion\fR.
+.IP "\(bu" 4
+Use of \s-1ISO C\s0 style function definitions.  This warning intentionally is
+\&\fInot\fR issued for prototype declarations or variadic functions
+because these \s-1ISO C\s0 features appear in your code when using
+libiberty's traditional C compatibility macros, \f(CW\*(C`PARAMS\*(C'\fR and
+\&\f(CW\*(C`VPARAMS\*(C'\fR.  This warning is also bypassed for nested functions
+because that feature is already a \s-1GCC\s0 extension and thus not relevant to
+traditional C compatibility.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wtraditional\-conversion\fR (C and Objective-C only)" 4
+.IX Item "-Wtraditional-conversion (C and Objective-C only)"
+Warn if a prototype causes a type conversion that is different from what
+would happen to the same argument in the absence of a prototype.  This
+includes conversions of fixed point to floating and vice versa, and
+conversions changing the width or signedness of a fixed-point argument
+except when the same as the default promotion.
+.IP "\fB\-Wdeclaration\-after\-statement\fR (C and Objective-C only)" 4
+.IX Item "-Wdeclaration-after-statement (C and Objective-C only)"
+Warn when a declaration is found after a statement in a block.  This
+construct, known from \*(C+, was introduced with \s-1ISO C99\s0 and is by default
+allowed in \s-1GCC. \s0 It is not supported by \s-1ISO C90\s0 and was not supported by
+\&\s-1GCC\s0 versions before \s-1GCC 3.0.  \s0
+.IP "\fB\-Wundef\fR" 4
+.IX Item "-Wundef"
+Warn if an undefined identifier is evaluated in an \fB#if\fR directive.
+.IP "\fB\-Wno\-endif\-labels\fR" 4
+.IX Item "-Wno-endif-labels"
+Do not warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
+.IP "\fB\-Wshadow\fR" 4
+.IX Item "-Wshadow"
+Warn whenever a local variable or type declaration shadows another variable,
+parameter, type, or class member (in \*(C+), or whenever a built-in function
+is shadowed. Note that in \*(C+, the compiler warns if a local variable
+shadows an explicit typedef, but not if it shadows a struct/class/enum.
+.IP "\fB\-Wlarger\-than=\fR\fIlen\fR" 4
+.IX Item "-Wlarger-than=len"
+Warn whenever an object of larger than \fIlen\fR bytes is defined.
+.IP "\fB\-Wframe\-larger\-than=\fR\fIlen\fR" 4
+.IX Item "-Wframe-larger-than=len"
+Warn if the size of a function frame is larger than \fIlen\fR bytes.
+The computation done to determine the stack frame size is approximate
+and not conservative.
+The actual requirements may be somewhat greater than \fIlen\fR
+even if you do not get a warning.  In addition, any space allocated
+via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related constructs
+is not included by the compiler when determining
+whether or not to issue a warning.
+.IP "\fB\-Wno\-free\-nonheap\-object\fR" 4
+.IX Item "-Wno-free-nonheap-object"
+Do not warn when attempting to free an object that was not allocated
+on the heap.
+.IP "\fB\-Wstack\-usage=\fR\fIlen\fR" 4
+.IX Item "-Wstack-usage=len"
+Warn if the stack usage of a function might be larger than \fIlen\fR bytes.
+The computation done to determine the stack usage is conservative.
+Any space allocated via \f(CW\*(C`alloca\*(C'\fR, variable-length arrays, or related
+constructs is included by the compiler when determining whether or not to
+issue a warning.
+.Sp
+The message is in keeping with the output of \fB\-fstack\-usage\fR.
+.RS 4
+.IP "\(bu" 4
+If the stack usage is fully static but exceeds the specified amount, it's:
+.Sp
+.Vb 1
+\&          warning: stack usage is 1120 bytes
+.Ve
+.IP "\(bu" 4
+If the stack usage is (partly) dynamic but bounded, it's:
+.Sp
+.Vb 1
+\&          warning: stack usage might be 1648 bytes
+.Ve
+.IP "\(bu" 4
+If the stack usage is (partly) dynamic and not bounded, it's:
+.Sp
+.Vb 1
+\&          warning: stack usage might be unbounded
+.Ve
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wunsafe\-loop\-optimizations\fR" 4
+.IX Item "-Wunsafe-loop-optimizations"
+Warn if the loop cannot be optimized because the compiler cannot
+assume anything on the bounds of the loop indices.  With
+\&\fB\-funsafe\-loop\-optimizations\fR warn if the compiler makes
+such assumptions.
+.IP "\fB\-Wno\-pedantic\-ms\-format\fR (MinGW targets only)" 4
+.IX Item "-Wno-pedantic-ms-format (MinGW targets only)"
+When used in combination with \fB\-Wformat\fR
+and \fB\-pedantic\fR without \s-1GNU\s0 extensions, this option
+disables the warnings about non-ISO \f(CW\*(C`printf\*(C'\fR / \f(CW\*(C`scanf\*(C'\fR format
+width specifiers \f(CW\*(C`I32\*(C'\fR, \f(CW\*(C`I64\*(C'\fR, and \f(CW\*(C`I\*(C'\fR used on Windows targets,
+which depend on the \s-1MS\s0 runtime.
+.IP "\fB\-Wpointer\-arith\fR" 4
+.IX Item "-Wpointer-arith"
+Warn about anything that depends on the \*(L"size of\*(R" a function type or
+of \f(CW\*(C`void\*(C'\fR.  \s-1GNU C\s0 assigns these types a size of 1, for
+convenience in calculations with \f(CW\*(C`void *\*(C'\fR pointers and pointers
+to functions.  In \*(C+, warn also when an arithmetic operation involves
+\&\f(CW\*(C`NULL\*(C'\fR.  This warning is also enabled by \fB\-Wpedantic\fR.
+.IP "\fB\-Wtype\-limits\fR" 4
+.IX Item "-Wtype-limits"
+Warn if a comparison is always true or always false due to the limited
+range of the data type, but do not warn for constant expressions.  For
+example, warn if an unsigned variable is compared against zero with
+\&\fB<\fR or \fB>=\fR.  This warning is also enabled by
+\&\fB\-Wextra\fR.
+.IP "\fB\-Wbad\-function\-cast\fR (C and Objective-C only)" 4
+.IX Item "-Wbad-function-cast (C and Objective-C only)"
+Warn whenever a function call is cast to a non-matching type.
+For example, warn if \f(CW\*(C`int malloc()\*(C'\fR is cast to \f(CW\*(C`anything *\*(C'\fR.
+.IP "\fB\-Wc++\-compat\fR (C and Objective-C only)" 4
+.IX Item "-Wc++-compat (C and Objective-C only)"
+Warn about \s-1ISO C\s0 constructs that are outside of the common subset of
+\&\s-1ISO C\s0 and \s-1ISO \*(C+,\s0 e.g. request for implicit conversion from
+\&\f(CW\*(C`void *\*(C'\fR to a pointer to non\-\f(CW\*(C`void\*(C'\fR type.
+.IP "\fB\-Wc++11\-compat\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wc++11-compat ( and Objective- only)"
+Warn about \*(C+ constructs whose meaning differs between \s-1ISO \*(C+ 1998\s0
+and \s-1ISO \*(C+ 2011,\s0 e.g., identifiers in \s-1ISO \*(C+ 1998\s0 that are keywords
+in \s-1ISO \*(C+ 2011. \s0 This warning turns on \fB\-Wnarrowing\fR and is
+enabled by \fB\-Wall\fR.
+.IP "\fB\-Wcast\-qual\fR" 4
+.IX Item "-Wcast-qual"
+Warn whenever a pointer is cast so as to remove a type qualifier from
+the target type.  For example, warn if a \f(CW\*(C`const char *\*(C'\fR is cast
+to an ordinary \f(CW\*(C`char *\*(C'\fR.
+.Sp
+Also warn when making a cast that introduces a type qualifier in an
+unsafe way.  For example, casting \f(CW\*(C`char **\*(C'\fR to \f(CW\*(C`const char **\*(C'\fR
+is unsafe, as in this example:
+.Sp
+.Vb 6
+\&          /* p is char ** value.  */
+\&          const char **q = (const char **) p;
+\&          /* Assignment of readonly string to const char * is OK.  */
+\&          *q = "string";
+\&          /* Now char** pointer points to read\-only memory.  */
+\&          **p = \*(Aqb\*(Aq;
+.Ve
+.IP "\fB\-Wcast\-align\fR" 4
+.IX Item "-Wcast-align"
+Warn whenever a pointer is cast such that the required alignment of the
+target is increased.  For example, warn if a \f(CW\*(C`char *\*(C'\fR is cast to
+an \f(CW\*(C`int *\*(C'\fR on machines where integers can only be accessed at
+two\- or four-byte boundaries.
+.IP "\fB\-Wwrite\-strings\fR" 4
+.IX Item "-Wwrite-strings"
+When compiling C, give string constants the type \f(CW\*(C`const
+char[\f(CIlength\f(CW]\*(C'\fR so that copying the address of one into a
+non\-\f(CW\*(C`const\*(C'\fR \f(CW\*(C`char *\*(C'\fR pointer produces a warning.  These
+warnings help you find at compile time code that can try to write
+into a string constant, but only if you have been very careful about
+using \f(CW\*(C`const\*(C'\fR in declarations and prototypes.  Otherwise, it is
+just a nuisance. This is why we did not make \fB\-Wall\fR request
+these warnings.
+.Sp
+When compiling \*(C+, warn about the deprecated conversion from string
+literals to \f(CW\*(C`char *\*(C'\fR.  This warning is enabled by default for \*(C+
+programs.
+.IP "\fB\-Wclobbered\fR" 4
+.IX Item "-Wclobbered"
+Warn for variables that might be changed by \fBlongjmp\fR or
+\&\fBvfork\fR.  This warning is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wconditionally\-supported\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wconditionally-supported ( and Objective- only)"
+Warn for conditionally-supported (\*(C+11 [intro.defs]) constructs.
+.IP "\fB\-Wconversion\fR" 4
+.IX Item "-Wconversion"
+Warn for implicit conversions that may alter a value. This includes
+conversions between real and integer, like \f(CW\*(C`abs (x)\*(C'\fR when
+\&\f(CW\*(C`x\*(C'\fR is \f(CW\*(C`double\*(C'\fR; conversions between signed and unsigned,
+like \f(CW\*(C`unsigned ui = \-1\*(C'\fR; and conversions to smaller types, like
+\&\f(CW\*(C`sqrtf (M_PI)\*(C'\fR. Do not warn for explicit casts like \f(CW\*(C`abs
+((int) x)\*(C'\fR and \f(CW\*(C`ui = (unsigned) \-1\*(C'\fR, or if the value is not
+changed by the conversion like in \f(CW\*(C`abs (2.0)\*(C'\fR.  Warnings about
+conversions between signed and unsigned integers can be disabled by
+using \fB\-Wno\-sign\-conversion\fR.
+.Sp
+For \*(C+, also warn for confusing overload resolution for user-defined
+conversions; and conversions that never use a type conversion
+operator: conversions to \f(CW\*(C`void\*(C'\fR, the same type, a base class or a
+reference to them. Warnings about conversions between signed and
+unsigned integers are disabled by default in \*(C+ unless
+\&\fB\-Wsign\-conversion\fR is explicitly enabled.
+.IP "\fB\-Wno\-conversion\-null\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-conversion-null ( and Objective- only)"
+Do not warn for conversions between \f(CW\*(C`NULL\*(C'\fR and non-pointer
+types. \fB\-Wconversion\-null\fR is enabled by default.
+.IP "\fB\-Wzero\-as\-null\-pointer\-constant\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wzero-as-null-pointer-constant ( and Objective- only)"
+Warn when a literal '0' is used as null pointer constant.  This can
+be useful to facilitate the conversion to \f(CW\*(C`nullptr\*(C'\fR in \*(C+11.
+.IP "\fB\-Wdate\-time\fR" 4
+.IX Item "-Wdate-time"
+Warn when macros \f(CW\*(C`_\|_TIME_\|_\*(C'\fR, \f(CW\*(C`_\|_DATE_\|_\*(C'\fR or \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR
+are encountered as they might prevent bit-wise-identical reproducible
+compilations.
+.IP "\fB\-Wdelete\-incomplete\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wdelete-incomplete ( and Objective- only)"
+Warn when deleting a pointer to incomplete type, which may cause
+undefined behavior at runtime.  This warning is enabled by default.
+.IP "\fB\-Wuseless\-cast\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wuseless-cast ( and Objective- only)"
+Warn when an expression is casted to its own type.
+.IP "\fB\-Wempty\-body\fR" 4
+.IX Item "-Wempty-body"
+Warn if an empty body occurs in an \fBif\fR, \fBelse\fR or \fBdo
+while\fR statement.  This warning is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wenum\-compare\fR" 4
+.IX Item "-Wenum-compare"
+Warn about a comparison between values of different enumerated types.
+In \*(C+ enumeral mismatches in conditional expressions are also
+diagnosed and the warning is enabled by default.  In C this warning is 
+enabled by \fB\-Wall\fR.
+.IP "\fB\-Wjump\-misses\-init\fR (C, Objective-C only)" 4
+.IX Item "-Wjump-misses-init (C, Objective-C only)"
+Warn if a \f(CW\*(C`goto\*(C'\fR statement or a \f(CW\*(C`switch\*(C'\fR statement jumps
+forward across the initialization of a variable, or jumps backward to a
+label after the variable has been initialized.  This only warns about
+variables that are initialized when they are declared.  This warning is
+only supported for C and Objective-C; in \*(C+ this sort of branch is an
+error in any case.
+.Sp
+\&\fB\-Wjump\-misses\-init\fR is included in \fB\-Wc++\-compat\fR.  It
+can be disabled with the \fB\-Wno\-jump\-misses\-init\fR option.
+.IP "\fB\-Wsign\-compare\fR" 4
+.IX Item "-Wsign-compare"
+Warn when a comparison between signed and unsigned values could produce
+an incorrect result when the signed value is converted to unsigned.
+This warning is also enabled by \fB\-Wextra\fR; to get the other warnings
+of \fB\-Wextra\fR without this warning, use \fB\-Wextra \-Wno\-sign\-compare\fR.
+.IP "\fB\-Wsign\-conversion\fR" 4
+.IX Item "-Wsign-conversion"
+Warn for implicit conversions that may change the sign of an integer
+value, like assigning a signed integer expression to an unsigned
+integer variable. An explicit cast silences the warning. In C, this
+option is enabled also by \fB\-Wconversion\fR.
+.IP "\fB\-Wfloat\-conversion\fR" 4
+.IX Item "-Wfloat-conversion"
+Warn for implicit conversions that reduce the precision of a real value.
+This includes conversions from real to integer, and from higher precision
+real to lower precision real values.  This option is also enabled by
+\&\fB\-Wconversion\fR.
+.IP "\fB\-Wsizeof\-pointer\-memaccess\fR" 4
+.IX Item "-Wsizeof-pointer-memaccess"
+Warn for suspicious length parameters to certain string and memory built-in
+functions if the argument uses \f(CW\*(C`sizeof\*(C'\fR.  This warning warns e.g.
+about \f(CW\*(C`memset (ptr, 0, sizeof (ptr));\*(C'\fR if \f(CW\*(C`ptr\*(C'\fR is not an array,
+but a pointer, and suggests a possible fix, or about
+\&\f(CW\*(C`memcpy (&foo, ptr, sizeof (&foo));\*(C'\fR.  This warning is enabled by
+\&\fB\-Wall\fR.
+.IP "\fB\-Waddress\fR" 4
+.IX Item "-Waddress"
+Warn about suspicious uses of memory addresses. These include using
+the address of a function in a conditional expression, such as
+\&\f(CW\*(C`void func(void); if (func)\*(C'\fR, and comparisons against the memory
+address of a string literal, such as \f(CW\*(C`if (x == "abc")\*(C'\fR.  Such
+uses typically indicate a programmer error: the address of a function
+always evaluates to true, so their use in a conditional usually
+indicate that the programmer forgot the parentheses in a function
+call; and comparisons against string literals result in unspecified
+behavior and are not portable in C, so they usually indicate that the
+programmer intended to use \f(CW\*(C`strcmp\*(C'\fR.  This warning is enabled by
+\&\fB\-Wall\fR.
+.IP "\fB\-Wlogical\-op\fR" 4
+.IX Item "-Wlogical-op"
+Warn about suspicious uses of logical operators in expressions.
+This includes using logical operators in contexts where a
+bit-wise operator is likely to be expected.
+.IP "\fB\-Waggregate\-return\fR" 4
+.IX Item "-Waggregate-return"
+Warn if any functions that return structures or unions are defined or
+called.  (In languages where you can return an array, this also elicits
+a warning.)
+.IP "\fB\-Wno\-aggressive\-loop\-optimizations\fR" 4
+.IX Item "-Wno-aggressive-loop-optimizations"
+Warn if in a loop with constant number of iterations the compiler detects
+undefined behavior in some statement during one or more of the iterations.
+.IP "\fB\-Wno\-attributes\fR" 4
+.IX Item "-Wno-attributes"
+Do not warn if an unexpected \f(CW\*(C`_\|_attribute_\|_\*(C'\fR is used, such as
+unrecognized attributes, function attributes applied to variables,
+etc.  This does not stop errors for incorrect use of supported
+attributes.
+.IP "\fB\-Wno\-builtin\-macro\-redefined\fR" 4
+.IX Item "-Wno-builtin-macro-redefined"
+Do not warn if certain built-in macros are redefined.  This suppresses
+warnings for redefinition of \f(CW\*(C`_\|_TIMESTAMP_\|_\*(C'\fR, \f(CW\*(C`_\|_TIME_\|_\*(C'\fR,
+\&\f(CW\*(C`_\|_DATE_\|_\*(C'\fR, \f(CW\*(C`_\|_FILE_\|_\*(C'\fR, and \f(CW\*(C`_\|_BASE_FILE_\|_\*(C'\fR.
+.IP "\fB\-Wstrict\-prototypes\fR (C and Objective-C only)" 4
+.IX Item "-Wstrict-prototypes (C and Objective-C only)"
+Warn if a function is declared or defined without specifying the
+argument types.  (An old-style function definition is permitted without
+a warning if preceded by a declaration that specifies the argument
+types.)
+.IP "\fB\-Wold\-style\-declaration\fR (C and Objective-C only)" 4
+.IX Item "-Wold-style-declaration (C and Objective-C only)"
+Warn for obsolescent usages, according to the C Standard, in a
+declaration. For example, warn if storage-class specifiers like
+\&\f(CW\*(C`static\*(C'\fR are not the first things in a declaration.  This warning
+is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wold\-style\-definition\fR (C and Objective-C only)" 4
+.IX Item "-Wold-style-definition (C and Objective-C only)"
+Warn if an old-style function definition is used.  A warning is given
+even if there is a previous prototype.
+.IP "\fB\-Wmissing\-parameter\-type\fR (C and Objective-C only)" 4
+.IX Item "-Wmissing-parameter-type (C and Objective-C only)"
+A function parameter is declared without a type specifier in K&R\-style
+functions:
+.Sp
+.Vb 1
+\&        void foo(bar) { }
+.Ve
+.Sp
+This warning is also enabled by \fB\-Wextra\fR.
+.IP "\fB\-Wmissing\-prototypes\fR (C and Objective-C only)" 4
+.IX Item "-Wmissing-prototypes (C and Objective-C only)"
+Warn if a global function is defined without a previous prototype
+declaration.  This warning is issued even if the definition itself
+provides a prototype.  Use this option to detect global functions
+that do not have a matching prototype declaration in a header file.
+This option is not valid for \*(C+ because all function declarations
+provide prototypes and a non-matching declaration will declare an
+overload rather than conflict with an earlier declaration.
+Use \fB\-Wmissing\-declarations\fR to detect missing declarations in \*(C+.
+.IP "\fB\-Wmissing\-declarations\fR" 4
+.IX Item "-Wmissing-declarations"
+Warn if a global function is defined without a previous declaration.
+Do so even if the definition itself provides a prototype.
+Use this option to detect global functions that are not declared in
+header files.  In C, no warnings are issued for functions with previous
+non-prototype declarations; use \fB\-Wmissing\-prototype\fR to detect
+missing prototypes.  In \*(C+, no warnings are issued for function templates,
+or for inline functions, or for functions in anonymous namespaces.
+.IP "\fB\-Wmissing\-field\-initializers\fR" 4
+.IX Item "-Wmissing-field-initializers"
+Warn if a structure's initializer has some fields missing.  For
+example, the following code causes such a warning, because
+\&\f(CW\*(C`x.h\*(C'\fR is implicitly zero:
+.Sp
+.Vb 2
+\&        struct s { int f, g, h; };
+\&        struct s x = { 3, 4 };
+.Ve
+.Sp
+This option does not warn about designated initializers, so the following
+modification does not trigger a warning:
+.Sp
+.Vb 2
+\&        struct s { int f, g, h; };
+\&        struct s x = { .f = 3, .g = 4 };
+.Ve
+.Sp
+This warning is included in \fB\-Wextra\fR.  To get other \fB\-Wextra\fR
+warnings without this one, use \fB\-Wextra \-Wno\-missing\-field\-initializers\fR.
+.IP "\fB\-Wno\-multichar\fR" 4
+.IX Item "-Wno-multichar"
+Do not warn if a multicharacter constant (\fB'\s-1FOOF\s0'\fR) is used.
+Usually they indicate a typo in the user's code, as they have
+implementation-defined values, and should not be used in portable code.
+.IP "\fB\-Wnormalized=<none|id|nfc|nfkc>\fR" 4
+.IX Item "-Wnormalized=<none|id|nfc|nfkc>"
+In \s-1ISO C\s0 and \s-1ISO \*(C+,\s0 two identifiers are different if they are
+different sequences of characters.  However, sometimes when characters
+outside the basic \s-1ASCII\s0 character set are used, you can have two
+different character sequences that look the same.  To avoid confusion,
+the \s-1ISO 10646\s0 standard sets out some \fInormalization rules\fR which
+when applied ensure that two sequences that look the same are turned into
+the same sequence.  \s-1GCC\s0 can warn you if you are using identifiers that
+have not been normalized; this option controls that warning.
+.Sp
+There are four levels of warning supported by \s-1GCC. \s0 The default is
+\&\fB\-Wnormalized=nfc\fR, which warns about any identifier that is
+not in the \s-1ISO 10646 \*(L"C\*(R"\s0 normalized form, \fI\s-1NFC\s0\fR.  \s-1NFC\s0 is the
+recommended form for most uses.
+.Sp
+Unfortunately, there are some characters allowed in identifiers by
+\&\s-1ISO C\s0 and \s-1ISO \*(C+\s0 that, when turned into \s-1NFC,\s0 are not allowed in 
+identifiers.  That is, there's no way to use these symbols in portable
+\&\s-1ISO C\s0 or \*(C+ and have all your identifiers in \s-1NFC.
+\&\s0\fB\-Wnormalized=id\fR suppresses the warning for these characters.
+It is hoped that future versions of the standards involved will correct
+this, which is why this option is not the default.
+.Sp
+You can switch the warning off for all characters by writing
+\&\fB\-Wnormalized=none\fR.  You should only do this if you
+are using some other normalization scheme (like \*(L"D\*(R"), because
+otherwise you can easily create bugs that are literally impossible to see.
+.Sp
+Some characters in \s-1ISO 10646\s0 have distinct meanings but look identical
+in some fonts or display methodologies, especially once formatting has
+been applied.  For instance \f(CW\*(C`\eu207F\*(C'\fR, \*(L"\s-1SUPERSCRIPT LATIN SMALL
+LETTER N\*(R",\s0 displays just like a regular \f(CW\*(C`n\*(C'\fR that has been
+placed in a superscript.  \s-1ISO 10646\s0 defines the \fI\s-1NFKC\s0\fR
+normalization scheme to convert all these into a standard form as
+well, and \s-1GCC\s0 warns if your code is not in \s-1NFKC\s0 if you use
+\&\fB\-Wnormalized=nfkc\fR.  This warning is comparable to warning
+about every identifier that contains the letter O because it might be
+confused with the digit 0, and so is not the default, but may be
+useful as a local coding convention if the programming environment 
+cannot be fixed to display these characters distinctly.
+.IP "\fB\-Wno\-deprecated\fR" 4
+.IX Item "-Wno-deprecated"
+Do not warn about usage of deprecated features.
+.IP "\fB\-Wno\-deprecated\-declarations\fR" 4
+.IX Item "-Wno-deprecated-declarations"
+Do not warn about uses of functions,
+variables, and types marked as deprecated by using the \f(CW\*(C`deprecated\*(C'\fR
+attribute.
+.IP "\fB\-Wno\-overflow\fR" 4
+.IX Item "-Wno-overflow"
+Do not warn about compile-time overflow in constant expressions.
+.IP "\fB\-Wopenmp\-simd\fR" 4
+.IX Item "-Wopenmp-simd"
+Warn if the vectorizer cost model overrides the OpenMP or the Cilk Plus
+simd directive set by user.  The \fB\-fsimd\-cost\-model=unlimited\fR can
+be used to relax the cost model.
+.IP "\fB\-Woverride\-init\fR (C and Objective-C only)" 4
+.IX Item "-Woverride-init (C and Objective-C only)"
+Warn if an initialized field without side effects is overridden when
+using designated initializers.
+.Sp
+This warning is included in \fB\-Wextra\fR.  To get other
+\&\fB\-Wextra\fR warnings without this one, use \fB\-Wextra
+\&\-Wno\-override\-init\fR.
+.IP "\fB\-Wpacked\fR" 4
+.IX Item "-Wpacked"
+Warn if a structure is given the packed attribute, but the packed
+attribute has no effect on the layout or size of the structure.
+Such structures may be mis-aligned for little benefit.  For
+instance, in this code, the variable \f(CW\*(C`f.x\*(C'\fR in \f(CW\*(C`struct bar\*(C'\fR
+is misaligned even though \f(CW\*(C`struct bar\*(C'\fR does not itself
+have the packed attribute:
+.Sp
+.Vb 8
+\&        struct foo {
+\&          int x;
+\&          char a, b, c, d;
+\&        } _\|_attribute_\|_((packed));
+\&        struct bar {
+\&          char z;
+\&          struct foo f;
+\&        };
+.Ve
+.IP "\fB\-Wpacked\-bitfield\-compat\fR" 4
+.IX Item "-Wpacked-bitfield-compat"
+The 4.1, 4.2 and 4.3 series of \s-1GCC\s0 ignore the \f(CW\*(C`packed\*(C'\fR attribute
+on bit-fields of type \f(CW\*(C`char\*(C'\fR.  This has been fixed in \s-1GCC 4.4\s0 but
+the change can lead to differences in the structure layout.  \s-1GCC\s0
+informs you when the offset of such a field has changed in \s-1GCC 4.4.\s0
+For example there is no longer a 4\-bit padding between field \f(CW\*(C`a\*(C'\fR
+and \f(CW\*(C`b\*(C'\fR in this structure:
+.Sp
+.Vb 5
+\&        struct foo
+\&        {
+\&          char a:4;
+\&          char b:8;
+\&        } _\|_attribute_\|_ ((packed));
+.Ve
+.Sp
+This warning is enabled by default.  Use
+\&\fB\-Wno\-packed\-bitfield\-compat\fR to disable this warning.
+.IP "\fB\-Wpadded\fR" 4
+.IX Item "-Wpadded"
+Warn if padding is included in a structure, either to align an element
+of the structure or to align the whole structure.  Sometimes when this
+happens it is possible to rearrange the fields of the structure to
+reduce the padding and so make the structure smaller.
+.IP "\fB\-Wredundant\-decls\fR" 4
+.IX Item "-Wredundant-decls"
+Warn if anything is declared more than once in the same scope, even in
+cases where multiple declaration is valid and changes nothing.
+.IP "\fB\-Wnested\-externs\fR (C and Objective-C only)" 4
+.IX Item "-Wnested-externs (C and Objective-C only)"
+Warn if an \f(CW\*(C`extern\*(C'\fR declaration is encountered within a function.
+.IP "\fB\-Wno\-inherited\-variadic\-ctor\fR" 4
+.IX Item "-Wno-inherited-variadic-ctor"
+Suppress warnings about use of \*(C+11 inheriting constructors when the
+base class inherited from has a C variadic constructor; the warning is
+on by default because the ellipsis is not inherited.
+.IP "\fB\-Winline\fR" 4
+.IX Item "-Winline"
+Warn if a function that is declared as inline cannot be inlined.
+Even with this option, the compiler does not warn about failures to
+inline functions declared in system headers.
+.Sp
+The compiler uses a variety of heuristics to determine whether or not
+to inline a function.  For example, the compiler takes into account
+the size of the function being inlined and the amount of inlining
+that has already been done in the current function.  Therefore,
+seemingly insignificant changes in the source program can cause the
+warnings produced by \fB\-Winline\fR to appear or disappear.
+.IP "\fB\-Wno\-invalid\-offsetof\fR (\*(C+ and Objective\-\*(C+ only)" 4
+.IX Item "-Wno-invalid-offsetof ( and Objective- only)"
+Suppress warnings from applying the \fBoffsetof\fR macro to a non-POD
+type.  According to the 1998 \s-1ISO \*(C+\s0 standard, applying \fBoffsetof\fR
+to a non-POD type is undefined.  In existing \*(C+ implementations,
+however, \fBoffsetof\fR typically gives meaningful results even when
+applied to certain kinds of non-POD types (such as a simple
+\&\fBstruct\fR that fails to be a \s-1POD\s0 type only by virtue of having a
+constructor).  This flag is for users who are aware that they are
+writing nonportable code and who have deliberately chosen to ignore the
+warning about it.
+.Sp
+The restrictions on \fBoffsetof\fR may be relaxed in a future version
+of the \*(C+ standard.
+.IP "\fB\-Wno\-int\-to\-pointer\-cast\fR" 4
+.IX Item "-Wno-int-to-pointer-cast"
+Suppress warnings from casts to pointer type of an integer of a
+different size. In \*(C+, casting to a pointer type of smaller size is
+an error. \fBWint-to-pointer-cast\fR is enabled by default.
+.IP "\fB\-Wno\-pointer\-to\-int\-cast\fR (C and Objective-C only)" 4
+.IX Item "-Wno-pointer-to-int-cast (C and Objective-C only)"
+Suppress warnings from casts from a pointer to an integer type of a
+different size.
+.IP "\fB\-Winvalid\-pch\fR" 4
+.IX Item "-Winvalid-pch"
+Warn if a precompiled header is found in
+the search path but can't be used.
+.IP "\fB\-Wlong\-long\fR" 4
+.IX Item "-Wlong-long"
+Warn if \fBlong long\fR type is used.  This is enabled by either
+\&\fB\-Wpedantic\fR or \fB\-Wtraditional\fR in \s-1ISO C90\s0 and \*(C+98
+modes.  To inhibit the warning messages, use \fB\-Wno\-long\-long\fR.
+.IP "\fB\-Wvariadic\-macros\fR" 4
+.IX Item "-Wvariadic-macros"
+Warn if variadic macros are used in pedantic \s-1ISO C90\s0 mode, or the \s-1GNU\s0
+alternate syntax when in pedantic \s-1ISO C99\s0 mode.  This is default.
+To inhibit the warning messages, use \fB\-Wno\-variadic\-macros\fR.
+.IP "\fB\-Wvarargs\fR" 4
+.IX Item "-Wvarargs"
+Warn upon questionable usage of the macros used to handle variable
+arguments like \fBva_start\fR.  This is default.  To inhibit the
+warning messages, use \fB\-Wno\-varargs\fR.
+.IP "\fB\-Wvector\-operation\-performance\fR" 4
+.IX Item "-Wvector-operation-performance"
+Warn if vector operation is not implemented via \s-1SIMD\s0 capabilities of the
+architecture.  Mainly useful for the performance tuning.
+Vector operation can be implemented \f(CW\*(C`piecewise\*(C'\fR, which means that the
+scalar operation is performed on every vector element; 
+\&\f(CW\*(C`in parallel\*(C'\fR, which means that the vector operation is implemented
+using scalars of wider type, which normally is more performance efficient;
+and \f(CW\*(C`as a single scalar\*(C'\fR, which means that vector fits into a
+scalar type.
+.IP "\fB\-Wno\-virtual\-move\-assign\fR" 4
+.IX Item "-Wno-virtual-move-assign"
+Suppress warnings about inheriting from a virtual base with a
+non-trivial \*(C+11 move assignment operator.  This is dangerous because
+if the virtual base is reachable along more than one path, it will be
+moved multiple times, which can mean both objects end up in the
+moved-from state.  If the move assignment operator is written to avoid
+moving from a moved-from object, this warning can be disabled.
+.IP "\fB\-Wvla\fR" 4
+.IX Item "-Wvla"
+Warn if variable length array is used in the code.
+\&\fB\-Wno\-vla\fR prevents the \fB\-Wpedantic\fR warning of
+the variable length array.
+.IP "\fB\-Wvolatile\-register\-var\fR" 4
+.IX Item "-Wvolatile-register-var"
+Warn if a register variable is declared volatile.  The volatile
+modifier does not inhibit all optimizations that may eliminate reads
+and/or writes to register variables.  This warning is enabled by
+\&\fB\-Wall\fR.
+.IP "\fB\-Wdisabled\-optimization\fR" 4
+.IX Item "-Wdisabled-optimization"
+Warn if a requested optimization pass is disabled.  This warning does
+not generally indicate that there is anything wrong with your code; it
+merely indicates that \s-1GCC\s0's optimizers are unable to handle the code
+effectively.  Often, the problem is that your code is too big or too
+complex; \s-1GCC\s0 refuses to optimize programs when the optimization
+itself is likely to take inordinate amounts of time.
+.IP "\fB\-Wpointer\-sign\fR (C and Objective-C only)" 4
+.IX Item "-Wpointer-sign (C and Objective-C only)"
+Warn for pointer argument passing or assignment with different signedness.
+This option is only supported for C and Objective-C.  It is implied by
+\&\fB\-Wall\fR and by \fB\-Wpedantic\fR, which can be disabled with
+\&\fB\-Wno\-pointer\-sign\fR.
+.IP "\fB\-Wstack\-protector\fR" 4
+.IX Item "-Wstack-protector"
+This option is only active when \fB\-fstack\-protector\fR is active.  It
+warns about functions that are not protected against stack smashing.
+.IP "\fB\-Woverlength\-strings\fR" 4
+.IX Item "-Woverlength-strings"
+Warn about string constants that are longer than the \*(L"minimum
+maximum\*(R" length specified in the C standard.  Modern compilers
+generally allow string constants that are much longer than the
+standard's minimum limit, but very portable programs should avoid
+using longer strings.
+.Sp
+The limit applies \fIafter\fR string constant concatenation, and does
+not count the trailing \s-1NUL. \s0 In C90, the limit was 509 characters; in
+C99, it was raised to 4095.  \*(C+98 does not specify a normative
+minimum maximum, so we do not diagnose overlength strings in \*(C+.
+.Sp
+This option is implied by \fB\-Wpedantic\fR, and can be disabled with
+\&\fB\-Wno\-overlength\-strings\fR.
+.IP "\fB\-Wunsuffixed\-float\-constants\fR (C and Objective-C only)" 4
+.IX Item "-Wunsuffixed-float-constants (C and Objective-C only)"
+Issue a warning for any floating constant that does not have
+a suffix.  When used together with \fB\-Wsystem\-headers\fR it
+warns about such constants in system header files.  This can be useful
+when preparing code to use with the \f(CW\*(C`FLOAT_CONST_DECIMAL64\*(C'\fR pragma
+from the decimal floating-point extension to C99.
+.SS "Options for Debugging Your Program or \s-1GCC\s0"
+.IX Subsection "Options for Debugging Your Program or GCC"
+\&\s-1GCC\s0 has various special options that are used for debugging
+either your program or \s-1GCC:\s0
+.IP "\fB\-g\fR" 4
+.IX Item "-g"
+Produce debugging information in the operating system's native format
+(stabs, \s-1COFF, XCOFF,\s0 or \s-1DWARF 2\s0).  \s-1GDB\s0 can work with this debugging
+information.
+.Sp
+On most systems that use stabs format, \fB\-g\fR enables use of extra
+debugging information that only \s-1GDB\s0 can use; this extra information
+makes debugging work better in \s-1GDB\s0 but probably makes other debuggers
+crash or
+refuse to read the program.  If you want to control for certain whether
+to generate the extra information, use \fB\-gstabs+\fR, \fB\-gstabs\fR,
+\&\fB\-gxcoff+\fR, \fB\-gxcoff\fR, or \fB\-gvms\fR (see below).
+.Sp
+\&\s-1GCC\s0 allows you to use \fB\-g\fR with
+\&\fB\-O\fR.  The shortcuts taken by optimized code may occasionally
+produce surprising results: some variables you declared may not exist
+at all; flow of control may briefly move where you did not expect it;
+some statements may not be executed because they compute constant
+results or their values are already at hand; some statements may
+execute in different places because they have been moved out of loops.
+.Sp
+Nevertheless it proves possible to debug optimized output.  This makes
+it reasonable to use the optimizer for programs that might have bugs.
+.Sp
+The following options are useful when \s-1GCC\s0 is generated with the
+capability for more than one debugging format.
+.IP "\fB\-gsplit\-dwarf\fR" 4
+.IX Item "-gsplit-dwarf"
+Separate as much dwarf debugging information as possible into a
+separate output file with the extension .dwo.  This option allows
+the build system to avoid linking files with debug information.  To
+be useful, this option requires a debugger capable of reading .dwo
+files.
+.IP "\fB\-ggdb\fR" 4
+.IX Item "-ggdb"
+Produce debugging information for use by \s-1GDB. \s0 This means to use the
+most expressive format available (\s-1DWARF 2,\s0 stabs, or the native format
+if neither of those are supported), including \s-1GDB\s0 extensions if at all
+possible.
+.IP "\fB\-gpubnames\fR" 4
+.IX Item "-gpubnames"
+Generate dwarf .debug_pubnames and .debug_pubtypes sections.
+.IP "\fB\-ggnu\-pubnames\fR" 4
+.IX Item "-ggnu-pubnames"
+Generate .debug_pubnames and .debug_pubtypes sections in a format
+suitable for conversion into a \s-1GDB\s0 index.  This option is only useful
+with a linker that can produce \s-1GDB\s0 index version 7.
+.IP "\fB\-gstabs\fR" 4
+.IX Item "-gstabs"
+Produce debugging information in stabs format (if that is supported),
+without \s-1GDB\s0 extensions.  This is the format used by \s-1DBX\s0 on most \s-1BSD\s0
+systems.  On \s-1MIPS,\s0 Alpha and System V Release 4 systems this option
+produces stabs debugging output that is not understood by \s-1DBX\s0 or \s-1SDB.\s0
+On System V Release 4 systems this option requires the \s-1GNU\s0 assembler.
+.IP "\fB\-feliminate\-unused\-debug\-symbols\fR" 4
+.IX Item "-feliminate-unused-debug-symbols"
+Produce debugging information in stabs format (if that is supported),
+for only symbols that are actually used.
+.IP "\fB\-femit\-class\-debug\-always\fR" 4
+.IX Item "-femit-class-debug-always"
+Instead of emitting debugging information for a \*(C+ class in only one
+object file, emit it in all object files using the class.  This option
+should be used only with debuggers that are unable to handle the way \s-1GCC\s0
+normally emits debugging information for classes because using this
+option increases the size of debugging information by as much as a
+factor of two.
+.IP "\fB\-fdebug\-types\-section\fR" 4
+.IX Item "-fdebug-types-section"
+When using \s-1DWARF\s0 Version 4 or higher, type DIEs can be put into
+their own \f(CW\*(C`.debug_types\*(C'\fR section instead of making them part of the
+\&\f(CW\*(C`.debug_info\*(C'\fR section.  It is more efficient to put them in a separate
+comdat sections since the linker can then remove duplicates.
+But not all \s-1DWARF\s0 consumers support \f(CW\*(C`.debug_types\*(C'\fR sections yet
+and on some objects \f(CW\*(C`.debug_types\*(C'\fR produces larger instead of smaller
+debugging information.
+.IP "\fB\-gstabs+\fR" 4
+.IX Item "-gstabs+"
+Produce debugging information in stabs format (if that is supported),
+using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0).  The
+use of these extensions is likely to make other debuggers crash or
+refuse to read the program.
+.IP "\fB\-gcoff\fR" 4
+.IX Item "-gcoff"
+Produce debugging information in \s-1COFF\s0 format (if that is supported).
+This is the format used by \s-1SDB\s0 on most System V systems prior to
+System V Release 4.
+.IP "\fB\-gxcoff\fR" 4
+.IX Item "-gxcoff"
+Produce debugging information in \s-1XCOFF\s0 format (if that is supported).
+This is the format used by the \s-1DBX\s0 debugger on \s-1IBM RS/6000\s0 systems.
+.IP "\fB\-gxcoff+\fR" 4
+.IX Item "-gxcoff+"
+Produce debugging information in \s-1XCOFF\s0 format (if that is supported),
+using \s-1GNU\s0 extensions understood only by the \s-1GNU\s0 debugger (\s-1GDB\s0).  The
+use of these extensions is likely to make other debuggers crash or
+refuse to read the program, and may cause assemblers other than the \s-1GNU\s0
+assembler (\s-1GAS\s0) to fail with an error.
+.IP "\fB\-gdwarf\-\fR\fIversion\fR" 4
+.IX Item "-gdwarf-version"
+Produce debugging information in \s-1DWARF\s0 format (if that is supported).
+The value of \fIversion\fR may be either 2, 3 or 4; the default version
+for most targets is 4.
+.Sp
+Note that with \s-1DWARF\s0 Version 2, some ports require and always
+use some non-conflicting \s-1DWARF 3\s0 extensions in the unwind tables.
+.Sp
+Version 4 may require \s-1GDB 7.0\s0 and \fB\-fvar\-tracking\-assignments\fR
+for maximum benefit.
+.IP "\fB\-grecord\-gcc\-switches\fR" 4
+.IX Item "-grecord-gcc-switches"
+This switch causes the command-line options used to invoke the
+compiler that may affect code generation to be appended to the
+DW_AT_producer attribute in \s-1DWARF\s0 debugging information.  The options
+are concatenated with spaces separating them from each other and from
+the compiler version.  See also \fB\-frecord\-gcc\-switches\fR for another
+way of storing compiler options into the object file.  This is the default.
+.IP "\fB\-gno\-record\-gcc\-switches\fR" 4
+.IX Item "-gno-record-gcc-switches"
+Disallow appending command-line options to the DW_AT_producer attribute
+in \s-1DWARF\s0 debugging information.
+.IP "\fB\-gstrict\-dwarf\fR" 4
+.IX Item "-gstrict-dwarf"
+Disallow using extensions of later \s-1DWARF\s0 standard version than selected
+with \fB\-gdwarf\-\fR\fIversion\fR.  On most targets using non-conflicting
+\&\s-1DWARF\s0 extensions from later standard versions is allowed.
+.IP "\fB\-gno\-strict\-dwarf\fR" 4
+.IX Item "-gno-strict-dwarf"
+Allow using extensions of later \s-1DWARF\s0 standard version than selected with
+\&\fB\-gdwarf\-\fR\fIversion\fR.
+.IP "\fB\-gvms\fR" 4
+.IX Item "-gvms"
+Produce debugging information in Alpha/VMS debug format (if that is
+supported).  This is the format used by \s-1DEBUG\s0 on Alpha/VMS systems.
+.IP "\fB\-g\fR\fIlevel\fR" 4
+.IX Item "-glevel"
+.PD 0
+.IP "\fB\-ggdb\fR\fIlevel\fR" 4
+.IX Item "-ggdblevel"
+.IP "\fB\-gstabs\fR\fIlevel\fR" 4
+.IX Item "-gstabslevel"
+.IP "\fB\-gcoff\fR\fIlevel\fR" 4
+.IX Item "-gcofflevel"
+.IP "\fB\-gxcoff\fR\fIlevel\fR" 4
+.IX Item "-gxcofflevel"
+.IP "\fB\-gvms\fR\fIlevel\fR" 4
+.IX Item "-gvmslevel"
+.PD
+Request debugging information and also use \fIlevel\fR to specify how
+much information.  The default level is 2.
+.Sp
+Level 0 produces no debug information at all.  Thus, \fB\-g0\fR negates
+\&\fB\-g\fR.
+.Sp
+Level 1 produces minimal information, enough for making backtraces in
+parts of the program that you don't plan to debug.  This includes
+descriptions of functions and external variables, and line number
+tables, but no information about local variables.
+.Sp
+Level 3 includes extra information, such as all the macro definitions
+present in the program.  Some debuggers support macro expansion when
+you use \fB\-g3\fR.
+.Sp
+\&\fB\-gdwarf\-2\fR does not accept a concatenated debug level, because
+\&\s-1GCC\s0 used to support an option \fB\-gdwarf\fR that meant to generate
+debug information in version 1 of the \s-1DWARF\s0 format (which is very
+different from version 2), and it would have been too confusing.  That
+debug format is long obsolete, but the option cannot be changed now.
+Instead use an additional \fB\-g\fR\fIlevel\fR option to change the
+debug level for \s-1DWARF.\s0
+.IP "\fB\-gtoggle\fR" 4
+.IX Item "-gtoggle"
+Turn off generation of debug info, if leaving out this option
+generates it, or turn it on at level 2 otherwise.  The position of this
+argument in the command line does not matter; it takes effect after all
+other options are processed, and it does so only once, no matter how
+many times it is given.  This is mainly intended to be used with
+\&\fB\-fcompare\-debug\fR.
+.IP "\fB\-fsanitize=address\fR" 4
+.IX Item "-fsanitize=address"
+Enable AddressSanitizer, a fast memory error detector.
+Memory access instructions will be instrumented to detect
+out-of-bounds and use-after-free bugs.
+See <\fBhttp://code.google.com/p/address\-sanitizer/\fR> for
+more details.  The run-time behavior can be influenced using the
+\&\fB\s-1ASAN_OPTIONS\s0\fR environment variable; see
+<\fBhttps://code.google.com/p/address\-sanitizer/wiki/Flags#Run\-time_flags\fR> for
+a list of supported options.
+.IP "\fB\-fsanitize=thread\fR" 4
+.IX Item "-fsanitize=thread"
+Enable ThreadSanitizer, a fast data race detector.
+Memory access instructions will be instrumented to detect
+data race bugs.  See <\fBhttp://code.google.com/p/thread\-sanitizer/\fR> for more
+details. The run-time behavior can be influenced using the \fB\s-1TSAN_OPTIONS\s0\fR
+environment variable; see
+<\fBhttps://code.google.com/p/thread\-sanitizer/wiki/Flags\fR> for a list of
+supported options.
+.IP "\fB\-fsanitize=leak\fR" 4
+.IX Item "-fsanitize=leak"
+Enable LeakSanitizer, a memory leak detector.
+This option only matters for linking of executables and if neither
+\&\fB\-fsanitize=address\fR nor \fB\-fsanitize=thread\fR is used.  In that
+case it will link the executable against a library that overrides \f(CW\*(C`malloc\*(C'\fR
+and other allocator functions.  See
+<\fBhttps://code.google.com/p/address\-sanitizer/wiki/LeakSanitizer\fR> for more
+details.  The run-time behavior can be influenced using the
+\&\fB\s-1LSAN_OPTIONS\s0\fR environment variable.
+.IP "\fB\-fsanitize=undefined\fR" 4
+.IX Item "-fsanitize=undefined"
+Enable UndefinedBehaviorSanitizer, a fast undefined behavior detector.
+Various computations will be instrumented to detect undefined behavior
+at runtime.  Current suboptions are:
+.RS 4
+.IP "\fB\-fsanitize=shift\fR" 4
+.IX Item "-fsanitize=shift"
+This option enables checking that the result of a shift operation is
+not undefined.  Note that what exactly is considered undefined differs
+slightly between C and \*(C+, as well as between \s-1ISO C90\s0 and C99, etc.
+.IP "\fB\-fsanitize=integer\-divide\-by\-zero\fR" 4
+.IX Item "-fsanitize=integer-divide-by-zero"
+Detect integer division by zero as well as \f(CW\*(C`INT_MIN / \-1\*(C'\fR division.
+.IP "\fB\-fsanitize=unreachable\fR" 4
+.IX Item "-fsanitize=unreachable"
+With this option, the compiler will turn the \f(CW\*(C`_\|_builtin_unreachable\*(C'\fR
+call into a diagnostics message call instead.  When reaching the
+\&\f(CW\*(C`_\|_builtin_unreachable\*(C'\fR call, the behavior is undefined.
+.IP "\fB\-fsanitize=vla\-bound\fR" 4
+.IX Item "-fsanitize=vla-bound"
+This option instructs the compiler to check that the size of a variable
+length array is positive.  This option does not have any effect in
+\&\fB\-std=c++1y\fR mode, as the standard requires the exception be thrown
+instead.
+.IP "\fB\-fsanitize=null\fR" 4
+.IX Item "-fsanitize=null"
+This option enables pointer checking.  Particularly, the application
+built with this option turned on will issue an error message when it
+tries to dereference a \s-1NULL\s0 pointer, or if a reference (possibly an
+rvalue reference) is bound to a \s-1NULL\s0 pointer.
+.IP "\fB\-fsanitize=return\fR" 4
+.IX Item "-fsanitize=return"
+This option enables return statement checking.  Programs
+built with this option turned on will issue an error message
+when the end of a non-void function is reached without actually
+returning a value.  This option works in \*(C+ only.
+.IP "\fB\-fsanitize=signed\-integer\-overflow\fR" 4
+.IX Item "-fsanitize=signed-integer-overflow"
+This option enables signed integer overflow checking.  We check that
+the result of \f(CW\*(C`+\*(C'\fR, \f(CW\*(C`*\*(C'\fR, and both unary and binary \f(CW\*(C`\-\*(C'\fR
+does not overflow in the signed arithmetics.  Note, integer promotion
+rules must be taken into account.  That is, the following is not an
+overflow:
+.Sp
+.Vb 2
+\&        signed char a = SCHAR_MAX;
+\&        a++;
+.Ve
+.RE
+.RS 4
+.Sp
+While \fB\-ftrapv\fR causes traps for signed overflows to be emitted,
+\&\fB\-fsanitize=undefined\fR gives a diagnostic message.
+This currently works only for the C family of languages.
+.RE
+.IP "\fB\-fdump\-final\-insns\fR[\fB=\fR\fIfile\fR]" 4
+.IX Item "-fdump-final-insns[=file]"
+Dump the final internal representation (\s-1RTL\s0) to \fIfile\fR.  If the
+optional argument is omitted (or if \fIfile\fR is \f(CW\*(C`.\*(C'\fR), the name
+of the dump file is determined by appending \f(CW\*(C`.gkd\*(C'\fR to the
+compilation output file name.
+.IP "\fB\-fcompare\-debug\fR[\fB=\fR\fIopts\fR]" 4
+.IX Item "-fcompare-debug[=opts]"
+If no error occurs during compilation, run the compiler a second time,
+adding \fIopts\fR and \fB\-fcompare\-debug\-second\fR to the arguments
+passed to the second compilation.  Dump the final internal
+representation in both compilations, and print an error if they differ.
+.Sp
+If the equal sign is omitted, the default \fB\-gtoggle\fR is used.
+.Sp
+The environment variable \fB\s-1GCC_COMPARE_DEBUG\s0\fR, if defined, non-empty
+and nonzero, implicitly enables \fB\-fcompare\-debug\fR.  If
+\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR is defined to a string starting with a dash,
+then it is used for \fIopts\fR, otherwise the default \fB\-gtoggle\fR
+is used.
+.Sp
+\&\fB\-fcompare\-debug=\fR, with the equal sign but without \fIopts\fR,
+is equivalent to \fB\-fno\-compare\-debug\fR, which disables the dumping
+of the final representation and the second compilation, preventing even
+\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR from taking effect.
+.Sp
+To verify full coverage during \fB\-fcompare\-debug\fR testing, set
+\&\fB\s-1GCC_COMPARE_DEBUG\s0\fR to say \fB\-fcompare\-debug\-not\-overridden\fR,
+which \s-1GCC\s0 rejects as an invalid option in any actual compilation
+(rather than preprocessing, assembly or linking).  To get just a
+warning, setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR to \fB\-w%n\-fcompare\-debug
+not overridden\fR will do.
+.IP "\fB\-fcompare\-debug\-second\fR" 4
+.IX Item "-fcompare-debug-second"
+This option is implicitly passed to the compiler for the second
+compilation requested by \fB\-fcompare\-debug\fR, along with options to
+silence warnings, and omitting other options that would cause
+side-effect compiler outputs to files or to the standard output.  Dump
+files and preserved temporary files are renamed so as to contain the
+\&\f(CW\*(C`.gk\*(C'\fR additional extension during the second compilation, to avoid
+overwriting those generated by the first.
+.Sp
+When this option is passed to the compiler driver, it causes the
+\&\fIfirst\fR compilation to be skipped, which makes it useful for little
+other than debugging the compiler proper.
+.IP "\fB\-feliminate\-dwarf2\-dups\fR" 4
+.IX Item "-feliminate-dwarf2-dups"
+Compress \s-1DWARF 2\s0 debugging information by eliminating duplicated
+information about each symbol.  This option only makes sense when
+generating \s-1DWARF 2\s0 debugging information with \fB\-gdwarf\-2\fR.
+.IP "\fB\-femit\-struct\-debug\-baseonly\fR" 4
+.IX Item "-femit-struct-debug-baseonly"
+Emit debug information for struct-like types
+only when the base name of the compilation source file
+matches the base name of file in which the struct is defined.
+.Sp
+This option substantially reduces the size of debugging information,
+but at significant potential loss in type information to the debugger.
+See \fB\-femit\-struct\-debug\-reduced\fR for a less aggressive option.
+See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
+.Sp
+This option works only with \s-1DWARF 2.\s0
+.IP "\fB\-femit\-struct\-debug\-reduced\fR" 4
+.IX Item "-femit-struct-debug-reduced"
+Emit debug information for struct-like types
+only when the base name of the compilation source file
+matches the base name of file in which the type is defined,
+unless the struct is a template or defined in a system header.
+.Sp
+This option significantly reduces the size of debugging information,
+with some potential loss in type information to the debugger.
+See \fB\-femit\-struct\-debug\-baseonly\fR for a more aggressive option.
+See \fB\-femit\-struct\-debug\-detailed\fR for more detailed control.
+.Sp
+This option works only with \s-1DWARF 2.\s0
+.IP "\fB\-femit\-struct\-debug\-detailed\fR[\fB=\fR\fIspec-list\fR]" 4
+.IX Item "-femit-struct-debug-detailed[=spec-list]"
+Specify the struct-like types
+for which the compiler generates debug information.
+The intent is to reduce duplicate struct debug information
+between different object files within the same program.
+.Sp
+This option is a detailed version of
+\&\fB\-femit\-struct\-debug\-reduced\fR and \fB\-femit\-struct\-debug\-baseonly\fR,
+which serves for most needs.
+.Sp
+A specification has the syntax[\fBdir:\fR|\fBind:\fR][\fBord:\fR|\fBgen:\fR](\fBany\fR|\fBsys\fR|\fBbase\fR|\fBnone\fR)
+.Sp
+The optional first word limits the specification to
+structs that are used directly (\fBdir:\fR) or used indirectly (\fBind:\fR).
+A struct type is used directly when it is the type of a variable, member.
+Indirect uses arise through pointers to structs.
+That is, when use of an incomplete struct is valid, the use is indirect.
+An example is
+\&\fBstruct one direct; struct two * indirect;\fR.
+.Sp
+The optional second word limits the specification to
+ordinary structs (\fBord:\fR) or generic structs (\fBgen:\fR).
+Generic structs are a bit complicated to explain.
+For \*(C+, these are non-explicit specializations of template classes,
+or non-template classes within the above.
+Other programming languages have generics,
+but \fB\-femit\-struct\-debug\-detailed\fR does not yet implement them.
+.Sp
+The third word specifies the source files for those
+structs for which the compiler should emit debug information.
+The values \fBnone\fR and \fBany\fR have the normal meaning.
+The value \fBbase\fR means that
+the base of name of the file in which the type declaration appears
+must match the base of the name of the main compilation file.
+In practice, this means that when compiling \fIfoo.c\fR, debug information
+is generated for types declared in that file and \fIfoo.h\fR,
+but not other header files.
+The value \fBsys\fR means those types satisfying \fBbase\fR
+or declared in system or compiler headers.
+.Sp
+You may need to experiment to determine the best settings for your application.
+.Sp
+The default is \fB\-femit\-struct\-debug\-detailed=all\fR.
+.Sp
+This option works only with \s-1DWARF 2.\s0
+.IP "\fB\-fno\-merge\-debug\-strings\fR" 4
+.IX Item "-fno-merge-debug-strings"
+Direct the linker to not merge together strings in the debugging
+information that are identical in different object files.  Merging is
+not supported by all assemblers or linkers.  Merging decreases the size
+of the debug information in the output file at the cost of increasing
+link processing time.  Merging is enabled by default.
+.IP "\fB\-fdebug\-prefix\-map=\fR\fIold\fR\fB=\fR\fInew\fR" 4
+.IX Item "-fdebug-prefix-map=old=new"
+When compiling files in directory \fI\fIold\fI\fR, record debugging
+information describing them as in \fI\fInew\fI\fR instead.
+.IP "\fB\-fno\-dwarf2\-cfi\-asm\fR" 4
+.IX Item "-fno-dwarf2-cfi-asm"
+Emit \s-1DWARF 2\s0 unwind info as compiler generated \f(CW\*(C`.eh_frame\*(C'\fR section
+instead of using \s-1GAS \s0\f(CW\*(C`.cfi_*\*(C'\fR directives.
+.IP "\fB\-p\fR" 4
+.IX Item "-p"
+Generate extra code to write profile information suitable for the
+analysis program \fBprof\fR.  You must use this option when compiling
+the source files you want data about, and you must also use it when
+linking.
+.IP "\fB\-pg\fR" 4
+.IX Item "-pg"
+Generate extra code to write profile information suitable for the
+analysis program \fBgprof\fR.  You must use this option when compiling
+the source files you want data about, and you must also use it when
+linking.
+.IP "\fB\-Q\fR" 4
+.IX Item "-Q"
+Makes the compiler print out each function name as it is compiled, and
+print some statistics about each pass when it finishes.
+.IP "\fB\-ftime\-report\fR" 4
+.IX Item "-ftime-report"
+Makes the compiler print some statistics about the time consumed by each
+pass when it finishes.
+.IP "\fB\-fmem\-report\fR" 4
+.IX Item "-fmem-report"
+Makes the compiler print some statistics about permanent memory
+allocation when it finishes.
+.IP "\fB\-fmem\-report\-wpa\fR" 4
+.IX Item "-fmem-report-wpa"
+Makes the compiler print some statistics about permanent memory
+allocation for the \s-1WPA\s0 phase only.
+.IP "\fB\-fpre\-ipa\-mem\-report\fR" 4
+.IX Item "-fpre-ipa-mem-report"
+.PD 0
+.IP "\fB\-fpost\-ipa\-mem\-report\fR" 4
+.IX Item "-fpost-ipa-mem-report"
+.PD
+Makes the compiler print some statistics about permanent memory
+allocation before or after interprocedural optimization.
+.IP "\fB\-fprofile\-report\fR" 4
+.IX Item "-fprofile-report"
+Makes the compiler print some statistics about consistency of the
+(estimated) profile and effect of individual passes.
+.IP "\fB\-fstack\-usage\fR" 4
+.IX Item "-fstack-usage"
+Makes the compiler output stack usage information for the program, on a
+per-function basis.  The filename for the dump is made by appending
+\&\fI.su\fR to the \fIauxname\fR.  \fIauxname\fR is generated from the name of
+the output file, if explicitly specified and it is not an executable,
+otherwise it is the basename of the source file.  An entry is made up
+of three fields:
+.RS 4
+.IP "\(bu" 4
+The name of the function.
+.IP "\(bu" 4
+A number of bytes.
+.IP "\(bu" 4
+One or more qualifiers: \f(CW\*(C`static\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`bounded\*(C'\fR.
+.RE
+.RS 4
+.Sp
+The qualifier \f(CW\*(C`static\*(C'\fR means that the function manipulates the stack
+statically: a fixed number of bytes are allocated for the frame on function
+entry and released on function exit; no stack adjustments are otherwise made
+in the function.  The second field is this fixed number of bytes.
+.Sp
+The qualifier \f(CW\*(C`dynamic\*(C'\fR means that the function manipulates the stack
+dynamically: in addition to the static allocation described above, stack
+adjustments are made in the body of the function, for example to push/pop
+arguments around function calls.  If the qualifier \f(CW\*(C`bounded\*(C'\fR is also
+present, the amount of these adjustments is bounded at compile time and
+the second field is an upper bound of the total amount of stack used by
+the function.  If it is not present, the amount of these adjustments is
+not bounded at compile time and the second field only represents the
+bounded part.
+.RE
+.IP "\fB\-fprofile\-arcs\fR" 4
+.IX Item "-fprofile-arcs"
+Add code so that program flow \fIarcs\fR are instrumented.  During
+execution the program records how many times each branch and call is
+executed and how many times it is taken or returns.  When the compiled
+program exits it saves this data to a file called
+\&\fI\fIauxname\fI.gcda\fR for each source file.  The data may be used for
+profile-directed optimizations (\fB\-fbranch\-probabilities\fR), or for
+test coverage analysis (\fB\-ftest\-coverage\fR).  Each object file's
+\&\fIauxname\fR is generated from the name of the output file, if
+explicitly specified and it is not the final executable, otherwise it is
+the basename of the source file.  In both cases any suffix is removed
+(e.g. \fIfoo.gcda\fR for input file \fIdir/foo.c\fR, or
+\&\fIdir/foo.gcda\fR for output file specified as \fB\-o dir/foo.o\fR).
+.IP "\fB\-\-coverage\fR" 4
+.IX Item "--coverage"
+This option is used to compile and link code instrumented for coverage
+analysis.  The option is a synonym for \fB\-fprofile\-arcs\fR
+\&\fB\-ftest\-coverage\fR (when compiling) and \fB\-lgcov\fR (when
+linking).  See the documentation for those options for more details.
+.RS 4
+.IP "\(bu" 4
+Compile the source files with \fB\-fprofile\-arcs\fR plus optimization
+and code generation options.  For test coverage analysis, use the
+additional \fB\-ftest\-coverage\fR option.  You do not need to profile
+every source file in a program.
+.IP "\(bu" 4
+Link your object files with \fB\-lgcov\fR or \fB\-fprofile\-arcs\fR
+(the latter implies the former).
+.IP "\(bu" 4
+Run the program on a representative workload to generate the arc profile
+information.  This may be repeated any number of times.  You can run
+concurrent instances of your program, and provided that the file system
+supports locking, the data files will be correctly updated.  Also
+\&\f(CW\*(C`fork\*(C'\fR calls are detected and correctly handled (double counting
+will not happen).
+.IP "\(bu" 4
+For profile-directed optimizations, compile the source files again with
+the same optimization and code generation options plus
+\&\fB\-fbranch\-probabilities\fR.
+.IP "\(bu" 4
+For test coverage analysis, use \fBgcov\fR to produce human readable
+information from the \fI.gcno\fR and \fI.gcda\fR files.  Refer to the
+\&\fBgcov\fR documentation for further information.
+.RE
+.RS 4
+.Sp
+With \fB\-fprofile\-arcs\fR, for each function of your program \s-1GCC\s0
+creates a program flow graph, then finds a spanning tree for the graph.
+Only arcs that are not on the spanning tree have to be instrumented: the
+compiler adds code to count the number of times that these arcs are
+executed.  When an arc is the only exit or only entrance to a block, the
+instrumentation code can be added to the block; otherwise, a new basic
+block must be created to hold the instrumentation code.
+.RE
+.IP "\fB\-ftest\-coverage\fR" 4
+.IX Item "-ftest-coverage"
+Produce a notes file that the \fBgcov\fR code-coverage utility can use to
+show program coverage.  Each source file's note file is called
+\&\fI\fIauxname\fI.gcno\fR.  Refer to the \fB\-fprofile\-arcs\fR option
+above for a description of \fIauxname\fR and instructions on how to
+generate test coverage data.  Coverage data matches the source files
+more closely if you do not optimize.
+.IP "\fB\-fdbg\-cnt\-list\fR" 4
+.IX Item "-fdbg-cnt-list"
+Print the name and the counter upper bound for all debug counters.
+.IP "\fB\-fdbg\-cnt=\fR\fIcounter-value-list\fR" 4
+.IX Item "-fdbg-cnt=counter-value-list"
+Set the internal debug counter upper bound.  \fIcounter-value-list\fR
+is a comma-separated list of \fIname\fR:\fIvalue\fR pairs
+which sets the upper bound of each debug counter \fIname\fR to \fIvalue\fR.
+All debug counters have the initial upper bound of \f(CW\*(C`UINT_MAX\*(C'\fR;
+thus \f(CW\*(C`dbg_cnt()\*(C'\fR returns true always unless the upper bound
+is set by this option.
+For example, with \fB\-fdbg\-cnt=dce:10,tail_call:0\fR,
+\&\f(CW\*(C`dbg_cnt(dce)\*(C'\fR returns true only for first 10 invocations.
+.IP "\fB\-fenable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR" 4
+.IX Item "-fenable-kind-pass"
+.PD 0
+.IP "\fB\-fdisable\-\fR\fIkind\fR\fB\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fdisable-kind-pass=range-list"
+.PD
+This is a set of options that are used to explicitly disable/enable
+optimization passes.  These options are intended for use for debugging \s-1GCC.\s0
+Compiler users should use regular options for enabling/disabling
+passes instead.
+.RS 4
+.IP "\fB\-fdisable\-ipa\-\fR\fIpass\fR" 4
+.IX Item "-fdisable-ipa-pass"
+Disable \s-1IPA\s0 pass \fIpass\fR. \fIpass\fR is the pass name.  If the same pass is
+statically invoked in the compiler multiple times, the pass name should be
+appended with a sequential number starting from 1.
+.IP "\fB\-fdisable\-rtl\-\fR\fIpass\fR" 4
+.IX Item "-fdisable-rtl-pass"
+.PD 0
+.IP "\fB\-fdisable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fdisable-rtl-pass=range-list"
+.PD
+Disable \s-1RTL\s0 pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
+statically invoked in the compiler multiple times, the pass name should be
+appended with a sequential number starting from 1.  \fIrange-list\fR is a 
+comma-separated list of function ranges or assembler names.  Each range is a number
+pair separated by a colon.  The range is inclusive in both ends.  If the range
+is trivial, the number pair can be simplified as a single number.  If the
+function's call graph node's \fIuid\fR falls within one of the specified ranges,
+the \fIpass\fR is disabled for that function.  The \fIuid\fR is shown in the
+function header of a dump file, and the pass names can be dumped by using
+option \fB\-fdump\-passes\fR.
+.IP "\fB\-fdisable\-tree\-\fR\fIpass\fR" 4
+.IX Item "-fdisable-tree-pass"
+.PD 0
+.IP "\fB\-fdisable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fdisable-tree-pass=range-list"
+.PD
+Disable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description of
+option arguments.
+.IP "\fB\-fenable\-ipa\-\fR\fIpass\fR" 4
+.IX Item "-fenable-ipa-pass"
+Enable \s-1IPA\s0 pass \fIpass\fR.  \fIpass\fR is the pass name.  If the same pass is
+statically invoked in the compiler multiple times, the pass name should be
+appended with a sequential number starting from 1.
+.IP "\fB\-fenable\-rtl\-\fR\fIpass\fR" 4
+.IX Item "-fenable-rtl-pass"
+.PD 0
+.IP "\fB\-fenable\-rtl\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fenable-rtl-pass=range-list"
+.PD
+Enable \s-1RTL\s0 pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for option argument
+description and examples.
+.IP "\fB\-fenable\-tree\-\fR\fIpass\fR" 4
+.IX Item "-fenable-tree-pass"
+.PD 0
+.IP "\fB\-fenable\-tree\-\fR\fIpass\fR\fB=\fR\fIrange-list\fR" 4
+.IX Item "-fenable-tree-pass=range-list"
+.PD
+Enable tree pass \fIpass\fR.  See \fB\-fdisable\-rtl\fR for the description
+of option arguments.
+.RE
+.RS 4
+.Sp
+Here are some examples showing uses of these options.
+.Sp
+.Vb 10
+\&        # disable ccp1 for all functions
+\&           \-fdisable\-tree\-ccp1
+\&        # disable complete unroll for function whose cgraph node uid is 1
+\&           \-fenable\-tree\-cunroll=1
+\&        # disable gcse2 for functions at the following ranges [1,1],
+\&        # [300,400], and [400,1000]
+\&        # disable gcse2 for functions foo and foo2
+\&           \-fdisable\-rtl\-gcse2=foo,foo2
+\&        # disable early inlining
+\&           \-fdisable\-tree\-einline
+\&        # disable ipa inlining
+\&           \-fdisable\-ipa\-inline
+\&        # enable tree full unroll
+\&           \-fenable\-tree\-unroll
+.Ve
+.RE
+.IP "\fB\-d\fR\fIletters\fR" 4
+.IX Item "-dletters"
+.PD 0
+.IP "\fB\-fdump\-rtl\-\fR\fIpass\fR" 4
+.IX Item "-fdump-rtl-pass"
+.IP "\fB\-fdump\-rtl\-\fR\fIpass\fR\fB=\fR\fIfilename\fR" 4
+.IX Item "-fdump-rtl-pass=filename"
+.PD
+Says to make debugging dumps during compilation at times specified by
+\&\fIletters\fR.  This is used for debugging the RTL-based passes of the
+compiler.  The file names for most of the dumps are made by appending
+a pass number and a word to the \fIdumpname\fR, and the files are
+created in the directory of the output file. In case of
+\&\fB=\fR\fIfilename\fR option, the dump is output on the given file
+instead of the pass numbered dump files. Note that the pass number is
+computed statically as passes get registered into the pass manager.
+Thus the numbering is not related to the dynamic order of execution of
+passes.  In particular, a pass installed by a plugin could have a
+number over 200 even if it executed quite early.  \fIdumpname\fR is
+generated from the name of the output file, if explicitly specified
+and it is not an executable, otherwise it is the basename of the
+source file. These switches may have different effects when
+\&\fB\-E\fR is used for preprocessing.
+.Sp
+Debug dumps can be enabled with a \fB\-fdump\-rtl\fR switch or some
+\&\fB\-d\fR option \fIletters\fR.  Here are the possible
+letters for use in \fIpass\fR and \fIletters\fR, and their meanings:
+.RS 4
+.IP "\fB\-fdump\-rtl\-alignments\fR" 4
+.IX Item "-fdump-rtl-alignments"
+Dump after branch alignments have been computed.
+.IP "\fB\-fdump\-rtl\-asmcons\fR" 4
+.IX Item "-fdump-rtl-asmcons"
+Dump after fixing rtl statements that have unsatisfied in/out constraints.
+.IP "\fB\-fdump\-rtl\-auto_inc_dec\fR" 4
+.IX Item "-fdump-rtl-auto_inc_dec"
+Dump after auto-inc-dec discovery.  This pass is only run on
+architectures that have auto inc or auto dec instructions.
+.IP "\fB\-fdump\-rtl\-barriers\fR" 4
+.IX Item "-fdump-rtl-barriers"
+Dump after cleaning up the barrier instructions.
+.IP "\fB\-fdump\-rtl\-bbpart\fR" 4
+.IX Item "-fdump-rtl-bbpart"
+Dump after partitioning hot and cold basic blocks.
+.IP "\fB\-fdump\-rtl\-bbro\fR" 4
+.IX Item "-fdump-rtl-bbro"
+Dump after block reordering.
+.IP "\fB\-fdump\-rtl\-btl1\fR" 4
+.IX Item "-fdump-rtl-btl1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-btl2\fR" 4
+.IX Item "-fdump-rtl-btl2"
+.PD
+\&\fB\-fdump\-rtl\-btl1\fR and \fB\-fdump\-rtl\-btl2\fR enable dumping
+after the two branch
+target load optimization passes.
+.IP "\fB\-fdump\-rtl\-bypass\fR" 4
+.IX Item "-fdump-rtl-bypass"
+Dump after jump bypassing and control flow optimizations.
+.IP "\fB\-fdump\-rtl\-combine\fR" 4
+.IX Item "-fdump-rtl-combine"
+Dump after the \s-1RTL\s0 instruction combination pass.
+.IP "\fB\-fdump\-rtl\-compgotos\fR" 4
+.IX Item "-fdump-rtl-compgotos"
+Dump after duplicating the computed gotos.
+.IP "\fB\-fdump\-rtl\-ce1\fR" 4
+.IX Item "-fdump-rtl-ce1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-ce2\fR" 4
+.IX Item "-fdump-rtl-ce2"
+.IP "\fB\-fdump\-rtl\-ce3\fR" 4
+.IX Item "-fdump-rtl-ce3"
+.PD
+\&\fB\-fdump\-rtl\-ce1\fR, \fB\-fdump\-rtl\-ce2\fR, and
+\&\fB\-fdump\-rtl\-ce3\fR enable dumping after the three
+if conversion passes.
+.IP "\fB\-fdump\-rtl\-cprop_hardreg\fR" 4
+.IX Item "-fdump-rtl-cprop_hardreg"
+Dump after hard register copy propagation.
+.IP "\fB\-fdump\-rtl\-csa\fR" 4
+.IX Item "-fdump-rtl-csa"
+Dump after combining stack adjustments.
+.IP "\fB\-fdump\-rtl\-cse1\fR" 4
+.IX Item "-fdump-rtl-cse1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-cse2\fR" 4
+.IX Item "-fdump-rtl-cse2"
+.PD
+\&\fB\-fdump\-rtl\-cse1\fR and \fB\-fdump\-rtl\-cse2\fR enable dumping after
+the two common subexpression elimination passes.
+.IP "\fB\-fdump\-rtl\-dce\fR" 4
+.IX Item "-fdump-rtl-dce"
+Dump after the standalone dead code elimination passes.
+.IP "\fB\-fdump\-rtl\-dbr\fR" 4
+.IX Item "-fdump-rtl-dbr"
+Dump after delayed branch scheduling.
+.IP "\fB\-fdump\-rtl\-dce1\fR" 4
+.IX Item "-fdump-rtl-dce1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-dce2\fR" 4
+.IX Item "-fdump-rtl-dce2"
+.PD
+\&\fB\-fdump\-rtl\-dce1\fR and \fB\-fdump\-rtl\-dce2\fR enable dumping after
+the two dead store elimination passes.
+.IP "\fB\-fdump\-rtl\-eh\fR" 4
+.IX Item "-fdump-rtl-eh"
+Dump after finalization of \s-1EH\s0 handling code.
+.IP "\fB\-fdump\-rtl\-eh_ranges\fR" 4
+.IX Item "-fdump-rtl-eh_ranges"
+Dump after conversion of \s-1EH\s0 handling range regions.
+.IP "\fB\-fdump\-rtl\-expand\fR" 4
+.IX Item "-fdump-rtl-expand"
+Dump after \s-1RTL\s0 generation.
+.IP "\fB\-fdump\-rtl\-fwprop1\fR" 4
+.IX Item "-fdump-rtl-fwprop1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-fwprop2\fR" 4
+.IX Item "-fdump-rtl-fwprop2"
+.PD
+\&\fB\-fdump\-rtl\-fwprop1\fR and \fB\-fdump\-rtl\-fwprop2\fR enable
+dumping after the two forward propagation passes.
+.IP "\fB\-fdump\-rtl\-gcse1\fR" 4
+.IX Item "-fdump-rtl-gcse1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-gcse2\fR" 4
+.IX Item "-fdump-rtl-gcse2"
+.PD
+\&\fB\-fdump\-rtl\-gcse1\fR and \fB\-fdump\-rtl\-gcse2\fR enable dumping
+after global common subexpression elimination.
+.IP "\fB\-fdump\-rtl\-init\-regs\fR" 4
+.IX Item "-fdump-rtl-init-regs"
+Dump after the initialization of the registers.
+.IP "\fB\-fdump\-rtl\-initvals\fR" 4
+.IX Item "-fdump-rtl-initvals"
+Dump after the computation of the initial value sets.
+.IP "\fB\-fdump\-rtl\-into_cfglayout\fR" 4
+.IX Item "-fdump-rtl-into_cfglayout"
+Dump after converting to cfglayout mode.
+.IP "\fB\-fdump\-rtl\-ira\fR" 4
+.IX Item "-fdump-rtl-ira"
+Dump after iterated register allocation.
+.IP "\fB\-fdump\-rtl\-jump\fR" 4
+.IX Item "-fdump-rtl-jump"
+Dump after the second jump optimization.
+.IP "\fB\-fdump\-rtl\-loop2\fR" 4
+.IX Item "-fdump-rtl-loop2"
+\&\fB\-fdump\-rtl\-loop2\fR enables dumping after the rtl
+loop optimization passes.
+.IP "\fB\-fdump\-rtl\-mach\fR" 4
+.IX Item "-fdump-rtl-mach"
+Dump after performing the machine dependent reorganization pass, if that
+pass exists.
+.IP "\fB\-fdump\-rtl\-mode_sw\fR" 4
+.IX Item "-fdump-rtl-mode_sw"
+Dump after removing redundant mode switches.
+.IP "\fB\-fdump\-rtl\-rnreg\fR" 4
+.IX Item "-fdump-rtl-rnreg"
+Dump after register renumbering.
+.IP "\fB\-fdump\-rtl\-outof_cfglayout\fR" 4
+.IX Item "-fdump-rtl-outof_cfglayout"
+Dump after converting from cfglayout mode.
+.IP "\fB\-fdump\-rtl\-peephole2\fR" 4
+.IX Item "-fdump-rtl-peephole2"
+Dump after the peephole pass.
+.IP "\fB\-fdump\-rtl\-postreload\fR" 4
+.IX Item "-fdump-rtl-postreload"
+Dump after post-reload optimizations.
+.IP "\fB\-fdump\-rtl\-pro_and_epilogue\fR" 4
+.IX Item "-fdump-rtl-pro_and_epilogue"
+Dump after generating the function prologues and epilogues.
+.IP "\fB\-fdump\-rtl\-sched1\fR" 4
+.IX Item "-fdump-rtl-sched1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-sched2\fR" 4
+.IX Item "-fdump-rtl-sched2"
+.PD
+\&\fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR enable dumping
+after the basic block scheduling passes.
+.IP "\fB\-fdump\-rtl\-ree\fR" 4
+.IX Item "-fdump-rtl-ree"
+Dump after sign/zero extension elimination.
+.IP "\fB\-fdump\-rtl\-seqabstr\fR" 4
+.IX Item "-fdump-rtl-seqabstr"
+Dump after common sequence discovery.
+.IP "\fB\-fdump\-rtl\-shorten\fR" 4
+.IX Item "-fdump-rtl-shorten"
+Dump after shortening branches.
+.IP "\fB\-fdump\-rtl\-sibling\fR" 4
+.IX Item "-fdump-rtl-sibling"
+Dump after sibling call optimizations.
+.IP "\fB\-fdump\-rtl\-split1\fR" 4
+.IX Item "-fdump-rtl-split1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-split2\fR" 4
+.IX Item "-fdump-rtl-split2"
+.IP "\fB\-fdump\-rtl\-split3\fR" 4
+.IX Item "-fdump-rtl-split3"
+.IP "\fB\-fdump\-rtl\-split4\fR" 4
+.IX Item "-fdump-rtl-split4"
+.IP "\fB\-fdump\-rtl\-split5\fR" 4
+.IX Item "-fdump-rtl-split5"
+.PD
+\&\fB\-fdump\-rtl\-split1\fR, \fB\-fdump\-rtl\-split2\fR,
+\&\fB\-fdump\-rtl\-split3\fR, \fB\-fdump\-rtl\-split4\fR and
+\&\fB\-fdump\-rtl\-split5\fR enable dumping after five rounds of
+instruction splitting.
+.IP "\fB\-fdump\-rtl\-sms\fR" 4
+.IX Item "-fdump-rtl-sms"
+Dump after modulo scheduling.  This pass is only run on some
+architectures.
+.IP "\fB\-fdump\-rtl\-stack\fR" 4
+.IX Item "-fdump-rtl-stack"
+Dump after conversion from \s-1GCC\s0's \*(L"flat register file\*(R" registers to the
+x87's stack-like registers.  This pass is only run on x86 variants.
+.IP "\fB\-fdump\-rtl\-subreg1\fR" 4
+.IX Item "-fdump-rtl-subreg1"
+.PD 0
+.IP "\fB\-fdump\-rtl\-subreg2\fR" 4
+.IX Item "-fdump-rtl-subreg2"
+.PD
+\&\fB\-fdump\-rtl\-subreg1\fR and \fB\-fdump\-rtl\-subreg2\fR enable dumping after
+the two subreg expansion passes.
+.IP "\fB\-fdump\-rtl\-unshare\fR" 4
+.IX Item "-fdump-rtl-unshare"
+Dump after all rtl has been unshared.
+.IP "\fB\-fdump\-rtl\-vartrack\fR" 4
+.IX Item "-fdump-rtl-vartrack"
+Dump after variable tracking.
+.IP "\fB\-fdump\-rtl\-vregs\fR" 4
+.IX Item "-fdump-rtl-vregs"
+Dump after converting virtual registers to hard registers.
+.IP "\fB\-fdump\-rtl\-web\fR" 4
+.IX Item "-fdump-rtl-web"
+Dump after live range splitting.
+.IP "\fB\-fdump\-rtl\-regclass\fR" 4
+.IX Item "-fdump-rtl-regclass"
+.PD 0
+.IP "\fB\-fdump\-rtl\-subregs_of_mode_init\fR" 4
+.IX Item "-fdump-rtl-subregs_of_mode_init"
+.IP "\fB\-fdump\-rtl\-subregs_of_mode_finish\fR" 4
+.IX Item "-fdump-rtl-subregs_of_mode_finish"
+.IP "\fB\-fdump\-rtl\-dfinit\fR" 4
+.IX Item "-fdump-rtl-dfinit"
+.IP "\fB\-fdump\-rtl\-dfinish\fR" 4
+.IX Item "-fdump-rtl-dfinish"
+.PD
+These dumps are defined but always produce empty files.
+.IP "\fB\-da\fR" 4
+.IX Item "-da"
+.PD 0
+.IP "\fB\-fdump\-rtl\-all\fR" 4
+.IX Item "-fdump-rtl-all"
+.PD
+Produce all the dumps listed above.
+.IP "\fB\-dA\fR" 4
+.IX Item "-dA"
+Annotate the assembler output with miscellaneous debugging information.
+.IP "\fB\-dD\fR" 4
+.IX Item "-dD"
+Dump all macro definitions, at the end of preprocessing, in addition to
+normal output.
+.IP "\fB\-dH\fR" 4
+.IX Item "-dH"
+Produce a core dump whenever an error occurs.
+.IP "\fB\-dp\fR" 4
+.IX Item "-dp"
+Annotate the assembler output with a comment indicating which
+pattern and alternative is used.  The length of each instruction is
+also printed.
+.IP "\fB\-dP\fR" 4
+.IX Item "-dP"
+Dump the \s-1RTL\s0 in the assembler output as a comment before each instruction.
+Also turns on \fB\-dp\fR annotation.
+.IP "\fB\-dx\fR" 4
+.IX Item "-dx"
+Just generate \s-1RTL\s0 for a function instead of compiling it.  Usually used
+with \fB\-fdump\-rtl\-expand\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fdump\-noaddr\fR" 4
+.IX Item "-fdump-noaddr"
+When doing debugging dumps, suppress address output.  This makes it more
+feasible to use diff on debugging dumps for compiler invocations with
+different compiler binaries and/or different
+text / bss / data / heap / stack / dso start locations.
+.IP "\fB\-fdump\-unnumbered\fR" 4
+.IX Item "-fdump-unnumbered"
+When doing debugging dumps, suppress instruction numbers and address output.
+This makes it more feasible to use diff on debugging dumps for compiler
+invocations with different options, in particular with and without
+\&\fB\-g\fR.
+.IP "\fB\-fdump\-unnumbered\-links\fR" 4
+.IX Item "-fdump-unnumbered-links"
+When doing debugging dumps (see \fB\-d\fR option above), suppress
+instruction numbers for the links to the previous and next instructions
+in a sequence.
+.IP "\fB\-fdump\-translation\-unit\fR (\*(C+ only)" 4
+.IX Item "-fdump-translation-unit ( only)"
+.PD 0
+.IP "\fB\-fdump\-translation\-unit\-\fR\fIoptions\fR\fB \fR(\*(C+ only)" 4
+.IX Item "-fdump-translation-unit-options ( only)"
+.PD
+Dump a representation of the tree structure for the entire translation
+unit to a file.  The file name is made by appending \fI.tu\fR to the
+source file name, and the file is created in the same directory as the
+output file.  If the \fB\-\fR\fIoptions\fR form is used, \fIoptions\fR
+controls the details of the dump as described for the
+\&\fB\-fdump\-tree\fR options.
+.IP "\fB\-fdump\-class\-hierarchy\fR (\*(C+ only)" 4
+.IX Item "-fdump-class-hierarchy ( only)"
+.PD 0
+.IP "\fB\-fdump\-class\-hierarchy\-\fR\fIoptions\fR\fB \fR(\*(C+ only)" 4
+.IX Item "-fdump-class-hierarchy-options ( only)"
+.PD
+Dump a representation of each class's hierarchy and virtual function
+table layout to a file.  The file name is made by appending
+\&\fI.class\fR to the source file name, and the file is created in the
+same directory as the output file.  If the \fB\-\fR\fIoptions\fR form
+is used, \fIoptions\fR controls the details of the dump as described
+for the \fB\-fdump\-tree\fR options.
+.IP "\fB\-fdump\-ipa\-\fR\fIswitch\fR" 4
+.IX Item "-fdump-ipa-switch"
+Control the dumping at various stages of inter-procedural analysis
+language tree to a file.  The file name is generated by appending a
+switch specific suffix to the source file name, and the file is created
+in the same directory as the output file.  The following dumps are
+possible:
+.RS 4
+.IP "\fBall\fR" 4
+.IX Item "all"
+Enables all inter-procedural analysis dumps.
+.IP "\fBcgraph\fR" 4
+.IX Item "cgraph"
+Dumps information about call-graph optimization, unused function removal,
+and inlining decisions.
+.IP "\fBinline\fR" 4
+.IX Item "inline"
+Dump after function inlining.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fdump\-passes\fR" 4
+.IX Item "-fdump-passes"
+Dump the list of optimization passes that are turned on and off by
+the current command-line options.
+.IP "\fB\-fdump\-statistics\-\fR\fIoption\fR" 4
+.IX Item "-fdump-statistics-option"
+Enable and control dumping of pass statistics in a separate file.  The
+file name is generated by appending a suffix ending in
+\&\fB.statistics\fR to the source file name, and the file is created in
+the same directory as the output file.  If the \fB\-\fR\fIoption\fR
+form is used, \fB\-stats\fR causes counters to be summed over the
+whole compilation unit while \fB\-details\fR dumps every event as
+the passes generate them.  The default with no option is to sum
+counters for each function compiled.
+.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR" 4
+.IX Item "-fdump-tree-switch"
+.PD 0
+.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR" 4
+.IX Item "-fdump-tree-switch-options"
+.IP "\fB\-fdump\-tree\-\fR\fIswitch\fR\fB\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
+.IX Item "-fdump-tree-switch-options=filename"
+.PD
+Control the dumping at various stages of processing the intermediate
+language tree to a file.  The file name is generated by appending a
+switch-specific suffix to the source file name, and the file is
+created in the same directory as the output file. In case of
+\&\fB=\fR\fIfilename\fR option, the dump is output on the given file
+instead of the auto named dump files.  If the \fB\-\fR\fIoptions\fR
+form is used, \fIoptions\fR is a list of \fB\-\fR separated options
+which control the details of the dump.  Not all options are applicable
+to all dumps; those that are not meaningful are ignored.  The
+following options are available
+.RS 4
+.IP "\fBaddress\fR" 4
+.IX Item "address"
+Print the address of each node.  Usually this is not meaningful as it
+changes according to the environment and source file.  Its primary use
+is for tying up a dump file with a debug environment.
+.IP "\fBasmname\fR" 4
+.IX Item "asmname"
+If \f(CW\*(C`DECL_ASSEMBLER_NAME\*(C'\fR has been set for a given decl, use that
+in the dump instead of \f(CW\*(C`DECL_NAME\*(C'\fR.  Its primary use is ease of
+use working backward from mangled names in the assembly file.
+.IP "\fBslim\fR" 4
+.IX Item "slim"
+When dumping front-end intermediate representations, inhibit dumping
+of members of a scope or body of a function merely because that scope
+has been reached.  Only dump such items when they are directly reachable
+by some other path.
+.Sp
+When dumping pretty-printed trees, this option inhibits dumping the
+bodies of control structures.
+.Sp
+When dumping \s-1RTL,\s0 print the \s-1RTL\s0 in slim (condensed) form instead of
+the default LISP-like representation.
+.IP "\fBraw\fR" 4
+.IX Item "raw"
+Print a raw representation of the tree.  By default, trees are
+pretty-printed into a C\-like representation.
+.IP "\fBdetails\fR" 4
+.IX Item "details"
+Enable more detailed dumps (not honored by every dump option). Also
+include information from the optimization passes.
+.IP "\fBstats\fR" 4
+.IX Item "stats"
+Enable dumping various statistics about the pass (not honored by every dump
+option).
+.IP "\fBblocks\fR" 4
+.IX Item "blocks"
+Enable showing basic block boundaries (disabled in raw dumps).
+.IP "\fBgraph\fR" 4
+.IX Item "graph"
+For each of the other indicated dump files (\fB\-fdump\-rtl\-\fR\fIpass\fR),
+dump a representation of the control flow graph suitable for viewing with
+GraphViz to \fI\fIfile\fI.\fIpassid\fI.\fIpass\fI.dot\fR.  Each function in
+the file is pretty-printed as a subgraph, so that GraphViz can render them
+all in a single plot.
+.Sp
+This option currently only works for \s-1RTL\s0 dumps, and the \s-1RTL\s0 is always
+dumped in slim form.
+.IP "\fBvops\fR" 4
+.IX Item "vops"
+Enable showing virtual operands for every statement.
+.IP "\fBlineno\fR" 4
+.IX Item "lineno"
+Enable showing line numbers for statements.
+.IP "\fBuid\fR" 4
+.IX Item "uid"
+Enable showing the unique \s-1ID \s0(\f(CW\*(C`DECL_UID\*(C'\fR) for each variable.
+.IP "\fBverbose\fR" 4
+.IX Item "verbose"
+Enable showing the tree dump for each statement.
+.IP "\fBeh\fR" 4
+.IX Item "eh"
+Enable showing the \s-1EH\s0 region number holding each statement.
+.IP "\fBscev\fR" 4
+.IX Item "scev"
+Enable showing scalar evolution analysis details.
+.IP "\fBoptimized\fR" 4
+.IX Item "optimized"
+Enable showing optimization information (only available in certain
+passes).
+.IP "\fBmissed\fR" 4
+.IX Item "missed"
+Enable showing missed optimization information (only available in certain
+passes).
+.IP "\fBnotes\fR" 4
+.IX Item "notes"
+Enable other detailed optimization information (only available in
+certain passes).
+.IP "\fB=\fR\fIfilename\fR" 4
+.IX Item "=filename"
+Instead of an auto named dump file, output into the given file
+name. The file names \fIstdout\fR and \fIstderr\fR are treated
+specially and are considered already open standard streams. For
+example,
+.Sp
+.Vb 2
+\&        gcc \-O2 \-ftree\-vectorize \-fdump\-tree\-vect\-blocks=foo.dump
+\&             \-fdump\-tree\-pre=stderr file.c
+.Ve
+.Sp
+outputs vectorizer dump into \fIfoo.dump\fR, while the \s-1PRE\s0 dump is
+output on to \fIstderr\fR. If two conflicting dump filenames are
+given for the same pass, then the latter option overrides the earlier
+one.
+.IP "\fBall\fR" 4
+.IX Item "all"
+Turn on all options, except \fBraw\fR, \fBslim\fR, \fBverbose\fR
+and \fBlineno\fR.
+.IP "\fBoptall\fR" 4
+.IX Item "optall"
+Turn on all optimization options, i.e., \fBoptimized\fR,
+\&\fBmissed\fR, and \fBnote\fR.
+.RE
+.RS 4
+.Sp
+The following tree dumps are possible:
+.IP "\fBoriginal\fR" 4
+.IX Item "original"
+Dump before any tree based optimization, to \fI\fIfile\fI.original\fR.
+.IP "\fBoptimized\fR" 4
+.IX Item "optimized"
+Dump after all tree based optimization, to \fI\fIfile\fI.optimized\fR.
+.IP "\fBgimple\fR" 4
+.IX Item "gimple"
+Dump each function before and after the gimplification pass to a file.  The
+file name is made by appending \fI.gimple\fR to the source file name.
+.IP "\fBcfg\fR" 4
+.IX Item "cfg"
+Dump the control flow graph of each function to a file.  The file name is
+made by appending \fI.cfg\fR to the source file name.
+.IP "\fBch\fR" 4
+.IX Item "ch"
+Dump each function after copying loop headers.  The file name is made by
+appending \fI.ch\fR to the source file name.
+.IP "\fBssa\fR" 4
+.IX Item "ssa"
+Dump \s-1SSA\s0 related information to a file.  The file name is made by appending
+\&\fI.ssa\fR to the source file name.
+.IP "\fBalias\fR" 4
+.IX Item "alias"
+Dump aliasing information for each function.  The file name is made by
+appending \fI.alias\fR to the source file name.
+.IP "\fBccp\fR" 4
+.IX Item "ccp"
+Dump each function after \s-1CCP. \s0 The file name is made by appending
+\&\fI.ccp\fR to the source file name.
+.IP "\fBstoreccp\fR" 4
+.IX Item "storeccp"
+Dump each function after STORE-CCP.  The file name is made by appending
+\&\fI.storeccp\fR to the source file name.
+.IP "\fBpre\fR" 4
+.IX Item "pre"
+Dump trees after partial redundancy elimination.  The file name is made
+by appending \fI.pre\fR to the source file name.
+.IP "\fBfre\fR" 4
+.IX Item "fre"
+Dump trees after full redundancy elimination.  The file name is made
+by appending \fI.fre\fR to the source file name.
+.IP "\fBcopyprop\fR" 4
+.IX Item "copyprop"
+Dump trees after copy propagation.  The file name is made
+by appending \fI.copyprop\fR to the source file name.
+.IP "\fBstore_copyprop\fR" 4
+.IX Item "store_copyprop"
+Dump trees after store copy-propagation.  The file name is made
+by appending \fI.store_copyprop\fR to the source file name.
+.IP "\fBdce\fR" 4
+.IX Item "dce"
+Dump each function after dead code elimination.  The file name is made by
+appending \fI.dce\fR to the source file name.
+.IP "\fBsra\fR" 4
+.IX Item "sra"
+Dump each function after performing scalar replacement of aggregates.  The
+file name is made by appending \fI.sra\fR to the source file name.
+.IP "\fBsink\fR" 4
+.IX Item "sink"
+Dump each function after performing code sinking.  The file name is made
+by appending \fI.sink\fR to the source file name.
+.IP "\fBdom\fR" 4
+.IX Item "dom"
+Dump each function after applying dominator tree optimizations.  The file
+name is made by appending \fI.dom\fR to the source file name.
+.IP "\fBdse\fR" 4
+.IX Item "dse"
+Dump each function after applying dead store elimination.  The file
+name is made by appending \fI.dse\fR to the source file name.
+.IP "\fBphiopt\fR" 4
+.IX Item "phiopt"
+Dump each function after optimizing \s-1PHI\s0 nodes into straightline code.  The file
+name is made by appending \fI.phiopt\fR to the source file name.
+.IP "\fBforwprop\fR" 4
+.IX Item "forwprop"
+Dump each function after forward propagating single use variables.  The file
+name is made by appending \fI.forwprop\fR to the source file name.
+.IP "\fBcopyrename\fR" 4
+.IX Item "copyrename"
+Dump each function after applying the copy rename optimization.  The file
+name is made by appending \fI.copyrename\fR to the source file name.
+.IP "\fBnrv\fR" 4
+.IX Item "nrv"
+Dump each function after applying the named return value optimization on
+generic trees.  The file name is made by appending \fI.nrv\fR to the source
+file name.
+.IP "\fBvect\fR" 4
+.IX Item "vect"
+Dump each function after applying vectorization of loops.  The file name is
+made by appending \fI.vect\fR to the source file name.
+.IP "\fBslp\fR" 4
+.IX Item "slp"
+Dump each function after applying vectorization of basic blocks.  The file name
+is made by appending \fI.slp\fR to the source file name.
+.IP "\fBvrp\fR" 4
+.IX Item "vrp"
+Dump each function after Value Range Propagation (\s-1VRP\s0).  The file name
+is made by appending \fI.vrp\fR to the source file name.
+.IP "\fBall\fR" 4
+.IX Item "all"
+Enable all the available tree dumps with the flags provided in this option.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fopt\-info\fR" 4
+.IX Item "-fopt-info"
+.PD 0
+.IP "\fB\-fopt\-info\-\fR\fIoptions\fR" 4
+.IX Item "-fopt-info-options"
+.IP "\fB\-fopt\-info\-\fR\fIoptions\fR\fB=\fR\fIfilename\fR" 4
+.IX Item "-fopt-info-options=filename"
+.PD
+Controls optimization dumps from various optimization passes. If the
+\&\fB\-\fR\fIoptions\fR form is used, \fIoptions\fR is a list of
+\&\fB\-\fR separated options to select the dump details and
+optimizations.  If \fIoptions\fR is not specified, it defaults to
+\&\fBoptimized\fR for details and \fBoptall\fR for optimization
+groups. If the \fIfilename\fR is not specified, it defaults to
+\&\fIstderr\fR. Note that the output \fIfilename\fR will be overwritten
+in case of multiple translation units. If a combined output from
+multiple translation units is desired, \fIstderr\fR should be used
+instead.
+.Sp
+The options can be divided into two groups, 1) options describing the
+verbosity of the dump, and 2) options describing which optimizations
+should be included. The options from both the groups can be freely
+mixed as they are non-overlapping. However, in case of any conflicts,
+the latter options override the earlier options on the command
+line. Though multiple \-fopt\-info options are accepted, only one of
+them can have \fB=filename\fR. If other filenames are provided then
+all but the first one are ignored.
+.Sp
+The dump verbosity has the following options
+.RS 4
+.IP "\fBoptimized\fR" 4
+.IX Item "optimized"
+Print information when an optimization is successfully applied. It is
+up to a pass to decide which information is relevant. For example, the
+vectorizer passes print the source location of loops which got
+successfully vectorized.
+.IP "\fBmissed\fR" 4
+.IX Item "missed"
+Print information about missed optimizations. Individual passes
+control which information to include in the output. For example,
+.Sp
+.Vb 1
+\&        gcc \-O2 \-ftree\-vectorize \-fopt\-info\-vec\-missed
+.Ve
+.Sp
+will print information about missed optimization opportunities from
+vectorization passes on stderr.
+.IP "\fBnote\fR" 4
+.IX Item "note"
+Print verbose information about optimizations, such as certain
+transformations, more detailed messages about decisions etc.
+.IP "\fBall\fR" 4
+.IX Item "all"
+Print detailed optimization information. This includes
+\&\fIoptimized\fR, \fImissed\fR, and \fInote\fR.
+.RE
+.RS 4
+.Sp
+The second set of options describes a group of optimizations and may
+include one or more of the following.
+.IP "\fBipa\fR" 4
+.IX Item "ipa"
+Enable dumps from all interprocedural optimizations.
+.IP "\fBloop\fR" 4
+.IX Item "loop"
+Enable dumps from all loop optimizations.
+.IP "\fBinline\fR" 4
+.IX Item "inline"
+Enable dumps from all inlining optimizations.
+.IP "\fBvec\fR" 4
+.IX Item "vec"
+Enable dumps from all vectorization optimizations.
+.IP "\fBoptall\fR" 4
+.IX Item "optall"
+Enable dumps from all optimizations. This is a superset of
+the optimization groups listed above.
+.RE
+.RS 4
+.Sp
+For example,
+.Sp
+.Vb 1
+\&        gcc \-O3 \-fopt\-info\-missed=missed.all
+.Ve
+.Sp
+outputs missed optimization report from all the passes into
+\&\fImissed.all\fR.
+.Sp
+As another example,
+.Sp
+.Vb 1
+\&        gcc \-O3 \-fopt\-info\-inline\-optimized\-missed=inline.txt
+.Ve
+.Sp
+will output information about missed optimizations as well as
+optimized locations from all the inlining passes into
+\&\fIinline.txt\fR.
+.Sp
+If the \fIfilename\fR is provided, then the dumps from all the
+applicable optimizations are concatenated into the \fIfilename\fR.
+Otherwise the dump is output onto \fIstderr\fR. If \fIoptions\fR is
+omitted, it defaults to \fBall-optall\fR, which means dump all
+available optimization info from all the passes. In the following
+example, all optimization info is output on to \fIstderr\fR.
+.Sp
+.Vb 1
+\&        gcc \-O3 \-fopt\-info
+.Ve
+.Sp
+Note that \fB\-fopt\-info\-vec\-missed\fR behaves the same as
+\&\fB\-fopt\-info\-missed\-vec\fR.
+.Sp
+As another example, consider
+.Sp
+.Vb 1
+\&        gcc \-fopt\-info\-vec\-missed=vec.miss \-fopt\-info\-loop\-optimized=loop.opt
+.Ve
+.Sp
+Here the two output filenames \fIvec.miss\fR and \fIloop.opt\fR are
+in conflict since only one output file is allowed. In this case, only
+the first option takes effect and the subsequent options are
+ignored. Thus only the \fIvec.miss\fR is produced which contains
+dumps from the vectorizer about missed opportunities.
+.RE
+.IP "\fB\-frandom\-seed=\fR\fIstring\fR" 4
+.IX Item "-frandom-seed=string"
+This option provides a seed that \s-1GCC\s0 uses in place of
+random numbers in generating certain symbol names
+that have to be different in every compiled file.  It is also used to
+place unique stamps in coverage data files and the object files that
+produce them.  You can use the \fB\-frandom\-seed\fR option to produce
+reproducibly identical object files.
+.Sp
+The \fIstring\fR should be different for every file you compile.
+.IP "\fB\-fsched\-verbose=\fR\fIn\fR" 4
+.IX Item "-fsched-verbose=n"
+On targets that use instruction scheduling, this option controls the
+amount of debugging output the scheduler prints.  This information is
+written to standard error, unless \fB\-fdump\-rtl\-sched1\fR or
+\&\fB\-fdump\-rtl\-sched2\fR is specified, in which case it is output
+to the usual dump listing file, \fI.sched1\fR or \fI.sched2\fR
+respectively.  However for \fIn\fR greater than nine, the output is
+always printed to standard error.
+.Sp
+For \fIn\fR greater than zero, \fB\-fsched\-verbose\fR outputs the
+same information as \fB\-fdump\-rtl\-sched1\fR and \fB\-fdump\-rtl\-sched2\fR.
+For \fIn\fR greater than one, it also output basic block probabilities,
+detailed ready list information and unit/insn info.  For \fIn\fR greater
+than two, it includes \s-1RTL\s0 at abort point, control-flow and regions info.
+And for \fIn\fR over four, \fB\-fsched\-verbose\fR also includes
+dependence info.
+.IP "\fB\-save\-temps\fR" 4
+.IX Item "-save-temps"
+.PD 0
+.IP "\fB\-save\-temps=cwd\fR" 4
+.IX Item "-save-temps=cwd"
+.PD
+Store the usual \*(L"temporary\*(R" intermediate files permanently; place them
+in the current directory and name them based on the source file.  Thus,
+compiling \fIfoo.c\fR with \fB\-c \-save\-temps\fR produces files
+\&\fIfoo.i\fR and \fIfoo.s\fR, as well as \fIfoo.o\fR.  This creates a
+preprocessed \fIfoo.i\fR output file even though the compiler now
+normally uses an integrated preprocessor.
+.Sp
+When used in combination with the \fB\-x\fR command-line option,
+\&\fB\-save\-temps\fR is sensible enough to avoid over writing an
+input source file with the same extension as an intermediate file.
+The corresponding intermediate file may be obtained by renaming the
+source file before using \fB\-save\-temps\fR.
+.Sp
+If you invoke \s-1GCC\s0 in parallel, compiling several different source
+files that share a common base name in different subdirectories or the
+same source file compiled for multiple output destinations, it is
+likely that the different parallel compilers will interfere with each
+other, and overwrite the temporary files.  For instance:
+.Sp
+.Vb 2
+\&        gcc \-save\-temps \-o outdir1/foo.o indir1/foo.c&
+\&        gcc \-save\-temps \-o outdir2/foo.o indir2/foo.c&
+.Ve
+.Sp
+may result in \fIfoo.i\fR and \fIfoo.o\fR being written to
+simultaneously by both compilers.
+.IP "\fB\-save\-temps=obj\fR" 4
+.IX Item "-save-temps=obj"
+Store the usual \*(L"temporary\*(R" intermediate files permanently.  If the
+\&\fB\-o\fR option is used, the temporary files are based on the
+object file.  If the \fB\-o\fR option is not used, the
+\&\fB\-save\-temps=obj\fR switch behaves like \fB\-save\-temps\fR.
+.Sp
+For example:
+.Sp
+.Vb 3
+\&        gcc \-save\-temps=obj \-c foo.c
+\&        gcc \-save\-temps=obj \-c bar.c \-o dir/xbar.o
+\&        gcc \-save\-temps=obj foobar.c \-o dir2/yfoobar
+.Ve
+.Sp
+creates \fIfoo.i\fR, \fIfoo.s\fR, \fIdir/xbar.i\fR,
+\&\fIdir/xbar.s\fR, \fIdir2/yfoobar.i\fR, \fIdir2/yfoobar.s\fR, and
+\&\fIdir2/yfoobar.o\fR.
+.IP "\fB\-time\fR[\fB=\fR\fIfile\fR]" 4
+.IX Item "-time[=file]"
+Report the \s-1CPU\s0 time taken by each subprocess in the compilation
+sequence.  For C source files, this is the compiler proper and assembler
+(plus the linker if linking is done).
+.Sp
+Without the specification of an output file, the output looks like this:
+.Sp
+.Vb 2
+\&        # cc1 0.12 0.01
+\&        # as 0.00 0.01
+.Ve
+.Sp
+The first number on each line is the \*(L"user time\*(R", that is time spent
+executing the program itself.  The second number is \*(L"system time\*(R",
+time spent executing operating system routines on behalf of the program.
+Both numbers are in seconds.
+.Sp
+With the specification of an output file, the output is appended to the
+named file, and it looks like this:
+.Sp
+.Vb 2
+\&        0.12 0.01 cc1 <options>
+\&        0.00 0.01 as <options>
+.Ve
+.Sp
+The \*(L"user time\*(R" and the \*(L"system time\*(R" are moved before the program
+name, and the options passed to the program are displayed, so that one
+can later tell what file was being compiled, and with which options.
+.IP "\fB\-fvar\-tracking\fR" 4
+.IX Item "-fvar-tracking"
+Run variable tracking pass.  It computes where variables are stored at each
+position in code.  Better debugging information is then generated
+(if the debugging information format supports this information).
+.Sp
+It is enabled by default when compiling with optimization (\fB\-Os\fR,
+\&\fB\-O\fR, \fB\-O2\fR, ...), debugging information (\fB\-g\fR) and
+the debug info format supports it.
+.IP "\fB\-fvar\-tracking\-assignments\fR" 4
+.IX Item "-fvar-tracking-assignments"
+Annotate assignments to user variables early in the compilation and
+attempt to carry the annotations over throughout the compilation all the
+way to the end, in an attempt to improve debug information while
+optimizing.  Use of \fB\-gdwarf\-4\fR is recommended along with it.
+.Sp
+It can be enabled even if var-tracking is disabled, in which case
+annotations are created and maintained, but discarded at the end.
+.IP "\fB\-fvar\-tracking\-assignments\-toggle\fR" 4
+.IX Item "-fvar-tracking-assignments-toggle"
+Toggle \fB\-fvar\-tracking\-assignments\fR, in the same way that
+\&\fB\-gtoggle\fR toggles \fB\-g\fR.
+.IP "\fB\-print\-file\-name=\fR\fIlibrary\fR" 4
+.IX Item "-print-file-name=library"
+Print the full absolute name of the library file \fIlibrary\fR that
+would be used when linking\-\-\-and don't do anything else.  With this
+option, \s-1GCC\s0 does not compile or link anything; it just prints the
+file name.
+.IP "\fB\-print\-multi\-directory\fR" 4
+.IX Item "-print-multi-directory"
+Print the directory name corresponding to the multilib selected by any
+other switches present in the command line.  This directory is supposed
+to exist in \fB\s-1GCC_EXEC_PREFIX\s0\fR.
+.IP "\fB\-print\-multi\-lib\fR" 4
+.IX Item "-print-multi-lib"
+Print the mapping from multilib directory names to compiler switches
+that enable them.  The directory name is separated from the switches by
+\&\fB;\fR, and each switch starts with an \fB@\fR instead of the
+\&\fB\-\fR, without spaces between multiple switches.  This is supposed to
+ease shell processing.
+.IP "\fB\-print\-multi\-os\-directory\fR" 4
+.IX Item "-print-multi-os-directory"
+Print the path to \s-1OS\s0 libraries for the selected
+multilib, relative to some \fIlib\fR subdirectory.  If \s-1OS\s0 libraries are
+present in the \fIlib\fR subdirectory and no multilibs are used, this is
+usually just \fI.\fR, if \s-1OS\s0 libraries are present in \fIlib\fIsuffix\fI\fR
+sibling directories this prints e.g. \fI../lib64\fR, \fI../lib\fR or
+\&\fI../lib32\fR, or if \s-1OS\s0 libraries are present in \fIlib/\fIsubdir\fI\fR
+subdirectories it prints e.g. \fIamd64\fR, \fIsparcv9\fR or \fIev6\fR.
+.IP "\fB\-print\-multiarch\fR" 4
+.IX Item "-print-multiarch"
+Print the path to \s-1OS\s0 libraries for the selected multiarch,
+relative to some \fIlib\fR subdirectory.
+.IP "\fB\-print\-prog\-name=\fR\fIprogram\fR" 4
+.IX Item "-print-prog-name=program"
+Like \fB\-print\-file\-name\fR, but searches for a program such as \fBcpp\fR.
+.IP "\fB\-print\-libgcc\-file\-name\fR" 4
+.IX Item "-print-libgcc-file-name"
+Same as \fB\-print\-file\-name=libgcc.a\fR.
+.Sp
+This is useful when you use \fB\-nostdlib\fR or \fB\-nodefaultlibs\fR
+but you do want to link with \fIlibgcc.a\fR.  You can do:
+.Sp
+.Vb 1
+\&        gcc \-nostdlib <files>... \`gcc \-print\-libgcc\-file\-name\`
+.Ve
+.IP "\fB\-print\-search\-dirs\fR" 4
+.IX Item "-print-search-dirs"
+Print the name of the configured installation directory and a list of
+program and library directories \fBgcc\fR searches\-\-\-and don't do anything else.
+.Sp
+This is useful when \fBgcc\fR prints the error message
+\&\fBinstallation problem, cannot exec cpp0: No such file or directory\fR.
+To resolve this you either need to put \fIcpp0\fR and the other compiler
+components where \fBgcc\fR expects to find them, or you can set the environment
+variable \fB\s-1GCC_EXEC_PREFIX\s0\fR to the directory where you installed them.
+Don't forget the trailing \fB/\fR.
+.IP "\fB\-print\-sysroot\fR" 4
+.IX Item "-print-sysroot"
+Print the target sysroot directory that is used during
+compilation.  This is the target sysroot specified either at configure
+time or using the \fB\-\-sysroot\fR option, possibly with an extra
+suffix that depends on compilation options.  If no target sysroot is
+specified, the option prints nothing.
+.IP "\fB\-print\-sysroot\-headers\-suffix\fR" 4
+.IX Item "-print-sysroot-headers-suffix"
+Print the suffix added to the target sysroot when searching for
+headers, or give an error if the compiler is not configured with such
+a suffix\-\-\-and don't do anything else.
+.IP "\fB\-dumpmachine\fR" 4
+.IX Item "-dumpmachine"
+Print the compiler's target machine (for example,
+\&\fBi686\-pc\-linux\-gnu\fR)\-\-\-and don't do anything else.
+.IP "\fB\-dumpversion\fR" 4
+.IX Item "-dumpversion"
+Print the compiler version (for example, \fB3.0\fR)\-\-\-and don't do
+anything else.
+.IP "\fB\-dumpspecs\fR" 4
+.IX Item "-dumpspecs"
+Print the compiler's built-in specs\-\-\-and don't do anything else.  (This
+is used when \s-1GCC\s0 itself is being built.)
+.IP "\fB\-fno\-eliminate\-unused\-debug\-types\fR" 4
+.IX Item "-fno-eliminate-unused-debug-types"
+Normally, when producing \s-1DWARF 2\s0 output, \s-1GCC\s0 avoids producing debug symbol 
+output for types that are nowhere used in the source file being compiled.
+Sometimes it is useful to have \s-1GCC\s0 emit debugging
+information for all types declared in a compilation
+unit, regardless of whether or not they are actually used
+in that compilation unit, for example 
+if, in the debugger, you want to cast a value to a type that is
+not actually used in your program (but is declared).  More often,
+however, this results in a significant amount of wasted space.
+.SS "Options That Control Optimization"
+.IX Subsection "Options That Control Optimization"
+These options control various sorts of optimizations.
+.PP
+Without any optimization option, the compiler's goal is to reduce the
+cost of compilation and to make debugging produce the expected
+results.  Statements are independent: if you stop the program with a
+breakpoint between statements, you can then assign a new value to any
+variable or change the program counter to any other statement in the
+function and get exactly the results you expect from the source
+code.
+.PP
+Turning on optimization flags makes the compiler attempt to improve
+the performance and/or code size at the expense of compilation time
+and possibly the ability to debug the program.
+.PP
+The compiler performs optimization based on the knowledge it has of the
+program.  Compiling multiple files at once to a single output file mode allows
+the compiler to use information gained from all of the files when compiling
+each of them.
+.PP
+Not all optimizations are controlled directly by a flag.  Only
+optimizations that have a flag are listed in this section.
+.PP
+Most optimizations are only enabled if an \fB\-O\fR level is set on
+the command line.  Otherwise they are disabled, even if individual
+optimization flags are specified.
+.PP
+Depending on the target and how \s-1GCC\s0 was configured, a slightly different
+set of optimizations may be enabled at each \fB\-O\fR level than
+those listed here.  You can invoke \s-1GCC\s0 with \fB\-Q \-\-help=optimizers\fR
+to find out the exact set of optimizations that are enabled at each level.
+.IP "\fB\-O\fR" 4
+.IX Item "-O"
+.PD 0
+.IP "\fB\-O1\fR" 4
+.IX Item "-O1"
+.PD
+Optimize.  Optimizing compilation takes somewhat more time, and a lot
+more memory for a large function.
+.Sp
+With \fB\-O\fR, the compiler tries to reduce code size and execution
+time, without performing any optimizations that take a great deal of
+compilation time.
+.Sp
+\&\fB\-O\fR turns on the following optimization flags:
+.Sp
+\&\fB\-fauto\-inc\-dec 
+\&\-fcompare\-elim 
+\&\-fcprop\-registers 
+\&\-fdce 
+\&\-fdefer\-pop 
+\&\-fdelayed\-branch 
+\&\-fdse 
+\&\-fguess\-branch\-probability 
+\&\-fif\-conversion2 
+\&\-fif\-conversion 
+\&\-fipa\-pure\-const 
+\&\-fipa\-profile 
+\&\-fipa\-reference 
+\&\-fmerge\-constants
+\&\-fsplit\-wide\-types 
+\&\-ftree\-bit\-ccp 
+\&\-ftree\-builtin\-call\-dce 
+\&\-ftree\-ccp 
+\&\-ftree\-ch 
+\&\-ftree\-copyrename 
+\&\-ftree\-dce 
+\&\-ftree\-dominator\-opts 
+\&\-ftree\-dse 
+\&\-ftree\-forwprop 
+\&\-ftree\-fre 
+\&\-ftree\-phiprop 
+\&\-ftree\-slsr 
+\&\-ftree\-sra 
+\&\-ftree\-pta 
+\&\-ftree\-ter 
+\&\-funit\-at\-a\-time\fR
+.Sp
+\&\fB\-O\fR also turns on \fB\-fomit\-frame\-pointer\fR on machines
+where doing so does not interfere with debugging.
+.IP "\fB\-O2\fR" 4
+.IX Item "-O2"
+Optimize even more.  \s-1GCC\s0 performs nearly all supported optimizations
+that do not involve a space-speed tradeoff.
+As compared to \fB\-O\fR, this option increases both compilation time
+and the performance of the generated code.
+.Sp
+\&\fB\-O2\fR turns on all optimization flags specified by \fB\-O\fR.  It
+also turns on the following optimization flags:
+\&\fB\-fthread\-jumps 
+\&\-falign\-functions  \-falign\-jumps 
+\&\-falign\-loops  \-falign\-labels 
+\&\-fcaller\-saves 
+\&\-fcrossjumping 
+\&\-fcse\-follow\-jumps  \-fcse\-skip\-blocks 
+\&\-fdelete\-null\-pointer\-checks 
+\&\-fdevirtualize \-fdevirtualize\-speculatively 
+\&\-fexpensive\-optimizations 
+\&\-fgcse  \-fgcse\-lm  
+\&\-fhoist\-adjacent\-loads 
+\&\-finline\-small\-functions 
+\&\-findirect\-inlining 
+\&\-fipa\-sra 
+\&\-fisolate\-erroneous\-paths\-dereference 
+\&\-foptimize\-sibling\-calls 
+\&\-fpartial\-inlining 
+\&\-fpeephole2 
+\&\-freorder\-blocks  \-freorder\-functions 
+\&\-frerun\-cse\-after\-loop  
+\&\-fsched\-interblock  \-fsched\-spec 
+\&\-fschedule\-insns  \-fschedule\-insns2 
+\&\-fstrict\-aliasing \-fstrict\-overflow 
+\&\-ftree\-switch\-conversion \-ftree\-tail\-merge 
+\&\-ftree\-pre 
+\&\-ftree\-vrp\fR
+.Sp
+Please note the warning under \fB\-fgcse\fR about
+invoking \fB\-O2\fR on programs that use computed gotos.
+.IP "\fB\-O3\fR" 4
+.IX Item "-O3"
+Optimize yet more.  \fB\-O3\fR turns on all optimizations specified
+by \fB\-O2\fR and also turns on the \fB\-finline\-functions\fR,
+\&\fB\-funswitch\-loops\fR, \fB\-fpredictive\-commoning\fR,
+\&\fB\-fgcse\-after\-reload\fR, \fB\-ftree\-loop\-vectorize\fR,
+\&\fB\-ftree\-slp\-vectorize\fR, \fB\-fvect\-cost\-model\fR,
+\&\fB\-ftree\-partial\-pre\fR and \fB\-fipa\-cp\-clone\fR options.
+.IP "\fB\-O0\fR" 4
+.IX Item "-O0"
+Reduce compilation time and make debugging produce the expected
+results.  This is the default.
+.IP "\fB\-Os\fR" 4
+.IX Item "-Os"
+Optimize for size.  \fB\-Os\fR enables all \fB\-O2\fR optimizations that
+do not typically increase code size.  It also performs further
+optimizations designed to reduce code size.
+.Sp
+\&\fB\-Os\fR disables the following optimization flags:
+\&\fB\-falign\-functions  \-falign\-jumps  \-falign\-loops 
+\&\-falign\-labels  \-freorder\-blocks  \-freorder\-blocks\-and\-partition 
+\&\-fprefetch\-loop\-arrays\fR
+.IP "\fB\-Ofast\fR" 4
+.IX Item "-Ofast"
+Disregard strict standards compliance.  \fB\-Ofast\fR enables all
+\&\fB\-O3\fR optimizations.  It also enables optimizations that are not
+valid for all standard-compliant programs.
+It turns on \fB\-ffast\-math\fR and the Fortran-specific
+\&\fB\-fno\-protect\-parens\fR and \fB\-fstack\-arrays\fR.
+.IP "\fB\-Og\fR" 4
+.IX Item "-Og"
+Optimize debugging experience.  \fB\-Og\fR enables optimizations
+that do not interfere with debugging. It should be the optimization
+level of choice for the standard edit-compile-debug cycle, offering
+a reasonable level of optimization while maintaining fast compilation
+and a good debugging experience.
+.Sp
+If you use multiple \fB\-O\fR options, with or without level numbers,
+the last such option is the one that is effective.
+.PP
+Options of the form \fB\-f\fR\fIflag\fR specify machine-independent
+flags.  Most flags have both positive and negative forms; the negative
+form of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In the table
+below, only one of the forms is listed\-\-\-the one you typically 
+use.  You can figure out the other form by either removing \fBno\-\fR
+or adding it.
+.PP
+The following options control specific optimizations.  They are either
+activated by \fB\-O\fR options or are related to ones that are.  You
+can use the following flags in the rare cases when \*(L"fine-tuning\*(R" of
+optimizations to be performed is desired.
+.IP "\fB\-fno\-defer\-pop\fR" 4
+.IX Item "-fno-defer-pop"
+Always pop the arguments to each function call as soon as that function
+returns.  For machines that must pop arguments after a function call,
+the compiler normally lets arguments accumulate on the stack for several
+function calls and pops them all at once.
+.Sp
+Disabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fforward\-propagate\fR" 4
+.IX Item "-fforward-propagate"
+Perform a forward propagation pass on \s-1RTL. \s0 The pass tries to combine two
+instructions and checks if the result can be simplified.  If loop unrolling
+is active, two passes are performed and the second is scheduled after
+loop unrolling.
+.Sp
+This option is enabled by default at optimization levels \fB\-O\fR,
+\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-ffp\-contract=\fR\fIstyle\fR" 4
+.IX Item "-ffp-contract=style"
+\&\fB\-ffp\-contract=off\fR disables floating-point expression contraction.
+\&\fB\-ffp\-contract=fast\fR enables floating-point expression contraction
+such as forming of fused multiply-add operations if the target has
+native support for them.
+\&\fB\-ffp\-contract=on\fR enables floating-point expression contraction
+if allowed by the language standard.  This is currently not implemented
+and treated equal to \fB\-ffp\-contract=off\fR.
+.Sp
+The default is \fB\-ffp\-contract=fast\fR.
+.IP "\fB\-fomit\-frame\-pointer\fR" 4
+.IX Item "-fomit-frame-pointer"
+Don't keep the frame pointer in a register for functions that
+don't need one.  This avoids the instructions to save, set up and
+restore frame pointers; it also makes an extra register available
+in many functions.  \fBIt also makes debugging impossible on
+some machines.\fR
+.Sp
+On some machines, such as the \s-1VAX,\s0 this flag has no effect, because
+the standard calling sequence automatically handles the frame pointer
+and nothing is saved by pretending it doesn't exist.  The
+machine-description macro \f(CW\*(C`FRAME_POINTER_REQUIRED\*(C'\fR controls
+whether a target machine supports this flag.
+.Sp
+Starting with \s-1GCC\s0 version 4.6, the default setting (when not optimizing for
+size) for 32\-bit GNU/Linux x86 and 32\-bit Darwin x86 targets has been changed to
+\&\fB\-fomit\-frame\-pointer\fR.  The default can be reverted to
+\&\fB\-fno\-omit\-frame\-pointer\fR by configuring \s-1GCC\s0 with the
+\&\fB\-\-enable\-frame\-pointer\fR configure option.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-foptimize\-sibling\-calls\fR" 4
+.IX Item "-foptimize-sibling-calls"
+Optimize sibling and tail recursive calls.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fno\-inline\fR" 4
+.IX Item "-fno-inline"
+Do not expand any functions inline apart from those marked with
+the \f(CW\*(C`always_inline\*(C'\fR attribute.  This is the default when not
+optimizing.
+.Sp
+Single functions can be exempted from inlining by marking them
+with the \f(CW\*(C`noinline\*(C'\fR attribute.
+.IP "\fB\-finline\-small\-functions\fR" 4
+.IX Item "-finline-small-functions"
+Integrate functions into their callers when their body is smaller than expected
+function call code (so overall size of program gets smaller).  The compiler
+heuristically decides which functions are simple enough to be worth integrating
+in this way.  This inlining applies to all functions, even those not declared
+inline.
+.Sp
+Enabled at level \fB\-O2\fR.
+.IP "\fB\-findirect\-inlining\fR" 4
+.IX Item "-findirect-inlining"
+Inline also indirect calls that are discovered to be known at compile
+time thanks to previous inlining.  This option has any effect only
+when inlining itself is turned on by the \fB\-finline\-functions\fR
+or \fB\-finline\-small\-functions\fR options.
+.Sp
+Enabled at level \fB\-O2\fR.
+.IP "\fB\-finline\-functions\fR" 4
+.IX Item "-finline-functions"
+Consider all functions for inlining, even if they are not declared inline.
+The compiler heuristically decides which functions are worth integrating
+in this way.
+.Sp
+If all calls to a given function are integrated, and the function is
+declared \f(CW\*(C`static\*(C'\fR, then the function is normally not output as
+assembler code in its own right.
+.Sp
+Enabled at level \fB\-O3\fR.
+.IP "\fB\-finline\-functions\-called\-once\fR" 4
+.IX Item "-finline-functions-called-once"
+Consider all \f(CW\*(C`static\*(C'\fR functions called once for inlining into their
+caller even if they are not marked \f(CW\*(C`inline\*(C'\fR.  If a call to a given
+function is integrated, then the function is not output as assembler code
+in its own right.
+.Sp
+Enabled at levels \fB\-O1\fR, \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
+.IP "\fB\-fearly\-inlining\fR" 4
+.IX Item "-fearly-inlining"
+Inline functions marked by \f(CW\*(C`always_inline\*(C'\fR and functions whose body seems
+smaller than the function call overhead early before doing
+\&\fB\-fprofile\-generate\fR instrumentation and real inlining pass.  Doing so
+makes profiling significantly cheaper and usually inlining faster on programs
+having large chains of nested wrapper functions.
+.Sp
+Enabled by default.
+.IP "\fB\-fipa\-sra\fR" 4
+.IX Item "-fipa-sra"
+Perform interprocedural scalar replacement of aggregates, removal of
+unused parameters and replacement of parameters passed by reference
+by parameters passed by value.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR and \fB\-Os\fR.
+.IP "\fB\-finline\-limit=\fR\fIn\fR" 4
+.IX Item "-finline-limit=n"
+By default, \s-1GCC\s0 limits the size of functions that can be inlined.  This flag
+allows coarse control of this limit.  \fIn\fR is the size of functions that
+can be inlined in number of pseudo instructions.
+.Sp
+Inlining is actually controlled by a number of parameters, which may be
+specified individually by using \fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR.
+The \fB\-finline\-limit=\fR\fIn\fR option sets some of these parameters
+as follows:
+.RS 4
+.IP "\fBmax-inline-insns-single\fR" 4
+.IX Item "max-inline-insns-single"
+is set to \fIn\fR/2.
+.IP "\fBmax-inline-insns-auto\fR" 4
+.IX Item "max-inline-insns-auto"
+is set to \fIn\fR/2.
+.RE
+.RS 4
+.Sp
+See below for a documentation of the individual
+parameters controlling inlining and for the defaults of these parameters.
+.Sp
+\&\fINote:\fR there may be no value to \fB\-finline\-limit\fR that results
+in default behavior.
+.Sp
+\&\fINote:\fR pseudo instruction represents, in this particular context, an
+abstract measurement of function's size.  In no way does it represent a count
+of assembly instructions and as such its exact meaning might change from one
+release to an another.
+.RE
+.IP "\fB\-fno\-keep\-inline\-dllexport\fR" 4
+.IX Item "-fno-keep-inline-dllexport"
+This is a more fine-grained version of \fB\-fkeep\-inline\-functions\fR,
+which applies only to functions that are declared using the \f(CW\*(C`dllexport\*(C'\fR
+attribute or declspec
+.IP "\fB\-fkeep\-inline\-functions\fR" 4
+.IX Item "-fkeep-inline-functions"
+In C, emit \f(CW\*(C`static\*(C'\fR functions that are declared \f(CW\*(C`inline\*(C'\fR
+into the object file, even if the function has been inlined into all
+of its callers.  This switch does not affect functions using the
+\&\f(CW\*(C`extern inline\*(C'\fR extension in \s-1GNU C90. \s0 In \*(C+, emit any and all
+inline functions into the object file.
+.IP "\fB\-fkeep\-static\-consts\fR" 4
+.IX Item "-fkeep-static-consts"
+Emit variables declared \f(CW\*(C`static const\*(C'\fR when optimization isn't turned
+on, even if the variables aren't referenced.
+.Sp
+\&\s-1GCC\s0 enables this option by default.  If you want to force the compiler to
+check if a variable is referenced, regardless of whether or not
+optimization is turned on, use the \fB\-fno\-keep\-static\-consts\fR option.
+.IP "\fB\-fmerge\-constants\fR" 4
+.IX Item "-fmerge-constants"
+Attempt to merge identical constants (string constants and floating-point
+constants) across compilation units.
+.Sp
+This option is the default for optimized compilation if the assembler and
+linker support it.  Use \fB\-fno\-merge\-constants\fR to inhibit this
+behavior.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fmerge\-all\-constants\fR" 4
+.IX Item "-fmerge-all-constants"
+Attempt to merge identical constants and identical variables.
+.Sp
+This option implies \fB\-fmerge\-constants\fR.  In addition to
+\&\fB\-fmerge\-constants\fR this considers e.g. even constant initialized
+arrays or initialized constant variables with integral or floating-point
+types.  Languages like C or \*(C+ require each variable, including multiple
+instances of the same variable in recursive calls, to have distinct locations,
+so using this option results in non-conforming
+behavior.
+.IP "\fB\-fmodulo\-sched\fR" 4
+.IX Item "-fmodulo-sched"
+Perform swing modulo scheduling immediately before the first scheduling
+pass.  This pass looks at innermost loops and reorders their
+instructions by overlapping different iterations.
+.IP "\fB\-fmodulo\-sched\-allow\-regmoves\fR" 4
+.IX Item "-fmodulo-sched-allow-regmoves"
+Perform more aggressive SMS-based modulo scheduling with register moves
+allowed.  By setting this flag certain anti-dependences edges are
+deleted, which triggers the generation of reg-moves based on the
+life-range analysis.  This option is effective only with
+\&\fB\-fmodulo\-sched\fR enabled.
+.IP "\fB\-fno\-branch\-count\-reg\fR" 4
+.IX Item "-fno-branch-count-reg"
+Do not use \*(L"decrement and branch\*(R" instructions on a count register,
+but instead generate a sequence of instructions that decrement a
+register, compare it against zero, then branch based upon the result.
+This option is only meaningful on architectures that support such
+instructions, which include x86, PowerPC, \s-1IA\-64\s0 and S/390.
+.Sp
+The default is \fB\-fbranch\-count\-reg\fR.
+.IP "\fB\-fno\-function\-cse\fR" 4
+.IX Item "-fno-function-cse"
+Do not put function addresses in registers; make each instruction that
+calls a constant function contain the function's address explicitly.
+.Sp
+This option results in less efficient code, but some strange hacks
+that alter the assembler output may be confused by the optimizations
+performed when this option is not used.
+.Sp
+The default is \fB\-ffunction\-cse\fR
+.IP "\fB\-fno\-zero\-initialized\-in\-bss\fR" 4
+.IX Item "-fno-zero-initialized-in-bss"
+If the target supports a \s-1BSS\s0 section, \s-1GCC\s0 by default puts variables that
+are initialized to zero into \s-1BSS. \s0 This can save space in the resulting
+code.
+.Sp
+This option turns off this behavior because some programs explicitly
+rely on variables going to the data section\-\-\-e.g., so that the
+resulting executable can find the beginning of that section and/or make
+assumptions based on that.
+.Sp
+The default is \fB\-fzero\-initialized\-in\-bss\fR.
+.IP "\fB\-fthread\-jumps\fR" 4
+.IX Item "-fthread-jumps"
+Perform optimizations that check to see if a jump branches to a
+location where another comparison subsumed by the first is found.  If
+so, the first branch is redirected to either the destination of the
+second branch or a point immediately following it, depending on whether
+the condition is known to be true or false.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fsplit\-wide\-types\fR" 4
+.IX Item "-fsplit-wide-types"
+When using a type that occupies multiple registers, such as \f(CW\*(C`long
+long\*(C'\fR on a 32\-bit system, split the registers apart and allocate them
+independently.  This normally generates better code for those types,
+but may make debugging more difficult.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR,
+\&\fB\-Os\fR.
+.IP "\fB\-fcse\-follow\-jumps\fR" 4
+.IX Item "-fcse-follow-jumps"
+In common subexpression elimination (\s-1CSE\s0), scan through jump instructions
+when the target of the jump is not reached by any other path.  For
+example, when \s-1CSE\s0 encounters an \f(CW\*(C`if\*(C'\fR statement with an
+\&\f(CW\*(C`else\*(C'\fR clause, \s-1CSE\s0 follows the jump when the condition
+tested is false.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fcse\-skip\-blocks\fR" 4
+.IX Item "-fcse-skip-blocks"
+This is similar to \fB\-fcse\-follow\-jumps\fR, but causes \s-1CSE\s0 to
+follow jumps that conditionally skip over blocks.  When \s-1CSE\s0
+encounters a simple \f(CW\*(C`if\*(C'\fR statement with no else clause,
+\&\fB\-fcse\-skip\-blocks\fR causes \s-1CSE\s0 to follow the jump around the
+body of the \f(CW\*(C`if\*(C'\fR.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-frerun\-cse\-after\-loop\fR" 4
+.IX Item "-frerun-cse-after-loop"
+Re-run common subexpression elimination after loop optimizations are
+performed.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fgcse\fR" 4
+.IX Item "-fgcse"
+Perform a global common subexpression elimination pass.
+This pass also performs global constant and copy propagation.
+.Sp
+\&\fINote:\fR When compiling a program using computed gotos, a \s-1GCC\s0
+extension, you may get better run-time performance if you disable
+the global common subexpression elimination pass by adding
+\&\fB\-fno\-gcse\fR to the command line.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fgcse\-lm\fR" 4
+.IX Item "-fgcse-lm"
+When \fB\-fgcse\-lm\fR is enabled, global common subexpression elimination
+attempts to move loads that are only killed by stores into themselves.  This
+allows a loop containing a load/store sequence to be changed to a load outside
+the loop, and a copy/store within the loop.
+.Sp
+Enabled by default when \fB\-fgcse\fR is enabled.
+.IP "\fB\-fgcse\-sm\fR" 4
+.IX Item "-fgcse-sm"
+When \fB\-fgcse\-sm\fR is enabled, a store motion pass is run after
+global common subexpression elimination.  This pass attempts to move
+stores out of loops.  When used in conjunction with \fB\-fgcse\-lm\fR,
+loops containing a load/store sequence can be changed to a load before
+the loop and a store after the loop.
+.Sp
+Not enabled at any optimization level.
+.IP "\fB\-fgcse\-las\fR" 4
+.IX Item "-fgcse-las"
+When \fB\-fgcse\-las\fR is enabled, the global common subexpression
+elimination pass eliminates redundant loads that come after stores to the
+same memory location (both partial and full redundancies).
+.Sp
+Not enabled at any optimization level.
+.IP "\fB\-fgcse\-after\-reload\fR" 4
+.IX Item "-fgcse-after-reload"
+When \fB\-fgcse\-after\-reload\fR is enabled, a redundant load elimination
+pass is performed after reload.  The purpose of this pass is to clean up
+redundant spilling.
+.IP "\fB\-faggressive\-loop\-optimizations\fR" 4
+.IX Item "-faggressive-loop-optimizations"
+This option tells the loop optimizer to use language constraints to
+derive bounds for the number of iterations of a loop.  This assumes that
+loop code does not invoke undefined behavior by for example causing signed
+integer overflows or out-of-bound array accesses.  The bounds for the
+number of iterations of a loop are used to guide loop unrolling and peeling
+and loop exit test optimizations.
+This option is enabled by default.
+.IP "\fB\-funsafe\-loop\-optimizations\fR" 4
+.IX Item "-funsafe-loop-optimizations"
+This option tells the loop optimizer to assume that loop indices do not
+overflow, and that loops with nontrivial exit condition are not
+infinite.  This enables a wider range of loop optimizations even if
+the loop optimizer itself cannot prove that these assumptions are valid.
+If you use \fB\-Wunsafe\-loop\-optimizations\fR, the compiler warns you
+if it finds this kind of loop.
+.IP "\fB\-fcrossjumping\fR" 4
+.IX Item "-fcrossjumping"
+Perform cross-jumping transformation.
+This transformation unifies equivalent code and saves code size.  The
+resulting code may or may not perform better than without cross-jumping.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fauto\-inc\-dec\fR" 4
+.IX Item "-fauto-inc-dec"
+Combine increments or decrements of addresses with memory accesses.
+This pass is always skipped on architectures that do not have
+instructions to support this.  Enabled by default at \fB\-O\fR and
+higher on architectures that support this.
+.IP "\fB\-fdce\fR" 4
+.IX Item "-fdce"
+Perform dead code elimination (\s-1DCE\s0) on \s-1RTL.\s0
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fdse\fR" 4
+.IX Item "-fdse"
+Perform dead store elimination (\s-1DSE\s0) on \s-1RTL.\s0
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fif\-conversion\fR" 4
+.IX Item "-fif-conversion"
+Attempt to transform conditional jumps into branch-less equivalents.  This
+includes use of conditional moves, min, max, set flags and abs instructions, and
+some tricks doable by standard arithmetics.  The use of conditional execution
+on chips where it is available is controlled by \f(CW\*(C`if\-conversion2\*(C'\fR.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fif\-conversion2\fR" 4
+.IX Item "-fif-conversion2"
+Use conditional execution (where available) to transform conditional jumps into
+branch-less equivalents.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fdeclone\-ctor\-dtor\fR" 4
+.IX Item "-fdeclone-ctor-dtor"
+The \*(C+ \s-1ABI\s0 requires multiple entry points for constructors and
+destructors: one for a base subobject, one for a complete object, and
+one for a virtual destructor that calls operator delete afterwards.
+For a hierarchy with virtual bases, the base and complete variants are
+clones, which means two copies of the function.  With this option, the
+base and complete variants are changed to be thunks that call a common
+implementation.
+.Sp
+Enabled by \fB\-Os\fR.
+.IP "\fB\-fdelete\-null\-pointer\-checks\fR" 4
+.IX Item "-fdelete-null-pointer-checks"
+Assume that programs cannot safely dereference null pointers, and that
+no code or data element resides there.  This enables simple constant
+folding optimizations at all optimization levels.  In addition, other
+optimization passes in \s-1GCC\s0 use this flag to control global dataflow
+analyses that eliminate useless checks for null pointers; these assume
+that if a pointer is checked after it has already been dereferenced,
+it cannot be null.
+.Sp
+Note however that in some environments this assumption is not true.
+Use \fB\-fno\-delete\-null\-pointer\-checks\fR to disable this optimization
+for programs that depend on that behavior.
+.Sp
+Some targets, especially embedded ones, disable this option at all levels.
+Otherwise it is enabled at all levels: \fB\-O0\fR, \fB\-O1\fR,
+\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.  Passes that use the information
+are enabled independently at different optimization levels.
+.IP "\fB\-fdevirtualize\fR" 4
+.IX Item "-fdevirtualize"
+Attempt to convert calls to virtual functions to direct calls.  This
+is done both within a procedure and interprocedurally as part of
+indirect inlining (\f(CW\*(C`\-findirect\-inlining\*(C'\fR) and interprocedural constant
+propagation (\fB\-fipa\-cp\fR).
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fdevirtualize\-speculatively\fR" 4
+.IX Item "-fdevirtualize-speculatively"
+Attempt to convert calls to virtual functions to speculative direct calls.
+Based on the analysis of the type inheritance graph, determine for a given call
+the set of likely targets. If the set is small, preferably of size 1, change
+the call into an conditional deciding on direct and indirect call.  The
+speculative calls enable more optimizations, such as inlining.  When they seem
+useless after further optimization, they are converted back into original form.
+.IP "\fB\-fexpensive\-optimizations\fR" 4
+.IX Item "-fexpensive-optimizations"
+Perform a number of minor optimizations that are relatively expensive.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-free\fR" 4
+.IX Item "-free"
+Attempt to remove redundant extension instructions.  This is especially
+helpful for the x86\-64 architecture, which implicitly zero-extends in 64\-bit
+registers after writing to their lower 32\-bit half.
+.Sp
+Enabled for AArch64 and x86 at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-flive\-range\-shrinkage\fR" 4
+.IX Item "-flive-range-shrinkage"
+Attempt to decrease register pressure through register live range
+shrinkage.  This is helpful for fast processors with small or moderate
+size register sets.
+.IP "\fB\-fira\-algorithm=\fR\fIalgorithm\fR" 4
+.IX Item "-fira-algorithm=algorithm"
+Use the specified coloring algorithm for the integrated register
+allocator.  The \fIalgorithm\fR argument can be \fBpriority\fR, which
+specifies Chow's priority coloring, or \fB\s-1CB\s0\fR, which specifies
+Chaitin-Briggs coloring.  Chaitin-Briggs coloring is not implemented
+for all architectures, but for those targets that do support it, it is
+the default because it generates better code.
+.IP "\fB\-fira\-region=\fR\fIregion\fR" 4
+.IX Item "-fira-region=region"
+Use specified regions for the integrated register allocator.  The
+\&\fIregion\fR argument should be one of the following:
+.RS 4
+.IP "\fBall\fR" 4
+.IX Item "all"
+Use all loops as register allocation regions.
+This can give the best results for machines with a small and/or
+irregular register set.
+.IP "\fBmixed\fR" 4
+.IX Item "mixed"
+Use all loops except for loops with small register pressure 
+as the regions.  This value usually gives
+the best results in most cases and for most architectures,
+and is enabled by default when compiling with optimization for speed
+(\fB\-O\fR, \fB\-O2\fR, ...).
+.IP "\fBone\fR" 4
+.IX Item "one"
+Use all functions as a single region.  
+This typically results in the smallest code size, and is enabled by default for
+\&\fB\-Os\fR or \fB\-O0\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fira\-hoist\-pressure\fR" 4
+.IX Item "-fira-hoist-pressure"
+Use \s-1IRA\s0 to evaluate register pressure in the code hoisting pass for
+decisions to hoist expressions.  This option usually results in smaller
+code, but it can slow the compiler down.
+.Sp
+This option is enabled at level \fB\-Os\fR for all targets.
+.IP "\fB\-fira\-loop\-pressure\fR" 4
+.IX Item "-fira-loop-pressure"
+Use \s-1IRA\s0 to evaluate register pressure in loops for decisions to move
+loop invariants.  This option usually results in generation
+of faster and smaller code on machines with large register files (>= 32
+registers), but it can slow the compiler down.
+.Sp
+This option is enabled at level \fB\-O3\fR for some targets.
+.IP "\fB\-fno\-ira\-share\-save\-slots\fR" 4
+.IX Item "-fno-ira-share-save-slots"
+Disable sharing of stack slots used for saving call-used hard
+registers living through a call.  Each hard register gets a
+separate stack slot, and as a result function stack frames are
+larger.
+.IP "\fB\-fno\-ira\-share\-spill\-slots\fR" 4
+.IX Item "-fno-ira-share-spill-slots"
+Disable sharing of stack slots allocated for pseudo-registers.  Each
+pseudo-register that does not get a hard register gets a separate
+stack slot, and as a result function stack frames are larger.
+.IP "\fB\-fira\-verbose=\fR\fIn\fR" 4
+.IX Item "-fira-verbose=n"
+Control the verbosity of the dump file for the integrated register allocator.
+The default value is 5.  If the value \fIn\fR is greater or equal to 10,
+the dump output is sent to stderr using the same format as \fIn\fR minus 10.
+.IP "\fB\-fdelayed\-branch\fR" 4
+.IX Item "-fdelayed-branch"
+If supported for the target machine, attempt to reorder instructions
+to exploit instruction slots available after delayed branch
+instructions.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fschedule\-insns\fR" 4
+.IX Item "-fschedule-insns"
+If supported for the target machine, attempt to reorder instructions to
+eliminate execution stalls due to required data being unavailable.  This
+helps machines that have slow floating point or memory load instructions
+by allowing other instructions to be issued until the result of the load
+or floating-point instruction is required.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-fschedule\-insns2\fR" 4
+.IX Item "-fschedule-insns2"
+Similar to \fB\-fschedule\-insns\fR, but requests an additional pass of
+instruction scheduling after register allocation has been done.  This is
+especially useful on machines with a relatively small number of
+registers and where memory load instructions take more than one cycle.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fno\-sched\-interblock\fR" 4
+.IX Item "-fno-sched-interblock"
+Don't schedule instructions across basic blocks.  This is normally
+enabled by default when scheduling before register allocation, i.e.
+with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fno\-sched\-spec\fR" 4
+.IX Item "-fno-sched-spec"
+Don't allow speculative motion of non-load instructions.  This is normally
+enabled by default when scheduling before register allocation, i.e.
+with \fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-pressure\fR" 4
+.IX Item "-fsched-pressure"
+Enable register pressure sensitive insn scheduling before register
+allocation.  This only makes sense when scheduling before register
+allocation is enabled, i.e. with \fB\-fschedule\-insns\fR or at
+\&\fB\-O2\fR or higher.  Usage of this option can improve the
+generated code and decrease its size by preventing register pressure
+increase above the number of available hard registers and subsequent
+spills in register allocation.
+.IP "\fB\-fsched\-spec\-load\fR" 4
+.IX Item "-fsched-spec-load"
+Allow speculative motion of some load instructions.  This only makes
+sense when scheduling before register allocation, i.e. with
+\&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-spec\-load\-dangerous\fR" 4
+.IX Item "-fsched-spec-load-dangerous"
+Allow speculative motion of more load instructions.  This only makes
+sense when scheduling before register allocation, i.e. with
+\&\fB\-fschedule\-insns\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-stalled\-insns\fR" 4
+.IX Item "-fsched-stalled-insns"
+.PD 0
+.IP "\fB\-fsched\-stalled\-insns=\fR\fIn\fR" 4
+.IX Item "-fsched-stalled-insns=n"
+.PD
+Define how many insns (if any) can be moved prematurely from the queue
+of stalled insns into the ready list during the second scheduling pass.
+\&\fB\-fno\-sched\-stalled\-insns\fR means that no insns are moved
+prematurely, \fB\-fsched\-stalled\-insns=0\fR means there is no limit
+on how many queued insns can be moved prematurely.
+\&\fB\-fsched\-stalled\-insns\fR without a value is equivalent to
+\&\fB\-fsched\-stalled\-insns=1\fR.
+.IP "\fB\-fsched\-stalled\-insns\-dep\fR" 4
+.IX Item "-fsched-stalled-insns-dep"
+.PD 0
+.IP "\fB\-fsched\-stalled\-insns\-dep=\fR\fIn\fR" 4
+.IX Item "-fsched-stalled-insns-dep=n"
+.PD
+Define how many insn groups (cycles) are examined for a dependency
+on a stalled insn that is a candidate for premature removal from the queue
+of stalled insns.  This has an effect only during the second scheduling pass,
+and only if \fB\-fsched\-stalled\-insns\fR is used.
+\&\fB\-fno\-sched\-stalled\-insns\-dep\fR is equivalent to
+\&\fB\-fsched\-stalled\-insns\-dep=0\fR.
+\&\fB\-fsched\-stalled\-insns\-dep\fR without a value is equivalent to
+\&\fB\-fsched\-stalled\-insns\-dep=1\fR.
+.IP "\fB\-fsched2\-use\-superblocks\fR" 4
+.IX Item "-fsched2-use-superblocks"
+When scheduling after register allocation, use superblock scheduling.
+This allows motion across basic block boundaries,
+resulting in faster schedules.  This option is experimental, as not all machine
+descriptions used by \s-1GCC\s0 model the \s-1CPU\s0 closely enough to avoid unreliable
+results from the algorithm.
+.Sp
+This only makes sense when scheduling after register allocation, i.e. with
+\&\fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-group\-heuristic\fR" 4
+.IX Item "-fsched-group-heuristic"
+Enable the group heuristic in the scheduler.  This heuristic favors
+the instruction that belongs to a schedule group.  This is enabled
+by default when scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
+or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-critical\-path\-heuristic\fR" 4
+.IX Item "-fsched-critical-path-heuristic"
+Enable the critical-path heuristic in the scheduler.  This heuristic favors
+instructions on the critical path.  This is enabled by default when
+scheduling is enabled, i.e. with \fB\-fschedule\-insns\fR
+or \fB\-fschedule\-insns2\fR or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-spec\-insn\-heuristic\fR" 4
+.IX Item "-fsched-spec-insn-heuristic"
+Enable the speculative instruction heuristic in the scheduler.  This
+heuristic favors speculative instructions with greater dependency weakness.
+This is enabled by default when scheduling is enabled, i.e.
+with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR
+or at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-rank\-heuristic\fR" 4
+.IX Item "-fsched-rank-heuristic"
+Enable the rank heuristic in the scheduler.  This heuristic favors
+the instruction belonging to a basic block with greater size or frequency.
+This is enabled by default when scheduling is enabled, i.e.
+with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
+at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-last\-insn\-heuristic\fR" 4
+.IX Item "-fsched-last-insn-heuristic"
+Enable the last-instruction heuristic in the scheduler.  This heuristic
+favors the instruction that is less dependent on the last instruction
+scheduled.  This is enabled by default when scheduling is enabled,
+i.e. with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
+at \fB\-O2\fR or higher.
+.IP "\fB\-fsched\-dep\-count\-heuristic\fR" 4
+.IX Item "-fsched-dep-count-heuristic"
+Enable the dependent-count heuristic in the scheduler.  This heuristic
+favors the instruction that has more instructions depending on it.
+This is enabled by default when scheduling is enabled, i.e.
+with \fB\-fschedule\-insns\fR or \fB\-fschedule\-insns2\fR or
+at \fB\-O2\fR or higher.
+.IP "\fB\-freschedule\-modulo\-scheduled\-loops\fR" 4
+.IX Item "-freschedule-modulo-scheduled-loops"
+Modulo scheduling is performed before traditional scheduling.  If a loop
+is modulo scheduled, later scheduling passes may change its schedule.  
+Use this option to control that behavior.
+.IP "\fB\-fselective\-scheduling\fR" 4
+.IX Item "-fselective-scheduling"
+Schedule instructions using selective scheduling algorithm.  Selective
+scheduling runs instead of the first scheduler pass.
+.IP "\fB\-fselective\-scheduling2\fR" 4
+.IX Item "-fselective-scheduling2"
+Schedule instructions using selective scheduling algorithm.  Selective
+scheduling runs instead of the second scheduler pass.
+.IP "\fB\-fsel\-sched\-pipelining\fR" 4
+.IX Item "-fsel-sched-pipelining"
+Enable software pipelining of innermost loops during selective scheduling.
+This option has no effect unless one of \fB\-fselective\-scheduling\fR or
+\&\fB\-fselective\-scheduling2\fR is turned on.
+.IP "\fB\-fsel\-sched\-pipelining\-outer\-loops\fR" 4
+.IX Item "-fsel-sched-pipelining-outer-loops"
+When pipelining loops during selective scheduling, also pipeline outer loops.
+This option has no effect unless \fB\-fsel\-sched\-pipelining\fR is turned on.
+.IP "\fB\-fshrink\-wrap\fR" 4
+.IX Item "-fshrink-wrap"
+Emit function prologues only before parts of the function that need it,
+rather than at the top of the function.  This flag is enabled by default at
+\&\fB\-O\fR and higher.
+.IP "\fB\-fcaller\-saves\fR" 4
+.IX Item "-fcaller-saves"
+Enable allocation of values to registers that are clobbered by
+function calls, by emitting extra instructions to save and restore the
+registers around such calls.  Such allocation is done only when it
+seems to result in better code.
+.Sp
+This option is always enabled by default on certain machines, usually
+those which have no call-preserved registers to use instead.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fcombine\-stack\-adjustments\fR" 4
+.IX Item "-fcombine-stack-adjustments"
+Tracks stack adjustments (pushes and pops) and stack memory references
+and then tries to find ways to combine them.
+.Sp
+Enabled by default at \fB\-O1\fR and higher.
+.IP "\fB\-fconserve\-stack\fR" 4
+.IX Item "-fconserve-stack"
+Attempt to minimize stack usage.  The compiler attempts to use less
+stack space, even if that makes the program slower.  This option
+implies setting the \fBlarge-stack-frame\fR parameter to 100
+and the \fBlarge-stack-frame-growth\fR parameter to 400.
+.IP "\fB\-ftree\-reassoc\fR" 4
+.IX Item "-ftree-reassoc"
+Perform reassociation on trees.  This flag is enabled by default
+at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-pre\fR" 4
+.IX Item "-ftree-pre"
+Perform partial redundancy elimination (\s-1PRE\s0) on trees.  This flag is
+enabled by default at \fB\-O2\fR and \fB\-O3\fR.
+.IP "\fB\-ftree\-partial\-pre\fR" 4
+.IX Item "-ftree-partial-pre"
+Make partial redundancy elimination (\s-1PRE\s0) more aggressive.  This flag is
+enabled by default at \fB\-O3\fR.
+.IP "\fB\-ftree\-forwprop\fR" 4
+.IX Item "-ftree-forwprop"
+Perform forward propagation on trees.  This flag is enabled by default
+at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-fre\fR" 4
+.IX Item "-ftree-fre"
+Perform full redundancy elimination (\s-1FRE\s0) on trees.  The difference
+between \s-1FRE\s0 and \s-1PRE\s0 is that \s-1FRE\s0 only considers expressions
+that are computed on all paths leading to the redundant computation.
+This analysis is faster than \s-1PRE,\s0 though it exposes fewer redundancies.
+This flag is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-phiprop\fR" 4
+.IX Item "-ftree-phiprop"
+Perform hoisting of loads from conditional pointers on trees.  This
+pass is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fhoist\-adjacent\-loads\fR" 4
+.IX Item "-fhoist-adjacent-loads"
+Speculatively hoist loads from both branches of an if-then-else if the
+loads are from adjacent locations in the same structure and the target
+architecture has a conditional move instruction.  This flag is enabled
+by default at \fB\-O2\fR and higher.
+.IP "\fB\-ftree\-copy\-prop\fR" 4
+.IX Item "-ftree-copy-prop"
+Perform copy propagation on trees.  This pass eliminates unnecessary
+copy operations.  This flag is enabled by default at \fB\-O\fR and
+higher.
+.IP "\fB\-fipa\-pure\-const\fR" 4
+.IX Item "-fipa-pure-const"
+Discover which functions are pure or constant.
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fipa\-reference\fR" 4
+.IX Item "-fipa-reference"
+Discover which static variables do not escape the
+compilation unit.
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fipa\-pta\fR" 4
+.IX Item "-fipa-pta"
+Perform interprocedural pointer analysis and interprocedural modification
+and reference analysis.  This option can cause excessive memory and
+compile-time usage on large compilation units.  It is not enabled by
+default at any optimization level.
+.IP "\fB\-fipa\-profile\fR" 4
+.IX Item "-fipa-profile"
+Perform interprocedural profile propagation.  The functions called only from
+cold functions are marked as cold. Also functions executed once (such as
+\&\f(CW\*(C`cold\*(C'\fR, \f(CW\*(C`noreturn\*(C'\fR, static constructors or destructors) are identified. Cold
+functions and loop less parts of functions executed once are then optimized for
+size.
+Enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-fipa\-cp\fR" 4
+.IX Item "-fipa-cp"
+Perform interprocedural constant propagation.
+This optimization analyzes the program to determine when values passed
+to functions are constants and then optimizes accordingly.
+This optimization can substantially increase performance
+if the application has constants passed to functions.
+This flag is enabled by default at \fB\-O2\fR, \fB\-Os\fR and \fB\-O3\fR.
+.IP "\fB\-fipa\-cp\-clone\fR" 4
+.IX Item "-fipa-cp-clone"
+Perform function cloning to make interprocedural constant propagation stronger.
+When enabled, interprocedural constant propagation performs function cloning
+when externally visible function can be called with constant arguments.
+Because this optimization can create multiple copies of functions,
+it may significantly increase code size
+(see \fB\-\-param ipcp\-unit\-growth=\fR\fIvalue\fR).
+This flag is enabled by default at \fB\-O3\fR.
+.IP "\fB\-fisolate\-erroneous\-paths\-dereference\fR" 4
+.IX Item "-fisolate-erroneous-paths-dereference"
+Detect paths which trigger erroneous or undefined behaviour due to
+dereferencing a \s-1NULL\s0 pointer.  Isolate those paths from the main control
+flow and turn the statement with erroneous or undefined behaviour into a trap.
+.IP "\fB\-fisolate\-erroneous\-paths\-attribute\fR" 4
+.IX Item "-fisolate-erroneous-paths-attribute"
+Detect paths which trigger erroneous or undefined behaviour due a \s-1NULL\s0 value
+being used in a way which is forbidden by a \f(CW\*(C`returns_nonnull\*(C'\fR or \f(CW\*(C`nonnull\*(C'\fR
+attribute.  Isolate those paths from the main control flow and turn the
+statement with erroneous or undefined behaviour into a trap.  This is not
+currently enabled, but may be enabled by \f(CW\*(C`\-O2\*(C'\fR in the future.
+.IP "\fB\-ftree\-sink\fR" 4
+.IX Item "-ftree-sink"
+Perform forward store motion  on trees.  This flag is
+enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-bit\-ccp\fR" 4
+.IX Item "-ftree-bit-ccp"
+Perform sparse conditional bit constant propagation on trees and propagate
+pointer alignment information.
+This pass only operates on local scalar variables and is enabled by default
+at \fB\-O\fR and higher.  It requires that \fB\-ftree\-ccp\fR is enabled.
+.IP "\fB\-ftree\-ccp\fR" 4
+.IX Item "-ftree-ccp"
+Perform sparse conditional constant propagation (\s-1CCP\s0) on trees.  This
+pass only operates on local scalar variables and is enabled by default
+at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-switch\-conversion\fR" 4
+.IX Item "-ftree-switch-conversion"
+Perform conversion of simple initializations in a switch to
+initializations from a scalar array.  This flag is enabled by default
+at \fB\-O2\fR and higher.
+.IP "\fB\-ftree\-tail\-merge\fR" 4
+.IX Item "-ftree-tail-merge"
+Look for identical code sequences.  When found, replace one with a jump to the
+other.  This optimization is known as tail merging or cross jumping.  This flag
+is enabled by default at \fB\-O2\fR and higher.  The compilation time
+in this pass can
+be limited using \fBmax-tail-merge-comparisons\fR parameter and
+\&\fBmax-tail-merge-iterations\fR parameter.
+.IP "\fB\-ftree\-dce\fR" 4
+.IX Item "-ftree-dce"
+Perform dead code elimination (\s-1DCE\s0) on trees.  This flag is enabled by
+default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-builtin\-call\-dce\fR" 4
+.IX Item "-ftree-builtin-call-dce"
+Perform conditional dead code elimination (\s-1DCE\s0) for calls to built-in functions
+that may set \f(CW\*(C`errno\*(C'\fR but are otherwise side-effect free.  This flag is
+enabled by default at \fB\-O2\fR and higher if \fB\-Os\fR is not also
+specified.
+.IP "\fB\-ftree\-dominator\-opts\fR" 4
+.IX Item "-ftree-dominator-opts"
+Perform a variety of simple scalar cleanups (constant/copy
+propagation, redundancy elimination, range propagation and expression
+simplification) based on a dominator tree traversal.  This also
+performs jump threading (to reduce jumps to jumps). This flag is
+enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-dse\fR" 4
+.IX Item "-ftree-dse"
+Perform dead store elimination (\s-1DSE\s0) on trees.  A dead store is a store into
+a memory location that is later overwritten by another store without
+any intervening loads.  In this case the earlier store can be deleted.  This
+flag is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-ch\fR" 4
+.IX Item "-ftree-ch"
+Perform loop header copying on trees.  This is beneficial since it increases
+effectiveness of code motion optimizations.  It also saves one jump.  This flag
+is enabled by default at \fB\-O\fR and higher.  It is not enabled
+for \fB\-Os\fR, since it usually increases code size.
+.IP "\fB\-ftree\-loop\-optimize\fR" 4
+.IX Item "-ftree-loop-optimize"
+Perform loop optimizations on trees.  This flag is enabled by default
+at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-loop\-linear\fR" 4
+.IX Item "-ftree-loop-linear"
+Perform loop interchange transformations on tree.  Same as
+\&\fB\-floop\-interchange\fR.  To use this code transformation, \s-1GCC\s0 has
+to be configured with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to
+enable the Graphite loop transformation infrastructure.
+.IP "\fB\-floop\-interchange\fR" 4
+.IX Item "-floop-interchange"
+Perform loop interchange transformations on loops.  Interchanging two
+nested loops switches the inner and outer loops.  For example, given a
+loop like:
+.Sp
+.Vb 5
+\&        DO J = 1, M
+\&          DO I = 1, N
+\&            A(J, I) = A(J, I) * C
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+loop interchange transforms the loop as if it were written:
+.Sp
+.Vb 5
+\&        DO I = 1, N
+\&          DO J = 1, M
+\&            A(J, I) = A(J, I) * C
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+which can be beneficial when \f(CW\*(C`N\*(C'\fR is larger than the caches,
+because in Fortran, the elements of an array are stored in memory
+contiguously by column, and the original loop iterates over rows,
+potentially creating at each access a cache miss.  This optimization
+applies to all the languages supported by \s-1GCC\s0 and is not limited to
+Fortran.  To use this code transformation, \s-1GCC\s0 has to be configured
+with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to enable the
+Graphite loop transformation infrastructure.
+.IP "\fB\-floop\-strip\-mine\fR" 4
+.IX Item "-floop-strip-mine"
+Perform loop strip mining transformations on loops.  Strip mining
+splits a loop into two nested loops.  The outer loop has strides
+equal to the strip size and the inner loop has strides of the
+original loop within a strip.  The strip length can be changed
+using the \fBloop-block-tile-size\fR parameter.  For example,
+given a loop like:
+.Sp
+.Vb 3
+\&        DO I = 1, N
+\&          A(I) = A(I) + C
+\&        ENDDO
+.Ve
+.Sp
+loop strip mining transforms the loop as if it were written:
+.Sp
+.Vb 5
+\&        DO II = 1, N, 51
+\&          DO I = II, min (II + 50, N)
+\&            A(I) = A(I) + C
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+This optimization applies to all the languages supported by \s-1GCC\s0 and is
+not limited to Fortran.  To use this code transformation, \s-1GCC\s0 has to
+be configured with \fB\-\-with\-ppl\fR and \fB\-\-with\-cloog\fR to
+enable the Graphite loop transformation infrastructure.
+.IP "\fB\-floop\-block\fR" 4
+.IX Item "-floop-block"
+Perform loop blocking transformations on loops.  Blocking strip mines
+each loop in the loop nest such that the memory accesses of the
+element loops fit inside caches.  The strip length can be changed
+using the \fBloop-block-tile-size\fR parameter.  For example, given
+a loop like:
+.Sp
+.Vb 5
+\&        DO I = 1, N
+\&          DO J = 1, M
+\&            A(J, I) = B(I) + C(J)
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+loop blocking transforms the loop as if it were written:
+.Sp
+.Vb 9
+\&        DO II = 1, N, 51
+\&          DO JJ = 1, M, 51
+\&            DO I = II, min (II + 50, N)
+\&              DO J = JJ, min (JJ + 50, M)
+\&                A(J, I) = B(I) + C(J)
+\&              ENDDO
+\&            ENDDO
+\&          ENDDO
+\&        ENDDO
+.Ve
+.Sp
+which can be beneficial when \f(CW\*(C`M\*(C'\fR is larger than the caches,
+because the innermost loop iterates over a smaller amount of data
+which can be kept in the caches.  This optimization applies to all the
+languages supported by \s-1GCC\s0 and is not limited to Fortran.  To use this
+code transformation, \s-1GCC\s0 has to be configured with \fB\-\-with\-ppl\fR
+and \fB\-\-with\-cloog\fR to enable the Graphite loop transformation
+infrastructure.
+.IP "\fB\-fgraphite\-identity\fR" 4
+.IX Item "-fgraphite-identity"
+Enable the identity transformation for graphite.  For every SCoP we generate
+the polyhedral representation and transform it back to gimple.  Using
+\&\fB\-fgraphite\-identity\fR we can check the costs or benefits of the
+\&\s-1GIMPLE \-\s0> \s-1GRAPHITE \-\s0> \s-1GIMPLE\s0 transformation.  Some minimal optimizations
+are also performed by the code generator CLooG, like index splitting and
+dead code elimination in loops.
+.IP "\fB\-floop\-nest\-optimize\fR" 4
+.IX Item "-floop-nest-optimize"
+Enable the \s-1ISL\s0 based loop nest optimizer.  This is a generic loop nest
+optimizer based on the Pluto optimization algorithms.  It calculates a loop
+structure optimized for data-locality and parallelism.  This option
+is experimental.
+.IP "\fB\-floop\-parallelize\-all\fR" 4
+.IX Item "-floop-parallelize-all"
+Use the Graphite data dependence analysis to identify loops that can
+be parallelized.  Parallelize all the loops that can be analyzed to
+not contain loop carried dependences without checking that it is
+profitable to parallelize the loops.
+.IP "\fB\-fcheck\-data\-deps\fR" 4
+.IX Item "-fcheck-data-deps"
+Compare the results of several data dependence analyzers.  This option
+is used for debugging the data dependence analyzers.
+.IP "\fB\-ftree\-loop\-if\-convert\fR" 4
+.IX Item "-ftree-loop-if-convert"
+Attempt to transform conditional jumps in the innermost loops to
+branch-less equivalents.  The intent is to remove control-flow from
+the innermost loops in order to improve the ability of the
+vectorization pass to handle these loops.  This is enabled by default
+if vectorization is enabled.
+.IP "\fB\-ftree\-loop\-if\-convert\-stores\fR" 4
+.IX Item "-ftree-loop-if-convert-stores"
+Attempt to also if-convert conditional jumps containing memory writes.
+This transformation can be unsafe for multi-threaded programs as it
+transforms conditional memory writes into unconditional memory writes.
+For example,
+.Sp
+.Vb 3
+\&        for (i = 0; i < N; i++)
+\&          if (cond)
+\&            A[i] = expr;
+.Ve
+.Sp
+is transformed to
+.Sp
+.Vb 2
+\&        for (i = 0; i < N; i++)
+\&          A[i] = cond ? expr : A[i];
+.Ve
+.Sp
+potentially producing data races.
+.IP "\fB\-ftree\-loop\-distribution\fR" 4
+.IX Item "-ftree-loop-distribution"
+Perform loop distribution.  This flag can improve cache performance on
+big loop bodies and allow further loop optimizations, like
+parallelization or vectorization, to take place.  For example, the loop
+.Sp
+.Vb 4
+\&        DO I = 1, N
+\&          A(I) = B(I) + C
+\&          D(I) = E(I) * F
+\&        ENDDO
+.Ve
+.Sp
+is transformed to
+.Sp
+.Vb 6
+\&        DO I = 1, N
+\&           A(I) = B(I) + C
+\&        ENDDO
+\&        DO I = 1, N
+\&           D(I) = E(I) * F
+\&        ENDDO
+.Ve
+.IP "\fB\-ftree\-loop\-distribute\-patterns\fR" 4
+.IX Item "-ftree-loop-distribute-patterns"
+Perform loop distribution of patterns that can be code generated with
+calls to a library.  This flag is enabled by default at \fB\-O3\fR.
+.Sp
+This pass distributes the initialization loops and generates a call to
+memset zero.  For example, the loop
+.Sp
+.Vb 4
+\&        DO I = 1, N
+\&          A(I) = 0
+\&          B(I) = A(I) + I
+\&        ENDDO
+.Ve
+.Sp
+is transformed to
+.Sp
+.Vb 6
+\&        DO I = 1, N
+\&           A(I) = 0
+\&        ENDDO
+\&        DO I = 1, N
+\&           B(I) = A(I) + I
+\&        ENDDO
+.Ve
+.Sp
+and the initialization loop is transformed into a call to memset zero.
+.IP "\fB\-ftree\-loop\-im\fR" 4
+.IX Item "-ftree-loop-im"
+Perform loop invariant motion on trees.  This pass moves only invariants that
+are hard to handle at \s-1RTL\s0 level (function calls, operations that expand to
+nontrivial sequences of insns).  With \fB\-funswitch\-loops\fR it also moves
+operands of conditions that are invariant out of the loop, so that we can use
+just trivial invariantness analysis in loop unswitching.  The pass also includes
+store motion.
+.IP "\fB\-ftree\-loop\-ivcanon\fR" 4
+.IX Item "-ftree-loop-ivcanon"
+Create a canonical counter for number of iterations in loops for which
+determining number of iterations requires complicated analysis.  Later
+optimizations then may determine the number easily.  Useful especially
+in connection with unrolling.
+.IP "\fB\-fivopts\fR" 4
+.IX Item "-fivopts"
+Perform induction variable optimizations (strength reduction, induction
+variable merging and induction variable elimination) on trees.
+.IP "\fB\-ftree\-parallelize\-loops=n\fR" 4
+.IX Item "-ftree-parallelize-loops=n"
+Parallelize loops, i.e., split their iteration space to run in n threads.
+This is only possible for loops whose iterations are independent
+and can be arbitrarily reordered.  The optimization is only
+profitable on multiprocessor machines, for loops that are CPU-intensive,
+rather than constrained e.g. by memory bandwidth.  This option
+implies \fB\-pthread\fR, and thus is only supported on targets
+that have support for \fB\-pthread\fR.
+.IP "\fB\-ftree\-pta\fR" 4
+.IX Item "-ftree-pta"
+Perform function-local points-to analysis on trees.  This flag is
+enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-sra\fR" 4
+.IX Item "-ftree-sra"
+Perform scalar replacement of aggregates.  This pass replaces structure
+references with scalars to prevent committing structures to memory too
+early.  This flag is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-copyrename\fR" 4
+.IX Item "-ftree-copyrename"
+Perform copy renaming on trees.  This pass attempts to rename compiler
+temporaries to other variables at copy locations, usually resulting in
+variable names which more closely resemble the original variables.  This flag
+is enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-coalesce\-inlined\-vars\fR" 4
+.IX Item "-ftree-coalesce-inlined-vars"
+Tell the copyrename pass (see \fB\-ftree\-copyrename\fR) to attempt to
+combine small user-defined variables too, but only if they were inlined
+from other functions.  It is a more limited form of
+\&\fB\-ftree\-coalesce\-vars\fR.  This may harm debug information of such
+inlined variables, but it will keep variables of the inlined-into
+function apart from each other, such that they are more likely to
+contain the expected values in a debugging session.  This was the
+default in \s-1GCC\s0 versions older than 4.7.
+.IP "\fB\-ftree\-coalesce\-vars\fR" 4
+.IX Item "-ftree-coalesce-vars"
+Tell the copyrename pass (see \fB\-ftree\-copyrename\fR) to attempt to
+combine small user-defined variables too, instead of just compiler
+temporaries.  This may severely limit the ability to debug an optimized
+program compiled with \fB\-fno\-var\-tracking\-assignments\fR.  In the
+negated form, this flag prevents \s-1SSA\s0 coalescing of user variables,
+including inlined ones.  This option is enabled by default.
+.IP "\fB\-ftree\-ter\fR" 4
+.IX Item "-ftree-ter"
+Perform temporary expression replacement during the \s-1SSA\-\s0>normal phase.  Single
+use/single def temporaries are replaced at their use location with their
+defining expression.  This results in non-GIMPLE code, but gives the expanders
+much more complex trees to work on resulting in better \s-1RTL\s0 generation.  This is
+enabled by default at \fB\-O\fR and higher.
+.IP "\fB\-ftree\-slsr\fR" 4
+.IX Item "-ftree-slsr"
+Perform straight-line strength reduction on trees.  This recognizes related
+expressions involving multiplications and replaces them by less expensive
+calculations when possible.  This is enabled by default at \fB\-O\fR and
+higher.
+.IP "\fB\-ftree\-vectorize\fR" 4
+.IX Item "-ftree-vectorize"
+Perform vectorization on trees. This flag enables \fB\-ftree\-loop\-vectorize\fR
+and \fB\-ftree\-slp\-vectorize\fR if not explicitly specified.
+.IP "\fB\-ftree\-loop\-vectorize\fR" 4
+.IX Item "-ftree-loop-vectorize"
+Perform loop vectorization on trees. This flag is enabled by default at
+\&\fB\-O3\fR and when \fB\-ftree\-vectorize\fR is enabled.
+.IP "\fB\-ftree\-slp\-vectorize\fR" 4
+.IX Item "-ftree-slp-vectorize"
+Perform basic block vectorization on trees. This flag is enabled by default at
+\&\fB\-O3\fR and when \fB\-ftree\-vectorize\fR is enabled.
+.IP "\fB\-fvect\-cost\-model=\fR\fImodel\fR" 4
+.IX Item "-fvect-cost-model=model"
+Alter the cost model used for vectorization.  The \fImodel\fR argument
+should be one of \f(CW\*(C`unlimited\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR or \f(CW\*(C`cheap\*(C'\fR.
+With the \f(CW\*(C`unlimited\*(C'\fR model the vectorized code-path is assumed
+to be profitable while with the \f(CW\*(C`dynamic\*(C'\fR model a runtime check
+will guard the vectorized code-path to enable it only for iteration
+counts that will likely execute faster than when executing the original
+scalar loop.  The \f(CW\*(C`cheap\*(C'\fR model will disable vectorization of
+loops where doing so would be cost prohibitive for example due to
+required runtime checks for data dependence or alignment but otherwise
+is equal to the \f(CW\*(C`dynamic\*(C'\fR model.
+The default cost model depends on other optimization flags and is
+either \f(CW\*(C`dynamic\*(C'\fR or \f(CW\*(C`cheap\*(C'\fR.
+.IP "\fB\-fsimd\-cost\-model=\fR\fImodel\fR" 4
+.IX Item "-fsimd-cost-model=model"
+Alter the cost model used for vectorization of loops marked with the OpenMP
+or Cilk Plus simd directive.  The \fImodel\fR argument should be one of
+\&\f(CW\*(C`unlimited\*(C'\fR, \f(CW\*(C`dynamic\*(C'\fR, \f(CW\*(C`cheap\*(C'\fR.  All values of \fImodel\fR
+have the same meaning as described in \fB\-fvect\-cost\-model\fR and by
+default a cost model defined with \fB\-fvect\-cost\-model\fR is used.
+.IP "\fB\-ftree\-vrp\fR" 4
+.IX Item "-ftree-vrp"
+Perform Value Range Propagation on trees.  This is similar to the
+constant propagation pass, but instead of values, ranges of values are
+propagated.  This allows the optimizers to remove unnecessary range
+checks like array bound checks and null pointer checks.  This is
+enabled by default at \fB\-O2\fR and higher.  Null pointer check
+elimination is only done if \fB\-fdelete\-null\-pointer\-checks\fR is
+enabled.
+.IP "\fB\-ftracer\fR" 4
+.IX Item "-ftracer"
+Perform tail duplication to enlarge superblock size.  This transformation
+simplifies the control flow of the function allowing other optimizations to do
+a better job.
+.IP "\fB\-funroll\-loops\fR" 4
+.IX Item "-funroll-loops"
+Unroll loops whose number of iterations can be determined at compile
+time or upon entry to the loop.  \fB\-funroll\-loops\fR implies
+\&\fB\-frerun\-cse\-after\-loop\fR.  This option makes code larger,
+and may or may not make it run faster.
+.IP "\fB\-funroll\-all\-loops\fR" 4
+.IX Item "-funroll-all-loops"
+Unroll all loops, even if their number of iterations is uncertain when
+the loop is entered.  This usually makes programs run more slowly.
+\&\fB\-funroll\-all\-loops\fR implies the same options as
+\&\fB\-funroll\-loops\fR,
+.IP "\fB\-fsplit\-ivs\-in\-unroller\fR" 4
+.IX Item "-fsplit-ivs-in-unroller"
+Enables expression of values of induction variables in later iterations
+of the unrolled loop using the value in the first iteration.  This breaks
+long dependency chains, thus improving efficiency of the scheduling passes.
+.Sp
+A combination of \fB\-fweb\fR and \s-1CSE\s0 is often sufficient to obtain the
+same effect.  However, that is not reliable in cases where the loop body
+is more complicated than a single basic block.  It also does not work at all
+on some architectures due to restrictions in the \s-1CSE\s0 pass.
+.Sp
+This optimization is enabled by default.
+.IP "\fB\-fvariable\-expansion\-in\-unroller\fR" 4
+.IX Item "-fvariable-expansion-in-unroller"
+With this option, the compiler creates multiple copies of some
+local variables when unrolling a loop, which can result in superior code.
+.IP "\fB\-fpartial\-inlining\fR" 4
+.IX Item "-fpartial-inlining"
+Inline parts of functions.  This option has any effect only
+when inlining itself is turned on by the \fB\-finline\-functions\fR
+or \fB\-finline\-small\-functions\fR options.
+.Sp
+Enabled at level \fB\-O2\fR.
+.IP "\fB\-fpredictive\-commoning\fR" 4
+.IX Item "-fpredictive-commoning"
+Perform predictive commoning optimization, i.e., reusing computations
+(especially memory loads and stores) performed in previous
+iterations of loops.
+.Sp
+This option is enabled at level \fB\-O3\fR.
+.IP "\fB\-fprefetch\-loop\-arrays\fR" 4
+.IX Item "-fprefetch-loop-arrays"
+If supported by the target machine, generate instructions to prefetch
+memory to improve the performance of loops that access large arrays.
+.Sp
+This option may generate better or worse code; results are highly
+dependent on the structure of loops within the source code.
+.Sp
+Disabled at level \fB\-Os\fR.
+.IP "\fB\-fno\-peephole\fR" 4
+.IX Item "-fno-peephole"
+.PD 0
+.IP "\fB\-fno\-peephole2\fR" 4
+.IX Item "-fno-peephole2"
+.PD
+Disable any machine-specific peephole optimizations.  The difference
+between \fB\-fno\-peephole\fR and \fB\-fno\-peephole2\fR is in how they
+are implemented in the compiler; some targets use one, some use the
+other, a few use both.
+.Sp
+\&\fB\-fpeephole\fR is enabled by default.
+\&\fB\-fpeephole2\fR enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fno\-guess\-branch\-probability\fR" 4
+.IX Item "-fno-guess-branch-probability"
+Do not guess branch probabilities using heuristics.
+.Sp
+\&\s-1GCC\s0 uses heuristics to guess branch probabilities if they are
+not provided by profiling feedback (\fB\-fprofile\-arcs\fR).  These
+heuristics are based on the control flow graph.  If some branch probabilities
+are specified by \fB_\|_builtin_expect\fR, then the heuristics are
+used to guess branch probabilities for the rest of the control flow graph,
+taking the \fB_\|_builtin_expect\fR info into account.  The interactions
+between the heuristics and \fB_\|_builtin_expect\fR can be complex, and in
+some cases, it may be useful to disable the heuristics so that the effects
+of \fB_\|_builtin_expect\fR are easier to understand.
+.Sp
+The default is \fB\-fguess\-branch\-probability\fR at levels
+\&\fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-freorder\-blocks\fR" 4
+.IX Item "-freorder-blocks"
+Reorder basic blocks in the compiled function in order to reduce number of
+taken branches and improve code locality.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-freorder\-blocks\-and\-partition\fR" 4
+.IX Item "-freorder-blocks-and-partition"
+In addition to reordering basic blocks in the compiled function, in order
+to reduce number of taken branches, partitions hot and cold basic blocks
+into separate sections of the assembly and .o files, to improve
+paging and cache locality performance.
+.Sp
+This optimization is automatically turned off in the presence of
+exception handling, for linkonce sections, for functions with a user-defined
+section attribute and on any architecture that does not support named
+sections.
+.Sp
+Enabled for x86 at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-freorder\-functions\fR" 4
+.IX Item "-freorder-functions"
+Reorder functions in the object file in order to
+improve code locality.  This is implemented by using special
+subsections \f(CW\*(C`.text.hot\*(C'\fR for most frequently executed functions and
+\&\f(CW\*(C`.text.unlikely\*(C'\fR for unlikely executed functions.  Reordering is done by
+the linker so object file format must support named sections and linker must
+place them in a reasonable way.
+.Sp
+Also profile feedback must be available to make this option effective.  See
+\&\fB\-fprofile\-arcs\fR for details.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fstrict\-aliasing\fR" 4
+.IX Item "-fstrict-aliasing"
+Allow the compiler to assume the strictest aliasing rules applicable to
+the language being compiled.  For C (and \*(C+), this activates
+optimizations based on the type of expressions.  In particular, an
+object of one type is assumed never to reside at the same address as an
+object of a different type, unless the types are almost the same.  For
+example, an \f(CW\*(C`unsigned int\*(C'\fR can alias an \f(CW\*(C`int\*(C'\fR, but not a
+\&\f(CW\*(C`void*\*(C'\fR or a \f(CW\*(C`double\*(C'\fR.  A character type may alias any other
+type.
+.Sp
+Pay special attention to code like this:
+.Sp
+.Vb 4
+\&        union a_union {
+\&          int i;
+\&          double d;
+\&        };
+\&        
+\&        int f() {
+\&          union a_union t;
+\&          t.d = 3.0;
+\&          return t.i;
+\&        }
+.Ve
+.Sp
+The practice of reading from a different union member than the one most
+recently written to (called \*(L"type-punning\*(R") is common.  Even with
+\&\fB\-fstrict\-aliasing\fR, type-punning is allowed, provided the memory
+is accessed through the union type.  So, the code above works as
+expected.    However, this code might not:
+.Sp
+.Vb 7
+\&        int f() {
+\&          union a_union t;
+\&          int* ip;
+\&          t.d = 3.0;
+\&          ip = &t.i;
+\&          return *ip;
+\&        }
+.Ve
+.Sp
+Similarly, access by taking the address, casting the resulting pointer
+and dereferencing the result has undefined behavior, even if the cast
+uses a union type, e.g.:
+.Sp
+.Vb 4
+\&        int f() {
+\&          double d = 3.0;
+\&          return ((union a_union *) &d)\->i;
+\&        }
+.Ve
+.Sp
+The \fB\-fstrict\-aliasing\fR option is enabled at levels
+\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fstrict\-overflow\fR" 4
+.IX Item "-fstrict-overflow"
+Allow the compiler to assume strict signed overflow rules, depending
+on the language being compiled.  For C (and \*(C+) this means that
+overflow when doing arithmetic with signed numbers is undefined, which
+means that the compiler may assume that it does not happen.  This
+permits various optimizations.  For example, the compiler assumes
+that an expression like \f(CW\*(C`i + 10 > i\*(C'\fR is always true for
+signed \f(CW\*(C`i\*(C'\fR.  This assumption is only valid if signed overflow is
+undefined, as the expression is false if \f(CW\*(C`i + 10\*(C'\fR overflows when
+using twos complement arithmetic.  When this option is in effect any
+attempt to determine whether an operation on signed numbers 
+overflows must be written carefully to not actually involve overflow.
+.Sp
+This option also allows the compiler to assume strict pointer
+semantics: given a pointer to an object, if adding an offset to that
+pointer does not produce a pointer to the same object, the addition is
+undefined.  This permits the compiler to conclude that \f(CW\*(C`p + u >
+p\*(C'\fR is always true for a pointer \f(CW\*(C`p\*(C'\fR and unsigned integer
+\&\f(CW\*(C`u\*(C'\fR.  This assumption is only valid because pointer wraparound is
+undefined, as the expression is false if \f(CW\*(C`p + u\*(C'\fR overflows using
+twos complement arithmetic.
+.Sp
+See also the \fB\-fwrapv\fR option.  Using \fB\-fwrapv\fR means
+that integer signed overflow is fully defined: it wraps.  When
+\&\fB\-fwrapv\fR is used, there is no difference between
+\&\fB\-fstrict\-overflow\fR and \fB\-fno\-strict\-overflow\fR for
+integers.  With \fB\-fwrapv\fR certain types of overflow are
+permitted.  For example, if the compiler gets an overflow when doing
+arithmetic on constants, the overflowed value can still be used with
+\&\fB\-fwrapv\fR, but not otherwise.
+.Sp
+The \fB\-fstrict\-overflow\fR option is enabled at levels
+\&\fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-falign\-functions\fR" 4
+.IX Item "-falign-functions"
+.PD 0
+.IP "\fB\-falign\-functions=\fR\fIn\fR" 4
+.IX Item "-falign-functions=n"
+.PD
+Align the start of functions to the next power-of-two greater than
+\&\fIn\fR, skipping up to \fIn\fR bytes.  For instance,
+\&\fB\-falign\-functions=32\fR aligns functions to the next 32\-byte
+boundary, but \fB\-falign\-functions=24\fR aligns to the next
+32\-byte boundary only if this can be done by skipping 23 bytes or less.
+.Sp
+\&\fB\-fno\-align\-functions\fR and \fB\-falign\-functions=1\fR are
+equivalent and mean that functions are not aligned.
+.Sp
+Some assemblers only support this flag when \fIn\fR is a power of two;
+in that case, it is rounded up.
+.Sp
+If \fIn\fR is not specified or is zero, use a machine-dependent default.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-falign\-labels\fR" 4
+.IX Item "-falign-labels"
+.PD 0
+.IP "\fB\-falign\-labels=\fR\fIn\fR" 4
+.IX Item "-falign-labels=n"
+.PD
+Align all branch targets to a power-of-two boundary, skipping up to
+\&\fIn\fR bytes like \fB\-falign\-functions\fR.  This option can easily
+make code slower, because it must insert dummy operations for when the
+branch target is reached in the usual flow of the code.
+.Sp
+\&\fB\-fno\-align\-labels\fR and \fB\-falign\-labels=1\fR are
+equivalent and mean that labels are not aligned.
+.Sp
+If \fB\-falign\-loops\fR or \fB\-falign\-jumps\fR are applicable and
+are greater than this value, then their values are used instead.
+.Sp
+If \fIn\fR is not specified or is zero, use a machine-dependent default
+which is very likely to be \fB1\fR, meaning no alignment.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-falign\-loops\fR" 4
+.IX Item "-falign-loops"
+.PD 0
+.IP "\fB\-falign\-loops=\fR\fIn\fR" 4
+.IX Item "-falign-loops=n"
+.PD
+Align loops to a power-of-two boundary, skipping up to \fIn\fR bytes
+like \fB\-falign\-functions\fR.  If the loops are
+executed many times, this makes up for any execution of the dummy
+operations.
+.Sp
+\&\fB\-fno\-align\-loops\fR and \fB\-falign\-loops=1\fR are
+equivalent and mean that loops are not aligned.
+.Sp
+If \fIn\fR is not specified or is zero, use a machine-dependent default.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-falign\-jumps\fR" 4
+.IX Item "-falign-jumps"
+.PD 0
+.IP "\fB\-falign\-jumps=\fR\fIn\fR" 4
+.IX Item "-falign-jumps=n"
+.PD
+Align branch targets to a power-of-two boundary, for branch targets
+where the targets can only be reached by jumping, skipping up to \fIn\fR
+bytes like \fB\-falign\-functions\fR.  In this case, no dummy operations
+need be executed.
+.Sp
+\&\fB\-fno\-align\-jumps\fR and \fB\-falign\-jumps=1\fR are
+equivalent and mean that loops are not aligned.
+.Sp
+If \fIn\fR is not specified or is zero, use a machine-dependent default.
+.Sp
+Enabled at levels \fB\-O2\fR, \fB\-O3\fR.
+.IP "\fB\-funit\-at\-a\-time\fR" 4
+.IX Item "-funit-at-a-time"
+This option is left for compatibility reasons. \fB\-funit\-at\-a\-time\fR
+has no effect, while \fB\-fno\-unit\-at\-a\-time\fR implies
+\&\fB\-fno\-toplevel\-reorder\fR and \fB\-fno\-section\-anchors\fR.
+.Sp
+Enabled by default.
+.IP "\fB\-fno\-toplevel\-reorder\fR" 4
+.IX Item "-fno-toplevel-reorder"
+Do not reorder top-level functions, variables, and \f(CW\*(C`asm\*(C'\fR
+statements.  Output them in the same order that they appear in the
+input file.  When this option is used, unreferenced static variables
+are not removed.  This option is intended to support existing code
+that relies on a particular ordering.  For new code, it is better to
+use attributes when possible.
+.Sp
+Enabled at level \fB\-O0\fR.  When disabled explicitly, it also implies
+\&\fB\-fno\-section\-anchors\fR, which is otherwise enabled at \fB\-O0\fR on some
+targets.
+.IP "\fB\-fweb\fR" 4
+.IX Item "-fweb"
+Constructs webs as commonly used for register allocation purposes and assign
+each web individual pseudo register.  This allows the register allocation pass
+to operate on pseudos directly, but also strengthens several other optimization
+passes, such as \s-1CSE,\s0 loop optimizer and trivial dead code remover.  It can,
+however, make debugging impossible, since variables no longer stay in a
+\&\*(L"home register\*(R".
+.Sp
+Enabled by default with \fB\-funroll\-loops\fR.
+.IP "\fB\-fwhole\-program\fR" 4
+.IX Item "-fwhole-program"
+Assume that the current compilation unit represents the whole program being
+compiled.  All public functions and variables with the exception of \f(CW\*(C`main\*(C'\fR
+and those merged by attribute \f(CW\*(C`externally_visible\*(C'\fR become static functions
+and in effect are optimized more aggressively by interprocedural optimizers.
+.Sp
+This option should not be used in combination with \f(CW\*(C`\-flto\*(C'\fR.
+Instead relying on a linker plugin should provide safer and more precise
+information.
+.IP "\fB\-flto[=\fR\fIn\fR\fB]\fR" 4
+.IX Item "-flto[=n]"
+This option runs the standard link-time optimizer.  When invoked
+with source code, it generates \s-1GIMPLE \s0(one of \s-1GCC\s0's internal
+representations) and writes it to special \s-1ELF\s0 sections in the object
+file.  When the object files are linked together, all the function
+bodies are read from these \s-1ELF\s0 sections and instantiated as if they
+had been part of the same translation unit.
+.Sp
+To use the link-time optimizer, \fB\-flto\fR and optimization
+options should be specified at compile time and during the final link.
+For example:
+.Sp
+.Vb 3
+\&        gcc \-c \-O2 \-flto foo.c
+\&        gcc \-c \-O2 \-flto bar.c
+\&        gcc \-o myprog \-flto \-O2 foo.o bar.o
+.Ve
+.Sp
+The first two invocations to \s-1GCC\s0 save a bytecode representation
+of \s-1GIMPLE\s0 into special \s-1ELF\s0 sections inside \fIfoo.o\fR and
+\&\fIbar.o\fR.  The final invocation reads the \s-1GIMPLE\s0 bytecode from
+\&\fIfoo.o\fR and \fIbar.o\fR, merges the two files into a single
+internal image, and compiles the result as usual.  Since both
+\&\fIfoo.o\fR and \fIbar.o\fR are merged into a single image, this
+causes all the interprocedural analyses and optimizations in \s-1GCC\s0 to
+work across the two files as if they were a single one.  This means,
+for example, that the inliner is able to inline functions in
+\&\fIbar.o\fR into functions in \fIfoo.o\fR and vice-versa.
+.Sp
+Another (simpler) way to enable link-time optimization is:
+.Sp
+.Vb 1
+\&        gcc \-o myprog \-flto \-O2 foo.c bar.c
+.Ve
+.Sp
+The above generates bytecode for \fIfoo.c\fR and \fIbar.c\fR,
+merges them together into a single \s-1GIMPLE\s0 representation and optimizes
+them as usual to produce \fImyprog\fR.
+.Sp
+The only important thing to keep in mind is that to enable link-time
+optimizations you need to use the \s-1GCC\s0 driver to perform the link-step.
+\&\s-1GCC\s0 then automatically performs link-time optimization if any of the
+objects involved were compiled with the \fB\-flto\fR.  You generally
+should specify the optimization options to be used for link-time
+optimization though \s-1GCC\s0 will try to be clever at guessing an
+optimization level to use from the options used at compile-time
+if you fail to specify one at link-time.  You can always override
+the automatic decision to do link-time optimization at link-time
+by passing \fB\-fno\-lto\fR to the link command.
+.Sp
+To make whole program optimization effective, it is necessary to make
+certain whole program assumptions.  The compiler needs to know
+what functions and variables can be accessed by libraries and runtime
+outside of the link-time optimized unit.  When supported by the linker,
+the linker plugin (see \fB\-fuse\-linker\-plugin\fR) passes information
+to the compiler about used and externally visible symbols.  When
+the linker plugin is not available, \fB\-fwhole\-program\fR should be
+used to allow the compiler to make these assumptions, which leads
+to more aggressive optimization decisions.
+.Sp
+When \fB\-fuse\-linker\-plugin\fR is not enabled then, when a file is
+compiled with \fB\-flto\fR, the generated object file is larger than
+a regular object file because it contains \s-1GIMPLE\s0 bytecodes and the usual
+final code (see \fB\-ffat\-lto\-objects\fR.  This means that
+object files with \s-1LTO\s0 information can be linked as normal object
+files; if \fB\-fno\-lto\fR is passed to the linker, no
+interprocedural optimizations are applied.  Note that when
+\&\fB\-fno\-fat\-lto\-objects\fR is enabled the compile-stage is faster
+but you cannot perform a regular, non-LTO link on them.
+.Sp
+Additionally, the optimization flags used to compile individual files
+are not necessarily related to those used at link time.  For instance,
+.Sp
+.Vb 3
+\&        gcc \-c \-O0 \-ffat\-lto\-objects \-flto foo.c
+\&        gcc \-c \-O0 \-ffat\-lto\-objects \-flto bar.c
+\&        gcc \-o myprog \-O3 foo.o bar.o
+.Ve
+.Sp
+This produces individual object files with unoptimized assembler
+code, but the resulting binary \fImyprog\fR is optimized at
+\&\fB\-O3\fR.  If, instead, the final binary is generated with
+\&\fB\-fno\-lto\fR, then \fImyprog\fR is not optimized.
+.Sp
+When producing the final binary, \s-1GCC\s0 only
+applies link-time optimizations to those files that contain bytecode.
+Therefore, you can mix and match object files and libraries with
+\&\s-1GIMPLE\s0 bytecodes and final object code.  \s-1GCC\s0 automatically selects
+which files to optimize in \s-1LTO\s0 mode and which files to link without
+further processing.
+.Sp
+There are some code generation flags preserved by \s-1GCC\s0 when
+generating bytecodes, as they need to be used during the final link
+stage.  Generally options specified at link-time override those
+specified at compile-time.
+.Sp
+If you do not specify an optimization level option \fB\-O\fR at
+link-time then \s-1GCC\s0 will compute one based on the optimization levels
+used when compiling the object files.  The highest optimization
+level will win here.
+.Sp
+Currently, the following options and their setting are take from
+the first object file that explicitely specified it: 
+\&\fB\-fPIC\fR, \fB\-fpic\fR, \fB\-fpie\fR, \fB\-fcommon\fR,
+\&\fB\-fexceptions\fR, \fB\-fnon\-call\-exceptions\fR, \fB\-fgnu\-tm\fR
+and all the \fB\-m\fR target flags.
+.Sp
+Certain \s-1ABI\s0 changing flags are required to match in all compilation-units
+and trying to override this at link-time with a conflicting value
+is ignored.  This includes options such as \fB\-freg\-struct\-return\fR
+and \fB\-fpcc\-struct\-return\fR.
+.Sp
+Other options such as \fB\-ffp\-contract\fR, \fB\-fno\-strict\-overflow\fR,
+\&\fB\-fwrapv\fR, \fB\-fno\-trapv\fR or \fB\-fno\-strict\-aliasing\fR
+are passed through to the link stage and merged conservatively for
+conflicting translation units.  Specifically
+\&\fB\-fno\-strict\-overflow\fR, \fB\-fwrapv\fR and \fB\-fno\-trapv\fR take
+precedence and for example \fB\-ffp\-contract=off\fR takes precedence
+over \fB\-ffp\-contract=fast\fR.  You can override them at linke-time.
+.Sp
+It is recommended that you compile all the files participating in the
+same link with the same options and also specify those options at
+link time.
+.Sp
+If \s-1LTO\s0 encounters objects with C linkage declared with incompatible
+types in separate translation units to be linked together (undefined
+behavior according to \s-1ISO C99 6.2.7\s0), a non-fatal diagnostic may be
+issued.  The behavior is still undefined at run time.  Similar
+diagnostics may be raised for other languages.
+.Sp
+Another feature of \s-1LTO\s0 is that it is possible to apply interprocedural
+optimizations on files written in different languages:
+.Sp
+.Vb 4
+\&        gcc \-c \-flto foo.c
+\&        g++ \-c \-flto bar.cc
+\&        gfortran \-c \-flto baz.f90
+\&        g++ \-o myprog \-flto \-O3 foo.o bar.o baz.o \-lgfortran
+.Ve
+.Sp
+Notice that the final link is done with \fBg++\fR to get the \*(C+
+runtime libraries and \fB\-lgfortran\fR is added to get the Fortran
+runtime libraries.  In general, when mixing languages in \s-1LTO\s0 mode, you
+should use the same link command options as when mixing languages in a
+regular (non-LTO) compilation.
+.Sp
+If object files containing \s-1GIMPLE\s0 bytecode are stored in a library archive, say
+\&\fIlibfoo.a\fR, it is possible to extract and use them in an \s-1LTO\s0 link if you
+are using a linker with plugin support.  To create static libraries suitable
+for \s-1LTO,\s0 use \fBgcc-ar\fR and \fBgcc-ranlib\fR instead of \fBar\fR
+and \f(CW\*(C`ranlib\*(C'\fR; to show the symbols of object files with \s-1GIMPLE\s0 bytecode, use
+\&\fBgcc-nm\fR.  Those commands require that \fBar\fR, \fBranlib\fR
+and \fBnm\fR have been compiled with plugin support.  At link time, use the the
+flag \fB\-fuse\-linker\-plugin\fR to ensure that the library participates in
+the \s-1LTO\s0 optimization process:
+.Sp
+.Vb 1
+\&        gcc \-o myprog \-O2 \-flto \-fuse\-linker\-plugin a.o b.o \-lfoo
+.Ve
+.Sp
+With the linker plugin enabled, the linker extracts the needed
+\&\s-1GIMPLE\s0 files from \fIlibfoo.a\fR and passes them on to the running \s-1GCC\s0
+to make them part of the aggregated \s-1GIMPLE\s0 image to be optimized.
+.Sp
+If you are not using a linker with plugin support and/or do not
+enable the linker plugin, then the objects inside \fIlibfoo.a\fR
+are extracted and linked as usual, but they do not participate
+in the \s-1LTO\s0 optimization process.  In order to make a static library suitable
+for both \s-1LTO\s0 optimization and usual linkage, compile its object files with
+\&\fB\-flto\fR \f(CW\*(C`\-ffat\-lto\-objects\*(C'\fR.
+.Sp
+Link-time optimizations do not require the presence of the whole program to
+operate.  If the program does not require any symbols to be exported, it is
+possible to combine \fB\-flto\fR and \fB\-fwhole\-program\fR to allow
+the interprocedural optimizers to use more aggressive assumptions which may
+lead to improved optimization opportunities.
+Use of \fB\-fwhole\-program\fR is not needed when linker plugin is
+active (see \fB\-fuse\-linker\-plugin\fR).
+.Sp
+The current implementation of \s-1LTO\s0 makes no
+attempt to generate bytecode that is portable between different
+types of hosts.  The bytecode files are versioned and there is a
+strict version check, so bytecode files generated in one version of
+\&\s-1GCC\s0 will not work with an older or newer version of \s-1GCC.\s0
+.Sp
+Link-time optimization does not work well with generation of debugging
+information.  Combining \fB\-flto\fR with
+\&\fB\-g\fR is currently experimental and expected to produce unexpected
+results.
+.Sp
+If you specify the optional \fIn\fR, the optimization and code
+generation done at link time is executed in parallel using \fIn\fR
+parallel jobs by utilizing an installed \fBmake\fR program.  The
+environment variable \fB\s-1MAKE\s0\fR may be used to override the program
+used.  The default value for \fIn\fR is 1.
+.Sp
+You can also specify \fB\-flto=jobserver\fR to use \s-1GNU\s0 make's
+job server mode to determine the number of parallel jobs. This
+is useful when the Makefile calling \s-1GCC\s0 is already executing in parallel.
+You must prepend a \fB+\fR to the command recipe in the parent Makefile
+for this to work.  This option likely only works if \fB\s-1MAKE\s0\fR is
+\&\s-1GNU\s0 make.
+.IP "\fB\-flto\-partition=\fR\fIalg\fR" 4
+.IX Item "-flto-partition=alg"
+Specify the partitioning algorithm used by the link-time optimizer.
+The value is either \f(CW\*(C`1to1\*(C'\fR to specify a partitioning mirroring
+the original source files or \f(CW\*(C`balanced\*(C'\fR to specify partitioning
+into equally sized chunks (whenever possible) or \f(CW\*(C`max\*(C'\fR to create
+new partition for every symbol where possible.  Specifying \f(CW\*(C`none\*(C'\fR
+as an algorithm disables partitioning and streaming completely. 
+The default value is \f(CW\*(C`balanced\*(C'\fR. While \f(CW\*(C`1to1\*(C'\fR can be used
+as an workaround for various code ordering issues, the \f(CW\*(C`max\*(C'\fR
+partitioning is intended for internal testing only.
+.IP "\fB\-flto\-compression\-level=\fR\fIn\fR" 4
+.IX Item "-flto-compression-level=n"
+This option specifies the level of compression used for intermediate
+language written to \s-1LTO\s0 object files, and is only meaningful in
+conjunction with \s-1LTO\s0 mode (\fB\-flto\fR).  Valid
+values are 0 (no compression) to 9 (maximum compression).  Values
+outside this range are clamped to either 0 or 9.  If the option is not
+given, a default balanced compression setting is used.
+.IP "\fB\-flto\-report\fR" 4
+.IX Item "-flto-report"
+Prints a report with internal details on the workings of the link-time
+optimizer.  The contents of this report vary from version to version.
+It is meant to be useful to \s-1GCC\s0 developers when processing object
+files in \s-1LTO\s0 mode (via \fB\-flto\fR).
+.Sp
+Disabled by default.
+.IP "\fB\-flto\-report\-wpa\fR" 4
+.IX Item "-flto-report-wpa"
+Like \fB\-flto\-report\fR, but only print for the \s-1WPA\s0 phase of Link
+Time Optimization.
+.IP "\fB\-fuse\-linker\-plugin\fR" 4
+.IX Item "-fuse-linker-plugin"
+Enables the use of a linker plugin during link-time optimization.  This
+option relies on plugin support in the linker, which is available in gold
+or in \s-1GNU\s0 ld 2.21 or newer.
+.Sp
+This option enables the extraction of object files with \s-1GIMPLE\s0 bytecode out
+of library archives. This improves the quality of optimization by exposing
+more code to the link-time optimizer.  This information specifies what
+symbols can be accessed externally (by non-LTO object or during dynamic
+linking).  Resulting code quality improvements on binaries (and shared
+libraries that use hidden visibility) are similar to \f(CW\*(C`\-fwhole\-program\*(C'\fR.
+See \fB\-flto\fR for a description of the effect of this flag and how to
+use it.
+.Sp
+This option is enabled by default when \s-1LTO\s0 support in \s-1GCC\s0 is enabled
+and \s-1GCC\s0 was configured for use with
+a linker supporting plugins (\s-1GNU\s0 ld 2.21 or newer or gold).
+.IP "\fB\-ffat\-lto\-objects\fR" 4
+.IX Item "-ffat-lto-objects"
+Fat \s-1LTO\s0 objects are object files that contain both the intermediate language
+and the object code. This makes them usable for both \s-1LTO\s0 linking and normal
+linking. This option is effective only when compiling with \fB\-flto\fR
+and is ignored at link time.
+.Sp
+\&\fB\-fno\-fat\-lto\-objects\fR improves compilation time over plain \s-1LTO,\s0 but
+requires the complete toolchain to be aware of \s-1LTO.\s0 It requires a linker with
+linker plugin support for basic functionality.  Additionally,
+\&\fBnm\fR, \fBar\fR and \fBranlib\fR
+need to support linker plugins to allow a full-featured build environment
+(capable of building static libraries etc).  \s-1GCC\s0 provides the \fBgcc-ar\fR,
+\&\fBgcc-nm\fR, \fBgcc-ranlib\fR wrappers to pass the right options
+to these tools. With non fat \s-1LTO\s0 makefiles need to be modified to use them.
+.Sp
+The default is \fB\-fno\-fat\-lto\-objects\fR on targets with linker plugin
+support.
+.IP "\fB\-fcompare\-elim\fR" 4
+.IX Item "-fcompare-elim"
+After register allocation and post-register allocation instruction splitting,
+identify arithmetic instructions that compute processor flags similar to a
+comparison operation based on that arithmetic.  If possible, eliminate the
+explicit comparison operation.
+.Sp
+This pass only applies to certain targets that cannot explicitly represent
+the comparison operation before register allocation is complete.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fuse\-ld=bfd\fR" 4
+.IX Item "-fuse-ld=bfd"
+Use the \fBbfd\fR linker instead of the default linker.
+.IP "\fB\-fuse\-ld=gold\fR" 4
+.IX Item "-fuse-ld=gold"
+Use the \fBgold\fR linker instead of the default linker.
+.IP "\fB\-fcprop\-registers\fR" 4
+.IX Item "-fcprop-registers"
+After register allocation and post-register allocation instruction splitting,
+perform a copy-propagation pass to try to reduce scheduling dependencies
+and occasionally eliminate the copy.
+.Sp
+Enabled at levels \fB\-O\fR, \fB\-O2\fR, \fB\-O3\fR, \fB\-Os\fR.
+.IP "\fB\-fprofile\-correction\fR" 4
+.IX Item "-fprofile-correction"
+Profiles collected using an instrumented binary for multi-threaded programs may
+be inconsistent due to missed counter updates. When this option is specified,
+\&\s-1GCC\s0 uses heuristics to correct or smooth out such inconsistencies. By
+default, \s-1GCC\s0 emits an error message when an inconsistent profile is detected.
+.IP "\fB\-fprofile\-dir=\fR\fIpath\fR" 4
+.IX Item "-fprofile-dir=path"
+Set the directory to search for the profile data files in to \fIpath\fR.
+This option affects only the profile data generated by
+\&\fB\-fprofile\-generate\fR, \fB\-ftest\-coverage\fR, \fB\-fprofile\-arcs\fR
+and used by \fB\-fprofile\-use\fR and \fB\-fbranch\-probabilities\fR
+and its related options.  Both absolute and relative paths can be used.
+By default, \s-1GCC\s0 uses the current directory as \fIpath\fR, thus the
+profile data file appears in the same directory as the object file.
+.IP "\fB\-fprofile\-generate\fR" 4
+.IX Item "-fprofile-generate"
+.PD 0
+.IP "\fB\-fprofile\-generate=\fR\fIpath\fR" 4
+.IX Item "-fprofile-generate=path"
+.PD
+Enable options usually used for instrumenting application to produce
+profile useful for later recompilation with profile feedback based
+optimization.  You must use \fB\-fprofile\-generate\fR both when
+compiling and when linking your program.
+.Sp
+The following options are enabled: \f(CW\*(C`\-fprofile\-arcs\*(C'\fR, \f(CW\*(C`\-fprofile\-values\*(C'\fR, \f(CW\*(C`\-fvpt\*(C'\fR.
+.Sp
+If \fIpath\fR is specified, \s-1GCC\s0 looks at the \fIpath\fR to find
+the profile feedback data files. See \fB\-fprofile\-dir\fR.
+.IP "\fB\-fprofile\-use\fR" 4
+.IX Item "-fprofile-use"
+.PD 0
+.IP "\fB\-fprofile\-use=\fR\fIpath\fR" 4
+.IX Item "-fprofile-use=path"
+.PD
+Enable profile feedback directed optimizations, and optimizations
+generally profitable only with profile feedback available.
+.Sp
+The following options are enabled: \f(CW\*(C`\-fbranch\-probabilities\*(C'\fR, \f(CW\*(C`\-fvpt\*(C'\fR,
+\&\f(CW\*(C`\-funroll\-loops\*(C'\fR, \f(CW\*(C`\-fpeel\-loops\*(C'\fR, \f(CW\*(C`\-ftracer\*(C'\fR, \f(CW\*(C`\-ftree\-vectorize\*(C'\fR,
+\&\f(CW\*(C`ftree\-loop\-distribute\-patterns\*(C'\fR
+.Sp
+By default, \s-1GCC\s0 emits an error message if the feedback profiles do not
+match the source code.  This error can be turned into a warning by using
+\&\fB\-Wcoverage\-mismatch\fR.  Note this may result in poorly optimized
+code.
+.Sp
+If \fIpath\fR is specified, \s-1GCC\s0 looks at the \fIpath\fR to find
+the profile feedback data files. See \fB\-fprofile\-dir\fR.
+.PP
+The following options control compiler behavior regarding floating-point 
+arithmetic.  These options trade off between speed and
+correctness.  All must be specifically enabled.
+.IP "\fB\-ffloat\-store\fR" 4
+.IX Item "-ffloat-store"
+Do not store floating-point variables in registers, and inhibit other
+options that might change whether a floating-point value is taken from a
+register or memory.
+.Sp
+This option prevents undesirable excess precision on machines such as
+the 68000 where the floating registers (of the 68881) keep more
+precision than a \f(CW\*(C`double\*(C'\fR is supposed to have.  Similarly for the
+x86 architecture.  For most programs, the excess precision does only
+good, but a few programs rely on the precise definition of \s-1IEEE\s0 floating
+point.  Use \fB\-ffloat\-store\fR for such programs, after modifying
+them to store all pertinent intermediate computations into variables.
+.IP "\fB\-fexcess\-precision=\fR\fIstyle\fR" 4
+.IX Item "-fexcess-precision=style"
+This option allows further control over excess precision on machines
+where floating-point registers have more precision than the \s-1IEEE
+\&\s0\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR types and the processor does not
+support operations rounding to those types.  By default,
+\&\fB\-fexcess\-precision=fast\fR is in effect; this means that
+operations are carried out in the precision of the registers and that
+it is unpredictable when rounding to the types specified in the source
+code takes place.  When compiling C, if
+\&\fB\-fexcess\-precision=standard\fR is specified then excess
+precision follows the rules specified in \s-1ISO C99\s0; in particular,
+both casts and assignments cause values to be rounded to their
+semantic types (whereas \fB\-ffloat\-store\fR only affects
+assignments).  This option is enabled by default for C if a strict
+conformance option such as \fB\-std=c99\fR is used.
+.Sp
+\&\fB\-fexcess\-precision=standard\fR is not implemented for languages
+other than C, and has no effect if
+\&\fB\-funsafe\-math\-optimizations\fR or \fB\-ffast\-math\fR is
+specified.  On the x86, it also has no effect if \fB\-mfpmath=sse\fR
+or \fB\-mfpmath=sse+387\fR is specified; in the former case, \s-1IEEE\s0
+semantics apply without excess precision, and in the latter, rounding
+is unpredictable.
+.IP "\fB\-ffast\-math\fR" 4
+.IX Item "-ffast-math"
+Sets \fB\-fno\-math\-errno\fR, \fB\-funsafe\-math\-optimizations\fR,
+\&\fB\-ffinite\-math\-only\fR, \fB\-fno\-rounding\-math\fR,
+\&\fB\-fno\-signaling\-nans\fR and \fB\-fcx\-limited\-range\fR.
+.Sp
+This option causes the preprocessor macro \f(CW\*(C`_\|_FAST_MATH_\|_\*(C'\fR to be defined.
+.Sp
+This option is not turned on by any \fB\-O\fR option besides
+\&\fB\-Ofast\fR since it can result in incorrect output for programs
+that depend on an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications
+for math functions. It may, however, yield faster code for programs
+that do not require the guarantees of these specifications.
+.IP "\fB\-fno\-math\-errno\fR" 4
+.IX Item "-fno-math-errno"
+Do not set \f(CW\*(C`errno\*(C'\fR after calling math functions that are executed
+with a single instruction, e.g., \f(CW\*(C`sqrt\*(C'\fR.  A program that relies on
+\&\s-1IEEE\s0 exceptions for math error handling may want to use this flag
+for speed while maintaining \s-1IEEE\s0 arithmetic compatibility.
+.Sp
+This option is not turned on by any \fB\-O\fR option since
+it can result in incorrect output for programs that depend on
+an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
+math functions. It may, however, yield faster code for programs
+that do not require the guarantees of these specifications.
+.Sp
+The default is \fB\-fmath\-errno\fR.
+.Sp
+On Darwin systems, the math library never sets \f(CW\*(C`errno\*(C'\fR.  There is
+therefore no reason for the compiler to consider the possibility that
+it might, and \fB\-fno\-math\-errno\fR is the default.
+.IP "\fB\-funsafe\-math\-optimizations\fR" 4
+.IX Item "-funsafe-math-optimizations"
+Allow optimizations for floating-point arithmetic that (a) assume
+that arguments and results are valid and (b) may violate \s-1IEEE\s0 or
+\&\s-1ANSI\s0 standards.  When used at link-time, it may include libraries
+or startup files that change the default \s-1FPU\s0 control word or other
+similar optimizations.
+.Sp
+This option is not turned on by any \fB\-O\fR option since
+it can result in incorrect output for programs that depend on
+an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
+math functions. It may, however, yield faster code for programs
+that do not require the guarantees of these specifications.
+Enables \fB\-fno\-signed\-zeros\fR, \fB\-fno\-trapping\-math\fR,
+\&\fB\-fassociative\-math\fR and \fB\-freciprocal\-math\fR.
+.Sp
+The default is \fB\-fno\-unsafe\-math\-optimizations\fR.
+.IP "\fB\-fassociative\-math\fR" 4
+.IX Item "-fassociative-math"
+Allow re-association of operands in series of floating-point operations.
+This violates the \s-1ISO C\s0 and \*(C+ language standard by possibly changing
+computation result.  \s-1NOTE:\s0 re-ordering may change the sign of zero as
+well as ignore NaNs and inhibit or create underflow or overflow (and
+thus cannot be used on code that relies on rounding behavior like
+\&\f(CW\*(C`(x + 2**52) \- 2**52\*(C'\fR.  May also reorder floating-point comparisons
+and thus may not be used when ordered comparisons are required.
+This option requires that both \fB\-fno\-signed\-zeros\fR and
+\&\fB\-fno\-trapping\-math\fR be in effect.  Moreover, it doesn't make
+much sense with \fB\-frounding\-math\fR. For Fortran the option
+is automatically enabled when both \fB\-fno\-signed\-zeros\fR and
+\&\fB\-fno\-trapping\-math\fR are in effect.
+.Sp
+The default is \fB\-fno\-associative\-math\fR.
+.IP "\fB\-freciprocal\-math\fR" 4
+.IX Item "-freciprocal-math"
+Allow the reciprocal of a value to be used instead of dividing by
+the value if this enables optimizations.  For example \f(CW\*(C`x / y\*(C'\fR
+can be replaced with \f(CW\*(C`x * (1/y)\*(C'\fR, which is useful if \f(CW\*(C`(1/y)\*(C'\fR
+is subject to common subexpression elimination.  Note that this loses
+precision and increases the number of flops operating on the value.
+.Sp
+The default is \fB\-fno\-reciprocal\-math\fR.
+.IP "\fB\-ffinite\-math\-only\fR" 4
+.IX Item "-ffinite-math-only"
+Allow optimizations for floating-point arithmetic that assume
+that arguments and results are not NaNs or +\-Infs.
+.Sp
+This option is not turned on by any \fB\-O\fR option since
+it can result in incorrect output for programs that depend on
+an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
+math functions. It may, however, yield faster code for programs
+that do not require the guarantees of these specifications.
+.Sp
+The default is \fB\-fno\-finite\-math\-only\fR.
+.IP "\fB\-fno\-signed\-zeros\fR" 4
+.IX Item "-fno-signed-zeros"
+Allow optimizations for floating-point arithmetic that ignore the
+signedness of zero.  \s-1IEEE\s0 arithmetic specifies the behavior of
+distinct +0.0 and \-0.0 values, which then prohibits simplification
+of expressions such as x+0.0 or 0.0*x (even with \fB\-ffinite\-math\-only\fR).
+This option implies that the sign of a zero result isn't significant.
+.Sp
+The default is \fB\-fsigned\-zeros\fR.
+.IP "\fB\-fno\-trapping\-math\fR" 4
+.IX Item "-fno-trapping-math"
+Compile code assuming that floating-point operations cannot generate
+user-visible traps.  These traps include division by zero, overflow,
+underflow, inexact result and invalid operation.  This option requires
+that \fB\-fno\-signaling\-nans\fR be in effect.  Setting this option may
+allow faster code if one relies on \*(L"non-stop\*(R" \s-1IEEE\s0 arithmetic, for example.
+.Sp
+This option should never be turned on by any \fB\-O\fR option since
+it can result in incorrect output for programs that depend on
+an exact implementation of \s-1IEEE\s0 or \s-1ISO\s0 rules/specifications for
+math functions.
+.Sp
+The default is \fB\-ftrapping\-math\fR.
+.IP "\fB\-frounding\-math\fR" 4
+.IX Item "-frounding-math"
+Disable transformations and optimizations that assume default floating-point
+rounding behavior.  This is round-to-zero for all floating point
+to integer conversions, and round-to-nearest for all other arithmetic
+truncations.  This option should be specified for programs that change
+the \s-1FP\s0 rounding mode dynamically, or that may be executed with a
+non-default rounding mode.  This option disables constant folding of
+floating-point expressions at compile time (which may be affected by
+rounding mode) and arithmetic transformations that are unsafe in the
+presence of sign-dependent rounding modes.
+.Sp
+The default is \fB\-fno\-rounding\-math\fR.
+.Sp
+This option is experimental and does not currently guarantee to
+disable all \s-1GCC\s0 optimizations that are affected by rounding mode.
+Future versions of \s-1GCC\s0 may provide finer control of this setting
+using C99's \f(CW\*(C`FENV_ACCESS\*(C'\fR pragma.  This command-line option
+will be used to specify the default state for \f(CW\*(C`FENV_ACCESS\*(C'\fR.
+.IP "\fB\-fsignaling\-nans\fR" 4
+.IX Item "-fsignaling-nans"
+Compile code assuming that \s-1IEEE\s0 signaling NaNs may generate user-visible
+traps during floating-point operations.  Setting this option disables
+optimizations that may change the number of exceptions visible with
+signaling NaNs.  This option implies \fB\-ftrapping\-math\fR.
+.Sp
+This option causes the preprocessor macro \f(CW\*(C`_\|_SUPPORT_SNAN_\|_\*(C'\fR to
+be defined.
+.Sp
+The default is \fB\-fno\-signaling\-nans\fR.
+.Sp
+This option is experimental and does not currently guarantee to
+disable all \s-1GCC\s0 optimizations that affect signaling NaN behavior.
+.IP "\fB\-fsingle\-precision\-constant\fR" 4
+.IX Item "-fsingle-precision-constant"
+Treat floating-point constants as single precision instead of
+implicitly converting them to double-precision constants.
+.IP "\fB\-fcx\-limited\-range\fR" 4
+.IX Item "-fcx-limited-range"
+When enabled, this option states that a range reduction step is not
+needed when performing complex division.  Also, there is no checking
+whether the result of a complex multiplication or division is \f(CW\*(C`NaN
++ I*NaN\*(C'\fR, with an attempt to rescue the situation in that case.  The
+default is \fB\-fno\-cx\-limited\-range\fR, but is enabled by
+\&\fB\-ffast\-math\fR.
+.Sp
+This option controls the default setting of the \s-1ISO C99
+\&\s0\f(CW\*(C`CX_LIMITED_RANGE\*(C'\fR pragma.  Nevertheless, the option applies to
+all languages.
+.IP "\fB\-fcx\-fortran\-rules\fR" 4
+.IX Item "-fcx-fortran-rules"
+Complex multiplication and division follow Fortran rules.  Range
+reduction is done as part of complex division, but there is no checking
+whether the result of a complex multiplication or division is \f(CW\*(C`NaN
++ I*NaN\*(C'\fR, with an attempt to rescue the situation in that case.
+.Sp
+The default is \fB\-fno\-cx\-fortran\-rules\fR.
+.PP
+The following options control optimizations that may improve
+performance, but are not enabled by any \fB\-O\fR options.  This
+section includes experimental options that may produce broken code.
+.IP "\fB\-fbranch\-probabilities\fR" 4
+.IX Item "-fbranch-probabilities"
+After running a program compiled with \fB\-fprofile\-arcs\fR, you can compile it a second time using
+\&\fB\-fbranch\-probabilities\fR, to improve optimizations based on
+the number of times each branch was taken.  When a program
+compiled with \fB\-fprofile\-arcs\fR exits, it saves arc execution
+counts to a file called \fI\fIsourcename\fI.gcda\fR for each source
+file.  The information in this data file is very dependent on the
+structure of the generated code, so you must use the same source code
+and the same optimization options for both compilations.
+.Sp
+With \fB\-fbranch\-probabilities\fR, \s-1GCC\s0 puts a
+\&\fB\s-1REG_BR_PROB\s0\fR note on each \fB\s-1JUMP_INSN\s0\fR and \fB\s-1CALL_INSN\s0\fR.
+These can be used to improve optimization.  Currently, they are only
+used in one place: in \fIreorg.c\fR, instead of guessing which path a
+branch is most likely to take, the \fB\s-1REG_BR_PROB\s0\fR values are used to
+exactly determine which path is taken more often.
+.IP "\fB\-fprofile\-values\fR" 4
+.IX Item "-fprofile-values"
+If combined with \fB\-fprofile\-arcs\fR, it adds code so that some
+data about values of expressions in the program is gathered.
+.Sp
+With \fB\-fbranch\-probabilities\fR, it reads back the data gathered
+from profiling values of expressions for usage in optimizations.
+.Sp
+Enabled with \fB\-fprofile\-generate\fR and \fB\-fprofile\-use\fR.
+.IP "\fB\-fprofile\-reorder\-functions\fR" 4
+.IX Item "-fprofile-reorder-functions"
+Function reordering based on profile instrumentation collects
+first time of execution of a function and orders these functions
+in ascending order.
+.Sp
+Enabled with \fB\-fprofile\-use\fR.
+.IP "\fB\-fvpt\fR" 4
+.IX Item "-fvpt"
+If combined with \fB\-fprofile\-arcs\fR, this option instructs the compiler
+to add code to gather information about values of expressions.
+.Sp
+With \fB\-fbranch\-probabilities\fR, it reads back the data gathered
+and actually performs the optimizations based on them.
+Currently the optimizations include specialization of division operations
+using the knowledge about the value of the denominator.
+.IP "\fB\-frename\-registers\fR" 4
+.IX Item "-frename-registers"
+Attempt to avoid false dependencies in scheduled code by making use
+of registers left over after register allocation.  This optimization
+most benefits processors with lots of registers.  Depending on the
+debug information format adopted by the target, however, it can
+make debugging impossible, since variables no longer stay in
+a \*(L"home register\*(R".
+.Sp
+Enabled by default with \fB\-funroll\-loops\fR and \fB\-fpeel\-loops\fR.
+.IP "\fB\-ftracer\fR" 4
+.IX Item "-ftracer"
+Perform tail duplication to enlarge superblock size.  This transformation
+simplifies the control flow of the function allowing other optimizations to do
+a better job.
+.Sp
+Enabled with \fB\-fprofile\-use\fR.
+.IP "\fB\-funroll\-loops\fR" 4
+.IX Item "-funroll-loops"
+Unroll loops whose number of iterations can be determined at compile time or
+upon entry to the loop.  \fB\-funroll\-loops\fR implies
+\&\fB\-frerun\-cse\-after\-loop\fR, \fB\-fweb\fR and \fB\-frename\-registers\fR.
+It also turns on complete loop peeling (i.e. complete removal of loops with
+a small constant number of iterations).  This option makes code larger, and may
+or may not make it run faster.
+.Sp
+Enabled with \fB\-fprofile\-use\fR.
+.IP "\fB\-funroll\-all\-loops\fR" 4
+.IX Item "-funroll-all-loops"
+Unroll all loops, even if their number of iterations is uncertain when
+the loop is entered.  This usually makes programs run more slowly.
+\&\fB\-funroll\-all\-loops\fR implies the same options as
+\&\fB\-funroll\-loops\fR.
+.IP "\fB\-fpeel\-loops\fR" 4
+.IX Item "-fpeel-loops"
+Peels loops for which there is enough information that they do not
+roll much (from profile feedback).  It also turns on complete loop peeling
+(i.e. complete removal of loops with small constant number of iterations).
+.Sp
+Enabled with \fB\-fprofile\-use\fR.
+.IP "\fB\-fmove\-loop\-invariants\fR" 4
+.IX Item "-fmove-loop-invariants"
+Enables the loop invariant motion pass in the \s-1RTL\s0 loop optimizer.  Enabled
+at level \fB\-O1\fR
+.IP "\fB\-funswitch\-loops\fR" 4
+.IX Item "-funswitch-loops"
+Move branches with loop invariant conditions out of the loop, with duplicates
+of the loop on both branches (modified according to result of the condition).
+.IP "\fB\-ffunction\-sections\fR" 4
+.IX Item "-ffunction-sections"
+.PD 0
+.IP "\fB\-fdata\-sections\fR" 4
+.IX Item "-fdata-sections"
+.PD
+Place each function or data item into its own section in the output
+file if the target supports arbitrary sections.  The name of the
+function or the name of the data item determines the section's name
+in the output file.
+.Sp
+Use these options on systems where the linker can perform optimizations
+to improve locality of reference in the instruction space.  Most systems
+using the \s-1ELF\s0 object format and \s-1SPARC\s0 processors running Solaris 2 have
+linkers with such optimizations.  \s-1AIX\s0 may have these optimizations in
+the future.
+.Sp
+Only use these options when there are significant benefits from doing
+so.  When you specify these options, the assembler and linker
+create larger object and executable files and are also slower.
+You cannot use \f(CW\*(C`gprof\*(C'\fR on all systems if you
+specify this option, and you may have problems with debugging if
+you specify both this option and \fB\-g\fR.
+.IP "\fB\-fbranch\-target\-load\-optimize\fR" 4
+.IX Item "-fbranch-target-load-optimize"
+Perform branch target register load optimization before prologue / epilogue
+threading.
+The use of target registers can typically be exposed only during reload,
+thus hoisting loads out of loops and doing inter-block scheduling needs
+a separate optimization pass.
+.IP "\fB\-fbranch\-target\-load\-optimize2\fR" 4
+.IX Item "-fbranch-target-load-optimize2"
+Perform branch target register load optimization after prologue / epilogue
+threading.
+.IP "\fB\-fbtr\-bb\-exclusive\fR" 4
+.IX Item "-fbtr-bb-exclusive"
+When performing branch target register load optimization, don't reuse
+branch target registers within any basic block.
+.IP "\fB\-fstack\-protector\fR" 4
+.IX Item "-fstack-protector"
+Emit extra code to check for buffer overflows, such as stack smashing
+attacks.  This is done by adding a guard variable to functions with
+vulnerable objects.  This includes functions that call \f(CW\*(C`alloca\*(C'\fR, and
+functions with buffers larger than 8 bytes.  The guards are initialized
+when a function is entered and then checked when the function exits.
+If a guard check fails, an error message is printed and the program exits.
+.IP "\fB\-fstack\-protector\-all\fR" 4
+.IX Item "-fstack-protector-all"
+Like \fB\-fstack\-protector\fR except that all functions are protected.
+.IP "\fB\-fstack\-protector\-strong\fR" 4
+.IX Item "-fstack-protector-strong"
+Like \fB\-fstack\-protector\fR but includes additional functions to
+be protected \-\-\- those that have local array definitions, or have
+references to local frame addresses.
+.IP "\fB\-fsection\-anchors\fR" 4
+.IX Item "-fsection-anchors"
+Try to reduce the number of symbolic address calculations by using
+shared \*(L"anchor\*(R" symbols to address nearby objects.  This transformation
+can help to reduce the number of \s-1GOT\s0 entries and \s-1GOT\s0 accesses on some
+targets.
+.Sp
+For example, the implementation of the following function \f(CW\*(C`foo\*(C'\fR:
+.Sp
+.Vb 2
+\&        static int a, b, c;
+\&        int foo (void) { return a + b + c; }
+.Ve
+.Sp
+usually calculates the addresses of all three variables, but if you
+compile it with \fB\-fsection\-anchors\fR, it accesses the variables
+from a common anchor point instead.  The effect is similar to the
+following pseudocode (which isn't valid C):
+.Sp
+.Vb 5
+\&        int foo (void)
+\&        {
+\&          register int *xr = &x;
+\&          return xr[&a \- &x] + xr[&b \- &x] + xr[&c \- &x];
+\&        }
+.Ve
+.Sp
+Not all targets support this option.
+.IP "\fB\-\-param\fR \fIname\fR\fB=\fR\fIvalue\fR" 4
+.IX Item "--param name=value"
+In some places, \s-1GCC\s0 uses various constants to control the amount of
+optimization that is done.  For example, \s-1GCC\s0 does not inline functions
+that contain more than a certain number of instructions.  You can
+control some of these constants on the command line using the
+\&\fB\-\-param\fR option.
+.Sp
+The names of specific parameters, and the meaning of the values, are
+tied to the internals of the compiler, and are subject to change
+without notice in future releases.
+.Sp
+In each case, the \fIvalue\fR is an integer.  The allowable choices for
+\&\fIname\fR are:
+.RS 4
+.IP "\fBpredictable-branch-outcome\fR" 4
+.IX Item "predictable-branch-outcome"
+When branch is predicted to be taken with probability lower than this threshold
+(in percent), then it is considered well predictable. The default is 10.
+.IP "\fBmax-crossjump-edges\fR" 4
+.IX Item "max-crossjump-edges"
+The maximum number of incoming edges to consider for cross-jumping.
+The algorithm used by \fB\-fcrossjumping\fR is O(N^2) in
+the number of edges incoming to each block.  Increasing values mean
+more aggressive optimization, making the compilation time increase with
+probably small improvement in executable size.
+.IP "\fBmin-crossjump-insns\fR" 4
+.IX Item "min-crossjump-insns"
+The minimum number of instructions that must be matched at the end
+of two blocks before cross-jumping is performed on them.  This
+value is ignored in the case where all instructions in the block being
+cross-jumped from are matched.  The default value is 5.
+.IP "\fBmax-grow-copy-bb-insns\fR" 4
+.IX Item "max-grow-copy-bb-insns"
+The maximum code size expansion factor when copying basic blocks
+instead of jumping.  The expansion is relative to a jump instruction.
+The default value is 8.
+.IP "\fBmax-goto-duplication-insns\fR" 4
+.IX Item "max-goto-duplication-insns"
+The maximum number of instructions to duplicate to a block that jumps
+to a computed goto.  To avoid O(N^2) behavior in a number of
+passes, \s-1GCC\s0 factors computed gotos early in the compilation process,
+and unfactors them as late as possible.  Only computed jumps at the
+end of a basic blocks with no more than max-goto-duplication-insns are
+unfactored.  The default value is 8.
+.IP "\fBmax-delay-slot-insn-search\fR" 4
+.IX Item "max-delay-slot-insn-search"
+The maximum number of instructions to consider when looking for an
+instruction to fill a delay slot.  If more than this arbitrary number of
+instructions are searched, the time savings from filling the delay slot
+are minimal, so stop searching.  Increasing values mean more
+aggressive optimization, making the compilation time increase with probably
+small improvement in execution time.
+.IP "\fBmax-delay-slot-live-search\fR" 4
+.IX Item "max-delay-slot-live-search"
+When trying to fill delay slots, the maximum number of instructions to
+consider when searching for a block with valid live register
+information.  Increasing this arbitrarily chosen value means more
+aggressive optimization, increasing the compilation time.  This parameter
+should be removed when the delay slot code is rewritten to maintain the
+control-flow graph.
+.IP "\fBmax-gcse-memory\fR" 4
+.IX Item "max-gcse-memory"
+The approximate maximum amount of memory that can be allocated in
+order to perform the global common subexpression elimination
+optimization.  If more memory than specified is required, the
+optimization is not done.
+.IP "\fBmax-gcse-insertion-ratio\fR" 4
+.IX Item "max-gcse-insertion-ratio"
+If the ratio of expression insertions to deletions is larger than this value
+for any expression, then \s-1RTL PRE\s0 inserts or removes the expression and thus
+leaves partially redundant computations in the instruction stream.  The default value is 20.
+.IP "\fBmax-pending-list-length\fR" 4
+.IX Item "max-pending-list-length"
+The maximum number of pending dependencies scheduling allows
+before flushing the current state and starting over.  Large functions
+with few branches or calls can create excessively large lists which
+needlessly consume memory and resources.
+.IP "\fBmax-modulo-backtrack-attempts\fR" 4
+.IX Item "max-modulo-backtrack-attempts"
+The maximum number of backtrack attempts the scheduler should make
+when modulo scheduling a loop.  Larger values can exponentially increase
+compilation time.
+.IP "\fBmax-inline-insns-single\fR" 4
+.IX Item "max-inline-insns-single"
+Several parameters control the tree inliner used in \s-1GCC.\s0
+This number sets the maximum number of instructions (counted in \s-1GCC\s0's
+internal representation) in a single function that the tree inliner
+considers for inlining.  This only affects functions declared
+inline and methods implemented in a class declaration (\*(C+).
+The default value is 400.
+.IP "\fBmax-inline-insns-auto\fR" 4
+.IX Item "max-inline-insns-auto"
+When you use \fB\-finline\-functions\fR (included in \fB\-O3\fR),
+a lot of functions that would otherwise not be considered for inlining
+by the compiler are investigated.  To those functions, a different
+(more restrictive) limit compared to functions declared inline can
+be applied.
+The default value is 40.
+.IP "\fBinline-min-speedup\fR" 4
+.IX Item "inline-min-speedup"
+When estimated performance improvement of caller + callee runtime exceeds this
+threshold (in precent), the function can be inlined regardless the limit on
+\&\fB\-\-param max-inline-insns-single\fR and \fB\-\-param
+max-inline-insns-auto\fR.
+.IP "\fBlarge-function-insns\fR" 4
+.IX Item "large-function-insns"
+The limit specifying really large functions.  For functions larger than this
+limit after inlining, inlining is constrained by
+\&\fB\-\-param large-function-growth\fR.  This parameter is useful primarily
+to avoid extreme compilation time caused by non-linear algorithms used by the
+back end.
+The default value is 2700.
+.IP "\fBlarge-function-growth\fR" 4
+.IX Item "large-function-growth"
+Specifies maximal growth of large function caused by inlining in percents.
+The default value is 100 which limits large function growth to 2.0 times
+the original size.
+.IP "\fBlarge-unit-insns\fR" 4
+.IX Item "large-unit-insns"
+The limit specifying large translation unit.  Growth caused by inlining of
+units larger than this limit is limited by \fB\-\-param inline-unit-growth\fR.
+For small units this might be too tight.
+For example, consider a unit consisting of function A
+that is inline and B that just calls A three times.  If B is small relative to
+A, the growth of unit is 300\e% and yet such inlining is very sane.  For very
+large units consisting of small inlineable functions, however, the overall unit
+growth limit is needed to avoid exponential explosion of code size.  Thus for
+smaller units, the size is increased to \fB\-\-param large-unit-insns\fR
+before applying \fB\-\-param inline-unit-growth\fR.  The default is 10000.
+.IP "\fBinline-unit-growth\fR" 4
+.IX Item "inline-unit-growth"
+Specifies maximal overall growth of the compilation unit caused by inlining.
+The default value is 30 which limits unit growth to 1.3 times the original
+size.
+.IP "\fBipcp-unit-growth\fR" 4
+.IX Item "ipcp-unit-growth"
+Specifies maximal overall growth of the compilation unit caused by
+interprocedural constant propagation.  The default value is 10 which limits
+unit growth to 1.1 times the original size.
+.IP "\fBlarge-stack-frame\fR" 4
+.IX Item "large-stack-frame"
+The limit specifying large stack frames.  While inlining the algorithm is trying
+to not grow past this limit too much.  The default value is 256 bytes.
+.IP "\fBlarge-stack-frame-growth\fR" 4
+.IX Item "large-stack-frame-growth"
+Specifies maximal growth of large stack frames caused by inlining in percents.
+The default value is 1000 which limits large stack frame growth to 11 times
+the original size.
+.IP "\fBmax-inline-insns-recursive\fR" 4
+.IX Item "max-inline-insns-recursive"
+.PD 0
+.IP "\fBmax-inline-insns-recursive-auto\fR" 4
+.IX Item "max-inline-insns-recursive-auto"
+.PD
+Specifies the maximum number of instructions an out-of-line copy of a
+self-recursive inline
+function can grow into by performing recursive inlining.
+.Sp
+For functions declared inline, \fB\-\-param max-inline-insns-recursive\fR is
+taken into account.  For functions not declared inline, recursive inlining
+happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
+enabled and \fB\-\-param max-inline-insns-recursive-auto\fR is used.  The
+default value is 450.
+.IP "\fBmax-inline-recursive-depth\fR" 4
+.IX Item "max-inline-recursive-depth"
+.PD 0
+.IP "\fBmax-inline-recursive-depth-auto\fR" 4
+.IX Item "max-inline-recursive-depth-auto"
+.PD
+Specifies the maximum recursion depth used for recursive inlining.
+.Sp
+For functions declared inline, \fB\-\-param max-inline-recursive-depth\fR is
+taken into account.  For functions not declared inline, recursive inlining
+happens only when \fB\-finline\-functions\fR (included in \fB\-O3\fR) is
+enabled and \fB\-\-param max-inline-recursive-depth-auto\fR is used.  The
+default value is 8.
+.IP "\fBmin-inline-recursive-probability\fR" 4
+.IX Item "min-inline-recursive-probability"
+Recursive inlining is profitable only for function having deep recursion
+in average and can hurt for function having little recursion depth by
+increasing the prologue size or complexity of function body to other
+optimizers.
+.Sp
+When profile feedback is available (see \fB\-fprofile\-generate\fR) the actual
+recursion depth can be guessed from probability that function recurses via a
+given call expression.  This parameter limits inlining only to call expressions
+whose probability exceeds the given threshold (in percents).
+The default value is 10.
+.IP "\fBearly-inlining-insns\fR" 4
+.IX Item "early-inlining-insns"
+Specify growth that the early inliner can make.  In effect it increases
+the amount of inlining for code having a large abstraction penalty.
+The default value is 10.
+.IP "\fBmax-early-inliner-iterations\fR" 4
+.IX Item "max-early-inliner-iterations"
+.PD 0
+.IP "\fBmax-early-inliner-iterations\fR" 4
+.IX Item "max-early-inliner-iterations"
+.PD
+Limit of iterations of the early inliner.  This basically bounds
+the number of nested indirect calls the early inliner can resolve.
+Deeper chains are still handled by late inlining.
+.IP "\fBcomdat-sharing-probability\fR" 4
+.IX Item "comdat-sharing-probability"
+.PD 0
+.IP "\fBcomdat-sharing-probability\fR" 4
+.IX Item "comdat-sharing-probability"
+.PD
+Probability (in percent) that \*(C+ inline function with comdat visibility
+are shared across multiple compilation units.  The default value is 20.
+.IP "\fBmin-vect-loop-bound\fR" 4
+.IX Item "min-vect-loop-bound"
+The minimum number of iterations under which loops are not vectorized
+when \fB\-ftree\-vectorize\fR is used.  The number of iterations after
+vectorization needs to be greater than the value specified by this option
+to allow vectorization.  The default value is 0.
+.IP "\fBgcse-cost-distance-ratio\fR" 4
+.IX Item "gcse-cost-distance-ratio"
+Scaling factor in calculation of maximum distance an expression
+can be moved by \s-1GCSE\s0 optimizations.  This is currently supported only in the
+code hoisting pass.  The bigger the ratio, the more aggressive code hoisting
+is with simple expressions, i.e., the expressions that have cost
+less than \fBgcse-unrestricted-cost\fR.  Specifying 0 disables
+hoisting of simple expressions.  The default value is 10.
+.IP "\fBgcse-unrestricted-cost\fR" 4
+.IX Item "gcse-unrestricted-cost"
+Cost, roughly measured as the cost of a single typical machine
+instruction, at which \s-1GCSE\s0 optimizations do not constrain
+the distance an expression can travel.  This is currently
+supported only in the code hoisting pass.  The lesser the cost,
+the more aggressive code hoisting is.  Specifying 0 
+allows all expressions to travel unrestricted distances.
+The default value is 3.
+.IP "\fBmax-hoist-depth\fR" 4
+.IX Item "max-hoist-depth"
+The depth of search in the dominator tree for expressions to hoist.
+This is used to avoid quadratic behavior in hoisting algorithm.
+The value of 0 does not limit on the search, but may slow down compilation
+of huge functions.  The default value is 30.
+.IP "\fBmax-tail-merge-comparisons\fR" 4
+.IX Item "max-tail-merge-comparisons"
+The maximum amount of similar bbs to compare a bb with.  This is used to
+avoid quadratic behavior in tree tail merging.  The default value is 10.
+.IP "\fBmax-tail-merge-iterations\fR" 4
+.IX Item "max-tail-merge-iterations"
+The maximum amount of iterations of the pass over the function.  This is used to
+limit compilation time in tree tail merging.  The default value is 2.
+.IP "\fBmax-unrolled-insns\fR" 4
+.IX Item "max-unrolled-insns"
+The maximum number of instructions that a loop may have to be unrolled.
+If a loop is unrolled, this parameter also determines how many times
+the loop code is unrolled.
+.IP "\fBmax-average-unrolled-insns\fR" 4
+.IX Item "max-average-unrolled-insns"
+The maximum number of instructions biased by probabilities of their execution
+that a loop may have to be unrolled.  If a loop is unrolled,
+this parameter also determines how many times the loop code is unrolled.
+.IP "\fBmax-unroll-times\fR" 4
+.IX Item "max-unroll-times"
+The maximum number of unrollings of a single loop.
+.IP "\fBmax-peeled-insns\fR" 4
+.IX Item "max-peeled-insns"
+The maximum number of instructions that a loop may have to be peeled.
+If a loop is peeled, this parameter also determines how many times
+the loop code is peeled.
+.IP "\fBmax-peel-times\fR" 4
+.IX Item "max-peel-times"
+The maximum number of peelings of a single loop.
+.IP "\fBmax-peel-branches\fR" 4
+.IX Item "max-peel-branches"
+The maximum number of branches on the hot path through the peeled sequence.
+.IP "\fBmax-completely-peeled-insns\fR" 4
+.IX Item "max-completely-peeled-insns"
+The maximum number of insns of a completely peeled loop.
+.IP "\fBmax-completely-peel-times\fR" 4
+.IX Item "max-completely-peel-times"
+The maximum number of iterations of a loop to be suitable for complete peeling.
+.IP "\fBmax-completely-peel-loop-nest-depth\fR" 4
+.IX Item "max-completely-peel-loop-nest-depth"
+The maximum depth of a loop nest suitable for complete peeling.
+.IP "\fBmax-unswitch-insns\fR" 4
+.IX Item "max-unswitch-insns"
+The maximum number of insns of an unswitched loop.
+.IP "\fBmax-unswitch-level\fR" 4
+.IX Item "max-unswitch-level"
+The maximum number of branches unswitched in a single loop.
+.IP "\fBlim-expensive\fR" 4
+.IX Item "lim-expensive"
+The minimum cost of an expensive expression in the loop invariant motion.
+.IP "\fBiv-consider-all-candidates-bound\fR" 4
+.IX Item "iv-consider-all-candidates-bound"
+Bound on number of candidates for induction variables, below which
+all candidates are considered for each use in induction variable
+optimizations.  If there are more candidates than this,
+only the most relevant ones are considered to avoid quadratic time complexity.
+.IP "\fBiv-max-considered-uses\fR" 4
+.IX Item "iv-max-considered-uses"
+The induction variable optimizations give up on loops that contain more
+induction variable uses.
+.IP "\fBiv-always-prune-cand-set-bound\fR" 4
+.IX Item "iv-always-prune-cand-set-bound"
+If the number of candidates in the set is smaller than this value,
+always try to remove unnecessary ivs from the set
+when adding a new one.
+.IP "\fBscev-max-expr-size\fR" 4
+.IX Item "scev-max-expr-size"
+Bound on size of expressions used in the scalar evolutions analyzer.
+Large expressions slow the analyzer.
+.IP "\fBscev-max-expr-complexity\fR" 4
+.IX Item "scev-max-expr-complexity"
+Bound on the complexity of the expressions in the scalar evolutions analyzer.
+Complex expressions slow the analyzer.
+.IP "\fBomega-max-vars\fR" 4
+.IX Item "omega-max-vars"
+The maximum number of variables in an Omega constraint system.
+The default value is 128.
+.IP "\fBomega-max-geqs\fR" 4
+.IX Item "omega-max-geqs"
+The maximum number of inequalities in an Omega constraint system.
+The default value is 256.
+.IP "\fBomega-max-eqs\fR" 4
+.IX Item "omega-max-eqs"
+The maximum number of equalities in an Omega constraint system.
+The default value is 128.
+.IP "\fBomega-max-wild-cards\fR" 4
+.IX Item "omega-max-wild-cards"
+The maximum number of wildcard variables that the Omega solver is
+able to insert.  The default value is 18.
+.IP "\fBomega-hash-table-size\fR" 4
+.IX Item "omega-hash-table-size"
+The size of the hash table in the Omega solver.  The default value is
+550.
+.IP "\fBomega-max-keys\fR" 4
+.IX Item "omega-max-keys"
+The maximal number of keys used by the Omega solver.  The default
+value is 500.
+.IP "\fBomega-eliminate-redundant-constraints\fR" 4
+.IX Item "omega-eliminate-redundant-constraints"
+When set to 1, use expensive methods to eliminate all redundant
+constraints.  The default value is 0.
+.IP "\fBvect-max-version-for-alignment-checks\fR" 4
+.IX Item "vect-max-version-for-alignment-checks"
+The maximum number of run-time checks that can be performed when
+doing loop versioning for alignment in the vectorizer.
+.IP "\fBvect-max-version-for-alias-checks\fR" 4
+.IX Item "vect-max-version-for-alias-checks"
+The maximum number of run-time checks that can be performed when
+doing loop versioning for alias in the vectorizer.
+.IP "\fBvect-max-peeling-for-alignment\fR" 4
+.IX Item "vect-max-peeling-for-alignment"
+The maximum number of loop peels to enhance access alignment
+for vectorizer. Value \-1 means 'no limit'.
+.IP "\fBmax-iterations-to-track\fR" 4
+.IX Item "max-iterations-to-track"
+The maximum number of iterations of a loop the brute-force algorithm
+for analysis of the number of iterations of the loop tries to evaluate.
+.IP "\fBhot-bb-count-ws-permille\fR" 4
+.IX Item "hot-bb-count-ws-permille"
+A basic block profile count is considered hot if it contributes to 
+the given permillage (i.e. 0...1000) of the entire profiled execution.
+.IP "\fBhot-bb-frequency-fraction\fR" 4
+.IX Item "hot-bb-frequency-fraction"
+Select fraction of the entry block frequency of executions of basic block in
+function given basic block needs to have to be considered hot.
+.IP "\fBmax-predicted-iterations\fR" 4
+.IX Item "max-predicted-iterations"
+The maximum number of loop iterations we predict statically.  This is useful
+in cases where a function contains a single loop with known bound and
+another loop with unknown bound.
+The known number of iterations is predicted correctly, while
+the unknown number of iterations average to roughly 10.  This means that the
+loop without bounds appears artificially cold relative to the other one.
+.IP "\fBbuiltin-expect-probability\fR" 4
+.IX Item "builtin-expect-probability"
+Control the probability of the expression having the specified value. This
+parameter takes a percentage (i.e. 0 ... 100) as input.
+The default probability of 90 is obtained empirically.
+.IP "\fBalign-threshold\fR" 4
+.IX Item "align-threshold"
+Select fraction of the maximal frequency of executions of a basic block in
+a function to align the basic block.
+.IP "\fBalign-loop-iterations\fR" 4
+.IX Item "align-loop-iterations"
+A loop expected to iterate at least the selected number of iterations is
+aligned.
+.IP "\fBtracer-dynamic-coverage\fR" 4
+.IX Item "tracer-dynamic-coverage"
+.PD 0
+.IP "\fBtracer-dynamic-coverage-feedback\fR" 4
+.IX Item "tracer-dynamic-coverage-feedback"
+.PD
+This value is used to limit superblock formation once the given percentage of
+executed instructions is covered.  This limits unnecessary code size
+expansion.
+.Sp
+The \fBtracer-dynamic-coverage-feedback\fR is used only when profile
+feedback is available.  The real profiles (as opposed to statically estimated
+ones) are much less balanced allowing the threshold to be larger value.
+.IP "\fBtracer-max-code-growth\fR" 4
+.IX Item "tracer-max-code-growth"
+Stop tail duplication once code growth has reached given percentage.  This is
+a rather artificial limit, as most of the duplicates are eliminated later in
+cross jumping, so it may be set to much higher values than is the desired code
+growth.
+.IP "\fBtracer-min-branch-ratio\fR" 4
+.IX Item "tracer-min-branch-ratio"
+Stop reverse growth when the reverse probability of best edge is less than this
+threshold (in percent).
+.IP "\fBtracer-min-branch-ratio\fR" 4
+.IX Item "tracer-min-branch-ratio"
+.PD 0
+.IP "\fBtracer-min-branch-ratio-feedback\fR" 4
+.IX Item "tracer-min-branch-ratio-feedback"
+.PD
+Stop forward growth if the best edge has probability lower than this
+threshold.
+.Sp
+Similarly to \fBtracer-dynamic-coverage\fR two values are present, one for
+compilation for profile feedback and one for compilation without.  The value
+for compilation with profile feedback needs to be more conservative (higher) in
+order to make tracer effective.
+.IP "\fBmax-cse-path-length\fR" 4
+.IX Item "max-cse-path-length"
+The maximum number of basic blocks on path that \s-1CSE\s0 considers.
+The default is 10.
+.IP "\fBmax-cse-insns\fR" 4
+.IX Item "max-cse-insns"
+The maximum number of instructions \s-1CSE\s0 processes before flushing.
+The default is 1000.
+.IP "\fBggc-min-expand\fR" 4
+.IX Item "ggc-min-expand"
+\&\s-1GCC\s0 uses a garbage collector to manage its own memory allocation.  This
+parameter specifies the minimum percentage by which the garbage
+collector's heap should be allowed to expand between collections.
+Tuning this may improve compilation speed; it has no effect on code
+generation.
+.Sp
+The default is 30% + 70% * (\s-1RAM/1GB\s0) with an upper bound of 100% when
+\&\s-1RAM \s0>= 1GB.  If \f(CW\*(C`getrlimit\*(C'\fR is available, the notion of \*(L"\s-1RAM\*(R"\s0 is
+the smallest of actual \s-1RAM\s0 and \f(CW\*(C`RLIMIT_DATA\*(C'\fR or \f(CW\*(C`RLIMIT_AS\*(C'\fR.  If
+\&\s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a particular platform, the lower
+bound of 30% is used.  Setting this parameter and
+\&\fBggc-min-heapsize\fR to zero causes a full collection to occur at
+every opportunity.  This is extremely slow, but can be useful for
+debugging.
+.IP "\fBggc-min-heapsize\fR" 4
+.IX Item "ggc-min-heapsize"
+Minimum size of the garbage collector's heap before it begins bothering
+to collect garbage.  The first collection occurs after the heap expands
+by \fBggc-min-expand\fR% beyond \fBggc-min-heapsize\fR.  Again,
+tuning this may improve compilation speed, and has no effect on code
+generation.
+.Sp
+The default is the smaller of \s-1RAM/8, RLIMIT_RSS,\s0 or a limit that
+tries to ensure that \s-1RLIMIT_DATA\s0 or \s-1RLIMIT_AS\s0 are not exceeded, but
+with a lower bound of 4096 (four megabytes) and an upper bound of
+131072 (128 megabytes).  If \s-1GCC\s0 is not able to calculate \s-1RAM\s0 on a
+particular platform, the lower bound is used.  Setting this parameter
+very large effectively disables garbage collection.  Setting this
+parameter and \fBggc-min-expand\fR to zero causes a full collection
+to occur at every opportunity.
+.IP "\fBmax-reload-search-insns\fR" 4
+.IX Item "max-reload-search-insns"
+The maximum number of instruction reload should look backward for equivalent
+register.  Increasing values mean more aggressive optimization, making the
+compilation time increase with probably slightly better performance.
+The default value is 100.
+.IP "\fBmax-cselib-memory-locations\fR" 4
+.IX Item "max-cselib-memory-locations"
+The maximum number of memory locations cselib should take into account.
+Increasing values mean more aggressive optimization, making the compilation time
+increase with probably slightly better performance.  The default value is 500.
+.IP "\fBreorder-blocks-duplicate\fR" 4
+.IX Item "reorder-blocks-duplicate"
+.PD 0
+.IP "\fBreorder-blocks-duplicate-feedback\fR" 4
+.IX Item "reorder-blocks-duplicate-feedback"
+.PD
+Used by the basic block reordering pass to decide whether to use unconditional
+branch or duplicate the code on its destination.  Code is duplicated when its
+estimated size is smaller than this value multiplied by the estimated size of
+unconditional jump in the hot spots of the program.
+.Sp
+The \fBreorder-block-duplicate-feedback\fR is used only when profile
+feedback is available.  It may be set to higher values than
+\&\fBreorder-block-duplicate\fR since information about the hot spots is more
+accurate.
+.IP "\fBmax-sched-ready-insns\fR" 4
+.IX Item "max-sched-ready-insns"
+The maximum number of instructions ready to be issued the scheduler should
+consider at any given time during the first scheduling pass.  Increasing
+values mean more thorough searches, making the compilation time increase
+with probably little benefit.  The default value is 100.
+.IP "\fBmax-sched-region-blocks\fR" 4
+.IX Item "max-sched-region-blocks"
+The maximum number of blocks in a region to be considered for
+interblock scheduling.  The default value is 10.
+.IP "\fBmax-pipeline-region-blocks\fR" 4
+.IX Item "max-pipeline-region-blocks"
+The maximum number of blocks in a region to be considered for
+pipelining in the selective scheduler.  The default value is 15.
+.IP "\fBmax-sched-region-insns\fR" 4
+.IX Item "max-sched-region-insns"
+The maximum number of insns in a region to be considered for
+interblock scheduling.  The default value is 100.
+.IP "\fBmax-pipeline-region-insns\fR" 4
+.IX Item "max-pipeline-region-insns"
+The maximum number of insns in a region to be considered for
+pipelining in the selective scheduler.  The default value is 200.
+.IP "\fBmin-spec-prob\fR" 4
+.IX Item "min-spec-prob"
+The minimum probability (in percents) of reaching a source block
+for interblock speculative scheduling.  The default value is 40.
+.IP "\fBmax-sched-extend-regions-iters\fR" 4
+.IX Item "max-sched-extend-regions-iters"
+The maximum number of iterations through \s-1CFG\s0 to extend regions.
+A value of 0 (the default) disables region extensions.
+.IP "\fBmax-sched-insn-conflict-delay\fR" 4
+.IX Item "max-sched-insn-conflict-delay"
+The maximum conflict delay for an insn to be considered for speculative motion.
+The default value is 3.
+.IP "\fBsched-spec-prob-cutoff\fR" 4
+.IX Item "sched-spec-prob-cutoff"
+The minimal probability of speculation success (in percents), so that
+speculative insns are scheduled.
+The default value is 40.
+.IP "\fBsched-spec-state-edge-prob-cutoff\fR" 4
+.IX Item "sched-spec-state-edge-prob-cutoff"
+The minimum probability an edge must have for the scheduler to save its
+state across it.
+The default value is 10.
+.IP "\fBsched-mem-true-dep-cost\fR" 4
+.IX Item "sched-mem-true-dep-cost"
+Minimal distance (in \s-1CPU\s0 cycles) between store and load targeting same
+memory locations.  The default value is 1.
+.IP "\fBselsched-max-lookahead\fR" 4
+.IX Item "selsched-max-lookahead"
+The maximum size of the lookahead window of selective scheduling.  It is a
+depth of search for available instructions.
+The default value is 50.
+.IP "\fBselsched-max-sched-times\fR" 4
+.IX Item "selsched-max-sched-times"
+The maximum number of times that an instruction is scheduled during
+selective scheduling.  This is the limit on the number of iterations
+through which the instruction may be pipelined.  The default value is 2.
+.IP "\fBselsched-max-insns-to-rename\fR" 4
+.IX Item "selsched-max-insns-to-rename"
+The maximum number of best instructions in the ready list that are considered
+for renaming in the selective scheduler.  The default value is 2.
+.IP "\fBsms-min-sc\fR" 4
+.IX Item "sms-min-sc"
+The minimum value of stage count that swing modulo scheduler
+generates.  The default value is 2.
+.IP "\fBmax-last-value-rtl\fR" 4
+.IX Item "max-last-value-rtl"
+The maximum size measured as number of RTLs that can be recorded in an expression
+in combiner for a pseudo register as last known value of that register.  The default
+is 10000.
+.IP "\fBinteger-share-limit\fR" 4
+.IX Item "integer-share-limit"
+Small integer constants can use a shared data structure, reducing the
+compiler's memory usage and increasing its speed.  This sets the maximum
+value of a shared integer constant.  The default value is 256.
+.IP "\fBssp-buffer-size\fR" 4
+.IX Item "ssp-buffer-size"
+The minimum size of buffers (i.e. arrays) that receive stack smashing
+protection when \fB\-fstack\-protection\fR is used.
+.IP "\fBmin-size-for-stack-sharing\fR" 4
+.IX Item "min-size-for-stack-sharing"
+The minimum size of variables taking part in stack slot sharing when not
+optimizing. The default value is 32.
+.IP "\fBmax-jump-thread-duplication-stmts\fR" 4
+.IX Item "max-jump-thread-duplication-stmts"
+Maximum number of statements allowed in a block that needs to be
+duplicated when threading jumps.
+.IP "\fBmax-fields-for-field-sensitive\fR" 4
+.IX Item "max-fields-for-field-sensitive"
+Maximum number of fields in a structure treated in
+a field sensitive manner during pointer analysis.  The default is zero
+for \fB\-O0\fR and \fB\-O1\fR,
+and 100 for \fB\-Os\fR, \fB\-O2\fR, and \fB\-O3\fR.
+.IP "\fBprefetch-latency\fR" 4
+.IX Item "prefetch-latency"
+Estimate on average number of instructions that are executed before
+prefetch finishes.  The distance prefetched ahead is proportional
+to this constant.  Increasing this number may also lead to less
+streams being prefetched (see \fBsimultaneous-prefetches\fR).
+.IP "\fBsimultaneous-prefetches\fR" 4
+.IX Item "simultaneous-prefetches"
+Maximum number of prefetches that can run at the same time.
+.IP "\fBl1\-cache\-line\-size\fR" 4
+.IX Item "l1-cache-line-size"
+The size of cache line in L1 cache, in bytes.
+.IP "\fBl1\-cache\-size\fR" 4
+.IX Item "l1-cache-size"
+The size of L1 cache, in kilobytes.
+.IP "\fBl2\-cache\-size\fR" 4
+.IX Item "l2-cache-size"
+The size of L2 cache, in kilobytes.
+.IP "\fBmin-insn-to-prefetch-ratio\fR" 4
+.IX Item "min-insn-to-prefetch-ratio"
+The minimum ratio between the number of instructions and the
+number of prefetches to enable prefetching in a loop.
+.IP "\fBprefetch-min-insn-to-mem-ratio\fR" 4
+.IX Item "prefetch-min-insn-to-mem-ratio"
+The minimum ratio between the number of instructions and the
+number of memory references to enable prefetching in a loop.
+.IP "\fBuse-canonical-types\fR" 4
+.IX Item "use-canonical-types"
+Whether the compiler should use the \*(L"canonical\*(R" type system.  By
+default, this should always be 1, which uses a more efficient internal
+mechanism for comparing types in \*(C+ and Objective\-\*(C+.  However, if
+bugs in the canonical type system are causing compilation failures,
+set this value to 0 to disable canonical types.
+.IP "\fBswitch-conversion-max-branch-ratio\fR" 4
+.IX Item "switch-conversion-max-branch-ratio"
+Switch initialization conversion refuses to create arrays that are
+bigger than \fBswitch-conversion-max-branch-ratio\fR times the number of
+branches in the switch.
+.IP "\fBmax-partial-antic-length\fR" 4
+.IX Item "max-partial-antic-length"
+Maximum length of the partial antic set computed during the tree
+partial redundancy elimination optimization (\fB\-ftree\-pre\fR) when
+optimizing at \fB\-O3\fR and above.  For some sorts of source code
+the enhanced partial redundancy elimination optimization can run away,
+consuming all of the memory available on the host machine.  This
+parameter sets a limit on the length of the sets that are computed,
+which prevents the runaway behavior.  Setting a value of 0 for
+this parameter allows an unlimited set length.
+.IP "\fBsccvn-max-scc-size\fR" 4
+.IX Item "sccvn-max-scc-size"
+Maximum size of a strongly connected component (\s-1SCC\s0) during \s-1SCCVN\s0
+processing.  If this limit is hit, \s-1SCCVN\s0 processing for the whole
+function is not done and optimizations depending on it are
+disabled.  The default maximum \s-1SCC\s0 size is 10000.
+.IP "\fBsccvn-max-alias-queries-per-access\fR" 4
+.IX Item "sccvn-max-alias-queries-per-access"
+Maximum number of alias-oracle queries we perform when looking for
+redundancies for loads and stores.  If this limit is hit the search
+is aborted and the load or store is not considered redundant.  The
+number of queries is algorithmically limited to the number of
+stores on all paths from the load to the function entry.
+The default maxmimum number of queries is 1000.
+.IP "\fBira-max-loops-num\fR" 4
+.IX Item "ira-max-loops-num"
+\&\s-1IRA\s0 uses regional register allocation by default.  If a function
+contains more loops than the number given by this parameter, only at most
+the given number of the most frequently-executed loops form regions
+for regional register allocation.  The default value of the
+parameter is 100.
+.IP "\fBira-max-conflict-table-size\fR" 4
+.IX Item "ira-max-conflict-table-size"
+Although \s-1IRA\s0 uses a sophisticated algorithm to compress the conflict
+table, the table can still require excessive amounts of memory for
+huge functions.  If the conflict table for a function could be more
+than the size in \s-1MB\s0 given by this parameter, the register allocator
+instead uses a faster, simpler, and lower-quality
+algorithm that does not require building a pseudo-register conflict table.  
+The default value of the parameter is 2000.
+.IP "\fBira-loop-reserved-regs\fR" 4
+.IX Item "ira-loop-reserved-regs"
+\&\s-1IRA\s0 can be used to evaluate more accurate register pressure in loops
+for decisions to move loop invariants (see \fB\-O3\fR).  The number
+of available registers reserved for some other purposes is given
+by this parameter.  The default value of the parameter is 2, which is
+the minimal number of registers needed by typical instructions.
+This value is the best found from numerous experiments.
+.IP "\fBloop-invariant-max-bbs-in-loop\fR" 4
+.IX Item "loop-invariant-max-bbs-in-loop"
+Loop invariant motion can be very expensive, both in compilation time and
+in amount of needed compile-time memory, with very large loops.  Loops
+with more basic blocks than this parameter won't have loop invariant
+motion optimization performed on them.  The default value of the
+parameter is 1000 for \fB\-O1\fR and 10000 for \fB\-O2\fR and above.
+.IP "\fBloop-max-datarefs-for-datadeps\fR" 4
+.IX Item "loop-max-datarefs-for-datadeps"
+Building data dapendencies is expensive for very large loops.  This
+parameter limits the number of data references in loops that are
+considered for data dependence analysis.  These large loops are no
+handled by the optimizations using loop data dependencies.
+The default value is 1000.
+.IP "\fBmax-vartrack-size\fR" 4
+.IX Item "max-vartrack-size"
+Sets a maximum number of hash table slots to use during variable
+tracking dataflow analysis of any function.  If this limit is exceeded
+with variable tracking at assignments enabled, analysis for that
+function is retried without it, after removing all debug insns from
+the function.  If the limit is exceeded even without debug insns, var
+tracking analysis is completely disabled for the function.  Setting
+the parameter to zero makes it unlimited.
+.IP "\fBmax-vartrack-expr-depth\fR" 4
+.IX Item "max-vartrack-expr-depth"
+Sets a maximum number of recursion levels when attempting to map
+variable names or debug temporaries to value expressions.  This trades
+compilation time for more complete debug information.  If this is set too
+low, value expressions that are available and could be represented in
+debug information may end up not being used; setting this higher may
+enable the compiler to find more complex debug expressions, but compile
+time and memory use may grow.  The default is 12.
+.IP "\fBmin-nondebug-insn-uid\fR" 4
+.IX Item "min-nondebug-insn-uid"
+Use uids starting at this parameter for nondebug insns.  The range below
+the parameter is reserved exclusively for debug insns created by
+\&\fB\-fvar\-tracking\-assignments\fR, but debug insns may get
+(non-overlapping) uids above it if the reserved range is exhausted.
+.IP "\fBipa-sra-ptr-growth-factor\fR" 4
+.IX Item "ipa-sra-ptr-growth-factor"
+IPA-SRA replaces a pointer to an aggregate with one or more new
+parameters only when their cumulative size is less or equal to
+\&\fBipa-sra-ptr-growth-factor\fR times the size of the original
+pointer parameter.
+.IP "\fBtm-max-aggregate-size\fR" 4
+.IX Item "tm-max-aggregate-size"
+When making copies of thread-local variables in a transaction, this
+parameter specifies the size in bytes after which variables are
+saved with the logging functions as opposed to save/restore code
+sequence pairs.  This option only applies when using
+\&\fB\-fgnu\-tm\fR.
+.IP "\fBgraphite-max-nb-scop-params\fR" 4
+.IX Item "graphite-max-nb-scop-params"
+To avoid exponential effects in the Graphite loop transforms, the
+number of parameters in a Static Control Part (SCoP) is bounded.  The
+default value is 10 parameters.  A variable whose value is unknown at
+compilation time and defined outside a SCoP is a parameter of the SCoP.
+.IP "\fBgraphite-max-bbs-per-function\fR" 4
+.IX Item "graphite-max-bbs-per-function"
+To avoid exponential effects in the detection of SCoPs, the size of
+the functions analyzed by Graphite is bounded.  The default value is
+100 basic blocks.
+.IP "\fBloop-block-tile-size\fR" 4
+.IX Item "loop-block-tile-size"
+Loop blocking or strip mining transforms, enabled with
+\&\fB\-floop\-block\fR or \fB\-floop\-strip\-mine\fR, strip mine each
+loop in the loop nest by a given number of iterations.  The strip
+length can be changed using the \fBloop-block-tile-size\fR
+parameter.  The default value is 51 iterations.
+.IP "\fBipa-cp-value-list-size\fR" 4
+.IX Item "ipa-cp-value-list-size"
+IPA-CP attempts to track all possible values and types passed to a function's
+parameter in order to propagate them and perform devirtualization.
+\&\fBipa-cp-value-list-size\fR is the maximum number of values and types it
+stores per one formal parameter of a function.
+.IP "\fBlto-partitions\fR" 4
+.IX Item "lto-partitions"
+Specify desired number of partitions produced during \s-1WHOPR\s0 compilation.
+The number of partitions should exceed the number of CPUs used for compilation.
+The default value is 32.
+.IP "\fBlto-minpartition\fR" 4
+.IX Item "lto-minpartition"
+Size of minimal partition for \s-1WHOPR \s0(in estimated instructions).
+This prevents expenses of splitting very small programs into too many
+partitions.
+.IP "\fBcxx-max-namespaces-for-diagnostic-help\fR" 4
+.IX Item "cxx-max-namespaces-for-diagnostic-help"
+The maximum number of namespaces to consult for suggestions when \*(C+
+name lookup fails for an identifier.  The default is 1000.
+.IP "\fBsink-frequency-threshold\fR" 4
+.IX Item "sink-frequency-threshold"
+The maximum relative execution frequency (in percents) of the target block
+relative to a statement's original block to allow statement sinking of a
+statement.  Larger numbers result in more aggressive statement sinking.
+The default value is 75.  A small positive adjustment is applied for
+statements with memory operands as those are even more profitable so sink.
+.IP "\fBmax-stores-to-sink\fR" 4
+.IX Item "max-stores-to-sink"
+The maximum number of conditional stores paires that can be sunk.  Set to 0
+if either vectorization (\fB\-ftree\-vectorize\fR) or if-conversion
+(\fB\-ftree\-loop\-if\-convert\fR) is disabled.  The default is 2.
+.IP "\fBallow-load-data-races\fR" 4
+.IX Item "allow-load-data-races"
+Allow optimizers to introduce new data races on loads.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the \fB\-fmemory\-model=\fR option.
+.IP "\fBallow-store-data-races\fR" 4
+.IX Item "allow-store-data-races"
+Allow optimizers to introduce new data races on stores.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the \fB\-fmemory\-model=\fR option.
+.IP "\fBallow-packed-load-data-races\fR" 4
+.IX Item "allow-packed-load-data-races"
+Allow optimizers to introduce new data races on packed data loads.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the \fB\-fmemory\-model=\fR option.
+.IP "\fBallow-packed-store-data-races\fR" 4
+.IX Item "allow-packed-store-data-races"
+Allow optimizers to introduce new data races on packed data stores.
+Set to 1 to allow, otherwise to 0.  This option is enabled by default
+unless implicitly set by the \fB\-fmemory\-model=\fR option.
+.IP "\fBcase-values-threshold\fR" 4
+.IX Item "case-values-threshold"
+The smallest number of different values for which it is best to use a
+jump-table instead of a tree of conditional branches.  If the value is
+0, use the default for the machine.  The default is 0.
+.IP "\fBtree-reassoc-width\fR" 4
+.IX Item "tree-reassoc-width"
+Set the maximum number of instructions executed in parallel in
+reassociated tree. This parameter overrides target dependent
+heuristics used by default if has non zero value.
+.IP "\fBsched-pressure-algorithm\fR" 4
+.IX Item "sched-pressure-algorithm"
+Choose between the two available implementations of
+\&\fB\-fsched\-pressure\fR.  Algorithm 1 is the original implementation
+and is the more likely to prevent instructions from being reordered.
+Algorithm 2 was designed to be a compromise between the relatively
+conservative approach taken by algorithm 1 and the rather aggressive
+approach taken by the default scheduler.  It relies more heavily on
+having a regular register file and accurate register pressure classes.
+See \fIhaifa\-sched.c\fR in the \s-1GCC\s0 sources for more details.
+.Sp
+The default choice depends on the target.
+.IP "\fBmax-slsr-cand-scan\fR" 4
+.IX Item "max-slsr-cand-scan"
+Set the maximum number of existing candidates that will be considered when
+seeking a basis for a new straight-line strength reduction candidate.
+.IP "\fBasan-globals\fR" 4
+.IX Item "asan-globals"
+Enable buffer overflow detection for global objects.  This kind
+of protection is enabled by default if you are using
+\&\fB\-fsanitize=address\fR option.
+To disable global objects protection use \fB\-\-param asan\-globals=0\fR.
+.IP "\fBasan-stack\fR" 4
+.IX Item "asan-stack"
+Enable buffer overflow detection for stack objects.  This kind of
+protection is enabled by default when using\fB\-fsanitize=address\fR.
+To disable stack protection use \fB\-\-param asan\-stack=0\fR option.
+.IP "\fBasan-instrument-reads\fR" 4
+.IX Item "asan-instrument-reads"
+Enable buffer overflow detection for memory reads.  This kind of
+protection is enabled by default when using \fB\-fsanitize=address\fR.
+To disable memory reads protection use
+\&\fB\-\-param asan\-instrument\-reads=0\fR.
+.IP "\fBasan-instrument-writes\fR" 4
+.IX Item "asan-instrument-writes"
+Enable buffer overflow detection for memory writes.  This kind of
+protection is enabled by default when using \fB\-fsanitize=address\fR.
+To disable memory writes protection use
+\&\fB\-\-param asan\-instrument\-writes=0\fR option.
+.IP "\fBasan-memintrin\fR" 4
+.IX Item "asan-memintrin"
+Enable detection for built-in functions.  This kind of protection
+is enabled by default when using \fB\-fsanitize=address\fR.
+To disable built-in functions protection use
+\&\fB\-\-param asan\-memintrin=0\fR.
+.IP "\fBasan-use-after-return\fR" 4
+.IX Item "asan-use-after-return"
+Enable detection of use-after-return.  This kind of protection
+is enabled by default when using \fB\-fsanitize=address\fR option.
+To disable use-after-return detection use 
+\&\fB\-\-param asan\-use\-after\-return=0\fR.
+.RE
+.RS 4
+.RE
+.SS "Options Controlling the Preprocessor"
+.IX Subsection "Options Controlling the Preprocessor"
+These options control the C preprocessor, which is run on each C source
+file before actual compilation.
+.PP
+If you use the \fB\-E\fR option, nothing is done except preprocessing.
+Some of these options make sense only together with \fB\-E\fR because
+they cause the preprocessor output to be unsuitable for actual
+compilation.
+.IP "\fB\-Wp,\fR\fIoption\fR" 4
+.IX Item "-Wp,option"
+You can use \fB\-Wp,\fR\fIoption\fR to bypass the compiler driver
+and pass \fIoption\fR directly through to the preprocessor.  If
+\&\fIoption\fR contains commas, it is split into multiple options at the
+commas.  However, many options are modified, translated or interpreted
+by the compiler driver before being passed to the preprocessor, and
+\&\fB\-Wp\fR forcibly bypasses this phase.  The preprocessor's direct
+interface is undocumented and subject to change, so whenever possible
+you should avoid using \fB\-Wp\fR and let the driver handle the
+options instead.
+.IP "\fB\-Xpreprocessor\fR \fIoption\fR" 4
+.IX Item "-Xpreprocessor option"
+Pass \fIoption\fR as an option to the preprocessor.  You can use this to
+supply system-specific preprocessor options that \s-1GCC\s0 does not 
+recognize.
+.Sp
+If you want to pass an option that takes an argument, you must use
+\&\fB\-Xpreprocessor\fR twice, once for the option and once for the argument.
+.IP "\fB\-no\-integrated\-cpp\fR" 4
+.IX Item "-no-integrated-cpp"
+Perform preprocessing as a separate pass before compilation.
+By default, \s-1GCC\s0 performs preprocessing as an integrated part of
+input tokenization and parsing.
+If this option is provided, the appropriate language front end
+(\fBcc1\fR, \fBcc1plus\fR, or \fBcc1obj\fR for C, \*(C+,
+and Objective-C, respectively) is instead invoked twice,
+once for preprocessing only and once for actual compilation
+of the preprocessed input.
+This option may be useful in conjunction with the \fB\-B\fR or
+\&\fB\-wrapper\fR options to specify an alternate preprocessor or
+perform additional processing of the program source between
+normal preprocessing and compilation.
+.IP "\fB\-D\fR \fIname\fR" 4
+.IX Item "-D name"
+Predefine \fIname\fR as a macro, with definition \f(CW1\fR.
+.IP "\fB\-D\fR \fIname\fR\fB=\fR\fIdefinition\fR" 4
+.IX Item "-D name=definition"
+The contents of \fIdefinition\fR are tokenized and processed as if
+they appeared during translation phase three in a \fB#define\fR
+directive.  In particular, the definition will be truncated by
+embedded newline characters.
+.Sp
+If you are invoking the preprocessor from a shell or shell-like
+program you may need to use the shell's quoting syntax to protect
+characters such as spaces that have a meaning in the shell syntax.
+.Sp
+If you wish to define a function-like macro on the command line, write
+its argument list with surrounding parentheses before the equals sign
+(if any).  Parentheses are meaningful to most shells, so you will need
+to quote the option.  With \fBsh\fR and \fBcsh\fR,
+\&\fB\-D'\fR\fIname\fR\fB(\fR\fIargs...\fR\fB)=\fR\fIdefinition\fR\fB'\fR works.
+.Sp
+\&\fB\-D\fR and \fB\-U\fR options are processed in the order they
+are given on the command line.  All \fB\-imacros\fR \fIfile\fR and
+\&\fB\-include\fR \fIfile\fR options are processed after all
+\&\fB\-D\fR and \fB\-U\fR options.
+.IP "\fB\-U\fR \fIname\fR" 4
+.IX Item "-U name"
+Cancel any previous definition of \fIname\fR, either built in or
+provided with a \fB\-D\fR option.
+.IP "\fB\-undef\fR" 4
+.IX Item "-undef"
+Do not predefine any system-specific or GCC-specific macros.  The
+standard predefined macros remain defined.
+.IP "\fB\-I\fR \fIdir\fR" 4
+.IX Item "-I dir"
+Add the directory \fIdir\fR to the list of directories to be searched
+for header files.
+Directories named by \fB\-I\fR are searched before the standard
+system include directories.  If the directory \fIdir\fR is a standard
+system include directory, the option is ignored to ensure that the
+default search order for system directories and the special treatment
+of system headers are not defeated
+\&.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-o\fR \fIfile\fR" 4
+.IX Item "-o file"
+Write output to \fIfile\fR.  This is the same as specifying \fIfile\fR
+as the second non-option argument to \fBcpp\fR.  \fBgcc\fR has a
+different interpretation of a second non-option argument, so you must
+use \fB\-o\fR to specify the output file.
+.IP "\fB\-Wall\fR" 4
+.IX Item "-Wall"
+Turns on all optional warnings which are desirable for normal code.
+At present this is \fB\-Wcomment\fR, \fB\-Wtrigraphs\fR,
+\&\fB\-Wmultichar\fR and a warning about integer promotion causing a
+change of sign in \f(CW\*(C`#if\*(C'\fR expressions.  Note that many of the
+preprocessor's warnings are on by default and have no options to
+control them.
+.IP "\fB\-Wcomment\fR" 4
+.IX Item "-Wcomment"
+.PD 0
+.IP "\fB\-Wcomments\fR" 4
+.IX Item "-Wcomments"
+.PD
+Warn whenever a comment-start sequence \fB/*\fR appears in a \fB/*\fR
+comment, or whenever a backslash-newline appears in a \fB//\fR comment.
+(Both forms have the same effect.)
+.IP "\fB\-Wtrigraphs\fR" 4
+.IX Item "-Wtrigraphs"
+Most trigraphs in comments cannot affect the meaning of the program.
+However, a trigraph that would form an escaped newline (\fB??/\fR at
+the end of a line) can, by changing where the comment begins or ends.
+Therefore, only trigraphs that would form escaped newlines produce
+warnings inside a comment.
+.Sp
+This option is implied by \fB\-Wall\fR.  If \fB\-Wall\fR is not
+given, this option is still enabled unless trigraphs are enabled.  To
+get trigraph conversion without warnings, but get the other
+\&\fB\-Wall\fR warnings, use \fB\-trigraphs \-Wall \-Wno\-trigraphs\fR.
+.IP "\fB\-Wtraditional\fR" 4
+.IX Item "-Wtraditional"
+Warn about certain constructs that behave differently in traditional and
+\&\s-1ISO C. \s0 Also warn about \s-1ISO C\s0 constructs that have no traditional C
+equivalent, and problematic constructs which should be avoided.
+.IP "\fB\-Wundef\fR" 4
+.IX Item "-Wundef"
+Warn whenever an identifier which is not a macro is encountered in an
+\&\fB#if\fR directive, outside of \fBdefined\fR.  Such identifiers are
+replaced with zero.
+.IP "\fB\-Wunused\-macros\fR" 4
+.IX Item "-Wunused-macros"
+Warn about macros defined in the main file that are unused.  A macro
+is \fIused\fR if it is expanded or tested for existence at least once.
+The preprocessor will also warn if the macro has not been used at the
+time it is redefined or undefined.
+.Sp
+Built-in macros, macros defined on the command line, and macros
+defined in include files are not warned about.
+.Sp
+\&\fINote:\fR If a macro is actually used, but only used in skipped
+conditional blocks, then \s-1CPP\s0 will report it as unused.  To avoid the
+warning in such a case, you might improve the scope of the macro's
+definition by, for example, moving it into the first skipped block.
+Alternatively, you could provide a dummy use with something like:
+.Sp
+.Vb 2
+\&        #if defined the_macro_causing_the_warning
+\&        #endif
+.Ve
+.IP "\fB\-Wendif\-labels\fR" 4
+.IX Item "-Wendif-labels"
+Warn whenever an \fB#else\fR or an \fB#endif\fR are followed by text.
+This usually happens in code of the form
+.Sp
+.Vb 5
+\&        #if FOO
+\&        ...
+\&        #else FOO
+\&        ...
+\&        #endif FOO
+.Ve
+.Sp
+The second and third \f(CW\*(C`FOO\*(C'\fR should be in comments, but often are not
+in older programs.  This warning is on by default.
+.IP "\fB\-Werror\fR" 4
+.IX Item "-Werror"
+Make all warnings into hard errors.  Source code which triggers warnings
+will be rejected.
+.IP "\fB\-Wsystem\-headers\fR" 4
+.IX Item "-Wsystem-headers"
+Issue warnings for code in system headers.  These are normally unhelpful
+in finding bugs in your own code, therefore suppressed.  If you are
+responsible for the system library, you may want to see them.
+.IP "\fB\-w\fR" 4
+.IX Item "-w"
+Suppress all warnings, including those which \s-1GNU CPP\s0 issues by default.
+.IP "\fB\-pedantic\fR" 4
+.IX Item "-pedantic"
+Issue all the mandatory diagnostics listed in the C standard.  Some of
+them are left out by default, since they trigger frequently on harmless
+code.
+.IP "\fB\-pedantic\-errors\fR" 4
+.IX Item "-pedantic-errors"
+Issue all the mandatory diagnostics, and make all mandatory diagnostics
+into errors.  This includes mandatory diagnostics that \s-1GCC\s0 issues
+without \fB\-pedantic\fR but treats as warnings.
+.IP "\fB\-M\fR" 4
+.IX Item "-M"
+Instead of outputting the result of preprocessing, output a rule
+suitable for \fBmake\fR describing the dependencies of the main
+source file.  The preprocessor outputs one \fBmake\fR rule containing
+the object file name for that source file, a colon, and the names of all
+the included files, including those coming from \fB\-include\fR or
+\&\fB\-imacros\fR command line options.
+.Sp
+Unless specified explicitly (with \fB\-MT\fR or \fB\-MQ\fR), the
+object file name consists of the name of the source file with any
+suffix replaced with object file suffix and with any leading directory
+parts removed.  If there are many included files then the rule is
+split into several lines using \fB\e\fR\-newline.  The rule has no
+commands.
+.Sp
+This option does not suppress the preprocessor's debug output, such as
+\&\fB\-dM\fR.  To avoid mixing such debug output with the dependency
+rules you should explicitly specify the dependency output file with
+\&\fB\-MF\fR, or use an environment variable like
+\&\fB\s-1DEPENDENCIES_OUTPUT\s0\fR.  Debug output
+will still be sent to the regular output stream as normal.
+.Sp
+Passing \fB\-M\fR to the driver implies \fB\-E\fR, and suppresses
+warnings with an implicit \fB\-w\fR.
+.IP "\fB\-MM\fR" 4
+.IX Item "-MM"
+Like \fB\-M\fR but do not mention header files that are found in
+system header directories, nor header files that are included,
+directly or indirectly, from such a header.
+.Sp
+This implies that the choice of angle brackets or double quotes in an
+\&\fB#include\fR directive does not in itself determine whether that
+header will appear in \fB\-MM\fR dependency output.  This is a
+slight change in semantics from \s-1GCC\s0 versions 3.0 and earlier.
+.IP "\fB\-MF\fR \fIfile\fR" 4
+.IX Item "-MF file"
+When used with \fB\-M\fR or \fB\-MM\fR, specifies a
+file to write the dependencies to.  If no \fB\-MF\fR switch is given
+the preprocessor sends the rules to the same place it would have sent
+preprocessed output.
+.Sp
+When used with the driver options \fB\-MD\fR or \fB\-MMD\fR,
+\&\fB\-MF\fR overrides the default dependency output file.
+.IP "\fB\-MG\fR" 4
+.IX Item "-MG"
+In conjunction with an option such as \fB\-M\fR requesting
+dependency generation, \fB\-MG\fR assumes missing header files are
+generated files and adds them to the dependency list without raising
+an error.  The dependency filename is taken directly from the
+\&\f(CW\*(C`#include\*(C'\fR directive without prepending any path.  \fB\-MG\fR
+also suppresses preprocessed output, as a missing header file renders
+this useless.
+.Sp
+This feature is used in automatic updating of makefiles.
+.IP "\fB\-MP\fR" 4
+.IX Item "-MP"
+This option instructs \s-1CPP\s0 to add a phony target for each dependency
+other than the main file, causing each to depend on nothing.  These
+dummy rules work around errors \fBmake\fR gives if you remove header
+files without updating the \fIMakefile\fR to match.
+.Sp
+This is typical output:
+.Sp
+.Vb 1
+\&        test.o: test.c test.h
+\&        
+\&        test.h:
+.Ve
+.IP "\fB\-MT\fR \fItarget\fR" 4
+.IX Item "-MT target"
+Change the target of the rule emitted by dependency generation.  By
+default \s-1CPP\s0 takes the name of the main input file, deletes any
+directory components and any file suffix such as \fB.c\fR, and
+appends the platform's usual object suffix.  The result is the target.
+.Sp
+An \fB\-MT\fR option will set the target to be exactly the string you
+specify.  If you want multiple targets, you can specify them as a single
+argument to \fB\-MT\fR, or use multiple \fB\-MT\fR options.
+.Sp
+For example, \fB\-MT\ '$(objpfx)foo.o'\fR might give
+.Sp
+.Vb 1
+\&        $(objpfx)foo.o: foo.c
+.Ve
+.IP "\fB\-MQ\fR \fItarget\fR" 4
+.IX Item "-MQ target"
+Same as \fB\-MT\fR, but it quotes any characters which are special to
+Make.  \fB\-MQ\ '$(objpfx)foo.o'\fR gives
+.Sp
+.Vb 1
+\&        $$(objpfx)foo.o: foo.c
+.Ve
+.Sp
+The default target is automatically quoted, as if it were given with
+\&\fB\-MQ\fR.
+.IP "\fB\-MD\fR" 4
+.IX Item "-MD"
+\&\fB\-MD\fR is equivalent to \fB\-M \-MF\fR \fIfile\fR, except that
+\&\fB\-E\fR is not implied.  The driver determines \fIfile\fR based on
+whether an \fB\-o\fR option is given.  If it is, the driver uses its
+argument but with a suffix of \fI.d\fR, otherwise it takes the name
+of the input file, removes any directory components and suffix, and
+applies a \fI.d\fR suffix.
+.Sp
+If \fB\-MD\fR is used in conjunction with \fB\-E\fR, any
+\&\fB\-o\fR switch is understood to specify the dependency output file, but if used without \fB\-E\fR, each \fB\-o\fR
+is understood to specify a target object file.
+.Sp
+Since \fB\-E\fR is not implied, \fB\-MD\fR can be used to generate
+a dependency output file as a side-effect of the compilation process.
+.IP "\fB\-MMD\fR" 4
+.IX Item "-MMD"
+Like \fB\-MD\fR except mention only user header files, not system
+header files.
+.IP "\fB\-fpch\-deps\fR" 4
+.IX Item "-fpch-deps"
+When using precompiled headers, this flag
+will cause the dependency-output flags to also list the files from the
+precompiled header's dependencies.  If not specified only the
+precompiled header would be listed and not the files that were used to
+create it because those files are not consulted when a precompiled
+header is used.
+.IP "\fB\-fpch\-preprocess\fR" 4
+.IX Item "-fpch-preprocess"
+This option allows use of a precompiled header together with \fB\-E\fR.  It inserts a special \f(CW\*(C`#pragma\*(C'\fR,
+\&\f(CW\*(C`#pragma GCC pch_preprocess "\f(CIfilename\f(CW"\*(C'\fR in the output to mark
+the place where the precompiled header was found, and its \fIfilename\fR.
+When \fB\-fpreprocessed\fR is in use, \s-1GCC\s0 recognizes this \f(CW\*(C`#pragma\*(C'\fR
+and loads the \s-1PCH.\s0
+.Sp
+This option is off by default, because the resulting preprocessed output
+is only really suitable as input to \s-1GCC. \s0 It is switched on by
+\&\fB\-save\-temps\fR.
+.Sp
+You should not write this \f(CW\*(C`#pragma\*(C'\fR in your own code, but it is
+safe to edit the filename if the \s-1PCH\s0 file is available in a different
+location.  The filename may be absolute or it may be relative to \s-1GCC\s0's
+current directory.
+.IP "\fB\-x c\fR" 4
+.IX Item "-x c"
+.PD 0
+.IP "\fB\-x c++\fR" 4
+.IX Item "-x c++"
+.IP "\fB\-x objective-c\fR" 4
+.IX Item "-x objective-c"
+.IP "\fB\-x assembler-with-cpp\fR" 4
+.IX Item "-x assembler-with-cpp"
+.PD
+Specify the source language: C, \*(C+, Objective-C, or assembly.  This has
+nothing to do with standards conformance or extensions; it merely
+selects which base syntax to expect.  If you give none of these options,
+cpp will deduce the language from the extension of the source file:
+\&\fB.c\fR, \fB.cc\fR, \fB.m\fR, or \fB.S\fR.  Some other common
+extensions for \*(C+ and assembly are also recognized.  If cpp does not
+recognize the extension, it will treat the file as C; this is the most
+generic mode.
+.Sp
+\&\fINote:\fR Previous versions of cpp accepted a \fB\-lang\fR option
+which selected both the language and the standards conformance level.
+This option has been removed, because it conflicts with the \fB\-l\fR
+option.
+.IP "\fB\-std=\fR\fIstandard\fR" 4
+.IX Item "-std=standard"
+.PD 0
+.IP "\fB\-ansi\fR" 4
+.IX Item "-ansi"
+.PD
+Specify the standard to which the code should conform.  Currently \s-1CPP\s0
+knows about C and \*(C+ standards; others may be added in the future.
+.Sp
+\&\fIstandard\fR
+may be one of:
+.RS 4
+.ie n .IP """c90""" 4
+.el .IP "\f(CWc90\fR" 4
+.IX Item "c90"
+.PD 0
+.ie n .IP """c89""" 4
+.el .IP "\f(CWc89\fR" 4
+.IX Item "c89"
+.ie n .IP """iso9899:1990""" 4
+.el .IP "\f(CWiso9899:1990\fR" 4
+.IX Item "iso9899:1990"
+.PD
+The \s-1ISO C\s0 standard from 1990.  \fBc90\fR is the customary shorthand for
+this version of the standard.
+.Sp
+The \fB\-ansi\fR option is equivalent to \fB\-std=c90\fR.
+.ie n .IP """iso9899:199409""" 4
+.el .IP "\f(CWiso9899:199409\fR" 4
+.IX Item "iso9899:199409"
+The 1990 C standard, as amended in 1994.
+.ie n .IP """iso9899:1999""" 4
+.el .IP "\f(CWiso9899:1999\fR" 4
+.IX Item "iso9899:1999"
+.PD 0
+.ie n .IP """c99""" 4
+.el .IP "\f(CWc99\fR" 4
+.IX Item "c99"
+.ie n .IP """iso9899:199x""" 4
+.el .IP "\f(CWiso9899:199x\fR" 4
+.IX Item "iso9899:199x"
+.ie n .IP """c9x""" 4
+.el .IP "\f(CWc9x\fR" 4
+.IX Item "c9x"
+.PD
+The revised \s-1ISO C\s0 standard, published in December 1999.  Before
+publication, this was known as C9X.
+.ie n .IP """iso9899:2011""" 4
+.el .IP "\f(CWiso9899:2011\fR" 4
+.IX Item "iso9899:2011"
+.PD 0
+.ie n .IP """c11""" 4
+.el .IP "\f(CWc11\fR" 4
+.IX Item "c11"
+.ie n .IP """c1x""" 4
+.el .IP "\f(CWc1x\fR" 4
+.IX Item "c1x"
+.PD
+The revised \s-1ISO C\s0 standard, published in December 2011.  Before
+publication, this was known as C1X.
+.ie n .IP """gnu90""" 4
+.el .IP "\f(CWgnu90\fR" 4
+.IX Item "gnu90"
+.PD 0
+.ie n .IP """gnu89""" 4
+.el .IP "\f(CWgnu89\fR" 4
+.IX Item "gnu89"
+.PD
+The 1990 C standard plus \s-1GNU\s0 extensions.  This is the default.
+.ie n .IP """gnu99""" 4
+.el .IP "\f(CWgnu99\fR" 4
+.IX Item "gnu99"
+.PD 0
+.ie n .IP """gnu9x""" 4
+.el .IP "\f(CWgnu9x\fR" 4
+.IX Item "gnu9x"
+.PD
+The 1999 C standard plus \s-1GNU\s0 extensions.
+.ie n .IP """gnu11""" 4
+.el .IP "\f(CWgnu11\fR" 4
+.IX Item "gnu11"
+.PD 0
+.ie n .IP """gnu1x""" 4
+.el .IP "\f(CWgnu1x\fR" 4
+.IX Item "gnu1x"
+.PD
+The 2011 C standard plus \s-1GNU\s0 extensions.
+.ie n .IP """c++98""" 4
+.el .IP "\f(CWc++98\fR" 4
+.IX Item "c++98"
+The 1998 \s-1ISO \*(C+\s0 standard plus amendments.
+.ie n .IP """gnu++98""" 4
+.el .IP "\f(CWgnu++98\fR" 4
+.IX Item "gnu++98"
+The same as \fB\-std=c++98\fR plus \s-1GNU\s0 extensions.  This is the
+default for \*(C+ code.
+.RE
+.RS 4
+.RE
+.IP "\fB\-I\-\fR" 4
+.IX Item "-I-"
+Split the include path.  Any directories specified with \fB\-I\fR
+options before \fB\-I\-\fR are searched only for headers requested with
+\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
+\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR.  If additional directories are
+specified with \fB\-I\fR options after the \fB\-I\-\fR, those
+directories are searched for all \fB#include\fR directives.
+.Sp
+In addition, \fB\-I\-\fR inhibits the use of the directory of the current
+file directory as the first search directory for \f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR.
+This option has been deprecated.
+.IP "\fB\-nostdinc\fR" 4
+.IX Item "-nostdinc"
+Do not search the standard system directories for header files.
+Only the directories you have specified with \fB\-I\fR options
+(and the directory of the current file, if appropriate) are searched.
+.IP "\fB\-nostdinc++\fR" 4
+.IX Item "-nostdinc++"
+Do not search for header files in the \*(C+\-specific standard directories,
+but do still search the other standard directories.  (This option is
+used when building the \*(C+ library.)
+.IP "\fB\-include\fR \fIfile\fR" 4
+.IX Item "-include file"
+Process \fIfile\fR as if \f(CW\*(C`#include "file"\*(C'\fR appeared as the first
+line of the primary source file.  However, the first directory searched
+for \fIfile\fR is the preprocessor's working directory \fIinstead of\fR
+the directory containing the main source file.  If not found there, it
+is searched for in the remainder of the \f(CW\*(C`#include "..."\*(C'\fR search
+chain as normal.
+.Sp
+If multiple \fB\-include\fR options are given, the files are included
+in the order they appear on the command line.
+.IP "\fB\-imacros\fR \fIfile\fR" 4
+.IX Item "-imacros file"
+Exactly like \fB\-include\fR, except that any output produced by
+scanning \fIfile\fR is thrown away.  Macros it defines remain defined.
+This allows you to acquire all the macros from a header without also
+processing its declarations.
+.Sp
+All files specified by \fB\-imacros\fR are processed before all files
+specified by \fB\-include\fR.
+.IP "\fB\-idirafter\fR \fIdir\fR" 4
+.IX Item "-idirafter dir"
+Search \fIdir\fR for header files, but do it \fIafter\fR all
+directories specified with \fB\-I\fR and the standard system directories
+have been exhausted.  \fIdir\fR is treated as a system include directory.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-iprefix\fR \fIprefix\fR" 4
+.IX Item "-iprefix prefix"
+Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
+options.  If the prefix represents a directory, you should include the
+final \fB/\fR.
+.IP "\fB\-iwithprefix\fR \fIdir\fR" 4
+.IX Item "-iwithprefix dir"
+.PD 0
+.IP "\fB\-iwithprefixbefore\fR \fIdir\fR" 4
+.IX Item "-iwithprefixbefore dir"
+.PD
+Append \fIdir\fR to the prefix specified previously with
+\&\fB\-iprefix\fR, and add the resulting directory to the include search
+path.  \fB\-iwithprefixbefore\fR puts it in the same place \fB\-I\fR
+would; \fB\-iwithprefix\fR puts it where \fB\-idirafter\fR would.
+.IP "\fB\-isysroot\fR \fIdir\fR" 4
+.IX Item "-isysroot dir"
+This option is like the \fB\-\-sysroot\fR option, but applies only to
+header files (except for Darwin targets, where it applies to both header
+files and libraries).  See the \fB\-\-sysroot\fR option for more
+information.
+.IP "\fB\-imultilib\fR \fIdir\fR" 4
+.IX Item "-imultilib dir"
+Use \fIdir\fR as a subdirectory of the directory containing
+target-specific \*(C+ headers.
+.IP "\fB\-isystem\fR \fIdir\fR" 4
+.IX Item "-isystem dir"
+Search \fIdir\fR for header files, after all directories specified by
+\&\fB\-I\fR but before the standard system directories.  Mark it
+as a system directory, so that it gets the same special treatment as
+is applied to the standard system directories.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-iquote\fR \fIdir\fR" 4
+.IX Item "-iquote dir"
+Search \fIdir\fR only for header files requested with
+\&\f(CW\*(C`#include\ "\f(CIfile\f(CW"\*(C'\fR; they are not searched for
+\&\f(CW\*(C`#include\ <\f(CIfile\f(CW>\*(C'\fR, before all directories specified by
+\&\fB\-I\fR and before the standard system directories.
+If \fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced
+by the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-fdirectives\-only\fR" 4
+.IX Item "-fdirectives-only"
+When preprocessing, handle directives, but do not expand macros.
+.Sp
+The option's behavior depends on the \fB\-E\fR and \fB\-fpreprocessed\fR
+options.
+.Sp
+With \fB\-E\fR, preprocessing is limited to the handling of directives
+such as \f(CW\*(C`#define\*(C'\fR, \f(CW\*(C`#ifdef\*(C'\fR, and \f(CW\*(C`#error\*(C'\fR.  Other
+preprocessor operations, such as macro expansion and trigraph
+conversion are not performed.  In addition, the \fB\-dD\fR option is
+implicitly enabled.
+.Sp
+With \fB\-fpreprocessed\fR, predefinition of command line and most
+builtin macros is disabled.  Macros such as \f(CW\*(C`_\|_LINE_\|_\*(C'\fR, which are
+contextually dependent, are handled normally.  This enables compilation of
+files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
+.Sp
+With both \fB\-E\fR and \fB\-fpreprocessed\fR, the rules for
+\&\fB\-fpreprocessed\fR take precedence.  This enables full preprocessing of
+files previously preprocessed with \f(CW\*(C`\-E \-fdirectives\-only\*(C'\fR.
+.IP "\fB\-fdollars\-in\-identifiers\fR" 4
+.IX Item "-fdollars-in-identifiers"
+Accept \fB$\fR in identifiers.
+.IP "\fB\-fextended\-identifiers\fR" 4
+.IX Item "-fextended-identifiers"
+Accept universal character names in identifiers.  This option is
+experimental; in a future version of \s-1GCC,\s0 it will be enabled by
+default for C99 and \*(C+.
+.IP "\fB\-fno\-canonical\-system\-headers\fR" 4
+.IX Item "-fno-canonical-system-headers"
+When preprocessing, do not shorten system header paths with canonicalization.
+.IP "\fB\-fpreprocessed\fR" 4
+.IX Item "-fpreprocessed"
+Indicate to the preprocessor that the input file has already been
+preprocessed.  This suppresses things like macro expansion, trigraph
+conversion, escaped newline splicing, and processing of most directives.
+The preprocessor still recognizes and removes comments, so that you can
+pass a file preprocessed with \fB\-C\fR to the compiler without
+problems.  In this mode the integrated preprocessor is little more than
+a tokenizer for the front ends.
+.Sp
+\&\fB\-fpreprocessed\fR is implicit if the input file has one of the
+extensions \fB.i\fR, \fB.ii\fR or \fB.mi\fR.  These are the
+extensions that \s-1GCC\s0 uses for preprocessed files created by
+\&\fB\-save\-temps\fR.
+.IP "\fB\-ftabstop=\fR\fIwidth\fR" 4
+.IX Item "-ftabstop=width"
+Set the distance between tab stops.  This helps the preprocessor report
+correct column numbers in warnings or errors, even if tabs appear on the
+line.  If the value is less than 1 or greater than 100, the option is
+ignored.  The default is 8.
+.IP "\fB\-fdebug\-cpp\fR" 4
+.IX Item "-fdebug-cpp"
+This option is only useful for debugging \s-1GCC. \s0 When used with
+\&\fB\-E\fR, dumps debugging information about location maps.  Every
+token in the output is preceded by the dump of the map its location
+belongs to.  The dump of the map holding the location of a token would
+be:
+.Sp
+.Vb 1
+\&        {"P":F</file/path>;"F":F</includer/path>;"L":<line_num>;"C":<col_num>;"S":<system_header_p>;"M":<map_address>;"E":<macro_expansion_p>,"loc":<location>}
+.Ve
+.Sp
+When used without \fB\-E\fR, this option has no effect.
+.IP "\fB\-ftrack\-macro\-expansion\fR[\fB=\fR\fIlevel\fR]" 4
+.IX Item "-ftrack-macro-expansion[=level]"
+Track locations of tokens across macro expansions. This allows the
+compiler to emit diagnostic about the current macro expansion stack
+when a compilation error occurs in a macro expansion. Using this
+option makes the preprocessor and the compiler consume more
+memory. The \fIlevel\fR parameter can be used to choose the level of
+precision of token location tracking thus decreasing the memory
+consumption if necessary. Value \fB0\fR of \fIlevel\fR de-activates
+this option just as if no \fB\-ftrack\-macro\-expansion\fR was present
+on the command line. Value \fB1\fR tracks tokens locations in a
+degraded mode for the sake of minimal memory overhead. In this mode
+all tokens resulting from the expansion of an argument of a
+function-like macro have the same location. Value \fB2\fR tracks
+tokens locations completely. This value is the most memory hungry.
+When this option is given no argument, the default parameter value is
+\&\fB2\fR.
+.Sp
+Note that \-ftrack\-macro\-expansion=2 is activated by default.
+.IP "\fB\-fexec\-charset=\fR\fIcharset\fR" 4
+.IX Item "-fexec-charset=charset"
+Set the execution character set, used for string and character
+constants.  The default is \s-1UTF\-8.  \s0\fIcharset\fR can be any encoding
+supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
+.IP "\fB\-fwide\-exec\-charset=\fR\fIcharset\fR" 4
+.IX Item "-fwide-exec-charset=charset"
+Set the wide execution character set, used for wide string and
+character constants.  The default is \s-1UTF\-32\s0 or \s-1UTF\-16,\s0 whichever
+corresponds to the width of \f(CW\*(C`wchar_t\*(C'\fR.  As with
+\&\fB\-fexec\-charset\fR, \fIcharset\fR can be any encoding supported
+by the system's \f(CW\*(C`iconv\*(C'\fR library routine; however, you will have
+problems with encodings that do not fit exactly in \f(CW\*(C`wchar_t\*(C'\fR.
+.IP "\fB\-finput\-charset=\fR\fIcharset\fR" 4
+.IX Item "-finput-charset=charset"
+Set the input character set, used for translation from the character
+set of the input file to the source character set used by \s-1GCC. \s0 If the
+locale does not specify, or \s-1GCC\s0 cannot get this information from the
+locale, the default is \s-1UTF\-8. \s0 This can be overridden by either the locale
+or this command line option.  Currently the command line option takes
+precedence if there's a conflict.  \fIcharset\fR can be any encoding
+supported by the system's \f(CW\*(C`iconv\*(C'\fR library routine.
+.IP "\fB\-fworking\-directory\fR" 4
+.IX Item "-fworking-directory"
+Enable generation of linemarkers in the preprocessor output that will
+let the compiler know the current working directory at the time of
+preprocessing.  When this option is enabled, the preprocessor will
+emit, after the initial linemarker, a second linemarker with the
+current working directory followed by two slashes.  \s-1GCC\s0 will use this
+directory, when it's present in the preprocessed input, as the
+directory emitted as the current working directory in some debugging
+information formats.  This option is implicitly enabled if debugging
+information is enabled, but this can be inhibited with the negated
+form \fB\-fno\-working\-directory\fR.  If the \fB\-P\fR flag is
+present in the command line, this option has no effect, since no
+\&\f(CW\*(C`#line\*(C'\fR directives are emitted whatsoever.
+.IP "\fB\-fno\-show\-column\fR" 4
+.IX Item "-fno-show-column"
+Do not print column numbers in diagnostics.  This may be necessary if
+diagnostics are being scanned by a program that does not understand the
+column numbers, such as \fBdejagnu\fR.
+.IP "\fB\-A\fR \fIpredicate\fR\fB=\fR\fIanswer\fR" 4
+.IX Item "-A predicate=answer"
+Make an assertion with the predicate \fIpredicate\fR and answer
+\&\fIanswer\fR.  This form is preferred to the older form \fB\-A\fR
+\&\fIpredicate\fR\fB(\fR\fIanswer\fR\fB)\fR, which is still supported, because
+it does not use shell special characters.
+.IP "\fB\-A \-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
+.IX Item "-A -predicate=answer"
+Cancel an assertion with the predicate \fIpredicate\fR and answer
+\&\fIanswer\fR.
+.IP "\fB\-dCHARS\fR" 4
+.IX Item "-dCHARS"
+\&\fI\s-1CHARS\s0\fR is a sequence of one or more of the following characters,
+and must not be preceded by a space.  Other characters are interpreted
+by the compiler proper, or reserved for future versions of \s-1GCC,\s0 and so
+are silently ignored.  If you specify characters whose behavior
+conflicts, the result is undefined.
+.RS 4
+.IP "\fBM\fR" 4
+.IX Item "M"
+Instead of the normal output, generate a list of \fB#define\fR
+directives for all the macros defined during the execution of the
+preprocessor, including predefined macros.  This gives you a way of
+finding out what is predefined in your version of the preprocessor.
+Assuming you have no file \fIfoo.h\fR, the command
+.Sp
+.Vb 1
+\&        touch foo.h; cpp \-dM foo.h
+.Ve
+.Sp
+will show all the predefined macros.
+.Sp
+If you use \fB\-dM\fR without the \fB\-E\fR option, \fB\-dM\fR is
+interpreted as a synonym for \fB\-fdump\-rtl\-mach\fR.
+.IP "\fBD\fR" 4
+.IX Item "D"
+Like \fBM\fR except in two respects: it does \fInot\fR include the
+predefined macros, and it outputs \fIboth\fR the \fB#define\fR
+directives and the result of preprocessing.  Both kinds of output go to
+the standard output file.
+.IP "\fBN\fR" 4
+.IX Item "N"
+Like \fBD\fR, but emit only the macro names, not their expansions.
+.IP "\fBI\fR" 4
+.IX Item "I"
+Output \fB#include\fR directives in addition to the result of
+preprocessing.
+.IP "\fBU\fR" 4
+.IX Item "U"
+Like \fBD\fR except that only macros that are expanded, or whose
+definedness is tested in preprocessor directives, are output; the
+output is delayed until the use or test of the macro; and
+\&\fB#undef\fR directives are also output for macros tested but
+undefined at the time.
+.RE
+.RS 4
+.RE
+.IP "\fB\-P\fR" 4
+.IX Item "-P"
+Inhibit generation of linemarkers in the output from the preprocessor.
+This might be useful when running the preprocessor on something that is
+not C code, and will be sent to a program which might be confused by the
+linemarkers.
+.IP "\fB\-C\fR" 4
+.IX Item "-C"
+Do not discard comments.  All comments are passed through to the output
+file, except for comments in processed directives, which are deleted
+along with the directive.
+.Sp
+You should be prepared for side effects when using \fB\-C\fR; it
+causes the preprocessor to treat comments as tokens in their own right.
+For example, comments appearing at the start of what would be a
+directive line have the effect of turning that line into an ordinary
+source line, since the first token on the line is no longer a \fB#\fR.
+.IP "\fB\-CC\fR" 4
+.IX Item "-CC"
+Do not discard comments, including during macro expansion.  This is
+like \fB\-C\fR, except that comments contained within macros are
+also passed through to the output file where the macro is expanded.
+.Sp
+In addition to the side-effects of the \fB\-C\fR option, the
+\&\fB\-CC\fR option causes all \*(C+\-style comments inside a macro
+to be converted to C\-style comments.  This is to prevent later use
+of that macro from inadvertently commenting out the remainder of
+the source line.
+.Sp
+The \fB\-CC\fR option is generally used to support lint comments.
+.IP "\fB\-traditional\-cpp\fR" 4
+.IX Item "-traditional-cpp"
+Try to imitate the behavior of old-fashioned C preprocessors, as
+opposed to \s-1ISO C\s0 preprocessors.
+.IP "\fB\-trigraphs\fR" 4
+.IX Item "-trigraphs"
+Process trigraph sequences.
+These are three-character sequences, all starting with \fB??\fR, that
+are defined by \s-1ISO C\s0 to stand for single characters.  For example,
+\&\fB??/\fR stands for \fB\e\fR, so \fB'??/n'\fR is a character
+constant for a newline.  By default, \s-1GCC\s0 ignores trigraphs, but in
+standard-conforming modes it converts them.  See the \fB\-std\fR and
+\&\fB\-ansi\fR options.
+.Sp
+The nine trigraphs and their replacements are
+.Sp
+.Vb 2
+\&        Trigraph:       ??(  ??)  ??<  ??>  ??=  ??/  ??\*(Aq  ??!  ??\-
+\&        Replacement:      [    ]    {    }    #    \e    ^    |    ~
+.Ve
+.IP "\fB\-remap\fR" 4
+.IX Item "-remap"
+Enable special code to work around file systems which only permit very
+short file names, such as MS-DOS.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+.PD 0
+.IP "\fB\-\-target\-help\fR" 4
+.IX Item "--target-help"
+.PD
+Print text describing all the command line options instead of
+preprocessing anything.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+Verbose mode.  Print out \s-1GNU CPP\s0's version number at the beginning of
+execution, and report the final form of the include path.
+.IP "\fB\-H\fR" 4
+.IX Item "-H"
+Print the name of each header file used, in addition to other normal
+activities.  Each name is indented to show how deep in the
+\&\fB#include\fR stack it is.  Precompiled header files are also
+printed, even if they are found to be invalid; an invalid precompiled
+header file is printed with \fB...x\fR and a valid one with \fB...!\fR .
+.IP "\fB\-version\fR" 4
+.IX Item "-version"
+.PD 0
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+.PD
+Print out \s-1GNU CPP\s0's version number.  With one dash, proceed to
+preprocess as normal.  With two dashes, exit immediately.
+.SS "Passing Options to the Assembler"
+.IX Subsection "Passing Options to the Assembler"
+You can pass options to the assembler.
+.IP "\fB\-Wa,\fR\fIoption\fR" 4
+.IX Item "-Wa,option"
+Pass \fIoption\fR as an option to the assembler.  If \fIoption\fR
+contains commas, it is split into multiple options at the commas.
+.IP "\fB\-Xassembler\fR \fIoption\fR" 4
+.IX Item "-Xassembler option"
+Pass \fIoption\fR as an option to the assembler.  You can use this to
+supply system-specific assembler options that \s-1GCC\s0 does not
+recognize.
+.Sp
+If you want to pass an option that takes an argument, you must use
+\&\fB\-Xassembler\fR twice, once for the option and once for the argument.
+.SS "Options for Linking"
+.IX Subsection "Options for Linking"
+These options come into play when the compiler links object files into
+an executable output file.  They are meaningless if the compiler is
+not doing a link step.
+.IP "\fIobject-file-name\fR" 4
+.IX Item "object-file-name"
+A file name that does not end in a special recognized suffix is
+considered to name an object file or library.  (Object files are
+distinguished from libraries by the linker according to the file
+contents.)  If linking is done, these object files are used as input
+to the linker.
+.IP "\fB\-c\fR" 4
+.IX Item "-c"
+.PD 0
+.IP "\fB\-S\fR" 4
+.IX Item "-S"
+.IP "\fB\-E\fR" 4
+.IX Item "-E"
+.PD
+If any of these options is used, then the linker is not run, and
+object file names should not be used as arguments.
+.IP "\fB\-l\fR\fIlibrary\fR" 4
+.IX Item "-llibrary"
+.PD 0
+.IP "\fB\-l\fR \fIlibrary\fR" 4
+.IX Item "-l library"
+.PD
+Search the library named \fIlibrary\fR when linking.  (The second
+alternative with the library as a separate argument is only for
+\&\s-1POSIX\s0 compliance and is not recommended.)
+.Sp
+It makes a difference where in the command you write this option; the
+linker searches and processes libraries and object files in the order they
+are specified.  Thus, \fBfoo.o \-lz bar.o\fR searches library \fBz\fR
+after file \fIfoo.o\fR but before \fIbar.o\fR.  If \fIbar.o\fR refers
+to functions in \fBz\fR, those functions may not be loaded.
+.Sp
+The linker searches a standard list of directories for the library,
+which is actually a file named \fIlib\fIlibrary\fI.a\fR.  The linker
+then uses this file as if it had been specified precisely by name.
+.Sp
+The directories searched include several standard system directories
+plus any that you specify with \fB\-L\fR.
+.Sp
+Normally the files found this way are library files\-\-\-archive files
+whose members are object files.  The linker handles an archive file by
+scanning through it for members which define symbols that have so far
+been referenced but not defined.  But if the file that is found is an
+ordinary object file, it is linked in the usual fashion.  The only
+difference between using an \fB\-l\fR option and specifying a file name
+is that \fB\-l\fR surrounds \fIlibrary\fR with \fBlib\fR and \fB.a\fR
+and searches several directories.
+.IP "\fB\-lobjc\fR" 4
+.IX Item "-lobjc"
+You need this special case of the \fB\-l\fR option in order to
+link an Objective-C or Objective\-\*(C+ program.
+.IP "\fB\-nostartfiles\fR" 4
+.IX Item "-nostartfiles"
+Do not use the standard system startup files when linking.
+The standard system libraries are used normally, unless \fB\-nostdlib\fR
+or \fB\-nodefaultlibs\fR is used.
+.IP "\fB\-nodefaultlibs\fR" 4
+.IX Item "-nodefaultlibs"
+Do not use the standard system libraries when linking.
+Only the libraries you specify are passed to the linker, and options
+specifying linkage of the system libraries, such as \f(CW\*(C`\-static\-libgcc\*(C'\fR
+or \f(CW\*(C`\-shared\-libgcc\*(C'\fR, are ignored.  
+The standard startup files are used normally, unless \fB\-nostartfiles\fR
+is used.
+.Sp
+The compiler may generate calls to \f(CW\*(C`memcmp\*(C'\fR,
+\&\f(CW\*(C`memset\*(C'\fR, \f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR.
+These entries are usually resolved by entries in
+libc.  These entry points should be supplied through some other
+mechanism when this option is specified.
+.IP "\fB\-nostdlib\fR" 4
+.IX Item "-nostdlib"
+Do not use the standard system startup files or libraries when linking.
+No startup files and only the libraries you specify are passed to
+the linker, and options specifying linkage of the system libraries, such as
+\&\f(CW\*(C`\-static\-libgcc\*(C'\fR or \f(CW\*(C`\-shared\-libgcc\*(C'\fR, are ignored.
+.Sp
+The compiler may generate calls to \f(CW\*(C`memcmp\*(C'\fR, \f(CW\*(C`memset\*(C'\fR,
+\&\f(CW\*(C`memcpy\*(C'\fR and \f(CW\*(C`memmove\*(C'\fR.
+These entries are usually resolved by entries in
+libc.  These entry points should be supplied through some other
+mechanism when this option is specified.
+.Sp
+One of the standard libraries bypassed by \fB\-nostdlib\fR and
+\&\fB\-nodefaultlibs\fR is \fIlibgcc.a\fR, a library of internal subroutines
+which \s-1GCC\s0 uses to overcome shortcomings of particular machines, or special
+needs for some languages.
+.Sp
+In most cases, you need \fIlibgcc.a\fR even when you want to avoid
+other standard libraries.  In other words, when you specify \fB\-nostdlib\fR
+or \fB\-nodefaultlibs\fR you should usually specify \fB\-lgcc\fR as well.
+This ensures that you have no unresolved references to internal \s-1GCC\s0
+library subroutines.
+(An example of such an internal subroutine is \fB_\|_main\fR, used to ensure \*(C+
+constructors are called.)
+.IP "\fB\-pie\fR" 4
+.IX Item "-pie"
+Produce a position independent executable on targets that support it.
+For predictable results, you must also specify the same set of options
+used for compilation (\fB\-fpie\fR, \fB\-fPIE\fR,
+or model suboptions) when you specify this linker option.
+.IP "\fB\-rdynamic\fR" 4
+.IX Item "-rdynamic"
+Pass the flag \fB\-export\-dynamic\fR to the \s-1ELF\s0 linker, on targets
+that support it. This instructs the linker to add all symbols, not
+only used ones, to the dynamic symbol table. This option is needed
+for some uses of \f(CW\*(C`dlopen\*(C'\fR or to allow obtaining backtraces
+from within a program.
+.IP "\fB\-s\fR" 4
+.IX Item "-s"
+Remove all symbol table and relocation information from the executable.
+.IP "\fB\-static\fR" 4
+.IX Item "-static"
+On systems that support dynamic linking, this prevents linking with the shared
+libraries.  On other systems, this option has no effect.
+.IP "\fB\-shared\fR" 4
+.IX Item "-shared"
+Produce a shared object which can then be linked with other objects to
+form an executable.  Not all systems support this option.  For predictable
+results, you must also specify the same set of options used for compilation
+(\fB\-fpic\fR, \fB\-fPIC\fR, or model suboptions) when
+you specify this linker option.[1]
+.IP "\fB\-shared\-libgcc\fR" 4
+.IX Item "-shared-libgcc"
+.PD 0
+.IP "\fB\-static\-libgcc\fR" 4
+.IX Item "-static-libgcc"
+.PD
+On systems that provide \fIlibgcc\fR as a shared library, these options
+force the use of either the shared or static version, respectively.
+If no shared version of \fIlibgcc\fR was built when the compiler was
+configured, these options have no effect.
+.Sp
+There are several situations in which an application should use the
+shared \fIlibgcc\fR instead of the static version.  The most common
+of these is when the application wishes to throw and catch exceptions
+across different shared libraries.  In that case, each of the libraries
+as well as the application itself should use the shared \fIlibgcc\fR.
+.Sp
+Therefore, the G++ and \s-1GCJ\s0 drivers automatically add
+\&\fB\-shared\-libgcc\fR whenever you build a shared library or a main
+executable, because \*(C+ and Java programs typically use exceptions, so
+this is the right thing to do.
+.Sp
+If, instead, you use the \s-1GCC\s0 driver to create shared libraries, you may
+find that they are not always linked with the shared \fIlibgcc\fR.
+If \s-1GCC\s0 finds, at its configuration time, that you have a non-GNU linker
+or a \s-1GNU\s0 linker that does not support option \fB\-\-eh\-frame\-hdr\fR,
+it links the shared version of \fIlibgcc\fR into shared libraries
+by default.  Otherwise, it takes advantage of the linker and optimizes
+away the linking with the shared version of \fIlibgcc\fR, linking with
+the static version of libgcc by default.  This allows exceptions to
+propagate through such shared libraries, without incurring relocation
+costs at library load time.
+.Sp
+However, if a library or main executable is supposed to throw or catch
+exceptions, you must link it using the G++ or \s-1GCJ\s0 driver, as appropriate
+for the languages used in the program, or using the option
+\&\fB\-shared\-libgcc\fR, such that it is linked with the shared
+\&\fIlibgcc\fR.
+.IP "\fB\-static\-libasan\fR" 4
+.IX Item "-static-libasan"
+When the \fB\-fsanitize=address\fR option is used to link a program,
+the \s-1GCC\s0 driver automatically links against \fBlibasan\fR.  If
+\&\fIlibasan\fR is available as a shared library, and the \fB\-static\fR
+option is not used, then this links against the shared version of
+\&\fIlibasan\fR.  The \fB\-static\-libasan\fR option directs the \s-1GCC\s0
+driver to link \fIlibasan\fR statically, without necessarily linking
+other libraries statically.
+.IP "\fB\-static\-libtsan\fR" 4
+.IX Item "-static-libtsan"
+When the \fB\-fsanitize=thread\fR option is used to link a program,
+the \s-1GCC\s0 driver automatically links against \fBlibtsan\fR.  If
+\&\fIlibtsan\fR is available as a shared library, and the \fB\-static\fR
+option is not used, then this links against the shared version of
+\&\fIlibtsan\fR.  The \fB\-static\-libtsan\fR option directs the \s-1GCC\s0
+driver to link \fIlibtsan\fR statically, without necessarily linking
+other libraries statically.
+.IP "\fB\-static\-liblsan\fR" 4
+.IX Item "-static-liblsan"
+When the \fB\-fsanitize=leak\fR option is used to link a program,
+the \s-1GCC\s0 driver automatically links against \fBliblsan\fR.  If
+\&\fIliblsan\fR is available as a shared library, and the \fB\-static\fR
+option is not used, then this links against the shared version of
+\&\fIliblsan\fR.  The \fB\-static\-liblsan\fR option directs the \s-1GCC\s0
+driver to link \fIliblsan\fR statically, without necessarily linking
+other libraries statically.
+.IP "\fB\-static\-libubsan\fR" 4
+.IX Item "-static-libubsan"
+When the \fB\-fsanitize=undefined\fR option is used to link a program,
+the \s-1GCC\s0 driver automatically links against \fBlibubsan\fR.  If
+\&\fIlibubsan\fR is available as a shared library, and the \fB\-static\fR
+option is not used, then this links against the shared version of
+\&\fIlibubsan\fR.  The \fB\-static\-libubsan\fR option directs the \s-1GCC\s0
+driver to link \fIlibubsan\fR statically, without necessarily linking
+other libraries statically.
+.IP "\fB\-static\-libstdc++\fR" 4
+.IX Item "-static-libstdc++"
+When the \fBg++\fR program is used to link a \*(C+ program, it
+normally automatically links against \fBlibstdc++\fR.  If
+\&\fIlibstdc++\fR is available as a shared library, and the
+\&\fB\-static\fR option is not used, then this links against the
+shared version of \fIlibstdc++\fR.  That is normally fine.  However, it
+is sometimes useful to freeze the version of \fIlibstdc++\fR used by
+the program without going all the way to a fully static link.  The
+\&\fB\-static\-libstdc++\fR option directs the \fBg++\fR driver to
+link \fIlibstdc++\fR statically, without necessarily linking other
+libraries statically.
+.IP "\fB\-symbolic\fR" 4
+.IX Item "-symbolic"
+Bind references to global symbols when building a shared object.  Warn
+about any unresolved references (unless overridden by the link editor
+option \fB\-Xlinker \-z \-Xlinker defs\fR).  Only a few systems support
+this option.
+.IP "\fB\-T\fR \fIscript\fR" 4
+.IX Item "-T script"
+Use \fIscript\fR as the linker script.  This option is supported by most
+systems using the \s-1GNU\s0 linker.  On some targets, such as bare-board
+targets without an operating system, the \fB\-T\fR option may be required
+when linking to avoid references to undefined symbols.
+.IP "\fB\-Xlinker\fR \fIoption\fR" 4
+.IX Item "-Xlinker option"
+Pass \fIoption\fR as an option to the linker.  You can use this to
+supply system-specific linker options that \s-1GCC\s0 does not recognize.
+.Sp
+If you want to pass an option that takes a separate argument, you must use
+\&\fB\-Xlinker\fR twice, once for the option and once for the argument.
+For example, to pass \fB\-assert definitions\fR, you must write
+\&\fB\-Xlinker \-assert \-Xlinker definitions\fR.  It does not work to write
+\&\fB\-Xlinker \*(L"\-assert definitions\*(R"\fR, because this passes the entire
+string as a single argument, which is not what the linker expects.
+.Sp
+When using the \s-1GNU\s0 linker, it is usually more convenient to pass
+arguments to linker options using the \fIoption\fR\fB=\fR\fIvalue\fR
+syntax than as separate arguments.  For example, you can specify
+\&\fB\-Xlinker \-Map=output.map\fR rather than
+\&\fB\-Xlinker \-Map \-Xlinker output.map\fR.  Other linkers may not support
+this syntax for command-line options.
+.IP "\fB\-Wl,\fR\fIoption\fR" 4
+.IX Item "-Wl,option"
+Pass \fIoption\fR as an option to the linker.  If \fIoption\fR contains
+commas, it is split into multiple options at the commas.  You can use this
+syntax to pass an argument to the option.
+For example, \fB\-Wl,\-Map,output.map\fR passes \fB\-Map output.map\fR to the
+linker.  When using the \s-1GNU\s0 linker, you can also get the same effect with
+\&\fB\-Wl,\-Map=output.map\fR.
+.IP "\fB\-u\fR \fIsymbol\fR" 4
+.IX Item "-u symbol"
+Pretend the symbol \fIsymbol\fR is undefined, to force linking of
+library modules to define it.  You can use \fB\-u\fR multiple times with
+different symbols to force loading of additional library modules.
+.SS "Options for Directory Search"
+.IX Subsection "Options for Directory Search"
+These options specify directories to search for header files, for
+libraries and for parts of the compiler:
+.IP "\fB\-I\fR\fIdir\fR" 4
+.IX Item "-Idir"
+Add the directory \fIdir\fR to the head of the list of directories to be
+searched for header files.  This can be used to override a system header
+file, substituting your own version, since these directories are
+searched before the system header file directories.  However, you should
+not use this option to add directories that contain vendor-supplied
+system header files (use \fB\-isystem\fR for that).  If you use more than
+one \fB\-I\fR option, the directories are scanned in left-to-right
+order; the standard system directories come after.
+.Sp
+If a standard system include directory, or a directory specified with
+\&\fB\-isystem\fR, is also specified with \fB\-I\fR, the \fB\-I\fR
+option is ignored.  The directory is still searched but as a
+system directory at its normal position in the system include chain.
+This is to ensure that \s-1GCC\s0's procedure to fix buggy system headers and
+the ordering for the \f(CW\*(C`include_next\*(C'\fR directive are not inadvertently changed.
+If you really need to change the search order for system directories,
+use the \fB\-nostdinc\fR and/or \fB\-isystem\fR options.
+.IP "\fB\-iplugindir=\fR\fIdir\fR" 4
+.IX Item "-iplugindir=dir"
+Set the directory to search for plugins that are passed
+by \fB\-fplugin=\fR\fIname\fR instead of
+\&\fB\-fplugin=\fR\fIpath\fR\fB/\fR\fIname\fR\fB.so\fR.  This option is not meant
+to be used by the user, but only passed by the driver.
+.IP "\fB\-iquote\fR\fIdir\fR" 4
+.IX Item "-iquotedir"
+Add the directory \fIdir\fR to the head of the list of directories to
+be searched for header files only for the case of \fB#include
+"\fR\fIfile\fR\fB"\fR; they are not searched for \fB#include <\fR\fIfile\fR\fB>\fR,
+otherwise just like \fB\-I\fR.
+.IP "\fB\-L\fR\fIdir\fR" 4
+.IX Item "-Ldir"
+Add directory \fIdir\fR to the list of directories to be searched
+for \fB\-l\fR.
+.IP "\fB\-B\fR\fIprefix\fR" 4
+.IX Item "-Bprefix"
+This option specifies where to find the executables, libraries,
+include files, and data files of the compiler itself.
+.Sp
+The compiler driver program runs one or more of the subprograms
+\&\fBcpp\fR, \fBcc1\fR, \fBas\fR and \fBld\fR.  It tries
+\&\fIprefix\fR as a prefix for each program it tries to run, both with and
+without \fImachine\fR\fB/\fR\fIversion\fR\fB/\fR.
+.Sp
+For each subprogram to be run, the compiler driver first tries the
+\&\fB\-B\fR prefix, if any.  If that name is not found, or if \fB\-B\fR
+is not specified, the driver tries two standard prefixes, 
+\&\fI/usr/lib/gcc/\fR and \fI/usr/local/lib/gcc/\fR.  If neither of
+those results in a file name that is found, the unmodified program
+name is searched for using the directories specified in your
+\&\fB\s-1PATH\s0\fR environment variable.
+.Sp
+The compiler checks to see if the path provided by the \fB\-B\fR
+refers to a directory, and if necessary it adds a directory
+separator character at the end of the path.
+.Sp
+\&\fB\-B\fR prefixes that effectively specify directory names also apply
+to libraries in the linker, because the compiler translates these
+options into \fB\-L\fR options for the linker.  They also apply to
+include files in the preprocessor, because the compiler translates these
+options into \fB\-isystem\fR options for the preprocessor.  In this case,
+the compiler appends \fBinclude\fR to the prefix.
+.Sp
+The runtime support file \fIlibgcc.a\fR can also be searched for using
+the \fB\-B\fR prefix, if needed.  If it is not found there, the two
+standard prefixes above are tried, and that is all.  The file is left
+out of the link if it is not found by those means.
+.Sp
+Another way to specify a prefix much like the \fB\-B\fR prefix is to use
+the environment variable \fB\s-1GCC_EXEC_PREFIX\s0\fR.
+.Sp
+As a special kludge, if the path provided by \fB\-B\fR is
+\&\fI[dir/]stage\fIN\fI/\fR, where \fIN\fR is a number in the range 0 to
+9, then it is replaced by \fI[dir/]include\fR.  This is to help
+with boot-strapping the compiler.
+.IP "\fB\-specs=\fR\fIfile\fR" 4
+.IX Item "-specs=file"
+Process \fIfile\fR after the compiler reads in the standard \fIspecs\fR
+file, in order to override the defaults which the \fBgcc\fR driver
+program uses when determining what switches to pass to \fBcc1\fR,
+\&\fBcc1plus\fR, \fBas\fR, \fBld\fR, etc.  More than one
+\&\fB\-specs=\fR\fIfile\fR can be specified on the command line, and they
+are processed in order, from left to right.
+.IP "\fB\-\-sysroot=\fR\fIdir\fR" 4
+.IX Item "--sysroot=dir"
+Use \fIdir\fR as the logical root directory for headers and libraries.
+For example, if the compiler normally searches for headers in
+\&\fI/usr/include\fR and libraries in \fI/usr/lib\fR, it instead
+searches \fI\fIdir\fI/usr/include\fR and \fI\fIdir\fI/usr/lib\fR.
+.Sp
+If you use both this option and the \fB\-isysroot\fR option, then
+the \fB\-\-sysroot\fR option applies to libraries, but the
+\&\fB\-isysroot\fR option applies to header files.
+.Sp
+The \s-1GNU\s0 linker (beginning with version 2.16) has the necessary support
+for this option.  If your linker does not support this option, the
+header file aspect of \fB\-\-sysroot\fR still works, but the
+library aspect does not.
+.IP "\fB\-\-no\-sysroot\-suffix\fR" 4
+.IX Item "--no-sysroot-suffix"
+For some targets, a suffix is added to the root directory specified
+with \fB\-\-sysroot\fR, depending on the other options used, so that
+headers may for example be found in
+\&\fI\fIdir\fI/\fIsuffix\fI/usr/include\fR instead of
+\&\fI\fIdir\fI/usr/include\fR.  This option disables the addition of
+such a suffix.
+.IP "\fB\-I\-\fR" 4
+.IX Item "-I-"
+This option has been deprecated.  Please use \fB\-iquote\fR instead for
+\&\fB\-I\fR directories before the \fB\-I\-\fR and remove the \fB\-I\-\fR.
+Any directories you specify with \fB\-I\fR options before the \fB\-I\-\fR
+option are searched only for the case of \fB#include "\fR\fIfile\fR\fB"\fR;
+they are not searched for \fB#include <\fR\fIfile\fR\fB>\fR.
+.Sp
+If additional directories are specified with \fB\-I\fR options after
+the \fB\-I\-\fR, these directories are searched for all \fB#include\fR
+directives.  (Ordinarily \fIall\fR \fB\-I\fR directories are used
+this way.)
+.Sp
+In addition, the \fB\-I\-\fR option inhibits the use of the current
+directory (where the current input file came from) as the first search
+directory for \fB#include "\fR\fIfile\fR\fB"\fR.  There is no way to
+override this effect of \fB\-I\-\fR.  With \fB\-I.\fR you can specify
+searching the directory that is current when the compiler is
+invoked.  That is not exactly the same as what the preprocessor does
+by default, but it is often satisfactory.
+.Sp
+\&\fB\-I\-\fR does not inhibit the use of the standard system directories
+for header files.  Thus, \fB\-I\-\fR and \fB\-nostdinc\fR are
+independent.
+.SS "Specifying Target Machine and Compiler Version"
+.IX Subsection "Specifying Target Machine and Compiler Version"
+The usual way to run \s-1GCC\s0 is to run the executable called \fBgcc\fR, or
+\&\fImachine\fR\fB\-gcc\fR when cross-compiling, or
+\&\fImachine\fR\fB\-gcc\-\fR\fIversion\fR to run a version other than the
+one that was installed last.
+.SS "Hardware Models and Configurations"
+.IX Subsection "Hardware Models and Configurations"
+Each target machine types can have its own
+special options, starting with \fB\-m\fR, to choose among various
+hardware models or configurations\-\-\-for example, 68010 vs 68020,
+floating coprocessor or none.  A single installed version of the
+compiler can compile for any model or configuration, according to the
+options specified.
+.PP
+Some configurations of the compiler also support additional special
+options, usually for compatibility with other compilers on the same
+platform.
+.PP
+\fIAArch64 Options\fR
+.IX Subsection "AArch64 Options"
+.PP
+These options are defined for AArch64 implementations:
+.IP "\fB\-mabi=\fR\fIname\fR" 4
+.IX Item "-mabi=name"
+Generate code for the specified data model.  Permissible values
+are \fBilp32\fR for SysV-like data model where int, long int and pointer
+are 32\-bit, and \fBlp64\fR for SysV-like data model where int is 32\-bit,
+but long int and pointer are 64\-bit.
+.Sp
+The default depends on the specific target configuration.  Note that
+the \s-1LP64\s0 and \s-1ILP32\s0 ABIs are not link-compatible; you must compile your
+entire program with the same \s-1ABI,\s0 and link with a compatible set of libraries.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate big-endian code.  This is the default when \s-1GCC\s0 is configured for an
+\&\fBaarch64_be\-*\-*\fR target.
+.IP "\fB\-mgeneral\-regs\-only\fR" 4
+.IX Item "-mgeneral-regs-only"
+Generate code which uses only the general registers.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate little-endian code.  This is the default when \s-1GCC\s0 is configured for an
+\&\fBaarch64\-*\-*\fR but not an \fBaarch64_be\-*\-*\fR target.
+.IP "\fB\-mcmodel=tiny\fR" 4
+.IX Item "-mcmodel=tiny"
+Generate code for the tiny code model.  The program and its statically defined
+symbols must be within 1GB of each other.  Pointers are 64 bits.  Programs can
+be statically or dynamically linked.  This model is not fully implemented and
+mostly treated as \fBsmall\fR.
+.IP "\fB\-mcmodel=small\fR" 4
+.IX Item "-mcmodel=small"
+Generate code for the small code model.  The program and its statically defined
+symbols must be within 4GB of each other.  Pointers are 64 bits.  Programs can
+be statically or dynamically linked.  This is the default code model.
+.IP "\fB\-mcmodel=large\fR" 4
+.IX Item "-mcmodel=large"
+Generate code for the large code model.  This makes no assumptions about
+addresses and sizes of sections.  Pointers are 64 bits.  Programs can be
+statically linked only.
+.IP "\fB\-mstrict\-align\fR" 4
+.IX Item "-mstrict-align"
+Do not assume that unaligned memory references will be handled by the system.
+.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
+.IX Item "-momit-leaf-frame-pointer"
+.PD 0
+.IP "\fB\-mno\-omit\-leaf\-frame\-pointer\fR" 4
+.IX Item "-mno-omit-leaf-frame-pointer"
+.PD
+Omit or keep the frame pointer in leaf functions.  The former behaviour is the
+default.
+.IP "\fB\-mtls\-dialect=desc\fR" 4
+.IX Item "-mtls-dialect=desc"
+Use \s-1TLS\s0 descriptors as the thread-local storage mechanism for dynamic accesses
+of \s-1TLS\s0 variables.  This is the default.
+.IP "\fB\-mtls\-dialect=traditional\fR" 4
+.IX Item "-mtls-dialect=traditional"
+Use traditional \s-1TLS\s0 as the thread-local storage mechanism for dynamic accesses
+of \s-1TLS\s0 variables.
+.IP "\fB\-march=\fR\fIname\fR" 4
+.IX Item "-march=name"
+Specify the name of the target architecture, optionally suffixed by one or
+more feature modifiers.  This option has the form
+\&\fB\-march=\fR\fIarch\fR{\fB+\fR[\fBno\fR]\fIfeature\fR}*, where the
+only permissible value for \fIarch\fR is \fBarmv8\-a\fR.  The permissible
+values for \fIfeature\fR are documented in the sub-section below.
+.Sp
+Where conflicting feature modifiers are specified, the right-most feature is
+used.
+.Sp
+\&\s-1GCC\s0 uses this name to determine what kind of instructions it can emit when
+generating assembly code.
+.Sp
+Where \fB\-march\fR is specified without either of \fB\-mtune\fR
+or \fB\-mcpu\fR also being specified, the code will be tuned to perform
+well across a range of target processors implementing the target
+architecture.
+.IP "\fB\-mtune=\fR\fIname\fR" 4
+.IX Item "-mtune=name"
+Specify the name of the target processor for which \s-1GCC\s0 should tune the
+performance of the code.  Permissible values for this option are:
+\&\fBgeneric\fR, \fBcortex\-a53\fR, \fBcortex\-a57\fR.
+.Sp
+Additionally, this option can specify that \s-1GCC\s0 should tune the performance
+of the code for a big.LITTLE system.  The only permissible value is
+\&\fBcortex\-a57.cortex\-a53\fR.
+.Sp
+Where none of \fB\-mtune=\fR, \fB\-mcpu=\fR or \fB\-march=\fR
+are specified, the code will be tuned to perform well across a range
+of target processors.
+.Sp
+This option cannot be suffixed by feature modifiers.
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Specify the name of the target processor, optionally suffixed by one or more
+feature modifiers.  This option has the form
+\&\fB\-mcpu=\fR\fIcpu\fR{\fB+\fR[\fBno\fR]\fIfeature\fR}*, where the
+permissible values for \fIcpu\fR are the same as those available for
+\&\fB\-mtune\fR.
+.Sp
+The permissible values for \fIfeature\fR are documented in the sub-section
+below.
+.Sp
+Where conflicting feature modifiers are specified, the right-most feature is
+used.
+.Sp
+\&\s-1GCC\s0 uses this name to determine what kind of instructions it can emit when
+generating assembly code (as if by \fB\-march\fR) and to determine
+the target processor for which to tune for performance (as if
+by \fB\-mtune\fR).  Where this option is used in conjunction
+with \fB\-march\fR or \fB\-mtune\fR, those options take precedence
+over the appropriate part of this option.
+.PP
+\fB\-march\fR and \fB\-mcpu\fR feature modifiers
+.IX Subsection "-march and -mcpu feature modifiers"
+.PP
+Feature modifiers used with \fB\-march\fR and \fB\-mcpu\fR can be one
+the following:
+.IP "\fBcrc\fR" 4
+.IX Item "crc"
+Enable \s-1CRC\s0 extension.
+.IP "\fBcrypto\fR" 4
+.IX Item "crypto"
+Enable Crypto extension.  This implies Advanced \s-1SIMD\s0 is enabled.
+.IP "\fBfp\fR" 4
+.IX Item "fp"
+Enable floating-point instructions.
+.IP "\fBsimd\fR" 4
+.IX Item "simd"
+Enable Advanced \s-1SIMD\s0 instructions.  This implies floating-point instructions
+are enabled.  This is the default for all current possible values for options
+\&\fB\-march\fR and \fB\-mcpu=\fR.
+.PP
+\fIAdapteva Epiphany Options\fR
+.IX Subsection "Adapteva Epiphany Options"
+.PP
+These \fB\-m\fR options are defined for Adapteva Epiphany:
+.IP "\fB\-mhalf\-reg\-file\fR" 4
+.IX Item "-mhalf-reg-file"
+Don't allocate any register in the range \f(CW\*(C`r32\*(C'\fR...\f(CW\*(C`r63\*(C'\fR.
+That allows code to run on hardware variants that lack these registers.
+.IP "\fB\-mprefer\-short\-insn\-regs\fR" 4
+.IX Item "-mprefer-short-insn-regs"
+Preferrentially allocate registers that allow short instruction generation.
+This can result in increased instruction count, so this may either reduce or
+increase overall code size.
+.IP "\fB\-mbranch\-cost=\fR\fInum\fR" 4
+.IX Item "-mbranch-cost=num"
+Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
+This cost is only a heuristic and is not guaranteed to produce
+consistent results across releases.
+.IP "\fB\-mcmove\fR" 4
+.IX Item "-mcmove"
+Enable the generation of conditional moves.
+.IP "\fB\-mnops=\fR\fInum\fR" 4
+.IX Item "-mnops=num"
+Emit \fInum\fR NOPs before every other generated instruction.
+.IP "\fB\-mno\-soft\-cmpsf\fR" 4
+.IX Item "-mno-soft-cmpsf"
+For single-precision floating-point comparisons, emit an \f(CW\*(C`fsub\*(C'\fR instruction
+and test the flags.  This is faster than a software comparison, but can
+get incorrect results in the presence of NaNs, or when two different small
+numbers are compared such that their difference is calculated as zero.
+The default is \fB\-msoft\-cmpsf\fR, which uses slower, but IEEE-compliant,
+software comparisons.
+.IP "\fB\-mstack\-offset=\fR\fInum\fR" 4
+.IX Item "-mstack-offset=num"
+Set the offset between the top of the stack and the stack pointer.
+E.g., a value of 8 means that the eight bytes in the range \f(CW\*(C`sp+0...sp+7\*(C'\fR
+can be used by leaf functions without stack allocation.
+Values other than \fB8\fR or \fB16\fR are untested and unlikely to work.
+Note also that this option changes the \s-1ABI\s0; compiling a program with a
+different stack offset than the libraries have been compiled with
+generally does not work.
+This option can be useful if you want to evaluate if a different stack
+offset would give you better code, but to actually use a different stack
+offset to build working programs, it is recommended to configure the
+toolchain with the appropriate \fB\-\-with\-stack\-offset=\fR\fInum\fR option.
+.IP "\fB\-mno\-round\-nearest\fR" 4
+.IX Item "-mno-round-nearest"
+Make the scheduler assume that the rounding mode has been set to
+truncating.  The default is \fB\-mround\-nearest\fR.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+If not otherwise specified by an attribute, assume all calls might be beyond
+the offset range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, and therefore load the
+function address into a register before performing a (otherwise direct) call.
+This is the default.
+.IP "\fB\-mshort\-calls\fR" 4
+.IX Item "-mshort-calls"
+If not otherwise specified by an attribute, assume all direct calls are
+in the range of the \f(CW\*(C`b\*(C'\fR / \f(CW\*(C`bl\*(C'\fR instructions, so use these instructions
+for direct calls.  The default is \fB\-mlong\-calls\fR.
+.IP "\fB\-msmall16\fR" 4
+.IX Item "-msmall16"
+Assume addresses can be loaded as 16\-bit unsigned values.  This does not
+apply to function addresses for which \fB\-mlong\-calls\fR semantics
+are in effect.
+.IP "\fB\-mfp\-mode=\fR\fImode\fR" 4
+.IX Item "-mfp-mode=mode"
+Set the prevailing mode of the floating-point unit.
+This determines the floating-point mode that is provided and expected
+at function call and return time.  Making this mode match the mode you
+predominantly need at function start can make your programs smaller and
+faster by avoiding unnecessary mode switches.
+.Sp
+\&\fImode\fR can be set to one the following values:
+.RS 4
+.IP "\fBcaller\fR" 4
+.IX Item "caller"
+Any mode at function entry is valid, and retained or restored when
+the function returns, and when it calls other functions.
+This mode is useful for compiling libraries or other compilation units
+you might want to incorporate into different programs with different
+prevailing \s-1FPU\s0 modes, and the convenience of being able to use a single
+object file outweighs the size and speed overhead for any extra
+mode switching that might be needed, compared with what would be needed
+with a more specific choice of prevailing \s-1FPU\s0 mode.
+.IP "\fBtruncate\fR" 4
+.IX Item "truncate"
+This is the mode used for floating-point calculations with
+truncating (i.e. round towards zero) rounding mode.  That includes
+conversion from floating point to integer.
+.IP "\fBround-nearest\fR" 4
+.IX Item "round-nearest"
+This is the mode used for floating-point calculations with
+round-to-nearest-or-even rounding mode.
+.IP "\fBint\fR" 4
+.IX Item "int"
+This is the mode used to perform integer calculations in the \s-1FPU,\s0 e.g.
+integer multiply, or integer multiply-and-accumulate.
+.RE
+.RS 4
+.Sp
+The default is \fB\-mfp\-mode=caller\fR
+.RE
+.IP "\fB\-mnosplit\-lohi\fR" 4
+.IX Item "-mnosplit-lohi"
+.PD 0
+.IP "\fB\-mno\-postinc\fR" 4
+.IX Item "-mno-postinc"
+.IP "\fB\-mno\-postmodify\fR" 4
+.IX Item "-mno-postmodify"
+.PD
+Code generation tweaks that disable, respectively, splitting of 32\-bit
+loads, generation of post-increment addresses, and generation of
+post-modify addresses.  The defaults are \fBmsplit-lohi\fR,
+\&\fB\-mpost\-inc\fR, and \fB\-mpost\-modify\fR.
+.IP "\fB\-mnovect\-double\fR" 4
+.IX Item "-mnovect-double"
+Change the preferred \s-1SIMD\s0 mode to SImode.  The default is
+\&\fB\-mvect\-double\fR, which uses DImode as preferred \s-1SIMD\s0 mode.
+.IP "\fB\-max\-vect\-align=\fR\fInum\fR" 4
+.IX Item "-max-vect-align=num"
+The maximum alignment for \s-1SIMD\s0 vector mode types.
+\&\fInum\fR may be 4 or 8.  The default is 8.
+Note that this is an \s-1ABI\s0 change, even though many library function
+interfaces are unaffected if they don't use \s-1SIMD\s0 vector modes
+in places that affect size and/or alignment of relevant types.
+.IP "\fB\-msplit\-vecmove\-early\fR" 4
+.IX Item "-msplit-vecmove-early"
+Split vector moves into single word moves before reload.  In theory this
+can give better register allocation, but so far the reverse seems to be
+generally the case.
+.IP "\fB\-m1reg\-\fR\fIreg\fR" 4
+.IX Item "-m1reg-reg"
+Specify a register to hold the constant \-1, which makes loading small negative
+constants and certain bitmasks faster.
+Allowable values for \fIreg\fR are \fBr43\fR and \fBr63\fR,
+which specify use of that register as a fixed register,
+and \fBnone\fR, which means that no register is used for this
+purpose.  The default is \fB\-m1reg\-none\fR.
+.PP
+\fI\s-1ARC\s0 Options\fR
+.IX Subsection "ARC Options"
+.PP
+The following options control the architecture variant for which code
+is being compiled:
+.IP "\fB\-mbarrel\-shifter\fR" 4
+.IX Item "-mbarrel-shifter"
+Generate instructions supported by barrel shifter.  This is the default
+unless \fB\-mcpu=ARC601\fR is in effect.
+.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
+.IX Item "-mcpu=cpu"
+Set architecture type, register usage, and instruction scheduling
+parameters for \fIcpu\fR.  There are also shortcut alias options
+available for backward compatibility and convenience.  Supported
+values for \fIcpu\fR are
+.RS 4
+.IP "\fB\s-1ARC600\s0\fR" 4
+.IX Item "ARC600"
+Compile for \s-1ARC600. \s0 Aliases: \fB\-mA6\fR, \fB\-mARC600\fR.
+.IP "\fB\s-1ARC601\s0\fR" 4
+.IX Item "ARC601"
+Compile for \s-1ARC601. \s0 Alias: \fB\-mARC601\fR.
+.IP "\fB\s-1ARC700\s0\fR" 4
+.IX Item "ARC700"
+Compile for \s-1ARC700. \s0 Aliases: \fB\-mA7\fR, \fB\-mARC700\fR.
+This is the default when configured with \fB\-\-with\-cpu=arc700\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mdpfp\fR" 4
+.IX Item "-mdpfp"
+.PD 0
+.IP "\fB\-mdpfp\-compact\fR" 4
+.IX Item "-mdpfp-compact"
+.PD
+\&\s-1FPX:\s0 Generate Double Precision \s-1FPX\s0 instructions, tuned for the compact
+implementation.
+.IP "\fB\-mdpfp\-fast\fR" 4
+.IX Item "-mdpfp-fast"
+\&\s-1FPX:\s0 Generate Double Precision \s-1FPX\s0 instructions, tuned for the fast
+implementation.
+.IP "\fB\-mno\-dpfp\-lrsr\fR" 4
+.IX Item "-mno-dpfp-lrsr"
+Disable \s-1LR\s0 and \s-1SR\s0 instructions from using \s-1FPX\s0 extension aux registers.
+.IP "\fB\-mea\fR" 4
+.IX Item "-mea"
+Generate Extended arithmetic instructions.  Currently only
+\&\f(CW\*(C`divaw\*(C'\fR, \f(CW\*(C`adds\*(C'\fR, \f(CW\*(C`subs\*(C'\fR, and \f(CW\*(C`sat16\*(C'\fR are
+supported.  This is always enabled for \fB\-mcpu=ARC700\fR.
+.IP "\fB\-mno\-mpy\fR" 4
+.IX Item "-mno-mpy"
+Do not generate mpy instructions for \s-1ARC700.\s0
+.IP "\fB\-mmul32x16\fR" 4
+.IX Item "-mmul32x16"
+Generate 32x16 bit multiply and mac instructions.
+.IP "\fB\-mmul64\fR" 4
+.IX Item "-mmul64"
+Generate mul64 and mulu64 instructions.  Only valid for \fB\-mcpu=ARC600\fR.
+.IP "\fB\-mnorm\fR" 4
+.IX Item "-mnorm"
+Generate norm instruction.  This is the default if \fB\-mcpu=ARC700\fR
+is in effect.
+.IP "\fB\-mspfp\fR" 4
+.IX Item "-mspfp"
+.PD 0
+.IP "\fB\-mspfp\-compact\fR" 4
+.IX Item "-mspfp-compact"
+.PD
+\&\s-1FPX:\s0 Generate Single Precision \s-1FPX\s0 instructions, tuned for the compact
+implementation.
+.IP "\fB\-mspfp\-fast\fR" 4
+.IX Item "-mspfp-fast"
+\&\s-1FPX:\s0 Generate Single Precision \s-1FPX\s0 instructions, tuned for the fast
+implementation.
+.IP "\fB\-msimd\fR" 4
+.IX Item "-msimd"
+Enable generation of \s-1ARC SIMD\s0 instructions via target-specific
+builtins.  Only valid for \fB\-mcpu=ARC700\fR.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+This option ignored; it is provided for compatibility purposes only.
+Software floating point code is emitted by default, and this default
+can overridden by \s-1FPX\s0 options; \fBmspfp\fR, \fBmspfp-compact\fR, or
+\&\fBmspfp-fast\fR for single precision, and \fBmdpfp\fR,
+\&\fBmdpfp-compact\fR, or \fBmdpfp-fast\fR for double precision.
+.IP "\fB\-mswap\fR" 4
+.IX Item "-mswap"
+Generate swap instructions.
+.PP
+The following options are passed through to the assembler, and also
+define preprocessor macro symbols.
+.IP "\fB\-mdsp\-packa\fR" 4
+.IX Item "-mdsp-packa"
+Passed down to the assembler to enable the \s-1DSP\s0 Pack A extensions.
+Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdsp_packa\*(C'\fR.
+.IP "\fB\-mdvbf\fR" 4
+.IX Item "-mdvbf"
+Passed down to the assembler to enable the dual viterbi butterfly
+extension.  Also sets the preprocessor symbol \f(CW\*(C`_\|_Xdvbf\*(C'\fR.
+.IP "\fB\-mlock\fR" 4
+.IX Item "-mlock"
+Passed down to the assembler to enable the Locked Load/Store
+Conditional extension.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xlock\*(C'\fR.
+.IP "\fB\-mmac\-d16\fR" 4
+.IX Item "-mmac-d16"
+Passed down to the assembler.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xxmac_d16\*(C'\fR.
+.IP "\fB\-mmac\-24\fR" 4
+.IX Item "-mmac-24"
+Passed down to the assembler.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xxmac_24\*(C'\fR.
+.IP "\fB\-mrtsc\fR" 4
+.IX Item "-mrtsc"
+Passed down to the assembler to enable the 64\-bit Time-Stamp Counter
+extension instruction.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xrtsc\*(C'\fR.
+.IP "\fB\-mswape\fR" 4
+.IX Item "-mswape"
+Passed down to the assembler to enable the swap byte ordering
+extension instruction.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xswape\*(C'\fR.
+.IP "\fB\-mtelephony\fR" 4
+.IX Item "-mtelephony"
+Passed down to the assembler to enable dual and single operand
+instructions for telephony.  Also sets the preprocessor symbol
+\&\f(CW\*(C`_\|_Xtelephony\*(C'\fR.
+.IP "\fB\-mxy\fR" 4
+.IX Item "-mxy"
+Passed down to the assembler to enable the \s-1XY\s0 Memory extension.  Also
+sets the preprocessor symbol \f(CW\*(C`_\|_Xxy\*(C'\fR.
+.PP
+The following options control how the assembly code is annotated:
+.IP "\fB\-misize\fR" 4
+.IX Item "-misize"
+Annotate assembler instructions with estimated addresses.
+.IP "\fB\-mannotate\-align\fR" 4
+.IX Item "-mannotate-align"
+Explain what alignment considerations lead to the decision to make an
+instruction short or long.
+.PP
+The following options are passed through to the linker:
+.IP "\fB\-marclinux\fR" 4
+.IX Item "-marclinux"
+Passed through to the linker, to specify use of the \f(CW\*(C`arclinux\*(C'\fR emulation.
+This option is enabled by default in tool chains built for
+\&\f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets
+when profiling is not requested.
+.IP "\fB\-marclinux_prof\fR" 4
+.IX Item "-marclinux_prof"
+Passed through to the linker, to specify use of the
+\&\f(CW\*(C`arclinux_prof\*(C'\fR emulation.  This option is enabled by default in
+tool chains built for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and
+\&\f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets when profiling is requested.
+.PP
+The following options control the semantics of generated code:
+.IP "\fB\-mepilogue\-cfi\fR" 4
+.IX Item "-mepilogue-cfi"
+Enable generation of call frame information for epilogues.
+.IP "\fB\-mno\-epilogue\-cfi\fR" 4
+.IX Item "-mno-epilogue-cfi"
+Disable generation of call frame information for epilogues.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+Generate call insns as register indirect calls, thus providing access
+to the full 32\-bit address range.
+.IP "\fB\-mmedium\-calls\fR" 4
+.IX Item "-mmedium-calls"
+Don't use less than 25 bit addressing range for calls, which is the
+offset available for an unconditional branch-and-link
+instruction.  Conditional execution of function calls is suppressed, to
+allow use of the 25\-bit range, rather than the 21\-bit range with
+conditional branch-and-link.  This is the default for tool chains built
+for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets.
+.IP "\fB\-mno\-sdata\fR" 4
+.IX Item "-mno-sdata"
+Do not generate sdata references.  This is the default for tool chains
+built for \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR
+targets.
+.IP "\fB\-mucb\-mcount\fR" 4
+.IX Item "-mucb-mcount"
+Instrument with mcount calls as used in \s-1UCB\s0 code.  I.e. do the
+counting in the callee, not the caller.  By default \s-1ARC\s0 instrumentation
+counts in the caller.
+.IP "\fB\-mvolatile\-cache\fR" 4
+.IX Item "-mvolatile-cache"
+Use ordinarily cached memory accesses for volatile references.  This is the
+default.
+.IP "\fB\-mno\-volatile\-cache\fR" 4
+.IX Item "-mno-volatile-cache"
+Enable cache bypass for volatile references.
+.PP
+The following options fine tune code generation:
+.IP "\fB\-malign\-call\fR" 4
+.IX Item "-malign-call"
+Do alignment optimizations for call instructions.
+.IP "\fB\-mauto\-modify\-reg\fR" 4
+.IX Item "-mauto-modify-reg"
+Enable the use of pre/post modify with register displacement.
+.IP "\fB\-mbbit\-peephole\fR" 4
+.IX Item "-mbbit-peephole"
+Enable bbit peephole2.
+.IP "\fB\-mno\-brcc\fR" 4
+.IX Item "-mno-brcc"
+This option disables a target-specific pass in \fIarc_reorg\fR to
+generate \f(CW\*(C`BRcc\*(C'\fR instructions.  It has no effect on \f(CW\*(C`BRcc\*(C'\fR
+generation driven by the combiner pass.
+.IP "\fB\-mcase\-vector\-pcrel\fR" 4
+.IX Item "-mcase-vector-pcrel"
+Use pc-relative switch case tables \- this enables case table shortening.
+This is the default for \fB\-Os\fR.
+.IP "\fB\-mcompact\-casesi\fR" 4
+.IX Item "-mcompact-casesi"
+Enable compact casesi pattern.
+This is the default for \fB\-Os\fR.
+.IP "\fB\-mno\-cond\-exec\fR" 4
+.IX Item "-mno-cond-exec"
+Disable ARCompact specific pass to generate conditional execution instructions.
+Due to delay slot scheduling and interactions between operand numbers,
+literal sizes, instruction lengths, and the support for conditional execution,
+the target-independent pass to generate conditional execution is often lacking,
+so the \s-1ARC\s0 port has kept a special pass around that tries to find more
+conditional execution generating opportunities after register allocation,
+branch shortening, and delay slot scheduling have been done.  This pass
+generally, but not always, improves performance and code size, at the cost of
+extra compilation time, which is why there is an option to switch it off.
+If you have a problem with call instructions exceeding their allowable
+offset range because they are conditionalized, you should consider using
+\&\fB\-mmedium\-calls\fR instead.
+.IP "\fB\-mearly\-cbranchsi\fR" 4
+.IX Item "-mearly-cbranchsi"
+Enable pre-reload use of the cbranchsi pattern.
+.IP "\fB\-mexpand\-adddi\fR" 4
+.IX Item "-mexpand-adddi"
+Expand \f(CW\*(C`adddi3\*(C'\fR and \f(CW\*(C`subdi3\*(C'\fR at rtl generation time into
+\&\f(CW\*(C`add.f\*(C'\fR, \f(CW\*(C`adc\*(C'\fR etc.
+.IP "\fB\-mindexed\-loads\fR" 4
+.IX Item "-mindexed-loads"
+Enable the use of indexed loads.  This can be problematic because some
+optimizers will then assume the that indexed stores exist, which is not
+the case.
+.IP "\fB\-mlra\fR" 4
+.IX Item "-mlra"
+Enable Local Register Allocation.  This is still experimental for \s-1ARC,\s0
+so by default the compiler uses standard reload
+(i.e. \fB\-mno\-lra\fR).
+.IP "\fB\-mlra\-priority\-none\fR" 4
+.IX Item "-mlra-priority-none"
+Don't indicate any priority for target registers.
+.IP "\fB\-mlra\-priority\-compact\fR" 4
+.IX Item "-mlra-priority-compact"
+Indicate target register priority for r0..r3 / r12..r15.
+.IP "\fB\-mlra\-priority\-noncompact\fR" 4
+.IX Item "-mlra-priority-noncompact"
+Reduce target regsiter priority for r0..r3 / r12..r15.
+.IP "\fB\-mno\-millicode\fR" 4
+.IX Item "-mno-millicode"
+When optimizing for size (using \fB\-Os\fR), prologues and epilogues
+that have to save or restore a large number of registers are often
+shortened by using call to a special function in libgcc; this is
+referred to as a \fImillicode\fR call.  As these calls can pose
+performance issues, and/or cause linking issues when linking in a
+nonstandard way, this option is provided to turn off millicode call
+generation.
+.IP "\fB\-mmixed\-code\fR" 4
+.IX Item "-mmixed-code"
+Tweak register allocation to help 16\-bit instruction generation.
+This generally has the effect of decreasing the average instruction size
+while increasing the instruction count.
+.IP "\fB\-mq\-class\fR" 4
+.IX Item "-mq-class"
+Enable 'q' instruction alternatives.
+This is the default for \fB\-Os\fR.
+.IP "\fB\-mRcq\fR" 4
+.IX Item "-mRcq"
+Enable Rcq constraint handling \- most short code generation depends on this.
+This is the default.
+.IP "\fB\-mRcw\fR" 4
+.IX Item "-mRcw"
+Enable Rcw constraint handling \- ccfsm condexec mostly depends on this.
+This is the default.
+.IP "\fB\-msize\-level=\fR\fIlevel\fR" 4
+.IX Item "-msize-level=level"
+Fine-tune size optimization with regards to instruction lengths and alignment.
+The recognized values for \fIlevel\fR are:
+.RS 4
+.IP "\fB0\fR" 4
+.IX Item "0"
+No size optimization.  This level is deprecated and treated like \fB1\fR.
+.IP "\fB1\fR" 4
+.IX Item "1"
+Short instructions are used opportunistically.
+.IP "\fB2\fR" 4
+.IX Item "2"
+In addition, alignment of loops and of code after barriers are dropped.
+.IP "\fB3\fR" 4
+.IX Item "3"
+In addition, optional data alignment is dropped, and the option \fBOs\fR is enabled.
+.RE
+.RS 4
+.Sp
+This defaults to \fB3\fR when \fB\-Os\fR is in effect.  Otherwise,
+the behavior when this is not set is equivalent to level \fB1\fR.
+.RE
+.IP "\fB\-mtune=\fR\fIcpu\fR" 4
+.IX Item "-mtune=cpu"
+Set instruction scheduling parameters for \fIcpu\fR, overriding any implied
+by \fB\-mcpu=\fR.
+.Sp
+Supported values for \fIcpu\fR are
+.RS 4
+.IP "\fB\s-1ARC600\s0\fR" 4
+.IX Item "ARC600"
+Tune for \s-1ARC600\s0 cpu.
+.IP "\fB\s-1ARC601\s0\fR" 4
+.IX Item "ARC601"
+Tune for \s-1ARC601\s0 cpu.
+.IP "\fB\s-1ARC700\s0\fR" 4
+.IX Item "ARC700"
+Tune for \s-1ARC700\s0 cpu with standard multiplier block.
+.IP "\fBARC700\-xmac\fR" 4
+.IX Item "ARC700-xmac"
+Tune for \s-1ARC700\s0 cpu with \s-1XMAC\s0 block.
+.IP "\fB\s-1ARC725D\s0\fR" 4
+.IX Item "ARC725D"
+Tune for \s-1ARC725D\s0 cpu.
+.IP "\fB\s-1ARC750D\s0\fR" 4
+.IX Item "ARC750D"
+Tune for \s-1ARC750D\s0 cpu.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mmultcost=\fR\fInum\fR" 4
+.IX Item "-mmultcost=num"
+Cost to assume for a multiply instruction, with \fB4\fR being equal to a
+normal instruction.
+.IP "\fB\-munalign\-prob\-threshold=\fR\fIprobability\fR" 4
+.IX Item "-munalign-prob-threshold=probability"
+Set probability threshold for unaligning branches.
+When tuning for \fB\s-1ARC700\s0\fR and optimizing for speed, branches without
+filled delay slot are preferably emitted unaligned and long, unless
+profiling indicates that the probability for the branch to be taken
+is below \fIprobability\fR.  
+The default is (\s-1REG_BR_PROB_BASE/2\s0), i.e. 5000.
+.PP
+The following options are maintained for backward compatibility, but
+are now deprecated and will be removed in a future release:
+.IP "\fB\-margonaut\fR" 4
+.IX Item "-margonaut"
+Obsolete \s-1FPX.\s0
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+.PD 0
+.IP "\fB\-EB\fR" 4
+.IX Item "-EB"
+.PD
+Compile code for big endian targets.  Use of these options is now
+deprecated.  Users wanting big-endian code, should use the
+\&\f(CW\*(C`arceb\-elf32\*(C'\fR and \f(CW\*(C`arceb\-linux\-uclibc\*(C'\fR targets when
+building the tool chain, for which big-endian is the default.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+.PD 0
+.IP "\fB\-EL\fR" 4
+.IX Item "-EL"
+.PD
+Compile code for little endian targets.  Use of these options is now
+deprecated.  Users wanting little-endian code should use the
+\&\f(CW\*(C`arc\-elf32\*(C'\fR and \f(CW\*(C`arc\-linux\-uclibc\*(C'\fR targets when
+building the tool chain, for which little-endian is the default.
+.IP "\fB\-mbarrel_shifter\fR" 4
+.IX Item "-mbarrel_shifter"
+Replaced by \fB\-mbarrel\-shifter\fR
+.IP "\fB\-mdpfp_compact\fR" 4
+.IX Item "-mdpfp_compact"
+Replaced by \fB\-mdpfp\-compact\fR
+.IP "\fB\-mdpfp_fast\fR" 4
+.IX Item "-mdpfp_fast"
+Replaced by \fB\-mdpfp\-fast\fR
+.IP "\fB\-mdsp_packa\fR" 4
+.IX Item "-mdsp_packa"
+Replaced by \fB\-mdsp\-packa\fR
+.IP "\fB\-mEA\fR" 4
+.IX Item "-mEA"
+Replaced by \fB\-mea\fR
+.IP "\fB\-mmac_24\fR" 4
+.IX Item "-mmac_24"
+Replaced by \fB\-mmac\-24\fR
+.IP "\fB\-mmac_d16\fR" 4
+.IX Item "-mmac_d16"
+Replaced by \fB\-mmac\-d16\fR
+.IP "\fB\-mspfp_compact\fR" 4
+.IX Item "-mspfp_compact"
+Replaced by \fB\-mspfp\-compact\fR
+.IP "\fB\-mspfp_fast\fR" 4
+.IX Item "-mspfp_fast"
+Replaced by \fB\-mspfp\-fast\fR
+.IP "\fB\-mtune=\fR\fIcpu\fR" 4
+.IX Item "-mtune=cpu"
+Values \fBarc600\fR, \fBarc601\fR, \fBarc700\fR and
+\&\fBarc700\-xmac\fR for \fIcpu\fR are replaced by \fB\s-1ARC600\s0\fR,
+\&\fB\s-1ARC601\s0\fR, \fB\s-1ARC700\s0\fR and \fBARC700\-xmac\fR respectively
+.IP "\fB\-multcost=\fR\fInum\fR" 4
+.IX Item "-multcost=num"
+Replaced by \fB\-mmultcost\fR.
+.PP
+\fI\s-1ARM\s0 Options\fR
+.IX Subsection "ARM Options"
+.PP
+These \fB\-m\fR options are defined for Advanced \s-1RISC\s0 Machines (\s-1ARM\s0)
+architectures:
+.IP "\fB\-mabi=\fR\fIname\fR" 4
+.IX Item "-mabi=name"
+Generate code for the specified \s-1ABI. \s0 Permissible values are: \fBapcs-gnu\fR,
+\&\fBatpcs\fR, \fBaapcs\fR, \fBaapcs-linux\fR and \fBiwmmxt\fR.
+.IP "\fB\-mapcs\-frame\fR" 4
+.IX Item "-mapcs-frame"
+Generate a stack frame that is compliant with the \s-1ARM\s0 Procedure Call
+Standard for all functions, even if this is not strictly necessary for
+correct execution of the code.  Specifying \fB\-fomit\-frame\-pointer\fR
+with this option causes the stack frames not to be generated for
+leaf functions.  The default is \fB\-mno\-apcs\-frame\fR.
+.IP "\fB\-mapcs\fR" 4
+.IX Item "-mapcs"
+This is a synonym for \fB\-mapcs\-frame\fR.
+.IP "\fB\-mthumb\-interwork\fR" 4
+.IX Item "-mthumb-interwork"
+Generate code that supports calling between the \s-1ARM\s0 and Thumb
+instruction sets.  Without this option, on pre\-v5 architectures, the
+two instruction sets cannot be reliably used inside one program.  The
+default is \fB\-mno\-thumb\-interwork\fR, since slightly larger code
+is generated when \fB\-mthumb\-interwork\fR is specified.  In \s-1AAPCS\s0
+configurations this option is meaningless.
+.IP "\fB\-mno\-sched\-prolog\fR" 4
+.IX Item "-mno-sched-prolog"
+Prevent the reordering of instructions in the function prologue, or the
+merging of those instruction with the instructions in the function's
+body.  This means that all functions start with a recognizable set
+of instructions (or in fact one of a choice from a small set of
+different function prologues), and this information can be used to
+locate the start of functions inside an executable piece of code.  The
+default is \fB\-msched\-prolog\fR.
+.IP "\fB\-mfloat\-abi=\fR\fIname\fR" 4
+.IX Item "-mfloat-abi=name"
+Specifies which floating-point \s-1ABI\s0 to use.  Permissible values
+are: \fBsoft\fR, \fBsoftfp\fR and \fBhard\fR.
+.Sp
+Specifying \fBsoft\fR causes \s-1GCC\s0 to generate output containing
+library calls for floating-point operations.
+\&\fBsoftfp\fR allows the generation of code using hardware floating-point
+instructions, but still uses the soft-float calling conventions.
+\&\fBhard\fR allows generation of floating-point instructions
+and uses FPU-specific calling conventions.
+.Sp
+The default depends on the specific target configuration.  Note that
+the hard-float and soft-float ABIs are not link-compatible; you must
+compile your entire program with the same \s-1ABI,\s0 and link with a
+compatible set of libraries.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code for a processor running in little-endian mode.  This is
+the default for all standard configurations.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code for a processor running in big-endian mode; the default is
+to compile code for a little-endian processor.
+.IP "\fB\-mwords\-little\-endian\fR" 4
+.IX Item "-mwords-little-endian"
+This option only applies when generating code for big-endian processors.
+Generate code for a little-endian word order but a big-endian byte
+order.  That is, a byte order of the form \fB32107654\fR.  Note: this
+option should only be used if you require compatibility with code for
+big-endian \s-1ARM\s0 processors generated by versions of the compiler prior to
+2.8.  This option is now deprecated.
+.IP "\fB\-march=\fR\fIname\fR" 4
+.IX Item "-march=name"
+This specifies the name of the target \s-1ARM\s0 architecture.  \s-1GCC\s0 uses this
+name to determine what kind of instructions it can emit when generating
+assembly code.  This option can be used in conjunction with or instead
+of the \fB\-mcpu=\fR option.  Permissible names are: \fBarmv2\fR,
+\&\fBarmv2a\fR, \fBarmv3\fR, \fBarmv3m\fR, \fBarmv4\fR, \fBarmv4t\fR,
+\&\fBarmv5\fR, \fBarmv5t\fR, \fBarmv5e\fR, \fBarmv5te\fR,
+\&\fBarmv6\fR, \fBarmv6j\fR,
+\&\fBarmv6t2\fR, \fBarmv6z\fR, \fBarmv6zk\fR, \fBarmv6\-m\fR,
+\&\fBarmv7\fR, \fBarmv7\-a\fR, \fBarmv7\-r\fR, \fBarmv7\-m\fR, \fBarmv7e\-m\fR,
+\&\fBarmv7ve\fR, \fBarmv8\-a\fR, \fBarmv8\-a+crc\fR,
+\&\fBiwmmxt\fR, \fBiwmmxt2\fR, \fBep9312\fR.
+.Sp
+\&\fB\-march=armv7ve\fR is the armv7\-a architecture with virtualization
+extensions.
+.Sp
+\&\fB\-march=armv8\-a+crc\fR enables code generation for the ARMv8\-A
+architecture together with the optional \s-1CRC32\s0 extensions.
+.Sp
+\&\fB\-march=native\fR causes the compiler to auto-detect the architecture
+of the build computer.  At present, this feature is only supported on
+Linux, and not all architectures are recognized.  If the auto-detect is
+unsuccessful the option has no effect.
+.IP "\fB\-mtune=\fR\fIname\fR" 4
+.IX Item "-mtune=name"
+This option specifies the name of the target \s-1ARM\s0 processor for
+which \s-1GCC\s0 should tune the performance of the code.
+For some \s-1ARM\s0 implementations better performance can be obtained by using
+this option.
+Permissible names are: \fBarm2\fR, \fBarm250\fR,
+\&\fBarm3\fR, \fBarm6\fR, \fBarm60\fR, \fBarm600\fR, \fBarm610\fR,
+\&\fBarm620\fR, \fBarm7\fR, \fBarm7m\fR, \fBarm7d\fR, \fBarm7dm\fR,
+\&\fBarm7di\fR, \fBarm7dmi\fR, \fBarm70\fR, \fBarm700\fR,
+\&\fBarm700i\fR, \fBarm710\fR, \fBarm710c\fR, \fBarm7100\fR,
+\&\fBarm720\fR,
+\&\fBarm7500\fR, \fBarm7500fe\fR, \fBarm7tdmi\fR, \fBarm7tdmi\-s\fR,
+\&\fBarm710t\fR, \fBarm720t\fR, \fBarm740t\fR,
+\&\fBstrongarm\fR, \fBstrongarm110\fR, \fBstrongarm1100\fR,
+\&\fBstrongarm1110\fR,
+\&\fBarm8\fR, \fBarm810\fR, \fBarm9\fR, \fBarm9e\fR, \fBarm920\fR,
+\&\fBarm920t\fR, \fBarm922t\fR, \fBarm946e\-s\fR, \fBarm966e\-s\fR,
+\&\fBarm968e\-s\fR, \fBarm926ej\-s\fR, \fBarm940t\fR, \fBarm9tdmi\fR,
+\&\fBarm10tdmi\fR, \fBarm1020t\fR, \fBarm1026ej\-s\fR,
+\&\fBarm10e\fR, \fBarm1020e\fR, \fBarm1022e\fR,
+\&\fBarm1136j\-s\fR, \fBarm1136jf\-s\fR, \fBmpcore\fR, \fBmpcorenovfp\fR,
+\&\fBarm1156t2\-s\fR, \fBarm1156t2f\-s\fR, \fBarm1176jz\-s\fR, \fBarm1176jzf\-s\fR,
+\&\fBcortex\-a5\fR, \fBcortex\-a7\fR, \fBcortex\-a8\fR, \fBcortex\-a9\fR,
+\&\fBcortex\-a12\fR, \fBcortex\-a15\fR, \fBcortex\-a53\fR, \fBcortex\-a57\fR,
+\&\fBcortex\-r4\fR,
+\&\fBcortex\-r4f\fR, \fBcortex\-r5\fR, \fBcortex\-r7\fR, \fBcortex\-m4\fR,
+\&\fBcortex\-m3\fR,
+\&\fBcortex\-m1\fR,
+\&\fBcortex\-m0\fR,
+\&\fBcortex\-m0plus\fR,
+\&\fBmarvell\-pj4\fR,
+\&\fBxscale\fR, \fBiwmmxt\fR, \fBiwmmxt2\fR, \fBep9312\fR,
+\&\fBfa526\fR, \fBfa626\fR,
+\&\fBfa606te\fR, \fBfa626te\fR, \fBfmp626\fR, \fBfa726te\fR.
+.Sp
+Additionally, this option can specify that \s-1GCC\s0 should tune the performance
+of the code for a big.LITTLE system.  Permissible names are:
+\&\fBcortex\-a15.cortex\-a7\fR, \fBcortex\-a57.cortex\-a53\fR.
+.Sp
+\&\fB\-mtune=generic\-\fR\fIarch\fR specifies that \s-1GCC\s0 should tune the
+performance for a blend of processors within architecture \fIarch\fR.
+The aim is to generate code that run well on the current most popular
+processors, balancing between optimizations that benefit some CPUs in the
+range, and avoiding performance pitfalls of other CPUs.  The effects of
+this option may change in future \s-1GCC\s0 versions as \s-1CPU\s0 models come and go.
+.Sp
+\&\fB\-mtune=native\fR causes the compiler to auto-detect the \s-1CPU\s0
+of the build computer.  At present, this feature is only supported on
+Linux, and not all architectures are recognized.  If the auto-detect is
+unsuccessful the option has no effect.
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+This specifies the name of the target \s-1ARM\s0 processor.  \s-1GCC\s0 uses this name
+to derive the name of the target \s-1ARM\s0 architecture (as if specified
+by \fB\-march\fR) and the \s-1ARM\s0 processor type for which to tune for
+performance (as if specified by \fB\-mtune\fR).  Where this option
+is used in conjunction with \fB\-march\fR or \fB\-mtune\fR,
+those options take precedence over the appropriate part of this option.
+.Sp
+Permissible names for this option are the same as those for
+\&\fB\-mtune\fR.
+.Sp
+\&\fB\-mcpu=generic\-\fR\fIarch\fR is also permissible, and is
+equivalent to \fB\-march=\fR\fIarch\fR \fB\-mtune=generic\-\fR\fIarch\fR.
+See \fB\-mtune\fR for more information.
+.Sp
+\&\fB\-mcpu=native\fR causes the compiler to auto-detect the \s-1CPU\s0
+of the build computer.  At present, this feature is only supported on
+Linux, and not all architectures are recognized.  If the auto-detect is
+unsuccessful the option has no effect.
+.IP "\fB\-mfpu=\fR\fIname\fR" 4
+.IX Item "-mfpu=name"
+This specifies what floating-point hardware (or hardware emulation) is
+available on the target.  Permissible names are: \fBvfp\fR, \fBvfpv3\fR,
+\&\fBvfpv3\-fp16\fR, \fBvfpv3\-d16\fR, \fBvfpv3\-d16\-fp16\fR, \fBvfpv3xd\fR,
+\&\fBvfpv3xd\-fp16\fR, \fBneon\fR, \fBneon\-fp16\fR, \fBvfpv4\fR,
+\&\fBvfpv4\-d16\fR, \fBfpv4\-sp\-d16\fR, \fBneon\-vfpv4\fR,
+\&\fBfp\-armv8\fR, \fBneon\-fp\-armv8\fR, and \fBcrypto\-neon\-fp\-armv8\fR.
+.Sp
+If \fB\-msoft\-float\fR is specified this specifies the format of
+floating-point values.
+.Sp
+If the selected floating-point hardware includes the \s-1NEON\s0 extension
+(e.g. \fB\-mfpu\fR=\fBneon\fR), note that floating-point
+operations are not generated by \s-1GCC\s0's auto-vectorization pass unless
+\&\fB\-funsafe\-math\-optimizations\fR is also specified.  This is
+because \s-1NEON\s0 hardware does not fully implement the \s-1IEEE 754\s0 standard for
+floating-point arithmetic (in particular denormal values are treated as
+zero), so the use of \s-1NEON\s0 instructions may lead to a loss of precision.
+.IP "\fB\-mfp16\-format=\fR\fIname\fR" 4
+.IX Item "-mfp16-format=name"
+Specify the format of the \f(CW\*(C`_\|_fp16\*(C'\fR half-precision floating-point type.
+Permissible names are \fBnone\fR, \fBieee\fR, and \fBalternative\fR;
+the default is \fBnone\fR, in which case the \f(CW\*(C`_\|_fp16\*(C'\fR type is not
+defined.
+.IP "\fB\-mstructure\-size\-boundary=\fR\fIn\fR" 4
+.IX Item "-mstructure-size-boundary=n"
+The sizes of all structures and unions are rounded up to a multiple
+of the number of bits set by this option.  Permissible values are 8, 32
+and 64.  The default value varies for different toolchains.  For the \s-1COFF\s0
+targeted toolchain the default value is 8.  A value of 64 is only allowed
+if the underlying \s-1ABI\s0 supports it.
+.Sp
+Specifying a larger number can produce faster, more efficient code, but
+can also increase the size of the program.  Different values are potentially
+incompatible.  Code compiled with one value cannot necessarily expect to
+work with code or libraries compiled with another value, if they exchange
+information using structures or unions.
+.IP "\fB\-mabort\-on\-noreturn\fR" 4
+.IX Item "-mabort-on-noreturn"
+Generate a call to the function \f(CW\*(C`abort\*(C'\fR at the end of a
+\&\f(CW\*(C`noreturn\*(C'\fR function.  It is executed if the function tries to
+return.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+.PD 0
+.IP "\fB\-mno\-long\-calls\fR" 4
+.IX Item "-mno-long-calls"
+.PD
+Tells the compiler to perform function calls by first loading the
+address of the function into a register and then performing a subroutine
+call on this register.  This switch is needed if the target function
+lies outside of the 64\-megabyte addressing range of the offset-based
+version of subroutine call instruction.
+.Sp
+Even if this switch is enabled, not all function calls are turned
+into long calls.  The heuristic is that static functions, functions
+that have the \fBshort-call\fR attribute, functions that are inside
+the scope of a \fB#pragma no_long_calls\fR directive, and functions whose
+definitions have already been compiled within the current compilation
+unit are not turned into long calls.  The exceptions to this rule are
+that weak function definitions, functions with the \fBlong-call\fR
+attribute or the \fBsection\fR attribute, and functions that are within
+the scope of a \fB#pragma long_calls\fR directive are always
+turned into long calls.
+.Sp
+This feature is not enabled by default.  Specifying
+\&\fB\-mno\-long\-calls\fR restores the default behavior, as does
+placing the function calls within the scope of a \fB#pragma
+long_calls_off\fR directive.  Note these switches have no effect on how
+the compiler generates code to handle function calls via function
+pointers.
+.IP "\fB\-msingle\-pic\-base\fR" 4
+.IX Item "-msingle-pic-base"
+Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
+loading it in the prologue for each function.  The runtime system is
+responsible for initializing this register with an appropriate value
+before execution begins.
+.IP "\fB\-mpic\-register=\fR\fIreg\fR" 4
+.IX Item "-mpic-register=reg"
+Specify the register to be used for \s-1PIC\s0 addressing.
+For standard \s-1PIC\s0 base case, the default will be any suitable register
+determined by compiler.  For single \s-1PIC\s0 base case, the default is
+\&\fBR9\fR if target is \s-1EABI\s0 based or stack-checking is enabled,
+otherwise the default is \fBR10\fR.
+.IP "\fB\-mpic\-data\-is\-text\-relative\fR" 4
+.IX Item "-mpic-data-is-text-relative"
+Assume that each data segments are relative to text segment at load time.
+Therefore, it permits addressing data using PC-relative operations.
+This option is on by default for targets other than VxWorks \s-1RTP.\s0
+.IP "\fB\-mpoke\-function\-name\fR" 4
+.IX Item "-mpoke-function-name"
+Write the name of each function into the text section, directly
+preceding the function prologue.  The generated code is similar to this:
+.Sp
+.Vb 9
+\&             t0
+\&                 .ascii "arm_poke_function_name", 0
+\&                 .align
+\&             t1
+\&                 .word 0xff000000 + (t1 \- t0)
+\&             arm_poke_function_name
+\&                 mov     ip, sp
+\&                 stmfd   sp!, {fp, ip, lr, pc}
+\&                 sub     fp, ip, #4
+.Ve
+.Sp
+When performing a stack backtrace, code can inspect the value of
+\&\f(CW\*(C`pc\*(C'\fR stored at \f(CW\*(C`fp + 0\*(C'\fR.  If the trace function then looks at
+location \f(CW\*(C`pc \- 12\*(C'\fR and the top 8 bits are set, then we know that
+there is a function name embedded immediately preceding this location
+and has length \f(CW\*(C`((pc[\-3]) & 0xff000000)\*(C'\fR.
+.IP "\fB\-mthumb\fR" 4
+.IX Item "-mthumb"
+.PD 0
+.IP "\fB\-marm\fR" 4
+.IX Item "-marm"
+.PD
+Select between generating code that executes in \s-1ARM\s0 and Thumb
+states.  The default for most configurations is to generate code
+that executes in \s-1ARM\s0 state, but the default can be changed by
+configuring \s-1GCC\s0 with the \fB\-\-with\-mode=\fR\fIstate\fR
+configure option.
+.IP "\fB\-mtpcs\-frame\fR" 4
+.IX Item "-mtpcs-frame"
+Generate a stack frame that is compliant with the Thumb Procedure Call
+Standard for all non-leaf functions.  (A leaf function is one that does
+not call any other functions.)  The default is \fB\-mno\-tpcs\-frame\fR.
+.IP "\fB\-mtpcs\-leaf\-frame\fR" 4
+.IX Item "-mtpcs-leaf-frame"
+Generate a stack frame that is compliant with the Thumb Procedure Call
+Standard for all leaf functions.  (A leaf function is one that does
+not call any other functions.)  The default is \fB\-mno\-apcs\-leaf\-frame\fR.
+.IP "\fB\-mcallee\-super\-interworking\fR" 4
+.IX Item "-mcallee-super-interworking"
+Gives all externally visible functions in the file being compiled an \s-1ARM\s0
+instruction set header which switches to Thumb mode before executing the
+rest of the function.  This allows these functions to be called from
+non-interworking code.  This option is not valid in \s-1AAPCS\s0 configurations
+because interworking is enabled by default.
+.IP "\fB\-mcaller\-super\-interworking\fR" 4
+.IX Item "-mcaller-super-interworking"
+Allows calls via function pointers (including virtual functions) to
+execute correctly regardless of whether the target code has been
+compiled for interworking or not.  There is a small overhead in the cost
+of executing a function pointer if this option is enabled.  This option
+is not valid in \s-1AAPCS\s0 configurations because interworking is enabled
+by default.
+.IP "\fB\-mtp=\fR\fIname\fR" 4
+.IX Item "-mtp=name"
+Specify the access model for the thread local storage pointer.  The valid
+models are \fBsoft\fR, which generates calls to \f(CW\*(C`_\|_aeabi_read_tp\*(C'\fR,
+\&\fBcp15\fR, which fetches the thread pointer from \f(CW\*(C`cp15\*(C'\fR directly
+(supported in the arm6k architecture), and \fBauto\fR, which uses the
+best available method for the selected processor.  The default setting is
+\&\fBauto\fR.
+.IP "\fB\-mtls\-dialect=\fR\fIdialect\fR" 4
+.IX Item "-mtls-dialect=dialect"
+Specify the dialect to use for accessing thread local storage.  Two
+\&\fIdialect\fRs are supported\-\-\-\fBgnu\fR and \fBgnu2\fR.  The
+\&\fBgnu\fR dialect selects the original \s-1GNU\s0 scheme for supporting
+local and global dynamic \s-1TLS\s0 models.  The \fBgnu2\fR dialect
+selects the \s-1GNU\s0 descriptor scheme, which provides better performance
+for shared libraries.  The \s-1GNU\s0 descriptor scheme is compatible with
+the original scheme, but does require new assembler, linker and
+library support.  Initial and local exec \s-1TLS\s0 models are unaffected by
+this option and always use the original scheme.
+.IP "\fB\-mword\-relocations\fR" 4
+.IX Item "-mword-relocations"
+Only generate absolute relocations on word-sized values (i.e. R_ARM_ABS32).
+This is enabled by default on targets (uClinux, SymbianOS) where the runtime
+loader imposes this restriction, and when \fB\-fpic\fR or \fB\-fPIC\fR
+is specified.
+.IP "\fB\-mfix\-cortex\-m3\-ldrd\fR" 4
+.IX Item "-mfix-cortex-m3-ldrd"
+Some Cortex\-M3 cores can cause data corruption when \f(CW\*(C`ldrd\*(C'\fR instructions
+with overlapping destination and base registers are used.  This option avoids
+generating these instructions.  This option is enabled by default when
+\&\fB\-mcpu=cortex\-m3\fR is specified.
+.IP "\fB\-munaligned\-access\fR" 4
+.IX Item "-munaligned-access"
+.PD 0
+.IP "\fB\-mno\-unaligned\-access\fR" 4
+.IX Item "-mno-unaligned-access"
+.PD
+Enables (or disables) reading and writing of 16\- and 32\- bit values
+from addresses that are not 16\- or 32\- bit aligned.  By default
+unaligned access is disabled for all pre\-ARMv6 and all ARMv6\-M
+architectures, and enabled for all other architectures.  If unaligned
+access is not enabled then words in packed data structures will be
+accessed a byte at a time.
+.Sp
+The \s-1ARM\s0 attribute \f(CW\*(C`Tag_CPU_unaligned_access\*(C'\fR will be set in the
+generated object file to either true or false, depending upon the
+setting of this option.  If unaligned access is enabled then the
+preprocessor symbol \f(CW\*(C`_\|_ARM_FEATURE_UNALIGNED\*(C'\fR will also be
+defined.
+.IP "\fB\-mneon\-for\-64bits\fR" 4
+.IX Item "-mneon-for-64bits"
+Enables using Neon to handle scalar 64\-bits operations. This is
+disabled by default since the cost of moving data from core registers
+to Neon is high.
+.IP "\fB\-mslow\-flash\-data\fR" 4
+.IX Item "-mslow-flash-data"
+Assume loading data from flash is slower than fetching instruction.
+Therefore literal load is minimized for better performance.
+This option is only supported when compiling for ARMv7 M\-profile and
+off by default.
+.IP "\fB\-mrestrict\-it\fR" 4
+.IX Item "-mrestrict-it"
+Restricts generation of \s-1IT\s0 blocks to conform to the rules of ARMv8.
+\&\s-1IT\s0 blocks can only contain a single 16\-bit instruction from a select
+set of instructions. This option is on by default for ARMv8 Thumb mode.
+.PP
+\fI\s-1AVR\s0 Options\fR
+.IX Subsection "AVR Options"
+.PP
+These options are defined for \s-1AVR\s0 implementations:
+.IP "\fB\-mmcu=\fR\fImcu\fR" 4
+.IX Item "-mmcu=mcu"
+Specify Atmel \s-1AVR\s0 instruction set architectures (\s-1ISA\s0) or \s-1MCU\s0 type.
+.Sp
+The default for this option is@tie{}\f(CW\*(C`avr2\*(C'\fR.
+.Sp
+\&\s-1GCC\s0 supports the following \s-1AVR\s0 devices and ISAs:
+.RS 4
+.ie n .IP """avr2""" 4
+.el .IP "\f(CWavr2\fR" 4
+.IX Item "avr2"
+\&\*(L"Classic\*(R" devices with up to 8@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`attiny22\*(C'\fR, \f(CW\*(C`attiny26\*(C'\fR, \f(CW\*(C`at90c8534\*(C'\fR, \f(CW\*(C`at90s2313\*(C'\fR, \f(CW\*(C`at90s2323\*(C'\fR, \f(CW\*(C`at90s2333\*(C'\fR, \f(CW\*(C`at90s2343\*(C'\fR, \f(CW\*(C`at90s4414\*(C'\fR, \f(CW\*(C`at90s4433\*(C'\fR, \f(CW\*(C`at90s4434\*(C'\fR, \f(CW\*(C`at90s8515\*(C'\fR, \f(CW\*(C`at90s8535\*(C'\fR.
+.ie n .IP """avr25""" 4
+.el .IP "\f(CWavr25\fR" 4
+.IX Item "avr25"
+\&\*(L"Classic\*(R" devices with up to 8@tie{}KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`ata5272\*(C'\fR, \f(CW\*(C`ata6289\*(C'\fR, \f(CW\*(C`attiny13\*(C'\fR, \f(CW\*(C`attiny13a\*(C'\fR, \f(CW\*(C`attiny2313\*(C'\fR, \f(CW\*(C`attiny2313a\*(C'\fR, \f(CW\*(C`attiny24\*(C'\fR, \f(CW\*(C`attiny24a\*(C'\fR, \f(CW\*(C`attiny25\*(C'\fR, \f(CW\*(C`attiny261\*(C'\fR, \f(CW\*(C`attiny261a\*(C'\fR, \f(CW\*(C`attiny43u\*(C'\fR, \f(CW\*(C`attiny4313\*(C'\fR, \f(CW\*(C`attiny44\*(C'\fR, \f(CW\*(C`attiny44a\*(C'\fR, \f(CW\*(C`attiny45\*(C'\fR, \f(CW\*(C`attiny461\*(C'\fR, \f(CW\*(C`attiny461a\*(C'\fR, \f(CW\*(C`attiny48\*(C'\fR, \f(CW\*(C`attiny84\*(C'\fR, \f(CW\*(C`attiny84a\*(C'\fR, \f(CW\*(C`attiny85\*(C'\fR, \f(CW\*(C`attiny861\*(C'\fR, \f(CW\*(C`attiny861a\*(C'\fR, \f(CW\*(C`attiny87\*(C'\fR, \f(CW\*(C`attiny88\*(C'\fR, \f(CW\*(C`at86rf401\*(C'\fR.
+.ie n .IP """avr3""" 4
+.el .IP "\f(CWavr3\fR" 4
+.IX Item "avr3"
+\&\*(L"Classic\*(R" devices with 16@tie{}KiB up to 64@tie{}KiB of  program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`at43usb355\*(C'\fR, \f(CW\*(C`at76c711\*(C'\fR.
+.ie n .IP """avr31""" 4
+.el .IP "\f(CWavr31\fR" 4
+.IX Item "avr31"
+\&\*(L"Classic\*(R" devices with 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmega103\*(C'\fR, \f(CW\*(C`at43usb320\*(C'\fR.
+.ie n .IP """avr35""" 4
+.el .IP "\f(CWavr35\fR" 4
+.IX Item "avr35"
+\&\*(L"Classic\*(R" devices with 16@tie{}KiB up to 64@tie{}KiB of program memory and with the \f(CW\*(C`MOVW\*(C'\fR instruction.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`ata5505\*(C'\fR, \f(CW\*(C`atmega16u2\*(C'\fR, \f(CW\*(C`atmega32u2\*(C'\fR, \f(CW\*(C`atmega8u2\*(C'\fR, \f(CW\*(C`attiny1634\*(C'\fR, \f(CW\*(C`attiny167\*(C'\fR, \f(CW\*(C`at90usb162\*(C'\fR, \f(CW\*(C`at90usb82\*(C'\fR.
+.ie n .IP """avr4""" 4
+.el .IP "\f(CWavr4\fR" 4
+.IX Item "avr4"
+\&\*(L"Enhanced\*(R" devices with up to 8@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`ata6285\*(C'\fR, \f(CW\*(C`ata6286\*(C'\fR, \f(CW\*(C`atmega48\*(C'\fR, \f(CW\*(C`atmega48a\*(C'\fR, \f(CW\*(C`atmega48p\*(C'\fR, \f(CW\*(C`atmega48pa\*(C'\fR, \f(CW\*(C`atmega8\*(C'\fR, \f(CW\*(C`atmega8a\*(C'\fR, \f(CW\*(C`atmega8hva\*(C'\fR, \f(CW\*(C`atmega8515\*(C'\fR, \f(CW\*(C`atmega8535\*(C'\fR, \f(CW\*(C`atmega88\*(C'\fR, \f(CW\*(C`atmega88a\*(C'\fR, \f(CW\*(C`atmega88p\*(C'\fR, \f(CW\*(C`atmega88pa\*(C'\fR, \f(CW\*(C`at90pwm1\*(C'\fR, \f(CW\*(C`at90pwm2\*(C'\fR, \f(CW\*(C`at90pwm2b\*(C'\fR, \f(CW\*(C`at90pwm3\*(C'\fR, \f(CW\*(C`at90pwm3b\*(C'\fR, \f(CW\*(C`at90pwm81\*(C'\fR.
+.ie n .IP """avr5""" 4
+.el .IP "\f(CWavr5\fR" 4
+.IX Item "avr5"
+\&\*(L"Enhanced\*(R" devices with 16@tie{}KiB up to 64@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`ata5790\*(C'\fR, \f(CW\*(C`ata5790n\*(C'\fR, \f(CW\*(C`ata5795\*(C'\fR, \f(CW\*(C`atmega16\*(C'\fR, \f(CW\*(C`atmega16a\*(C'\fR, \f(CW\*(C`atmega16hva\*(C'\fR, \f(CW\*(C`atmega16hva2\*(C'\fR, \f(CW\*(C`atmega16hvb\*(C'\fR, \f(CW\*(C`atmega16hvbrevb\*(C'\fR, \f(CW\*(C`atmega16m1\*(C'\fR, \f(CW\*(C`atmega16u4\*(C'\fR, \f(CW\*(C`atmega161\*(C'\fR, \f(CW\*(C`atmega162\*(C'\fR, \f(CW\*(C`atmega163\*(C'\fR, \f(CW\*(C`atmega164a\*(C'\fR, \f(CW\*(C`atmega164p\*(C'\fR, \f(CW\*(C`atmega164pa\*(C'\fR, \f(CW\*(C`atmega165\*(C'\fR, \f(CW\*(C`atmega165a\*(C'\fR, \f(CW\*(C`atmega165p\*(C'\fR, \f(CW\*(C`atmega165pa\*(C'\fR, \f(CW\*(C`atmega168\*(C'\fR, \f(CW\*(C`atmega168a\*(C'\fR, \f(CW\*(C`atmega168p\*(C'\fR, \f(CW\*(C`atmega168pa\*(C'\fR, \f(CW\*(C`atmega169\*(C'\fR, \f(CW\*(C`atmega169a\*(C'\fR, \f(CW\*(C`atmega169p\*(C'\fR, \f(CW\*(C`atmega169pa\*(C'\fR, \f(CW\*(C`atmega26hvg\*(C'\fR, \f(CW\*(C`atmega32\*(C'\fR, \f(CW\*(C`atmega32a\*(C'\fR, \f(CW\*(C`atmega32c1\*(C'\fR, \f(CW\*(C`atmega32hvb\*(C'\fR, \f(CW\*(C`atmega32hvbrevb\*(C'\fR, \f(CW\*(C`atmega32m1\*(C'\fR, \f(CW\*(C`atmega32u4\*(C'\fR, \f(CW\*(C`atmega32u6\*(C'\fR, \f(CW\*(C`atmega323\*(C'\fR, \f(CW\*(C`atmega324a\*(C'\fR, \f(CW\*(C`atmega324p\*(C'\fR, \f(CW\*(C`atmega324pa\*(C'\fR, \f(CW\*(C`atmega325\*(C'\fR, \f(CW\*(C`atmega325a\*(C'\fR, \f(CW\*(C`atmega325p\*(C'\fR, \f(CW\*(C`atmega3250\*(C'\fR, \f(CW\*(C`atmega3250a\*(C'\fR, \f(CW\*(C`atmega3250p\*(C'\fR, \f(CW\*(C`atmega3250pa\*(C'\fR, \f(CW\*(C`atmega328\*(C'\fR, \f(CW\*(C`atmega328p\*(C'\fR, \f(CW\*(C`atmega329\*(C'\fR, \f(CW\*(C`atmega329a\*(C'\fR, \f(CW\*(C`atmega329p\*(C'\fR, \f(CW\*(C`atmega329pa\*(C'\fR, \f(CW\*(C`atmega3290\*(C'\fR, \f(CW\*(C`atmega3290a\*(C'\fR, \f(CW\*(C`atmega3290p\*(C'\fR, \f(CW\*(C`atmega3290pa\*(C'\fR, \f(CW\*(C`atmega406\*(C'\fR, \f(CW\*(C`atmega48hvf\*(C'\fR, \f(CW\*(C`atmega64\*(C'\fR, \f(CW\*(C`atmega64a\*(C'\fR, \f(CW\*(C`atmega64c1\*(C'\fR, \f(CW\*(C`atmega64hve\*(C'\fR, \f(CW\*(C`atmega64m1\*(C'\fR, \f(CW\*(C`atmega64rfa2\*(C'\fR, \f(CW\*(C`atmega64rfr2\*(C'\fR, \f(CW\*(C`atmega640\*(C'\fR, \f(CW\*(C`atmega644\*(C'\fR, \f(CW\*(C`atmega644a\*(C'\fR, \f(CW\*(C`atmega644p\*(C'\fR, \f(CW\*(C`atmega644pa\*(C'\fR, \f(CW\*(C`atmega645\*(C'\fR, \f(CW\*(C`atmega645a\*(C'\fR, \f(CW\*(C`atmega645p\*(C'\fR, \f(CW\*(C`atmega6450\*(C'\fR, \f(CW\*(C`atmega6450a\*(C'\fR, \f(CW\*(C`atmega6450p\*(C'\fR, \f(CW\*(C`atmega649\*(C'\fR, \f(CW\*(C`atmega649a\*(C'\fR, \f(CW\*(C`atmega649p\*(C'\fR, \f(CW\*(C`atmega6490\*(C'\fR, \f(CW\*(C`atmega6490a\*(C'\fR, \f(CW\*(C`atmega6490p\*(C'\fR, \f(CW\*(C`at90can32\*(C'\fR, \f(CW\*(C`at90can64\*(C'\fR, \f(CW\*(C`at90pwm161\*(C'\fR, \f(CW\*(C`at90pwm216\*(C'\fR, \f(CW\*(C`at90pwm316\*(C'\fR, \f(CW\*(C`at90scr100\*(C'\fR, \f(CW\*(C`at90usb646\*(C'\fR, \f(CW\*(C`at90usb647\*(C'\fR, \f(CW\*(C`at94k\*(C'\fR, \f(CW\*(C`m3000\*(C'\fR.
+.ie n .IP """avr51""" 4
+.el .IP "\f(CWavr51\fR" 4
+.IX Item "avr51"
+\&\*(L"Enhanced\*(R" devices with 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmega128\*(C'\fR, \f(CW\*(C`atmega128a\*(C'\fR, \f(CW\*(C`atmega128rfa1\*(C'\fR, \f(CW\*(C`atmega1280\*(C'\fR, \f(CW\*(C`atmega1281\*(C'\fR, \f(CW\*(C`atmega1284\*(C'\fR, \f(CW\*(C`atmega1284p\*(C'\fR, \f(CW\*(C`at90can128\*(C'\fR, \f(CW\*(C`at90usb1286\*(C'\fR, \f(CW\*(C`at90usb1287\*(C'\fR.
+.ie n .IP """avr6""" 4
+.el .IP "\f(CWavr6\fR" 4
+.IX Item "avr6"
+\&\*(L"Enhanced\*(R" devices with 3\-byte \s-1PC,\s0 i.e. with more than 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmega2560\*(C'\fR, \f(CW\*(C`atmega2561\*(C'\fR.
+.ie n .IP """avrxmega2""" 4
+.el .IP "\f(CWavrxmega2\fR" 4
+.IX Item "avrxmega2"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 8@tie{}KiB and up to 64@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmxt112sl\*(C'\fR, \f(CW\*(C`atmxt224\*(C'\fR, \f(CW\*(C`atmxt224e\*(C'\fR, \f(CW\*(C`atmxt336s\*(C'\fR, \f(CW\*(C`atxmega16a4\*(C'\fR, \f(CW\*(C`atxmega16a4u\*(C'\fR, \f(CW\*(C`atxmega16c4\*(C'\fR, \f(CW\*(C`atxmega16d4\*(C'\fR, \f(CW\*(C`atxmega32a4\*(C'\fR, \f(CW\*(C`atxmega32a4u\*(C'\fR, \f(CW\*(C`atxmega32c4\*(C'\fR, \f(CW\*(C`atxmega32d4\*(C'\fR, \f(CW\*(C`atxmega32e5\*(C'\fR, \f(CW\*(C`atxmega32x1\*(C'\fR.
+.ie n .IP """avrxmega4""" 4
+.el .IP "\f(CWavrxmega4\fR" 4
+.IX Item "avrxmega4"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atxmega64a3\*(C'\fR, \f(CW\*(C`atxmega64a3u\*(C'\fR, \f(CW\*(C`atxmega64a4u\*(C'\fR, \f(CW\*(C`atxmega64b1\*(C'\fR, \f(CW\*(C`atxmega64b3\*(C'\fR, \f(CW\*(C`atxmega64c3\*(C'\fR, \f(CW\*(C`atxmega64d3\*(C'\fR, \f(CW\*(C`atxmega64d4\*(C'\fR.
+.ie n .IP """avrxmega5""" 4
+.el .IP "\f(CWavrxmega5\fR" 4
+.IX Item "avrxmega5"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 64@tie{}KiB and up to 128@tie{}KiB of program memory and more than 64@tie{}KiB of \s-1RAM.
+\&\s0\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atxmega64a1\*(C'\fR, \f(CW\*(C`atxmega64a1u\*(C'\fR.
+.ie n .IP """avrxmega6""" 4
+.el .IP "\f(CWavrxmega6\fR" 4
+.IX Item "avrxmega6"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 128@tie{}KiB of program memory.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atmxt540s\*(C'\fR, \f(CW\*(C`atmxt540sreva\*(C'\fR, \f(CW\*(C`atxmega128a3\*(C'\fR, \f(CW\*(C`atxmega128a3u\*(C'\fR, \f(CW\*(C`atxmega128b1\*(C'\fR, \f(CW\*(C`atxmega128b3\*(C'\fR, \f(CW\*(C`atxmega128c3\*(C'\fR, \f(CW\*(C`atxmega128d3\*(C'\fR, \f(CW\*(C`atxmega128d4\*(C'\fR, \f(CW\*(C`atxmega192a3\*(C'\fR, \f(CW\*(C`atxmega192a3u\*(C'\fR, \f(CW\*(C`atxmega192c3\*(C'\fR, \f(CW\*(C`atxmega192d3\*(C'\fR, \f(CW\*(C`atxmega256a3\*(C'\fR, \f(CW\*(C`atxmega256a3b\*(C'\fR, \f(CW\*(C`atxmega256a3bu\*(C'\fR, \f(CW\*(C`atxmega256a3u\*(C'\fR, \f(CW\*(C`atxmega256c3\*(C'\fR, \f(CW\*(C`atxmega256d3\*(C'\fR, \f(CW\*(C`atxmega384c3\*(C'\fR, \f(CW\*(C`atxmega384d3\*(C'\fR.
+.ie n .IP """avrxmega7""" 4
+.el .IP "\f(CWavrxmega7\fR" 4
+.IX Item "avrxmega7"
+\&\*(L"\s-1XMEGA\*(R"\s0 devices with more than 128@tie{}KiB of program memory and more than 64@tie{}KiB of \s-1RAM.
+\&\s0\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`atxmega128a1\*(C'\fR, \f(CW\*(C`atxmega128a1u\*(C'\fR, \f(CW\*(C`atxmega128a4u\*(C'\fR.
+.ie n .IP """avr1""" 4
+.el .IP "\f(CWavr1\fR" 4
+.IX Item "avr1"
+This \s-1ISA\s0 is implemented by the minimal \s-1AVR\s0 core and supported for assembler only.
+\&\fImcu\fR\f(CW@tie\fR{}= \f(CW\*(C`attiny11\*(C'\fR, \f(CW\*(C`attiny12\*(C'\fR, \f(CW\*(C`attiny15\*(C'\fR, \f(CW\*(C`attiny28\*(C'\fR, \f(CW\*(C`at90s1200\*(C'\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-maccumulate\-args\fR" 4
+.IX Item "-maccumulate-args"
+Accumulate outgoing function arguments and acquire/release the needed
+stack space for outgoing function arguments once in function
+prologue/epilogue.  Without this option, outgoing arguments are pushed
+before calling a function and popped afterwards.
+.Sp
+Popping the arguments after the function call can be expensive on
+\&\s-1AVR\s0 so that accumulating the stack space might lead to smaller
+executables because arguments need not to be removed from the
+stack after such a function call.
+.Sp
+This option can lead to reduced code size for functions that perform
+several calls to functions that get their arguments on the stack like
+calls to printf-like functions.
+.IP "\fB\-mbranch\-cost=\fR\fIcost\fR" 4
+.IX Item "-mbranch-cost=cost"
+Set the branch costs for conditional branch instructions to
+\&\fIcost\fR.  Reasonable values for \fIcost\fR are small, non-negative
+integers. The default branch cost is 0.
+.IP "\fB\-mcall\-prologues\fR" 4
+.IX Item "-mcall-prologues"
+Functions prologues/epilogues are expanded as calls to appropriate
+subroutines.  Code size is smaller.
+.IP "\fB\-mint8\fR" 4
+.IX Item "-mint8"
+Assume \f(CW\*(C`int\*(C'\fR to be 8\-bit integer.  This affects the sizes of all types: a
+\&\f(CW\*(C`char\*(C'\fR is 1 byte, an \f(CW\*(C`int\*(C'\fR is 1 byte, a \f(CW\*(C`long\*(C'\fR is 2 bytes,
+and \f(CW\*(C`long long\*(C'\fR is 4 bytes.  Please note that this option does not
+conform to the C standards, but it results in smaller code
+size.
+.IP "\fB\-mno\-interrupts\fR" 4
+.IX Item "-mno-interrupts"
+Generated code is not compatible with hardware interrupts.
+Code size is smaller.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Try to replace \f(CW\*(C`CALL\*(C'\fR resp. \f(CW\*(C`JMP\*(C'\fR instruction by the shorter
+\&\f(CW\*(C`RCALL\*(C'\fR resp. \f(CW\*(C`RJMP\*(C'\fR instruction if applicable.
+Setting \f(CW\*(C`\-mrelax\*(C'\fR just adds the \f(CW\*(C`\-\-relax\*(C'\fR option to the
+linker command line when the linker is called.
+.Sp
+Jump relaxing is performed by the linker because jump offsets are not
+known before code is located. Therefore, the assembler code generated by the
+compiler is the same, but the instructions in the executable may
+differ from instructions in the assembler code.
+.Sp
+Relaxing must be turned on if linker stubs are needed, see the
+section on \f(CW\*(C`EIND\*(C'\fR and linker stubs below.
+.IP "\fB\-msp8\fR" 4
+.IX Item "-msp8"
+Treat the stack pointer register as an 8\-bit register,
+i.e. assume the high byte of the stack pointer is zero.
+In general, you don't need to set this option by hand.
+.Sp
+This option is used internally by the compiler to select and
+build multilibs for architectures \f(CW\*(C`avr2\*(C'\fR and \f(CW\*(C`avr25\*(C'\fR.
+These architectures mix devices with and without \f(CW\*(C`SPH\*(C'\fR.
+For any setting other than \f(CW\*(C`\-mmcu=avr2\*(C'\fR or \f(CW\*(C`\-mmcu=avr25\*(C'\fR
+the compiler driver will add or remove this option from the compiler
+proper's command line, because the compiler then knows if the device
+or architecture has an 8\-bit stack pointer and thus no \f(CW\*(C`SPH\*(C'\fR
+register or not.
+.IP "\fB\-mstrict\-X\fR" 4
+.IX Item "-mstrict-X"
+Use address register \f(CW\*(C`X\*(C'\fR in a way proposed by the hardware.  This means
+that \f(CW\*(C`X\*(C'\fR is only used in indirect, post-increment or
+pre-decrement addressing.
+.Sp
+Without this option, the \f(CW\*(C`X\*(C'\fR register may be used in the same way
+as \f(CW\*(C`Y\*(C'\fR or \f(CW\*(C`Z\*(C'\fR which then is emulated by additional
+instructions.  
+For example, loading a value with \f(CW\*(C`X+const\*(C'\fR addressing with a
+small non-negative \f(CW\*(C`const < 64\*(C'\fR to a register \fIRn\fR is
+performed as
+.Sp
+.Vb 3
+\&        adiw r26, const   ; X += const
+\&        ld   <Rn>, X        ; <Rn> = *X
+\&        sbiw r26, const   ; X \-= const
+.Ve
+.IP "\fB\-mtiny\-stack\fR" 4
+.IX Item "-mtiny-stack"
+Only change the lower 8@tie{}bits of the stack pointer.
+.IP "\fB\-Waddr\-space\-convert\fR" 4
+.IX Item "-Waddr-space-convert"
+Warn about conversions between address spaces in the case where the
+resulting address space is not contained in the incoming address space.
+.PP
+\f(CW\*(C`EIND\*(C'\fR and Devices with more than 128 Ki Bytes of Flash
+.IX Subsection "EIND and Devices with more than 128 Ki Bytes of Flash"
+.PP
+Pointers in the implementation are 16@tie{}bits wide.
+The address of a function or label is represented as word address so
+that indirect jumps and calls can target any code address in the
+range of 64@tie{}Ki words.
+.PP
+In order to facilitate indirect jump on devices with more than 128@tie{}Ki
+bytes of program memory space, there is a special function register called
+\&\f(CW\*(C`EIND\*(C'\fR that serves as most significant part of the target address
+when \f(CW\*(C`EICALL\*(C'\fR or \f(CW\*(C`EIJMP\*(C'\fR instructions are used.
+.PP
+Indirect jumps and calls on these devices are handled as follows by
+the compiler and are subject to some limitations:
+.IP "\(bu" 4
+The compiler never sets \f(CW\*(C`EIND\*(C'\fR.
+.IP "\(bu" 4
+The compiler uses \f(CW\*(C`EIND\*(C'\fR implicitely in \f(CW\*(C`EICALL\*(C'\fR/\f(CW\*(C`EIJMP\*(C'\fR
+instructions or might read \f(CW\*(C`EIND\*(C'\fR directly in order to emulate an
+indirect call/jump by means of a \f(CW\*(C`RET\*(C'\fR instruction.
+.IP "\(bu" 4
+The compiler assumes that \f(CW\*(C`EIND\*(C'\fR never changes during the startup
+code or during the application. In particular, \f(CW\*(C`EIND\*(C'\fR is not
+saved/restored in function or interrupt service routine
+prologue/epilogue.
+.IP "\(bu" 4
+For indirect calls to functions and computed goto, the linker
+generates \fIstubs\fR. Stubs are jump pads sometimes also called
+\&\fItrampolines\fR. Thus, the indirect call/jump jumps to such a stub.
+The stub contains a direct jump to the desired address.
+.IP "\(bu" 4
+Linker relaxation must be turned on so that the linker will generate
+the stubs correctly an all situaltion. See the compiler option
+\&\f(CW\*(C`\-mrelax\*(C'\fR and the linler option \f(CW\*(C`\-\-relax\*(C'\fR.
+There are corner cases where the linker is supposed to generate stubs
+but aborts without relaxation and without a helpful error message.
+.IP "\(bu" 4
+The default linker script is arranged for code with \f(CW\*(C`EIND = 0\*(C'\fR.
+If code is supposed to work for a setup with \f(CW\*(C`EIND != 0\*(C'\fR, a custom
+linker script has to be used in order to place the sections whose
+name start with \f(CW\*(C`.trampolines\*(C'\fR into the segment where \f(CW\*(C`EIND\*(C'\fR
+points to.
+.IP "\(bu" 4
+The startup code from libgcc never sets \f(CW\*(C`EIND\*(C'\fR.
+Notice that startup code is a blend of code from libgcc and AVR-LibC.
+For the impact of AVR-LibC on \f(CW\*(C`EIND\*(C'\fR, see the
+AVR-LibC\ user\ manual (\f(CW\*(C`http://nongnu.org/avr\-libc/user\-manual/\*(C'\fR).
+.IP "\(bu" 4
+It is legitimate for user-specific startup code to set up \f(CW\*(C`EIND\*(C'\fR
+early, for example by means of initialization code located in
+section \f(CW\*(C`.init3\*(C'\fR. Such code runs prior to general startup code
+that initializes \s-1RAM\s0 and calls constructors, but after the bit
+of startup code from AVR-LibC that sets \f(CW\*(C`EIND\*(C'\fR to the segment
+where the vector table is located.
+.Sp
+.Vb 1
+\&        #include <avr/io.h>
+\&        
+\&        static void
+\&        _\|_attribute_\|_((section(".init3"),naked,used,no_instrument_function))
+\&        init3_set_eind (void)
+\&        {
+\&          _\|_asm volatile ("ldi r24,pm_hh8(_\|_trampolines_start)\en\et"
+\&                          "out %i0,r24" :: "n" (&EIND) : "r24","memory");
+\&        }
+.Ve
+.Sp
+The \f(CW\*(C`_\|_trampolines_start\*(C'\fR symbol is defined in the linker script.
+.IP "\(bu" 4
+Stubs are generated automatically by the linker if
+the following two conditions are met:
+.RS 4
+.ie n .IP "\-<The address of a label is taken by means of the ""gs"" modifier>" 4
+.el .IP "\-<The address of a label is taken by means of the \f(CWgs\fR modifier>" 4
+.IX Item "-<The address of a label is taken by means of the gs modifier>"
+(short for \fIgenerate stubs\fR) like so:
+.Sp
+.Vb 2
+\&        LDI r24, lo8(gs(<func>))
+\&        LDI r25, hi8(gs(<func>))
+.Ve
+.IP "\-<The final location of that label is in a code segment>" 4
+.IX Item "-<The final location of that label is in a code segment>"
+\&\fIoutside\fR the segment where the stubs are located.
+.RE
+.RS 4
+.RE
+.IP "\(bu" 4
+The compiler emits such \f(CW\*(C`gs\*(C'\fR modifiers for code labels in the
+following situations:
+.RS 4
+.IP "\-<Taking address of a function or code label.>" 4
+.IX Item "-<Taking address of a function or code label.>"
+.PD 0
+.IP "\-<Computed goto.>" 4
+.IX Item "-<Computed goto.>"
+.IP "\-<If prologue-save function is used, see \fB\-mcall\-prologues\fR>" 4
+.IX Item "-<If prologue-save function is used, see -mcall-prologues>"
+.PD
+command-line option.
+.IP "\-<Switch/case dispatch tables. If you do not want such dispatch>" 4
+.IX Item "-<Switch/case dispatch tables. If you do not want such dispatch>"
+tables you can specify the \fB\-fno\-jump\-tables\fR command-line option.
+.IP "\-<C and \*(C+ constructors/destructors called during startup/shutdown.>" 4
+.IX Item "-<C and constructors/destructors called during startup/shutdown.>"
+.PD 0
+.ie n .IP "\-<If the tools hit a ""gs()"" modifier explained above.>" 4
+.el .IP "\-<If the tools hit a \f(CWgs()\fR modifier explained above.>" 4
+.IX Item "-<If the tools hit a gs() modifier explained above.>"
+.RE
+.RS 4
+.RE
+.IP "\(bu" 4
+.PD
+Jumping to non-symbolic addresses like so is \fInot\fR supported:
+.Sp
+.Vb 5
+\&        int main (void)
+\&        {
+\&            /* Call function at word address 0x2 */
+\&            return ((int(*)(void)) 0x2)();
+\&        }
+.Ve
+.Sp
+Instead, a stub has to be set up, i.e. the function has to be called
+through a symbol (\f(CW\*(C`func_4\*(C'\fR in the example):
+.Sp
+.Vb 3
+\&        int main (void)
+\&        {
+\&            extern int func_4 (void);
+\&        
+\&            /* Call function at byte address 0x4 */
+\&            return func_4();
+\&        }
+.Ve
+.Sp
+and the application be linked with \f(CW\*(C`\-Wl,\-\-defsym,func_4=0x4\*(C'\fR.
+Alternatively, \f(CW\*(C`func_4\*(C'\fR can be defined in the linker script.
+.PP
+Handling of the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR and \f(CW\*(C`RAMPZ\*(C'\fR Special Function Registers
+.IX Subsection "Handling of the RAMPD, RAMPX, RAMPY and RAMPZ Special Function Registers"
+.PP
+Some \s-1AVR\s0 devices support memories larger than the 64@tie{}KiB range
+that can be accessed with 16\-bit pointers.  To access memory locations
+outside this 64@tie{}KiB range, the contentent of a \f(CW\*(C`RAMP\*(C'\fR
+register is used as high part of the address:
+The \f(CW\*(C`X\*(C'\fR, \f(CW\*(C`Y\*(C'\fR, \f(CW\*(C`Z\*(C'\fR address register is concatenated
+with the \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR, \f(CW\*(C`RAMPZ\*(C'\fR special function
+register, respectively, to get a wide address. Similarly,
+\&\f(CW\*(C`RAMPD\*(C'\fR is used together with direct addressing.
+.IP "\(bu" 4
+The startup code initializes the \f(CW\*(C`RAMP\*(C'\fR special function
+registers with zero.
+.IP "\(bu" 4
+If a \fB\s-1AVR\s0 Named Address Spaces,named address space\fR other than
+generic or \f(CW\*(C`_\|_flash\*(C'\fR is used, then \f(CW\*(C`RAMPZ\*(C'\fR is set
+as needed before the operation.
+.IP "\(bu" 4
+If the device supports \s-1RAM\s0 larger than 64@tie{}KiB and the compiler
+needs to change \f(CW\*(C`RAMPZ\*(C'\fR to accomplish an operation, \f(CW\*(C`RAMPZ\*(C'\fR
+is reset to zero after the operation.
+.IP "\(bu" 4
+If the device comes with a specific \f(CW\*(C`RAMP\*(C'\fR register, the \s-1ISR\s0
+prologue/epilogue saves/restores that \s-1SFR\s0 and initializes it with
+zero in case the \s-1ISR\s0 code might (implicitly) use it.
+.IP "\(bu" 4
+\&\s-1RAM\s0 larger than 64@tie{}KiB is not supported by \s-1GCC\s0 for \s-1AVR\s0 targets.
+If you use inline assembler to read from locations outside the
+16\-bit address range and change one of the \f(CW\*(C`RAMP\*(C'\fR registers,
+you must reset it to zero after the access.
+.PP
+\s-1AVR\s0 Built-in Macros
+.IX Subsection "AVR Built-in Macros"
+.PP
+\&\s-1GCC\s0 defines several built-in macros so that the user code can test
+for the presence or absence of features.  Almost any of the following
+built-in macros are deduced from device capabilities and thus
+triggered by the \f(CW\*(C`\-mmcu=\*(C'\fR command-line option.
+.PP
+For even more AVR-specific built-in macros see
+\&\fB\s-1AVR\s0 Named Address Spaces\fR and \fB\s-1AVR\s0 Built-in Functions\fR.
+.ie n .IP """_\|_AVR_ARCH_\|_""" 4
+.el .IP "\f(CW_\|_AVR_ARCH_\|_\fR" 4
+.IX Item "__AVR_ARCH__"
+Build-in macro that resolves to a decimal number that identifies the
+architecture and depends on the \f(CW\*(C`\-mmcu=\f(CImcu\f(CW\*(C'\fR option.
+Possible values are:
+.Sp
+\&\f(CW2\fR, \f(CW25\fR, \f(CW3\fR, \f(CW31\fR, \f(CW35\fR,
+\&\f(CW4\fR, \f(CW5\fR, \f(CW51\fR, \f(CW6\fR, \f(CW102\fR, \f(CW104\fR,
+\&\f(CW105\fR, \f(CW106\fR, \f(CW107\fR
+.Sp
+for \fImcu\fR=\f(CW\*(C`avr2\*(C'\fR, \f(CW\*(C`avr25\*(C'\fR, \f(CW\*(C`avr3\*(C'\fR,
+\&\f(CW\*(C`avr31\*(C'\fR, \f(CW\*(C`avr35\*(C'\fR, \f(CW\*(C`avr4\*(C'\fR, \f(CW\*(C`avr5\*(C'\fR, \f(CW\*(C`avr51\*(C'\fR,
+\&\f(CW\*(C`avr6\*(C'\fR, \f(CW\*(C`avrxmega2\*(C'\fR, \f(CW\*(C`avrxmega4\*(C'\fR, \f(CW\*(C`avrxmega5\*(C'\fR,
+\&\f(CW\*(C`avrxmega6\*(C'\fR, \f(CW\*(C`avrxmega7\*(C'\fR, respectively.
+If \fImcu\fR specifies a device, this built-in macro is set
+accordingly. For example, with \f(CW\*(C`\-mmcu=atmega8\*(C'\fR the macro will be
+defined to \f(CW4\fR.
+.ie n .IP """_\|_AVR_\f(CIDevice\f(CW_\|_""" 4
+.el .IP "\f(CW_\|_AVR_\f(CIDevice\f(CW_\|_\fR" 4
+.IX Item "__AVR_Device__"
+Setting \f(CW\*(C`\-mmcu=\f(CIdevice\f(CW\*(C'\fR defines this built-in macro which reflects
+the device's name. For example, \f(CW\*(C`\-mmcu=atmega8\*(C'\fR defines the
+built-in macro \f(CW\*(C`_\|_AVR_ATmega8_\|_\*(C'\fR, \f(CW\*(C`\-mmcu=attiny261a\*(C'\fR defines
+\&\f(CW\*(C`_\|_AVR_ATtiny261A_\|_\*(C'\fR, etc.
+.Sp
+The built-in macros' names follow
+the scheme \f(CW\*(C`_\|_AVR_\f(CIDevice\f(CW_\|_\*(C'\fR where \fIDevice\fR is
+the device name as from the \s-1AVR\s0 user manual. The difference between
+\&\fIDevice\fR in the built-in macro and \fIdevice\fR in
+\&\f(CW\*(C`\-mmcu=\f(CIdevice\f(CW\*(C'\fR is that the latter is always lowercase.
+.Sp
+If \fIdevice\fR is not a device but only a core architecture like
+\&\f(CW\*(C`avr51\*(C'\fR, this macro will not be defined.
+.ie n .IP """_\|_AVR_XMEGA_\|_""" 4
+.el .IP "\f(CW_\|_AVR_XMEGA_\|_\fR" 4
+.IX Item "__AVR_XMEGA__"
+The device / architecture belongs to the \s-1XMEGA\s0 family of devices.
+.ie n .IP """_\|_AVR_HAVE_ELPM_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_ELPM_\|_\fR" 4
+.IX Item "__AVR_HAVE_ELPM__"
+The device has the the \f(CW\*(C`ELPM\*(C'\fR instruction.
+.ie n .IP """_\|_AVR_HAVE_ELPMX_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_ELPMX_\|_\fR" 4
+.IX Item "__AVR_HAVE_ELPMX__"
+The device has the \f(CW\*(C`ELPM R\f(CIn\f(CW,Z\*(C'\fR and \f(CW\*(C`ELPM
+R\f(CIn\f(CW,Z+\*(C'\fR instructions.
+.ie n .IP """_\|_AVR_HAVE_MOVW_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_MOVW_\|_\fR" 4
+.IX Item "__AVR_HAVE_MOVW__"
+The device has the \f(CW\*(C`MOVW\*(C'\fR instruction to perform 16\-bit
+register-register moves.
+.ie n .IP """_\|_AVR_HAVE_LPMX_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_LPMX_\|_\fR" 4
+.IX Item "__AVR_HAVE_LPMX__"
+The device has the \f(CW\*(C`LPM R\f(CIn\f(CW,Z\*(C'\fR and
+\&\f(CW\*(C`LPM R\f(CIn\f(CW,Z+\*(C'\fR instructions.
+.ie n .IP """_\|_AVR_HAVE_MUL_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_MUL_\|_\fR" 4
+.IX Item "__AVR_HAVE_MUL__"
+The device has a hardware multiplier.
+.ie n .IP """_\|_AVR_HAVE_JMP_CALL_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_JMP_CALL_\|_\fR" 4
+.IX Item "__AVR_HAVE_JMP_CALL__"
+The device has the \f(CW\*(C`JMP\*(C'\fR and \f(CW\*(C`CALL\*(C'\fR instructions.
+This is the case for devices with at least 16@tie{}KiB of program
+memory.
+.ie n .IP """_\|_AVR_HAVE_EIJMP_EICALL_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_EIJMP_EICALL_\|_\fR" 4
+.IX Item "__AVR_HAVE_EIJMP_EICALL__"
+.PD 0
+.ie n .IP """_\|_AVR_3_BYTE_PC_\|_""" 4
+.el .IP "\f(CW_\|_AVR_3_BYTE_PC_\|_\fR" 4
+.IX Item "__AVR_3_BYTE_PC__"
+.PD
+The device has the \f(CW\*(C`EIJMP\*(C'\fR and \f(CW\*(C`EICALL\*(C'\fR instructions.
+This is the case for devices with more than 128@tie{}KiB of program memory.
+This also means that the program counter
+(\s-1PC\s0) is 3@tie{}bytes wide.
+.ie n .IP """_\|_AVR_2_BYTE_PC_\|_""" 4
+.el .IP "\f(CW_\|_AVR_2_BYTE_PC_\|_\fR" 4
+.IX Item "__AVR_2_BYTE_PC__"
+The program counter (\s-1PC\s0) is 2@tie{}bytes wide. This is the case for devices
+with up to 128@tie{}KiB of program memory.
+.ie n .IP """_\|_AVR_HAVE_8BIT_SP_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_8BIT_SP_\|_\fR" 4
+.IX Item "__AVR_HAVE_8BIT_SP__"
+.PD 0
+.ie n .IP """_\|_AVR_HAVE_16BIT_SP_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_16BIT_SP_\|_\fR" 4
+.IX Item "__AVR_HAVE_16BIT_SP__"
+.PD
+The stack pointer (\s-1SP\s0) register is treated as 8\-bit respectively
+16\-bit register by the compiler.
+The definition of these macros is affected by \f(CW\*(C`\-mtiny\-stack\*(C'\fR.
+.ie n .IP """_\|_AVR_HAVE_SPH_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_SPH_\|_\fR" 4
+.IX Item "__AVR_HAVE_SPH__"
+.PD 0
+.ie n .IP """_\|_AVR_SP8_\|_""" 4
+.el .IP "\f(CW_\|_AVR_SP8_\|_\fR" 4
+.IX Item "__AVR_SP8__"
+.PD
+The device has the \s-1SPH \s0(high part of stack pointer) special function
+register or has an 8\-bit stack pointer, respectively.
+The definition of these macros is affected by \f(CW\*(C`\-mmcu=\*(C'\fR and
+in the cases of \f(CW\*(C`\-mmcu=avr2\*(C'\fR and \f(CW\*(C`\-mmcu=avr25\*(C'\fR also
+by \f(CW\*(C`\-msp8\*(C'\fR.
+.ie n .IP """_\|_AVR_HAVE_RAMPD_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_RAMPD_\|_\fR" 4
+.IX Item "__AVR_HAVE_RAMPD__"
+.PD 0
+.ie n .IP """_\|_AVR_HAVE_RAMPX_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_RAMPX_\|_\fR" 4
+.IX Item "__AVR_HAVE_RAMPX__"
+.ie n .IP """_\|_AVR_HAVE_RAMPY_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_RAMPY_\|_\fR" 4
+.IX Item "__AVR_HAVE_RAMPY__"
+.ie n .IP """_\|_AVR_HAVE_RAMPZ_\|_""" 4
+.el .IP "\f(CW_\|_AVR_HAVE_RAMPZ_\|_\fR" 4
+.IX Item "__AVR_HAVE_RAMPZ__"
+.PD
+The device has the \f(CW\*(C`RAMPD\*(C'\fR, \f(CW\*(C`RAMPX\*(C'\fR, \f(CW\*(C`RAMPY\*(C'\fR,
+\&\f(CW\*(C`RAMPZ\*(C'\fR special function register, respectively.
+.ie n .IP """_\|_NO_INTERRUPTS_\|_""" 4
+.el .IP "\f(CW_\|_NO_INTERRUPTS_\|_\fR" 4
+.IX Item "__NO_INTERRUPTS__"
+This macro reflects the \f(CW\*(C`\-mno\-interrupts\*(C'\fR command line option.
+.ie n .IP """_\|_AVR_ERRATA_SKIP_\|_""" 4
+.el .IP "\f(CW_\|_AVR_ERRATA_SKIP_\|_\fR" 4
+.IX Item "__AVR_ERRATA_SKIP__"
+.PD 0
+.ie n .IP """_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_""" 4
+.el .IP "\f(CW_\|_AVR_ERRATA_SKIP_JMP_CALL_\|_\fR" 4
+.IX Item "__AVR_ERRATA_SKIP_JMP_CALL__"
+.PD
+Some \s-1AVR\s0 devices (\s-1AT90S8515,\s0 ATmega103) must not skip 32\-bit
+instructions because of a hardware erratum.  Skip instructions are
+\&\f(CW\*(C`SBRS\*(C'\fR, \f(CW\*(C`SBRC\*(C'\fR, \f(CW\*(C`SBIS\*(C'\fR, \f(CW\*(C`SBIC\*(C'\fR and \f(CW\*(C`CPSE\*(C'\fR.
+The second macro is only defined if \f(CW\*(C`_\|_AVR_HAVE_JMP_CALL_\|_\*(C'\fR is also
+set.
+.ie n .IP """_\|_AVR_ISA_RMW_\|_""" 4
+.el .IP "\f(CW_\|_AVR_ISA_RMW_\|_\fR" 4
+.IX Item "__AVR_ISA_RMW__"
+The device has Read-Modify-Write instructions (\s-1XCH, LAC, LAS\s0 and \s-1LAT\s0).
+.ie n .IP """_\|_AVR_SFR_OFFSET_\|_=\f(CIoffset\f(CW""" 4
+.el .IP "\f(CW_\|_AVR_SFR_OFFSET_\|_=\f(CIoffset\f(CW\fR" 4
+.IX Item "__AVR_SFR_OFFSET__=offset"
+Instructions that can address I/O special function registers directly
+like \f(CW\*(C`IN\*(C'\fR, \f(CW\*(C`OUT\*(C'\fR, \f(CW\*(C`SBI\*(C'\fR, etc. may use a different
+address as if addressed by an instruction to access \s-1RAM\s0 like \f(CW\*(C`LD\*(C'\fR
+or \f(CW\*(C`STS\*(C'\fR. This offset depends on the device architecture and has
+to be subtracted from the \s-1RAM\s0 address in order to get the
+respective I/O@tie{}address.
+.ie n .IP """_\|_WITH_AVRLIBC_\|_""" 4
+.el .IP "\f(CW_\|_WITH_AVRLIBC_\|_\fR" 4
+.IX Item "__WITH_AVRLIBC__"
+The compiler is configured to be used together with AVR-Libc.
+See the \f(CW\*(C`\-\-with\-avrlibc\*(C'\fR configure option.
+.PP
+\fIBlackfin Options\fR
+.IX Subsection "Blackfin Options"
+.IP "\fB\-mcpu=\fR\fIcpu\fR[\fB\-\fR\fIsirevision\fR]" 4
+.IX Item "-mcpu=cpu[-sirevision]"
+Specifies the name of the target Blackfin processor.  Currently, \fIcpu\fR
+can be one of \fBbf512\fR, \fBbf514\fR, \fBbf516\fR, \fBbf518\fR,
+\&\fBbf522\fR, \fBbf523\fR, \fBbf524\fR, \fBbf525\fR, \fBbf526\fR,
+\&\fBbf527\fR, \fBbf531\fR, \fBbf532\fR, \fBbf533\fR,
+\&\fBbf534\fR, \fBbf536\fR, \fBbf537\fR, \fBbf538\fR, \fBbf539\fR,
+\&\fBbf542\fR, \fBbf544\fR, \fBbf547\fR, \fBbf548\fR, \fBbf549\fR,
+\&\fBbf542m\fR, \fBbf544m\fR, \fBbf547m\fR, \fBbf548m\fR, \fBbf549m\fR,
+\&\fBbf561\fR, \fBbf592\fR.
+.Sp
+The optional \fIsirevision\fR specifies the silicon revision of the target
+Blackfin processor.  Any workarounds available for the targeted silicon revision
+are enabled.  If \fIsirevision\fR is \fBnone\fR, no workarounds are enabled.
+If \fIsirevision\fR is \fBany\fR, all workarounds for the targeted processor
+are enabled.  The \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR macro is defined to two
+hexadecimal digits representing the major and minor numbers in the silicon
+revision.  If \fIsirevision\fR is \fBnone\fR, the \f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR
+is not defined.  If \fIsirevision\fR is \fBany\fR, the
+\&\f(CW\*(C`_\|_SILICON_REVISION_\|_\*(C'\fR is defined to be \f(CW0xffff\fR.
+If this optional \fIsirevision\fR is not used, \s-1GCC\s0 assumes the latest known
+silicon revision of the targeted Blackfin processor.
+.Sp
+\&\s-1GCC\s0 defines a preprocessor macro for the specified \fIcpu\fR.
+For the \fBbfin-elf\fR toolchain, this option causes the hardware \s-1BSP\s0
+provided by libgloss to be linked in if \fB\-msim\fR is not given.
+.Sp
+Without this option, \fBbf532\fR is used as the processor by default.
+.Sp
+Note that support for \fBbf561\fR is incomplete.  For \fBbf561\fR,
+only the preprocessor macro is defined.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Specifies that the program will be run on the simulator.  This causes
+the simulator \s-1BSP\s0 provided by libgloss to be linked in.  This option
+has effect only for \fBbfin-elf\fR toolchain.
+Certain other options, such as \fB\-mid\-shared\-library\fR and
+\&\fB\-mfdpic\fR, imply \fB\-msim\fR.
+.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
+.IX Item "-momit-leaf-frame-pointer"
+Don't keep the frame pointer in a register for leaf functions.  This
+avoids the instructions to save, set up and restore frame pointers and
+makes an extra register available in leaf functions.  The option
+\&\fB\-fomit\-frame\-pointer\fR removes the frame pointer for all functions,
+which might make debugging harder.
+.IP "\fB\-mspecld\-anomaly\fR" 4
+.IX Item "-mspecld-anomaly"
+When enabled, the compiler ensures that the generated code does not
+contain speculative loads after jump instructions. If this option is used,
+\&\f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_LOADS\*(C'\fR is defined.
+.IP "\fB\-mno\-specld\-anomaly\fR" 4
+.IX Item "-mno-specld-anomaly"
+Don't generate extra code to prevent speculative loads from occurring.
+.IP "\fB\-mcsync\-anomaly\fR" 4
+.IX Item "-mcsync-anomaly"
+When enabled, the compiler ensures that the generated code does not
+contain \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions too soon after conditional branches.
+If this option is used, \f(CW\*(C`_\|_WORKAROUND_SPECULATIVE_SYNCS\*(C'\fR is defined.
+.IP "\fB\-mno\-csync\-anomaly\fR" 4
+.IX Item "-mno-csync-anomaly"
+Don't generate extra code to prevent \s-1CSYNC\s0 or \s-1SSYNC\s0 instructions from
+occurring too soon after a conditional branch.
+.IP "\fB\-mlow\-64k\fR" 4
+.IX Item "-mlow-64k"
+When enabled, the compiler is free to take advantage of the knowledge that
+the entire program fits into the low 64k of memory.
+.IP "\fB\-mno\-low\-64k\fR" 4
+.IX Item "-mno-low-64k"
+Assume that the program is arbitrarily large.  This is the default.
+.IP "\fB\-mstack\-check\-l1\fR" 4
+.IX Item "-mstack-check-l1"
+Do stack checking using information placed into L1 scratchpad memory by the
+uClinux kernel.
+.IP "\fB\-mid\-shared\-library\fR" 4
+.IX Item "-mid-shared-library"
+Generate code that supports shared libraries via the library \s-1ID\s0 method.
+This allows for execute in place and shared libraries in an environment
+without virtual memory management.  This option implies \fB\-fPIC\fR.
+With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
+.IP "\fB\-mno\-id\-shared\-library\fR" 4
+.IX Item "-mno-id-shared-library"
+Generate code that doesn't assume ID-based shared libraries are being used.
+This is the default.
+.IP "\fB\-mleaf\-id\-shared\-library\fR" 4
+.IX Item "-mleaf-id-shared-library"
+Generate code that supports shared libraries via the library \s-1ID\s0 method,
+but assumes that this library or executable won't link against any other
+\&\s-1ID\s0 shared libraries.  That allows the compiler to use faster code for jumps
+and calls.
+.IP "\fB\-mno\-leaf\-id\-shared\-library\fR" 4
+.IX Item "-mno-leaf-id-shared-library"
+Do not assume that the code being compiled won't link against any \s-1ID\s0 shared
+libraries.  Slower code is generated for jump and call insns.
+.IP "\fB\-mshared\-library\-id=n\fR" 4
+.IX Item "-mshared-library-id=n"
+Specifies the identification number of the ID-based shared library being
+compiled.  Specifying a value of 0 generates more compact code; specifying
+other values forces the allocation of that number to the current
+library but is no more space\- or time-efficient than omitting this option.
+.IP "\fB\-msep\-data\fR" 4
+.IX Item "-msep-data"
+Generate code that allows the data segment to be located in a different
+area of memory from the text segment.  This allows for execute in place in
+an environment without virtual memory management by eliminating relocations
+against the text section.
+.IP "\fB\-mno\-sep\-data\fR" 4
+.IX Item "-mno-sep-data"
+Generate code that assumes that the data segment follows the text segment.
+This is the default.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+.PD 0
+.IP "\fB\-mno\-long\-calls\fR" 4
+.IX Item "-mno-long-calls"
+.PD
+Tells the compiler to perform function calls by first loading the
+address of the function into a register and then performing a subroutine
+call on this register.  This switch is needed if the target function
+lies outside of the 24\-bit addressing range of the offset-based
+version of subroutine call instruction.
+.Sp
+This feature is not enabled by default.  Specifying
+\&\fB\-mno\-long\-calls\fR restores the default behavior.  Note these
+switches have no effect on how the compiler generates code to handle
+function calls via function pointers.
+.IP "\fB\-mfast\-fp\fR" 4
+.IX Item "-mfast-fp"
+Link with the fast floating-point library. This library relaxes some of
+the \s-1IEEE\s0 floating-point standard's rules for checking inputs against
+Not-a-Number (\s-1NAN\s0), in the interest of performance.
+.IP "\fB\-minline\-plt\fR" 4
+.IX Item "-minline-plt"
+Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
+not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
+.IP "\fB\-mmulticore\fR" 4
+.IX Item "-mmulticore"
+Build a standalone application for multicore Blackfin processors. 
+This option causes proper start files and link scripts supporting 
+multicore to be used, and defines the macro \f(CW\*(C`_\|_BFIN_MULTICORE\*(C'\fR. 
+It can only be used with \fB\-mcpu=bf561\fR[\fB\-\fR\fIsirevision\fR].
+.Sp
+This option can be used with \fB\-mcorea\fR or \fB\-mcoreb\fR, which
+selects the one-application-per-core programming model.  Without
+\&\fB\-mcorea\fR or \fB\-mcoreb\fR, the single\-application/dual\-core
+programming model is used. In this model, the main function of Core B
+should be named as \f(CW\*(C`coreb_main\*(C'\fR.
+.Sp
+If this option is not used, the single-core application programming
+model is used.
+.IP "\fB\-mcorea\fR" 4
+.IX Item "-mcorea"
+Build a standalone application for Core A of \s-1BF561\s0 when using
+the one-application-per-core programming model. Proper start files
+and link scripts are used to support Core A, and the macro
+\&\f(CW\*(C`_\|_BFIN_COREA\*(C'\fR is defined.
+This option can only be used in conjunction with \fB\-mmulticore\fR.
+.IP "\fB\-mcoreb\fR" 4
+.IX Item "-mcoreb"
+Build a standalone application for Core B of \s-1BF561\s0 when using
+the one-application-per-core programming model. Proper start files
+and link scripts are used to support Core B, and the macro
+\&\f(CW\*(C`_\|_BFIN_COREB\*(C'\fR is defined. When this option is used, \f(CW\*(C`coreb_main\*(C'\fR
+should be used instead of \f(CW\*(C`main\*(C'\fR. 
+This option can only be used in conjunction with \fB\-mmulticore\fR.
+.IP "\fB\-msdram\fR" 4
+.IX Item "-msdram"
+Build a standalone application for \s-1SDRAM.\s0 Proper start files and
+link scripts are used to put the application into \s-1SDRAM,\s0 and the macro
+\&\f(CW\*(C`_\|_BFIN_SDRAM\*(C'\fR is defined.
+The loader should initialize \s-1SDRAM\s0 before loading the application.
+.IP "\fB\-micplb\fR" 4
+.IX Item "-micplb"
+Assume that ICPLBs are enabled at run time.  This has an effect on certain
+anomaly workarounds.  For Linux targets, the default is to assume ICPLBs
+are enabled; for standalone applications the default is off.
+.PP
+\fIC6X Options\fR
+.IX Subsection "C6X Options"
+.IP "\fB\-march=\fR\fIname\fR" 4
+.IX Item "-march=name"
+This specifies the name of the target architecture.  \s-1GCC\s0 uses this
+name to determine what kind of instructions it can emit when generating
+assembly code.  Permissible names are: \fBc62x\fR,
+\&\fBc64x\fR, \fBc64x+\fR, \fBc67x\fR, \fBc67x+\fR, \fBc674x\fR.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code for a big-endian target.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code for a little-endian target.  This is the default.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Choose startup files and linker script suitable for the simulator.
+.IP "\fB\-msdata=default\fR" 4
+.IX Item "-msdata=default"
+Put small global and static data in the \fB.neardata\fR section,
+which is pointed to by register \f(CW\*(C`B14\*(C'\fR.  Put small uninitialized
+global and static data in the \fB.bss\fR section, which is adjacent
+to the \fB.neardata\fR section.  Put small read-only data into the
+\&\fB.rodata\fR section.  The corresponding sections used for large
+pieces of data are \fB.fardata\fR, \fB.far\fR and \fB.const\fR.
+.IP "\fB\-msdata=all\fR" 4
+.IX Item "-msdata=all"
+Put all data, not just small objects, into the sections reserved for
+small data, and use addressing relative to the \f(CW\*(C`B14\*(C'\fR register to
+access them.
+.IP "\fB\-msdata=none\fR" 4
+.IX Item "-msdata=none"
+Make no use of the sections reserved for small data, and use absolute
+addresses to access all data.  Put all initialized global and static
+data in the \fB.fardata\fR section, and all uninitialized data in the
+\&\fB.far\fR section.  Put all constant data into the \fB.const\fR
+section.
+.PP
+\fI\s-1CRIS\s0 Options\fR
+.IX Subsection "CRIS Options"
+.PP
+These options are defined specifically for the \s-1CRIS\s0 ports.
+.IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
+.IX Item "-march=architecture-type"
+.PD 0
+.IP "\fB\-mcpu=\fR\fIarchitecture-type\fR" 4
+.IX Item "-mcpu=architecture-type"
+.PD
+Generate code for the specified architecture.  The choices for
+\&\fIarchitecture-type\fR are \fBv3\fR, \fBv8\fR and \fBv10\fR for
+respectively \s-1ETRAX\s0\ 4, \s-1ETRAX\s0\ 100, and \s-1ETRAX\s0\ 100\ \s-1LX.\s0
+Default is \fBv0\fR except for cris-axis-linux-gnu, where the default is
+\&\fBv10\fR.
+.IP "\fB\-mtune=\fR\fIarchitecture-type\fR" 4
+.IX Item "-mtune=architecture-type"
+Tune to \fIarchitecture-type\fR everything applicable about the generated
+code, except for the \s-1ABI\s0 and the set of available instructions.  The
+choices for \fIarchitecture-type\fR are the same as for
+\&\fB\-march=\fR\fIarchitecture-type\fR.
+.IP "\fB\-mmax\-stack\-frame=\fR\fIn\fR" 4
+.IX Item "-mmax-stack-frame=n"
+Warn when the stack frame of a function exceeds \fIn\fR bytes.
+.IP "\fB\-metrax4\fR" 4
+.IX Item "-metrax4"
+.PD 0
+.IP "\fB\-metrax100\fR" 4
+.IX Item "-metrax100"
+.PD
+The options \fB\-metrax4\fR and \fB\-metrax100\fR are synonyms for
+\&\fB\-march=v3\fR and \fB\-march=v8\fR respectively.
+.IP "\fB\-mmul\-bug\-workaround\fR" 4
+.IX Item "-mmul-bug-workaround"
+.PD 0
+.IP "\fB\-mno\-mul\-bug\-workaround\fR" 4
+.IX Item "-mno-mul-bug-workaround"
+.PD
+Work around a bug in the \f(CW\*(C`muls\*(C'\fR and \f(CW\*(C`mulu\*(C'\fR instructions for \s-1CPU\s0
+models where it applies.  This option is active by default.
+.IP "\fB\-mpdebug\fR" 4
+.IX Item "-mpdebug"
+Enable CRIS-specific verbose debug-related information in the assembly
+code.  This option also has the effect of turning off the \fB#NO_APP\fR
+formatted-code indicator to the assembler at the beginning of the
+assembly file.
+.IP "\fB\-mcc\-init\fR" 4
+.IX Item "-mcc-init"
+Do not use condition-code results from previous instruction; always emit
+compare and test instructions before use of condition codes.
+.IP "\fB\-mno\-side\-effects\fR" 4
+.IX Item "-mno-side-effects"
+Do not emit instructions with side effects in addressing modes other than
+post-increment.
+.IP "\fB\-mstack\-align\fR" 4
+.IX Item "-mstack-align"
+.PD 0
+.IP "\fB\-mno\-stack\-align\fR" 4
+.IX Item "-mno-stack-align"
+.IP "\fB\-mdata\-align\fR" 4
+.IX Item "-mdata-align"
+.IP "\fB\-mno\-data\-align\fR" 4
+.IX Item "-mno-data-align"
+.IP "\fB\-mconst\-align\fR" 4
+.IX Item "-mconst-align"
+.IP "\fB\-mno\-const\-align\fR" 4
+.IX Item "-mno-const-align"
+.PD
+These options (\fBno\-\fR options) arrange (eliminate arrangements) for the
+stack frame, individual data and constants to be aligned for the maximum
+single data access size for the chosen \s-1CPU\s0 model.  The default is to
+arrange for 32\-bit alignment.  \s-1ABI\s0 details such as structure layout are
+not affected by these options.
+.IP "\fB\-m32\-bit\fR" 4
+.IX Item "-m32-bit"
+.PD 0
+.IP "\fB\-m16\-bit\fR" 4
+.IX Item "-m16-bit"
+.IP "\fB\-m8\-bit\fR" 4
+.IX Item "-m8-bit"
+.PD
+Similar to the stack\- data\- and const-align options above, these options
+arrange for stack frame, writable data and constants to all be 32\-bit,
+16\-bit or 8\-bit aligned.  The default is 32\-bit alignment.
+.IP "\fB\-mno\-prologue\-epilogue\fR" 4
+.IX Item "-mno-prologue-epilogue"
+.PD 0
+.IP "\fB\-mprologue\-epilogue\fR" 4
+.IX Item "-mprologue-epilogue"
+.PD
+With \fB\-mno\-prologue\-epilogue\fR, the normal function prologue and
+epilogue which set up the stack frame are omitted and no return
+instructions or return sequences are generated in the code.  Use this
+option only together with visual inspection of the compiled code: no
+warnings or errors are generated when call-saved registers must be saved,
+or storage for local variables needs to be allocated.
+.IP "\fB\-mno\-gotplt\fR" 4
+.IX Item "-mno-gotplt"
+.PD 0
+.IP "\fB\-mgotplt\fR" 4
+.IX Item "-mgotplt"
+.PD
+With \fB\-fpic\fR and \fB\-fPIC\fR, don't generate (do generate)
+instruction sequences that load addresses for functions from the \s-1PLT\s0 part
+of the \s-1GOT\s0 rather than (traditional on other architectures) calls to the
+\&\s-1PLT. \s0 The default is \fB\-mgotplt\fR.
+.IP "\fB\-melf\fR" 4
+.IX Item "-melf"
+Legacy no-op option only recognized with the cris-axis-elf and
+cris-axis-linux-gnu targets.
+.IP "\fB\-mlinux\fR" 4
+.IX Item "-mlinux"
+Legacy no-op option only recognized with the cris-axis-linux-gnu target.
+.IP "\fB\-sim\fR" 4
+.IX Item "-sim"
+This option, recognized for the cris-axis-elf, arranges
+to link with input-output functions from a simulator library.  Code,
+initialized data and zero-initialized data are allocated consecutively.
+.IP "\fB\-sim2\fR" 4
+.IX Item "-sim2"
+Like \fB\-sim\fR, but pass linker options to locate initialized data at
+0x40000000 and zero-initialized data at 0x80000000.
+.PP
+\fI\s-1CR16\s0 Options\fR
+.IX Subsection "CR16 Options"
+.PP
+These options are defined specifically for the \s-1CR16\s0 ports.
+.IP "\fB\-mmac\fR" 4
+.IX Item "-mmac"
+Enable the use of multiply-accumulate instructions. Disabled by default.
+.IP "\fB\-mcr16cplus\fR" 4
+.IX Item "-mcr16cplus"
+.PD 0
+.IP "\fB\-mcr16c\fR" 4
+.IX Item "-mcr16c"
+.PD
+Generate code for \s-1CR16C\s0 or \s-1CR16C+\s0 architecture. \s-1CR16C+\s0 architecture 
+is default.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Links the library libsim.a which is in compatible with simulator. Applicable
+to \s-1ELF\s0 compiler only.
+.IP "\fB\-mint32\fR" 4
+.IX Item "-mint32"
+Choose integer type as 32\-bit wide.
+.IP "\fB\-mbit\-ops\fR" 4
+.IX Item "-mbit-ops"
+Generates \f(CW\*(C`sbit\*(C'\fR/\f(CW\*(C`cbit\*(C'\fR instructions for bit manipulations.
+.IP "\fB\-mdata\-model=\fR\fImodel\fR" 4
+.IX Item "-mdata-model=model"
+Choose a data model. The choices for \fImodel\fR are \fBnear\fR,
+\&\fBfar\fR or \fBmedium\fR. \fBmedium\fR is default.
+However, \fBfar\fR is not valid with \fB\-mcr16c\fR, as the
+\&\s-1CR16C\s0 architecture does not support the far data model.
+.PP
+\fIDarwin Options\fR
+.IX Subsection "Darwin Options"
+.PP
+These options are defined for all architectures running the Darwin operating
+system.
+.PP
+\&\s-1FSF GCC\s0 on Darwin does not create \*(L"fat\*(R" object files; it creates
+an object file for the single architecture that \s-1GCC\s0 was built to
+target.  Apple's \s-1GCC\s0 on Darwin does create \*(L"fat\*(R" files if multiple
+\&\fB\-arch\fR options are used; it does so by running the compiler or
+linker multiple times and joining the results together with
+\&\fIlipo\fR.
+.PP
+The subtype of the file created (like \fBppc7400\fR or \fBppc970\fR or
+\&\fBi686\fR) is determined by the flags that specify the \s-1ISA\s0
+that \s-1GCC\s0 is targeting, like \fB\-mcpu\fR or \fB\-march\fR.  The
+\&\fB\-force_cpusubtype_ALL\fR option can be used to override this.
+.PP
+The Darwin tools vary in their behavior when presented with an \s-1ISA\s0
+mismatch.  The assembler, \fIas\fR, only permits instructions to
+be used that are valid for the subtype of the file it is generating,
+so you cannot put 64\-bit instructions in a \fBppc750\fR object file.
+The linker for shared libraries, \fI/usr/bin/libtool\fR, fails
+and prints an error if asked to create a shared library with a less
+restrictive subtype than its input files (for instance, trying to put
+a \fBppc970\fR object file in a \fBppc7400\fR library).  The linker
+for executables, \fBld\fR, quietly gives the executable the most
+restrictive subtype of any of its input files.
+.IP "\fB\-F\fR\fIdir\fR" 4
+.IX Item "-Fdir"
+Add the framework directory \fIdir\fR to the head of the list of
+directories to be searched for header files.  These directories are
+interleaved with those specified by \fB\-I\fR options and are
+scanned in a left-to-right order.
+.Sp
+A framework directory is a directory with frameworks in it.  A
+framework is a directory with a \fIHeaders\fR and/or
+\&\fIPrivateHeaders\fR directory contained directly in it that ends
+in \fI.framework\fR.  The name of a framework is the name of this
+directory excluding the \fI.framework\fR.  Headers associated with
+the framework are found in one of those two directories, with
+\&\fIHeaders\fR being searched first.  A subframework is a framework
+directory that is in a framework's \fIFrameworks\fR directory.
+Includes of subframework headers can only appear in a header of a
+framework that contains the subframework, or in a sibling subframework
+header.  Two subframeworks are siblings if they occur in the same
+framework.  A subframework should not have the same name as a
+framework; a warning is issued if this is violated.  Currently a
+subframework cannot have subframeworks; in the future, the mechanism
+may be extended to support this.  The standard frameworks can be found
+in \fI/System/Library/Frameworks\fR and
+\&\fI/Library/Frameworks\fR.  An example include looks like
+\&\f(CW\*(C`#include <Framework/header.h>\*(C'\fR, where \fIFramework\fR denotes
+the name of the framework and \fIheader.h\fR is found in the
+\&\fIPrivateHeaders\fR or \fIHeaders\fR directory.
+.IP "\fB\-iframework\fR\fIdir\fR" 4
+.IX Item "-iframeworkdir"
+Like \fB\-F\fR except the directory is a treated as a system
+directory.  The main difference between this \fB\-iframework\fR and
+\&\fB\-F\fR is that with \fB\-iframework\fR the compiler does not
+warn about constructs contained within header files found via
+\&\fIdir\fR.  This option is valid only for the C family of languages.
+.IP "\fB\-gused\fR" 4
+.IX Item "-gused"
+Emit debugging information for symbols that are used.  For stabs
+debugging format, this enables \fB\-feliminate\-unused\-debug\-symbols\fR.
+This is by default \s-1ON.\s0
+.IP "\fB\-gfull\fR" 4
+.IX Item "-gfull"
+Emit debugging information for all symbols and types.
+.IP "\fB\-mmacosx\-version\-min=\fR\fIversion\fR" 4
+.IX Item "-mmacosx-version-min=version"
+The earliest version of MacOS X that this executable will run on
+is \fIversion\fR.  Typical values of \fIversion\fR include \f(CW10.1\fR,
+\&\f(CW10.2\fR, and \f(CW10.3.9\fR.
+.Sp
+If the compiler was built to use the system's headers by default,
+then the default for this option is the system version on which the
+compiler is running, otherwise the default is to make choices that
+are compatible with as many systems and code bases as possible.
+.IP "\fB\-mkernel\fR" 4
+.IX Item "-mkernel"
+Enable kernel development mode.  The \fB\-mkernel\fR option sets
+\&\fB\-static\fR, \fB\-fno\-common\fR, \fB\-fno\-cxa\-atexit\fR,
+\&\fB\-fno\-exceptions\fR, \fB\-fno\-non\-call\-exceptions\fR,
+\&\fB\-fapple\-kext\fR, \fB\-fno\-weak\fR and \fB\-fno\-rtti\fR where
+applicable.  This mode also sets \fB\-mno\-altivec\fR,
+\&\fB\-msoft\-float\fR, \fB\-fno\-builtin\fR and
+\&\fB\-mlong\-branch\fR for PowerPC targets.
+.IP "\fB\-mone\-byte\-bool\fR" 4
+.IX Item "-mone-byte-bool"
+Override the defaults for \fBbool\fR so that \fBsizeof(bool)==1\fR.
+By default \fBsizeof(bool)\fR is \fB4\fR when compiling for
+Darwin/PowerPC and \fB1\fR when compiling for Darwin/x86, so this
+option has no effect on x86.
+.Sp
+\&\fBWarning:\fR The \fB\-mone\-byte\-bool\fR switch causes \s-1GCC\s0
+to generate code that is not binary compatible with code generated
+without that switch.  Using this switch may require recompiling all
+other modules in a program, including system libraries.  Use this
+switch to conform to a non-default data model.
+.IP "\fB\-mfix\-and\-continue\fR" 4
+.IX Item "-mfix-and-continue"
+.PD 0
+.IP "\fB\-ffix\-and\-continue\fR" 4
+.IX Item "-ffix-and-continue"
+.IP "\fB\-findirect\-data\fR" 4
+.IX Item "-findirect-data"
+.PD
+Generate code suitable for fast turnaround development, such as to
+allow \s-1GDB\s0 to dynamically load \f(CW\*(C`.o\*(C'\fR files into already-running
+programs.  \fB\-findirect\-data\fR and \fB\-ffix\-and\-continue\fR
+are provided for backwards compatibility.
+.IP "\fB\-all_load\fR" 4
+.IX Item "-all_load"
+Loads all members of static archive libraries.
+See man \fIld\fR\|(1) for more information.
+.IP "\fB\-arch_errors_fatal\fR" 4
+.IX Item "-arch_errors_fatal"
+Cause the errors having to do with files that have the wrong architecture
+to be fatal.
+.IP "\fB\-bind_at_load\fR" 4
+.IX Item "-bind_at_load"
+Causes the output file to be marked such that the dynamic linker will
+bind all undefined references when the file is loaded or launched.
+.IP "\fB\-bundle\fR" 4
+.IX Item "-bundle"
+Produce a Mach-o bundle format file.
+See man \fIld\fR\|(1) for more information.
+.IP "\fB\-bundle_loader\fR \fIexecutable\fR" 4
+.IX Item "-bundle_loader executable"
+This option specifies the \fIexecutable\fR that will load the build
+output file being linked.  See man \fIld\fR\|(1) for more information.
+.IP "\fB\-dynamiclib\fR" 4
+.IX Item "-dynamiclib"
+When passed this option, \s-1GCC\s0 produces a dynamic library instead of
+an executable when linking, using the Darwin \fIlibtool\fR command.
+.IP "\fB\-force_cpusubtype_ALL\fR" 4
+.IX Item "-force_cpusubtype_ALL"
+This causes \s-1GCC\s0's output file to have the \fI\s-1ALL\s0\fR subtype, instead of
+one controlled by the \fB\-mcpu\fR or \fB\-march\fR option.
+.IP "\fB\-allowable_client\fR  \fIclient_name\fR" 4
+.IX Item "-allowable_client client_name"
+.PD 0
+.IP "\fB\-client_name\fR" 4
+.IX Item "-client_name"
+.IP "\fB\-compatibility_version\fR" 4
+.IX Item "-compatibility_version"
+.IP "\fB\-current_version\fR" 4
+.IX Item "-current_version"
+.IP "\fB\-dead_strip\fR" 4
+.IX Item "-dead_strip"
+.IP "\fB\-dependency\-file\fR" 4
+.IX Item "-dependency-file"
+.IP "\fB\-dylib_file\fR" 4
+.IX Item "-dylib_file"
+.IP "\fB\-dylinker_install_name\fR" 4
+.IX Item "-dylinker_install_name"
+.IP "\fB\-dynamic\fR" 4
+.IX Item "-dynamic"
+.IP "\fB\-exported_symbols_list\fR" 4
+.IX Item "-exported_symbols_list"
+.IP "\fB\-filelist\fR" 4
+.IX Item "-filelist"
+.IP "\fB\-flat_namespace\fR" 4
+.IX Item "-flat_namespace"
+.IP "\fB\-force_flat_namespace\fR" 4
+.IX Item "-force_flat_namespace"
+.IP "\fB\-headerpad_max_install_names\fR" 4
+.IX Item "-headerpad_max_install_names"
+.IP "\fB\-image_base\fR" 4
+.IX Item "-image_base"
+.IP "\fB\-init\fR" 4
+.IX Item "-init"
+.IP "\fB\-install_name\fR" 4
+.IX Item "-install_name"
+.IP "\fB\-keep_private_externs\fR" 4
+.IX Item "-keep_private_externs"
+.IP "\fB\-multi_module\fR" 4
+.IX Item "-multi_module"
+.IP "\fB\-multiply_defined\fR" 4
+.IX Item "-multiply_defined"
+.IP "\fB\-multiply_defined_unused\fR" 4
+.IX Item "-multiply_defined_unused"
+.IP "\fB\-noall_load\fR" 4
+.IX Item "-noall_load"
+.IP "\fB\-no_dead_strip_inits_and_terms\fR" 4
+.IX Item "-no_dead_strip_inits_and_terms"
+.IP "\fB\-nofixprebinding\fR" 4
+.IX Item "-nofixprebinding"
+.IP "\fB\-nomultidefs\fR" 4
+.IX Item "-nomultidefs"
+.IP "\fB\-noprebind\fR" 4
+.IX Item "-noprebind"
+.IP "\fB\-noseglinkedit\fR" 4
+.IX Item "-noseglinkedit"
+.IP "\fB\-pagezero_size\fR" 4
+.IX Item "-pagezero_size"
+.IP "\fB\-prebind\fR" 4
+.IX Item "-prebind"
+.IP "\fB\-prebind_all_twolevel_modules\fR" 4
+.IX Item "-prebind_all_twolevel_modules"
+.IP "\fB\-private_bundle\fR" 4
+.IX Item "-private_bundle"
+.IP "\fB\-read_only_relocs\fR" 4
+.IX Item "-read_only_relocs"
+.IP "\fB\-sectalign\fR" 4
+.IX Item "-sectalign"
+.IP "\fB\-sectobjectsymbols\fR" 4
+.IX Item "-sectobjectsymbols"
+.IP "\fB\-whyload\fR" 4
+.IX Item "-whyload"
+.IP "\fB\-seg1addr\fR" 4
+.IX Item "-seg1addr"
+.IP "\fB\-sectcreate\fR" 4
+.IX Item "-sectcreate"
+.IP "\fB\-sectobjectsymbols\fR" 4
+.IX Item "-sectobjectsymbols"
+.IP "\fB\-sectorder\fR" 4
+.IX Item "-sectorder"
+.IP "\fB\-segaddr\fR" 4
+.IX Item "-segaddr"
+.IP "\fB\-segs_read_only_addr\fR" 4
+.IX Item "-segs_read_only_addr"
+.IP "\fB\-segs_read_write_addr\fR" 4
+.IX Item "-segs_read_write_addr"
+.IP "\fB\-seg_addr_table\fR" 4
+.IX Item "-seg_addr_table"
+.IP "\fB\-seg_addr_table_filename\fR" 4
+.IX Item "-seg_addr_table_filename"
+.IP "\fB\-seglinkedit\fR" 4
+.IX Item "-seglinkedit"
+.IP "\fB\-segprot\fR" 4
+.IX Item "-segprot"
+.IP "\fB\-segs_read_only_addr\fR" 4
+.IX Item "-segs_read_only_addr"
+.IP "\fB\-segs_read_write_addr\fR" 4
+.IX Item "-segs_read_write_addr"
+.IP "\fB\-single_module\fR" 4
+.IX Item "-single_module"
+.IP "\fB\-static\fR" 4
+.IX Item "-static"
+.IP "\fB\-sub_library\fR" 4
+.IX Item "-sub_library"
+.IP "\fB\-sub_umbrella\fR" 4
+.IX Item "-sub_umbrella"
+.IP "\fB\-twolevel_namespace\fR" 4
+.IX Item "-twolevel_namespace"
+.IP "\fB\-umbrella\fR" 4
+.IX Item "-umbrella"
+.IP "\fB\-undefined\fR" 4
+.IX Item "-undefined"
+.IP "\fB\-unexported_symbols_list\fR" 4
+.IX Item "-unexported_symbols_list"
+.IP "\fB\-weak_reference_mismatches\fR" 4
+.IX Item "-weak_reference_mismatches"
+.IP "\fB\-whatsloaded\fR" 4
+.IX Item "-whatsloaded"
+.PD
+These options are passed to the Darwin linker.  The Darwin linker man page
+describes them in detail.
+.PP
+\fI\s-1DEC\s0 Alpha Options\fR
+.IX Subsection "DEC Alpha Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1DEC\s0 Alpha implementations:
+.IP "\fB\-mno\-soft\-float\fR" 4
+.IX Item "-mno-soft-float"
+.PD 0
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD
+Use (do not use) the hardware floating-point instructions for
+floating-point operations.  When \fB\-msoft\-float\fR is specified,
+functions in \fIlibgcc.a\fR are used to perform floating-point
+operations.  Unless they are replaced by routines that emulate the
+floating-point operations, or compiled in such a way as to call such
+emulations routines, these routines issue floating-point
+operations.   If you are compiling for an Alpha without floating-point
+operations, you must ensure that the library is built so as not to call
+them.
+.Sp
+Note that Alpha implementations without floating-point operations are
+required to have floating-point registers.
+.IP "\fB\-mfp\-reg\fR" 4
+.IX Item "-mfp-reg"
+.PD 0
+.IP "\fB\-mno\-fp\-regs\fR" 4
+.IX Item "-mno-fp-regs"
+.PD
+Generate code that uses (does not use) the floating-point register set.
+\&\fB\-mno\-fp\-regs\fR implies \fB\-msoft\-float\fR.  If the floating-point
+register set is not used, floating-point operands are passed in integer
+registers as if they were integers and floating-point results are passed
+in \f(CW$0\fR instead of \f(CW$f0\fR.  This is a non-standard calling sequence,
+so any function with a floating-point argument or return value called by code
+compiled with \fB\-mno\-fp\-regs\fR must also be compiled with that
+option.
+.Sp
+A typical use of this option is building a kernel that does not use,
+and hence need not save and restore, any floating-point registers.
+.IP "\fB\-mieee\fR" 4
+.IX Item "-mieee"
+The Alpha architecture implements floating-point hardware optimized for
+maximum performance.  It is mostly compliant with the \s-1IEEE\s0 floating-point
+standard.  However, for full compliance, software assistance is
+required.  This option generates code fully IEEE-compliant code
+\&\fIexcept\fR that the \fIinexact-flag\fR is not maintained (see below).
+If this option is turned on, the preprocessor macro \f(CW\*(C`_IEEE_FP\*(C'\fR is
+defined during compilation.  The resulting code is less efficient but is
+able to correctly support denormalized numbers and exceptional \s-1IEEE\s0
+values such as not-a-number and plus/minus infinity.  Other Alpha
+compilers call this option \fB\-ieee_with_no_inexact\fR.
+.IP "\fB\-mieee\-with\-inexact\fR" 4
+.IX Item "-mieee-with-inexact"
+This is like \fB\-mieee\fR except the generated code also maintains
+the \s-1IEEE \s0\fIinexact-flag\fR.  Turning on this option causes the
+generated code to implement fully-compliant \s-1IEEE\s0 math.  In addition to
+\&\f(CW\*(C`_IEEE_FP\*(C'\fR, \f(CW\*(C`_IEEE_FP_EXACT\*(C'\fR is defined as a preprocessor
+macro.  On some Alpha implementations the resulting code may execute
+significantly slower than the code generated by default.  Since there is
+very little code that depends on the \fIinexact-flag\fR, you should
+normally not specify this option.  Other Alpha compilers call this
+option \fB\-ieee_with_inexact\fR.
+.IP "\fB\-mfp\-trap\-mode=\fR\fItrap-mode\fR" 4
+.IX Item "-mfp-trap-mode=trap-mode"
+This option controls what floating-point related traps are enabled.
+Other Alpha compilers call this option \fB\-fptm\fR \fItrap-mode\fR.
+The trap mode can be set to one of four values:
+.RS 4
+.IP "\fBn\fR" 4
+.IX Item "n"
+This is the default (normal) setting.  The only traps that are enabled
+are the ones that cannot be disabled in software (e.g., division by zero
+trap).
+.IP "\fBu\fR" 4
+.IX Item "u"
+In addition to the traps enabled by \fBn\fR, underflow traps are enabled
+as well.
+.IP "\fBsu\fR" 4
+.IX Item "su"
+Like \fBu\fR, but the instructions are marked to be safe for software
+completion (see Alpha architecture manual for details).
+.IP "\fBsui\fR" 4
+.IX Item "sui"
+Like \fBsu\fR, but inexact traps are enabled as well.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mfp\-rounding\-mode=\fR\fIrounding-mode\fR" 4
+.IX Item "-mfp-rounding-mode=rounding-mode"
+Selects the \s-1IEEE\s0 rounding mode.  Other Alpha compilers call this option
+\&\fB\-fprm\fR \fIrounding-mode\fR.  The \fIrounding-mode\fR can be one
+of:
+.RS 4
+.IP "\fBn\fR" 4
+.IX Item "n"
+Normal \s-1IEEE\s0 rounding mode.  Floating-point numbers are rounded towards
+the nearest machine number or towards the even machine number in case
+of a tie.
+.IP "\fBm\fR" 4
+.IX Item "m"
+Round towards minus infinity.
+.IP "\fBc\fR" 4
+.IX Item "c"
+Chopped rounding mode.  Floating-point numbers are rounded towards zero.
+.IP "\fBd\fR" 4
+.IX Item "d"
+Dynamic rounding mode.  A field in the floating-point control register
+(\fIfpcr\fR, see Alpha architecture reference manual) controls the
+rounding mode in effect.  The C library initializes this register for
+rounding towards plus infinity.  Thus, unless your program modifies the
+\&\fIfpcr\fR, \fBd\fR corresponds to round towards plus infinity.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mtrap\-precision=\fR\fItrap-precision\fR" 4
+.IX Item "-mtrap-precision=trap-precision"
+In the Alpha architecture, floating-point traps are imprecise.  This
+means without software assistance it is impossible to recover from a
+floating trap and program execution normally needs to be terminated.
+\&\s-1GCC\s0 can generate code that can assist operating system trap handlers
+in determining the exact location that caused a floating-point trap.
+Depending on the requirements of an application, different levels of
+precisions can be selected:
+.RS 4
+.IP "\fBp\fR" 4
+.IX Item "p"
+Program precision.  This option is the default and means a trap handler
+can only identify which program caused a floating-point exception.
+.IP "\fBf\fR" 4
+.IX Item "f"
+Function precision.  The trap handler can determine the function that
+caused a floating-point exception.
+.IP "\fBi\fR" 4
+.IX Item "i"
+Instruction precision.  The trap handler can determine the exact
+instruction that caused a floating-point exception.
+.RE
+.RS 4
+.Sp
+Other Alpha compilers provide the equivalent options called
+\&\fB\-scope_safe\fR and \fB\-resumption_safe\fR.
+.RE
+.IP "\fB\-mieee\-conformant\fR" 4
+.IX Item "-mieee-conformant"
+This option marks the generated code as \s-1IEEE\s0 conformant.  You must not
+use this option unless you also specify \fB\-mtrap\-precision=i\fR and either
+\&\fB\-mfp\-trap\-mode=su\fR or \fB\-mfp\-trap\-mode=sui\fR.  Its only effect
+is to emit the line \fB.eflag 48\fR in the function prologue of the
+generated assembly file.
+.IP "\fB\-mbuild\-constants\fR" 4
+.IX Item "-mbuild-constants"
+Normally \s-1GCC\s0 examines a 32\- or 64\-bit integer constant to
+see if it can construct it from smaller constants in two or three
+instructions.  If it cannot, it outputs the constant as a literal and
+generates code to load it from the data segment at run time.
+.Sp
+Use this option to require \s-1GCC\s0 to construct \fIall\fR integer constants
+using code, even if it takes more instructions (the maximum is six).
+.Sp
+You typically use this option to build a shared library dynamic
+loader.  Itself a shared library, it must relocate itself in memory
+before it can find the variables and constants in its own data segment.
+.IP "\fB\-mbwx\fR" 4
+.IX Item "-mbwx"
+.PD 0
+.IP "\fB\-mno\-bwx\fR" 4
+.IX Item "-mno-bwx"
+.IP "\fB\-mcix\fR" 4
+.IX Item "-mcix"
+.IP "\fB\-mno\-cix\fR" 4
+.IX Item "-mno-cix"
+.IP "\fB\-mfix\fR" 4
+.IX Item "-mfix"
+.IP "\fB\-mno\-fix\fR" 4
+.IX Item "-mno-fix"
+.IP "\fB\-mmax\fR" 4
+.IX Item "-mmax"
+.IP "\fB\-mno\-max\fR" 4
+.IX Item "-mno-max"
+.PD
+Indicate whether \s-1GCC\s0 should generate code to use the optional \s-1BWX,
+CIX, FIX\s0 and \s-1MAX\s0 instruction sets.  The default is to use the instruction
+sets supported by the \s-1CPU\s0 type specified via \fB\-mcpu=\fR option or that
+of the \s-1CPU\s0 on which \s-1GCC\s0 was built if none is specified.
+.IP "\fB\-mfloat\-vax\fR" 4
+.IX Item "-mfloat-vax"
+.PD 0
+.IP "\fB\-mfloat\-ieee\fR" 4
+.IX Item "-mfloat-ieee"
+.PD
+Generate code that uses (does not use) \s-1VAX F\s0 and G floating-point
+arithmetic instead of \s-1IEEE\s0 single and double precision.
+.IP "\fB\-mexplicit\-relocs\fR" 4
+.IX Item "-mexplicit-relocs"
+.PD 0
+.IP "\fB\-mno\-explicit\-relocs\fR" 4
+.IX Item "-mno-explicit-relocs"
+.PD
+Older Alpha assemblers provided no way to generate symbol relocations
+except via assembler macros.  Use of these macros does not allow
+optimal instruction scheduling.  \s-1GNU\s0 binutils as of version 2.12
+supports a new syntax that allows the compiler to explicitly mark
+which relocations should apply to which instructions.  This option
+is mostly useful for debugging, as \s-1GCC\s0 detects the capabilities of
+the assembler when it is built and sets the default accordingly.
+.IP "\fB\-msmall\-data\fR" 4
+.IX Item "-msmall-data"
+.PD 0
+.IP "\fB\-mlarge\-data\fR" 4
+.IX Item "-mlarge-data"
+.PD
+When \fB\-mexplicit\-relocs\fR is in effect, static data is
+accessed via \fIgp-relative\fR relocations.  When \fB\-msmall\-data\fR
+is used, objects 8 bytes long or smaller are placed in a \fIsmall data area\fR
+(the \f(CW\*(C`.sdata\*(C'\fR and \f(CW\*(C`.sbss\*(C'\fR sections) and are accessed via
+16\-bit relocations off of the \f(CW$gp\fR register.  This limits the
+size of the small data area to 64KB, but allows the variables to be
+directly accessed via a single instruction.
+.Sp
+The default is \fB\-mlarge\-data\fR.  With this option the data area
+is limited to just below 2GB.  Programs that require more than 2GB of
+data must use \f(CW\*(C`malloc\*(C'\fR or \f(CW\*(C`mmap\*(C'\fR to allocate the data in the
+heap instead of in the program's data segment.
+.Sp
+When generating code for shared libraries, \fB\-fpic\fR implies
+\&\fB\-msmall\-data\fR and \fB\-fPIC\fR implies \fB\-mlarge\-data\fR.
+.IP "\fB\-msmall\-text\fR" 4
+.IX Item "-msmall-text"
+.PD 0
+.IP "\fB\-mlarge\-text\fR" 4
+.IX Item "-mlarge-text"
+.PD
+When \fB\-msmall\-text\fR is used, the compiler assumes that the
+code of the entire program (or shared library) fits in 4MB, and is
+thus reachable with a branch instruction.  When \fB\-msmall\-data\fR
+is used, the compiler can assume that all local symbols share the
+same \f(CW$gp\fR value, and thus reduce the number of instructions
+required for a function call from 4 to 1.
+.Sp
+The default is \fB\-mlarge\-text\fR.
+.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
+.IX Item "-mcpu=cpu_type"
+Set the instruction set and instruction scheduling parameters for
+machine type \fIcpu_type\fR.  You can specify either the \fB\s-1EV\s0\fR
+style name or the corresponding chip number.  \s-1GCC\s0 supports scheduling
+parameters for the \s-1EV4, EV5\s0 and \s-1EV6\s0 family of processors and
+chooses the default values for the instruction set from the processor
+you specify.  If you do not specify a processor type, \s-1GCC\s0 defaults
+to the processor on which the compiler was built.
+.Sp
+Supported values for \fIcpu_type\fR are
+.RS 4
+.IP "\fBev4\fR" 4
+.IX Item "ev4"
+.PD 0
+.IP "\fBev45\fR" 4
+.IX Item "ev45"
+.IP "\fB21064\fR" 4
+.IX Item "21064"
+.PD
+Schedules as an \s-1EV4\s0 and has no instruction set extensions.
+.IP "\fBev5\fR" 4
+.IX Item "ev5"
+.PD 0
+.IP "\fB21164\fR" 4
+.IX Item "21164"
+.PD
+Schedules as an \s-1EV5\s0 and has no instruction set extensions.
+.IP "\fBev56\fR" 4
+.IX Item "ev56"
+.PD 0
+.IP "\fB21164a\fR" 4
+.IX Item "21164a"
+.PD
+Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 extension.
+.IP "\fBpca56\fR" 4
+.IX Item "pca56"
+.PD 0
+.IP "\fB21164pc\fR" 4
+.IX Item "21164pc"
+.IP "\fB21164PC\fR" 4
+.IX Item "21164PC"
+.PD
+Schedules as an \s-1EV5\s0 and supports the \s-1BWX\s0 and \s-1MAX\s0 extensions.
+.IP "\fBev6\fR" 4
+.IX Item "ev6"
+.PD 0
+.IP "\fB21264\fR" 4
+.IX Item "21264"
+.PD
+Schedules as an \s-1EV6\s0 and supports the \s-1BWX, FIX,\s0 and \s-1MAX\s0 extensions.
+.IP "\fBev67\fR" 4
+.IX Item "ev67"
+.PD 0
+.IP "\fB21264a\fR" 4
+.IX Item "21264a"
+.PD
+Schedules as an \s-1EV6\s0 and supports the \s-1BWX, CIX, FIX,\s0 and \s-1MAX\s0 extensions.
+.RE
+.RS 4
+.Sp
+Native toolchains also support the value \fBnative\fR,
+which selects the best architecture option for the host processor.
+\&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
+the processor.
+.RE
+.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
+.IX Item "-mtune=cpu_type"
+Set only the instruction scheduling parameters for machine type
+\&\fIcpu_type\fR.  The instruction set is not changed.
+.Sp
+Native toolchains also support the value \fBnative\fR,
+which selects the best architecture option for the host processor.
+\&\fB\-mtune=native\fR has no effect if \s-1GCC\s0 does not recognize
+the processor.
+.IP "\fB\-mmemory\-latency=\fR\fItime\fR" 4
+.IX Item "-mmemory-latency=time"
+Sets the latency the scheduler should assume for typical memory
+references as seen by the application.  This number is highly
+dependent on the memory access patterns used by the application
+and the size of the external cache on the machine.
+.Sp
+Valid options for \fItime\fR are
+.RS 4
+.IP "\fInumber\fR" 4
+.IX Item "number"
+A decimal number representing clock cycles.
+.IP "\fBL1\fR" 4
+.IX Item "L1"
+.PD 0
+.IP "\fBL2\fR" 4
+.IX Item "L2"
+.IP "\fBL3\fR" 4
+.IX Item "L3"
+.IP "\fBmain\fR" 4
+.IX Item "main"
+.PD
+The compiler contains estimates of the number of clock cycles for
+\&\*(L"typical\*(R" \s-1EV4 & EV5\s0 hardware for the Level 1, 2 & 3 caches
+(also called Dcache, Scache, and Bcache), as well as to main memory.
+Note that L3 is only valid for \s-1EV5.\s0
+.RE
+.RS 4
+.RE
+.PP
+\fI\s-1FR30\s0 Options\fR
+.IX Subsection "FR30 Options"
+.PP
+These options are defined specifically for the \s-1FR30\s0 port.
+.IP "\fB\-msmall\-model\fR" 4
+.IX Item "-msmall-model"
+Use the small address space model.  This can produce smaller code, but
+it does assume that all symbolic values and addresses fit into a
+20\-bit range.
+.IP "\fB\-mno\-lsim\fR" 4
+.IX Item "-mno-lsim"
+Assume that runtime support has been provided and so there is no need
+to include the simulator library (\fIlibsim.a\fR) on the linker
+command line.
+.PP
+\fI\s-1FRV\s0 Options\fR
+.IX Subsection "FRV Options"
+.IP "\fB\-mgpr\-32\fR" 4
+.IX Item "-mgpr-32"
+Only use the first 32 general-purpose registers.
+.IP "\fB\-mgpr\-64\fR" 4
+.IX Item "-mgpr-64"
+Use all 64 general-purpose registers.
+.IP "\fB\-mfpr\-32\fR" 4
+.IX Item "-mfpr-32"
+Use only the first 32 floating-point registers.
+.IP "\fB\-mfpr\-64\fR" 4
+.IX Item "-mfpr-64"
+Use all 64 floating-point registers.
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+Use hardware instructions for floating-point operations.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Use library routines for floating-point operations.
+.IP "\fB\-malloc\-cc\fR" 4
+.IX Item "-malloc-cc"
+Dynamically allocate condition code registers.
+.IP "\fB\-mfixed\-cc\fR" 4
+.IX Item "-mfixed-cc"
+Do not try to dynamically allocate condition code registers, only
+use \f(CW\*(C`icc0\*(C'\fR and \f(CW\*(C`fcc0\*(C'\fR.
+.IP "\fB\-mdword\fR" 4
+.IX Item "-mdword"
+Change \s-1ABI\s0 to use double word insns.
+.IP "\fB\-mno\-dword\fR" 4
+.IX Item "-mno-dword"
+Do not use double word instructions.
+.IP "\fB\-mdouble\fR" 4
+.IX Item "-mdouble"
+Use floating-point double instructions.
+.IP "\fB\-mno\-double\fR" 4
+.IX Item "-mno-double"
+Do not use floating-point double instructions.
+.IP "\fB\-mmedia\fR" 4
+.IX Item "-mmedia"
+Use media instructions.
+.IP "\fB\-mno\-media\fR" 4
+.IX Item "-mno-media"
+Do not use media instructions.
+.IP "\fB\-mmuladd\fR" 4
+.IX Item "-mmuladd"
+Use multiply and add/subtract instructions.
+.IP "\fB\-mno\-muladd\fR" 4
+.IX Item "-mno-muladd"
+Do not use multiply and add/subtract instructions.
+.IP "\fB\-mfdpic\fR" 4
+.IX Item "-mfdpic"
+Select the \s-1FDPIC ABI,\s0 which uses function descriptors to represent
+pointers to functions.  Without any PIC/PIE\-related options, it
+implies \fB\-fPIE\fR.  With \fB\-fpic\fR or \fB\-fpie\fR, it
+assumes \s-1GOT\s0 entries and small data are within a 12\-bit range from the
+\&\s-1GOT\s0 base address; with \fB\-fPIC\fR or \fB\-fPIE\fR, \s-1GOT\s0 offsets
+are computed with 32 bits.
+With a \fBbfin-elf\fR target, this option implies \fB\-msim\fR.
+.IP "\fB\-minline\-plt\fR" 4
+.IX Item "-minline-plt"
+Enable inlining of \s-1PLT\s0 entries in function calls to functions that are
+not known to bind locally.  It has no effect without \fB\-mfdpic\fR.
+It's enabled by default if optimizing for speed and compiling for
+shared libraries (i.e., \fB\-fPIC\fR or \fB\-fpic\fR), or when an
+optimization option such as \fB\-O3\fR or above is present in the
+command line.
+.IP "\fB\-mTLS\fR" 4
+.IX Item "-mTLS"
+Assume a large \s-1TLS\s0 segment when generating thread-local code.
+.IP "\fB\-mtls\fR" 4
+.IX Item "-mtls"
+Do not assume a large \s-1TLS\s0 segment when generating thread-local code.
+.IP "\fB\-mgprel\-ro\fR" 4
+.IX Item "-mgprel-ro"
+Enable the use of \f(CW\*(C`GPREL\*(C'\fR relocations in the \s-1FDPIC ABI\s0 for data
+that is known to be in read-only sections.  It's enabled by default,
+except for \fB\-fpic\fR or \fB\-fpie\fR: even though it may help
+make the global offset table smaller, it trades 1 instruction for 4.
+With \fB\-fPIC\fR or \fB\-fPIE\fR, it trades 3 instructions for 4,
+one of which may be shared by multiple symbols, and it avoids the need
+for a \s-1GOT\s0 entry for the referenced symbol, so it's more likely to be a
+win.  If it is not, \fB\-mno\-gprel\-ro\fR can be used to disable it.
+.IP "\fB\-multilib\-library\-pic\fR" 4
+.IX Item "-multilib-library-pic"
+Link with the (library, not \s-1FD\s0) pic libraries.  It's implied by
+\&\fB\-mlibrary\-pic\fR, as well as by \fB\-fPIC\fR and
+\&\fB\-fpic\fR without \fB\-mfdpic\fR.  You should never have to use
+it explicitly.
+.IP "\fB\-mlinked\-fp\fR" 4
+.IX Item "-mlinked-fp"
+Follow the \s-1EABI\s0 requirement of always creating a frame pointer whenever
+a stack frame is allocated.  This option is enabled by default and can
+be disabled with \fB\-mno\-linked\-fp\fR.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+Use indirect addressing to call functions outside the current
+compilation unit.  This allows the functions to be placed anywhere
+within the 32\-bit address space.
+.IP "\fB\-malign\-labels\fR" 4
+.IX Item "-malign-labels"
+Try to align labels to an 8\-byte boundary by inserting NOPs into the
+previous packet.  This option only has an effect when \s-1VLIW\s0 packing
+is enabled.  It doesn't create new packets; it merely adds NOPs to
+existing ones.
+.IP "\fB\-mlibrary\-pic\fR" 4
+.IX Item "-mlibrary-pic"
+Generate position-independent \s-1EABI\s0 code.
+.IP "\fB\-macc\-4\fR" 4
+.IX Item "-macc-4"
+Use only the first four media accumulator registers.
+.IP "\fB\-macc\-8\fR" 4
+.IX Item "-macc-8"
+Use all eight media accumulator registers.
+.IP "\fB\-mpack\fR" 4
+.IX Item "-mpack"
+Pack \s-1VLIW\s0 instructions.
+.IP "\fB\-mno\-pack\fR" 4
+.IX Item "-mno-pack"
+Do not pack \s-1VLIW\s0 instructions.
+.IP "\fB\-mno\-eflags\fR" 4
+.IX Item "-mno-eflags"
+Do not mark \s-1ABI\s0 switches in e_flags.
+.IP "\fB\-mcond\-move\fR" 4
+.IX Item "-mcond-move"
+Enable the use of conditional-move instructions (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-cond\-move\fR" 4
+.IX Item "-mno-cond-move"
+Disable the use of conditional-move instructions.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mscc\fR" 4
+.IX Item "-mscc"
+Enable the use of conditional set instructions (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-scc\fR" 4
+.IX Item "-mno-scc"
+Disable the use of conditional set instructions.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mcond\-exec\fR" 4
+.IX Item "-mcond-exec"
+Enable the use of conditional execution (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-cond\-exec\fR" 4
+.IX Item "-mno-cond-exec"
+Disable the use of conditional execution.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mvliw\-branch\fR" 4
+.IX Item "-mvliw-branch"
+Run a pass to pack branches into \s-1VLIW\s0 instructions (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-vliw\-branch\fR" 4
+.IX Item "-mno-vliw-branch"
+Do not run a pass to pack branches into \s-1VLIW\s0 instructions.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mmulti\-cond\-exec\fR" 4
+.IX Item "-mmulti-cond-exec"
+Enable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution
+(default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-multi\-cond\-exec\fR" 4
+.IX Item "-mno-multi-cond-exec"
+Disable optimization of \f(CW\*(C`&&\*(C'\fR and \f(CW\*(C`||\*(C'\fR in conditional execution.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mnested\-cond\-exec\fR" 4
+.IX Item "-mnested-cond-exec"
+Enable nested conditional execution optimizations (default).
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-mno\-nested\-cond\-exec\fR" 4
+.IX Item "-mno-nested-cond-exec"
+Disable nested conditional execution optimizations.
+.Sp
+This switch is mainly for debugging the compiler and will likely be removed
+in a future version.
+.IP "\fB\-moptimize\-membar\fR" 4
+.IX Item "-moptimize-membar"
+This switch removes redundant \f(CW\*(C`membar\*(C'\fR instructions from the
+compiler-generated code.  It is enabled by default.
+.IP "\fB\-mno\-optimize\-membar\fR" 4
+.IX Item "-mno-optimize-membar"
+This switch disables the automatic removal of redundant \f(CW\*(C`membar\*(C'\fR
+instructions from the generated code.
+.IP "\fB\-mtomcat\-stats\fR" 4
+.IX Item "-mtomcat-stats"
+Cause gas to print out tomcat statistics.
+.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
+.IX Item "-mcpu=cpu"
+Select the processor type for which to generate code.  Possible values are
+\&\fBfrv\fR, \fBfr550\fR, \fBtomcat\fR, \fBfr500\fR, \fBfr450\fR,
+\&\fBfr405\fR, \fBfr400\fR, \fBfr300\fR and \fBsimple\fR.
+.PP
+\fIGNU/Linux Options\fR
+.IX Subsection "GNU/Linux Options"
+.PP
+These \fB\-m\fR options are defined for GNU/Linux targets:
+.IP "\fB\-mglibc\fR" 4
+.IX Item "-mglibc"
+Use the \s-1GNU C\s0 library.  This is the default except
+on \fB*\-*\-linux\-*uclibc*\fR and \fB*\-*\-linux\-*android*\fR targets.
+.IP "\fB\-muclibc\fR" 4
+.IX Item "-muclibc"
+Use uClibc C library.  This is the default on
+\&\fB*\-*\-linux\-*uclibc*\fR targets.
+.IP "\fB\-mbionic\fR" 4
+.IX Item "-mbionic"
+Use Bionic C library.  This is the default on
+\&\fB*\-*\-linux\-*android*\fR targets.
+.IP "\fB\-mandroid\fR" 4
+.IX Item "-mandroid"
+Compile code compatible with Android platform.  This is the default on
+\&\fB*\-*\-linux\-*android*\fR targets.
+.Sp
+When compiling, this option enables \fB\-mbionic\fR, \fB\-fPIC\fR,
+\&\fB\-fno\-exceptions\fR and \fB\-fno\-rtti\fR by default.  When linking,
+this option makes the \s-1GCC\s0 driver pass Android-specific options to the linker.
+Finally, this option causes the preprocessor macro \f(CW\*(C`_\|_ANDROID_\|_\*(C'\fR
+to be defined.
+.IP "\fB\-tno\-android\-cc\fR" 4
+.IX Item "-tno-android-cc"
+Disable compilation effects of \fB\-mandroid\fR, i.e., do not enable
+\&\fB\-mbionic\fR, \fB\-fPIC\fR, \fB\-fno\-exceptions\fR and
+\&\fB\-fno\-rtti\fR by default.
+.IP "\fB\-tno\-android\-ld\fR" 4
+.IX Item "-tno-android-ld"
+Disable linking effects of \fB\-mandroid\fR, i.e., pass standard Linux
+linking options to the linker.
+.PP
+\fIH8/300 Options\fR
+.IX Subsection "H8/300 Options"
+.PP
+These \fB\-m\fR options are defined for the H8/300 implementations:
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Shorten some address references at link time, when possible; uses the
+linker option \fB\-relax\fR.
+.IP "\fB\-mh\fR" 4
+.IX Item "-mh"
+Generate code for the H8/300H.
+.IP "\fB\-ms\fR" 4
+.IX Item "-ms"
+Generate code for the H8S.
+.IP "\fB\-mn\fR" 4
+.IX Item "-mn"
+Generate code for the H8S and H8/300H in the normal mode.  This switch
+must be used either with \fB\-mh\fR or \fB\-ms\fR.
+.IP "\fB\-ms2600\fR" 4
+.IX Item "-ms2600"
+Generate code for the H8S/2600.  This switch must be used with \fB\-ms\fR.
+.IP "\fB\-mexr\fR" 4
+.IX Item "-mexr"
+Extended registers are stored on stack before execution of function
+with monitor attribute. Default option is \fB\-mexr\fR.
+This option is valid only for H8S targets.
+.IP "\fB\-mno\-exr\fR" 4
+.IX Item "-mno-exr"
+Extended registers are not stored on stack before execution of function 
+with monitor attribute. Default option is \fB\-mno\-exr\fR. 
+This option is valid only for H8S targets.
+.IP "\fB\-mint32\fR" 4
+.IX Item "-mint32"
+Make \f(CW\*(C`int\*(C'\fR data 32 bits by default.
+.IP "\fB\-malign\-300\fR" 4
+.IX Item "-malign-300"
+On the H8/300H and H8S, use the same alignment rules as for the H8/300.
+The default for the H8/300H and H8S is to align longs and floats on
+4\-byte boundaries.
+\&\fB\-malign\-300\fR causes them to be aligned on 2\-byte boundaries.
+This option has no effect on the H8/300.
+.PP
+\fI\s-1HPPA\s0 Options\fR
+.IX Subsection "HPPA Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1HPPA\s0 family of computers:
+.IP "\fB\-march=\fR\fIarchitecture-type\fR" 4
+.IX Item "-march=architecture-type"
+Generate code for the specified architecture.  The choices for
+\&\fIarchitecture-type\fR are \fB1.0\fR for \s-1PA 1.0, \s0\fB1.1\fR for \s-1PA
+1.1,\s0 and \fB2.0\fR for \s-1PA 2.0\s0 processors.  Refer to
+\&\fI/usr/lib/sched.models\fR on an HP-UX system to determine the proper
+architecture option for your machine.  Code compiled for lower numbered
+architectures runs on higher numbered architectures, but not the
+other way around.
+.IP "\fB\-mpa\-risc\-1\-0\fR" 4
+.IX Item "-mpa-risc-1-0"
+.PD 0
+.IP "\fB\-mpa\-risc\-1\-1\fR" 4
+.IX Item "-mpa-risc-1-1"
+.IP "\fB\-mpa\-risc\-2\-0\fR" 4
+.IX Item "-mpa-risc-2-0"
+.PD
+Synonyms for \fB\-march=1.0\fR, \fB\-march=1.1\fR, and \fB\-march=2.0\fR respectively.
+.IP "\fB\-mjump\-in\-delay\fR" 4
+.IX Item "-mjump-in-delay"
+Fill delay slots of function calls with unconditional jump instructions
+by modifying the return pointer for the function call to be the target
+of the conditional jump.
+.IP "\fB\-mdisable\-fpregs\fR" 4
+.IX Item "-mdisable-fpregs"
+Prevent floating-point registers from being used in any manner.  This is
+necessary for compiling kernels that perform lazy context switching of
+floating-point registers.  If you use this option and attempt to perform
+floating-point operations, the compiler aborts.
+.IP "\fB\-mdisable\-indexing\fR" 4
+.IX Item "-mdisable-indexing"
+Prevent the compiler from using indexing address modes.  This avoids some
+rather obscure problems when compiling \s-1MIG\s0 generated code under \s-1MACH.\s0
+.IP "\fB\-mno\-space\-regs\fR" 4
+.IX Item "-mno-space-regs"
+Generate code that assumes the target has no space registers.  This allows
+\&\s-1GCC\s0 to generate faster indirect calls and use unscaled index address modes.
+.Sp
+Such code is suitable for level 0 \s-1PA\s0 systems and kernels.
+.IP "\fB\-mfast\-indirect\-calls\fR" 4
+.IX Item "-mfast-indirect-calls"
+Generate code that assumes calls never cross space boundaries.  This
+allows \s-1GCC\s0 to emit code that performs faster indirect calls.
+.Sp
+This option does not work in the presence of shared libraries or nested
+functions.
+.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
+.IX Item "-mfixed-range=register-range"
+Generate code treating the given register range as fixed registers.
+A fixed register is one that the register allocator cannot use.  This is
+useful when compiling kernel code.  A register range is specified as
+two registers separated by a dash.  Multiple register ranges can be
+specified separated by a comma.
+.IP "\fB\-mlong\-load\-store\fR" 4
+.IX Item "-mlong-load-store"
+Generate 3\-instruction load and store sequences as sometimes required by
+the HP-UX 10 linker.  This is equivalent to the \fB+k\fR option to
+the \s-1HP\s0 compilers.
+.IP "\fB\-mportable\-runtime\fR" 4
+.IX Item "-mportable-runtime"
+Use the portable calling conventions proposed by \s-1HP\s0 for \s-1ELF\s0 systems.
+.IP "\fB\-mgas\fR" 4
+.IX Item "-mgas"
+Enable the use of assembler directives only \s-1GAS\s0 understands.
+.IP "\fB\-mschedule=\fR\fIcpu-type\fR" 4
+.IX Item "-mschedule=cpu-type"
+Schedule code according to the constraints for the machine type
+\&\fIcpu-type\fR.  The choices for \fIcpu-type\fR are \fB700\fR
+\&\fB7100\fR, \fB7100LC\fR, \fB7200\fR, \fB7300\fR and \fB8000\fR.  Refer
+to \fI/usr/lib/sched.models\fR on an HP-UX system to determine the
+proper scheduling option for your machine.  The default scheduling is
+\&\fB8000\fR.
+.IP "\fB\-mlinker\-opt\fR" 4
+.IX Item "-mlinker-opt"
+Enable the optimization pass in the HP-UX linker.  Note this makes symbolic
+debugging impossible.  It also triggers a bug in the HP-UX 8 and HP-UX 9
+linkers in which they give bogus error messages when linking some programs.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Generate output containing library calls for floating point.
+\&\fBWarning:\fR the requisite libraries are not available for all \s-1HPPA\s0
+targets.  Normally the facilities of the machine's usual C compiler are
+used, but this cannot be done directly in cross-compilation.  You must make
+your own arrangements to provide suitable library functions for
+cross-compilation.
+.Sp
+\&\fB\-msoft\-float\fR changes the calling convention in the output file;
+therefore, it is only useful if you compile \fIall\fR of a program with
+this option.  In particular, you need to compile \fIlibgcc.a\fR, the
+library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
+this to work.
+.IP "\fB\-msio\fR" 4
+.IX Item "-msio"
+Generate the predefine, \f(CW\*(C`_SIO\*(C'\fR, for server \s-1IO. \s0 The default is
+\&\fB\-mwsio\fR.  This generates the predefines, \f(CW\*(C`_\|_hp9000s700\*(C'\fR,
+\&\f(CW\*(C`_\|_hp9000s700_\|_\*(C'\fR and \f(CW\*(C`_WSIO\*(C'\fR, for workstation \s-1IO. \s0 These
+options are available under HP-UX and HI-UX.
+.IP "\fB\-mgnu\-ld\fR" 4
+.IX Item "-mgnu-ld"
+Use options specific to \s-1GNU \s0\fBld\fR.
+This passes \fB\-shared\fR to \fBld\fR when
+building a shared library.  It is the default when \s-1GCC\s0 is configured,
+explicitly or implicitly, with the \s-1GNU\s0 linker.  This option does not
+affect which \fBld\fR is called; it only changes what parameters
+are passed to that \fBld\fR.
+The \fBld\fR that is called is determined by the
+\&\fB\-\-with\-ld\fR configure option, \s-1GCC\s0's program search path, and
+finally by the user's \fB\s-1PATH\s0\fR.  The linker used by \s-1GCC\s0 can be printed
+using \fBwhich `gcc \-print\-prog\-name=ld`\fR.  This option is only available
+on the 64\-bit HP-UX \s-1GCC,\s0 i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
+.IP "\fB\-mhp\-ld\fR" 4
+.IX Item "-mhp-ld"
+Use options specific to \s-1HP \s0\fBld\fR.
+This passes \fB\-b\fR to \fBld\fR when building
+a shared library and passes \fB+Accept TypeMismatch\fR to \fBld\fR on all
+links.  It is the default when \s-1GCC\s0 is configured, explicitly or
+implicitly, with the \s-1HP\s0 linker.  This option does not affect
+which \fBld\fR is called; it only changes what parameters are passed to that
+\&\fBld\fR.
+The \fBld\fR that is called is determined by the \fB\-\-with\-ld\fR
+configure option, \s-1GCC\s0's program search path, and finally by the user's
+\&\fB\s-1PATH\s0\fR.  The linker used by \s-1GCC\s0 can be printed using \fBwhich
+`gcc \-print\-prog\-name=ld`\fR.  This option is only available on the 64\-bit
+HP-UX \s-1GCC,\s0 i.e. configured with \fBhppa*64*\-*\-hpux*\fR.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+Generate code that uses long call sequences.  This ensures that a call
+is always able to reach linker generated stubs.  The default is to generate
+long calls only when the distance from the call site to the beginning
+of the function or translation unit, as the case may be, exceeds a
+predefined limit set by the branch type being used.  The limits for
+normal calls are 7,600,000 and 240,000 bytes, respectively for the
+\&\s-1PA 2.0\s0 and \s-1PA 1.X\s0 architectures.  Sibcalls are always limited at
+240,000 bytes.
+.Sp
+Distances are measured from the beginning of functions when using the
+\&\fB\-ffunction\-sections\fR option, or when using the \fB\-mgas\fR
+and \fB\-mno\-portable\-runtime\fR options together under HP-UX with
+the \s-1SOM\s0 linker.
+.Sp
+It is normally not desirable to use this option as it degrades
+performance.  However, it may be useful in large applications,
+particularly when partial linking is used to build the application.
+.Sp
+The types of long calls used depends on the capabilities of the
+assembler and linker, and the type of code being generated.  The
+impact on systems that support long absolute calls, and long pic
+symbol-difference or pc-relative calls should be relatively small.
+However, an indirect call is used on 32\-bit \s-1ELF\s0 systems in pic code
+and it is quite long.
+.IP "\fB\-munix=\fR\fIunix-std\fR" 4
+.IX Item "-munix=unix-std"
+Generate compiler predefines and select a startfile for the specified
+\&\s-1UNIX\s0 standard.  The choices for \fIunix-std\fR are \fB93\fR, \fB95\fR
+and \fB98\fR.  \fB93\fR is supported on all HP-UX versions.  \fB95\fR
+is available on HP-UX 10.10 and later.  \fB98\fR is available on HP-UX
+11.11 and later.  The default values are \fB93\fR for HP-UX 10.00,
+\&\fB95\fR for HP-UX 10.10 though to 11.00, and \fB98\fR for HP-UX 11.11
+and later.
+.Sp
+\&\fB\-munix=93\fR provides the same predefines as \s-1GCC 3.3\s0 and 3.4.
+\&\fB\-munix=95\fR provides additional predefines for \f(CW\*(C`XOPEN_UNIX\*(C'\fR
+and \f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, and the startfile \fIunix95.o\fR.
+\&\fB\-munix=98\fR provides additional predefines for \f(CW\*(C`_XOPEN_UNIX\*(C'\fR,
+\&\f(CW\*(C`_XOPEN_SOURCE_EXTENDED\*(C'\fR, \f(CW\*(C`_INCLUDE_\|_STDC_A1_SOURCE\*(C'\fR and
+\&\f(CW\*(C`_INCLUDE_XOPEN_SOURCE_500\*(C'\fR, and the startfile \fIunix98.o\fR.
+.Sp
+It is \fIimportant\fR to note that this option changes the interfaces
+for various library routines.  It also affects the operational behavior
+of the C library.  Thus, \fIextreme\fR care is needed in using this
+option.
+.Sp
+Library code that is intended to operate with more than one \s-1UNIX\s0
+standard must test, set and restore the variable \fI_\|_xpg4_extended_mask\fR
+as appropriate.  Most \s-1GNU\s0 software doesn't provide this capability.
+.IP "\fB\-nolibdld\fR" 4
+.IX Item "-nolibdld"
+Suppress the generation of link options to search libdld.sl when the
+\&\fB\-static\fR option is specified on HP-UX 10 and later.
+.IP "\fB\-static\fR" 4
+.IX Item "-static"
+The HP-UX implementation of setlocale in libc has a dependency on
+libdld.sl.  There isn't an archive version of libdld.sl.  Thus,
+when the \fB\-static\fR option is specified, special link options
+are needed to resolve this dependency.
+.Sp
+On HP-UX 10 and later, the \s-1GCC\s0 driver adds the necessary options to
+link with libdld.sl when the \fB\-static\fR option is specified.
+This causes the resulting binary to be dynamic.  On the 64\-bit port,
+the linkers generate dynamic binaries by default in any case.  The
+\&\fB\-nolibdld\fR option can be used to prevent the \s-1GCC\s0 driver from
+adding these link options.
+.IP "\fB\-threads\fR" 4
+.IX Item "-threads"
+Add support for multithreading with the \fIdce thread\fR library
+under HP-UX.  This option sets flags for both the preprocessor and
+linker.
+.PP
+\fIIntel 386 and \s-1AMD\s0 x86\-64 Options\fR
+.IX Subsection "Intel 386 and AMD x86-64 Options"
+.PP
+These \fB\-m\fR options are defined for the i386 and x86\-64 family of
+computers:
+.IP "\fB\-march=\fR\fIcpu-type\fR" 4
+.IX Item "-march=cpu-type"
+Generate instructions for the machine type \fIcpu-type\fR.  In contrast to
+\&\fB\-mtune=\fR\fIcpu-type\fR, which merely tunes the generated code 
+for the specified \fIcpu-type\fR, \fB\-march=\fR\fIcpu-type\fR allows \s-1GCC\s0
+to generate code that may not run at all on processors other than the one
+indicated.  Specifying \fB\-march=\fR\fIcpu-type\fR implies 
+\&\fB\-mtune=\fR\fIcpu-type\fR.
+.Sp
+The choices for \fIcpu-type\fR are:
+.RS 4
+.IP "\fBnative\fR" 4
+.IX Item "native"
+This selects the \s-1CPU\s0 to generate code for at compilation time by determining
+the processor type of the compiling machine.  Using \fB\-march=native\fR
+enables all instruction subsets supported by the local machine (hence
+the result might not run on different machines).  Using \fB\-mtune=native\fR
+produces code optimized for the local machine under the constraints
+of the selected instruction set.
+.IP "\fBi386\fR" 4
+.IX Item "i386"
+Original Intel i386 \s-1CPU.\s0
+.IP "\fBi486\fR" 4
+.IX Item "i486"
+Intel i486 \s-1CPU.  \s0(No scheduling is implemented for this chip.)
+.IP "\fBi586\fR" 4
+.IX Item "i586"
+.PD 0
+.IP "\fBpentium\fR" 4
+.IX Item "pentium"
+.PD
+Intel Pentium \s-1CPU\s0 with no \s-1MMX\s0 support.
+.IP "\fBpentium-mmx\fR" 4
+.IX Item "pentium-mmx"
+Intel Pentium \s-1MMX CPU,\s0 based on Pentium core with \s-1MMX\s0 instruction set support.
+.IP "\fBpentiumpro\fR" 4
+.IX Item "pentiumpro"
+Intel Pentium Pro \s-1CPU.\s0
+.IP "\fBi686\fR" 4
+.IX Item "i686"
+When used with \fB\-march\fR, the Pentium Pro
+instruction set is used, so the code runs on all i686 family chips.
+When used with \fB\-mtune\fR, it has the same meaning as \fBgeneric\fR.
+.IP "\fBpentium2\fR" 4
+.IX Item "pentium2"
+Intel Pentium \s-1II CPU,\s0 based on Pentium Pro core with \s-1MMX\s0 instruction set
+support.
+.IP "\fBpentium3\fR" 4
+.IX Item "pentium3"
+.PD 0
+.IP "\fBpentium3m\fR" 4
+.IX Item "pentium3m"
+.PD
+Intel Pentium \s-1III CPU,\s0 based on Pentium Pro core with \s-1MMX\s0 and \s-1SSE\s0 instruction
+set support.
+.IP "\fBpentium-m\fR" 4
+.IX Item "pentium-m"
+Intel Pentium M; low-power version of Intel Pentium \s-1III CPU\s0
+with \s-1MMX, SSE\s0 and \s-1SSE2\s0 instruction set support.  Used by Centrino notebooks.
+.IP "\fBpentium4\fR" 4
+.IX Item "pentium4"
+.PD 0
+.IP "\fBpentium4m\fR" 4
+.IX Item "pentium4m"
+.PD
+Intel Pentium 4 \s-1CPU\s0 with \s-1MMX, SSE\s0 and \s-1SSE2\s0 instruction set support.
+.IP "\fBprescott\fR" 4
+.IX Item "prescott"
+Improved version of Intel Pentium 4 \s-1CPU\s0 with \s-1MMX, SSE, SSE2\s0 and \s-1SSE3\s0 instruction
+set support.
+.IP "\fBnocona\fR" 4
+.IX Item "nocona"
+Improved version of Intel Pentium 4 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE,
+SSE2\s0 and \s-1SSE3\s0 instruction set support.
+.IP "\fBcore2\fR" 4
+.IX Item "core2"
+Intel Core 2 \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
+instruction set support.
+.IP "\fBnehalem\fR" 4
+.IX Item "nehalem"
+Intel Nehalem \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2\s0 and \s-1POPCNT\s0 instruction set support.
+.IP "\fBwestmere\fR" 4
+.IX Item "westmere"
+Intel Westmere \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AES\s0 and \s-1PCLMUL\s0 instruction set support.
+.IP "\fBsandybridge\fR" 4
+.IX Item "sandybridge"
+Intel Sandy Bridge \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AVX, AES\s0 and \s-1PCLMUL\s0 instruction set support.
+.IP "\fBivybridge\fR" 4
+.IX Item "ivybridge"
+Intel Ivy Bridge \s-1CPU\s0 with 64\-bit extensions, \s-1MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AVX, AES, PCLMUL, FSGSBASE, RDRND\s0 and F16C
+instruction set support.
+.IP "\fBhaswell\fR" 4
+.IX Item "haswell"
+Intel Haswell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA,
+BMI, BMI2\s0 and F16C instruction set support.
+.IP "\fBbroadwell\fR" 4
+.IX Item "broadwell"
+Intel Broadwell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES, PCLMUL, FSGSBASE, RDRND, FMA,
+BMI, BMI2, F16C, RDSEED, ADCX\s0 and \s-1PREFETCHW\s0 instruction set support.
+.IP "\fBbonnell\fR" 4
+.IX Item "bonnell"
+Intel Bonnell \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3\s0 and \s-1SSSE3\s0
+instruction set support.
+.IP "\fBsilvermont\fR" 4
+.IX Item "silvermont"
+Intel Silvermont \s-1CPU\s0 with 64\-bit extensions, \s-1MOVBE, MMX, SSE, SSE2, SSE3, SSSE3,
+SSE4.1, SSE4.2, POPCNT, AES, PCLMUL\s0 and \s-1RDRND\s0 instruction set support.
+.IP "\fBk6\fR" 4
+.IX Item "k6"
+\&\s-1AMD K6 CPU\s0 with \s-1MMX\s0 instruction set support.
+.IP "\fBk6\-2\fR" 4
+.IX Item "k6-2"
+.PD 0
+.IP "\fBk6\-3\fR" 4
+.IX Item "k6-3"
+.PD
+Improved versions of \s-1AMD K6 CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.
+.IP "\fBathlon\fR" 4
+.IX Item "athlon"
+.PD 0
+.IP "\fBathlon-tbird\fR" 4
+.IX Item "athlon-tbird"
+.PD
+\&\s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX,\s0 3dNOW!, enhanced 3DNow! and \s-1SSE\s0 prefetch instructions
+support.
+.IP "\fBathlon\-4\fR" 4
+.IX Item "athlon-4"
+.PD 0
+.IP "\fBathlon-xp\fR" 4
+.IX Item "athlon-xp"
+.IP "\fBathlon-mp\fR" 4
+.IX Item "athlon-mp"
+.PD
+Improved \s-1AMD\s0 Athlon \s-1CPU\s0 with \s-1MMX,\s0 3DNow!, enhanced 3DNow! and full \s-1SSE\s0
+instruction set support.
+.IP "\fBk8\fR" 4
+.IX Item "k8"
+.PD 0
+.IP "\fBopteron\fR" 4
+.IX Item "opteron"
+.IP "\fBathlon64\fR" 4
+.IX Item "athlon64"
+.IP "\fBathlon-fx\fR" 4
+.IX Item "athlon-fx"
+.PD
+Processors based on the \s-1AMD K8\s0 core with x86\-64 instruction set support,
+including the \s-1AMD\s0 Opteron, Athlon 64, and Athlon 64 \s-1FX\s0 processors.
+(This supersets \s-1MMX, SSE, SSE2,\s0 3DNow!, enhanced 3DNow! and 64\-bit
+instruction set extensions.)
+.IP "\fBk8\-sse3\fR" 4
+.IX Item "k8-sse3"
+.PD 0
+.IP "\fBopteron\-sse3\fR" 4
+.IX Item "opteron-sse3"
+.IP "\fBathlon64\-sse3\fR" 4
+.IX Item "athlon64-sse3"
+.PD
+Improved versions of \s-1AMD K8\s0 cores with \s-1SSE3\s0 instruction set support.
+.IP "\fBamdfam10\fR" 4
+.IX Item "amdfam10"
+.PD 0
+.IP "\fBbarcelona\fR" 4
+.IX Item "barcelona"
+.PD
+CPUs based on \s-1AMD\s0 Family 10h cores with x86\-64 instruction set support.  (This
+supersets \s-1MMX, SSE, SSE2, SSE3, SSE4A,\s0 3DNow!, enhanced 3DNow!, \s-1ABM\s0 and 64\-bit
+instruction set extensions.)
+.IP "\fBbdver1\fR" 4
+.IX Item "bdver1"
+CPUs based on \s-1AMD\s0 Family 15h cores with x86\-64 instruction set support.  (This
+supersets \s-1FMA4, AVX, XOP, LWP, AES, PCL_MUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A,
+SSSE3, SSE4.1, SSE4.2, ABM\s0 and 64\-bit instruction set extensions.)
+.IP "\fBbdver2\fR" 4
+.IX Item "bdver2"
+\&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
+supersets \s-1BMI, TBM, F16C, FMA, FMA4, AVX, XOP, LWP, AES, PCL_MUL, CX16, MMX,
+SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM\s0 and 64\-bit instruction set 
+extensions.)
+.IP "\fBbdver3\fR" 4
+.IX Item "bdver3"
+\&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
+supersets \s-1BMI, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, XOP, LWP, AES, 
+PCL_MUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM\s0 and 
+64\-bit instruction set extensions.
+.IP "\fBbdver4\fR" 4
+.IX Item "bdver4"
+\&\s-1AMD\s0 Family 15h core based CPUs with x86\-64 instruction set support.  (This
+supersets \s-1BMI, BMI2, TBM, F16C, FMA, FMA4, FSGSBASE, AVX, AVX2, XOP, LWP, 
+AES, PCL_MUL, CX16, MOVBE, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, 
+SSE4.2, ABM\s0 and 64\-bit instruction set extensions.
+.IP "\fBbtver1\fR" 4
+.IX Item "btver1"
+CPUs based on \s-1AMD\s0 Family 14h cores with x86\-64 instruction set support.  (This
+supersets \s-1MMX, SSE, SSE2, SSE3, SSSE3, SSE4A, CX16, ABM\s0 and 64\-bit
+instruction set extensions.)
+.IP "\fBbtver2\fR" 4
+.IX Item "btver2"
+CPUs based on \s-1AMD\s0 Family 16h cores with x86\-64 instruction set support. This
+includes \s-1MOVBE, F16C, BMI, AVX, PCL_MUL, AES, SSE4.2, SSE4.1, CX16, ABM,
+SSE4A, SSSE3, SSE3, SSE2, SSE, MMX\s0 and 64\-bit instruction set extensions.
+.IP "\fBwinchip\-c6\fR" 4
+.IX Item "winchip-c6"
+\&\s-1IDT\s0 WinChip C6 \s-1CPU,\s0 dealt in same way as i486 with additional \s-1MMX\s0 instruction
+set support.
+.IP "\fBwinchip2\fR" 4
+.IX Item "winchip2"
+\&\s-1IDT\s0 WinChip 2 \s-1CPU,\s0 dealt in same way as i486 with additional \s-1MMX\s0 and 3DNow!
+instruction set support.
+.IP "\fBc3\fR" 4
+.IX Item "c3"
+\&\s-1VIA C3 CPU\s0 with \s-1MMX\s0 and 3DNow! instruction set support.  (No scheduling is
+implemented for this chip.)
+.IP "\fBc3\-2\fR" 4
+.IX Item "c3-2"
+\&\s-1VIA C3\-2 \s0(Nehemiah/C5XL) \s-1CPU\s0 with \s-1MMX\s0 and \s-1SSE\s0 instruction set support.
+(No scheduling is
+implemented for this chip.)
+.IP "\fBgeode\fR" 4
+.IX Item "geode"
+\&\s-1AMD\s0 Geode embedded processor with \s-1MMX\s0 and 3DNow! instruction set support.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
+.IX Item "-mtune=cpu-type"
+Tune to \fIcpu-type\fR everything applicable about the generated code, except
+for the \s-1ABI\s0 and the set of available instructions.  
+While picking a specific \fIcpu-type\fR schedules things appropriately
+for that particular chip, the compiler does not generate any code that
+cannot run on the default machine type unless you use a
+\&\fB\-march=\fR\fIcpu-type\fR option.
+For example, if \s-1GCC\s0 is configured for i686\-pc\-linux\-gnu
+then \fB\-mtune=pentium4\fR generates code that is tuned for Pentium 4
+but still runs on i686 machines.
+.Sp
+The choices for \fIcpu-type\fR are the same as for \fB\-march\fR.
+In addition, \fB\-mtune\fR supports 2 extra choices for \fIcpu-type\fR:
+.RS 4
+.IP "\fBgeneric\fR" 4
+.IX Item "generic"
+Produce code optimized for the most common \s-1IA32/AMD64/EM64T\s0 processors.
+If you know the \s-1CPU\s0 on which your code will run, then you should use
+the corresponding \fB\-mtune\fR or \fB\-march\fR option instead of
+\&\fB\-mtune=generic\fR.  But, if you do not know exactly what \s-1CPU\s0 users
+of your application will have, then you should use this option.
+.Sp
+As new processors are deployed in the marketplace, the behavior of this
+option will change.  Therefore, if you upgrade to a newer version of
+\&\s-1GCC,\s0 code generation controlled by this option will change to reflect
+the processors
+that are most common at the time that version of \s-1GCC\s0 is released.
+.Sp
+There is no \fB\-march=generic\fR option because \fB\-march\fR
+indicates the instruction set the compiler can use, and there is no
+generic instruction set applicable to all processors.  In contrast,
+\&\fB\-mtune\fR indicates the processor (or, in this case, collection of
+processors) for which the code is optimized.
+.IP "\fBintel\fR" 4
+.IX Item "intel"
+Produce code optimized for the most current Intel processors, which are
+Haswell and Silvermont for this version of \s-1GCC. \s0 If you know the \s-1CPU\s0
+on which your code will run, then you should use the corresponding
+\&\fB\-mtune\fR or \fB\-march\fR option instead of \fB\-mtune=intel\fR.
+But, if you want your application performs better on both Haswell and
+Silvermont, then you should use this option.
+.Sp
+As new Intel processors are deployed in the marketplace, the behavior of
+this option will change.  Therefore, if you upgrade to a newer version of
+\&\s-1GCC,\s0 code generation controlled by this option will change to reflect
+the most current Intel processors at the time that version of \s-1GCC\s0 is
+released.
+.Sp
+There is no \fB\-march=intel\fR option because \fB\-march\fR indicates
+the instruction set the compiler can use, and there is no common
+instruction set applicable to all processors.  In contrast,
+\&\fB\-mtune\fR indicates the processor (or, in this case, collection of
+processors) for which the code is optimized.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
+.IX Item "-mcpu=cpu-type"
+A deprecated synonym for \fB\-mtune\fR.
+.IP "\fB\-mfpmath=\fR\fIunit\fR" 4
+.IX Item "-mfpmath=unit"
+Generate floating-point arithmetic for selected unit \fIunit\fR.  The choices
+for \fIunit\fR are:
+.RS 4
+.IP "\fB387\fR" 4
+.IX Item "387"
+Use the standard 387 floating-point coprocessor present on the majority of chips and
+emulated otherwise.  Code compiled with this option runs almost everywhere.
+The temporary results are computed in 80\-bit precision instead of the precision
+specified by the type, resulting in slightly different results compared to most
+of other chips.  See \fB\-ffloat\-store\fR for more detailed description.
+.Sp
+This is the default choice for i386 compiler.
+.IP "\fBsse\fR" 4
+.IX Item "sse"
+Use scalar floating-point instructions present in the \s-1SSE\s0 instruction set.
+This instruction set is supported by Pentium \s-1III\s0 and newer chips,
+and in the \s-1AMD\s0 line
+by Athlon\-4, Athlon \s-1XP\s0 and Athlon \s-1MP\s0 chips.  The earlier version of the \s-1SSE\s0
+instruction set supports only single-precision arithmetic, thus the double and
+extended-precision arithmetic are still done using 387.  A later version, present
+only in Pentium 4 and \s-1AMD\s0 x86\-64 chips, supports double-precision
+arithmetic too.
+.Sp
+For the i386 compiler, you must use \fB\-march=\fR\fIcpu-type\fR, \fB\-msse\fR
+or \fB\-msse2\fR switches to enable \s-1SSE\s0 extensions and make this option
+effective.  For the x86\-64 compiler, these extensions are enabled by default.
+.Sp
+The resulting code should be considerably faster in the majority of cases and avoid
+the numerical instability problems of 387 code, but may break some existing
+code that expects temporaries to be 80 bits.
+.Sp
+This is the default choice for the x86\-64 compiler.
+.IP "\fBsse,387\fR" 4
+.IX Item "sse,387"
+.PD 0
+.IP "\fBsse+387\fR" 4
+.IX Item "sse+387"
+.IP "\fBboth\fR" 4
+.IX Item "both"
+.PD
+Attempt to utilize both instruction sets at once.  This effectively doubles the
+amount of available registers, and on chips with separate execution units for
+387 and \s-1SSE\s0 the execution resources too.  Use this option with care, as it is
+still experimental, because the \s-1GCC\s0 register allocator does not model separate
+functional units well, resulting in unstable performance.
+.RE
+.RS 4
+.RE
+.IP "\fB\-masm=\fR\fIdialect\fR" 4
+.IX Item "-masm=dialect"
+Output assembly instructions using selected \fIdialect\fR.  Supported
+choices are \fBintel\fR or \fBatt\fR (the default).  Darwin does
+not support \fBintel\fR.
+.IP "\fB\-mieee\-fp\fR" 4
+.IX Item "-mieee-fp"
+.PD 0
+.IP "\fB\-mno\-ieee\-fp\fR" 4
+.IX Item "-mno-ieee-fp"
+.PD
+Control whether or not the compiler uses \s-1IEEE\s0 floating-point
+comparisons.  These correctly handle the case where the result of a
+comparison is unordered.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Generate output containing library calls for floating point.
+.Sp
+\&\fBWarning:\fR the requisite libraries are not part of \s-1GCC.\s0
+Normally the facilities of the machine's usual C compiler are used, but
+this can't be done directly in cross-compilation.  You must make your
+own arrangements to provide suitable library functions for
+cross-compilation.
+.Sp
+On machines where a function returns floating-point results in the 80387
+register stack, some floating-point opcodes may be emitted even if
+\&\fB\-msoft\-float\fR is used.
+.IP "\fB\-mno\-fp\-ret\-in\-387\fR" 4
+.IX Item "-mno-fp-ret-in-387"
+Do not use the \s-1FPU\s0 registers for return values of functions.
+.Sp
+The usual calling convention has functions return values of types
+\&\f(CW\*(C`float\*(C'\fR and \f(CW\*(C`double\*(C'\fR in an \s-1FPU\s0 register, even if there
+is no \s-1FPU. \s0 The idea is that the operating system should emulate
+an \s-1FPU.\s0
+.Sp
+The option \fB\-mno\-fp\-ret\-in\-387\fR causes such values to be returned
+in ordinary \s-1CPU\s0 registers instead.
+.IP "\fB\-mno\-fancy\-math\-387\fR" 4
+.IX Item "-mno-fancy-math-387"
+Some 387 emulators do not support the \f(CW\*(C`sin\*(C'\fR, \f(CW\*(C`cos\*(C'\fR and
+\&\f(CW\*(C`sqrt\*(C'\fR instructions for the 387.  Specify this option to avoid
+generating those instructions.  This option is the default on FreeBSD,
+OpenBSD and NetBSD.  This option is overridden when \fB\-march\fR
+indicates that the target \s-1CPU\s0 always has an \s-1FPU\s0 and so the
+instruction does not need emulation.  These
+instructions are not generated unless you also use the
+\&\fB\-funsafe\-math\-optimizations\fR switch.
+.IP "\fB\-malign\-double\fR" 4
+.IX Item "-malign-double"
+.PD 0
+.IP "\fB\-mno\-align\-double\fR" 4
+.IX Item "-mno-align-double"
+.PD
+Control whether \s-1GCC\s0 aligns \f(CW\*(C`double\*(C'\fR, \f(CW\*(C`long double\*(C'\fR, and
+\&\f(CW\*(C`long long\*(C'\fR variables on a two-word boundary or a one-word
+boundary.  Aligning \f(CW\*(C`double\*(C'\fR variables on a two-word boundary
+produces code that runs somewhat faster on a Pentium at the
+expense of more memory.
+.Sp
+On x86\-64, \fB\-malign\-double\fR is enabled by default.
+.Sp
+\&\fBWarning:\fR if you use the \fB\-malign\-double\fR switch,
+structures containing the above types are aligned differently than
+the published application binary interface specifications for the 386
+and are not binary compatible with structures in code compiled
+without that switch.
+.IP "\fB\-m96bit\-long\-double\fR" 4
+.IX Item "-m96bit-long-double"
+.PD 0
+.IP "\fB\-m128bit\-long\-double\fR" 4
+.IX Item "-m128bit-long-double"
+.PD
+These switches control the size of \f(CW\*(C`long double\*(C'\fR type.  The i386
+application binary interface specifies the size to be 96 bits,
+so \fB\-m96bit\-long\-double\fR is the default in 32\-bit mode.
+.Sp
+Modern architectures (Pentium and newer) prefer \f(CW\*(C`long double\*(C'\fR
+to be aligned to an 8\- or 16\-byte boundary.  In arrays or structures
+conforming to the \s-1ABI,\s0 this is not possible.  So specifying
+\&\fB\-m128bit\-long\-double\fR aligns \f(CW\*(C`long double\*(C'\fR
+to a 16\-byte boundary by padding the \f(CW\*(C`long double\*(C'\fR with an additional
+32\-bit zero.
+.Sp
+In the x86\-64 compiler, \fB\-m128bit\-long\-double\fR is the default choice as
+its \s-1ABI\s0 specifies that \f(CW\*(C`long double\*(C'\fR is aligned on 16\-byte boundary.
+.Sp
+Notice that neither of these options enable any extra precision over the x87
+standard of 80 bits for a \f(CW\*(C`long double\*(C'\fR.
+.Sp
+\&\fBWarning:\fR if you override the default value for your target \s-1ABI,\s0 this
+changes the size of 
+structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
+as well as modifying the function calling convention for functions taking
+\&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary-compatible
+with code compiled without that switch.
+.IP "\fB\-mlong\-double\-64\fR" 4
+.IX Item "-mlong-double-64"
+.PD 0
+.IP "\fB\-mlong\-double\-80\fR" 4
+.IX Item "-mlong-double-80"
+.IP "\fB\-mlong\-double\-128\fR" 4
+.IX Item "-mlong-double-128"
+.PD
+These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
+of 64 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
+type. This is the default for 32\-bit Bionic C library.  A size
+of 128 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the
+\&\f(CW\*(C`_\|_float128\*(C'\fR type. This is the default for 64\-bit Bionic C library.
+.Sp
+\&\fBWarning:\fR if you override the default value for your target \s-1ABI,\s0 this
+changes the size of
+structures and arrays containing \f(CW\*(C`long double\*(C'\fR variables,
+as well as modifying the function calling convention for functions taking
+\&\f(CW\*(C`long double\*(C'\fR.  Hence they are not binary-compatible
+with code compiled without that switch.
+.IP "\fB\-mlarge\-data\-threshold=\fR\fIthreshold\fR" 4
+.IX Item "-mlarge-data-threshold=threshold"
+When \fB\-mcmodel=medium\fR is specified, data objects larger than
+\&\fIthreshold\fR are placed in the large data section.  This value must be the
+same across all objects linked into the binary, and defaults to 65535.
+.IP "\fB\-mrtd\fR" 4
+.IX Item "-mrtd"
+Use a different function-calling convention, in which functions that
+take a fixed number of arguments return with the \f(CW\*(C`ret \f(CInum\f(CW\*(C'\fR
+instruction, which pops their arguments while returning.  This saves one
+instruction in the caller since there is no need to pop the arguments
+there.
+.Sp
+You can specify that an individual function is called with this calling
+sequence with the function attribute \fBstdcall\fR.  You can also
+override the \fB\-mrtd\fR option by using the function attribute
+\&\fBcdecl\fR.
+.Sp
+\&\fBWarning:\fR this calling convention is incompatible with the one
+normally used on Unix, so you cannot use it if you need to call
+libraries compiled with the Unix compiler.
+.Sp
+Also, you must provide function prototypes for all functions that
+take variable numbers of arguments (including \f(CW\*(C`printf\*(C'\fR);
+otherwise incorrect code is generated for calls to those
+functions.
+.Sp
+In addition, seriously incorrect code results if you call a
+function with too many arguments.  (Normally, extra arguments are
+harmlessly ignored.)
+.IP "\fB\-mregparm=\fR\fInum\fR" 4
+.IX Item "-mregparm=num"
+Control how many registers are used to pass integer arguments.  By
+default, no registers are used to pass arguments, and at most 3
+registers can be used.  You can control this behavior for a specific
+function by using the function attribute \fBregparm\fR.
+.Sp
+\&\fBWarning:\fR if you use this switch, and
+\&\fInum\fR is nonzero, then you must build all modules with the same
+value, including any libraries.  This includes the system libraries and
+startup modules.
+.IP "\fB\-msseregparm\fR" 4
+.IX Item "-msseregparm"
+Use \s-1SSE\s0 register passing conventions for float and double arguments
+and return values.  You can control this behavior for a specific
+function by using the function attribute \fBsseregparm\fR.
+.Sp
+\&\fBWarning:\fR if you use this switch then you must build all
+modules with the same value, including any libraries.  This includes
+the system libraries and startup modules.
+.IP "\fB\-mvect8\-ret\-in\-mem\fR" 4
+.IX Item "-mvect8-ret-in-mem"
+Return 8\-byte vectors in memory instead of \s-1MMX\s0 registers.  This is the
+default on Solaris@tie{}8 and 9 and VxWorks to match the \s-1ABI\s0 of the Sun
+Studio compilers until version 12.  Later compiler versions (starting
+with Studio 12 Update@tie{}1) follow the \s-1ABI\s0 used by other x86 targets, which
+is the default on Solaris@tie{}10 and later.  \fIOnly\fR use this option if
+you need to remain compatible with existing code produced by those
+previous compiler versions or older versions of \s-1GCC.\s0
+.IP "\fB\-mpc32\fR" 4
+.IX Item "-mpc32"
+.PD 0
+.IP "\fB\-mpc64\fR" 4
+.IX Item "-mpc64"
+.IP "\fB\-mpc80\fR" 4
+.IX Item "-mpc80"
+.PD
+Set 80387 floating-point precision to 32, 64 or 80 bits.  When \fB\-mpc32\fR
+is specified, the significands of results of floating-point operations are
+rounded to 24 bits (single precision); \fB\-mpc64\fR rounds the
+significands of results of floating-point operations to 53 bits (double
+precision) and \fB\-mpc80\fR rounds the significands of results of
+floating-point operations to 64 bits (extended double precision), which is
+the default.  When this option is used, floating-point operations in higher
+precisions are not available to the programmer without setting the \s-1FPU\s0
+control word explicitly.
+.Sp
+Setting the rounding of floating-point operations to less than the default
+80 bits can speed some programs by 2% or more.  Note that some mathematical
+libraries assume that extended-precision (80\-bit) floating-point operations
+are enabled by default; routines in such libraries could suffer significant
+loss of accuracy, typically through so-called \*(L"catastrophic cancellation\*(R",
+when this option is used to set the precision to less than extended precision.
+.IP "\fB\-mstackrealign\fR" 4
+.IX Item "-mstackrealign"
+Realign the stack at entry.  On the Intel x86, the \fB\-mstackrealign\fR
+option generates an alternate prologue and epilogue that realigns the
+run-time stack if necessary.  This supports mixing legacy codes that keep
+4\-byte stack alignment with modern codes that keep 16\-byte stack alignment for
+\&\s-1SSE\s0 compatibility.  See also the attribute \f(CW\*(C`force_align_arg_pointer\*(C'\fR,
+applicable to individual functions.
+.IP "\fB\-mpreferred\-stack\-boundary=\fR\fInum\fR" 4
+.IX Item "-mpreferred-stack-boundary=num"
+Attempt to keep the stack boundary aligned to a 2 raised to \fInum\fR
+byte boundary.  If \fB\-mpreferred\-stack\-boundary\fR is not specified,
+the default is 4 (16 bytes or 128 bits).
+.Sp
+\&\fBWarning:\fR When generating code for the x86\-64 architecture with
+\&\s-1SSE\s0 extensions disabled, \fB\-mpreferred\-stack\-boundary=3\fR can be
+used to keep the stack boundary aligned to 8 byte boundary.  Since
+x86\-64 \s-1ABI\s0 require 16 byte stack alignment, this is \s-1ABI\s0 incompatible and
+intended to be used in controlled environment where stack space is
+important limitation.  This option will lead to wrong code when functions
+compiled with 16 byte stack alignment (such as functions from a standard
+library) are called with misaligned stack.  In this case, \s-1SSE\s0
+instructions may lead to misaligned memory access traps.  In addition,
+variable arguments will be handled incorrectly for 16 byte aligned
+objects (including x87 long double and _\|_int128), leading to wrong
+results.  You must build all modules with
+\&\fB\-mpreferred\-stack\-boundary=3\fR, including any libraries.  This
+includes the system libraries and startup modules.
+.IP "\fB\-mincoming\-stack\-boundary=\fR\fInum\fR" 4
+.IX Item "-mincoming-stack-boundary=num"
+Assume the incoming stack is aligned to a 2 raised to \fInum\fR byte
+boundary.  If \fB\-mincoming\-stack\-boundary\fR is not specified,
+the one specified by \fB\-mpreferred\-stack\-boundary\fR is used.
+.Sp
+On Pentium and Pentium Pro, \f(CW\*(C`double\*(C'\fR and \f(CW\*(C`long double\*(C'\fR values
+should be aligned to an 8\-byte boundary (see \fB\-malign\-double\fR) or
+suffer significant run time performance penalties.  On Pentium \s-1III,\s0 the
+Streaming \s-1SIMD\s0 Extension (\s-1SSE\s0) data type \f(CW\*(C`_\|_m128\*(C'\fR may not work
+properly if it is not 16\-byte aligned.
+.Sp
+To ensure proper alignment of this values on the stack, the stack boundary
+must be as aligned as that required by any value stored on the stack.
+Further, every function must be generated such that it keeps the stack
+aligned.  Thus calling a function compiled with a higher preferred
+stack boundary from a function compiled with a lower preferred stack
+boundary most likely misaligns the stack.  It is recommended that
+libraries that use callbacks always use the default setting.
+.Sp
+This extra alignment does consume extra stack space, and generally
+increases code size.  Code that is sensitive to stack space usage, such
+as embedded systems and operating system kernels, may want to reduce the
+preferred alignment to \fB\-mpreferred\-stack\-boundary=2\fR.
+.IP "\fB\-mmmx\fR" 4
+.IX Item "-mmmx"
+.PD 0
+.IP "\fB\-mno\-mmx\fR" 4
+.IX Item "-mno-mmx"
+.IP "\fB\-msse\fR" 4
+.IX Item "-msse"
+.IP "\fB\-mno\-sse\fR" 4
+.IX Item "-mno-sse"
+.IP "\fB\-msse2\fR" 4
+.IX Item "-msse2"
+.IP "\fB\-mno\-sse2\fR" 4
+.IX Item "-mno-sse2"
+.IP "\fB\-msse3\fR" 4
+.IX Item "-msse3"
+.IP "\fB\-mno\-sse3\fR" 4
+.IX Item "-mno-sse3"
+.IP "\fB\-mssse3\fR" 4
+.IX Item "-mssse3"
+.IP "\fB\-mno\-ssse3\fR" 4
+.IX Item "-mno-ssse3"
+.IP "\fB\-msse4.1\fR" 4
+.IX Item "-msse4.1"
+.IP "\fB\-mno\-sse4.1\fR" 4
+.IX Item "-mno-sse4.1"
+.IP "\fB\-msse4.2\fR" 4
+.IX Item "-msse4.2"
+.IP "\fB\-mno\-sse4.2\fR" 4
+.IX Item "-mno-sse4.2"
+.IP "\fB\-msse4\fR" 4
+.IX Item "-msse4"
+.IP "\fB\-mno\-sse4\fR" 4
+.IX Item "-mno-sse4"
+.IP "\fB\-mavx\fR" 4
+.IX Item "-mavx"
+.IP "\fB\-mno\-avx\fR" 4
+.IX Item "-mno-avx"
+.IP "\fB\-mavx2\fR" 4
+.IX Item "-mavx2"
+.IP "\fB\-mno\-avx2\fR" 4
+.IX Item "-mno-avx2"
+.IP "\fB\-mavx512f\fR" 4
+.IX Item "-mavx512f"
+.IP "\fB\-mno\-avx512f\fR" 4
+.IX Item "-mno-avx512f"
+.IP "\fB\-mavx512pf\fR" 4
+.IX Item "-mavx512pf"
+.IP "\fB\-mno\-avx512pf\fR" 4
+.IX Item "-mno-avx512pf"
+.IP "\fB\-mavx512er\fR" 4
+.IX Item "-mavx512er"
+.IP "\fB\-mno\-avx512er\fR" 4
+.IX Item "-mno-avx512er"
+.IP "\fB\-mavx512cd\fR" 4
+.IX Item "-mavx512cd"
+.IP "\fB\-mno\-avx512cd\fR" 4
+.IX Item "-mno-avx512cd"
+.IP "\fB\-msha\fR" 4
+.IX Item "-msha"
+.IP "\fB\-mno\-sha\fR" 4
+.IX Item "-mno-sha"
+.IP "\fB\-maes\fR" 4
+.IX Item "-maes"
+.IP "\fB\-mno\-aes\fR" 4
+.IX Item "-mno-aes"
+.IP "\fB\-mpclmul\fR" 4
+.IX Item "-mpclmul"
+.IP "\fB\-mno\-pclmul\fR" 4
+.IX Item "-mno-pclmul"
+.IP "\fB\-mfsgsbase\fR" 4
+.IX Item "-mfsgsbase"
+.IP "\fB\-mno\-fsgsbase\fR" 4
+.IX Item "-mno-fsgsbase"
+.IP "\fB\-mrdrnd\fR" 4
+.IX Item "-mrdrnd"
+.IP "\fB\-mno\-rdrnd\fR" 4
+.IX Item "-mno-rdrnd"
+.IP "\fB\-mf16c\fR" 4
+.IX Item "-mf16c"
+.IP "\fB\-mno\-f16c\fR" 4
+.IX Item "-mno-f16c"
+.IP "\fB\-mfma\fR" 4
+.IX Item "-mfma"
+.IP "\fB\-mno\-fma\fR" 4
+.IX Item "-mno-fma"
+.IP "\fB\-mprefetchwt1\fR" 4
+.IX Item "-mprefetchwt1"
+.IP "\fB\-mno\-prefetchwt1\fR" 4
+.IX Item "-mno-prefetchwt1"
+.IP "\fB\-msse4a\fR" 4
+.IX Item "-msse4a"
+.IP "\fB\-mno\-sse4a\fR" 4
+.IX Item "-mno-sse4a"
+.IP "\fB\-mfma4\fR" 4
+.IX Item "-mfma4"
+.IP "\fB\-mno\-fma4\fR" 4
+.IX Item "-mno-fma4"
+.IP "\fB\-mxop\fR" 4
+.IX Item "-mxop"
+.IP "\fB\-mno\-xop\fR" 4
+.IX Item "-mno-xop"
+.IP "\fB\-mlwp\fR" 4
+.IX Item "-mlwp"
+.IP "\fB\-mno\-lwp\fR" 4
+.IX Item "-mno-lwp"
+.IP "\fB\-m3dnow\fR" 4
+.IX Item "-m3dnow"
+.IP "\fB\-mno\-3dnow\fR" 4
+.IX Item "-mno-3dnow"
+.IP "\fB\-mpopcnt\fR" 4
+.IX Item "-mpopcnt"
+.IP "\fB\-mno\-popcnt\fR" 4
+.IX Item "-mno-popcnt"
+.IP "\fB\-mabm\fR" 4
+.IX Item "-mabm"
+.IP "\fB\-mno\-abm\fR" 4
+.IX Item "-mno-abm"
+.IP "\fB\-mbmi\fR" 4
+.IX Item "-mbmi"
+.IP "\fB\-mbmi2\fR" 4
+.IX Item "-mbmi2"
+.IP "\fB\-mno\-bmi\fR" 4
+.IX Item "-mno-bmi"
+.IP "\fB\-mno\-bmi2\fR" 4
+.IX Item "-mno-bmi2"
+.IP "\fB\-mlzcnt\fR" 4
+.IX Item "-mlzcnt"
+.IP "\fB\-mno\-lzcnt\fR" 4
+.IX Item "-mno-lzcnt"
+.IP "\fB\-mfxsr\fR" 4
+.IX Item "-mfxsr"
+.IP "\fB\-mxsave\fR" 4
+.IX Item "-mxsave"
+.IP "\fB\-mxsaveopt\fR" 4
+.IX Item "-mxsaveopt"
+.IP "\fB\-mrtm\fR" 4
+.IX Item "-mrtm"
+.IP "\fB\-mtbm\fR" 4
+.IX Item "-mtbm"
+.IP "\fB\-mno\-tbm\fR" 4
+.IX Item "-mno-tbm"
+.PD
+These switches enable or disable the use of instructions in the \s-1MMX, SSE,
+SSE2, SSE3, SSSE3, SSE4.1, AVX, AVX2, AVX512F, AVX512PF, AVX512ER, AVX512CD,
+SHA, AES, PCLMUL, FSGSBASE, RDRND, F16C, FMA, SSE4A, FMA4, XOP, LWP, ABM,
+BMI, BMI2, FXSR, XSAVE, XSAVEOPT, LZCNT, RTM,\s0 or 3DNow!
+extended instruction sets.
+These extensions are also available as built-in functions: see
+\&\fBX86 Built-in Functions\fR, for details of the functions enabled and
+disabled by these switches.
+.Sp
+To generate \s-1SSE/SSE2\s0 instructions automatically from floating-point
+code (as opposed to 387 instructions), see \fB\-mfpmath=sse\fR.
+.Sp
+\&\s-1GCC\s0 depresses SSEx instructions when \fB\-mavx\fR is used. Instead, it
+generates new \s-1AVX\s0 instructions or \s-1AVX\s0 equivalence for all SSEx instructions
+when needed.
+.Sp
+These options enable \s-1GCC\s0 to use these extended instructions in
+generated code, even without \fB\-mfpmath=sse\fR.  Applications that
+perform run-time \s-1CPU\s0 detection must compile separate files for each
+supported architecture, using the appropriate flags.  In particular,
+the file containing the \s-1CPU\s0 detection code should be compiled without
+these options.
+.IP "\fB\-mdump\-tune\-features\fR" 4
+.IX Item "-mdump-tune-features"
+This option instructs \s-1GCC\s0 to dump the names of the x86 performance 
+tuning features and default settings. The names can be used in 
+\&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR.
+.IP "\fB\-mtune\-ctrl=\fR\fIfeature-list\fR" 4
+.IX Item "-mtune-ctrl=feature-list"
+This option is used to do fine grain control of x86 code generation features.
+\&\fIfeature-list\fR is a comma separated list of \fIfeature\fR names. See also
+\&\fB\-mdump\-tune\-features\fR. When specified, the \fIfeature\fR will be turned
+on if it is not preceded with \f(CW\*(C`^\*(C'\fR, otherwise, it will be turned off. 
+\&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR is intended to be used by \s-1GCC\s0
+developers. Using it may lead to code paths not covered by testing and can
+potentially result in compiler ICEs or runtime errors.
+.IP "\fB\-mno\-default\fR" 4
+.IX Item "-mno-default"
+This option instructs \s-1GCC\s0 to turn off all tunable features. See also 
+\&\fB\-mtune\-ctrl=\fR\fIfeature-list\fR and \fB\-mdump\-tune\-features\fR.
+.IP "\fB\-mcld\fR" 4
+.IX Item "-mcld"
+This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`cld\*(C'\fR instruction in the prologue
+of functions that use string instructions.  String instructions depend on
+the \s-1DF\s0 flag to select between autoincrement or autodecrement mode.  While the
+\&\s-1ABI\s0 specifies the \s-1DF\s0 flag to be cleared on function entry, some operating
+systems violate this specification by not clearing the \s-1DF\s0 flag in their
+exception dispatchers.  The exception handler can be invoked with the \s-1DF\s0 flag
+set, which leads to wrong direction mode when string instructions are used.
+This option can be enabled by default on 32\-bit x86 targets by configuring
+\&\s-1GCC\s0 with the \fB\-\-enable\-cld\fR configure option.  Generation of \f(CW\*(C`cld\*(C'\fR
+instructions can be suppressed with the \fB\-mno\-cld\fR compiler option
+in this case.
+.IP "\fB\-mvzeroupper\fR" 4
+.IX Item "-mvzeroupper"
+This option instructs \s-1GCC\s0 to emit a \f(CW\*(C`vzeroupper\*(C'\fR instruction
+before a transfer of control flow out of the function to minimize
+the \s-1AVX\s0 to \s-1SSE\s0 transition penalty as well as remove unnecessary \f(CW\*(C`zeroupper\*(C'\fR
+intrinsics.
+.IP "\fB\-mprefer\-avx128\fR" 4
+.IX Item "-mprefer-avx128"
+This option instructs \s-1GCC\s0 to use 128\-bit \s-1AVX\s0 instructions instead of
+256\-bit \s-1AVX\s0 instructions in the auto-vectorizer.
+.IP "\fB\-mcx16\fR" 4
+.IX Item "-mcx16"
+This option enables \s-1GCC\s0 to generate \f(CW\*(C`CMPXCHG16B\*(C'\fR instructions.
+\&\f(CW\*(C`CMPXCHG16B\*(C'\fR allows for atomic operations on 128\-bit double quadword
+(or oword) data types.  
+This is useful for high-resolution counters that can be updated
+by multiple processors (or cores).  This instruction is generated as part of
+atomic built-in functions: see \fB_\|_sync Builtins\fR or
+\&\fB_\|_atomic Builtins\fR for details.
+.IP "\fB\-msahf\fR" 4
+.IX Item "-msahf"
+This option enables generation of \f(CW\*(C`SAHF\*(C'\fR instructions in 64\-bit code.
+Early Intel Pentium 4 CPUs with Intel 64 support,
+prior to the introduction of Pentium 4 G1 step in December 2005,
+lacked the \f(CW\*(C`LAHF\*(C'\fR and \f(CW\*(C`SAHF\*(C'\fR instructions
+which were supported by \s-1AMD64.\s0
+These are load and store instructions, respectively, for certain status flags.
+In 64\-bit mode, the \f(CW\*(C`SAHF\*(C'\fR instruction is used to optimize \f(CW\*(C`fmod\*(C'\fR,
+\&\f(CW\*(C`drem\*(C'\fR, and \f(CW\*(C`remainder\*(C'\fR built-in functions;
+see \fBOther Builtins\fR for details.
+.IP "\fB\-mmovbe\fR" 4
+.IX Item "-mmovbe"
+This option enables use of the \f(CW\*(C`movbe\*(C'\fR instruction to implement
+\&\f(CW\*(C`_\|_builtin_bswap32\*(C'\fR and \f(CW\*(C`_\|_builtin_bswap64\*(C'\fR.
+.IP "\fB\-mcrc32\fR" 4
+.IX Item "-mcrc32"
+This option enables built-in functions \f(CW\*(C`_\|_builtin_ia32_crc32qi\*(C'\fR,
+\&\f(CW\*(C`_\|_builtin_ia32_crc32hi\*(C'\fR, \f(CW\*(C`_\|_builtin_ia32_crc32si\*(C'\fR and
+\&\f(CW\*(C`_\|_builtin_ia32_crc32di\*(C'\fR to generate the \f(CW\*(C`crc32\*(C'\fR machine instruction.
+.IP "\fB\-mrecip\fR" 4
+.IX Item "-mrecip"
+This option enables use of \f(CW\*(C`RCPSS\*(C'\fR and \f(CW\*(C`RSQRTSS\*(C'\fR instructions
+(and their vectorized variants \f(CW\*(C`RCPPS\*(C'\fR and \f(CW\*(C`RSQRTPS\*(C'\fR)
+with an additional Newton-Raphson step
+to increase precision instead of \f(CW\*(C`DIVSS\*(C'\fR and \f(CW\*(C`SQRTSS\*(C'\fR
+(and their vectorized
+variants) for single-precision floating-point arguments.  These instructions
+are generated only when \fB\-funsafe\-math\-optimizations\fR is enabled
+together with \fB\-finite\-math\-only\fR and \fB\-fno\-trapping\-math\fR.
+Note that while the throughput of the sequence is higher than the throughput
+of the non-reciprocal instruction, the precision of the sequence can be
+decreased by up to 2 ulp (i.e. the inverse of 1.0 equals 0.99999994).
+.Sp
+Note that \s-1GCC\s0 implements \f(CW\*(C`1.0f/sqrtf(\f(CIx\f(CW)\*(C'\fR in terms of \f(CW\*(C`RSQRTSS\*(C'\fR
+(or \f(CW\*(C`RSQRTPS\*(C'\fR) already with \fB\-ffast\-math\fR (or the above option
+combination), and doesn't need \fB\-mrecip\fR.
+.Sp
+Also note that \s-1GCC\s0 emits the above sequence with additional Newton-Raphson step
+for vectorized single-float division and vectorized \f(CW\*(C`sqrtf(\f(CIx\f(CW)\*(C'\fR
+already with \fB\-ffast\-math\fR (or the above option combination), and
+doesn't need \fB\-mrecip\fR.
+.IP "\fB\-mrecip=\fR\fIopt\fR" 4
+.IX Item "-mrecip=opt"
+This option controls which reciprocal estimate instructions
+may be used.  \fIopt\fR is a comma-separated list of options, which may
+be preceded by a \fB!\fR to invert the option:
+.RS 4
+.IP "\fBall\fR" 4
+.IX Item "all"
+Enable all estimate instructions.
+.IP "\fBdefault\fR" 4
+.IX Item "default"
+Enable the default instructions, equivalent to \fB\-mrecip\fR.
+.IP "\fBnone\fR" 4
+.IX Item "none"
+Disable all estimate instructions, equivalent to \fB\-mno\-recip\fR.
+.IP "\fBdiv\fR" 4
+.IX Item "div"
+Enable the approximation for scalar division.
+.IP "\fBvec-div\fR" 4
+.IX Item "vec-div"
+Enable the approximation for vectorized division.
+.IP "\fBsqrt\fR" 4
+.IX Item "sqrt"
+Enable the approximation for scalar square root.
+.IP "\fBvec-sqrt\fR" 4
+.IX Item "vec-sqrt"
+Enable the approximation for vectorized square root.
+.RE
+.RS 4
+.Sp
+So, for example, \fB\-mrecip=all,!sqrt\fR enables
+all of the reciprocal approximations, except for square root.
+.RE
+.IP "\fB\-mveclibabi=\fR\fItype\fR" 4
+.IX Item "-mveclibabi=type"
+Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
+external library.  Supported values for \fItype\fR are \fBsvml\fR 
+for the Intel short
+vector math library and \fBacml\fR for the \s-1AMD\s0 math core library.
+To use this option, both \fB\-ftree\-vectorize\fR and
+\&\fB\-funsafe\-math\-optimizations\fR have to be enabled, and an \s-1SVML\s0 or \s-1ACML \s0
+ABI-compatible library must be specified at link time.
+.Sp
+\&\s-1GCC\s0 currently emits calls to \f(CW\*(C`vmldExp2\*(C'\fR,
+\&\f(CW\*(C`vmldLn2\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldLog102\*(C'\fR, \f(CW\*(C`vmldPow2\*(C'\fR,
+\&\f(CW\*(C`vmldTanh2\*(C'\fR, \f(CW\*(C`vmldTan2\*(C'\fR, \f(CW\*(C`vmldAtan2\*(C'\fR, \f(CW\*(C`vmldAtanh2\*(C'\fR,
+\&\f(CW\*(C`vmldCbrt2\*(C'\fR, \f(CW\*(C`vmldSinh2\*(C'\fR, \f(CW\*(C`vmldSin2\*(C'\fR, \f(CW\*(C`vmldAsinh2\*(C'\fR,
+\&\f(CW\*(C`vmldAsin2\*(C'\fR, \f(CW\*(C`vmldCosh2\*(C'\fR, \f(CW\*(C`vmldCos2\*(C'\fR, \f(CW\*(C`vmldAcosh2\*(C'\fR,
+\&\f(CW\*(C`vmldAcos2\*(C'\fR, \f(CW\*(C`vmlsExp4\*(C'\fR, \f(CW\*(C`vmlsLn4\*(C'\fR, \f(CW\*(C`vmlsLog104\*(C'\fR,
+\&\f(CW\*(C`vmlsLog104\*(C'\fR, \f(CW\*(C`vmlsPow4\*(C'\fR, \f(CW\*(C`vmlsTanh4\*(C'\fR, \f(CW\*(C`vmlsTan4\*(C'\fR,
+\&\f(CW\*(C`vmlsAtan4\*(C'\fR, \f(CW\*(C`vmlsAtanh4\*(C'\fR, \f(CW\*(C`vmlsCbrt4\*(C'\fR, \f(CW\*(C`vmlsSinh4\*(C'\fR,
+\&\f(CW\*(C`vmlsSin4\*(C'\fR, \f(CW\*(C`vmlsAsinh4\*(C'\fR, \f(CW\*(C`vmlsAsin4\*(C'\fR, \f(CW\*(C`vmlsCosh4\*(C'\fR,
+\&\f(CW\*(C`vmlsCos4\*(C'\fR, \f(CW\*(C`vmlsAcosh4\*(C'\fR and \f(CW\*(C`vmlsAcos4\*(C'\fR for corresponding
+function type when \fB\-mveclibabi=svml\fR is used, and \f(CW\*(C`_\|_vrd2_sin\*(C'\fR,
+\&\f(CW\*(C`_\|_vrd2_cos\*(C'\fR, \f(CW\*(C`_\|_vrd2_exp\*(C'\fR, \f(CW\*(C`_\|_vrd2_log\*(C'\fR, \f(CW\*(C`_\|_vrd2_log2\*(C'\fR,
+\&\f(CW\*(C`_\|_vrd2_log10\*(C'\fR, \f(CW\*(C`_\|_vrs4_sinf\*(C'\fR, \f(CW\*(C`_\|_vrs4_cosf\*(C'\fR,
+\&\f(CW\*(C`_\|_vrs4_expf\*(C'\fR, \f(CW\*(C`_\|_vrs4_logf\*(C'\fR, \f(CW\*(C`_\|_vrs4_log2f\*(C'\fR,
+\&\f(CW\*(C`_\|_vrs4_log10f\*(C'\fR and \f(CW\*(C`_\|_vrs4_powf\*(C'\fR for the corresponding function type
+when \fB\-mveclibabi=acml\fR is used.
+.IP "\fB\-mabi=\fR\fIname\fR" 4
+.IX Item "-mabi=name"
+Generate code for the specified calling convention.  Permissible values
+are \fBsysv\fR for the \s-1ABI\s0 used on GNU/Linux and other systems, and
+\&\fBms\fR for the Microsoft \s-1ABI. \s0 The default is to use the Microsoft
+\&\s-1ABI\s0 when targeting Microsoft Windows and the SysV \s-1ABI\s0 on all other systems.
+You can control this behavior for a specific function by
+using the function attribute \fBms_abi\fR/\fBsysv_abi\fR.
+.IP "\fB\-mtls\-dialect=\fR\fItype\fR" 4
+.IX Item "-mtls-dialect=type"
+Generate code to access thread-local storage using the \fBgnu\fR or
+\&\fBgnu2\fR conventions.  \fBgnu\fR is the conservative default;
+\&\fBgnu2\fR is more efficient, but it may add compile\- and run-time
+requirements that cannot be satisfied on all systems.
+.IP "\fB\-mpush\-args\fR" 4
+.IX Item "-mpush-args"
+.PD 0
+.IP "\fB\-mno\-push\-args\fR" 4
+.IX Item "-mno-push-args"
+.PD
+Use \s-1PUSH\s0 operations to store outgoing parameters.  This method is shorter
+and usually equally fast as method using \s-1SUB/MOV\s0 operations and is enabled
+by default.  In some cases disabling it may improve performance because of
+improved scheduling and reduced dependencies.
+.IP "\fB\-maccumulate\-outgoing\-args\fR" 4
+.IX Item "-maccumulate-outgoing-args"
+If enabled, the maximum amount of space required for outgoing arguments is
+computed in the function prologue.  This is faster on most modern CPUs
+because of reduced dependencies, improved scheduling and reduced stack usage
+when the preferred stack boundary is not equal to 2.  The drawback is a notable
+increase in code size.  This switch implies \fB\-mno\-push\-args\fR.
+.IP "\fB\-mthreads\fR" 4
+.IX Item "-mthreads"
+Support thread-safe exception handling on MinGW.  Programs that rely
+on thread-safe exception handling must compile and link all code with the
+\&\fB\-mthreads\fR option.  When compiling, \fB\-mthreads\fR defines
+\&\f(CW\*(C`\-D_MT\*(C'\fR; when linking, it links in a special thread helper library
+\&\fB\-lmingwthrd\fR which cleans up per-thread exception-handling data.
+.IP "\fB\-mno\-align\-stringops\fR" 4
+.IX Item "-mno-align-stringops"
+Do not align the destination of inlined string operations.  This switch reduces
+code size and improves performance in case the destination is already aligned,
+but \s-1GCC\s0 doesn't know about it.
+.IP "\fB\-minline\-all\-stringops\fR" 4
+.IX Item "-minline-all-stringops"
+By default \s-1GCC\s0 inlines string operations only when the destination is 
+known to be aligned to least a 4\-byte boundary.  
+This enables more inlining and increases code
+size, but may improve performance of code that depends on fast
+\&\f(CW\*(C`memcpy\*(C'\fR, \f(CW\*(C`strlen\*(C'\fR,
+and \f(CW\*(C`memset\*(C'\fR for short lengths.
+.IP "\fB\-minline\-stringops\-dynamically\fR" 4
+.IX Item "-minline-stringops-dynamically"
+For string operations of unknown size, use run-time checks with
+inline code for small blocks and a library call for large blocks.
+.IP "\fB\-mstringop\-strategy=\fR\fIalg\fR" 4
+.IX Item "-mstringop-strategy=alg"
+Override the internal decision heuristic for the particular algorithm to use
+for inlining string operations.  The allowed values for \fIalg\fR are:
+.RS 4
+.IP "\fBrep_byte\fR" 4
+.IX Item "rep_byte"
+.PD 0
+.IP "\fBrep_4byte\fR" 4
+.IX Item "rep_4byte"
+.IP "\fBrep_8byte\fR" 4
+.IX Item "rep_8byte"
+.PD
+Expand using i386 \f(CW\*(C`rep\*(C'\fR prefix of the specified size.
+.IP "\fBbyte_loop\fR" 4
+.IX Item "byte_loop"
+.PD 0
+.IP "\fBloop\fR" 4
+.IX Item "loop"
+.IP "\fBunrolled_loop\fR" 4
+.IX Item "unrolled_loop"
+.PD
+Expand into an inline loop.
+.IP "\fBlibcall\fR" 4
+.IX Item "libcall"
+Always use a library call.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mmemcpy\-strategy=\fR\fIstrategy\fR" 4
+.IX Item "-mmemcpy-strategy=strategy"
+Override the internal decision heuristic to decide if \f(CW\*(C`_\|_builtin_memcpy\*(C'\fR
+should be inlined and what inline algorithm to use when the expected size
+of the copy operation is known. \fIstrategy\fR 
+is a comma-separated list of \fIalg\fR:\fImax_size\fR:\fIdest_align\fR triplets. 
+\&\fIalg\fR is specified in \fB\-mstringop\-strategy\fR, \fImax_size\fR specifies
+the max byte size with which inline algorithm \fIalg\fR is allowed.  For the last
+triplet, the \fImax_size\fR must be \f(CW\*(C`\-1\*(C'\fR. The \fImax_size\fR of the triplets
+in the list must be specified in increasing order.  The minimal byte size for 
+\&\fIalg\fR is \f(CW0\fR for the first triplet and \f(CW\*(C`\f(CImax_size\f(CW + 1\*(C'\fR of the 
+preceding range.
+.IP "\fB\-mmemset\-strategy=\fR\fIstrategy\fR" 4
+.IX Item "-mmemset-strategy=strategy"
+The option is similar to \fB\-mmemcpy\-strategy=\fR except that it is to control
+\&\f(CW\*(C`_\|_builtin_memset\*(C'\fR expansion.
+.IP "\fB\-momit\-leaf\-frame\-pointer\fR" 4
+.IX Item "-momit-leaf-frame-pointer"
+Don't keep the frame pointer in a register for leaf functions.  This
+avoids the instructions to save, set up, and restore frame pointers and
+makes an extra register available in leaf functions.  The option
+\&\fB\-fomit\-leaf\-frame\-pointer\fR removes the frame pointer for leaf functions,
+which might make debugging harder.
+.IP "\fB\-mtls\-direct\-seg\-refs\fR" 4
+.IX Item "-mtls-direct-seg-refs"
+.PD 0
+.IP "\fB\-mno\-tls\-direct\-seg\-refs\fR" 4
+.IX Item "-mno-tls-direct-seg-refs"
+.PD
+Controls whether \s-1TLS\s0 variables may be accessed with offsets from the
+\&\s-1TLS\s0 segment register (\f(CW%gs\fR for 32\-bit, \f(CW%fs\fR for 64\-bit),
+or whether the thread base pointer must be added.  Whether or not this
+is valid depends on the operating system, and whether it maps the
+segment to cover the entire \s-1TLS\s0 area.
+.Sp
+For systems that use the \s-1GNU C\s0 Library, the default is on.
+.IP "\fB\-msse2avx\fR" 4
+.IX Item "-msse2avx"
+.PD 0
+.IP "\fB\-mno\-sse2avx\fR" 4
+.IX Item "-mno-sse2avx"
+.PD
+Specify that the assembler should encode \s-1SSE\s0 instructions with \s-1VEX\s0
+prefix.  The option \fB\-mavx\fR turns this on by default.
+.IP "\fB\-mfentry\fR" 4
+.IX Item "-mfentry"
+.PD 0
+.IP "\fB\-mno\-fentry\fR" 4
+.IX Item "-mno-fentry"
+.PD
+If profiling is active (\fB\-pg\fR), put the profiling
+counter call before the prologue.
+Note: On x86 architectures the attribute \f(CW\*(C`ms_hook_prologue\*(C'\fR
+isn't possible at the moment for \fB\-mfentry\fR and \fB\-pg\fR.
+.IP "\fB\-m8bit\-idiv\fR" 4
+.IX Item "-m8bit-idiv"
+.PD 0
+.IP "\fB\-mno\-8bit\-idiv\fR" 4
+.IX Item "-mno-8bit-idiv"
+.PD
+On some processors, like Intel Atom, 8\-bit unsigned integer divide is
+much faster than 32\-bit/64\-bit integer divide.  This option generates a
+run-time check.  If both dividend and divisor are within range of 0
+to 255, 8\-bit unsigned integer divide is used instead of
+32\-bit/64\-bit integer divide.
+.IP "\fB\-mavx256\-split\-unaligned\-load\fR" 4
+.IX Item "-mavx256-split-unaligned-load"
+.PD 0
+.IP "\fB\-mavx256\-split\-unaligned\-store\fR" 4
+.IX Item "-mavx256-split-unaligned-store"
+.PD
+Split 32\-byte \s-1AVX\s0 unaligned load and store.
+.IP "\fB\-mstack\-protector\-guard=\fR\fIguard\fR" 4
+.IX Item "-mstack-protector-guard=guard"
+Generate stack protection code using canary at \fIguard\fR.  Supported
+locations are \fBglobal\fR for global canary or \fBtls\fR for per-thread
+canary in the \s-1TLS\s0 block (the default).  This option has effect only when
+\&\fB\-fstack\-protector\fR or \fB\-fstack\-protector\-all\fR is specified.
+.PP
+These \fB\-m\fR switches are supported in addition to the above
+on x86\-64 processors in 64\-bit environments.
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+.PD 0
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.IP "\fB\-mx32\fR" 4
+.IX Item "-mx32"
+.IP "\fB\-m16\fR" 4
+.IX Item "-m16"
+.PD
+Generate code for a 16\-bit, 32\-bit or 64\-bit environment.
+The \fB\-m32\fR option sets \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, and pointer types
+to 32 bits, and
+generates code that runs on any i386 system.
+.Sp
+The \fB\-m64\fR option sets \f(CW\*(C`int\*(C'\fR to 32 bits and \f(CW\*(C`long\*(C'\fR and pointer
+types to 64 bits, and generates code for the x86\-64 architecture.
+For Darwin only the \fB\-m64\fR option also turns off the \fB\-fno\-pic\fR
+and \fB\-mdynamic\-no\-pic\fR options.
+.Sp
+The \fB\-mx32\fR option sets \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, and pointer types
+to 32 bits, and
+generates code for the x86\-64 architecture.
+.Sp
+The \fB\-m16\fR option is the same as \fB\-m32\fR, except for that
+it outputs the \f(CW\*(C`.code16gcc\*(C'\fR assembly directive at the beginning of
+the assembly output so that the binary can run in 16\-bit mode.
+.IP "\fB\-mno\-red\-zone\fR" 4
+.IX Item "-mno-red-zone"
+Do not use a so-called \*(L"red zone\*(R" for x86\-64 code.  The red zone is mandated
+by the x86\-64 \s-1ABI\s0; it is a 128\-byte area beyond the location of the
+stack pointer that is not modified by signal or interrupt handlers
+and therefore can be used for temporary data without adjusting the stack
+pointer.  The flag \fB\-mno\-red\-zone\fR disables this red zone.
+.IP "\fB\-mcmodel=small\fR" 4
+.IX Item "-mcmodel=small"
+Generate code for the small code model: the program and its symbols must
+be linked in the lower 2 \s-1GB\s0 of the address space.  Pointers are 64 bits.
+Programs can be statically or dynamically linked.  This is the default
+code model.
+.IP "\fB\-mcmodel=kernel\fR" 4
+.IX Item "-mcmodel=kernel"
+Generate code for the kernel code model.  The kernel runs in the
+negative 2 \s-1GB\s0 of the address space.
+This model has to be used for Linux kernel code.
+.IP "\fB\-mcmodel=medium\fR" 4
+.IX Item "-mcmodel=medium"
+Generate code for the medium model: the program is linked in the lower 2
+\&\s-1GB\s0 of the address space.  Small symbols are also placed there.  Symbols
+with sizes larger than \fB\-mlarge\-data\-threshold\fR are put into
+large data or \s-1BSS\s0 sections and can be located above 2GB.  Programs can
+be statically or dynamically linked.
+.IP "\fB\-mcmodel=large\fR" 4
+.IX Item "-mcmodel=large"
+Generate code for the large model.  This model makes no assumptions
+about addresses and sizes of sections.
+.IP "\fB\-maddress\-mode=long\fR" 4
+.IX Item "-maddress-mode=long"
+Generate code for long address mode.  This is only supported for 64\-bit
+and x32 environments.  It is the default address mode for 64\-bit
+environments.
+.IP "\fB\-maddress\-mode=short\fR" 4
+.IX Item "-maddress-mode=short"
+Generate code for short address mode.  This is only supported for 32\-bit
+and x32 environments.  It is the default address mode for 32\-bit and
+x32 environments.
+.PP
+\fIi386 and x86\-64 Windows Options\fR
+.IX Subsection "i386 and x86-64 Windows Options"
+.PP
+These additional options are available for Microsoft Windows targets:
+.IP "\fB\-mconsole\fR" 4
+.IX Item "-mconsole"
+This option
+specifies that a console application is to be generated, by
+instructing the linker to set the \s-1PE\s0 header subsystem type
+required for console applications.
+This option is available for Cygwin and MinGW targets and is
+enabled by default on those targets.
+.IP "\fB\-mdll\fR" 4
+.IX Item "-mdll"
+This option is available for Cygwin and MinGW targets.  It
+specifies that a DLL\-\-\-a dynamic link library\-\-\-is to be
+generated, enabling the selection of the required runtime
+startup object and entry point.
+.IP "\fB\-mnop\-fun\-dllimport\fR" 4
+.IX Item "-mnop-fun-dllimport"
+This option is available for Cygwin and MinGW targets.  It
+specifies that the \f(CW\*(C`dllimport\*(C'\fR attribute should be ignored.
+.IP "\fB\-mthread\fR" 4
+.IX Item "-mthread"
+This option is available for MinGW targets. It specifies
+that MinGW-specific thread support is to be used.
+.IP "\fB\-municode\fR" 4
+.IX Item "-municode"
+This option is available for MinGW\-w64 targets.  It causes
+the \f(CW\*(C`UNICODE\*(C'\fR preprocessor macro to be predefined, and
+chooses Unicode-capable runtime startup code.
+.IP "\fB\-mwin32\fR" 4
+.IX Item "-mwin32"
+This option is available for Cygwin and MinGW targets.  It
+specifies that the typical Microsoft Windows predefined macros are to
+be set in the pre-processor, but does not influence the choice
+of runtime library/startup code.
+.IP "\fB\-mwindows\fR" 4
+.IX Item "-mwindows"
+This option is available for Cygwin and MinGW targets.  It
+specifies that a \s-1GUI\s0 application is to be generated by
+instructing the linker to set the \s-1PE\s0 header subsystem type
+appropriately.
+.IP "\fB\-fno\-set\-stack\-executable\fR" 4
+.IX Item "-fno-set-stack-executable"
+This option is available for MinGW targets. It specifies that
+the executable flag for the stack used by nested functions isn't
+set. This is necessary for binaries running in kernel mode of
+Microsoft Windows, as there the User32 \s-1API,\s0 which is used to set executable
+privileges, isn't available.
+.IP "\fB\-fwritable\-relocated\-rdata\fR" 4
+.IX Item "-fwritable-relocated-rdata"
+This option is available for MinGW and Cygwin targets.  It specifies
+that relocated-data in read-only section is put into .data
+section.  This is a necessary for older runtimes not supporting
+modification of .rdata sections for pseudo-relocation.
+.IP "\fB\-mpe\-aligned\-commons\fR" 4
+.IX Item "-mpe-aligned-commons"
+This option is available for Cygwin and MinGW targets.  It
+specifies that the \s-1GNU\s0 extension to the \s-1PE\s0 file format that
+permits the correct alignment of \s-1COMMON\s0 variables should be
+used when generating code.  It is enabled by default if
+\&\s-1GCC\s0 detects that the target assembler found during configuration
+supports the feature.
+.PP
+See also under \fBi386 and x86\-64 Options\fR for standard options.
+.PP
+\fI\s-1IA\-64\s0 Options\fR
+.IX Subsection "IA-64 Options"
+.PP
+These are the \fB\-m\fR options defined for the Intel \s-1IA\-64\s0 architecture.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code for a big-endian target.  This is the default for HP-UX.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code for a little-endian target.  This is the default for \s-1AIX5\s0
+and GNU/Linux.
+.IP "\fB\-mgnu\-as\fR" 4
+.IX Item "-mgnu-as"
+.PD 0
+.IP "\fB\-mno\-gnu\-as\fR" 4
+.IX Item "-mno-gnu-as"
+.PD
+Generate (or don't) code for the \s-1GNU\s0 assembler.  This is the default.
+.IP "\fB\-mgnu\-ld\fR" 4
+.IX Item "-mgnu-ld"
+.PD 0
+.IP "\fB\-mno\-gnu\-ld\fR" 4
+.IX Item "-mno-gnu-ld"
+.PD
+Generate (or don't) code for the \s-1GNU\s0 linker.  This is the default.
+.IP "\fB\-mno\-pic\fR" 4
+.IX Item "-mno-pic"
+Generate code that does not use a global pointer register.  The result
+is not position independent code, and violates the \s-1IA\-64 ABI.\s0
+.IP "\fB\-mvolatile\-asm\-stop\fR" 4
+.IX Item "-mvolatile-asm-stop"
+.PD 0
+.IP "\fB\-mno\-volatile\-asm\-stop\fR" 4
+.IX Item "-mno-volatile-asm-stop"
+.PD
+Generate (or don't) a stop bit immediately before and after volatile asm
+statements.
+.IP "\fB\-mregister\-names\fR" 4
+.IX Item "-mregister-names"
+.PD 0
+.IP "\fB\-mno\-register\-names\fR" 4
+.IX Item "-mno-register-names"
+.PD
+Generate (or don't) \fBin\fR, \fBloc\fR, and \fBout\fR register names for
+the stacked registers.  This may make assembler output more readable.
+.IP "\fB\-mno\-sdata\fR" 4
+.IX Item "-mno-sdata"
+.PD 0
+.IP "\fB\-msdata\fR" 4
+.IX Item "-msdata"
+.PD
+Disable (or enable) optimizations that use the small data section.  This may
+be useful for working around optimizer bugs.
+.IP "\fB\-mconstant\-gp\fR" 4
+.IX Item "-mconstant-gp"
+Generate code that uses a single constant global pointer value.  This is
+useful when compiling kernel code.
+.IP "\fB\-mauto\-pic\fR" 4
+.IX Item "-mauto-pic"
+Generate code that is self-relocatable.  This implies \fB\-mconstant\-gp\fR.
+This is useful when compiling firmware code.
+.IP "\fB\-minline\-float\-divide\-min\-latency\fR" 4
+.IX Item "-minline-float-divide-min-latency"
+Generate code for inline divides of floating-point values
+using the minimum latency algorithm.
+.IP "\fB\-minline\-float\-divide\-max\-throughput\fR" 4
+.IX Item "-minline-float-divide-max-throughput"
+Generate code for inline divides of floating-point values
+using the maximum throughput algorithm.
+.IP "\fB\-mno\-inline\-float\-divide\fR" 4
+.IX Item "-mno-inline-float-divide"
+Do not generate inline code for divides of floating-point values.
+.IP "\fB\-minline\-int\-divide\-min\-latency\fR" 4
+.IX Item "-minline-int-divide-min-latency"
+Generate code for inline divides of integer values
+using the minimum latency algorithm.
+.IP "\fB\-minline\-int\-divide\-max\-throughput\fR" 4
+.IX Item "-minline-int-divide-max-throughput"
+Generate code for inline divides of integer values
+using the maximum throughput algorithm.
+.IP "\fB\-mno\-inline\-int\-divide\fR" 4
+.IX Item "-mno-inline-int-divide"
+Do not generate inline code for divides of integer values.
+.IP "\fB\-minline\-sqrt\-min\-latency\fR" 4
+.IX Item "-minline-sqrt-min-latency"
+Generate code for inline square roots
+using the minimum latency algorithm.
+.IP "\fB\-minline\-sqrt\-max\-throughput\fR" 4
+.IX Item "-minline-sqrt-max-throughput"
+Generate code for inline square roots
+using the maximum throughput algorithm.
+.IP "\fB\-mno\-inline\-sqrt\fR" 4
+.IX Item "-mno-inline-sqrt"
+Do not generate inline code for \f(CW\*(C`sqrt\*(C'\fR.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Do (don't) generate code that uses the fused multiply/add or multiply/subtract
+instructions.  The default is to use these instructions.
+.IP "\fB\-mno\-dwarf2\-asm\fR" 4
+.IX Item "-mno-dwarf2-asm"
+.PD 0
+.IP "\fB\-mdwarf2\-asm\fR" 4
+.IX Item "-mdwarf2-asm"
+.PD
+Don't (or do) generate assembler code for the \s-1DWARF 2\s0 line number debugging
+info.  This may be useful when not using the \s-1GNU\s0 assembler.
+.IP "\fB\-mearly\-stop\-bits\fR" 4
+.IX Item "-mearly-stop-bits"
+.PD 0
+.IP "\fB\-mno\-early\-stop\-bits\fR" 4
+.IX Item "-mno-early-stop-bits"
+.PD
+Allow stop bits to be placed earlier than immediately preceding the
+instruction that triggered the stop bit.  This can improve instruction
+scheduling, but does not always do so.
+.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
+.IX Item "-mfixed-range=register-range"
+Generate code treating the given register range as fixed registers.
+A fixed register is one that the register allocator cannot use.  This is
+useful when compiling kernel code.  A register range is specified as
+two registers separated by a dash.  Multiple register ranges can be
+specified separated by a comma.
+.IP "\fB\-mtls\-size=\fR\fItls-size\fR" 4
+.IX Item "-mtls-size=tls-size"
+Specify bit size of immediate \s-1TLS\s0 offsets.  Valid values are 14, 22, and
+64.
+.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
+.IX Item "-mtune=cpu-type"
+Tune the instruction scheduling for a particular \s-1CPU,\s0 Valid values are
+\&\fBitanium\fR, \fBitanium1\fR, \fBmerced\fR, \fBitanium2\fR,
+and \fBmckinley\fR.
+.IP "\fB\-milp32\fR" 4
+.IX Item "-milp32"
+.PD 0
+.IP "\fB\-mlp64\fR" 4
+.IX Item "-mlp64"
+.PD
+Generate code for a 32\-bit or 64\-bit environment.
+The 32\-bit environment sets int, long and pointer to 32 bits.
+The 64\-bit environment sets int to 32 bits and long and pointer
+to 64 bits.  These are HP-UX specific flags.
+.IP "\fB\-mno\-sched\-br\-data\-spec\fR" 4
+.IX Item "-mno-sched-br-data-spec"
+.PD 0
+.IP "\fB\-msched\-br\-data\-spec\fR" 4
+.IX Item "-msched-br-data-spec"
+.PD
+(Dis/En)able data speculative scheduling before reload.
+This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
+the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
+The default is 'disable'.
+.IP "\fB\-msched\-ar\-data\-spec\fR" 4
+.IX Item "-msched-ar-data-spec"
+.PD 0
+.IP "\fB\-mno\-sched\-ar\-data\-spec\fR" 4
+.IX Item "-mno-sched-ar-data-spec"
+.PD
+(En/Dis)able data speculative scheduling after reload.
+This results in generation of \f(CW\*(C`ld.a\*(C'\fR instructions and
+the corresponding check instructions (\f(CW\*(C`ld.c\*(C'\fR / \f(CW\*(C`chk.a\*(C'\fR).
+The default is 'enable'.
+.IP "\fB\-mno\-sched\-control\-spec\fR" 4
+.IX Item "-mno-sched-control-spec"
+.PD 0
+.IP "\fB\-msched\-control\-spec\fR" 4
+.IX Item "-msched-control-spec"
+.PD
+(Dis/En)able control speculative scheduling.  This feature is
+available only during region scheduling (i.e. before reload).
+This results in generation of the \f(CW\*(C`ld.s\*(C'\fR instructions and
+the corresponding check instructions \f(CW\*(C`chk.s\*(C'\fR.
+The default is 'disable'.
+.IP "\fB\-msched\-br\-in\-data\-spec\fR" 4
+.IX Item "-msched-br-in-data-spec"
+.PD 0
+.IP "\fB\-mno\-sched\-br\-in\-data\-spec\fR" 4
+.IX Item "-mno-sched-br-in-data-spec"
+.PD
+(En/Dis)able speculative scheduling of the instructions that
+are dependent on the data speculative loads before reload.
+This is effective only with \fB\-msched\-br\-data\-spec\fR enabled.
+The default is 'enable'.
+.IP "\fB\-msched\-ar\-in\-data\-spec\fR" 4
+.IX Item "-msched-ar-in-data-spec"
+.PD 0
+.IP "\fB\-mno\-sched\-ar\-in\-data\-spec\fR" 4
+.IX Item "-mno-sched-ar-in-data-spec"
+.PD
+(En/Dis)able speculative scheduling of the instructions that
+are dependent on the data speculative loads after reload.
+This is effective only with \fB\-msched\-ar\-data\-spec\fR enabled.
+The default is 'enable'.
+.IP "\fB\-msched\-in\-control\-spec\fR" 4
+.IX Item "-msched-in-control-spec"
+.PD 0
+.IP "\fB\-mno\-sched\-in\-control\-spec\fR" 4
+.IX Item "-mno-sched-in-control-spec"
+.PD
+(En/Dis)able speculative scheduling of the instructions that
+are dependent on the control speculative loads.
+This is effective only with \fB\-msched\-control\-spec\fR enabled.
+The default is 'enable'.
+.IP "\fB\-mno\-sched\-prefer\-non\-data\-spec\-insns\fR" 4
+.IX Item "-mno-sched-prefer-non-data-spec-insns"
+.PD 0
+.IP "\fB\-msched\-prefer\-non\-data\-spec\-insns\fR" 4
+.IX Item "-msched-prefer-non-data-spec-insns"
+.PD
+If enabled, data-speculative instructions are chosen for schedule
+only if there are no other choices at the moment.  This makes
+the use of the data speculation much more conservative.
+The default is 'disable'.
+.IP "\fB\-mno\-sched\-prefer\-non\-control\-spec\-insns\fR" 4
+.IX Item "-mno-sched-prefer-non-control-spec-insns"
+.PD 0
+.IP "\fB\-msched\-prefer\-non\-control\-spec\-insns\fR" 4
+.IX Item "-msched-prefer-non-control-spec-insns"
+.PD
+If enabled, control-speculative instructions are chosen for schedule
+only if there are no other choices at the moment.  This makes
+the use of the control speculation much more conservative.
+The default is 'disable'.
+.IP "\fB\-mno\-sched\-count\-spec\-in\-critical\-path\fR" 4
+.IX Item "-mno-sched-count-spec-in-critical-path"
+.PD 0
+.IP "\fB\-msched\-count\-spec\-in\-critical\-path\fR" 4
+.IX Item "-msched-count-spec-in-critical-path"
+.PD
+If enabled, speculative dependencies are considered during
+computation of the instructions priorities.  This makes the use of the
+speculation a bit more conservative.
+The default is 'disable'.
+.IP "\fB\-msched\-spec\-ldc\fR" 4
+.IX Item "-msched-spec-ldc"
+Use a simple data speculation check.  This option is on by default.
+.IP "\fB\-msched\-control\-spec\-ldc\fR" 4
+.IX Item "-msched-control-spec-ldc"
+Use a simple check for control speculation.  This option is on by default.
+.IP "\fB\-msched\-stop\-bits\-after\-every\-cycle\fR" 4
+.IX Item "-msched-stop-bits-after-every-cycle"
+Place a stop bit after every cycle when scheduling.  This option is on
+by default.
+.IP "\fB\-msched\-fp\-mem\-deps\-zero\-cost\fR" 4
+.IX Item "-msched-fp-mem-deps-zero-cost"
+Assume that floating-point stores and loads are not likely to cause a conflict
+when placed into the same instruction group.  This option is disabled by
+default.
+.IP "\fB\-msel\-sched\-dont\-check\-control\-spec\fR" 4
+.IX Item "-msel-sched-dont-check-control-spec"
+Generate checks for control speculation in selective scheduling.
+This flag is disabled by default.
+.IP "\fB\-msched\-max\-memory\-insns=\fR\fImax-insns\fR" 4
+.IX Item "-msched-max-memory-insns=max-insns"
+Limit on the number of memory insns per instruction group, giving lower
+priority to subsequent memory insns attempting to schedule in the same
+instruction group. Frequently useful to prevent cache bank conflicts.
+The default value is 1.
+.IP "\fB\-msched\-max\-memory\-insns\-hard\-limit\fR" 4
+.IX Item "-msched-max-memory-insns-hard-limit"
+Makes the limit specified by \fBmsched-max-memory-insns\fR a hard limit,
+disallowing more than that number in an instruction group.
+Otherwise, the limit is \*(L"soft\*(R", meaning that non-memory operations
+are preferred when the limit is reached, but memory operations may still
+be scheduled.
+.PP
+\fI\s-1LM32\s0 Options\fR
+.IX Subsection "LM32 Options"
+.PP
+These \fB\-m\fR options are defined for the LatticeMico32 architecture:
+.IP "\fB\-mbarrel\-shift\-enabled\fR" 4
+.IX Item "-mbarrel-shift-enabled"
+Enable barrel-shift instructions.
+.IP "\fB\-mdivide\-enabled\fR" 4
+.IX Item "-mdivide-enabled"
+Enable divide and modulus instructions.
+.IP "\fB\-mmultiply\-enabled\fR" 4
+.IX Item "-mmultiply-enabled"
+Enable multiply instructions.
+.IP "\fB\-msign\-extend\-enabled\fR" 4
+.IX Item "-msign-extend-enabled"
+Enable sign extend instructions.
+.IP "\fB\-muser\-enabled\fR" 4
+.IX Item "-muser-enabled"
+Enable user-defined instructions.
+.PP
+\fIM32C Options\fR
+.IX Subsection "M32C Options"
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Select the \s-1CPU\s0 for which code is generated.  \fIname\fR may be one of
+\&\fBr8c\fR for the R8C/Tiny series, \fBm16c\fR for the M16C (up to
+/60) series, \fBm32cm\fR for the M16C/80 series, or \fBm32c\fR for
+the M32C/80 series.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Specifies that the program will be run on the simulator.  This causes
+an alternate runtime library to be linked in which supports, for
+example, file I/O.  You must not use this option when generating
+programs that will run on real hardware; you must provide your own
+runtime library for whatever I/O functions are needed.
+.IP "\fB\-memregs=\fR\fInumber\fR" 4
+.IX Item "-memregs=number"
+Specifies the number of memory-based pseudo-registers \s-1GCC\s0 uses
+during code generation.  These pseudo-registers are used like real
+registers, so there is a tradeoff between \s-1GCC\s0's ability to fit the
+code into available registers, and the performance penalty of using
+memory instead of registers.  Note that all modules in a program must
+be compiled with the same value for this option.  Because of that, you
+must not use this option with \s-1GCC\s0's default runtime libraries.
+.PP
+\fIM32R/D Options\fR
+.IX Subsection "M32R/D Options"
+.PP
+These \fB\-m\fR options are defined for Renesas M32R/D architectures:
+.IP "\fB\-m32r2\fR" 4
+.IX Item "-m32r2"
+Generate code for the M32R/2.
+.IP "\fB\-m32rx\fR" 4
+.IX Item "-m32rx"
+Generate code for the M32R/X.
+.IP "\fB\-m32r\fR" 4
+.IX Item "-m32r"
+Generate code for the M32R.  This is the default.
+.IP "\fB\-mmodel=small\fR" 4
+.IX Item "-mmodel=small"
+Assume all objects live in the lower 16MB of memory (so that their addresses
+can be loaded with the \f(CW\*(C`ld24\*(C'\fR instruction), and assume all subroutines
+are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
+This is the default.
+.Sp
+The addressability of a particular object can be set with the
+\&\f(CW\*(C`model\*(C'\fR attribute.
+.IP "\fB\-mmodel=medium\fR" 4
+.IX Item "-mmodel=medium"
+Assume objects may be anywhere in the 32\-bit address space (the compiler
+generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
+assume all subroutines are reachable with the \f(CW\*(C`bl\*(C'\fR instruction.
+.IP "\fB\-mmodel=large\fR" 4
+.IX Item "-mmodel=large"
+Assume objects may be anywhere in the 32\-bit address space (the compiler
+generates \f(CW\*(C`seth/add3\*(C'\fR instructions to load their addresses), and
+assume subroutines may not be reachable with the \f(CW\*(C`bl\*(C'\fR instruction
+(the compiler generates the much slower \f(CW\*(C`seth/add3/jl\*(C'\fR
+instruction sequence).
+.IP "\fB\-msdata=none\fR" 4
+.IX Item "-msdata=none"
+Disable use of the small data area.  Variables are put into
+one of \fB.data\fR, \fB.bss\fR, or \fB.rodata\fR (unless the
+\&\f(CW\*(C`section\*(C'\fR attribute has been specified).
+This is the default.
+.Sp
+The small data area consists of sections \fB.sdata\fR and \fB.sbss\fR.
+Objects may be explicitly put in the small data area with the
+\&\f(CW\*(C`section\*(C'\fR attribute using one of these sections.
+.IP "\fB\-msdata=sdata\fR" 4
+.IX Item "-msdata=sdata"
+Put small global and static data in the small data area, but do not
+generate special code to reference them.
+.IP "\fB\-msdata=use\fR" 4
+.IX Item "-msdata=use"
+Put small global and static data in the small data area, and generate
+special instructions to reference them.
+.IP "\fB\-G\fR \fInum\fR" 4
+.IX Item "-G num"
+Put global and static objects less than or equal to \fInum\fR bytes
+into the small data or \s-1BSS\s0 sections instead of the normal data or \s-1BSS\s0
+sections.  The default value of \fInum\fR is 8.
+The \fB\-msdata\fR option must be set to one of \fBsdata\fR or \fBuse\fR
+for this option to have any effect.
+.Sp
+All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
+Compiling with different values of \fInum\fR may or may not work; if it
+doesn't the linker gives an error message\-\-\-incorrect code is not
+generated.
+.IP "\fB\-mdebug\fR" 4
+.IX Item "-mdebug"
+Makes the M32R\-specific code in the compiler display some statistics
+that might help in debugging programs.
+.IP "\fB\-malign\-loops\fR" 4
+.IX Item "-malign-loops"
+Align all loops to a 32\-byte boundary.
+.IP "\fB\-mno\-align\-loops\fR" 4
+.IX Item "-mno-align-loops"
+Do not enforce a 32\-byte alignment for loops.  This is the default.
+.IP "\fB\-missue\-rate=\fR\fInumber\fR" 4
+.IX Item "-missue-rate=number"
+Issue \fInumber\fR instructions per cycle.  \fInumber\fR can only be 1
+or 2.
+.IP "\fB\-mbranch\-cost=\fR\fInumber\fR" 4
+.IX Item "-mbranch-cost=number"
+\&\fInumber\fR can only be 1 or 2.  If it is 1 then branches are
+preferred over conditional code, if it is 2, then the opposite applies.
+.IP "\fB\-mflush\-trap=\fR\fInumber\fR" 4
+.IX Item "-mflush-trap=number"
+Specifies the trap number to use to flush the cache.  The default is
+12.  Valid numbers are between 0 and 15 inclusive.
+.IP "\fB\-mno\-flush\-trap\fR" 4
+.IX Item "-mno-flush-trap"
+Specifies that the cache cannot be flushed by using a trap.
+.IP "\fB\-mflush\-func=\fR\fIname\fR" 4
+.IX Item "-mflush-func=name"
+Specifies the name of the operating system function to call to flush
+the cache.  The default is \fI_flush_cache\fR, but a function call
+is only used if a trap is not available.
+.IP "\fB\-mno\-flush\-func\fR" 4
+.IX Item "-mno-flush-func"
+Indicates that there is no \s-1OS\s0 function for flushing the cache.
+.PP
+\fIM680x0 Options\fR
+.IX Subsection "M680x0 Options"
+.PP
+These are the \fB\-m\fR options defined for M680x0 and ColdFire processors.
+The default settings depend on which architecture was selected when
+the compiler was configured; the defaults for the most common choices
+are given below.
+.IP "\fB\-march=\fR\fIarch\fR" 4
+.IX Item "-march=arch"
+Generate code for a specific M680x0 or ColdFire instruction set
+architecture.  Permissible values of \fIarch\fR for M680x0
+architectures are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
+\&\fB68030\fR, \fB68040\fR, \fB68060\fR and \fBcpu32\fR.  ColdFire
+architectures are selected according to Freescale's \s-1ISA\s0 classification
+and the permissible values are: \fBisaa\fR, \fBisaaplus\fR,
+\&\fBisab\fR and \fBisac\fR.
+.Sp
+\&\s-1GCC\s0 defines a macro \fB_\|_mcf\fR\fIarch\fR\fB_\|_\fR whenever it is generating
+code for a ColdFire target.  The \fIarch\fR in this macro is one of the
+\&\fB\-march\fR arguments given above.
+.Sp
+When used together, \fB\-march\fR and \fB\-mtune\fR select code
+that runs on a family of similar processors but that is optimized
+for a particular microarchitecture.
+.IP "\fB\-mcpu=\fR\fIcpu\fR" 4
+.IX Item "-mcpu=cpu"
+Generate code for a specific M680x0 or ColdFire processor.
+The M680x0 \fIcpu\fRs are: \fB68000\fR, \fB68010\fR, \fB68020\fR,
+\&\fB68030\fR, \fB68040\fR, \fB68060\fR, \fB68302\fR, \fB68332\fR
+and \fBcpu32\fR.  The ColdFire \fIcpu\fRs are given by the table
+below, which also classifies the CPUs into families:
+.RS 4
+.IP "Family : \fB\-mcpu\fR arguments" 4
+.IX Item "Family : -mcpu arguments"
+.PD 0
+.IP "\fB51\fR : \fB51\fR \fB51ac\fR \fB51ag\fR \fB51cn\fR \fB51em\fR \fB51je\fR \fB51jf\fR \fB51jg\fR \fB51jm\fR \fB51mm\fR \fB51qe\fR \fB51qm\fR" 4
+.IX Item "51 : 51 51ac 51ag 51cn 51em 51je 51jf 51jg 51jm 51mm 51qe 51qm"
+.IP "\fB5206\fR : \fB5202\fR \fB5204\fR \fB5206\fR" 4
+.IX Item "5206 : 5202 5204 5206"
+.IP "\fB5206e\fR : \fB5206e\fR" 4
+.IX Item "5206e : 5206e"
+.IP "\fB5208\fR : \fB5207\fR \fB5208\fR" 4
+.IX Item "5208 : 5207 5208"
+.IP "\fB5211a\fR : \fB5210a\fR \fB5211a\fR" 4
+.IX Item "5211a : 5210a 5211a"
+.IP "\fB5213\fR : \fB5211\fR \fB5212\fR \fB5213\fR" 4
+.IX Item "5213 : 5211 5212 5213"
+.IP "\fB5216\fR : \fB5214\fR \fB5216\fR" 4
+.IX Item "5216 : 5214 5216"
+.IP "\fB52235\fR : \fB52230\fR \fB52231\fR \fB52232\fR \fB52233\fR \fB52234\fR \fB52235\fR" 4
+.IX Item "52235 : 52230 52231 52232 52233 52234 52235"
+.IP "\fB5225\fR : \fB5224\fR \fB5225\fR" 4
+.IX Item "5225 : 5224 5225"
+.IP "\fB52259\fR : \fB52252\fR \fB52254\fR \fB52255\fR \fB52256\fR \fB52258\fR \fB52259\fR" 4
+.IX Item "52259 : 52252 52254 52255 52256 52258 52259"
+.IP "\fB5235\fR : \fB5232\fR \fB5233\fR \fB5234\fR \fB5235\fR \fB523x\fR" 4
+.IX Item "5235 : 5232 5233 5234 5235 523x"
+.IP "\fB5249\fR : \fB5249\fR" 4
+.IX Item "5249 : 5249"
+.IP "\fB5250\fR : \fB5250\fR" 4
+.IX Item "5250 : 5250"
+.IP "\fB5271\fR : \fB5270\fR \fB5271\fR" 4
+.IX Item "5271 : 5270 5271"
+.IP "\fB5272\fR : \fB5272\fR" 4
+.IX Item "5272 : 5272"
+.IP "\fB5275\fR : \fB5274\fR \fB5275\fR" 4
+.IX Item "5275 : 5274 5275"
+.IP "\fB5282\fR : \fB5280\fR \fB5281\fR \fB5282\fR \fB528x\fR" 4
+.IX Item "5282 : 5280 5281 5282 528x"
+.IP "\fB53017\fR : \fB53011\fR \fB53012\fR \fB53013\fR \fB53014\fR \fB53015\fR \fB53016\fR \fB53017\fR" 4
+.IX Item "53017 : 53011 53012 53013 53014 53015 53016 53017"
+.IP "\fB5307\fR : \fB5307\fR" 4
+.IX Item "5307 : 5307"
+.IP "\fB5329\fR : \fB5327\fR \fB5328\fR \fB5329\fR \fB532x\fR" 4
+.IX Item "5329 : 5327 5328 5329 532x"
+.IP "\fB5373\fR : \fB5372\fR \fB5373\fR \fB537x\fR" 4
+.IX Item "5373 : 5372 5373 537x"
+.IP "\fB5407\fR : \fB5407\fR" 4
+.IX Item "5407 : 5407"
+.IP "\fB5475\fR : \fB5470\fR \fB5471\fR \fB5472\fR \fB5473\fR \fB5474\fR \fB5475\fR \fB547x\fR \fB5480\fR \fB5481\fR \fB5482\fR \fB5483\fR \fB5484\fR \fB5485\fR" 4
+.IX Item "5475 : 5470 5471 5472 5473 5474 5475 547x 5480 5481 5482 5483 5484 5485"
+.RE
+.RS 4
+.PD
+.Sp
+\&\fB\-mcpu=\fR\fIcpu\fR overrides \fB\-march=\fR\fIarch\fR if
+\&\fIarch\fR is compatible with \fIcpu\fR.  Other combinations of
+\&\fB\-mcpu\fR and \fB\-march\fR are rejected.
+.Sp
+\&\s-1GCC\s0 defines the macro \fB_\|_mcf_cpu_\fR\fIcpu\fR when ColdFire target
+\&\fIcpu\fR is selected.  It also defines \fB_\|_mcf_family_\fR\fIfamily\fR,
+where the value of \fIfamily\fR is given by the table above.
+.RE
+.IP "\fB\-mtune=\fR\fItune\fR" 4
+.IX Item "-mtune=tune"
+Tune the code for a particular microarchitecture within the
+constraints set by \fB\-march\fR and \fB\-mcpu\fR.
+The M680x0 microarchitectures are: \fB68000\fR, \fB68010\fR,
+\&\fB68020\fR, \fB68030\fR, \fB68040\fR, \fB68060\fR
+and \fBcpu32\fR.  The ColdFire microarchitectures
+are: \fBcfv1\fR, \fBcfv2\fR, \fBcfv3\fR, \fBcfv4\fR and \fBcfv4e\fR.
+.Sp
+You can also use \fB\-mtune=68020\-40\fR for code that needs
+to run relatively well on 68020, 68030 and 68040 targets.
+\&\fB\-mtune=68020\-60\fR is similar but includes 68060 targets
+as well.  These two options select the same tuning decisions as
+\&\fB\-m68020\-40\fR and \fB\-m68020\-60\fR respectively.
+.Sp
+\&\s-1GCC\s0 defines the macros \fB_\|_mc\fR\fIarch\fR and \fB_\|_mc\fR\fIarch\fR\fB_\|_\fR
+when tuning for 680x0 architecture \fIarch\fR.  It also defines
+\&\fBmc\fR\fIarch\fR unless either \fB\-ansi\fR or a non-GNU \fB\-std\fR
+option is used.  If \s-1GCC\s0 is tuning for a range of architectures,
+as selected by \fB\-mtune=68020\-40\fR or \fB\-mtune=68020\-60\fR,
+it defines the macros for every architecture in the range.
+.Sp
+\&\s-1GCC\s0 also defines the macro \fB_\|_m\fR\fIuarch\fR\fB_\|_\fR when tuning for
+ColdFire microarchitecture \fIuarch\fR, where \fIuarch\fR is one
+of the arguments given above.
+.IP "\fB\-m68000\fR" 4
+.IX Item "-m68000"
+.PD 0
+.IP "\fB\-mc68000\fR" 4
+.IX Item "-mc68000"
+.PD
+Generate output for a 68000.  This is the default
+when the compiler is configured for 68000\-based systems.
+It is equivalent to \fB\-march=68000\fR.
+.Sp
+Use this option for microcontrollers with a 68000 or \s-1EC000\s0 core,
+including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
+.IP "\fB\-m68010\fR" 4
+.IX Item "-m68010"
+Generate output for a 68010.  This is the default
+when the compiler is configured for 68010\-based systems.
+It is equivalent to \fB\-march=68010\fR.
+.IP "\fB\-m68020\fR" 4
+.IX Item "-m68020"
+.PD 0
+.IP "\fB\-mc68020\fR" 4
+.IX Item "-mc68020"
+.PD
+Generate output for a 68020.  This is the default
+when the compiler is configured for 68020\-based systems.
+It is equivalent to \fB\-march=68020\fR.
+.IP "\fB\-m68030\fR" 4
+.IX Item "-m68030"
+Generate output for a 68030.  This is the default when the compiler is
+configured for 68030\-based systems.  It is equivalent to
+\&\fB\-march=68030\fR.
+.IP "\fB\-m68040\fR" 4
+.IX Item "-m68040"
+Generate output for a 68040.  This is the default when the compiler is
+configured for 68040\-based systems.  It is equivalent to
+\&\fB\-march=68040\fR.
+.Sp
+This option inhibits the use of 68881/68882 instructions that have to be
+emulated by software on the 68040.  Use this option if your 68040 does not
+have code to emulate those instructions.
+.IP "\fB\-m68060\fR" 4
+.IX Item "-m68060"
+Generate output for a 68060.  This is the default when the compiler is
+configured for 68060\-based systems.  It is equivalent to
+\&\fB\-march=68060\fR.
+.Sp
+This option inhibits the use of 68020 and 68881/68882 instructions that
+have to be emulated by software on the 68060.  Use this option if your 68060
+does not have code to emulate those instructions.
+.IP "\fB\-mcpu32\fR" 4
+.IX Item "-mcpu32"
+Generate output for a \s-1CPU32. \s0 This is the default
+when the compiler is configured for CPU32\-based systems.
+It is equivalent to \fB\-march=cpu32\fR.
+.Sp
+Use this option for microcontrollers with a
+\&\s-1CPU32\s0 or \s-1CPU32+\s0 core, including the 68330, 68331, 68332, 68333, 68334,
+68336, 68340, 68341, 68349 and 68360.
+.IP "\fB\-m5200\fR" 4
+.IX Item "-m5200"
+Generate output for a 520X ColdFire \s-1CPU. \s0 This is the default
+when the compiler is configured for 520X\-based systems.
+It is equivalent to \fB\-mcpu=5206\fR, and is now deprecated
+in favor of that option.
+.Sp
+Use this option for microcontroller with a 5200 core, including
+the \s-1MCF5202, MCF5203, MCF5204\s0 and \s-1MCF5206.\s0
+.IP "\fB\-m5206e\fR" 4
+.IX Item "-m5206e"
+Generate output for a 5206e ColdFire \s-1CPU. \s0 The option is now
+deprecated in favor of the equivalent \fB\-mcpu=5206e\fR.
+.IP "\fB\-m528x\fR" 4
+.IX Item "-m528x"
+Generate output for a member of the ColdFire 528X family.
+The option is now deprecated in favor of the equivalent
+\&\fB\-mcpu=528x\fR.
+.IP "\fB\-m5307\fR" 4
+.IX Item "-m5307"
+Generate output for a ColdFire 5307 \s-1CPU. \s0 The option is now deprecated
+in favor of the equivalent \fB\-mcpu=5307\fR.
+.IP "\fB\-m5407\fR" 4
+.IX Item "-m5407"
+Generate output for a ColdFire 5407 \s-1CPU. \s0 The option is now deprecated
+in favor of the equivalent \fB\-mcpu=5407\fR.
+.IP "\fB\-mcfv4e\fR" 4
+.IX Item "-mcfv4e"
+Generate output for a ColdFire V4e family \s-1CPU \s0(e.g. 547x/548x).
+This includes use of hardware floating-point instructions.
+The option is equivalent to \fB\-mcpu=547x\fR, and is now
+deprecated in favor of that option.
+.IP "\fB\-m68020\-40\fR" 4
+.IX Item "-m68020-40"
+Generate output for a 68040, without using any of the new instructions.
+This results in code that can run relatively efficiently on either a
+68020/68881 or a 68030 or a 68040.  The generated code does use the
+68881 instructions that are emulated on the 68040.
+.Sp
+The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-40\fR.
+.IP "\fB\-m68020\-60\fR" 4
+.IX Item "-m68020-60"
+Generate output for a 68060, without using any of the new instructions.
+This results in code that can run relatively efficiently on either a
+68020/68881 or a 68030 or a 68040.  The generated code does use the
+68881 instructions that are emulated on the 68060.
+.Sp
+The option is equivalent to \fB\-march=68020\fR \fB\-mtune=68020\-60\fR.
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD 0
+.IP "\fB\-m68881\fR" 4
+.IX Item "-m68881"
+.PD
+Generate floating-point instructions.  This is the default for 68020
+and above, and for ColdFire devices that have an \s-1FPU. \s0 It defines the
+macro \fB_\|_HAVE_68881_\|_\fR on M680x0 targets and \fB_\|_mcffpu_\|_\fR
+on ColdFire targets.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Do not generate floating-point instructions; use library calls instead.
+This is the default for 68000, 68010, and 68832 targets.  It is also
+the default for ColdFire devices that have no \s-1FPU.\s0
+.IP "\fB\-mdiv\fR" 4
+.IX Item "-mdiv"
+.PD 0
+.IP "\fB\-mno\-div\fR" 4
+.IX Item "-mno-div"
+.PD
+Generate (do not generate) ColdFire hardware divide and remainder
+instructions.  If \fB\-march\fR is used without \fB\-mcpu\fR,
+the default is \*(L"on\*(R" for ColdFire architectures and \*(L"off\*(R" for M680x0
+architectures.  Otherwise, the default is taken from the target \s-1CPU
+\&\s0(either the default \s-1CPU,\s0 or the one specified by \fB\-mcpu\fR).  For
+example, the default is \*(L"off\*(R" for \fB\-mcpu=5206\fR and \*(L"on\*(R" for
+\&\fB\-mcpu=5206e\fR.
+.Sp
+\&\s-1GCC\s0 defines the macro \fB_\|_mcfhwdiv_\|_\fR when this option is enabled.
+.IP "\fB\-mshort\fR" 4
+.IX Item "-mshort"
+Consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide, like \f(CW\*(C`short int\*(C'\fR.
+Additionally, parameters passed on the stack are also aligned to a
+16\-bit boundary even on targets whose \s-1API\s0 mandates promotion to 32\-bit.
+.IP "\fB\-mno\-short\fR" 4
+.IX Item "-mno-short"
+Do not consider type \f(CW\*(C`int\*(C'\fR to be 16 bits wide.  This is the default.
+.IP "\fB\-mnobitfield\fR" 4
+.IX Item "-mnobitfield"
+.PD 0
+.IP "\fB\-mno\-bitfield\fR" 4
+.IX Item "-mno-bitfield"
+.PD
+Do not use the bit-field instructions.  The \fB\-m68000\fR, \fB\-mcpu32\fR
+and \fB\-m5200\fR options imply \fB\-mnobitfield\fR.
+.IP "\fB\-mbitfield\fR" 4
+.IX Item "-mbitfield"
+Do use the bit-field instructions.  The \fB\-m68020\fR option implies
+\&\fB\-mbitfield\fR.  This is the default if you use a configuration
+designed for a 68020.
+.IP "\fB\-mrtd\fR" 4
+.IX Item "-mrtd"
+Use a different function-calling convention, in which functions
+that take a fixed number of arguments return with the \f(CW\*(C`rtd\*(C'\fR
+instruction, which pops their arguments while returning.  This
+saves one instruction in the caller since there is no need to pop
+the arguments there.
+.Sp
+This calling convention is incompatible with the one normally
+used on Unix, so you cannot use it if you need to call libraries
+compiled with the Unix compiler.
+.Sp
+Also, you must provide function prototypes for all functions that
+take variable numbers of arguments (including \f(CW\*(C`printf\*(C'\fR);
+otherwise incorrect code is generated for calls to those
+functions.
+.Sp
+In addition, seriously incorrect code results if you call a
+function with too many arguments.  (Normally, extra arguments are
+harmlessly ignored.)
+.Sp
+The \f(CW\*(C`rtd\*(C'\fR instruction is supported by the 68010, 68020, 68030,
+68040, 68060 and \s-1CPU32\s0 processors, but not by the 68000 or 5200.
+.IP "\fB\-mno\-rtd\fR" 4
+.IX Item "-mno-rtd"
+Do not use the calling conventions selected by \fB\-mrtd\fR.
+This is the default.
+.IP "\fB\-malign\-int\fR" 4
+.IX Item "-malign-int"
+.PD 0
+.IP "\fB\-mno\-align\-int\fR" 4
+.IX Item "-mno-align-int"
+.PD
+Control whether \s-1GCC\s0 aligns \f(CW\*(C`int\*(C'\fR, \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`long long\*(C'\fR,
+\&\f(CW\*(C`float\*(C'\fR, \f(CW\*(C`double\*(C'\fR, and \f(CW\*(C`long double\*(C'\fR variables on a 32\-bit
+boundary (\fB\-malign\-int\fR) or a 16\-bit boundary (\fB\-mno\-align\-int\fR).
+Aligning variables on 32\-bit boundaries produces code that runs somewhat
+faster on processors with 32\-bit busses at the expense of more memory.
+.Sp
+\&\fBWarning:\fR if you use the \fB\-malign\-int\fR switch, \s-1GCC\s0
+aligns structures containing the above types differently than
+most published application binary interface specifications for the m68k.
+.IP "\fB\-mpcrel\fR" 4
+.IX Item "-mpcrel"
+Use the pc-relative addressing mode of the 68000 directly, instead of
+using a global offset table.  At present, this option implies \fB\-fpic\fR,
+allowing at most a 16\-bit offset for pc-relative addressing.  \fB\-fPIC\fR is
+not presently supported with \fB\-mpcrel\fR, though this could be supported for
+68020 and higher processors.
+.IP "\fB\-mno\-strict\-align\fR" 4
+.IX Item "-mno-strict-align"
+.PD 0
+.IP "\fB\-mstrict\-align\fR" 4
+.IX Item "-mstrict-align"
+.PD
+Do not (do) assume that unaligned memory references are handled by
+the system.
+.IP "\fB\-msep\-data\fR" 4
+.IX Item "-msep-data"
+Generate code that allows the data segment to be located in a different
+area of memory from the text segment.  This allows for execute-in-place in
+an environment without virtual memory management.  This option implies
+\&\fB\-fPIC\fR.
+.IP "\fB\-mno\-sep\-data\fR" 4
+.IX Item "-mno-sep-data"
+Generate code that assumes that the data segment follows the text segment.
+This is the default.
+.IP "\fB\-mid\-shared\-library\fR" 4
+.IX Item "-mid-shared-library"
+Generate code that supports shared libraries via the library \s-1ID\s0 method.
+This allows for execute-in-place and shared libraries in an environment
+without virtual memory management.  This option implies \fB\-fPIC\fR.
+.IP "\fB\-mno\-id\-shared\-library\fR" 4
+.IX Item "-mno-id-shared-library"
+Generate code that doesn't assume ID-based shared libraries are being used.
+This is the default.
+.IP "\fB\-mshared\-library\-id=n\fR" 4
+.IX Item "-mshared-library-id=n"
+Specifies the identification number of the ID-based shared library being
+compiled.  Specifying a value of 0 generates more compact code; specifying
+other values forces the allocation of that number to the current
+library, but is no more space\- or time-efficient than omitting this option.
+.IP "\fB\-mxgot\fR" 4
+.IX Item "-mxgot"
+.PD 0
+.IP "\fB\-mno\-xgot\fR" 4
+.IX Item "-mno-xgot"
+.PD
+When generating position-independent code for ColdFire, generate code
+that works if the \s-1GOT\s0 has more than 8192 entries.  This code is
+larger and slower than code generated without this option.  On M680x0
+processors, this option is not needed; \fB\-fPIC\fR suffices.
+.Sp
+\&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT.\s0
+While this is relatively efficient, it only works if the \s-1GOT\s0
+is smaller than about 64k.  Anything larger causes the linker
+to report an error such as:
+.Sp
+.Vb 1
+\&        relocation truncated to fit: R_68K_GOT16O foobar
+.Ve
+.Sp
+If this happens, you should recompile your code with \fB\-mxgot\fR.
+It should then work with very large GOTs.  However, code generated with
+\&\fB\-mxgot\fR is less efficient, since it takes 4 instructions to fetch
+the value of a global symbol.
+.Sp
+Note that some linkers, including newer versions of the \s-1GNU\s0 linker,
+can create multiple GOTs and sort \s-1GOT\s0 entries.  If you have such a linker,
+you should only need to use \fB\-mxgot\fR when compiling a single
+object file that accesses more than 8192 \s-1GOT\s0 entries.  Very few do.
+.Sp
+These options have no effect unless \s-1GCC\s0 is generating
+position-independent code.
+.PP
+\fIMCore Options\fR
+.IX Subsection "MCore Options"
+.PP
+These are the \fB\-m\fR options defined for the Motorola M*Core
+processors.
+.IP "\fB\-mhardlit\fR" 4
+.IX Item "-mhardlit"
+.PD 0
+.IP "\fB\-mno\-hardlit\fR" 4
+.IX Item "-mno-hardlit"
+.PD
+Inline constants into the code stream if it can be done in two
+instructions or less.
+.IP "\fB\-mdiv\fR" 4
+.IX Item "-mdiv"
+.PD 0
+.IP "\fB\-mno\-div\fR" 4
+.IX Item "-mno-div"
+.PD
+Use the divide instruction.  (Enabled by default).
+.IP "\fB\-mrelax\-immediate\fR" 4
+.IX Item "-mrelax-immediate"
+.PD 0
+.IP "\fB\-mno\-relax\-immediate\fR" 4
+.IX Item "-mno-relax-immediate"
+.PD
+Allow arbitrary-sized immediates in bit operations.
+.IP "\fB\-mwide\-bitfields\fR" 4
+.IX Item "-mwide-bitfields"
+.PD 0
+.IP "\fB\-mno\-wide\-bitfields\fR" 4
+.IX Item "-mno-wide-bitfields"
+.PD
+Always treat bit-fields as \f(CW\*(C`int\*(C'\fR\-sized.
+.IP "\fB\-m4byte\-functions\fR" 4
+.IX Item "-m4byte-functions"
+.PD 0
+.IP "\fB\-mno\-4byte\-functions\fR" 4
+.IX Item "-mno-4byte-functions"
+.PD
+Force all functions to be aligned to a 4\-byte boundary.
+.IP "\fB\-mcallgraph\-data\fR" 4
+.IX Item "-mcallgraph-data"
+.PD 0
+.IP "\fB\-mno\-callgraph\-data\fR" 4
+.IX Item "-mno-callgraph-data"
+.PD
+Emit callgraph information.
+.IP "\fB\-mslow\-bytes\fR" 4
+.IX Item "-mslow-bytes"
+.PD 0
+.IP "\fB\-mno\-slow\-bytes\fR" 4
+.IX Item "-mno-slow-bytes"
+.PD
+Prefer word access when reading byte quantities.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+.PD 0
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+.PD
+Generate code for a little-endian target.
+.IP "\fB\-m210\fR" 4
+.IX Item "-m210"
+.PD 0
+.IP "\fB\-m340\fR" 4
+.IX Item "-m340"
+.PD
+Generate code for the 210 processor.
+.IP "\fB\-mno\-lsim\fR" 4
+.IX Item "-mno-lsim"
+Assume that runtime support has been provided and so omit the
+simulator library (\fIlibsim.a)\fR from the linker command line.
+.IP "\fB\-mstack\-increment=\fR\fIsize\fR" 4
+.IX Item "-mstack-increment=size"
+Set the maximum amount for a single stack increment operation.  Large
+values can increase the speed of programs that contain functions
+that need a large amount of stack space, but they can also trigger a
+segmentation fault if the stack is extended too much.  The default
+value is 0x1000.
+.PP
+\fIMeP Options\fR
+.IX Subsection "MeP Options"
+.IP "\fB\-mabsdiff\fR" 4
+.IX Item "-mabsdiff"
+Enables the \f(CW\*(C`abs\*(C'\fR instruction, which is the absolute difference
+between two registers.
+.IP "\fB\-mall\-opts\fR" 4
+.IX Item "-mall-opts"
+Enables all the optional instructions\-\-\-average, multiply, divide, bit
+operations, leading zero, absolute difference, min/max, clip, and
+saturation.
+.IP "\fB\-maverage\fR" 4
+.IX Item "-maverage"
+Enables the \f(CW\*(C`ave\*(C'\fR instruction, which computes the average of two
+registers.
+.IP "\fB\-mbased=\fR\fIn\fR" 4
+.IX Item "-mbased=n"
+Variables of size \fIn\fR bytes or smaller are placed in the
+\&\f(CW\*(C`.based\*(C'\fR section by default.  Based variables use the \f(CW$tp\fR
+register as a base register, and there is a 128\-byte limit to the
+\&\f(CW\*(C`.based\*(C'\fR section.
+.IP "\fB\-mbitops\fR" 4
+.IX Item "-mbitops"
+Enables the bit operation instructions\-\-\-bit test (\f(CW\*(C`btstm\*(C'\fR), set
+(\f(CW\*(C`bsetm\*(C'\fR), clear (\f(CW\*(C`bclrm\*(C'\fR), invert (\f(CW\*(C`bnotm\*(C'\fR), and
+test-and-set (\f(CW\*(C`tas\*(C'\fR).
+.IP "\fB\-mc=\fR\fIname\fR" 4
+.IX Item "-mc=name"
+Selects which section constant data is placed in.  \fIname\fR may
+be \f(CW\*(C`tiny\*(C'\fR, \f(CW\*(C`near\*(C'\fR, or \f(CW\*(C`far\*(C'\fR.
+.IP "\fB\-mclip\fR" 4
+.IX Item "-mclip"
+Enables the \f(CW\*(C`clip\*(C'\fR instruction.  Note that \f(CW\*(C`\-mclip\*(C'\fR is not
+useful unless you also provide \f(CW\*(C`\-mminmax\*(C'\fR.
+.IP "\fB\-mconfig=\fR\fIname\fR" 4
+.IX Item "-mconfig=name"
+Selects one of the built-in core configurations.  Each MeP chip has
+one or more modules in it; each module has a core \s-1CPU\s0 and a variety of
+coprocessors, optional instructions, and peripherals.  The
+\&\f(CW\*(C`MeP\-Integrator\*(C'\fR tool, not part of \s-1GCC,\s0 provides these
+configurations through this option; using this option is the same as
+using all the corresponding command-line options.  The default
+configuration is \f(CW\*(C`default\*(C'\fR.
+.IP "\fB\-mcop\fR" 4
+.IX Item "-mcop"
+Enables the coprocessor instructions.  By default, this is a 32\-bit
+coprocessor.  Note that the coprocessor is normally enabled via the
+\&\f(CW\*(C`\-mconfig=\*(C'\fR option.
+.IP "\fB\-mcop32\fR" 4
+.IX Item "-mcop32"
+Enables the 32\-bit coprocessor's instructions.
+.IP "\fB\-mcop64\fR" 4
+.IX Item "-mcop64"
+Enables the 64\-bit coprocessor's instructions.
+.IP "\fB\-mivc2\fR" 4
+.IX Item "-mivc2"
+Enables \s-1IVC2\s0 scheduling.  \s-1IVC2\s0 is a 64\-bit \s-1VLIW\s0 coprocessor.
+.IP "\fB\-mdc\fR" 4
+.IX Item "-mdc"
+Causes constant variables to be placed in the \f(CW\*(C`.near\*(C'\fR section.
+.IP "\fB\-mdiv\fR" 4
+.IX Item "-mdiv"
+Enables the \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions.
+.IP "\fB\-meb\fR" 4
+.IX Item "-meb"
+Generate big-endian code.
+.IP "\fB\-mel\fR" 4
+.IX Item "-mel"
+Generate little-endian code.
+.IP "\fB\-mio\-volatile\fR" 4
+.IX Item "-mio-volatile"
+Tells the compiler that any variable marked with the \f(CW\*(C`io\*(C'\fR
+attribute is to be considered volatile.
+.IP "\fB\-ml\fR" 4
+.IX Item "-ml"
+Causes variables to be assigned to the \f(CW\*(C`.far\*(C'\fR section by default.
+.IP "\fB\-mleadz\fR" 4
+.IX Item "-mleadz"
+Enables the \f(CW\*(C`leadz\*(C'\fR (leading zero) instruction.
+.IP "\fB\-mm\fR" 4
+.IX Item "-mm"
+Causes variables to be assigned to the \f(CW\*(C`.near\*(C'\fR section by default.
+.IP "\fB\-mminmax\fR" 4
+.IX Item "-mminmax"
+Enables the \f(CW\*(C`min\*(C'\fR and \f(CW\*(C`max\*(C'\fR instructions.
+.IP "\fB\-mmult\fR" 4
+.IX Item "-mmult"
+Enables the multiplication and multiply-accumulate instructions.
+.IP "\fB\-mno\-opts\fR" 4
+.IX Item "-mno-opts"
+Disables all the optional instructions enabled by \f(CW\*(C`\-mall\-opts\*(C'\fR.
+.IP "\fB\-mrepeat\fR" 4
+.IX Item "-mrepeat"
+Enables the \f(CW\*(C`repeat\*(C'\fR and \f(CW\*(C`erepeat\*(C'\fR instructions, used for
+low-overhead looping.
+.IP "\fB\-ms\fR" 4
+.IX Item "-ms"
+Causes all variables to default to the \f(CW\*(C`.tiny\*(C'\fR section.  Note
+that there is a 65536\-byte limit to this section.  Accesses to these
+variables use the \f(CW%gp\fR base register.
+.IP "\fB\-msatur\fR" 4
+.IX Item "-msatur"
+Enables the saturation instructions.  Note that the compiler does not
+currently generate these itself, but this option is included for
+compatibility with other tools, like \f(CW\*(C`as\*(C'\fR.
+.IP "\fB\-msdram\fR" 4
+.IX Item "-msdram"
+Link the SDRAM-based runtime instead of the default ROM-based runtime.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Link the simulator run-time libraries.
+.IP "\fB\-msimnovec\fR" 4
+.IX Item "-msimnovec"
+Link the simulator runtime libraries, excluding built-in support
+for reset and exception vectors and tables.
+.IP "\fB\-mtf\fR" 4
+.IX Item "-mtf"
+Causes all functions to default to the \f(CW\*(C`.far\*(C'\fR section.  Without
+this option, functions default to the \f(CW\*(C`.near\*(C'\fR section.
+.IP "\fB\-mtiny=\fR\fIn\fR" 4
+.IX Item "-mtiny=n"
+Variables that are \fIn\fR bytes or smaller are allocated to the
+\&\f(CW\*(C`.tiny\*(C'\fR section.  These variables use the \f(CW$gp\fR base
+register.  The default for this option is 4, but note that there's a
+65536\-byte limit to the \f(CW\*(C`.tiny\*(C'\fR section.
+.PP
+\fIMicroBlaze Options\fR
+.IX Subsection "MicroBlaze Options"
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Use software emulation for floating point (default).
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+Use hardware floating-point instructions.
+.IP "\fB\-mmemcpy\fR" 4
+.IX Item "-mmemcpy"
+Do not optimize block moves, use \f(CW\*(C`memcpy\*(C'\fR.
+.IP "\fB\-mno\-clearbss\fR" 4
+.IX Item "-mno-clearbss"
+This option is deprecated.  Use \fB\-fno\-zero\-initialized\-in\-bss\fR instead.
+.IP "\fB\-mcpu=\fR\fIcpu-type\fR" 4
+.IX Item "-mcpu=cpu-type"
+Use features of, and schedule code for, the given \s-1CPU.\s0
+Supported values are in the format \fBv\fR\fIX\fR\fB.\fR\fI\s-1YY\s0\fR\fB.\fR\fIZ\fR,
+where \fIX\fR is a major version, \fI\s-1YY\s0\fR is the minor version, and
+\&\fIZ\fR is compatibility code.  Example values are \fBv3.00.a\fR,
+\&\fBv4.00.b\fR, \fBv5.00.a\fR, \fBv5.00.b\fR, \fBv5.00.b\fR, \fBv6.00.a\fR.
+.IP "\fB\-mxl\-soft\-mul\fR" 4
+.IX Item "-mxl-soft-mul"
+Use software multiply emulation (default).
+.IP "\fB\-mxl\-soft\-div\fR" 4
+.IX Item "-mxl-soft-div"
+Use software emulation for divides (default).
+.IP "\fB\-mxl\-barrel\-shift\fR" 4
+.IX Item "-mxl-barrel-shift"
+Use the hardware barrel shifter.
+.IP "\fB\-mxl\-pattern\-compare\fR" 4
+.IX Item "-mxl-pattern-compare"
+Use pattern compare instructions.
+.IP "\fB\-msmall\-divides\fR" 4
+.IX Item "-msmall-divides"
+Use table lookup optimization for small signed integer divisions.
+.IP "\fB\-mxl\-stack\-check\fR" 4
+.IX Item "-mxl-stack-check"
+This option is deprecated.  Use \fB\-fstack\-check\fR instead.
+.IP "\fB\-mxl\-gp\-opt\fR" 4
+.IX Item "-mxl-gp-opt"
+Use GP-relative \f(CW\*(C`.sdata\*(C'\fR/\f(CW\*(C`.sbss\*(C'\fR sections.
+.IP "\fB\-mxl\-multiply\-high\fR" 4
+.IX Item "-mxl-multiply-high"
+Use multiply high instructions for high part of 32x32 multiply.
+.IP "\fB\-mxl\-float\-convert\fR" 4
+.IX Item "-mxl-float-convert"
+Use hardware floating-point conversion instructions.
+.IP "\fB\-mxl\-float\-sqrt\fR" 4
+.IX Item "-mxl-float-sqrt"
+Use hardware floating-point square root instruction.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code for a big-endian target.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code for a little-endian target.
+.IP "\fB\-mxl\-reorder\fR" 4
+.IX Item "-mxl-reorder"
+Use reorder instructions (swap and byte reversed load/store).
+.IP "\fB\-mxl\-mode\-\fR\fIapp-model\fR" 4
+.IX Item "-mxl-mode-app-model"
+Select application model \fIapp-model\fR.  Valid models are
+.RS 4
+.IP "\fBexecutable\fR" 4
+.IX Item "executable"
+normal executable (default), uses startup code \fIcrt0.o\fR.
+.IP "\fBxmdstub\fR" 4
+.IX Item "xmdstub"
+for use with Xilinx Microprocessor Debugger (\s-1XMD\s0) based
+software intrusive debug agent called xmdstub. This uses startup file
+\&\fIcrt1.o\fR and sets the start address of the program to 0x800.
+.IP "\fBbootstrap\fR" 4
+.IX Item "bootstrap"
+for applications that are loaded using a bootloader.
+This model uses startup file \fIcrt2.o\fR which does not contain a processor
+reset vector handler. This is suitable for transferring control on a
+processor reset to the bootloader rather than the application.
+.IP "\fBnovectors\fR" 4
+.IX Item "novectors"
+for applications that do not require any of the
+MicroBlaze vectors. This option may be useful for applications running
+within a monitoring application. This model uses \fIcrt3.o\fR as a startup file.
+.RE
+.RS 4
+.Sp
+Option \fB\-xl\-mode\-\fR\fIapp-model\fR is a deprecated alias for
+\&\fB\-mxl\-mode\-\fR\fIapp-model\fR.
+.RE
+.PP
+\fI\s-1MIPS\s0 Options\fR
+.IX Subsection "MIPS Options"
+.IP "\fB\-EB\fR" 4
+.IX Item "-EB"
+Generate big-endian code.
+.IP "\fB\-EL\fR" 4
+.IX Item "-EL"
+Generate little-endian code.  This is the default for \fBmips*el\-*\-*\fR
+configurations.
+.IP "\fB\-march=\fR\fIarch\fR" 4
+.IX Item "-march=arch"
+Generate code that runs on \fIarch\fR, which can be the name of a
+generic \s-1MIPS ISA,\s0 or the name of a particular processor.
+The \s-1ISA\s0 names are:
+\&\fBmips1\fR, \fBmips2\fR, \fBmips3\fR, \fBmips4\fR,
+\&\fBmips32\fR, \fBmips32r2\fR, \fBmips64\fR and \fBmips64r2\fR.
+The processor names are:
+\&\fB4kc\fR, \fB4km\fR, \fB4kp\fR, \fB4ksc\fR,
+\&\fB4kec\fR, \fB4kem\fR, \fB4kep\fR, \fB4ksd\fR,
+\&\fB5kc\fR, \fB5kf\fR,
+\&\fB20kc\fR,
+\&\fB24kc\fR, \fB24kf2_1\fR, \fB24kf1_1\fR,
+\&\fB24kec\fR, \fB24kef2_1\fR, \fB24kef1_1\fR,
+\&\fB34kc\fR, \fB34kf2_1\fR, \fB34kf1_1\fR, \fB34kn\fR,
+\&\fB74kc\fR, \fB74kf2_1\fR, \fB74kf1_1\fR, \fB74kf3_2\fR,
+\&\fB1004kc\fR, \fB1004kf2_1\fR, \fB1004kf1_1\fR,
+\&\fBloongson2e\fR, \fBloongson2f\fR, \fBloongson3a\fR,
+\&\fBm4k\fR,
+\&\fBm14k\fR, \fBm14kc\fR, \fBm14ke\fR, \fBm14kec\fR,
+\&\fBocteon\fR, \fBocteon+\fR, \fBocteon2\fR,
+\&\fBorion\fR,
+\&\fBr2000\fR, \fBr3000\fR, \fBr3900\fR, \fBr4000\fR, \fBr4400\fR,
+\&\fBr4600\fR, \fBr4650\fR, \fBr4700\fR, \fBr6000\fR, \fBr8000\fR,
+\&\fBrm7000\fR, \fBrm9000\fR,
+\&\fBr10000\fR, \fBr12000\fR, \fBr14000\fR, \fBr16000\fR,
+\&\fBsb1\fR,
+\&\fBsr71000\fR,
+\&\fBvr4100\fR, \fBvr4111\fR, \fBvr4120\fR, \fBvr4130\fR, \fBvr4300\fR,
+\&\fBvr5000\fR, \fBvr5400\fR, \fBvr5500\fR,
+\&\fBxlr\fR and \fBxlp\fR.
+The special value \fBfrom-abi\fR selects the
+most compatible architecture for the selected \s-1ABI \s0(that is,
+\&\fBmips1\fR for 32\-bit ABIs and \fBmips3\fR for 64\-bit ABIs).
+.Sp
+The native Linux/GNU toolchain also supports the value \fBnative\fR,
+which selects the best architecture option for the host processor.
+\&\fB\-march=native\fR has no effect if \s-1GCC\s0 does not recognize
+the processor.
+.Sp
+In processor names, a final \fB000\fR can be abbreviated as \fBk\fR
+(for example, \fB\-march=r2k\fR).  Prefixes are optional, and
+\&\fBvr\fR may be written \fBr\fR.
+.Sp
+Names of the form \fIn\fR\fBf2_1\fR refer to processors with
+FPUs clocked at half the rate of the core, names of the form
+\&\fIn\fR\fBf1_1\fR refer to processors with FPUs clocked at the same
+rate as the core, and names of the form \fIn\fR\fBf3_2\fR refer to
+processors with FPUs clocked a ratio of 3:2 with respect to the core.
+For compatibility reasons, \fIn\fR\fBf\fR is accepted as a synonym
+for \fIn\fR\fBf2_1\fR while \fIn\fR\fBx\fR and \fIb\fR\fBfx\fR are
+accepted as synonyms for \fIn\fR\fBf1_1\fR.
+.Sp
+\&\s-1GCC\s0 defines two macros based on the value of this option.  The first
+is \fB_MIPS_ARCH\fR, which gives the name of target architecture, as
+a string.  The second has the form \fB_MIPS_ARCH_\fR\fIfoo\fR,
+where \fIfoo\fR is the capitalized value of \fB_MIPS_ARCH\fR.
+For example, \fB\-march=r2000\fR sets \fB_MIPS_ARCH\fR
+to \fB\*(L"r2000\*(R"\fR and defines the macro \fB_MIPS_ARCH_R2000\fR.
+.Sp
+Note that the \fB_MIPS_ARCH\fR macro uses the processor names given
+above.  In other words, it has the full prefix and does not
+abbreviate \fB000\fR as \fBk\fR.  In the case of \fBfrom-abi\fR,
+the macro names the resolved architecture (either \fB\*(L"mips1\*(R"\fR or
+\&\fB\*(L"mips3\*(R"\fR).  It names the default architecture when no
+\&\fB\-march\fR option is given.
+.IP "\fB\-mtune=\fR\fIarch\fR" 4
+.IX Item "-mtune=arch"
+Optimize for \fIarch\fR.  Among other things, this option controls
+the way instructions are scheduled, and the perceived cost of arithmetic
+operations.  The list of \fIarch\fR values is the same as for
+\&\fB\-march\fR.
+.Sp
+When this option is not used, \s-1GCC\s0 optimizes for the processor
+specified by \fB\-march\fR.  By using \fB\-march\fR and
+\&\fB\-mtune\fR together, it is possible to generate code that
+runs on a family of processors, but optimize the code for one
+particular member of that family.
+.Sp
+\&\fB\-mtune\fR defines the macros \fB_MIPS_TUNE\fR and
+\&\fB_MIPS_TUNE_\fR\fIfoo\fR, which work in the same way as the
+\&\fB\-march\fR ones described above.
+.IP "\fB\-mips1\fR" 4
+.IX Item "-mips1"
+Equivalent to \fB\-march=mips1\fR.
+.IP "\fB\-mips2\fR" 4
+.IX Item "-mips2"
+Equivalent to \fB\-march=mips2\fR.
+.IP "\fB\-mips3\fR" 4
+.IX Item "-mips3"
+Equivalent to \fB\-march=mips3\fR.
+.IP "\fB\-mips4\fR" 4
+.IX Item "-mips4"
+Equivalent to \fB\-march=mips4\fR.
+.IP "\fB\-mips32\fR" 4
+.IX Item "-mips32"
+Equivalent to \fB\-march=mips32\fR.
+.IP "\fB\-mips32r2\fR" 4
+.IX Item "-mips32r2"
+Equivalent to \fB\-march=mips32r2\fR.
+.IP "\fB\-mips64\fR" 4
+.IX Item "-mips64"
+Equivalent to \fB\-march=mips64\fR.
+.IP "\fB\-mips64r2\fR" 4
+.IX Item "-mips64r2"
+Equivalent to \fB\-march=mips64r2\fR.
+.IP "\fB\-mips16\fR" 4
+.IX Item "-mips16"
+.PD 0
+.IP "\fB\-mno\-mips16\fR" 4
+.IX Item "-mno-mips16"
+.PD
+Generate (do not generate) \s-1MIPS16\s0 code.  If \s-1GCC\s0 is targeting a
+\&\s-1MIPS32\s0 or \s-1MIPS64\s0 architecture, it makes use of the MIPS16e \s-1ASE.\s0
+.Sp
+\&\s-1MIPS16\s0 code generation can also be controlled on a per-function basis
+by means of \f(CW\*(C`mips16\*(C'\fR and \f(CW\*(C`nomips16\*(C'\fR attributes.
+.IP "\fB\-mflip\-mips16\fR" 4
+.IX Item "-mflip-mips16"
+Generate \s-1MIPS16\s0 code on alternating functions.  This option is provided
+for regression testing of mixed MIPS16/non\-MIPS16 code generation, and is
+not intended for ordinary use in compiling user code.
+.IP "\fB\-minterlink\-compressed\fR" 4
+.IX Item "-minterlink-compressed"
+.PD 0
+.IP "\fB\-mno\-interlink\-compressed\fR" 4
+.IX Item "-mno-interlink-compressed"
+.PD
+Require (do not require) that code using the standard (uncompressed) \s-1MIPS ISA\s0
+be link-compatible with \s-1MIPS16\s0 and microMIPS code, and vice versa.
+.Sp
+For example, code using the standard \s-1ISA\s0 encoding cannot jump directly
+to \s-1MIPS16\s0 or microMIPS code; it must either use a call or an indirect jump.
+\&\fB\-minterlink\-compressed\fR therefore disables direct jumps unless \s-1GCC\s0
+knows that the target of the jump is not compressed.
+.IP "\fB\-minterlink\-mips16\fR" 4
+.IX Item "-minterlink-mips16"
+.PD 0
+.IP "\fB\-mno\-interlink\-mips16\fR" 4
+.IX Item "-mno-interlink-mips16"
+.PD
+Aliases of \fB\-minterlink\-compressed\fR and
+\&\fB\-mno\-interlink\-compressed\fR.  These options predate the microMIPS \s-1ASE\s0
+and are retained for backwards compatibility.
+.IP "\fB\-mabi=32\fR" 4
+.IX Item "-mabi=32"
+.PD 0
+.IP "\fB\-mabi=o64\fR" 4
+.IX Item "-mabi=o64"
+.IP "\fB\-mabi=n32\fR" 4
+.IX Item "-mabi=n32"
+.IP "\fB\-mabi=64\fR" 4
+.IX Item "-mabi=64"
+.IP "\fB\-mabi=eabi\fR" 4
+.IX Item "-mabi=eabi"
+.PD
+Generate code for the given \s-1ABI.\s0
+.Sp
+Note that the \s-1EABI\s0 has a 32\-bit and a 64\-bit variant.  \s-1GCC\s0 normally
+generates 64\-bit code when you select a 64\-bit architecture, but you
+can use \fB\-mgp32\fR to get 32\-bit code instead.
+.Sp
+For information about the O64 \s-1ABI,\s0 see
+<\fBhttp://gcc.gnu.org/projects/mipso64\-abi.html\fR>.
+.Sp
+\&\s-1GCC\s0 supports a variant of the o32 \s-1ABI\s0 in which floating-point registers
+are 64 rather than 32 bits wide.  You can select this combination with
+\&\fB\-mabi=32\fR \fB\-mfp64\fR.  This \s-1ABI\s0 relies on the \f(CW\*(C`mthc1\*(C'\fR
+and \f(CW\*(C`mfhc1\*(C'\fR instructions and is therefore only supported for
+\&\s-1MIPS32R2\s0 processors.
+.Sp
+The register assignments for arguments and return values remain the
+same, but each scalar value is passed in a single 64\-bit register
+rather than a pair of 32\-bit registers.  For example, scalar
+floating-point values are returned in \fB\f(CB$f0\fB\fR only, not a
+\&\fB\f(CB$f0\fB\fR/\fB\f(CB$f1\fB\fR pair.  The set of call-saved registers also
+remains the same, but all 64 bits are saved.
+.IP "\fB\-mabicalls\fR" 4
+.IX Item "-mabicalls"
+.PD 0
+.IP "\fB\-mno\-abicalls\fR" 4
+.IX Item "-mno-abicalls"
+.PD
+Generate (do not generate) code that is suitable for SVR4\-style
+dynamic objects.  \fB\-mabicalls\fR is the default for SVR4\-based
+systems.
+.IP "\fB\-mshared\fR" 4
+.IX Item "-mshared"
+.PD 0
+.IP "\fB\-mno\-shared\fR" 4
+.IX Item "-mno-shared"
+.PD
+Generate (do not generate) code that is fully position-independent,
+and that can therefore be linked into shared libraries.  This option
+only affects \fB\-mabicalls\fR.
+.Sp
+All \fB\-mabicalls\fR code has traditionally been position-independent,
+regardless of options like \fB\-fPIC\fR and \fB\-fpic\fR.  However,
+as an extension, the \s-1GNU\s0 toolchain allows executables to use absolute
+accesses for locally-binding symbols.  It can also use shorter \s-1GP\s0
+initialization sequences and generate direct calls to locally-defined
+functions.  This mode is selected by \fB\-mno\-shared\fR.
+.Sp
+\&\fB\-mno\-shared\fR depends on binutils 2.16 or higher and generates
+objects that can only be linked by the \s-1GNU\s0 linker.  However, the option
+does not affect the \s-1ABI\s0 of the final executable; it only affects the \s-1ABI\s0
+of relocatable objects.  Using \fB\-mno\-shared\fR generally makes
+executables both smaller and quicker.
+.Sp
+\&\fB\-mshared\fR is the default.
+.IP "\fB\-mplt\fR" 4
+.IX Item "-mplt"
+.PD 0
+.IP "\fB\-mno\-plt\fR" 4
+.IX Item "-mno-plt"
+.PD
+Assume (do not assume) that the static and dynamic linkers
+support PLTs and copy relocations.  This option only affects
+\&\fB\-mno\-shared \-mabicalls\fR.  For the n64 \s-1ABI,\s0 this option
+has no effect without \fB\-msym32\fR.
+.Sp
+You can make \fB\-mplt\fR the default by configuring
+\&\s-1GCC\s0 with \fB\-\-with\-mips\-plt\fR.  The default is
+\&\fB\-mno\-plt\fR otherwise.
+.IP "\fB\-mxgot\fR" 4
+.IX Item "-mxgot"
+.PD 0
+.IP "\fB\-mno\-xgot\fR" 4
+.IX Item "-mno-xgot"
+.PD
+Lift (do not lift) the usual restrictions on the size of the global
+offset table.
+.Sp
+\&\s-1GCC\s0 normally uses a single instruction to load values from the \s-1GOT.\s0
+While this is relatively efficient, it only works if the \s-1GOT\s0
+is smaller than about 64k.  Anything larger causes the linker
+to report an error such as:
+.Sp
+.Vb 1
+\&        relocation truncated to fit: R_MIPS_GOT16 foobar
+.Ve
+.Sp
+If this happens, you should recompile your code with \fB\-mxgot\fR.
+This works with very large GOTs, although the code is also
+less efficient, since it takes three instructions to fetch the
+value of a global symbol.
+.Sp
+Note that some linkers can create multiple GOTs.  If you have such a
+linker, you should only need to use \fB\-mxgot\fR when a single object
+file accesses more than 64k's worth of \s-1GOT\s0 entries.  Very few do.
+.Sp
+These options have no effect unless \s-1GCC\s0 is generating position
+independent code.
+.IP "\fB\-mgp32\fR" 4
+.IX Item "-mgp32"
+Assume that general-purpose registers are 32 bits wide.
+.IP "\fB\-mgp64\fR" 4
+.IX Item "-mgp64"
+Assume that general-purpose registers are 64 bits wide.
+.IP "\fB\-mfp32\fR" 4
+.IX Item "-mfp32"
+Assume that floating-point registers are 32 bits wide.
+.IP "\fB\-mfp64\fR" 4
+.IX Item "-mfp64"
+Assume that floating-point registers are 64 bits wide.
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+Use floating-point coprocessor instructions.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Do not use floating-point coprocessor instructions.  Implement
+floating-point calculations using library calls instead.
+.IP "\fB\-mno\-float\fR" 4
+.IX Item "-mno-float"
+Equivalent to \fB\-msoft\-float\fR, but additionally asserts that the
+program being compiled does not perform any floating-point operations.
+This option is presently supported only by some bare-metal \s-1MIPS\s0
+configurations, where it may select a special set of libraries
+that lack all floating-point support (including, for example, the
+floating-point \f(CW\*(C`printf\*(C'\fR formats).  
+If code compiled with \f(CW\*(C`\-mno\-float\*(C'\fR accidentally contains
+floating-point operations, it is likely to suffer a link-time
+or run-time failure.
+.IP "\fB\-msingle\-float\fR" 4
+.IX Item "-msingle-float"
+Assume that the floating-point coprocessor only supports single-precision
+operations.
+.IP "\fB\-mdouble\-float\fR" 4
+.IX Item "-mdouble-float"
+Assume that the floating-point coprocessor supports double-precision
+operations.  This is the default.
+.IP "\fB\-mabs=2008\fR" 4
+.IX Item "-mabs=2008"
+.PD 0
+.IP "\fB\-mabs=legacy\fR" 4
+.IX Item "-mabs=legacy"
+.PD
+These options control the treatment of the special not-a-number (NaN)
+\&\s-1IEEE 754\s0 floating-point data with the \f(CW\*(C`abs.\f(CIfmt\f(CW\*(C'\fR and
+\&\f(CW\*(C`neg.\f(CIfmt\f(CW\*(C'\fR machine instructions.
+.Sp
+By default or when the \fB\-mabs=legacy\fR is used the legacy
+treatment is selected.  In this case these instructions are considered
+arithmetic and avoided where correct operation is required and the
+input operand might be a NaN.  A longer sequence of instructions that
+manipulate the sign bit of floating-point datum manually is used
+instead unless the \fB\-ffinite\-math\-only\fR option has also been
+specified.
+.Sp
+The \fB\-mabs=2008\fR option selects the \s-1IEEE 754\-2008\s0 treatment.  In
+this case these instructions are considered non-arithmetic and therefore
+operating correctly in all cases, including in particular where the
+input operand is a NaN.  These instructions are therefore always used
+for the respective operations.
+.IP "\fB\-mnan=2008\fR" 4
+.IX Item "-mnan=2008"
+.PD 0
+.IP "\fB\-mnan=legacy\fR" 4
+.IX Item "-mnan=legacy"
+.PD
+These options control the encoding of the special not-a-number (NaN)
+\&\s-1IEEE 754\s0 floating-point data.
+.Sp
+The \fB\-mnan=legacy\fR option selects the legacy encoding.  In this
+case quiet NaNs (qNaNs) are denoted by the first bit of their trailing
+significand field being 0, whereas signalling NaNs (sNaNs) are denoted
+by the first bit of their trailing significand field being 1.
+.Sp
+The \fB\-mnan=2008\fR option selects the \s-1IEEE 754\-2008\s0 encoding.  In
+this case qNaNs are denoted by the first bit of their trailing
+significand field being 1, whereas sNaNs are denoted by the first bit of
+their trailing significand field being 0.
+.Sp
+The default is \fB\-mnan=legacy\fR unless \s-1GCC\s0 has been configured with
+\&\fB\-\-with\-nan=2008\fR.
+.IP "\fB\-mllsc\fR" 4
+.IX Item "-mllsc"
+.PD 0
+.IP "\fB\-mno\-llsc\fR" 4
+.IX Item "-mno-llsc"
+.PD
+Use (do not use) \fBll\fR, \fBsc\fR, and \fBsync\fR instructions to
+implement atomic memory built-in functions.  When neither option is
+specified, \s-1GCC\s0 uses the instructions if the target architecture
+supports them.
+.Sp
+\&\fB\-mllsc\fR is useful if the runtime environment can emulate the
+instructions and \fB\-mno\-llsc\fR can be useful when compiling for
+nonstandard ISAs.  You can make either option the default by
+configuring \s-1GCC\s0 with \fB\-\-with\-llsc\fR and \fB\-\-without\-llsc\fR
+respectively.  \fB\-\-with\-llsc\fR is the default for some
+configurations; see the installation documentation for details.
+.IP "\fB\-mdsp\fR" 4
+.IX Item "-mdsp"
+.PD 0
+.IP "\fB\-mno\-dsp\fR" 4
+.IX Item "-mno-dsp"
+.PD
+Use (do not use) revision 1 of the \s-1MIPS DSP ASE.
+ \s0 This option defines the
+preprocessor macro \fB_\|_mips_dsp\fR.  It also defines
+\&\fB_\|_mips_dsp_rev\fR to 1.
+.IP "\fB\-mdspr2\fR" 4
+.IX Item "-mdspr2"
+.PD 0
+.IP "\fB\-mno\-dspr2\fR" 4
+.IX Item "-mno-dspr2"
+.PD
+Use (do not use) revision 2 of the \s-1MIPS DSP ASE.
+ \s0 This option defines the
+preprocessor macros \fB_\|_mips_dsp\fR and \fB_\|_mips_dspr2\fR.
+It also defines \fB_\|_mips_dsp_rev\fR to 2.
+.IP "\fB\-msmartmips\fR" 4
+.IX Item "-msmartmips"
+.PD 0
+.IP "\fB\-mno\-smartmips\fR" 4
+.IX Item "-mno-smartmips"
+.PD
+Use (do not use) the \s-1MIPS\s0 SmartMIPS \s-1ASE.\s0
+.IP "\fB\-mpaired\-single\fR" 4
+.IX Item "-mpaired-single"
+.PD 0
+.IP "\fB\-mno\-paired\-single\fR" 4
+.IX Item "-mno-paired-single"
+.PD
+Use (do not use) paired-single floating-point instructions.
+  This option requires
+hardware floating-point support to be enabled.
+.IP "\fB\-mdmx\fR" 4
+.IX Item "-mdmx"
+.PD 0
+.IP "\fB\-mno\-mdmx\fR" 4
+.IX Item "-mno-mdmx"
+.PD
+Use (do not use) \s-1MIPS\s0 Digital Media Extension instructions.
+This option can only be used when generating 64\-bit code and requires
+hardware floating-point support to be enabled.
+.IP "\fB\-mips3d\fR" 4
+.IX Item "-mips3d"
+.PD 0
+.IP "\fB\-mno\-mips3d\fR" 4
+.IX Item "-mno-mips3d"
+.PD
+Use (do not use) the \s-1MIPS\-3D ASE.  \s0
+The option \fB\-mips3d\fR implies \fB\-mpaired\-single\fR.
+.IP "\fB\-mmicromips\fR" 4
+.IX Item "-mmicromips"
+.PD 0
+.IP "\fB\-mno\-micromips\fR" 4
+.IX Item "-mno-micromips"
+.PD
+Generate (do not generate) microMIPS code.
+.Sp
+MicroMIPS code generation can also be controlled on a per-function basis
+by means of \f(CW\*(C`micromips\*(C'\fR and \f(CW\*(C`nomicromips\*(C'\fR attributes.
+.IP "\fB\-mmt\fR" 4
+.IX Item "-mmt"
+.PD 0
+.IP "\fB\-mno\-mt\fR" 4
+.IX Item "-mno-mt"
+.PD
+Use (do not use) \s-1MT\s0 Multithreading instructions.
+.IP "\fB\-mmcu\fR" 4
+.IX Item "-mmcu"
+.PD 0
+.IP "\fB\-mno\-mcu\fR" 4
+.IX Item "-mno-mcu"
+.PD
+Use (do not use) the \s-1MIPS MCU ASE\s0 instructions.
+.IP "\fB\-meva\fR" 4
+.IX Item "-meva"
+.PD 0
+.IP "\fB\-mno\-eva\fR" 4
+.IX Item "-mno-eva"
+.PD
+Use (do not use) the \s-1MIPS\s0 Enhanced Virtual Addressing instructions.
+.IP "\fB\-mvirt\fR" 4
+.IX Item "-mvirt"
+.PD 0
+.IP "\fB\-mno\-virt\fR" 4
+.IX Item "-mno-virt"
+.PD
+Use (do not use) the \s-1MIPS\s0 Virtualization Application Specific instructions.
+.IP "\fB\-mlong64\fR" 4
+.IX Item "-mlong64"
+Force \f(CW\*(C`long\*(C'\fR types to be 64 bits wide.  See \fB\-mlong32\fR for
+an explanation of the default and the way that the pointer size is
+determined.
+.IP "\fB\-mlong32\fR" 4
+.IX Item "-mlong32"
+Force \f(CW\*(C`long\*(C'\fR, \f(CW\*(C`int\*(C'\fR, and pointer types to be 32 bits wide.
+.Sp
+The default size of \f(CW\*(C`int\*(C'\fRs, \f(CW\*(C`long\*(C'\fRs and pointers depends on
+the \s-1ABI. \s0 All the supported ABIs use 32\-bit \f(CW\*(C`int\*(C'\fRs.  The n64 \s-1ABI\s0
+uses 64\-bit \f(CW\*(C`long\*(C'\fRs, as does the 64\-bit \s-1EABI\s0; the others use
+32\-bit \f(CW\*(C`long\*(C'\fRs.  Pointers are the same size as \f(CW\*(C`long\*(C'\fRs,
+or the same size as integer registers, whichever is smaller.
+.IP "\fB\-msym32\fR" 4
+.IX Item "-msym32"
+.PD 0
+.IP "\fB\-mno\-sym32\fR" 4
+.IX Item "-mno-sym32"
+.PD
+Assume (do not assume) that all symbols have 32\-bit values, regardless
+of the selected \s-1ABI. \s0 This option is useful in combination with
+\&\fB\-mabi=64\fR and \fB\-mno\-abicalls\fR because it allows \s-1GCC\s0
+to generate shorter and faster references to symbolic addresses.
+.IP "\fB\-G\fR \fInum\fR" 4
+.IX Item "-G num"
+Put definitions of externally-visible data in a small data section
+if that data is no bigger than \fInum\fR bytes.  \s-1GCC\s0 can then generate
+more efficient accesses to the data; see \fB\-mgpopt\fR for details.
+.Sp
+The default \fB\-G\fR option depends on the configuration.
+.IP "\fB\-mlocal\-sdata\fR" 4
+.IX Item "-mlocal-sdata"
+.PD 0
+.IP "\fB\-mno\-local\-sdata\fR" 4
+.IX Item "-mno-local-sdata"
+.PD
+Extend (do not extend) the \fB\-G\fR behavior to local data too,
+such as to static variables in C.  \fB\-mlocal\-sdata\fR is the
+default for all configurations.
+.Sp
+If the linker complains that an application is using too much small data,
+you might want to try rebuilding the less performance-critical parts with
+\&\fB\-mno\-local\-sdata\fR.  You might also want to build large
+libraries with \fB\-mno\-local\-sdata\fR, so that the libraries leave
+more room for the main program.
+.IP "\fB\-mextern\-sdata\fR" 4
+.IX Item "-mextern-sdata"
+.PD 0
+.IP "\fB\-mno\-extern\-sdata\fR" 4
+.IX Item "-mno-extern-sdata"
+.PD
+Assume (do not assume) that externally-defined data is in
+a small data section if the size of that data is within the \fB\-G\fR limit.
+\&\fB\-mextern\-sdata\fR is the default for all configurations.
+.Sp
+If you compile a module \fIMod\fR with \fB\-mextern\-sdata\fR \fB\-G\fR
+\&\fInum\fR \fB\-mgpopt\fR, and \fIMod\fR references a variable \fIVar\fR
+that is no bigger than \fInum\fR bytes, you must make sure that \fIVar\fR
+is placed in a small data section.  If \fIVar\fR is defined by another
+module, you must either compile that module with a high-enough
+\&\fB\-G\fR setting or attach a \f(CW\*(C`section\*(C'\fR attribute to \fIVar\fR's
+definition.  If \fIVar\fR is common, you must link the application
+with a high-enough \fB\-G\fR setting.
+.Sp
+The easiest way of satisfying these restrictions is to compile
+and link every module with the same \fB\-G\fR option.  However,
+you may wish to build a library that supports several different
+small data limits.  You can do this by compiling the library with
+the highest supported \fB\-G\fR setting and additionally using
+\&\fB\-mno\-extern\-sdata\fR to stop the library from making assumptions
+about externally-defined data.
+.IP "\fB\-mgpopt\fR" 4
+.IX Item "-mgpopt"
+.PD 0
+.IP "\fB\-mno\-gpopt\fR" 4
+.IX Item "-mno-gpopt"
+.PD
+Use (do not use) GP-relative accesses for symbols that are known to be
+in a small data section; see \fB\-G\fR, \fB\-mlocal\-sdata\fR and
+\&\fB\-mextern\-sdata\fR.  \fB\-mgpopt\fR is the default for all
+configurations.
+.Sp
+\&\fB\-mno\-gpopt\fR is useful for cases where the \f(CW$gp\fR register
+might not hold the value of \f(CW\*(C`_gp\*(C'\fR.  For example, if the code is
+part of a library that might be used in a boot monitor, programs that
+call boot monitor routines pass an unknown value in \f(CW$gp\fR.
+(In such situations, the boot monitor itself is usually compiled
+with \fB\-G0\fR.)
+.Sp
+\&\fB\-mno\-gpopt\fR implies \fB\-mno\-local\-sdata\fR and
+\&\fB\-mno\-extern\-sdata\fR.
+.IP "\fB\-membedded\-data\fR" 4
+.IX Item "-membedded-data"
+.PD 0
+.IP "\fB\-mno\-embedded\-data\fR" 4
+.IX Item "-mno-embedded-data"
+.PD
+Allocate variables to the read-only data section first if possible, then
+next in the small data section if possible, otherwise in data.  This gives
+slightly slower code than the default, but reduces the amount of \s-1RAM\s0 required
+when executing, and thus may be preferred for some embedded systems.
+.IP "\fB\-muninit\-const\-in\-rodata\fR" 4
+.IX Item "-muninit-const-in-rodata"
+.PD 0
+.IP "\fB\-mno\-uninit\-const\-in\-rodata\fR" 4
+.IX Item "-mno-uninit-const-in-rodata"
+.PD
+Put uninitialized \f(CW\*(C`const\*(C'\fR variables in the read-only data section.
+This option is only meaningful in conjunction with \fB\-membedded\-data\fR.
+.IP "\fB\-mcode\-readable=\fR\fIsetting\fR" 4
+.IX Item "-mcode-readable=setting"
+Specify whether \s-1GCC\s0 may generate code that reads from executable sections.
+There are three possible settings:
+.RS 4
+.IP "\fB\-mcode\-readable=yes\fR" 4
+.IX Item "-mcode-readable=yes"
+Instructions may freely access executable sections.  This is the
+default setting.
+.IP "\fB\-mcode\-readable=pcrel\fR" 4
+.IX Item "-mcode-readable=pcrel"
+\&\s-1MIPS16\s0 PC-relative load instructions can access executable sections,
+but other instructions must not do so.  This option is useful on 4KSc
+and 4KSd processors when the code TLBs have the Read Inhibit bit set.
+It is also useful on processors that can be configured to have a dual
+instruction/data \s-1SRAM\s0 interface and that, like the M4K, automatically
+redirect PC-relative loads to the instruction \s-1RAM.\s0
+.IP "\fB\-mcode\-readable=no\fR" 4
+.IX Item "-mcode-readable=no"
+Instructions must not access executable sections.  This option can be
+useful on targets that are configured to have a dual instruction/data
+\&\s-1SRAM\s0 interface but that (unlike the M4K) do not automatically redirect
+PC-relative loads to the instruction \s-1RAM.\s0
+.RE
+.RS 4
+.RE
+.IP "\fB\-msplit\-addresses\fR" 4
+.IX Item "-msplit-addresses"
+.PD 0
+.IP "\fB\-mno\-split\-addresses\fR" 4
+.IX Item "-mno-split-addresses"
+.PD
+Enable (disable) use of the \f(CW\*(C`%hi()\*(C'\fR and \f(CW\*(C`%lo()\*(C'\fR assembler
+relocation operators.  This option has been superseded by
+\&\fB\-mexplicit\-relocs\fR but is retained for backwards compatibility.
+.IP "\fB\-mexplicit\-relocs\fR" 4
+.IX Item "-mexplicit-relocs"
+.PD 0
+.IP "\fB\-mno\-explicit\-relocs\fR" 4
+.IX Item "-mno-explicit-relocs"
+.PD
+Use (do not use) assembler relocation operators when dealing with symbolic
+addresses.  The alternative, selected by \fB\-mno\-explicit\-relocs\fR,
+is to use assembler macros instead.
+.Sp
+\&\fB\-mexplicit\-relocs\fR is the default if \s-1GCC\s0 was configured
+to use an assembler that supports relocation operators.
+.IP "\fB\-mcheck\-zero\-division\fR" 4
+.IX Item "-mcheck-zero-division"
+.PD 0
+.IP "\fB\-mno\-check\-zero\-division\fR" 4
+.IX Item "-mno-check-zero-division"
+.PD
+Trap (do not trap) on integer division by zero.
+.Sp
+The default is \fB\-mcheck\-zero\-division\fR.
+.IP "\fB\-mdivide\-traps\fR" 4
+.IX Item "-mdivide-traps"
+.PD 0
+.IP "\fB\-mdivide\-breaks\fR" 4
+.IX Item "-mdivide-breaks"
+.PD
+\&\s-1MIPS\s0 systems check for division by zero by generating either a
+conditional trap or a break instruction.  Using traps results in
+smaller code, but is only supported on \s-1MIPS II\s0 and later.  Also, some
+versions of the Linux kernel have a bug that prevents trap from
+generating the proper signal (\f(CW\*(C`SIGFPE\*(C'\fR).  Use \fB\-mdivide\-traps\fR to
+allow conditional traps on architectures that support them and
+\&\fB\-mdivide\-breaks\fR to force the use of breaks.
+.Sp
+The default is usually \fB\-mdivide\-traps\fR, but this can be
+overridden at configure time using \fB\-\-with\-divide=breaks\fR.
+Divide-by-zero checks can be completely disabled using
+\&\fB\-mno\-check\-zero\-division\fR.
+.IP "\fB\-mmemcpy\fR" 4
+.IX Item "-mmemcpy"
+.PD 0
+.IP "\fB\-mno\-memcpy\fR" 4
+.IX Item "-mno-memcpy"
+.PD
+Force (do not force) the use of \f(CW\*(C`memcpy()\*(C'\fR for non-trivial block
+moves.  The default is \fB\-mno\-memcpy\fR, which allows \s-1GCC\s0 to inline
+most constant-sized copies.
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+.PD 0
+.IP "\fB\-mno\-long\-calls\fR" 4
+.IX Item "-mno-long-calls"
+.PD
+Disable (do not disable) use of the \f(CW\*(C`jal\*(C'\fR instruction.  Calling
+functions using \f(CW\*(C`jal\*(C'\fR is more efficient but requires the caller
+and callee to be in the same 256 megabyte segment.
+.Sp
+This option has no effect on abicalls code.  The default is
+\&\fB\-mno\-long\-calls\fR.
+.IP "\fB\-mmad\fR" 4
+.IX Item "-mmad"
+.PD 0
+.IP "\fB\-mno\-mad\fR" 4
+.IX Item "-mno-mad"
+.PD
+Enable (disable) use of the \f(CW\*(C`mad\*(C'\fR, \f(CW\*(C`madu\*(C'\fR and \f(CW\*(C`mul\*(C'\fR
+instructions, as provided by the R4650 \s-1ISA.\s0
+.IP "\fB\-mimadd\fR" 4
+.IX Item "-mimadd"
+.PD 0
+.IP "\fB\-mno\-imadd\fR" 4
+.IX Item "-mno-imadd"
+.PD
+Enable (disable) use of the \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR integer
+instructions.  The default is \fB\-mimadd\fR on architectures
+that support \f(CW\*(C`madd\*(C'\fR and \f(CW\*(C`msub\*(C'\fR except for the 74k 
+architecture where it was found to generate slower code.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Enable (disable) use of the floating-point multiply-accumulate
+instructions, when they are available.  The default is
+\&\fB\-mfused\-madd\fR.
+.Sp
+On the R8000 \s-1CPU\s0 when multiply-accumulate instructions are used,
+the intermediate product is calculated to infinite precision
+and is not subject to the \s-1FCSR\s0 Flush to Zero bit.  This may be
+undesirable in some circumstances.  On other processors the result
+is numerically identical to the equivalent computation using
+separate multiply, add, subtract and negate instructions.
+.IP "\fB\-nocpp\fR" 4
+.IX Item "-nocpp"
+Tell the \s-1MIPS\s0 assembler to not run its preprocessor over user
+assembler files (with a \fB.s\fR suffix) when assembling them.
+.IP "\fB\-mfix\-24k\fR" 4
+.IX Item "-mfix-24k"
+.PD 0
+.IP "\fB\-mno\-fix\-24k\fR" 4
+.IX Item "-mno-fix-24k"
+.PD
+Work around the 24K E48 (lost data on stores during refill) errata.
+The workarounds are implemented by the assembler rather than by \s-1GCC.\s0
+.IP "\fB\-mfix\-r4000\fR" 4
+.IX Item "-mfix-r4000"
+.PD 0
+.IP "\fB\-mno\-fix\-r4000\fR" 4
+.IX Item "-mno-fix-r4000"
+.PD
+Work around certain R4000 \s-1CPU\s0 errata:
+.RS 4
+.IP "\-" 4
+A double-word or a variable shift may give an incorrect result if executed
+immediately after starting an integer division.
+.IP "\-" 4
+A double-word or a variable shift may give an incorrect result if executed
+while an integer multiplication is in progress.
+.IP "\-" 4
+An integer division may give an incorrect result if started in a delay slot
+of a taken branch or a jump.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mfix\-r4400\fR" 4
+.IX Item "-mfix-r4400"
+.PD 0
+.IP "\fB\-mno\-fix\-r4400\fR" 4
+.IX Item "-mno-fix-r4400"
+.PD
+Work around certain R4400 \s-1CPU\s0 errata:
+.RS 4
+.IP "\-" 4
+A double-word or a variable shift may give an incorrect result if executed
+immediately after starting an integer division.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mfix\-r10000\fR" 4
+.IX Item "-mfix-r10000"
+.PD 0
+.IP "\fB\-mno\-fix\-r10000\fR" 4
+.IX Item "-mno-fix-r10000"
+.PD
+Work around certain R10000 errata:
+.RS 4
+.IP "\-" 4
+\&\f(CW\*(C`ll\*(C'\fR/\f(CW\*(C`sc\*(C'\fR sequences may not behave atomically on revisions
+prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
+.RE
+.RS 4
+.Sp
+This option can only be used if the target architecture supports
+branch-likely instructions.  \fB\-mfix\-r10000\fR is the default when
+\&\fB\-march=r10000\fR is used; \fB\-mno\-fix\-r10000\fR is the default
+otherwise.
+.RE
+.IP "\fB\-mfix\-rm7000\fR" 4
+.IX Item "-mfix-rm7000"
+.PD 0
+.IP "\fB\-mno\-fix\-rm7000\fR" 4
+.IX Item "-mno-fix-rm7000"
+.PD
+Work around the \s-1RM7000 \s0\f(CW\*(C`dmult\*(C'\fR/\f(CW\*(C`dmultu\*(C'\fR errata.  The
+workarounds are implemented by the assembler rather than by \s-1GCC.\s0
+.IP "\fB\-mfix\-vr4120\fR" 4
+.IX Item "-mfix-vr4120"
+.PD 0
+.IP "\fB\-mno\-fix\-vr4120\fR" 4
+.IX Item "-mno-fix-vr4120"
+.PD
+Work around certain \s-1VR4120\s0 errata:
+.RS 4
+.IP "\-" 4
+\&\f(CW\*(C`dmultu\*(C'\fR does not always produce the correct result.
+.IP "\-" 4
+\&\f(CW\*(C`div\*(C'\fR and \f(CW\*(C`ddiv\*(C'\fR do not always produce the correct result if one
+of the operands is negative.
+.RE
+.RS 4
+.Sp
+The workarounds for the division errata rely on special functions in
+\&\fIlibgcc.a\fR.  At present, these functions are only provided by
+the \f(CW\*(C`mips64vr*\-elf\*(C'\fR configurations.
+.Sp
+Other \s-1VR4120\s0 errata require a \s-1NOP\s0 to be inserted between certain pairs of
+instructions.  These errata are handled by the assembler, not by \s-1GCC\s0 itself.
+.RE
+.IP "\fB\-mfix\-vr4130\fR" 4
+.IX Item "-mfix-vr4130"
+Work around the \s-1VR4130 \s0\f(CW\*(C`mflo\*(C'\fR/\f(CW\*(C`mfhi\*(C'\fR errata.  The
+workarounds are implemented by the assembler rather than by \s-1GCC,\s0
+although \s-1GCC\s0 avoids using \f(CW\*(C`mflo\*(C'\fR and \f(CW\*(C`mfhi\*(C'\fR if the
+\&\s-1VR4130 \s0\f(CW\*(C`macc\*(C'\fR, \f(CW\*(C`macchi\*(C'\fR, \f(CW\*(C`dmacc\*(C'\fR and \f(CW\*(C`dmacchi\*(C'\fR
+instructions are available instead.
+.IP "\fB\-mfix\-sb1\fR" 4
+.IX Item "-mfix-sb1"
+.PD 0
+.IP "\fB\-mno\-fix\-sb1\fR" 4
+.IX Item "-mno-fix-sb1"
+.PD
+Work around certain \s-1SB\-1 CPU\s0 core errata.
+(This flag currently works around the \s-1SB\-1\s0 revision 2
+\&\*(L"F1\*(R" and \*(L"F2\*(R" floating-point errata.)
+.IP "\fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR" 4
+.IX Item "-mr10k-cache-barrier=setting"
+Specify whether \s-1GCC\s0 should insert cache barriers to avoid the
+side-effects of speculation on R10K processors.
+.Sp
+In common with many processors, the R10K tries to predict the outcome
+of a conditional branch and speculatively executes instructions from
+the \*(L"taken\*(R" branch.  It later aborts these instructions if the
+predicted outcome is wrong.  However, on the R10K, even aborted
+instructions can have side effects.
+.Sp
+This problem only affects kernel stores and, depending on the system,
+kernel loads.  As an example, a speculatively-executed store may load
+the target memory into cache and mark the cache line as dirty, even if
+the store itself is later aborted.  If a \s-1DMA\s0 operation writes to the
+same area of memory before the \*(L"dirty\*(R" line is flushed, the cached
+data overwrites the DMA-ed data.  See the R10K processor manual
+for a full description, including other potential problems.
+.Sp
+One workaround is to insert cache barrier instructions before every memory
+access that might be speculatively executed and that might have side
+effects even if aborted.  \fB\-mr10k\-cache\-barrier=\fR\fIsetting\fR
+controls \s-1GCC\s0's implementation of this workaround.  It assumes that
+aborted accesses to any byte in the following regions does not have
+side effects:
+.RS 4
+.IP "1." 4
+the memory occupied by the current function's stack frame;
+.IP "2." 4
+the memory occupied by an incoming stack argument;
+.IP "3." 4
+the memory occupied by an object with a link-time-constant address.
+.RE
+.RS 4
+.Sp
+It is the kernel's responsibility to ensure that speculative
+accesses to these regions are indeed safe.
+.Sp
+If the input program contains a function declaration such as:
+.Sp
+.Vb 1
+\&        void foo (void);
+.Ve
+.Sp
+then the implementation of \f(CW\*(C`foo\*(C'\fR must allow \f(CW\*(C`j foo\*(C'\fR and
+\&\f(CW\*(C`jal foo\*(C'\fR to be executed speculatively.  \s-1GCC\s0 honors this
+restriction for functions it compiles itself.  It expects non-GCC
+functions (such as hand-written assembly code) to do the same.
+.Sp
+The option has three forms:
+.IP "\fB\-mr10k\-cache\-barrier=load\-store\fR" 4
+.IX Item "-mr10k-cache-barrier=load-store"
+Insert a cache barrier before a load or store that might be
+speculatively executed and that might have side effects even
+if aborted.
+.IP "\fB\-mr10k\-cache\-barrier=store\fR" 4
+.IX Item "-mr10k-cache-barrier=store"
+Insert a cache barrier before a store that might be speculatively
+executed and that might have side effects even if aborted.
+.IP "\fB\-mr10k\-cache\-barrier=none\fR" 4
+.IX Item "-mr10k-cache-barrier=none"
+Disable the insertion of cache barriers.  This is the default setting.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mflush\-func=\fR\fIfunc\fR" 4
+.IX Item "-mflush-func=func"
+.PD 0
+.IP "\fB\-mno\-flush\-func\fR" 4
+.IX Item "-mno-flush-func"
+.PD
+Specifies the function to call to flush the I and D caches, or to not
+call any such function.  If called, the function must take the same
+arguments as the common \f(CW\*(C`_flush_func()\*(C'\fR, that is, the address of the
+memory range for which the cache is being flushed, the size of the
+memory range, and the number 3 (to flush both caches).  The default
+depends on the target \s-1GCC\s0 was configured for, but commonly is either
+\&\fB_flush_func\fR or \fB_\|_cpu_flush\fR.
+.IP "\fBmbranch\-cost=\fR\fInum\fR" 4
+.IX Item "mbranch-cost=num"
+Set the cost of branches to roughly \fInum\fR \*(L"simple\*(R" instructions.
+This cost is only a heuristic and is not guaranteed to produce
+consistent results across releases.  A zero cost redundantly selects
+the default, which is based on the \fB\-mtune\fR setting.
+.IP "\fB\-mbranch\-likely\fR" 4
+.IX Item "-mbranch-likely"
+.PD 0
+.IP "\fB\-mno\-branch\-likely\fR" 4
+.IX Item "-mno-branch-likely"
+.PD
+Enable or disable use of Branch Likely instructions, regardless of the
+default for the selected architecture.  By default, Branch Likely
+instructions may be generated if they are supported by the selected
+architecture.  An exception is for the \s-1MIPS32\s0 and \s-1MIPS64\s0 architectures
+and processors that implement those architectures; for those, Branch
+Likely instructions are not be generated by default because the \s-1MIPS32\s0
+and \s-1MIPS64\s0 architectures specifically deprecate their use.
+.IP "\fB\-mfp\-exceptions\fR" 4
+.IX Item "-mfp-exceptions"
+.PD 0
+.IP "\fB\-mno\-fp\-exceptions\fR" 4
+.IX Item "-mno-fp-exceptions"
+.PD
+Specifies whether \s-1FP\s0 exceptions are enabled.  This affects how
+\&\s-1FP\s0 instructions are scheduled for some processors.
+The default is that \s-1FP\s0 exceptions are
+enabled.
+.Sp
+For instance, on the \s-1SB\-1,\s0 if \s-1FP\s0 exceptions are disabled, and we are emitting
+64\-bit code, then we can use both \s-1FP\s0 pipes.  Otherwise, we can only use one
+\&\s-1FP\s0 pipe.
+.IP "\fB\-mvr4130\-align\fR" 4
+.IX Item "-mvr4130-align"
+.PD 0
+.IP "\fB\-mno\-vr4130\-align\fR" 4
+.IX Item "-mno-vr4130-align"
+.PD
+The \s-1VR4130\s0 pipeline is two-way superscalar, but can only issue two
+instructions together if the first one is 8\-byte aligned.  When this
+option is enabled, \s-1GCC\s0 aligns pairs of instructions that it
+thinks should execute in parallel.
+.Sp
+This option only has an effect when optimizing for the \s-1VR4130.\s0
+It normally makes code faster, but at the expense of making it bigger.
+It is enabled by default at optimization level \fB\-O3\fR.
+.IP "\fB\-msynci\fR" 4
+.IX Item "-msynci"
+.PD 0
+.IP "\fB\-mno\-synci\fR" 4
+.IX Item "-mno-synci"
+.PD
+Enable (disable) generation of \f(CW\*(C`synci\*(C'\fR instructions on
+architectures that support it.  The \f(CW\*(C`synci\*(C'\fR instructions (if
+enabled) are generated when \f(CW\*(C`_\|_builtin_\|_\|_clear_cache()\*(C'\fR is
+compiled.
+.Sp
+This option defaults to \f(CW\*(C`\-mno\-synci\*(C'\fR, but the default can be
+overridden by configuring with \f(CW\*(C`\-\-with\-synci\*(C'\fR.
+.Sp
+When compiling code for single processor systems, it is generally safe
+to use \f(CW\*(C`synci\*(C'\fR.  However, on many multi-core (\s-1SMP\s0) systems, it
+does not invalidate the instruction caches on all cores and may lead
+to undefined behavior.
+.IP "\fB\-mrelax\-pic\-calls\fR" 4
+.IX Item "-mrelax-pic-calls"
+.PD 0
+.IP "\fB\-mno\-relax\-pic\-calls\fR" 4
+.IX Item "-mno-relax-pic-calls"
+.PD
+Try to turn \s-1PIC\s0 calls that are normally dispatched via register
+\&\f(CW$25\fR into direct calls.  This is only possible if the linker can
+resolve the destination at link-time and if the destination is within
+range for a direct call.
+.Sp
+\&\fB\-mrelax\-pic\-calls\fR is the default if \s-1GCC\s0 was configured to use
+an assembler and a linker that support the \f(CW\*(C`.reloc\*(C'\fR assembly
+directive and \f(CW\*(C`\-mexplicit\-relocs\*(C'\fR is in effect.  With
+\&\f(CW\*(C`\-mno\-explicit\-relocs\*(C'\fR, this optimization can be performed by the
+assembler and the linker alone without help from the compiler.
+.IP "\fB\-mmcount\-ra\-address\fR" 4
+.IX Item "-mmcount-ra-address"
+.PD 0
+.IP "\fB\-mno\-mcount\-ra\-address\fR" 4
+.IX Item "-mno-mcount-ra-address"
+.PD
+Emit (do not emit) code that allows \f(CW\*(C`_mcount\*(C'\fR to modify the
+calling function's return address.  When enabled, this option extends
+the usual \f(CW\*(C`_mcount\*(C'\fR interface with a new \fIra-address\fR
+parameter, which has type \f(CW\*(C`intptr_t *\*(C'\fR and is passed in register
+\&\f(CW$12\fR.  \f(CW\*(C`_mcount\*(C'\fR can then modify the return address by
+doing both of the following:
+.RS 4
+.IP "\(bu" 4
+Returning the new address in register \f(CW$31\fR.
+.IP "\(bu" 4
+Storing the new address in \f(CW\*(C`*\f(CIra\-address\f(CW\*(C'\fR,
+if \fIra-address\fR is nonnull.
+.RE
+.RS 4
+.Sp
+The default is \fB\-mno\-mcount\-ra\-address\fR.
+.RE
+.PP
+\fI\s-1MMIX\s0 Options\fR
+.IX Subsection "MMIX Options"
+.PP
+These options are defined for the \s-1MMIX:\s0
+.IP "\fB\-mlibfuncs\fR" 4
+.IX Item "-mlibfuncs"
+.PD 0
+.IP "\fB\-mno\-libfuncs\fR" 4
+.IX Item "-mno-libfuncs"
+.PD
+Specify that intrinsic library functions are being compiled, passing all
+values in registers, no matter the size.
+.IP "\fB\-mepsilon\fR" 4
+.IX Item "-mepsilon"
+.PD 0
+.IP "\fB\-mno\-epsilon\fR" 4
+.IX Item "-mno-epsilon"
+.PD
+Generate floating-point comparison instructions that compare with respect
+to the \f(CW\*(C`rE\*(C'\fR epsilon register.
+.IP "\fB\-mabi=mmixware\fR" 4
+.IX Item "-mabi=mmixware"
+.PD 0
+.IP "\fB\-mabi=gnu\fR" 4
+.IX Item "-mabi=gnu"
+.PD
+Generate code that passes function parameters and return values that (in
+the called function) are seen as registers \f(CW$0\fR and up, as opposed to
+the \s-1GNU ABI\s0 which uses global registers \f(CW$231\fR and up.
+.IP "\fB\-mzero\-extend\fR" 4
+.IX Item "-mzero-extend"
+.PD 0
+.IP "\fB\-mno\-zero\-extend\fR" 4
+.IX Item "-mno-zero-extend"
+.PD
+When reading data from memory in sizes shorter than 64 bits, use (do not
+use) zero-extending load instructions by default, rather than
+sign-extending ones.
+.IP "\fB\-mknuthdiv\fR" 4
+.IX Item "-mknuthdiv"
+.PD 0
+.IP "\fB\-mno\-knuthdiv\fR" 4
+.IX Item "-mno-knuthdiv"
+.PD
+Make the result of a division yielding a remainder have the same sign as
+the divisor.  With the default, \fB\-mno\-knuthdiv\fR, the sign of the
+remainder follows the sign of the dividend.  Both methods are
+arithmetically valid, the latter being almost exclusively used.
+.IP "\fB\-mtoplevel\-symbols\fR" 4
+.IX Item "-mtoplevel-symbols"
+.PD 0
+.IP "\fB\-mno\-toplevel\-symbols\fR" 4
+.IX Item "-mno-toplevel-symbols"
+.PD
+Prepend (do not prepend) a \fB:\fR to all global symbols, so the assembly
+code can be used with the \f(CW\*(C`PREFIX\*(C'\fR assembly directive.
+.IP "\fB\-melf\fR" 4
+.IX Item "-melf"
+Generate an executable in the \s-1ELF\s0 format, rather than the default
+\&\fBmmo\fR format used by the \fBmmix\fR simulator.
+.IP "\fB\-mbranch\-predict\fR" 4
+.IX Item "-mbranch-predict"
+.PD 0
+.IP "\fB\-mno\-branch\-predict\fR" 4
+.IX Item "-mno-branch-predict"
+.PD
+Use (do not use) the probable-branch instructions, when static branch
+prediction indicates a probable branch.
+.IP "\fB\-mbase\-addresses\fR" 4
+.IX Item "-mbase-addresses"
+.PD 0
+.IP "\fB\-mno\-base\-addresses\fR" 4
+.IX Item "-mno-base-addresses"
+.PD
+Generate (do not generate) code that uses \fIbase addresses\fR.  Using a
+base address automatically generates a request (handled by the assembler
+and the linker) for a constant to be set up in a global register.  The
+register is used for one or more base address requests within the range 0
+to 255 from the value held in the register.  The generally leads to short
+and fast code, but the number of different data items that can be
+addressed is limited.  This means that a program that uses lots of static
+data may require \fB\-mno\-base\-addresses\fR.
+.IP "\fB\-msingle\-exit\fR" 4
+.IX Item "-msingle-exit"
+.PD 0
+.IP "\fB\-mno\-single\-exit\fR" 4
+.IX Item "-mno-single-exit"
+.PD
+Force (do not force) generated code to have a single exit point in each
+function.
+.PP
+\fI\s-1MN10300\s0 Options\fR
+.IX Subsection "MN10300 Options"
+.PP
+These \fB\-m\fR options are defined for Matsushita \s-1MN10300\s0 architectures:
+.IP "\fB\-mmult\-bug\fR" 4
+.IX Item "-mmult-bug"
+Generate code to avoid bugs in the multiply instructions for the \s-1MN10300\s0
+processors.  This is the default.
+.IP "\fB\-mno\-mult\-bug\fR" 4
+.IX Item "-mno-mult-bug"
+Do not generate code to avoid bugs in the multiply instructions for the
+\&\s-1MN10300\s0 processors.
+.IP "\fB\-mam33\fR" 4
+.IX Item "-mam33"
+Generate code using features specific to the \s-1AM33\s0 processor.
+.IP "\fB\-mno\-am33\fR" 4
+.IX Item "-mno-am33"
+Do not generate code using features specific to the \s-1AM33\s0 processor.  This
+is the default.
+.IP "\fB\-mam33\-2\fR" 4
+.IX Item "-mam33-2"
+Generate code using features specific to the \s-1AM33/2.0\s0 processor.
+.IP "\fB\-mam34\fR" 4
+.IX Item "-mam34"
+Generate code using features specific to the \s-1AM34\s0 processor.
+.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
+.IX Item "-mtune=cpu-type"
+Use the timing characteristics of the indicated \s-1CPU\s0 type when
+scheduling instructions.  This does not change the targeted processor
+type.  The \s-1CPU\s0 type must be one of \fBmn10300\fR, \fBam33\fR,
+\&\fBam33\-2\fR or \fBam34\fR.
+.IP "\fB\-mreturn\-pointer\-on\-d0\fR" 4
+.IX Item "-mreturn-pointer-on-d0"
+When generating a function that returns a pointer, return the pointer
+in both \f(CW\*(C`a0\*(C'\fR and \f(CW\*(C`d0\*(C'\fR.  Otherwise, the pointer is returned
+only in \f(CW\*(C`a0\*(C'\fR, and attempts to call such functions without a prototype
+result in errors.  Note that this option is on by default; use
+\&\fB\-mno\-return\-pointer\-on\-d0\fR to disable it.
+.IP "\fB\-mno\-crt0\fR" 4
+.IX Item "-mno-crt0"
+Do not link in the C run-time initialization object file.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Indicate to the linker that it should perform a relaxation optimization pass
+to shorten branches, calls and absolute memory addresses.  This option only
+has an effect when used on the command line for the final link step.
+.Sp
+This option makes symbolic debugging impossible.
+.IP "\fB\-mliw\fR" 4
+.IX Item "-mliw"
+Allow the compiler to generate \fILong Instruction Word\fR
+instructions if the target is the \fB\s-1AM33\s0\fR or later.  This is the
+default.  This option defines the preprocessor macro \fB_\|_LIW_\|_\fR.
+.IP "\fB\-mnoliw\fR" 4
+.IX Item "-mnoliw"
+Do not allow the compiler to generate \fILong Instruction Word\fR
+instructions.  This option defines the preprocessor macro
+\&\fB_\|_NO_LIW_\|_\fR.
+.IP "\fB\-msetlb\fR" 4
+.IX Item "-msetlb"
+Allow the compiler to generate the \fI\s-1SETLB\s0\fR and \fILcc\fR
+instructions if the target is the \fB\s-1AM33\s0\fR or later.  This is the
+default.  This option defines the preprocessor macro \fB_\|_SETLB_\|_\fR.
+.IP "\fB\-mnosetlb\fR" 4
+.IX Item "-mnosetlb"
+Do not allow the compiler to generate \fI\s-1SETLB\s0\fR or \fILcc\fR
+instructions.  This option defines the preprocessor macro
+\&\fB_\|_NO_SETLB_\|_\fR.
+.PP
+\fIMoxie Options\fR
+.IX Subsection "Moxie Options"
+.IP "\fB\-meb\fR" 4
+.IX Item "-meb"
+Generate big-endian code.  This is the default for \fBmoxie\-*\-*\fR
+configurations.
+.IP "\fB\-mel\fR" 4
+.IX Item "-mel"
+Generate little-endian code.
+.IP "\fB\-mno\-crt0\fR" 4
+.IX Item "-mno-crt0"
+Do not link in the C run-time initialization object file.
+.PP
+\fI\s-1MSP430\s0 Options\fR
+.IX Subsection "MSP430 Options"
+.PP
+These options are defined for the \s-1MSP430:\s0
+.IP "\fB\-masm\-hex\fR" 4
+.IX Item "-masm-hex"
+Force assembly output to always use hex constants.  Normally such
+constants are signed decimals, but this option is available for
+testsuite and/or aesthetic purposes.
+.IP "\fB\-mmcu=\fR" 4
+.IX Item "-mmcu="
+Select the \s-1MCU\s0 to target.  This is used to create a C preprocessor
+symbol based upon the \s-1MCU\s0 name, converted to upper case and pre\- and
+post\- fixed with \f(CW\*(C`_\|_\*(C'\fR.  This in turn will be used by the
+\&\f(CW\*(C`msp430.h\*(C'\fR header file to select an \s-1MCU\s0 specific supplimentary
+header file.
+.Sp
+The option also sets the \s-1ISA\s0 to use.  If the \s-1MCU\s0 name is one that is
+known to only support the 430 \s-1ISA\s0 then that is selected, otherwise the
+430X \s-1ISA\s0 is selected.  A generic \s-1MCU\s0 name of \f(CW\*(C`msp430\*(C'\fR can also be
+used to select the 430 \s-1ISA. \s0 Similarly the generic \f(CW\*(C`msp430x\*(C'\fR \s-1MCU\s0
+name will select the 430X \s-1ISA.\s0
+.Sp
+In addition an \s-1MCU\s0 specific linker script will be added to the linker
+command line.  The script's name is the name of the \s-1MCU\s0 with
+\&\f(CW\*(C`.ld\*(C'\fR appended.  Thus specifying \fB\-mmcu=xxx\fR on the gcc
+command line will define the C preprocessor symbol \f(CW\*(C`_\|_XXX_\|_\*(C'\fR and
+cause the linker to search for a script called \fIxxx.ld\fR.
+.Sp
+This option is also passed on to the assembler.
+.IP "\fB\-mcpu=\fR" 4
+.IX Item "-mcpu="
+Specifies the \s-1ISA\s0 to use.  Accepted values are \f(CW\*(C`msp430\*(C'\fR,
+\&\f(CW\*(C`msp430x\*(C'\fR and \f(CW\*(C`msp430xv2\*(C'\fR.  This option is deprecated.  The
+\&\fB\-mmcu=\fR option should be used to select the \s-1ISA.\s0
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Link to the simulator runtime libraries and linker script.  Overrides
+any scripts that would be selected by the \fB\-mmcu=\fR option.
+.IP "\fB\-mlarge\fR" 4
+.IX Item "-mlarge"
+Use large-model addressing (20\-bit pointers, 32\-bit \f(CW\*(C`size_t\*(C'\fR).
+.IP "\fB\-msmall\fR" 4
+.IX Item "-msmall"
+Use small-model addressing (16\-bit pointers, 16\-bit \f(CW\*(C`size_t\*(C'\fR).
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+This option is passed to the assembler and linker, and allows the
+linker to perform certain optimizations that cannot be done until
+the final link.
+.PP
+\fI\s-1NDS32\s0 Options\fR
+.IX Subsection "NDS32 Options"
+.PP
+These options are defined for \s-1NDS32\s0 implementations:
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+Generate code in big-endian mode.
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+Generate code in little-endian mode.
+.IP "\fB\-mreduced\-regs\fR" 4
+.IX Item "-mreduced-regs"
+Use reduced-set registers for register allocation.
+.IP "\fB\-mfull\-regs\fR" 4
+.IX Item "-mfull-regs"
+Use full-set registers for register allocation.
+.IP "\fB\-mcmov\fR" 4
+.IX Item "-mcmov"
+Generate conditional move instructions.
+.IP "\fB\-mno\-cmov\fR" 4
+.IX Item "-mno-cmov"
+Do not generate conditional move instructions.
+.IP "\fB\-mperf\-ext\fR" 4
+.IX Item "-mperf-ext"
+Generate performance extension instructions.
+.IP "\fB\-mno\-perf\-ext\fR" 4
+.IX Item "-mno-perf-ext"
+Do not generate performance extension instructions.
+.IP "\fB\-mv3push\fR" 4
+.IX Item "-mv3push"
+Generate v3 push25/pop25 instructions.
+.IP "\fB\-mno\-v3push\fR" 4
+.IX Item "-mno-v3push"
+Do not generate v3 push25/pop25 instructions.
+.IP "\fB\-m16\-bit\fR" 4
+.IX Item "-m16-bit"
+Generate 16\-bit instructions.
+.IP "\fB\-mno\-16\-bit\fR" 4
+.IX Item "-mno-16-bit"
+Do not generate 16\-bit instructions.
+.IP "\fB\-mgp\-direct\fR" 4
+.IX Item "-mgp-direct"
+Generate \s-1GP\s0 base instructions directly.
+.IP "\fB\-mno\-gp\-direct\fR" 4
+.IX Item "-mno-gp-direct"
+Do no generate \s-1GP\s0 base instructions directly.
+.IP "\fB\-misr\-vector\-size=\fR\fInum\fR" 4
+.IX Item "-misr-vector-size=num"
+Specify the size of each interrupt vector, which must be 4 or 16.
+.IP "\fB\-mcache\-block\-size=\fR\fInum\fR" 4
+.IX Item "-mcache-block-size=num"
+Specify the size of each cache block,
+which must be a power of 2 between 4 and 512.
+.IP "\fB\-march=\fR\fIarch\fR" 4
+.IX Item "-march=arch"
+Specify the name of the target architecture.
+.IP "\fB\-mforce\-fp\-as\-gp\fR" 4
+.IX Item "-mforce-fp-as-gp"
+Prevent \f(CW$fp\fR being allocated during register allocation so that compiler
+is able to force performing fp-as-gp optimization.
+.IP "\fB\-mforbid\-fp\-as\-gp\fR" 4
+.IX Item "-mforbid-fp-as-gp"
+Forbid using \f(CW$fp\fR to access static and global variables.
+This option strictly forbids fp-as-gp optimization
+regardless of \fB\-mforce\-fp\-as\-gp\fR.
+.IP "\fB\-mex9\fR" 4
+.IX Item "-mex9"
+Use special directives to guide linker doing ex9 optimization.
+.IP "\fB\-mctor\-dtor\fR" 4
+.IX Item "-mctor-dtor"
+Enable constructor/destructor feature.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Guide linker to relax instructions.
+.PP
+\fINios \s-1II\s0 Options\fR
+.IX Subsection "Nios II Options"
+.PP
+These are the options defined for the Altera Nios \s-1II\s0 processor.
+.IP "\fB\-G\fR \fInum\fR" 4
+.IX Item "-G num"
+Put global and static objects less than or equal to \fInum\fR bytes
+into the small data or \s-1BSS\s0 sections instead of the normal data or \s-1BSS\s0
+sections.  The default value of \fInum\fR is 8.
+.IP "\fB\-mgpopt\fR" 4
+.IX Item "-mgpopt"
+.PD 0
+.IP "\fB\-mno\-gpopt\fR" 4
+.IX Item "-mno-gpopt"
+.PD
+Generate (do not generate) GP-relative accesses for objects in the
+small data or \s-1BSS\s0 sections.  The default is \fB\-mgpopt\fR except
+when \fB\-fpic\fR or \fB\-fPIC\fR is specified to generate
+position-independent code.  Note that the Nios \s-1II ABI\s0 does not permit
+GP-relative accesses from shared libraries.
+.Sp
+You may need to specify \fB\-mno\-gpopt\fR explicitly when building
+programs that include large amounts of small data, including large
+\&\s-1GOT\s0 data sections.  In this case, the 16\-bit offset for GP-relative
+addressing may not be large enough to allow access to the entire 
+small data section.
+.IP "\fB\-mel\fR" 4
+.IX Item "-mel"
+.PD 0
+.IP "\fB\-meb\fR" 4
+.IX Item "-meb"
+.PD
+Generate little-endian (default) or big-endian (experimental) code,
+respectively.
+.IP "\fB\-mbypass\-cache\fR" 4
+.IX Item "-mbypass-cache"
+.PD 0
+.IP "\fB\-mno\-bypass\-cache\fR" 4
+.IX Item "-mno-bypass-cache"
+.PD
+Force all load and store instructions to always bypass cache by 
+using I/O variants of the instructions. The default is not to
+bypass the cache.
+.IP "\fB\-mno\-cache\-volatile\fR" 4
+.IX Item "-mno-cache-volatile"
+.PD 0
+.IP "\fB\-mcache\-volatile\fR" 4
+.IX Item "-mcache-volatile"
+.PD
+Volatile memory access bypass the cache using the I/O variants of 
+the load and store instructions. The default is not to bypass the cache.
+.IP "\fB\-mno\-fast\-sw\-div\fR" 4
+.IX Item "-mno-fast-sw-div"
+.PD 0
+.IP "\fB\-mfast\-sw\-div\fR" 4
+.IX Item "-mfast-sw-div"
+.PD
+Do not use table-based fast divide for small numbers. The default 
+is to use the fast divide at \fB\-O3\fR and above.
+.IP "\fB\-mno\-hw\-mul\fR" 4
+.IX Item "-mno-hw-mul"
+.PD 0
+.IP "\fB\-mhw\-mul\fR" 4
+.IX Item "-mhw-mul"
+.IP "\fB\-mno\-hw\-mulx\fR" 4
+.IX Item "-mno-hw-mulx"
+.IP "\fB\-mhw\-mulx\fR" 4
+.IX Item "-mhw-mulx"
+.IP "\fB\-mno\-hw\-div\fR" 4
+.IX Item "-mno-hw-div"
+.IP "\fB\-mhw\-div\fR" 4
+.IX Item "-mhw-div"
+.PD
+Enable or disable emitting \f(CW\*(C`mul\*(C'\fR, \f(CW\*(C`mulx\*(C'\fR and \f(CW\*(C`div\*(C'\fR family of 
+instructions by the compiler. The default is to emit \f(CW\*(C`mul\*(C'\fR
+and not emit \f(CW\*(C`div\*(C'\fR and \f(CW\*(C`mulx\*(C'\fR.
+.IP "\fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR" 4
+.IX Item "-mcustom-insn=N"
+.PD 0
+.IP "\fB\-mno\-custom\-\fR\fIinsn\fR" 4
+.IX Item "-mno-custom-insn"
+.PD
+Each \fB\-mcustom\-\fR\fIinsn\fR\fB=\fR\fIN\fR option enables use of a
+custom instruction with encoding \fIN\fR when generating code that uses 
+\&\fIinsn\fR.  For example, \f(CW\*(C`\-mcustom\-fadds=253\*(C'\fR generates custom
+instruction 253 for single-precision floating-point add operations instead
+of the default behavior of using a library call.
+.Sp
+The following values of \fIinsn\fR are supported.  Except as otherwise
+noted, floating-point operations are expected to be implemented with
+normal \s-1IEEE 754\s0 semantics and correspond directly to the C operators or the
+equivalent \s-1GCC\s0 built-in functions.
+.Sp
+Single-precision floating point:
+.RS 4
+.IP "\fBfadds\fR, \fBfsubs\fR, \fBfdivs\fR, \fBfmuls\fR" 4
+.IX Item "fadds, fsubs, fdivs, fmuls"
+Binary arithmetic operations.
+.IP "\fBfnegs\fR" 4
+.IX Item "fnegs"
+Unary negation.
+.IP "\fBfabss\fR" 4
+.IX Item "fabss"
+Unary absolute value.
+.IP "\fBfcmpeqs\fR, \fBfcmpges\fR, \fBfcmpgts\fR, \fBfcmples\fR, \fBfcmplts\fR, \fBfcmpnes\fR" 4
+.IX Item "fcmpeqs, fcmpges, fcmpgts, fcmples, fcmplts, fcmpnes"
+Comparison operations.
+.IP "\fBfmins\fR, \fBfmaxs\fR" 4
+.IX Item "fmins, fmaxs"
+Floating-point minimum and maximum.  These instructions are only
+generated if \fB\-ffinite\-math\-only\fR is specified.
+.IP "\fBfsqrts\fR" 4
+.IX Item "fsqrts"
+Unary square root operation.
+.IP "\fBfcoss\fR, \fBfsins\fR, \fBftans\fR, \fBfatans\fR, \fBfexps\fR, \fBflogs\fR" 4
+.IX Item "fcoss, fsins, ftans, fatans, fexps, flogs"
+Floating-point trigonometric and exponential functions.  These instructions
+are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
+.RE
+.RS 4
+.Sp
+Double-precision floating point:
+.IP "\fBfaddd\fR, \fBfsubd\fR, \fBfdivd\fR, \fBfmuld\fR" 4
+.IX Item "faddd, fsubd, fdivd, fmuld"
+Binary arithmetic operations.
+.IP "\fBfnegd\fR" 4
+.IX Item "fnegd"
+Unary negation.
+.IP "\fBfabsd\fR" 4
+.IX Item "fabsd"
+Unary absolute value.
+.IP "\fBfcmpeqd\fR, \fBfcmpged\fR, \fBfcmpgtd\fR, \fBfcmpled\fR, \fBfcmpltd\fR, \fBfcmpned\fR" 4
+.IX Item "fcmpeqd, fcmpged, fcmpgtd, fcmpled, fcmpltd, fcmpned"
+Comparison operations.
+.IP "\fBfmind\fR, \fBfmaxd\fR" 4
+.IX Item "fmind, fmaxd"
+Double-precision minimum and maximum.  These instructions are only
+generated if \fB\-ffinite\-math\-only\fR is specified.
+.IP "\fBfsqrtd\fR" 4
+.IX Item "fsqrtd"
+Unary square root operation.
+.IP "\fBfcosd\fR, \fBfsind\fR, \fBftand\fR, \fBfatand\fR, \fBfexpd\fR, \fBflogd\fR" 4
+.IX Item "fcosd, fsind, ftand, fatand, fexpd, flogd"
+Double-precision trigonometric and exponential functions.  These instructions
+are only generated if \fB\-funsafe\-math\-optimizations\fR is also specified.
+.RE
+.RS 4
+.Sp
+Conversions:
+.IP "\fBfextsd\fR" 4
+.IX Item "fextsd"
+Conversion from single precision to double precision.
+.IP "\fBftruncds\fR" 4
+.IX Item "ftruncds"
+Conversion from double precision to single precision.
+.IP "\fBfixsi\fR, \fBfixsu\fR, \fBfixdi\fR, \fBfixdu\fR" 4
+.IX Item "fixsi, fixsu, fixdi, fixdu"
+Conversion from floating point to signed or unsigned integer types, with
+truncation towards zero.
+.IP "\fBfloatis\fR, \fBfloatus\fR, \fBfloatid\fR, \fBfloatud\fR" 4
+.IX Item "floatis, floatus, floatid, floatud"
+Conversion from signed or unsigned integer types to floating-point types.
+.RE
+.RS 4
+.Sp
+In addition, all of the following transfer instructions for internal
+registers X and Y must be provided to use any of the double-precision
+floating-point instructions.  Custom instructions taking two
+double-precision source operands expect the first operand in the
+64\-bit register X.  The other operand (or only operand of a unary
+operation) is given to the custom arithmetic instruction with the
+least significant half in source register \fIsrc1\fR and the most
+significant half in \fIsrc2\fR.  A custom instruction that returns a
+double-precision result returns the most significant 32 bits in the
+destination register and the other half in 32\-bit register Y.  
+\&\s-1GCC\s0 automatically generates the necessary code sequences to write
+register X and/or read register Y when double-precision floating-point
+instructions are used.
+.IP "\fBfwrx\fR" 4
+.IX Item "fwrx"
+Write \fIsrc1\fR into the least significant half of X and \fIsrc2\fR into
+the most significant half of X.
+.IP "\fBfwry\fR" 4
+.IX Item "fwry"
+Write \fIsrc1\fR into Y.
+.IP "\fBfrdxhi\fR, \fBfrdxlo\fR" 4
+.IX Item "frdxhi, frdxlo"
+Read the most or least (respectively) significant half of X and store it in
+\&\fIdest\fR.
+.IP "\fBfrdy\fR" 4
+.IX Item "frdy"
+Read the value of Y and store it into \fIdest\fR.
+.RE
+.RS 4
+.Sp
+Note that you can gain more local control over generation of Nios \s-1II\s0 custom
+instructions by using the \f(CW\*(C`target("custom\-\f(CIinsn\f(CW=\f(CIN\f(CW")\*(C'\fR
+and \f(CW\*(C`target("no\-custom\-\f(CIinsn\f(CW")\*(C'\fR function attributes
+or pragmas.
+.RE
+.IP "\fB\-mcustom\-fpu\-cfg=\fR\fIname\fR" 4
+.IX Item "-mcustom-fpu-cfg=name"
+This option enables a predefined, named set of custom instruction encodings
+(see \fB\-mcustom\-\fR\fIinsn\fR above).  
+Currently, the following sets are defined:
+.Sp
+\&\fB\-mcustom\-fpu\-cfg=60\-1\fR is equivalent to:
+\&\fB\-mcustom\-fmuls=252 
+\&\-mcustom\-fadds=253 
+\&\-mcustom\-fsubs=254 
+\&\-fsingle\-precision\-constant\fR
+.Sp
+\&\fB\-mcustom\-fpu\-cfg=60\-2\fR is equivalent to:
+\&\fB\-mcustom\-fmuls=252 
+\&\-mcustom\-fadds=253 
+\&\-mcustom\-fsubs=254 
+\&\-mcustom\-fdivs=255 
+\&\-fsingle\-precision\-constant\fR
+.Sp
+\&\fB\-mcustom\-fpu\-cfg=72\-3\fR is equivalent to:
+\&\fB\-mcustom\-floatus=243 
+\&\-mcustom\-fixsi=244 
+\&\-mcustom\-floatis=245 
+\&\-mcustom\-fcmpgts=246 
+\&\-mcustom\-fcmples=249 
+\&\-mcustom\-fcmpeqs=250 
+\&\-mcustom\-fcmpnes=251 
+\&\-mcustom\-fmuls=252 
+\&\-mcustom\-fadds=253 
+\&\-mcustom\-fsubs=254 
+\&\-mcustom\-fdivs=255 
+\&\-fsingle\-precision\-constant\fR
+.Sp
+Custom instruction assignments given by individual
+\&\fB\-mcustom\-\fR\fIinsn\fR\fB=\fR options override those given by
+\&\fB\-mcustom\-fpu\-cfg=\fR, regardless of the
+order of the options on the command line.
+.Sp
+Note that you can gain more local control over selection of a \s-1FPU\s0
+configuration by using the \f(CW\*(C`target("custom\-fpu\-cfg=\f(CIname\f(CW")\*(C'\fR
+function attribute
+or pragma.
+.PP
+These additional \fB\-m\fR options are available for the Altera Nios \s-1II
+ELF \s0(bare-metal) target:
+.IP "\fB\-mhal\fR" 4
+.IX Item "-mhal"
+Link with \s-1HAL BSP. \s0 This suppresses linking with the GCC-provided C runtime
+startup and termination code, and is typically used in conjunction with
+\&\fB\-msys\-crt0=\fR to specify the location of the alternate startup code
+provided by the \s-1HAL BSP.\s0
+.IP "\fB\-msmallc\fR" 4
+.IX Item "-msmallc"
+Link with a limited version of the C library, \fB\-lsmallc\fR, rather than
+Newlib.
+.IP "\fB\-msys\-crt0=\fR\fIstartfile\fR" 4
+.IX Item "-msys-crt0=startfile"
+\&\fIstartfile\fR is the file name of the startfile (crt0) to use 
+when linking.  This option is only useful in conjunction with \fB\-mhal\fR.
+.IP "\fB\-msys\-lib=\fR\fIsystemlib\fR" 4
+.IX Item "-msys-lib=systemlib"
+\&\fIsystemlib\fR is the library name of the library that provides
+low-level system calls required by the C library,
+e.g. \f(CW\*(C`read\*(C'\fR and \f(CW\*(C`write\*(C'\fR.
+This option is typically used to link with a library provided by a \s-1HAL BSP.\s0
+.PP
+\fI\s-1PDP\-11\s0 Options\fR
+.IX Subsection "PDP-11 Options"
+.PP
+These options are defined for the \s-1PDP\-11:\s0
+.IP "\fB\-mfpu\fR" 4
+.IX Item "-mfpu"
+Use hardware \s-1FPP\s0 floating point.  This is the default.  (\s-1FIS\s0 floating
+point on the \s-1PDP\-11/40\s0 is not supported.)
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+Do not use hardware floating point.
+.IP "\fB\-mac0\fR" 4
+.IX Item "-mac0"
+Return floating-point results in ac0 (fr0 in Unix assembler syntax).
+.IP "\fB\-mno\-ac0\fR" 4
+.IX Item "-mno-ac0"
+Return floating-point results in memory.  This is the default.
+.IP "\fB\-m40\fR" 4
+.IX Item "-m40"
+Generate code for a \s-1PDP\-11/40.\s0
+.IP "\fB\-m45\fR" 4
+.IX Item "-m45"
+Generate code for a \s-1PDP\-11/45. \s0 This is the default.
+.IP "\fB\-m10\fR" 4
+.IX Item "-m10"
+Generate code for a \s-1PDP\-11/10.\s0
+.IP "\fB\-mbcopy\-builtin\fR" 4
+.IX Item "-mbcopy-builtin"
+Use inline \f(CW\*(C`movmemhi\*(C'\fR patterns for copying memory.  This is the
+default.
+.IP "\fB\-mbcopy\fR" 4
+.IX Item "-mbcopy"
+Do not use inline \f(CW\*(C`movmemhi\*(C'\fR patterns for copying memory.
+.IP "\fB\-mint16\fR" 4
+.IX Item "-mint16"
+.PD 0
+.IP "\fB\-mno\-int32\fR" 4
+.IX Item "-mno-int32"
+.PD
+Use 16\-bit \f(CW\*(C`int\*(C'\fR.  This is the default.
+.IP "\fB\-mint32\fR" 4
+.IX Item "-mint32"
+.PD 0
+.IP "\fB\-mno\-int16\fR" 4
+.IX Item "-mno-int16"
+.PD
+Use 32\-bit \f(CW\*(C`int\*(C'\fR.
+.IP "\fB\-mfloat64\fR" 4
+.IX Item "-mfloat64"
+.PD 0
+.IP "\fB\-mno\-float32\fR" 4
+.IX Item "-mno-float32"
+.PD
+Use 64\-bit \f(CW\*(C`float\*(C'\fR.  This is the default.
+.IP "\fB\-mfloat32\fR" 4
+.IX Item "-mfloat32"
+.PD 0
+.IP "\fB\-mno\-float64\fR" 4
+.IX Item "-mno-float64"
+.PD
+Use 32\-bit \f(CW\*(C`float\*(C'\fR.
+.IP "\fB\-mabshi\fR" 4
+.IX Item "-mabshi"
+Use \f(CW\*(C`abshi2\*(C'\fR pattern.  This is the default.
+.IP "\fB\-mno\-abshi\fR" 4
+.IX Item "-mno-abshi"
+Do not use \f(CW\*(C`abshi2\*(C'\fR pattern.
+.IP "\fB\-mbranch\-expensive\fR" 4
+.IX Item "-mbranch-expensive"
+Pretend that branches are expensive.  This is for experimenting with
+code generation only.
+.IP "\fB\-mbranch\-cheap\fR" 4
+.IX Item "-mbranch-cheap"
+Do not pretend that branches are expensive.  This is the default.
+.IP "\fB\-munix\-asm\fR" 4
+.IX Item "-munix-asm"
+Use Unix assembler syntax.  This is the default when configured for
+\&\fBpdp11\-*\-bsd\fR.
+.IP "\fB\-mdec\-asm\fR" 4
+.IX Item "-mdec-asm"
+Use \s-1DEC\s0 assembler syntax.  This is the default when configured for any
+\&\s-1PDP\-11\s0 target other than \fBpdp11\-*\-bsd\fR.
+.PP
+\fIpicoChip Options\fR
+.IX Subsection "picoChip Options"
+.PP
+These \fB\-m\fR options are defined for picoChip implementations:
+.IP "\fB\-mae=\fR\fIae_type\fR" 4
+.IX Item "-mae=ae_type"
+Set the instruction set, register set, and instruction scheduling
+parameters for array element type \fIae_type\fR.  Supported values
+for \fIae_type\fR are \fB\s-1ANY\s0\fR, \fB\s-1MUL\s0\fR, and \fB\s-1MAC\s0\fR.
+.Sp
+\&\fB\-mae=ANY\fR selects a completely generic \s-1AE\s0 type.  Code
+generated with this option runs on any of the other \s-1AE\s0 types.  The
+code is not as efficient as it would be if compiled for a specific
+\&\s-1AE\s0 type, and some types of operation (e.g., multiplication) do not
+work properly on all types of \s-1AE.\s0
+.Sp
+\&\fB\-mae=MUL\fR selects a \s-1MUL AE\s0 type.  This is the most useful \s-1AE\s0 type
+for compiled code, and is the default.
+.Sp
+\&\fB\-mae=MAC\fR selects a DSP-style \s-1MAC AE. \s0 Code compiled with this
+option may suffer from poor performance of byte (char) manipulation,
+since the \s-1DSP AE\s0 does not provide hardware support for byte load/stores.
+.IP "\fB\-msymbol\-as\-address\fR" 4
+.IX Item "-msymbol-as-address"
+Enable the compiler to directly use a symbol name as an address in a
+load/store instruction, without first loading it into a
+register.  Typically, the use of this option generates larger
+programs, which run faster than when the option isn't used.  However, the
+results vary from program to program, so it is left as a user option,
+rather than being permanently enabled.
+.IP "\fB\-mno\-inefficient\-warnings\fR" 4
+.IX Item "-mno-inefficient-warnings"
+Disables warnings about the generation of inefficient code.  These
+warnings can be generated, for example, when compiling code that
+performs byte-level memory operations on the \s-1MAC AE\s0 type.  The \s-1MAC AE\s0 has
+no hardware support for byte-level memory operations, so all byte
+load/stores must be synthesized from word load/store operations.  This is
+inefficient and a warning is generated to indicate
+that you should rewrite the code to avoid byte operations, or to target
+an \s-1AE\s0 type that has the necessary hardware support.  This option disables
+these warnings.
+.PP
+\fIPowerPC Options\fR
+.IX Subsection "PowerPC Options"
+.PP
+These are listed under
+.PP
+\fI\s-1RL78\s0 Options\fR
+.IX Subsection "RL78 Options"
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Links in additional target libraries to support operation within a
+simulator.
+.IP "\fB\-mmul=none\fR" 4
+.IX Item "-mmul=none"
+.PD 0
+.IP "\fB\-mmul=g13\fR" 4
+.IX Item "-mmul=g13"
+.IP "\fB\-mmul=rl78\fR" 4
+.IX Item "-mmul=rl78"
+.PD
+Specifies the type of hardware multiplication support to be used.  The
+default is \f(CW\*(C`none\*(C'\fR, which uses software multiplication functions.
+The \f(CW\*(C`g13\*(C'\fR option is for the hardware multiply/divide peripheral
+only on the \s-1RL78/G13\s0 targets.  The \f(CW\*(C`rl78\*(C'\fR option is for the
+standard hardware multiplication defined in the \s-1RL78\s0 software manual.
+.PP
+\fI\s-1IBM RS/6000\s0 and PowerPC Options\fR
+.IX Subsection "IBM RS/6000 and PowerPC Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1IBM RS/6000\s0 and PowerPC:
+.IP "\fB\-mpowerpc\-gpopt\fR" 4
+.IX Item "-mpowerpc-gpopt"
+.PD 0
+.IP "\fB\-mno\-powerpc\-gpopt\fR" 4
+.IX Item "-mno-powerpc-gpopt"
+.IP "\fB\-mpowerpc\-gfxopt\fR" 4
+.IX Item "-mpowerpc-gfxopt"
+.IP "\fB\-mno\-powerpc\-gfxopt\fR" 4
+.IX Item "-mno-powerpc-gfxopt"
+.IP "\fB\-mpowerpc64\fR" 4
+.IX Item "-mpowerpc64"
+.IP "\fB\-mno\-powerpc64\fR" 4
+.IX Item "-mno-powerpc64"
+.IP "\fB\-mmfcrf\fR" 4
+.IX Item "-mmfcrf"
+.IP "\fB\-mno\-mfcrf\fR" 4
+.IX Item "-mno-mfcrf"
+.IP "\fB\-mpopcntb\fR" 4
+.IX Item "-mpopcntb"
+.IP "\fB\-mno\-popcntb\fR" 4
+.IX Item "-mno-popcntb"
+.IP "\fB\-mpopcntd\fR" 4
+.IX Item "-mpopcntd"
+.IP "\fB\-mno\-popcntd\fR" 4
+.IX Item "-mno-popcntd"
+.IP "\fB\-mfprnd\fR" 4
+.IX Item "-mfprnd"
+.IP "\fB\-mno\-fprnd\fR" 4
+.IX Item "-mno-fprnd"
+.IP "\fB\-mcmpb\fR" 4
+.IX Item "-mcmpb"
+.IP "\fB\-mno\-cmpb\fR" 4
+.IX Item "-mno-cmpb"
+.IP "\fB\-mmfpgpr\fR" 4
+.IX Item "-mmfpgpr"
+.IP "\fB\-mno\-mfpgpr\fR" 4
+.IX Item "-mno-mfpgpr"
+.IP "\fB\-mhard\-dfp\fR" 4
+.IX Item "-mhard-dfp"
+.IP "\fB\-mno\-hard\-dfp\fR" 4
+.IX Item "-mno-hard-dfp"
+.PD
+You use these options to specify which instructions are available on the
+processor you are using.  The default value of these options is
+determined when configuring \s-1GCC. \s0 Specifying the
+\&\fB\-mcpu=\fR\fIcpu_type\fR overrides the specification of these
+options.  We recommend you use the \fB\-mcpu=\fR\fIcpu_type\fR option
+rather than the options listed above.
+.Sp
+Specifying \fB\-mpowerpc\-gpopt\fR allows
+\&\s-1GCC\s0 to use the optional PowerPC architecture instructions in the
+General Purpose group, including floating-point square root.  Specifying
+\&\fB\-mpowerpc\-gfxopt\fR allows \s-1GCC\s0 to
+use the optional PowerPC architecture instructions in the Graphics
+group, including floating-point select.
+.Sp
+The \fB\-mmfcrf\fR option allows \s-1GCC\s0 to generate the move from
+condition register field instruction implemented on the \s-1POWER4\s0
+processor and other processors that support the PowerPC V2.01
+architecture.
+The \fB\-mpopcntb\fR option allows \s-1GCC\s0 to generate the popcount and
+double-precision \s-1FP\s0 reciprocal estimate instruction implemented on the
+\&\s-1POWER5\s0 processor and other processors that support the PowerPC V2.02
+architecture.
+The \fB\-mpopcntd\fR option allows \s-1GCC\s0 to generate the popcount
+instruction implemented on the \s-1POWER7\s0 processor and other processors
+that support the PowerPC V2.06 architecture.
+The \fB\-mfprnd\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 round to
+integer instructions implemented on the \s-1POWER5+\s0 processor and other
+processors that support the PowerPC V2.03 architecture.
+The \fB\-mcmpb\fR option allows \s-1GCC\s0 to generate the compare bytes
+instruction implemented on the \s-1POWER6\s0 processor and other processors
+that support the PowerPC V2.05 architecture.
+The \fB\-mmfpgpr\fR option allows \s-1GCC\s0 to generate the \s-1FP\s0 move to/from
+general-purpose register instructions implemented on the \s-1POWER6X\s0
+processor and other processors that support the extended PowerPC V2.05
+architecture.
+The \fB\-mhard\-dfp\fR option allows \s-1GCC\s0 to generate the decimal
+floating-point instructions implemented on some \s-1POWER\s0 processors.
+.Sp
+The \fB\-mpowerpc64\fR option allows \s-1GCC\s0 to generate the additional
+64\-bit instructions that are found in the full PowerPC64 architecture
+and to treat GPRs as 64\-bit, doubleword quantities.  \s-1GCC\s0 defaults to
+\&\fB\-mno\-powerpc64\fR.
+.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
+.IX Item "-mcpu=cpu_type"
+Set architecture type, register usage, and
+instruction scheduling parameters for machine type \fIcpu_type\fR.
+Supported values for \fIcpu_type\fR are \fB401\fR, \fB403\fR,
+\&\fB405\fR, \fB405fp\fR, \fB440\fR, \fB440fp\fR, \fB464\fR, \fB464fp\fR,
+\&\fB476\fR, \fB476fp\fR, \fB505\fR, \fB601\fR, \fB602\fR, \fB603\fR,
+\&\fB603e\fR, \fB604\fR, \fB604e\fR, \fB620\fR, \fB630\fR, \fB740\fR,
+\&\fB7400\fR, \fB7450\fR, \fB750\fR, \fB801\fR, \fB821\fR, \fB823\fR,
+\&\fB860\fR, \fB970\fR, \fB8540\fR, \fBa2\fR, \fBe300c2\fR,
+\&\fBe300c3\fR, \fBe500mc\fR, \fBe500mc64\fR, \fBe5500\fR,
+\&\fBe6500\fR, \fBec603e\fR, \fBG3\fR, \fBG4\fR, \fBG5\fR,
+\&\fBtitan\fR, \fBpower3\fR, \fBpower4\fR, \fBpower5\fR, \fBpower5+\fR,
+\&\fBpower6\fR, \fBpower6x\fR, \fBpower7\fR, \fBpower8\fR, \fBpowerpc\fR,
+\&\fBpowerpc64\fR, and \fBrs64\fR.
+.Sp
+\&\fB\-mcpu=powerpc\fR, and \fB\-mcpu=powerpc64\fR specify pure 32\-bit
+PowerPC and 64\-bit PowerPC architecture machine
+types, with an appropriate, generic processor model assumed for
+scheduling purposes.
+.Sp
+The other options specify a specific processor.  Code generated under
+those options runs best on that processor, and may not run at all on
+others.
+.Sp
+The \fB\-mcpu\fR options automatically enable or disable the
+following options:
+.Sp
+\&\fB\-maltivec  \-mfprnd  \-mhard\-float  \-mmfcrf  \-mmultiple 
+\&\-mpopcntb \-mpopcntd  \-mpowerpc64 
+\&\-mpowerpc\-gpopt  \-mpowerpc\-gfxopt  \-msingle\-float \-mdouble\-float 
+\&\-msimple\-fpu \-mstring  \-mmulhw  \-mdlmzb  \-mmfpgpr \-mvsx 
+\&\-mcrypto \-mdirect\-move \-mpower8\-fusion \-mpower8\-vector 
+\&\-mquad\-memory \-mquad\-memory\-atomic\fR
+.Sp
+The particular options set for any particular \s-1CPU\s0 varies between
+compiler versions, depending on what setting seems to produce optimal
+code for that \s-1CPU\s0; it doesn't necessarily reflect the actual hardware's
+capabilities.  If you wish to set an individual option to a particular
+value, you may specify it after the \fB\-mcpu\fR option, like
+\&\fB\-mcpu=970 \-mno\-altivec\fR.
+.Sp
+On \s-1AIX,\s0 the \fB\-maltivec\fR and \fB\-mpowerpc64\fR options are
+not enabled or disabled by the \fB\-mcpu\fR option at present because
+\&\s-1AIX\s0 does not have full support for these options.  You may still
+enable or disable them individually if you're sure it'll work in your
+environment.
+.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
+.IX Item "-mtune=cpu_type"
+Set the instruction scheduling parameters for machine type
+\&\fIcpu_type\fR, but do not set the architecture type or register usage,
+as \fB\-mcpu=\fR\fIcpu_type\fR does.  The same
+values for \fIcpu_type\fR are used for \fB\-mtune\fR as for
+\&\fB\-mcpu\fR.  If both are specified, the code generated uses the
+architecture and registers set by \fB\-mcpu\fR, but the
+scheduling parameters set by \fB\-mtune\fR.
+.IP "\fB\-mcmodel=small\fR" 4
+.IX Item "-mcmodel=small"
+Generate PowerPC64 code for the small model: The \s-1TOC\s0 is limited to
+64k.
+.IP "\fB\-mcmodel=medium\fR" 4
+.IX Item "-mcmodel=medium"
+Generate PowerPC64 code for the medium model: The \s-1TOC\s0 and other static
+data may be up to a total of 4G in size.
+.IP "\fB\-mcmodel=large\fR" 4
+.IX Item "-mcmodel=large"
+Generate PowerPC64 code for the large model: The \s-1TOC\s0 may be up to 4G
+in size.  Other data and code is only limited by the 64\-bit address
+space.
+.IP "\fB\-maltivec\fR" 4
+.IX Item "-maltivec"
+.PD 0
+.IP "\fB\-mno\-altivec\fR" 4
+.IX Item "-mno-altivec"
+.PD
+Generate code that uses (does not use) AltiVec instructions, and also
+enable the use of built-in functions that allow more direct access to
+the AltiVec instruction set.  You may also need to set
+\&\fB\-mabi=altivec\fR to adjust the current \s-1ABI\s0 with AltiVec \s-1ABI\s0
+enhancements.
+.Sp
+When \fB\-maltivec\fR is used, rather than \fB\-maltivec=le\fR or
+\&\fB\-maltivec=be\fR, the element order for Altivec intrinsics such
+as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and \f(CW\*(C`vec_insert\*(C'\fR will
+match array element order corresponding to the endianness of the
+target.  That is, element zero identifies the leftmost element in a
+vector register when targeting a big-endian platform, and identifies
+the rightmost element in a vector register when targeting a
+little-endian platform.
+.IP "\fB\-maltivec=be\fR" 4
+.IX Item "-maltivec=be"
+Generate Altivec instructions using big-endian element order,
+regardless of whether the target is big\- or little-endian.  This is
+the default when targeting a big-endian platform.
+.Sp
+The element order is used to interpret element numbers in Altivec
+intrinsics such as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and
+\&\f(CW\*(C`vec_insert\*(C'\fR.  By default, these will match array element order
+corresponding to the endianness for the target.
+.IP "\fB\-maltivec=le\fR" 4
+.IX Item "-maltivec=le"
+Generate Altivec instructions using little-endian element order,
+regardless of whether the target is big\- or little-endian.  This is
+the default when targeting a little-endian platform.  This option is
+currently ignored when targeting a big-endian platform.
+.Sp
+The element order is used to interpret element numbers in Altivec
+intrinsics such as \f(CW\*(C`vec_splat\*(C'\fR, \f(CW\*(C`vec_extract\*(C'\fR, and
+\&\f(CW\*(C`vec_insert\*(C'\fR.  By default, these will match array element order
+corresponding to the endianness for the target.
+.IP "\fB\-mvrsave\fR" 4
+.IX Item "-mvrsave"
+.PD 0
+.IP "\fB\-mno\-vrsave\fR" 4
+.IX Item "-mno-vrsave"
+.PD
+Generate \s-1VRSAVE\s0 instructions when generating AltiVec code.
+.IP "\fB\-mgen\-cell\-microcode\fR" 4
+.IX Item "-mgen-cell-microcode"
+Generate Cell microcode instructions.
+.IP "\fB\-mwarn\-cell\-microcode\fR" 4
+.IX Item "-mwarn-cell-microcode"
+Warn when a Cell microcode instruction is emitted.  An example
+of a Cell microcode instruction is a variable shift.
+.IP "\fB\-msecure\-plt\fR" 4
+.IX Item "-msecure-plt"
+Generate code that allows \fBld\fR and \fBld.so\fR
+to build executables and shared
+libraries with non-executable \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR sections.
+This is a PowerPC
+32\-bit \s-1SYSV ABI\s0 option.
+.IP "\fB\-mbss\-plt\fR" 4
+.IX Item "-mbss-plt"
+Generate code that uses a \s-1BSS \s0\f(CW\*(C`.plt\*(C'\fR section that \fBld.so\fR
+fills in, and
+requires \f(CW\*(C`.plt\*(C'\fR and \f(CW\*(C`.got\*(C'\fR
+sections that are both writable and executable.
+This is a PowerPC 32\-bit \s-1SYSV ABI\s0 option.
+.IP "\fB\-misel\fR" 4
+.IX Item "-misel"
+.PD 0
+.IP "\fB\-mno\-isel\fR" 4
+.IX Item "-mno-isel"
+.PD
+This switch enables or disables the generation of \s-1ISEL\s0 instructions.
+.IP "\fB\-misel=\fR\fIyes/no\fR" 4
+.IX Item "-misel=yes/no"
+This switch has been deprecated.  Use \fB\-misel\fR and
+\&\fB\-mno\-isel\fR instead.
+.IP "\fB\-mspe\fR" 4
+.IX Item "-mspe"
+.PD 0
+.IP "\fB\-mno\-spe\fR" 4
+.IX Item "-mno-spe"
+.PD
+This switch enables or disables the generation of \s-1SPE\s0 simd
+instructions.
+.IP "\fB\-mpaired\fR" 4
+.IX Item "-mpaired"
+.PD 0
+.IP "\fB\-mno\-paired\fR" 4
+.IX Item "-mno-paired"
+.PD
+This switch enables or disables the generation of \s-1PAIRED\s0 simd
+instructions.
+.IP "\fB\-mspe=\fR\fIyes/no\fR" 4
+.IX Item "-mspe=yes/no"
+This option has been deprecated.  Use \fB\-mspe\fR and
+\&\fB\-mno\-spe\fR instead.
+.IP "\fB\-mvsx\fR" 4
+.IX Item "-mvsx"
+.PD 0
+.IP "\fB\-mno\-vsx\fR" 4
+.IX Item "-mno-vsx"
+.PD
+Generate code that uses (does not use) vector/scalar (\s-1VSX\s0)
+instructions, and also enable the use of built-in functions that allow
+more direct access to the \s-1VSX\s0 instruction set.
+.IP "\fB\-mcrypto\fR" 4
+.IX Item "-mcrypto"
+.PD 0
+.IP "\fB\-mno\-crypto\fR" 4
+.IX Item "-mno-crypto"
+.PD
+Enable the use (disable) of the built-in functions that allow direct
+access to the cryptographic instructions that were added in version
+2.07 of the PowerPC \s-1ISA.\s0
+.IP "\fB\-mdirect\-move\fR" 4
+.IX Item "-mdirect-move"
+.PD 0
+.IP "\fB\-mno\-direct\-move\fR" 4
+.IX Item "-mno-direct-move"
+.PD
+Generate code that uses (does not use) the instructions to move data
+between the general purpose registers and the vector/scalar (\s-1VSX\s0)
+registers that were added in version 2.07 of the PowerPC \s-1ISA.\s0
+.IP "\fB\-mpower8\-fusion\fR" 4
+.IX Item "-mpower8-fusion"
+.PD 0
+.IP "\fB\-mno\-power8\-fusion\fR" 4
+.IX Item "-mno-power8-fusion"
+.PD
+Generate code that keeps (does not keeps) some integer operations
+adjacent so that the instructions can be fused together on power8 and
+later processors.
+.IP "\fB\-mpower8\-vector\fR" 4
+.IX Item "-mpower8-vector"
+.PD 0
+.IP "\fB\-mno\-power8\-vector\fR" 4
+.IX Item "-mno-power8-vector"
+.PD
+Generate code that uses (does not use) the vector and scalar
+instructions that were added in version 2.07 of the PowerPC \s-1ISA. \s0 Also
+enable the use of built-in functions that allow more direct access to
+the vector instructions.
+.IP "\fB\-mquad\-memory\fR" 4
+.IX Item "-mquad-memory"
+.PD 0
+.IP "\fB\-mno\-quad\-memory\fR" 4
+.IX Item "-mno-quad-memory"
+.PD
+Generate code that uses (does not use) the non-atomic quad word memory
+instructions.  The \fB\-mquad\-memory\fR option requires use of
+64\-bit mode.
+.IP "\fB\-mquad\-memory\-atomic\fR" 4
+.IX Item "-mquad-memory-atomic"
+.PD 0
+.IP "\fB\-mno\-quad\-memory\-atomic\fR" 4
+.IX Item "-mno-quad-memory-atomic"
+.PD
+Generate code that uses (does not use) the atomic quad word memory
+instructions.  The \fB\-mquad\-memory\-atomic\fR option requires use of
+64\-bit mode.
+.IP "\fB\-mfloat\-gprs=\fR\fIyes/single/double/no\fR" 4
+.IX Item "-mfloat-gprs=yes/single/double/no"
+.PD 0
+.IP "\fB\-mfloat\-gprs\fR" 4
+.IX Item "-mfloat-gprs"
+.PD
+This switch enables or disables the generation of floating-point
+operations on the general-purpose registers for architectures that
+support it.
+.Sp
+The argument \fIyes\fR or \fIsingle\fR enables the use of
+single-precision floating-point operations.
+.Sp
+The argument \fIdouble\fR enables the use of single and
+double-precision floating-point operations.
+.Sp
+The argument \fIno\fR disables floating-point operations on the
+general-purpose registers.
+.Sp
+This option is currently only available on the MPC854x.
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+.PD 0
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.PD
+Generate code for 32\-bit or 64\-bit environments of Darwin and \s-1SVR4\s0
+targets (including GNU/Linux).  The 32\-bit environment sets int, long
+and pointer to 32 bits and generates code that runs on any PowerPC
+variant.  The 64\-bit environment sets int to 32 bits and long and
+pointer to 64 bits, and generates code for PowerPC64, as for
+\&\fB\-mpowerpc64\fR.
+.IP "\fB\-mfull\-toc\fR" 4
+.IX Item "-mfull-toc"
+.PD 0
+.IP "\fB\-mno\-fp\-in\-toc\fR" 4
+.IX Item "-mno-fp-in-toc"
+.IP "\fB\-mno\-sum\-in\-toc\fR" 4
+.IX Item "-mno-sum-in-toc"
+.IP "\fB\-mminimal\-toc\fR" 4
+.IX Item "-mminimal-toc"
+.PD
+Modify generation of the \s-1TOC \s0(Table Of Contents), which is created for
+every executable file.  The \fB\-mfull\-toc\fR option is selected by
+default.  In that case, \s-1GCC\s0 allocates at least one \s-1TOC\s0 entry for
+each unique non-automatic variable reference in your program.  \s-1GCC\s0
+also places floating-point constants in the \s-1TOC. \s0 However, only
+16,384 entries are available in the \s-1TOC.\s0
+.Sp
+If you receive a linker error message that saying you have overflowed
+the available \s-1TOC\s0 space, you can reduce the amount of \s-1TOC\s0 space used
+with the \fB\-mno\-fp\-in\-toc\fR and \fB\-mno\-sum\-in\-toc\fR options.
+\&\fB\-mno\-fp\-in\-toc\fR prevents \s-1GCC\s0 from putting floating-point
+constants in the \s-1TOC\s0 and \fB\-mno\-sum\-in\-toc\fR forces \s-1GCC\s0 to
+generate code to calculate the sum of an address and a constant at
+run time instead of putting that sum into the \s-1TOC. \s0 You may specify one
+or both of these options.  Each causes \s-1GCC\s0 to produce very slightly
+slower and larger code at the expense of conserving \s-1TOC\s0 space.
+.Sp
+If you still run out of space in the \s-1TOC\s0 even when you specify both of
+these options, specify \fB\-mminimal\-toc\fR instead.  This option causes
+\&\s-1GCC\s0 to make only one \s-1TOC\s0 entry for every file.  When you specify this
+option, \s-1GCC\s0 produces code that is slower and larger but which
+uses extremely little \s-1TOC\s0 space.  You may wish to use this option
+only on files that contain less frequently-executed code.
+.IP "\fB\-maix64\fR" 4
+.IX Item "-maix64"
+.PD 0
+.IP "\fB\-maix32\fR" 4
+.IX Item "-maix32"
+.PD
+Enable 64\-bit \s-1AIX ABI\s0 and calling convention: 64\-bit pointers, 64\-bit
+\&\f(CW\*(C`long\*(C'\fR type, and the infrastructure needed to support them.
+Specifying \fB\-maix64\fR implies \fB\-mpowerpc64\fR,
+while \fB\-maix32\fR disables the 64\-bit \s-1ABI\s0 and
+implies \fB\-mno\-powerpc64\fR.  \s-1GCC\s0 defaults to \fB\-maix32\fR.
+.IP "\fB\-mxl\-compat\fR" 4
+.IX Item "-mxl-compat"
+.PD 0
+.IP "\fB\-mno\-xl\-compat\fR" 4
+.IX Item "-mno-xl-compat"
+.PD
+Produce code that conforms more closely to \s-1IBM XL\s0 compiler semantics
+when using AIX-compatible \s-1ABI. \s0 Pass floating-point arguments to
+prototyped functions beyond the register save area (\s-1RSA\s0) on the stack
+in addition to argument FPRs.  Do not assume that most significant
+double in 128\-bit long double value is properly rounded when comparing
+values and converting to double.  Use \s-1XL\s0 symbol names for long double
+support routines.
+.Sp
+The \s-1AIX\s0 calling convention was extended but not initially documented to
+handle an obscure K&R C case of calling a function that takes the
+address of its arguments with fewer arguments than declared.  \s-1IBM XL\s0
+compilers access floating-point arguments that do not fit in the
+\&\s-1RSA\s0 from the stack when a subroutine is compiled without
+optimization.  Because always storing floating-point arguments on the
+stack is inefficient and rarely needed, this option is not enabled by
+default and only is necessary when calling subroutines compiled by \s-1IBM
+XL\s0 compilers without optimization.
+.IP "\fB\-mpe\fR" 4
+.IX Item "-mpe"
+Support \fI\s-1IBM RS/6000 SP\s0\fR \fIParallel Environment\fR (\s-1PE\s0).  Link an
+application written to use message passing with special startup code to
+enable the application to run.  The system must have \s-1PE\s0 installed in the
+standard location (\fI/usr/lpp/ppe.poe/\fR), or the \fIspecs\fR file
+must be overridden with the \fB\-specs=\fR option to specify the
+appropriate directory location.  The Parallel Environment does not
+support threads, so the \fB\-mpe\fR option and the \fB\-pthread\fR
+option are incompatible.
+.IP "\fB\-malign\-natural\fR" 4
+.IX Item "-malign-natural"
+.PD 0
+.IP "\fB\-malign\-power\fR" 4
+.IX Item "-malign-power"
+.PD
+On \s-1AIX,\s0 32\-bit Darwin, and 64\-bit PowerPC GNU/Linux, the option
+\&\fB\-malign\-natural\fR overrides the ABI-defined alignment of larger
+types, such as floating-point doubles, on their natural size-based boundary.
+The option \fB\-malign\-power\fR instructs \s-1GCC\s0 to follow the ABI-specified
+alignment rules.  \s-1GCC\s0 defaults to the standard alignment defined in the \s-1ABI.\s0
+.Sp
+On 64\-bit Darwin, natural alignment is the default, and \fB\-malign\-power\fR
+is not supported.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD 0
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD
+Generate code that does not use (uses) the floating-point register set.
+Software floating-point emulation is provided if you use the
+\&\fB\-msoft\-float\fR option, and pass the option to \s-1GCC\s0 when linking.
+.IP "\fB\-msingle\-float\fR" 4
+.IX Item "-msingle-float"
+.PD 0
+.IP "\fB\-mdouble\-float\fR" 4
+.IX Item "-mdouble-float"
+.PD
+Generate code for single\- or double-precision floating-point operations.
+\&\fB\-mdouble\-float\fR implies \fB\-msingle\-float\fR.
+.IP "\fB\-msimple\-fpu\fR" 4
+.IX Item "-msimple-fpu"
+Do not generate \f(CW\*(C`sqrt\*(C'\fR and \f(CW\*(C`div\*(C'\fR instructions for hardware
+floating-point unit.
+.IP "\fB\-mfpu=\fR\fIname\fR" 4
+.IX Item "-mfpu=name"
+Specify type of floating-point unit.  Valid values for \fIname\fR are
+\&\fBsp_lite\fR (equivalent to \fB\-msingle\-float \-msimple\-fpu\fR),
+\&\fBdp_lite\fR (equivalent to \fB\-mdouble\-float \-msimple\-fpu\fR),
+\&\fBsp_full\fR (equivalent to \fB\-msingle\-float\fR),
+and \fBdp_full\fR (equivalent to \fB\-mdouble\-float\fR).
+.IP "\fB\-mxilinx\-fpu\fR" 4
+.IX Item "-mxilinx-fpu"
+Perform optimizations for the floating-point unit on Xilinx \s-1PPC 405/440.\s0
+.IP "\fB\-mmultiple\fR" 4
+.IX Item "-mmultiple"
+.PD 0
+.IP "\fB\-mno\-multiple\fR" 4
+.IX Item "-mno-multiple"
+.PD
+Generate code that uses (does not use) the load multiple word
+instructions and the store multiple word instructions.  These
+instructions are generated by default on \s-1POWER\s0 systems, and not
+generated on PowerPC systems.  Do not use \fB\-mmultiple\fR on little-endian
+PowerPC systems, since those instructions do not work when the
+processor is in little-endian mode.  The exceptions are \s-1PPC740\s0 and
+\&\s-1PPC750\s0 which permit these instructions in little-endian mode.
+.IP "\fB\-mstring\fR" 4
+.IX Item "-mstring"
+.PD 0
+.IP "\fB\-mno\-string\fR" 4
+.IX Item "-mno-string"
+.PD
+Generate code that uses (does not use) the load string instructions
+and the store string word instructions to save multiple registers and
+do small block moves.  These instructions are generated by default on
+\&\s-1POWER\s0 systems, and not generated on PowerPC systems.  Do not use
+\&\fB\-mstring\fR on little-endian PowerPC systems, since those
+instructions do not work when the processor is in little-endian mode.
+The exceptions are \s-1PPC740\s0 and \s-1PPC750\s0 which permit these instructions
+in little-endian mode.
+.IP "\fB\-mupdate\fR" 4
+.IX Item "-mupdate"
+.PD 0
+.IP "\fB\-mno\-update\fR" 4
+.IX Item "-mno-update"
+.PD
+Generate code that uses (does not use) the load or store instructions
+that update the base register to the address of the calculated memory
+location.  These instructions are generated by default.  If you use
+\&\fB\-mno\-update\fR, there is a small window between the time that the
+stack pointer is updated and the address of the previous frame is
+stored, which means code that walks the stack frame across interrupts or
+signals may get corrupted data.
+.IP "\fB\-mavoid\-indexed\-addresses\fR" 4
+.IX Item "-mavoid-indexed-addresses"
+.PD 0
+.IP "\fB\-mno\-avoid\-indexed\-addresses\fR" 4
+.IX Item "-mno-avoid-indexed-addresses"
+.PD
+Generate code that tries to avoid (not avoid) the use of indexed load
+or store instructions. These instructions can incur a performance
+penalty on Power6 processors in certain situations, such as when
+stepping through large arrays that cross a 16M boundary.  This option
+is enabled by default when targeting Power6 and disabled otherwise.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Generate code that uses (does not use) the floating-point multiply and
+accumulate instructions.  These instructions are generated by default
+if hardware floating point is used.  The machine-dependent
+\&\fB\-mfused\-madd\fR option is now mapped to the machine-independent
+\&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
+mapped to \fB\-ffp\-contract=off\fR.
+.IP "\fB\-mmulhw\fR" 4
+.IX Item "-mmulhw"
+.PD 0
+.IP "\fB\-mno\-mulhw\fR" 4
+.IX Item "-mno-mulhw"
+.PD
+Generate code that uses (does not use) the half-word multiply and
+multiply-accumulate instructions on the \s-1IBM 405, 440, 464\s0 and 476 processors.
+These instructions are generated by default when targeting those
+processors.
+.IP "\fB\-mdlmzb\fR" 4
+.IX Item "-mdlmzb"
+.PD 0
+.IP "\fB\-mno\-dlmzb\fR" 4
+.IX Item "-mno-dlmzb"
+.PD
+Generate code that uses (does not use) the string-search \fBdlmzb\fR
+instruction on the \s-1IBM 405, 440, 464\s0 and 476 processors.  This instruction is
+generated by default when targeting those processors.
+.IP "\fB\-mno\-bit\-align\fR" 4
+.IX Item "-mno-bit-align"
+.PD 0
+.IP "\fB\-mbit\-align\fR" 4
+.IX Item "-mbit-align"
+.PD
+On System V.4 and embedded PowerPC systems do not (do) force structures
+and unions that contain bit-fields to be aligned to the base type of the
+bit-field.
+.Sp
+For example, by default a structure containing nothing but 8
+\&\f(CW\*(C`unsigned\*(C'\fR bit-fields of length 1 is aligned to a 4\-byte
+boundary and has a size of 4 bytes.  By using \fB\-mno\-bit\-align\fR,
+the structure is aligned to a 1\-byte boundary and is 1 byte in
+size.
+.IP "\fB\-mno\-strict\-align\fR" 4
+.IX Item "-mno-strict-align"
+.PD 0
+.IP "\fB\-mstrict\-align\fR" 4
+.IX Item "-mstrict-align"
+.PD
+On System V.4 and embedded PowerPC systems do not (do) assume that
+unaligned memory references are handled by the system.
+.IP "\fB\-mrelocatable\fR" 4
+.IX Item "-mrelocatable"
+.PD 0
+.IP "\fB\-mno\-relocatable\fR" 4
+.IX Item "-mno-relocatable"
+.PD
+Generate code that allows (does not allow) a static executable to be
+relocated to a different address at run time.  A simple embedded
+PowerPC system loader should relocate the entire contents of
+\&\f(CW\*(C`.got2\*(C'\fR and 4\-byte locations listed in the \f(CW\*(C`.fixup\*(C'\fR section,
+a table of 32\-bit addresses generated by this option.  For this to
+work, all objects linked together must be compiled with
+\&\fB\-mrelocatable\fR or \fB\-mrelocatable\-lib\fR.
+\&\fB\-mrelocatable\fR code aligns the stack to an 8\-byte boundary.
+.IP "\fB\-mrelocatable\-lib\fR" 4
+.IX Item "-mrelocatable-lib"
+.PD 0
+.IP "\fB\-mno\-relocatable\-lib\fR" 4
+.IX Item "-mno-relocatable-lib"
+.PD
+Like \fB\-mrelocatable\fR, \fB\-mrelocatable\-lib\fR generates a
+\&\f(CW\*(C`.fixup\*(C'\fR section to allow static executables to be relocated at
+run time, but \fB\-mrelocatable\-lib\fR does not use the smaller stack
+alignment of \fB\-mrelocatable\fR.  Objects compiled with
+\&\fB\-mrelocatable\-lib\fR may be linked with objects compiled with
+any combination of the \fB\-mrelocatable\fR options.
+.IP "\fB\-mno\-toc\fR" 4
+.IX Item "-mno-toc"
+.PD 0
+.IP "\fB\-mtoc\fR" 4
+.IX Item "-mtoc"
+.PD
+On System V.4 and embedded PowerPC systems do not (do) assume that
+register 2 contains a pointer to a global area pointing to the addresses
+used in the program.
+.IP "\fB\-mlittle\fR" 4
+.IX Item "-mlittle"
+.PD 0
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+.PD
+On System V.4 and embedded PowerPC systems compile code for the
+processor in little-endian mode.  The \fB\-mlittle\-endian\fR option is
+the same as \fB\-mlittle\fR.
+.IP "\fB\-mbig\fR" 4
+.IX Item "-mbig"
+.PD 0
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+.PD
+On System V.4 and embedded PowerPC systems compile code for the
+processor in big-endian mode.  The \fB\-mbig\-endian\fR option is
+the same as \fB\-mbig\fR.
+.IP "\fB\-mdynamic\-no\-pic\fR" 4
+.IX Item "-mdynamic-no-pic"
+On Darwin and Mac \s-1OS X\s0 systems, compile code so that it is not
+relocatable, but that its external references are relocatable.  The
+resulting code is suitable for applications, but not shared
+libraries.
+.IP "\fB\-msingle\-pic\-base\fR" 4
+.IX Item "-msingle-pic-base"
+Treat the register used for \s-1PIC\s0 addressing as read-only, rather than
+loading it in the prologue for each function.  The runtime system is
+responsible for initializing this register with an appropriate value
+before execution begins.
+.IP "\fB\-mprioritize\-restricted\-insns=\fR\fIpriority\fR" 4
+.IX Item "-mprioritize-restricted-insns=priority"
+This option controls the priority that is assigned to
+dispatch-slot restricted instructions during the second scheduling
+pass.  The argument \fIpriority\fR takes the value \fB0\fR, \fB1\fR,
+or \fB2\fR to assign no, highest, or second-highest (respectively) 
+priority to dispatch-slot restricted
+instructions.
+.IP "\fB\-msched\-costly\-dep=\fR\fIdependence_type\fR" 4
+.IX Item "-msched-costly-dep=dependence_type"
+This option controls which dependences are considered costly
+by the target during instruction scheduling.  The argument
+\&\fIdependence_type\fR takes one of the following values:
+.RS 4
+.IP "\fBno\fR" 4
+.IX Item "no"
+No dependence is costly.
+.IP "\fBall\fR" 4
+.IX Item "all"
+All dependences are costly.
+.IP "\fBtrue_store_to_load\fR" 4
+.IX Item "true_store_to_load"
+A true dependence from store to load is costly.
+.IP "\fBstore_to_load\fR" 4
+.IX Item "store_to_load"
+Any dependence from store to load is costly.
+.IP "\fInumber\fR" 4
+.IX Item "number"
+Any dependence for which the latency is greater than or equal to 
+\&\fInumber\fR is costly.
+.RE
+.RS 4
+.RE
+.IP "\fB\-minsert\-sched\-nops=\fR\fIscheme\fR" 4
+.IX Item "-minsert-sched-nops=scheme"
+This option controls which \s-1NOP\s0 insertion scheme is used during
+the second scheduling pass.  The argument \fIscheme\fR takes one of the
+following values:
+.RS 4
+.IP "\fBno\fR" 4
+.IX Item "no"
+Don't insert NOPs.
+.IP "\fBpad\fR" 4
+.IX Item "pad"
+Pad with NOPs any dispatch group that has vacant issue slots,
+according to the scheduler's grouping.
+.IP "\fBregroup_exact\fR" 4
+.IX Item "regroup_exact"
+Insert NOPs to force costly dependent insns into
+separate groups.  Insert exactly as many NOPs as needed to force an insn
+to a new group, according to the estimated processor grouping.
+.IP "\fInumber\fR" 4
+.IX Item "number"
+Insert NOPs to force costly dependent insns into
+separate groups.  Insert \fInumber\fR NOPs to force an insn to a new group.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mcall\-sysv\fR" 4
+.IX Item "-mcall-sysv"
+On System V.4 and embedded PowerPC systems compile code using calling
+conventions that adhere to the March 1995 draft of the System V
+Application Binary Interface, PowerPC processor supplement.  This is the
+default unless you configured \s-1GCC\s0 using \fBpowerpc\-*\-eabiaix\fR.
+.IP "\fB\-mcall\-sysv\-eabi\fR" 4
+.IX Item "-mcall-sysv-eabi"
+.PD 0
+.IP "\fB\-mcall\-eabi\fR" 4
+.IX Item "-mcall-eabi"
+.PD
+Specify both \fB\-mcall\-sysv\fR and \fB\-meabi\fR options.
+.IP "\fB\-mcall\-sysv\-noeabi\fR" 4
+.IX Item "-mcall-sysv-noeabi"
+Specify both \fB\-mcall\-sysv\fR and \fB\-mno\-eabi\fR options.
+.IP "\fB\-mcall\-aixdesc\fR" 4
+.IX Item "-mcall-aixdesc"
+On System V.4 and embedded PowerPC systems compile code for the \s-1AIX\s0
+operating system.
+.IP "\fB\-mcall\-linux\fR" 4
+.IX Item "-mcall-linux"
+On System V.4 and embedded PowerPC systems compile code for the
+Linux-based \s-1GNU\s0 system.
+.IP "\fB\-mcall\-freebsd\fR" 4
+.IX Item "-mcall-freebsd"
+On System V.4 and embedded PowerPC systems compile code for the
+FreeBSD operating system.
+.IP "\fB\-mcall\-netbsd\fR" 4
+.IX Item "-mcall-netbsd"
+On System V.4 and embedded PowerPC systems compile code for the
+NetBSD operating system.
+.IP "\fB\-mcall\-openbsd\fR" 4
+.IX Item "-mcall-openbsd"
+On System V.4 and embedded PowerPC systems compile code for the
+OpenBSD operating system.
+.IP "\fB\-maix\-struct\-return\fR" 4
+.IX Item "-maix-struct-return"
+Return all structures in memory (as specified by the \s-1AIX ABI\s0).
+.IP "\fB\-msvr4\-struct\-return\fR" 4
+.IX Item "-msvr4-struct-return"
+Return structures smaller than 8 bytes in registers (as specified by the
+\&\s-1SVR4 ABI\s0).
+.IP "\fB\-mabi=\fR\fIabi-type\fR" 4
+.IX Item "-mabi=abi-type"
+Extend the current \s-1ABI\s0 with a particular extension, or remove such extension.
+Valid values are \fIaltivec\fR, \fIno-altivec\fR, \fIspe\fR,
+\&\fIno-spe\fR, \fIibmlongdouble\fR, \fIieeelongdouble\fR,
+\&\fIelfv1\fR, \fIelfv2\fR.
+.IP "\fB\-mabi=spe\fR" 4
+.IX Item "-mabi=spe"
+Extend the current \s-1ABI\s0 with \s-1SPE ABI\s0 extensions.  This does not change
+the default \s-1ABI,\s0 instead it adds the \s-1SPE ABI\s0 extensions to the current
+\&\s-1ABI.\s0
+.IP "\fB\-mabi=no\-spe\fR" 4
+.IX Item "-mabi=no-spe"
+Disable Book-E \s-1SPE ABI\s0 extensions for the current \s-1ABI.\s0
+.IP "\fB\-mabi=ibmlongdouble\fR" 4
+.IX Item "-mabi=ibmlongdouble"
+Change the current \s-1ABI\s0 to use \s-1IBM\s0 extended-precision long double.
+This is a PowerPC 32\-bit \s-1SYSV ABI\s0 option.
+.IP "\fB\-mabi=ieeelongdouble\fR" 4
+.IX Item "-mabi=ieeelongdouble"
+Change the current \s-1ABI\s0 to use \s-1IEEE\s0 extended-precision long double.
+This is a PowerPC 32\-bit Linux \s-1ABI\s0 option.
+.IP "\fB\-mabi=elfv1\fR" 4
+.IX Item "-mabi=elfv1"
+Change the current \s-1ABI\s0 to use the ELFv1 \s-1ABI.\s0
+This is the default \s-1ABI\s0 for big-endian PowerPC 64\-bit Linux.
+Overriding the default \s-1ABI\s0 requires special system support and is
+likely to fail in spectacular ways.
+.IP "\fB\-mabi=elfv2\fR" 4
+.IX Item "-mabi=elfv2"
+Change the current \s-1ABI\s0 to use the ELFv2 \s-1ABI.\s0
+This is the default \s-1ABI\s0 for little-endian PowerPC 64\-bit Linux.
+Overriding the default \s-1ABI\s0 requires special system support and is
+likely to fail in spectacular ways.
+.IP "\fB\-mprototype\fR" 4
+.IX Item "-mprototype"
+.PD 0
+.IP "\fB\-mno\-prototype\fR" 4
+.IX Item "-mno-prototype"
+.PD
+On System V.4 and embedded PowerPC systems assume that all calls to
+variable argument functions are properly prototyped.  Otherwise, the
+compiler must insert an instruction before every non-prototyped call to
+set or clear bit 6 of the condition code register (\fI\s-1CR\s0\fR) to
+indicate whether floating-point values are passed in the floating-point
+registers in case the function takes variable arguments.  With
+\&\fB\-mprototype\fR, only calls to prototyped variable argument functions
+set or clear the bit.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+On embedded PowerPC systems, assume that the startup module is called
+\&\fIsim\-crt0.o\fR and that the standard C libraries are \fIlibsim.a\fR and
+\&\fIlibc.a\fR.  This is the default for \fBpowerpc\-*\-eabisim\fR
+configurations.
+.IP "\fB\-mmvme\fR" 4
+.IX Item "-mmvme"
+On embedded PowerPC systems, assume that the startup module is called
+\&\fIcrt0.o\fR and the standard C libraries are \fIlibmvme.a\fR and
+\&\fIlibc.a\fR.
+.IP "\fB\-mads\fR" 4
+.IX Item "-mads"
+On embedded PowerPC systems, assume that the startup module is called
+\&\fIcrt0.o\fR and the standard C libraries are \fIlibads.a\fR and
+\&\fIlibc.a\fR.
+.IP "\fB\-myellowknife\fR" 4
+.IX Item "-myellowknife"
+On embedded PowerPC systems, assume that the startup module is called
+\&\fIcrt0.o\fR and the standard C libraries are \fIlibyk.a\fR and
+\&\fIlibc.a\fR.
+.IP "\fB\-mvxworks\fR" 4
+.IX Item "-mvxworks"
+On System V.4 and embedded PowerPC systems, specify that you are
+compiling for a VxWorks system.
+.IP "\fB\-memb\fR" 4
+.IX Item "-memb"
+On embedded PowerPC systems, set the \fI\s-1PPC_EMB\s0\fR bit in the \s-1ELF\s0 flags
+header to indicate that \fBeabi\fR extended relocations are used.
+.IP "\fB\-meabi\fR" 4
+.IX Item "-meabi"
+.PD 0
+.IP "\fB\-mno\-eabi\fR" 4
+.IX Item "-mno-eabi"
+.PD
+On System V.4 and embedded PowerPC systems do (do not) adhere to the
+Embedded Applications Binary Interface (\s-1EABI\s0), which is a set of
+modifications to the System V.4 specifications.  Selecting \fB\-meabi\fR
+means that the stack is aligned to an 8\-byte boundary, a function
+\&\f(CW\*(C`_\|_eabi\*(C'\fR is called from \f(CW\*(C`main\*(C'\fR to set up the \s-1EABI\s0
+environment, and the \fB\-msdata\fR option can use both \f(CW\*(C`r2\*(C'\fR and
+\&\f(CW\*(C`r13\*(C'\fR to point to two separate small data areas.  Selecting
+\&\fB\-mno\-eabi\fR means that the stack is aligned to a 16\-byte boundary,
+no \s-1EABI\s0 initialization function is called from \f(CW\*(C`main\*(C'\fR, and the
+\&\fB\-msdata\fR option only uses \f(CW\*(C`r13\*(C'\fR to point to a single
+small data area.  The \fB\-meabi\fR option is on by default if you
+configured \s-1GCC\s0 using one of the \fBpowerpc*\-*\-eabi*\fR options.
+.IP "\fB\-msdata=eabi\fR" 4
+.IX Item "-msdata=eabi"
+On System V.4 and embedded PowerPC systems, put small initialized
+\&\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata2\fR section, which
+is pointed to by register \f(CW\*(C`r2\*(C'\fR.  Put small initialized
+non\-\f(CW\*(C`const\*(C'\fR global and static data in the \fB.sdata\fR section,
+which is pointed to by register \f(CW\*(C`r13\*(C'\fR.  Put small uninitialized
+global and static data in the \fB.sbss\fR section, which is adjacent to
+the \fB.sdata\fR section.  The \fB\-msdata=eabi\fR option is
+incompatible with the \fB\-mrelocatable\fR option.  The
+\&\fB\-msdata=eabi\fR option also sets the \fB\-memb\fR option.
+.IP "\fB\-msdata=sysv\fR" 4
+.IX Item "-msdata=sysv"
+On System V.4 and embedded PowerPC systems, put small global and static
+data in the \fB.sdata\fR section, which is pointed to by register
+\&\f(CW\*(C`r13\*(C'\fR.  Put small uninitialized global and static data in the
+\&\fB.sbss\fR section, which is adjacent to the \fB.sdata\fR section.
+The \fB\-msdata=sysv\fR option is incompatible with the
+\&\fB\-mrelocatable\fR option.
+.IP "\fB\-msdata=default\fR" 4
+.IX Item "-msdata=default"
+.PD 0
+.IP "\fB\-msdata\fR" 4
+.IX Item "-msdata"
+.PD
+On System V.4 and embedded PowerPC systems, if \fB\-meabi\fR is used,
+compile code the same as \fB\-msdata=eabi\fR, otherwise compile code the
+same as \fB\-msdata=sysv\fR.
+.IP "\fB\-msdata=data\fR" 4
+.IX Item "-msdata=data"
+On System V.4 and embedded PowerPC systems, put small global
+data in the \fB.sdata\fR section.  Put small uninitialized global
+data in the \fB.sbss\fR section.  Do not use register \f(CW\*(C`r13\*(C'\fR
+to address small data however.  This is the default behavior unless
+other \fB\-msdata\fR options are used.
+.IP "\fB\-msdata=none\fR" 4
+.IX Item "-msdata=none"
+.PD 0
+.IP "\fB\-mno\-sdata\fR" 4
+.IX Item "-mno-sdata"
+.PD
+On embedded PowerPC systems, put all initialized global and static data
+in the \fB.data\fR section, and all uninitialized data in the
+\&\fB.bss\fR section.
+.IP "\fB\-mblock\-move\-inline\-limit=\fR\fInum\fR" 4
+.IX Item "-mblock-move-inline-limit=num"
+Inline all block moves (such as calls to \f(CW\*(C`memcpy\*(C'\fR or structure
+copies) less than or equal to \fInum\fR bytes.  The minimum value for
+\&\fInum\fR is 32 bytes on 32\-bit targets and 64 bytes on 64\-bit
+targets.  The default value is target-specific.
+.IP "\fB\-G\fR \fInum\fR" 4
+.IX Item "-G num"
+On embedded PowerPC systems, put global and static items less than or
+equal to \fInum\fR bytes into the small data or \s-1BSS\s0 sections instead of
+the normal data or \s-1BSS\s0 section.  By default, \fInum\fR is 8.  The
+\&\fB\-G\fR \fInum\fR switch is also passed to the linker.
+All modules should be compiled with the same \fB\-G\fR \fInum\fR value.
+.IP "\fB\-mregnames\fR" 4
+.IX Item "-mregnames"
+.PD 0
+.IP "\fB\-mno\-regnames\fR" 4
+.IX Item "-mno-regnames"
+.PD
+On System V.4 and embedded PowerPC systems do (do not) emit register
+names in the assembly language output using symbolic forms.
+.IP "\fB\-mlongcall\fR" 4
+.IX Item "-mlongcall"
+.PD 0
+.IP "\fB\-mno\-longcall\fR" 4
+.IX Item "-mno-longcall"
+.PD
+By default assume that all calls are far away so that a longer and more
+expensive calling sequence is required.  This is required for calls
+farther than 32 megabytes (33,554,432 bytes) from the current location.
+A short call is generated if the compiler knows
+the call cannot be that far away.  This setting can be overridden by
+the \f(CW\*(C`shortcall\*(C'\fR function attribute, or by \f(CW\*(C`#pragma
+longcall(0)\*(C'\fR.
+.Sp
+Some linkers are capable of detecting out-of-range calls and generating
+glue code on the fly.  On these systems, long calls are unnecessary and
+generate slower code.  As of this writing, the \s-1AIX\s0 linker can do this,
+as can the \s-1GNU\s0 linker for PowerPC/64.  It is planned to add this feature
+to the \s-1GNU\s0 linker for 32\-bit PowerPC systems as well.
+.Sp
+On Darwin/PPC systems, \f(CW\*(C`#pragma longcall\*(C'\fR generates \f(CW\*(C`jbsr
+callee, L42\*(C'\fR, plus a \fIbranch island\fR (glue code).  The two target
+addresses represent the callee and the branch island.  The
+Darwin/PPC linker prefers the first address and generates a \f(CW\*(C`bl
+callee\*(C'\fR if the \s-1PPC \s0\f(CW\*(C`bl\*(C'\fR instruction reaches the callee directly;
+otherwise, the linker generates \f(CW\*(C`bl L42\*(C'\fR to call the branch
+island.  The branch island is appended to the body of the
+calling function; it computes the full 32\-bit address of the callee
+and jumps to it.
+.Sp
+On Mach-O (Darwin) systems, this option directs the compiler emit to
+the glue for every direct call, and the Darwin linker decides whether
+to use or discard it.
+.Sp
+In the future, \s-1GCC\s0 may ignore all longcall specifications
+when the linker is known to generate glue.
+.IP "\fB\-mtls\-markers\fR" 4
+.IX Item "-mtls-markers"
+.PD 0
+.IP "\fB\-mno\-tls\-markers\fR" 4
+.IX Item "-mno-tls-markers"
+.PD
+Mark (do not mark) calls to \f(CW\*(C`_\|_tls_get_addr\*(C'\fR with a relocation
+specifying the function argument.  The relocation allows the linker to
+reliably associate function call with argument setup instructions for
+\&\s-1TLS\s0 optimization, which in turn allows \s-1GCC\s0 to better schedule the
+sequence.
+.IP "\fB\-pthread\fR" 4
+.IX Item "-pthread"
+Adds support for multithreading with the \fIpthreads\fR library.
+This option sets flags for both the preprocessor and linker.
+.IP "\fB\-mrecip\fR" 4
+.IX Item "-mrecip"
+.PD 0
+.IP "\fB\-mno\-recip\fR" 4
+.IX Item "-mno-recip"
+.PD
+This option enables use of the reciprocal estimate and
+reciprocal square root estimate instructions with additional
+Newton-Raphson steps to increase precision instead of doing a divide or
+square root and divide for floating-point arguments.  You should use
+the \fB\-ffast\-math\fR option when using \fB\-mrecip\fR (or at
+least \fB\-funsafe\-math\-optimizations\fR,
+\&\fB\-finite\-math\-only\fR, \fB\-freciprocal\-math\fR and
+\&\fB\-fno\-trapping\-math\fR).  Note that while the throughput of the
+sequence is generally higher than the throughput of the non-reciprocal
+instruction, the precision of the sequence can be decreased by up to 2
+ulp (i.e. the inverse of 1.0 equals 0.99999994) for reciprocal square
+roots.
+.IP "\fB\-mrecip=\fR\fIopt\fR" 4
+.IX Item "-mrecip=opt"
+This option controls which reciprocal estimate instructions
+may be used.  \fIopt\fR is a comma-separated list of options, which may
+be preceded by a \f(CW\*(C`!\*(C'\fR to invert the option:
+\&\f(CW\*(C`all\*(C'\fR: enable all estimate instructions,
+\&\f(CW\*(C`default\*(C'\fR: enable the default instructions, equivalent to \fB\-mrecip\fR,
+\&\f(CW\*(C`none\*(C'\fR: disable all estimate instructions, equivalent to \fB\-mno\-recip\fR;
+\&\f(CW\*(C`div\*(C'\fR: enable the reciprocal approximation instructions for both single and double precision;
+\&\f(CW\*(C`divf\*(C'\fR: enable the single-precision reciprocal approximation instructions;
+\&\f(CW\*(C`divd\*(C'\fR: enable the double-precision reciprocal approximation instructions;
+\&\f(CW\*(C`rsqrt\*(C'\fR: enable the reciprocal square root approximation instructions for both single and double precision;
+\&\f(CW\*(C`rsqrtf\*(C'\fR: enable the single-precision reciprocal square root approximation instructions;
+\&\f(CW\*(C`rsqrtd\*(C'\fR: enable the double-precision reciprocal square root approximation instructions;
+.Sp
+So, for example, \fB\-mrecip=all,!rsqrtd\fR enables
+all of the reciprocal estimate instructions, except for the
+\&\f(CW\*(C`FRSQRTE\*(C'\fR, \f(CW\*(C`XSRSQRTEDP\*(C'\fR, and \f(CW\*(C`XVRSQRTEDP\*(C'\fR instructions
+which handle the double-precision reciprocal square root calculations.
+.IP "\fB\-mrecip\-precision\fR" 4
+.IX Item "-mrecip-precision"
+.PD 0
+.IP "\fB\-mno\-recip\-precision\fR" 4
+.IX Item "-mno-recip-precision"
+.PD
+Assume (do not assume) that the reciprocal estimate instructions
+provide higher-precision estimates than is mandated by the PowerPC
+\&\s-1ABI. \s0 Selecting \fB\-mcpu=power6\fR, \fB\-mcpu=power7\fR or
+\&\fB\-mcpu=power8\fR automatically selects \fB\-mrecip\-precision\fR.
+The double-precision square root estimate instructions are not generated by
+default on low-precision machines, since they do not provide an
+estimate that converges after three steps.
+.IP "\fB\-mveclibabi=\fR\fItype\fR" 4
+.IX Item "-mveclibabi=type"
+Specifies the \s-1ABI\s0 type to use for vectorizing intrinsics using an
+external library.  The only type supported at present is \f(CW\*(C`mass\*(C'\fR,
+which specifies to use \s-1IBM\s0's Mathematical Acceleration Subsystem
+(\s-1MASS\s0) libraries for vectorizing intrinsics using external libraries.
+\&\s-1GCC\s0 currently emits calls to \f(CW\*(C`acosd2\*(C'\fR, \f(CW\*(C`acosf4\*(C'\fR,
+\&\f(CW\*(C`acoshd2\*(C'\fR, \f(CW\*(C`acoshf4\*(C'\fR, \f(CW\*(C`asind2\*(C'\fR, \f(CW\*(C`asinf4\*(C'\fR,
+\&\f(CW\*(C`asinhd2\*(C'\fR, \f(CW\*(C`asinhf4\*(C'\fR, \f(CW\*(C`atan2d2\*(C'\fR, \f(CW\*(C`atan2f4\*(C'\fR,
+\&\f(CW\*(C`atand2\*(C'\fR, \f(CW\*(C`atanf4\*(C'\fR, \f(CW\*(C`atanhd2\*(C'\fR, \f(CW\*(C`atanhf4\*(C'\fR,
+\&\f(CW\*(C`cbrtd2\*(C'\fR, \f(CW\*(C`cbrtf4\*(C'\fR, \f(CW\*(C`cosd2\*(C'\fR, \f(CW\*(C`cosf4\*(C'\fR,
+\&\f(CW\*(C`coshd2\*(C'\fR, \f(CW\*(C`coshf4\*(C'\fR, \f(CW\*(C`erfcd2\*(C'\fR, \f(CW\*(C`erfcf4\*(C'\fR,
+\&\f(CW\*(C`erfd2\*(C'\fR, \f(CW\*(C`erff4\*(C'\fR, \f(CW\*(C`exp2d2\*(C'\fR, \f(CW\*(C`exp2f4\*(C'\fR,
+\&\f(CW\*(C`expd2\*(C'\fR, \f(CW\*(C`expf4\*(C'\fR, \f(CW\*(C`expm1d2\*(C'\fR, \f(CW\*(C`expm1f4\*(C'\fR,
+\&\f(CW\*(C`hypotd2\*(C'\fR, \f(CW\*(C`hypotf4\*(C'\fR, \f(CW\*(C`lgammad2\*(C'\fR, \f(CW\*(C`lgammaf4\*(C'\fR,
+\&\f(CW\*(C`log10d2\*(C'\fR, \f(CW\*(C`log10f4\*(C'\fR, \f(CW\*(C`log1pd2\*(C'\fR, \f(CW\*(C`log1pf4\*(C'\fR,
+\&\f(CW\*(C`log2d2\*(C'\fR, \f(CW\*(C`log2f4\*(C'\fR, \f(CW\*(C`logd2\*(C'\fR, \f(CW\*(C`logf4\*(C'\fR,
+\&\f(CW\*(C`powd2\*(C'\fR, \f(CW\*(C`powf4\*(C'\fR, \f(CW\*(C`sind2\*(C'\fR, \f(CW\*(C`sinf4\*(C'\fR, \f(CW\*(C`sinhd2\*(C'\fR,
+\&\f(CW\*(C`sinhf4\*(C'\fR, \f(CW\*(C`sqrtd2\*(C'\fR, \f(CW\*(C`sqrtf4\*(C'\fR, \f(CW\*(C`tand2\*(C'\fR,
+\&\f(CW\*(C`tanf4\*(C'\fR, \f(CW\*(C`tanhd2\*(C'\fR, and \f(CW\*(C`tanhf4\*(C'\fR when generating code
+for power7.  Both \fB\-ftree\-vectorize\fR and
+\&\fB\-funsafe\-math\-optimizations\fR must also be enabled.  The \s-1MASS\s0
+libraries must be specified at link time.
+.IP "\fB\-mfriz\fR" 4
+.IX Item "-mfriz"
+.PD 0
+.IP "\fB\-mno\-friz\fR" 4
+.IX Item "-mno-friz"
+.PD
+Generate (do not generate) the \f(CW\*(C`friz\*(C'\fR instruction when the
+\&\fB\-funsafe\-math\-optimizations\fR option is used to optimize
+rounding of floating-point values to 64\-bit integer and back to floating
+point.  The \f(CW\*(C`friz\*(C'\fR instruction does not return the same value if
+the floating-point number is too large to fit in an integer.
+.IP "\fB\-mpointers\-to\-nested\-functions\fR" 4
+.IX Item "-mpointers-to-nested-functions"
+.PD 0
+.IP "\fB\-mno\-pointers\-to\-nested\-functions\fR" 4
+.IX Item "-mno-pointers-to-nested-functions"
+.PD
+Generate (do not generate) code to load up the static chain register
+(\fIr11\fR) when calling through a pointer on \s-1AIX\s0 and 64\-bit Linux
+systems where a function pointer points to a 3\-word descriptor giving
+the function address, \s-1TOC\s0 value to be loaded in register \fIr2\fR, and
+static chain value to be loaded in register \fIr11\fR.  The
+\&\fB\-mpointers\-to\-nested\-functions\fR is on by default.  You cannot
+call through pointers to nested functions or pointers
+to functions compiled in other languages that use the static chain if
+you use the \fB\-mno\-pointers\-to\-nested\-functions\fR.
+.IP "\fB\-msave\-toc\-indirect\fR" 4
+.IX Item "-msave-toc-indirect"
+.PD 0
+.IP "\fB\-mno\-save\-toc\-indirect\fR" 4
+.IX Item "-mno-save-toc-indirect"
+.PD
+Generate (do not generate) code to save the \s-1TOC\s0 value in the reserved
+stack location in the function prologue if the function calls through
+a pointer on \s-1AIX\s0 and 64\-bit Linux systems.  If the \s-1TOC\s0 value is not
+saved in the prologue, it is saved just before the call through the
+pointer.  The \fB\-mno\-save\-toc\-indirect\fR option is the default.
+.IP "\fB\-mcompat\-align\-parm\fR" 4
+.IX Item "-mcompat-align-parm"
+.PD 0
+.IP "\fB\-mno\-compat\-align\-parm\fR" 4
+.IX Item "-mno-compat-align-parm"
+.PD
+Generate (do not generate) code to pass structure parameters with a
+maximum alignment of 64 bits, for compatibility with older versions
+of \s-1GCC.\s0
+.Sp
+Older versions of \s-1GCC \s0(prior to 4.9.0) incorrectly did not align a
+structure parameter on a 128\-bit boundary when that structure contained
+a member requiring 128\-bit alignment.  This is corrected in more
+recent versions of \s-1GCC. \s0 This option may be used to generate code
+that is compatible with functions compiled with older versions of
+\&\s-1GCC.\s0
+.Sp
+The \fB\-mno\-compat\-align\-parm\fR option is the default.
+.PP
+\fI\s-1RX\s0 Options\fR
+.IX Subsection "RX Options"
+.PP
+These command-line options are defined for \s-1RX\s0 targets:
+.IP "\fB\-m64bit\-doubles\fR" 4
+.IX Item "-m64bit-doubles"
+.PD 0
+.IP "\fB\-m32bit\-doubles\fR" 4
+.IX Item "-m32bit-doubles"
+.PD
+Make the \f(CW\*(C`double\*(C'\fR data type be 64 bits (\fB\-m64bit\-doubles\fR)
+or 32 bits (\fB\-m32bit\-doubles\fR) in size.  The default is
+\&\fB\-m32bit\-doubles\fR.  \fINote\fR \s-1RX\s0 floating-point hardware only
+works on 32\-bit values, which is why the default is
+\&\fB\-m32bit\-doubles\fR.
+.IP "\fB\-fpu\fR" 4
+.IX Item "-fpu"
+.PD 0
+.IP "\fB\-nofpu\fR" 4
+.IX Item "-nofpu"
+.PD
+Enables (\fB\-fpu\fR) or disables (\fB\-nofpu\fR) the use of \s-1RX\s0
+floating-point hardware.  The default is enabled for the \fI\s-1RX600\s0\fR
+series and disabled for the \fI\s-1RX200\s0\fR series.
+.Sp
+Floating-point instructions are only generated for 32\-bit floating-point 
+values, however, so the \s-1FPU\s0 hardware is not used for doubles if the
+\&\fB\-m64bit\-doubles\fR option is used.
+.Sp
+\&\fINote\fR If the \fB\-fpu\fR option is enabled then
+\&\fB\-funsafe\-math\-optimizations\fR is also enabled automatically.
+This is because the \s-1RX FPU\s0 instructions are themselves unsafe.
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Selects the type of \s-1RX CPU\s0 to be targeted.  Currently three types are
+supported, the generic \fI\s-1RX600\s0\fR and \fI\s-1RX200\s0\fR series hardware and
+the specific \fI\s-1RX610\s0\fR \s-1CPU. \s0 The default is \fI\s-1RX600\s0\fR.
+.Sp
+The only difference between \fI\s-1RX600\s0\fR and \fI\s-1RX610\s0\fR is that the
+\&\fI\s-1RX610\s0\fR does not support the \f(CW\*(C`MVTIPL\*(C'\fR instruction.
+.Sp
+The \fI\s-1RX200\s0\fR series does not have a hardware floating-point unit
+and so \fB\-nofpu\fR is enabled by default when this type is
+selected.
+.IP "\fB\-mbig\-endian\-data\fR" 4
+.IX Item "-mbig-endian-data"
+.PD 0
+.IP "\fB\-mlittle\-endian\-data\fR" 4
+.IX Item "-mlittle-endian-data"
+.PD
+Store data (but not code) in the big-endian format.  The default is
+\&\fB\-mlittle\-endian\-data\fR, i.e. to store data in the little-endian
+format.
+.IP "\fB\-msmall\-data\-limit=\fR\fIN\fR" 4
+.IX Item "-msmall-data-limit=N"
+Specifies the maximum size in bytes of global and static variables
+which can be placed into the small data area.  Using the small data
+area can lead to smaller and faster code, but the size of area is
+limited and it is up to the programmer to ensure that the area does
+not overflow.  Also when the small data area is used one of the \s-1RX\s0's
+registers (usually \f(CW\*(C`r13\*(C'\fR) is reserved for use pointing to this
+area, so it is no longer available for use by the compiler.  This
+could result in slower and/or larger code if variables are pushed onto
+the stack instead of being held in this register.
+.Sp
+Note, common variables (variables that have not been initialized) and
+constants are not placed into the small data area as they are assigned
+to other sections in the output executable.
+.Sp
+The default value is zero, which disables this feature.  Note, this
+feature is not enabled by default with higher optimization levels
+(\fB\-O2\fR etc) because of the potentially detrimental effects of
+reserving a register.  It is up to the programmer to experiment and
+discover whether this feature is of benefit to their program.  See the
+description of the \fB\-mpid\fR option for a description of how the
+actual register to hold the small data area pointer is chosen.
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+.PD 0
+.IP "\fB\-mno\-sim\fR" 4
+.IX Item "-mno-sim"
+.PD
+Use the simulator runtime.  The default is to use the libgloss
+board-specific runtime.
+.IP "\fB\-mas100\-syntax\fR" 4
+.IX Item "-mas100-syntax"
+.PD 0
+.IP "\fB\-mno\-as100\-syntax\fR" 4
+.IX Item "-mno-as100-syntax"
+.PD
+When generating assembler output use a syntax that is compatible with
+Renesas's \s-1AS100\s0 assembler.  This syntax can also be handled by the \s-1GAS\s0
+assembler, but it has some restrictions so it is not generated by default.
+.IP "\fB\-mmax\-constant\-size=\fR\fIN\fR" 4
+.IX Item "-mmax-constant-size=N"
+Specifies the maximum size, in bytes, of a constant that can be used as
+an operand in a \s-1RX\s0 instruction.  Although the \s-1RX\s0 instruction set does
+allow constants of up to 4 bytes in length to be used in instructions,
+a longer value equates to a longer instruction.  Thus in some
+circumstances it can be beneficial to restrict the size of constants
+that are used in instructions.  Constants that are too big are instead
+placed into a constant pool and referenced via register indirection.
+.Sp
+The value \fIN\fR can be between 0 and 4.  A value of 0 (the default)
+or 4 means that constants of any size are allowed.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Enable linker relaxation.  Linker relaxation is a process whereby the
+linker attempts to reduce the size of a program by finding shorter
+versions of various instructions.  Disabled by default.
+.IP "\fB\-mint\-register=\fR\fIN\fR" 4
+.IX Item "-mint-register=N"
+Specify the number of registers to reserve for fast interrupt handler
+functions.  The value \fIN\fR can be between 0 and 4.  A value of 1
+means that register \f(CW\*(C`r13\*(C'\fR is reserved for the exclusive use
+of fast interrupt handlers.  A value of 2 reserves \f(CW\*(C`r13\*(C'\fR and
+\&\f(CW\*(C`r12\*(C'\fR.  A value of 3 reserves \f(CW\*(C`r13\*(C'\fR, \f(CW\*(C`r12\*(C'\fR and
+\&\f(CW\*(C`r11\*(C'\fR, and a value of 4 reserves \f(CW\*(C`r13\*(C'\fR through \f(CW\*(C`r10\*(C'\fR.
+A value of 0, the default, does not reserve any registers.
+.IP "\fB\-msave\-acc\-in\-interrupts\fR" 4
+.IX Item "-msave-acc-in-interrupts"
+Specifies that interrupt handler functions should preserve the
+accumulator register.  This is only necessary if normal code might use
+the accumulator register, for example because it performs 64\-bit
+multiplications.  The default is to ignore the accumulator as this
+makes the interrupt handlers faster.
+.IP "\fB\-mpid\fR" 4
+.IX Item "-mpid"
+.PD 0
+.IP "\fB\-mno\-pid\fR" 4
+.IX Item "-mno-pid"
+.PD
+Enables the generation of position independent data.  When enabled any
+access to constant data is done via an offset from a base address
+held in a register.  This allows the location of constant data to be
+determined at run time without requiring the executable to be
+relocated, which is a benefit to embedded applications with tight
+memory constraints.  Data that can be modified is not affected by this
+option.
+.Sp
+Note, using this feature reserves a register, usually \f(CW\*(C`r13\*(C'\fR, for
+the constant data base address.  This can result in slower and/or
+larger code, especially in complicated functions.
+.Sp
+The actual register chosen to hold the constant data base address
+depends upon whether the \fB\-msmall\-data\-limit\fR and/or the
+\&\fB\-mint\-register\fR command-line options are enabled.  Starting
+with register \f(CW\*(C`r13\*(C'\fR and proceeding downwards, registers are
+allocated first to satisfy the requirements of \fB\-mint\-register\fR,
+then \fB\-mpid\fR and finally \fB\-msmall\-data\-limit\fR.  Thus it
+is possible for the small data area register to be \f(CW\*(C`r8\*(C'\fR if both
+\&\fB\-mint\-register=4\fR and \fB\-mpid\fR are specified on the
+command line.
+.Sp
+By default this feature is not enabled.  The default can be restored
+via the \fB\-mno\-pid\fR command-line option.
+.IP "\fB\-mno\-warn\-multiple\-fast\-interrupts\fR" 4
+.IX Item "-mno-warn-multiple-fast-interrupts"
+.PD 0
+.IP "\fB\-mwarn\-multiple\-fast\-interrupts\fR" 4
+.IX Item "-mwarn-multiple-fast-interrupts"
+.PD
+Prevents \s-1GCC\s0 from issuing a warning message if it finds more than one
+fast interrupt handler when it is compiling a file.  The default is to
+issue a warning for each extra fast interrupt handler found, as the \s-1RX\s0
+only supports one such interrupt.
+.PP
+\&\fINote:\fR The generic \s-1GCC\s0 command-line option \fB\-ffixed\-\fR\fIreg\fR
+has special significance to the \s-1RX\s0 port when used with the
+\&\f(CW\*(C`interrupt\*(C'\fR function attribute.  This attribute indicates a
+function intended to process fast interrupts.  \s-1GCC\s0 ensures
+that it only uses the registers \f(CW\*(C`r10\*(C'\fR, \f(CW\*(C`r11\*(C'\fR, \f(CW\*(C`r12\*(C'\fR
+and/or \f(CW\*(C`r13\*(C'\fR and only provided that the normal use of the
+corresponding registers have been restricted via the
+\&\fB\-ffixed\-\fR\fIreg\fR or \fB\-mint\-register\fR command-line
+options.
+.PP
+\fIS/390 and zSeries Options\fR
+.IX Subsection "S/390 and zSeries Options"
+.PP
+These are the \fB\-m\fR options defined for the S/390 and zSeries architecture.
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD 0
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD
+Use (do not use) the hardware floating-point instructions and registers
+for floating-point operations.  When \fB\-msoft\-float\fR is specified,
+functions in \fIlibgcc.a\fR are used to perform floating-point
+operations.  When \fB\-mhard\-float\fR is specified, the compiler
+generates \s-1IEEE\s0 floating-point instructions.  This is the default.
+.IP "\fB\-mhard\-dfp\fR" 4
+.IX Item "-mhard-dfp"
+.PD 0
+.IP "\fB\-mno\-hard\-dfp\fR" 4
+.IX Item "-mno-hard-dfp"
+.PD
+Use (do not use) the hardware decimal-floating-point instructions for
+decimal-floating-point operations.  When \fB\-mno\-hard\-dfp\fR is
+specified, functions in \fIlibgcc.a\fR are used to perform
+decimal-floating-point operations.  When \fB\-mhard\-dfp\fR is
+specified, the compiler generates decimal-floating-point hardware
+instructions.  This is the default for \fB\-march=z9\-ec\fR or higher.
+.IP "\fB\-mlong\-double\-64\fR" 4
+.IX Item "-mlong-double-64"
+.PD 0
+.IP "\fB\-mlong\-double\-128\fR" 4
+.IX Item "-mlong-double-128"
+.PD
+These switches control the size of \f(CW\*(C`long double\*(C'\fR type. A size
+of 64 bits makes the \f(CW\*(C`long double\*(C'\fR type equivalent to the \f(CW\*(C`double\*(C'\fR
+type. This is the default.
+.IP "\fB\-mbackchain\fR" 4
+.IX Item "-mbackchain"
+.PD 0
+.IP "\fB\-mno\-backchain\fR" 4
+.IX Item "-mno-backchain"
+.PD
+Store (do not store) the address of the caller's frame as backchain pointer
+into the callee's stack frame.
+A backchain may be needed to allow debugging using tools that do not understand
+\&\s-1DWARF 2\s0 call frame information.
+When \fB\-mno\-packed\-stack\fR is in effect, the backchain pointer is stored
+at the bottom of the stack frame; when \fB\-mpacked\-stack\fR is in effect,
+the backchain is placed into the topmost word of the 96/160 byte register
+save area.
+.Sp
+In general, code compiled with \fB\-mbackchain\fR is call-compatible with
+code compiled with \fB\-mmo\-backchain\fR; however, use of the backchain
+for debugging purposes usually requires that the whole binary is built with
+\&\fB\-mbackchain\fR.  Note that the combination of \fB\-mbackchain\fR,
+\&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported.  In order
+to build a linux kernel use \fB\-msoft\-float\fR.
+.Sp
+The default is to not maintain the backchain.
+.IP "\fB\-mpacked\-stack\fR" 4
+.IX Item "-mpacked-stack"
+.PD 0
+.IP "\fB\-mno\-packed\-stack\fR" 4
+.IX Item "-mno-packed-stack"
+.PD
+Use (do not use) the packed stack layout.  When \fB\-mno\-packed\-stack\fR is
+specified, the compiler uses the all fields of the 96/160 byte register save
+area only for their default purpose; unused fields still take up stack space.
+When \fB\-mpacked\-stack\fR is specified, register save slots are densely
+packed at the top of the register save area; unused space is reused for other
+purposes, allowing for more efficient use of the available stack space.
+However, when \fB\-mbackchain\fR is also in effect, the topmost word of
+the save area is always used to store the backchain, and the return address
+register is always saved two words below the backchain.
+.Sp
+As long as the stack frame backchain is not used, code generated with
+\&\fB\-mpacked\-stack\fR is call-compatible with code generated with
+\&\fB\-mno\-packed\-stack\fR.  Note that some non-FSF releases of \s-1GCC 2.95\s0 for
+S/390 or zSeries generated code that uses the stack frame backchain at run
+time, not just for debugging purposes.  Such code is not call-compatible
+with code compiled with \fB\-mpacked\-stack\fR.  Also, note that the
+combination of \fB\-mbackchain\fR,
+\&\fB\-mpacked\-stack\fR and \fB\-mhard\-float\fR is not supported.  In order
+to build a linux kernel use \fB\-msoft\-float\fR.
+.Sp
+The default is to not use the packed stack layout.
+.IP "\fB\-msmall\-exec\fR" 4
+.IX Item "-msmall-exec"
+.PD 0
+.IP "\fB\-mno\-small\-exec\fR" 4
+.IX Item "-mno-small-exec"
+.PD
+Generate (or do not generate) code using the \f(CW\*(C`bras\*(C'\fR instruction
+to do subroutine calls.
+This only works reliably if the total executable size does not
+exceed 64k.  The default is to use the \f(CW\*(C`basr\*(C'\fR instruction instead,
+which does not have this limitation.
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.PD 0
+.IP "\fB\-m31\fR" 4
+.IX Item "-m31"
+.PD
+When \fB\-m31\fR is specified, generate code compliant to the
+GNU/Linux for S/390 \s-1ABI. \s0 When \fB\-m64\fR is specified, generate
+code compliant to the GNU/Linux for zSeries \s-1ABI. \s0 This allows \s-1GCC\s0 in
+particular to generate 64\-bit instructions.  For the \fBs390\fR
+targets, the default is \fB\-m31\fR, while the \fBs390x\fR
+targets default to \fB\-m64\fR.
+.IP "\fB\-mzarch\fR" 4
+.IX Item "-mzarch"
+.PD 0
+.IP "\fB\-mesa\fR" 4
+.IX Item "-mesa"
+.PD
+When \fB\-mzarch\fR is specified, generate code using the
+instructions available on z/Architecture.
+When \fB\-mesa\fR is specified, generate code using the
+instructions available on \s-1ESA/390. \s0 Note that \fB\-mesa\fR is
+not possible with \fB\-m64\fR.
+When generating code compliant to the GNU/Linux for S/390 \s-1ABI,\s0
+the default is \fB\-mesa\fR.  When generating code compliant
+to the GNU/Linux for zSeries \s-1ABI,\s0 the default is \fB\-mzarch\fR.
+.IP "\fB\-mmvcle\fR" 4
+.IX Item "-mmvcle"
+.PD 0
+.IP "\fB\-mno\-mvcle\fR" 4
+.IX Item "-mno-mvcle"
+.PD
+Generate (or do not generate) code using the \f(CW\*(C`mvcle\*(C'\fR instruction
+to perform block moves.  When \fB\-mno\-mvcle\fR is specified,
+use a \f(CW\*(C`mvc\*(C'\fR loop instead.  This is the default unless optimizing for
+size.
+.IP "\fB\-mdebug\fR" 4
+.IX Item "-mdebug"
+.PD 0
+.IP "\fB\-mno\-debug\fR" 4
+.IX Item "-mno-debug"
+.PD
+Print (or do not print) additional debug information when compiling.
+The default is to not print debug information.
+.IP "\fB\-march=\fR\fIcpu-type\fR" 4
+.IX Item "-march=cpu-type"
+Generate code that runs on \fIcpu-type\fR, which is the name of a system
+representing a certain processor type.  Possible values for
+\&\fIcpu-type\fR are \fBg5\fR, \fBg6\fR, \fBz900\fR, \fBz990\fR,
+\&\fBz9\-109\fR, \fBz9\-ec\fR and \fBz10\fR.
+When generating code using the instructions available on z/Architecture,
+the default is \fB\-march=z900\fR.  Otherwise, the default is
+\&\fB\-march=g5\fR.
+.IP "\fB\-mtune=\fR\fIcpu-type\fR" 4
+.IX Item "-mtune=cpu-type"
+Tune to \fIcpu-type\fR everything applicable about the generated code,
+except for the \s-1ABI\s0 and the set of available instructions.
+The list of \fIcpu-type\fR values is the same as for \fB\-march\fR.
+The default is the value used for \fB\-march\fR.
+.IP "\fB\-mtpf\-trace\fR" 4
+.IX Item "-mtpf-trace"
+.PD 0
+.IP "\fB\-mno\-tpf\-trace\fR" 4
+.IX Item "-mno-tpf-trace"
+.PD
+Generate code that adds (does not add) in \s-1TPF OS\s0 specific branches to trace
+routines in the operating system.  This option is off by default, even
+when compiling for the \s-1TPF OS.\s0
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Generate code that uses (does not use) the floating-point multiply and
+accumulate instructions.  These instructions are generated by default if
+hardware floating point is used.
+.IP "\fB\-mwarn\-framesize=\fR\fIframesize\fR" 4
+.IX Item "-mwarn-framesize=framesize"
+Emit a warning if the current function exceeds the given frame size.  Because
+this is a compile-time check it doesn't need to be a real problem when the program
+runs.  It is intended to identify functions that most probably cause
+a stack overflow.  It is useful to be used in an environment with limited stack
+size e.g. the linux kernel.
+.IP "\fB\-mwarn\-dynamicstack\fR" 4
+.IX Item "-mwarn-dynamicstack"
+Emit a warning if the function calls \f(CW\*(C`alloca\*(C'\fR or uses dynamically-sized
+arrays.  This is generally a bad idea with a limited stack size.
+.IP "\fB\-mstack\-guard=\fR\fIstack-guard\fR" 4
+.IX Item "-mstack-guard=stack-guard"
+.PD 0
+.IP "\fB\-mstack\-size=\fR\fIstack-size\fR" 4
+.IX Item "-mstack-size=stack-size"
+.PD
+If these options are provided the S/390 back end emits additional instructions in
+the function prologue that trigger a trap if the stack size is \fIstack-guard\fR
+bytes above the \fIstack-size\fR (remember that the stack on S/390 grows downward).
+If the \fIstack-guard\fR option is omitted the smallest power of 2 larger than
+the frame size of the compiled function is chosen.
+These options are intended to be used to help debugging stack overflow problems.
+The additionally emitted code causes only little overhead and hence can also be
+used in production-like systems without greater performance degradation.  The given
+values have to be exact powers of 2 and \fIstack-size\fR has to be greater than
+\&\fIstack-guard\fR without exceeding 64k.
+In order to be efficient the extra code makes the assumption that the stack starts
+at an address aligned to the value given by \fIstack-size\fR.
+The \fIstack-guard\fR option can only be used in conjunction with \fIstack-size\fR.
+.IP "\fB\-mhotpatch[=\fR\fIhalfwords\fR\fB]\fR" 4
+.IX Item "-mhotpatch[=halfwords]"
+.PD 0
+.IP "\fB\-mno\-hotpatch\fR" 4
+.IX Item "-mno-hotpatch"
+.PD
+If the hotpatch option is enabled, a \*(L"hot-patching\*(R" function
+prologue is generated for all functions in the compilation unit.
+The funtion label is prepended with the given number of two-byte
+Nop instructions (\fIhalfwords\fR, maximum 1000000) or 12 Nop
+instructions if no argument is present.  Functions with a
+hot-patching prologue are never inlined automatically, and a
+hot-patching prologue is never generated for functions functions
+that are explicitly inline.
+.Sp
+This option can be overridden for individual functions with the
+\&\f(CW\*(C`hotpatch\*(C'\fR attribute.
+.PP
+\fIScore Options\fR
+.IX Subsection "Score Options"
+.PP
+These options are defined for Score implementations:
+.IP "\fB\-meb\fR" 4
+.IX Item "-meb"
+Compile code for big-endian mode.  This is the default.
+.IP "\fB\-mel\fR" 4
+.IX Item "-mel"
+Compile code for little-endian mode.
+.IP "\fB\-mnhwloop\fR" 4
+.IX Item "-mnhwloop"
+Disable generation of \f(CW\*(C`bcnz\*(C'\fR instructions.
+.IP "\fB\-muls\fR" 4
+.IX Item "-muls"
+Enable generation of unaligned load and store instructions.
+.IP "\fB\-mmac\fR" 4
+.IX Item "-mmac"
+Enable the use of multiply-accumulate instructions. Disabled by default.
+.IP "\fB\-mscore5\fR" 4
+.IX Item "-mscore5"
+Specify the \s-1SCORE5\s0 as the target architecture.
+.IP "\fB\-mscore5u\fR" 4
+.IX Item "-mscore5u"
+Specify the \s-1SCORE5U\s0 of the target architecture.
+.IP "\fB\-mscore7\fR" 4
+.IX Item "-mscore7"
+Specify the \s-1SCORE7\s0 as the target architecture. This is the default.
+.IP "\fB\-mscore7d\fR" 4
+.IX Item "-mscore7d"
+Specify the \s-1SCORE7D\s0 as the target architecture.
+.PP
+\fI\s-1SH\s0 Options\fR
+.IX Subsection "SH Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1SH\s0 implementations:
+.IP "\fB\-m1\fR" 4
+.IX Item "-m1"
+Generate code for the \s-1SH1.\s0
+.IP "\fB\-m2\fR" 4
+.IX Item "-m2"
+Generate code for the \s-1SH2.\s0
+.IP "\fB\-m2e\fR" 4
+.IX Item "-m2e"
+Generate code for the SH2e.
+.IP "\fB\-m2a\-nofpu\fR" 4
+.IX Item "-m2a-nofpu"
+Generate code for the SH2a without \s-1FPU,\s0 or for a SH2a\-FPU in such a way
+that the floating-point unit is not used.
+.IP "\fB\-m2a\-single\-only\fR" 4
+.IX Item "-m2a-single-only"
+Generate code for the SH2a\-FPU, in such a way that no double-precision
+floating-point operations are used.
+.IP "\fB\-m2a\-single\fR" 4
+.IX Item "-m2a-single"
+Generate code for the SH2a\-FPU assuming the floating-point unit is in
+single-precision mode by default.
+.IP "\fB\-m2a\fR" 4
+.IX Item "-m2a"
+Generate code for the SH2a\-FPU assuming the floating-point unit is in
+double-precision mode by default.
+.IP "\fB\-m3\fR" 4
+.IX Item "-m3"
+Generate code for the \s-1SH3.\s0
+.IP "\fB\-m3e\fR" 4
+.IX Item "-m3e"
+Generate code for the SH3e.
+.IP "\fB\-m4\-nofpu\fR" 4
+.IX Item "-m4-nofpu"
+Generate code for the \s-1SH4\s0 without a floating-point unit.
+.IP "\fB\-m4\-single\-only\fR" 4
+.IX Item "-m4-single-only"
+Generate code for the \s-1SH4\s0 with a floating-point unit that only
+supports single-precision arithmetic.
+.IP "\fB\-m4\-single\fR" 4
+.IX Item "-m4-single"
+Generate code for the \s-1SH4\s0 assuming the floating-point unit is in
+single-precision mode by default.
+.IP "\fB\-m4\fR" 4
+.IX Item "-m4"
+Generate code for the \s-1SH4.\s0
+.IP "\fB\-m4a\-nofpu\fR" 4
+.IX Item "-m4a-nofpu"
+Generate code for the SH4al\-dsp, or for a SH4a in such a way that the
+floating-point unit is not used.
+.IP "\fB\-m4a\-single\-only\fR" 4
+.IX Item "-m4a-single-only"
+Generate code for the SH4a, in such a way that no double-precision
+floating-point operations are used.
+.IP "\fB\-m4a\-single\fR" 4
+.IX Item "-m4a-single"
+Generate code for the SH4a assuming the floating-point unit is in
+single-precision mode by default.
+.IP "\fB\-m4a\fR" 4
+.IX Item "-m4a"
+Generate code for the SH4a.
+.IP "\fB\-m4al\fR" 4
+.IX Item "-m4al"
+Same as \fB\-m4a\-nofpu\fR, except that it implicitly passes
+\&\fB\-dsp\fR to the assembler.  \s-1GCC\s0 doesn't generate any \s-1DSP\s0
+instructions at the moment.
+.IP "\fB\-mb\fR" 4
+.IX Item "-mb"
+Compile code for the processor in big-endian mode.
+.IP "\fB\-ml\fR" 4
+.IX Item "-ml"
+Compile code for the processor in little-endian mode.
+.IP "\fB\-mdalign\fR" 4
+.IX Item "-mdalign"
+Align doubles at 64\-bit boundaries.  Note that this changes the calling
+conventions, and thus some functions from the standard C library do
+not work unless you recompile it first with \fB\-mdalign\fR.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+Shorten some address references at link time, when possible; uses the
+linker option \fB\-relax\fR.
+.IP "\fB\-mbigtable\fR" 4
+.IX Item "-mbigtable"
+Use 32\-bit offsets in \f(CW\*(C`switch\*(C'\fR tables.  The default is to use
+16\-bit offsets.
+.IP "\fB\-mbitops\fR" 4
+.IX Item "-mbitops"
+Enable the use of bit manipulation instructions on \s-1SH2A.\s0
+.IP "\fB\-mfmovd\fR" 4
+.IX Item "-mfmovd"
+Enable the use of the instruction \f(CW\*(C`fmovd\*(C'\fR.  Check \fB\-mdalign\fR for
+alignment constraints.
+.IP "\fB\-mhitachi\fR" 4
+.IX Item "-mhitachi"
+Comply with the calling conventions defined by Renesas.
+.IP "\fB\-mrenesas\fR" 4
+.IX Item "-mrenesas"
+Comply with the calling conventions defined by Renesas.
+.IP "\fB\-mno\-renesas\fR" 4
+.IX Item "-mno-renesas"
+Comply with the calling conventions defined for \s-1GCC\s0 before the Renesas
+conventions were available.  This option is the default for all
+targets of the \s-1SH\s0 toolchain.
+.IP "\fB\-mnomacsave\fR" 4
+.IX Item "-mnomacsave"
+Mark the \f(CW\*(C`MAC\*(C'\fR register as call-clobbered, even if
+\&\fB\-mhitachi\fR is given.
+.IP "\fB\-mieee\fR" 4
+.IX Item "-mieee"
+.PD 0
+.IP "\fB\-mno\-ieee\fR" 4
+.IX Item "-mno-ieee"
+.PD
+Control the \s-1IEEE\s0 compliance of floating-point comparisons, which affects the
+handling of cases where the result of a comparison is unordered.  By default
+\&\fB\-mieee\fR is implicitly enabled.  If \fB\-ffinite\-math\-only\fR is
+enabled \fB\-mno\-ieee\fR is implicitly set, which results in faster
+floating-point greater-equal and less-equal comparisons.  The implcit settings
+can be overridden by specifying either \fB\-mieee\fR or \fB\-mno\-ieee\fR.
+.IP "\fB\-minline\-ic_invalidate\fR" 4
+.IX Item "-minline-ic_invalidate"
+Inline code to invalidate instruction cache entries after setting up
+nested function trampolines.
+This option has no effect if \fB\-musermode\fR is in effect and the selected
+code generation option (e.g. \fB\-m4\fR) does not allow the use of the \f(CW\*(C`icbi\*(C'\fR
+instruction.
+If the selected code generation option does not allow the use of the \f(CW\*(C`icbi\*(C'\fR
+instruction, and \fB\-musermode\fR is not in effect, the inlined code
+manipulates the instruction cache address array directly with an associative
+write.  This not only requires privileged mode at run time, but it also
+fails if the cache line had been mapped via the \s-1TLB\s0 and has become unmapped.
+.IP "\fB\-misize\fR" 4
+.IX Item "-misize"
+Dump instruction size and location in the assembly code.
+.IP "\fB\-mpadstruct\fR" 4
+.IX Item "-mpadstruct"
+This option is deprecated.  It pads structures to multiple of 4 bytes,
+which is incompatible with the \s-1SH ABI.\s0
+.IP "\fB\-matomic\-model=\fR\fImodel\fR" 4
+.IX Item "-matomic-model=model"
+Sets the model of atomic operations and additional parameters as a comma
+separated list.  For details on the atomic built-in functions see
+\&\fB_\|_atomic Builtins\fR.  The following models and parameters are supported:
+.RS 4
+.IP "\fBnone\fR" 4
+.IX Item "none"
+Disable compiler generated atomic sequences and emit library calls for atomic
+operations.  This is the default if the target is not \f(CW\*(C`sh\-*\-linux*\*(C'\fR.
+.IP "\fBsoft-gusa\fR" 4
+.IX Item "soft-gusa"
+Generate GNU/Linux compatible gUSA software atomic sequences for the atomic
+built-in functions.  The generated atomic sequences require additional support
+from the interrupt/exception handling code of the system and are only suitable
+for SH3* and SH4* single-core systems.  This option is enabled by default when
+the target is \f(CW\*(C`sh\-*\-linux*\*(C'\fR and SH3* or SH4*.  When the target is \s-1SH4A,\s0
+this option will also partially utilize the hardware atomic instructions
+\&\f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR to create more efficient code, unless
+\&\fBstrict\fR is specified.
+.IP "\fBsoft-tcb\fR" 4
+.IX Item "soft-tcb"
+Generate software atomic sequences that use a variable in the thread control
+block.  This is a variation of the gUSA sequences which can also be used on
+SH1* and SH2* targets.  The generated atomic sequences require additional
+support from the interrupt/exception handling code of the system and are only
+suitable for single-core systems.  When using this model, the \fBgbr\-offset=\fR
+parameter has to be specified as well.
+.IP "\fBsoft-imask\fR" 4
+.IX Item "soft-imask"
+Generate software atomic sequences that temporarily disable interrupts by
+setting \f(CW\*(C`SR.IMASK = 1111\*(C'\fR.  This model works only when the program runs
+in privileged mode and is only suitable for single-core systems.  Additional
+support from the interrupt/exception handling code of the system is not
+required.  This model is enabled by default when the target is
+\&\f(CW\*(C`sh\-*\-linux*\*(C'\fR and SH1* or SH2*.
+.IP "\fBhard-llcs\fR" 4
+.IX Item "hard-llcs"
+Generate hardware atomic sequences using the \f(CW\*(C`movli.l\*(C'\fR and \f(CW\*(C`movco.l\*(C'\fR
+instructions only.  This is only available on \s-1SH4A\s0 and is suitable for
+multi-core systems.  Since the hardware instructions support only 32 bit atomic
+variables access to 8 or 16 bit variables is emulated with 32 bit accesses.
+Code compiled with this option will also be compatible with other software
+atomic model interrupt/exception handling systems if executed on an \s-1SH4A\s0
+system.  Additional support from the interrupt/exception handling code of the
+system is not required for this model.
+.IP "\fBgbr\-offset=\fR" 4
+.IX Item "gbr-offset="
+This parameter specifies the offset in bytes of the variable in the thread
+control block structure that should be used by the generated atomic sequences
+when the \fBsoft-tcb\fR model has been selected.  For other models this
+parameter is ignored.  The specified value must be an integer multiple of four
+and in the range 0\-1020.
+.IP "\fBstrict\fR" 4
+.IX Item "strict"
+This parameter prevents mixed usage of multiple atomic models, even though they
+would be compatible, and will make the compiler generate atomic sequences of the
+specified model only.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mtas\fR" 4
+.IX Item "-mtas"
+Generate the \f(CW\*(C`tas.b\*(C'\fR opcode for \f(CW\*(C`_\|_atomic_test_and_set\*(C'\fR.
+Notice that depending on the particular hardware and software configuration
+this can degrade overall performance due to the operand cache line flushes
+that are implied by the \f(CW\*(C`tas.b\*(C'\fR instruction.  On multi-core \s-1SH4A\s0
+processors the \f(CW\*(C`tas.b\*(C'\fR instruction must be used with caution since it
+can result in data corruption for certain cache configurations.
+.IP "\fB\-mspace\fR" 4
+.IX Item "-mspace"
+Optimize for space instead of speed.  Implied by \fB\-Os\fR.
+.IP "\fB\-mprefergot\fR" 4
+.IX Item "-mprefergot"
+When generating position-independent code, emit function calls using
+the Global Offset Table instead of the Procedure Linkage Table.
+.IP "\fB\-musermode\fR" 4
+.IX Item "-musermode"
+Don't generate privileged mode only code.  This option
+implies \fB\-mno\-inline\-ic_invalidate\fR
+if the inlined code would not work in user mode.
+This is the default when the target is \f(CW\*(C`sh\-*\-linux*\*(C'\fR.
+.IP "\fB\-multcost=\fR\fInumber\fR" 4
+.IX Item "-multcost=number"
+Set the cost to assume for a multiply insn.
+.IP "\fB\-mdiv=\fR\fIstrategy\fR" 4
+.IX Item "-mdiv=strategy"
+Set the division strategy to be used for integer division operations.
+For SHmedia \fIstrategy\fR can be one of:
+.RS 4
+.IP "\fBfp\fR" 4
+.IX Item "fp"
+Performs the operation in floating point.  This has a very high latency,
+but needs only a few instructions, so it might be a good choice if
+your code has enough easily-exploitable \s-1ILP\s0 to allow the compiler to
+schedule the floating-point instructions together with other instructions.
+Division by zero causes a floating-point exception.
+.IP "\fBinv\fR" 4
+.IX Item "inv"
+Uses integer operations to calculate the inverse of the divisor,
+and then multiplies the dividend with the inverse.  This strategy allows
+\&\s-1CSE\s0 and hoisting of the inverse calculation.  Division by zero calculates
+an unspecified result, but does not trap.
+.IP "\fBinv:minlat\fR" 4
+.IX Item "inv:minlat"
+A variant of \fBinv\fR where, if no \s-1CSE\s0 or hoisting opportunities
+have been found, or if the entire operation has been hoisted to the same
+place, the last stages of the inverse calculation are intertwined with the
+final multiply to reduce the overall latency, at the expense of using a few
+more instructions, and thus offering fewer scheduling opportunities with
+other code.
+.IP "\fBcall\fR" 4
+.IX Item "call"
+Calls a library function that usually implements the \fBinv:minlat\fR
+strategy.
+This gives high code density for \f(CW\*(C`m5\-*media\-nofpu\*(C'\fR compilations.
+.IP "\fBcall2\fR" 4
+.IX Item "call2"
+Uses a different entry point of the same library function, where it
+assumes that a pointer to a lookup table has already been set up, which
+exposes the pointer load to \s-1CSE\s0 and code hoisting optimizations.
+.IP "\fBinv:call\fR" 4
+.IX Item "inv:call"
+.PD 0
+.IP "\fBinv:call2\fR" 4
+.IX Item "inv:call2"
+.IP "\fBinv:fp\fR" 4
+.IX Item "inv:fp"
+.PD
+Use the \fBinv\fR algorithm for initial
+code generation, but if the code stays unoptimized, revert to the \fBcall\fR,
+\&\fBcall2\fR, or \fBfp\fR strategies, respectively.  Note that the
+potentially-trapping side effect of division by zero is carried by a
+separate instruction, so it is possible that all the integer instructions
+are hoisted out, but the marker for the side effect stays where it is.
+A recombination to floating-point operations or a call is not possible
+in that case.
+.IP "\fBinv20u\fR" 4
+.IX Item "inv20u"
+.PD 0
+.IP "\fBinv20l\fR" 4
+.IX Item "inv20l"
+.PD
+Variants of the \fBinv:minlat\fR strategy.  In the case
+that the inverse calculation is not separated from the multiply, they speed
+up division where the dividend fits into 20 bits (plus sign where applicable)
+by inserting a test to skip a number of operations in this case; this test
+slows down the case of larger dividends.  \fBinv20u\fR assumes the case of a such
+a small dividend to be unlikely, and \fBinv20l\fR assumes it to be likely.
+.RE
+.RS 4
+.Sp
+For targets other than SHmedia \fIstrategy\fR can be one of:
+.IP "\fBcall\-div1\fR" 4
+.IX Item "call-div1"
+Calls a library function that uses the single-step division instruction
+\&\f(CW\*(C`div1\*(C'\fR to perform the operation.  Division by zero calculates an
+unspecified result and does not trap.  This is the default except for \s-1SH4,
+SH2A\s0 and SHcompact.
+.IP "\fBcall-fp\fR" 4
+.IX Item "call-fp"
+Calls a library function that performs the operation in double precision
+floating point.  Division by zero causes a floating-point exception.  This is
+the default for SHcompact with \s-1FPU. \s0 Specifying this for targets that do not
+have a double precision \s-1FPU\s0 will default to \f(CW\*(C`call\-div1\*(C'\fR.
+.IP "\fBcall-table\fR" 4
+.IX Item "call-table"
+Calls a library function that uses a lookup table for small divisors and
+the \f(CW\*(C`div1\*(C'\fR instruction with case distinction for larger divisors.  Division
+by zero calculates an unspecified result and does not trap.  This is the default
+for \s-1SH4. \s0 Specifying this for targets that do not have dynamic shift
+instructions will default to \f(CW\*(C`call\-div1\*(C'\fR.
+.RE
+.RS 4
+.Sp
+When a division strategy has not been specified the default strategy will be
+selected based on the current target.  For \s-1SH2A\s0 the default strategy is to
+use the \f(CW\*(C`divs\*(C'\fR and \f(CW\*(C`divu\*(C'\fR instructions instead of library function
+calls.
+.RE
+.IP "\fB\-maccumulate\-outgoing\-args\fR" 4
+.IX Item "-maccumulate-outgoing-args"
+Reserve space once for outgoing arguments in the function prologue rather
+than around each call.  Generally beneficial for performance and size.  Also
+needed for unwinding to avoid changing the stack frame around conditional code.
+.IP "\fB\-mdivsi3_libfunc=\fR\fIname\fR" 4
+.IX Item "-mdivsi3_libfunc=name"
+Set the name of the library function used for 32\-bit signed division to
+\&\fIname\fR.
+This only affects the name used in the \fBcall\fR and \fBinv:call\fR
+division strategies, and the compiler still expects the same
+sets of input/output/clobbered registers as if this option were not present.
+.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
+.IX Item "-mfixed-range=register-range"
+Generate code treating the given register range as fixed registers.
+A fixed register is one that the register allocator can not use.  This is
+useful when compiling kernel code.  A register range is specified as
+two registers separated by a dash.  Multiple register ranges can be
+specified separated by a comma.
+.IP "\fB\-mindexed\-addressing\fR" 4
+.IX Item "-mindexed-addressing"
+Enable the use of the indexed addressing mode for SHmedia32/SHcompact.
+This is only safe if the hardware and/or \s-1OS\s0 implement 32\-bit wrap-around
+semantics for the indexed addressing mode.  The architecture allows the
+implementation of processors with 64\-bit \s-1MMU,\s0 which the \s-1OS\s0 could use to
+get 32\-bit addressing, but since no current hardware implementation supports
+this or any other way to make the indexed addressing mode safe to use in
+the 32\-bit \s-1ABI,\s0 the default is \fB\-mno\-indexed\-addressing\fR.
+.IP "\fB\-mgettrcost=\fR\fInumber\fR" 4
+.IX Item "-mgettrcost=number"
+Set the cost assumed for the \f(CW\*(C`gettr\*(C'\fR instruction to \fInumber\fR.
+The default is 2 if \fB\-mpt\-fixed\fR is in effect, 100 otherwise.
+.IP "\fB\-mpt\-fixed\fR" 4
+.IX Item "-mpt-fixed"
+Assume \f(CW\*(C`pt*\*(C'\fR instructions won't trap.  This generally generates
+better-scheduled code, but is unsafe on current hardware.
+The current architecture
+definition says that \f(CW\*(C`ptabs\*(C'\fR and \f(CW\*(C`ptrel\*(C'\fR trap when the target 
+anded with 3 is 3.
+This has the unintentional effect of making it unsafe to schedule these
+instructions before a branch, or hoist them out of a loop.  For example,
+\&\f(CW\*(C`_\|_do_global_ctors\*(C'\fR, a part of \fIlibgcc\fR
+that runs constructors at program
+startup, calls functions in a list which is delimited by \-1.  With the
+\&\fB\-mpt\-fixed\fR option, the \f(CW\*(C`ptabs\*(C'\fR is done before testing against \-1.
+That means that all the constructors run a bit more quickly, but when
+the loop comes to the end of the list, the program crashes because \f(CW\*(C`ptabs\*(C'\fR
+loads \-1 into a target register.
+.Sp
+Since this option is unsafe for any
+hardware implementing the current architecture specification, the default
+is \fB\-mno\-pt\-fixed\fR.  Unless specified explicitly with 
+\&\fB\-mgettrcost\fR, \fB\-mno\-pt\-fixed\fR also implies \fB\-mgettrcost=100\fR;
+this deters register allocation from using target registers for storing
+ordinary integers.
+.IP "\fB\-minvalid\-symbols\fR" 4
+.IX Item "-minvalid-symbols"
+Assume symbols might be invalid.  Ordinary function symbols generated by
+the compiler are always valid to load with
+\&\f(CW\*(C`movi\*(C'\fR/\f(CW\*(C`shori\*(C'\fR/\f(CW\*(C`ptabs\*(C'\fR or
+\&\f(CW\*(C`movi\*(C'\fR/\f(CW\*(C`shori\*(C'\fR/\f(CW\*(C`ptrel\*(C'\fR,
+but with assembler and/or linker tricks it is possible
+to generate symbols that cause \f(CW\*(C`ptabs\*(C'\fR or \f(CW\*(C`ptrel\*(C'\fR to trap.
+This option is only meaningful when \fB\-mno\-pt\-fixed\fR is in effect.
+It prevents cross-basic-block \s-1CSE,\s0 hoisting and most scheduling
+of symbol loads.  The default is \fB\-mno\-invalid\-symbols\fR.
+.IP "\fB\-mbranch\-cost=\fR\fInum\fR" 4
+.IX Item "-mbranch-cost=num"
+Assume \fInum\fR to be the cost for a branch instruction.  Higher numbers
+make the compiler try to generate more branch-free code if possible.  
+If not specified the value is selected depending on the processor type that
+is being compiled for.
+.IP "\fB\-mzdcbranch\fR" 4
+.IX Item "-mzdcbranch"
+.PD 0
+.IP "\fB\-mno\-zdcbranch\fR" 4
+.IX Item "-mno-zdcbranch"
+.PD
+Assume (do not assume) that zero displacement conditional branch instructions
+\&\f(CW\*(C`bt\*(C'\fR and \f(CW\*(C`bf\*(C'\fR are fast.  If \fB\-mzdcbranch\fR is specified, the
+compiler will try to prefer zero displacement branch code sequences.  This is
+enabled by default when generating code for \s-1SH4\s0 and \s-1SH4A. \s0 It can be explicitly
+disabled by specifying \fB\-mno\-zdcbranch\fR.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Generate code that uses (does not use) the floating-point multiply and
+accumulate instructions.  These instructions are generated by default
+if hardware floating point is used.  The machine-dependent
+\&\fB\-mfused\-madd\fR option is now mapped to the machine-independent
+\&\fB\-ffp\-contract=fast\fR option, and \fB\-mno\-fused\-madd\fR is
+mapped to \fB\-ffp\-contract=off\fR.
+.IP "\fB\-mfsca\fR" 4
+.IX Item "-mfsca"
+.PD 0
+.IP "\fB\-mno\-fsca\fR" 4
+.IX Item "-mno-fsca"
+.PD
+Allow or disallow the compiler to emit the \f(CW\*(C`fsca\*(C'\fR instruction for sine
+and cosine approximations.  The option \f(CW\*(C`\-mfsca\*(C'\fR must be used in
+combination with \f(CW\*(C`\-funsafe\-math\-optimizations\*(C'\fR.  It is enabled by default
+when generating code for \s-1SH4A. \s0 Using \f(CW\*(C`\-mno\-fsca\*(C'\fR disables sine and cosine
+approximations even if \f(CW\*(C`\-funsafe\-math\-optimizations\*(C'\fR is in effect.
+.IP "\fB\-mfsrra\fR" 4
+.IX Item "-mfsrra"
+.PD 0
+.IP "\fB\-mno\-fsrra\fR" 4
+.IX Item "-mno-fsrra"
+.PD
+Allow or disallow the compiler to emit the \f(CW\*(C`fsrra\*(C'\fR instruction for
+reciprocal square root approximations.  The option \f(CW\*(C`\-mfsrra\*(C'\fR must be used
+in combination with \f(CW\*(C`\-funsafe\-math\-optimizations\*(C'\fR and
+\&\f(CW\*(C`\-ffinite\-math\-only\*(C'\fR.  It is enabled by default when generating code for
+\&\s-1SH4A. \s0 Using \f(CW\*(C`\-mno\-fsrra\*(C'\fR disables reciprocal square root approximations
+even if \f(CW\*(C`\-funsafe\-math\-optimizations\*(C'\fR and \f(CW\*(C`\-ffinite\-math\-only\*(C'\fR are
+in effect.
+.IP "\fB\-mpretend\-cmove\fR" 4
+.IX Item "-mpretend-cmove"
+Prefer zero-displacement conditional branches for conditional move instruction
+patterns.  This can result in faster code on the \s-1SH4\s0 processor.
+.PP
+\fISolaris 2 Options\fR
+.IX Subsection "Solaris 2 Options"
+.PP
+These \fB\-m\fR options are supported on Solaris 2:
+.IP "\fB\-mimpure\-text\fR" 4
+.IX Item "-mimpure-text"
+\&\fB\-mimpure\-text\fR, used in addition to \fB\-shared\fR, tells
+the compiler to not pass \fB\-z text\fR to the linker when linking a
+shared object.  Using this option, you can link position-dependent
+code into a shared object.
+.Sp
+\&\fB\-mimpure\-text\fR suppresses the \*(L"relocations remain against
+allocatable but non-writable sections\*(R" linker error message.
+However, the necessary relocations trigger copy-on-write, and the
+shared object is not actually shared across processes.  Instead of
+using \fB\-mimpure\-text\fR, you should compile all source code with
+\&\fB\-fpic\fR or \fB\-fPIC\fR.
+.PP
+These switches are supported in addition to the above on Solaris 2:
+.IP "\fB\-pthreads\fR" 4
+.IX Item "-pthreads"
+Add support for multithreading using the \s-1POSIX\s0 threads library.  This
+option sets flags for both the preprocessor and linker.  This option does
+not affect the thread safety of object code produced  by the compiler or
+that of libraries supplied with it.
+.IP "\fB\-pthread\fR" 4
+.IX Item "-pthread"
+This is a synonym for \fB\-pthreads\fR.
+.PP
+\fI\s-1SPARC\s0 Options\fR
+.IX Subsection "SPARC Options"
+.PP
+These \fB\-m\fR options are supported on the \s-1SPARC:\s0
+.IP "\fB\-mno\-app\-regs\fR" 4
+.IX Item "-mno-app-regs"
+.PD 0
+.IP "\fB\-mapp\-regs\fR" 4
+.IX Item "-mapp-regs"
+.PD
+Specify \fB\-mapp\-regs\fR to generate output using the global registers
+2 through 4, which the \s-1SPARC SVR4 ABI\s0 reserves for applications.  Like the
+global register 1, each global register 2 through 4 is then treated as an
+allocable register that is clobbered by function calls.  This is the default.
+.Sp
+To be fully \s-1SVR4\s0 ABI-compliant at the cost of some performance loss,
+specify \fB\-mno\-app\-regs\fR.  You should compile libraries and system
+software with this option.
+.IP "\fB\-mflat\fR" 4
+.IX Item "-mflat"
+.PD 0
+.IP "\fB\-mno\-flat\fR" 4
+.IX Item "-mno-flat"
+.PD
+With \fB\-mflat\fR, the compiler does not generate save/restore instructions
+and uses a \*(L"flat\*(R" or single register window model.  This model is compatible
+with the regular register window model.  The local registers and the input
+registers (0\-\-5) are still treated as \*(L"call-saved\*(R" registers and are
+saved on the stack as needed.
+.Sp
+With \fB\-mno\-flat\fR (the default), the compiler generates save/restore
+instructions (except for leaf functions).  This is the normal operating mode.
+.IP "\fB\-mfpu\fR" 4
+.IX Item "-mfpu"
+.PD 0
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD
+Generate output containing floating-point instructions.  This is the
+default.
+.IP "\fB\-mno\-fpu\fR" 4
+.IX Item "-mno-fpu"
+.PD 0
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD
+Generate output containing library calls for floating point.
+\&\fBWarning:\fR the requisite libraries are not available for all \s-1SPARC\s0
+targets.  Normally the facilities of the machine's usual C compiler are
+used, but this cannot be done directly in cross-compilation.  You must make
+your own arrangements to provide suitable library functions for
+cross-compilation.  The embedded targets \fBsparc\-*\-aout\fR and
+\&\fBsparclite\-*\-*\fR do provide software floating-point support.
+.Sp
+\&\fB\-msoft\-float\fR changes the calling convention in the output file;
+therefore, it is only useful if you compile \fIall\fR of a program with
+this option.  In particular, you need to compile \fIlibgcc.a\fR, the
+library that comes with \s-1GCC,\s0 with \fB\-msoft\-float\fR in order for
+this to work.
+.IP "\fB\-mhard\-quad\-float\fR" 4
+.IX Item "-mhard-quad-float"
+Generate output containing quad-word (long double) floating-point
+instructions.
+.IP "\fB\-msoft\-quad\-float\fR" 4
+.IX Item "-msoft-quad-float"
+Generate output containing library calls for quad-word (long double)
+floating-point instructions.  The functions called are those specified
+in the \s-1SPARC ABI. \s0 This is the default.
+.Sp
+As of this writing, there are no \s-1SPARC\s0 implementations that have hardware
+support for the quad-word floating-point instructions.  They all invoke
+a trap handler for one of these instructions, and then the trap handler
+emulates the effect of the instruction.  Because of the trap handler overhead,
+this is much slower than calling the \s-1ABI\s0 library routines.  Thus the
+\&\fB\-msoft\-quad\-float\fR option is the default.
+.IP "\fB\-mno\-unaligned\-doubles\fR" 4
+.IX Item "-mno-unaligned-doubles"
+.PD 0
+.IP "\fB\-munaligned\-doubles\fR" 4
+.IX Item "-munaligned-doubles"
+.PD
+Assume that doubles have 8\-byte alignment.  This is the default.
+.Sp
+With \fB\-munaligned\-doubles\fR, \s-1GCC\s0 assumes that doubles have 8\-byte
+alignment only if they are contained in another type, or if they have an
+absolute address.  Otherwise, it assumes they have 4\-byte alignment.
+Specifying this option avoids some rare compatibility problems with code
+generated by other compilers.  It is not the default because it results
+in a performance loss, especially for floating-point code.
+.IP "\fB\-mno\-faster\-structs\fR" 4
+.IX Item "-mno-faster-structs"
+.PD 0
+.IP "\fB\-mfaster\-structs\fR" 4
+.IX Item "-mfaster-structs"
+.PD
+With \fB\-mfaster\-structs\fR, the compiler assumes that structures
+should have 8\-byte alignment.  This enables the use of pairs of
+\&\f(CW\*(C`ldd\*(C'\fR and \f(CW\*(C`std\*(C'\fR instructions for copies in structure
+assignment, in place of twice as many \f(CW\*(C`ld\*(C'\fR and \f(CW\*(C`st\*(C'\fR pairs.
+However, the use of this changed alignment directly violates the \s-1SPARC
+ABI. \s0 Thus, it's intended only for use on targets where the developer
+acknowledges that their resulting code is not directly in line with
+the rules of the \s-1ABI.\s0
+.IP "\fB\-mcpu=\fR\fIcpu_type\fR" 4
+.IX Item "-mcpu=cpu_type"
+Set the instruction set, register set, and instruction scheduling parameters
+for machine type \fIcpu_type\fR.  Supported values for \fIcpu_type\fR are
+\&\fBv7\fR, \fBcypress\fR, \fBv8\fR, \fBsupersparc\fR, \fBhypersparc\fR,
+\&\fBleon\fR, \fBleon3\fR, \fBsparclite\fR, \fBf930\fR, \fBf934\fR,
+\&\fBsparclite86x\fR, \fBsparclet\fR, \fBtsc701\fR, \fBv9\fR,
+\&\fBultrasparc\fR, \fBultrasparc3\fR, \fBniagara\fR, \fBniagara2\fR,
+\&\fBniagara3\fR and \fBniagara4\fR.
+.Sp
+Native Solaris and GNU/Linux toolchains also support the value \fBnative\fR,
+which selects the best architecture option for the host processor.
+\&\fB\-mcpu=native\fR has no effect if \s-1GCC\s0 does not recognize
+the processor.
+.Sp
+Default instruction scheduling parameters are used for values that select
+an architecture and not an implementation.  These are \fBv7\fR, \fBv8\fR,
+\&\fBsparclite\fR, \fBsparclet\fR, \fBv9\fR.
+.Sp
+Here is a list of each supported architecture and their supported
+implementations.
+.RS 4
+.IP "v7" 4
+.IX Item "v7"
+cypress
+.IP "v8" 4
+.IX Item "v8"
+supersparc, hypersparc, leon, leon3
+.IP "sparclite" 4
+.IX Item "sparclite"
+f930, f934, sparclite86x
+.IP "sparclet" 4
+.IX Item "sparclet"
+tsc701
+.IP "v9" 4
+.IX Item "v9"
+ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4
+.RE
+.RS 4
+.Sp
+By default (unless configured otherwise), \s-1GCC\s0 generates code for the V7
+variant of the \s-1SPARC\s0 architecture.  With \fB\-mcpu=cypress\fR, the compiler
+additionally optimizes it for the Cypress \s-1CY7C602\s0 chip, as used in the
+SPARCStation/SPARCServer 3xx series.  This is also appropriate for the older
+SPARCStation 1, 2, \s-1IPX\s0 etc.
+.Sp
+With \fB\-mcpu=v8\fR, \s-1GCC\s0 generates code for the V8 variant of the \s-1SPARC\s0
+architecture.  The only difference from V7 code is that the compiler emits
+the integer multiply and integer divide instructions which exist in \s-1SPARC\-V8\s0
+but not in \s-1SPARC\-V7. \s0 With \fB\-mcpu=supersparc\fR, the compiler additionally
+optimizes it for the SuperSPARC chip, as used in the SPARCStation 10, 1000 and
+2000 series.
+.Sp
+With \fB\-mcpu=sparclite\fR, \s-1GCC\s0 generates code for the SPARClite variant of
+the \s-1SPARC\s0 architecture.  This adds the integer multiply, integer divide step
+and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClite but not in \s-1SPARC\-V7.\s0
+With \fB\-mcpu=f930\fR, the compiler additionally optimizes it for the
+Fujitsu \s-1MB86930\s0 chip, which is the original SPARClite, with no \s-1FPU. \s0 With
+\&\fB\-mcpu=f934\fR, the compiler additionally optimizes it for the Fujitsu
+\&\s-1MB86934\s0 chip, which is the more recent SPARClite with \s-1FPU.\s0
+.Sp
+With \fB\-mcpu=sparclet\fR, \s-1GCC\s0 generates code for the SPARClet variant of
+the \s-1SPARC\s0 architecture.  This adds the integer multiply, multiply/accumulate,
+integer divide step and scan (\f(CW\*(C`ffs\*(C'\fR) instructions which exist in SPARClet
+but not in \s-1SPARC\-V7. \s0 With \fB\-mcpu=tsc701\fR, the compiler additionally
+optimizes it for the \s-1TEMIC\s0 SPARClet chip.
+.Sp
+With \fB\-mcpu=v9\fR, \s-1GCC\s0 generates code for the V9 variant of the \s-1SPARC\s0
+architecture.  This adds 64\-bit integer and floating-point move instructions,
+3 additional floating-point condition code registers and conditional move
+instructions.  With \fB\-mcpu=ultrasparc\fR, the compiler additionally
+optimizes it for the Sun UltraSPARC I/II/IIi chips.  With
+\&\fB\-mcpu=ultrasparc3\fR, the compiler additionally optimizes it for the
+Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+ chips.  With
+\&\fB\-mcpu=niagara\fR, the compiler additionally optimizes it for
+Sun UltraSPARC T1 chips.  With \fB\-mcpu=niagara2\fR, the compiler
+additionally optimizes it for Sun UltraSPARC T2 chips. With
+\&\fB\-mcpu=niagara3\fR, the compiler additionally optimizes it for Sun
+UltraSPARC T3 chips.  With \fB\-mcpu=niagara4\fR, the compiler
+additionally optimizes it for Sun UltraSPARC T4 chips.
+.RE
+.IP "\fB\-mtune=\fR\fIcpu_type\fR" 4
+.IX Item "-mtune=cpu_type"
+Set the instruction scheduling parameters for machine type
+\&\fIcpu_type\fR, but do not set the instruction set or register set that the
+option \fB\-mcpu=\fR\fIcpu_type\fR does.
+.Sp
+The same values for \fB\-mcpu=\fR\fIcpu_type\fR can be used for
+\&\fB\-mtune=\fR\fIcpu_type\fR, but the only useful values are those
+that select a particular \s-1CPU\s0 implementation.  Those are \fBcypress\fR,
+\&\fBsupersparc\fR, \fBhypersparc\fR, \fBleon\fR, \fBleon3\fR, \fBf930\fR,
+\&\fBf934\fR, \fBsparclite86x\fR, \fBtsc701\fR, \fBultrasparc\fR,
+\&\fBultrasparc3\fR, \fBniagara\fR, \fBniagara2\fR, \fBniagara3\fR and
+\&\fBniagara4\fR.  With native Solaris and GNU/Linux toolchains, \fBnative\fR
+can also be used.
+.IP "\fB\-mv8plus\fR" 4
+.IX Item "-mv8plus"
+.PD 0
+.IP "\fB\-mno\-v8plus\fR" 4
+.IX Item "-mno-v8plus"
+.PD
+With \fB\-mv8plus\fR, \s-1GCC\s0 generates code for the \s-1SPARC\-V8+ ABI. \s0 The
+difference from the V8 \s-1ABI\s0 is that the global and out registers are
+considered 64 bits wide.  This is enabled by default on Solaris in 32\-bit
+mode for all \s-1SPARC\-V9\s0 processors.
+.IP "\fB\-mvis\fR" 4
+.IX Item "-mvis"
+.PD 0
+.IP "\fB\-mno\-vis\fR" 4
+.IX Item "-mno-vis"
+.PD
+With \fB\-mvis\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
+Visual Instruction Set extensions.  The default is \fB\-mno\-vis\fR.
+.IP "\fB\-mvis2\fR" 4
+.IX Item "-mvis2"
+.PD 0
+.IP "\fB\-mno\-vis2\fR" 4
+.IX Item "-mno-vis2"
+.PD
+With \fB\-mvis2\fR, \s-1GCC\s0 generates code that takes advantage of
+version 2.0 of the UltraSPARC Visual Instruction Set extensions.  The
+default is \fB\-mvis2\fR when targeting a cpu that supports such
+instructions, such as UltraSPARC-III and later.  Setting \fB\-mvis2\fR
+also sets \fB\-mvis\fR.
+.IP "\fB\-mvis3\fR" 4
+.IX Item "-mvis3"
+.PD 0
+.IP "\fB\-mno\-vis3\fR" 4
+.IX Item "-mno-vis3"
+.PD
+With \fB\-mvis3\fR, \s-1GCC\s0 generates code that takes advantage of
+version 3.0 of the UltraSPARC Visual Instruction Set extensions.  The
+default is \fB\-mvis3\fR when targeting a cpu that supports such
+instructions, such as niagara\-3 and later.  Setting \fB\-mvis3\fR
+also sets \fB\-mvis2\fR and \fB\-mvis\fR.
+.IP "\fB\-mcbcond\fR" 4
+.IX Item "-mcbcond"
+.PD 0
+.IP "\fB\-mno\-cbcond\fR" 4
+.IX Item "-mno-cbcond"
+.PD
+With \fB\-mcbcond\fR, \s-1GCC\s0 generates code that takes advantage of
+compare-and-branch instructions, as defined in the Sparc Architecture 2011.
+The default is \fB\-mcbcond\fR when targeting a cpu that supports such
+instructions, such as niagara\-4 and later.
+.IP "\fB\-mpopc\fR" 4
+.IX Item "-mpopc"
+.PD 0
+.IP "\fB\-mno\-popc\fR" 4
+.IX Item "-mno-popc"
+.PD
+With \fB\-mpopc\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
+population count instruction.  The default is \fB\-mpopc\fR
+when targeting a cpu that supports such instructions, such as Niagara\-2 and
+later.
+.IP "\fB\-mfmaf\fR" 4
+.IX Item "-mfmaf"
+.PD 0
+.IP "\fB\-mno\-fmaf\fR" 4
+.IX Item "-mno-fmaf"
+.PD
+With \fB\-mfmaf\fR, \s-1GCC\s0 generates code that takes advantage of the UltraSPARC
+Fused Multiply-Add Floating-point extensions.  The default is \fB\-mfmaf\fR
+when targeting a cpu that supports such instructions, such as Niagara\-3 and
+later.
+.IP "\fB\-mfix\-at697f\fR" 4
+.IX Item "-mfix-at697f"
+Enable the documented workaround for the single erratum of the Atmel \s-1AT697F\s0
+processor (which corresponds to erratum #13 of the \s-1AT697E\s0 processor).
+.IP "\fB\-mfix\-ut699\fR" 4
+.IX Item "-mfix-ut699"
+Enable the documented workarounds for the floating-point errata and the data
+cache nullify errata of the \s-1UT699\s0 processor.
+.PP
+These \fB\-m\fR options are supported in addition to the above
+on \s-1SPARC\-V9\s0 processors in 64\-bit environments:
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+.PD 0
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.PD
+Generate code for a 32\-bit or 64\-bit environment.
+The 32\-bit environment sets int, long and pointer to 32 bits.
+The 64\-bit environment sets int to 32 bits and long and pointer
+to 64 bits.
+.IP "\fB\-mcmodel=\fR\fIwhich\fR" 4
+.IX Item "-mcmodel=which"
+Set the code model to one of
+.RS 4
+.IP "\fBmedlow\fR" 4
+.IX Item "medlow"
+The Medium/Low code model: 64\-bit addresses, programs
+must be linked in the low 32 bits of memory.  Programs can be statically
+or dynamically linked.
+.IP "\fBmedmid\fR" 4
+.IX Item "medmid"
+The Medium/Middle code model: 64\-bit addresses, programs
+must be linked in the low 44 bits of memory, the text and data segments must
+be less than 2GB in size and the data segment must be located within 2GB of
+the text segment.
+.IP "\fBmedany\fR" 4
+.IX Item "medany"
+The Medium/Anywhere code model: 64\-bit addresses, programs
+may be linked anywhere in memory, the text and data segments must be less
+than 2GB in size and the data segment must be located within 2GB of the
+text segment.
+.IP "\fBembmedany\fR" 4
+.IX Item "embmedany"
+The Medium/Anywhere code model for embedded systems:
+64\-bit addresses, the text and data segments must be less than 2GB in
+size, both starting anywhere in memory (determined at link time).  The
+global register \f(CW%g4\fR points to the base of the data segment.  Programs
+are statically linked and \s-1PIC\s0 is not supported.
+.RE
+.RS 4
+.RE
+.IP "\fB\-mmemory\-model=\fR\fImem-model\fR" 4
+.IX Item "-mmemory-model=mem-model"
+Set the memory model in force on the processor to one of
+.RS 4
+.IP "\fBdefault\fR" 4
+.IX Item "default"
+The default memory model for the processor and operating system.
+.IP "\fBrmo\fR" 4
+.IX Item "rmo"
+Relaxed Memory Order
+.IP "\fBpso\fR" 4
+.IX Item "pso"
+Partial Store Order
+.IP "\fBtso\fR" 4
+.IX Item "tso"
+Total Store Order
+.IP "\fBsc\fR" 4
+.IX Item "sc"
+Sequential Consistency
+.RE
+.RS 4
+.Sp
+These memory models are formally defined in Appendix D of the Sparc V9
+architecture manual, as set in the processor's \f(CW\*(C`PSTATE.MM\*(C'\fR field.
+.RE
+.IP "\fB\-mstack\-bias\fR" 4
+.IX Item "-mstack-bias"
+.PD 0
+.IP "\fB\-mno\-stack\-bias\fR" 4
+.IX Item "-mno-stack-bias"
+.PD
+With \fB\-mstack\-bias\fR, \s-1GCC\s0 assumes that the stack pointer, and
+frame pointer if present, are offset by \-2047 which must be added back
+when making stack frame references.  This is the default in 64\-bit mode.
+Otherwise, assume no such offset is present.
+.PP
+\fI\s-1SPU\s0 Options\fR
+.IX Subsection "SPU Options"
+.PP
+These \fB\-m\fR options are supported on the \s-1SPU:\s0
+.IP "\fB\-mwarn\-reloc\fR" 4
+.IX Item "-mwarn-reloc"
+.PD 0
+.IP "\fB\-merror\-reloc\fR" 4
+.IX Item "-merror-reloc"
+.PD
+The loader for \s-1SPU\s0 does not handle dynamic relocations.  By default, \s-1GCC\s0
+gives an error when it generates code that requires a dynamic
+relocation.  \fB\-mno\-error\-reloc\fR disables the error,
+\&\fB\-mwarn\-reloc\fR generates a warning instead.
+.IP "\fB\-msafe\-dma\fR" 4
+.IX Item "-msafe-dma"
+.PD 0
+.IP "\fB\-munsafe\-dma\fR" 4
+.IX Item "-munsafe-dma"
+.PD
+Instructions that initiate or test completion of \s-1DMA\s0 must not be
+reordered with respect to loads and stores of the memory that is being
+accessed.
+With \fB\-munsafe\-dma\fR you must use the \f(CW\*(C`volatile\*(C'\fR keyword to protect
+memory accesses, but that can lead to inefficient code in places where the
+memory is known to not change.  Rather than mark the memory as volatile,
+you can use \fB\-msafe\-dma\fR to tell the compiler to treat
+the \s-1DMA\s0 instructions as potentially affecting all memory.
+.IP "\fB\-mbranch\-hints\fR" 4
+.IX Item "-mbranch-hints"
+By default, \s-1GCC\s0 generates a branch hint instruction to avoid
+pipeline stalls for always-taken or probably-taken branches.  A hint
+is not generated closer than 8 instructions away from its branch.
+There is little reason to disable them, except for debugging purposes,
+or to make an object a little bit smaller.
+.IP "\fB\-msmall\-mem\fR" 4
+.IX Item "-msmall-mem"
+.PD 0
+.IP "\fB\-mlarge\-mem\fR" 4
+.IX Item "-mlarge-mem"
+.PD
+By default, \s-1GCC\s0 generates code assuming that addresses are never larger
+than 18 bits.  With \fB\-mlarge\-mem\fR code is generated that assumes
+a full 32\-bit address.
+.IP "\fB\-mstdmain\fR" 4
+.IX Item "-mstdmain"
+By default, \s-1GCC\s0 links against startup code that assumes the SPU-style
+main function interface (which has an unconventional parameter list).
+With \fB\-mstdmain\fR, \s-1GCC\s0 links your program against startup
+code that assumes a C99\-style interface to \f(CW\*(C`main\*(C'\fR, including a
+local copy of \f(CW\*(C`argv\*(C'\fR strings.
+.IP "\fB\-mfixed\-range=\fR\fIregister-range\fR" 4
+.IX Item "-mfixed-range=register-range"
+Generate code treating the given register range as fixed registers.
+A fixed register is one that the register allocator cannot use.  This is
+useful when compiling kernel code.  A register range is specified as
+two registers separated by a dash.  Multiple register ranges can be
+specified separated by a comma.
+.IP "\fB\-mea32\fR" 4
+.IX Item "-mea32"
+.PD 0
+.IP "\fB\-mea64\fR" 4
+.IX Item "-mea64"
+.PD
+Compile code assuming that pointers to the \s-1PPU\s0 address space accessed
+via the \f(CW\*(C`_\|_ea\*(C'\fR named address space qualifier are either 32 or 64
+bits wide.  The default is 32 bits.  As this is an ABI-changing option,
+all object code in an executable must be compiled with the same setting.
+.IP "\fB\-maddress\-space\-conversion\fR" 4
+.IX Item "-maddress-space-conversion"
+.PD 0
+.IP "\fB\-mno\-address\-space\-conversion\fR" 4
+.IX Item "-mno-address-space-conversion"
+.PD
+Allow/disallow treating the \f(CW\*(C`_\|_ea\*(C'\fR address space as superset
+of the generic address space.  This enables explicit type casts
+between \f(CW\*(C`_\|_ea\*(C'\fR and generic pointer as well as implicit
+conversions of generic pointers to \f(CW\*(C`_\|_ea\*(C'\fR pointers.  The
+default is to allow address space pointer conversions.
+.IP "\fB\-mcache\-size=\fR\fIcache-size\fR" 4
+.IX Item "-mcache-size=cache-size"
+This option controls the version of libgcc that the compiler links to an
+executable and selects a software-managed cache for accessing variables
+in the \f(CW\*(C`_\|_ea\*(C'\fR address space with a particular cache size.  Possible
+options for \fIcache-size\fR are \fB8\fR, \fB16\fR, \fB32\fR, \fB64\fR
+and \fB128\fR.  The default cache size is 64KB.
+.IP "\fB\-matomic\-updates\fR" 4
+.IX Item "-matomic-updates"
+.PD 0
+.IP "\fB\-mno\-atomic\-updates\fR" 4
+.IX Item "-mno-atomic-updates"
+.PD
+This option controls the version of libgcc that the compiler links to an
+executable and selects whether atomic updates to the software-managed
+cache of PPU-side variables are used.  If you use atomic updates, changes
+to a \s-1PPU\s0 variable from \s-1SPU\s0 code using the \f(CW\*(C`_\|_ea\*(C'\fR named address space
+qualifier do not interfere with changes to other \s-1PPU\s0 variables residing
+in the same cache line from \s-1PPU\s0 code.  If you do not use atomic updates,
+such interference may occur; however, writing back cache lines is
+more efficient.  The default behavior is to use atomic updates.
+.IP "\fB\-mdual\-nops\fR" 4
+.IX Item "-mdual-nops"
+.PD 0
+.IP "\fB\-mdual\-nops=\fR\fIn\fR" 4
+.IX Item "-mdual-nops=n"
+.PD
+By default, \s-1GCC\s0 inserts nops to increase dual issue when it expects
+it to increase performance.  \fIn\fR can be a value from 0 to 10.  A
+smaller \fIn\fR inserts fewer nops.  10 is the default, 0 is the
+same as \fB\-mno\-dual\-nops\fR.  Disabled with \fB\-Os\fR.
+.IP "\fB\-mhint\-max\-nops=\fR\fIn\fR" 4
+.IX Item "-mhint-max-nops=n"
+Maximum number of nops to insert for a branch hint.  A branch hint must
+be at least 8 instructions away from the branch it is affecting.  \s-1GCC\s0
+inserts up to \fIn\fR nops to enforce this, otherwise it does not
+generate the branch hint.
+.IP "\fB\-mhint\-max\-distance=\fR\fIn\fR" 4
+.IX Item "-mhint-max-distance=n"
+The encoding of the branch hint instruction limits the hint to be within
+256 instructions of the branch it is affecting.  By default, \s-1GCC\s0 makes
+sure it is within 125.
+.IP "\fB\-msafe\-hints\fR" 4
+.IX Item "-msafe-hints"
+Work around a hardware bug that causes the \s-1SPU\s0 to stall indefinitely.
+By default, \s-1GCC\s0 inserts the \f(CW\*(C`hbrp\*(C'\fR instruction to make sure
+this stall won't happen.
+.PP
+\fIOptions for System V\fR
+.IX Subsection "Options for System V"
+.PP
+These additional options are available on System V Release 4 for
+compatibility with other compilers on those systems:
+.IP "\fB\-G\fR" 4
+.IX Item "-G"
+Create a shared object.
+It is recommended that \fB\-symbolic\fR or \fB\-shared\fR be used instead.
+.IP "\fB\-Qy\fR" 4
+.IX Item "-Qy"
+Identify the versions of each tool used by the compiler, in a
+\&\f(CW\*(C`.ident\*(C'\fR assembler directive in the output.
+.IP "\fB\-Qn\fR" 4
+.IX Item "-Qn"
+Refrain from adding \f(CW\*(C`.ident\*(C'\fR directives to the output file (this is
+the default).
+.IP "\fB\-YP,\fR\fIdirs\fR" 4
+.IX Item "-YP,dirs"
+Search the directories \fIdirs\fR, and no others, for libraries
+specified with \fB\-l\fR.
+.IP "\fB\-Ym,\fR\fIdir\fR" 4
+.IX Item "-Ym,dir"
+Look in the directory \fIdir\fR to find the M4 preprocessor.
+The assembler uses this option.
+.PP
+\fITILE-Gx Options\fR
+.IX Subsection "TILE-Gx Options"
+.PP
+These \fB\-m\fR options are supported on the TILE-Gx:
+.IP "\fB\-mcmodel=small\fR" 4
+.IX Item "-mcmodel=small"
+Generate code for the small model.  The distance for direct calls is
+limited to 500M in either direction.  PC-relative addresses are 32
+bits.  Absolute addresses support the full address range.
+.IP "\fB\-mcmodel=large\fR" 4
+.IX Item "-mcmodel=large"
+Generate code for the large model.  There is no limitation on call
+distance, pc-relative addresses, or absolute addresses.
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Selects the type of \s-1CPU\s0 to be targeted.  Currently the only supported
+type is \fBtilegx\fR.
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+.PD 0
+.IP "\fB\-m64\fR" 4
+.IX Item "-m64"
+.PD
+Generate code for a 32\-bit or 64\-bit environment.  The 32\-bit
+environment sets int, long, and pointer to 32 bits.  The 64\-bit
+environment sets int to 32 bits and long and pointer to 64 bits.
+.IP "\fB\-mbig\-endian\fR" 4
+.IX Item "-mbig-endian"
+.PD 0
+.IP "\fB\-mlittle\-endian\fR" 4
+.IX Item "-mlittle-endian"
+.PD
+Generate code in big/little endian mode, respectively.
+.PP
+\fITILEPro Options\fR
+.IX Subsection "TILEPro Options"
+.PP
+These \fB\-m\fR options are supported on the TILEPro:
+.IP "\fB\-mcpu=\fR\fIname\fR" 4
+.IX Item "-mcpu=name"
+Selects the type of \s-1CPU\s0 to be targeted.  Currently the only supported
+type is \fBtilepro\fR.
+.IP "\fB\-m32\fR" 4
+.IX Item "-m32"
+Generate code for a 32\-bit environment, which sets int, long, and
+pointer to 32 bits.  This is the only supported behavior so the flag
+is essentially ignored.
+.PP
+\fIV850 Options\fR
+.IX Subsection "V850 Options"
+.PP
+These \fB\-m\fR options are defined for V850 implementations:
+.IP "\fB\-mlong\-calls\fR" 4
+.IX Item "-mlong-calls"
+.PD 0
+.IP "\fB\-mno\-long\-calls\fR" 4
+.IX Item "-mno-long-calls"
+.PD
+Treat all calls as being far away (near).  If calls are assumed to be
+far away, the compiler always loads the function's address into a
+register, and calls indirect through the pointer.
+.IP "\fB\-mno\-ep\fR" 4
+.IX Item "-mno-ep"
+.PD 0
+.IP "\fB\-mep\fR" 4
+.IX Item "-mep"
+.PD
+Do not optimize (do optimize) basic blocks that use the same index
+pointer 4 or more times to copy pointer into the \f(CW\*(C`ep\*(C'\fR register, and
+use the shorter \f(CW\*(C`sld\*(C'\fR and \f(CW\*(C`sst\*(C'\fR instructions.  The \fB\-mep\fR
+option is on by default if you optimize.
+.IP "\fB\-mno\-prolog\-function\fR" 4
+.IX Item "-mno-prolog-function"
+.PD 0
+.IP "\fB\-mprolog\-function\fR" 4
+.IX Item "-mprolog-function"
+.PD
+Do not use (do use) external functions to save and restore registers
+at the prologue and epilogue of a function.  The external functions
+are slower, but use less code space if more than one function saves
+the same number of registers.  The \fB\-mprolog\-function\fR option
+is on by default if you optimize.
+.IP "\fB\-mspace\fR" 4
+.IX Item "-mspace"
+Try to make the code as small as possible.  At present, this just turns
+on the \fB\-mep\fR and \fB\-mprolog\-function\fR options.
+.IP "\fB\-mtda=\fR\fIn\fR" 4
+.IX Item "-mtda=n"
+Put static or global variables whose size is \fIn\fR bytes or less into
+the tiny data area that register \f(CW\*(C`ep\*(C'\fR points to.  The tiny data
+area can hold up to 256 bytes in total (128 bytes for byte references).
+.IP "\fB\-msda=\fR\fIn\fR" 4
+.IX Item "-msda=n"
+Put static or global variables whose size is \fIn\fR bytes or less into
+the small data area that register \f(CW\*(C`gp\*(C'\fR points to.  The small data
+area can hold up to 64 kilobytes.
+.IP "\fB\-mzda=\fR\fIn\fR" 4
+.IX Item "-mzda=n"
+Put static or global variables whose size is \fIn\fR bytes or less into
+the first 32 kilobytes of memory.
+.IP "\fB\-mv850\fR" 4
+.IX Item "-mv850"
+Specify that the target processor is the V850.
+.IP "\fB\-mv850e3v5\fR" 4
+.IX Item "-mv850e3v5"
+Specify that the target processor is the V850E3V5.  The preprocessor
+constant \fB_\|_v850e3v5_\|_\fR is defined if this option is used.
+.IP "\fB\-mv850e2v4\fR" 4
+.IX Item "-mv850e2v4"
+Specify that the target processor is the V850E3V5.  This is an alias for
+the \fB\-mv850e3v5\fR option.
+.IP "\fB\-mv850e2v3\fR" 4
+.IX Item "-mv850e2v3"
+Specify that the target processor is the V850E2V3.  The preprocessor
+constant \fB_\|_v850e2v3_\|_\fR is defined if this option is used.
+.IP "\fB\-mv850e2\fR" 4
+.IX Item "-mv850e2"
+Specify that the target processor is the V850E2.  The preprocessor
+constant \fB_\|_v850e2_\|_\fR is defined if this option is used.
+.IP "\fB\-mv850e1\fR" 4
+.IX Item "-mv850e1"
+Specify that the target processor is the V850E1.  The preprocessor
+constants \fB_\|_v850e1_\|_\fR and \fB_\|_v850e_\|_\fR are defined if
+this option is used.
+.IP "\fB\-mv850es\fR" 4
+.IX Item "-mv850es"
+Specify that the target processor is the V850ES.  This is an alias for
+the \fB\-mv850e1\fR option.
+.IP "\fB\-mv850e\fR" 4
+.IX Item "-mv850e"
+Specify that the target processor is the V850E.  The preprocessor
+constant \fB_\|_v850e_\|_\fR is defined if this option is used.
+.Sp
+If neither \fB\-mv850\fR nor \fB\-mv850e\fR nor \fB\-mv850e1\fR
+nor \fB\-mv850e2\fR nor \fB\-mv850e2v3\fR nor \fB\-mv850e3v5\fR
+are defined then a default target processor is chosen and the
+relevant \fB_\|_v850*_\|_\fR preprocessor constant is defined.
+.Sp
+The preprocessor constants \fB_\|_v850\fR and \fB_\|_v851_\|_\fR are always
+defined, regardless of which processor variant is the target.
+.IP "\fB\-mdisable\-callt\fR" 4
+.IX Item "-mdisable-callt"
+.PD 0
+.IP "\fB\-mno\-disable\-callt\fR" 4
+.IX Item "-mno-disable-callt"
+.PD
+This option suppresses generation of the \f(CW\*(C`CALLT\*(C'\fR instruction for the
+v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the v850
+architecture.
+.Sp
+This option is enabled by default when the \s-1RH850 ABI\s0 is
+in use (see \fB\-mrh850\-abi\fR), and disabled by default when the
+\&\s-1GCC ABI\s0 is in use.  If \f(CW\*(C`CALLT\*(C'\fR instructions are being generated
+then the C preprocessor symbol \f(CW\*(C`_\|_V850_CALLT_\|_\*(C'\fR will be defined.
+.IP "\fB\-mrelax\fR" 4
+.IX Item "-mrelax"
+.PD 0
+.IP "\fB\-mno\-relax\fR" 4
+.IX Item "-mno-relax"
+.PD
+Pass on (or do not pass on) the \fB\-mrelax\fR command line option
+to the assembler.
+.IP "\fB\-mlong\-jumps\fR" 4
+.IX Item "-mlong-jumps"
+.PD 0
+.IP "\fB\-mno\-long\-jumps\fR" 4
+.IX Item "-mno-long-jumps"
+.PD
+Disable (or re-enable) the generation of PC-relative jump instructions.
+.IP "\fB\-msoft\-float\fR" 4
+.IX Item "-msoft-float"
+.PD 0
+.IP "\fB\-mhard\-float\fR" 4
+.IX Item "-mhard-float"
+.PD
+Disable (or re-enable) the generation of hardware floating point
+instructions.  This option is only significant when the target
+architecture is \fBV850E2V3\fR or higher.  If hardware floating point
+instructions are being generated then the C preprocessor symbol
+\&\f(CW\*(C`_\|_FPU_OK_\|_\*(C'\fR will be defined, otherwise the symbol
+\&\f(CW\*(C`_\|_NO_FPU_\|_\*(C'\fR will be defined.
+.IP "\fB\-mloop\fR" 4
+.IX Item "-mloop"
+Enables the use of the e3v5 \s-1LOOP\s0 instruction.  The use of this
+instruction is not enabled by default when the e3v5 architecture is
+selected because its use is still experimental.
+.IP "\fB\-mrh850\-abi\fR" 4
+.IX Item "-mrh850-abi"
+.PD 0
+.IP "\fB\-mghs\fR" 4
+.IX Item "-mghs"
+.PD
+Enables support for the \s-1RH850\s0 version of the V850 \s-1ABI. \s0 This is the
+default.  With this version of the \s-1ABI\s0 the following rules apply:
+.RS 4
+.IP "\(bu" 4
+Integer sized structures and unions are returned via a memory pointer
+rather than a register.
+.IP "\(bu" 4
+Large structures and unions (more than 8 bytes in size) are passed by
+value.
+.IP "\(bu" 4
+Functions are aligned to 16\-bit boundaries.
+.IP "\(bu" 4
+The \fB\-m8byte\-align\fR command line option is supported.
+.IP "\(bu" 4
+The \fB\-mdisable\-callt\fR command line option is enabled by
+default.  The \fB\-mno\-disable\-callt\fR command line option is not
+supported.
+.RE
+.RS 4
+.Sp
+When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
+\&\f(CW\*(C`_\|_V850_RH850_ABI_\|_\*(C'\fR is defined.
+.RE
+.IP "\fB\-mgcc\-abi\fR" 4
+.IX Item "-mgcc-abi"
+Enables support for the old \s-1GCC\s0 version of the V850 \s-1ABI. \s0 With this
+version of the \s-1ABI\s0 the following rules apply:
+.RS 4
+.IP "\(bu" 4
+Integer sized structures and unions are returned in register \f(CW\*(C`r10\*(C'\fR.
+.IP "\(bu" 4
+Large structures and unions (more than 8 bytes in size) are passed by
+reference.
+.IP "\(bu" 4
+Functions are aligned to 32\-bit boundaries, unless optimizing for
+size.
+.IP "\(bu" 4
+The \fB\-m8byte\-align\fR command line option is not supported.
+.IP "\(bu" 4
+The \fB\-mdisable\-callt\fR command line option is supported but not
+enabled by default.
+.RE
+.RS 4
+.Sp
+When this version of the \s-1ABI\s0 is enabled the C preprocessor symbol
+\&\f(CW\*(C`_\|_V850_GCC_ABI_\|_\*(C'\fR is defined.
+.RE
+.IP "\fB\-m8byte\-align\fR" 4
+.IX Item "-m8byte-align"
+.PD 0
+.IP "\fB\-mno\-8byte\-align\fR" 4
+.IX Item "-mno-8byte-align"
+.PD
+Enables support for \f(CW\*(C`doubles\*(C'\fR and \f(CW\*(C`long long\*(C'\fR types to be
+aligned on 8\-byte boundaries.  The default is to restrict the
+alignment of all objects to at most 4\-bytes.  When
+\&\fB\-m8byte\-align\fR is in effect the C preprocessor symbol
+\&\f(CW\*(C`_\|_V850_8BYTE_ALIGN_\|_\*(C'\fR will be defined.
+.IP "\fB\-mbig\-switch\fR" 4
+.IX Item "-mbig-switch"
+Generate code suitable for big switch tables.  Use this option only if
+the assembler/linker complain about out of range branches within a switch
+table.
+.IP "\fB\-mapp\-regs\fR" 4
+.IX Item "-mapp-regs"
+This option causes r2 and r5 to be used in the code generated by
+the compiler.  This setting is the default.
+.IP "\fB\-mno\-app\-regs\fR" 4
+.IX Item "-mno-app-regs"
+This option causes r2 and r5 to be treated as fixed registers.
+.PP
+\fI\s-1VAX\s0 Options\fR
+.IX Subsection "VAX Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1VAX:\s0
+.IP "\fB\-munix\fR" 4
+.IX Item "-munix"
+Do not output certain jump instructions (\f(CW\*(C`aobleq\*(C'\fR and so on)
+that the Unix assembler for the \s-1VAX\s0 cannot handle across long
+ranges.
+.IP "\fB\-mgnu\fR" 4
+.IX Item "-mgnu"
+Do output those jump instructions, on the assumption that the
+\&\s-1GNU\s0 assembler is being used.
+.IP "\fB\-mg\fR" 4
+.IX Item "-mg"
+Output code for G\-format floating-point numbers instead of D\-format.
+.PP
+\fI\s-1VMS\s0 Options\fR
+.IX Subsection "VMS Options"
+.PP
+These \fB\-m\fR options are defined for the \s-1VMS\s0 implementations:
+.IP "\fB\-mvms\-return\-codes\fR" 4
+.IX Item "-mvms-return-codes"
+Return \s-1VMS\s0 condition codes from \f(CW\*(C`main\*(C'\fR. The default is to return POSIX-style
+condition (e.g. error) codes.
+.IP "\fB\-mdebug\-main=\fR\fIprefix\fR" 4
+.IX Item "-mdebug-main=prefix"
+Flag the first routine whose name starts with \fIprefix\fR as the main
+routine for the debugger.
+.IP "\fB\-mmalloc64\fR" 4
+.IX Item "-mmalloc64"
+Default to 64\-bit memory allocation routines.
+.IP "\fB\-mpointer\-size=\fR\fIsize\fR" 4
+.IX Item "-mpointer-size=size"
+Set the default size of pointers. Possible options for \fIsize\fR are
+\&\fB32\fR or \fBshort\fR for 32 bit pointers, \fB64\fR or \fBlong\fR
+for 64 bit pointers, and \fBno\fR for supporting only 32 bit pointers.
+The later option disables \f(CW\*(C`pragma pointer_size\*(C'\fR.
+.PP
+\fIVxWorks Options\fR
+.IX Subsection "VxWorks Options"
+.PP
+The options in this section are defined for all VxWorks targets.
+Options specific to the target hardware are listed with the other
+options for that target.
+.IP "\fB\-mrtp\fR" 4
+.IX Item "-mrtp"
+\&\s-1GCC\s0 can generate code for both VxWorks kernels and real time processes
+(RTPs).  This option switches from the former to the latter.  It also
+defines the preprocessor macro \f(CW\*(C`_\|_RTP_\|_\*(C'\fR.
+.IP "\fB\-non\-static\fR" 4
+.IX Item "-non-static"
+Link an \s-1RTP\s0 executable against shared libraries rather than static
+libraries.  The options \fB\-static\fR and \fB\-shared\fR can
+also be used for RTPs; \fB\-static\fR
+is the default.
+.IP "\fB\-Bstatic\fR" 4
+.IX Item "-Bstatic"
+.PD 0
+.IP "\fB\-Bdynamic\fR" 4
+.IX Item "-Bdynamic"
+.PD
+These options are passed down to the linker.  They are defined for
+compatibility with Diab.
+.IP "\fB\-Xbind\-lazy\fR" 4
+.IX Item "-Xbind-lazy"
+Enable lazy binding of function calls.  This option is equivalent to
+\&\fB\-Wl,\-z,now\fR and is defined for compatibility with Diab.
+.IP "\fB\-Xbind\-now\fR" 4
+.IX Item "-Xbind-now"
+Disable lazy binding of function calls.  This option is the default and
+is defined for compatibility with Diab.
+.PP
+\fIx86\-64 Options\fR
+.IX Subsection "x86-64 Options"
+.PP
+These are listed under
+.PP
+\fIXstormy16 Options\fR
+.IX Subsection "Xstormy16 Options"
+.PP
+These options are defined for Xstormy16:
+.IP "\fB\-msim\fR" 4
+.IX Item "-msim"
+Choose startup files and linker script suitable for the simulator.
+.PP
+\fIXtensa Options\fR
+.IX Subsection "Xtensa Options"
+.PP
+These options are supported for Xtensa targets:
+.IP "\fB\-mconst16\fR" 4
+.IX Item "-mconst16"
+.PD 0
+.IP "\fB\-mno\-const16\fR" 4
+.IX Item "-mno-const16"
+.PD
+Enable or disable use of \f(CW\*(C`CONST16\*(C'\fR instructions for loading
+constant values.  The \f(CW\*(C`CONST16\*(C'\fR instruction is currently not a
+standard option from Tensilica.  When enabled, \f(CW\*(C`CONST16\*(C'\fR
+instructions are always used in place of the standard \f(CW\*(C`L32R\*(C'\fR
+instructions.  The use of \f(CW\*(C`CONST16\*(C'\fR is enabled by default only if
+the \f(CW\*(C`L32R\*(C'\fR instruction is not available.
+.IP "\fB\-mfused\-madd\fR" 4
+.IX Item "-mfused-madd"
+.PD 0
+.IP "\fB\-mno\-fused\-madd\fR" 4
+.IX Item "-mno-fused-madd"
+.PD
+Enable or disable use of fused multiply/add and multiply/subtract
+instructions in the floating-point option.  This has no effect if the
+floating-point option is not also enabled.  Disabling fused multiply/add
+and multiply/subtract instructions forces the compiler to use separate
+instructions for the multiply and add/subtract operations.  This may be
+desirable in some cases where strict \s-1IEEE\s0 754\-compliant results are
+required: the fused multiply add/subtract instructions do not round the
+intermediate result, thereby producing results with \fImore\fR bits of
+precision than specified by the \s-1IEEE\s0 standard.  Disabling fused multiply
+add/subtract instructions also ensures that the program output is not
+sensitive to the compiler's ability to combine multiply and add/subtract
+operations.
+.IP "\fB\-mserialize\-volatile\fR" 4
+.IX Item "-mserialize-volatile"
+.PD 0
+.IP "\fB\-mno\-serialize\-volatile\fR" 4
+.IX Item "-mno-serialize-volatile"
+.PD
+When this option is enabled, \s-1GCC\s0 inserts \f(CW\*(C`MEMW\*(C'\fR instructions before
+\&\f(CW\*(C`volatile\*(C'\fR memory references to guarantee sequential consistency.
+The default is \fB\-mserialize\-volatile\fR.  Use
+\&\fB\-mno\-serialize\-volatile\fR to omit the \f(CW\*(C`MEMW\*(C'\fR instructions.
+.IP "\fB\-mforce\-no\-pic\fR" 4
+.IX Item "-mforce-no-pic"
+For targets, like GNU/Linux, where all user-mode Xtensa code must be
+position-independent code (\s-1PIC\s0), this option disables \s-1PIC\s0 for compiling
+kernel code.
+.IP "\fB\-mtext\-section\-literals\fR" 4
+.IX Item "-mtext-section-literals"
+.PD 0
+.IP "\fB\-mno\-text\-section\-literals\fR" 4
+.IX Item "-mno-text-section-literals"
+.PD
+Control the treatment of literal pools.  The default is
+\&\fB\-mno\-text\-section\-literals\fR, which places literals in a separate
+section in the output file.  This allows the literal pool to be placed
+in a data \s-1RAM/ROM,\s0 and it also allows the linker to combine literal
+pools from separate object files to remove redundant literals and
+improve code size.  With \fB\-mtext\-section\-literals\fR, the literals
+are interspersed in the text section in order to keep them as close as
+possible to their references.  This may be necessary for large assembly
+files.
+.IP "\fB\-mtarget\-align\fR" 4
+.IX Item "-mtarget-align"
+.PD 0
+.IP "\fB\-mno\-target\-align\fR" 4
+.IX Item "-mno-target-align"
+.PD
+When this option is enabled, \s-1GCC\s0 instructs the assembler to
+automatically align instructions to reduce branch penalties at the
+expense of some code density.  The assembler attempts to widen density
+instructions to align branch targets and the instructions following call
+instructions.  If there are not enough preceding safe density
+instructions to align a target, no widening is performed.  The
+default is \fB\-mtarget\-align\fR.  These options do not affect the
+treatment of auto-aligned instructions like \f(CW\*(C`LOOP\*(C'\fR, which the
+assembler always aligns, either by widening density instructions or
+by inserting \s-1NOP\s0 instructions.
+.IP "\fB\-mlongcalls\fR" 4
+.IX Item "-mlongcalls"
+.PD 0
+.IP "\fB\-mno\-longcalls\fR" 4
+.IX Item "-mno-longcalls"
+.PD
+When this option is enabled, \s-1GCC\s0 instructs the assembler to translate
+direct calls to indirect calls unless it can determine that the target
+of a direct call is in the range allowed by the call instruction.  This
+translation typically occurs for calls to functions in other source
+files.  Specifically, the assembler translates a direct \f(CW\*(C`CALL\*(C'\fR
+instruction into an \f(CW\*(C`L32R\*(C'\fR followed by a \f(CW\*(C`CALLX\*(C'\fR instruction.
+The default is \fB\-mno\-longcalls\fR.  This option should be used in
+programs where the call target can potentially be out of range.  This
+option is implemented in the assembler, not the compiler, so the
+assembly code generated by \s-1GCC\s0 still shows direct call
+instructions\-\-\-look at the disassembled object code to see the actual
+instructions.  Note that the assembler uses an indirect call for
+every cross-file call, not just those that really are out of range.
+.PP
+\fIzSeries Options\fR
+.IX Subsection "zSeries Options"
+.PP
+These are listed under
+.SS "Options for Code Generation Conventions"
+.IX Subsection "Options for Code Generation Conventions"
+These machine-independent options control the interface conventions
+used in code generation.
+.PP
+Most of them have both positive and negative forms; the negative form
+of \fB\-ffoo\fR is \fB\-fno\-foo\fR.  In the table below, only
+one of the forms is listed\-\-\-the one that is not the default.  You
+can figure out the other form by either removing \fBno\-\fR or adding
+it.
+.IP "\fB\-fbounds\-check\fR" 4
+.IX Item "-fbounds-check"
+For front ends that support it, generate additional code to check that
+indices used to access arrays are within the declared range.  This is
+currently only supported by the Java and Fortran front ends, where
+this option defaults to true and false respectively.
+.IP "\fB\-fstack\-reuse=\fR\fIreuse-level\fR" 4
+.IX Item "-fstack-reuse=reuse-level"
+This option controls stack space reuse for user declared local/auto variables
+and compiler generated temporaries.  \fIreuse_level\fR can be \fBall\fR,
+\&\fBnamed_vars\fR, or \fBnone\fR. \fBall\fR enables stack reuse for all
+local variables and temporaries, \fBnamed_vars\fR enables the reuse only for
+user defined local variables with names, and \fBnone\fR disables stack reuse
+completely. The default value is \fBall\fR. The option is needed when the
+program extends the lifetime of a scoped local variable or a compiler generated
+temporary beyond the end point defined by the language.  When a lifetime of
+a variable ends, and if the variable lives in memory, the optimizing compiler
+has the freedom to reuse its stack space with other temporaries or scoped
+local variables whose live range does not overlap with it. Legacy code extending
+local lifetime will likely to break with the stack reuse optimization.
+.Sp
+For example,
+.Sp
+.Vb 3
+\&           int *p;
+\&           {
+\&             int local1;
+\&        
+\&             p = &local1;
+\&             local1 = 10;
+\&             ....
+\&           }
+\&           {
+\&              int local2;
+\&              local2 = 20;
+\&              ...
+\&           }
+\&        
+\&           if (*p == 10)  // out of scope use of local1
+\&             {
+\&        
+\&             }
+.Ve
+.Sp
+Another example:
+.Sp
+.Vb 6
+\&           struct A
+\&           {
+\&               A(int k) : i(k), j(k) { }
+\&               int i;
+\&               int j;
+\&           };
+\&        
+\&           A *ap;
+\&        
+\&           void foo(const A& ar)
+\&           {
+\&              ap = &ar;
+\&           }
+\&        
+\&           void bar()
+\&           {
+\&              foo(A(10)); // temp object\*(Aqs lifetime ends when foo returns
+\&        
+\&              {
+\&                A a(20);
+\&                ....
+\&              }
+\&              ap\->i+= 10;  // ap references out of scope temp whose space
+\&                           // is reused with a. What is the value of ap\->i?
+\&           }
+.Ve
+.Sp
+The lifetime of a compiler generated temporary is well defined by the \*(C+
+standard. When a lifetime of a temporary ends, and if the temporary lives
+in memory, the optimizing compiler has the freedom to reuse its stack
+space with other temporaries or scoped local variables whose live range
+does not overlap with it. However some of the legacy code relies on
+the behavior of older compilers in which temporaries' stack space is
+not reused, the aggressive stack reuse can lead to runtime errors. This
+option is used to control the temporary stack reuse optimization.
+.IP "\fB\-ftrapv\fR" 4
+.IX Item "-ftrapv"
+This option generates traps for signed overflow on addition, subtraction,
+multiplication operations.
+.IP "\fB\-fwrapv\fR" 4
+.IX Item "-fwrapv"
+This option instructs the compiler to assume that signed arithmetic
+overflow of addition, subtraction and multiplication wraps around
+using twos-complement representation.  This flag enables some optimizations
+and disables others.  This option is enabled by default for the Java
+front end, as required by the Java language specification.
+.IP "\fB\-fexceptions\fR" 4
+.IX Item "-fexceptions"
+Enable exception handling.  Generates extra code needed to propagate
+exceptions.  For some targets, this implies \s-1GCC\s0 generates frame
+unwind information for all functions, which can produce significant data
+size overhead, although it does not affect execution.  If you do not
+specify this option, \s-1GCC\s0 enables it by default for languages like
+\&\*(C+ that normally require exception handling, and disables it for
+languages like C that do not normally require it.  However, you may need
+to enable this option when compiling C code that needs to interoperate
+properly with exception handlers written in \*(C+.  You may also wish to
+disable this option if you are compiling older \*(C+ programs that don't
+use exception handling.
+.IP "\fB\-fnon\-call\-exceptions\fR" 4
+.IX Item "-fnon-call-exceptions"
+Generate code that allows trapping instructions to throw exceptions.
+Note that this requires platform-specific runtime support that does
+not exist everywhere.  Moreover, it only allows \fItrapping\fR
+instructions to throw exceptions, i.e. memory references or floating-point
+instructions.  It does not allow exceptions to be thrown from
+arbitrary signal handlers such as \f(CW\*(C`SIGALRM\*(C'\fR.
+.IP "\fB\-fdelete\-dead\-exceptions\fR" 4
+.IX Item "-fdelete-dead-exceptions"
+Consider that instructions that may throw exceptions but don't otherwise
+contribute to the execution of the program can be optimized away.
+This option is enabled by default for the Ada front end, as permitted by
+the Ada language specification.
+Optimization passes that cause dead exceptions to be removed are enabled independently at different optimization levels.
+.IP "\fB\-funwind\-tables\fR" 4
+.IX Item "-funwind-tables"
+Similar to \fB\-fexceptions\fR, except that it just generates any needed
+static data, but does not affect the generated code in any other way.
+You normally do not need to enable this option; instead, a language processor
+that needs this handling enables it on your behalf.
+.IP "\fB\-fasynchronous\-unwind\-tables\fR" 4
+.IX Item "-fasynchronous-unwind-tables"
+Generate unwind table in \s-1DWARF 2\s0 format, if supported by target machine.  The
+table is exact at each instruction boundary, so it can be used for stack
+unwinding from asynchronous events (such as debugger or garbage collector).
+.IP "\fB\-fno\-gnu\-unique\fR" 4
+.IX Item "-fno-gnu-unique"
+On systems with recent \s-1GNU\s0 assembler and C library, the \*(C+ compiler
+uses the \f(CW\*(C`STB_GNU_UNIQUE\*(C'\fR binding to make sure that definitions
+of template static data members and static local variables in inline
+functions are unique even in the presence of \f(CW\*(C`RTLD_LOCAL\*(C'\fR; this
+is necessary to avoid problems with a library used by two different
+\&\f(CW\*(C`RTLD_LOCAL\*(C'\fR plugins depending on a definition in one of them and
+therefore disagreeing with the other one about the binding of the
+symbol.  But this causes \f(CW\*(C`dlclose\*(C'\fR to be ignored for affected
+DSOs; if your program relies on reinitialization of a \s-1DSO\s0 via
+\&\f(CW\*(C`dlclose\*(C'\fR and \f(CW\*(C`dlopen\*(C'\fR, you can use
+\&\fB\-fno\-gnu\-unique\fR.
+.IP "\fB\-fpcc\-struct\-return\fR" 4
+.IX Item "-fpcc-struct-return"
+Return \*(L"short\*(R" \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in memory like
+longer ones, rather than in registers.  This convention is less
+efficient, but it has the advantage of allowing intercallability between
+GCC-compiled files and files compiled with other compilers, particularly
+the Portable C Compiler (pcc).
+.Sp
+The precise convention for returning structures in memory depends
+on the target configuration macros.
+.Sp
+Short structures and unions are those whose size and alignment match
+that of some integer type.
+.Sp
+\&\fBWarning:\fR code compiled with the \fB\-fpcc\-struct\-return\fR
+switch is not binary compatible with code compiled with the
+\&\fB\-freg\-struct\-return\fR switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-freg\-struct\-return\fR" 4
+.IX Item "-freg-struct-return"
+Return \f(CW\*(C`struct\*(C'\fR and \f(CW\*(C`union\*(C'\fR values in registers when possible.
+This is more efficient for small structures than
+\&\fB\-fpcc\-struct\-return\fR.
+.Sp
+If you specify neither \fB\-fpcc\-struct\-return\fR nor
+\&\fB\-freg\-struct\-return\fR, \s-1GCC\s0 defaults to whichever convention is
+standard for the target.  If there is no standard convention, \s-1GCC\s0
+defaults to \fB\-fpcc\-struct\-return\fR, except on targets where \s-1GCC\s0 is
+the principal compiler.  In those cases, we can choose the standard, and
+we chose the more efficient register return alternative.
+.Sp
+\&\fBWarning:\fR code compiled with the \fB\-freg\-struct\-return\fR
+switch is not binary compatible with code compiled with the
+\&\fB\-fpcc\-struct\-return\fR switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-fshort\-enums\fR" 4
+.IX Item "-fshort-enums"
+Allocate to an \f(CW\*(C`enum\*(C'\fR type only as many bytes as it needs for the
+declared range of possible values.  Specifically, the \f(CW\*(C`enum\*(C'\fR type
+is equivalent to the smallest integer type that has enough room.
+.Sp
+\&\fBWarning:\fR the \fB\-fshort\-enums\fR switch causes \s-1GCC\s0 to generate
+code that is not binary compatible with code generated without that switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-fshort\-double\fR" 4
+.IX Item "-fshort-double"
+Use the same size for \f(CW\*(C`double\*(C'\fR as for \f(CW\*(C`float\*(C'\fR.
+.Sp
+\&\fBWarning:\fR the \fB\-fshort\-double\fR switch causes \s-1GCC\s0 to generate
+code that is not binary compatible with code generated without that switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-fshort\-wchar\fR" 4
+.IX Item "-fshort-wchar"
+Override the underlying type for \fBwchar_t\fR to be \fBshort
+unsigned int\fR instead of the default for the target.  This option is
+useful for building programs to run under \s-1WINE.\s0
+.Sp
+\&\fBWarning:\fR the \fB\-fshort\-wchar\fR switch causes \s-1GCC\s0 to generate
+code that is not binary compatible with code generated without that switch.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-fno\-common\fR" 4
+.IX Item "-fno-common"
+In C code, controls the placement of uninitialized global variables.
+Unix C compilers have traditionally permitted multiple definitions of
+such variables in different compilation units by placing the variables
+in a common block.
+This is the behavior specified by \fB\-fcommon\fR, and is the default
+for \s-1GCC\s0 on most targets.
+On the other hand, this behavior is not required by \s-1ISO C,\s0 and on some
+targets may carry a speed or code size penalty on variable references.
+The \fB\-fno\-common\fR option specifies that the compiler should place
+uninitialized global variables in the data section of the object file,
+rather than generating them as common blocks.
+This has the effect that if the same variable is declared
+(without \f(CW\*(C`extern\*(C'\fR) in two different compilations,
+you get a multiple-definition error when you link them.
+In this case, you must compile with \fB\-fcommon\fR instead.
+Compiling with \fB\-fno\-common\fR is useful on targets for which
+it provides better performance, or if you wish to verify that the
+program will work on other systems that always treat uninitialized
+variable declarations this way.
+.IP "\fB\-fno\-ident\fR" 4
+.IX Item "-fno-ident"
+Ignore the \fB#ident\fR directive.
+.IP "\fB\-finhibit\-size\-directive\fR" 4
+.IX Item "-finhibit-size-directive"
+Don't output a \f(CW\*(C`.size\*(C'\fR assembler directive, or anything else that
+would cause trouble if the function is split in the middle, and the
+two halves are placed at locations far apart in memory.  This option is
+used when compiling \fIcrtstuff.c\fR; you should not need to use it
+for anything else.
+.IP "\fB\-fverbose\-asm\fR" 4
+.IX Item "-fverbose-asm"
+Put extra commentary information in the generated assembly code to
+make it more readable.  This option is generally only of use to those
+who actually need to read the generated assembly code (perhaps while
+debugging the compiler itself).
+.Sp
+\&\fB\-fno\-verbose\-asm\fR, the default, causes the
+extra information to be omitted and is useful when comparing two assembler
+files.
+.IP "\fB\-frecord\-gcc\-switches\fR" 4
+.IX Item "-frecord-gcc-switches"
+This switch causes the command line used to invoke the
+compiler to be recorded into the object file that is being created.
+This switch is only implemented on some targets and the exact format
+of the recording is target and binary file format dependent, but it
+usually takes the form of a section containing \s-1ASCII\s0 text.  This
+switch is related to the \fB\-fverbose\-asm\fR switch, but that
+switch only records information in the assembler output file as
+comments, so it never reaches the object file.
+See also \fB\-grecord\-gcc\-switches\fR for another
+way of storing compiler options into the object file.
+.IP "\fB\-fpic\fR" 4
+.IX Item "-fpic"
+Generate position-independent code (\s-1PIC\s0) suitable for use in a shared
+library, if supported for the target machine.  Such code accesses all
+constant addresses through a global offset table (\s-1GOT\s0).  The dynamic
+loader resolves the \s-1GOT\s0 entries when the program starts (the dynamic
+loader is not part of \s-1GCC\s0; it is part of the operating system).  If
+the \s-1GOT\s0 size for the linked executable exceeds a machine-specific
+maximum size, you get an error message from the linker indicating that
+\&\fB\-fpic\fR does not work; in that case, recompile with \fB\-fPIC\fR
+instead.  (These maximums are 8k on the \s-1SPARC\s0 and 32k
+on the m68k and \s-1RS/6000. \s0 The 386 has no such limit.)
+.Sp
+Position-independent code requires special support, and therefore works
+only on certain machines.  For the 386, \s-1GCC\s0 supports \s-1PIC\s0 for System V
+but not for the Sun 386i.  Code generated for the \s-1IBM RS/6000\s0 is always
+position-independent.
+.Sp
+When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
+are defined to 1.
+.IP "\fB\-fPIC\fR" 4
+.IX Item "-fPIC"
+If supported for the target machine, emit position-independent code,
+suitable for dynamic linking and avoiding any limit on the size of the
+global offset table.  This option makes a difference on the m68k,
+PowerPC and \s-1SPARC.\s0
+.Sp
+Position-independent code requires special support, and therefore works
+only on certain machines.
+.Sp
+When this flag is set, the macros \f(CW\*(C`_\|_pic_\|_\*(C'\fR and \f(CW\*(C`_\|_PIC_\|_\*(C'\fR
+are defined to 2.
+.IP "\fB\-fpie\fR" 4
+.IX Item "-fpie"
+.PD 0
+.IP "\fB\-fPIE\fR" 4
+.IX Item "-fPIE"
+.PD
+These options are similar to \fB\-fpic\fR and \fB\-fPIC\fR, but
+generated position independent code can be only linked into executables.
+Usually these options are used when \fB\-pie\fR \s-1GCC\s0 option is
+used during linking.
+.Sp
+\&\fB\-fpie\fR and \fB\-fPIE\fR both define the macros
+\&\f(CW\*(C`_\|_pie_\|_\*(C'\fR and \f(CW\*(C`_\|_PIE_\|_\*(C'\fR.  The macros have the value 1
+for \fB\-fpie\fR and 2 for \fB\-fPIE\fR.
+.IP "\fB\-fno\-jump\-tables\fR" 4
+.IX Item "-fno-jump-tables"
+Do not use jump tables for switch statements even where it would be
+more efficient than other code generation strategies.  This option is
+of use in conjunction with \fB\-fpic\fR or \fB\-fPIC\fR for
+building code that forms part of a dynamic linker and cannot
+reference the address of a jump table.  On some targets, jump tables
+do not require a \s-1GOT\s0 and this option is not needed.
+.IP "\fB\-ffixed\-\fR\fIreg\fR" 4
+.IX Item "-ffixed-reg"
+Treat the register named \fIreg\fR as a fixed register; generated code
+should never refer to it (except perhaps as a stack pointer, frame
+pointer or in some other fixed role).
+.Sp
+\&\fIreg\fR must be the name of a register.  The register names accepted
+are machine-specific and are defined in the \f(CW\*(C`REGISTER_NAMES\*(C'\fR
+macro in the machine description macro file.
+.Sp
+This flag does not have a negative form, because it specifies a
+three-way choice.
+.IP "\fB\-fcall\-used\-\fR\fIreg\fR" 4
+.IX Item "-fcall-used-reg"
+Treat the register named \fIreg\fR as an allocable register that is
+clobbered by function calls.  It may be allocated for temporaries or
+variables that do not live across a call.  Functions compiled this way
+do not save and restore the register \fIreg\fR.
+.Sp
+It is an error to use this flag with the frame pointer or stack pointer.
+Use of this flag for other registers that have fixed pervasive roles in
+the machine's execution model produces disastrous results.
+.Sp
+This flag does not have a negative form, because it specifies a
+three-way choice.
+.IP "\fB\-fcall\-saved\-\fR\fIreg\fR" 4
+.IX Item "-fcall-saved-reg"
+Treat the register named \fIreg\fR as an allocable register saved by
+functions.  It may be allocated even for temporaries or variables that
+live across a call.  Functions compiled this way save and restore
+the register \fIreg\fR if they use it.
+.Sp
+It is an error to use this flag with the frame pointer or stack pointer.
+Use of this flag for other registers that have fixed pervasive roles in
+the machine's execution model produces disastrous results.
+.Sp
+A different sort of disaster results from the use of this flag for
+a register in which function values may be returned.
+.Sp
+This flag does not have a negative form, because it specifies a
+three-way choice.
+.IP "\fB\-fpack\-struct[=\fR\fIn\fR\fB]\fR" 4
+.IX Item "-fpack-struct[=n]"
+Without a value specified, pack all structure members together without
+holes.  When a value is specified (which must be a small power of two), pack
+structure members according to this value, representing the maximum
+alignment (that is, objects with default alignment requirements larger than
+this are output potentially unaligned at the next fitting location.
+.Sp
+\&\fBWarning:\fR the \fB\-fpack\-struct\fR switch causes \s-1GCC\s0 to generate
+code that is not binary compatible with code generated without that switch.
+Additionally, it makes the code suboptimal.
+Use it to conform to a non-default application binary interface.
+.IP "\fB\-finstrument\-functions\fR" 4
+.IX Item "-finstrument-functions"
+Generate instrumentation calls for entry and exit to functions.  Just
+after function entry and just before function exit, the following
+profiling functions are called with the address of the current
+function and its call site.  (On some platforms,
+\&\f(CW\*(C`_\|_builtin_return_address\*(C'\fR does not work beyond the current
+function, so the call site information may not be available to the
+profiling functions otherwise.)
+.Sp
+.Vb 4
+\&        void _\|_cyg_profile_func_enter (void *this_fn,
+\&                                       void *call_site);
+\&        void _\|_cyg_profile_func_exit  (void *this_fn,
+\&                                       void *call_site);
+.Ve
+.Sp
+The first argument is the address of the start of the current function,
+which may be looked up exactly in the symbol table.
+.Sp
+This instrumentation is also done for functions expanded inline in other
+functions.  The profiling calls indicate where, conceptually, the
+inline function is entered and exited.  This means that addressable
+versions of such functions must be available.  If all your uses of a
+function are expanded inline, this may mean an additional expansion of
+code size.  If you use \fBextern inline\fR in your C code, an
+addressable version of such functions must be provided.  (This is
+normally the case anyway, but if you get lucky and the optimizer always
+expands the functions inline, you might have gotten away without
+providing static copies.)
+.Sp
+A function may be given the attribute \f(CW\*(C`no_instrument_function\*(C'\fR, in
+which case this instrumentation is not done.  This can be used, for
+example, for the profiling functions listed above, high-priority
+interrupt routines, and any functions from which the profiling functions
+cannot safely be called (perhaps signal handlers, if the profiling
+routines generate output or allocate memory).
+.IP "\fB\-finstrument\-functions\-exclude\-file\-list=\fR\fIfile\fR\fB,\fR\fIfile\fR\fB,...\fR" 4
+.IX Item "-finstrument-functions-exclude-file-list=file,file,..."
+Set the list of functions that are excluded from instrumentation (see
+the description of \f(CW\*(C`\-finstrument\-functions\*(C'\fR).  If the file that
+contains a function definition matches with one of \fIfile\fR, then
+that function is not instrumented.  The match is done on substrings:
+if the \fIfile\fR parameter is a substring of the file name, it is
+considered to be a match.
+.Sp
+For example:
+.Sp
+.Vb 1
+\&        \-finstrument\-functions\-exclude\-file\-list=/bits/stl,include/sys
+.Ve
+.Sp
+excludes any inline function defined in files whose pathnames
+contain \f(CW\*(C`/bits/stl\*(C'\fR or \f(CW\*(C`include/sys\*(C'\fR.
+.Sp
+If, for some reason, you want to include letter \f(CW\*(Aq,\*(Aq\fR in one of
+\&\fIsym\fR, write \f(CW\*(Aq,\*(Aq\fR. For example,
+\&\f(CW\*(C`\-finstrument\-functions\-exclude\-file\-list=\*(Aq,,tmp\*(Aq\*(C'\fR
+(note the single quote surrounding the option).
+.IP "\fB\-finstrument\-functions\-exclude\-function\-list=\fR\fIsym\fR\fB,\fR\fIsym\fR\fB,...\fR" 4
+.IX Item "-finstrument-functions-exclude-function-list=sym,sym,..."
+This is similar to \f(CW\*(C`\-finstrument\-functions\-exclude\-file\-list\*(C'\fR,
+but this option sets the list of function names to be excluded from
+instrumentation.  The function name to be matched is its user-visible
+name, such as \f(CW\*(C`vector<int> blah(const vector<int> &)\*(C'\fR, not the
+internal mangled name (e.g., \f(CW\*(C`_Z4blahRSt6vectorIiSaIiEE\*(C'\fR).  The
+match is done on substrings: if the \fIsym\fR parameter is a substring
+of the function name, it is considered to be a match.  For C99 and \*(C+
+extended identifiers, the function name must be given in \s-1UTF\-8,\s0 not
+using universal character names.
+.IP "\fB\-fstack\-check\fR" 4
+.IX Item "-fstack-check"
+Generate code to verify that you do not go beyond the boundary of the
+stack.  You should specify this flag if you are running in an
+environment with multiple threads, but you only rarely need to specify it in
+a single-threaded environment since stack overflow is automatically
+detected on nearly all systems if there is only one stack.
+.Sp
+Note that this switch does not actually cause checking to be done; the
+operating system or the language runtime must do that.  The switch causes
+generation of code to ensure that they see the stack being extended.
+.Sp
+You can additionally specify a string parameter: \f(CW\*(C`no\*(C'\fR means no
+checking, \f(CW\*(C`generic\*(C'\fR means force the use of old-style checking,
+\&\f(CW\*(C`specific\*(C'\fR means use the best checking method and is equivalent
+to bare \fB\-fstack\-check\fR.
+.Sp
+Old-style checking is a generic mechanism that requires no specific
+target support in the compiler but comes with the following drawbacks:
+.RS 4
+.IP "1." 4
+Modified allocation strategy for large objects: they are always
+allocated dynamically if their size exceeds a fixed threshold.
+.IP "2." 4
+Fixed limit on the size of the static frame of functions: when it is
+topped by a particular function, stack checking is not reliable and
+a warning is issued by the compiler.
+.IP "3." 4
+Inefficiency: because of both the modified allocation strategy and the
+generic implementation, code performance is hampered.
+.RE
+.RS 4
+.Sp
+Note that old-style stack checking is also the fallback method for
+\&\f(CW\*(C`specific\*(C'\fR if no target support has been added in the compiler.
+.RE
+.IP "\fB\-fstack\-limit\-register=\fR\fIreg\fR" 4
+.IX Item "-fstack-limit-register=reg"
+.PD 0
+.IP "\fB\-fstack\-limit\-symbol=\fR\fIsym\fR" 4
+.IX Item "-fstack-limit-symbol=sym"
+.IP "\fB\-fno\-stack\-limit\fR" 4
+.IX Item "-fno-stack-limit"
+.PD
+Generate code to ensure that the stack does not grow beyond a certain value,
+either the value of a register or the address of a symbol.  If a larger
+stack is required, a signal is raised at run time.  For most targets,
+the signal is raised before the stack overruns the boundary, so
+it is possible to catch the signal without taking special precautions.
+.Sp
+For instance, if the stack starts at absolute address \fB0x80000000\fR
+and grows downwards, you can use the flags
+\&\fB\-fstack\-limit\-symbol=_\|_stack_limit\fR and
+\&\fB\-Wl,\-\-defsym,_\|_stack_limit=0x7ffe0000\fR to enforce a stack limit
+of 128KB.  Note that this may only work with the \s-1GNU\s0 linker.
+.IP "\fB\-fsplit\-stack\fR" 4
+.IX Item "-fsplit-stack"
+Generate code to automatically split the stack before it overflows.
+The resulting program has a discontiguous stack which can only
+overflow if the program is unable to allocate any more memory.  This
+is most useful when running threaded programs, as it is no longer
+necessary to calculate a good stack size to use for each thread.  This
+is currently only implemented for the i386 and x86_64 back ends running
+GNU/Linux.
+.Sp
+When code compiled with \fB\-fsplit\-stack\fR calls code compiled
+without \fB\-fsplit\-stack\fR, there may not be much stack space
+available for the latter code to run.  If compiling all code,
+including library code, with \fB\-fsplit\-stack\fR is not an option,
+then the linker can fix up these calls so that the code compiled
+without \fB\-fsplit\-stack\fR always has a large stack.  Support for
+this is implemented in the gold linker in \s-1GNU\s0 binutils release 2.21
+and later.
+.IP "\fB\-fleading\-underscore\fR" 4
+.IX Item "-fleading-underscore"
+This option and its counterpart, \fB\-fno\-leading\-underscore\fR, forcibly
+change the way C symbols are represented in the object file.  One use
+is to help link with legacy assembly code.
+.Sp
+\&\fBWarning:\fR the \fB\-fleading\-underscore\fR switch causes \s-1GCC\s0 to
+generate code that is not binary compatible with code generated without that
+switch.  Use it to conform to a non-default application binary interface.
+Not all targets provide complete support for this switch.
+.IP "\fB\-ftls\-model=\fR\fImodel\fR" 4
+.IX Item "-ftls-model=model"
+Alter the thread-local storage model to be used.
+The \fImodel\fR argument should be one of \f(CW\*(C`global\-dynamic\*(C'\fR,
+\&\f(CW\*(C`local\-dynamic\*(C'\fR, \f(CW\*(C`initial\-exec\*(C'\fR or \f(CW\*(C`local\-exec\*(C'\fR.
+Note that the choice is subject to optimization: the compiler may use
+a more efficient model for symbols not visible outside of the translation
+unit, or if \fB\-fpic\fR is not given on the command line.
+.Sp
+The default without \fB\-fpic\fR is \f(CW\*(C`initial\-exec\*(C'\fR; with
+\&\fB\-fpic\fR the default is \f(CW\*(C`global\-dynamic\*(C'\fR.
+.IP "\fB\-fvisibility=\fR\fIdefault|internal|hidden|protected\fR" 4
+.IX Item "-fvisibility=default|internal|hidden|protected"
+Set the default \s-1ELF\s0 image symbol visibility to the specified option\-\-\-all
+symbols are marked with this unless overridden within the code.
+Using this feature can very substantially improve linking and
+load times of shared object libraries, produce more optimized
+code, provide near-perfect \s-1API\s0 export and prevent symbol clashes.
+It is \fBstrongly\fR recommended that you use this in any shared objects
+you distribute.
+.Sp
+Despite the nomenclature, \f(CW\*(C`default\*(C'\fR always means public; i.e.,
+available to be linked against from outside the shared object.
+\&\f(CW\*(C`protected\*(C'\fR and \f(CW\*(C`internal\*(C'\fR are pretty useless in real-world
+usage so the only other commonly used option is \f(CW\*(C`hidden\*(C'\fR.
+The default if \fB\-fvisibility\fR isn't specified is
+\&\f(CW\*(C`default\*(C'\fR, i.e., make every
+symbol public\-\-\-this causes the same behavior as previous versions of
+\&\s-1GCC.\s0
+.Sp
+A good explanation of the benefits offered by ensuring \s-1ELF\s0
+symbols have the correct visibility is given by \*(L"How To Write
+Shared Libraries\*(R" by Ulrich Drepper (which can be found at
+<\fBhttp://people.redhat.com/~drepper/\fR>)\-\-\-however a superior
+solution made possible by this option to marking things hidden when
+the default is public is to make the default hidden and mark things
+public.  This is the norm with DLLs on Windows and with \fB\-fvisibility=hidden\fR
+and \f(CW\*(C`_\|_attribute_\|_ ((visibility("default")))\*(C'\fR instead of
+\&\f(CW\*(C`_\|_declspec(dllexport)\*(C'\fR you get almost identical semantics with
+identical syntax.  This is a great boon to those working with
+cross-platform projects.
+.Sp
+For those adding visibility support to existing code, you may find
+\&\fB#pragma \s-1GCC\s0 visibility\fR of use.  This works by you enclosing
+the declarations you wish to set visibility for with (for example)
+\&\fB#pragma \s-1GCC\s0 visibility push(hidden)\fR and
+\&\fB#pragma \s-1GCC\s0 visibility pop\fR.
+Bear in mind that symbol visibility should be viewed \fBas
+part of the \s-1API\s0 interface contract\fR and thus all new code should
+always specify visibility when it is not the default; i.e., declarations
+only for use within the local \s-1DSO\s0 should \fBalways\fR be marked explicitly
+as hidden as so to avoid \s-1PLT\s0 indirection overheads\-\-\-making this
+abundantly clear also aids readability and self-documentation of the code.
+Note that due to \s-1ISO \*(C+\s0 specification requirements, \f(CW\*(C`operator new\*(C'\fR and
+\&\f(CW\*(C`operator delete\*(C'\fR must always be of default visibility.
+.Sp
+Be aware that headers from outside your project, in particular system
+headers and headers from any other library you use, may not be
+expecting to be compiled with visibility other than the default.  You
+may need to explicitly say \fB#pragma \s-1GCC\s0 visibility push(default)\fR
+before including any such headers.
+.Sp
+\&\fBextern\fR declarations are not affected by \fB\-fvisibility\fR, so
+a lot of code can be recompiled with \fB\-fvisibility=hidden\fR with
+no modifications.  However, this means that calls to \f(CW\*(C`extern\*(C'\fR
+functions with no explicit visibility use the \s-1PLT,\s0 so it is more
+effective to use \f(CW\*(C`_\|_attribute ((visibility))\*(C'\fR and/or
+\&\f(CW\*(C`#pragma GCC visibility\*(C'\fR to tell the compiler which \f(CW\*(C`extern\*(C'\fR
+declarations should be treated as hidden.
+.Sp
+Note that \fB\-fvisibility\fR does affect \*(C+ vague linkage
+entities. This means that, for instance, an exception class that is
+be thrown between DSOs must be explicitly marked with default
+visibility so that the \fBtype_info\fR nodes are unified between
+the DSOs.
+.Sp
+An overview of these techniques, their benefits and how to use them
+is at <\fBhttp://gcc.gnu.org/wiki/Visibility\fR>.
+.IP "\fB\-fstrict\-volatile\-bitfields\fR" 4
+.IX Item "-fstrict-volatile-bitfields"
+This option should be used if accesses to volatile bit-fields (or other
+structure fields, although the compiler usually honors those types
+anyway) should use a single access of the width of the
+field's type, aligned to a natural alignment if possible.  For
+example, targets with memory-mapped peripheral registers might require
+all such accesses to be 16 bits wide; with this flag you can
+declare all peripheral bit-fields as \f(CW\*(C`unsigned short\*(C'\fR (assuming short
+is 16 bits on these targets) to force \s-1GCC\s0 to use 16\-bit accesses
+instead of, perhaps, a more efficient 32\-bit access.
+.Sp
+If this option is disabled, the compiler uses the most efficient
+instruction.  In the previous example, that might be a 32\-bit load
+instruction, even though that accesses bytes that do not contain
+any portion of the bit-field, or memory-mapped registers unrelated to
+the one being updated.
+.Sp
+In some cases, such as when the \f(CW\*(C`packed\*(C'\fR attribute is applied to a 
+structure field, it may not be possible to access the field with a single
+read or write that is correctly aligned for the target machine.  In this
+case \s-1GCC\s0 falls back to generating multiple accesses rather than code that 
+will fault or truncate the result at run time.
+.Sp
+Note:  Due to restrictions of the C/\*(C+11 memory model, write accesses are
+not allowed to touch non bit-field members.  It is therefore recommended
+to define all bits of the field's type as bit-field members.
+.Sp
+The default value of this option is determined by the application binary
+interface for the target processor.
+.IP "\fB\-fsync\-libcalls\fR" 4
+.IX Item "-fsync-libcalls"
+This option controls whether any out-of-line instance of the \f(CW\*(C`_\|_sync\*(C'\fR
+family of functions may be used to implement the \*(C+11 \f(CW\*(C`_\|_atomic\*(C'\fR
+family of functions.
+.Sp
+The default value of this option is enabled, thus the only useful form
+of the option is \fB\-fno\-sync\-libcalls\fR.  This option is used in
+the implementation of the \fIlibatomic\fR runtime library.
+.SH "ENVIRONMENT"
+.IX Header "ENVIRONMENT"
+This section describes several environment variables that affect how \s-1GCC\s0
+operates.  Some of them work by specifying directories or prefixes to use
+when searching for various kinds of files.  Some are used to specify other
+aspects of the compilation environment.
+.PP
+Note that you can also specify places to search using options such as
+\&\fB\-B\fR, \fB\-I\fR and \fB\-L\fR.  These
+take precedence over places specified using environment variables, which
+in turn take precedence over those specified by the configuration of \s-1GCC.\s0
+.IP "\fB\s-1LANG\s0\fR" 4
+.IX Item "LANG"
+.PD 0
+.IP "\fB\s-1LC_CTYPE\s0\fR" 4
+.IX Item "LC_CTYPE"
+.IP "\fB\s-1LC_MESSAGES\s0\fR" 4
+.IX Item "LC_MESSAGES"
+.IP "\fB\s-1LC_ALL\s0\fR" 4
+.IX Item "LC_ALL"
+.PD
+These environment variables control the way that \s-1GCC\s0 uses
+localization information which allows \s-1GCC\s0 to work with different
+national conventions.  \s-1GCC\s0 inspects the locale categories
+\&\fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR if it has been configured to do
+so.  These locale categories can be set to any value supported by your
+installation.  A typical value is \fBen_GB.UTF\-8\fR for English in the United
+Kingdom encoded in \s-1UTF\-8.\s0
+.Sp
+The \fB\s-1LC_CTYPE\s0\fR environment variable specifies character
+classification.  \s-1GCC\s0 uses it to determine the character boundaries in
+a string; this is needed for some multibyte encodings that contain quote
+and escape characters that are otherwise interpreted as a string
+end or escape.
+.Sp
+The \fB\s-1LC_MESSAGES\s0\fR environment variable specifies the language to
+use in diagnostic messages.
+.Sp
+If the \fB\s-1LC_ALL\s0\fR environment variable is set, it overrides the value
+of \fB\s-1LC_CTYPE\s0\fR and \fB\s-1LC_MESSAGES\s0\fR; otherwise, \fB\s-1LC_CTYPE\s0\fR
+and \fB\s-1LC_MESSAGES\s0\fR default to the value of the \fB\s-1LANG\s0\fR
+environment variable.  If none of these variables are set, \s-1GCC\s0
+defaults to traditional C English behavior.
+.IP "\fB\s-1TMPDIR\s0\fR" 4
+.IX Item "TMPDIR"
+If \fB\s-1TMPDIR\s0\fR is set, it specifies the directory to use for temporary
+files.  \s-1GCC\s0 uses temporary files to hold the output of one stage of
+compilation which is to be used as input to the next stage: for example,
+the output of the preprocessor, which is the input to the compiler
+proper.
+.IP "\fB\s-1GCC_COMPARE_DEBUG\s0\fR" 4
+.IX Item "GCC_COMPARE_DEBUG"
+Setting \fB\s-1GCC_COMPARE_DEBUG\s0\fR is nearly equivalent to passing
+\&\fB\-fcompare\-debug\fR to the compiler driver.  See the documentation
+of this option for more details.
+.IP "\fB\s-1GCC_EXEC_PREFIX\s0\fR" 4
+.IX Item "GCC_EXEC_PREFIX"
+If \fB\s-1GCC_EXEC_PREFIX\s0\fR is set, it specifies a prefix to use in the
+names of the subprograms executed by the compiler.  No slash is added
+when this prefix is combined with the name of a subprogram, but you can
+specify a prefix that ends with a slash if you wish.
+.Sp
+If \fB\s-1GCC_EXEC_PREFIX\s0\fR is not set, \s-1GCC\s0 attempts to figure out
+an appropriate prefix to use based on the pathname it is invoked with.
+.Sp
+If \s-1GCC\s0 cannot find the subprogram using the specified prefix, it
+tries looking in the usual places for the subprogram.
+.Sp
+The default value of \fB\s-1GCC_EXEC_PREFIX\s0\fR is
+\&\fI\fIprefix\fI/lib/gcc/\fR where \fIprefix\fR is the prefix to
+the installed compiler. In many cases \fIprefix\fR is the value
+of \f(CW\*(C`prefix\*(C'\fR when you ran the \fIconfigure\fR script.
+.Sp
+Other prefixes specified with \fB\-B\fR take precedence over this prefix.
+.Sp
+This prefix is also used for finding files such as \fIcrt0.o\fR that are
+used for linking.
+.Sp
+In addition, the prefix is used in an unusual way in finding the
+directories to search for header files.  For each of the standard
+directories whose name normally begins with \fB/usr/local/lib/gcc\fR
+(more precisely, with the value of \fB\s-1GCC_INCLUDE_DIR\s0\fR), \s-1GCC\s0 tries
+replacing that beginning with the specified prefix to produce an
+alternate directory name.  Thus, with \fB\-Bfoo/\fR, \s-1GCC\s0 searches
+\&\fIfoo/bar\fR just before it searches the standard directory 
+\&\fI/usr/local/lib/bar\fR.
+If a standard directory begins with the configured
+\&\fIprefix\fR then the value of \fIprefix\fR is replaced by
+\&\fB\s-1GCC_EXEC_PREFIX\s0\fR when looking for header files.
+.IP "\fB\s-1COMPILER_PATH\s0\fR" 4
+.IX Item "COMPILER_PATH"
+The value of \fB\s-1COMPILER_PATH\s0\fR is a colon-separated list of
+directories, much like \fB\s-1PATH\s0\fR.  \s-1GCC\s0 tries the directories thus
+specified when searching for subprograms, if it can't find the
+subprograms using \fB\s-1GCC_EXEC_PREFIX\s0\fR.
+.IP "\fB\s-1LIBRARY_PATH\s0\fR" 4
+.IX Item "LIBRARY_PATH"
+The value of \fB\s-1LIBRARY_PATH\s0\fR is a colon-separated list of
+directories, much like \fB\s-1PATH\s0\fR.  When configured as a native compiler,
+\&\s-1GCC\s0 tries the directories thus specified when searching for special
+linker files, if it can't find them using \fB\s-1GCC_EXEC_PREFIX\s0\fR.  Linking
+using \s-1GCC\s0 also uses these directories when searching for ordinary
+libraries for the \fB\-l\fR option (but directories specified with
+\&\fB\-L\fR come first).
+.IP "\fB\s-1LANG\s0\fR" 4
+.IX Item "LANG"
+This variable is used to pass locale information to the compiler.  One way in
+which this information is used is to determine the character set to be used
+when character literals, string literals and comments are parsed in C and \*(C+.
+When the compiler is configured to allow multibyte characters,
+the following values for \fB\s-1LANG\s0\fR are recognized:
+.RS 4
+.IP "\fBC\-JIS\fR" 4
+.IX Item "C-JIS"
+Recognize \s-1JIS\s0 characters.
+.IP "\fBC\-SJIS\fR" 4
+.IX Item "C-SJIS"
+Recognize \s-1SJIS\s0 characters.
+.IP "\fBC\-EUCJP\fR" 4
+.IX Item "C-EUCJP"
+Recognize \s-1EUCJP\s0 characters.
+.RE
+.RS 4
+.Sp
+If \fB\s-1LANG\s0\fR is not defined, or if it has some other value, then the
+compiler uses \f(CW\*(C`mblen\*(C'\fR and \f(CW\*(C`mbtowc\*(C'\fR as defined by the default locale to
+recognize and translate multibyte characters.
+.RE
+.PP
+Some additional environment variables affect the behavior of the
+preprocessor.
+.IP "\fB\s-1CPATH\s0\fR" 4
+.IX Item "CPATH"
+.PD 0
+.IP "\fBC_INCLUDE_PATH\fR" 4
+.IX Item "C_INCLUDE_PATH"
+.IP "\fB\s-1CPLUS_INCLUDE_PATH\s0\fR" 4
+.IX Item "CPLUS_INCLUDE_PATH"
+.IP "\fB\s-1OBJC_INCLUDE_PATH\s0\fR" 4
+.IX Item "OBJC_INCLUDE_PATH"
+.PD
+Each variable's value is a list of directories separated by a special
+character, much like \fB\s-1PATH\s0\fR, in which to look for header files.
+The special character, \f(CW\*(C`PATH_SEPARATOR\*(C'\fR, is target-dependent and
+determined at \s-1GCC\s0 build time.  For Microsoft Windows-based targets it is a
+semicolon, and for almost all other targets it is a colon.
+.Sp
+\&\fB\s-1CPATH\s0\fR specifies a list of directories to be searched as if
+specified with \fB\-I\fR, but after any paths given with \fB\-I\fR
+options on the command line.  This environment variable is used
+regardless of which language is being preprocessed.
+.Sp
+The remaining environment variables apply only when preprocessing the
+particular language indicated.  Each specifies a list of directories
+to be searched as if specified with \fB\-isystem\fR, but after any
+paths given with \fB\-isystem\fR options on the command line.
+.Sp
+In all these variables, an empty element instructs the compiler to
+search its current working directory.  Empty elements can appear at the
+beginning or end of a path.  For instance, if the value of
+\&\fB\s-1CPATH\s0\fR is \f(CW\*(C`:/special/include\*(C'\fR, that has the same
+effect as \fB\-I.\ \-I/special/include\fR.
+.IP "\fB\s-1DEPENDENCIES_OUTPUT\s0\fR" 4
+.IX Item "DEPENDENCIES_OUTPUT"
+If this variable is set, its value specifies how to output
+dependencies for Make based on the non-system header files processed
+by the compiler.  System header files are ignored in the dependency
+output.
+.Sp
+The value of \fB\s-1DEPENDENCIES_OUTPUT\s0\fR can be just a file name, in
+which case the Make rules are written to that file, guessing the target
+name from the source file name.  Or the value can have the form
+\&\fIfile\fR\fB \fR\fItarget\fR, in which case the rules are written to
+file \fIfile\fR using \fItarget\fR as the target name.
+.Sp
+In other words, this environment variable is equivalent to combining
+the options \fB\-MM\fR and \fB\-MF\fR,
+with an optional \fB\-MT\fR switch too.
+.IP "\fB\s-1SUNPRO_DEPENDENCIES\s0\fR" 4
+.IX Item "SUNPRO_DEPENDENCIES"
+This variable is the same as \fB\s-1DEPENDENCIES_OUTPUT\s0\fR (see above),
+except that system header files are not ignored, so it implies
+\&\fB\-M\fR rather than \fB\-MM\fR.  However, the dependence on the
+main input file is omitted.
+.SH "BUGS"
+.IX Header "BUGS"
+For instructions on reporting bugs, see
+<\fBhttp://gcc.gnu.org/bugs.html\fR>.
+.SH "FOOTNOTES"
+.IX Header "FOOTNOTES"
+.IP "1." 4
+On some systems, \fBgcc \-shared\fR
+needs to build supplementary stub code for constructors to work.  On
+multi-libbed systems, \fBgcc \-shared\fR must select the correct support
+libraries to link against.  Failing to supply the correct flags may lead
+to subtle defects.  Supplying them in cases where they are not necessary
+is innocuous.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7),
+\&\fIcpp\fR\|(1), \fIgcov\fR\|(1), \fIas\fR\|(1), \fIld\fR\|(1), \fIgdb\fR\|(1), \fIadb\fR\|(1), \fIdbx\fR\|(1), \fIsdb\fR\|(1)
+and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIas\fR,
+\&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+See the Info entry for \fBgcc\fR, or
+<\fBhttp://gcc.gnu.org/onlinedocs/gcc/Contributors.html\fR>,
+for contributors to \s-1GCC.\s0
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 1988\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
+Free Software\*(R", 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 \fIgfdl\fR\|(7) man page.
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/gcc.info b/gcc-4.9/gcc/doc/gcc.info
new file mode 100644
index 000000000..29f054977
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gcc.info
@@ -0,0 +1,56908 @@
+This is gcc.info, produced by makeinfo version 5.1 from gcc.texi.
+
+Copyright (C) 1988-2014 Free Software Foundation, Inc.
+
+ 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 the
+Invariant Sections being "Funding Free Software", 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 "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.
+INFO-DIR-SECTION Software development
+START-INFO-DIR-ENTRY
+* gcc: (gcc).                  The GNU Compiler Collection.
+* g++: (gcc).                  The GNU C++ compiler.
+* gcov: (gcc) Gcov.            'gcov'--a test coverage program.
+END-INFO-DIR-ENTRY
+
+ This file documents the use of the GNU compilers.
+
+ Copyright (C) 1988-2014 Free Software Foundation, Inc.
+
+ 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 the
+Invariant Sections being "Funding Free Software", 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 "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.
+
+
+File: gcc.info,  Node: Top,  Next: G++ and GCC,  Up: (DIR)
+
+Introduction
+************
+
+This manual documents how to use the GNU compilers, as well as their
+features and incompatibilities, and how to report bugs.  It corresponds
+to the compilers (GCC) version 4.9.0.  The internals of the GNU
+compilers, including how to port them to new targets and some
+information about how to write front ends for new languages, are
+documented in a separate manual.  *Note Introduction: (gccint)Top.
+
+* Menu:
+
+* G++ and GCC::     You can compile C or C++ programs.
+* Standards::       Language standards supported by GCC.
+* Invoking GCC::    Command options supported by 'gcc'.
+* C Implementation:: How GCC implements the ISO C specification.
+* C++ Implementation:: How GCC implements the ISO C++ specification.
+* C Extensions::    GNU extensions to the C language family.
+* C++ Extensions::  GNU extensions to the C++ language.
+* Objective-C::     GNU Objective-C runtime features.
+* Compatibility::   Binary Compatibility
+* Gcov::            'gcov'--a test coverage program.
+* Trouble::         If you have trouble using GCC.
+* Bugs::            How, why and where to report bugs.
+* Service::         How To Get Help with GCC
+* Contributing::    How to contribute to testing and developing GCC.
+
+* Funding::         How to help assure funding for free software.
+* GNU Project::     The GNU Project and GNU/Linux.
+
+* Copying::         GNU General Public License says
+                    how you can copy and share GCC.
+* GNU Free Documentation License:: How you can copy and share this manual.
+* Contributors::    People who have contributed to GCC.
+
+* Option Index::    Index to command line options.
+* Keyword Index::   Index of concepts and symbol names.
+
+
+File: gcc.info,  Node: G++ and GCC,  Next: Standards,  Up: Top
+
+1 Programming Languages Supported by GCC
+****************************************
+
+GCC stands for "GNU Compiler Collection".  GCC is an integrated
+distribution of compilers for several major programming languages.
+These languages currently include C, C++, Objective-C, Objective-C++,
+Java, Fortran, Ada, and Go.
+
+ The abbreviation "GCC" has multiple meanings in common use.  The
+current official meaning is "GNU Compiler Collection", which refers
+generically to the complete suite of tools.  The name historically stood
+for "GNU C Compiler", and this usage is still common when the emphasis
+is on compiling C programs.  Finally, the name is also used when
+speaking of the "language-independent" component of GCC: code shared
+among the compilers for all supported languages.
+
+ The language-independent component of GCC includes the majority of the
+optimizers, as well as the "back ends" that generate machine code for
+various processors.
+
+ The part of a compiler that is specific to a particular language is
+called the "front end".  In addition to the front ends that are
+integrated components of GCC, there are several other front ends that
+are maintained separately.  These support languages such as Pascal,
+Mercury, and COBOL.  To use these, they must be built together with GCC
+proper.
+
+ Most of the compilers for languages other than C have their own names.
+The C++ compiler is G++, the Ada compiler is GNAT, and so on.  When we
+talk about compiling one of those languages, we might refer to that
+compiler by its own name, or as GCC.  Either is correct.
+
+ Historically, compilers for many languages, including C++ and Fortran,
+have been implemented as "preprocessors" which emit another high level
+language such as C.  None of the compilers included in GCC are
+implemented this way; they all generate machine code directly.  This
+sort of preprocessor should not be confused with the "C preprocessor",
+which is an integral feature of the C, C++, Objective-C and
+Objective-C++ languages.
+
+
+File: gcc.info,  Node: Standards,  Next: Invoking GCC,  Prev: G++ and GCC,  Up: Top
+
+2 Language Standards Supported by GCC
+*************************************
+
+For each language compiled by GCC for which there is a standard, GCC
+attempts to follow one or more versions of that standard, possibly with
+some exceptions, and possibly with some extensions.
+
+2.1 C language
+==============
+
+GCC supports three versions of the C standard, although support for the
+most recent version is not yet complete.
+
+ The original ANSI C standard (X3.159-1989) was ratified in 1989 and
+published in 1990.  This standard was ratified as an ISO standard
+(ISO/IEC 9899:1990) later in 1990.  There were no technical differences
+between these publications, although the sections of the ANSI standard
+were renumbered and became clauses in the ISO standard.  This standard,
+in both its forms, is commonly known as "C89", or occasionally as "C90",
+from the dates of ratification.  The ANSI standard, but not the ISO
+standard, also came with a Rationale document.  To select this standard
+in GCC, use one of the options '-ansi', '-std=c90' or
+'-std=iso9899:1990'; to obtain all the diagnostics required by the
+standard, you should also specify '-pedantic' (or '-pedantic-errors' if
+you want them to be errors rather than warnings).  *Note Options
+Controlling C Dialect: C Dialect Options.
+
+ Errors in the 1990 ISO C standard were corrected in two Technical
+Corrigenda published in 1994 and 1996.  GCC does not support the
+uncorrected version.
+
+ An amendment to the 1990 standard was published in 1995.  This
+amendment added digraphs and '__STDC_VERSION__' to the language, but
+otherwise concerned the library.  This amendment is commonly known as
+"AMD1"; the amended standard is sometimes known as "C94" or "C95".  To
+select this standard in GCC, use the option '-std=iso9899:199409' (with,
+as for other standard versions, '-pedantic' to receive all required
+diagnostics).
+
+ A new edition of the ISO C standard was published in 1999 as ISO/IEC
+9899:1999, and is commonly known as "C99".  GCC has substantially
+complete support for this standard version; see
+<http://gcc.gnu.org/c99status.html> for details.  To select this
+standard, use '-std=c99' or '-std=iso9899:1999'.  (While in development,
+drafts of this standard version were referred to as "C9X".)
+
+ Errors in the 1999 ISO C standard were corrected in three Technical
+Corrigenda published in 2001, 2004 and 2007.  GCC does not support the
+uncorrected version.
+
+ A fourth version of the C standard, known as "C11", was published in
+2011 as ISO/IEC 9899:2011.  GCC has substantially complete support for
+this standard, enabled with '-std=c11' or '-std=iso9899:2011'.  (While
+in development, drafts of this standard version were referred to as
+"C1X".)
+
+ By default, GCC provides some extensions to the C language that on rare
+occasions conflict with the C standard.  *Note Extensions to the C
+Language Family: C Extensions.  Use of the '-std' options listed above
+will disable these extensions where they conflict with the C standard
+version selected.  You may also select an extended version of the C
+language explicitly with '-std=gnu90' (for C90 with GNU extensions),
+'-std=gnu99' (for C99 with GNU extensions) or '-std=gnu11' (for C11 with
+GNU extensions).  The default, if no C language dialect options are
+given, is '-std=gnu90'; this is intended to change to '-std=gnu11' in
+some future release.  Some features that are part of the C99 standard
+are accepted as extensions in C90 mode, and some features that are part
+of the C11 standard are accepted as extensions in C90 and C99 modes.
+
+ The ISO C standard defines (in clause 4) two classes of conforming
+implementation.  A "conforming hosted implementation" supports the whole
+standard including all the library facilities; a "conforming
+freestanding implementation" is only required to provide certain library
+facilities: those in '<float.h>', '<limits.h>', '<stdarg.h>', and
+'<stddef.h>'; since AMD1, also those in '<iso646.h>'; since C99, also
+those in '<stdbool.h>' and '<stdint.h>'; and since C11, also those in
+'<stdalign.h>' and '<stdnoreturn.h>'.  In addition, complex types, added
+in C99, are not required for freestanding implementations.  The standard
+also defines two environments for programs, a "freestanding
+environment", required of all implementations and which may not have
+library facilities beyond those required of freestanding
+implementations, where the handling of program startup and termination
+are implementation-defined, and a "hosted environment", which is not
+required, in which all the library facilities are provided and startup
+is through a function 'int main (void)' or 'int main (int, char *[])'.
+An OS kernel would be a freestanding environment; a program using the
+facilities of an operating system would normally be in a hosted
+implementation.
+
+ GCC aims towards being usable as a conforming freestanding
+implementation, or as the compiler for a conforming hosted
+implementation.  By default, it will act as the compiler for a hosted
+implementation, defining '__STDC_HOSTED__' as '1' and presuming that
+when the names of ISO C functions are used, they have the semantics
+defined in the standard.  To make it act as a conforming freestanding
+implementation for a freestanding environment, use the option
+'-ffreestanding'; it will then define '__STDC_HOSTED__' to '0' and not
+make assumptions about the meanings of function names from the standard
+library, with exceptions noted below.  To build an OS kernel, you may
+well still need to make your own arrangements for linking and startup.
+*Note Options Controlling C Dialect: C Dialect Options.
+
+ GCC does not provide the library facilities required only of hosted
+implementations, nor yet all the facilities required by C99 of
+freestanding implementations on all platforms; to use the facilities of
+a hosted environment, you will need to find them elsewhere (for example,
+in the GNU C library).  *Note Standard Libraries: Standard Libraries.
+
+ Most of the compiler support routines used by GCC are present in
+'libgcc', but there are a few exceptions.  GCC requires the freestanding
+environment provide 'memcpy', 'memmove', 'memset' and 'memcmp'.
+Finally, if '__builtin_trap' is used, and the target does not implement
+the 'trap' pattern, then GCC will emit a call to 'abort'.
+
+ For references to Technical Corrigenda, Rationale documents and
+information concerning the history of C that is available online, see
+<http://gcc.gnu.org/readings.html>
+
+2.2 C++ language
+================
+
+GCC supports the original ISO C++ standard (1998) and contains
+experimental support for the second ISO C++ standard (2011).
+
+ The original ISO C++ standard was published as the ISO standard
+(ISO/IEC 14882:1998) and amended by a Technical Corrigenda published in
+2003 (ISO/IEC 14882:2003).  These standards are referred to as C++98 and
+C++03, respectively.  GCC implements the majority of C++98 ('export' is
+a notable exception) and most of the changes in C++03.  To select this
+standard in GCC, use one of the options '-ansi', '-std=c++98', or
+'-std=c++03'; to obtain all the diagnostics required by the standard,
+you should also specify '-pedantic' (or '-pedantic-errors' if you want
+them to be errors rather than warnings).
+
+ A revised ISO C++ standard was published in 2011 as ISO/IEC 14882:2011,
+and is referred to as C++11; before its publication it was commonly
+referred to as C++0x.  C++11 contains several changes to the C++
+language, most of which have been implemented in an experimental C++11
+mode in GCC.  For information regarding the C++11 features available in
+the experimental C++11 mode, see
+<http://gcc.gnu.org/projects/cxx0x.html>.  To select this standard in
+GCC, use the option '-std=c++11'; to obtain all the diagnostics required
+by the standard, you should also specify '-pedantic' (or
+'-pedantic-errors' if you want them to be errors rather than warnings).
+
+ More information about the C++ standards is available on the ISO C++
+committee's web site at <http://www.open-std.org/jtc1/sc22/wg21/>.
+
+ By default, GCC provides some extensions to the C++ language; *Note
+Options Controlling C++ Dialect: C++ Dialect Options.  Use of the '-std'
+option listed above will disable these extensions.  You may also select
+an extended version of the C++ language explicitly with '-std=gnu++98'
+(for C++98 with GNU extensions) or '-std=gnu++11' (for C++11 with GNU
+extensions).  The default, if no C++ language dialect options are given,
+is '-std=gnu++98'.
+
+2.3 Objective-C and Objective-C++ languages
+===========================================
+
+GCC supports "traditional" Objective-C (also known as "Objective-C 1.0")
+and contains support for the Objective-C exception and synchronization
+syntax.  It has also support for a number of "Objective-C 2.0" language
+extensions, including properties, fast enumeration (only for
+Objective-C), method attributes and the @optional and @required keywords
+in protocols.  GCC supports Objective-C++ and features available in
+Objective-C are also available in Objective-C++.
+
+ GCC by default uses the GNU Objective-C runtime library, which is part
+of GCC and is not the same as the Apple/NeXT Objective-C runtime library
+used on Apple systems.  There are a number of differences documented in
+this manual.  The options '-fgnu-runtime' and '-fnext-runtime' allow you
+to switch between producing output that works with the GNU Objective-C
+runtime library and output that works with the Apple/NeXT Objective-C
+runtime library.
+
+ There is no formal written standard for Objective-C or Objective-C++.
+The authoritative manual on traditional Objective-C (1.0) is
+"Object-Oriented Programming and the Objective-C Language", available at
+a number of web sites:
+   * <http://www.gnustep.org/resources/documentation/ObjectivCBook.pdf>
+     is the original NeXTstep document;
+   * <http://objc.toodarkpark.net> is the same document in another
+     format;
+   * 
+     <http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/>
+     has an updated version but make sure you search for "Object
+     Oriented Programming and the Objective-C Programming Language 1.0",
+     not documentation on the newer "Objective-C 2.0" language
+
+ The Objective-C exception and synchronization syntax (that is, the
+keywords @try, @throw, @catch, @finally and @synchronized) is supported
+by GCC and is enabled with the option '-fobjc-exceptions'.  The syntax
+is briefly documented in this manual and in the Objective-C 2.0 manuals
+from Apple.
+
+ The Objective-C 2.0 language extensions and features are automatically
+enabled; they include properties (via the @property, @synthesize and
+@dynamic keywords), fast enumeration (not available in Objective-C++),
+attributes for methods (such as deprecated, noreturn, sentinel, format),
+the unused attribute for method arguments, the @package keyword for
+instance variables and the @optional and @required keywords in
+protocols.  You can disable all these Objective-C 2.0 language
+extensions with the option '-fobjc-std=objc1', which causes the compiler
+to recognize the same Objective-C language syntax recognized by GCC 4.0,
+and to produce an error if one of the new features is used.
+
+ GCC has currently no support for non-fragile instance variables.
+
+ The authoritative manual on Objective-C 2.0 is available from Apple:
+   * 
+     <http://developer.apple.com/mac/library/documentation/Cocoa/Conceptual/ObjectiveC/>
+
+ For more information concerning the history of Objective-C that is
+available online, see <http://gcc.gnu.org/readings.html>
+
+2.4 Go language
+===============
+
+As of the GCC 4.7.1 release, GCC supports the Go 1 language standard,
+described at <http://golang.org/doc/go1.html>.
+
+2.5 References for other languages
+==================================
+
+*Note GNAT Reference Manual: (gnat_rm)Top, for information on standard
+conformance and compatibility of the Ada compiler.
+
+ *Note Standards: (gfortran)Standards, for details of standards
+supported by GNU Fortran.
+
+ *Note Compatibility with the Java Platform: (gcj)Compatibility, for
+details of compatibility between 'gcj' and the Java Platform.
+
+
+File: gcc.info,  Node: Invoking GCC,  Next: C Implementation,  Prev: Standards,  Up: Top
+
+3 GCC Command Options
+*********************
+
+When you invoke GCC, it normally does preprocessing, compilation,
+assembly and linking.  The "overall options" allow you to stop this
+process at an intermediate stage.  For example, the '-c' option says not
+to run the linker.  Then the output consists of object files output by
+the assembler.
+
+ Other options are passed on to one stage of processing.  Some options
+control the preprocessor and others the compiler itself.  Yet other
+options control the assembler and linker; most of these are not
+documented here, since you rarely need to use any of them.
+
+ Most of the command-line options that you can use with GCC are useful
+for C programs; when an option is only useful with another language
+(usually C++), the explanation says so explicitly.  If the description
+for a particular option does not mention a source language, you can use
+that option with all supported languages.
+
+ *Note Compiling C++ Programs: Invoking G++, for a summary of special
+options for compiling C++ programs.
+
+ The 'gcc' program accepts options and file names as operands.  Many
+options have multi-letter names; therefore multiple single-letter
+options may _not_ be grouped: '-dv' is very different from '-d -v'.
+
+ You can mix options and other arguments.  For the most part, the order
+you use doesn't matter.  Order does matter when you use several options
+of the same kind; for example, if you specify '-L' more than once, the
+directories are searched in the order specified.  Also, the placement of
+the '-l' option is significant.
+
+ Many options have long names starting with '-f' or with '-W'--for
+example, '-fmove-loop-invariants', '-Wformat' and so on.  Most of these
+have both positive and negative forms; the negative form of '-ffoo' is
+'-fno-foo'.  This manual documents only one of these two forms,
+whichever one is not the default.
+
+ *Note Option Index::, for an index to GCC's options.
+
+* Menu:
+
+* Option Summary::      Brief list of all options, without explanations.
+* Overall Options::     Controlling the kind of output:
+                        an executable, object files, assembler files,
+                        or preprocessed source.
+* Invoking G++::        Compiling C++ programs.
+* C Dialect Options::   Controlling the variant of C language compiled.
+* C++ Dialect Options:: Variations on C++.
+* Objective-C and Objective-C++ Dialect Options:: Variations on Objective-C
+                        and Objective-C++.
+* Language Independent Options:: Controlling how diagnostics should be
+                        formatted.
+* Warning Options::     How picky should the compiler be?
+* Debugging Options::   Symbol tables, measurements, and debugging dumps.
+* Optimize Options::    How much optimization?
+* Preprocessor Options:: Controlling header files and macro definitions.
+                         Also, getting dependency information for Make.
+* Assembler Options::   Passing options to the assembler.
+* Link Options::        Specifying libraries and so on.
+* Directory Options::   Where to find header files and libraries.
+                        Where to find the compiler executable files.
+* Spec Files::          How to pass switches to sub-processes.
+* Target Options::      Running a cross-compiler, or an old version of GCC.
+* Submodel Options::    Specifying minor hardware or convention variations,
+                        such as 68010 vs 68020.
+* Code Gen Options::    Specifying conventions for function calls, data layout
+                        and register usage.
+* Environment Variables:: Env vars that affect GCC.
+* Precompiled Headers:: Compiling a header once, and using it many times.
+
+
+File: gcc.info,  Node: Option Summary,  Next: Overall Options,  Up: Invoking GCC
+
+3.1 Option Summary
+==================
+
+Here is a summary of all the options, grouped by type.  Explanations are
+in the following sections.
+
+_Overall Options_
+     *Note Options Controlling the Kind of Output: Overall Options.
+          -c  -S  -E  -o FILE  -no-canonical-prefixes
+          -pipe  -pass-exit-codes
+          -x LANGUAGE  -v  -###  --help[=CLASS[,...]]  --target-help
+          --version -wrapper @FILE -fplugin=FILE -fplugin-arg-NAME=ARG
+          -fdump-ada-spec[-slim] -fada-spec-parent=UNIT -fdump-go-spec=FILE
+
+_C Language Options_
+     *Note Options Controlling C Dialect: C Dialect Options.
+          -ansi  -std=STANDARD  -fgnu89-inline
+          -aux-info FILENAME -fallow-parameterless-variadic-functions
+          -fno-asm  -fno-builtin  -fno-builtin-FUNCTION
+          -fhosted  -ffreestanding -fopenmp -fopenmp-simd -fms-extensions
+          -fplan9-extensions -trigraphs  -traditional  -traditional-cpp
+          -fallow-single-precision  -fcond-mismatch -flax-vector-conversions
+          -fsigned-bitfields  -fsigned-char
+          -funsigned-bitfields  -funsigned-char
+
+_C++ Language Options_
+     *Note Options Controlling C++ Dialect: C++ Dialect Options.
+          -fabi-version=N  -fno-access-control  -fcheck-new
+          -fconstexpr-depth=N  -ffriend-injection
+          -fno-elide-constructors
+          -fno-enforce-eh-specs
+          -ffor-scope  -fno-for-scope  -fno-gnu-keywords
+          -fno-implicit-templates
+          -fno-implicit-inline-templates
+          -fno-implement-inlines  -fms-extensions
+          -fno-nonansi-builtins  -fnothrow-opt  -fno-operator-names
+          -fno-optional-diags  -fpermissive
+          -fno-pretty-templates
+          -frepo  -fno-rtti  -fstats  -ftemplate-backtrace-limit=N
+          -ftemplate-depth=N
+          -fno-threadsafe-statics -fuse-cxa-atexit  -fno-weak  -nostdinc++
+          -fvisibility-inlines-hidden
+          -fvtable-verify=STD|PREINIT|NONE
+          -fvtv-counts -fvtv-debug
+          -fvisibility-ms-compat
+          -fext-numeric-literals
+          -Wabi  -Wconversion-null  -Wctor-dtor-privacy
+          -Wdelete-non-virtual-dtor -Wliteral-suffix -Wnarrowing
+          -Wnoexcept -Wnon-virtual-dtor  -Wreorder
+          -Weffc++  -Wstrict-null-sentinel
+          -Wno-non-template-friend  -Wold-style-cast
+          -Woverloaded-virtual  -Wno-pmf-conversions
+          -Wsign-promo
+
+_Objective-C and Objective-C++ Language Options_
+     *Note Options Controlling Objective-C and Objective-C++ Dialects:
+     Objective-C and Objective-C++ Dialect Options.
+          -fconstant-string-class=CLASS-NAME
+          -fgnu-runtime  -fnext-runtime
+          -fno-nil-receivers
+          -fobjc-abi-version=N
+          -fobjc-call-cxx-cdtors
+          -fobjc-direct-dispatch
+          -fobjc-exceptions
+          -fobjc-gc
+          -fobjc-nilcheck
+          -fobjc-std=objc1
+          -freplace-objc-classes
+          -fzero-link
+          -gen-decls
+          -Wassign-intercept
+          -Wno-protocol  -Wselector
+          -Wstrict-selector-match
+          -Wundeclared-selector
+
+_Language Independent Options_
+     *Note Options to Control Diagnostic Messages Formatting: Language
+     Independent Options.
+          -fmessage-length=N
+          -fdiagnostics-show-location=[once|every-line]
+          -fdiagnostics-color=[auto|never|always]
+          -fno-diagnostics-show-option -fno-diagnostics-show-caret
+
+_Warning Options_
+     *Note Options to Request or Suppress Warnings: Warning Options.
+          -fsyntax-only  -fmax-errors=N  -Wpedantic
+          -pedantic-errors
+          -w  -Wextra  -Wall  -Waddress  -Waggregate-return
+          -Waggressive-loop-optimizations -Warray-bounds
+          -Wno-attributes -Wno-builtin-macro-redefined
+          -Wc++-compat -Wc++11-compat -Wcast-align  -Wcast-qual
+          -Wchar-subscripts -Wclobbered  -Wcomment -Wconditionally-supported
+          -Wconversion -Wcoverage-mismatch -Wdate-time -Wdelete-incomplete -Wno-cpp
+          -Wno-deprecated -Wno-deprecated-declarations -Wdisabled-optimization
+          -Wno-div-by-zero -Wdouble-promotion -Wempty-body  -Wenum-compare
+          -Wno-endif-labels -Werror  -Werror=*
+          -Wfatal-errors  -Wfloat-equal  -Wformat  -Wformat=2
+          -Wno-format-contains-nul -Wno-format-extra-args -Wformat-nonliteral
+          -Wformat-security  -Wformat-y2k
+          -Wframe-larger-than=LEN -Wno-free-nonheap-object -Wjump-misses-init
+          -Wignored-qualifiers
+          -Wimplicit  -Wimplicit-function-declaration  -Wimplicit-int
+          -Winit-self  -Winline -Wmaybe-uninitialized
+          -Wno-int-to-pointer-cast -Wno-invalid-offsetof
+          -Winvalid-pch -Wlarger-than=LEN  -Wunsafe-loop-optimizations
+          -Wlogical-op -Wlong-long
+          -Wmain -Wmaybe-uninitialized -Wmissing-braces  -Wmissing-field-initializers
+          -Wmissing-include-dirs
+          -Wno-multichar  -Wnonnull  -Wno-overflow -Wopenmp-simd
+          -Woverlength-strings  -Wpacked  -Wpacked-bitfield-compat  -Wpadded
+          -Wparentheses  -Wpedantic-ms-format -Wno-pedantic-ms-format
+          -Wpointer-arith  -Wno-pointer-to-int-cast
+          -Wredundant-decls  -Wno-return-local-addr
+          -Wreturn-type  -Wsequence-point  -Wshadow
+          -Wsign-compare  -Wsign-conversion -Wfloat-conversion
+          -Wsizeof-pointer-memaccess
+          -Wstack-protector -Wstack-usage=LEN -Wstrict-aliasing
+          -Wstrict-aliasing=n  -Wstrict-overflow -Wstrict-overflow=N
+          -Wsuggest-attribute=[pure|const|noreturn|format]
+          -Wmissing-format-attribute
+          -Wswitch  -Wswitch-default  -Wswitch-enum -Wsync-nand
+          -Wsystem-headers  -Wtrampolines  -Wtrigraphs  -Wtype-limits  -Wundef
+          -Wuninitialized  -Wunknown-pragmas  -Wno-pragmas
+          -Wunsuffixed-float-constants  -Wunused  -Wunused-function
+          -Wunused-label  -Wunused-local-typedefs -Wunused-parameter
+          -Wno-unused-result -Wunused-value  -Wunused-variable
+          -Wunused-but-set-parameter -Wunused-but-set-variable
+          -Wuseless-cast -Wvariadic-macros -Wvector-operation-performance
+          -Wvla -Wvolatile-register-var  -Wwrite-strings -Wzero-as-null-pointer-constant
+
+_C and Objective-C-only Warning Options_
+          -Wbad-function-cast  -Wmissing-declarations
+          -Wmissing-parameter-type  -Wmissing-prototypes  -Wnested-externs
+          -Wold-style-declaration  -Wold-style-definition
+          -Wstrict-prototypes  -Wtraditional  -Wtraditional-conversion
+          -Wdeclaration-after-statement -Wpointer-sign
+
+_Debugging Options_
+     *Note Options for Debugging Your Program or GCC: Debugging Options.
+          -dLETTERS  -dumpspecs  -dumpmachine  -dumpversion
+          -fsanitize=STYLE
+          -fdbg-cnt-list -fdbg-cnt=COUNTER-VALUE-LIST
+          -fdisable-ipa-PASS_NAME
+          -fdisable-rtl-PASS_NAME
+          -fdisable-rtl-PASS-NAME=RANGE-LIST
+          -fdisable-tree-PASS_NAME
+          -fdisable-tree-PASS-NAME=RANGE-LIST
+          -fdump-noaddr -fdump-unnumbered -fdump-unnumbered-links
+          -fdump-translation-unit[-N]
+          -fdump-class-hierarchy[-N]
+          -fdump-ipa-all -fdump-ipa-cgraph -fdump-ipa-inline
+          -fdump-passes
+          -fdump-statistics
+          -fdump-tree-all
+          -fdump-tree-original[-N]
+          -fdump-tree-optimized[-N]
+          -fdump-tree-cfg -fdump-tree-alias
+          -fdump-tree-ch
+          -fdump-tree-ssa[-N] -fdump-tree-pre[-N]
+          -fdump-tree-ccp[-N] -fdump-tree-dce[-N]
+          -fdump-tree-gimple[-raw]
+          -fdump-tree-dom[-N]
+          -fdump-tree-dse[-N]
+          -fdump-tree-phiprop[-N]
+          -fdump-tree-phiopt[-N]
+          -fdump-tree-forwprop[-N]
+          -fdump-tree-copyrename[-N]
+          -fdump-tree-nrv -fdump-tree-vect
+          -fdump-tree-sink
+          -fdump-tree-sra[-N]
+          -fdump-tree-forwprop[-N]
+          -fdump-tree-fre[-N]
+          -fdump-tree-vtable-verify
+          -fdump-tree-vrp[-N]
+          -fdump-tree-storeccp[-N]
+          -fdump-final-insns=FILE
+          -fcompare-debug[=OPTS]  -fcompare-debug-second
+          -feliminate-dwarf2-dups -fno-eliminate-unused-debug-types
+          -feliminate-unused-debug-symbols -femit-class-debug-always
+          -fenable-KIND-PASS
+          -fenable-KIND-PASS=RANGE-LIST
+          -fdebug-types-section -fmem-report-wpa
+          -fmem-report -fpre-ipa-mem-report -fpost-ipa-mem-report -fprofile-arcs
+          -fopt-info
+          -fopt-info-OPTIONS[=FILE]
+          -frandom-seed=STRING -fsched-verbose=N
+          -fsel-sched-verbose -fsel-sched-dump-cfg -fsel-sched-pipelining-verbose
+          -fstack-usage  -ftest-coverage  -ftime-report -fvar-tracking
+          -fvar-tracking-assignments  -fvar-tracking-assignments-toggle
+          -g  -gLEVEL  -gtoggle  -gcoff  -gdwarf-VERSION
+          -ggdb  -grecord-gcc-switches  -gno-record-gcc-switches
+          -gstabs  -gstabs+  -gstrict-dwarf  -gno-strict-dwarf
+          -gvms  -gxcoff  -gxcoff+
+          -fno-merge-debug-strings -fno-dwarf2-cfi-asm
+          -fdebug-prefix-map=OLD=NEW
+          -femit-struct-debug-baseonly -femit-struct-debug-reduced
+          -femit-struct-debug-detailed[=SPEC-LIST]
+          -p  -pg  -print-file-name=LIBRARY  -print-libgcc-file-name
+          -print-multi-directory  -print-multi-lib  -print-multi-os-directory
+          -print-prog-name=PROGRAM  -print-search-dirs  -Q
+          -print-sysroot -print-sysroot-headers-suffix
+          -save-temps -save-temps=cwd -save-temps=obj -time[=FILE]
+
+_Optimization Options_
+     *Note Options that Control Optimization: Optimize Options.
+          -faggressive-loop-optimizations -falign-functions[=N]
+          -falign-jumps[=N]
+          -falign-labels[=N] -falign-loops[=N]
+          -fassociative-math -fauto-inc-dec -fbranch-probabilities
+          -fbranch-target-load-optimize -fbranch-target-load-optimize2
+          -fbtr-bb-exclusive -fcaller-saves
+          -fcheck-data-deps -fcombine-stack-adjustments -fconserve-stack
+          -fcompare-elim -fcprop-registers -fcrossjumping
+          -fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules
+          -fcx-limited-range
+          -fdata-sections -fdce -fdelayed-branch
+          -fdelete-null-pointer-checks -fdevirtualize -fdevirtualize-speculatively -fdse
+          -fearly-inlining -fipa-sra -fexpensive-optimizations -ffat-lto-objects
+          -ffast-math -ffinite-math-only -ffloat-store -fexcess-precision=STYLE
+          -fforward-propagate -ffp-contract=STYLE -ffunction-sections
+          -fgcse -fgcse-after-reload -fgcse-las -fgcse-lm -fgraphite-identity
+          -fgcse-sm -fhoist-adjacent-loads -fif-conversion
+          -fif-conversion2 -findirect-inlining
+          -finline-functions -finline-functions-called-once -finline-limit=N
+          -finline-small-functions -fipa-cp -fipa-cp-clone
+          -fipa-pta -fipa-profile -fipa-pure-const -fipa-reference
+          -fira-algorithm=ALGORITHM
+          -fira-region=REGION -fira-hoist-pressure
+          -fira-loop-pressure -fno-ira-share-save-slots
+          -fno-ira-share-spill-slots -fira-verbose=N
+          -fisolate-erroneous-paths-dereference -fisolate-erroneous-paths-attribute
+          -fivopts -fkeep-inline-functions -fkeep-static-consts -flive-range-shrinkage
+          -floop-block -floop-interchange -floop-strip-mine -floop-nest-optimize
+          -floop-parallelize-all -flto -flto-compression-level
+          -flto-partition=ALG -flto-report -flto-report-wpa -fmerge-all-constants
+          -fmerge-constants -fmodulo-sched -fmodulo-sched-allow-regmoves
+          -fmove-loop-invariants -fno-branch-count-reg
+          -fno-defer-pop -fno-function-cse -fno-guess-branch-probability
+          -fno-inline -fno-math-errno -fno-peephole -fno-peephole2
+          -fno-sched-interblock -fno-sched-spec -fno-signed-zeros
+          -fno-toplevel-reorder -fno-trapping-math -fno-zero-initialized-in-bss
+          -fomit-frame-pointer -foptimize-sibling-calls
+          -fpartial-inlining -fpeel-loops -fpredictive-commoning
+          -fprefetch-loop-arrays -fprofile-report
+          -fprofile-correction -fprofile-dir=PATH -fprofile-generate
+          -fprofile-generate=PATH
+          -fprofile-use -fprofile-use=PATH -fprofile-values -fprofile-reorder-functions
+          -freciprocal-math -free -frename-registers -freorder-blocks
+          -freorder-blocks-and-partition -freorder-functions
+          -frerun-cse-after-loop -freschedule-modulo-scheduled-loops
+          -frounding-math -fsched2-use-superblocks -fsched-pressure
+          -fsched-spec-load -fsched-spec-load-dangerous
+          -fsched-stalled-insns-dep[=N] -fsched-stalled-insns[=N]
+          -fsched-group-heuristic -fsched-critical-path-heuristic
+          -fsched-spec-insn-heuristic -fsched-rank-heuristic
+          -fsched-last-insn-heuristic -fsched-dep-count-heuristic
+          -fschedule-insns -fschedule-insns2 -fsection-anchors
+          -fselective-scheduling -fselective-scheduling2
+          -fsel-sched-pipelining -fsel-sched-pipelining-outer-loops
+          -fshrink-wrap -fsignaling-nans -fsingle-precision-constant
+          -fsplit-ivs-in-unroller -fsplit-wide-types -fstack-protector
+          -fstack-protector-all -fstack-protector-strong -fstrict-aliasing
+          -fstrict-overflow -fthread-jumps -ftracer -ftree-bit-ccp
+          -ftree-builtin-call-dce -ftree-ccp -ftree-ch
+          -ftree-coalesce-inline-vars -ftree-coalesce-vars -ftree-copy-prop
+          -ftree-copyrename -ftree-dce -ftree-dominator-opts -ftree-dse
+          -ftree-forwprop -ftree-fre -ftree-loop-if-convert
+          -ftree-loop-if-convert-stores -ftree-loop-im
+          -ftree-phiprop -ftree-loop-distribution -ftree-loop-distribute-patterns
+          -ftree-loop-ivcanon -ftree-loop-linear -ftree-loop-optimize
+          -ftree-loop-vectorize
+          -ftree-parallelize-loops=N -ftree-pre -ftree-partial-pre -ftree-pta
+          -ftree-reassoc -ftree-sink -ftree-slsr -ftree-sra
+          -ftree-switch-conversion -ftree-tail-merge -ftree-ter
+          -ftree-vectorize -ftree-vrp
+          -funit-at-a-time -funroll-all-loops -funroll-loops
+          -funsafe-loop-optimizations -funsafe-math-optimizations -funswitch-loops
+          -fvariable-expansion-in-unroller -fvect-cost-model -fvpt -fweb
+          -fwhole-program -fwpa -fuse-ld=LINKER -fuse-linker-plugin
+          --param NAME=VALUE
+          -O  -O0  -O1  -O2  -O3  -Os -Ofast -Og
+
+_Preprocessor Options_
+     *Note Options Controlling the Preprocessor: Preprocessor Options.
+          -AQUESTION=ANSWER
+          -A-QUESTION[=ANSWER]
+          -C  -dD  -dI  -dM  -dN
+          -DMACRO[=DEFN]  -E  -H
+          -idirafter DIR
+          -include FILE  -imacros FILE
+          -iprefix FILE  -iwithprefix DIR
+          -iwithprefixbefore DIR  -isystem DIR
+          -imultilib DIR -isysroot DIR
+          -M  -MM  -MF  -MG  -MP  -MQ  -MT  -nostdinc
+          -P  -fdebug-cpp -ftrack-macro-expansion -fworking-directory
+          -remap -trigraphs  -undef  -UMACRO
+          -Wp,OPTION -Xpreprocessor OPTION -no-integrated-cpp
+
+_Assembler Option_
+     *Note Passing Options to the Assembler: Assembler Options.
+          -Wa,OPTION  -Xassembler OPTION
+
+_Linker Options_
+     *Note Options for Linking: Link Options.
+          OBJECT-FILE-NAME  -lLIBRARY
+          -nostartfiles  -nodefaultlibs  -nostdlib -pie -rdynamic
+          -s  -static -static-libgcc -static-libstdc++
+          -static-libasan -static-libtsan -static-liblsan -static-libubsan
+          -shared -shared-libgcc  -symbolic
+          -T SCRIPT  -Wl,OPTION  -Xlinker OPTION
+          -u SYMBOL
+
+_Directory Options_
+     *Note Options for Directory Search: Directory Options.
+          -BPREFIX -IDIR -iplugindir=DIR
+          -iquoteDIR -LDIR -specs=FILE -I-
+          --sysroot=DIR --no-sysroot-suffix
+
+_Machine Dependent Options_
+     *Note Hardware Models and Configurations: Submodel Options.
+
+     _AArch64 Options_
+          -mabi=NAME  -mbig-endian  -mlittle-endian
+          -mgeneral-regs-only
+          -mcmodel=tiny  -mcmodel=small  -mcmodel=large
+          -mstrict-align
+          -momit-leaf-frame-pointer  -mno-omit-leaf-frame-pointer
+          -mtls-dialect=desc  -mtls-dialect=traditional
+          -march=NAME  -mcpu=NAME  -mtune=NAME
+
+     _Adapteva Epiphany Options_
+          -mhalf-reg-file -mprefer-short-insn-regs
+          -mbranch-cost=NUM -mcmove -mnops=NUM -msoft-cmpsf
+          -msplit-lohi -mpost-inc -mpost-modify -mstack-offset=NUM
+          -mround-nearest -mlong-calls -mshort-calls -msmall16
+          -mfp-mode=MODE -mvect-double -max-vect-align=NUM
+          -msplit-vecmove-early -m1reg-REG
+
+     _ARC Options_
+          -mbarrel-shifter
+          -mcpu=CPU -mA6 -mARC600 -mA7 -mARC700
+          -mdpfp -mdpfp-compact -mdpfp-fast -mno-dpfp-lrsr
+          -mea -mno-mpy -mmul32x16 -mmul64
+          -mnorm -mspfp -mspfp-compact -mspfp-fast -msimd -msoft-float -mswap
+          -mcrc -mdsp-packa -mdvbf -mlock -mmac-d16 -mmac-24 -mrtsc -mswape
+          -mtelephony -mxy -misize -mannotate-align -marclinux -marclinux_prof
+          -mepilogue-cfi -mlong-calls -mmedium-calls -msdata
+          -mucb-mcount -mvolatile-cache
+          -malign-call -mauto-modify-reg -mbbit-peephole -mno-brcc
+          -mcase-vector-pcrel -mcompact-casesi -mno-cond-exec -mearly-cbranchsi
+          -mexpand-adddi -mindexed-loads -mlra -mlra-priority-none
+          -mlra-priority-compact mlra-priority-noncompact -mno-millicode
+          -mmixed-code -mq-class -mRcq -mRcw -msize-level=LEVEL
+          -mtune=CPU -mmultcost=NUM -munalign-prob-threshold=PROBABILITY
+
+     _ARM Options_
+          -mapcs-frame  -mno-apcs-frame
+          -mabi=NAME
+          -mapcs-stack-check  -mno-apcs-stack-check
+          -mapcs-float  -mno-apcs-float
+          -mapcs-reentrant  -mno-apcs-reentrant
+          -msched-prolog  -mno-sched-prolog
+          -mlittle-endian  -mbig-endian  -mwords-little-endian
+          -mfloat-abi=NAME
+          -mfp16-format=NAME
+          -mthumb-interwork  -mno-thumb-interwork
+          -mcpu=NAME  -march=NAME  -mfpu=NAME
+          -mstructure-size-boundary=N
+          -mabort-on-noreturn
+          -mlong-calls  -mno-long-calls
+          -msingle-pic-base  -mno-single-pic-base
+          -mpic-register=REG
+          -mnop-fun-dllimport
+          -mpoke-function-name
+          -mthumb  -marm
+          -mtpcs-frame  -mtpcs-leaf-frame
+          -mcaller-super-interworking  -mcallee-super-interworking
+          -mtp=NAME -mtls-dialect=DIALECT
+          -mword-relocations
+          -mfix-cortex-m3-ldrd
+          -munaligned-access
+          -mneon-for-64bits
+          -mslow-flash-data
+          -mrestrict-it
+
+     _AVR Options_
+          -mmcu=MCU -maccumulate-args -mbranch-cost=COST
+          -mcall-prologues -mint8 -mno-interrupts -mrelax
+          -mstrict-X -mtiny-stack -Waddr-space-convert
+
+     _Blackfin Options_
+          -mcpu=CPU[-SIREVISION]
+          -msim -momit-leaf-frame-pointer  -mno-omit-leaf-frame-pointer
+          -mspecld-anomaly  -mno-specld-anomaly  -mcsync-anomaly  -mno-csync-anomaly
+          -mlow-64k -mno-low64k  -mstack-check-l1  -mid-shared-library
+          -mno-id-shared-library  -mshared-library-id=N
+          -mleaf-id-shared-library  -mno-leaf-id-shared-library
+          -msep-data  -mno-sep-data  -mlong-calls  -mno-long-calls
+          -mfast-fp -minline-plt -mmulticore  -mcorea  -mcoreb  -msdram
+          -micplb
+
+     _C6X Options_
+          -mbig-endian  -mlittle-endian -march=CPU
+          -msim -msdata=SDATA-TYPE
+
+     _CRIS Options_
+          -mcpu=CPU  -march=CPU  -mtune=CPU
+          -mmax-stack-frame=N  -melinux-stacksize=N
+          -metrax4  -metrax100  -mpdebug  -mcc-init  -mno-side-effects
+          -mstack-align  -mdata-align  -mconst-align
+          -m32-bit  -m16-bit  -m8-bit  -mno-prologue-epilogue  -mno-gotplt
+          -melf  -maout  -melinux  -mlinux  -sim  -sim2
+          -mmul-bug-workaround  -mno-mul-bug-workaround
+
+     _CR16 Options_
+          -mmac
+          -mcr16cplus -mcr16c
+          -msim -mint32 -mbit-ops
+          -mdata-model=MODEL
+
+     _Darwin Options_
+          -all_load  -allowable_client  -arch  -arch_errors_fatal
+          -arch_only  -bind_at_load  -bundle  -bundle_loader
+          -client_name  -compatibility_version  -current_version
+          -dead_strip
+          -dependency-file  -dylib_file  -dylinker_install_name
+          -dynamic  -dynamiclib  -exported_symbols_list
+          -filelist  -flat_namespace  -force_cpusubtype_ALL
+          -force_flat_namespace  -headerpad_max_install_names
+          -iframework
+          -image_base  -init  -install_name  -keep_private_externs
+          -multi_module  -multiply_defined  -multiply_defined_unused
+          -noall_load   -no_dead_strip_inits_and_terms
+          -nofixprebinding -nomultidefs  -noprebind  -noseglinkedit
+          -pagezero_size  -prebind  -prebind_all_twolevel_modules
+          -private_bundle  -read_only_relocs  -sectalign
+          -sectobjectsymbols  -whyload  -seg1addr
+          -sectcreate  -sectobjectsymbols  -sectorder
+          -segaddr -segs_read_only_addr -segs_read_write_addr
+          -seg_addr_table  -seg_addr_table_filename  -seglinkedit
+          -segprot  -segs_read_only_addr  -segs_read_write_addr
+          -single_module  -static  -sub_library  -sub_umbrella
+          -twolevel_namespace  -umbrella  -undefined
+          -unexported_symbols_list  -weak_reference_mismatches
+          -whatsloaded -F -gused -gfull -mmacosx-version-min=VERSION
+          -mkernel -mone-byte-bool
+
+     _DEC Alpha Options_
+          -mno-fp-regs  -msoft-float
+          -mieee  -mieee-with-inexact  -mieee-conformant
+          -mfp-trap-mode=MODE  -mfp-rounding-mode=MODE
+          -mtrap-precision=MODE  -mbuild-constants
+          -mcpu=CPU-TYPE  -mtune=CPU-TYPE
+          -mbwx  -mmax  -mfix  -mcix
+          -mfloat-vax  -mfloat-ieee
+          -mexplicit-relocs  -msmall-data  -mlarge-data
+          -msmall-text  -mlarge-text
+          -mmemory-latency=TIME
+
+     _FR30 Options_
+          -msmall-model -mno-lsim
+
+     _FRV Options_
+          -mgpr-32  -mgpr-64  -mfpr-32  -mfpr-64
+          -mhard-float  -msoft-float
+          -malloc-cc  -mfixed-cc  -mdword  -mno-dword
+          -mdouble  -mno-double
+          -mmedia  -mno-media  -mmuladd  -mno-muladd
+          -mfdpic  -minline-plt -mgprel-ro  -multilib-library-pic
+          -mlinked-fp  -mlong-calls  -malign-labels
+          -mlibrary-pic  -macc-4  -macc-8
+          -mpack  -mno-pack  -mno-eflags  -mcond-move  -mno-cond-move
+          -moptimize-membar -mno-optimize-membar
+          -mscc  -mno-scc  -mcond-exec  -mno-cond-exec
+          -mvliw-branch  -mno-vliw-branch
+          -mmulti-cond-exec  -mno-multi-cond-exec  -mnested-cond-exec
+          -mno-nested-cond-exec  -mtomcat-stats
+          -mTLS -mtls
+          -mcpu=CPU
+
+     _GNU/Linux Options_
+          -mglibc -muclibc -mbionic -mandroid
+          -tno-android-cc -tno-android-ld
+
+     _H8/300 Options_
+          -mrelax  -mh  -ms  -mn  -mexr -mno-exr  -mint32  -malign-300
+
+     _HPPA Options_
+          -march=ARCHITECTURE-TYPE
+          -mdisable-fpregs  -mdisable-indexing
+          -mfast-indirect-calls  -mgas  -mgnu-ld   -mhp-ld
+          -mfixed-range=REGISTER-RANGE
+          -mjump-in-delay -mlinker-opt -mlong-calls
+          -mlong-load-store  -mno-disable-fpregs
+          -mno-disable-indexing  -mno-fast-indirect-calls  -mno-gas
+          -mno-jump-in-delay  -mno-long-load-store
+          -mno-portable-runtime  -mno-soft-float
+          -mno-space-regs  -msoft-float  -mpa-risc-1-0
+          -mpa-risc-1-1  -mpa-risc-2-0  -mportable-runtime
+          -mschedule=CPU-TYPE  -mspace-regs  -msio  -mwsio
+          -munix=UNIX-STD  -nolibdld  -static  -threads
+
+     _i386 and x86-64 Options_
+          -mtune=CPU-TYPE  -march=CPU-TYPE
+          -mtune-ctrl=FEATURE-LIST -mdump-tune-features -mno-default
+          -mfpmath=UNIT
+          -masm=DIALECT  -mno-fancy-math-387
+          -mno-fp-ret-in-387  -msoft-float
+          -mno-wide-multiply  -mrtd  -malign-double
+          -mpreferred-stack-boundary=NUM
+          -mincoming-stack-boundary=NUM
+          -mcld -mcx16 -msahf -mmovbe -mcrc32
+          -mrecip -mrecip=OPT
+          -mvzeroupper -mprefer-avx128
+          -mmmx  -msse  -msse2 -msse3 -mssse3 -msse4.1 -msse4.2 -msse4 -mavx
+          -mavx2 -mavx512f -mavx512pf -mavx512er -mavx512cd -msha
+          -maes -mpclmul -mfsgsbase -mrdrnd -mf16c -mfma -mprefetchwt1
+          -msse4a -m3dnow -mpopcnt -mabm -mbmi -mtbm -mfma4 -mxop -mlzcnt
+          -mbmi2 -mfxsr -mxsave -mxsaveopt -mrtm -mlwp -mthreads
+          -mno-align-stringops  -minline-all-stringops
+          -minline-stringops-dynamically -mstringop-strategy=ALG
+          -mmemcpy-strategy=STRATEGY -mmemset-strategy=STRATEGY
+          -mpush-args  -maccumulate-outgoing-args  -m128bit-long-double
+          -m96bit-long-double -mlong-double-64 -mlong-double-80 -mlong-double-128
+          -mregparm=NUM  -msseregparm
+          -mveclibabi=TYPE -mvect8-ret-in-mem
+          -mpc32 -mpc64 -mpc80 -mstackrealign
+          -momit-leaf-frame-pointer  -mno-red-zone -mno-tls-direct-seg-refs
+          -mcmodel=CODE-MODEL -mabi=NAME -maddress-mode=MODE
+          -m32 -m64 -mx32 -m16 -mlarge-data-threshold=NUM
+          -msse2avx -mfentry -m8bit-idiv
+          -mavx256-split-unaligned-load -mavx256-split-unaligned-store
+          -mstack-protector-guard=GUARD
+
+     _i386 and x86-64 Windows Options_
+          -mconsole -mcygwin -mno-cygwin -mdll
+          -mnop-fun-dllimport -mthread
+          -municode -mwin32 -mwindows -fno-set-stack-executable
+
+     _IA-64 Options_
+          -mbig-endian  -mlittle-endian  -mgnu-as  -mgnu-ld  -mno-pic
+          -mvolatile-asm-stop  -mregister-names  -msdata -mno-sdata
+          -mconstant-gp  -mauto-pic  -mfused-madd
+          -minline-float-divide-min-latency
+          -minline-float-divide-max-throughput
+          -mno-inline-float-divide
+          -minline-int-divide-min-latency
+          -minline-int-divide-max-throughput
+          -mno-inline-int-divide
+          -minline-sqrt-min-latency -minline-sqrt-max-throughput
+          -mno-inline-sqrt
+          -mdwarf2-asm -mearly-stop-bits
+          -mfixed-range=REGISTER-RANGE -mtls-size=TLS-SIZE
+          -mtune=CPU-TYPE -milp32 -mlp64
+          -msched-br-data-spec -msched-ar-data-spec -msched-control-spec
+          -msched-br-in-data-spec -msched-ar-in-data-spec -msched-in-control-spec
+          -msched-spec-ldc -msched-spec-control-ldc
+          -msched-prefer-non-data-spec-insns -msched-prefer-non-control-spec-insns
+          -msched-stop-bits-after-every-cycle -msched-count-spec-in-critical-path
+          -msel-sched-dont-check-control-spec -msched-fp-mem-deps-zero-cost
+          -msched-max-memory-insns-hard-limit -msched-max-memory-insns=MAX-INSNS
+
+     _LM32 Options_
+          -mbarrel-shift-enabled -mdivide-enabled -mmultiply-enabled
+          -msign-extend-enabled -muser-enabled
+
+     _M32R/D Options_
+          -m32r2 -m32rx -m32r
+          -mdebug
+          -malign-loops -mno-align-loops
+          -missue-rate=NUMBER
+          -mbranch-cost=NUMBER
+          -mmodel=CODE-SIZE-MODEL-TYPE
+          -msdata=SDATA-TYPE
+          -mno-flush-func -mflush-func=NAME
+          -mno-flush-trap -mflush-trap=NUMBER
+          -G NUM
+
+     _M32C Options_
+          -mcpu=CPU -msim -memregs=NUMBER
+
+     _M680x0 Options_
+          -march=ARCH  -mcpu=CPU  -mtune=TUNE
+          -m68000  -m68020  -m68020-40  -m68020-60  -m68030  -m68040
+          -m68060  -mcpu32  -m5200  -m5206e  -m528x  -m5307  -m5407
+          -mcfv4e  -mbitfield  -mno-bitfield  -mc68000  -mc68020
+          -mnobitfield  -mrtd  -mno-rtd  -mdiv  -mno-div  -mshort
+          -mno-short  -mhard-float  -m68881  -msoft-float  -mpcrel
+          -malign-int  -mstrict-align  -msep-data  -mno-sep-data
+          -mshared-library-id=n  -mid-shared-library  -mno-id-shared-library
+          -mxgot -mno-xgot
+
+     _MCore Options_
+          -mhardlit  -mno-hardlit  -mdiv  -mno-div  -mrelax-immediates
+          -mno-relax-immediates  -mwide-bitfields  -mno-wide-bitfields
+          -m4byte-functions  -mno-4byte-functions  -mcallgraph-data
+          -mno-callgraph-data  -mslow-bytes  -mno-slow-bytes  -mno-lsim
+          -mlittle-endian  -mbig-endian  -m210  -m340  -mstack-increment
+
+     _MeP Options_
+          -mabsdiff -mall-opts -maverage -mbased=N -mbitops
+          -mc=N -mclip -mconfig=NAME -mcop -mcop32 -mcop64 -mivc2
+          -mdc -mdiv -meb -mel -mio-volatile -ml -mleadz -mm -mminmax
+          -mmult -mno-opts -mrepeat -ms -msatur -msdram -msim -msimnovec -mtf
+          -mtiny=N
+
+     _MicroBlaze Options_
+          -msoft-float -mhard-float -msmall-divides -mcpu=CPU
+          -mmemcpy -mxl-soft-mul -mxl-soft-div -mxl-barrel-shift
+          -mxl-pattern-compare -mxl-stack-check -mxl-gp-opt -mno-clearbss
+          -mxl-multiply-high -mxl-float-convert -mxl-float-sqrt
+          -mbig-endian -mlittle-endian -mxl-reorder -mxl-mode-APP-MODEL
+
+     _MIPS Options_
+          -EL  -EB  -march=ARCH  -mtune=ARCH
+          -mips1  -mips2  -mips3  -mips4  -mips32  -mips32r2
+          -mips64  -mips64r2
+          -mips16  -mno-mips16  -mflip-mips16
+          -minterlink-compressed -mno-interlink-compressed
+          -minterlink-mips16  -mno-interlink-mips16
+          -mabi=ABI  -mabicalls  -mno-abicalls
+          -mshared  -mno-shared  -mplt  -mno-plt  -mxgot  -mno-xgot
+          -mgp32  -mgp64  -mfp32  -mfp64  -mhard-float  -msoft-float
+          -mno-float  -msingle-float  -mdouble-float
+          -mabs=MODE  -mnan=ENCODING
+          -mdsp  -mno-dsp  -mdspr2  -mno-dspr2
+          -mmcu -mmno-mcu
+          -meva -mno-eva
+          -mvirt -mno-virt
+          -mmicromips -mno-micromips
+          -mfpu=FPU-TYPE
+          -msmartmips  -mno-smartmips
+          -mpaired-single  -mno-paired-single  -mdmx  -mno-mdmx
+          -mips3d  -mno-mips3d  -mmt  -mno-mt  -mllsc  -mno-llsc
+          -mlong64  -mlong32  -msym32  -mno-sym32
+          -GNUM  -mlocal-sdata  -mno-local-sdata
+          -mextern-sdata  -mno-extern-sdata  -mgpopt  -mno-gopt
+          -membedded-data  -mno-embedded-data
+          -muninit-const-in-rodata  -mno-uninit-const-in-rodata
+          -mcode-readable=SETTING
+          -msplit-addresses  -mno-split-addresses
+          -mexplicit-relocs  -mno-explicit-relocs
+          -mcheck-zero-division  -mno-check-zero-division
+          -mdivide-traps  -mdivide-breaks
+          -mmemcpy  -mno-memcpy  -mlong-calls  -mno-long-calls
+          -mmad -mno-mad -mimadd -mno-imadd -mfused-madd  -mno-fused-madd  -nocpp
+          -mfix-24k -mno-fix-24k
+          -mfix-r4000  -mno-fix-r4000  -mfix-r4400  -mno-fix-r4400
+          -mfix-r10000 -mno-fix-r10000  -mfix-rm7000 -mno-fix-rm7000
+          -mfix-vr4120  -mno-fix-vr4120
+          -mfix-vr4130  -mno-fix-vr4130  -mfix-sb1  -mno-fix-sb1
+          -mflush-func=FUNC  -mno-flush-func
+          -mbranch-cost=NUM  -mbranch-likely  -mno-branch-likely
+          -mfp-exceptions -mno-fp-exceptions
+          -mvr4130-align -mno-vr4130-align -msynci -mno-synci
+          -mrelax-pic-calls -mno-relax-pic-calls -mmcount-ra-address
+
+     _MMIX Options_
+          -mlibfuncs  -mno-libfuncs  -mepsilon  -mno-epsilon  -mabi=gnu
+          -mabi=mmixware  -mzero-extend  -mknuthdiv  -mtoplevel-symbols
+          -melf  -mbranch-predict  -mno-branch-predict  -mbase-addresses
+          -mno-base-addresses  -msingle-exit  -mno-single-exit
+
+     _MN10300 Options_
+          -mmult-bug  -mno-mult-bug
+          -mno-am33 -mam33 -mam33-2 -mam34
+          -mtune=CPU-TYPE
+          -mreturn-pointer-on-d0
+          -mno-crt0  -mrelax -mliw -msetlb
+
+     _Moxie Options_
+          -meb -mel -mno-crt0
+
+     _MSP430 Options_
+          -msim -masm-hex -mmcu= -mcpu= -mlarge -msmall -mrelax
+
+     _NDS32 Options_
+          -mbig-endian -mlittle-endian
+          -mreduced-regs -mfull-regs
+          -mcmov -mno-cmov
+          -mperf-ext -mno-perf-ext
+          -mv3push -mno-v3push
+          -m16bit -mno-16bit
+          -mgp-direct -mno-gp-direct
+          -misr-vector-size=NUM
+          -mcache-block-size=NUM
+          -march=ARCH
+          -mforce-fp-as-gp -mforbid-fp-as-gp
+          -mex9 -mctor-dtor -mrelax
+
+     _Nios II Options_
+          -G NUM -mgpopt -mno-gpopt -mel -meb
+          -mno-bypass-cache -mbypass-cache
+          -mno-cache-volatile -mcache-volatile
+          -mno-fast-sw-div -mfast-sw-div
+          -mhw-mul -mno-hw-mul -mhw-mulx -mno-hw-mulx -mno-hw-div -mhw-div
+          -mcustom-INSN=N -mno-custom-INSN
+          -mcustom-fpu-cfg=NAME
+          -mhal -msmallc -msys-crt0=NAME -msys-lib=NAME
+
+     _PDP-11 Options_
+          -mfpu  -msoft-float  -mac0  -mno-ac0  -m40  -m45  -m10
+          -mbcopy  -mbcopy-builtin  -mint32  -mno-int16
+          -mint16  -mno-int32  -mfloat32  -mno-float64
+          -mfloat64  -mno-float32  -mabshi  -mno-abshi
+          -mbranch-expensive  -mbranch-cheap
+          -munix-asm  -mdec-asm
+
+     _picoChip Options_
+          -mae=AE_TYPE -mvliw-lookahead=N
+          -msymbol-as-address -mno-inefficient-warnings
+
+     _PowerPC Options_ See RS/6000 and PowerPC Options.
+
+     _RL78 Options_
+          -msim -mmul=none -mmul=g13 -mmul=rl78
+
+     _RS/6000 and PowerPC Options_
+          -mcpu=CPU-TYPE
+          -mtune=CPU-TYPE
+          -mcmodel=CODE-MODEL
+          -mpowerpc64
+          -maltivec  -mno-altivec
+          -mpowerpc-gpopt  -mno-powerpc-gpopt
+          -mpowerpc-gfxopt  -mno-powerpc-gfxopt
+          -mmfcrf  -mno-mfcrf  -mpopcntb  -mno-popcntb -mpopcntd -mno-popcntd
+          -mfprnd  -mno-fprnd
+          -mcmpb -mno-cmpb -mmfpgpr -mno-mfpgpr -mhard-dfp -mno-hard-dfp
+          -mfull-toc   -mminimal-toc  -mno-fp-in-toc  -mno-sum-in-toc
+          -m64  -m32  -mxl-compat  -mno-xl-compat  -mpe
+          -malign-power  -malign-natural
+          -msoft-float  -mhard-float  -mmultiple  -mno-multiple
+          -msingle-float -mdouble-float -msimple-fpu
+          -mstring  -mno-string  -mupdate  -mno-update
+          -mavoid-indexed-addresses  -mno-avoid-indexed-addresses
+          -mfused-madd  -mno-fused-madd  -mbit-align  -mno-bit-align
+          -mstrict-align  -mno-strict-align  -mrelocatable
+          -mno-relocatable  -mrelocatable-lib  -mno-relocatable-lib
+          -mtoc  -mno-toc  -mlittle  -mlittle-endian  -mbig  -mbig-endian
+          -mdynamic-no-pic  -maltivec -mswdiv  -msingle-pic-base
+          -mprioritize-restricted-insns=PRIORITY
+          -msched-costly-dep=DEPENDENCE_TYPE
+          -minsert-sched-nops=SCHEME
+          -mcall-sysv  -mcall-netbsd
+          -maix-struct-return  -msvr4-struct-return
+          -mabi=ABI-TYPE -msecure-plt -mbss-plt
+          -mblock-move-inline-limit=NUM
+          -misel -mno-isel
+          -misel=yes  -misel=no
+          -mspe -mno-spe
+          -mspe=yes  -mspe=no
+          -mpaired
+          -mgen-cell-microcode -mwarn-cell-microcode
+          -mvrsave -mno-vrsave
+          -mmulhw -mno-mulhw
+          -mdlmzb -mno-dlmzb
+          -mfloat-gprs=yes  -mfloat-gprs=no -mfloat-gprs=single -mfloat-gprs=double
+          -mprototype  -mno-prototype
+          -msim  -mmvme  -mads  -myellowknife  -memb  -msdata
+          -msdata=OPT  -mvxworks  -G NUM  -pthread
+          -mrecip -mrecip=OPT -mno-recip -mrecip-precision
+          -mno-recip-precision
+          -mveclibabi=TYPE -mfriz -mno-friz
+          -mpointers-to-nested-functions -mno-pointers-to-nested-functions
+          -msave-toc-indirect -mno-save-toc-indirect
+          -mpower8-fusion -mno-mpower8-fusion -mpower8-vector -mno-power8-vector
+          -mcrypto -mno-crypto -mdirect-move -mno-direct-move
+          -mquad-memory -mno-quad-memory
+          -mquad-memory-atomic -mno-quad-memory-atomic
+          -mcompat-align-parm -mno-compat-align-parm
+
+     _RX Options_
+          -m64bit-doubles  -m32bit-doubles  -fpu  -nofpu
+          -mcpu=
+          -mbig-endian-data -mlittle-endian-data
+          -msmall-data
+          -msim  -mno-sim
+          -mas100-syntax -mno-as100-syntax
+          -mrelax
+          -mmax-constant-size=
+          -mint-register=
+          -mpid
+          -mno-warn-multiple-fast-interrupts
+          -msave-acc-in-interrupts
+
+     _S/390 and zSeries Options_
+          -mtune=CPU-TYPE  -march=CPU-TYPE
+          -mhard-float  -msoft-float  -mhard-dfp -mno-hard-dfp
+          -mlong-double-64 -mlong-double-128
+          -mbackchain  -mno-backchain -mpacked-stack  -mno-packed-stack
+          -msmall-exec  -mno-small-exec  -mmvcle -mno-mvcle
+          -m64  -m31  -mdebug  -mno-debug  -mesa  -mzarch
+          -mtpf-trace -mno-tpf-trace  -mfused-madd  -mno-fused-madd
+          -mwarn-framesize  -mwarn-dynamicstack  -mstack-size -mstack-guard
+          -mhotpatch[=HALFWORDS] -mno-hotpatch
+
+     _Score Options_
+          -meb -mel
+          -mnhwloop
+          -muls
+          -mmac
+          -mscore5 -mscore5u -mscore7 -mscore7d
+
+     _SH Options_
+          -m1  -m2  -m2e
+          -m2a-nofpu -m2a-single-only -m2a-single -m2a
+          -m3  -m3e
+          -m4-nofpu  -m4-single-only  -m4-single  -m4
+          -m4a-nofpu -m4a-single-only -m4a-single -m4a -m4al
+          -m5-64media  -m5-64media-nofpu
+          -m5-32media  -m5-32media-nofpu
+          -m5-compact  -m5-compact-nofpu
+          -mb  -ml  -mdalign  -mrelax
+          -mbigtable -mfmovd -mhitachi -mrenesas -mno-renesas -mnomacsave
+          -mieee -mno-ieee -mbitops  -misize  -minline-ic_invalidate -mpadstruct
+          -mspace -mprefergot  -musermode -multcost=NUMBER -mdiv=STRATEGY
+          -mdivsi3_libfunc=NAME -mfixed-range=REGISTER-RANGE
+          -mindexed-addressing -mgettrcost=NUMBER -mpt-fixed
+          -maccumulate-outgoing-args -minvalid-symbols
+          -matomic-model=ATOMIC-MODEL
+          -mbranch-cost=NUM -mzdcbranch -mno-zdcbranch
+          -mfused-madd -mno-fused-madd -mfsca -mno-fsca -mfsrra -mno-fsrra
+          -mpretend-cmove -mtas
+
+     _Solaris 2 Options_
+          -mimpure-text  -mno-impure-text
+          -pthreads -pthread
+
+     _SPARC Options_
+          -mcpu=CPU-TYPE
+          -mtune=CPU-TYPE
+          -mcmodel=CODE-MODEL
+          -mmemory-model=MEM-MODEL
+          -m32  -m64  -mapp-regs  -mno-app-regs
+          -mfaster-structs  -mno-faster-structs  -mflat  -mno-flat
+          -mfpu  -mno-fpu  -mhard-float  -msoft-float
+          -mhard-quad-float  -msoft-quad-float
+          -mstack-bias  -mno-stack-bias
+          -munaligned-doubles  -mno-unaligned-doubles
+          -mv8plus  -mno-v8plus  -mvis  -mno-vis
+          -mvis2  -mno-vis2  -mvis3  -mno-vis3
+          -mcbcond -mno-cbcond
+          -mfmaf  -mno-fmaf  -mpopc  -mno-popc
+          -mfix-at697f -mfix-ut699
+
+     _SPU Options_
+          -mwarn-reloc -merror-reloc
+          -msafe-dma -munsafe-dma
+          -mbranch-hints
+          -msmall-mem -mlarge-mem -mstdmain
+          -mfixed-range=REGISTER-RANGE
+          -mea32 -mea64
+          -maddress-space-conversion -mno-address-space-conversion
+          -mcache-size=CACHE-SIZE
+          -matomic-updates -mno-atomic-updates
+
+     _System V Options_
+          -Qy  -Qn  -YP,PATHS  -Ym,DIR
+
+     _TILE-Gx Options_
+          -mcpu=CPU -m32 -m64 -mbig-endian -mlittle-endian
+          -mcmodel=CODE-MODEL
+
+     _TILEPro Options_
+          -mcpu=CPU -m32
+
+     _V850 Options_
+          -mlong-calls  -mno-long-calls  -mep  -mno-ep
+          -mprolog-function  -mno-prolog-function  -mspace
+          -mtda=N  -msda=N  -mzda=N
+          -mapp-regs  -mno-app-regs
+          -mdisable-callt  -mno-disable-callt
+          -mv850e2v3 -mv850e2 -mv850e1 -mv850es
+          -mv850e -mv850 -mv850e3v5
+          -mloop
+          -mrelax
+          -mlong-jumps
+          -msoft-float
+          -mhard-float
+          -mgcc-abi
+          -mrh850-abi
+          -mbig-switch
+
+     _VAX Options_
+          -mg  -mgnu  -munix
+
+     _VMS Options_
+          -mvms-return-codes -mdebug-main=PREFIX -mmalloc64
+          -mpointer-size=SIZE
+
+     _VxWorks Options_
+          -mrtp  -non-static  -Bstatic  -Bdynamic
+          -Xbind-lazy  -Xbind-now
+
+     _x86-64 Options_ See i386 and x86-64 Options.
+
+     _Xstormy16 Options_
+          -msim
+
+     _Xtensa Options_
+          -mconst16 -mno-const16
+          -mfused-madd  -mno-fused-madd
+          -mforce-no-pic
+          -mserialize-volatile  -mno-serialize-volatile
+          -mtext-section-literals  -mno-text-section-literals
+          -mtarget-align  -mno-target-align
+          -mlongcalls  -mno-longcalls
+
+     _zSeries Options_ See S/390 and zSeries Options.
+
+_Code Generation Options_
+     *Note Options for Code Generation Conventions: Code Gen Options.
+          -fcall-saved-REG  -fcall-used-REG
+          -ffixed-REG  -fexceptions
+          -fnon-call-exceptions  -fdelete-dead-exceptions  -funwind-tables
+          -fasynchronous-unwind-tables
+          -fno-gnu-unique
+          -finhibit-size-directive  -finstrument-functions
+          -finstrument-functions-exclude-function-list=SYM,SYM,...
+          -finstrument-functions-exclude-file-list=FILE,FILE,...
+          -fno-common  -fno-ident
+          -fpcc-struct-return  -fpic  -fPIC -fpie -fPIE
+          -fno-jump-tables
+          -frecord-gcc-switches
+          -freg-struct-return  -fshort-enums
+          -fshort-double  -fshort-wchar
+          -fverbose-asm  -fpack-struct[=N]  -fstack-check
+          -fstack-limit-register=REG  -fstack-limit-symbol=SYM
+          -fno-stack-limit -fsplit-stack
+          -fleading-underscore  -ftls-model=MODEL
+          -fstack-reuse=REUSE_LEVEL
+          -ftrapv  -fwrapv  -fbounds-check
+          -fvisibility -fstrict-volatile-bitfields -fsync-libcalls
+
+
+File: gcc.info,  Node: Overall Options,  Next: Invoking G++,  Prev: Option Summary,  Up: Invoking GCC
+
+3.2 Options Controlling the Kind of Output
+==========================================
+
+Compilation can involve up to four stages: preprocessing, compilation
+proper, assembly and linking, always in that order.  GCC is capable of
+preprocessing and compiling several files either into several assembler
+input files, or into one assembler input file; then each assembler input
+file produces an object file, and linking combines all the object files
+(those newly compiled, and those specified as input) into an executable
+file.
+
+ For any given input file, the file name suffix determines what kind of
+compilation is done:
+
+'FILE.c'
+     C source code that must be preprocessed.
+
+'FILE.i'
+     C source code that should not be preprocessed.
+
+'FILE.ii'
+     C++ source code that should not be preprocessed.
+
+'FILE.m'
+     Objective-C source code.  Note that you must link with the
+     'libobjc' library to make an Objective-C program work.
+
+'FILE.mi'
+     Objective-C source code that should not be preprocessed.
+
+'FILE.mm'
+'FILE.M'
+     Objective-C++ source code.  Note that you must link with the
+     'libobjc' library to make an Objective-C++ program work.  Note that
+     '.M' refers to a literal capital M.
+
+'FILE.mii'
+     Objective-C++ source code that should not be preprocessed.
+
+'FILE.h'
+     C, C++, Objective-C or Objective-C++ header file to be turned into
+     a precompiled header (default), or C, C++ header file to be turned
+     into an Ada spec (via the '-fdump-ada-spec' switch).
+
+'FILE.cc'
+'FILE.cp'
+'FILE.cxx'
+'FILE.cpp'
+'FILE.CPP'
+'FILE.c++'
+'FILE.C'
+     C++ source code that must be preprocessed.  Note that in '.cxx',
+     the last two letters must both be literally 'x'.  Likewise, '.C'
+     refers to a literal capital C.
+
+'FILE.mm'
+'FILE.M'
+     Objective-C++ source code that must be preprocessed.
+
+'FILE.mii'
+     Objective-C++ source code that should not be preprocessed.
+
+'FILE.hh'
+'FILE.H'
+'FILE.hp'
+'FILE.hxx'
+'FILE.hpp'
+'FILE.HPP'
+'FILE.h++'
+'FILE.tcc'
+     C++ header file to be turned into a precompiled header or Ada spec.
+
+'FILE.f'
+'FILE.for'
+'FILE.ftn'
+     Fixed form Fortran source code that should not be preprocessed.
+
+'FILE.F'
+'FILE.FOR'
+'FILE.fpp'
+'FILE.FPP'
+'FILE.FTN'
+     Fixed form Fortran source code that must be preprocessed (with the
+     traditional preprocessor).
+
+'FILE.f90'
+'FILE.f95'
+'FILE.f03'
+'FILE.f08'
+     Free form Fortran source code that should not be preprocessed.
+
+'FILE.F90'
+'FILE.F95'
+'FILE.F03'
+'FILE.F08'
+     Free form Fortran source code that must be preprocessed (with the
+     traditional preprocessor).
+
+'FILE.go'
+     Go source code.
+
+'FILE.ads'
+     Ada source code file that contains a library unit declaration (a
+     declaration of a package, subprogram, or generic, or a generic
+     instantiation), or a library unit renaming declaration (a package,
+     generic, or subprogram renaming declaration).  Such files are also
+     called "specs".
+
+'FILE.adb'
+     Ada source code file containing a library unit body (a subprogram
+     or package body).  Such files are also called "bodies".
+
+'FILE.s'
+     Assembler code.
+
+'FILE.S'
+'FILE.sx'
+     Assembler code that must be preprocessed.
+
+'OTHER'
+     An object file to be fed straight into linking.  Any file name with
+     no recognized suffix is treated this way.
+
+ You can specify the input language explicitly with the '-x' option:
+
+'-x LANGUAGE'
+     Specify explicitly the LANGUAGE for the following input files
+     (rather than letting the compiler choose a default based on the
+     file name suffix).  This option applies to all following input
+     files until the next '-x' option.  Possible values for LANGUAGE
+     are:
+          c  c-header  cpp-output
+          c++  c++-header  c++-cpp-output
+          objective-c  objective-c-header  objective-c-cpp-output
+          objective-c++ objective-c++-header objective-c++-cpp-output
+          assembler  assembler-with-cpp
+          ada
+          f77  f77-cpp-input f95  f95-cpp-input
+          go
+          java
+
+'-x none'
+     Turn off any specification of a language, so that subsequent files
+     are handled according to their file name suffixes (as they are if
+     '-x' has not been used at all).
+
+'-pass-exit-codes'
+     Normally the 'gcc' program exits with the code of 1 if any phase of
+     the compiler returns a non-success return code.  If you specify
+     '-pass-exit-codes', the 'gcc' program instead returns with the
+     numerically highest error produced by any phase returning an error
+     indication.  The C, C++, and Fortran front ends return 4 if an
+     internal compiler error is encountered.
+
+ If you only want some of the stages of compilation, you can use '-x'
+(or filename suffixes) to tell 'gcc' where to start, and one of the
+options '-c', '-S', or '-E' to say where 'gcc' is to stop.  Note that
+some combinations (for example, '-x cpp-output -E') instruct 'gcc' to do
+nothing at all.
+
+'-c'
+     Compile or assemble the source files, but do not link.  The linking
+     stage simply is not done.  The ultimate output is in the form of an
+     object file for each source file.
+
+     By default, the object file name for a source file is made by
+     replacing the suffix '.c', '.i', '.s', etc., with '.o'.
+
+     Unrecognized input files, not requiring compilation or assembly,
+     are ignored.
+
+'-S'
+     Stop after the stage of compilation proper; do not assemble.  The
+     output is in the form of an assembler code file for each
+     non-assembler input file specified.
+
+     By default, the assembler file name for a source file is made by
+     replacing the suffix '.c', '.i', etc., with '.s'.
+
+     Input files that don't require compilation are ignored.
+
+'-E'
+     Stop after the preprocessing stage; do not run the compiler proper.
+     The output is in the form of preprocessed source code, which is
+     sent to the standard output.
+
+     Input files that don't require preprocessing are ignored.
+
+'-o FILE'
+     Place output in file FILE.  This applies to whatever sort of output
+     is being produced, whether it be an executable file, an object
+     file, an assembler file or preprocessed C code.
+
+     If '-o' is not specified, the default is to put an executable file
+     in 'a.out', the object file for 'SOURCE.SUFFIX' in 'SOURCE.o', its
+     assembler file in 'SOURCE.s', a precompiled header file in
+     'SOURCE.SUFFIX.gch', and all preprocessed C source on standard
+     output.
+
+'-v'
+     Print (on standard error output) the commands executed to run the
+     stages of compilation.  Also print the version number of the
+     compiler driver program and of the preprocessor and the compiler
+     proper.
+
+'-###'
+     Like '-v' except the commands are not executed and arguments are
+     quoted unless they contain only alphanumeric characters or './-_'.
+     This is useful for shell scripts to capture the driver-generated
+     command lines.
+
+'-pipe'
+     Use pipes rather than temporary files for communication between the
+     various stages of compilation.  This fails to work on some systems
+     where the assembler is unable to read from a pipe; but the GNU
+     assembler has no trouble.
+
+'--help'
+     Print (on the standard output) a description of the command-line
+     options understood by 'gcc'.  If the '-v' option is also specified
+     then '--help' is also passed on to the various processes invoked by
+     'gcc', so that they can display the command-line options they
+     accept.  If the '-Wextra' option has also been specified (prior to
+     the '--help' option), then command-line options that have no
+     documentation associated with them are also displayed.
+
+'--target-help'
+     Print (on the standard output) a description of target-specific
+     command-line options for each tool.  For some targets extra
+     target-specific information may also be printed.
+
+'--help={CLASS|[^]QUALIFIER}[,...]'
+     Print (on the standard output) a description of the command-line
+     options understood by the compiler that fit into all specified
+     classes and qualifiers.  These are the supported classes:
+
+     'optimizers'
+          Display all of the optimization options supported by the
+          compiler.
+
+     'warnings'
+          Display all of the options controlling warning messages
+          produced by the compiler.
+
+     'target'
+          Display target-specific options.  Unlike the '--target-help'
+          option however, target-specific options of the linker and
+          assembler are not displayed.  This is because those tools do
+          not currently support the extended '--help=' syntax.
+
+     'params'
+          Display the values recognized by the '--param' option.
+
+     LANGUAGE
+          Display the options supported for LANGUAGE, where LANGUAGE is
+          the name of one of the languages supported in this version of
+          GCC.
+
+     'common'
+          Display the options that are common to all languages.
+
+     These are the supported qualifiers:
+
+     'undocumented'
+          Display only those options that are undocumented.
+
+     'joined'
+          Display options taking an argument that appears after an equal
+          sign in the same continuous piece of text, such as:
+          '--help=target'.
+
+     'separate'
+          Display options taking an argument that appears as a separate
+          word following the original option, such as: '-o output-file'.
+
+     Thus for example to display all the undocumented target-specific
+     switches supported by the compiler, use:
+
+          --help=target,undocumented
+
+     The sense of a qualifier can be inverted by prefixing it with the
+     '^' character, so for example to display all binary warning options
+     (i.e., ones that are either on or off and that do not take an
+     argument) that have a description, use:
+
+          --help=warnings,^joined,^undocumented
+
+     The argument to '--help=' should not consist solely of inverted
+     qualifiers.
+
+     Combining several classes is possible, although this usually
+     restricts the output so much that there is nothing to display.  One
+     case where it does work, however, is when one of the classes is
+     TARGET.  For example, to display all the target-specific
+     optimization options, use:
+
+          --help=target,optimizers
+
+     The '--help=' option can be repeated on the command line.  Each
+     successive use displays its requested class of options, skipping
+     those that have already been displayed.
+
+     If the '-Q' option appears on the command line before the '--help='
+     option, then the descriptive text displayed by '--help=' is
+     changed.  Instead of describing the displayed options, an
+     indication is given as to whether the option is enabled, disabled
+     or set to a specific value (assuming that the compiler knows this
+     at the point where the '--help=' option is used).
+
+     Here is a truncated example from the ARM port of 'gcc':
+
+            % gcc -Q -mabi=2 --help=target -c
+            The following options are target specific:
+            -mabi=                                2
+            -mabort-on-noreturn                   [disabled]
+            -mapcs                                [disabled]
+
+     The output is sensitive to the effects of previous command-line
+     options, so for example it is possible to find out which
+     optimizations are enabled at '-O2' by using:
+
+          -Q -O2 --help=optimizers
+
+     Alternatively you can discover which binary optimizations are
+     enabled by '-O3' by using:
+
+          gcc -c -Q -O3 --help=optimizers > /tmp/O3-opts
+          gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
+          diff /tmp/O2-opts /tmp/O3-opts | grep enabled
+
+'-no-canonical-prefixes'
+     Do not expand any symbolic links, resolve references to '/../' or
+     '/./', or make the path absolute when generating a relative prefix.
+
+'--version'
+     Display the version number and copyrights of the invoked GCC.
+
+'-wrapper'
+     Invoke all subcommands under a wrapper program.  The name of the
+     wrapper program and its parameters are passed as a comma separated
+     list.
+
+          gcc -c t.c -wrapper gdb,--args
+
+     This invokes all subprograms of 'gcc' under 'gdb --args', thus the
+     invocation of 'cc1' is 'gdb --args cc1 ...'.
+
+'-fplugin=NAME.so'
+     Load the plugin code in file NAME.so, assumed to be a shared object
+     to be dlopen'd by the compiler.  The base name of the shared object
+     file is used to identify the plugin for the purposes of argument
+     parsing (See '-fplugin-arg-NAME-KEY=VALUE' below).  Each plugin
+     should define the callback functions specified in the Plugins API.
+
+'-fplugin-arg-NAME-KEY=VALUE'
+     Define an argument called KEY with a value of VALUE for the plugin
+     called NAME.
+
+'-fdump-ada-spec[-slim]'
+     For C and C++ source and include files, generate corresponding Ada
+     specs.  *Note (gnat_ugn)Generating Ada Bindings for C and C++
+     headers::, which provides detailed documentation on this feature.
+
+'-fada-spec-parent=UNIT'
+     In conjunction with '-fdump-ada-spec[-slim]' above, generate Ada
+     specs as child units of parent UNIT.
+
+'-fdump-go-spec=FILE'
+     For input files in any language, generate corresponding Go
+     declarations in FILE.  This generates Go 'const', 'type', 'var',
+     and 'func' declarations which may be a useful way to start writing
+     a Go interface to code written in some other language.
+
+'@FILE'
+     Read command-line options from FILE.  The options read are inserted
+     in place of the original @FILE option.  If FILE does not exist, or
+     cannot be read, then the option will be treated literally, and not
+     removed.
+
+     Options in FILE are separated by whitespace.  A whitespace
+     character may be included in an option by surrounding the entire
+     option in either single or double quotes.  Any character (including
+     a backslash) may be included by prefixing the character to be
+     included with a backslash.  The FILE may itself contain additional
+     @FILE options; any such options will be processed recursively.
+
+
+File: gcc.info,  Node: Invoking G++,  Next: C Dialect Options,  Prev: Overall Options,  Up: Invoking GCC
+
+3.3 Compiling C++ Programs
+==========================
+
+C++ source files conventionally use one of the suffixes '.C', '.cc',
+'.cpp', '.CPP', '.c++', '.cp', or '.cxx'; C++ header files often use
+'.hh', '.hpp', '.H', or (for shared template code) '.tcc'; and
+preprocessed C++ files use the suffix '.ii'.  GCC recognizes files with
+these names and compiles them as C++ programs even if you call the
+compiler the same way as for compiling C programs (usually with the name
+'gcc').
+
+ However, the use of 'gcc' does not add the C++ library.  'g++' is a
+program that calls GCC and automatically specifies linking against the
+C++ library.  It treats '.c', '.h' and '.i' files as C++ source files
+instead of C source files unless '-x' is used.  This program is also
+useful when precompiling a C header file with a '.h' extension for use
+in C++ compilations.  On many systems, 'g++' is also installed with the
+name 'c++'.
+
+ When you compile C++ programs, you may specify many of the same
+command-line options that you use for compiling programs in any
+language; or command-line options meaningful for C and related
+languages; or options that are meaningful only for C++ programs.  *Note
+Options Controlling C Dialect: C Dialect Options, for explanations of
+options for languages related to C.  *Note Options Controlling C++
+Dialect: C++ Dialect Options, for explanations of options that are
+meaningful only for C++ programs.
+
+
+File: gcc.info,  Node: C Dialect Options,  Next: C++ Dialect Options,  Prev: Invoking G++,  Up: Invoking GCC
+
+3.4 Options Controlling C Dialect
+=================================
+
+The following options control the dialect of C (or languages derived
+from C, such as C++, Objective-C and Objective-C++) that the compiler
+accepts:
+
+'-ansi'
+     In C mode, this is equivalent to '-std=c90'.  In C++ mode, it is
+     equivalent to '-std=c++98'.
+
+     This turns off certain features of GCC that are incompatible with
+     ISO C90 (when compiling C code), or of standard C++ (when compiling
+     C++ code), such as the 'asm' and 'typeof' keywords, and predefined
+     macros such as 'unix' and 'vax' that identify the type of system
+     you are using.  It also enables the undesirable and rarely used ISO
+     trigraph feature.  For the C compiler, it disables recognition of
+     C++ style '//' comments as well as the 'inline' keyword.
+
+     The alternate keywords '__asm__', '__extension__', '__inline__' and
+     '__typeof__' continue to work despite '-ansi'.  You would not want
+     to use them in an ISO C program, of course, but it is useful to put
+     them in header files that might be included in compilations done
+     with '-ansi'.  Alternate predefined macros such as '__unix__' and
+     '__vax__' are also available, with or without '-ansi'.
+
+     The '-ansi' option does not cause non-ISO programs to be rejected
+     gratuitously.  For that, '-Wpedantic' is required in addition to
+     '-ansi'.  *Note Warning Options::.
+
+     The macro '__STRICT_ANSI__' is predefined when the '-ansi' option
+     is used.  Some header files may notice this macro and refrain from
+     declaring certain functions or defining certain macros that the ISO
+     standard doesn't call for; this is to avoid interfering with any
+     programs that might use these names for other things.
+
+     Functions that are normally built in but do not have semantics
+     defined by ISO C (such as 'alloca' and 'ffs') are not built-in
+     functions when '-ansi' is used.  *Note Other built-in functions
+     provided by GCC: Other Builtins, for details of the functions
+     affected.
+
+'-std='
+     Determine the language standard.  *Note Language Standards
+     Supported by GCC: Standards, for details of these standard
+     versions.  This option is currently only supported when compiling C
+     or C++.
+
+     The compiler can accept several base standards, such as 'c90' or
+     'c++98', and GNU dialects of those standards, such as 'gnu90' or
+     'gnu++98'.  When a base standard is specified, the compiler accepts
+     all programs following that standard plus those using GNU
+     extensions that do not contradict it.  For example, '-std=c90'
+     turns off certain features of GCC that are incompatible with ISO
+     C90, such as the 'asm' and 'typeof' keywords, but not other GNU
+     extensions that do not have a meaning in ISO C90, such as omitting
+     the middle term of a '?:' expression.  On the other hand, when a
+     GNU dialect of a standard is specified, all features supported by
+     the compiler are enabled, even when those features change the
+     meaning of the base standard.  As a result, some strict-conforming
+     programs may be rejected.  The particular standard is used by
+     '-Wpedantic' to identify which features are GNU extensions given
+     that version of the standard.  For example '-std=gnu90 -Wpedantic'
+     warns about C++ style '//' comments, while '-std=gnu99 -Wpedantic'
+     does not.
+
+     A value for this option must be provided; possible values are
+
+     'c90'
+     'c89'
+     'iso9899:1990'
+          Support all ISO C90 programs (certain GNU extensions that
+          conflict with ISO C90 are disabled).  Same as '-ansi' for C
+          code.
+
+     'iso9899:199409'
+          ISO C90 as modified in amendment 1.
+
+     'c99'
+     'c9x'
+     'iso9899:1999'
+     'iso9899:199x'
+          ISO C99.  This standard is substantially completely supported,
+          modulo bugs, extended identifiers (supported except for corner
+          cases when '-fextended-identifiers' is used) and
+          floating-point issues (mainly but not entirely relating to
+          optional C99 features from Annexes F and G). See <http://gcc.gnu.org/c99status.html>
+          for more information.  The names 'c9x' and 'iso9899:199x' are
+          deprecated.
+
+     'c11'
+     'c1x'
+     'iso9899:2011'
+          ISO C11, the 2011 revision of the ISO C standard.  This
+          standard is substantially completely supported, modulo bugs,
+          extended identifiers (supported except for corner cases when
+          '-fextended-identifiers' is used), floating-point issues
+          (mainly but not entirely relating to optional C11 features
+          from Annexes F and G) and the optional Annexes K
+          (Bounds-checking interfaces) and L (Analyzability).  The name
+          'c1x' is deprecated.
+
+     'gnu90'
+     'gnu89'
+          GNU dialect of ISO C90 (including some C99 features).  This is
+          the default for C code.
+
+     'gnu99'
+     'gnu9x'
+          GNU dialect of ISO C99.  The name 'gnu9x' is deprecated.
+
+     'gnu11'
+     'gnu1x'
+          GNU dialect of ISO C11.  This is intended to become the
+          default in a future release of GCC. The name 'gnu1x' is
+          deprecated.
+
+     'c++98'
+     'c++03'
+          The 1998 ISO C++ standard plus the 2003 technical corrigendum
+          and some additional defect reports.  Same as '-ansi' for C++
+          code.
+
+     'gnu++98'
+     'gnu++03'
+          GNU dialect of '-std=c++98'.  This is the default for C++
+          code.
+
+     'c++11'
+     'c++0x'
+          The 2011 ISO C++ standard plus amendments.  The name 'c++0x'
+          is deprecated.
+
+     'gnu++11'
+     'gnu++0x'
+          GNU dialect of '-std=c++11'.  The name 'gnu++0x' is
+          deprecated.
+
+     'c++1y'
+          The next revision of the ISO C++ standard, tentatively planned
+          for 2014.  Support is highly experimental, and will almost
+          certainly change in incompatible ways in future releases.
+
+     'gnu++1y'
+          GNU dialect of '-std=c++1y'.  Support is highly experimental,
+          and will almost certainly change in incompatible ways in
+          future releases.
+
+'-fgnu89-inline'
+     The option '-fgnu89-inline' tells GCC to use the traditional GNU
+     semantics for 'inline' functions when in C99 mode.  *Note An Inline
+     Function is As Fast As a Macro: Inline.  This option is accepted
+     and ignored by GCC versions 4.1.3 up to but not including 4.3.  In
+     GCC versions 4.3 and later it changes the behavior of GCC in C99
+     mode.  Using this option is roughly equivalent to adding the
+     'gnu_inline' function attribute to all inline functions (*note
+     Function Attributes::).
+
+     The option '-fno-gnu89-inline' explicitly tells GCC to use the C99
+     semantics for 'inline' when in C99 or gnu99 mode (i.e., it
+     specifies the default behavior).  This option was first supported
+     in GCC 4.3.  This option is not supported in '-std=c90' or
+     '-std=gnu90' mode.
+
+     The preprocessor macros '__GNUC_GNU_INLINE__' and
+     '__GNUC_STDC_INLINE__' may be used to check which semantics are in
+     effect for 'inline' functions.  *Note (cpp)Common Predefined
+     Macros::.
+
+'-aux-info FILENAME'
+     Output to the given filename prototyped declarations for all
+     functions declared and/or defined in a translation unit, including
+     those in header files.  This option is silently ignored in any
+     language other than C.
+
+     Besides declarations, the file indicates, in comments, the origin
+     of each declaration (source file and line), whether the declaration
+     was implicit, prototyped or unprototyped ('I', 'N' for new or 'O'
+     for old, respectively, in the first character after the line number
+     and the colon), and whether it came from a declaration or a
+     definition ('C' or 'F', respectively, in the following character).
+     In the case of function definitions, a K&R-style list of arguments
+     followed by their declarations is also provided, inside comments,
+     after the declaration.
+
+'-fallow-parameterless-variadic-functions'
+     Accept variadic functions without named parameters.
+
+     Although it is possible to define such a function, this is not very
+     useful as it is not possible to read the arguments.  This is only
+     supported for C as this construct is allowed by C++.
+
+'-fno-asm'
+     Do not recognize 'asm', 'inline' or 'typeof' as a keyword, so that
+     code can use these words as identifiers.  You can use the keywords
+     '__asm__', '__inline__' and '__typeof__' instead.  '-ansi' implies
+     '-fno-asm'.
+
+     In C++, this switch only affects the 'typeof' keyword, since 'asm'
+     and 'inline' are standard keywords.  You may want to use the
+     '-fno-gnu-keywords' flag instead, which has the same effect.  In
+     C99 mode ('-std=c99' or '-std=gnu99'), this switch only affects the
+     'asm' and 'typeof' keywords, since 'inline' is a standard keyword
+     in ISO C99.
+
+'-fno-builtin'
+'-fno-builtin-FUNCTION'
+     Don't recognize built-in functions that do not begin with
+     '__builtin_' as prefix.  *Note Other built-in functions provided by
+     GCC: Other Builtins, for details of the functions affected,
+     including those which are not built-in functions when '-ansi' or
+     '-std' options for strict ISO C conformance are used because they
+     do not have an ISO standard meaning.
+
+     GCC normally generates special code to handle certain built-in
+     functions more efficiently; for instance, calls to 'alloca' may
+     become single instructions which adjust the stack directly, and
+     calls to 'memcpy' may become inline copy loops.  The resulting code
+     is often both smaller and faster, but since the function calls no
+     longer appear as such, you cannot set a breakpoint on those calls,
+     nor can you change the behavior of the functions by linking with a
+     different library.  In addition, when a function is recognized as a
+     built-in function, GCC may use information about that function to
+     warn about problems with calls to that function, or to generate
+     more efficient code, even if the resulting code still contains
+     calls to that function.  For example, warnings are given with
+     '-Wformat' for bad calls to 'printf' when 'printf' is built in and
+     'strlen' is known not to modify global memory.
+
+     With the '-fno-builtin-FUNCTION' option only the built-in function
+     FUNCTION is disabled.  FUNCTION must not begin with '__builtin_'.
+     If a function is named that is not built-in in this version of GCC,
+     this option is ignored.  There is no corresponding
+     '-fbuiltin-FUNCTION' option; if you wish to enable built-in
+     functions selectively when using '-fno-builtin' or
+     '-ffreestanding', you may define macros such as:
+
+          #define abs(n)          __builtin_abs ((n))
+          #define strcpy(d, s)    __builtin_strcpy ((d), (s))
+
+'-fhosted'
+
+     Assert that compilation targets a hosted environment.  This implies
+     '-fbuiltin'.  A hosted environment is one in which the entire
+     standard library is available, and in which 'main' has a return
+     type of 'int'.  Examples are nearly everything except a kernel.
+     This is equivalent to '-fno-freestanding'.
+
+'-ffreestanding'
+
+     Assert that compilation targets a freestanding environment.  This
+     implies '-fno-builtin'.  A freestanding environment is one in which
+     the standard library may not exist, and program startup may not
+     necessarily be at 'main'.  The most obvious example is an OS
+     kernel.  This is equivalent to '-fno-hosted'.
+
+     *Note Language Standards Supported by GCC: Standards, for details
+     of freestanding and hosted environments.
+
+'-fopenmp'
+     Enable handling of OpenMP directives '#pragma omp' in C/C++ and
+     '!$omp' in Fortran.  When '-fopenmp' is specified, the compiler
+     generates parallel code according to the OpenMP Application Program
+     Interface v4.0 <http://www.openmp.org/>.  This option implies
+     '-pthread', and thus is only supported on targets that have support
+     for '-pthread'.  '-fopenmp' implies '-fopenmp-simd'.
+
+'-fopenmp-simd'
+     Enable handling of OpenMP's SIMD directives with '#pragma omp' in
+     C/C++ and '!$omp' in Fortran.  Other OpenMP directives are ignored.
+
+'-fcilkplus'
+     Enable the usage of Cilk Plus language extension features for
+     C/C++.  When the option '-fcilkplus' is specified, enable the usage
+     of the Cilk Plus Language extension features for C/C++.  The
+     present implementation follows ABI version 1.2.  This is an
+     experimental feature that is only partially complete, and whose
+     interface may change in future versions of GCC as the official
+     specification changes.  Currently, all features but '_Cilk_for'
+     have been implemented.
+
+'-fgnu-tm'
+     When the option '-fgnu-tm' is specified, the compiler generates
+     code for the Linux variant of Intel's current Transactional Memory
+     ABI specification document (Revision 1.1, May 6 2009).  This is an
+     experimental feature whose interface may change in future versions
+     of GCC, as the official specification changes.  Please note that
+     not all architectures are supported for this feature.
+
+     For more information on GCC's support for transactional memory,
+     *Note The GNU Transactional Memory Library: (libitm)Enabling
+     libitm.
+
+     Note that the transactional memory feature is not supported with
+     non-call exceptions ('-fnon-call-exceptions').
+
+'-fms-extensions'
+     Accept some non-standard constructs used in Microsoft header files.
+
+     In C++ code, this allows member names in structures to be similar
+     to previous types declarations.
+
+          typedef int UOW;
+          struct ABC {
+            UOW UOW;
+          };
+
+     Some cases of unnamed fields in structures and unions are only
+     accepted with this option.  *Note Unnamed struct/union fields
+     within structs/unions: Unnamed Fields, for details.
+
+     Note that this option is off for all targets but i?86 and x86_64
+     targets using ms-abi.
+'-fplan9-extensions'
+     Accept some non-standard constructs used in Plan 9 code.
+
+     This enables '-fms-extensions', permits passing pointers to
+     structures with anonymous fields to functions that expect pointers
+     to elements of the type of the field, and permits referring to
+     anonymous fields declared using a typedef.  *Note Unnamed
+     struct/union fields within structs/unions: Unnamed Fields, for
+     details.  This is only supported for C, not C++.
+
+'-trigraphs'
+     Support ISO C trigraphs.  The '-ansi' option (and '-std' options
+     for strict ISO C conformance) implies '-trigraphs'.
+
+'-traditional'
+'-traditional-cpp'
+     Formerly, these options caused GCC to attempt to emulate a
+     pre-standard C compiler.  They are now only supported with the '-E'
+     switch.  The preprocessor continues to support a pre-standard mode.
+     See the GNU CPP manual for details.
+
+'-fcond-mismatch'
+     Allow conditional expressions with mismatched types in the second
+     and third arguments.  The value of such an expression is void.
+     This option is not supported for C++.
+
+'-flax-vector-conversions'
+     Allow implicit conversions between vectors with differing numbers
+     of elements and/or incompatible element types.  This option should
+     not be used for new code.
+
+'-funsigned-char'
+     Let the type 'char' be unsigned, like 'unsigned char'.
+
+     Each kind of machine has a default for what 'char' should be.  It
+     is either like 'unsigned char' by default or like 'signed char' by
+     default.
+
+     Ideally, a portable program should always use 'signed char' or
+     'unsigned char' when it depends on the signedness of an object.
+     But many programs have been written to use plain 'char' and expect
+     it to be signed, or expect it to be unsigned, depending on the
+     machines they were written for.  This option, and its inverse, let
+     you make such a program work with the opposite default.
+
+     The type 'char' is always a distinct type from each of 'signed
+     char' or 'unsigned char', even though its behavior is always just
+     like one of those two.
+
+'-fsigned-char'
+     Let the type 'char' be signed, like 'signed char'.
+
+     Note that this is equivalent to '-fno-unsigned-char', which is the
+     negative form of '-funsigned-char'.  Likewise, the option
+     '-fno-signed-char' is equivalent to '-funsigned-char'.
+
+'-fsigned-bitfields'
+'-funsigned-bitfields'
+'-fno-signed-bitfields'
+'-fno-unsigned-bitfields'
+     These options control whether a bit-field is signed or unsigned,
+     when the declaration does not use either 'signed' or 'unsigned'.
+     By default, such a bit-field is signed, because this is consistent:
+     the basic integer types such as 'int' are signed types.
+
+
+File: gcc.info,  Node: C++ Dialect Options,  Next: Objective-C and Objective-C++ Dialect Options,  Prev: C Dialect Options,  Up: Invoking GCC
+
+3.5 Options Controlling C++ Dialect
+===================================
+
+This section describes the command-line options that are only meaningful
+for C++ programs.  You can also use most of the GNU compiler options
+regardless of what language your program is in.  For example, you might
+compile a file 'firstClass.C' like this:
+
+     g++ -g -frepo -O -c firstClass.C
+
+In this example, only '-frepo' is an option meant only for C++ programs;
+you can use the other options with any language supported by GCC.
+
+ Here is a list of options that are _only_ for compiling C++ programs:
+
+'-fabi-version=N'
+     Use version N of the C++ ABI.  The default is version 2.
+
+     Version 0 refers to the version conforming most closely to the C++
+     ABI specification.  Therefore, the ABI obtained using version 0
+     will change in different versions of G++ as ABI bugs are fixed.
+
+     Version 1 is the version of the C++ ABI that first appeared in G++
+     3.2.
+
+     Version 2 is the version of the C++ ABI that first appeared in G++
+     3.4.
+
+     Version 3 corrects an error in mangling a constant address as a
+     template argument.
+
+     Version 4, which first appeared in G++ 4.5, implements a standard
+     mangling for vector types.
+
+     Version 5, which first appeared in G++ 4.6, corrects the mangling
+     of attribute const/volatile on function pointer types, decltype of
+     a plain decl, and use of a function parameter in the declaration of
+     another parameter.
+
+     Version 6, which first appeared in G++ 4.7, corrects the promotion
+     behavior of C++11 scoped enums and the mangling of template
+     argument packs, const/static_cast, prefix ++ and -, and a class
+     scope function used as a template argument.
+
+     See also '-Wabi'.
+
+'-fno-access-control'
+     Turn off all access checking.  This switch is mainly useful for
+     working around bugs in the access control code.
+
+'-fcheck-new'
+     Check that the pointer returned by 'operator new' is non-null
+     before attempting to modify the storage allocated.  This check is
+     normally unnecessary because the C++ standard specifies that
+     'operator new' only returns '0' if it is declared 'throw()', in
+     which case the compiler always checks the return value even without
+     this option.  In all other cases, when 'operator new' has a
+     non-empty exception specification, memory exhaustion is signalled
+     by throwing 'std::bad_alloc'.  See also 'new (nothrow)'.
+
+'-fconstexpr-depth=N'
+     Set the maximum nested evaluation depth for C++11 constexpr
+     functions to N.  A limit is needed to detect endless recursion
+     during constant expression evaluation.  The minimum specified by
+     the standard is 512.
+
+'-fdeduce-init-list'
+     Enable deduction of a template type parameter as
+     'std::initializer_list' from a brace-enclosed initializer list,
+     i.e.
+
+          template <class T> auto forward(T t) -> decltype (realfn (t))
+          {
+            return realfn (t);
+          }
+
+          void f()
+          {
+            forward({1,2}); // call forward<std::initializer_list<int>>
+          }
+
+     This deduction was implemented as a possible extension to the
+     originally proposed semantics for the C++11 standard, but was not
+     part of the final standard, so it is disabled by default.  This
+     option is deprecated, and may be removed in a future version of
+     G++.
+
+'-ffriend-injection'
+     Inject friend functions into the enclosing namespace, so that they
+     are visible outside the scope of the class in which they are
+     declared.  Friend functions were documented to work this way in the
+     old Annotated C++ Reference Manual, and versions of G++ before 4.1
+     always worked that way.  However, in ISO C++ a friend function that
+     is not declared in an enclosing scope can only be found using
+     argument dependent lookup.  This option causes friends to be
+     injected as they were in earlier releases.
+
+     This option is for compatibility, and may be removed in a future
+     release of G++.
+
+'-fno-elide-constructors'
+     The C++ standard allows an implementation to omit creating a
+     temporary that is only used to initialize another object of the
+     same type.  Specifying this option disables that optimization, and
+     forces G++ to call the copy constructor in all cases.
+
+'-fno-enforce-eh-specs'
+     Don't generate code to check for violation of exception
+     specifications at run time.  This option violates the C++ standard,
+     but may be useful for reducing code size in production builds, much
+     like defining 'NDEBUG'.  This does not give user code permission to
+     throw exceptions in violation of the exception specifications; the
+     compiler still optimizes based on the specifications, so throwing
+     an unexpected exception results in undefined behavior at run time.
+
+'-fextern-tls-init'
+'-fno-extern-tls-init'
+     The C++11 and OpenMP standards allow 'thread_local' and
+     'threadprivate' variables to have dynamic (runtime) initialization.
+     To support this, any use of such a variable goes through a wrapper
+     function that performs any necessary initialization.  When the use
+     and definition of the variable are in the same translation unit,
+     this overhead can be optimized away, but when the use is in a
+     different translation unit there is significant overhead even if
+     the variable doesn't actually need dynamic initialization.  If the
+     programmer can be sure that no use of the variable in a
+     non-defining TU needs to trigger dynamic initialization (either
+     because the variable is statically initialized, or a use of the
+     variable in the defining TU will be executed before any uses in
+     another TU), they can avoid this overhead with the
+     '-fno-extern-tls-init' option.
+
+     On targets that support symbol aliases, the default is
+     '-fextern-tls-init'.  On targets that do not support symbol
+     aliases, the default is '-fno-extern-tls-init'.
+
+'-ffor-scope'
+'-fno-for-scope'
+     If '-ffor-scope' is specified, the scope of variables declared in a
+     for-init-statement is limited to the 'for' loop itself, as
+     specified by the C++ standard.  If '-fno-for-scope' is specified,
+     the scope of variables declared in a for-init-statement extends to
+     the end of the enclosing scope, as was the case in old versions of
+     G++, and other (traditional) implementations of C++.
+
+     If neither flag is given, the default is to follow the standard,
+     but to allow and give a warning for old-style code that would
+     otherwise be invalid, or have different behavior.
+
+'-fno-gnu-keywords'
+     Do not recognize 'typeof' as a keyword, so that code can use this
+     word as an identifier.  You can use the keyword '__typeof__'
+     instead.  '-ansi' implies '-fno-gnu-keywords'.
+
+'-fno-implicit-templates'
+     Never emit code for non-inline templates that are instantiated
+     implicitly (i.e. by use); only emit code for explicit
+     instantiations.  *Note Template Instantiation::, for more
+     information.
+
+'-fno-implicit-inline-templates'
+     Don't emit code for implicit instantiations of inline templates,
+     either.  The default is to handle inlines differently so that
+     compiles with and without optimization need the same set of
+     explicit instantiations.
+
+'-fno-implement-inlines'
+     To save space, do not emit out-of-line copies of inline functions
+     controlled by '#pragma implementation'.  This causes linker errors
+     if these functions are not inlined everywhere they are called.
+
+'-fms-extensions'
+     Disable Wpedantic warnings about constructs used in MFC, such as
+     implicit int and getting a pointer to member function via
+     non-standard syntax.
+
+'-fno-nonansi-builtins'
+     Disable built-in declarations of functions that are not mandated by
+     ANSI/ISO C.  These include 'ffs', 'alloca', '_exit', 'index',
+     'bzero', 'conjf', and other related functions.
+
+'-fnothrow-opt'
+     Treat a 'throw()' exception specification as if it were a
+     'noexcept' specification to reduce or eliminate the text size
+     overhead relative to a function with no exception specification.
+     If the function has local variables of types with non-trivial
+     destructors, the exception specification actually makes the
+     function smaller because the EH cleanups for those variables can be
+     optimized away.  The semantic effect is that an exception thrown
+     out of a function with such an exception specification results in a
+     call to 'terminate' rather than 'unexpected'.
+
+'-fno-operator-names'
+     Do not treat the operator name keywords 'and', 'bitand', 'bitor',
+     'compl', 'not', 'or' and 'xor' as synonyms as keywords.
+
+'-fno-optional-diags'
+     Disable diagnostics that the standard says a compiler does not need
+     to issue.  Currently, the only such diagnostic issued by G++ is the
+     one for a name having multiple meanings within a class.
+
+'-fpermissive'
+     Downgrade some diagnostics about nonconformant code from errors to
+     warnings.  Thus, using '-fpermissive' allows some nonconforming
+     code to compile.
+
+'-fno-pretty-templates'
+     When an error message refers to a specialization of a function
+     template, the compiler normally prints the signature of the
+     template followed by the template arguments and any typedefs or
+     typenames in the signature (e.g.  'void f(T) [with T = int]' rather
+     than 'void f(int)') so that it's clear which template is involved.
+     When an error message refers to a specialization of a class
+     template, the compiler omits any template arguments that match the
+     default template arguments for that template.  If either of these
+     behaviors make it harder to understand the error message rather
+     than easier, you can use '-fno-pretty-templates' to disable them.
+
+'-frepo'
+     Enable automatic template instantiation at link time.  This option
+     also implies '-fno-implicit-templates'.  *Note Template
+     Instantiation::, for more information.
+
+'-fno-rtti'
+     Disable generation of information about every class with virtual
+     functions for use by the C++ run-time type identification features
+     ('dynamic_cast' and 'typeid').  If you don't use those parts of the
+     language, you can save some space by using this flag.  Note that
+     exception handling uses the same information, but G++ generates it
+     as needed.  The 'dynamic_cast' operator can still be used for casts
+     that do not require run-time type information, i.e. casts to 'void
+     *' or to unambiguous base classes.
+
+'-fstats'
+     Emit statistics about front-end processing at the end of the
+     compilation.  This information is generally only useful to the G++
+     development team.
+
+'-fstrict-enums'
+     Allow the compiler to optimize using the assumption that a value of
+     enumerated type can only be one of the values of the enumeration
+     (as defined in the C++ standard; basically, a value that can be
+     represented in the minimum number of bits needed to represent all
+     the enumerators).  This assumption may not be valid if the program
+     uses a cast to convert an arbitrary integer value to the enumerated
+     type.
+
+'-ftemplate-backtrace-limit=N'
+     Set the maximum number of template instantiation notes for a single
+     warning or error to N.  The default value is 10.
+
+'-ftemplate-depth=N'
+     Set the maximum instantiation depth for template classes to N.  A
+     limit on the template instantiation depth is needed to detect
+     endless recursions during template class instantiation.  ANSI/ISO
+     C++ conforming programs must not rely on a maximum depth greater
+     than 17 (changed to 1024 in C++11).  The default value is 900, as
+     the compiler can run out of stack space before hitting 1024 in some
+     situations.
+
+'-fno-threadsafe-statics'
+     Do not emit the extra code to use the routines specified in the C++
+     ABI for thread-safe initialization of local statics.  You can use
+     this option to reduce code size slightly in code that doesn't need
+     to be thread-safe.
+
+'-fuse-cxa-atexit'
+     Register destructors for objects with static storage duration with
+     the '__cxa_atexit' function rather than the 'atexit' function.
+     This option is required for fully standards-compliant handling of
+     static destructors, but only works if your C library supports
+     '__cxa_atexit'.
+
+'-fno-use-cxa-get-exception-ptr'
+     Don't use the '__cxa_get_exception_ptr' runtime routine.  This
+     causes 'std::uncaught_exception' to be incorrect, but is necessary
+     if the runtime routine is not available.
+
+'-fvisibility-inlines-hidden'
+     This switch declares that the user does not attempt to compare
+     pointers to inline functions or methods where the addresses of the
+     two functions are taken in different shared objects.
+
+     The effect of this is that GCC may, effectively, mark inline
+     methods with '__attribute__ ((visibility ("hidden")))' so that they
+     do not appear in the export table of a DSO and do not require a PLT
+     indirection when used within the DSO.  Enabling this option can
+     have a dramatic effect on load and link times of a DSO as it
+     massively reduces the size of the dynamic export table when the
+     library makes heavy use of templates.
+
+     The behavior of this switch is not quite the same as marking the
+     methods as hidden directly, because it does not affect static
+     variables local to the function or cause the compiler to deduce
+     that the function is defined in only one shared object.
+
+     You may mark a method as having a visibility explicitly to negate
+     the effect of the switch for that method.  For example, if you do
+     want to compare pointers to a particular inline method, you might
+     mark it as having default visibility.  Marking the enclosing class
+     with explicit visibility has no effect.
+
+     Explicitly instantiated inline methods are unaffected by this
+     option as their linkage might otherwise cross a shared library
+     boundary.  *Note Template Instantiation::.
+
+'-fvisibility-ms-compat'
+     This flag attempts to use visibility settings to make GCC's C++
+     linkage model compatible with that of Microsoft Visual Studio.
+
+     The flag makes these changes to GCC's linkage model:
+
+       1. It sets the default visibility to 'hidden', like
+          '-fvisibility=hidden'.
+
+       2. Types, but not their members, are not hidden by default.
+
+       3. The One Definition Rule is relaxed for types without explicit
+          visibility specifications that are defined in more than one
+          shared object: those declarations are permitted if they are
+          permitted when this option is not used.
+
+     In new code it is better to use '-fvisibility=hidden' and export
+     those classes that are intended to be externally visible.
+     Unfortunately it is possible for code to rely, perhaps
+     accidentally, on the Visual Studio behavior.
+
+     Among the consequences of these changes are that static data
+     members of the same type with the same name but defined in
+     different shared objects are different, so changing one does not
+     change the other; and that pointers to function members defined in
+     different shared objects may not compare equal.  When this flag is
+     given, it is a violation of the ODR to define types with the same
+     name differently.
+
+'-fvtable-verify=STD|PREINIT|NONE'
+     Turn on (or off, if using '-fvtable-verify=none') the security
+     feature that verifies at runtime, for every virtual call that is
+     made, that the vtable pointer through which the call is made is
+     valid for the type of the object, and has not been corrupted or
+     overwritten.  If an invalid vtable pointer is detected (at
+     runtime), an error is reported and execution of the program is
+     immediately halted.
+
+     This option causes runtime data structures to be built, at program
+     start up, for verifying the vtable pointers.  The options 'std' and
+     'preinit' control the timing of when these data structures are
+     built.  In both cases the data structures are built before
+     execution reaches 'main'.  The '-fvtable-verify=std' causes these
+     data structure to be built after the shared libraries have been
+     loaded and initialized.  '-fvtable-verify=preinit' causes them to
+     be built before the shared libraries have been loaded and
+     initialized.
+
+     If this option appears multiple times in the compiler line, with
+     different values specified, 'none' will take highest priority over
+     both 'std' and 'preinit'; 'preinit' will take priority over 'std'.
+
+'-fvtv-debug'
+     Causes debug versions of the runtime functions for the vtable
+     verification feature to be called.  This assumes the
+     '-fvtable-verify=std' or '-fvtable-verify=preinit' has been used.
+     This flag will also cause the compiler to keep track of which
+     vtable pointers it found for each class, and record that
+     information in the file "vtv_set_ptr_data.log", in the dump file
+     directory on the user's machine.
+
+     Note: This feature APPENDS data to the log file.  If you want a
+     fresh log file, be sure to delete any existing one.
+
+'-fvtv-counts'
+     This is a debugging flag.  When used in conjunction with
+     '-fvtable-verify=std' or '-fvtable-verify=preinit', this causes the
+     compiler to keep track of the total number of virtual calls it
+     encountered and the number of verifications it inserted.  It also
+     counts the number of calls to certain runtime library functions
+     that it inserts.  This information, for each compilation unit, is
+     written to a file named "vtv_count_data.log", in the dump_file
+     directory on the user's machine.  It also counts the size of the
+     vtable pointer sets for each class, and writes this information to
+     "vtv_class_set_sizes.log" in the same directory.
+
+     Note: This feature APPENDS data to the log files.  To get a fresh
+     log files, be sure to delete any existing ones.
+
+'-fno-weak'
+     Do not use weak symbol support, even if it is provided by the
+     linker.  By default, G++ uses weak symbols if they are available.
+     This option exists only for testing, and should not be used by
+     end-users; it results in inferior code and has no benefits.  This
+     option may be removed in a future release of G++.
+
+'-nostdinc++'
+     Do not search for header files in the standard directories specific
+     to C++, but do still search the other standard directories.  (This
+     option is used when building the C++ library.)
+
+ In addition, these optimization, warning, and code generation options
+have meanings only for C++ programs:
+
+'-Wabi (C, Objective-C, C++ and Objective-C++ only)'
+     Warn when G++ generates code that is probably not compatible with
+     the vendor-neutral C++ ABI.  Although an effort has been made to
+     warn about all such cases, there are probably some cases that are
+     not warned about, even though G++ is generating incompatible code.
+     There may also be cases where warnings are emitted even though the
+     code that is generated is compatible.
+
+     You should rewrite your code to avoid these warnings if you are
+     concerned about the fact that code generated by G++ may not be
+     binary compatible with code generated by other compilers.
+
+     The known incompatibilities in '-fabi-version=2' (the default)
+     include:
+
+        * A template with a non-type template parameter of reference
+          type is mangled incorrectly:
+               extern int N;
+               template <int &> struct S {};
+               void n (S<N>) {2}
+
+          This is fixed in '-fabi-version=3'.
+
+        * SIMD vector types declared using '__attribute ((vector_size))'
+          are mangled in a non-standard way that does not allow for
+          overloading of functions taking vectors of different sizes.
+
+          The mangling is changed in '-fabi-version=4'.
+
+     The known incompatibilities in '-fabi-version=1' include:
+
+        * Incorrect handling of tail-padding for bit-fields.  G++ may
+          attempt to pack data into the same byte as a base class.  For
+          example:
+
+               struct A { virtual void f(); int f1 : 1; };
+               struct B : public A { int f2 : 1; };
+
+          In this case, G++ places 'B::f2' into the same byte as
+          'A::f1'; other compilers do not.  You can avoid this problem
+          by explicitly padding 'A' so that its size is a multiple of
+          the byte size on your platform; that causes G++ and other
+          compilers to lay out 'B' identically.
+
+        * Incorrect handling of tail-padding for virtual bases.  G++
+          does not use tail padding when laying out virtual bases.  For
+          example:
+
+               struct A { virtual void f(); char c1; };
+               struct B { B(); char c2; };
+               struct C : public A, public virtual B {};
+
+          In this case, G++ does not place 'B' into the tail-padding for
+          'A'; other compilers do.  You can avoid this problem by
+          explicitly padding 'A' so that its size is a multiple of its
+          alignment (ignoring virtual base classes); that causes G++ and
+          other compilers to lay out 'C' identically.
+
+        * Incorrect handling of bit-fields with declared widths greater
+          than that of their underlying types, when the bit-fields
+          appear in a union.  For example:
+
+               union U { int i : 4096; };
+
+          Assuming that an 'int' does not have 4096 bits, G++ makes the
+          union too small by the number of bits in an 'int'.
+
+        * Empty classes can be placed at incorrect offsets.  For
+          example:
+
+               struct A {};
+
+               struct B {
+                 A a;
+                 virtual void f ();
+               };
+
+               struct C : public B, public A {};
+
+          G++ places the 'A' base class of 'C' at a nonzero offset; it
+          should be placed at offset zero.  G++ mistakenly believes that
+          the 'A' data member of 'B' is already at offset zero.
+
+        * Names of template functions whose types involve 'typename' or
+          template template parameters can be mangled incorrectly.
+
+               template <typename Q>
+               void f(typename Q::X) {}
+
+               template <template <typename> class Q>
+               void f(typename Q<int>::X) {}
+
+          Instantiations of these templates may be mangled incorrectly.
+
+     It also warns about psABI-related changes.  The known psABI changes
+     at this point include:
+
+        * For SysV/x86-64, unions with 'long double' members are passed
+          in memory as specified in psABI. For example:
+
+               union U {
+                 long double ld;
+                 int i;
+               };
+
+          'union U' is always passed in memory.
+
+'-Wctor-dtor-privacy (C++ and Objective-C++ only)'
+     Warn when a class seems unusable because all the constructors or
+     destructors in that class are private, and it has neither friends
+     nor public static member functions.  Also warn if there are no
+     non-private methods, and there's at least one private member
+     function that isn't a constructor or destructor.
+
+'-Wdelete-non-virtual-dtor (C++ and Objective-C++ only)'
+     Warn when 'delete' is used to destroy an instance of a class that
+     has virtual functions and non-virtual destructor.  It is unsafe to
+     delete an instance of a derived class through a pointer to a base
+     class if the base class does not have a virtual destructor.  This
+     warning is enabled by '-Wall'.
+
+'-Wliteral-suffix (C++ and Objective-C++ only)'
+     Warn when a string or character literal is followed by a ud-suffix
+     which does not begin with an underscore.  As a conforming
+     extension, GCC treats such suffixes as separate preprocessing
+     tokens in order to maintain backwards compatibility with code that
+     uses formatting macros from '<inttypes.h>'.  For example:
+
+          #define __STDC_FORMAT_MACROS
+          #include <inttypes.h>
+          #include <stdio.h>
+
+          int main() {
+            int64_t i64 = 123;
+            printf("My int64: %"PRId64"\n", i64);
+          }
+
+     In this case, 'PRId64' is treated as a separate preprocessing
+     token.
+
+     This warning is enabled by default.
+
+'-Wnarrowing (C++ and Objective-C++ only)'
+     Warn when a narrowing conversion prohibited by C++11 occurs within
+     '{ }', e.g.
+
+          int i = { 2.2 }; // error: narrowing from double to int
+
+     This flag is included in '-Wall' and '-Wc++11-compat'.
+
+     With '-std=c++11', '-Wno-narrowing' suppresses the diagnostic
+     required by the standard.  Note that this does not affect the
+     meaning of well-formed code; narrowing conversions are still
+     considered ill-formed in SFINAE context.
+
+'-Wnoexcept (C++ and Objective-C++ only)'
+     Warn when a noexcept-expression evaluates to false because of a
+     call to a function that does not have a non-throwing exception
+     specification (i.e.  'throw()' or 'noexcept') but is known by the
+     compiler to never throw an exception.
+
+'-Wnon-virtual-dtor (C++ and Objective-C++ only)'
+     Warn when a class has virtual functions and an accessible
+     non-virtual destructor itself or in an accessible polymorphic base
+     class, in which case it is possible but unsafe to delete an
+     instance of a derived class through a pointer to the class itself
+     or base class.  This warning is automatically enabled if '-Weffc++'
+     is specified.
+
+'-Wreorder (C++ and Objective-C++ only)'
+     Warn when the order of member initializers given in the code does
+     not match the order in which they must be executed.  For instance:
+
+          struct A {
+            int i;
+            int j;
+            A(): j (0), i (1) { }
+          };
+
+     The compiler rearranges the member initializers for 'i' and 'j' to
+     match the declaration order of the members, emitting a warning to
+     that effect.  This warning is enabled by '-Wall'.
+
+'-fext-numeric-literals (C++ and Objective-C++ only)'
+     Accept imaginary, fixed-point, or machine-defined literal number
+     suffixes as GNU extensions.  When this option is turned off these
+     suffixes are treated as C++11 user-defined literal numeric
+     suffixes.  This is on by default for all pre-C++11 dialects and all
+     GNU dialects: '-std=c++98', '-std=gnu++98', '-std=gnu++11',
+     '-std=gnu++1y'.  This option is off by default for ISO C++11
+     onwards ('-std=c++11', ...).
+
+ The following '-W...' options are not affected by '-Wall'.
+
+'-Weffc++ (C++ and Objective-C++ only)'
+     Warn about violations of the following style guidelines from Scott
+     Meyers' 'Effective C++' series of books:
+
+        * Define a copy constructor and an assignment operator for
+          classes with dynamically-allocated memory.
+
+        * Prefer initialization to assignment in constructors.
+
+        * Have 'operator=' return a reference to '*this'.
+
+        * Don't try to return a reference when you must return an
+          object.
+
+        * Distinguish between prefix and postfix forms of increment and
+          decrement operators.
+
+        * Never overload '&&', '||', or ','.
+
+     This option also enables '-Wnon-virtual-dtor', which is also one of
+     the effective C++ recommendations.  However, the check is extended
+     to warn about the lack of virtual destructor in accessible
+     non-polymorphic bases classes too.
+
+     When selecting this option, be aware that the standard library
+     headers do not obey all of these guidelines; use 'grep -v' to
+     filter out those warnings.
+
+'-Wstrict-null-sentinel (C++ and Objective-C++ only)'
+     Warn about the use of an uncasted 'NULL' as sentinel.  When
+     compiling only with GCC this is a valid sentinel, as 'NULL' is
+     defined to '__null'.  Although it is a null pointer constant rather
+     than a null pointer, it is guaranteed to be of the same size as a
+     pointer.  But this use is not portable across different compilers.
+
+'-Wno-non-template-friend (C++ and Objective-C++ only)'
+     Disable warnings when non-templatized friend functions are declared
+     within a template.  Since the advent of explicit template
+     specification support in G++, if the name of the friend is an
+     unqualified-id (i.e., 'friend foo(int)'), the C++ language
+     specification demands that the friend declare or define an
+     ordinary, nontemplate function.  (Section 14.5.3).  Before G++
+     implemented explicit specification, unqualified-ids could be
+     interpreted as a particular specialization of a templatized
+     function.  Because this non-conforming behavior is no longer the
+     default behavior for G++, '-Wnon-template-friend' allows the
+     compiler to check existing code for potential trouble spots and is
+     on by default.  This new compiler behavior can be turned off with
+     '-Wno-non-template-friend', which keeps the conformant compiler
+     code but disables the helpful warning.
+
+'-Wold-style-cast (C++ and Objective-C++ only)'
+     Warn if an old-style (C-style) cast to a non-void type is used
+     within a C++ program.  The new-style casts ('dynamic_cast',
+     'static_cast', 'reinterpret_cast', and 'const_cast') are less
+     vulnerable to unintended effects and much easier to search for.
+
+'-Woverloaded-virtual (C++ and Objective-C++ only)'
+     Warn when a function declaration hides virtual functions from a
+     base class.  For example, in:
+
+          struct A {
+            virtual void f();
+          };
+
+          struct B: public A {
+            void f(int);
+          };
+
+     the 'A' class version of 'f' is hidden in 'B', and code like:
+
+          B* b;
+          b->f();
+
+     fails to compile.
+
+'-Wno-pmf-conversions (C++ and Objective-C++ only)'
+     Disable the diagnostic for converting a bound pointer to member
+     function to a plain pointer.
+
+'-Wsign-promo (C++ and Objective-C++ only)'
+     Warn when overload resolution chooses a promotion from unsigned or
+     enumerated type to a signed type, over a conversion to an unsigned
+     type of the same size.  Previous versions of G++ tried to preserve
+     unsignedness, but the standard mandates the current behavior.
+
+
+File: gcc.info,  Node: Objective-C and Objective-C++ Dialect Options,  Next: Language Independent Options,  Prev: C++ Dialect Options,  Up: Invoking GCC
+
+3.6 Options Controlling Objective-C and Objective-C++ Dialects
+==============================================================
+
+(NOTE: This manual does not describe the Objective-C and Objective-C++
+languages themselves.  *Note Language Standards Supported by GCC:
+Standards, for references.)
+
+ This section describes the command-line options that are only
+meaningful for Objective-C and Objective-C++ programs.  You can also use
+most of the language-independent GNU compiler options.  For example, you
+might compile a file 'some_class.m' like this:
+
+     gcc -g -fgnu-runtime -O -c some_class.m
+
+In this example, '-fgnu-runtime' is an option meant only for Objective-C
+and Objective-C++ programs; you can use the other options with any
+language supported by GCC.
+
+ Note that since Objective-C is an extension of the C language,
+Objective-C compilations may also use options specific to the C
+front-end (e.g., '-Wtraditional').  Similarly, Objective-C++
+compilations may use C++-specific options (e.g., '-Wabi').
+
+ Here is a list of options that are _only_ for compiling Objective-C and
+Objective-C++ programs:
+
+'-fconstant-string-class=CLASS-NAME'
+     Use CLASS-NAME as the name of the class to instantiate for each
+     literal string specified with the syntax '@"..."'.  The default
+     class name is 'NXConstantString' if the GNU runtime is being used,
+     and 'NSConstantString' if the NeXT runtime is being used (see
+     below).  The '-fconstant-cfstrings' option, if also present,
+     overrides the '-fconstant-string-class' setting and cause '@"..."'
+     literals to be laid out as constant CoreFoundation strings.
+
+'-fgnu-runtime'
+     Generate object code compatible with the standard GNU Objective-C
+     runtime.  This is the default for most types of systems.
+
+'-fnext-runtime'
+     Generate output compatible with the NeXT runtime.  This is the
+     default for NeXT-based systems, including Darwin and Mac OS X.  The
+     macro '__NEXT_RUNTIME__' is predefined if (and only if) this option
+     is used.
+
+'-fno-nil-receivers'
+     Assume that all Objective-C message dispatches ('[receiver
+     message:arg]') in this translation unit ensure that the receiver is
+     not 'nil'.  This allows for more efficient entry points in the
+     runtime to be used.  This option is only available in conjunction
+     with the NeXT runtime and ABI version 0 or 1.
+
+'-fobjc-abi-version=N'
+     Use version N of the Objective-C ABI for the selected runtime.
+     This option is currently supported only for the NeXT runtime.  In
+     that case, Version 0 is the traditional (32-bit) ABI without
+     support for properties and other Objective-C 2.0 additions.
+     Version 1 is the traditional (32-bit) ABI with support for
+     properties and other Objective-C 2.0 additions.  Version 2 is the
+     modern (64-bit) ABI. If nothing is specified, the default is
+     Version 0 on 32-bit target machines, and Version 2 on 64-bit target
+     machines.
+
+'-fobjc-call-cxx-cdtors'
+     For each Objective-C class, check if any of its instance variables
+     is a C++ object with a non-trivial default constructor.  If so,
+     synthesize a special '- (id) .cxx_construct' instance method which
+     runs non-trivial default constructors on any such instance
+     variables, in order, and then return 'self'.  Similarly, check if
+     any instance variable is a C++ object with a non-trivial
+     destructor, and if so, synthesize a special '- (void)
+     .cxx_destruct' method which runs all such default destructors, in
+     reverse order.
+
+     The '- (id) .cxx_construct' and '- (void) .cxx_destruct' methods
+     thusly generated only operate on instance variables declared in the
+     current Objective-C class, and not those inherited from
+     superclasses.  It is the responsibility of the Objective-C runtime
+     to invoke all such methods in an object's inheritance hierarchy.
+     The '- (id) .cxx_construct' methods are invoked by the runtime
+     immediately after a new object instance is allocated; the '- (void)
+     .cxx_destruct' methods are invoked immediately before the runtime
+     deallocates an object instance.
+
+     As of this writing, only the NeXT runtime on Mac OS X 10.4 and
+     later has support for invoking the '- (id) .cxx_construct' and '-
+     (void) .cxx_destruct' methods.
+
+'-fobjc-direct-dispatch'
+     Allow fast jumps to the message dispatcher.  On Darwin this is
+     accomplished via the comm page.
+
+'-fobjc-exceptions'
+     Enable syntactic support for structured exception handling in
+     Objective-C, similar to what is offered by C++ and Java.  This
+     option is required to use the Objective-C keywords '@try',
+     '@throw', '@catch', '@finally' and '@synchronized'.  This option is
+     available with both the GNU runtime and the NeXT runtime (but not
+     available in conjunction with the NeXT runtime on Mac OS X 10.2 and
+     earlier).
+
+'-fobjc-gc'
+     Enable garbage collection (GC) in Objective-C and Objective-C++
+     programs.  This option is only available with the NeXT runtime; the
+     GNU runtime has a different garbage collection implementation that
+     does not require special compiler flags.
+
+'-fobjc-nilcheck'
+     For the NeXT runtime with version 2 of the ABI, check for a nil
+     receiver in method invocations before doing the actual method call.
+     This is the default and can be disabled using '-fno-objc-nilcheck'.
+     Class methods and super calls are never checked for nil in this way
+     no matter what this flag is set to.  Currently this flag does
+     nothing when the GNU runtime, or an older version of the NeXT
+     runtime ABI, is used.
+
+'-fobjc-std=objc1'
+     Conform to the language syntax of Objective-C 1.0, the language
+     recognized by GCC 4.0.  This only affects the Objective-C additions
+     to the C/C++ language; it does not affect conformance to C/C++
+     standards, which is controlled by the separate C/C++ dialect option
+     flags.  When this option is used with the Objective-C or
+     Objective-C++ compiler, any Objective-C syntax that is not
+     recognized by GCC 4.0 is rejected.  This is useful if you need to
+     make sure that your Objective-C code can be compiled with older
+     versions of GCC.
+
+'-freplace-objc-classes'
+     Emit a special marker instructing 'ld(1)' not to statically link in
+     the resulting object file, and allow 'dyld(1)' to load it in at run
+     time instead.  This is used in conjunction with the
+     Fix-and-Continue debugging mode, where the object file in question
+     may be recompiled and dynamically reloaded in the course of program
+     execution, without the need to restart the program itself.
+     Currently, Fix-and-Continue functionality is only available in
+     conjunction with the NeXT runtime on Mac OS X 10.3 and later.
+
+'-fzero-link'
+     When compiling for the NeXT runtime, the compiler ordinarily
+     replaces calls to 'objc_getClass("...")' (when the name of the
+     class is known at compile time) with static class references that
+     get initialized at load time, which improves run-time performance.
+     Specifying the '-fzero-link' flag suppresses this behavior and
+     causes calls to 'objc_getClass("...")' to be retained.  This is
+     useful in Zero-Link debugging mode, since it allows for individual
+     class implementations to be modified during program execution.  The
+     GNU runtime currently always retains calls to
+     'objc_get_class("...")' regardless of command-line options.
+
+'-gen-decls'
+     Dump interface declarations for all classes seen in the source file
+     to a file named 'SOURCENAME.decl'.
+
+'-Wassign-intercept (Objective-C and Objective-C++ only)'
+     Warn whenever an Objective-C assignment is being intercepted by the
+     garbage collector.
+
+'-Wno-protocol (Objective-C and Objective-C++ only)'
+     If a class is declared to implement a protocol, a warning is issued
+     for every method in the protocol that is not implemented by the
+     class.  The default behavior is to issue a warning for every method
+     not explicitly implemented in the class, even if a method
+     implementation is inherited from the superclass.  If you use the
+     '-Wno-protocol' option, then methods inherited from the superclass
+     are considered to be implemented, and no warning is issued for
+     them.
+
+'-Wselector (Objective-C and Objective-C++ only)'
+     Warn if multiple methods of different types for the same selector
+     are found during compilation.  The check is performed on the list
+     of methods in the final stage of compilation.  Additionally, a
+     check is performed for each selector appearing in a
+     '@selector(...)' expression, and a corresponding method for that
+     selector has been found during compilation.  Because these checks
+     scan the method table only at the end of compilation, these
+     warnings are not produced if the final stage of compilation is not
+     reached, for example because an error is found during compilation,
+     or because the '-fsyntax-only' option is being used.
+
+'-Wstrict-selector-match (Objective-C and Objective-C++ only)'
+     Warn if multiple methods with differing argument and/or return
+     types are found for a given selector when attempting to send a
+     message using this selector to a receiver of type 'id' or 'Class'.
+     When this flag is off (which is the default behavior), the compiler
+     omits such warnings if any differences found are confined to types
+     that share the same size and alignment.
+
+'-Wundeclared-selector (Objective-C and Objective-C++ only)'
+     Warn if a '@selector(...)' expression referring to an undeclared
+     selector is found.  A selector is considered undeclared if no
+     method with that name has been declared before the '@selector(...)'
+     expression, either explicitly in an '@interface' or '@protocol'
+     declaration, or implicitly in an '@implementation' section.  This
+     option always performs its checks as soon as a '@selector(...)'
+     expression is found, while '-Wselector' only performs its checks in
+     the final stage of compilation.  This also enforces the coding
+     style convention that methods and selectors must be declared before
+     being used.
+
+'-print-objc-runtime-info'
+     Generate C header describing the largest structure that is passed
+     by value, if any.
+
+
+File: gcc.info,  Node: Language Independent Options,  Next: Warning Options,  Prev: Objective-C and Objective-C++ Dialect Options,  Up: Invoking GCC
+
+3.7 Options to Control Diagnostic Messages Formatting
+=====================================================
+
+Traditionally, diagnostic messages have been formatted irrespective of
+the output device's aspect (e.g. its width, ...).  You can use the
+options described below to control the formatting algorithm for
+diagnostic messages, e.g. how many characters per line, how often source
+location information should be reported.  Note that some language front
+ends may not honor these options.
+
+'-fmessage-length=N'
+     Try to format error messages so that they fit on lines of about N
+     characters.  The default is 72 characters for 'g++' and 0 for the
+     rest of the front ends supported by GCC.  If N is zero, then no
+     line-wrapping is done; each error message appears on a single line.
+
+'-fdiagnostics-show-location=once'
+     Only meaningful in line-wrapping mode.  Instructs the diagnostic
+     messages reporter to emit source location information _once_; that
+     is, in case the message is too long to fit on a single physical
+     line and has to be wrapped, the source location won't be emitted
+     (as prefix) again, over and over, in subsequent continuation lines.
+     This is the default behavior.
+
+'-fdiagnostics-show-location=every-line'
+     Only meaningful in line-wrapping mode.  Instructs the diagnostic
+     messages reporter to emit the same source location information (as
+     prefix) for physical lines that result from the process of breaking
+     a message which is too long to fit on a single line.
+
+'-fdiagnostics-color[=WHEN]'
+'-fno-diagnostics-color'
+     Use color in diagnostics.  WHEN is 'never', 'always', or 'auto'.
+     The default is 'never' if 'GCC_COLORS' environment variable isn't
+     present in the environment, and 'auto' otherwise.  'auto' means to
+     use color only when the standard error is a terminal.  The forms
+     '-fdiagnostics-color' and '-fno-diagnostics-color' are aliases for
+     '-fdiagnostics-color=always' and '-fdiagnostics-color=never',
+     respectively.
+
+     The colors are defined by the environment variable 'GCC_COLORS'.
+     Its value is a colon-separated list of capabilities and Select
+     Graphic Rendition (SGR) substrings.  SGR commands are interpreted
+     by the terminal or terminal emulator.  (See the section in the
+     documentation of your text terminal for permitted values and their
+     meanings as character attributes.)  These substring values are
+     integers in decimal representation and can be concatenated with
+     semicolons.  Common values to concatenate include '1' for bold, '4'
+     for underline, '5' for blink, '7' for inverse, '39' for default
+     foreground color, '30' to '37' for foreground colors, '90' to '97'
+     for 16-color mode foreground colors, '38;5;0' to '38;5;255' for
+     88-color and 256-color modes foreground colors, '49' for default
+     background color, '40' to '47' for background colors, '100' to
+     '107' for 16-color mode background colors, and '48;5;0' to
+     '48;5;255' for 88-color and 256-color modes background colors.
+
+     The default 'GCC_COLORS' is
+     'error=01;31:warning=01;35:note=01;36:caret=01;32:locus=01:quote=01'
+     where '01;31' is bold red, '01;35' is bold magenta, '01;36' is bold
+     cyan, '01;32' is bold green and '01' is bold.  Setting 'GCC_COLORS'
+     to the empty string disables colors.  Supported capabilities are as
+     follows.
+
+     'error='
+          SGR substring for error: markers.
+
+     'warning='
+          SGR substring for warning: markers.
+
+     'note='
+          SGR substring for note: markers.
+
+     'caret='
+          SGR substring for caret line.
+
+     'locus='
+          SGR substring for location information, 'file:line' or
+          'file:line:column' etc.
+
+     'quote='
+          SGR substring for information printed within quotes.
+
+'-fno-diagnostics-show-option'
+     By default, each diagnostic emitted includes text indicating the
+     command-line option that directly controls the diagnostic (if such
+     an option is known to the diagnostic machinery).  Specifying the
+     '-fno-diagnostics-show-option' flag suppresses that behavior.
+
+'-fno-diagnostics-show-caret'
+     By default, each diagnostic emitted includes the original source
+     line and a caret '^' indicating the column.  This option suppresses
+     this information.
+
+
+File: gcc.info,  Node: Warning Options,  Next: Debugging Options,  Prev: Language Independent Options,  Up: Invoking GCC
+
+3.8 Options to Request or Suppress Warnings
+===========================================
+
+Warnings are diagnostic messages that report constructions that are not
+inherently erroneous but that are risky or suggest there may have been
+an error.
+
+ The following language-independent options do not enable specific
+warnings but control the kinds of diagnostics produced by GCC.
+
+'-fsyntax-only'
+     Check the code for syntax errors, but don't do anything beyond
+     that.
+
+'-fmax-errors=N'
+     Limits the maximum number of error messages to N, at which point
+     GCC bails out rather than attempting to continue processing the
+     source code.  If N is 0 (the default), there is no limit on the
+     number of error messages produced.  If '-Wfatal-errors' is also
+     specified, then '-Wfatal-errors' takes precedence over this option.
+
+'-w'
+     Inhibit all warning messages.
+
+'-Werror'
+     Make all warnings into errors.
+
+'-Werror='
+     Make the specified warning into an error.  The specifier for a
+     warning is appended; for example '-Werror=switch' turns the
+     warnings controlled by '-Wswitch' into errors.  This switch takes a
+     negative form, to be used to negate '-Werror' for specific
+     warnings; for example '-Wno-error=switch' makes '-Wswitch' warnings
+     not be errors, even when '-Werror' is in effect.
+
+     The warning message for each controllable warning includes the
+     option that controls the warning.  That option can then be used
+     with '-Werror=' and '-Wno-error=' as described above.  (Printing of
+     the option in the warning message can be disabled using the
+     '-fno-diagnostics-show-option' flag.)
+
+     Note that specifying '-Werror='FOO automatically implies '-W'FOO.
+     However, '-Wno-error='FOO does not imply anything.
+
+'-Wfatal-errors'
+     This option causes the compiler to abort compilation on the first
+     error occurred rather than trying to keep going and printing
+     further error messages.
+
+ You can request many specific warnings with options beginning with
+'-W', for example '-Wimplicit' to request warnings on implicit
+declarations.  Each of these specific warning options also has a
+negative form beginning '-Wno-' to turn off warnings; for example,
+'-Wno-implicit'.  This manual lists only one of the two forms, whichever
+is not the default.  For further language-specific options also refer to
+*note C++ Dialect Options:: and *note Objective-C and Objective-C++
+Dialect Options::.
+
+ When an unrecognized warning option is requested (e.g.,
+'-Wunknown-warning'), GCC emits a diagnostic stating that the option is
+not recognized.  However, if the '-Wno-' form is used, the behavior is
+slightly different: no diagnostic is produced for '-Wno-unknown-warning'
+unless other diagnostics are being produced.  This allows the use of new
+'-Wno-' options with old compilers, but if something goes wrong, the
+compiler warns that an unrecognized option is present.
+
+'-Wpedantic'
+'-pedantic'
+     Issue all the warnings demanded by strict ISO C and ISO C++; reject
+     all programs that use forbidden extensions, and some other programs
+     that do not follow ISO C and ISO C++.  For ISO C, follows the
+     version of the ISO C standard specified by any '-std' option used.
+
+     Valid ISO C and ISO C++ programs should compile properly with or
+     without this option (though a rare few require '-ansi' or a '-std'
+     option specifying the required version of ISO C).  However, without
+     this option, certain GNU extensions and traditional C and C++
+     features are supported as well.  With this option, they are
+     rejected.
+
+     '-Wpedantic' does not cause warning messages for use of the
+     alternate keywords whose names begin and end with '__'.  Pedantic
+     warnings are also disabled in the expression that follows
+     '__extension__'.  However, only system header files should use
+     these escape routes; application programs should avoid them.  *Note
+     Alternate Keywords::.
+
+     Some users try to use '-Wpedantic' to check programs for strict ISO
+     C conformance.  They soon find that it does not do quite what they
+     want: it finds some non-ISO practices, but not all--only those for
+     which ISO C _requires_ a diagnostic, and some others for which
+     diagnostics have been added.
+
+     A feature to report any failure to conform to ISO C might be useful
+     in some instances, but would require considerable additional work
+     and would be quite different from '-Wpedantic'.  We don't have
+     plans to support such a feature in the near future.
+
+     Where the standard specified with '-std' represents a GNU extended
+     dialect of C, such as 'gnu90' or 'gnu99', there is a corresponding
+     "base standard", the version of ISO C on which the GNU extended
+     dialect is based.  Warnings from '-Wpedantic' are given where they
+     are required by the base standard.  (It does not make sense for
+     such warnings to be given only for features not in the specified
+     GNU C dialect, since by definition the GNU dialects of C include
+     all features the compiler supports with the given option, and there
+     would be nothing to warn about.)
+
+'-pedantic-errors'
+     Like '-Wpedantic', except that errors are produced rather than
+     warnings.
+
+'-Wall'
+     This enables all the warnings about constructions that some users
+     consider questionable, and that are easy to avoid (or modify to
+     prevent the warning), even in conjunction with macros.  This also
+     enables some language-specific warnings described in *note C++
+     Dialect Options:: and *note Objective-C and Objective-C++ Dialect
+     Options::.
+
+     '-Wall' turns on the following warning flags:
+
+          -Waddress
+          -Warray-bounds (only with -O2)
+          -Wc++11-compat
+          -Wchar-subscripts
+          -Wenum-compare (in C/ObjC; this is on by default in C++)
+          -Wimplicit-int (C and Objective-C only)
+          -Wimplicit-function-declaration (C and Objective-C only)
+          -Wcomment
+          -Wformat
+          -Wmain (only for C/ObjC and unless -ffreestanding)
+          -Wmaybe-uninitialized
+          -Wmissing-braces (only for C/ObjC)
+          -Wnonnull
+          -Wopenmp-simd
+          -Wparentheses
+          -Wpointer-sign
+          -Wreorder
+          -Wreturn-type
+          -Wsequence-point
+          -Wsign-compare (only in C++)
+          -Wstrict-aliasing
+          -Wstrict-overflow=1
+          -Wswitch
+          -Wtrigraphs
+          -Wuninitialized
+          -Wunknown-pragmas
+          -Wunused-function
+          -Wunused-label
+          -Wunused-value
+          -Wunused-variable
+          -Wvolatile-register-var
+
+     Note that some warning flags are not implied by '-Wall'.  Some of
+     them warn about constructions that users generally do not consider
+     questionable, but which occasionally you might wish to check for;
+     others warn about constructions that are necessary or hard to avoid
+     in some cases, and there is no simple way to modify the code to
+     suppress the warning.  Some of them are enabled by '-Wextra' but
+     many of them must be enabled individually.
+
+'-Wextra'
+     This enables some extra warning flags that are not enabled by
+     '-Wall'.  (This option used to be called '-W'.  The older name is
+     still supported, but the newer name is more descriptive.)
+
+          -Wclobbered
+          -Wempty-body
+          -Wignored-qualifiers
+          -Wmissing-field-initializers
+          -Wmissing-parameter-type (C only)
+          -Wold-style-declaration (C only)
+          -Woverride-init
+          -Wsign-compare
+          -Wtype-limits
+          -Wuninitialized
+          -Wunused-parameter (only with -Wunused or -Wall)
+          -Wunused-but-set-parameter (only with -Wunused or -Wall)
+
+     The option '-Wextra' also prints warning messages for the following
+     cases:
+
+        * A pointer is compared against integer zero with '<', '<=',
+          '>', or '>='.
+
+        * (C++ only) An enumerator and a non-enumerator both appear in a
+          conditional expression.
+
+        * (C++ only) Ambiguous virtual bases.
+
+        * (C++ only) Subscripting an array that has been declared
+          'register'.
+
+        * (C++ only) Taking the address of a variable that has been
+          declared 'register'.
+
+        * (C++ only) A base class is not initialized in a derived
+          class's copy constructor.
+
+'-Wchar-subscripts'
+     Warn if an array subscript has type 'char'.  This is a common cause
+     of error, as programmers often forget that this type is signed on
+     some machines.  This warning is enabled by '-Wall'.
+
+'-Wcomment'
+     Warn whenever a comment-start sequence '/*' appears in a '/*'
+     comment, or whenever a Backslash-Newline appears in a '//' comment.
+     This warning is enabled by '-Wall'.
+
+'-Wno-coverage-mismatch'
+     Warn if feedback profiles do not match when using the
+     '-fprofile-use' option.  If a source file is changed between
+     compiling with '-fprofile-gen' and with '-fprofile-use', the files
+     with the profile feedback can fail to match the source file and GCC
+     cannot use the profile feedback information.  By default, this
+     warning is enabled and is treated as an error.
+     '-Wno-coverage-mismatch' can be used to disable the warning or
+     '-Wno-error=coverage-mismatch' can be used to disable the error.
+     Disabling the error for this warning can result in poorly optimized
+     code and is useful only in the case of very minor changes such as
+     bug fixes to an existing code-base.  Completely disabling the
+     warning is not recommended.
+
+'-Wno-cpp'
+     (C, Objective-C, C++, Objective-C++ and Fortran only)
+
+     Suppress warning messages emitted by '#warning' directives.
+
+'-Wdouble-promotion (C, C++, Objective-C and Objective-C++ only)'
+     Give a warning when a value of type 'float' is implicitly promoted
+     to 'double'.  CPUs with a 32-bit "single-precision" floating-point
+     unit implement 'float' in hardware, but emulate 'double' in
+     software.  On such a machine, doing computations using 'double'
+     values is much more expensive because of the overhead required for
+     software emulation.
+
+     It is easy to accidentally do computations with 'double' because
+     floating-point literals are implicitly of type 'double'.  For
+     example, in:
+          float area(float radius)
+          {
+             return 3.14159 * radius * radius;
+          }
+     the compiler performs the entire computation with 'double' because
+     the floating-point literal is a 'double'.
+
+'-Wformat'
+'-Wformat=N'
+     Check calls to 'printf' and 'scanf', etc., to make sure that the
+     arguments supplied have types appropriate to the format string
+     specified, and that the conversions specified in the format string
+     make sense.  This includes standard functions, and others specified
+     by format attributes (*note Function Attributes::), in the
+     'printf', 'scanf', 'strftime' and 'strfmon' (an X/Open extension,
+     not in the C standard) families (or other target-specific
+     families).  Which functions are checked without format attributes
+     having been specified depends on the standard version selected, and
+     such checks of functions without the attribute specified are
+     disabled by '-ffreestanding' or '-fno-builtin'.
+
+     The formats are checked against the format features supported by
+     GNU libc version 2.2.  These include all ISO C90 and C99 features,
+     as well as features from the Single Unix Specification and some BSD
+     and GNU extensions.  Other library implementations may not support
+     all these features; GCC does not support warning about features
+     that go beyond a particular library's limitations.  However, if
+     '-Wpedantic' is used with '-Wformat', warnings are given about
+     format features not in the selected standard version (but not for
+     'strfmon' formats, since those are not in any version of the C
+     standard).  *Note Options Controlling C Dialect: C Dialect Options.
+
+     '-Wformat=1'
+     '-Wformat'
+          Option '-Wformat' is equivalent to '-Wformat=1', and
+          '-Wno-format' is equivalent to '-Wformat=0'.  Since '-Wformat'
+          also checks for null format arguments for several functions,
+          '-Wformat' also implies '-Wnonnull'.  Some aspects of this
+          level of format checking can be disabled by the options:
+          '-Wno-format-contains-nul', '-Wno-format-extra-args', and
+          '-Wno-format-zero-length'.  '-Wformat' is enabled by '-Wall'.
+
+     '-Wno-format-contains-nul'
+          If '-Wformat' is specified, do not warn about format strings
+          that contain NUL bytes.
+
+     '-Wno-format-extra-args'
+          If '-Wformat' is specified, do not warn about excess arguments
+          to a 'printf' or 'scanf' format function.  The C standard
+          specifies that such arguments are ignored.
+
+          Where the unused arguments lie between used arguments that are
+          specified with '$' operand number specifications, normally
+          warnings are still given, since the implementation could not
+          know what type to pass to 'va_arg' to skip the unused
+          arguments.  However, in the case of 'scanf' formats, this
+          option suppresses the warning if the unused arguments are all
+          pointers, since the Single Unix Specification says that such
+          unused arguments are allowed.
+
+     '-Wno-format-zero-length'
+          If '-Wformat' is specified, do not warn about zero-length
+          formats.  The C standard specifies that zero-length formats
+          are allowed.
+
+     '-Wformat=2'
+          Enable '-Wformat' plus additional format checks.  Currently
+          equivalent to '-Wformat -Wformat-nonliteral -Wformat-security
+          -Wformat-y2k'.
+
+     '-Wformat-nonliteral'
+          If '-Wformat' is specified, also warn if the format string is
+          not a string literal and so cannot be checked, unless the
+          format function takes its format arguments as a 'va_list'.
+
+     '-Wformat-security'
+          If '-Wformat' is specified, also warn about uses of format
+          functions that represent possible security problems.  At
+          present, this warns about calls to 'printf' and 'scanf'
+          functions where the format string is not a string literal and
+          there are no format arguments, as in 'printf (foo);'.  This
+          may be a security hole if the format string came from
+          untrusted input and contains '%n'.  (This is currently a
+          subset of what '-Wformat-nonliteral' warns about, but in
+          future warnings may be added to '-Wformat-security' that are
+          not included in '-Wformat-nonliteral'.)
+
+     '-Wformat-y2k'
+          If '-Wformat' is specified, also warn about 'strftime' formats
+          that may yield only a two-digit year.
+
+'-Wnonnull'
+     Warn about passing a null pointer for arguments marked as requiring
+     a non-null value by the 'nonnull' function attribute.
+
+     '-Wnonnull' is included in '-Wall' and '-Wformat'.  It can be
+     disabled with the '-Wno-nonnull' option.
+
+'-Winit-self (C, C++, Objective-C and Objective-C++ only)'
+     Warn about uninitialized variables that are initialized with
+     themselves.  Note this option can only be used with the
+     '-Wuninitialized' option.
+
+     For example, GCC warns about 'i' being uninitialized in the
+     following snippet only when '-Winit-self' has been specified:
+          int f()
+          {
+            int i = i;
+            return i;
+          }
+
+     This warning is enabled by '-Wall' in C++.
+
+'-Wimplicit-int (C and Objective-C only)'
+     Warn when a declaration does not specify a type.  This warning is
+     enabled by '-Wall'.
+
+'-Wimplicit-function-declaration (C and Objective-C only)'
+     Give a warning whenever a function is used before being declared.
+     In C99 mode ('-std=c99' or '-std=gnu99'), this warning is enabled
+     by default and it is made into an error by '-pedantic-errors'.
+     This warning is also enabled by '-Wall'.
+
+'-Wimplicit (C and Objective-C only)'
+     Same as '-Wimplicit-int' and '-Wimplicit-function-declaration'.
+     This warning is enabled by '-Wall'.
+
+'-Wignored-qualifiers (C and C++ only)'
+     Warn if the return type of a function has a type qualifier such as
+     'const'.  For ISO C such a type qualifier has no effect, since the
+     value returned by a function is not an lvalue.  For C++, the
+     warning is only emitted for scalar types or 'void'.  ISO C
+     prohibits qualified 'void' return types on function definitions, so
+     such return types always receive a warning even without this
+     option.
+
+     This warning is also enabled by '-Wextra'.
+
+'-Wmain'
+     Warn if the type of 'main' is suspicious.  'main' should be a
+     function with external linkage, returning int, taking either zero
+     arguments, two, or three arguments of appropriate types.  This
+     warning is enabled by default in C++ and is enabled by either
+     '-Wall' or '-Wpedantic'.
+
+'-Wmissing-braces'
+     Warn if an aggregate or union initializer is not fully bracketed.
+     In the following example, the initializer for 'a' is not fully
+     bracketed, but that for 'b' is fully bracketed.  This warning is
+     enabled by '-Wall' in C.
+
+          int a[2][2] = { 0, 1, 2, 3 };
+          int b[2][2] = { { 0, 1 }, { 2, 3 } };
+
+     This warning is enabled by '-Wall'.
+
+'-Wmissing-include-dirs (C, C++, Objective-C and Objective-C++ only)'
+     Warn if a user-supplied include directory does not exist.
+
+'-Wparentheses'
+     Warn if parentheses are omitted in certain contexts, such as when
+     there is an assignment in a context where a truth value is
+     expected, or when operators are nested whose precedence people
+     often get confused about.
+
+     Also warn if a comparison like 'x<=y<=z' appears; this is
+     equivalent to '(x<=y ? 1 : 0) <= z', which is a different
+     interpretation from that of ordinary mathematical notation.
+
+     Also warn about constructions where there may be confusion to which
+     'if' statement an 'else' branch belongs.  Here is an example of
+     such a case:
+
+          {
+            if (a)
+              if (b)
+                foo ();
+            else
+              bar ();
+          }
+
+     In C/C++, every 'else' branch belongs to the innermost possible
+     'if' statement, which in this example is 'if (b)'.  This is often
+     not what the programmer expected, as illustrated in the above
+     example by indentation the programmer chose.  When there is the
+     potential for this confusion, GCC issues a warning when this flag
+     is specified.  To eliminate the warning, add explicit braces around
+     the innermost 'if' statement so there is no way the 'else' can
+     belong to the enclosing 'if'.  The resulting code looks like this:
+
+          {
+            if (a)
+              {
+                if (b)
+                  foo ();
+                else
+                  bar ();
+              }
+          }
+
+     Also warn for dangerous uses of the GNU extension to '?:' with
+     omitted middle operand.  When the condition in the '?': operator is
+     a boolean expression, the omitted value is always 1.  Often
+     programmers expect it to be a value computed inside the conditional
+     expression instead.
+
+     This warning is enabled by '-Wall'.
+
+'-Wsequence-point'
+     Warn about code that may have undefined semantics because of
+     violations of sequence point rules in the C and C++ standards.
+
+     The C and C++ standards define the order in which expressions in a
+     C/C++ program are evaluated in terms of "sequence points", which
+     represent a partial ordering between the execution of parts of the
+     program: those executed before the sequence point, and those
+     executed after it.  These occur after the evaluation of a full
+     expression (one which is not part of a larger expression), after
+     the evaluation of the first operand of a '&&', '||', '? :' or ','
+     (comma) operator, before a function is called (but after the
+     evaluation of its arguments and the expression denoting the called
+     function), and in certain other places.  Other than as expressed by
+     the sequence point rules, the order of evaluation of subexpressions
+     of an expression is not specified.  All these rules describe only a
+     partial order rather than a total order, since, for example, if two
+     functions are called within one expression with no sequence point
+     between them, the order in which the functions are called is not
+     specified.  However, the standards committee have ruled that
+     function calls do not overlap.
+
+     It is not specified when between sequence points modifications to
+     the values of objects take effect.  Programs whose behavior depends
+     on this have undefined behavior; the C and C++ standards specify
+     that "Between the previous and next sequence point an object shall
+     have its stored value modified at most once by the evaluation of an
+     expression.  Furthermore, the prior value shall be read only to
+     determine the value to be stored.".  If a program breaks these
+     rules, the results on any particular implementation are entirely
+     unpredictable.
+
+     Examples of code with undefined behavior are 'a = a++;', 'a[n] =
+     b[n++]' and 'a[i++] = i;'.  Some more complicated cases are not
+     diagnosed by this option, and it may give an occasional false
+     positive result, but in general it has been found fairly effective
+     at detecting this sort of problem in programs.
+
+     The standard is worded confusingly, therefore there is some debate
+     over the precise meaning of the sequence point rules in subtle
+     cases.  Links to discussions of the problem, including proposed
+     formal definitions, may be found on the GCC readings page, at
+     <http://gcc.gnu.org/readings.html>.
+
+     This warning is enabled by '-Wall' for C and C++.
+
+'-Wno-return-local-addr'
+     Do not warn about returning a pointer (or in C++, a reference) to a
+     variable that goes out of scope after the function returns.
+
+'-Wreturn-type'
+     Warn whenever a function is defined with a return type that
+     defaults to 'int'.  Also warn about any 'return' statement with no
+     return value in a function whose return type is not 'void' (falling
+     off the end of the function body is considered returning without a
+     value), and about a 'return' statement with an expression in a
+     function whose return type is 'void'.
+
+     For C++, a function without return type always produces a
+     diagnostic message, even when '-Wno-return-type' is specified.  The
+     only exceptions are 'main' and functions defined in system headers.
+
+     This warning is enabled by '-Wall'.
+
+'-Wswitch'
+     Warn whenever a 'switch' statement has an index of enumerated type
+     and lacks a 'case' for one or more of the named codes of that
+     enumeration.  (The presence of a 'default' label prevents this
+     warning.)  'case' labels outside the enumeration range also provoke
+     warnings when this option is used (even if there is a 'default'
+     label).  This warning is enabled by '-Wall'.
+
+'-Wswitch-default'
+     Warn whenever a 'switch' statement does not have a 'default' case.
+
+'-Wswitch-enum'
+     Warn whenever a 'switch' statement has an index of enumerated type
+     and lacks a 'case' for one or more of the named codes of that
+     enumeration.  'case' labels outside the enumeration range also
+     provoke warnings when this option is used.  The only difference
+     between '-Wswitch' and this option is that this option gives a
+     warning about an omitted enumeration code even if there is a
+     'default' label.
+
+'-Wsync-nand (C and C++ only)'
+     Warn when '__sync_fetch_and_nand' and '__sync_nand_and_fetch'
+     built-in functions are used.  These functions changed semantics in
+     GCC 4.4.
+
+'-Wtrigraphs'
+     Warn if any trigraphs are encountered that might change the meaning
+     of the program (trigraphs within comments are not warned about).
+     This warning is enabled by '-Wall'.
+
+'-Wunused-but-set-parameter'
+     Warn whenever a function parameter is assigned to, but otherwise
+     unused (aside from its declaration).
+
+     To suppress this warning use the 'unused' attribute (*note Variable
+     Attributes::).
+
+     This warning is also enabled by '-Wunused' together with '-Wextra'.
+
+'-Wunused-but-set-variable'
+     Warn whenever a local variable is assigned to, but otherwise unused
+     (aside from its declaration).  This warning is enabled by '-Wall'.
+
+     To suppress this warning use the 'unused' attribute (*note Variable
+     Attributes::).
+
+     This warning is also enabled by '-Wunused', which is enabled by
+     '-Wall'.
+
+'-Wunused-function'
+     Warn whenever a static function is declared but not defined or a
+     non-inline static function is unused.  This warning is enabled by
+     '-Wall'.
+
+'-Wunused-label'
+     Warn whenever a label is declared but not used.  This warning is
+     enabled by '-Wall'.
+
+     To suppress this warning use the 'unused' attribute (*note Variable
+     Attributes::).
+
+'-Wunused-local-typedefs (C, Objective-C, C++ and Objective-C++ only)'
+     Warn when a typedef locally defined in a function is not used.
+     This warning is enabled by '-Wall'.
+
+'-Wunused-parameter'
+     Warn whenever a function parameter is unused aside from its
+     declaration.
+
+     To suppress this warning use the 'unused' attribute (*note Variable
+     Attributes::).
+
+'-Wno-unused-result'
+     Do not warn if a caller of a function marked with attribute
+     'warn_unused_result' (*note Function Attributes::) does not use its
+     return value.  The default is '-Wunused-result'.
+
+'-Wunused-variable'
+     Warn whenever a local variable or non-constant static variable is
+     unused aside from its declaration.  This warning is enabled by
+     '-Wall'.
+
+     To suppress this warning use the 'unused' attribute (*note Variable
+     Attributes::).
+
+'-Wunused-value'
+     Warn whenever a statement computes a result that is explicitly not
+     used.  To suppress this warning cast the unused expression to
+     'void'.  This includes an expression-statement or the left-hand
+     side of a comma expression that contains no side effects.  For
+     example, an expression such as 'x[i,j]' causes a warning, while
+     'x[(void)i,j]' does not.
+
+     This warning is enabled by '-Wall'.
+
+'-Wunused'
+     All the above '-Wunused' options combined.
+
+     In order to get a warning about an unused function parameter, you
+     must either specify '-Wextra -Wunused' (note that '-Wall' implies
+     '-Wunused'), or separately specify '-Wunused-parameter'.
+
+'-Wuninitialized'
+     Warn if an automatic variable is used without first being
+     initialized or if a variable may be clobbered by a 'setjmp' call.
+     In C++, warn if a non-static reference or non-static 'const' member
+     appears in a class without constructors.
+
+     If you want to warn about code that uses the uninitialized value of
+     the variable in its own initializer, use the '-Winit-self' option.
+
+     These warnings occur for individual uninitialized or clobbered
+     elements of structure, union or array variables as well as for
+     variables that are uninitialized or clobbered as a whole.  They do
+     not occur for variables or elements declared 'volatile'.  Because
+     these warnings depend on optimization, the exact variables or
+     elements for which there are warnings depends on the precise
+     optimization options and version of GCC used.
+
+     Note that there may be no warning about a variable that is used
+     only to compute a value that itself is never used, because such
+     computations may be deleted by data flow analysis before the
+     warnings are printed.
+
+'-Wmaybe-uninitialized'
+     For an automatic variable, if there exists a path from the function
+     entry to a use of the variable that is initialized, but there exist
+     some other paths for which the variable is not initialized, the
+     compiler emits a warning if it cannot prove the uninitialized paths
+     are not executed at run time.  These warnings are made optional
+     because GCC is not smart enough to see all the reasons why the code
+     might be correct in spite of appearing to have an error.  Here is
+     one example of how this can happen:
+
+          {
+            int x;
+            switch (y)
+              {
+              case 1: x = 1;
+                break;
+              case 2: x = 4;
+                break;
+              case 3: x = 5;
+              }
+            foo (x);
+          }
+
+     If the value of 'y' is always 1, 2 or 3, then 'x' is always
+     initialized, but GCC doesn't know this.  To suppress the warning,
+     you need to provide a default case with assert(0) or similar code.
+
+     This option also warns when a non-volatile automatic variable might
+     be changed by a call to 'longjmp'.  These warnings as well are
+     possible only in optimizing compilation.
+
+     The compiler sees only the calls to 'setjmp'.  It cannot know where
+     'longjmp' will be called; in fact, a signal handler could call it
+     at any point in the code.  As a result, you may get a warning even
+     when there is in fact no problem because 'longjmp' cannot in fact
+     be called at the place that would cause a problem.
+
+     Some spurious warnings can be avoided if you declare all the
+     functions you use that never return as 'noreturn'.  *Note Function
+     Attributes::.
+
+     This warning is enabled by '-Wall' or '-Wextra'.
+
+'-Wunknown-pragmas'
+     Warn when a '#pragma' directive is encountered that is not
+     understood by GCC.  If this command-line option is used, warnings
+     are even issued for unknown pragmas in system header files.  This
+     is not the case if the warnings are only enabled by the '-Wall'
+     command-line option.
+
+'-Wno-pragmas'
+     Do not warn about misuses of pragmas, such as incorrect parameters,
+     invalid syntax, or conflicts between pragmas.  See also
+     '-Wunknown-pragmas'.
+
+'-Wstrict-aliasing'
+     This option is only active when '-fstrict-aliasing' is active.  It
+     warns about code that might break the strict aliasing rules that
+     the compiler is using for optimization.  The warning does not catch
+     all cases, but does attempt to catch the more common pitfalls.  It
+     is included in '-Wall'.  It is equivalent to '-Wstrict-aliasing=3'
+
+'-Wstrict-aliasing=n'
+     This option is only active when '-fstrict-aliasing' is active.  It
+     warns about code that might break the strict aliasing rules that
+     the compiler is using for optimization.  Higher levels correspond
+     to higher accuracy (fewer false positives).  Higher levels also
+     correspond to more effort, similar to the way '-O' works.
+     '-Wstrict-aliasing' is equivalent to '-Wstrict-aliasing=3'.
+
+     Level 1: Most aggressive, quick, least accurate.  Possibly useful
+     when higher levels do not warn but '-fstrict-aliasing' still breaks
+     the code, as it has very few false negatives.  However, it has many
+     false positives.  Warns for all pointer conversions between
+     possibly incompatible types, even if never dereferenced.  Runs in
+     the front end only.
+
+     Level 2: Aggressive, quick, not too precise.  May still have many
+     false positives (not as many as level 1 though), and few false
+     negatives (but possibly more than level 1).  Unlike level 1, it
+     only warns when an address is taken.  Warns about incomplete types.
+     Runs in the front end only.
+
+     Level 3 (default for '-Wstrict-aliasing'): Should have very few
+     false positives and few false negatives.  Slightly slower than
+     levels 1 or 2 when optimization is enabled.  Takes care of the
+     common pun+dereference pattern in the front end:
+     '*(int*)&some_float'.  If optimization is enabled, it also runs in
+     the back end, where it deals with multiple statement cases using
+     flow-sensitive points-to information.  Only warns when the
+     converted pointer is dereferenced.  Does not warn about incomplete
+     types.
+
+'-Wstrict-overflow'
+'-Wstrict-overflow=N'
+     This option is only active when '-fstrict-overflow' is active.  It
+     warns about cases where the compiler optimizes based on the
+     assumption that signed overflow does not occur.  Note that it does
+     not warn about all cases where the code might overflow: it only
+     warns about cases where the compiler implements some optimization.
+     Thus this warning depends on the optimization level.
+
+     An optimization that assumes that signed overflow does not occur is
+     perfectly safe if the values of the variables involved are such
+     that overflow never does, in fact, occur.  Therefore this warning
+     can easily give a false positive: a warning about code that is not
+     actually a problem.  To help focus on important issues, several
+     warning levels are defined.  No warnings are issued for the use of
+     undefined signed overflow when estimating how many iterations a
+     loop requires, in particular when determining whether a loop will
+     be executed at all.
+
+     '-Wstrict-overflow=1'
+          Warn about cases that are both questionable and easy to avoid.
+          For example, with '-fstrict-overflow', the compiler simplifies
+          'x + 1 > x' to '1'.  This level of '-Wstrict-overflow' is
+          enabled by '-Wall'; higher levels are not, and must be
+          explicitly requested.
+
+     '-Wstrict-overflow=2'
+          Also warn about other cases where a comparison is simplified
+          to a constant.  For example: 'abs (x) >= 0'.  This can only be
+          simplified when '-fstrict-overflow' is in effect, because 'abs
+          (INT_MIN)' overflows to 'INT_MIN', which is less than zero.
+          '-Wstrict-overflow' (with no level) is the same as
+          '-Wstrict-overflow=2'.
+
+     '-Wstrict-overflow=3'
+          Also warn about other cases where a comparison is simplified.
+          For example: 'x + 1 > 1' is simplified to 'x > 0'.
+
+     '-Wstrict-overflow=4'
+          Also warn about other simplifications not covered by the above
+          cases.  For example: '(x * 10) / 5' is simplified to 'x * 2'.
+
+     '-Wstrict-overflow=5'
+          Also warn about cases where the compiler reduces the magnitude
+          of a constant involved in a comparison.  For example: 'x + 2 >
+          y' is simplified to 'x + 1 >= y'.  This is reported only at
+          the highest warning level because this simplification applies
+          to many comparisons, so this warning level gives a very large
+          number of false positives.
+
+'-Wsuggest-attribute=[pure|const|noreturn|format]'
+     Warn for cases where adding an attribute may be beneficial.  The
+     attributes currently supported are listed below.
+
+     '-Wsuggest-attribute=pure'
+     '-Wsuggest-attribute=const'
+     '-Wsuggest-attribute=noreturn'
+
+          Warn about functions that might be candidates for attributes
+          'pure', 'const' or 'noreturn'.  The compiler only warns for
+          functions visible in other compilation units or (in the case
+          of 'pure' and 'const') if it cannot prove that the function
+          returns normally.  A function returns normally if it doesn't
+          contain an infinite loop or return abnormally by throwing,
+          calling 'abort()' or trapping.  This analysis requires option
+          '-fipa-pure-const', which is enabled by default at '-O' and
+          higher.  Higher optimization levels improve the accuracy of
+          the analysis.
+
+     '-Wsuggest-attribute=format'
+     '-Wmissing-format-attribute'
+
+          Warn about function pointers that might be candidates for
+          'format' attributes.  Note these are only possible candidates,
+          not absolute ones.  GCC guesses that function pointers with
+          'format' attributes that are used in assignment,
+          initialization, parameter passing or return statements should
+          have a corresponding 'format' attribute in the resulting type.
+          I.e. the left-hand side of the assignment or initialization,
+          the type of the parameter variable, or the return type of the
+          containing function respectively should also have a 'format'
+          attribute to avoid the warning.
+
+          GCC also warns about function definitions that might be
+          candidates for 'format' attributes.  Again, these are only
+          possible candidates.  GCC guesses that 'format' attributes
+          might be appropriate for any function that calls a function
+          like 'vprintf' or 'vscanf', but this might not always be the
+          case, and some functions for which 'format' attributes are
+          appropriate may not be detected.
+
+'-Warray-bounds'
+     This option is only active when '-ftree-vrp' is active (default for
+     '-O2' and above).  It warns about subscripts to arrays that are
+     always out of bounds.  This warning is enabled by '-Wall'.
+
+'-Wno-div-by-zero'
+     Do not warn about compile-time integer division by zero.
+     Floating-point division by zero is not warned about, as it can be a
+     legitimate way of obtaining infinities and NaNs.
+
+'-Wsystem-headers'
+     Print warning messages for constructs found in system header files.
+     Warnings from system headers are normally suppressed, on the
+     assumption that they usually do not indicate real problems and
+     would only make the compiler output harder to read.  Using this
+     command-line option tells GCC to emit warnings from system headers
+     as if they occurred in user code.  However, note that using '-Wall'
+     in conjunction with this option does _not_ warn about unknown
+     pragmas in system headers--for that, '-Wunknown-pragmas' must also
+     be used.
+
+'-Wtrampolines'
+     Warn about trampolines generated for pointers to nested functions.
+
+     A trampoline is a small piece of data or code that is created at
+     run time on the stack when the address of a nested function is
+     taken, and is used to call the nested function indirectly.  For
+     some targets, it is made up of data only and thus requires no
+     special treatment.  But, for most targets, it is made up of code
+     and thus requires the stack to be made executable in order for the
+     program to work properly.
+
+'-Wfloat-equal'
+     Warn if floating-point values are used in equality comparisons.
+
+     The idea behind this is that sometimes it is convenient (for the
+     programmer) to consider floating-point values as approximations to
+     infinitely precise real numbers.  If you are doing this, then you
+     need to compute (by analyzing the code, or in some other way) the
+     maximum or likely maximum error that the computation introduces,
+     and allow for it when performing comparisons (and when producing
+     output, but that's a different problem).  In particular, instead of
+     testing for equality, you should check to see whether the two
+     values have ranges that overlap; and this is done with the
+     relational operators, so equality comparisons are probably
+     mistaken.
+
+'-Wtraditional (C and Objective-C only)'
+     Warn about certain constructs that behave differently in
+     traditional and ISO C.  Also warn about ISO C constructs that have
+     no traditional C equivalent, and/or problematic constructs that
+     should be avoided.
+
+        * Macro parameters that appear within string literals in the
+          macro body.  In traditional C macro replacement takes place
+          within string literals, but in ISO C it does not.
+
+        * In traditional C, some preprocessor directives did not exist.
+          Traditional preprocessors only considered a line to be a
+          directive if the '#' appeared in column 1 on the line.
+          Therefore '-Wtraditional' warns about directives that
+          traditional C understands but ignores because the '#' does not
+          appear as the first character on the line.  It also suggests
+          you hide directives like '#pragma' not understood by
+          traditional C by indenting them.  Some traditional
+          implementations do not recognize '#elif', so this option
+          suggests avoiding it altogether.
+
+        * A function-like macro that appears without arguments.
+
+        * The unary plus operator.
+
+        * The 'U' integer constant suffix, or the 'F' or 'L'
+          floating-point constant suffixes.  (Traditional C does support
+          the 'L' suffix on integer constants.)  Note, these suffixes
+          appear in macros defined in the system headers of most modern
+          systems, e.g. the '_MIN'/'_MAX' macros in '<limits.h>'.  Use
+          of these macros in user code might normally lead to spurious
+          warnings, however GCC's integrated preprocessor has enough
+          context to avoid warning in these cases.
+
+        * A function declared external in one block and then used after
+          the end of the block.
+
+        * A 'switch' statement has an operand of type 'long'.
+
+        * A non-'static' function declaration follows a 'static' one.
+          This construct is not accepted by some traditional C
+          compilers.
+
+        * The ISO type of an integer constant has a different width or
+          signedness from its traditional type.  This warning is only
+          issued if the base of the constant is ten.  I.e. hexadecimal
+          or octal values, which typically represent bit patterns, are
+          not warned about.
+
+        * Usage of ISO string concatenation is detected.
+
+        * Initialization of automatic aggregates.
+
+        * Identifier conflicts with labels.  Traditional C lacks a
+          separate namespace for labels.
+
+        * Initialization of unions.  If the initializer is zero, the
+          warning is omitted.  This is done under the assumption that
+          the zero initializer in user code appears conditioned on e.g.
+          '__STDC__' to avoid missing initializer warnings and relies on
+          default initialization to zero in the traditional C case.
+
+        * Conversions by prototypes between fixed/floating-point values
+          and vice versa.  The absence of these prototypes when
+          compiling with traditional C causes serious problems.  This is
+          a subset of the possible conversion warnings; for the full set
+          use '-Wtraditional-conversion'.
+
+        * Use of ISO C style function definitions.  This warning
+          intentionally is _not_ issued for prototype declarations or
+          variadic functions because these ISO C features appear in your
+          code when using libiberty's traditional C compatibility
+          macros, 'PARAMS' and 'VPARAMS'.  This warning is also bypassed
+          for nested functions because that feature is already a GCC
+          extension and thus not relevant to traditional C
+          compatibility.
+
+'-Wtraditional-conversion (C and Objective-C only)'
+     Warn if a prototype causes a type conversion that is different from
+     what would happen to the same argument in the absence of a
+     prototype.  This includes conversions of fixed point to floating
+     and vice versa, and conversions changing the width or signedness of
+     a fixed-point argument except when the same as the default
+     promotion.
+
+'-Wdeclaration-after-statement (C and Objective-C only)'
+     Warn when a declaration is found after a statement in a block.
+     This construct, known from C++, was introduced with ISO C99 and is
+     by default allowed in GCC.  It is not supported by ISO C90 and was
+     not supported by GCC versions before GCC 3.0.  *Note Mixed
+     Declarations::.
+
+'-Wundef'
+     Warn if an undefined identifier is evaluated in an '#if' directive.
+
+'-Wno-endif-labels'
+     Do not warn whenever an '#else' or an '#endif' are followed by
+     text.
+
+'-Wshadow'
+     Warn whenever a local variable or type declaration shadows another
+     variable, parameter, type, or class member (in C++), or whenever a
+     built-in function is shadowed.  Note that in C++, the compiler
+     warns if a local variable shadows an explicit typedef, but not if
+     it shadows a struct/class/enum.
+
+'-Wlarger-than=LEN'
+     Warn whenever an object of larger than LEN bytes is defined.
+
+'-Wframe-larger-than=LEN'
+     Warn if the size of a function frame is larger than LEN bytes.  The
+     computation done to determine the stack frame size is approximate
+     and not conservative.  The actual requirements may be somewhat
+     greater than LEN even if you do not get a warning.  In addition,
+     any space allocated via 'alloca', variable-length arrays, or
+     related constructs is not included by the compiler when determining
+     whether or not to issue a warning.
+
+'-Wno-free-nonheap-object'
+     Do not warn when attempting to free an object that was not
+     allocated on the heap.
+
+'-Wstack-usage=LEN'
+     Warn if the stack usage of a function might be larger than LEN
+     bytes.  The computation done to determine the stack usage is
+     conservative.  Any space allocated via 'alloca', variable-length
+     arrays, or related constructs is included by the compiler when
+     determining whether or not to issue a warning.
+
+     The message is in keeping with the output of '-fstack-usage'.
+
+        * If the stack usage is fully static but exceeds the specified
+          amount, it's:
+
+                 warning: stack usage is 1120 bytes
+        * If the stack usage is (partly) dynamic but bounded, it's:
+
+                 warning: stack usage might be 1648 bytes
+        * If the stack usage is (partly) dynamic and not bounded, it's:
+
+                 warning: stack usage might be unbounded
+
+'-Wunsafe-loop-optimizations'
+     Warn if the loop cannot be optimized because the compiler cannot
+     assume anything on the bounds of the loop indices.  With
+     '-funsafe-loop-optimizations' warn if the compiler makes such
+     assumptions.
+
+'-Wno-pedantic-ms-format (MinGW targets only)'
+     When used in combination with '-Wformat' and '-pedantic' without
+     GNU extensions, this option disables the warnings about non-ISO
+     'printf' / 'scanf' format width specifiers 'I32', 'I64', and 'I'
+     used on Windows targets, which depend on the MS runtime.
+
+'-Wpointer-arith'
+     Warn about anything that depends on the "size of" a function type
+     or of 'void'.  GNU C assigns these types a size of 1, for
+     convenience in calculations with 'void *' pointers and pointers to
+     functions.  In C++, warn also when an arithmetic operation involves
+     'NULL'.  This warning is also enabled by '-Wpedantic'.
+
+'-Wtype-limits'
+     Warn if a comparison is always true or always false due to the
+     limited range of the data type, but do not warn for constant
+     expressions.  For example, warn if an unsigned variable is compared
+     against zero with '<' or '>='.  This warning is also enabled by
+     '-Wextra'.
+
+'-Wbad-function-cast (C and Objective-C only)'
+     Warn whenever a function call is cast to a non-matching type.  For
+     example, warn if 'int malloc()' is cast to 'anything *'.
+
+'-Wc++-compat (C and Objective-C only)'
+     Warn about ISO C constructs that are outside of the common subset
+     of ISO C and ISO C++, e.g. request for implicit conversion from
+     'void *' to a pointer to non-'void' type.
+
+'-Wc++11-compat (C++ and Objective-C++ only)'
+     Warn about C++ constructs whose meaning differs between ISO C++
+     1998 and ISO C++ 2011, e.g., identifiers in ISO C++ 1998 that are
+     keywords in ISO C++ 2011.  This warning turns on '-Wnarrowing' and
+     is enabled by '-Wall'.
+
+'-Wcast-qual'
+     Warn whenever a pointer is cast so as to remove a type qualifier
+     from the target type.  For example, warn if a 'const char *' is
+     cast to an ordinary 'char *'.
+
+     Also warn when making a cast that introduces a type qualifier in an
+     unsafe way.  For example, casting 'char **' to 'const char **' is
+     unsafe, as in this example:
+
+            /* p is char ** value.  */
+            const char **q = (const char **) p;
+            /* Assignment of readonly string to const char * is OK.  */
+            *q = "string";
+            /* Now char** pointer points to read-only memory.  */
+            **p = 'b';
+
+'-Wcast-align'
+     Warn whenever a pointer is cast such that the required alignment of
+     the target is increased.  For example, warn if a 'char *' is cast
+     to an 'int *' on machines where integers can only be accessed at
+     two- or four-byte boundaries.
+
+'-Wwrite-strings'
+     When compiling C, give string constants the type 'const
+     char[LENGTH]' so that copying the address of one into a non-'const'
+     'char *' pointer produces a warning.  These warnings help you find
+     at compile time code that can try to write into a string constant,
+     but only if you have been very careful about using 'const' in
+     declarations and prototypes.  Otherwise, it is just a nuisance.
+     This is why we did not make '-Wall' request these warnings.
+
+     When compiling C++, warn about the deprecated conversion from
+     string literals to 'char *'.  This warning is enabled by default
+     for C++ programs.
+
+'-Wclobbered'
+     Warn for variables that might be changed by 'longjmp' or 'vfork'.
+     This warning is also enabled by '-Wextra'.
+
+'-Wconditionally-supported (C++ and Objective-C++ only)'
+     Warn for conditionally-supported (C++11 [intro.defs]) constructs.
+
+'-Wconversion'
+     Warn for implicit conversions that may alter a value.  This
+     includes conversions between real and integer, like 'abs (x)' when
+     'x' is 'double'; conversions between signed and unsigned, like
+     'unsigned ui = -1'; and conversions to smaller types, like 'sqrtf
+     (M_PI)'.  Do not warn for explicit casts like 'abs ((int) x)' and
+     'ui = (unsigned) -1', or if the value is not changed by the
+     conversion like in 'abs (2.0)'.  Warnings about conversions between
+     signed and unsigned integers can be disabled by using
+     '-Wno-sign-conversion'.
+
+     For C++, also warn for confusing overload resolution for
+     user-defined conversions; and conversions that never use a type
+     conversion operator: conversions to 'void', the same type, a base
+     class or a reference to them.  Warnings about conversions between
+     signed and unsigned integers are disabled by default in C++ unless
+     '-Wsign-conversion' is explicitly enabled.
+
+'-Wno-conversion-null (C++ and Objective-C++ only)'
+     Do not warn for conversions between 'NULL' and non-pointer types.
+     '-Wconversion-null' is enabled by default.
+
+'-Wzero-as-null-pointer-constant (C++ and Objective-C++ only)'
+     Warn when a literal '0' is used as null pointer constant.  This can
+     be useful to facilitate the conversion to 'nullptr' in C++11.
+
+'-Wdate-time'
+     Warn when macros '__TIME__', '__DATE__' or '__TIMESTAMP__' are
+     encountered as they might prevent bit-wise-identical reproducible
+     compilations.
+
+'-Wdelete-incomplete (C++ and Objective-C++ only)'
+     Warn when deleting a pointer to incomplete type, which may cause
+     undefined behavior at runtime.  This warning is enabled by default.
+
+'-Wuseless-cast (C++ and Objective-C++ only)'
+     Warn when an expression is casted to its own type.
+
+'-Wempty-body'
+     Warn if an empty body occurs in an 'if', 'else' or 'do while'
+     statement.  This warning is also enabled by '-Wextra'.
+
+'-Wenum-compare'
+     Warn about a comparison between values of different enumerated
+     types.  In C++ enumeral mismatches in conditional expressions are
+     also diagnosed and the warning is enabled by default.  In C this
+     warning is enabled by '-Wall'.
+
+'-Wjump-misses-init (C, Objective-C only)'
+     Warn if a 'goto' statement or a 'switch' statement jumps forward
+     across the initialization of a variable, or jumps backward to a
+     label after the variable has been initialized.  This only warns
+     about variables that are initialized when they are declared.  This
+     warning is only supported for C and Objective-C; in C++ this sort
+     of branch is an error in any case.
+
+     '-Wjump-misses-init' is included in '-Wc++-compat'.  It can be
+     disabled with the '-Wno-jump-misses-init' option.
+
+'-Wsign-compare'
+     Warn when a comparison between signed and unsigned values could
+     produce an incorrect result when the signed value is converted to
+     unsigned.  This warning is also enabled by '-Wextra'; to get the
+     other warnings of '-Wextra' without this warning, use '-Wextra
+     -Wno-sign-compare'.
+
+'-Wsign-conversion'
+     Warn for implicit conversions that may change the sign of an
+     integer value, like assigning a signed integer expression to an
+     unsigned integer variable.  An explicit cast silences the warning.
+     In C, this option is enabled also by '-Wconversion'.
+
+'-Wfloat-conversion'
+     Warn for implicit conversions that reduce the precision of a real
+     value.  This includes conversions from real to integer, and from
+     higher precision real to lower precision real values.  This option
+     is also enabled by '-Wconversion'.
+
+'-Wsizeof-pointer-memaccess'
+     Warn for suspicious length parameters to certain string and memory
+     built-in functions if the argument uses 'sizeof'.  This warning
+     warns e.g. about 'memset (ptr, 0, sizeof (ptr));' if 'ptr' is not
+     an array, but a pointer, and suggests a possible fix, or about
+     'memcpy (&foo, ptr, sizeof (&foo));'.  This warning is enabled by
+     '-Wall'.
+
+'-Waddress'
+     Warn about suspicious uses of memory addresses.  These include
+     using the address of a function in a conditional expression, such
+     as 'void func(void); if (func)', and comparisons against the memory
+     address of a string literal, such as 'if (x == "abc")'.  Such uses
+     typically indicate a programmer error: the address of a function
+     always evaluates to true, so their use in a conditional usually
+     indicate that the programmer forgot the parentheses in a function
+     call; and comparisons against string literals result in unspecified
+     behavior and are not portable in C, so they usually indicate that
+     the programmer intended to use 'strcmp'.  This warning is enabled
+     by '-Wall'.
+
+'-Wlogical-op'
+     Warn about suspicious uses of logical operators in expressions.
+     This includes using logical operators in contexts where a bit-wise
+     operator is likely to be expected.
+
+'-Waggregate-return'
+     Warn if any functions that return structures or unions are defined
+     or called.  (In languages where you can return an array, this also
+     elicits a warning.)
+
+'-Wno-aggressive-loop-optimizations'
+     Warn if in a loop with constant number of iterations the compiler
+     detects undefined behavior in some statement during one or more of
+     the iterations.
+
+'-Wno-attributes'
+     Do not warn if an unexpected '__attribute__' is used, such as
+     unrecognized attributes, function attributes applied to variables,
+     etc.  This does not stop errors for incorrect use of supported
+     attributes.
+
+'-Wno-builtin-macro-redefined'
+     Do not warn if certain built-in macros are redefined.  This
+     suppresses warnings for redefinition of '__TIMESTAMP__',
+     '__TIME__', '__DATE__', '__FILE__', and '__BASE_FILE__'.
+
+'-Wstrict-prototypes (C and Objective-C only)'
+     Warn if a function is declared or defined without specifying the
+     argument types.  (An old-style function definition is permitted
+     without a warning if preceded by a declaration that specifies the
+     argument types.)
+
+'-Wold-style-declaration (C and Objective-C only)'
+     Warn for obsolescent usages, according to the C Standard, in a
+     declaration.  For example, warn if storage-class specifiers like
+     'static' are not the first things in a declaration.  This warning
+     is also enabled by '-Wextra'.
+
+'-Wold-style-definition (C and Objective-C only)'
+     Warn if an old-style function definition is used.  A warning is
+     given even if there is a previous prototype.
+
+'-Wmissing-parameter-type (C and Objective-C only)'
+     A function parameter is declared without a type specifier in
+     K&R-style functions:
+
+          void foo(bar) { }
+
+     This warning is also enabled by '-Wextra'.
+
+'-Wmissing-prototypes (C and Objective-C only)'
+     Warn if a global function is defined without a previous prototype
+     declaration.  This warning is issued even if the definition itself
+     provides a prototype.  Use this option to detect global functions
+     that do not have a matching prototype declaration in a header file.
+     This option is not valid for C++ because all function declarations
+     provide prototypes and a non-matching declaration will declare an
+     overload rather than conflict with an earlier declaration.  Use
+     '-Wmissing-declarations' to detect missing declarations in C++.
+
+'-Wmissing-declarations'
+     Warn if a global function is defined without a previous
+     declaration.  Do so even if the definition itself provides a
+     prototype.  Use this option to detect global functions that are not
+     declared in header files.  In C, no warnings are issued for
+     functions with previous non-prototype declarations; use
+     '-Wmissing-prototype' to detect missing prototypes.  In C++, no
+     warnings are issued for function templates, or for inline
+     functions, or for functions in anonymous namespaces.
+
+'-Wmissing-field-initializers'
+     Warn if a structure's initializer has some fields missing.  For
+     example, the following code causes such a warning, because 'x.h' is
+     implicitly zero:
+
+          struct s { int f, g, h; };
+          struct s x = { 3, 4 };
+
+     This option does not warn about designated initializers, so the
+     following modification does not trigger a warning:
+
+          struct s { int f, g, h; };
+          struct s x = { .f = 3, .g = 4 };
+
+     This warning is included in '-Wextra'.  To get other '-Wextra'
+     warnings without this one, use '-Wextra
+     -Wno-missing-field-initializers'.
+
+'-Wno-multichar'
+     Do not warn if a multicharacter constant (''FOOF'') is used.
+     Usually they indicate a typo in the user's code, as they have
+     implementation-defined values, and should not be used in portable
+     code.
+
+'-Wnormalized=<none|id|nfc|nfkc>'
+     In ISO C and ISO C++, two identifiers are different if they are
+     different sequences of characters.  However, sometimes when
+     characters outside the basic ASCII character set are used, you can
+     have two different character sequences that look the same.  To
+     avoid confusion, the ISO 10646 standard sets out some
+     "normalization rules" which when applied ensure that two sequences
+     that look the same are turned into the same sequence.  GCC can warn
+     you if you are using identifiers that have not been normalized;
+     this option controls that warning.
+
+     There are four levels of warning supported by GCC.  The default is
+     '-Wnormalized=nfc', which warns about any identifier that is not in
+     the ISO 10646 "C" normalized form, "NFC". NFC is the recommended
+     form for most uses.
+
+     Unfortunately, there are some characters allowed in identifiers by
+     ISO C and ISO C++ that, when turned into NFC, are not allowed in
+     identifiers.  That is, there's no way to use these symbols in
+     portable ISO C or C++ and have all your identifiers in NFC.
+     '-Wnormalized=id' suppresses the warning for these characters.  It
+     is hoped that future versions of the standards involved will
+     correct this, which is why this option is not the default.
+
+     You can switch the warning off for all characters by writing
+     '-Wnormalized=none'.  You should only do this if you are using some
+     other normalization scheme (like "D"), because otherwise you can
+     easily create bugs that are literally impossible to see.
+
+     Some characters in ISO 10646 have distinct meanings but look
+     identical in some fonts or display methodologies, especially once
+     formatting has been applied.  For instance '\u207F', "SUPERSCRIPT
+     LATIN SMALL LETTER N", displays just like a regular 'n' that has
+     been placed in a superscript.  ISO 10646 defines the "NFKC"
+     normalization scheme to convert all these into a standard form as
+     well, and GCC warns if your code is not in NFKC if you use
+     '-Wnormalized=nfkc'.  This warning is comparable to warning about
+     every identifier that contains the letter O because it might be
+     confused with the digit 0, and so is not the default, but may be
+     useful as a local coding convention if the programming environment
+     cannot be fixed to display these characters distinctly.
+
+'-Wno-deprecated'
+     Do not warn about usage of deprecated features.  *Note Deprecated
+     Features::.
+
+'-Wno-deprecated-declarations'
+     Do not warn about uses of functions (*note Function Attributes::),
+     variables (*note Variable Attributes::), and types (*note Type
+     Attributes::) marked as deprecated by using the 'deprecated'
+     attribute.
+
+'-Wno-overflow'
+     Do not warn about compile-time overflow in constant expressions.
+
+'-Wopenmp-simd'
+     Warn if the vectorizer cost model overrides the OpenMP or the Cilk
+     Plus simd directive set by user.  The '-fsimd-cost-model=unlimited'
+     can be used to relax the cost model.
+
+'-Woverride-init (C and Objective-C only)'
+     Warn if an initialized field without side effects is overridden
+     when using designated initializers (*note Designated Initializers:
+     Designated Inits.).
+
+     This warning is included in '-Wextra'.  To get other '-Wextra'
+     warnings without this one, use '-Wextra -Wno-override-init'.
+
+'-Wpacked'
+     Warn if a structure is given the packed attribute, but the packed
+     attribute has no effect on the layout or size of the structure.
+     Such structures may be mis-aligned for little benefit.  For
+     instance, in this code, the variable 'f.x' in 'struct bar' is
+     misaligned even though 'struct bar' does not itself have the packed
+     attribute:
+
+          struct foo {
+            int x;
+            char a, b, c, d;
+          } __attribute__((packed));
+          struct bar {
+            char z;
+            struct foo f;
+          };
+
+'-Wpacked-bitfield-compat'
+     The 4.1, 4.2 and 4.3 series of GCC ignore the 'packed' attribute on
+     bit-fields of type 'char'.  This has been fixed in GCC 4.4 but the
+     change can lead to differences in the structure layout.  GCC
+     informs you when the offset of such a field has changed in GCC 4.4.
+     For example there is no longer a 4-bit padding between field 'a'
+     and 'b' in this structure:
+
+          struct foo
+          {
+            char a:4;
+            char b:8;
+          } __attribute__ ((packed));
+
+     This warning is enabled by default.  Use
+     '-Wno-packed-bitfield-compat' to disable this warning.
+
+'-Wpadded'
+     Warn if padding is included in a structure, either to align an
+     element of the structure or to align the whole structure.
+     Sometimes when this happens it is possible to rearrange the fields
+     of the structure to reduce the padding and so make the structure
+     smaller.
+
+'-Wredundant-decls'
+     Warn if anything is declared more than once in the same scope, even
+     in cases where multiple declaration is valid and changes nothing.
+
+'-Wnested-externs (C and Objective-C only)'
+     Warn if an 'extern' declaration is encountered within a function.
+
+'-Wno-inherited-variadic-ctor'
+     Suppress warnings about use of C++11 inheriting constructors when
+     the base class inherited from has a C variadic constructor; the
+     warning is on by default because the ellipsis is not inherited.
+
+'-Winline'
+     Warn if a function that is declared as inline cannot be inlined.
+     Even with this option, the compiler does not warn about failures to
+     inline functions declared in system headers.
+
+     The compiler uses a variety of heuristics to determine whether or
+     not to inline a function.  For example, the compiler takes into
+     account the size of the function being inlined and the amount of
+     inlining that has already been done in the current function.
+     Therefore, seemingly insignificant changes in the source program
+     can cause the warnings produced by '-Winline' to appear or
+     disappear.
+
+'-Wno-invalid-offsetof (C++ and Objective-C++ only)'
+     Suppress warnings from applying the 'offsetof' macro to a non-POD
+     type.  According to the 1998 ISO C++ standard, applying 'offsetof'
+     to a non-POD type is undefined.  In existing C++ implementations,
+     however, 'offsetof' typically gives meaningful results even when
+     applied to certain kinds of non-POD types (such as a simple
+     'struct' that fails to be a POD type only by virtue of having a
+     constructor).  This flag is for users who are aware that they are
+     writing nonportable code and who have deliberately chosen to ignore
+     the warning about it.
+
+     The restrictions on 'offsetof' may be relaxed in a future version
+     of the C++ standard.
+
+'-Wno-int-to-pointer-cast'
+     Suppress warnings from casts to pointer type of an integer of a
+     different size.  In C++, casting to a pointer type of smaller size
+     is an error.  'Wint-to-pointer-cast' is enabled by default.
+
+'-Wno-pointer-to-int-cast (C and Objective-C only)'
+     Suppress warnings from casts from a pointer to an integer type of a
+     different size.
+
+'-Winvalid-pch'
+     Warn if a precompiled header (*note Precompiled Headers::) is found
+     in the search path but can't be used.
+
+'-Wlong-long'
+     Warn if 'long long' type is used.  This is enabled by either
+     '-Wpedantic' or '-Wtraditional' in ISO C90 and C++98 modes.  To
+     inhibit the warning messages, use '-Wno-long-long'.
+
+'-Wvariadic-macros'
+     Warn if variadic macros are used in pedantic ISO C90 mode, or the
+     GNU alternate syntax when in pedantic ISO C99 mode.  This is
+     default.  To inhibit the warning messages, use
+     '-Wno-variadic-macros'.
+
+'-Wvarargs'
+     Warn upon questionable usage of the macros used to handle variable
+     arguments like 'va_start'.  This is default.  To inhibit the
+     warning messages, use '-Wno-varargs'.
+
+'-Wvector-operation-performance'
+     Warn if vector operation is not implemented via SIMD capabilities
+     of the architecture.  Mainly useful for the performance tuning.
+     Vector operation can be implemented 'piecewise', which means that
+     the scalar operation is performed on every vector element; 'in
+     parallel', which means that the vector operation is implemented
+     using scalars of wider type, which normally is more performance
+     efficient; and 'as a single scalar', which means that vector fits
+     into a scalar type.
+
+'-Wno-virtual-move-assign'
+     Suppress warnings about inheriting from a virtual base with a
+     non-trivial C++11 move assignment operator.  This is dangerous
+     because if the virtual base is reachable along more than one path,
+     it will be moved multiple times, which can mean both objects end up
+     in the moved-from state.  If the move assignment operator is
+     written to avoid moving from a moved-from object, this warning can
+     be disabled.
+
+'-Wvla'
+     Warn if variable length array is used in the code.  '-Wno-vla'
+     prevents the '-Wpedantic' warning of the variable length array.
+
+'-Wvolatile-register-var'
+     Warn if a register variable is declared volatile.  The volatile
+     modifier does not inhibit all optimizations that may eliminate
+     reads and/or writes to register variables.  This warning is enabled
+     by '-Wall'.
+
+'-Wdisabled-optimization'
+     Warn if a requested optimization pass is disabled.  This warning
+     does not generally indicate that there is anything wrong with your
+     code; it merely indicates that GCC's optimizers are unable to
+     handle the code effectively.  Often, the problem is that your code
+     is too big or too complex; GCC refuses to optimize programs when
+     the optimization itself is likely to take inordinate amounts of
+     time.
+
+'-Wpointer-sign (C and Objective-C only)'
+     Warn for pointer argument passing or assignment with different
+     signedness.  This option is only supported for C and Objective-C.
+     It is implied by '-Wall' and by '-Wpedantic', which can be disabled
+     with '-Wno-pointer-sign'.
+
+'-Wstack-protector'
+     This option is only active when '-fstack-protector' is active.  It
+     warns about functions that are not protected against stack
+     smashing.
+
+'-Woverlength-strings'
+     Warn about string constants that are longer than the "minimum
+     maximum" length specified in the C standard.  Modern compilers
+     generally allow string constants that are much longer than the
+     standard's minimum limit, but very portable programs should avoid
+     using longer strings.
+
+     The limit applies _after_ string constant concatenation, and does
+     not count the trailing NUL.  In C90, the limit was 509 characters;
+     in C99, it was raised to 4095.  C++98 does not specify a normative
+     minimum maximum, so we do not diagnose overlength strings in C++.
+
+     This option is implied by '-Wpedantic', and can be disabled with
+     '-Wno-overlength-strings'.
+
+'-Wunsuffixed-float-constants (C and Objective-C only)'
+
+     Issue a warning for any floating constant that does not have a
+     suffix.  When used together with '-Wsystem-headers' it warns about
+     such constants in system header files.  This can be useful when
+     preparing code to use with the 'FLOAT_CONST_DECIMAL64' pragma from
+     the decimal floating-point extension to C99.
+
+
+File: gcc.info,  Node: Debugging Options,  Next: Optimize Options,  Prev: Warning Options,  Up: Invoking GCC
+
+3.9 Options for Debugging Your Program or GCC
+=============================================
+
+GCC has various special options that are used for debugging either your
+program or GCC:
+
+'-g'
+     Produce debugging information in the operating system's native
+     format (stabs, COFF, XCOFF, or DWARF 2).  GDB can work with this
+     debugging information.
+
+     On most systems that use stabs format, '-g' enables use of extra
+     debugging information that only GDB can use; this extra information
+     makes debugging work better in GDB but probably makes other
+     debuggers crash or refuse to read the program.  If you want to
+     control for certain whether to generate the extra information, use
+     '-gstabs+', '-gstabs', '-gxcoff+', '-gxcoff', or '-gvms' (see
+     below).
+
+     GCC allows you to use '-g' with '-O'.  The shortcuts taken by
+     optimized code may occasionally produce surprising results: some
+     variables you declared may not exist at all; flow of control may
+     briefly move where you did not expect it; some statements may not
+     be executed because they compute constant results or their values
+     are already at hand; some statements may execute in different
+     places because they have been moved out of loops.
+
+     Nevertheless it proves possible to debug optimized output.  This
+     makes it reasonable to use the optimizer for programs that might
+     have bugs.
+
+     The following options are useful when GCC is generated with the
+     capability for more than one debugging format.
+
+'-gsplit-dwarf'
+     Separate as much dwarf debugging information as possible into a
+     separate output file with the extension .dwo.  This option allows
+     the build system to avoid linking files with debug information.  To
+     be useful, this option requires a debugger capable of reading .dwo
+     files.
+
+'-ggdb'
+     Produce debugging information for use by GDB.  This means to use
+     the most expressive format available (DWARF 2, stabs, or the native
+     format if neither of those are supported), including GDB extensions
+     if at all possible.
+
+'-gpubnames'
+     Generate dwarf .debug_pubnames and .debug_pubtypes sections.
+
+'-ggnu-pubnames'
+     Generate .debug_pubnames and .debug_pubtypes sections in a format
+     suitable for conversion into a GDB index.  This option is only
+     useful with a linker that can produce GDB index version 7.
+
+'-gstabs'
+     Produce debugging information in stabs format (if that is
+     supported), without GDB extensions.  This is the format used by DBX
+     on most BSD systems.  On MIPS, Alpha and System V Release 4 systems
+     this option produces stabs debugging output that is not understood
+     by DBX or SDB.  On System V Release 4 systems this option requires
+     the GNU assembler.
+
+'-feliminate-unused-debug-symbols'
+     Produce debugging information in stabs format (if that is
+     supported), for only symbols that are actually used.
+
+'-femit-class-debug-always'
+     Instead of emitting debugging information for a C++ class in only
+     one object file, emit it in all object files using the class.  This
+     option should be used only with debuggers that are unable to handle
+     the way GCC normally emits debugging information for classes
+     because using this option increases the size of debugging
+     information by as much as a factor of two.
+
+'-fdebug-types-section'
+     When using DWARF Version 4 or higher, type DIEs can be put into
+     their own '.debug_types' section instead of making them part of the
+     '.debug_info' section.  It is more efficient to put them in a
+     separate comdat sections since the linker can then remove
+     duplicates.  But not all DWARF consumers support '.debug_types'
+     sections yet and on some objects '.debug_types' produces larger
+     instead of smaller debugging information.
+
+'-gstabs+'
+     Produce debugging information in stabs format (if that is
+     supported), using GNU extensions understood only by the GNU
+     debugger (GDB).  The use of these extensions is likely to make
+     other debuggers crash or refuse to read the program.
+
+'-gcoff'
+     Produce debugging information in COFF format (if that is
+     supported).  This is the format used by SDB on most System V
+     systems prior to System V Release 4.
+
+'-gxcoff'
+     Produce debugging information in XCOFF format (if that is
+     supported).  This is the format used by the DBX debugger on IBM
+     RS/6000 systems.
+
+'-gxcoff+'
+     Produce debugging information in XCOFF format (if that is
+     supported), using GNU extensions understood only by the GNU
+     debugger (GDB).  The use of these extensions is likely to make
+     other debuggers crash or refuse to read the program, and may cause
+     assemblers other than the GNU assembler (GAS) to fail with an
+     error.
+
+'-gdwarf-VERSION'
+     Produce debugging information in DWARF format (if that is
+     supported).  The value of VERSION may be either 2, 3 or 4; the
+     default version for most targets is 4.
+
+     Note that with DWARF Version 2, some ports require and always use
+     some non-conflicting DWARF 3 extensions in the unwind tables.
+
+     Version 4 may require GDB 7.0 and '-fvar-tracking-assignments' for
+     maximum benefit.
+
+'-grecord-gcc-switches'
+     This switch causes the command-line options used to invoke the
+     compiler that may affect code generation to be appended to the
+     DW_AT_producer attribute in DWARF debugging information.  The
+     options are concatenated with spaces separating them from each
+     other and from the compiler version.  See also
+     '-frecord-gcc-switches' for another way of storing compiler options
+     into the object file.  This is the default.
+
+'-gno-record-gcc-switches'
+     Disallow appending command-line options to the DW_AT_producer
+     attribute in DWARF debugging information.
+
+'-gstrict-dwarf'
+     Disallow using extensions of later DWARF standard version than
+     selected with '-gdwarf-VERSION'.  On most targets using
+     non-conflicting DWARF extensions from later standard versions is
+     allowed.
+
+'-gno-strict-dwarf'
+     Allow using extensions of later DWARF standard version than
+     selected with '-gdwarf-VERSION'.
+
+'-gvms'
+     Produce debugging information in Alpha/VMS debug format (if that is
+     supported).  This is the format used by DEBUG on Alpha/VMS systems.
+
+'-gLEVEL'
+'-ggdbLEVEL'
+'-gstabsLEVEL'
+'-gcoffLEVEL'
+'-gxcoffLEVEL'
+'-gvmsLEVEL'
+     Request debugging information and also use LEVEL to specify how
+     much information.  The default level is 2.
+
+     Level 0 produces no debug information at all.  Thus, '-g0' negates
+     '-g'.
+
+     Level 1 produces minimal information, enough for making backtraces
+     in parts of the program that you don't plan to debug.  This
+     includes descriptions of functions and external variables, and line
+     number tables, but no information about local variables.
+
+     Level 3 includes extra information, such as all the macro
+     definitions present in the program.  Some debuggers support macro
+     expansion when you use '-g3'.
+
+     '-gdwarf-2' does not accept a concatenated debug level, because GCC
+     used to support an option '-gdwarf' that meant to generate debug
+     information in version 1 of the DWARF format (which is very
+     different from version 2), and it would have been too confusing.
+     That debug format is long obsolete, but the option cannot be
+     changed now.  Instead use an additional '-gLEVEL' option to change
+     the debug level for DWARF.
+
+'-gtoggle'
+     Turn off generation of debug info, if leaving out this option
+     generates it, or turn it on at level 2 otherwise.  The position of
+     this argument in the command line does not matter; it takes effect
+     after all other options are processed, and it does so only once, no
+     matter how many times it is given.  This is mainly intended to be
+     used with '-fcompare-debug'.
+
+'-fsanitize=address'
+     Enable AddressSanitizer, a fast memory error detector.  Memory
+     access instructions will be instrumented to detect out-of-bounds
+     and use-after-free bugs.  See
+     <http://code.google.com/p/address-sanitizer/> for more details.
+     The run-time behavior can be influenced using the 'ASAN_OPTIONS'
+     environment variable; see
+     <https://code.google.com/p/address-sanitizer/wiki/Flags#Run-time_flags>
+     for a list of supported options.
+
+'-fsanitize=thread'
+     Enable ThreadSanitizer, a fast data race detector.  Memory access
+     instructions will be instrumented to detect data race bugs.  See
+     <http://code.google.com/p/thread-sanitizer/> for more details.  The
+     run-time behavior can be influenced using the 'TSAN_OPTIONS'
+     environment variable; see
+     <https://code.google.com/p/thread-sanitizer/wiki/Flags> for a list
+     of supported options.
+
+'-fsanitize=leak'
+     Enable LeakSanitizer, a memory leak detector.  This option only
+     matters for linking of executables and if neither
+     '-fsanitize=address' nor '-fsanitize=thread' is used.  In that case
+     it will link the executable against a library that overrides
+     'malloc' and other allocator functions.  See
+     <https://code.google.com/p/address-sanitizer/wiki/LeakSanitizer>
+     for more details.  The run-time behavior can be influenced using
+     the 'LSAN_OPTIONS' environment variable.
+
+'-fsanitize=undefined'
+     Enable UndefinedBehaviorSanitizer, a fast undefined behavior
+     detector.  Various computations will be instrumented to detect
+     undefined behavior at runtime.  Current suboptions are:
+
+     '-fsanitize=shift'
+
+          This option enables checking that the result of a shift
+          operation is not undefined.  Note that what exactly is
+          considered undefined differs slightly between C and C++, as
+          well as between ISO C90 and C99, etc.
+
+     '-fsanitize=integer-divide-by-zero'
+
+          Detect integer division by zero as well as 'INT_MIN / -1'
+          division.
+
+     '-fsanitize=unreachable'
+
+          With this option, the compiler will turn the
+          '__builtin_unreachable' call into a diagnostics message call
+          instead.  When reaching the '__builtin_unreachable' call, the
+          behavior is undefined.
+
+     '-fsanitize=vla-bound'
+
+          This option instructs the compiler to check that the size of a
+          variable length array is positive.  This option does not have
+          any effect in '-std=c++1y' mode, as the standard requires the
+          exception be thrown instead.
+
+     '-fsanitize=null'
+
+          This option enables pointer checking.  Particularly, the
+          application built with this option turned on will issue an
+          error message when it tries to dereference a NULL pointer, or
+          if a reference (possibly an rvalue reference) is bound to a
+          NULL pointer.
+
+     '-fsanitize=return'
+
+          This option enables return statement checking.  Programs built
+          with this option turned on will issue an error message when
+          the end of a non-void function is reached without actually
+          returning a value.  This option works in C++ only.
+
+     '-fsanitize=signed-integer-overflow'
+
+          This option enables signed integer overflow checking.  We
+          check that the result of '+', '*', and both unary and binary
+          '-' does not overflow in the signed arithmetics.  Note,
+          integer promotion rules must be taken into account.  That is,
+          the following is not an overflow:
+               signed char a = SCHAR_MAX;
+               a++;
+
+     While '-ftrapv' causes traps for signed overflows to be emitted,
+     '-fsanitize=undefined' gives a diagnostic message.  This currently
+     works only for the C family of languages.
+
+'-fdump-final-insns[=FILE]'
+     Dump the final internal representation (RTL) to FILE.  If the
+     optional argument is omitted (or if FILE is '.'), the name of the
+     dump file is determined by appending '.gkd' to the compilation
+     output file name.
+
+'-fcompare-debug[=OPTS]'
+     If no error occurs during compilation, run the compiler a second
+     time, adding OPTS and '-fcompare-debug-second' to the arguments
+     passed to the second compilation.  Dump the final internal
+     representation in both compilations, and print an error if they
+     differ.
+
+     If the equal sign is omitted, the default '-gtoggle' is used.
+
+     The environment variable 'GCC_COMPARE_DEBUG', if defined, non-empty
+     and nonzero, implicitly enables '-fcompare-debug'.  If
+     'GCC_COMPARE_DEBUG' is defined to a string starting with a dash,
+     then it is used for OPTS, otherwise the default '-gtoggle' is used.
+
+     '-fcompare-debug=', with the equal sign but without OPTS, is
+     equivalent to '-fno-compare-debug', which disables the dumping of
+     the final representation and the second compilation, preventing
+     even 'GCC_COMPARE_DEBUG' from taking effect.
+
+     To verify full coverage during '-fcompare-debug' testing, set
+     'GCC_COMPARE_DEBUG' to say '-fcompare-debug-not-overridden', which
+     GCC rejects as an invalid option in any actual compilation (rather
+     than preprocessing, assembly or linking).  To get just a warning,
+     setting 'GCC_COMPARE_DEBUG' to '-w%n-fcompare-debug not overridden'
+     will do.
+
+'-fcompare-debug-second'
+     This option is implicitly passed to the compiler for the second
+     compilation requested by '-fcompare-debug', along with options to
+     silence warnings, and omitting other options that would cause
+     side-effect compiler outputs to files or to the standard output.
+     Dump files and preserved temporary files are renamed so as to
+     contain the '.gk' additional extension during the second
+     compilation, to avoid overwriting those generated by the first.
+
+     When this option is passed to the compiler driver, it causes the
+     _first_ compilation to be skipped, which makes it useful for little
+     other than debugging the compiler proper.
+
+'-feliminate-dwarf2-dups'
+     Compress DWARF 2 debugging information by eliminating duplicated
+     information about each symbol.  This option only makes sense when
+     generating DWARF 2 debugging information with '-gdwarf-2'.
+
+'-femit-struct-debug-baseonly'
+     Emit debug information for struct-like types only when the base
+     name of the compilation source file matches the base name of file
+     in which the struct is defined.
+
+     This option substantially reduces the size of debugging
+     information, but at significant potential loss in type information
+     to the debugger.  See '-femit-struct-debug-reduced' for a less
+     aggressive option.  See '-femit-struct-debug-detailed' for more
+     detailed control.
+
+     This option works only with DWARF 2.
+
+'-femit-struct-debug-reduced'
+     Emit debug information for struct-like types only when the base
+     name of the compilation source file matches the base name of file
+     in which the type is defined, unless the struct is a template or
+     defined in a system header.
+
+     This option significantly reduces the size of debugging
+     information, with some potential loss in type information to the
+     debugger.  See '-femit-struct-debug-baseonly' for a more aggressive
+     option.  See '-femit-struct-debug-detailed' for more detailed
+     control.
+
+     This option works only with DWARF 2.
+
+'-femit-struct-debug-detailed[=SPEC-LIST]'
+     Specify the struct-like types for which the compiler generates
+     debug information.  The intent is to reduce duplicate struct debug
+     information between different object files within the same program.
+
+     This option is a detailed version of '-femit-struct-debug-reduced'
+     and '-femit-struct-debug-baseonly', which serves for most needs.
+
+     A specification has the syntax
+     ['dir:'|'ind:']['ord:'|'gen:']('any'|'sys'|'base'|'none')
+
+     The optional first word limits the specification to structs that
+     are used directly ('dir:') or used indirectly ('ind:').  A struct
+     type is used directly when it is the type of a variable, member.
+     Indirect uses arise through pointers to structs.  That is, when use
+     of an incomplete struct is valid, the use is indirect.  An example
+     is 'struct one direct; struct two * indirect;'.
+
+     The optional second word limits the specification to ordinary
+     structs ('ord:') or generic structs ('gen:').  Generic structs are
+     a bit complicated to explain.  For C++, these are non-explicit
+     specializations of template classes, or non-template classes within
+     the above.  Other programming languages have generics, but
+     '-femit-struct-debug-detailed' does not yet implement them.
+
+     The third word specifies the source files for those structs for
+     which the compiler should emit debug information.  The values
+     'none' and 'any' have the normal meaning.  The value 'base' means
+     that the base of name of the file in which the type declaration
+     appears must match the base of the name of the main compilation
+     file.  In practice, this means that when compiling 'foo.c', debug
+     information is generated for types declared in that file and
+     'foo.h', but not other header files.  The value 'sys' means those
+     types satisfying 'base' or declared in system or compiler headers.
+
+     You may need to experiment to determine the best settings for your
+     application.
+
+     The default is '-femit-struct-debug-detailed=all'.
+
+     This option works only with DWARF 2.
+
+'-fno-merge-debug-strings'
+     Direct the linker to not merge together strings in the debugging
+     information that are identical in different object files.  Merging
+     is not supported by all assemblers or linkers.  Merging decreases
+     the size of the debug information in the output file at the cost of
+     increasing link processing time.  Merging is enabled by default.
+
+'-fdebug-prefix-map=OLD=NEW'
+     When compiling files in directory 'OLD', record debugging
+     information describing them as in 'NEW' instead.
+
+'-fno-dwarf2-cfi-asm'
+     Emit DWARF 2 unwind info as compiler generated '.eh_frame' section
+     instead of using GAS '.cfi_*' directives.
+
+'-p'
+     Generate extra code to write profile information suitable for the
+     analysis program 'prof'.  You must use this option when compiling
+     the source files you want data about, and you must also use it when
+     linking.
+
+'-pg'
+     Generate extra code to write profile information suitable for the
+     analysis program 'gprof'.  You must use this option when compiling
+     the source files you want data about, and you must also use it when
+     linking.
+
+'-Q'
+     Makes the compiler print out each function name as it is compiled,
+     and print some statistics about each pass when it finishes.
+
+'-ftime-report'
+     Makes the compiler print some statistics about the time consumed by
+     each pass when it finishes.
+
+'-fmem-report'
+     Makes the compiler print some statistics about permanent memory
+     allocation when it finishes.
+
+'-fmem-report-wpa'
+     Makes the compiler print some statistics about permanent memory
+     allocation for the WPA phase only.
+
+'-fpre-ipa-mem-report'
+'-fpost-ipa-mem-report'
+     Makes the compiler print some statistics about permanent memory
+     allocation before or after interprocedural optimization.
+
+'-fprofile-report'
+     Makes the compiler print some statistics about consistency of the
+     (estimated) profile and effect of individual passes.
+
+'-fstack-usage'
+     Makes the compiler output stack usage information for the program,
+     on a per-function basis.  The filename for the dump is made by
+     appending '.su' to the AUXNAME.  AUXNAME is generated from the name
+     of the output file, if explicitly specified and it is not an
+     executable, otherwise it is the basename of the source file.  An
+     entry is made up of three fields:
+
+        * The name of the function.
+        * A number of bytes.
+        * One or more qualifiers: 'static', 'dynamic', 'bounded'.
+
+     The qualifier 'static' means that the function manipulates the
+     stack statically: a fixed number of bytes are allocated for the
+     frame on function entry and released on function exit; no stack
+     adjustments are otherwise made in the function.  The second field
+     is this fixed number of bytes.
+
+     The qualifier 'dynamic' means that the function manipulates the
+     stack dynamically: in addition to the static allocation described
+     above, stack adjustments are made in the body of the function, for
+     example to push/pop arguments around function calls.  If the
+     qualifier 'bounded' is also present, the amount of these
+     adjustments is bounded at compile time and the second field is an
+     upper bound of the total amount of stack used by the function.  If
+     it is not present, the amount of these adjustments is not bounded
+     at compile time and the second field only represents the bounded
+     part.
+
+'-fprofile-arcs'
+     Add code so that program flow "arcs" are instrumented.  During
+     execution the program records how many times each branch and call
+     is executed and how many times it is taken or returns.  When the
+     compiled program exits it saves this data to a file called
+     'AUXNAME.gcda' for each source file.  The data may be used for
+     profile-directed optimizations ('-fbranch-probabilities'), or for
+     test coverage analysis ('-ftest-coverage').  Each object file's
+     AUXNAME is generated from the name of the output file, if
+     explicitly specified and it is not the final executable, otherwise
+     it is the basename of the source file.  In both cases any suffix is
+     removed (e.g. 'foo.gcda' for input file 'dir/foo.c', or
+     'dir/foo.gcda' for output file specified as '-o dir/foo.o').  *Note
+     Cross-profiling::.
+
+'--coverage'
+
+     This option is used to compile and link code instrumented for
+     coverage analysis.  The option is a synonym for '-fprofile-arcs'
+     '-ftest-coverage' (when compiling) and '-lgcov' (when linking).
+     See the documentation for those options for more details.
+
+        * Compile the source files with '-fprofile-arcs' plus
+          optimization and code generation options.  For test coverage
+          analysis, use the additional '-ftest-coverage' option.  You do
+          not need to profile every source file in a program.
+
+        * Link your object files with '-lgcov' or '-fprofile-arcs' (the
+          latter implies the former).
+
+        * Run the program on a representative workload to generate the
+          arc profile information.  This may be repeated any number of
+          times.  You can run concurrent instances of your program, and
+          provided that the file system supports locking, the data files
+          will be correctly updated.  Also 'fork' calls are detected and
+          correctly handled (double counting will not happen).
+
+        * For profile-directed optimizations, compile the source files
+          again with the same optimization and code generation options
+          plus '-fbranch-probabilities' (*note Options that Control
+          Optimization: Optimize Options.).
+
+        * For test coverage analysis, use 'gcov' to produce human
+          readable information from the '.gcno' and '.gcda' files.
+          Refer to the 'gcov' documentation for further information.
+
+     With '-fprofile-arcs', for each function of your program GCC
+     creates a program flow graph, then finds a spanning tree for the
+     graph.  Only arcs that are not on the spanning tree have to be
+     instrumented: the compiler adds code to count the number of times
+     that these arcs are executed.  When an arc is the only exit or only
+     entrance to a block, the instrumentation code can be added to the
+     block; otherwise, a new basic block must be created to hold the
+     instrumentation code.
+
+'-ftest-coverage'
+     Produce a notes file that the 'gcov' code-coverage utility (*note
+     'gcov'--a Test Coverage Program: Gcov.) can use to show program
+     coverage.  Each source file's note file is called 'AUXNAME.gcno'.
+     Refer to the '-fprofile-arcs' option above for a description of
+     AUXNAME and instructions on how to generate test coverage data.
+     Coverage data matches the source files more closely if you do not
+     optimize.
+
+'-fdbg-cnt-list'
+     Print the name and the counter upper bound for all debug counters.
+
+'-fdbg-cnt=COUNTER-VALUE-LIST'
+     Set the internal debug counter upper bound.  COUNTER-VALUE-LIST is
+     a comma-separated list of NAME:VALUE pairs which sets the upper
+     bound of each debug counter NAME to VALUE.  All debug counters have
+     the initial upper bound of 'UINT_MAX'; thus 'dbg_cnt()' returns
+     true always unless the upper bound is set by this option.  For
+     example, with '-fdbg-cnt=dce:10,tail_call:0', 'dbg_cnt(dce)'
+     returns true only for first 10 invocations.
+
+'-fenable-KIND-PASS'
+'-fdisable-KIND-PASS=RANGE-LIST'
+
+     This is a set of options that are used to explicitly disable/enable
+     optimization passes.  These options are intended for use for
+     debugging GCC. Compiler users should use regular options for
+     enabling/disabling passes instead.
+
+     '-fdisable-ipa-PASS'
+          Disable IPA pass PASS.  PASS is the pass name.  If the same
+          pass is statically invoked in the compiler multiple times, the
+          pass name should be appended with a sequential number starting
+          from 1.
+
+     '-fdisable-rtl-PASS'
+     '-fdisable-rtl-PASS=RANGE-LIST'
+          Disable RTL pass PASS.  PASS is the pass name.  If the same
+          pass is statically invoked in the compiler multiple times, the
+          pass name should be appended with a sequential number starting
+          from 1.  RANGE-LIST is a comma-separated list of function
+          ranges or assembler names.  Each range is a number pair
+          separated by a colon.  The range is inclusive in both ends.
+          If the range is trivial, the number pair can be simplified as
+          a single number.  If the function's call graph node's UID
+          falls within one of the specified ranges, the PASS is disabled
+          for that function.  The UID is shown in the function header of
+          a dump file, and the pass names can be dumped by using option
+          '-fdump-passes'.
+
+     '-fdisable-tree-PASS'
+     '-fdisable-tree-PASS=RANGE-LIST'
+          Disable tree pass PASS.  See '-fdisable-rtl' for the
+          description of option arguments.
+
+     '-fenable-ipa-PASS'
+          Enable IPA pass PASS.  PASS is the pass name.  If the same
+          pass is statically invoked in the compiler multiple times, the
+          pass name should be appended with a sequential number starting
+          from 1.
+
+     '-fenable-rtl-PASS'
+     '-fenable-rtl-PASS=RANGE-LIST'
+          Enable RTL pass PASS.  See '-fdisable-rtl' for option argument
+          description and examples.
+
+     '-fenable-tree-PASS'
+     '-fenable-tree-PASS=RANGE-LIST'
+          Enable tree pass PASS.  See '-fdisable-rtl' for the
+          description of option arguments.
+
+     Here are some examples showing uses of these options.
+
+
+          # disable ccp1 for all functions
+             -fdisable-tree-ccp1
+          # disable complete unroll for function whose cgraph node uid is 1
+             -fenable-tree-cunroll=1
+          # disable gcse2 for functions at the following ranges [1,1],
+          # [300,400], and [400,1000]
+          # disable gcse2 for functions foo and foo2
+             -fdisable-rtl-gcse2=foo,foo2
+          # disable early inlining
+             -fdisable-tree-einline
+          # disable ipa inlining
+             -fdisable-ipa-inline
+          # enable tree full unroll
+             -fenable-tree-unroll
+
+'-dLETTERS'
+'-fdump-rtl-PASS'
+'-fdump-rtl-PASS=FILENAME'
+     Says to make debugging dumps during compilation at times specified
+     by LETTERS.  This is used for debugging the RTL-based passes of the
+     compiler.  The file names for most of the dumps are made by
+     appending a pass number and a word to the DUMPNAME, and the files
+     are created in the directory of the output file.  In case of
+     '=FILENAME' option, the dump is output on the given file instead of
+     the pass numbered dump files.  Note that the pass number is
+     computed statically as passes get registered into the pass manager.
+     Thus the numbering is not related to the dynamic order of execution
+     of passes.  In particular, a pass installed by a plugin could have
+     a number over 200 even if it executed quite early.  DUMPNAME is
+     generated from the name of the output file, if explicitly specified
+     and it is not an executable, otherwise it is the basename of the
+     source file.  These switches may have different effects when '-E'
+     is used for preprocessing.
+
+     Debug dumps can be enabled with a '-fdump-rtl' switch or some '-d'
+     option LETTERS.  Here are the possible letters for use in PASS and
+     LETTERS, and their meanings:
+
+     '-fdump-rtl-alignments'
+          Dump after branch alignments have been computed.
+
+     '-fdump-rtl-asmcons'
+          Dump after fixing rtl statements that have unsatisfied in/out
+          constraints.
+
+     '-fdump-rtl-auto_inc_dec'
+          Dump after auto-inc-dec discovery.  This pass is only run on
+          architectures that have auto inc or auto dec instructions.
+
+     '-fdump-rtl-barriers'
+          Dump after cleaning up the barrier instructions.
+
+     '-fdump-rtl-bbpart'
+          Dump after partitioning hot and cold basic blocks.
+
+     '-fdump-rtl-bbro'
+          Dump after block reordering.
+
+     '-fdump-rtl-btl1'
+     '-fdump-rtl-btl2'
+          '-fdump-rtl-btl1' and '-fdump-rtl-btl2' enable dumping after
+          the two branch target load optimization passes.
+
+     '-fdump-rtl-bypass'
+          Dump after jump bypassing and control flow optimizations.
+
+     '-fdump-rtl-combine'
+          Dump after the RTL instruction combination pass.
+
+     '-fdump-rtl-compgotos'
+          Dump after duplicating the computed gotos.
+
+     '-fdump-rtl-ce1'
+     '-fdump-rtl-ce2'
+     '-fdump-rtl-ce3'
+          '-fdump-rtl-ce1', '-fdump-rtl-ce2', and '-fdump-rtl-ce3'
+          enable dumping after the three if conversion passes.
+
+     '-fdump-rtl-cprop_hardreg'
+          Dump after hard register copy propagation.
+
+     '-fdump-rtl-csa'
+          Dump after combining stack adjustments.
+
+     '-fdump-rtl-cse1'
+     '-fdump-rtl-cse2'
+          '-fdump-rtl-cse1' and '-fdump-rtl-cse2' enable dumping after
+          the two common subexpression elimination passes.
+
+     '-fdump-rtl-dce'
+          Dump after the standalone dead code elimination passes.
+
+     '-fdump-rtl-dbr'
+          Dump after delayed branch scheduling.
+
+     '-fdump-rtl-dce1'
+     '-fdump-rtl-dce2'
+          '-fdump-rtl-dce1' and '-fdump-rtl-dce2' enable dumping after
+          the two dead store elimination passes.
+
+     '-fdump-rtl-eh'
+          Dump after finalization of EH handling code.
+
+     '-fdump-rtl-eh_ranges'
+          Dump after conversion of EH handling range regions.
+
+     '-fdump-rtl-expand'
+          Dump after RTL generation.
+
+     '-fdump-rtl-fwprop1'
+     '-fdump-rtl-fwprop2'
+          '-fdump-rtl-fwprop1' and '-fdump-rtl-fwprop2' enable dumping
+          after the two forward propagation passes.
+
+     '-fdump-rtl-gcse1'
+     '-fdump-rtl-gcse2'
+          '-fdump-rtl-gcse1' and '-fdump-rtl-gcse2' enable dumping after
+          global common subexpression elimination.
+
+     '-fdump-rtl-init-regs'
+          Dump after the initialization of the registers.
+
+     '-fdump-rtl-initvals'
+          Dump after the computation of the initial value sets.
+
+     '-fdump-rtl-into_cfglayout'
+          Dump after converting to cfglayout mode.
+
+     '-fdump-rtl-ira'
+          Dump after iterated register allocation.
+
+     '-fdump-rtl-jump'
+          Dump after the second jump optimization.
+
+     '-fdump-rtl-loop2'
+          '-fdump-rtl-loop2' enables dumping after the rtl loop
+          optimization passes.
+
+     '-fdump-rtl-mach'
+          Dump after performing the machine dependent reorganization
+          pass, if that pass exists.
+
+     '-fdump-rtl-mode_sw'
+          Dump after removing redundant mode switches.
+
+     '-fdump-rtl-rnreg'
+          Dump after register renumbering.
+
+     '-fdump-rtl-outof_cfglayout'
+          Dump after converting from cfglayout mode.
+
+     '-fdump-rtl-peephole2'
+          Dump after the peephole pass.
+
+     '-fdump-rtl-postreload'
+          Dump after post-reload optimizations.
+
+     '-fdump-rtl-pro_and_epilogue'
+          Dump after generating the function prologues and epilogues.
+
+     '-fdump-rtl-sched1'
+     '-fdump-rtl-sched2'
+          '-fdump-rtl-sched1' and '-fdump-rtl-sched2' enable dumping
+          after the basic block scheduling passes.
+
+     '-fdump-rtl-ree'
+          Dump after sign/zero extension elimination.
+
+     '-fdump-rtl-seqabstr'
+          Dump after common sequence discovery.
+
+     '-fdump-rtl-shorten'
+          Dump after shortening branches.
+
+     '-fdump-rtl-sibling'
+          Dump after sibling call optimizations.
+
+     '-fdump-rtl-split1'
+     '-fdump-rtl-split2'
+     '-fdump-rtl-split3'
+     '-fdump-rtl-split4'
+     '-fdump-rtl-split5'
+          '-fdump-rtl-split1', '-fdump-rtl-split2', '-fdump-rtl-split3',
+          '-fdump-rtl-split4' and '-fdump-rtl-split5' enable dumping
+          after five rounds of instruction splitting.
+
+     '-fdump-rtl-sms'
+          Dump after modulo scheduling.  This pass is only run on some
+          architectures.
+
+     '-fdump-rtl-stack'
+          Dump after conversion from GCC's "flat register file"
+          registers to the x87's stack-like registers.  This pass is
+          only run on x86 variants.
+
+     '-fdump-rtl-subreg1'
+     '-fdump-rtl-subreg2'
+          '-fdump-rtl-subreg1' and '-fdump-rtl-subreg2' enable dumping
+          after the two subreg expansion passes.
+
+     '-fdump-rtl-unshare'
+          Dump after all rtl has been unshared.
+
+     '-fdump-rtl-vartrack'
+          Dump after variable tracking.
+
+     '-fdump-rtl-vregs'
+          Dump after converting virtual registers to hard registers.
+
+     '-fdump-rtl-web'
+          Dump after live range splitting.
+
+     '-fdump-rtl-regclass'
+     '-fdump-rtl-subregs_of_mode_init'
+     '-fdump-rtl-subregs_of_mode_finish'
+     '-fdump-rtl-dfinit'
+     '-fdump-rtl-dfinish'
+          These dumps are defined but always produce empty files.
+
+     '-da'
+     '-fdump-rtl-all'
+          Produce all the dumps listed above.
+
+     '-dA'
+          Annotate the assembler output with miscellaneous debugging
+          information.
+
+     '-dD'
+          Dump all macro definitions, at the end of preprocessing, in
+          addition to normal output.
+
+     '-dH'
+          Produce a core dump whenever an error occurs.
+
+     '-dp'
+          Annotate the assembler output with a comment indicating which
+          pattern and alternative is used.  The length of each
+          instruction is also printed.
+
+     '-dP'
+          Dump the RTL in the assembler output as a comment before each
+          instruction.  Also turns on '-dp' annotation.
+
+     '-dx'
+          Just generate RTL for a function instead of compiling it.
+          Usually used with '-fdump-rtl-expand'.
+
+'-fdump-noaddr'
+     When doing debugging dumps, suppress address output.  This makes it
+     more feasible to use diff on debugging dumps for compiler
+     invocations with different compiler binaries and/or different text
+     / bss / data / heap / stack / dso start locations.
+
+'-fdump-unnumbered'
+     When doing debugging dumps, suppress instruction numbers and
+     address output.  This makes it more feasible to use diff on
+     debugging dumps for compiler invocations with different options, in
+     particular with and without '-g'.
+
+'-fdump-unnumbered-links'
+     When doing debugging dumps (see '-d' option above), suppress
+     instruction numbers for the links to the previous and next
+     instructions in a sequence.
+
+'-fdump-translation-unit (C++ only)'
+'-fdump-translation-unit-OPTIONS (C++ only)'
+     Dump a representation of the tree structure for the entire
+     translation unit to a file.  The file name is made by appending
+     '.tu' to the source file name, and the file is created in the same
+     directory as the output file.  If the '-OPTIONS' form is used,
+     OPTIONS controls the details of the dump as described for the
+     '-fdump-tree' options.
+
+'-fdump-class-hierarchy (C++ only)'
+'-fdump-class-hierarchy-OPTIONS (C++ only)'
+     Dump a representation of each class's hierarchy and virtual
+     function table layout to a file.  The file name is made by
+     appending '.class' to the source file name, and the file is created
+     in the same directory as the output file.  If the '-OPTIONS' form
+     is used, OPTIONS controls the details of the dump as described for
+     the '-fdump-tree' options.
+
+'-fdump-ipa-SWITCH'
+     Control the dumping at various stages of inter-procedural analysis
+     language tree to a file.  The file name is generated by appending a
+     switch specific suffix to the source file name, and the file is
+     created in the same directory as the output file.  The following
+     dumps are possible:
+
+     'all'
+          Enables all inter-procedural analysis dumps.
+
+     'cgraph'
+          Dumps information about call-graph optimization, unused
+          function removal, and inlining decisions.
+
+     'inline'
+          Dump after function inlining.
+
+'-fdump-passes'
+     Dump the list of optimization passes that are turned on and off by
+     the current command-line options.
+
+'-fdump-statistics-OPTION'
+     Enable and control dumping of pass statistics in a separate file.
+     The file name is generated by appending a suffix ending in
+     '.statistics' to the source file name, and the file is created in
+     the same directory as the output file.  If the '-OPTION' form is
+     used, '-stats' causes counters to be summed over the whole
+     compilation unit while '-details' dumps every event as the passes
+     generate them.  The default with no option is to sum counters for
+     each function compiled.
+
+'-fdump-tree-SWITCH'
+'-fdump-tree-SWITCH-OPTIONS'
+'-fdump-tree-SWITCH-OPTIONS=FILENAME'
+     Control the dumping at various stages of processing the
+     intermediate language tree to a file.  The file name is generated
+     by appending a switch-specific suffix to the source file name, and
+     the file is created in the same directory as the output file.  In
+     case of '=FILENAME' option, the dump is output on the given file
+     instead of the auto named dump files.  If the '-OPTIONS' form is
+     used, OPTIONS is a list of '-' separated options which control the
+     details of the dump.  Not all options are applicable to all dumps;
+     those that are not meaningful are ignored.  The following options
+     are available
+
+     'address'
+          Print the address of each node.  Usually this is not
+          meaningful as it changes according to the environment and
+          source file.  Its primary use is for tying up a dump file with
+          a debug environment.
+     'asmname'
+          If 'DECL_ASSEMBLER_NAME' has been set for a given decl, use
+          that in the dump instead of 'DECL_NAME'.  Its primary use is
+          ease of use working backward from mangled names in the
+          assembly file.
+     'slim'
+          When dumping front-end intermediate representations, inhibit
+          dumping of members of a scope or body of a function merely
+          because that scope has been reached.  Only dump such items
+          when they are directly reachable by some other path.
+
+          When dumping pretty-printed trees, this option inhibits
+          dumping the bodies of control structures.
+
+          When dumping RTL, print the RTL in slim (condensed) form
+          instead of the default LISP-like representation.
+     'raw'
+          Print a raw representation of the tree.  By default, trees are
+          pretty-printed into a C-like representation.
+     'details'
+          Enable more detailed dumps (not honored by every dump option).
+          Also include information from the optimization passes.
+     'stats'
+          Enable dumping various statistics about the pass (not honored
+          by every dump option).
+     'blocks'
+          Enable showing basic block boundaries (disabled in raw dumps).
+     'graph'
+          For each of the other indicated dump files
+          ('-fdump-rtl-PASS'), dump a representation of the control flow
+          graph suitable for viewing with GraphViz to
+          'FILE.PASSID.PASS.dot'.  Each function in the file is
+          pretty-printed as a subgraph, so that GraphViz can render them
+          all in a single plot.
+
+          This option currently only works for RTL dumps, and the RTL is
+          always dumped in slim form.
+     'vops'
+          Enable showing virtual operands for every statement.
+     'lineno'
+          Enable showing line numbers for statements.
+     'uid'
+          Enable showing the unique ID ('DECL_UID') for each variable.
+     'verbose'
+          Enable showing the tree dump for each statement.
+     'eh'
+          Enable showing the EH region number holding each statement.
+     'scev'
+          Enable showing scalar evolution analysis details.
+     'optimized'
+          Enable showing optimization information (only available in
+          certain passes).
+     'missed'
+          Enable showing missed optimization information (only available
+          in certain passes).
+     'notes'
+          Enable other detailed optimization information (only available
+          in certain passes).
+     '=FILENAME'
+          Instead of an auto named dump file, output into the given file
+          name.  The file names 'stdout' and 'stderr' are treated
+          specially and are considered already open standard streams.
+          For example,
+
+               gcc -O2 -ftree-vectorize -fdump-tree-vect-blocks=foo.dump
+                    -fdump-tree-pre=stderr file.c
+
+          outputs vectorizer dump into 'foo.dump', while the PRE dump is
+          output on to 'stderr'.  If two conflicting dump filenames are
+          given for the same pass, then the latter option overrides the
+          earlier one.
+
+     'all'
+          Turn on all options, except 'raw', 'slim', 'verbose' and
+          'lineno'.
+
+     'optall'
+          Turn on all optimization options, i.e., 'optimized', 'missed',
+          and 'note'.
+
+     The following tree dumps are possible:
+
+     'original'
+          Dump before any tree based optimization, to 'FILE.original'.
+
+     'optimized'
+          Dump after all tree based optimization, to 'FILE.optimized'.
+
+     'gimple'
+          Dump each function before and after the gimplification pass to
+          a file.  The file name is made by appending '.gimple' to the
+          source file name.
+
+     'cfg'
+          Dump the control flow graph of each function to a file.  The
+          file name is made by appending '.cfg' to the source file name.
+
+     'ch'
+          Dump each function after copying loop headers.  The file name
+          is made by appending '.ch' to the source file name.
+
+     'ssa'
+          Dump SSA related information to a file.  The file name is made
+          by appending '.ssa' to the source file name.
+
+     'alias'
+          Dump aliasing information for each function.  The file name is
+          made by appending '.alias' to the source file name.
+
+     'ccp'
+          Dump each function after CCP.  The file name is made by
+          appending '.ccp' to the source file name.
+
+     'storeccp'
+          Dump each function after STORE-CCP.  The file name is made by
+          appending '.storeccp' to the source file name.
+
+     'pre'
+          Dump trees after partial redundancy elimination.  The file
+          name is made by appending '.pre' to the source file name.
+
+     'fre'
+          Dump trees after full redundancy elimination.  The file name
+          is made by appending '.fre' to the source file name.
+
+     'copyprop'
+          Dump trees after copy propagation.  The file name is made by
+          appending '.copyprop' to the source file name.
+
+     'store_copyprop'
+          Dump trees after store copy-propagation.  The file name is
+          made by appending '.store_copyprop' to the source file name.
+
+     'dce'
+          Dump each function after dead code elimination.  The file name
+          is made by appending '.dce' to the source file name.
+
+     'sra'
+          Dump each function after performing scalar replacement of
+          aggregates.  The file name is made by appending '.sra' to the
+          source file name.
+
+     'sink'
+          Dump each function after performing code sinking.  The file
+          name is made by appending '.sink' to the source file name.
+
+     'dom'
+          Dump each function after applying dominator tree
+          optimizations.  The file name is made by appending '.dom' to
+          the source file name.
+
+     'dse'
+          Dump each function after applying dead store elimination.  The
+          file name is made by appending '.dse' to the source file name.
+
+     'phiopt'
+          Dump each function after optimizing PHI nodes into
+          straightline code.  The file name is made by appending
+          '.phiopt' to the source file name.
+
+     'forwprop'
+          Dump each function after forward propagating single use
+          variables.  The file name is made by appending '.forwprop' to
+          the source file name.
+
+     'copyrename'
+          Dump each function after applying the copy rename
+          optimization.  The file name is made by appending
+          '.copyrename' to the source file name.
+
+     'nrv'
+          Dump each function after applying the named return value
+          optimization on generic trees.  The file name is made by
+          appending '.nrv' to the source file name.
+
+     'vect'
+          Dump each function after applying vectorization of loops.  The
+          file name is made by appending '.vect' to the source file
+          name.
+
+     'slp'
+          Dump each function after applying vectorization of basic
+          blocks.  The file name is made by appending '.slp' to the
+          source file name.
+
+     'vrp'
+          Dump each function after Value Range Propagation (VRP). The
+          file name is made by appending '.vrp' to the source file name.
+
+     'all'
+          Enable all the available tree dumps with the flags provided in
+          this option.
+
+'-fopt-info'
+'-fopt-info-OPTIONS'
+'-fopt-info-OPTIONS=FILENAME'
+     Controls optimization dumps from various optimization passes.  If
+     the '-OPTIONS' form is used, OPTIONS is a list of '-' separated
+     options to select the dump details and optimizations.  If OPTIONS
+     is not specified, it defaults to 'optimized' for details and
+     'optall' for optimization groups.  If the FILENAME is not
+     specified, it defaults to 'stderr'.  Note that the output FILENAME
+     will be overwritten in case of multiple translation units.  If a
+     combined output from multiple translation units is desired,
+     'stderr' should be used instead.
+
+     The options can be divided into two groups, 1) options describing
+     the verbosity of the dump, and 2) options describing which
+     optimizations should be included.  The options from both the groups
+     can be freely mixed as they are non-overlapping.  However, in case
+     of any conflicts, the latter options override the earlier options
+     on the command line.  Though multiple -fopt-info options are
+     accepted, only one of them can have '=filename'.  If other
+     filenames are provided then all but the first one are ignored.
+
+     The dump verbosity has the following options
+
+     'optimized'
+          Print information when an optimization is successfully
+          applied.  It is up to a pass to decide which information is
+          relevant.  For example, the vectorizer passes print the source
+          location of loops which got successfully vectorized.
+     'missed'
+          Print information about missed optimizations.  Individual
+          passes control which information to include in the output.
+          For example,
+
+               gcc -O2 -ftree-vectorize -fopt-info-vec-missed
+
+          will print information about missed optimization opportunities
+          from vectorization passes on stderr.
+     'note'
+          Print verbose information about optimizations, such as certain
+          transformations, more detailed messages about decisions etc.
+     'all'
+          Print detailed optimization information.  This includes
+          OPTIMIZED, MISSED, and NOTE.
+
+     The second set of options describes a group of optimizations and
+     may include one or more of the following.
+
+     'ipa'
+          Enable dumps from all interprocedural optimizations.
+     'loop'
+          Enable dumps from all loop optimizations.
+     'inline'
+          Enable dumps from all inlining optimizations.
+     'vec'
+          Enable dumps from all vectorization optimizations.
+     'optall'
+          Enable dumps from all optimizations.  This is a superset of
+          the optimization groups listed above.
+
+     For example,
+          gcc -O3 -fopt-info-missed=missed.all
+
+     outputs missed optimization report from all the passes into
+     'missed.all'.
+
+     As another example,
+          gcc -O3 -fopt-info-inline-optimized-missed=inline.txt
+
+     will output information about missed optimizations as well as
+     optimized locations from all the inlining passes into 'inline.txt'.
+
+     If the FILENAME is provided, then the dumps from all the applicable
+     optimizations are concatenated into the 'filename'.  Otherwise the
+     dump is output onto 'stderr'.  If OPTIONS is omitted, it defaults
+     to 'all-optall', which means dump all available optimization info
+     from all the passes.  In the following example, all optimization
+     info is output on to 'stderr'.
+
+          gcc -O3 -fopt-info
+
+     Note that '-fopt-info-vec-missed' behaves the same as
+     '-fopt-info-missed-vec'.
+
+     As another example, consider
+
+          gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt
+
+     Here the two output filenames 'vec.miss' and 'loop.opt' are in
+     conflict since only one output file is allowed.  In this case, only
+     the first option takes effect and the subsequent options are
+     ignored.  Thus only the 'vec.miss' is produced which contains dumps
+     from the vectorizer about missed opportunities.
+
+'-frandom-seed=STRING'
+     This option provides a seed that GCC uses in place of random
+     numbers in generating certain symbol names that have to be
+     different in every compiled file.  It is also used to place unique
+     stamps in coverage data files and the object files that produce
+     them.  You can use the '-frandom-seed' option to produce
+     reproducibly identical object files.
+
+     The STRING should be different for every file you compile.
+
+'-fsched-verbose=N'
+     On targets that use instruction scheduling, this option controls
+     the amount of debugging output the scheduler prints.  This
+     information is written to standard error, unless
+     '-fdump-rtl-sched1' or '-fdump-rtl-sched2' is specified, in which
+     case it is output to the usual dump listing file, '.sched1' or
+     '.sched2' respectively.  However for N greater than nine, the
+     output is always printed to standard error.
+
+     For N greater than zero, '-fsched-verbose' outputs the same
+     information as '-fdump-rtl-sched1' and '-fdump-rtl-sched2'.  For N
+     greater than one, it also output basic block probabilities,
+     detailed ready list information and unit/insn info.  For N greater
+     than two, it includes RTL at abort point, control-flow and regions
+     info.  And for N over four, '-fsched-verbose' also includes
+     dependence info.
+
+'-save-temps'
+'-save-temps=cwd'
+     Store the usual "temporary" intermediate files permanently; place
+     them in the current directory and name them based on the source
+     file.  Thus, compiling 'foo.c' with '-c -save-temps' produces files
+     'foo.i' and 'foo.s', as well as 'foo.o'.  This creates a
+     preprocessed 'foo.i' output file even though the compiler now
+     normally uses an integrated preprocessor.
+
+     When used in combination with the '-x' command-line option,
+     '-save-temps' is sensible enough to avoid over writing an input
+     source file with the same extension as an intermediate file.  The
+     corresponding intermediate file may be obtained by renaming the
+     source file before using '-save-temps'.
+
+     If you invoke GCC in parallel, compiling several different source
+     files that share a common base name in different subdirectories or
+     the same source file compiled for multiple output destinations, it
+     is likely that the different parallel compilers will interfere with
+     each other, and overwrite the temporary files.  For instance:
+
+          gcc -save-temps -o outdir1/foo.o indir1/foo.c&
+          gcc -save-temps -o outdir2/foo.o indir2/foo.c&
+
+     may result in 'foo.i' and 'foo.o' being written to simultaneously
+     by both compilers.
+
+'-save-temps=obj'
+     Store the usual "temporary" intermediate files permanently.  If the
+     '-o' option is used, the temporary files are based on the object
+     file.  If the '-o' option is not used, the '-save-temps=obj' switch
+     behaves like '-save-temps'.
+
+     For example:
+
+          gcc -save-temps=obj -c foo.c
+          gcc -save-temps=obj -c bar.c -o dir/xbar.o
+          gcc -save-temps=obj foobar.c -o dir2/yfoobar
+
+     creates 'foo.i', 'foo.s', 'dir/xbar.i', 'dir/xbar.s',
+     'dir2/yfoobar.i', 'dir2/yfoobar.s', and 'dir2/yfoobar.o'.
+
+'-time[=FILE]'
+     Report the CPU time taken by each subprocess in the compilation
+     sequence.  For C source files, this is the compiler proper and
+     assembler (plus the linker if linking is done).
+
+     Without the specification of an output file, the output looks like
+     this:
+
+          # cc1 0.12 0.01
+          # as 0.00 0.01
+
+     The first number on each line is the "user time", that is time
+     spent executing the program itself.  The second number is "system
+     time", time spent executing operating system routines on behalf of
+     the program.  Both numbers are in seconds.
+
+     With the specification of an output file, the output is appended to
+     the named file, and it looks like this:
+
+          0.12 0.01 cc1 OPTIONS
+          0.00 0.01 as OPTIONS
+
+     The "user time" and the "system time" are moved before the program
+     name, and the options passed to the program are displayed, so that
+     one can later tell what file was being compiled, and with which
+     options.
+
+'-fvar-tracking'
+     Run variable tracking pass.  It computes where variables are stored
+     at each position in code.  Better debugging information is then
+     generated (if the debugging information format supports this
+     information).
+
+     It is enabled by default when compiling with optimization ('-Os',
+     '-O', '-O2', ...), debugging information ('-g') and the debug info
+     format supports it.
+
+'-fvar-tracking-assignments'
+     Annotate assignments to user variables early in the compilation and
+     attempt to carry the annotations over throughout the compilation
+     all the way to the end, in an attempt to improve debug information
+     while optimizing.  Use of '-gdwarf-4' is recommended along with it.
+
+     It can be enabled even if var-tracking is disabled, in which case
+     annotations are created and maintained, but discarded at the end.
+
+'-fvar-tracking-assignments-toggle'
+     Toggle '-fvar-tracking-assignments', in the same way that
+     '-gtoggle' toggles '-g'.
+
+'-print-file-name=LIBRARY'
+     Print the full absolute name of the library file LIBRARY that would
+     be used when linking--and don't do anything else.  With this
+     option, GCC does not compile or link anything; it just prints the
+     file name.
+
+'-print-multi-directory'
+     Print the directory name corresponding to the multilib selected by
+     any other switches present in the command line.  This directory is
+     supposed to exist in 'GCC_EXEC_PREFIX'.
+
+'-print-multi-lib'
+     Print the mapping from multilib directory names to compiler
+     switches that enable them.  The directory name is separated from
+     the switches by ';', and each switch starts with an '@' instead of
+     the '-', without spaces between multiple switches.  This is
+     supposed to ease shell processing.
+
+'-print-multi-os-directory'
+     Print the path to OS libraries for the selected multilib, relative
+     to some 'lib' subdirectory.  If OS libraries are present in the
+     'lib' subdirectory and no multilibs are used, this is usually just
+     '.', if OS libraries are present in 'libSUFFIX' sibling directories
+     this prints e.g. '../lib64', '../lib' or '../lib32', or if OS
+     libraries are present in 'lib/SUBDIR' subdirectories it prints e.g.
+     'amd64', 'sparcv9' or 'ev6'.
+
+'-print-multiarch'
+     Print the path to OS libraries for the selected multiarch, relative
+     to some 'lib' subdirectory.
+
+'-print-prog-name=PROGRAM'
+     Like '-print-file-name', but searches for a program such as 'cpp'.
+
+'-print-libgcc-file-name'
+     Same as '-print-file-name=libgcc.a'.
+
+     This is useful when you use '-nostdlib' or '-nodefaultlibs' but you
+     do want to link with 'libgcc.a'.  You can do:
+
+          gcc -nostdlib FILES... `gcc -print-libgcc-file-name`
+
+'-print-search-dirs'
+     Print the name of the configured installation directory and a list
+     of program and library directories 'gcc' searches--and don't do
+     anything else.
+
+     This is useful when 'gcc' prints the error message 'installation
+     problem, cannot exec cpp0: No such file or directory'.  To resolve
+     this you either need to put 'cpp0' and the other compiler
+     components where 'gcc' expects to find them, or you can set the
+     environment variable 'GCC_EXEC_PREFIX' to the directory where you
+     installed them.  Don't forget the trailing '/'.  *Note Environment
+     Variables::.
+
+'-print-sysroot'
+     Print the target sysroot directory that is used during compilation.
+     This is the target sysroot specified either at configure time or
+     using the '--sysroot' option, possibly with an extra suffix that
+     depends on compilation options.  If no target sysroot is specified,
+     the option prints nothing.
+
+'-print-sysroot-headers-suffix'
+     Print the suffix added to the target sysroot when searching for
+     headers, or give an error if the compiler is not configured with
+     such a suffix--and don't do anything else.
+
+'-dumpmachine'
+     Print the compiler's target machine (for example,
+     'i686-pc-linux-gnu')--and don't do anything else.
+
+'-dumpversion'
+     Print the compiler version (for example, '3.0')--and don't do
+     anything else.
+
+'-dumpspecs'
+     Print the compiler's built-in specs--and don't do anything else.
+     (This is used when GCC itself is being built.)  *Note Spec Files::.
+
+'-fno-eliminate-unused-debug-types'
+     Normally, when producing DWARF 2 output, GCC avoids producing debug
+     symbol output for types that are nowhere used in the source file
+     being compiled.  Sometimes it is useful to have GCC emit debugging
+     information for all types declared in a compilation unit,
+     regardless of whether or not they are actually used in that
+     compilation unit, for example if, in the debugger, you want to cast
+     a value to a type that is not actually used in your program (but is
+     declared).  More often, however, this results in a significant
+     amount of wasted space.
+
+
+File: gcc.info,  Node: Optimize Options,  Next: Preprocessor Options,  Prev: Debugging Options,  Up: Invoking GCC
+
+3.10 Options That Control Optimization
+======================================
+
+These options control various sorts of optimizations.
+
+ Without any optimization option, the compiler's goal is to reduce the
+cost of compilation and to make debugging produce the expected results.
+Statements are independent: if you stop the program with a breakpoint
+between statements, you can then assign a new value to any variable or
+change the program counter to any other statement in the function and
+get exactly the results you expect from the source code.
+
+ Turning on optimization flags makes the compiler attempt to improve the
+performance and/or code size at the expense of compilation time and
+possibly the ability to debug the program.
+
+ The compiler performs optimization based on the knowledge it has of the
+program.  Compiling multiple files at once to a single output file mode
+allows the compiler to use information gained from all of the files when
+compiling each of them.
+
+ Not all optimizations are controlled directly by a flag.  Only
+optimizations that have a flag are listed in this section.
+
+ Most optimizations are only enabled if an '-O' level is set on the
+command line.  Otherwise they are disabled, even if individual
+optimization flags are specified.
+
+ Depending on the target and how GCC was configured, a slightly
+different set of optimizations may be enabled at each '-O' level than
+those listed here.  You can invoke GCC with '-Q --help=optimizers' to
+find out the exact set of optimizations that are enabled at each level.
+*Note Overall Options::, for examples.
+
+'-O'
+'-O1'
+     Optimize.  Optimizing compilation takes somewhat more time, and a
+     lot more memory for a large function.
+
+     With '-O', the compiler tries to reduce code size and execution
+     time, without performing any optimizations that take a great deal
+     of compilation time.
+
+     '-O' turns on the following optimization flags:
+          -fauto-inc-dec
+          -fcompare-elim
+          -fcprop-registers
+          -fdce
+          -fdefer-pop
+          -fdelayed-branch
+          -fdse
+          -fguess-branch-probability
+          -fif-conversion2
+          -fif-conversion
+          -fipa-pure-const
+          -fipa-profile
+          -fipa-reference
+          -fmerge-constants
+          -fsplit-wide-types
+          -ftree-bit-ccp
+          -ftree-builtin-call-dce
+          -ftree-ccp
+          -ftree-ch
+          -ftree-copyrename
+          -ftree-dce
+          -ftree-dominator-opts
+          -ftree-dse
+          -ftree-forwprop
+          -ftree-fre
+          -ftree-phiprop
+          -ftree-slsr
+          -ftree-sra
+          -ftree-pta
+          -ftree-ter
+          -funit-at-a-time
+
+     '-O' also turns on '-fomit-frame-pointer' on machines where doing
+     so does not interfere with debugging.
+
+'-O2'
+     Optimize even more.  GCC performs nearly all supported
+     optimizations that do not involve a space-speed tradeoff.  As
+     compared to '-O', this option increases both compilation time and
+     the performance of the generated code.
+
+     '-O2' turns on all optimization flags specified by '-O'.  It also
+     turns on the following optimization flags:
+          -fthread-jumps
+          -falign-functions  -falign-jumps
+          -falign-loops  -falign-labels
+          -fcaller-saves
+          -fcrossjumping
+          -fcse-follow-jumps  -fcse-skip-blocks
+          -fdelete-null-pointer-checks
+          -fdevirtualize -fdevirtualize-speculatively
+          -fexpensive-optimizations
+          -fgcse  -fgcse-lm
+          -fhoist-adjacent-loads
+          -finline-small-functions
+          -findirect-inlining
+          -fipa-sra
+          -fisolate-erroneous-paths-dereference
+          -foptimize-sibling-calls
+          -fpartial-inlining
+          -fpeephole2
+          -freorder-blocks  -freorder-functions
+          -frerun-cse-after-loop
+          -fsched-interblock  -fsched-spec
+          -fschedule-insns  -fschedule-insns2
+          -fstrict-aliasing -fstrict-overflow
+          -ftree-switch-conversion -ftree-tail-merge
+          -ftree-pre
+          -ftree-vrp
+
+     Please note the warning under '-fgcse' about invoking '-O2' on
+     programs that use computed gotos.
+
+'-O3'
+     Optimize yet more.  '-O3' turns on all optimizations specified by
+     '-O2' and also turns on the '-finline-functions',
+     '-funswitch-loops', '-fpredictive-commoning',
+     '-fgcse-after-reload', '-ftree-loop-vectorize',
+     '-ftree-slp-vectorize', '-fvect-cost-model', '-ftree-partial-pre'
+     and '-fipa-cp-clone' options.
+
+'-O0'
+     Reduce compilation time and make debugging produce the expected
+     results.  This is the default.
+
+'-Os'
+     Optimize for size.  '-Os' enables all '-O2' optimizations that do
+     not typically increase code size.  It also performs further
+     optimizations designed to reduce code size.
+
+     '-Os' disables the following optimization flags:
+          -falign-functions  -falign-jumps  -falign-loops
+          -falign-labels  -freorder-blocks  -freorder-blocks-and-partition
+          -fprefetch-loop-arrays
+
+'-Ofast'
+     Disregard strict standards compliance.  '-Ofast' enables all '-O3'
+     optimizations.  It also enables optimizations that are not valid
+     for all standard-compliant programs.  It turns on '-ffast-math' and
+     the Fortran-specific '-fno-protect-parens' and '-fstack-arrays'.
+
+'-Og'
+     Optimize debugging experience.  '-Og' enables optimizations that do
+     not interfere with debugging.  It should be the optimization level
+     of choice for the standard edit-compile-debug cycle, offering a
+     reasonable level of optimization while maintaining fast compilation
+     and a good debugging experience.
+
+     If you use multiple '-O' options, with or without level numbers,
+     the last such option is the one that is effective.
+
+ Options of the form '-fFLAG' specify machine-independent flags.  Most
+flags have both positive and negative forms; the negative form of
+'-ffoo' is '-fno-foo'.  In the table below, only one of the forms is
+listed--the one you typically use.  You can figure out the other form by
+either removing 'no-' or adding it.
+
+ The following options control specific optimizations.  They are either
+activated by '-O' options or are related to ones that are.  You can use
+the following flags in the rare cases when "fine-tuning" of
+optimizations to be performed is desired.
+
+'-fno-defer-pop'
+     Always pop the arguments to each function call as soon as that
+     function returns.  For machines that must pop arguments after a
+     function call, the compiler normally lets arguments accumulate on
+     the stack for several function calls and pops them all at once.
+
+     Disabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-fforward-propagate'
+     Perform a forward propagation pass on RTL.  The pass tries to
+     combine two instructions and checks if the result can be
+     simplified.  If loop unrolling is active, two passes are performed
+     and the second is scheduled after loop unrolling.
+
+     This option is enabled by default at optimization levels '-O',
+     '-O2', '-O3', '-Os'.
+
+'-ffp-contract=STYLE'
+     '-ffp-contract=off' disables floating-point expression contraction.
+     '-ffp-contract=fast' enables floating-point expression contraction
+     such as forming of fused multiply-add operations if the target has
+     native support for them.  '-ffp-contract=on' enables floating-point
+     expression contraction if allowed by the language standard.  This
+     is currently not implemented and treated equal to
+     '-ffp-contract=off'.
+
+     The default is '-ffp-contract=fast'.
+
+'-fomit-frame-pointer'
+     Don't keep the frame pointer in a register for functions that don't
+     need one.  This avoids the instructions to save, set up and restore
+     frame pointers; it also makes an extra register available in many
+     functions.  *It also makes debugging impossible on some machines.*
+
+     On some machines, such as the VAX, this flag has no effect, because
+     the standard calling sequence automatically handles the frame
+     pointer and nothing is saved by pretending it doesn't exist.  The
+     machine-description macro 'FRAME_POINTER_REQUIRED' controls whether
+     a target machine supports this flag.  *Note Register Usage:
+     (gccint)Registers.
+
+     Starting with GCC version 4.6, the default setting (when not
+     optimizing for size) for 32-bit GNU/Linux x86 and 32-bit Darwin x86
+     targets has been changed to '-fomit-frame-pointer'.  The default
+     can be reverted to '-fno-omit-frame-pointer' by configuring GCC
+     with the '--enable-frame-pointer' configure option.
+
+     Enabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-foptimize-sibling-calls'
+     Optimize sibling and tail recursive calls.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fno-inline'
+     Do not expand any functions inline apart from those marked with the
+     'always_inline' attribute.  This is the default when not
+     optimizing.
+
+     Single functions can be exempted from inlining by marking them with
+     the 'noinline' attribute.
+
+'-finline-small-functions'
+     Integrate functions into their callers when their body is smaller
+     than expected function call code (so overall size of program gets
+     smaller).  The compiler heuristically decides which functions are
+     simple enough to be worth integrating in this way.  This inlining
+     applies to all functions, even those not declared inline.
+
+     Enabled at level '-O2'.
+
+'-findirect-inlining'
+     Inline also indirect calls that are discovered to be known at
+     compile time thanks to previous inlining.  This option has any
+     effect only when inlining itself is turned on by the
+     '-finline-functions' or '-finline-small-functions' options.
+
+     Enabled at level '-O2'.
+
+'-finline-functions'
+     Consider all functions for inlining, even if they are not declared
+     inline.  The compiler heuristically decides which functions are
+     worth integrating in this way.
+
+     If all calls to a given function are integrated, and the function
+     is declared 'static', then the function is normally not output as
+     assembler code in its own right.
+
+     Enabled at level '-O3'.
+
+'-finline-functions-called-once'
+     Consider all 'static' functions called once for inlining into their
+     caller even if they are not marked 'inline'.  If a call to a given
+     function is integrated, then the function is not output as
+     assembler code in its own right.
+
+     Enabled at levels '-O1', '-O2', '-O3' and '-Os'.
+
+'-fearly-inlining'
+     Inline functions marked by 'always_inline' and functions whose body
+     seems smaller than the function call overhead early before doing
+     '-fprofile-generate' instrumentation and real inlining pass.  Doing
+     so makes profiling significantly cheaper and usually inlining
+     faster on programs having large chains of nested wrapper functions.
+
+     Enabled by default.
+
+'-fipa-sra'
+     Perform interprocedural scalar replacement of aggregates, removal
+     of unused parameters and replacement of parameters passed by
+     reference by parameters passed by value.
+
+     Enabled at levels '-O2', '-O3' and '-Os'.
+
+'-finline-limit=N'
+     By default, GCC limits the size of functions that can be inlined.
+     This flag allows coarse control of this limit.  N is the size of
+     functions that can be inlined in number of pseudo instructions.
+
+     Inlining is actually controlled by a number of parameters, which
+     may be specified individually by using '--param NAME=VALUE'.  The
+     '-finline-limit=N' option sets some of these parameters as follows:
+
+     'max-inline-insns-single'
+          is set to N/2.
+     'max-inline-insns-auto'
+          is set to N/2.
+
+     See below for a documentation of the individual parameters
+     controlling inlining and for the defaults of these parameters.
+
+     _Note:_ there may be no value to '-finline-limit' that results in
+     default behavior.
+
+     _Note:_ pseudo instruction represents, in this particular context,
+     an abstract measurement of function's size.  In no way does it
+     represent a count of assembly instructions and as such its exact
+     meaning might change from one release to an another.
+
+'-fno-keep-inline-dllexport'
+     This is a more fine-grained version of '-fkeep-inline-functions',
+     which applies only to functions that are declared using the
+     'dllexport' attribute or declspec (*Note Declaring Attributes of
+     Functions: Function Attributes.)
+
+'-fkeep-inline-functions'
+     In C, emit 'static' functions that are declared 'inline' into the
+     object file, even if the function has been inlined into all of its
+     callers.  This switch does not affect functions using the 'extern
+     inline' extension in GNU C90.  In C++, emit any and all inline
+     functions into the object file.
+
+'-fkeep-static-consts'
+     Emit variables declared 'static const' when optimization isn't
+     turned on, even if the variables aren't referenced.
+
+     GCC enables this option by default.  If you want to force the
+     compiler to check if a variable is referenced, regardless of
+     whether or not optimization is turned on, use the
+     '-fno-keep-static-consts' option.
+
+'-fmerge-constants'
+     Attempt to merge identical constants (string constants and
+     floating-point constants) across compilation units.
+
+     This option is the default for optimized compilation if the
+     assembler and linker support it.  Use '-fno-merge-constants' to
+     inhibit this behavior.
+
+     Enabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-fmerge-all-constants'
+     Attempt to merge identical constants and identical variables.
+
+     This option implies '-fmerge-constants'.  In addition to
+     '-fmerge-constants' this considers e.g. even constant initialized
+     arrays or initialized constant variables with integral or
+     floating-point types.  Languages like C or C++ require each
+     variable, including multiple instances of the same variable in
+     recursive calls, to have distinct locations, so using this option
+     results in non-conforming behavior.
+
+'-fmodulo-sched'
+     Perform swing modulo scheduling immediately before the first
+     scheduling pass.  This pass looks at innermost loops and reorders
+     their instructions by overlapping different iterations.
+
+'-fmodulo-sched-allow-regmoves'
+     Perform more aggressive SMS-based modulo scheduling with register
+     moves allowed.  By setting this flag certain anti-dependences edges
+     are deleted, which triggers the generation of reg-moves based on
+     the life-range analysis.  This option is effective only with
+     '-fmodulo-sched' enabled.
+
+'-fno-branch-count-reg'
+     Do not use "decrement and branch" instructions on a count register,
+     but instead generate a sequence of instructions that decrement a
+     register, compare it against zero, then branch based upon the
+     result.  This option is only meaningful on architectures that
+     support such instructions, which include x86, PowerPC, IA-64 and
+     S/390.
+
+     The default is '-fbranch-count-reg'.
+
+'-fno-function-cse'
+     Do not put function addresses in registers; make each instruction
+     that calls a constant function contain the function's address
+     explicitly.
+
+     This option results in less efficient code, but some strange hacks
+     that alter the assembler output may be confused by the
+     optimizations performed when this option is not used.
+
+     The default is '-ffunction-cse'
+
+'-fno-zero-initialized-in-bss'
+     If the target supports a BSS section, GCC by default puts variables
+     that are initialized to zero into BSS.  This can save space in the
+     resulting code.
+
+     This option turns off this behavior because some programs
+     explicitly rely on variables going to the data section--e.g., so
+     that the resulting executable can find the beginning of that
+     section and/or make assumptions based on that.
+
+     The default is '-fzero-initialized-in-bss'.
+
+'-fthread-jumps'
+     Perform optimizations that check to see if a jump branches to a
+     location where another comparison subsumed by the first is found.
+     If so, the first branch is redirected to either the destination of
+     the second branch or a point immediately following it, depending on
+     whether the condition is known to be true or false.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fsplit-wide-types'
+     When using a type that occupies multiple registers, such as 'long
+     long' on a 32-bit system, split the registers apart and allocate
+     them independently.  This normally generates better code for those
+     types, but may make debugging more difficult.
+
+     Enabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-fcse-follow-jumps'
+     In common subexpression elimination (CSE), scan through jump
+     instructions when the target of the jump is not reached by any
+     other path.  For example, when CSE encounters an 'if' statement
+     with an 'else' clause, CSE follows the jump when the condition
+     tested is false.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fcse-skip-blocks'
+     This is similar to '-fcse-follow-jumps', but causes CSE to follow
+     jumps that conditionally skip over blocks.  When CSE encounters a
+     simple 'if' statement with no else clause, '-fcse-skip-blocks'
+     causes CSE to follow the jump around the body of the 'if'.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-frerun-cse-after-loop'
+     Re-run common subexpression elimination after loop optimizations
+     are performed.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fgcse'
+     Perform a global common subexpression elimination pass.  This pass
+     also performs global constant and copy propagation.
+
+     _Note:_ When compiling a program using computed gotos, a GCC
+     extension, you may get better run-time performance if you disable
+     the global common subexpression elimination pass by adding
+     '-fno-gcse' to the command line.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fgcse-lm'
+     When '-fgcse-lm' is enabled, global common subexpression
+     elimination attempts to move loads that are only killed by stores
+     into themselves.  This allows a loop containing a load/store
+     sequence to be changed to a load outside the loop, and a copy/store
+     within the loop.
+
+     Enabled by default when '-fgcse' is enabled.
+
+'-fgcse-sm'
+     When '-fgcse-sm' is enabled, a store motion pass is run after
+     global common subexpression elimination.  This pass attempts to
+     move stores out of loops.  When used in conjunction with
+     '-fgcse-lm', loops containing a load/store sequence can be changed
+     to a load before the loop and a store after the loop.
+
+     Not enabled at any optimization level.
+
+'-fgcse-las'
+     When '-fgcse-las' is enabled, the global common subexpression
+     elimination pass eliminates redundant loads that come after stores
+     to the same memory location (both partial and full redundancies).
+
+     Not enabled at any optimization level.
+
+'-fgcse-after-reload'
+     When '-fgcse-after-reload' is enabled, a redundant load elimination
+     pass is performed after reload.  The purpose of this pass is to
+     clean up redundant spilling.
+
+'-faggressive-loop-optimizations'
+     This option tells the loop optimizer to use language constraints to
+     derive bounds for the number of iterations of a loop.  This assumes
+     that loop code does not invoke undefined behavior by for example
+     causing signed integer overflows or out-of-bound array accesses.
+     The bounds for the number of iterations of a loop are used to guide
+     loop unrolling and peeling and loop exit test optimizations.  This
+     option is enabled by default.
+
+'-funsafe-loop-optimizations'
+     This option tells the loop optimizer to assume that loop indices do
+     not overflow, and that loops with nontrivial exit condition are not
+     infinite.  This enables a wider range of loop optimizations even if
+     the loop optimizer itself cannot prove that these assumptions are
+     valid.  If you use '-Wunsafe-loop-optimizations', the compiler
+     warns you if it finds this kind of loop.
+
+'-fcrossjumping'
+     Perform cross-jumping transformation.  This transformation unifies
+     equivalent code and saves code size.  The resulting code may or may
+     not perform better than without cross-jumping.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fauto-inc-dec'
+     Combine increments or decrements of addresses with memory accesses.
+     This pass is always skipped on architectures that do not have
+     instructions to support this.  Enabled by default at '-O' and
+     higher on architectures that support this.
+
+'-fdce'
+     Perform dead code elimination (DCE) on RTL.  Enabled by default at
+     '-O' and higher.
+
+'-fdse'
+     Perform dead store elimination (DSE) on RTL.  Enabled by default at
+     '-O' and higher.
+
+'-fif-conversion'
+     Attempt to transform conditional jumps into branch-less
+     equivalents.  This includes use of conditional moves, min, max, set
+     flags and abs instructions, and some tricks doable by standard
+     arithmetics.  The use of conditional execution on chips where it is
+     available is controlled by 'if-conversion2'.
+
+     Enabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-fif-conversion2'
+     Use conditional execution (where available) to transform
+     conditional jumps into branch-less equivalents.
+
+     Enabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-fdeclone-ctor-dtor'
+     The C++ ABI requires multiple entry points for constructors and
+     destructors: one for a base subobject, one for a complete object,
+     and one for a virtual destructor that calls operator delete
+     afterwards.  For a hierarchy with virtual bases, the base and
+     complete variants are clones, which means two copies of the
+     function.  With this option, the base and complete variants are
+     changed to be thunks that call a common implementation.
+
+     Enabled by '-Os'.
+
+'-fdelete-null-pointer-checks'
+     Assume that programs cannot safely dereference null pointers, and
+     that no code or data element resides there.  This enables simple
+     constant folding optimizations at all optimization levels.  In
+     addition, other optimization passes in GCC use this flag to control
+     global dataflow analyses that eliminate useless checks for null
+     pointers; these assume that if a pointer is checked after it has
+     already been dereferenced, it cannot be null.
+
+     Note however that in some environments this assumption is not true.
+     Use '-fno-delete-null-pointer-checks' to disable this optimization
+     for programs that depend on that behavior.
+
+     Some targets, especially embedded ones, disable this option at all
+     levels.  Otherwise it is enabled at all levels: '-O0', '-O1',
+     '-O2', '-O3', '-Os'.  Passes that use the information are enabled
+     independently at different optimization levels.
+
+'-fdevirtualize'
+     Attempt to convert calls to virtual functions to direct calls.
+     This is done both within a procedure and interprocedurally as part
+     of indirect inlining ('-findirect-inlining') and interprocedural
+     constant propagation ('-fipa-cp').  Enabled at levels '-O2', '-O3',
+     '-Os'.
+
+'-fdevirtualize-speculatively'
+     Attempt to convert calls to virtual functions to speculative direct
+     calls.  Based on the analysis of the type inheritance graph,
+     determine for a given call the set of likely targets.  If the set
+     is small, preferably of size 1, change the call into an conditional
+     deciding on direct and indirect call.  The speculative calls enable
+     more optimizations, such as inlining.  When they seem useless after
+     further optimization, they are converted back into original form.
+
+'-fexpensive-optimizations'
+     Perform a number of minor optimizations that are relatively
+     expensive.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-free'
+     Attempt to remove redundant extension instructions.  This is
+     especially helpful for the x86-64 architecture, which implicitly
+     zero-extends in 64-bit registers after writing to their lower
+     32-bit half.
+
+     Enabled for AArch64 and x86 at levels '-O2', '-O3'.
+
+'-flive-range-shrinkage'
+     Attempt to decrease register pressure through register live range
+     shrinkage.  This is helpful for fast processors with small or
+     moderate size register sets.
+
+'-fira-algorithm=ALGORITHM'
+     Use the specified coloring algorithm for the integrated register
+     allocator.  The ALGORITHM argument can be 'priority', which
+     specifies Chow's priority coloring, or 'CB', which specifies
+     Chaitin-Briggs coloring.  Chaitin-Briggs coloring is not
+     implemented for all architectures, but for those targets that do
+     support it, it is the default because it generates better code.
+
+'-fira-region=REGION'
+     Use specified regions for the integrated register allocator.  The
+     REGION argument should be one of the following:
+
+     'all'
+          Use all loops as register allocation regions.  This can give
+          the best results for machines with a small and/or irregular
+          register set.
+
+     'mixed'
+          Use all loops except for loops with small register pressure as
+          the regions.  This value usually gives the best results in
+          most cases and for most architectures, and is enabled by
+          default when compiling with optimization for speed ('-O',
+          '-O2', ...).
+
+     'one'
+          Use all functions as a single region.  This typically results
+          in the smallest code size, and is enabled by default for '-Os'
+          or '-O0'.
+
+'-fira-hoist-pressure'
+     Use IRA to evaluate register pressure in the code hoisting pass for
+     decisions to hoist expressions.  This option usually results in
+     smaller code, but it can slow the compiler down.
+
+     This option is enabled at level '-Os' for all targets.
+
+'-fira-loop-pressure'
+     Use IRA to evaluate register pressure in loops for decisions to
+     move loop invariants.  This option usually results in generation of
+     faster and smaller code on machines with large register files (>=
+     32 registers), but it can slow the compiler down.
+
+     This option is enabled at level '-O3' for some targets.
+
+'-fno-ira-share-save-slots'
+     Disable sharing of stack slots used for saving call-used hard
+     registers living through a call.  Each hard register gets a
+     separate stack slot, and as a result function stack frames are
+     larger.
+
+'-fno-ira-share-spill-slots'
+     Disable sharing of stack slots allocated for pseudo-registers.
+     Each pseudo-register that does not get a hard register gets a
+     separate stack slot, and as a result function stack frames are
+     larger.
+
+'-fira-verbose=N'
+     Control the verbosity of the dump file for the integrated register
+     allocator.  The default value is 5.  If the value N is greater or
+     equal to 10, the dump output is sent to stderr using the same
+     format as N minus 10.
+
+'-fdelayed-branch'
+     If supported for the target machine, attempt to reorder
+     instructions to exploit instruction slots available after delayed
+     branch instructions.
+
+     Enabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-fschedule-insns'
+     If supported for the target machine, attempt to reorder
+     instructions to eliminate execution stalls due to required data
+     being unavailable.  This helps machines that have slow floating
+     point or memory load instructions by allowing other instructions to
+     be issued until the result of the load or floating-point
+     instruction is required.
+
+     Enabled at levels '-O2', '-O3'.
+
+'-fschedule-insns2'
+     Similar to '-fschedule-insns', but requests an additional pass of
+     instruction scheduling after register allocation has been done.
+     This is especially useful on machines with a relatively small
+     number of registers and where memory load instructions take more
+     than one cycle.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fno-sched-interblock'
+     Don't schedule instructions across basic blocks.  This is normally
+     enabled by default when scheduling before register allocation, i.e.
+     with '-fschedule-insns' or at '-O2' or higher.
+
+'-fno-sched-spec'
+     Don't allow speculative motion of non-load instructions.  This is
+     normally enabled by default when scheduling before register
+     allocation, i.e. with '-fschedule-insns' or at '-O2' or higher.
+
+'-fsched-pressure'
+     Enable register pressure sensitive insn scheduling before register
+     allocation.  This only makes sense when scheduling before register
+     allocation is enabled, i.e. with '-fschedule-insns' or at '-O2' or
+     higher.  Usage of this option can improve the generated code and
+     decrease its size by preventing register pressure increase above
+     the number of available hard registers and subsequent spills in
+     register allocation.
+
+'-fsched-spec-load'
+     Allow speculative motion of some load instructions.  This only
+     makes sense when scheduling before register allocation, i.e. with
+     '-fschedule-insns' or at '-O2' or higher.
+
+'-fsched-spec-load-dangerous'
+     Allow speculative motion of more load instructions.  This only
+     makes sense when scheduling before register allocation, i.e. with
+     '-fschedule-insns' or at '-O2' or higher.
+
+'-fsched-stalled-insns'
+'-fsched-stalled-insns=N'
+     Define how many insns (if any) can be moved prematurely from the
+     queue of stalled insns into the ready list during the second
+     scheduling pass.  '-fno-sched-stalled-insns' means that no insns
+     are moved prematurely, '-fsched-stalled-insns=0' means there is no
+     limit on how many queued insns can be moved prematurely.
+     '-fsched-stalled-insns' without a value is equivalent to
+     '-fsched-stalled-insns=1'.
+
+'-fsched-stalled-insns-dep'
+'-fsched-stalled-insns-dep=N'
+     Define how many insn groups (cycles) are examined for a dependency
+     on a stalled insn that is a candidate for premature removal from
+     the queue of stalled insns.  This has an effect only during the
+     second scheduling pass, and only if '-fsched-stalled-insns' is
+     used.  '-fno-sched-stalled-insns-dep' is equivalent to
+     '-fsched-stalled-insns-dep=0'.  '-fsched-stalled-insns-dep' without
+     a value is equivalent to '-fsched-stalled-insns-dep=1'.
+
+'-fsched2-use-superblocks'
+     When scheduling after register allocation, use superblock
+     scheduling.  This allows motion across basic block boundaries,
+     resulting in faster schedules.  This option is experimental, as not
+     all machine descriptions used by GCC model the CPU closely enough
+     to avoid unreliable results from the algorithm.
+
+     This only makes sense when scheduling after register allocation,
+     i.e. with '-fschedule-insns2' or at '-O2' or higher.
+
+'-fsched-group-heuristic'
+     Enable the group heuristic in the scheduler.  This heuristic favors
+     the instruction that belongs to a schedule group.  This is enabled
+     by default when scheduling is enabled, i.e. with '-fschedule-insns'
+     or '-fschedule-insns2' or at '-O2' or higher.
+
+'-fsched-critical-path-heuristic'
+     Enable the critical-path heuristic in the scheduler.  This
+     heuristic favors instructions on the critical path.  This is
+     enabled by default when scheduling is enabled, i.e. with
+     '-fschedule-insns' or '-fschedule-insns2' or at '-O2' or higher.
+
+'-fsched-spec-insn-heuristic'
+     Enable the speculative instruction heuristic in the scheduler.
+     This heuristic favors speculative instructions with greater
+     dependency weakness.  This is enabled by default when scheduling is
+     enabled, i.e. with '-fschedule-insns' or '-fschedule-insns2' or at
+     '-O2' or higher.
+
+'-fsched-rank-heuristic'
+     Enable the rank heuristic in the scheduler.  This heuristic favors
+     the instruction belonging to a basic block with greater size or
+     frequency.  This is enabled by default when scheduling is enabled,
+     i.e. with '-fschedule-insns' or '-fschedule-insns2' or at '-O2' or
+     higher.
+
+'-fsched-last-insn-heuristic'
+     Enable the last-instruction heuristic in the scheduler.  This
+     heuristic favors the instruction that is less dependent on the last
+     instruction scheduled.  This is enabled by default when scheduling
+     is enabled, i.e. with '-fschedule-insns' or '-fschedule-insns2' or
+     at '-O2' or higher.
+
+'-fsched-dep-count-heuristic'
+     Enable the dependent-count heuristic in the scheduler.  This
+     heuristic favors the instruction that has more instructions
+     depending on it.  This is enabled by default when scheduling is
+     enabled, i.e. with '-fschedule-insns' or '-fschedule-insns2' or at
+     '-O2' or higher.
+
+'-freschedule-modulo-scheduled-loops'
+     Modulo scheduling is performed before traditional scheduling.  If a
+     loop is modulo scheduled, later scheduling passes may change its
+     schedule.  Use this option to control that behavior.
+
+'-fselective-scheduling'
+     Schedule instructions using selective scheduling algorithm.
+     Selective scheduling runs instead of the first scheduler pass.
+
+'-fselective-scheduling2'
+     Schedule instructions using selective scheduling algorithm.
+     Selective scheduling runs instead of the second scheduler pass.
+
+'-fsel-sched-pipelining'
+     Enable software pipelining of innermost loops during selective
+     scheduling.  This option has no effect unless one of
+     '-fselective-scheduling' or '-fselective-scheduling2' is turned on.
+
+'-fsel-sched-pipelining-outer-loops'
+     When pipelining loops during selective scheduling, also pipeline
+     outer loops.  This option has no effect unless
+     '-fsel-sched-pipelining' is turned on.
+
+'-fshrink-wrap'
+     Emit function prologues only before parts of the function that need
+     it, rather than at the top of the function.  This flag is enabled
+     by default at '-O' and higher.
+
+'-fcaller-saves'
+     Enable allocation of values to registers that are clobbered by
+     function calls, by emitting extra instructions to save and restore
+     the registers around such calls.  Such allocation is done only when
+     it seems to result in better code.
+
+     This option is always enabled by default on certain machines,
+     usually those which have no call-preserved registers to use
+     instead.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fcombine-stack-adjustments'
+     Tracks stack adjustments (pushes and pops) and stack memory
+     references and then tries to find ways to combine them.
+
+     Enabled by default at '-O1' and higher.
+
+'-fconserve-stack'
+     Attempt to minimize stack usage.  The compiler attempts to use less
+     stack space, even if that makes the program slower.  This option
+     implies setting the 'large-stack-frame' parameter to 100 and the
+     'large-stack-frame-growth' parameter to 400.
+
+'-ftree-reassoc'
+     Perform reassociation on trees.  This flag is enabled by default at
+     '-O' and higher.
+
+'-ftree-pre'
+     Perform partial redundancy elimination (PRE) on trees.  This flag
+     is enabled by default at '-O2' and '-O3'.
+
+'-ftree-partial-pre'
+     Make partial redundancy elimination (PRE) more aggressive.  This
+     flag is enabled by default at '-O3'.
+
+'-ftree-forwprop'
+     Perform forward propagation on trees.  This flag is enabled by
+     default at '-O' and higher.
+
+'-ftree-fre'
+     Perform full redundancy elimination (FRE) on trees.  The difference
+     between FRE and PRE is that FRE only considers expressions that are
+     computed on all paths leading to the redundant computation.  This
+     analysis is faster than PRE, though it exposes fewer redundancies.
+     This flag is enabled by default at '-O' and higher.
+
+'-ftree-phiprop'
+     Perform hoisting of loads from conditional pointers on trees.  This
+     pass is enabled by default at '-O' and higher.
+
+'-fhoist-adjacent-loads'
+     Speculatively hoist loads from both branches of an if-then-else if
+     the loads are from adjacent locations in the same structure and the
+     target architecture has a conditional move instruction.  This flag
+     is enabled by default at '-O2' and higher.
+
+'-ftree-copy-prop'
+     Perform copy propagation on trees.  This pass eliminates
+     unnecessary copy operations.  This flag is enabled by default at
+     '-O' and higher.
+
+'-fipa-pure-const'
+     Discover which functions are pure or constant.  Enabled by default
+     at '-O' and higher.
+
+'-fipa-reference'
+     Discover which static variables do not escape the compilation unit.
+     Enabled by default at '-O' and higher.
+
+'-fipa-pta'
+     Perform interprocedural pointer analysis and interprocedural
+     modification and reference analysis.  This option can cause
+     excessive memory and compile-time usage on large compilation units.
+     It is not enabled by default at any optimization level.
+
+'-fipa-profile'
+     Perform interprocedural profile propagation.  The functions called
+     only from cold functions are marked as cold.  Also functions
+     executed once (such as 'cold', 'noreturn', static constructors or
+     destructors) are identified.  Cold functions and loop less parts of
+     functions executed once are then optimized for size.  Enabled by
+     default at '-O' and higher.
+
+'-fipa-cp'
+     Perform interprocedural constant propagation.  This optimization
+     analyzes the program to determine when values passed to functions
+     are constants and then optimizes accordingly.  This optimization
+     can substantially increase performance if the application has
+     constants passed to functions.  This flag is enabled by default at
+     '-O2', '-Os' and '-O3'.
+
+'-fipa-cp-clone'
+     Perform function cloning to make interprocedural constant
+     propagation stronger.  When enabled, interprocedural constant
+     propagation performs function cloning when externally visible
+     function can be called with constant arguments.  Because this
+     optimization can create multiple copies of functions, it may
+     significantly increase code size (see '--param
+     ipcp-unit-growth=VALUE').  This flag is enabled by default at
+     '-O3'.
+
+'-fisolate-erroneous-paths-dereference'
+     Detect paths which trigger erroneous or undefined behaviour due to
+     dereferencing a NULL pointer.  Isolate those paths from the main
+     control flow and turn the statement with erroneous or undefined
+     behaviour into a trap.
+
+'-fisolate-erroneous-paths-attribute'
+     Detect paths which trigger erroneous or undefined behaviour due a
+     NULL value being used in a way which is forbidden by a
+     'returns_nonnull' or 'nonnull' attribute.  Isolate those paths from
+     the main control flow and turn the statement with erroneous or
+     undefined behaviour into a trap.  This is not currently enabled,
+     but may be enabled by '-O2' in the future.
+
+'-ftree-sink'
+     Perform forward store motion on trees.  This flag is enabled by
+     default at '-O' and higher.
+
+'-ftree-bit-ccp'
+     Perform sparse conditional bit constant propagation on trees and
+     propagate pointer alignment information.  This pass only operates
+     on local scalar variables and is enabled by default at '-O' and
+     higher.  It requires that '-ftree-ccp' is enabled.
+
+'-ftree-ccp'
+     Perform sparse conditional constant propagation (CCP) on trees.
+     This pass only operates on local scalar variables and is enabled by
+     default at '-O' and higher.
+
+'-ftree-switch-conversion'
+     Perform conversion of simple initializations in a switch to
+     initializations from a scalar array.  This flag is enabled by
+     default at '-O2' and higher.
+
+'-ftree-tail-merge'
+     Look for identical code sequences.  When found, replace one with a
+     jump to the other.  This optimization is known as tail merging or
+     cross jumping.  This flag is enabled by default at '-O2' and
+     higher.  The compilation time in this pass can be limited using
+     'max-tail-merge-comparisons' parameter and
+     'max-tail-merge-iterations' parameter.
+
+'-ftree-dce'
+     Perform dead code elimination (DCE) on trees.  This flag is enabled
+     by default at '-O' and higher.
+
+'-ftree-builtin-call-dce'
+     Perform conditional dead code elimination (DCE) for calls to
+     built-in functions that may set 'errno' but are otherwise
+     side-effect free.  This flag is enabled by default at '-O2' and
+     higher if '-Os' is not also specified.
+
+'-ftree-dominator-opts'
+     Perform a variety of simple scalar cleanups (constant/copy
+     propagation, redundancy elimination, range propagation and
+     expression simplification) based on a dominator tree traversal.
+     This also performs jump threading (to reduce jumps to jumps).  This
+     flag is enabled by default at '-O' and higher.
+
+'-ftree-dse'
+     Perform dead store elimination (DSE) on trees.  A dead store is a
+     store into a memory location that is later overwritten by another
+     store without any intervening loads.  In this case the earlier
+     store can be deleted.  This flag is enabled by default at '-O' and
+     higher.
+
+'-ftree-ch'
+     Perform loop header copying on trees.  This is beneficial since it
+     increases effectiveness of code motion optimizations.  It also
+     saves one jump.  This flag is enabled by default at '-O' and
+     higher.  It is not enabled for '-Os', since it usually increases
+     code size.
+
+'-ftree-loop-optimize'
+     Perform loop optimizations on trees.  This flag is enabled by
+     default at '-O' and higher.
+
+'-ftree-loop-linear'
+     Perform loop interchange transformations on tree.  Same as
+     '-floop-interchange'.  To use this code transformation, GCC has to
+     be configured with '--with-ppl' and '--with-cloog' to enable the
+     Graphite loop transformation infrastructure.
+
+'-floop-interchange'
+     Perform loop interchange transformations on loops.  Interchanging
+     two nested loops switches the inner and outer loops.  For example,
+     given a loop like:
+          DO J = 1, M
+            DO I = 1, N
+              A(J, I) = A(J, I) * C
+            ENDDO
+          ENDDO
+     loop interchange transforms the loop as if it were written:
+          DO I = 1, N
+            DO J = 1, M
+              A(J, I) = A(J, I) * C
+            ENDDO
+          ENDDO
+     which can be beneficial when 'N' is larger than the caches, because
+     in Fortran, the elements of an array are stored in memory
+     contiguously by column, and the original loop iterates over rows,
+     potentially creating at each access a cache miss.  This
+     optimization applies to all the languages supported by GCC and is
+     not limited to Fortran.  To use this code transformation, GCC has
+     to be configured with '--with-ppl' and '--with-cloog' to enable the
+     Graphite loop transformation infrastructure.
+
+'-floop-strip-mine'
+     Perform loop strip mining transformations on loops.  Strip mining
+     splits a loop into two nested loops.  The outer loop has strides
+     equal to the strip size and the inner loop has strides of the
+     original loop within a strip.  The strip length can be changed
+     using the 'loop-block-tile-size' parameter.  For example, given a
+     loop like:
+          DO I = 1, N
+            A(I) = A(I) + C
+          ENDDO
+     loop strip mining transforms the loop as if it were written:
+          DO II = 1, N, 51
+            DO I = II, min (II + 50, N)
+              A(I) = A(I) + C
+            ENDDO
+          ENDDO
+     This optimization applies to all the languages supported by GCC and
+     is not limited to Fortran.  To use this code transformation, GCC
+     has to be configured with '--with-ppl' and '--with-cloog' to enable
+     the Graphite loop transformation infrastructure.
+
+'-floop-block'
+     Perform loop blocking transformations on loops.  Blocking strip
+     mines each loop in the loop nest such that the memory accesses of
+     the element loops fit inside caches.  The strip length can be
+     changed using the 'loop-block-tile-size' parameter.  For example,
+     given a loop like:
+          DO I = 1, N
+            DO J = 1, M
+              A(J, I) = B(I) + C(J)
+            ENDDO
+          ENDDO
+     loop blocking transforms the loop as if it were written:
+          DO II = 1, N, 51
+            DO JJ = 1, M, 51
+              DO I = II, min (II + 50, N)
+                DO J = JJ, min (JJ + 50, M)
+                  A(J, I) = B(I) + C(J)
+                ENDDO
+              ENDDO
+            ENDDO
+          ENDDO
+     which can be beneficial when 'M' is larger than the caches, because
+     the innermost loop iterates over a smaller amount of data which can
+     be kept in the caches.  This optimization applies to all the
+     languages supported by GCC and is not limited to Fortran.  To use
+     this code transformation, GCC has to be configured with
+     '--with-ppl' and '--with-cloog' to enable the Graphite loop
+     transformation infrastructure.
+
+'-fgraphite-identity'
+     Enable the identity transformation for graphite.  For every SCoP we
+     generate the polyhedral representation and transform it back to
+     gimple.  Using '-fgraphite-identity' we can check the costs or
+     benefits of the GIMPLE -> GRAPHITE -> GIMPLE transformation.  Some
+     minimal optimizations are also performed by the code generator
+     CLooG, like index splitting and dead code elimination in loops.
+
+'-floop-nest-optimize'
+     Enable the ISL based loop nest optimizer.  This is a generic loop
+     nest optimizer based on the Pluto optimization algorithms.  It
+     calculates a loop structure optimized for data-locality and
+     parallelism.  This option is experimental.
+
+'-floop-parallelize-all'
+     Use the Graphite data dependence analysis to identify loops that
+     can be parallelized.  Parallelize all the loops that can be
+     analyzed to not contain loop carried dependences without checking
+     that it is profitable to parallelize the loops.
+
+'-fcheck-data-deps'
+     Compare the results of several data dependence analyzers.  This
+     option is used for debugging the data dependence analyzers.
+
+'-ftree-loop-if-convert'
+     Attempt to transform conditional jumps in the innermost loops to
+     branch-less equivalents.  The intent is to remove control-flow from
+     the innermost loops in order to improve the ability of the
+     vectorization pass to handle these loops.  This is enabled by
+     default if vectorization is enabled.
+
+'-ftree-loop-if-convert-stores'
+     Attempt to also if-convert conditional jumps containing memory
+     writes.  This transformation can be unsafe for multi-threaded
+     programs as it transforms conditional memory writes into
+     unconditional memory writes.  For example,
+          for (i = 0; i < N; i++)
+            if (cond)
+              A[i] = expr;
+     is transformed to
+          for (i = 0; i < N; i++)
+            A[i] = cond ? expr : A[i];
+     potentially producing data races.
+
+'-ftree-loop-distribution'
+     Perform loop distribution.  This flag can improve cache performance
+     on big loop bodies and allow further loop optimizations, like
+     parallelization or vectorization, to take place.  For example, the
+     loop
+          DO I = 1, N
+            A(I) = B(I) + C
+            D(I) = E(I) * F
+          ENDDO
+     is transformed to
+          DO I = 1, N
+             A(I) = B(I) + C
+          ENDDO
+          DO I = 1, N
+             D(I) = E(I) * F
+          ENDDO
+
+'-ftree-loop-distribute-patterns'
+     Perform loop distribution of patterns that can be code generated
+     with calls to a library.  This flag is enabled by default at '-O3'.
+
+     This pass distributes the initialization loops and generates a call
+     to memset zero.  For example, the loop
+          DO I = 1, N
+            A(I) = 0
+            B(I) = A(I) + I
+          ENDDO
+     is transformed to
+          DO I = 1, N
+             A(I) = 0
+          ENDDO
+          DO I = 1, N
+             B(I) = A(I) + I
+          ENDDO
+     and the initialization loop is transformed into a call to memset
+     zero.
+
+'-ftree-loop-im'
+     Perform loop invariant motion on trees.  This pass moves only
+     invariants that are hard to handle at RTL level (function calls,
+     operations that expand to nontrivial sequences of insns).  With
+     '-funswitch-loops' it also moves operands of conditions that are
+     invariant out of the loop, so that we can use just trivial
+     invariantness analysis in loop unswitching.  The pass also includes
+     store motion.
+
+'-ftree-loop-ivcanon'
+     Create a canonical counter for number of iterations in loops for
+     which determining number of iterations requires complicated
+     analysis.  Later optimizations then may determine the number
+     easily.  Useful especially in connection with unrolling.
+
+'-fivopts'
+     Perform induction variable optimizations (strength reduction,
+     induction variable merging and induction variable elimination) on
+     trees.
+
+'-ftree-parallelize-loops=n'
+     Parallelize loops, i.e., split their iteration space to run in n
+     threads.  This is only possible for loops whose iterations are
+     independent and can be arbitrarily reordered.  The optimization is
+     only profitable on multiprocessor machines, for loops that are
+     CPU-intensive, rather than constrained e.g. by memory bandwidth.
+     This option implies '-pthread', and thus is only supported on
+     targets that have support for '-pthread'.
+
+'-ftree-pta'
+     Perform function-local points-to analysis on trees.  This flag is
+     enabled by default at '-O' and higher.
+
+'-ftree-sra'
+     Perform scalar replacement of aggregates.  This pass replaces
+     structure references with scalars to prevent committing structures
+     to memory too early.  This flag is enabled by default at '-O' and
+     higher.
+
+'-ftree-copyrename'
+     Perform copy renaming on trees.  This pass attempts to rename
+     compiler temporaries to other variables at copy locations, usually
+     resulting in variable names which more closely resemble the
+     original variables.  This flag is enabled by default at '-O' and
+     higher.
+
+'-ftree-coalesce-inlined-vars'
+     Tell the copyrename pass (see '-ftree-copyrename') to attempt to
+     combine small user-defined variables too, but only if they were
+     inlined from other functions.  It is a more limited form of
+     '-ftree-coalesce-vars'.  This may harm debug information of such
+     inlined variables, but it will keep variables of the inlined-into
+     function apart from each other, such that they are more likely to
+     contain the expected values in a debugging session.  This was the
+     default in GCC versions older than 4.7.
+
+'-ftree-coalesce-vars'
+     Tell the copyrename pass (see '-ftree-copyrename') to attempt to
+     combine small user-defined variables too, instead of just compiler
+     temporaries.  This may severely limit the ability to debug an
+     optimized program compiled with '-fno-var-tracking-assignments'.
+     In the negated form, this flag prevents SSA coalescing of user
+     variables, including inlined ones.  This option is enabled by
+     default.
+
+'-ftree-ter'
+     Perform temporary expression replacement during the SSA->normal
+     phase.  Single use/single def temporaries are replaced at their use
+     location with their defining expression.  This results in
+     non-GIMPLE code, but gives the expanders much more complex trees to
+     work on resulting in better RTL generation.  This is enabled by
+     default at '-O' and higher.
+
+'-ftree-slsr'
+     Perform straight-line strength reduction on trees.  This recognizes
+     related expressions involving multiplications and replaces them by
+     less expensive calculations when possible.  This is enabled by
+     default at '-O' and higher.
+
+'-ftree-vectorize'
+     Perform vectorization on trees.  This flag enables
+     '-ftree-loop-vectorize' and '-ftree-slp-vectorize' if not
+     explicitly specified.
+
+'-ftree-loop-vectorize'
+     Perform loop vectorization on trees.  This flag is enabled by
+     default at '-O3' and when '-ftree-vectorize' is enabled.
+
+'-ftree-slp-vectorize'
+     Perform basic block vectorization on trees.  This flag is enabled
+     by default at '-O3' and when '-ftree-vectorize' is enabled.
+
+'-fvect-cost-model=MODEL'
+     Alter the cost model used for vectorization.  The MODEL argument
+     should be one of 'unlimited', 'dynamic' or 'cheap'.  With the
+     'unlimited' model the vectorized code-path is assumed to be
+     profitable while with the 'dynamic' model a runtime check will
+     guard the vectorized code-path to enable it only for iteration
+     counts that will likely execute faster than when executing the
+     original scalar loop.  The 'cheap' model will disable vectorization
+     of loops where doing so would be cost prohibitive for example due
+     to required runtime checks for data dependence or alignment but
+     otherwise is equal to the 'dynamic' model.  The default cost model
+     depends on other optimization flags and is either 'dynamic' or
+     'cheap'.
+
+'-fsimd-cost-model=MODEL'
+     Alter the cost model used for vectorization of loops marked with
+     the OpenMP or Cilk Plus simd directive.  The MODEL argument should
+     be one of 'unlimited', 'dynamic', 'cheap'.  All values of MODEL
+     have the same meaning as described in '-fvect-cost-model' and by
+     default a cost model defined with '-fvect-cost-model' is used.
+
+'-ftree-vrp'
+     Perform Value Range Propagation on trees.  This is similar to the
+     constant propagation pass, but instead of values, ranges of values
+     are propagated.  This allows the optimizers to remove unnecessary
+     range checks like array bound checks and null pointer checks.  This
+     is enabled by default at '-O2' and higher.  Null pointer check
+     elimination is only done if '-fdelete-null-pointer-checks' is
+     enabled.
+
+'-ftracer'
+     Perform tail duplication to enlarge superblock size.  This
+     transformation simplifies the control flow of the function allowing
+     other optimizations to do a better job.
+
+'-funroll-loops'
+     Unroll loops whose number of iterations can be determined at
+     compile time or upon entry to the loop.  '-funroll-loops' implies
+     '-frerun-cse-after-loop'.  This option makes code larger, and may
+     or may not make it run faster.
+
+'-funroll-all-loops'
+     Unroll all loops, even if their number of iterations is uncertain
+     when the loop is entered.  This usually makes programs run more
+     slowly.  '-funroll-all-loops' implies the same options as
+     '-funroll-loops',
+
+'-fsplit-ivs-in-unroller'
+     Enables expression of values of induction variables in later
+     iterations of the unrolled loop using the value in the first
+     iteration.  This breaks long dependency chains, thus improving
+     efficiency of the scheduling passes.
+
+     A combination of '-fweb' and CSE is often sufficient to obtain the
+     same effect.  However, that is not reliable in cases where the loop
+     body is more complicated than a single basic block.  It also does
+     not work at all on some architectures due to restrictions in the
+     CSE pass.
+
+     This optimization is enabled by default.
+
+'-fvariable-expansion-in-unroller'
+     With this option, the compiler creates multiple copies of some
+     local variables when unrolling a loop, which can result in superior
+     code.
+
+'-fpartial-inlining'
+     Inline parts of functions.  This option has any effect only when
+     inlining itself is turned on by the '-finline-functions' or
+     '-finline-small-functions' options.
+
+     Enabled at level '-O2'.
+
+'-fpredictive-commoning'
+     Perform predictive commoning optimization, i.e., reusing
+     computations (especially memory loads and stores) performed in
+     previous iterations of loops.
+
+     This option is enabled at level '-O3'.
+
+'-fprefetch-loop-arrays'
+     If supported by the target machine, generate instructions to
+     prefetch memory to improve the performance of loops that access
+     large arrays.
+
+     This option may generate better or worse code; results are highly
+     dependent on the structure of loops within the source code.
+
+     Disabled at level '-Os'.
+
+'-fno-peephole'
+'-fno-peephole2'
+     Disable any machine-specific peephole optimizations.  The
+     difference between '-fno-peephole' and '-fno-peephole2' is in how
+     they are implemented in the compiler; some targets use one, some
+     use the other, a few use both.
+
+     '-fpeephole' is enabled by default.  '-fpeephole2' enabled at
+     levels '-O2', '-O3', '-Os'.
+
+'-fno-guess-branch-probability'
+     Do not guess branch probabilities using heuristics.
+
+     GCC uses heuristics to guess branch probabilities if they are not
+     provided by profiling feedback ('-fprofile-arcs').  These
+     heuristics are based on the control flow graph.  If some branch
+     probabilities are specified by '__builtin_expect', then the
+     heuristics are used to guess branch probabilities for the rest of
+     the control flow graph, taking the '__builtin_expect' info into
+     account.  The interactions between the heuristics and
+     '__builtin_expect' can be complex, and in some cases, it may be
+     useful to disable the heuristics so that the effects of
+     '__builtin_expect' are easier to understand.
+
+     The default is '-fguess-branch-probability' at levels '-O', '-O2',
+     '-O3', '-Os'.
+
+'-freorder-blocks'
+     Reorder basic blocks in the compiled function in order to reduce
+     number of taken branches and improve code locality.
+
+     Enabled at levels '-O2', '-O3'.
+
+'-freorder-blocks-and-partition'
+     In addition to reordering basic blocks in the compiled function, in
+     order to reduce number of taken branches, partitions hot and cold
+     basic blocks into separate sections of the assembly and .o files,
+     to improve paging and cache locality performance.
+
+     This optimization is automatically turned off in the presence of
+     exception handling, for linkonce sections, for functions with a
+     user-defined section attribute and on any architecture that does
+     not support named sections.
+
+     Enabled for x86 at levels '-O2', '-O3'.
+
+'-freorder-functions'
+     Reorder functions in the object file in order to improve code
+     locality.  This is implemented by using special subsections
+     '.text.hot' for most frequently executed functions and
+     '.text.unlikely' for unlikely executed functions.  Reordering is
+     done by the linker so object file format must support named
+     sections and linker must place them in a reasonable way.
+
+     Also profile feedback must be available to make this option
+     effective.  See '-fprofile-arcs' for details.
+
+     Enabled at levels '-O2', '-O3', '-Os'.
+
+'-fstrict-aliasing'
+     Allow the compiler to assume the strictest aliasing rules
+     applicable to the language being compiled.  For C (and C++), this
+     activates optimizations based on the type of expressions.  In
+     particular, an object of one type is assumed never to reside at the
+     same address as an object of a different type, unless the types are
+     almost the same.  For example, an 'unsigned int' can alias an
+     'int', but not a 'void*' or a 'double'.  A character type may alias
+     any other type.
+
+     Pay special attention to code like this:
+          union a_union {
+            int i;
+            double d;
+          };
+
+          int f() {
+            union a_union t;
+            t.d = 3.0;
+            return t.i;
+          }
+     The practice of reading from a different union member than the one
+     most recently written to (called "type-punning") is common.  Even
+     with '-fstrict-aliasing', type-punning is allowed, provided the
+     memory is accessed through the union type.  So, the code above
+     works as expected.  *Note Structures unions enumerations and
+     bit-fields implementation::.  However, this code might not:
+          int f() {
+            union a_union t;
+            int* ip;
+            t.d = 3.0;
+            ip = &t.i;
+            return *ip;
+          }
+
+     Similarly, access by taking the address, casting the resulting
+     pointer and dereferencing the result has undefined behavior, even
+     if the cast uses a union type, e.g.:
+          int f() {
+            double d = 3.0;
+            return ((union a_union *) &d)->i;
+          }
+
+     The '-fstrict-aliasing' option is enabled at levels '-O2', '-O3',
+     '-Os'.
+
+'-fstrict-overflow'
+     Allow the compiler to assume strict signed overflow rules,
+     depending on the language being compiled.  For C (and C++) this
+     means that overflow when doing arithmetic with signed numbers is
+     undefined, which means that the compiler may assume that it does
+     not happen.  This permits various optimizations.  For example, the
+     compiler assumes that an expression like 'i + 10 > i' is always
+     true for signed 'i'.  This assumption is only valid if signed
+     overflow is undefined, as the expression is false if 'i + 10'
+     overflows when using twos complement arithmetic.  When this option
+     is in effect any attempt to determine whether an operation on
+     signed numbers overflows must be written carefully to not actually
+     involve overflow.
+
+     This option also allows the compiler to assume strict pointer
+     semantics: given a pointer to an object, if adding an offset to
+     that pointer does not produce a pointer to the same object, the
+     addition is undefined.  This permits the compiler to conclude that
+     'p + u > p' is always true for a pointer 'p' and unsigned integer
+     'u'.  This assumption is only valid because pointer wraparound is
+     undefined, as the expression is false if 'p + u' overflows using
+     twos complement arithmetic.
+
+     See also the '-fwrapv' option.  Using '-fwrapv' means that integer
+     signed overflow is fully defined: it wraps.  When '-fwrapv' is
+     used, there is no difference between '-fstrict-overflow' and
+     '-fno-strict-overflow' for integers.  With '-fwrapv' certain types
+     of overflow are permitted.  For example, if the compiler gets an
+     overflow when doing arithmetic on constants, the overflowed value
+     can still be used with '-fwrapv', but not otherwise.
+
+     The '-fstrict-overflow' option is enabled at levels '-O2', '-O3',
+     '-Os'.
+
+'-falign-functions'
+'-falign-functions=N'
+     Align the start of functions to the next power-of-two greater than
+     N, skipping up to N bytes.  For instance, '-falign-functions=32'
+     aligns functions to the next 32-byte boundary, but
+     '-falign-functions=24' aligns to the next 32-byte boundary only if
+     this can be done by skipping 23 bytes or less.
+
+     '-fno-align-functions' and '-falign-functions=1' are equivalent and
+     mean that functions are not aligned.
+
+     Some assemblers only support this flag when N is a power of two; in
+     that case, it is rounded up.
+
+     If N is not specified or is zero, use a machine-dependent default.
+
+     Enabled at levels '-O2', '-O3'.
+
+'-falign-labels'
+'-falign-labels=N'
+     Align all branch targets to a power-of-two boundary, skipping up to
+     N bytes like '-falign-functions'.  This option can easily make code
+     slower, because it must insert dummy operations for when the branch
+     target is reached in the usual flow of the code.
+
+     '-fno-align-labels' and '-falign-labels=1' are equivalent and mean
+     that labels are not aligned.
+
+     If '-falign-loops' or '-falign-jumps' are applicable and are
+     greater than this value, then their values are used instead.
+
+     If N is not specified or is zero, use a machine-dependent default
+     which is very likely to be '1', meaning no alignment.
+
+     Enabled at levels '-O2', '-O3'.
+
+'-falign-loops'
+'-falign-loops=N'
+     Align loops to a power-of-two boundary, skipping up to N bytes like
+     '-falign-functions'.  If the loops are executed many times, this
+     makes up for any execution of the dummy operations.
+
+     '-fno-align-loops' and '-falign-loops=1' are equivalent and mean
+     that loops are not aligned.
+
+     If N is not specified or is zero, use a machine-dependent default.
+
+     Enabled at levels '-O2', '-O3'.
+
+'-falign-jumps'
+'-falign-jumps=N'
+     Align branch targets to a power-of-two boundary, for branch targets
+     where the targets can only be reached by jumping, skipping up to N
+     bytes like '-falign-functions'.  In this case, no dummy operations
+     need be executed.
+
+     '-fno-align-jumps' and '-falign-jumps=1' are equivalent and mean
+     that loops are not aligned.
+
+     If N is not specified or is zero, use a machine-dependent default.
+
+     Enabled at levels '-O2', '-O3'.
+
+'-funit-at-a-time'
+     This option is left for compatibility reasons.  '-funit-at-a-time'
+     has no effect, while '-fno-unit-at-a-time' implies
+     '-fno-toplevel-reorder' and '-fno-section-anchors'.
+
+     Enabled by default.
+
+'-fno-toplevel-reorder'
+     Do not reorder top-level functions, variables, and 'asm'
+     statements.  Output them in the same order that they appear in the
+     input file.  When this option is used, unreferenced static
+     variables are not removed.  This option is intended to support
+     existing code that relies on a particular ordering.  For new code,
+     it is better to use attributes when possible.
+
+     Enabled at level '-O0'.  When disabled explicitly, it also implies
+     '-fno-section-anchors', which is otherwise enabled at '-O0' on some
+     targets.
+
+'-fweb'
+     Constructs webs as commonly used for register allocation purposes
+     and assign each web individual pseudo register.  This allows the
+     register allocation pass to operate on pseudos directly, but also
+     strengthens several other optimization passes, such as CSE, loop
+     optimizer and trivial dead code remover.  It can, however, make
+     debugging impossible, since variables no longer stay in a "home
+     register".
+
+     Enabled by default with '-funroll-loops'.
+
+'-fwhole-program'
+     Assume that the current compilation unit represents the whole
+     program being compiled.  All public functions and variables with
+     the exception of 'main' and those merged by attribute
+     'externally_visible' become static functions and in effect are
+     optimized more aggressively by interprocedural optimizers.
+
+     This option should not be used in combination with '-flto'.
+     Instead relying on a linker plugin should provide safer and more
+     precise information.
+
+'-flto[=N]'
+     This option runs the standard link-time optimizer.  When invoked
+     with source code, it generates GIMPLE (one of GCC's internal
+     representations) and writes it to special ELF sections in the
+     object file.  When the object files are linked together, all the
+     function bodies are read from these ELF sections and instantiated
+     as if they had been part of the same translation unit.
+
+     To use the link-time optimizer, '-flto' and optimization options
+     should be specified at compile time and during the final link.  For
+     example:
+
+          gcc -c -O2 -flto foo.c
+          gcc -c -O2 -flto bar.c
+          gcc -o myprog -flto -O2 foo.o bar.o
+
+     The first two invocations to GCC save a bytecode representation of
+     GIMPLE into special ELF sections inside 'foo.o' and 'bar.o'.  The
+     final invocation reads the GIMPLE bytecode from 'foo.o' and
+     'bar.o', merges the two files into a single internal image, and
+     compiles the result as usual.  Since both 'foo.o' and 'bar.o' are
+     merged into a single image, this causes all the interprocedural
+     analyses and optimizations in GCC to work across the two files as
+     if they were a single one.  This means, for example, that the
+     inliner is able to inline functions in 'bar.o' into functions in
+     'foo.o' and vice-versa.
+
+     Another (simpler) way to enable link-time optimization is:
+
+          gcc -o myprog -flto -O2 foo.c bar.c
+
+     The above generates bytecode for 'foo.c' and 'bar.c', merges them
+     together into a single GIMPLE representation and optimizes them as
+     usual to produce 'myprog'.
+
+     The only important thing to keep in mind is that to enable
+     link-time optimizations you need to use the GCC driver to perform
+     the link-step.  GCC then automatically performs link-time
+     optimization if any of the objects involved were compiled with the
+     '-flto'.  You generally should specify the optimization options to
+     be used for link-time optimization though GCC will try to be clever
+     at guessing an optimization level to use from the options used at
+     compile-time if you fail to specify one at link-time.  You can
+     always override the automatic decision to do link-time optimization
+     at link-time by passing '-fno-lto' to the link command.
+
+     To make whole program optimization effective, it is necessary to
+     make certain whole program assumptions.  The compiler needs to know
+     what functions and variables can be accessed by libraries and
+     runtime outside of the link-time optimized unit.  When supported by
+     the linker, the linker plugin (see '-fuse-linker-plugin') passes
+     information to the compiler about used and externally visible
+     symbols.  When the linker plugin is not available,
+     '-fwhole-program' should be used to allow the compiler to make
+     these assumptions, which leads to more aggressive optimization
+     decisions.
+
+     When '-fuse-linker-plugin' is not enabled then, when a file is
+     compiled with '-flto', the generated object file is larger than a
+     regular object file because it contains GIMPLE bytecodes and the
+     usual final code (see '-ffat-lto-objects'.  This means that object
+     files with LTO information can be linked as normal object files; if
+     '-fno-lto' is passed to the linker, no interprocedural
+     optimizations are applied.  Note that when '-fno-fat-lto-objects'
+     is enabled the compile-stage is faster but you cannot perform a
+     regular, non-LTO link on them.
+
+     Additionally, the optimization flags used to compile individual
+     files are not necessarily related to those used at link time.  For
+     instance,
+
+          gcc -c -O0 -ffat-lto-objects -flto foo.c
+          gcc -c -O0 -ffat-lto-objects -flto bar.c
+          gcc -o myprog -O3 foo.o bar.o
+
+     This produces individual object files with unoptimized assembler
+     code, but the resulting binary 'myprog' is optimized at '-O3'.  If,
+     instead, the final binary is generated with '-fno-lto', then
+     'myprog' is not optimized.
+
+     When producing the final binary, GCC only applies link-time
+     optimizations to those files that contain bytecode.  Therefore, you
+     can mix and match object files and libraries with GIMPLE bytecodes
+     and final object code.  GCC automatically selects which files to
+     optimize in LTO mode and which files to link without further
+     processing.
+
+     There are some code generation flags preserved by GCC when
+     generating bytecodes, as they need to be used during the final link
+     stage.  Generally options specified at link-time override those
+     specified at compile-time.
+
+     If you do not specify an optimization level option '-O' at
+     link-time then GCC will compute one based on the optimization
+     levels used when compiling the object files.  The highest
+     optimization level will win here.
+
+     Currently, the following options and their setting are take from
+     the first object file that explicitely specified it: '-fPIC',
+     '-fpic', '-fpie', '-fcommon', '-fexceptions',
+     '-fnon-call-exceptions', '-fgnu-tm' and all the '-m' target flags.
+
+     Certain ABI changing flags are required to match in all
+     compilation-units and trying to override this at link-time with a
+     conflicting value is ignored.  This includes options such as
+     '-freg-struct-return' and '-fpcc-struct-return'.
+
+     Other options such as '-ffp-contract', '-fno-strict-overflow',
+     '-fwrapv', '-fno-trapv' or '-fno-strict-aliasing' are passed
+     through to the link stage and merged conservatively for conflicting
+     translation units.  Specifically '-fno-strict-overflow', '-fwrapv'
+     and '-fno-trapv' take precedence and for example
+     '-ffp-contract=off' takes precedence over '-ffp-contract=fast'.
+     You can override them at linke-time.
+
+     It is recommended that you compile all the files participating in
+     the same link with the same options and also specify those options
+     at link time.
+
+     If LTO encounters objects with C linkage declared with incompatible
+     types in separate translation units to be linked together
+     (undefined behavior according to ISO C99 6.2.7), a non-fatal
+     diagnostic may be issued.  The behavior is still undefined at run
+     time.  Similar diagnostics may be raised for other languages.
+
+     Another feature of LTO is that it is possible to apply
+     interprocedural optimizations on files written in different
+     languages:
+
+          gcc -c -flto foo.c
+          g++ -c -flto bar.cc
+          gfortran -c -flto baz.f90
+          g++ -o myprog -flto -O3 foo.o bar.o baz.o -lgfortran
+
+     Notice that the final link is done with 'g++' to get the C++
+     runtime libraries and '-lgfortran' is added to get the Fortran
+     runtime libraries.  In general, when mixing languages in LTO mode,
+     you should use the same link command options as when mixing
+     languages in a regular (non-LTO) compilation.
+
+     If object files containing GIMPLE bytecode are stored in a library
+     archive, say 'libfoo.a', it is possible to extract and use them in
+     an LTO link if you are using a linker with plugin support.  To
+     create static libraries suitable for LTO, use 'gcc-ar' and
+     'gcc-ranlib' instead of 'ar' and 'ranlib'; to show the symbols of
+     object files with GIMPLE bytecode, use 'gcc-nm'.  Those commands
+     require that 'ar', 'ranlib' and 'nm' have been compiled with plugin
+     support.  At link time, use the the flag '-fuse-linker-plugin' to
+     ensure that the library participates in the LTO optimization
+     process:
+
+          gcc -o myprog -O2 -flto -fuse-linker-plugin a.o b.o -lfoo
+
+     With the linker plugin enabled, the linker extracts the needed
+     GIMPLE files from 'libfoo.a' and passes them on to the running GCC
+     to make them part of the aggregated GIMPLE image to be optimized.
+
+     If you are not using a linker with plugin support and/or do not
+     enable the linker plugin, then the objects inside 'libfoo.a' are
+     extracted and linked as usual, but they do not participate in the
+     LTO optimization process.  In order to make a static library
+     suitable for both LTO optimization and usual linkage, compile its
+     object files with '-flto' '-ffat-lto-objects'.
+
+     Link-time optimizations do not require the presence of the whole
+     program to operate.  If the program does not require any symbols to
+     be exported, it is possible to combine '-flto' and
+     '-fwhole-program' to allow the interprocedural optimizers to use
+     more aggressive assumptions which may lead to improved optimization
+     opportunities.  Use of '-fwhole-program' is not needed when linker
+     plugin is active (see '-fuse-linker-plugin').
+
+     The current implementation of LTO makes no attempt to generate
+     bytecode that is portable between different types of hosts.  The
+     bytecode files are versioned and there is a strict version check,
+     so bytecode files generated in one version of GCC will not work
+     with an older or newer version of GCC.
+
+     Link-time optimization does not work well with generation of
+     debugging information.  Combining '-flto' with '-g' is currently
+     experimental and expected to produce unexpected results.
+
+     If you specify the optional N, the optimization and code generation
+     done at link time is executed in parallel using N parallel jobs by
+     utilizing an installed 'make' program.  The environment variable
+     'MAKE' may be used to override the program used.  The default value
+     for N is 1.
+
+     You can also specify '-flto=jobserver' to use GNU make's job server
+     mode to determine the number of parallel jobs.  This is useful when
+     the Makefile calling GCC is already executing in parallel.  You
+     must prepend a '+' to the command recipe in the parent Makefile for
+     this to work.  This option likely only works if 'MAKE' is GNU make.
+
+'-flto-partition=ALG'
+     Specify the partitioning algorithm used by the link-time optimizer.
+     The value is either '1to1' to specify a partitioning mirroring the
+     original source files or 'balanced' to specify partitioning into
+     equally sized chunks (whenever possible) or 'max' to create new
+     partition for every symbol where possible.  Specifying 'none' as an
+     algorithm disables partitioning and streaming completely.  The
+     default value is 'balanced'.  While '1to1' can be used as an
+     workaround for various code ordering issues, the 'max' partitioning
+     is intended for internal testing only.
+
+'-flto-compression-level=N'
+     This option specifies the level of compression used for
+     intermediate language written to LTO object files, and is only
+     meaningful in conjunction with LTO mode ('-flto').  Valid values
+     are 0 (no compression) to 9 (maximum compression).  Values outside
+     this range are clamped to either 0 or 9.  If the option is not
+     given, a default balanced compression setting is used.
+
+'-flto-report'
+     Prints a report with internal details on the workings of the
+     link-time optimizer.  The contents of this report vary from version
+     to version.  It is meant to be useful to GCC developers when
+     processing object files in LTO mode (via '-flto').
+
+     Disabled by default.
+
+'-flto-report-wpa'
+     Like '-flto-report', but only print for the WPA phase of Link Time
+     Optimization.
+
+'-fuse-linker-plugin'
+     Enables the use of a linker plugin during link-time optimization.
+     This option relies on plugin support in the linker, which is
+     available in gold or in GNU ld 2.21 or newer.
+
+     This option enables the extraction of object files with GIMPLE
+     bytecode out of library archives.  This improves the quality of
+     optimization by exposing more code to the link-time optimizer.
+     This information specifies what symbols can be accessed externally
+     (by non-LTO object or during dynamic linking).  Resulting code
+     quality improvements on binaries (and shared libraries that use
+     hidden visibility) are similar to '-fwhole-program'.  See '-flto'
+     for a description of the effect of this flag and how to use it.
+
+     This option is enabled by default when LTO support in GCC is
+     enabled and GCC was configured for use with a linker supporting
+     plugins (GNU ld 2.21 or newer or gold).
+
+'-ffat-lto-objects'
+     Fat LTO objects are object files that contain both the intermediate
+     language and the object code.  This makes them usable for both LTO
+     linking and normal linking.  This option is effective only when
+     compiling with '-flto' and is ignored at link time.
+
+     '-fno-fat-lto-objects' improves compilation time over plain LTO,
+     but requires the complete toolchain to be aware of LTO. It requires
+     a linker with linker plugin support for basic functionality.
+     Additionally, 'nm', 'ar' and 'ranlib' need to support linker
+     plugins to allow a full-featured build environment (capable of
+     building static libraries etc).  GCC provides the 'gcc-ar',
+     'gcc-nm', 'gcc-ranlib' wrappers to pass the right options to these
+     tools.  With non fat LTO makefiles need to be modified to use them.
+
+     The default is '-fno-fat-lto-objects' on targets with linker plugin
+     support.
+
+'-fcompare-elim'
+     After register allocation and post-register allocation instruction
+     splitting, identify arithmetic instructions that compute processor
+     flags similar to a comparison operation based on that arithmetic.
+     If possible, eliminate the explicit comparison operation.
+
+     This pass only applies to certain targets that cannot explicitly
+     represent the comparison operation before register allocation is
+     complete.
+
+     Enabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-fuse-ld=bfd'
+     Use the 'bfd' linker instead of the default linker.
+
+'-fuse-ld=gold'
+     Use the 'gold' linker instead of the default linker.
+
+'-fcprop-registers'
+     After register allocation and post-register allocation instruction
+     splitting, perform a copy-propagation pass to try to reduce
+     scheduling dependencies and occasionally eliminate the copy.
+
+     Enabled at levels '-O', '-O2', '-O3', '-Os'.
+
+'-fprofile-correction'
+     Profiles collected using an instrumented binary for multi-threaded
+     programs may be inconsistent due to missed counter updates.  When
+     this option is specified, GCC uses heuristics to correct or smooth
+     out such inconsistencies.  By default, GCC emits an error message
+     when an inconsistent profile is detected.
+
+'-fprofile-dir=PATH'
+
+     Set the directory to search for the profile data files in to PATH.
+     This option affects only the profile data generated by
+     '-fprofile-generate', '-ftest-coverage', '-fprofile-arcs' and used
+     by '-fprofile-use' and '-fbranch-probabilities' and its related
+     options.  Both absolute and relative paths can be used.  By
+     default, GCC uses the current directory as PATH, thus the profile
+     data file appears in the same directory as the object file.
+
+'-fprofile-generate'
+'-fprofile-generate=PATH'
+
+     Enable options usually used for instrumenting application to
+     produce profile useful for later recompilation with profile
+     feedback based optimization.  You must use '-fprofile-generate'
+     both when compiling and when linking your program.
+
+     The following options are enabled: '-fprofile-arcs',
+     '-fprofile-values', '-fvpt'.
+
+     If PATH is specified, GCC looks at the PATH to find the profile
+     feedback data files.  See '-fprofile-dir'.
+
+'-fprofile-use'
+'-fprofile-use=PATH'
+     Enable profile feedback directed optimizations, and optimizations
+     generally profitable only with profile feedback available.
+
+     The following options are enabled: '-fbranch-probabilities',
+     '-fvpt', '-funroll-loops', '-fpeel-loops', '-ftracer',
+     '-ftree-vectorize', 'ftree-loop-distribute-patterns'
+
+     By default, GCC emits an error message if the feedback profiles do
+     not match the source code.  This error can be turned into a warning
+     by using '-Wcoverage-mismatch'.  Note this may result in poorly
+     optimized code.
+
+     If PATH is specified, GCC looks at the PATH to find the profile
+     feedback data files.  See '-fprofile-dir'.
+
+ The following options control compiler behavior regarding
+floating-point arithmetic.  These options trade off between speed and
+correctness.  All must be specifically enabled.
+
+'-ffloat-store'
+     Do not store floating-point variables in registers, and inhibit
+     other options that might change whether a floating-point value is
+     taken from a register or memory.
+
+     This option prevents undesirable excess precision on machines such
+     as the 68000 where the floating registers (of the 68881) keep more
+     precision than a 'double' is supposed to have.  Similarly for the
+     x86 architecture.  For most programs, the excess precision does
+     only good, but a few programs rely on the precise definition of
+     IEEE floating point.  Use '-ffloat-store' for such programs, after
+     modifying them to store all pertinent intermediate computations
+     into variables.
+
+'-fexcess-precision=STYLE'
+     This option allows further control over excess precision on
+     machines where floating-point registers have more precision than
+     the IEEE 'float' and 'double' types and the processor does not
+     support operations rounding to those types.  By default,
+     '-fexcess-precision=fast' is in effect; this means that operations
+     are carried out in the precision of the registers and that it is
+     unpredictable when rounding to the types specified in the source
+     code takes place.  When compiling C, if
+     '-fexcess-precision=standard' is specified then excess precision
+     follows the rules specified in ISO C99; in particular, both casts
+     and assignments cause values to be rounded to their semantic types
+     (whereas '-ffloat-store' only affects assignments).  This option is
+     enabled by default for C if a strict conformance option such as
+     '-std=c99' is used.
+
+     '-fexcess-precision=standard' is not implemented for languages
+     other than C, and has no effect if '-funsafe-math-optimizations' or
+     '-ffast-math' is specified.  On the x86, it also has no effect if
+     '-mfpmath=sse' or '-mfpmath=sse+387' is specified; in the former
+     case, IEEE semantics apply without excess precision, and in the
+     latter, rounding is unpredictable.
+
+'-ffast-math'
+     Sets '-fno-math-errno', '-funsafe-math-optimizations',
+     '-ffinite-math-only', '-fno-rounding-math', '-fno-signaling-nans'
+     and '-fcx-limited-range'.
+
+     This option causes the preprocessor macro '__FAST_MATH__' to be
+     defined.
+
+     This option is not turned on by any '-O' option besides '-Ofast'
+     since it can result in incorrect output for programs that depend on
+     an exact implementation of IEEE or ISO rules/specifications for
+     math functions.  It may, however, yield faster code for programs
+     that do not require the guarantees of these specifications.
+
+'-fno-math-errno'
+     Do not set 'errno' after calling math functions that are executed
+     with a single instruction, e.g., 'sqrt'.  A program that relies on
+     IEEE exceptions for math error handling may want to use this flag
+     for speed while maintaining IEEE arithmetic compatibility.
+
+     This option is not turned on by any '-O' option since it can result
+     in incorrect output for programs that depend on an exact
+     implementation of IEEE or ISO rules/specifications for math
+     functions.  It may, however, yield faster code for programs that do
+     not require the guarantees of these specifications.
+
+     The default is '-fmath-errno'.
+
+     On Darwin systems, the math library never sets 'errno'.  There is
+     therefore no reason for the compiler to consider the possibility
+     that it might, and '-fno-math-errno' is the default.
+
+'-funsafe-math-optimizations'
+
+     Allow optimizations for floating-point arithmetic that (a) assume
+     that arguments and results are valid and (b) may violate IEEE or
+     ANSI standards.  When used at link-time, it may include libraries
+     or startup files that change the default FPU control word or other
+     similar optimizations.
+
+     This option is not turned on by any '-O' option since it can result
+     in incorrect output for programs that depend on an exact
+     implementation of IEEE or ISO rules/specifications for math
+     functions.  It may, however, yield faster code for programs that do
+     not require the guarantees of these specifications.  Enables
+     '-fno-signed-zeros', '-fno-trapping-math', '-fassociative-math' and
+     '-freciprocal-math'.
+
+     The default is '-fno-unsafe-math-optimizations'.
+
+'-fassociative-math'
+
+     Allow re-association of operands in series of floating-point
+     operations.  This violates the ISO C and C++ language standard by
+     possibly changing computation result.  NOTE: re-ordering may change
+     the sign of zero as well as ignore NaNs and inhibit or create
+     underflow or overflow (and thus cannot be used on code that relies
+     on rounding behavior like '(x + 2**52) - 2**52'.  May also reorder
+     floating-point comparisons and thus may not be used when ordered
+     comparisons are required.  This option requires that both
+     '-fno-signed-zeros' and '-fno-trapping-math' be in effect.
+     Moreover, it doesn't make much sense with '-frounding-math'.  For
+     Fortran the option is automatically enabled when both
+     '-fno-signed-zeros' and '-fno-trapping-math' are in effect.
+
+     The default is '-fno-associative-math'.
+
+'-freciprocal-math'
+
+     Allow the reciprocal of a value to be used instead of dividing by
+     the value if this enables optimizations.  For example 'x / y' can
+     be replaced with 'x * (1/y)', which is useful if '(1/y)' is subject
+     to common subexpression elimination.  Note that this loses
+     precision and increases the number of flops operating on the value.
+
+     The default is '-fno-reciprocal-math'.
+
+'-ffinite-math-only'
+     Allow optimizations for floating-point arithmetic that assume that
+     arguments and results are not NaNs or +-Infs.
+
+     This option is not turned on by any '-O' option since it can result
+     in incorrect output for programs that depend on an exact
+     implementation of IEEE or ISO rules/specifications for math
+     functions.  It may, however, yield faster code for programs that do
+     not require the guarantees of these specifications.
+
+     The default is '-fno-finite-math-only'.
+
+'-fno-signed-zeros'
+     Allow optimizations for floating-point arithmetic that ignore the
+     signedness of zero.  IEEE arithmetic specifies the behavior of
+     distinct +0.0 and -0.0 values, which then prohibits simplification
+     of expressions such as x+0.0 or 0.0*x (even with
+     '-ffinite-math-only').  This option implies that the sign of a zero
+     result isn't significant.
+
+     The default is '-fsigned-zeros'.
+
+'-fno-trapping-math'
+     Compile code assuming that floating-point operations cannot
+     generate user-visible traps.  These traps include division by zero,
+     overflow, underflow, inexact result and invalid operation.  This
+     option requires that '-fno-signaling-nans' be in effect.  Setting
+     this option may allow faster code if one relies on "non-stop" IEEE
+     arithmetic, for example.
+
+     This option should never be turned on by any '-O' option since it
+     can result in incorrect output for programs that depend on an exact
+     implementation of IEEE or ISO rules/specifications for math
+     functions.
+
+     The default is '-ftrapping-math'.
+
+'-frounding-math'
+     Disable transformations and optimizations that assume default
+     floating-point rounding behavior.  This is round-to-zero for all
+     floating point to integer conversions, and round-to-nearest for all
+     other arithmetic truncations.  This option should be specified for
+     programs that change the FP rounding mode dynamically, or that may
+     be executed with a non-default rounding mode.  This option disables
+     constant folding of floating-point expressions at compile time
+     (which may be affected by rounding mode) and arithmetic
+     transformations that are unsafe in the presence of sign-dependent
+     rounding modes.
+
+     The default is '-fno-rounding-math'.
+
+     This option is experimental and does not currently guarantee to
+     disable all GCC optimizations that are affected by rounding mode.
+     Future versions of GCC may provide finer control of this setting
+     using C99's 'FENV_ACCESS' pragma.  This command-line option will be
+     used to specify the default state for 'FENV_ACCESS'.
+
+'-fsignaling-nans'
+     Compile code assuming that IEEE signaling NaNs may generate
+     user-visible traps during floating-point operations.  Setting this
+     option disables optimizations that may change the number of
+     exceptions visible with signaling NaNs.  This option implies
+     '-ftrapping-math'.
+
+     This option causes the preprocessor macro '__SUPPORT_SNAN__' to be
+     defined.
+
+     The default is '-fno-signaling-nans'.
+
+     This option is experimental and does not currently guarantee to
+     disable all GCC optimizations that affect signaling NaN behavior.
+
+'-fsingle-precision-constant'
+     Treat floating-point constants as single precision instead of
+     implicitly converting them to double-precision constants.
+
+'-fcx-limited-range'
+     When enabled, this option states that a range reduction step is not
+     needed when performing complex division.  Also, there is no
+     checking whether the result of a complex multiplication or division
+     is 'NaN + I*NaN', with an attempt to rescue the situation in that
+     case.  The default is '-fno-cx-limited-range', but is enabled by
+     '-ffast-math'.
+
+     This option controls the default setting of the ISO C99
+     'CX_LIMITED_RANGE' pragma.  Nevertheless, the option applies to all
+     languages.
+
+'-fcx-fortran-rules'
+     Complex multiplication and division follow Fortran rules.  Range
+     reduction is done as part of complex division, but there is no
+     checking whether the result of a complex multiplication or division
+     is 'NaN + I*NaN', with an attempt to rescue the situation in that
+     case.
+
+     The default is '-fno-cx-fortran-rules'.
+
+ The following options control optimizations that may improve
+performance, but are not enabled by any '-O' options.  This section
+includes experimental options that may produce broken code.
+
+'-fbranch-probabilities'
+     After running a program compiled with '-fprofile-arcs' (*note
+     Options for Debugging Your Program or 'gcc': Debugging Options.),
+     you can compile it a second time using '-fbranch-probabilities', to
+     improve optimizations based on the number of times each branch was
+     taken.  When a program compiled with '-fprofile-arcs' exits, it
+     saves arc execution counts to a file called 'SOURCENAME.gcda' for
+     each source file.  The information in this data file is very
+     dependent on the structure of the generated code, so you must use
+     the same source code and the same optimization options for both
+     compilations.
+
+     With '-fbranch-probabilities', GCC puts a 'REG_BR_PROB' note on
+     each 'JUMP_INSN' and 'CALL_INSN'.  These can be used to improve
+     optimization.  Currently, they are only used in one place: in
+     'reorg.c', instead of guessing which path a branch is most likely
+     to take, the 'REG_BR_PROB' values are used to exactly determine
+     which path is taken more often.
+
+'-fprofile-values'
+     If combined with '-fprofile-arcs', it adds code so that some data
+     about values of expressions in the program is gathered.
+
+     With '-fbranch-probabilities', it reads back the data gathered from
+     profiling values of expressions for usage in optimizations.
+
+     Enabled with '-fprofile-generate' and '-fprofile-use'.
+
+'-fprofile-reorder-functions'
+     Function reordering based on profile instrumentation collects first
+     time of execution of a function and orders these functions in
+     ascending order.
+
+     Enabled with '-fprofile-use'.
+
+'-fvpt'
+     If combined with '-fprofile-arcs', this option instructs the
+     compiler to add code to gather information about values of
+     expressions.
+
+     With '-fbranch-probabilities', it reads back the data gathered and
+     actually performs the optimizations based on them.  Currently the
+     optimizations include specialization of division operations using
+     the knowledge about the value of the denominator.
+
+'-frename-registers'
+     Attempt to avoid false dependencies in scheduled code by making use
+     of registers left over after register allocation.  This
+     optimization most benefits processors with lots of registers.
+     Depending on the debug information format adopted by the target,
+     however, it can make debugging impossible, since variables no
+     longer stay in a "home register".
+
+     Enabled by default with '-funroll-loops' and '-fpeel-loops'.
+
+'-ftracer'
+     Perform tail duplication to enlarge superblock size.  This
+     transformation simplifies the control flow of the function allowing
+     other optimizations to do a better job.
+
+     Enabled with '-fprofile-use'.
+
+'-funroll-loops'
+     Unroll loops whose number of iterations can be determined at
+     compile time or upon entry to the loop.  '-funroll-loops' implies
+     '-frerun-cse-after-loop', '-fweb' and '-frename-registers'.  It
+     also turns on complete loop peeling (i.e. complete removal of loops
+     with a small constant number of iterations).  This option makes
+     code larger, and may or may not make it run faster.
+
+     Enabled with '-fprofile-use'.
+
+'-funroll-all-loops'
+     Unroll all loops, even if their number of iterations is uncertain
+     when the loop is entered.  This usually makes programs run more
+     slowly.  '-funroll-all-loops' implies the same options as
+     '-funroll-loops'.
+
+'-fpeel-loops'
+     Peels loops for which there is enough information that they do not
+     roll much (from profile feedback).  It also turns on complete loop
+     peeling (i.e. complete removal of loops with small constant number
+     of iterations).
+
+     Enabled with '-fprofile-use'.
+
+'-fmove-loop-invariants'
+     Enables the loop invariant motion pass in the RTL loop optimizer.
+     Enabled at level '-O1'
+
+'-funswitch-loops'
+     Move branches with loop invariant conditions out of the loop, with
+     duplicates of the loop on both branches (modified according to
+     result of the condition).
+
+'-ffunction-sections'
+'-fdata-sections'
+     Place each function or data item into its own section in the output
+     file if the target supports arbitrary sections.  The name of the
+     function or the name of the data item determines the section's name
+     in the output file.
+
+     Use these options on systems where the linker can perform
+     optimizations to improve locality of reference in the instruction
+     space.  Most systems using the ELF object format and SPARC
+     processors running Solaris 2 have linkers with such optimizations.
+     AIX may have these optimizations in the future.
+
+     Only use these options when there are significant benefits from
+     doing so.  When you specify these options, the assembler and linker
+     create larger object and executable files and are also slower.  You
+     cannot use 'gprof' on all systems if you specify this option, and
+     you may have problems with debugging if you specify both this
+     option and '-g'.
+
+'-fbranch-target-load-optimize'
+     Perform branch target register load optimization before prologue /
+     epilogue threading.  The use of target registers can typically be
+     exposed only during reload, thus hoisting loads out of loops and
+     doing inter-block scheduling needs a separate optimization pass.
+
+'-fbranch-target-load-optimize2'
+     Perform branch target register load optimization after prologue /
+     epilogue threading.
+
+'-fbtr-bb-exclusive'
+     When performing branch target register load optimization, don't
+     reuse branch target registers within any basic block.
+
+'-fstack-protector'
+     Emit extra code to check for buffer overflows, such as stack
+     smashing attacks.  This is done by adding a guard variable to
+     functions with vulnerable objects.  This includes functions that
+     call 'alloca', and functions with buffers larger than 8 bytes.  The
+     guards are initialized when a function is entered and then checked
+     when the function exits.  If a guard check fails, an error message
+     is printed and the program exits.
+
+'-fstack-protector-all'
+     Like '-fstack-protector' except that all functions are protected.
+
+'-fstack-protector-strong'
+     Like '-fstack-protector' but includes additional functions to be
+     protected -- those that have local array definitions, or have
+     references to local frame addresses.
+
+'-fsection-anchors'
+     Try to reduce the number of symbolic address calculations by using
+     shared "anchor" symbols to address nearby objects.  This
+     transformation can help to reduce the number of GOT entries and GOT
+     accesses on some targets.
+
+     For example, the implementation of the following function 'foo':
+
+          static int a, b, c;
+          int foo (void) { return a + b + c; }
+
+     usually calculates the addresses of all three variables, but if you
+     compile it with '-fsection-anchors', it accesses the variables from
+     a common anchor point instead.  The effect is similar to the
+     following pseudocode (which isn't valid C):
+
+          int foo (void)
+          {
+            register int *xr = &x;
+            return xr[&a - &x] + xr[&b - &x] + xr[&c - &x];
+          }
+
+     Not all targets support this option.
+
+'--param NAME=VALUE'
+     In some places, GCC uses various constants to control the amount of
+     optimization that is done.  For example, GCC does not inline
+     functions that contain more than a certain number of instructions.
+     You can control some of these constants on the command line using
+     the '--param' option.
+
+     The names of specific parameters, and the meaning of the values,
+     are tied to the internals of the compiler, and are subject to
+     change without notice in future releases.
+
+     In each case, the VALUE is an integer.  The allowable choices for
+     NAME are:
+
+     'predictable-branch-outcome'
+          When branch is predicted to be taken with probability lower
+          than this threshold (in percent), then it is considered well
+          predictable.  The default is 10.
+
+     'max-crossjump-edges'
+          The maximum number of incoming edges to consider for
+          cross-jumping.  The algorithm used by '-fcrossjumping' is
+          O(N^2) in the number of edges incoming to each block.
+          Increasing values mean more aggressive optimization, making
+          the compilation time increase with probably small improvement
+          in executable size.
+
+     'min-crossjump-insns'
+          The minimum number of instructions that must be matched at the
+          end of two blocks before cross-jumping is performed on them.
+          This value is ignored in the case where all instructions in
+          the block being cross-jumped from are matched.  The default
+          value is 5.
+
+     'max-grow-copy-bb-insns'
+          The maximum code size expansion factor when copying basic
+          blocks instead of jumping.  The expansion is relative to a
+          jump instruction.  The default value is 8.
+
+     'max-goto-duplication-insns'
+          The maximum number of instructions to duplicate to a block
+          that jumps to a computed goto.  To avoid O(N^2) behavior in a
+          number of passes, GCC factors computed gotos early in the
+          compilation process, and unfactors them as late as possible.
+          Only computed jumps at the end of a basic blocks with no more
+          than max-goto-duplication-insns are unfactored.  The default
+          value is 8.
+
+     'max-delay-slot-insn-search'
+          The maximum number of instructions to consider when looking
+          for an instruction to fill a delay slot.  If more than this
+          arbitrary number of instructions are searched, the time
+          savings from filling the delay slot are minimal, so stop
+          searching.  Increasing values mean more aggressive
+          optimization, making the compilation time increase with
+          probably small improvement in execution time.
+
+     'max-delay-slot-live-search'
+          When trying to fill delay slots, the maximum number of
+          instructions to consider when searching for a block with valid
+          live register information.  Increasing this arbitrarily chosen
+          value means more aggressive optimization, increasing the
+          compilation time.  This parameter should be removed when the
+          delay slot code is rewritten to maintain the control-flow
+          graph.
+
+     'max-gcse-memory'
+          The approximate maximum amount of memory that can be allocated
+          in order to perform the global common subexpression
+          elimination optimization.  If more memory than specified is
+          required, the optimization is not done.
+
+     'max-gcse-insertion-ratio'
+          If the ratio of expression insertions to deletions is larger
+          than this value for any expression, then RTL PRE inserts or
+          removes the expression and thus leaves partially redundant
+          computations in the instruction stream.  The default value is
+          20.
+
+     'max-pending-list-length'
+          The maximum number of pending dependencies scheduling allows
+          before flushing the current state and starting over.  Large
+          functions with few branches or calls can create excessively
+          large lists which needlessly consume memory and resources.
+
+     'max-modulo-backtrack-attempts'
+          The maximum number of backtrack attempts the scheduler should
+          make when modulo scheduling a loop.  Larger values can
+          exponentially increase compilation time.
+
+     'max-inline-insns-single'
+          Several parameters control the tree inliner used in GCC.  This
+          number sets the maximum number of instructions (counted in
+          GCC's internal representation) in a single function that the
+          tree inliner considers for inlining.  This only affects
+          functions declared inline and methods implemented in a class
+          declaration (C++).  The default value is 400.
+
+     'max-inline-insns-auto'
+          When you use '-finline-functions' (included in '-O3'), a lot
+          of functions that would otherwise not be considered for
+          inlining by the compiler are investigated.  To those
+          functions, a different (more restrictive) limit compared to
+          functions declared inline can be applied.  The default value
+          is 40.
+
+     'inline-min-speedup'
+          When estimated performance improvement of caller + callee
+          runtime exceeds this threshold (in precent), the function can
+          be inlined regardless the limit on '--param
+          max-inline-insns-single' and '--param max-inline-insns-auto'.
+
+     'large-function-insns'
+          The limit specifying really large functions.  For functions
+          larger than this limit after inlining, inlining is constrained
+          by '--param large-function-growth'.  This parameter is useful
+          primarily to avoid extreme compilation time caused by
+          non-linear algorithms used by the back end.  The default value
+          is 2700.
+
+     'large-function-growth'
+          Specifies maximal growth of large function caused by inlining
+          in percents.  The default value is 100 which limits large
+          function growth to 2.0 times the original size.
+
+     'large-unit-insns'
+          The limit specifying large translation unit.  Growth caused by
+          inlining of units larger than this limit is limited by
+          '--param inline-unit-growth'.  For small units this might be
+          too tight.  For example, consider a unit consisting of
+          function A that is inline and B that just calls A three times.
+          If B is small relative to A, the growth of unit is 300\% and
+          yet such inlining is very sane.  For very large units
+          consisting of small inlineable functions, however, the overall
+          unit growth limit is needed to avoid exponential explosion of
+          code size.  Thus for smaller units, the size is increased to
+          '--param large-unit-insns' before applying '--param
+          inline-unit-growth'.  The default is 10000.
+
+     'inline-unit-growth'
+          Specifies maximal overall growth of the compilation unit
+          caused by inlining.  The default value is 30 which limits unit
+          growth to 1.3 times the original size.
+
+     'ipcp-unit-growth'
+          Specifies maximal overall growth of the compilation unit
+          caused by interprocedural constant propagation.  The default
+          value is 10 which limits unit growth to 1.1 times the original
+          size.
+
+     'large-stack-frame'
+          The limit specifying large stack frames.  While inlining the
+          algorithm is trying to not grow past this limit too much.  The
+          default value is 256 bytes.
+
+     'large-stack-frame-growth'
+          Specifies maximal growth of large stack frames caused by
+          inlining in percents.  The default value is 1000 which limits
+          large stack frame growth to 11 times the original size.
+
+     'max-inline-insns-recursive'
+     'max-inline-insns-recursive-auto'
+          Specifies the maximum number of instructions an out-of-line
+          copy of a self-recursive inline function can grow into by
+          performing recursive inlining.
+
+          For functions declared inline, '--param
+          max-inline-insns-recursive' is taken into account.  For
+          functions not declared inline, recursive inlining happens only
+          when '-finline-functions' (included in '-O3') is enabled and
+          '--param max-inline-insns-recursive-auto' is used.  The
+          default value is 450.
+
+     'max-inline-recursive-depth'
+     'max-inline-recursive-depth-auto'
+          Specifies the maximum recursion depth used for recursive
+          inlining.
+
+          For functions declared inline, '--param
+          max-inline-recursive-depth' is taken into account.  For
+          functions not declared inline, recursive inlining happens only
+          when '-finline-functions' (included in '-O3') is enabled and
+          '--param max-inline-recursive-depth-auto' is used.  The
+          default value is 8.
+
+     'min-inline-recursive-probability'
+          Recursive inlining is profitable only for function having deep
+          recursion in average and can hurt for function having little
+          recursion depth by increasing the prologue size or complexity
+          of function body to other optimizers.
+
+          When profile feedback is available (see '-fprofile-generate')
+          the actual recursion depth can be guessed from probability
+          that function recurses via a given call expression.  This
+          parameter limits inlining only to call expressions whose
+          probability exceeds the given threshold (in percents).  The
+          default value is 10.
+
+     'early-inlining-insns'
+          Specify growth that the early inliner can make.  In effect it
+          increases the amount of inlining for code having a large
+          abstraction penalty.  The default value is 10.
+
+     'max-early-inliner-iterations'
+     'max-early-inliner-iterations'
+          Limit of iterations of the early inliner.  This basically
+          bounds the number of nested indirect calls the early inliner
+          can resolve.  Deeper chains are still handled by late
+          inlining.
+
+     'comdat-sharing-probability'
+     'comdat-sharing-probability'
+          Probability (in percent) that C++ inline function with comdat
+          visibility are shared across multiple compilation units.  The
+          default value is 20.
+
+     'min-vect-loop-bound'
+          The minimum number of iterations under which loops are not
+          vectorized when '-ftree-vectorize' is used.  The number of
+          iterations after vectorization needs to be greater than the
+          value specified by this option to allow vectorization.  The
+          default value is 0.
+
+     'gcse-cost-distance-ratio'
+          Scaling factor in calculation of maximum distance an
+          expression can be moved by GCSE optimizations.  This is
+          currently supported only in the code hoisting pass.  The
+          bigger the ratio, the more aggressive code hoisting is with
+          simple expressions, i.e., the expressions that have cost less
+          than 'gcse-unrestricted-cost'.  Specifying 0 disables hoisting
+          of simple expressions.  The default value is 10.
+
+     'gcse-unrestricted-cost'
+          Cost, roughly measured as the cost of a single typical machine
+          instruction, at which GCSE optimizations do not constrain the
+          distance an expression can travel.  This is currently
+          supported only in the code hoisting pass.  The lesser the
+          cost, the more aggressive code hoisting is.  Specifying 0
+          allows all expressions to travel unrestricted distances.  The
+          default value is 3.
+
+     'max-hoist-depth'
+          The depth of search in the dominator tree for expressions to
+          hoist.  This is used to avoid quadratic behavior in hoisting
+          algorithm.  The value of 0 does not limit on the search, but
+          may slow down compilation of huge functions.  The default
+          value is 30.
+
+     'max-tail-merge-comparisons'
+          The maximum amount of similar bbs to compare a bb with.  This
+          is used to avoid quadratic behavior in tree tail merging.  The
+          default value is 10.
+
+     'max-tail-merge-iterations'
+          The maximum amount of iterations of the pass over the
+          function.  This is used to limit compilation time in tree tail
+          merging.  The default value is 2.
+
+     'max-unrolled-insns'
+          The maximum number of instructions that a loop may have to be
+          unrolled.  If a loop is unrolled, this parameter also
+          determines how many times the loop code is unrolled.
+
+     'max-average-unrolled-insns'
+          The maximum number of instructions biased by probabilities of
+          their execution that a loop may have to be unrolled.  If a
+          loop is unrolled, this parameter also determines how many
+          times the loop code is unrolled.
+
+     'max-unroll-times'
+          The maximum number of unrollings of a single loop.
+
+     'max-peeled-insns'
+          The maximum number of instructions that a loop may have to be
+          peeled.  If a loop is peeled, this parameter also determines
+          how many times the loop code is peeled.
+
+     'max-peel-times'
+          The maximum number of peelings of a single loop.
+
+     'max-peel-branches'
+          The maximum number of branches on the hot path through the
+          peeled sequence.
+
+     'max-completely-peeled-insns'
+          The maximum number of insns of a completely peeled loop.
+
+     'max-completely-peel-times'
+          The maximum number of iterations of a loop to be suitable for
+          complete peeling.
+
+     'max-completely-peel-loop-nest-depth'
+          The maximum depth of a loop nest suitable for complete
+          peeling.
+
+     'max-unswitch-insns'
+          The maximum number of insns of an unswitched loop.
+
+     'max-unswitch-level'
+          The maximum number of branches unswitched in a single loop.
+
+     'lim-expensive'
+          The minimum cost of an expensive expression in the loop
+          invariant motion.
+
+     'iv-consider-all-candidates-bound'
+          Bound on number of candidates for induction variables, below
+          which all candidates are considered for each use in induction
+          variable optimizations.  If there are more candidates than
+          this, only the most relevant ones are considered to avoid
+          quadratic time complexity.
+
+     'iv-max-considered-uses'
+          The induction variable optimizations give up on loops that
+          contain more induction variable uses.
+
+     'iv-always-prune-cand-set-bound'
+          If the number of candidates in the set is smaller than this
+          value, always try to remove unnecessary ivs from the set when
+          adding a new one.
+
+     'scev-max-expr-size'
+          Bound on size of expressions used in the scalar evolutions
+          analyzer.  Large expressions slow the analyzer.
+
+     'scev-max-expr-complexity'
+          Bound on the complexity of the expressions in the scalar
+          evolutions analyzer.  Complex expressions slow the analyzer.
+
+     'omega-max-vars'
+          The maximum number of variables in an Omega constraint system.
+          The default value is 128.
+
+     'omega-max-geqs'
+          The maximum number of inequalities in an Omega constraint
+          system.  The default value is 256.
+
+     'omega-max-eqs'
+          The maximum number of equalities in an Omega constraint
+          system.  The default value is 128.
+
+     'omega-max-wild-cards'
+          The maximum number of wildcard variables that the Omega solver
+          is able to insert.  The default value is 18.
+
+     'omega-hash-table-size'
+          The size of the hash table in the Omega solver.  The default
+          value is 550.
+
+     'omega-max-keys'
+          The maximal number of keys used by the Omega solver.  The
+          default value is 500.
+
+     'omega-eliminate-redundant-constraints'
+          When set to 1, use expensive methods to eliminate all
+          redundant constraints.  The default value is 0.
+
+     'vect-max-version-for-alignment-checks'
+          The maximum number of run-time checks that can be performed
+          when doing loop versioning for alignment in the vectorizer.
+
+     'vect-max-version-for-alias-checks'
+          The maximum number of run-time checks that can be performed
+          when doing loop versioning for alias in the vectorizer.
+
+     'vect-max-peeling-for-alignment'
+          The maximum number of loop peels to enhance access alignment
+          for vectorizer.  Value -1 means 'no limit'.
+
+     'max-iterations-to-track'
+          The maximum number of iterations of a loop the brute-force
+          algorithm for analysis of the number of iterations of the loop
+          tries to evaluate.
+
+     'hot-bb-count-ws-permille'
+          A basic block profile count is considered hot if it
+          contributes to the given permillage (i.e.  0...1000) of the
+          entire profiled execution.
+
+     'hot-bb-frequency-fraction'
+          Select fraction of the entry block frequency of executions of
+          basic block in function given basic block needs to have to be
+          considered hot.
+
+     'max-predicted-iterations'
+          The maximum number of loop iterations we predict statically.
+          This is useful in cases where a function contains a single
+          loop with known bound and another loop with unknown bound.
+          The known number of iterations is predicted correctly, while
+          the unknown number of iterations average to roughly 10.  This
+          means that the loop without bounds appears artificially cold
+          relative to the other one.
+
+     'builtin-expect-probability'
+          Control the probability of the expression having the specified
+          value.  This parameter takes a percentage (i.e.  0 ...  100)
+          as input.  The default probability of 90 is obtained
+          empirically.
+
+     'align-threshold'
+
+          Select fraction of the maximal frequency of executions of a
+          basic block in a function to align the basic block.
+
+     'align-loop-iterations'
+
+          A loop expected to iterate at least the selected number of
+          iterations is aligned.
+
+     'tracer-dynamic-coverage'
+     'tracer-dynamic-coverage-feedback'
+
+          This value is used to limit superblock formation once the
+          given percentage of executed instructions is covered.  This
+          limits unnecessary code size expansion.
+
+          The 'tracer-dynamic-coverage-feedback' is used only when
+          profile feedback is available.  The real profiles (as opposed
+          to statically estimated ones) are much less balanced allowing
+          the threshold to be larger value.
+
+     'tracer-max-code-growth'
+          Stop tail duplication once code growth has reached given
+          percentage.  This is a rather artificial limit, as most of the
+          duplicates are eliminated later in cross jumping, so it may be
+          set to much higher values than is the desired code growth.
+
+     'tracer-min-branch-ratio'
+
+          Stop reverse growth when the reverse probability of best edge
+          is less than this threshold (in percent).
+
+     'tracer-min-branch-ratio'
+     'tracer-min-branch-ratio-feedback'
+
+          Stop forward growth if the best edge has probability lower
+          than this threshold.
+
+          Similarly to 'tracer-dynamic-coverage' two values are present,
+          one for compilation for profile feedback and one for
+          compilation without.  The value for compilation with profile
+          feedback needs to be more conservative (higher) in order to
+          make tracer effective.
+
+     'max-cse-path-length'
+
+          The maximum number of basic blocks on path that CSE considers.
+          The default is 10.
+
+     'max-cse-insns'
+          The maximum number of instructions CSE processes before
+          flushing.  The default is 1000.
+
+     'ggc-min-expand'
+
+          GCC uses a garbage collector to manage its own memory
+          allocation.  This parameter specifies the minimum percentage
+          by which the garbage collector's heap should be allowed to
+          expand between collections.  Tuning this may improve
+          compilation speed; it has no effect on code generation.
+
+          The default is 30% + 70% * (RAM/1GB) with an upper bound of
+          100% when RAM >= 1GB.  If 'getrlimit' is available, the notion
+          of "RAM" is the smallest of actual RAM and 'RLIMIT_DATA' or
+          'RLIMIT_AS'.  If GCC is not able to calculate RAM on a
+          particular platform, the lower bound of 30% is used.  Setting
+          this parameter and 'ggc-min-heapsize' to zero causes a full
+          collection to occur at every opportunity.  This is extremely
+          slow, but can be useful for debugging.
+
+     'ggc-min-heapsize'
+
+          Minimum size of the garbage collector's heap before it begins
+          bothering to collect garbage.  The first collection occurs
+          after the heap expands by 'ggc-min-expand'% beyond
+          'ggc-min-heapsize'.  Again, tuning this may improve
+          compilation speed, and has no effect on code generation.
+
+          The default is the smaller of RAM/8, RLIMIT_RSS, or a limit
+          that tries to ensure that RLIMIT_DATA or RLIMIT_AS are not
+          exceeded, but with a lower bound of 4096 (four megabytes) and
+          an upper bound of 131072 (128 megabytes).  If GCC is not able
+          to calculate RAM on a particular platform, the lower bound is
+          used.  Setting this parameter very large effectively disables
+          garbage collection.  Setting this parameter and
+          'ggc-min-expand' to zero causes a full collection to occur at
+          every opportunity.
+
+     'max-reload-search-insns'
+          The maximum number of instruction reload should look backward
+          for equivalent register.  Increasing values mean more
+          aggressive optimization, making the compilation time increase
+          with probably slightly better performance.  The default value
+          is 100.
+
+     'max-cselib-memory-locations'
+          The maximum number of memory locations cselib should take into
+          account.  Increasing values mean more aggressive optimization,
+          making the compilation time increase with probably slightly
+          better performance.  The default value is 500.
+
+     'reorder-blocks-duplicate'
+     'reorder-blocks-duplicate-feedback'
+
+          Used by the basic block reordering pass to decide whether to
+          use unconditional branch or duplicate the code on its
+          destination.  Code is duplicated when its estimated size is
+          smaller than this value multiplied by the estimated size of
+          unconditional jump in the hot spots of the program.
+
+          The 'reorder-block-duplicate-feedback' is used only when
+          profile feedback is available.  It may be set to higher values
+          than 'reorder-block-duplicate' since information about the hot
+          spots is more accurate.
+
+     'max-sched-ready-insns'
+          The maximum number of instructions ready to be issued the
+          scheduler should consider at any given time during the first
+          scheduling pass.  Increasing values mean more thorough
+          searches, making the compilation time increase with probably
+          little benefit.  The default value is 100.
+
+     'max-sched-region-blocks'
+          The maximum number of blocks in a region to be considered for
+          interblock scheduling.  The default value is 10.
+
+     'max-pipeline-region-blocks'
+          The maximum number of blocks in a region to be considered for
+          pipelining in the selective scheduler.  The default value is
+          15.
+
+     'max-sched-region-insns'
+          The maximum number of insns in a region to be considered for
+          interblock scheduling.  The default value is 100.
+
+     'max-pipeline-region-insns'
+          The maximum number of insns in a region to be considered for
+          pipelining in the selective scheduler.  The default value is
+          200.
+
+     'min-spec-prob'
+          The minimum probability (in percents) of reaching a source
+          block for interblock speculative scheduling.  The default
+          value is 40.
+
+     'max-sched-extend-regions-iters'
+          The maximum number of iterations through CFG to extend
+          regions.  A value of 0 (the default) disables region
+          extensions.
+
+     'max-sched-insn-conflict-delay'
+          The maximum conflict delay for an insn to be considered for
+          speculative motion.  The default value is 3.
+
+     'sched-spec-prob-cutoff'
+          The minimal probability of speculation success (in percents),
+          so that speculative insns are scheduled.  The default value is
+          40.
+
+     'sched-spec-state-edge-prob-cutoff'
+          The minimum probability an edge must have for the scheduler to
+          save its state across it.  The default value is 10.
+
+     'sched-mem-true-dep-cost'
+          Minimal distance (in CPU cycles) between store and load
+          targeting same memory locations.  The default value is 1.
+
+     'selsched-max-lookahead'
+          The maximum size of the lookahead window of selective
+          scheduling.  It is a depth of search for available
+          instructions.  The default value is 50.
+
+     'selsched-max-sched-times'
+          The maximum number of times that an instruction is scheduled
+          during selective scheduling.  This is the limit on the number
+          of iterations through which the instruction may be pipelined.
+          The default value is 2.
+
+     'selsched-max-insns-to-rename'
+          The maximum number of best instructions in the ready list that
+          are considered for renaming in the selective scheduler.  The
+          default value is 2.
+
+     'sms-min-sc'
+          The minimum value of stage count that swing modulo scheduler
+          generates.  The default value is 2.
+
+     'max-last-value-rtl'
+          The maximum size measured as number of RTLs that can be
+          recorded in an expression in combiner for a pseudo register as
+          last known value of that register.  The default is 10000.
+
+     'integer-share-limit'
+          Small integer constants can use a shared data structure,
+          reducing the compiler's memory usage and increasing its speed.
+          This sets the maximum value of a shared integer constant.  The
+          default value is 256.
+
+     'ssp-buffer-size'
+          The minimum size of buffers (i.e. arrays) that receive stack
+          smashing protection when '-fstack-protection' is used.
+
+     'min-size-for-stack-sharing'
+          The minimum size of variables taking part in stack slot
+          sharing when not optimizing.  The default value is 32.
+
+     'max-jump-thread-duplication-stmts'
+          Maximum number of statements allowed in a block that needs to
+          be duplicated when threading jumps.
+
+     'max-fields-for-field-sensitive'
+          Maximum number of fields in a structure treated in a field
+          sensitive manner during pointer analysis.  The default is zero
+          for '-O0' and '-O1', and 100 for '-Os', '-O2', and '-O3'.
+
+     'prefetch-latency'
+          Estimate on average number of instructions that are executed
+          before prefetch finishes.  The distance prefetched ahead is
+          proportional to this constant.  Increasing this number may
+          also lead to less streams being prefetched (see
+          'simultaneous-prefetches').
+
+     'simultaneous-prefetches'
+          Maximum number of prefetches that can run at the same time.
+
+     'l1-cache-line-size'
+          The size of cache line in L1 cache, in bytes.
+
+     'l1-cache-size'
+          The size of L1 cache, in kilobytes.
+
+     'l2-cache-size'
+          The size of L2 cache, in kilobytes.
+
+     'min-insn-to-prefetch-ratio'
+          The minimum ratio between the number of instructions and the
+          number of prefetches to enable prefetching in a loop.
+
+     'prefetch-min-insn-to-mem-ratio'
+          The minimum ratio between the number of instructions and the
+          number of memory references to enable prefetching in a loop.
+
+     'use-canonical-types'
+          Whether the compiler should use the "canonical" type system.
+          By default, this should always be 1, which uses a more
+          efficient internal mechanism for comparing types in C++ and
+          Objective-C++.  However, if bugs in the canonical type system
+          are causing compilation failures, set this value to 0 to
+          disable canonical types.
+
+     'switch-conversion-max-branch-ratio'
+          Switch initialization conversion refuses to create arrays that
+          are bigger than 'switch-conversion-max-branch-ratio' times the
+          number of branches in the switch.
+
+     'max-partial-antic-length'
+          Maximum length of the partial antic set computed during the
+          tree partial redundancy elimination optimization
+          ('-ftree-pre') when optimizing at '-O3' and above.  For some
+          sorts of source code the enhanced partial redundancy
+          elimination optimization can run away, consuming all of the
+          memory available on the host machine.  This parameter sets a
+          limit on the length of the sets that are computed, which
+          prevents the runaway behavior.  Setting a value of 0 for this
+          parameter allows an unlimited set length.
+
+     'sccvn-max-scc-size'
+          Maximum size of a strongly connected component (SCC) during
+          SCCVN processing.  If this limit is hit, SCCVN processing for
+          the whole function is not done and optimizations depending on
+          it are disabled.  The default maximum SCC size is 10000.
+
+     'sccvn-max-alias-queries-per-access'
+          Maximum number of alias-oracle queries we perform when looking
+          for redundancies for loads and stores.  If this limit is hit
+          the search is aborted and the load or store is not considered
+          redundant.  The number of queries is algorithmically limited
+          to the number of stores on all paths from the load to the
+          function entry.  The default maxmimum number of queries is
+          1000.
+
+     'ira-max-loops-num'
+          IRA uses regional register allocation by default.  If a
+          function contains more loops than the number given by this
+          parameter, only at most the given number of the most
+          frequently-executed loops form regions for regional register
+          allocation.  The default value of the parameter is 100.
+
+     'ira-max-conflict-table-size'
+          Although IRA uses a sophisticated algorithm to compress the
+          conflict table, the table can still require excessive amounts
+          of memory for huge functions.  If the conflict table for a
+          function could be more than the size in MB given by this
+          parameter, the register allocator instead uses a faster,
+          simpler, and lower-quality algorithm that does not require
+          building a pseudo-register conflict table.  The default value
+          of the parameter is 2000.
+
+     'ira-loop-reserved-regs'
+          IRA can be used to evaluate more accurate register pressure in
+          loops for decisions to move loop invariants (see '-O3').  The
+          number of available registers reserved for some other purposes
+          is given by this parameter.  The default value of the
+          parameter is 2, which is the minimal number of registers
+          needed by typical instructions.  This value is the best found
+          from numerous experiments.
+
+     'loop-invariant-max-bbs-in-loop'
+          Loop invariant motion can be very expensive, both in
+          compilation time and in amount of needed compile-time memory,
+          with very large loops.  Loops with more basic blocks than this
+          parameter won't have loop invariant motion optimization
+          performed on them.  The default value of the parameter is 1000
+          for '-O1' and 10000 for '-O2' and above.
+
+     'loop-max-datarefs-for-datadeps'
+          Building data dapendencies is expensive for very large loops.
+          This parameter limits the number of data references in loops
+          that are considered for data dependence analysis.  These large
+          loops are no handled by the optimizations using loop data
+          dependencies.  The default value is 1000.
+
+     'max-vartrack-size'
+          Sets a maximum number of hash table slots to use during
+          variable tracking dataflow analysis of any function.  If this
+          limit is exceeded with variable tracking at assignments
+          enabled, analysis for that function is retried without it,
+          after removing all debug insns from the function.  If the
+          limit is exceeded even without debug insns, var tracking
+          analysis is completely disabled for the function.  Setting the
+          parameter to zero makes it unlimited.
+
+     'max-vartrack-expr-depth'
+          Sets a maximum number of recursion levels when attempting to
+          map variable names or debug temporaries to value expressions.
+          This trades compilation time for more complete debug
+          information.  If this is set too low, value expressions that
+          are available and could be represented in debug information
+          may end up not being used; setting this higher may enable the
+          compiler to find more complex debug expressions, but compile
+          time and memory use may grow.  The default is 12.
+
+     'min-nondebug-insn-uid'
+          Use uids starting at this parameter for nondebug insns.  The
+          range below the parameter is reserved exclusively for debug
+          insns created by '-fvar-tracking-assignments', but debug insns
+          may get (non-overlapping) uids above it if the reserved range
+          is exhausted.
+
+     'ipa-sra-ptr-growth-factor'
+          IPA-SRA replaces a pointer to an aggregate with one or more
+          new parameters only when their cumulative size is less or
+          equal to 'ipa-sra-ptr-growth-factor' times the size of the
+          original pointer parameter.
+
+     'tm-max-aggregate-size'
+          When making copies of thread-local variables in a transaction,
+          this parameter specifies the size in bytes after which
+          variables are saved with the logging functions as opposed to
+          save/restore code sequence pairs.  This option only applies
+          when using '-fgnu-tm'.
+
+     'graphite-max-nb-scop-params'
+          To avoid exponential effects in the Graphite loop transforms,
+          the number of parameters in a Static Control Part (SCoP) is
+          bounded.  The default value is 10 parameters.  A variable
+          whose value is unknown at compilation time and defined outside
+          a SCoP is a parameter of the SCoP.
+
+     'graphite-max-bbs-per-function'
+          To avoid exponential effects in the detection of SCoPs, the
+          size of the functions analyzed by Graphite is bounded.  The
+          default value is 100 basic blocks.
+
+     'loop-block-tile-size'
+          Loop blocking or strip mining transforms, enabled with
+          '-floop-block' or '-floop-strip-mine', strip mine each loop in
+          the loop nest by a given number of iterations.  The strip
+          length can be changed using the 'loop-block-tile-size'
+          parameter.  The default value is 51 iterations.
+
+     'ipa-cp-value-list-size'
+          IPA-CP attempts to track all possible values and types passed
+          to a function's parameter in order to propagate them and
+          perform devirtualization.  'ipa-cp-value-list-size' is the
+          maximum number of values and types it stores per one formal
+          parameter of a function.
+
+     'lto-partitions'
+          Specify desired number of partitions produced during WHOPR
+          compilation.  The number of partitions should exceed the
+          number of CPUs used for compilation.  The default value is 32.
+
+     'lto-minpartition'
+          Size of minimal partition for WHOPR (in estimated
+          instructions).  This prevents expenses of splitting very small
+          programs into too many partitions.
+
+     'cxx-max-namespaces-for-diagnostic-help'
+          The maximum number of namespaces to consult for suggestions
+          when C++ name lookup fails for an identifier.  The default is
+          1000.
+
+     'sink-frequency-threshold'
+          The maximum relative execution frequency (in percents) of the
+          target block relative to a statement's original block to allow
+          statement sinking of a statement.  Larger numbers result in
+          more aggressive statement sinking.  The default value is 75.
+          A small positive adjustment is applied for statements with
+          memory operands as those are even more profitable so sink.
+
+     'max-stores-to-sink'
+          The maximum number of conditional stores paires that can be
+          sunk.  Set to 0 if either vectorization ('-ftree-vectorize')
+          or if-conversion ('-ftree-loop-if-convert') is disabled.  The
+          default is 2.
+
+     'allow-load-data-races'
+          Allow optimizers to introduce new data races on loads.  Set to
+          1 to allow, otherwise to 0.  This option is enabled by default
+          unless implicitly set by the '-fmemory-model=' option.
+
+     'allow-store-data-races'
+          Allow optimizers to introduce new data races on stores.  Set
+          to 1 to allow, otherwise to 0.  This option is enabled by
+          default unless implicitly set by the '-fmemory-model=' option.
+
+     'allow-packed-load-data-races'
+          Allow optimizers to introduce new data races on packed data
+          loads.  Set to 1 to allow, otherwise to 0.  This option is
+          enabled by default unless implicitly set by the
+          '-fmemory-model=' option.
+
+     'allow-packed-store-data-races'
+          Allow optimizers to introduce new data races on packed data
+          stores.  Set to 1 to allow, otherwise to 0.  This option is
+          enabled by default unless implicitly set by the
+          '-fmemory-model=' option.
+
+     'case-values-threshold'
+          The smallest number of different values for which it is best
+          to use a jump-table instead of a tree of conditional branches.
+          If the value is 0, use the default for the machine.  The
+          default is 0.
+
+     'tree-reassoc-width'
+          Set the maximum number of instructions executed in parallel in
+          reassociated tree.  This parameter overrides target dependent
+          heuristics used by default if has non zero value.
+
+     'sched-pressure-algorithm'
+          Choose between the two available implementations of
+          '-fsched-pressure'.  Algorithm 1 is the original
+          implementation and is the more likely to prevent instructions
+          from being reordered.  Algorithm 2 was designed to be a
+          compromise between the relatively conservative approach taken
+          by algorithm 1 and the rather aggressive approach taken by the
+          default scheduler.  It relies more heavily on having a regular
+          register file and accurate register pressure classes.  See
+          'haifa-sched.c' in the GCC sources for more details.
+
+          The default choice depends on the target.
+
+     'max-slsr-cand-scan'
+          Set the maximum number of existing candidates that will be
+          considered when seeking a basis for a new straight-line
+          strength reduction candidate.
+
+     'asan-globals'
+          Enable buffer overflow detection for global objects.  This
+          kind of protection is enabled by default if you are using
+          '-fsanitize=address' option.  To disable global objects
+          protection use '--param asan-globals=0'.
+
+     'asan-stack'
+          Enable buffer overflow detection for stack objects.  This kind
+          of protection is enabled by default when
+          using'-fsanitize=address'.  To disable stack protection use
+          '--param asan-stack=0' option.
+
+     'asan-instrument-reads'
+          Enable buffer overflow detection for memory reads.  This kind
+          of protection is enabled by default when using
+          '-fsanitize=address'.  To disable memory reads protection use
+          '--param asan-instrument-reads=0'.
+
+     'asan-instrument-writes'
+          Enable buffer overflow detection for memory writes.  This kind
+          of protection is enabled by default when using
+          '-fsanitize=address'.  To disable memory writes protection use
+          '--param asan-instrument-writes=0' option.
+
+     'asan-memintrin'
+          Enable detection for built-in functions.  This kind of
+          protection is enabled by default when using
+          '-fsanitize=address'.  To disable built-in functions
+          protection use '--param asan-memintrin=0'.
+
+     'asan-use-after-return'
+          Enable detection of use-after-return.  This kind of protection
+          is enabled by default when using '-fsanitize=address' option.
+          To disable use-after-return detection use '--param
+          asan-use-after-return=0'.
+
+
+File: gcc.info,  Node: Preprocessor Options,  Next: Assembler Options,  Prev: Optimize Options,  Up: Invoking GCC
+
+3.11 Options Controlling the Preprocessor
+=========================================
+
+These options control the C preprocessor, which is run on each C source
+file before actual compilation.
+
+ If you use the '-E' option, nothing is done except preprocessing.  Some
+of these options make sense only together with '-E' because they cause
+the preprocessor output to be unsuitable for actual compilation.
+
+'-Wp,OPTION'
+     You can use '-Wp,OPTION' to bypass the compiler driver and pass
+     OPTION directly through to the preprocessor.  If OPTION contains
+     commas, it is split into multiple options at the commas.  However,
+     many options are modified, translated or interpreted by the
+     compiler driver before being passed to the preprocessor, and '-Wp'
+     forcibly bypasses this phase.  The preprocessor's direct interface
+     is undocumented and subject to change, so whenever possible you
+     should avoid using '-Wp' and let the driver handle the options
+     instead.
+
+'-Xpreprocessor OPTION'
+     Pass OPTION as an option to the preprocessor.  You can use this to
+     supply system-specific preprocessor options that GCC does not
+     recognize.
+
+     If you want to pass an option that takes an argument, you must use
+     '-Xpreprocessor' twice, once for the option and once for the
+     argument.
+
+'-no-integrated-cpp'
+     Perform preprocessing as a separate pass before compilation.  By
+     default, GCC performs preprocessing as an integrated part of input
+     tokenization and parsing.  If this option is provided, the
+     appropriate language front end ('cc1', 'cc1plus', or 'cc1obj' for
+     C, C++, and Objective-C, respectively) is instead invoked twice,
+     once for preprocessing only and once for actual compilation of the
+     preprocessed input.  This option may be useful in conjunction with
+     the '-B' or '-wrapper' options to specify an alternate preprocessor
+     or perform additional processing of the program source between
+     normal preprocessing and compilation.
+
+'-D NAME'
+     Predefine NAME as a macro, with definition '1'.
+
+'-D NAME=DEFINITION'
+     The contents of DEFINITION are tokenized and processed as if they
+     appeared during translation phase three in a '#define' directive.
+     In particular, the definition will be truncated by embedded newline
+     characters.
+
+     If you are invoking the preprocessor from a shell or shell-like
+     program you may need to use the shell's quoting syntax to protect
+     characters such as spaces that have a meaning in the shell syntax.
+
+     If you wish to define a function-like macro on the command line,
+     write its argument list with surrounding parentheses before the
+     equals sign (if any).  Parentheses are meaningful to most shells,
+     so you will need to quote the option.  With 'sh' and 'csh',
+     '-D'NAME(ARGS...)=DEFINITION'' works.
+
+     '-D' and '-U' options are processed in the order they are given on
+     the command line.  All '-imacros FILE' and '-include FILE' options
+     are processed after all '-D' and '-U' options.
+
+'-U NAME'
+     Cancel any previous definition of NAME, either built in or provided
+     with a '-D' option.
+
+'-undef'
+     Do not predefine any system-specific or GCC-specific macros.  The
+     standard predefined macros remain defined.
+
+'-I DIR'
+     Add the directory DIR to the list of directories to be searched for
+     header files.  Directories named by '-I' are searched before the
+     standard system include directories.  If the directory DIR is a
+     standard system include directory, the option is ignored to ensure
+     that the default search order for system directories and the
+     special treatment of system headers are not defeated .  If DIR
+     begins with '=', then the '=' will be replaced by the sysroot
+     prefix; see '--sysroot' and '-isysroot'.
+
+'-o FILE'
+     Write output to FILE.  This is the same as specifying FILE as the
+     second non-option argument to 'cpp'.  'gcc' has a different
+     interpretation of a second non-option argument, so you must use
+     '-o' to specify the output file.
+
+'-Wall'
+     Turns on all optional warnings which are desirable for normal code.
+     At present this is '-Wcomment', '-Wtrigraphs', '-Wmultichar' and a
+     warning about integer promotion causing a change of sign in '#if'
+     expressions.  Note that many of the preprocessor's warnings are on
+     by default and have no options to control them.
+
+'-Wcomment'
+'-Wcomments'
+     Warn whenever a comment-start sequence '/*' appears in a '/*'
+     comment, or whenever a backslash-newline appears in a '//' comment.
+     (Both forms have the same effect.)
+
+'-Wtrigraphs'
+     Most trigraphs in comments cannot affect the meaning of the
+     program.  However, a trigraph that would form an escaped newline
+     ('??/' at the end of a line) can, by changing where the comment
+     begins or ends.  Therefore, only trigraphs that would form escaped
+     newlines produce warnings inside a comment.
+
+     This option is implied by '-Wall'.  If '-Wall' is not given, this
+     option is still enabled unless trigraphs are enabled.  To get
+     trigraph conversion without warnings, but get the other '-Wall'
+     warnings, use '-trigraphs -Wall -Wno-trigraphs'.
+
+'-Wtraditional'
+     Warn about certain constructs that behave differently in
+     traditional and ISO C.  Also warn about ISO C constructs that have
+     no traditional C equivalent, and problematic constructs which
+     should be avoided.
+
+'-Wundef'
+     Warn whenever an identifier which is not a macro is encountered in
+     an '#if' directive, outside of 'defined'.  Such identifiers are
+     replaced with zero.
+
+'-Wunused-macros'
+     Warn about macros defined in the main file that are unused.  A
+     macro is "used" if it is expanded or tested for existence at least
+     once.  The preprocessor will also warn if the macro has not been
+     used at the time it is redefined or undefined.
+
+     Built-in macros, macros defined on the command line, and macros
+     defined in include files are not warned about.
+
+     _Note:_ If a macro is actually used, but only used in skipped
+     conditional blocks, then CPP will report it as unused.  To avoid
+     the warning in such a case, you might improve the scope of the
+     macro's definition by, for example, moving it into the first
+     skipped block.  Alternatively, you could provide a dummy use with
+     something like:
+
+          #if defined the_macro_causing_the_warning
+          #endif
+
+'-Wendif-labels'
+     Warn whenever an '#else' or an '#endif' are followed by text.  This
+     usually happens in code of the form
+
+          #if FOO
+          ...
+          #else FOO
+          ...
+          #endif FOO
+
+     The second and third 'FOO' should be in comments, but often are not
+     in older programs.  This warning is on by default.
+
+'-Werror'
+     Make all warnings into hard errors.  Source code which triggers
+     warnings will be rejected.
+
+'-Wsystem-headers'
+     Issue warnings for code in system headers.  These are normally
+     unhelpful in finding bugs in your own code, therefore suppressed.
+     If you are responsible for the system library, you may want to see
+     them.
+
+'-w'
+     Suppress all warnings, including those which GNU CPP issues by
+     default.
+
+'-pedantic'
+     Issue all the mandatory diagnostics listed in the C standard.  Some
+     of them are left out by default, since they trigger frequently on
+     harmless code.
+
+'-pedantic-errors'
+     Issue all the mandatory diagnostics, and make all mandatory
+     diagnostics into errors.  This includes mandatory diagnostics that
+     GCC issues without '-pedantic' but treats as warnings.
+
+'-M'
+     Instead of outputting the result of preprocessing, output a rule
+     suitable for 'make' describing the dependencies of the main source
+     file.  The preprocessor outputs one 'make' rule containing the
+     object file name for that source file, a colon, and the names of
+     all the included files, including those coming from '-include' or
+     '-imacros' command line options.
+
+     Unless specified explicitly (with '-MT' or '-MQ'), the object file
+     name consists of the name of the source file with any suffix
+     replaced with object file suffix and with any leading directory
+     parts removed.  If there are many included files then the rule is
+     split into several lines using '\'-newline.  The rule has no
+     commands.
+
+     This option does not suppress the preprocessor's debug output, such
+     as '-dM'.  To avoid mixing such debug output with the dependency
+     rules you should explicitly specify the dependency output file with
+     '-MF', or use an environment variable like 'DEPENDENCIES_OUTPUT'
+     (*note Environment Variables::).  Debug output will still be sent
+     to the regular output stream as normal.
+
+     Passing '-M' to the driver implies '-E', and suppresses warnings
+     with an implicit '-w'.
+
+'-MM'
+     Like '-M' but do not mention header files that are found in system
+     header directories, nor header files that are included, directly or
+     indirectly, from such a header.
+
+     This implies that the choice of angle brackets or double quotes in
+     an '#include' directive does not in itself determine whether that
+     header will appear in '-MM' dependency output.  This is a slight
+     change in semantics from GCC versions 3.0 and earlier.
+
+'-MF FILE'
+     When used with '-M' or '-MM', specifies a file to write the
+     dependencies to.  If no '-MF' switch is given the preprocessor
+     sends the rules to the same place it would have sent preprocessed
+     output.
+
+     When used with the driver options '-MD' or '-MMD', '-MF' overrides
+     the default dependency output file.
+
+'-MG'
+     In conjunction with an option such as '-M' requesting dependency
+     generation, '-MG' assumes missing header files are generated files
+     and adds them to the dependency list without raising an error.  The
+     dependency filename is taken directly from the '#include' directive
+     without prepending any path.  '-MG' also suppresses preprocessed
+     output, as a missing header file renders this useless.
+
+     This feature is used in automatic updating of makefiles.
+
+'-MP'
+     This option instructs CPP to add a phony target for each dependency
+     other than the main file, causing each to depend on nothing.  These
+     dummy rules work around errors 'make' gives if you remove header
+     files without updating the 'Makefile' to match.
+
+     This is typical output:
+
+          test.o: test.c test.h
+
+          test.h:
+
+'-MT TARGET'
+
+     Change the target of the rule emitted by dependency generation.  By
+     default CPP takes the name of the main input file, deletes any
+     directory components and any file suffix such as '.c', and appends
+     the platform's usual object suffix.  The result is the target.
+
+     An '-MT' option will set the target to be exactly the string you
+     specify.  If you want multiple targets, you can specify them as a
+     single argument to '-MT', or use multiple '-MT' options.
+
+     For example, '-MT '$(objpfx)foo.o'' might give
+
+          $(objpfx)foo.o: foo.c
+
+'-MQ TARGET'
+
+     Same as '-MT', but it quotes any characters which are special to
+     Make.  '-MQ '$(objpfx)foo.o'' gives
+
+          $$(objpfx)foo.o: foo.c
+
+     The default target is automatically quoted, as if it were given
+     with '-MQ'.
+
+'-MD'
+     '-MD' is equivalent to '-M -MF FILE', except that '-E' is not
+     implied.  The driver determines FILE based on whether an '-o'
+     option is given.  If it is, the driver uses its argument but with a
+     suffix of '.d', otherwise it takes the name of the input file,
+     removes any directory components and suffix, and applies a '.d'
+     suffix.
+
+     If '-MD' is used in conjunction with '-E', any '-o' switch is
+     understood to specify the dependency output file (*note -MF:
+     dashMF.), but if used without '-E', each '-o' is understood to
+     specify a target object file.
+
+     Since '-E' is not implied, '-MD' can be used to generate a
+     dependency output file as a side-effect of the compilation process.
+
+'-MMD'
+     Like '-MD' except mention only user header files, not system header
+     files.
+
+'-fpch-deps'
+     When using precompiled headers (*note Precompiled Headers::), this
+     flag will cause the dependency-output flags to also list the files
+     from the precompiled header's dependencies.  If not specified only
+     the precompiled header would be listed and not the files that were
+     used to create it because those files are not consulted when a
+     precompiled header is used.
+
+'-fpch-preprocess'
+     This option allows use of a precompiled header (*note Precompiled
+     Headers::) together with '-E'.  It inserts a special '#pragma',
+     '#pragma GCC pch_preprocess "FILENAME"' in the output to mark the
+     place where the precompiled header was found, and its FILENAME.
+     When '-fpreprocessed' is in use, GCC recognizes this '#pragma' and
+     loads the PCH.
+
+     This option is off by default, because the resulting preprocessed
+     output is only really suitable as input to GCC.  It is switched on
+     by '-save-temps'.
+
+     You should not write this '#pragma' in your own code, but it is
+     safe to edit the filename if the PCH file is available in a
+     different location.  The filename may be absolute or it may be
+     relative to GCC's current directory.
+
+'-x c'
+'-x c++'
+'-x objective-c'
+'-x assembler-with-cpp'
+     Specify the source language: C, C++, Objective-C, or assembly.
+     This has nothing to do with standards conformance or extensions; it
+     merely selects which base syntax to expect.  If you give none of
+     these options, cpp will deduce the language from the extension of
+     the source file: '.c', '.cc', '.m', or '.S'.  Some other common
+     extensions for C++ and assembly are also recognized.  If cpp does
+     not recognize the extension, it will treat the file as C; this is
+     the most generic mode.
+
+     _Note:_ Previous versions of cpp accepted a '-lang' option which
+     selected both the language and the standards conformance level.
+     This option has been removed, because it conflicts with the '-l'
+     option.
+
+'-std=STANDARD'
+'-ansi'
+     Specify the standard to which the code should conform.  Currently
+     CPP knows about C and C++ standards; others may be added in the
+     future.
+
+     STANDARD may be one of:
+     'c90'
+     'c89'
+     'iso9899:1990'
+          The ISO C standard from 1990.  'c90' is the customary
+          shorthand for this version of the standard.
+
+          The '-ansi' option is equivalent to '-std=c90'.
+
+     'iso9899:199409'
+          The 1990 C standard, as amended in 1994.
+
+     'iso9899:1999'
+     'c99'
+     'iso9899:199x'
+     'c9x'
+          The revised ISO C standard, published in December 1999.
+          Before publication, this was known as C9X.
+
+     'iso9899:2011'
+     'c11'
+     'c1x'
+          The revised ISO C standard, published in December 2011.
+          Before publication, this was known as C1X.
+
+     'gnu90'
+     'gnu89'
+          The 1990 C standard plus GNU extensions.  This is the default.
+
+     'gnu99'
+     'gnu9x'
+          The 1999 C standard plus GNU extensions.
+
+     'gnu11'
+     'gnu1x'
+          The 2011 C standard plus GNU extensions.
+
+     'c++98'
+          The 1998 ISO C++ standard plus amendments.
+
+     'gnu++98'
+          The same as '-std=c++98' plus GNU extensions.  This is the
+          default for C++ code.
+
+'-I-'
+     Split the include path.  Any directories specified with '-I'
+     options before '-I-' are searched only for headers requested with
+     '#include "FILE"'; they are not searched for '#include <FILE>'.  If
+     additional directories are specified with '-I' options after the
+     '-I-', those directories are searched for all '#include'
+     directives.
+
+     In addition, '-I-' inhibits the use of the directory of the current
+     file directory as the first search directory for '#include "FILE"'.
+     This option has been deprecated.
+
+'-nostdinc'
+     Do not search the standard system directories for header files.
+     Only the directories you have specified with '-I' options (and the
+     directory of the current file, if appropriate) are searched.
+
+'-nostdinc++'
+     Do not search for header files in the C++-specific standard
+     directories, but do still search the other standard directories.
+     (This option is used when building the C++ library.)
+
+'-include FILE'
+     Process FILE as if '#include "file"' appeared as the first line of
+     the primary source file.  However, the first directory searched for
+     FILE is the preprocessor's working directory _instead of_ the
+     directory containing the main source file.  If not found there, it
+     is searched for in the remainder of the '#include "..."' search
+     chain as normal.
+
+     If multiple '-include' options are given, the files are included in
+     the order they appear on the command line.
+
+'-imacros FILE'
+     Exactly like '-include', except that any output produced by
+     scanning FILE is thrown away.  Macros it defines remain defined.
+     This allows you to acquire all the macros from a header without
+     also processing its declarations.
+
+     All files specified by '-imacros' are processed before all files
+     specified by '-include'.
+
+'-idirafter DIR'
+     Search DIR for header files, but do it _after_ all directories
+     specified with '-I' and the standard system directories have been
+     exhausted.  DIR is treated as a system include directory.  If DIR
+     begins with '=', then the '=' will be replaced by the sysroot
+     prefix; see '--sysroot' and '-isysroot'.
+
+'-iprefix PREFIX'
+     Specify PREFIX as the prefix for subsequent '-iwithprefix' options.
+     If the prefix represents a directory, you should include the final
+     '/'.
+
+'-iwithprefix DIR'
+'-iwithprefixbefore DIR'
+     Append DIR to the prefix specified previously with '-iprefix', and
+     add the resulting directory to the include search path.
+     '-iwithprefixbefore' puts it in the same place '-I' would;
+     '-iwithprefix' puts it where '-idirafter' would.
+
+'-isysroot DIR'
+     This option is like the '--sysroot' option, but applies only to
+     header files (except for Darwin targets, where it applies to both
+     header files and libraries).  See the '--sysroot' option for more
+     information.
+
+'-imultilib DIR'
+     Use DIR as a subdirectory of the directory containing
+     target-specific C++ headers.
+
+'-isystem DIR'
+     Search DIR for header files, after all directories specified by
+     '-I' but before the standard system directories.  Mark it as a
+     system directory, so that it gets the same special treatment as is
+     applied to the standard system directories.  If DIR begins with
+     '=', then the '=' will be replaced by the sysroot prefix; see
+     '--sysroot' and '-isysroot'.
+
+'-iquote DIR'
+     Search DIR only for header files requested with '#include "FILE"';
+     they are not searched for '#include <FILE>', before all directories
+     specified by '-I' and before the standard system directories.  If
+     DIR begins with '=', then the '=' will be replaced by the sysroot
+     prefix; see '--sysroot' and '-isysroot'.
+
+'-fdirectives-only'
+     When preprocessing, handle directives, but do not expand macros.
+
+     The option's behavior depends on the '-E' and '-fpreprocessed'
+     options.
+
+     With '-E', preprocessing is limited to the handling of directives
+     such as '#define', '#ifdef', and '#error'.  Other preprocessor
+     operations, such as macro expansion and trigraph conversion are not
+     performed.  In addition, the '-dD' option is implicitly enabled.
+
+     With '-fpreprocessed', predefinition of command line and most
+     builtin macros is disabled.  Macros such as '__LINE__', which are
+     contextually dependent, are handled normally.  This enables
+     compilation of files previously preprocessed with '-E
+     -fdirectives-only'.
+
+     With both '-E' and '-fpreprocessed', the rules for '-fpreprocessed'
+     take precedence.  This enables full preprocessing of files
+     previously preprocessed with '-E -fdirectives-only'.
+
+'-fdollars-in-identifiers'
+     Accept '$' in identifiers.
+
+'-fextended-identifiers'
+     Accept universal character names in identifiers.  This option is
+     experimental; in a future version of GCC, it will be enabled by
+     default for C99 and C++.
+
+'-fno-canonical-system-headers'
+     When preprocessing, do not shorten system header paths with
+     canonicalization.
+
+'-fpreprocessed'
+     Indicate to the preprocessor that the input file has already been
+     preprocessed.  This suppresses things like macro expansion,
+     trigraph conversion, escaped newline splicing, and processing of
+     most directives.  The preprocessor still recognizes and removes
+     comments, so that you can pass a file preprocessed with '-C' to the
+     compiler without problems.  In this mode the integrated
+     preprocessor is little more than a tokenizer for the front ends.
+
+     '-fpreprocessed' is implicit if the input file has one of the
+     extensions '.i', '.ii' or '.mi'.  These are the extensions that GCC
+     uses for preprocessed files created by '-save-temps'.
+
+'-ftabstop=WIDTH'
+     Set the distance between tab stops.  This helps the preprocessor
+     report correct column numbers in warnings or errors, even if tabs
+     appear on the line.  If the value is less than 1 or greater than
+     100, the option is ignored.  The default is 8.
+
+'-fdebug-cpp'
+     This option is only useful for debugging GCC. When used with '-E',
+     dumps debugging information about location maps.  Every token in
+     the output is preceded by the dump of the map its location belongs
+     to.  The dump of the map holding the location of a token would be:
+          {'P':/file/path;'F':/includer/path;'L':LINE_NUM;'C':COL_NUM;'S':SYSTEM_HEADER_P;'M':MAP_ADDRESS;'E':MACRO_EXPANSION_P,'loc':LOCATION}
+
+     When used without '-E', this option has no effect.
+
+'-ftrack-macro-expansion[=LEVEL]'
+     Track locations of tokens across macro expansions.  This allows the
+     compiler to emit diagnostic about the current macro expansion stack
+     when a compilation error occurs in a macro expansion.  Using this
+     option makes the preprocessor and the compiler consume more memory.
+     The LEVEL parameter can be used to choose the level of precision of
+     token location tracking thus decreasing the memory consumption if
+     necessary.  Value '0' of LEVEL de-activates this option just as if
+     no '-ftrack-macro-expansion' was present on the command line.
+     Value '1' tracks tokens locations in a degraded mode for the sake
+     of minimal memory overhead.  In this mode all tokens resulting from
+     the expansion of an argument of a function-like macro have the same
+     location.  Value '2' tracks tokens locations completely.  This
+     value is the most memory hungry.  When this option is given no
+     argument, the default parameter value is '2'.
+
+     Note that -ftrack-macro-expansion=2 is activated by default.
+
+'-fexec-charset=CHARSET'
+     Set the execution character set, used for string and character
+     constants.  The default is UTF-8.  CHARSET can be any encoding
+     supported by the system's 'iconv' library routine.
+
+'-fwide-exec-charset=CHARSET'
+     Set the wide execution character set, used for wide string and
+     character constants.  The default is UTF-32 or UTF-16, whichever
+     corresponds to the width of 'wchar_t'.  As with '-fexec-charset',
+     CHARSET can be any encoding supported by the system's 'iconv'
+     library routine; however, you will have problems with encodings
+     that do not fit exactly in 'wchar_t'.
+
+'-finput-charset=CHARSET'
+     Set the input character set, used for translation from the
+     character set of the input file to the source character set used by
+     GCC.  If the locale does not specify, or GCC cannot get this
+     information from the locale, the default is UTF-8.  This can be
+     overridden by either the locale or this command line option.
+     Currently the command line option takes precedence if there's a
+     conflict.  CHARSET can be any encoding supported by the system's
+     'iconv' library routine.
+
+'-fworking-directory'
+     Enable generation of linemarkers in the preprocessor output that
+     will let the compiler know the current working directory at the
+     time of preprocessing.  When this option is enabled, the
+     preprocessor will emit, after the initial linemarker, a second
+     linemarker with the current working directory followed by two
+     slashes.  GCC will use this directory, when it's present in the
+     preprocessed input, as the directory emitted as the current working
+     directory in some debugging information formats.  This option is
+     implicitly enabled if debugging information is enabled, but this
+     can be inhibited with the negated form '-fno-working-directory'.
+     If the '-P' flag is present in the command line, this option has no
+     effect, since no '#line' directives are emitted whatsoever.
+
+'-fno-show-column'
+     Do not print column numbers in diagnostics.  This may be necessary
+     if diagnostics are being scanned by a program that does not
+     understand the column numbers, such as 'dejagnu'.
+
+'-A PREDICATE=ANSWER'
+     Make an assertion with the predicate PREDICATE and answer ANSWER.
+     This form is preferred to the older form '-A PREDICATE(ANSWER)',
+     which is still supported, because it does not use shell special
+     characters.
+
+'-A -PREDICATE=ANSWER'
+     Cancel an assertion with the predicate PREDICATE and answer ANSWER.
+
+'-dCHARS'
+     CHARS is a sequence of one or more of the following characters, and
+     must not be preceded by a space.  Other characters are interpreted
+     by the compiler proper, or reserved for future versions of GCC, and
+     so are silently ignored.  If you specify characters whose behavior
+     conflicts, the result is undefined.
+
+     'M'
+          Instead of the normal output, generate a list of '#define'
+          directives for all the macros defined during the execution of
+          the preprocessor, including predefined macros.  This gives you
+          a way of finding out what is predefined in your version of the
+          preprocessor.  Assuming you have no file 'foo.h', the command
+
+               touch foo.h; cpp -dM foo.h
+
+          will show all the predefined macros.
+
+          If you use '-dM' without the '-E' option, '-dM' is interpreted
+          as a synonym for '-fdump-rtl-mach'.  *Note (gcc)Debugging
+          Options::.
+
+     'D'
+          Like 'M' except in two respects: it does _not_ include the
+          predefined macros, and it outputs _both_ the '#define'
+          directives and the result of preprocessing.  Both kinds of
+          output go to the standard output file.
+
+     'N'
+          Like 'D', but emit only the macro names, not their expansions.
+
+     'I'
+          Output '#include' directives in addition to the result of
+          preprocessing.
+
+     'U'
+          Like 'D' except that only macros that are expanded, or whose
+          definedness is tested in preprocessor directives, are output;
+          the output is delayed until the use or test of the macro; and
+          '#undef' directives are also output for macros tested but
+          undefined at the time.
+
+'-P'
+     Inhibit generation of linemarkers in the output from the
+     preprocessor.  This might be useful when running the preprocessor
+     on something that is not C code, and will be sent to a program
+     which might be confused by the linemarkers.
+
+'-C'
+     Do not discard comments.  All comments are passed through to the
+     output file, except for comments in processed directives, which are
+     deleted along with the directive.
+
+     You should be prepared for side effects when using '-C'; it causes
+     the preprocessor to treat comments as tokens in their own right.
+     For example, comments appearing at the start of what would be a
+     directive line have the effect of turning that line into an
+     ordinary source line, since the first token on the line is no
+     longer a '#'.
+
+'-CC'
+     Do not discard comments, including during macro expansion.  This is
+     like '-C', except that comments contained within macros are also
+     passed through to the output file where the macro is expanded.
+
+     In addition to the side-effects of the '-C' option, the '-CC'
+     option causes all C++-style comments inside a macro to be converted
+     to C-style comments.  This is to prevent later use of that macro
+     from inadvertently commenting out the remainder of the source line.
+
+     The '-CC' option is generally used to support lint comments.
+
+'-traditional-cpp'
+     Try to imitate the behavior of old-fashioned C preprocessors, as
+     opposed to ISO C preprocessors.
+
+'-trigraphs'
+     Process trigraph sequences.  These are three-character sequences,
+     all starting with '??', that are defined by ISO C to stand for
+     single characters.  For example, '??/' stands for '\', so ''??/n''
+     is a character constant for a newline.  By default, GCC ignores
+     trigraphs, but in standard-conforming modes it converts them.  See
+     the '-std' and '-ansi' options.
+
+     The nine trigraphs and their replacements are
+
+          Trigraph:       ??(  ??)  ??<  ??>  ??=  ??/  ??'  ??!  ??-
+          Replacement:      [    ]    {    }    #    \    ^    |    ~
+
+'-remap'
+     Enable special code to work around file systems which only permit
+     very short file names, such as MS-DOS.
+
+'--help'
+'--target-help'
+     Print text describing all the command line options instead of
+     preprocessing anything.
+
+'-v'
+     Verbose mode.  Print out GNU CPP's version number at the beginning
+     of execution, and report the final form of the include path.
+
+'-H'
+     Print the name of each header file used, in addition to other
+     normal activities.  Each name is indented to show how deep in the
+     '#include' stack it is.  Precompiled header files are also printed,
+     even if they are found to be invalid; an invalid precompiled header
+     file is printed with '...x' and a valid one with '...!' .
+
+'-version'
+'--version'
+     Print out GNU CPP's version number.  With one dash, proceed to
+     preprocess as normal.  With two dashes, exit immediately.
+
+
+File: gcc.info,  Node: Assembler Options,  Next: Link Options,  Prev: Preprocessor Options,  Up: Invoking GCC
+
+3.12 Passing Options to the Assembler
+=====================================
+
+You can pass options to the assembler.
+
+'-Wa,OPTION'
+     Pass OPTION as an option to the assembler.  If OPTION contains
+     commas, it is split into multiple options at the commas.
+
+'-Xassembler OPTION'
+     Pass OPTION as an option to the assembler.  You can use this to
+     supply system-specific assembler options that GCC does not
+     recognize.
+
+     If you want to pass an option that takes an argument, you must use
+     '-Xassembler' twice, once for the option and once for the argument.
+
+
+File: gcc.info,  Node: Link Options,  Next: Directory Options,  Prev: Assembler Options,  Up: Invoking GCC
+
+3.13 Options for Linking
+========================
+
+These options come into play when the compiler links object files into
+an executable output file.  They are meaningless if the compiler is not
+doing a link step.
+
+'OBJECT-FILE-NAME'
+     A file name that does not end in a special recognized suffix is
+     considered to name an object file or library.  (Object files are
+     distinguished from libraries by the linker according to the file
+     contents.)  If linking is done, these object files are used as
+     input to the linker.
+
+'-c'
+'-S'
+'-E'
+     If any of these options is used, then the linker is not run, and
+     object file names should not be used as arguments.  *Note Overall
+     Options::.
+
+'-lLIBRARY'
+'-l LIBRARY'
+     Search the library named LIBRARY when linking.  (The second
+     alternative with the library as a separate argument is only for
+     POSIX compliance and is not recommended.)
+
+     It makes a difference where in the command you write this option;
+     the linker searches and processes libraries and object files in the
+     order they are specified.  Thus, 'foo.o -lz bar.o' searches library
+     'z' after file 'foo.o' but before 'bar.o'.  If 'bar.o' refers to
+     functions in 'z', those functions may not be loaded.
+
+     The linker searches a standard list of directories for the library,
+     which is actually a file named 'libLIBRARY.a'.  The linker then
+     uses this file as if it had been specified precisely by name.
+
+     The directories searched include several standard system
+     directories plus any that you specify with '-L'.
+
+     Normally the files found this way are library files--archive files
+     whose members are object files.  The linker handles an archive file
+     by scanning through it for members which define symbols that have
+     so far been referenced but not defined.  But if the file that is
+     found is an ordinary object file, it is linked in the usual
+     fashion.  The only difference between using an '-l' option and
+     specifying a file name is that '-l' surrounds LIBRARY with 'lib'
+     and '.a' and searches several directories.
+
+'-lobjc'
+     You need this special case of the '-l' option in order to link an
+     Objective-C or Objective-C++ program.
+
+'-nostartfiles'
+     Do not use the standard system startup files when linking.  The
+     standard system libraries are used normally, unless '-nostdlib' or
+     '-nodefaultlibs' is used.
+
+'-nodefaultlibs'
+     Do not use the standard system libraries when linking.  Only the
+     libraries you specify are passed to the linker, and options
+     specifying linkage of the system libraries, such as
+     '-static-libgcc' or '-shared-libgcc', are ignored.  The standard
+     startup files are used normally, unless '-nostartfiles' is used.
+
+     The compiler may generate calls to 'memcmp', 'memset', 'memcpy' and
+     'memmove'.  These entries are usually resolved by entries in libc.
+     These entry points should be supplied through some other mechanism
+     when this option is specified.
+
+'-nostdlib'
+     Do not use the standard system startup files or libraries when
+     linking.  No startup files and only the libraries you specify are
+     passed to the linker, and options specifying linkage of the system
+     libraries, such as '-static-libgcc' or '-shared-libgcc', are
+     ignored.
+
+     The compiler may generate calls to 'memcmp', 'memset', 'memcpy' and
+     'memmove'.  These entries are usually resolved by entries in libc.
+     These entry points should be supplied through some other mechanism
+     when this option is specified.
+
+     One of the standard libraries bypassed by '-nostdlib' and
+     '-nodefaultlibs' is 'libgcc.a', a library of internal subroutines
+     which GCC uses to overcome shortcomings of particular machines, or
+     special needs for some languages.  (*Note Interfacing to GCC
+     Output: (gccint)Interface, for more discussion of 'libgcc.a'.)  In
+     most cases, you need 'libgcc.a' even when you want to avoid other
+     standard libraries.  In other words, when you specify '-nostdlib'
+     or '-nodefaultlibs' you should usually specify '-lgcc' as well.
+     This ensures that you have no unresolved references to internal GCC
+     library subroutines.  (An example of such an internal subroutine is
+     '__main', used to ensure C++ constructors are called; *note
+     'collect2': (gccint)Collect2.)
+
+'-pie'
+     Produce a position independent executable on targets that support
+     it.  For predictable results, you must also specify the same set of
+     options used for compilation ('-fpie', '-fPIE', or model
+     suboptions) when you specify this linker option.
+
+'-rdynamic'
+     Pass the flag '-export-dynamic' to the ELF linker, on targets that
+     support it.  This instructs the linker to add all symbols, not only
+     used ones, to the dynamic symbol table.  This option is needed for
+     some uses of 'dlopen' or to allow obtaining backtraces from within
+     a program.
+
+'-s'
+     Remove all symbol table and relocation information from the
+     executable.
+
+'-static'
+     On systems that support dynamic linking, this prevents linking with
+     the shared libraries.  On other systems, this option has no effect.
+
+'-shared'
+     Produce a shared object which can then be linked with other objects
+     to form an executable.  Not all systems support this option.  For
+     predictable results, you must also specify the same set of options
+     used for compilation ('-fpic', '-fPIC', or model suboptions) when
+     you specify this linker option.(1)
+
+'-shared-libgcc'
+'-static-libgcc'
+     On systems that provide 'libgcc' as a shared library, these options
+     force the use of either the shared or static version, respectively.
+     If no shared version of 'libgcc' was built when the compiler was
+     configured, these options have no effect.
+
+     There are several situations in which an application should use the
+     shared 'libgcc' instead of the static version.  The most common of
+     these is when the application wishes to throw and catch exceptions
+     across different shared libraries.  In that case, each of the
+     libraries as well as the application itself should use the shared
+     'libgcc'.
+
+     Therefore, the G++ and GCJ drivers automatically add
+     '-shared-libgcc' whenever you build a shared library or a main
+     executable, because C++ and Java programs typically use exceptions,
+     so this is the right thing to do.
+
+     If, instead, you use the GCC driver to create shared libraries, you
+     may find that they are not always linked with the shared 'libgcc'.
+     If GCC finds, at its configuration time, that you have a non-GNU
+     linker or a GNU linker that does not support option
+     '--eh-frame-hdr', it links the shared version of 'libgcc' into
+     shared libraries by default.  Otherwise, it takes advantage of the
+     linker and optimizes away the linking with the shared version of
+     'libgcc', linking with the static version of libgcc by default.
+     This allows exceptions to propagate through such shared libraries,
+     without incurring relocation costs at library load time.
+
+     However, if a library or main executable is supposed to throw or
+     catch exceptions, you must link it using the G++ or GCJ driver, as
+     appropriate for the languages used in the program, or using the
+     option '-shared-libgcc', such that it is linked with the shared
+     'libgcc'.
+
+'-static-libasan'
+     When the '-fsanitize=address' option is used to link a program, the
+     GCC driver automatically links against 'libasan'.  If 'libasan' is
+     available as a shared library, and the '-static' option is not
+     used, then this links against the shared version of 'libasan'.  The
+     '-static-libasan' option directs the GCC driver to link 'libasan'
+     statically, without necessarily linking other libraries statically.
+
+'-static-libtsan'
+     When the '-fsanitize=thread' option is used to link a program, the
+     GCC driver automatically links against 'libtsan'.  If 'libtsan' is
+     available as a shared library, and the '-static' option is not
+     used, then this links against the shared version of 'libtsan'.  The
+     '-static-libtsan' option directs the GCC driver to link 'libtsan'
+     statically, without necessarily linking other libraries statically.
+
+'-static-liblsan'
+     When the '-fsanitize=leak' option is used to link a program, the
+     GCC driver automatically links against 'liblsan'.  If 'liblsan' is
+     available as a shared library, and the '-static' option is not
+     used, then this links against the shared version of 'liblsan'.  The
+     '-static-liblsan' option directs the GCC driver to link 'liblsan'
+     statically, without necessarily linking other libraries statically.
+
+'-static-libubsan'
+     When the '-fsanitize=undefined' option is used to link a program,
+     the GCC driver automatically links against 'libubsan'.  If
+     'libubsan' is available as a shared library, and the '-static'
+     option is not used, then this links against the shared version of
+     'libubsan'.  The '-static-libubsan' option directs the GCC driver
+     to link 'libubsan' statically, without necessarily linking other
+     libraries statically.
+
+'-static-libstdc++'
+     When the 'g++' program is used to link a C++ program, it normally
+     automatically links against 'libstdc++'.  If 'libstdc++' is
+     available as a shared library, and the '-static' option is not
+     used, then this links against the shared version of 'libstdc++'.
+     That is normally fine.  However, it is sometimes useful to freeze
+     the version of 'libstdc++' used by the program without going all
+     the way to a fully static link.  The '-static-libstdc++' option
+     directs the 'g++' driver to link 'libstdc++' statically, without
+     necessarily linking other libraries statically.
+
+'-symbolic'
+     Bind references to global symbols when building a shared object.
+     Warn about any unresolved references (unless overridden by the link
+     editor option '-Xlinker -z -Xlinker defs').  Only a few systems
+     support this option.
+
+'-T SCRIPT'
+     Use SCRIPT as the linker script.  This option is supported by most
+     systems using the GNU linker.  On some targets, such as bare-board
+     targets without an operating system, the '-T' option may be
+     required when linking to avoid references to undefined symbols.
+
+'-Xlinker OPTION'
+     Pass OPTION as an option to the linker.  You can use this to supply
+     system-specific linker options that GCC does not recognize.
+
+     If you want to pass an option that takes a separate argument, you
+     must use '-Xlinker' twice, once for the option and once for the
+     argument.  For example, to pass '-assert definitions', you must
+     write '-Xlinker -assert -Xlinker definitions'.  It does not work to
+     write '-Xlinker "-assert definitions"', because this passes the
+     entire string as a single argument, which is not what the linker
+     expects.
+
+     When using the GNU linker, it is usually more convenient to pass
+     arguments to linker options using the 'OPTION=VALUE' syntax than as
+     separate arguments.  For example, you can specify '-Xlinker
+     -Map=output.map' rather than '-Xlinker -Map -Xlinker output.map'.
+     Other linkers may not support this syntax for command-line options.
+
+'-Wl,OPTION'
+     Pass OPTION as an option to the linker.  If OPTION contains commas,
+     it is split into multiple options at the commas.  You can use this
+     syntax to pass an argument to the option.  For example,
+     '-Wl,-Map,output.map' passes '-Map output.map' to the linker.  When
+     using the GNU linker, you can also get the same effect with
+     '-Wl,-Map=output.map'.
+
+'-u SYMBOL'
+     Pretend the symbol SYMBOL is undefined, to force linking of library
+     modules to define it.  You can use '-u' multiple times with
+     different symbols to force loading of additional library modules.
+
+   ---------- Footnotes ----------
+
+   (1) On some systems, 'gcc -shared' needs to build supplementary stub
+code for constructors to work.  On multi-libbed systems, 'gcc -shared'
+must select the correct support libraries to link against.  Failing to
+supply the correct flags may lead to subtle defects.  Supplying them in
+cases where they are not necessary is innocuous.
+
+
+File: gcc.info,  Node: Directory Options,  Next: Spec Files,  Prev: Link Options,  Up: Invoking GCC
+
+3.14 Options for Directory Search
+=================================
+
+These options specify directories to search for header files, for
+libraries and for parts of the compiler:
+
+'-IDIR'
+     Add the directory DIR to the head of the list of directories to be
+     searched for header files.  This can be used to override a system
+     header file, substituting your own version, since these directories
+     are searched before the system header file directories.  However,
+     you should not use this option to add directories that contain
+     vendor-supplied system header files (use '-isystem' for that).  If
+     you use more than one '-I' option, the directories are scanned in
+     left-to-right order; the standard system directories come after.
+
+     If a standard system include directory, or a directory specified
+     with '-isystem', is also specified with '-I', the '-I' option is
+     ignored.  The directory is still searched but as a system directory
+     at its normal position in the system include chain.  This is to
+     ensure that GCC's procedure to fix buggy system headers and the
+     ordering for the 'include_next' directive are not inadvertently
+     changed.  If you really need to change the search order for system
+     directories, use the '-nostdinc' and/or '-isystem' options.
+
+'-iplugindir=DIR'
+     Set the directory to search for plugins that are passed by
+     '-fplugin=NAME' instead of '-fplugin=PATH/NAME.so'.  This option is
+     not meant to be used by the user, but only passed by the driver.
+
+'-iquoteDIR'
+     Add the directory DIR to the head of the list of directories to be
+     searched for header files only for the case of '#include "FILE"';
+     they are not searched for '#include <FILE>', otherwise just like
+     '-I'.
+
+'-LDIR'
+     Add directory DIR to the list of directories to be searched for
+     '-l'.
+
+'-BPREFIX'
+     This option specifies where to find the executables, libraries,
+     include files, and data files of the compiler itself.
+
+     The compiler driver program runs one or more of the subprograms
+     'cpp', 'cc1', 'as' and 'ld'.  It tries PREFIX as a prefix for each
+     program it tries to run, both with and without 'MACHINE/VERSION/'
+     (*note Target Options::).
+
+     For each subprogram to be run, the compiler driver first tries the
+     '-B' prefix, if any.  If that name is not found, or if '-B' is not
+     specified, the driver tries two standard prefixes, '/usr/lib/gcc/'
+     and '/usr/local/lib/gcc/'.  If neither of those results in a file
+     name that is found, the unmodified program name is searched for
+     using the directories specified in your 'PATH' environment
+     variable.
+
+     The compiler checks to see if the path provided by the '-B' refers
+     to a directory, and if necessary it adds a directory separator
+     character at the end of the path.
+
+     '-B' prefixes that effectively specify directory names also apply
+     to libraries in the linker, because the compiler translates these
+     options into '-L' options for the linker.  They also apply to
+     include files in the preprocessor, because the compiler translates
+     these options into '-isystem' options for the preprocessor.  In
+     this case, the compiler appends 'include' to the prefix.
+
+     The runtime support file 'libgcc.a' can also be searched for using
+     the '-B' prefix, if needed.  If it is not found there, the two
+     standard prefixes above are tried, and that is all.  The file is
+     left out of the link if it is not found by those means.
+
+     Another way to specify a prefix much like the '-B' prefix is to use
+     the environment variable 'GCC_EXEC_PREFIX'.  *Note Environment
+     Variables::.
+
+     As a special kludge, if the path provided by '-B' is
+     '[dir/]stageN/', where N is a number in the range 0 to 9, then it
+     is replaced by '[dir/]include'.  This is to help with
+     boot-strapping the compiler.
+
+'-specs=FILE'
+     Process FILE after the compiler reads in the standard 'specs' file,
+     in order to override the defaults which the 'gcc' driver program
+     uses when determining what switches to pass to 'cc1', 'cc1plus',
+     'as', 'ld', etc.  More than one '-specs=FILE' can be specified on
+     the command line, and they are processed in order, from left to
+     right.
+
+'--sysroot=DIR'
+     Use DIR as the logical root directory for headers and libraries.
+     For example, if the compiler normally searches for headers in
+     '/usr/include' and libraries in '/usr/lib', it instead searches
+     'DIR/usr/include' and 'DIR/usr/lib'.
+
+     If you use both this option and the '-isysroot' option, then the
+     '--sysroot' option applies to libraries, but the '-isysroot' option
+     applies to header files.
+
+     The GNU linker (beginning with version 2.16) has the necessary
+     support for this option.  If your linker does not support this
+     option, the header file aspect of '--sysroot' still works, but the
+     library aspect does not.
+
+'--no-sysroot-suffix'
+     For some targets, a suffix is added to the root directory specified
+     with '--sysroot', depending on the other options used, so that
+     headers may for example be found in 'DIR/SUFFIX/usr/include'
+     instead of 'DIR/usr/include'.  This option disables the addition of
+     such a suffix.
+
+'-I-'
+     This option has been deprecated.  Please use '-iquote' instead for
+     '-I' directories before the '-I-' and remove the '-I-'.  Any
+     directories you specify with '-I' options before the '-I-' option
+     are searched only for the case of '#include "FILE"'; they are not
+     searched for '#include <FILE>'.
+
+     If additional directories are specified with '-I' options after the
+     '-I-', these directories are searched for all '#include'
+     directives.  (Ordinarily _all_ '-I' directories are used this way.)
+
+     In addition, the '-I-' option inhibits the use of the current
+     directory (where the current input file came from) as the first
+     search directory for '#include "FILE"'.  There is no way to
+     override this effect of '-I-'.  With '-I.' you can specify
+     searching the directory that is current when the compiler is
+     invoked.  That is not exactly the same as what the preprocessor
+     does by default, but it is often satisfactory.
+
+     '-I-' does not inhibit the use of the standard system directories
+     for header files.  Thus, '-I-' and '-nostdinc' are independent.
+
+
+File: gcc.info,  Node: Spec Files,  Next: Target Options,  Prev: Directory Options,  Up: Invoking GCC
+
+3.15 Specifying subprocesses and the switches to pass to them
+=============================================================
+
+'gcc' is a driver program.  It performs its job by invoking a sequence
+of other programs to do the work of compiling, assembling and linking.
+GCC interprets its command-line parameters and uses these to deduce
+which programs it should invoke, and which command-line options it ought
+to place on their command lines.  This behavior is controlled by "spec
+strings".  In most cases there is one spec string for each program that
+GCC can invoke, but a few programs have multiple spec strings to control
+their behavior.  The spec strings built into GCC can be overridden by
+using the '-specs=' command-line switch to specify a spec file.
+
+ "Spec files" are plaintext files that are used to construct spec
+strings.  They consist of a sequence of directives separated by blank
+lines.  The type of directive is determined by the first non-whitespace
+character on the line, which can be one of the following:
+
+'%COMMAND'
+     Issues a COMMAND to the spec file processor.  The commands that can
+     appear here are:
+
+     '%include <FILE>'
+          Search for FILE and insert its text at the current point in
+          the specs file.
+
+     '%include_noerr <FILE>'
+          Just like '%include', but do not generate an error message if
+          the include file cannot be found.
+
+     '%rename OLD_NAME NEW_NAME'
+          Rename the spec string OLD_NAME to NEW_NAME.
+
+'*[SPEC_NAME]:'
+     This tells the compiler to create, override or delete the named
+     spec string.  All lines after this directive up to the next
+     directive or blank line are considered to be the text for the spec
+     string.  If this results in an empty string then the spec is
+     deleted.  (Or, if the spec did not exist, then nothing happens.)
+     Otherwise, if the spec does not currently exist a new spec is
+     created.  If the spec does exist then its contents are overridden
+     by the text of this directive, unless the first character of that
+     text is the '+' character, in which case the text is appended to
+     the spec.
+
+'[SUFFIX]:'
+     Creates a new '[SUFFIX] spec' pair.  All lines after this directive
+     and up to the next directive or blank line are considered to make
+     up the spec string for the indicated suffix.  When the compiler
+     encounters an input file with the named suffix, it processes the
+     spec string in order to work out how to compile that file.  For
+     example:
+
+          .ZZ:
+          z-compile -input %i
+
+     This says that any input file whose name ends in '.ZZ' should be
+     passed to the program 'z-compile', which should be invoked with the
+     command-line switch '-input' and with the result of performing the
+     '%i' substitution.  (See below.)
+
+     As an alternative to providing a spec string, the text following a
+     suffix directive can be one of the following:
+
+     '@LANGUAGE'
+          This says that the suffix is an alias for a known LANGUAGE.
+          This is similar to using the '-x' command-line switch to GCC
+          to specify a language explicitly.  For example:
+
+               .ZZ:
+               @c++
+
+          Says that .ZZ files are, in fact, C++ source files.
+
+     '#NAME'
+          This causes an error messages saying:
+
+               NAME compiler not installed on this system.
+
+     GCC already has an extensive list of suffixes built into it.  This
+     directive adds an entry to the end of the list of suffixes, but
+     since the list is searched from the end backwards, it is
+     effectively possible to override earlier entries using this
+     technique.
+
+ GCC has the following spec strings built into it.  Spec files can
+override these strings or create their own.  Note that individual
+targets can also add their own spec strings to this list.
+
+     asm          Options to pass to the assembler
+     asm_final    Options to pass to the assembler post-processor
+     cpp          Options to pass to the C preprocessor
+     cc1          Options to pass to the C compiler
+     cc1plus      Options to pass to the C++ compiler
+     endfile      Object files to include at the end of the link
+     link         Options to pass to the linker
+     lib          Libraries to include on the command line to the linker
+     libgcc       Decides which GCC support library to pass to the linker
+     linker       Sets the name of the linker
+     predefines   Defines to be passed to the C preprocessor
+     signed_char  Defines to pass to CPP to say whether char is signed
+                  by default
+     startfile    Object files to include at the start of the link
+
+ Here is a small example of a spec file:
+
+     %rename lib                 old_lib
+
+     *lib:
+     --start-group -lgcc -lc -leval1 --end-group %(old_lib)
+
+ This example renames the spec called 'lib' to 'old_lib' and then
+overrides the previous definition of 'lib' with a new one.  The new
+definition adds in some extra command-line options before including the
+text of the old definition.
+
+ "Spec strings" are a list of command-line options to be passed to their
+corresponding program.  In addition, the spec strings can contain
+'%'-prefixed sequences to substitute variable text or to conditionally
+insert text into the command line.  Using these constructs it is
+possible to generate quite complex command lines.
+
+ Here is a table of all defined '%'-sequences for spec strings.  Note
+that spaces are not generated automatically around the results of
+expanding these sequences.  Therefore you can concatenate them together
+or combine them with constant text in a single argument.
+
+'%%'
+     Substitute one '%' into the program name or argument.
+
+'%i'
+     Substitute the name of the input file being processed.
+
+'%b'
+     Substitute the basename of the input file being processed.  This is
+     the substring up to (and not including) the last period and not
+     including the directory.
+
+'%B'
+     This is the same as '%b', but include the file suffix (text after
+     the last period).
+
+'%d'
+     Marks the argument containing or following the '%d' as a temporary
+     file name, so that that file is deleted if GCC exits successfully.
+     Unlike '%g', this contributes no text to the argument.
+
+'%gSUFFIX'
+     Substitute a file name that has suffix SUFFIX and is chosen once
+     per compilation, and mark the argument in the same way as '%d'.  To
+     reduce exposure to denial-of-service attacks, the file name is now
+     chosen in a way that is hard to predict even when previously chosen
+     file names are known.  For example, '%g.s ... %g.o ... %g.s' might
+     turn into 'ccUVUUAU.s ccXYAXZ12.o ccUVUUAU.s'.  SUFFIX matches the
+     regexp '[.A-Za-z]*' or the special string '%O', which is treated
+     exactly as if '%O' had been preprocessed.  Previously, '%g' was
+     simply substituted with a file name chosen once per compilation,
+     without regard to any appended suffix (which was therefore treated
+     just like ordinary text), making such attacks more likely to
+     succeed.
+
+'%uSUFFIX'
+     Like '%g', but generates a new temporary file name each time it
+     appears instead of once per compilation.
+
+'%USUFFIX'
+     Substitutes the last file name generated with '%uSUFFIX',
+     generating a new one if there is no such last file name.  In the
+     absence of any '%uSUFFIX', this is just like '%gSUFFIX', except
+     they don't share the same suffix _space_, so '%g.s ... %U.s ...
+     %g.s ... %U.s' involves the generation of two distinct file names,
+     one for each '%g.s' and another for each '%U.s'.  Previously, '%U'
+     was simply substituted with a file name chosen for the previous
+     '%u', without regard to any appended suffix.
+
+'%jSUFFIX'
+     Substitutes the name of the 'HOST_BIT_BUCKET', if any, and if it is
+     writable, and if '-save-temps' is not used; otherwise, substitute
+     the name of a temporary file, just like '%u'.  This temporary file
+     is not meant for communication between processes, but rather as a
+     junk disposal mechanism.
+
+'%|SUFFIX'
+'%mSUFFIX'
+     Like '%g', except if '-pipe' is in effect.  In that case '%|'
+     substitutes a single dash and '%m' substitutes nothing at all.
+     These are the two most common ways to instruct a program that it
+     should read from standard input or write to standard output.  If
+     you need something more elaborate you can use an '%{pipe:'X'}'
+     construct: see for example 'f/lang-specs.h'.
+
+'%.SUFFIX'
+     Substitutes .SUFFIX for the suffixes of a matched switch's args
+     when it is subsequently output with '%*'.  SUFFIX is terminated by
+     the next space or %.
+
+'%w'
+     Marks the argument containing or following the '%w' as the
+     designated output file of this compilation.  This puts the argument
+     into the sequence of arguments that '%o' substitutes.
+
+'%o'
+     Substitutes the names of all the output files, with spaces
+     automatically placed around them.  You should write spaces around
+     the '%o' as well or the results are undefined.  '%o' is for use in
+     the specs for running the linker.  Input files whose names have no
+     recognized suffix are not compiled at all, but they are included
+     among the output files, so they are linked.
+
+'%O'
+     Substitutes the suffix for object files.  Note that this is handled
+     specially when it immediately follows '%g, %u, or %U', because of
+     the need for those to form complete file names.  The handling is
+     such that '%O' is treated exactly as if it had already been
+     substituted, except that '%g, %u, and %U' do not currently support
+     additional SUFFIX characters following '%O' as they do following,
+     for example, '.o'.
+
+'%p'
+     Substitutes the standard macro predefinitions for the current
+     target machine.  Use this when running 'cpp'.
+
+'%P'
+     Like '%p', but puts '__' before and after the name of each
+     predefined macro, except for macros that start with '__' or with
+     '_L', where L is an uppercase letter.  This is for ISO C.
+
+'%I'
+     Substitute any of '-iprefix' (made from 'GCC_EXEC_PREFIX'),
+     '-isysroot' (made from 'TARGET_SYSTEM_ROOT'), '-isystem' (made from
+     'COMPILER_PATH' and '-B' options) and '-imultilib' as necessary.
+
+'%s'
+     Current argument is the name of a library or startup file of some
+     sort.  Search for that file in a standard list of directories and
+     substitute the full name found.  The current working directory is
+     included in the list of directories scanned.
+
+'%T'
+     Current argument is the name of a linker script.  Search for that
+     file in the current list of directories to scan for libraries.  If
+     the file is located insert a '--script' option into the command
+     line followed by the full path name found.  If the file is not
+     found then generate an error message.  Note: the current working
+     directory is not searched.
+
+'%eSTR'
+     Print STR as an error message.  STR is terminated by a newline.
+     Use this when inconsistent options are detected.
+
+'%(NAME)'
+     Substitute the contents of spec string NAME at this point.
+
+'%x{OPTION}'
+     Accumulate an option for '%X'.
+
+'%X'
+     Output the accumulated linker options specified by '-Wl' or a '%x'
+     spec string.
+
+'%Y'
+     Output the accumulated assembler options specified by '-Wa'.
+
+'%Z'
+     Output the accumulated preprocessor options specified by '-Wp'.
+
+'%a'
+     Process the 'asm' spec.  This is used to compute the switches to be
+     passed to the assembler.
+
+'%A'
+     Process the 'asm_final' spec.  This is a spec string for passing
+     switches to an assembler post-processor, if such a program is
+     needed.
+
+'%l'
+     Process the 'link' spec.  This is the spec for computing the
+     command line passed to the linker.  Typically it makes use of the
+     '%L %G %S %D and %E' sequences.
+
+'%D'
+     Dump out a '-L' option for each directory that GCC believes might
+     contain startup files.  If the target supports multilibs then the
+     current multilib directory is prepended to each of these paths.
+
+'%L'
+     Process the 'lib' spec.  This is a spec string for deciding which
+     libraries are included on the command line to the linker.
+
+'%G'
+     Process the 'libgcc' spec.  This is a spec string for deciding
+     which GCC support library is included on the command line to the
+     linker.
+
+'%S'
+     Process the 'startfile' spec.  This is a spec for deciding which
+     object files are the first ones passed to the linker.  Typically
+     this might be a file named 'crt0.o'.
+
+'%E'
+     Process the 'endfile' spec.  This is a spec string that specifies
+     the last object files that are passed to the linker.
+
+'%C'
+     Process the 'cpp' spec.  This is used to construct the arguments to
+     be passed to the C preprocessor.
+
+'%1'
+     Process the 'cc1' spec.  This is used to construct the options to
+     be passed to the actual C compiler ('cc1').
+
+'%2'
+     Process the 'cc1plus' spec.  This is used to construct the options
+     to be passed to the actual C++ compiler ('cc1plus').
+
+'%*'
+     Substitute the variable part of a matched option.  See below.  Note
+     that each comma in the substituted string is replaced by a single
+     space.
+
+'%<S'
+     Remove all occurrences of '-S' from the command line.  Note--this
+     command is position dependent.  '%' commands in the spec string
+     before this one see '-S', '%' commands in the spec string after
+     this one do not.
+
+'%:FUNCTION(ARGS)'
+     Call the named function FUNCTION, passing it ARGS.  ARGS is first
+     processed as a nested spec string, then split into an argument
+     vector in the usual fashion.  The function returns a string which
+     is processed as if it had appeared literally as part of the current
+     spec.
+
+     The following built-in spec functions are provided:
+
+     'getenv'
+          The 'getenv' spec function takes two arguments: an environment
+          variable name and a string.  If the environment variable is
+          not defined, a fatal error is issued.  Otherwise, the return
+          value is the value of the environment variable concatenated
+          with the string.  For example, if 'TOPDIR' is defined as
+          '/path/to/top', then:
+
+               %:getenv(TOPDIR /include)
+
+          expands to '/path/to/top/include'.
+
+     'if-exists'
+          The 'if-exists' spec function takes one argument, an absolute
+          pathname to a file.  If the file exists, 'if-exists' returns
+          the pathname.  Here is a small example of its usage:
+
+               *startfile:
+               crt0%O%s %:if-exists(crti%O%s) crtbegin%O%s
+
+     'if-exists-else'
+          The 'if-exists-else' spec function is similar to the
+          'if-exists' spec function, except that it takes two arguments.
+          The first argument is an absolute pathname to a file.  If the
+          file exists, 'if-exists-else' returns the pathname.  If it
+          does not exist, it returns the second argument.  This way,
+          'if-exists-else' can be used to select one file or another,
+          based on the existence of the first.  Here is a small example
+          of its usage:
+
+               *startfile:
+               crt0%O%s %:if-exists(crti%O%s) \
+               %:if-exists-else(crtbeginT%O%s crtbegin%O%s)
+
+     'replace-outfile'
+          The 'replace-outfile' spec function takes two arguments.  It
+          looks for the first argument in the outfiles array and
+          replaces it with the second argument.  Here is a small example
+          of its usage:
+
+               %{fgnu-runtime:%:replace-outfile(-lobjc -lobjc-gnu)}
+
+     'remove-outfile'
+          The 'remove-outfile' spec function takes one argument.  It
+          looks for the first argument in the outfiles array and removes
+          it.  Here is a small example its usage:
+
+               %:remove-outfile(-lm)
+
+     'pass-through-libs'
+          The 'pass-through-libs' spec function takes any number of
+          arguments.  It finds any '-l' options and any non-options
+          ending in '.a' (which it assumes are the names of linker input
+          library archive files) and returns a result containing all the
+          found arguments each prepended by '-plugin-opt=-pass-through='
+          and joined by spaces.  This list is intended to be passed to
+          the LTO linker plugin.
+
+               %:pass-through-libs(%G %L %G)
+
+     'print-asm-header'
+          The 'print-asm-header' function takes no arguments and simply
+          prints a banner like:
+
+               Assembler options
+               =================
+
+               Use "-Wa,OPTION" to pass "OPTION" to the assembler.
+
+          It is used to separate compiler options from assembler options
+          in the '--target-help' output.
+
+'%{S}'
+     Substitutes the '-S' switch, if that switch is given to GCC.  If
+     that switch is not specified, this substitutes nothing.  Note that
+     the leading dash is omitted when specifying this option, and it is
+     automatically inserted if the substitution is performed.  Thus the
+     spec string '%{foo}' matches the command-line option '-foo' and
+     outputs the command-line option '-foo'.
+
+'%W{S}'
+     Like %{'S'} but mark last argument supplied within as a file to be
+     deleted on failure.
+
+'%{S*}'
+     Substitutes all the switches specified to GCC whose names start
+     with '-S', but which also take an argument.  This is used for
+     switches like '-o', '-D', '-I', etc.  GCC considers '-o foo' as
+     being one switch whose name starts with 'o'.  %{o*} substitutes
+     this text, including the space.  Thus two arguments are generated.
+
+'%{S*&T*}'
+     Like %{'S'*}, but preserve order of 'S' and 'T' options (the order
+     of 'S' and 'T' in the spec is not significant).  There can be any
+     number of ampersand-separated variables; for each the wild card is
+     optional.  Useful for CPP as '%{D*&U*&A*}'.
+
+'%{S:X}'
+     Substitutes 'X', if the '-S' switch is given to GCC.
+
+'%{!S:X}'
+     Substitutes 'X', if the '-S' switch is _not_ given to GCC.
+
+'%{S*:X}'
+     Substitutes 'X' if one or more switches whose names start with '-S'
+     are specified to GCC.  Normally 'X' is substituted only once, no
+     matter how many such switches appeared.  However, if '%*' appears
+     somewhere in 'X', then 'X' is substituted once for each matching
+     switch, with the '%*' replaced by the part of that switch matching
+     the '*'.
+
+     If '%*' appears as the last part of a spec sequence then a space
+     will be added after the end of the last substitution.  If there is
+     more text in the sequence however then a space will not be
+     generated.  This allows the '%*' substitution to be used as part of
+     a larger string.  For example, a spec string like this:
+
+          %{mcu=*:--script=%*/memory.ld}
+
+     when matching an option like '-mcu=newchip' will produce:
+
+          --script=newchip/memory.ld
+
+'%{.S:X}'
+     Substitutes 'X', if processing a file with suffix 'S'.
+
+'%{!.S:X}'
+     Substitutes 'X', if _not_ processing a file with suffix 'S'.
+
+'%{,S:X}'
+     Substitutes 'X', if processing a file for language 'S'.
+
+'%{!,S:X}'
+     Substitutes 'X', if not processing a file for language 'S'.
+
+'%{S|P:X}'
+     Substitutes 'X' if either '-S' or '-P' is given to GCC.  This may
+     be combined with '!', '.', ',', and '*' sequences as well, although
+     they have a stronger binding than the '|'.  If '%*' appears in 'X',
+     all of the alternatives must be starred, and only the first
+     matching alternative is substituted.
+
+     For example, a spec string like this:
+
+          %{.c:-foo} %{!.c:-bar} %{.c|d:-baz} %{!.c|d:-boggle}
+
+     outputs the following command-line options from the following input
+     command-line options:
+
+          fred.c        -foo -baz
+          jim.d         -bar -boggle
+          -d fred.c     -foo -baz -boggle
+          -d jim.d      -bar -baz -boggle
+
+'%{S:X; T:Y; :D}'
+
+     If 'S' is given to GCC, substitutes 'X'; else if 'T' is given to
+     GCC, substitutes 'Y'; else substitutes 'D'.  There can be as many
+     clauses as you need.  This may be combined with '.', ',', '!', '|',
+     and '*' as needed.
+
+ The conditional text 'X' in a %{'S':'X'} or similar construct may
+contain other nested '%' constructs or spaces, or even newlines.  They
+are processed as usual, as described above.  Trailing white space in 'X'
+is ignored.  White space may also appear anywhere on the left side of
+the colon in these constructs, except between '.' or '*' and the
+corresponding word.
+
+ The '-O', '-f', '-m', and '-W' switches are handled specifically in
+these constructs.  If another value of '-O' or the negated form of a
+'-f', '-m', or '-W' switch is found later in the command line, the
+earlier switch value is ignored, except with {'S'*} where 'S' is just
+one letter, which passes all matching options.
+
+ The character '|' at the beginning of the predicate text is used to
+indicate that a command should be piped to the following command, but
+only if '-pipe' is specified.
+
+ It is built into GCC which switches take arguments and which do not.
+(You might think it would be useful to generalize this to allow each
+compiler's spec to say which switches take arguments.  But this cannot
+be done in a consistent fashion.  GCC cannot even decide which input
+files have been specified without knowing which switches take arguments,
+and it must know which input files to compile in order to tell which
+compilers to run).
+
+ GCC also knows implicitly that arguments starting in '-l' are to be
+treated as compiler output files, and passed to the linker in their
+proper position among the other output files.
+
+
+File: gcc.info,  Node: Target Options,  Next: Submodel Options,  Prev: Spec Files,  Up: Invoking GCC
+
+3.16 Specifying Target Machine and Compiler Version
+===================================================
+
+The usual way to run GCC is to run the executable called 'gcc', or
+'MACHINE-gcc' when cross-compiling, or 'MACHINE-gcc-VERSION' to run a
+version other than the one that was installed last.
+
+
+File: gcc.info,  Node: Submodel Options,  Next: Code Gen Options,  Prev: Target Options,  Up: Invoking GCC
+
+3.17 Hardware Models and Configurations
+=======================================
+
+Each target machine types can have its own special options, starting
+with '-m', to choose among various hardware models or
+configurations--for example, 68010 vs 68020, floating coprocessor or
+none.  A single installed version of the compiler can compile for any
+model or configuration, according to the options specified.
+
+ Some configurations of the compiler also support additional special
+options, usually for compatibility with other compilers on the same
+platform.
+
+* Menu:
+
+* AArch64 Options::
+* Adapteva Epiphany Options::
+* ARC Options::
+* ARM Options::
+* AVR Options::
+* Blackfin Options::
+* C6X Options::
+* CRIS Options::
+* CR16 Options::
+* Darwin Options::
+* DEC Alpha Options::
+* FR30 Options::
+* FRV Options::
+* GNU/Linux Options::
+* H8/300 Options::
+* HPPA Options::
+* i386 and x86-64 Options::
+* i386 and x86-64 Windows Options::
+* IA-64 Options::
+* LM32 Options::
+* M32C Options::
+* M32R/D Options::
+* M680x0 Options::
+* MCore Options::
+* MeP Options::
+* MicroBlaze Options::
+* MIPS Options::
+* MMIX Options::
+* MN10300 Options::
+* Moxie Options::
+* MSP430 Options::
+* NDS32 Options::
+* Nios II Options::
+* PDP-11 Options::
+* picoChip Options::
+* PowerPC Options::
+* RL78 Options::
+* RS/6000 and PowerPC Options::
+* RX Options::
+* S/390 and zSeries Options::
+* Score Options::
+* SH Options::
+* Solaris 2 Options::
+* SPARC Options::
+* SPU Options::
+* System V Options::
+* TILE-Gx Options::
+* TILEPro Options::
+* V850 Options::
+* VAX Options::
+* VMS Options::
+* VxWorks Options::
+* x86-64 Options::
+* Xstormy16 Options::
+* Xtensa Options::
+* zSeries Options::
+
+
+File: gcc.info,  Node: AArch64 Options,  Next: Adapteva Epiphany Options,  Up: Submodel Options
+
+3.17.1 AArch64 Options
+----------------------
+
+These options are defined for AArch64 implementations:
+
+'-mabi=NAME'
+     Generate code for the specified data model.  Permissible values are
+     'ilp32' for SysV-like data model where int, long int and pointer
+     are 32-bit, and 'lp64' for SysV-like data model where int is
+     32-bit, but long int and pointer are 64-bit.
+
+     The default depends on the specific target configuration.  Note
+     that the LP64 and ILP32 ABIs are not link-compatible; you must
+     compile your entire program with the same ABI, and link with a
+     compatible set of libraries.
+
+'-mbig-endian'
+     Generate big-endian code.  This is the default when GCC is
+     configured for an 'aarch64_be-*-*' target.
+
+'-mgeneral-regs-only'
+     Generate code which uses only the general registers.
+
+'-mlittle-endian'
+     Generate little-endian code.  This is the default when GCC is
+     configured for an 'aarch64-*-*' but not an 'aarch64_be-*-*' target.
+
+'-mcmodel=tiny'
+     Generate code for the tiny code model.  The program and its
+     statically defined symbols must be within 1GB of each other.
+     Pointers are 64 bits.  Programs can be statically or dynamically
+     linked.  This model is not fully implemented and mostly treated as
+     'small'.
+
+'-mcmodel=small'
+     Generate code for the small code model.  The program and its
+     statically defined symbols must be within 4GB of each other.
+     Pointers are 64 bits.  Programs can be statically or dynamically
+     linked.  This is the default code model.
+
+'-mcmodel=large'
+     Generate code for the large code model.  This makes no assumptions
+     about addresses and sizes of sections.  Pointers are 64 bits.
+     Programs can be statically linked only.
+
+'-mstrict-align'
+     Do not assume that unaligned memory references will be handled by
+     the system.
+
+'-momit-leaf-frame-pointer'
+'-mno-omit-leaf-frame-pointer'
+     Omit or keep the frame pointer in leaf functions.  The former
+     behaviour is the default.
+
+'-mtls-dialect=desc'
+     Use TLS descriptors as the thread-local storage mechanism for
+     dynamic accesses of TLS variables.  This is the default.
+
+'-mtls-dialect=traditional'
+     Use traditional TLS as the thread-local storage mechanism for
+     dynamic accesses of TLS variables.
+
+'-march=NAME'
+     Specify the name of the target architecture, optionally suffixed by
+     one or more feature modifiers.  This option has the form
+     '-march=ARCH{+[no]FEATURE}*', where the only permissible value for
+     ARCH is 'armv8-a'.  The permissible values for FEATURE are
+     documented in the sub-section below.
+
+     Where conflicting feature modifiers are specified, the right-most
+     feature is used.
+
+     GCC uses this name to determine what kind of instructions it can
+     emit when generating assembly code.
+
+     Where '-march' is specified without either of '-mtune' or '-mcpu'
+     also being specified, the code will be tuned to perform well across
+     a range of target processors implementing the target architecture.
+
+'-mtune=NAME'
+     Specify the name of the target processor for which GCC should tune
+     the performance of the code.  Permissible values for this option
+     are: 'generic', 'cortex-a53', 'cortex-a57'.
+
+     Additionally, this option can specify that GCC should tune the
+     performance of the code for a big.LITTLE system.  The only
+     permissible value is 'cortex-a57.cortex-a53'.
+
+     Where none of '-mtune=', '-mcpu=' or '-march=' are specified, the
+     code will be tuned to perform well across a range of target
+     processors.
+
+     This option cannot be suffixed by feature modifiers.
+
+'-mcpu=NAME'
+     Specify the name of the target processor, optionally suffixed by
+     one or more feature modifiers.  This option has the form
+     '-mcpu=CPU{+[no]FEATURE}*', where the permissible values for CPU
+     are the same as those available for '-mtune'.
+
+     The permissible values for FEATURE are documented in the
+     sub-section below.
+
+     Where conflicting feature modifiers are specified, the right-most
+     feature is used.
+
+     GCC uses this name to determine what kind of instructions it can
+     emit when generating assembly code (as if by '-march') and to
+     determine the target processor for which to tune for performance
+     (as if by '-mtune').  Where this option is used in conjunction with
+     '-march' or '-mtune', those options take precedence over the
+     appropriate part of this option.
+
+3.17.1.1 '-march' and '-mcpu' feature modifiers
+...............................................
+
+Feature modifiers used with '-march' and '-mcpu' can be one the
+following:
+
+'crc'
+     Enable CRC extension.
+'crypto'
+     Enable Crypto extension.  This implies Advanced SIMD is enabled.
+'fp'
+     Enable floating-point instructions.
+'simd'
+     Enable Advanced SIMD instructions.  This implies floating-point
+     instructions are enabled.  This is the default for all current
+     possible values for options '-march' and '-mcpu='.
+
+
+File: gcc.info,  Node: Adapteva Epiphany Options,  Next: ARC Options,  Prev: AArch64 Options,  Up: Submodel Options
+
+3.17.2 Adapteva Epiphany Options
+--------------------------------
+
+These '-m' options are defined for Adapteva Epiphany:
+
+'-mhalf-reg-file'
+     Don't allocate any register in the range 'r32'...'r63'.  That
+     allows code to run on hardware variants that lack these registers.
+
+'-mprefer-short-insn-regs'
+     Preferrentially allocate registers that allow short instruction
+     generation.  This can result in increased instruction count, so
+     this may either reduce or increase overall code size.
+
+'-mbranch-cost=NUM'
+     Set the cost of branches to roughly NUM "simple" instructions.
+     This cost is only a heuristic and is not guaranteed to produce
+     consistent results across releases.
+
+'-mcmove'
+     Enable the generation of conditional moves.
+
+'-mnops=NUM'
+     Emit NUM NOPs before every other generated instruction.
+
+'-mno-soft-cmpsf'
+     For single-precision floating-point comparisons, emit an 'fsub'
+     instruction and test the flags.  This is faster than a software
+     comparison, but can get incorrect results in the presence of NaNs,
+     or when two different small numbers are compared such that their
+     difference is calculated as zero.  The default is '-msoft-cmpsf',
+     which uses slower, but IEEE-compliant, software comparisons.
+
+'-mstack-offset=NUM'
+     Set the offset between the top of the stack and the stack pointer.
+     E.g., a value of 8 means that the eight bytes in the range
+     'sp+0...sp+7' can be used by leaf functions without stack
+     allocation.  Values other than '8' or '16' are untested and
+     unlikely to work.  Note also that this option changes the ABI;
+     compiling a program with a different stack offset than the
+     libraries have been compiled with generally does not work.  This
+     option can be useful if you want to evaluate if a different stack
+     offset would give you better code, but to actually use a different
+     stack offset to build working programs, it is recommended to
+     configure the toolchain with the appropriate
+     '--with-stack-offset=NUM' option.
+
+'-mno-round-nearest'
+     Make the scheduler assume that the rounding mode has been set to
+     truncating.  The default is '-mround-nearest'.
+
+'-mlong-calls'
+     If not otherwise specified by an attribute, assume all calls might
+     be beyond the offset range of the 'b' / 'bl' instructions, and
+     therefore load the function address into a register before
+     performing a (otherwise direct) call.  This is the default.
+
+'-mshort-calls'
+     If not otherwise specified by an attribute, assume all direct calls
+     are in the range of the 'b' / 'bl' instructions, so use these
+     instructions for direct calls.  The default is '-mlong-calls'.
+
+'-msmall16'
+     Assume addresses can be loaded as 16-bit unsigned values.  This
+     does not apply to function addresses for which '-mlong-calls'
+     semantics are in effect.
+
+'-mfp-mode=MODE'
+     Set the prevailing mode of the floating-point unit.  This
+     determines the floating-point mode that is provided and expected at
+     function call and return time.  Making this mode match the mode you
+     predominantly need at function start can make your programs smaller
+     and faster by avoiding unnecessary mode switches.
+
+     MODE can be set to one the following values:
+
+     'caller'
+          Any mode at function entry is valid, and retained or restored
+          when the function returns, and when it calls other functions.
+          This mode is useful for compiling libraries or other
+          compilation units you might want to incorporate into different
+          programs with different prevailing FPU modes, and the
+          convenience of being able to use a single object file
+          outweighs the size and speed overhead for any extra mode
+          switching that might be needed, compared with what would be
+          needed with a more specific choice of prevailing FPU mode.
+
+     'truncate'
+          This is the mode used for floating-point calculations with
+          truncating (i.e. round towards zero) rounding mode.  That
+          includes conversion from floating point to integer.
+
+     'round-nearest'
+          This is the mode used for floating-point calculations with
+          round-to-nearest-or-even rounding mode.
+
+     'int'
+          This is the mode used to perform integer calculations in the
+          FPU, e.g. integer multiply, or integer
+          multiply-and-accumulate.
+
+     The default is '-mfp-mode=caller'
+
+'-mnosplit-lohi'
+'-mno-postinc'
+'-mno-postmodify'
+     Code generation tweaks that disable, respectively, splitting of
+     32-bit loads, generation of post-increment addresses, and
+     generation of post-modify addresses.  The defaults are
+     'msplit-lohi', '-mpost-inc', and '-mpost-modify'.
+
+'-mnovect-double'
+     Change the preferred SIMD mode to SImode.  The default is
+     '-mvect-double', which uses DImode as preferred SIMD mode.
+
+'-max-vect-align=NUM'
+     The maximum alignment for SIMD vector mode types.  NUM may be 4 or
+     8.  The default is 8.  Note that this is an ABI change, even though
+     many library function interfaces are unaffected if they don't use
+     SIMD vector modes in places that affect size and/or alignment of
+     relevant types.
+
+'-msplit-vecmove-early'
+     Split vector moves into single word moves before reload.  In theory
+     this can give better register allocation, but so far the reverse
+     seems to be generally the case.
+
+'-m1reg-REG'
+     Specify a register to hold the constant -1, which makes loading
+     small negative constants and certain bitmasks faster.  Allowable
+     values for REG are 'r43' and 'r63', which specify use of that
+     register as a fixed register, and 'none', which means that no
+     register is used for this purpose.  The default is '-m1reg-none'.
+
+
+File: gcc.info,  Node: ARC Options,  Next: ARM Options,  Prev: Adapteva Epiphany Options,  Up: Submodel Options
+
+3.17.3 ARC Options
+------------------
+
+The following options control the architecture variant for which code is
+being compiled:
+
+'-mbarrel-shifter'
+     Generate instructions supported by barrel shifter.  This is the
+     default unless '-mcpu=ARC601' is in effect.
+
+'-mcpu=CPU'
+     Set architecture type, register usage, and instruction scheduling
+     parameters for CPU.  There are also shortcut alias options
+     available for backward compatibility and convenience.  Supported
+     values for CPU are
+
+     'ARC600'
+          Compile for ARC600.  Aliases: '-mA6', '-mARC600'.
+
+     'ARC601'
+          Compile for ARC601.  Alias: '-mARC601'.
+
+     'ARC700'
+          Compile for ARC700.  Aliases: '-mA7', '-mARC700'.  This is the
+          default when configured with '--with-cpu=arc700'.
+
+'-mdpfp'
+'-mdpfp-compact'
+     FPX: Generate Double Precision FPX instructions, tuned for the
+     compact implementation.
+
+'-mdpfp-fast'
+     FPX: Generate Double Precision FPX instructions, tuned for the fast
+     implementation.
+
+'-mno-dpfp-lrsr'
+     Disable LR and SR instructions from using FPX extension aux
+     registers.
+
+'-mea'
+     Generate Extended arithmetic instructions.  Currently only 'divaw',
+     'adds', 'subs', and 'sat16' are supported.  This is always enabled
+     for '-mcpu=ARC700'.
+
+'-mno-mpy'
+     Do not generate mpy instructions for ARC700.
+
+'-mmul32x16'
+     Generate 32x16 bit multiply and mac instructions.
+
+'-mmul64'
+     Generate mul64 and mulu64 instructions.  Only valid for
+     '-mcpu=ARC600'.
+
+'-mnorm'
+     Generate norm instruction.  This is the default if '-mcpu=ARC700'
+     is in effect.
+
+'-mspfp'
+'-mspfp-compact'
+     FPX: Generate Single Precision FPX instructions, tuned for the
+     compact implementation.
+
+'-mspfp-fast'
+     FPX: Generate Single Precision FPX instructions, tuned for the fast
+     implementation.
+
+'-msimd'
+     Enable generation of ARC SIMD instructions via target-specific
+     builtins.  Only valid for '-mcpu=ARC700'.
+
+'-msoft-float'
+     This option ignored; it is provided for compatibility purposes
+     only.  Software floating point code is emitted by default, and this
+     default can overridden by FPX options; 'mspfp', 'mspfp-compact', or
+     'mspfp-fast' for single precision, and 'mdpfp', 'mdpfp-compact', or
+     'mdpfp-fast' for double precision.
+
+'-mswap'
+     Generate swap instructions.
+
+ The following options are passed through to the assembler, and also
+define preprocessor macro symbols.
+
+'-mdsp-packa'
+     Passed down to the assembler to enable the DSP Pack A extensions.
+     Also sets the preprocessor symbol '__Xdsp_packa'.
+
+'-mdvbf'
+     Passed down to the assembler to enable the dual viterbi butterfly
+     extension.  Also sets the preprocessor symbol '__Xdvbf'.
+
+'-mlock'
+     Passed down to the assembler to enable the Locked Load/Store
+     Conditional extension.  Also sets the preprocessor symbol
+     '__Xlock'.
+
+'-mmac-d16'
+     Passed down to the assembler.  Also sets the preprocessor symbol
+     '__Xxmac_d16'.
+
+'-mmac-24'
+     Passed down to the assembler.  Also sets the preprocessor symbol
+     '__Xxmac_24'.
+
+'-mrtsc'
+     Passed down to the assembler to enable the 64-bit Time-Stamp
+     Counter extension instruction.  Also sets the preprocessor symbol
+     '__Xrtsc'.
+
+'-mswape'
+     Passed down to the assembler to enable the swap byte ordering
+     extension instruction.  Also sets the preprocessor symbol
+     '__Xswape'.
+
+'-mtelephony'
+     Passed down to the assembler to enable dual and single operand
+     instructions for telephony.  Also sets the preprocessor symbol
+     '__Xtelephony'.
+
+'-mxy'
+     Passed down to the assembler to enable the XY Memory extension.
+     Also sets the preprocessor symbol '__Xxy'.
+
+ The following options control how the assembly code is annotated:
+
+'-misize'
+     Annotate assembler instructions with estimated addresses.
+
+'-mannotate-align'
+     Explain what alignment considerations lead to the decision to make
+     an instruction short or long.
+
+ The following options are passed through to the linker:
+
+'-marclinux'
+     Passed through to the linker, to specify use of the 'arclinux'
+     emulation.  This option is enabled by default in tool chains built
+     for 'arc-linux-uclibc' and 'arceb-linux-uclibc' targets when
+     profiling is not requested.
+
+'-marclinux_prof'
+     Passed through to the linker, to specify use of the 'arclinux_prof'
+     emulation.  This option is enabled by default in tool chains built
+     for 'arc-linux-uclibc' and 'arceb-linux-uclibc' targets when
+     profiling is requested.
+
+ The following options control the semantics of generated code:
+
+'-mepilogue-cfi'
+     Enable generation of call frame information for epilogues.
+
+'-mno-epilogue-cfi'
+     Disable generation of call frame information for epilogues.
+
+'-mlong-calls'
+     Generate call insns as register indirect calls, thus providing
+     access to the full 32-bit address range.
+
+'-mmedium-calls'
+     Don't use less than 25 bit addressing range for calls, which is the
+     offset available for an unconditional branch-and-link instruction.
+     Conditional execution of function calls is suppressed, to allow use
+     of the 25-bit range, rather than the 21-bit range with conditional
+     branch-and-link.  This is the default for tool chains built for 'arc-linux-uclibc'
+     and 'arceb-linux-uclibc' targets.
+
+'-mno-sdata'
+     Do not generate sdata references.  This is the default for tool
+     chains built for 'arc-linux-uclibc' and 'arceb-linux-uclibc'
+     targets.
+
+'-mucb-mcount'
+     Instrument with mcount calls as used in UCB code.  I.e.  do the
+     counting in the callee, not the caller.  By default ARC
+     instrumentation counts in the caller.
+
+'-mvolatile-cache'
+     Use ordinarily cached memory accesses for volatile references.
+     This is the default.
+
+'-mno-volatile-cache'
+     Enable cache bypass for volatile references.
+
+ The following options fine tune code generation:
+'-malign-call'
+     Do alignment optimizations for call instructions.
+
+'-mauto-modify-reg'
+     Enable the use of pre/post modify with register displacement.
+
+'-mbbit-peephole'
+     Enable bbit peephole2.
+
+'-mno-brcc'
+     This option disables a target-specific pass in 'arc_reorg' to
+     generate 'BRcc' instructions.  It has no effect on 'BRcc'
+     generation driven by the combiner pass.
+
+'-mcase-vector-pcrel'
+     Use pc-relative switch case tables - this enables case table
+     shortening.  This is the default for '-Os'.
+
+'-mcompact-casesi'
+     Enable compact casesi pattern.  This is the default for '-Os'.
+
+'-mno-cond-exec'
+     Disable ARCompact specific pass to generate conditional execution
+     instructions.  Due to delay slot scheduling and interactions
+     between operand numbers, literal sizes, instruction lengths, and
+     the support for conditional execution, the target-independent pass
+     to generate conditional execution is often lacking, so the ARC port
+     has kept a special pass around that tries to find more conditional
+     execution generating opportunities after register allocation,
+     branch shortening, and delay slot scheduling have been done.  This
+     pass generally, but not always, improves performance and code size,
+     at the cost of extra compilation time, which is why there is an
+     option to switch it off.  If you have a problem with call
+     instructions exceeding their allowable offset range because they
+     are conditionalized, you should consider using '-mmedium-calls'
+     instead.
+
+'-mearly-cbranchsi'
+     Enable pre-reload use of the cbranchsi pattern.
+
+'-mexpand-adddi'
+     Expand 'adddi3' and 'subdi3' at rtl generation time into 'add.f',
+     'adc' etc.
+
+'-mindexed-loads'
+     Enable the use of indexed loads.  This can be problematic because
+     some optimizers will then assume the that indexed stores exist,
+     which is not the case.
+
+'-mlra'
+     Enable Local Register Allocation.  This is still experimental for
+     ARC, so by default the compiler uses standard reload (i.e.
+     '-mno-lra').
+
+'-mlra-priority-none'
+     Don't indicate any priority for target registers.
+
+'-mlra-priority-compact'
+     Indicate target register priority for r0..r3 / r12..r15.
+
+'-mlra-priority-noncompact'
+     Reduce target regsiter priority for r0..r3 / r12..r15.
+
+'-mno-millicode'
+     When optimizing for size (using '-Os'), prologues and epilogues
+     that have to save or restore a large number of registers are often
+     shortened by using call to a special function in libgcc; this is
+     referred to as a _millicode_ call.  As these calls can pose
+     performance issues, and/or cause linking issues when linking in a
+     nonstandard way, this option is provided to turn off millicode call
+     generation.
+
+'-mmixed-code'
+     Tweak register allocation to help 16-bit instruction generation.
+     This generally has the effect of decreasing the average instruction
+     size while increasing the instruction count.
+
+'-mq-class'
+     Enable 'q' instruction alternatives.  This is the default for
+     '-Os'.
+
+'-mRcq'
+     Enable Rcq constraint handling - most short code generation depends
+     on this.  This is the default.
+
+'-mRcw'
+     Enable Rcw constraint handling - ccfsm condexec mostly depends on
+     this.  This is the default.
+
+'-msize-level=LEVEL'
+     Fine-tune size optimization with regards to instruction lengths and
+     alignment.  The recognized values for LEVEL are:
+     '0'
+          No size optimization.  This level is deprecated and treated
+          like '1'.
+
+     '1'
+          Short instructions are used opportunistically.
+
+     '2'
+          In addition, alignment of loops and of code after barriers are
+          dropped.
+
+     '3'
+          In addition, optional data alignment is dropped, and the
+          option 'Os' is enabled.
+
+     This defaults to '3' when '-Os' is in effect.  Otherwise, the
+     behavior when this is not set is equivalent to level '1'.
+
+'-mtune=CPU'
+     Set instruction scheduling parameters for CPU, overriding any
+     implied by '-mcpu='.
+
+     Supported values for CPU are
+
+     'ARC600'
+          Tune for ARC600 cpu.
+
+     'ARC601'
+          Tune for ARC601 cpu.
+
+     'ARC700'
+          Tune for ARC700 cpu with standard multiplier block.
+
+     'ARC700-xmac'
+          Tune for ARC700 cpu with XMAC block.
+
+     'ARC725D'
+          Tune for ARC725D cpu.
+
+     'ARC750D'
+          Tune for ARC750D cpu.
+
+'-mmultcost=NUM'
+     Cost to assume for a multiply instruction, with '4' being equal to
+     a normal instruction.
+
+'-munalign-prob-threshold=PROBABILITY'
+     Set probability threshold for unaligning branches.  When tuning for
+     'ARC700' and optimizing for speed, branches without filled delay
+     slot are preferably emitted unaligned and long, unless profiling
+     indicates that the probability for the branch to be taken is below
+     PROBABILITY.  *Note Cross-profiling::.  The default is
+     (REG_BR_PROB_BASE/2), i.e. 5000.
+
+ The following options are maintained for backward compatibility, but
+are now deprecated and will be removed in a future release:
+
+'-margonaut'
+     Obsolete FPX.
+
+'-mbig-endian'
+'-EB'
+     Compile code for big endian targets.  Use of these options is now
+     deprecated.  Users wanting big-endian code, should use the 'arceb-elf32'
+     and 'arceb-linux-uclibc' targets when building the tool chain, for
+     which big-endian is the default.
+
+'-mlittle-endian'
+'-EL'
+     Compile code for little endian targets.  Use of these options is
+     now deprecated.  Users wanting little-endian code should use the 'arc-elf32'
+     and 'arc-linux-uclibc' targets when building the tool chain, for
+     which little-endian is the default.
+
+'-mbarrel_shifter'
+     Replaced by '-mbarrel-shifter'
+
+'-mdpfp_compact'
+     Replaced by '-mdpfp-compact'
+
+'-mdpfp_fast'
+     Replaced by '-mdpfp-fast'
+
+'-mdsp_packa'
+     Replaced by '-mdsp-packa'
+
+'-mEA'
+     Replaced by '-mea'
+
+'-mmac_24'
+     Replaced by '-mmac-24'
+
+'-mmac_d16'
+     Replaced by '-mmac-d16'
+
+'-mspfp_compact'
+     Replaced by '-mspfp-compact'
+
+'-mspfp_fast'
+     Replaced by '-mspfp-fast'
+
+'-mtune=CPU'
+     Values 'arc600', 'arc601', 'arc700' and 'arc700-xmac' for CPU are
+     replaced by 'ARC600', 'ARC601', 'ARC700' and 'ARC700-xmac'
+     respectively
+
+'-multcost=NUM'
+     Replaced by '-mmultcost'.
+
+
+File: gcc.info,  Node: ARM Options,  Next: AVR Options,  Prev: ARC Options,  Up: Submodel Options
+
+3.17.4 ARM Options
+------------------
+
+These '-m' options are defined for Advanced RISC Machines (ARM)
+architectures:
+
+'-mabi=NAME'
+     Generate code for the specified ABI.  Permissible values are:
+     'apcs-gnu', 'atpcs', 'aapcs', 'aapcs-linux' and 'iwmmxt'.
+
+'-mapcs-frame'
+     Generate a stack frame that is compliant with the ARM Procedure
+     Call Standard for all functions, even if this is not strictly
+     necessary for correct execution of the code.  Specifying
+     '-fomit-frame-pointer' with this option causes the stack frames not
+     to be generated for leaf functions.  The default is
+     '-mno-apcs-frame'.
+
+'-mapcs'
+     This is a synonym for '-mapcs-frame'.
+
+'-mthumb-interwork'
+     Generate code that supports calling between the ARM and Thumb
+     instruction sets.  Without this option, on pre-v5 architectures,
+     the two instruction sets cannot be reliably used inside one
+     program.  The default is '-mno-thumb-interwork', since slightly
+     larger code is generated when '-mthumb-interwork' is specified.  In
+     AAPCS configurations this option is meaningless.
+
+'-mno-sched-prolog'
+     Prevent the reordering of instructions in the function prologue, or
+     the merging of those instruction with the instructions in the
+     function's body.  This means that all functions start with a
+     recognizable set of instructions (or in fact one of a choice from a
+     small set of different function prologues), and this information
+     can be used to locate the start of functions inside an executable
+     piece of code.  The default is '-msched-prolog'.
+
+'-mfloat-abi=NAME'
+     Specifies which floating-point ABI to use.  Permissible values are:
+     'soft', 'softfp' and 'hard'.
+
+     Specifying 'soft' causes GCC to generate output containing library
+     calls for floating-point operations.  'softfp' allows the
+     generation of code using hardware floating-point instructions, but
+     still uses the soft-float calling conventions.  'hard' allows
+     generation of floating-point instructions and uses FPU-specific
+     calling conventions.
+
+     The default depends on the specific target configuration.  Note
+     that the hard-float and soft-float ABIs are not link-compatible;
+     you must compile your entire program with the same ABI, and link
+     with a compatible set of libraries.
+
+'-mlittle-endian'
+     Generate code for a processor running in little-endian mode.  This
+     is the default for all standard configurations.
+
+'-mbig-endian'
+     Generate code for a processor running in big-endian mode; the
+     default is to compile code for a little-endian processor.
+
+'-mwords-little-endian'
+     This option only applies when generating code for big-endian
+     processors.  Generate code for a little-endian word order but a
+     big-endian byte order.  That is, a byte order of the form
+     '32107654'.  Note: this option should only be used if you require
+     compatibility with code for big-endian ARM processors generated by
+     versions of the compiler prior to 2.8.  This option is now
+     deprecated.
+
+'-march=NAME'
+     This specifies the name of the target ARM architecture.  GCC uses
+     this name to determine what kind of instructions it can emit when
+     generating assembly code.  This option can be used in conjunction
+     with or instead of the '-mcpu=' option.  Permissible names are:
+     'armv2', 'armv2a', 'armv3', 'armv3m', 'armv4', 'armv4t', 'armv5',
+     'armv5t', 'armv5e', 'armv5te', 'armv6', 'armv6j', 'armv6t2',
+     'armv6z', 'armv6zk', 'armv6-m', 'armv7', 'armv7-a', 'armv7-r',
+     'armv7-m', 'armv7e-m', 'armv7ve', 'armv8-a', 'armv8-a+crc',
+     'iwmmxt', 'iwmmxt2', 'ep9312'.
+
+     '-march=armv7ve' is the armv7-a architecture with virtualization
+     extensions.
+
+     '-march=armv8-a+crc' enables code generation for the ARMv8-A
+     architecture together with the optional CRC32 extensions.
+
+     '-march=native' causes the compiler to auto-detect the architecture
+     of the build computer.  At present, this feature is only supported
+     on Linux, and not all architectures are recognized.  If the
+     auto-detect is unsuccessful the option has no effect.
+
+'-mtune=NAME'
+     This option specifies the name of the target ARM processor for
+     which GCC should tune the performance of the code.  For some ARM
+     implementations better performance can be obtained by using this
+     option.  Permissible names are: 'arm2', 'arm250', 'arm3', 'arm6',
+     'arm60', 'arm600', 'arm610', 'arm620', 'arm7', 'arm7m', 'arm7d',
+     'arm7dm', 'arm7di', 'arm7dmi', 'arm70', 'arm700', 'arm700i',
+     'arm710', 'arm710c', 'arm7100', 'arm720', 'arm7500', 'arm7500fe',
+     'arm7tdmi', 'arm7tdmi-s', 'arm710t', 'arm720t', 'arm740t',
+     'strongarm', 'strongarm110', 'strongarm1100', 'strongarm1110',
+     'arm8', 'arm810', 'arm9', 'arm9e', 'arm920', 'arm920t', 'arm922t',
+     'arm946e-s', 'arm966e-s', 'arm968e-s', 'arm926ej-s', 'arm940t',
+     'arm9tdmi', 'arm10tdmi', 'arm1020t', 'arm1026ej-s', 'arm10e',
+     'arm1020e', 'arm1022e', 'arm1136j-s', 'arm1136jf-s', 'mpcore',
+     'mpcorenovfp', 'arm1156t2-s', 'arm1156t2f-s', 'arm1176jz-s',
+     'arm1176jzf-s', 'cortex-a5', 'cortex-a7', 'cortex-a8', 'cortex-a9',
+     'cortex-a12', 'cortex-a15', 'cortex-a53', 'cortex-a57',
+     'cortex-r4', 'cortex-r4f', 'cortex-r5', 'cortex-r7', 'cortex-m4',
+     'cortex-m3', 'cortex-m1', 'cortex-m0', 'cortex-m0plus',
+     'marvell-pj4', 'xscale', 'iwmmxt', 'iwmmxt2', 'ep9312', 'fa526',
+     'fa626', 'fa606te', 'fa626te', 'fmp626', 'fa726te'.
+
+     Additionally, this option can specify that GCC should tune the
+     performance of the code for a big.LITTLE system.  Permissible names
+     are: 'cortex-a15.cortex-a7', 'cortex-a57.cortex-a53'.
+
+     '-mtune=generic-ARCH' specifies that GCC should tune the
+     performance for a blend of processors within architecture ARCH.
+     The aim is to generate code that run well on the current most
+     popular processors, balancing between optimizations that benefit
+     some CPUs in the range, and avoiding performance pitfalls of other
+     CPUs.  The effects of this option may change in future GCC versions
+     as CPU models come and go.
+
+     '-mtune=native' causes the compiler to auto-detect the CPU of the
+     build computer.  At present, this feature is only supported on
+     Linux, and not all architectures are recognized.  If the
+     auto-detect is unsuccessful the option has no effect.
+
+'-mcpu=NAME'
+     This specifies the name of the target ARM processor.  GCC uses this
+     name to derive the name of the target ARM architecture (as if
+     specified by '-march') and the ARM processor type for which to tune
+     for performance (as if specified by '-mtune').  Where this option
+     is used in conjunction with '-march' or '-mtune', those options
+     take precedence over the appropriate part of this option.
+
+     Permissible names for this option are the same as those for
+     '-mtune'.
+
+     '-mcpu=generic-ARCH' is also permissible, and is equivalent to
+     '-march=ARCH -mtune=generic-ARCH'.  See '-mtune' for more
+     information.
+
+     '-mcpu=native' causes the compiler to auto-detect the CPU of the
+     build computer.  At present, this feature is only supported on
+     Linux, and not all architectures are recognized.  If the
+     auto-detect is unsuccessful the option has no effect.
+
+'-mfpu=NAME'
+     This specifies what floating-point hardware (or hardware emulation)
+     is available on the target.  Permissible names are: 'vfp', 'vfpv3',
+     'vfpv3-fp16', 'vfpv3-d16', 'vfpv3-d16-fp16', 'vfpv3xd',
+     'vfpv3xd-fp16', 'neon', 'neon-fp16', 'vfpv4', 'vfpv4-d16',
+     'fpv4-sp-d16', 'neon-vfpv4', 'fp-armv8', 'neon-fp-armv8', and
+     'crypto-neon-fp-armv8'.
+
+     If '-msoft-float' is specified this specifies the format of
+     floating-point values.
+
+     If the selected floating-point hardware includes the NEON extension
+     (e.g.  '-mfpu'='neon'), note that floating-point operations are not
+     generated by GCC's auto-vectorization pass unless
+     '-funsafe-math-optimizations' is also specified.  This is because
+     NEON hardware does not fully implement the IEEE 754 standard for
+     floating-point arithmetic (in particular denormal values are
+     treated as zero), so the use of NEON instructions may lead to a
+     loss of precision.
+
+'-mfp16-format=NAME'
+     Specify the format of the '__fp16' half-precision floating-point
+     type.  Permissible names are 'none', 'ieee', and 'alternative'; the
+     default is 'none', in which case the '__fp16' type is not defined.
+     *Note Half-Precision::, for more information.
+
+'-mstructure-size-boundary=N'
+     The sizes of all structures and unions are rounded up to a multiple
+     of the number of bits set by this option.  Permissible values are
+     8, 32 and 64.  The default value varies for different toolchains.
+     For the COFF targeted toolchain the default value is 8.  A value of
+     64 is only allowed if the underlying ABI supports it.
+
+     Specifying a larger number can produce faster, more efficient code,
+     but can also increase the size of the program.  Different values
+     are potentially incompatible.  Code compiled with one value cannot
+     necessarily expect to work with code or libraries compiled with
+     another value, if they exchange information using structures or
+     unions.
+
+'-mabort-on-noreturn'
+     Generate a call to the function 'abort' at the end of a 'noreturn'
+     function.  It is executed if the function tries to return.
+
+'-mlong-calls'
+'-mno-long-calls'
+     Tells the compiler to perform function calls by first loading the
+     address of the function into a register and then performing a
+     subroutine call on this register.  This switch is needed if the
+     target function lies outside of the 64-megabyte addressing range of
+     the offset-based version of subroutine call instruction.
+
+     Even if this switch is enabled, not all function calls are turned
+     into long calls.  The heuristic is that static functions, functions
+     that have the 'short-call' attribute, functions that are inside the
+     scope of a '#pragma no_long_calls' directive, and functions whose
+     definitions have already been compiled within the current
+     compilation unit are not turned into long calls.  The exceptions to
+     this rule are that weak function definitions, functions with the
+     'long-call' attribute or the 'section' attribute, and functions
+     that are within the scope of a '#pragma long_calls' directive are
+     always turned into long calls.
+
+     This feature is not enabled by default.  Specifying
+     '-mno-long-calls' restores the default behavior, as does placing
+     the function calls within the scope of a '#pragma long_calls_off'
+     directive.  Note these switches have no effect on how the compiler
+     generates code to handle function calls via function pointers.
+
+'-msingle-pic-base'
+     Treat the register used for PIC addressing as read-only, rather
+     than loading it in the prologue for each function.  The runtime
+     system is responsible for initializing this register with an
+     appropriate value before execution begins.
+
+'-mpic-register=REG'
+     Specify the register to be used for PIC addressing.  For standard
+     PIC base case, the default will be any suitable register determined
+     by compiler.  For single PIC base case, the default is 'R9' if
+     target is EABI based or stack-checking is enabled, otherwise the
+     default is 'R10'.
+
+'-mpic-data-is-text-relative'
+     Assume that each data segments are relative to text segment at load
+     time.  Therefore, it permits addressing data using PC-relative
+     operations.  This option is on by default for targets other than
+     VxWorks RTP.
+
+'-mpoke-function-name'
+     Write the name of each function into the text section, directly
+     preceding the function prologue.  The generated code is similar to
+     this:
+
+               t0
+                   .ascii "arm_poke_function_name", 0
+                   .align
+               t1
+                   .word 0xff000000 + (t1 - t0)
+               arm_poke_function_name
+                   mov     ip, sp
+                   stmfd   sp!, {fp, ip, lr, pc}
+                   sub     fp, ip, #4
+
+     When performing a stack backtrace, code can inspect the value of
+     'pc' stored at 'fp + 0'.  If the trace function then looks at
+     location 'pc - 12' and the top 8 bits are set, then we know that
+     there is a function name embedded immediately preceding this
+     location and has length '((pc[-3]) & 0xff000000)'.
+
+'-mthumb'
+'-marm'
+
+     Select between generating code that executes in ARM and Thumb
+     states.  The default for most configurations is to generate code
+     that executes in ARM state, but the default can be changed by
+     configuring GCC with the '--with-mode='STATE configure option.
+
+'-mtpcs-frame'
+     Generate a stack frame that is compliant with the Thumb Procedure
+     Call Standard for all non-leaf functions.  (A leaf function is one
+     that does not call any other functions.)  The default is
+     '-mno-tpcs-frame'.
+
+'-mtpcs-leaf-frame'
+     Generate a stack frame that is compliant with the Thumb Procedure
+     Call Standard for all leaf functions.  (A leaf function is one that
+     does not call any other functions.)  The default is
+     '-mno-apcs-leaf-frame'.
+
+'-mcallee-super-interworking'
+     Gives all externally visible functions in the file being compiled
+     an ARM instruction set header which switches to Thumb mode before
+     executing the rest of the function.  This allows these functions to
+     be called from non-interworking code.  This option is not valid in
+     AAPCS configurations because interworking is enabled by default.
+
+'-mcaller-super-interworking'
+     Allows calls via function pointers (including virtual functions) to
+     execute correctly regardless of whether the target code has been
+     compiled for interworking or not.  There is a small overhead in the
+     cost of executing a function pointer if this option is enabled.
+     This option is not valid in AAPCS configurations because
+     interworking is enabled by default.
+
+'-mtp=NAME'
+     Specify the access model for the thread local storage pointer.  The
+     valid models are 'soft', which generates calls to
+     '__aeabi_read_tp', 'cp15', which fetches the thread pointer from
+     'cp15' directly (supported in the arm6k architecture), and 'auto',
+     which uses the best available method for the selected processor.
+     The default setting is 'auto'.
+
+'-mtls-dialect=DIALECT'
+     Specify the dialect to use for accessing thread local storage.  Two
+     DIALECTs are supported--'gnu' and 'gnu2'.  The 'gnu' dialect
+     selects the original GNU scheme for supporting local and global
+     dynamic TLS models.  The 'gnu2' dialect selects the GNU descriptor
+     scheme, which provides better performance for shared libraries.
+     The GNU descriptor scheme is compatible with the original scheme,
+     but does require new assembler, linker and library support.
+     Initial and local exec TLS models are unaffected by this option and
+     always use the original scheme.
+
+'-mword-relocations'
+     Only generate absolute relocations on word-sized values (i.e.
+     R_ARM_ABS32).  This is enabled by default on targets (uClinux,
+     SymbianOS) where the runtime loader imposes this restriction, and
+     when '-fpic' or '-fPIC' is specified.
+
+'-mfix-cortex-m3-ldrd'
+     Some Cortex-M3 cores can cause data corruption when 'ldrd'
+     instructions with overlapping destination and base registers are
+     used.  This option avoids generating these instructions.  This
+     option is enabled by default when '-mcpu=cortex-m3' is specified.
+
+'-munaligned-access'
+'-mno-unaligned-access'
+     Enables (or disables) reading and writing of 16- and 32- bit values
+     from addresses that are not 16- or 32- bit aligned.  By default
+     unaligned access is disabled for all pre-ARMv6 and all ARMv6-M
+     architectures, and enabled for all other architectures.  If
+     unaligned access is not enabled then words in packed data
+     structures will be accessed a byte at a time.
+
+     The ARM attribute 'Tag_CPU_unaligned_access' will be set in the
+     generated object file to either true or false, depending upon the
+     setting of this option.  If unaligned access is enabled then the
+     preprocessor symbol '__ARM_FEATURE_UNALIGNED' will also be defined.
+
+'-mneon-for-64bits'
+     Enables using Neon to handle scalar 64-bits operations.  This is
+     disabled by default since the cost of moving data from core
+     registers to Neon is high.
+
+'-mslow-flash-data'
+     Assume loading data from flash is slower than fetching instruction.
+     Therefore literal load is minimized for better performance.  This
+     option is only supported when compiling for ARMv7 M-profile and off
+     by default.
+
+'-mrestrict-it'
+     Restricts generation of IT blocks to conform to the rules of ARMv8.
+     IT blocks can only contain a single 16-bit instruction from a
+     select set of instructions.  This option is on by default for ARMv8
+     Thumb mode.
+
+
+File: gcc.info,  Node: AVR Options,  Next: Blackfin Options,  Prev: ARM Options,  Up: Submodel Options
+
+3.17.5 AVR Options
+------------------
+
+These options are defined for AVR implementations:
+
+'-mmcu=MCU'
+     Specify Atmel AVR instruction set architectures (ISA) or MCU type.
+
+     The default for this option is 'avr2'.
+
+     GCC supports the following AVR devices and ISAs:
+
+     'avr2'
+          "Classic" devices with up to 8 KiB of program memory.
+          MCU = 'attiny22', 'attiny26', 'at90c8534', 'at90s2313',
+          'at90s2323', 'at90s2333', 'at90s2343', 'at90s4414',
+          'at90s4433', 'at90s4434', 'at90s8515', 'at90s8535'.
+
+     'avr25'
+          "Classic" devices with up to 8 KiB of program memory and with
+          the 'MOVW' instruction.
+          MCU = 'ata5272', 'ata6289', 'attiny13', 'attiny13a',
+          'attiny2313', 'attiny2313a', 'attiny24', 'attiny24a',
+          'attiny25', 'attiny261', 'attiny261a', 'attiny43u',
+          'attiny4313', 'attiny44', 'attiny44a', 'attiny45',
+          'attiny461', 'attiny461a', 'attiny48', 'attiny84',
+          'attiny84a', 'attiny85', 'attiny861', 'attiny861a',
+          'attiny87', 'attiny88', 'at86rf401'.
+
+     'avr3'
+          "Classic" devices with 16 KiB up to 64 KiB of program memory.
+          MCU = 'at43usb355', 'at76c711'.
+
+     'avr31'
+          "Classic" devices with 128 KiB of program memory.
+          MCU = 'atmega103', 'at43usb320'.
+
+     'avr35'
+          "Classic" devices with 16 KiB up to 64 KiB of program memory
+          and with the 'MOVW' instruction.
+          MCU = 'ata5505', 'atmega16u2', 'atmega32u2', 'atmega8u2',
+          'attiny1634', 'attiny167', 'at90usb162', 'at90usb82'.
+
+     'avr4'
+          "Enhanced" devices with up to 8 KiB of program memory.
+          MCU = 'ata6285', 'ata6286', 'atmega48', 'atmega48a',
+          'atmega48p', 'atmega48pa', 'atmega8', 'atmega8a',
+          'atmega8hva', 'atmega8515', 'atmega8535', 'atmega88',
+          'atmega88a', 'atmega88p', 'atmega88pa', 'at90pwm1',
+          'at90pwm2', 'at90pwm2b', 'at90pwm3', 'at90pwm3b', 'at90pwm81'.
+
+     'avr5'
+          "Enhanced" devices with 16 KiB up to 64 KiB of program memory.
+
+          MCU = 'ata5790', 'ata5790n', 'ata5795', 'atmega16',
+          'atmega16a', 'atmega16hva', 'atmega16hva2', 'atmega16hvb',
+          'atmega16hvbrevb', 'atmega16m1', 'atmega16u4', 'atmega161',
+          'atmega162', 'atmega163', 'atmega164a', 'atmega164p',
+          'atmega164pa', 'atmega165', 'atmega165a', 'atmega165p',
+          'atmega165pa', 'atmega168', 'atmega168a', 'atmega168p',
+          'atmega168pa', 'atmega169', 'atmega169a', 'atmega169p',
+          'atmega169pa', 'atmega26hvg', 'atmega32', 'atmega32a',
+          'atmega32c1', 'atmega32hvb', 'atmega32hvbrevb', 'atmega32m1',
+          'atmega32u4', 'atmega32u6', 'atmega323', 'atmega324a',
+          'atmega324p', 'atmega324pa', 'atmega325', 'atmega325a',
+          'atmega325p', 'atmega3250', 'atmega3250a', 'atmega3250p',
+          'atmega3250pa', 'atmega328', 'atmega328p', 'atmega329',
+          'atmega329a', 'atmega329p', 'atmega329pa', 'atmega3290',
+          'atmega3290a', 'atmega3290p', 'atmega3290pa', 'atmega406',
+          'atmega48hvf', 'atmega64', 'atmega64a', 'atmega64c1',
+          'atmega64hve', 'atmega64m1', 'atmega64rfa2', 'atmega64rfr2',
+          'atmega640', 'atmega644', 'atmega644a', 'atmega644p',
+          'atmega644pa', 'atmega645', 'atmega645a', 'atmega645p',
+          'atmega6450', 'atmega6450a', 'atmega6450p', 'atmega649',
+          'atmega649a', 'atmega649p', 'atmega6490', 'atmega6490a',
+          'atmega6490p', 'at90can32', 'at90can64', 'at90pwm161',
+          'at90pwm216', 'at90pwm316', 'at90scr100', 'at90usb646',
+          'at90usb647', 'at94k', 'm3000'.
+
+     'avr51'
+          "Enhanced" devices with 128 KiB of program memory.
+          MCU = 'atmega128', 'atmega128a', 'atmega128rfa1',
+          'atmega1280', 'atmega1281', 'atmega1284', 'atmega1284p',
+          'at90can128', 'at90usb1286', 'at90usb1287'.
+
+     'avr6'
+          "Enhanced" devices with 3-byte PC, i.e. with more than 128 KiB
+          of program memory.
+          MCU = 'atmega2560', 'atmega2561'.
+
+     'avrxmega2'
+          "XMEGA" devices with more than 8 KiB and up to 64 KiB of
+          program memory.
+          MCU = 'atmxt112sl', 'atmxt224', 'atmxt224e', 'atmxt336s',
+          'atxmega16a4', 'atxmega16a4u', 'atxmega16c4', 'atxmega16d4',
+          'atxmega32a4', 'atxmega32a4u', 'atxmega32c4', 'atxmega32d4',
+          'atxmega32e5', 'atxmega32x1'.
+
+     'avrxmega4'
+          "XMEGA" devices with more than 64 KiB and up to 128 KiB of
+          program memory.
+          MCU = 'atxmega64a3', 'atxmega64a3u', 'atxmega64a4u',
+          'atxmega64b1', 'atxmega64b3', 'atxmega64c3', 'atxmega64d3',
+          'atxmega64d4'.
+
+     'avrxmega5'
+          "XMEGA" devices with more than 64 KiB and up to 128 KiB of
+          program memory and more than 64 KiB of RAM.
+          MCU = 'atxmega64a1', 'atxmega64a1u'.
+
+     'avrxmega6'
+          "XMEGA" devices with more than 128 KiB of program memory.
+          MCU = 'atmxt540s', 'atmxt540sreva', 'atxmega128a3',
+          'atxmega128a3u', 'atxmega128b1', 'atxmega128b3',
+          'atxmega128c3', 'atxmega128d3', 'atxmega128d4',
+          'atxmega192a3', 'atxmega192a3u', 'atxmega192c3',
+          'atxmega192d3', 'atxmega256a3', 'atxmega256a3b',
+          'atxmega256a3bu', 'atxmega256a3u', 'atxmega256c3',
+          'atxmega256d3', 'atxmega384c3', 'atxmega384d3'.
+
+     'avrxmega7'
+          "XMEGA" devices with more than 128 KiB of program memory and
+          more than 64 KiB of RAM.
+          MCU = 'atxmega128a1', 'atxmega128a1u', 'atxmega128a4u'.
+
+     'avr1'
+          This ISA is implemented by the minimal AVR core and supported
+          for assembler only.
+          MCU = 'attiny11', 'attiny12', 'attiny15', 'attiny28',
+          'at90s1200'.
+
+'-maccumulate-args'
+     Accumulate outgoing function arguments and acquire/release the
+     needed stack space for outgoing function arguments once in function
+     prologue/epilogue.  Without this option, outgoing arguments are
+     pushed before calling a function and popped afterwards.
+
+     Popping the arguments after the function call can be expensive on
+     AVR so that accumulating the stack space might lead to smaller
+     executables because arguments need not to be removed from the stack
+     after such a function call.
+
+     This option can lead to reduced code size for functions that
+     perform several calls to functions that get their arguments on the
+     stack like calls to printf-like functions.
+
+'-mbranch-cost=COST'
+     Set the branch costs for conditional branch instructions to COST.
+     Reasonable values for COST are small, non-negative integers.  The
+     default branch cost is 0.
+
+'-mcall-prologues'
+     Functions prologues/epilogues are expanded as calls to appropriate
+     subroutines.  Code size is smaller.
+
+'-mint8'
+     Assume 'int' to be 8-bit integer.  This affects the sizes of all
+     types: a 'char' is 1 byte, an 'int' is 1 byte, a 'long' is 2 bytes,
+     and 'long long' is 4 bytes.  Please note that this option does not
+     conform to the C standards, but it results in smaller code size.
+
+'-mno-interrupts'
+     Generated code is not compatible with hardware interrupts.  Code
+     size is smaller.
+
+'-mrelax'
+     Try to replace 'CALL' resp. 'JMP' instruction by the shorter
+     'RCALL' resp. 'RJMP' instruction if applicable.  Setting '-mrelax'
+     just adds the '--relax' option to the linker command line when the
+     linker is called.
+
+     Jump relaxing is performed by the linker because jump offsets are
+     not known before code is located.  Therefore, the assembler code
+     generated by the compiler is the same, but the instructions in the
+     executable may differ from instructions in the assembler code.
+
+     Relaxing must be turned on if linker stubs are needed, see the
+     section on 'EIND' and linker stubs below.
+
+'-msp8'
+     Treat the stack pointer register as an 8-bit register, i.e. assume
+     the high byte of the stack pointer is zero.  In general, you don't
+     need to set this option by hand.
+
+     This option is used internally by the compiler to select and build
+     multilibs for architectures 'avr2' and 'avr25'.  These
+     architectures mix devices with and without 'SPH'.  For any setting
+     other than '-mmcu=avr2' or '-mmcu=avr25' the compiler driver will
+     add or remove this option from the compiler proper's command line,
+     because the compiler then knows if the device or architecture has
+     an 8-bit stack pointer and thus no 'SPH' register or not.
+
+'-mstrict-X'
+     Use address register 'X' in a way proposed by the hardware.  This
+     means that 'X' is only used in indirect, post-increment or
+     pre-decrement addressing.
+
+     Without this option, the 'X' register may be used in the same way
+     as 'Y' or 'Z' which then is emulated by additional instructions.
+     For example, loading a value with 'X+const' addressing with a small
+     non-negative 'const < 64' to a register RN is performed as
+
+          adiw r26, const   ; X += const
+          ld   RN, X        ; RN = *X
+          sbiw r26, const   ; X -= const
+
+'-mtiny-stack'
+     Only change the lower 8 bits of the stack pointer.
+
+'-Waddr-space-convert'
+     Warn about conversions between address spaces in the case where the
+     resulting address space is not contained in the incoming address
+     space.
+
+3.17.5.1 'EIND' and Devices with more than 128 Ki Bytes of Flash
+................................................................
+
+Pointers in the implementation are 16 bits wide.  The address of a
+function or label is represented as word address so that indirect jumps
+and calls can target any code address in the range of 64 Ki words.
+
+ In order to facilitate indirect jump on devices with more than 128 Ki
+bytes of program memory space, there is a special function register
+called 'EIND' that serves as most significant part of the target address
+when 'EICALL' or 'EIJMP' instructions are used.
+
+ Indirect jumps and calls on these devices are handled as follows by the
+compiler and are subject to some limitations:
+
+   * The compiler never sets 'EIND'.
+
+   * The compiler uses 'EIND' implicitely in 'EICALL'/'EIJMP'
+     instructions or might read 'EIND' directly in order to emulate an
+     indirect call/jump by means of a 'RET' instruction.
+
+   * The compiler assumes that 'EIND' never changes during the startup
+     code or during the application.  In particular, 'EIND' is not
+     saved/restored in function or interrupt service routine
+     prologue/epilogue.
+
+   * For indirect calls to functions and computed goto, the linker
+     generates _stubs_.  Stubs are jump pads sometimes also called
+     _trampolines_.  Thus, the indirect call/jump jumps to such a stub.
+     The stub contains a direct jump to the desired address.
+
+   * Linker relaxation must be turned on so that the linker will
+     generate the stubs correctly an all situaltion.  See the compiler
+     option '-mrelax' and the linler option '--relax'.  There are corner
+     cases where the linker is supposed to generate stubs but aborts
+     without relaxation and without a helpful error message.
+
+   * The default linker script is arranged for code with 'EIND = 0'.  If
+     code is supposed to work for a setup with 'EIND != 0', a custom
+     linker script has to be used in order to place the sections whose
+     name start with '.trampolines' into the segment where 'EIND' points
+     to.
+
+   * The startup code from libgcc never sets 'EIND'.  Notice that
+     startup code is a blend of code from libgcc and AVR-LibC. For the
+     impact of AVR-LibC on 'EIND', see the
+     AVR-LibC user manual (http://nongnu.org/avr-libc/user-manual/).
+
+   * It is legitimate for user-specific startup code to set up 'EIND'
+     early, for example by means of initialization code located in
+     section '.init3'.  Such code runs prior to general startup code
+     that initializes RAM and calls constructors, but after the bit of
+     startup code from AVR-LibC that sets 'EIND' to the segment where
+     the vector table is located.
+          #include <avr/io.h>
+
+          static void
+          __attribute__((section(".init3"),naked,used,no_instrument_function))
+          init3_set_eind (void)
+          {
+            __asm volatile ("ldi r24,pm_hh8(__trampolines_start)\n\t"
+                            "out %i0,r24" :: "n" (&EIND) : "r24","memory");
+          }
+
+     The '__trampolines_start' symbol is defined in the linker script.
+
+   * Stubs are generated automatically by the linker if the following
+     two conditions are met:
+
+        - The address of a label is taken by means of the 'gs' modifier
+          (short for _generate stubs_) like so:
+               LDI r24, lo8(gs(FUNC))
+               LDI r25, hi8(gs(FUNC))
+        - The final location of that label is in a code segment
+          _outside_ the segment where the stubs are located.
+
+   * The compiler emits such 'gs' modifiers for code labels in the
+     following situations:
+        - Taking address of a function or code label.
+        - Computed goto.
+        - If prologue-save function is used, see '-mcall-prologues'
+          command-line option.
+        - Switch/case dispatch tables.  If you do not want such dispatch
+          tables you can specify the '-fno-jump-tables' command-line
+          option.
+        - C and C++ constructors/destructors called during
+          startup/shutdown.
+        - If the tools hit a 'gs()' modifier explained above.
+
+   * Jumping to non-symbolic addresses like so is _not_ supported:
+
+          int main (void)
+          {
+              /* Call function at word address 0x2 */
+              return ((int(*)(void)) 0x2)();
+          }
+
+     Instead, a stub has to be set up, i.e. the function has to be
+     called through a symbol ('func_4' in the example):
+
+          int main (void)
+          {
+              extern int func_4 (void);
+
+              /* Call function at byte address 0x4 */
+              return func_4();
+          }
+
+     and the application be linked with '-Wl,--defsym,func_4=0x4'.
+     Alternatively, 'func_4' can be defined in the linker script.
+
+3.17.5.2 Handling of the 'RAMPD', 'RAMPX', 'RAMPY' and 'RAMPZ' Special Function Registers
+.........................................................................................
+
+Some AVR devices support memories larger than the 64 KiB range that can
+be accessed with 16-bit pointers.  To access memory locations outside
+this 64 KiB range, the contentent of a 'RAMP' register is used as high
+part of the address: The 'X', 'Y', 'Z' address register is concatenated
+with the 'RAMPX', 'RAMPY', 'RAMPZ' special function register,
+respectively, to get a wide address.  Similarly, 'RAMPD' is used
+together with direct addressing.
+
+   * The startup code initializes the 'RAMP' special function registers
+     with zero.
+
+   * If a *note named address space: AVR Named Address Spaces. other
+     than generic or '__flash' is used, then 'RAMPZ' is set as needed
+     before the operation.
+
+   * If the device supports RAM larger than 64 KiB and the compiler
+     needs to change 'RAMPZ' to accomplish an operation, 'RAMPZ' is
+     reset to zero after the operation.
+
+   * If the device comes with a specific 'RAMP' register, the ISR
+     prologue/epilogue saves/restores that SFR and initializes it with
+     zero in case the ISR code might (implicitly) use it.
+
+   * RAM larger than 64 KiB is not supported by GCC for AVR targets.  If
+     you use inline assembler to read from locations outside the 16-bit
+     address range and change one of the 'RAMP' registers, you must
+     reset it to zero after the access.
+
+3.17.5.3 AVR Built-in Macros
+............................
+
+GCC defines several built-in macros so that the user code can test for
+the presence or absence of features.  Almost any of the following
+built-in macros are deduced from device capabilities and thus triggered
+by the '-mmcu=' command-line option.
+
+ For even more AVR-specific built-in macros see *note AVR Named Address
+Spaces:: and *note AVR Built-in Functions::.
+
+'__AVR_ARCH__'
+     Build-in macro that resolves to a decimal number that identifies
+     the architecture and depends on the '-mmcu=MCU' option.  Possible
+     values are:
+
+     '2', '25', '3', '31', '35', '4', '5', '51', '6', '102', '104',
+     '105', '106', '107'
+
+     for MCU='avr2', 'avr25', 'avr3', 'avr31', 'avr35', 'avr4', 'avr5',
+     'avr51', 'avr6', 'avrxmega2', 'avrxmega4', 'avrxmega5',
+     'avrxmega6', 'avrxmega7', respectively.  If MCU specifies a device,
+     this built-in macro is set accordingly.  For example, with
+     '-mmcu=atmega8' the macro will be defined to '4'.
+
+'__AVR_DEVICE__'
+     Setting '-mmcu=DEVICE' defines this built-in macro which reflects
+     the device's name.  For example, '-mmcu=atmega8' defines the
+     built-in macro '__AVR_ATmega8__', '-mmcu=attiny261a' defines
+     '__AVR_ATtiny261A__', etc.
+
+     The built-in macros' names follow the scheme '__AVR_DEVICE__' where
+     DEVICE is the device name as from the AVR user manual.  The
+     difference between DEVICE in the built-in macro and DEVICE in
+     '-mmcu=DEVICE' is that the latter is always lowercase.
+
+     If DEVICE is not a device but only a core architecture like
+     'avr51', this macro will not be defined.
+
+'__AVR_XMEGA__'
+     The device / architecture belongs to the XMEGA family of devices.
+
+'__AVR_HAVE_ELPM__'
+     The device has the the 'ELPM' instruction.
+
+'__AVR_HAVE_ELPMX__'
+     The device has the 'ELPM RN,Z' and 'ELPM RN,Z+' instructions.
+
+'__AVR_HAVE_MOVW__'
+     The device has the 'MOVW' instruction to perform 16-bit
+     register-register moves.
+
+'__AVR_HAVE_LPMX__'
+     The device has the 'LPM RN,Z' and 'LPM RN,Z+' instructions.
+
+'__AVR_HAVE_MUL__'
+     The device has a hardware multiplier.
+
+'__AVR_HAVE_JMP_CALL__'
+     The device has the 'JMP' and 'CALL' instructions.  This is the case
+     for devices with at least 16 KiB of program memory.
+
+'__AVR_HAVE_EIJMP_EICALL__'
+'__AVR_3_BYTE_PC__'
+     The device has the 'EIJMP' and 'EICALL' instructions.  This is the
+     case for devices with more than 128 KiB of program memory.  This
+     also means that the program counter (PC) is 3 bytes wide.
+
+'__AVR_2_BYTE_PC__'
+     The program counter (PC) is 2 bytes wide.  This is the case for
+     devices with up to 128 KiB of program memory.
+
+'__AVR_HAVE_8BIT_SP__'
+'__AVR_HAVE_16BIT_SP__'
+     The stack pointer (SP) register is treated as 8-bit respectively
+     16-bit register by the compiler.  The definition of these macros is
+     affected by '-mtiny-stack'.
+
+'__AVR_HAVE_SPH__'
+'__AVR_SP8__'
+     The device has the SPH (high part of stack pointer) special
+     function register or has an 8-bit stack pointer, respectively.  The
+     definition of these macros is affected by '-mmcu=' and in the cases
+     of '-mmcu=avr2' and '-mmcu=avr25' also by '-msp8'.
+
+'__AVR_HAVE_RAMPD__'
+'__AVR_HAVE_RAMPX__'
+'__AVR_HAVE_RAMPY__'
+'__AVR_HAVE_RAMPZ__'
+     The device has the 'RAMPD', 'RAMPX', 'RAMPY', 'RAMPZ' special
+     function register, respectively.
+
+'__NO_INTERRUPTS__'
+     This macro reflects the '-mno-interrupts' command line option.
+
+'__AVR_ERRATA_SKIP__'
+'__AVR_ERRATA_SKIP_JMP_CALL__'
+     Some AVR devices (AT90S8515, ATmega103) must not skip 32-bit
+     instructions because of a hardware erratum.  Skip instructions are
+     'SBRS', 'SBRC', 'SBIS', 'SBIC' and 'CPSE'.  The second macro is
+     only defined if '__AVR_HAVE_JMP_CALL__' is also set.
+
+'__AVR_ISA_RMW__'
+     The device has Read-Modify-Write instructions (XCH, LAC, LAS and
+     LAT).
+
+'__AVR_SFR_OFFSET__=OFFSET'
+     Instructions that can address I/O special function registers
+     directly like 'IN', 'OUT', 'SBI', etc. may use a different address
+     as if addressed by an instruction to access RAM like 'LD' or 'STS'.
+     This offset depends on the device architecture and has to be
+     subtracted from the RAM address in order to get the respective
+     I/O address.
+
+'__WITH_AVRLIBC__'
+     The compiler is configured to be used together with AVR-Libc.  See
+     the '--with-avrlibc' configure option.
+
+
+File: gcc.info,  Node: Blackfin Options,  Next: C6X Options,  Prev: AVR Options,  Up: Submodel Options
+
+3.17.6 Blackfin Options
+-----------------------
+
+'-mcpu=CPU[-SIREVISION]'
+     Specifies the name of the target Blackfin processor.  Currently,
+     CPU can be one of 'bf512', 'bf514', 'bf516', 'bf518', 'bf522',
+     'bf523', 'bf524', 'bf525', 'bf526', 'bf527', 'bf531', 'bf532',
+     'bf533', 'bf534', 'bf536', 'bf537', 'bf538', 'bf539', 'bf542',
+     'bf544', 'bf547', 'bf548', 'bf549', 'bf542m', 'bf544m', 'bf547m',
+     'bf548m', 'bf549m', 'bf561', 'bf592'.
+
+     The optional SIREVISION specifies the silicon revision of the
+     target Blackfin processor.  Any workarounds available for the
+     targeted silicon revision are enabled.  If SIREVISION is 'none', no
+     workarounds are enabled.  If SIREVISION is 'any', all workarounds
+     for the targeted processor are enabled.  The '__SILICON_REVISION__'
+     macro is defined to two hexadecimal digits representing the major
+     and minor numbers in the silicon revision.  If SIREVISION is
+     'none', the '__SILICON_REVISION__' is not defined.  If SIREVISION
+     is 'any', the '__SILICON_REVISION__' is defined to be '0xffff'.  If
+     this optional SIREVISION is not used, GCC assumes the latest known
+     silicon revision of the targeted Blackfin processor.
+
+     GCC defines a preprocessor macro for the specified CPU.  For the
+     'bfin-elf' toolchain, this option causes the hardware BSP provided
+     by libgloss to be linked in if '-msim' is not given.
+
+     Without this option, 'bf532' is used as the processor by default.
+
+     Note that support for 'bf561' is incomplete.  For 'bf561', only the
+     preprocessor macro is defined.
+
+'-msim'
+     Specifies that the program will be run on the simulator.  This
+     causes the simulator BSP provided by libgloss to be linked in.
+     This option has effect only for 'bfin-elf' toolchain.  Certain
+     other options, such as '-mid-shared-library' and '-mfdpic', imply
+     '-msim'.
+
+'-momit-leaf-frame-pointer'
+     Don't keep the frame pointer in a register for leaf functions.
+     This avoids the instructions to save, set up and restore frame
+     pointers and makes an extra register available in leaf functions.
+     The option '-fomit-frame-pointer' removes the frame pointer for all
+     functions, which might make debugging harder.
+
+'-mspecld-anomaly'
+     When enabled, the compiler ensures that the generated code does not
+     contain speculative loads after jump instructions.  If this option
+     is used, '__WORKAROUND_SPECULATIVE_LOADS' is defined.
+
+'-mno-specld-anomaly'
+     Don't generate extra code to prevent speculative loads from
+     occurring.
+
+'-mcsync-anomaly'
+     When enabled, the compiler ensures that the generated code does not
+     contain CSYNC or SSYNC instructions too soon after conditional
+     branches.  If this option is used, '__WORKAROUND_SPECULATIVE_SYNCS'
+     is defined.
+
+'-mno-csync-anomaly'
+     Don't generate extra code to prevent CSYNC or SSYNC instructions
+     from occurring too soon after a conditional branch.
+
+'-mlow-64k'
+     When enabled, the compiler is free to take advantage of the
+     knowledge that the entire program fits into the low 64k of memory.
+
+'-mno-low-64k'
+     Assume that the program is arbitrarily large.  This is the default.
+
+'-mstack-check-l1'
+     Do stack checking using information placed into L1 scratchpad
+     memory by the uClinux kernel.
+
+'-mid-shared-library'
+     Generate code that supports shared libraries via the library ID
+     method.  This allows for execute in place and shared libraries in
+     an environment without virtual memory management.  This option
+     implies '-fPIC'.  With a 'bfin-elf' target, this option implies
+     '-msim'.
+
+'-mno-id-shared-library'
+     Generate code that doesn't assume ID-based shared libraries are
+     being used.  This is the default.
+
+'-mleaf-id-shared-library'
+     Generate code that supports shared libraries via the library ID
+     method, but assumes that this library or executable won't link
+     against any other ID shared libraries.  That allows the compiler to
+     use faster code for jumps and calls.
+
+'-mno-leaf-id-shared-library'
+     Do not assume that the code being compiled won't link against any
+     ID shared libraries.  Slower code is generated for jump and call
+     insns.
+
+'-mshared-library-id=n'
+     Specifies the identification number of the ID-based shared library
+     being compiled.  Specifying a value of 0 generates more compact
+     code; specifying other values forces the allocation of that number
+     to the current library but is no more space- or time-efficient than
+     omitting this option.
+
+'-msep-data'
+     Generate code that allows the data segment to be located in a
+     different area of memory from the text segment.  This allows for
+     execute in place in an environment without virtual memory
+     management by eliminating relocations against the text section.
+
+'-mno-sep-data'
+     Generate code that assumes that the data segment follows the text
+     segment.  This is the default.
+
+'-mlong-calls'
+'-mno-long-calls'
+     Tells the compiler to perform function calls by first loading the
+     address of the function into a register and then performing a
+     subroutine call on this register.  This switch is needed if the
+     target function lies outside of the 24-bit addressing range of the
+     offset-based version of subroutine call instruction.
+
+     This feature is not enabled by default.  Specifying
+     '-mno-long-calls' restores the default behavior.  Note these
+     switches have no effect on how the compiler generates code to
+     handle function calls via function pointers.
+
+'-mfast-fp'
+     Link with the fast floating-point library.  This library relaxes
+     some of the IEEE floating-point standard's rules for checking
+     inputs against Not-a-Number (NAN), in the interest of performance.
+
+'-minline-plt'
+     Enable inlining of PLT entries in function calls to functions that
+     are not known to bind locally.  It has no effect without '-mfdpic'.
+
+'-mmulticore'
+     Build a standalone application for multicore Blackfin processors.
+     This option causes proper start files and link scripts supporting
+     multicore to be used, and defines the macro '__BFIN_MULTICORE'.  It
+     can only be used with '-mcpu=bf561[-SIREVISION]'.
+
+     This option can be used with '-mcorea' or '-mcoreb', which selects
+     the one-application-per-core programming model.  Without '-mcorea'
+     or '-mcoreb', the single-application/dual-core programming model is
+     used.  In this model, the main function of Core B should be named
+     as 'coreb_main'.
+
+     If this option is not used, the single-core application programming
+     model is used.
+
+'-mcorea'
+     Build a standalone application for Core A of BF561 when using the
+     one-application-per-core programming model.  Proper start files and
+     link scripts are used to support Core A, and the macro
+     '__BFIN_COREA' is defined.  This option can only be used in
+     conjunction with '-mmulticore'.
+
+'-mcoreb'
+     Build a standalone application for Core B of BF561 when using the
+     one-application-per-core programming model.  Proper start files and
+     link scripts are used to support Core B, and the macro
+     '__BFIN_COREB' is defined.  When this option is used, 'coreb_main'
+     should be used instead of 'main'.  This option can only be used in
+     conjunction with '-mmulticore'.
+
+'-msdram'
+     Build a standalone application for SDRAM. Proper start files and
+     link scripts are used to put the application into SDRAM, and the
+     macro '__BFIN_SDRAM' is defined.  The loader should initialize
+     SDRAM before loading the application.
+
+'-micplb'
+     Assume that ICPLBs are enabled at run time.  This has an effect on
+     certain anomaly workarounds.  For Linux targets, the default is to
+     assume ICPLBs are enabled; for standalone applications the default
+     is off.
+
+
+File: gcc.info,  Node: C6X Options,  Next: CRIS Options,  Prev: Blackfin Options,  Up: Submodel Options
+
+3.17.7 C6X Options
+------------------
+
+'-march=NAME'
+     This specifies the name of the target architecture.  GCC uses this
+     name to determine what kind of instructions it can emit when
+     generating assembly code.  Permissible names are: 'c62x', 'c64x',
+     'c64x+', 'c67x', 'c67x+', 'c674x'.
+
+'-mbig-endian'
+     Generate code for a big-endian target.
+
+'-mlittle-endian'
+     Generate code for a little-endian target.  This is the default.
+
+'-msim'
+     Choose startup files and linker script suitable for the simulator.
+
+'-msdata=default'
+     Put small global and static data in the '.neardata' section, which
+     is pointed to by register 'B14'.  Put small uninitialized global
+     and static data in the '.bss' section, which is adjacent to the
+     '.neardata' section.  Put small read-only data into the '.rodata'
+     section.  The corresponding sections used for large pieces of data
+     are '.fardata', '.far' and '.const'.
+
+'-msdata=all'
+     Put all data, not just small objects, into the sections reserved
+     for small data, and use addressing relative to the 'B14' register
+     to access them.
+
+'-msdata=none'
+     Make no use of the sections reserved for small data, and use
+     absolute addresses to access all data.  Put all initialized global
+     and static data in the '.fardata' section, and all uninitialized
+     data in the '.far' section.  Put all constant data into the
+     '.const' section.
+
+
+File: gcc.info,  Node: CRIS Options,  Next: CR16 Options,  Prev: C6X Options,  Up: Submodel Options
+
+3.17.8 CRIS Options
+-------------------
+
+These options are defined specifically for the CRIS ports.
+
+'-march=ARCHITECTURE-TYPE'
+'-mcpu=ARCHITECTURE-TYPE'
+     Generate code for the specified architecture.  The choices for
+     ARCHITECTURE-TYPE are 'v3', 'v8' and 'v10' for respectively
+     ETRAX 4, ETRAX 100, and ETRAX 100 LX.  Default is 'v0' except for
+     cris-axis-linux-gnu, where the default is 'v10'.
+
+'-mtune=ARCHITECTURE-TYPE'
+     Tune to ARCHITECTURE-TYPE everything applicable about the generated
+     code, except for the ABI and the set of available instructions.
+     The choices for ARCHITECTURE-TYPE are the same as for
+     '-march=ARCHITECTURE-TYPE'.
+
+'-mmax-stack-frame=N'
+     Warn when the stack frame of a function exceeds N bytes.
+
+'-metrax4'
+'-metrax100'
+     The options '-metrax4' and '-metrax100' are synonyms for
+     '-march=v3' and '-march=v8' respectively.
+
+'-mmul-bug-workaround'
+'-mno-mul-bug-workaround'
+     Work around a bug in the 'muls' and 'mulu' instructions for CPU
+     models where it applies.  This option is active by default.
+
+'-mpdebug'
+     Enable CRIS-specific verbose debug-related information in the
+     assembly code.  This option also has the effect of turning off the
+     '#NO_APP' formatted-code indicator to the assembler at the
+     beginning of the assembly file.
+
+'-mcc-init'
+     Do not use condition-code results from previous instruction; always
+     emit compare and test instructions before use of condition codes.
+
+'-mno-side-effects'
+     Do not emit instructions with side effects in addressing modes
+     other than post-increment.
+
+'-mstack-align'
+'-mno-stack-align'
+'-mdata-align'
+'-mno-data-align'
+'-mconst-align'
+'-mno-const-align'
+     These options ('no-' options) arrange (eliminate arrangements) for
+     the stack frame, individual data and constants to be aligned for
+     the maximum single data access size for the chosen CPU model.  The
+     default is to arrange for 32-bit alignment.  ABI details such as
+     structure layout are not affected by these options.
+
+'-m32-bit'
+'-m16-bit'
+'-m8-bit'
+     Similar to the stack- data- and const-align options above, these
+     options arrange for stack frame, writable data and constants to all
+     be 32-bit, 16-bit or 8-bit aligned.  The default is 32-bit
+     alignment.
+
+'-mno-prologue-epilogue'
+'-mprologue-epilogue'
+     With '-mno-prologue-epilogue', the normal function prologue and
+     epilogue which set up the stack frame are omitted and no return
+     instructions or return sequences are generated in the code.  Use
+     this option only together with visual inspection of the compiled
+     code: no warnings or errors are generated when call-saved registers
+     must be saved, or storage for local variables needs to be
+     allocated.
+
+'-mno-gotplt'
+'-mgotplt'
+     With '-fpic' and '-fPIC', don't generate (do generate) instruction
+     sequences that load addresses for functions from the PLT part of
+     the GOT rather than (traditional on other architectures) calls to
+     the PLT.  The default is '-mgotplt'.
+
+'-melf'
+     Legacy no-op option only recognized with the cris-axis-elf and
+     cris-axis-linux-gnu targets.
+
+'-mlinux'
+     Legacy no-op option only recognized with the cris-axis-linux-gnu
+     target.
+
+'-sim'
+     This option, recognized for the cris-axis-elf, arranges to link
+     with input-output functions from a simulator library.  Code,
+     initialized data and zero-initialized data are allocated
+     consecutively.
+
+'-sim2'
+     Like '-sim', but pass linker options to locate initialized data at
+     0x40000000 and zero-initialized data at 0x80000000.
+
+
+File: gcc.info,  Node: CR16 Options,  Next: Darwin Options,  Prev: CRIS Options,  Up: Submodel Options
+
+3.17.9 CR16 Options
+-------------------
+
+These options are defined specifically for the CR16 ports.
+
+'-mmac'
+     Enable the use of multiply-accumulate instructions.  Disabled by
+     default.
+
+'-mcr16cplus'
+'-mcr16c'
+     Generate code for CR16C or CR16C+ architecture.  CR16C+
+     architecture is default.
+
+'-msim'
+     Links the library libsim.a which is in compatible with simulator.
+     Applicable to ELF compiler only.
+
+'-mint32'
+     Choose integer type as 32-bit wide.
+
+'-mbit-ops'
+     Generates 'sbit'/'cbit' instructions for bit manipulations.
+
+'-mdata-model=MODEL'
+     Choose a data model.  The choices for MODEL are 'near', 'far' or
+     'medium'.  'medium' is default.  However, 'far' is not valid with
+     '-mcr16c', as the CR16C architecture does not support the far data
+     model.
+
+
+File: gcc.info,  Node: Darwin Options,  Next: DEC Alpha Options,  Prev: CR16 Options,  Up: Submodel Options
+
+3.17.10 Darwin Options
+----------------------
+
+These options are defined for all architectures running the Darwin
+operating system.
+
+ FSF GCC on Darwin does not create "fat" object files; it creates an
+object file for the single architecture that GCC was built to target.
+Apple's GCC on Darwin does create "fat" files if multiple '-arch'
+options are used; it does so by running the compiler or linker multiple
+times and joining the results together with 'lipo'.
+
+ The subtype of the file created (like 'ppc7400' or 'ppc970' or 'i686')
+is determined by the flags that specify the ISA that GCC is targeting,
+like '-mcpu' or '-march'.  The '-force_cpusubtype_ALL' option can be
+used to override this.
+
+ The Darwin tools vary in their behavior when presented with an ISA
+mismatch.  The assembler, 'as', only permits instructions to be used
+that are valid for the subtype of the file it is generating, so you
+cannot put 64-bit instructions in a 'ppc750' object file.  The linker
+for shared libraries, '/usr/bin/libtool', fails and prints an error if
+asked to create a shared library with a less restrictive subtype than
+its input files (for instance, trying to put a 'ppc970' object file in a
+'ppc7400' library).  The linker for executables, 'ld', quietly gives the
+executable the most restrictive subtype of any of its input files.
+
+'-FDIR'
+     Add the framework directory DIR to the head of the list of
+     directories to be searched for header files.  These directories are
+     interleaved with those specified by '-I' options and are scanned in
+     a left-to-right order.
+
+     A framework directory is a directory with frameworks in it.  A
+     framework is a directory with a 'Headers' and/or 'PrivateHeaders'
+     directory contained directly in it that ends in '.framework'.  The
+     name of a framework is the name of this directory excluding the
+     '.framework'.  Headers associated with the framework are found in
+     one of those two directories, with 'Headers' being searched first.
+     A subframework is a framework directory that is in a framework's
+     'Frameworks' directory.  Includes of subframework headers can only
+     appear in a header of a framework that contains the subframework,
+     or in a sibling subframework header.  Two subframeworks are
+     siblings if they occur in the same framework.  A subframework
+     should not have the same name as a framework; a warning is issued
+     if this is violated.  Currently a subframework cannot have
+     subframeworks; in the future, the mechanism may be extended to
+     support this.  The standard frameworks can be found in
+     '/System/Library/Frameworks' and '/Library/Frameworks'.  An example
+     include looks like '#include <Framework/header.h>', where
+     'Framework' denotes the name of the framework and 'header.h' is
+     found in the 'PrivateHeaders' or 'Headers' directory.
+
+'-iframeworkDIR'
+     Like '-F' except the directory is a treated as a system directory.
+     The main difference between this '-iframework' and '-F' is that
+     with '-iframework' the compiler does not warn about constructs
+     contained within header files found via DIR.  This option is valid
+     only for the C family of languages.
+
+'-gused'
+     Emit debugging information for symbols that are used.  For stabs
+     debugging format, this enables '-feliminate-unused-debug-symbols'.
+     This is by default ON.
+
+'-gfull'
+     Emit debugging information for all symbols and types.
+
+'-mmacosx-version-min=VERSION'
+     The earliest version of MacOS X that this executable will run on is
+     VERSION.  Typical values of VERSION include '10.1', '10.2', and
+     '10.3.9'.
+
+     If the compiler was built to use the system's headers by default,
+     then the default for this option is the system version on which the
+     compiler is running, otherwise the default is to make choices that
+     are compatible with as many systems and code bases as possible.
+
+'-mkernel'
+     Enable kernel development mode.  The '-mkernel' option sets
+     '-static', '-fno-common', '-fno-cxa-atexit', '-fno-exceptions',
+     '-fno-non-call-exceptions', '-fapple-kext', '-fno-weak' and
+     '-fno-rtti' where applicable.  This mode also sets '-mno-altivec',
+     '-msoft-float', '-fno-builtin' and '-mlong-branch' for PowerPC
+     targets.
+
+'-mone-byte-bool'
+     Override the defaults for 'bool' so that 'sizeof(bool)==1'.  By
+     default 'sizeof(bool)' is '4' when compiling for Darwin/PowerPC and
+     '1' when compiling for Darwin/x86, so this option has no effect on
+     x86.
+
+     *Warning:* The '-mone-byte-bool' switch causes GCC to generate code
+     that is not binary compatible with code generated without that
+     switch.  Using this switch may require recompiling all other
+     modules in a program, including system libraries.  Use this switch
+     to conform to a non-default data model.
+
+'-mfix-and-continue'
+'-ffix-and-continue'
+'-findirect-data'
+     Generate code suitable for fast turnaround development, such as to
+     allow GDB to dynamically load '.o' files into already-running
+     programs.  '-findirect-data' and '-ffix-and-continue' are provided
+     for backwards compatibility.
+
+'-all_load'
+     Loads all members of static archive libraries.  See man ld(1) for
+     more information.
+
+'-arch_errors_fatal'
+     Cause the errors having to do with files that have the wrong
+     architecture to be fatal.
+
+'-bind_at_load'
+     Causes the output file to be marked such that the dynamic linker
+     will bind all undefined references when the file is loaded or
+     launched.
+
+'-bundle'
+     Produce a Mach-o bundle format file.  See man ld(1) for more
+     information.
+
+'-bundle_loader EXECUTABLE'
+     This option specifies the EXECUTABLE that will load the build
+     output file being linked.  See man ld(1) for more information.
+
+'-dynamiclib'
+     When passed this option, GCC produces a dynamic library instead of
+     an executable when linking, using the Darwin 'libtool' command.
+
+'-force_cpusubtype_ALL'
+     This causes GCC's output file to have the ALL subtype, instead of
+     one controlled by the '-mcpu' or '-march' option.
+
+'-allowable_client CLIENT_NAME'
+'-client_name'
+'-compatibility_version'
+'-current_version'
+'-dead_strip'
+'-dependency-file'
+'-dylib_file'
+'-dylinker_install_name'
+'-dynamic'
+'-exported_symbols_list'
+'-filelist'
+'-flat_namespace'
+'-force_flat_namespace'
+'-headerpad_max_install_names'
+'-image_base'
+'-init'
+'-install_name'
+'-keep_private_externs'
+'-multi_module'
+'-multiply_defined'
+'-multiply_defined_unused'
+'-noall_load'
+'-no_dead_strip_inits_and_terms'
+'-nofixprebinding'
+'-nomultidefs'
+'-noprebind'
+'-noseglinkedit'
+'-pagezero_size'
+'-prebind'
+'-prebind_all_twolevel_modules'
+'-private_bundle'
+'-read_only_relocs'
+'-sectalign'
+'-sectobjectsymbols'
+'-whyload'
+'-seg1addr'
+'-sectcreate'
+'-sectobjectsymbols'
+'-sectorder'
+'-segaddr'
+'-segs_read_only_addr'
+'-segs_read_write_addr'
+'-seg_addr_table'
+'-seg_addr_table_filename'
+'-seglinkedit'
+'-segprot'
+'-segs_read_only_addr'
+'-segs_read_write_addr'
+'-single_module'
+'-static'
+'-sub_library'
+'-sub_umbrella'
+'-twolevel_namespace'
+'-umbrella'
+'-undefined'
+'-unexported_symbols_list'
+'-weak_reference_mismatches'
+'-whatsloaded'
+     These options are passed to the Darwin linker.  The Darwin linker
+     man page describes them in detail.
+
+
+File: gcc.info,  Node: DEC Alpha Options,  Next: FR30 Options,  Prev: Darwin Options,  Up: Submodel Options
+
+3.17.11 DEC Alpha Options
+-------------------------
+
+These '-m' options are defined for the DEC Alpha implementations:
+
+'-mno-soft-float'
+'-msoft-float'
+     Use (do not use) the hardware floating-point instructions for
+     floating-point operations.  When '-msoft-float' is specified,
+     functions in 'libgcc.a' are used to perform floating-point
+     operations.  Unless they are replaced by routines that emulate the
+     floating-point operations, or compiled in such a way as to call
+     such emulations routines, these routines issue floating-point
+     operations.  If you are compiling for an Alpha without
+     floating-point operations, you must ensure that the library is
+     built so as not to call them.
+
+     Note that Alpha implementations without floating-point operations
+     are required to have floating-point registers.
+
+'-mfp-reg'
+'-mno-fp-regs'
+     Generate code that uses (does not use) the floating-point register
+     set.  '-mno-fp-regs' implies '-msoft-float'.  If the floating-point
+     register set is not used, floating-point operands are passed in
+     integer registers as if they were integers and floating-point
+     results are passed in '$0' instead of '$f0'.  This is a
+     non-standard calling sequence, so any function with a
+     floating-point argument or return value called by code compiled
+     with '-mno-fp-regs' must also be compiled with that option.
+
+     A typical use of this option is building a kernel that does not
+     use, and hence need not save and restore, any floating-point
+     registers.
+
+'-mieee'
+     The Alpha architecture implements floating-point hardware optimized
+     for maximum performance.  It is mostly compliant with the IEEE
+     floating-point standard.  However, for full compliance, software
+     assistance is required.  This option generates code fully
+     IEEE-compliant code _except_ that the INEXACT-FLAG is not
+     maintained (see below).  If this option is turned on, the
+     preprocessor macro '_IEEE_FP' is defined during compilation.  The
+     resulting code is less efficient but is able to correctly support
+     denormalized numbers and exceptional IEEE values such as
+     not-a-number and plus/minus infinity.  Other Alpha compilers call
+     this option '-ieee_with_no_inexact'.
+
+'-mieee-with-inexact'
+     This is like '-mieee' except the generated code also maintains the
+     IEEE INEXACT-FLAG.  Turning on this option causes the generated
+     code to implement fully-compliant IEEE math.  In addition to
+     '_IEEE_FP', '_IEEE_FP_EXACT' is defined as a preprocessor macro.
+     On some Alpha implementations the resulting code may execute
+     significantly slower than the code generated by default.  Since
+     there is very little code that depends on the INEXACT-FLAG, you
+     should normally not specify this option.  Other Alpha compilers
+     call this option '-ieee_with_inexact'.
+
+'-mfp-trap-mode=TRAP-MODE'
+     This option controls what floating-point related traps are enabled.
+     Other Alpha compilers call this option '-fptm TRAP-MODE'.  The trap
+     mode can be set to one of four values:
+
+     'n'
+          This is the default (normal) setting.  The only traps that are
+          enabled are the ones that cannot be disabled in software
+          (e.g., division by zero trap).
+
+     'u'
+          In addition to the traps enabled by 'n', underflow traps are
+          enabled as well.
+
+     'su'
+          Like 'u', but the instructions are marked to be safe for
+          software completion (see Alpha architecture manual for
+          details).
+
+     'sui'
+          Like 'su', but inexact traps are enabled as well.
+
+'-mfp-rounding-mode=ROUNDING-MODE'
+     Selects the IEEE rounding mode.  Other Alpha compilers call this
+     option '-fprm ROUNDING-MODE'.  The ROUNDING-MODE can be one of:
+
+     'n'
+          Normal IEEE rounding mode.  Floating-point numbers are rounded
+          towards the nearest machine number or towards the even machine
+          number in case of a tie.
+
+     'm'
+          Round towards minus infinity.
+
+     'c'
+          Chopped rounding mode.  Floating-point numbers are rounded
+          towards zero.
+
+     'd'
+          Dynamic rounding mode.  A field in the floating-point control
+          register (FPCR, see Alpha architecture reference manual)
+          controls the rounding mode in effect.  The C library
+          initializes this register for rounding towards plus infinity.
+          Thus, unless your program modifies the FPCR, 'd' corresponds
+          to round towards plus infinity.
+
+'-mtrap-precision=TRAP-PRECISION'
+     In the Alpha architecture, floating-point traps are imprecise.
+     This means without software assistance it is impossible to recover
+     from a floating trap and program execution normally needs to be
+     terminated.  GCC can generate code that can assist operating system
+     trap handlers in determining the exact location that caused a
+     floating-point trap.  Depending on the requirements of an
+     application, different levels of precisions can be selected:
+
+     'p'
+          Program precision.  This option is the default and means a
+          trap handler can only identify which program caused a
+          floating-point exception.
+
+     'f'
+          Function precision.  The trap handler can determine the
+          function that caused a floating-point exception.
+
+     'i'
+          Instruction precision.  The trap handler can determine the
+          exact instruction that caused a floating-point exception.
+
+     Other Alpha compilers provide the equivalent options called
+     '-scope_safe' and '-resumption_safe'.
+
+'-mieee-conformant'
+     This option marks the generated code as IEEE conformant.  You must
+     not use this option unless you also specify '-mtrap-precision=i'
+     and either '-mfp-trap-mode=su' or '-mfp-trap-mode=sui'.  Its only
+     effect is to emit the line '.eflag 48' in the function prologue of
+     the generated assembly file.
+
+'-mbuild-constants'
+     Normally GCC examines a 32- or 64-bit integer constant to see if it
+     can construct it from smaller constants in two or three
+     instructions.  If it cannot, it outputs the constant as a literal
+     and generates code to load it from the data segment at run time.
+
+     Use this option to require GCC to construct _all_ integer constants
+     using code, even if it takes more instructions (the maximum is
+     six).
+
+     You typically use this option to build a shared library dynamic
+     loader.  Itself a shared library, it must relocate itself in memory
+     before it can find the variables and constants in its own data
+     segment.
+
+'-mbwx'
+'-mno-bwx'
+'-mcix'
+'-mno-cix'
+'-mfix'
+'-mno-fix'
+'-mmax'
+'-mno-max'
+     Indicate whether GCC should generate code to use the optional BWX,
+     CIX, FIX and MAX instruction sets.  The default is to use the
+     instruction sets supported by the CPU type specified via '-mcpu='
+     option or that of the CPU on which GCC was built if none is
+     specified.
+
+'-mfloat-vax'
+'-mfloat-ieee'
+     Generate code that uses (does not use) VAX F and G floating-point
+     arithmetic instead of IEEE single and double precision.
+
+'-mexplicit-relocs'
+'-mno-explicit-relocs'
+     Older Alpha assemblers provided no way to generate symbol
+     relocations except via assembler macros.  Use of these macros does
+     not allow optimal instruction scheduling.  GNU binutils as of
+     version 2.12 supports a new syntax that allows the compiler to
+     explicitly mark which relocations should apply to which
+     instructions.  This option is mostly useful for debugging, as GCC
+     detects the capabilities of the assembler when it is built and sets
+     the default accordingly.
+
+'-msmall-data'
+'-mlarge-data'
+     When '-mexplicit-relocs' is in effect, static data is accessed via
+     "gp-relative" relocations.  When '-msmall-data' is used, objects 8
+     bytes long or smaller are placed in a "small data area" (the
+     '.sdata' and '.sbss' sections) and are accessed via 16-bit
+     relocations off of the '$gp' register.  This limits the size of the
+     small data area to 64KB, but allows the variables to be directly
+     accessed via a single instruction.
+
+     The default is '-mlarge-data'.  With this option the data area is
+     limited to just below 2GB.  Programs that require more than 2GB of
+     data must use 'malloc' or 'mmap' to allocate the data in the heap
+     instead of in the program's data segment.
+
+     When generating code for shared libraries, '-fpic' implies
+     '-msmall-data' and '-fPIC' implies '-mlarge-data'.
+
+'-msmall-text'
+'-mlarge-text'
+     When '-msmall-text' is used, the compiler assumes that the code of
+     the entire program (or shared library) fits in 4MB, and is thus
+     reachable with a branch instruction.  When '-msmall-data' is used,
+     the compiler can assume that all local symbols share the same '$gp'
+     value, and thus reduce the number of instructions required for a
+     function call from 4 to 1.
+
+     The default is '-mlarge-text'.
+
+'-mcpu=CPU_TYPE'
+     Set the instruction set and instruction scheduling parameters for
+     machine type CPU_TYPE.  You can specify either the 'EV' style name
+     or the corresponding chip number.  GCC supports scheduling
+     parameters for the EV4, EV5 and EV6 family of processors and
+     chooses the default values for the instruction set from the
+     processor you specify.  If you do not specify a processor type, GCC
+     defaults to the processor on which the compiler was built.
+
+     Supported values for CPU_TYPE are
+
+     'ev4'
+     'ev45'
+     '21064'
+          Schedules as an EV4 and has no instruction set extensions.
+
+     'ev5'
+     '21164'
+          Schedules as an EV5 and has no instruction set extensions.
+
+     'ev56'
+     '21164a'
+          Schedules as an EV5 and supports the BWX extension.
+
+     'pca56'
+     '21164pc'
+     '21164PC'
+          Schedules as an EV5 and supports the BWX and MAX extensions.
+
+     'ev6'
+     '21264'
+          Schedules as an EV6 and supports the BWX, FIX, and MAX
+          extensions.
+
+     'ev67'
+     '21264a'
+          Schedules as an EV6 and supports the BWX, CIX, FIX, and MAX
+          extensions.
+
+     Native toolchains also support the value 'native', which selects
+     the best architecture option for the host processor.
+     '-mcpu=native' has no effect if GCC does not recognize the
+     processor.
+
+'-mtune=CPU_TYPE'
+     Set only the instruction scheduling parameters for machine type
+     CPU_TYPE.  The instruction set is not changed.
+
+     Native toolchains also support the value 'native', which selects
+     the best architecture option for the host processor.
+     '-mtune=native' has no effect if GCC does not recognize the
+     processor.
+
+'-mmemory-latency=TIME'
+     Sets the latency the scheduler should assume for typical memory
+     references as seen by the application.  This number is highly
+     dependent on the memory access patterns used by the application and
+     the size of the external cache on the machine.
+
+     Valid options for TIME are
+
+     'NUMBER'
+          A decimal number representing clock cycles.
+
+     'L1'
+     'L2'
+     'L3'
+     'main'
+          The compiler contains estimates of the number of clock cycles
+          for "typical" EV4 & EV5 hardware for the Level 1, 2 & 3 caches
+          (also called Dcache, Scache, and Bcache), as well as to main
+          memory.  Note that L3 is only valid for EV5.
+
+
+File: gcc.info,  Node: FR30 Options,  Next: FRV Options,  Prev: DEC Alpha Options,  Up: Submodel Options
+
+3.17.12 FR30 Options
+--------------------
+
+These options are defined specifically for the FR30 port.
+
+'-msmall-model'
+     Use the small address space model.  This can produce smaller code,
+     but it does assume that all symbolic values and addresses fit into
+     a 20-bit range.
+
+'-mno-lsim'
+     Assume that runtime support has been provided and so there is no
+     need to include the simulator library ('libsim.a') on the linker
+     command line.
+
+
+File: gcc.info,  Node: FRV Options,  Next: GNU/Linux Options,  Prev: FR30 Options,  Up: Submodel Options
+
+3.17.13 FRV Options
+-------------------
+
+'-mgpr-32'
+
+     Only use the first 32 general-purpose registers.
+
+'-mgpr-64'
+
+     Use all 64 general-purpose registers.
+
+'-mfpr-32'
+
+     Use only the first 32 floating-point registers.
+
+'-mfpr-64'
+
+     Use all 64 floating-point registers.
+
+'-mhard-float'
+
+     Use hardware instructions for floating-point operations.
+
+'-msoft-float'
+
+     Use library routines for floating-point operations.
+
+'-malloc-cc'
+
+     Dynamically allocate condition code registers.
+
+'-mfixed-cc'
+
+     Do not try to dynamically allocate condition code registers, only
+     use 'icc0' and 'fcc0'.
+
+'-mdword'
+
+     Change ABI to use double word insns.
+
+'-mno-dword'
+
+     Do not use double word instructions.
+
+'-mdouble'
+
+     Use floating-point double instructions.
+
+'-mno-double'
+
+     Do not use floating-point double instructions.
+
+'-mmedia'
+
+     Use media instructions.
+
+'-mno-media'
+
+     Do not use media instructions.
+
+'-mmuladd'
+
+     Use multiply and add/subtract instructions.
+
+'-mno-muladd'
+
+     Do not use multiply and add/subtract instructions.
+
+'-mfdpic'
+
+     Select the FDPIC ABI, which uses function descriptors to represent
+     pointers to functions.  Without any PIC/PIE-related options, it
+     implies '-fPIE'.  With '-fpic' or '-fpie', it assumes GOT entries
+     and small data are within a 12-bit range from the GOT base address;
+     with '-fPIC' or '-fPIE', GOT offsets are computed with 32 bits.
+     With a 'bfin-elf' target, this option implies '-msim'.
+
+'-minline-plt'
+
+     Enable inlining of PLT entries in function calls to functions that
+     are not known to bind locally.  It has no effect without '-mfdpic'.
+     It's enabled by default if optimizing for speed and compiling for
+     shared libraries (i.e., '-fPIC' or '-fpic'), or when an
+     optimization option such as '-O3' or above is present in the
+     command line.
+
+'-mTLS'
+
+     Assume a large TLS segment when generating thread-local code.
+
+'-mtls'
+
+     Do not assume a large TLS segment when generating thread-local
+     code.
+
+'-mgprel-ro'
+
+     Enable the use of 'GPREL' relocations in the FDPIC ABI for data
+     that is known to be in read-only sections.  It's enabled by
+     default, except for '-fpic' or '-fpie': even though it may help
+     make the global offset table smaller, it trades 1 instruction for
+     4.  With '-fPIC' or '-fPIE', it trades 3 instructions for 4, one of
+     which may be shared by multiple symbols, and it avoids the need for
+     a GOT entry for the referenced symbol, so it's more likely to be a
+     win.  If it is not, '-mno-gprel-ro' can be used to disable it.
+
+'-multilib-library-pic'
+
+     Link with the (library, not FD) pic libraries.  It's implied by
+     '-mlibrary-pic', as well as by '-fPIC' and '-fpic' without
+     '-mfdpic'.  You should never have to use it explicitly.
+
+'-mlinked-fp'
+
+     Follow the EABI requirement of always creating a frame pointer
+     whenever a stack frame is allocated.  This option is enabled by
+     default and can be disabled with '-mno-linked-fp'.
+
+'-mlong-calls'
+
+     Use indirect addressing to call functions outside the current
+     compilation unit.  This allows the functions to be placed anywhere
+     within the 32-bit address space.
+
+'-malign-labels'
+
+     Try to align labels to an 8-byte boundary by inserting NOPs into
+     the previous packet.  This option only has an effect when VLIW
+     packing is enabled.  It doesn't create new packets; it merely adds
+     NOPs to existing ones.
+
+'-mlibrary-pic'
+
+     Generate position-independent EABI code.
+
+'-macc-4'
+
+     Use only the first four media accumulator registers.
+
+'-macc-8'
+
+     Use all eight media accumulator registers.
+
+'-mpack'
+
+     Pack VLIW instructions.
+
+'-mno-pack'
+
+     Do not pack VLIW instructions.
+
+'-mno-eflags'
+
+     Do not mark ABI switches in e_flags.
+
+'-mcond-move'
+
+     Enable the use of conditional-move instructions (default).
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mno-cond-move'
+
+     Disable the use of conditional-move instructions.
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mscc'
+
+     Enable the use of conditional set instructions (default).
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mno-scc'
+
+     Disable the use of conditional set instructions.
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mcond-exec'
+
+     Enable the use of conditional execution (default).
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mno-cond-exec'
+
+     Disable the use of conditional execution.
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mvliw-branch'
+
+     Run a pass to pack branches into VLIW instructions (default).
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mno-vliw-branch'
+
+     Do not run a pass to pack branches into VLIW instructions.
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mmulti-cond-exec'
+
+     Enable optimization of '&&' and '||' in conditional execution
+     (default).
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mno-multi-cond-exec'
+
+     Disable optimization of '&&' and '||' in conditional execution.
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mnested-cond-exec'
+
+     Enable nested conditional execution optimizations (default).
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-mno-nested-cond-exec'
+
+     Disable nested conditional execution optimizations.
+
+     This switch is mainly for debugging the compiler and will likely be
+     removed in a future version.
+
+'-moptimize-membar'
+
+     This switch removes redundant 'membar' instructions from the
+     compiler-generated code.  It is enabled by default.
+
+'-mno-optimize-membar'
+
+     This switch disables the automatic removal of redundant 'membar'
+     instructions from the generated code.
+
+'-mtomcat-stats'
+
+     Cause gas to print out tomcat statistics.
+
+'-mcpu=CPU'
+
+     Select the processor type for which to generate code.  Possible
+     values are 'frv', 'fr550', 'tomcat', 'fr500', 'fr450', 'fr405',
+     'fr400', 'fr300' and 'simple'.
+
+
+File: gcc.info,  Node: GNU/Linux Options,  Next: H8/300 Options,  Prev: FRV Options,  Up: Submodel Options
+
+3.17.14 GNU/Linux Options
+-------------------------
+
+These '-m' options are defined for GNU/Linux targets:
+
+'-mglibc'
+     Use the GNU C library.  This is the default except on
+     '*-*-linux-*uclibc*' and '*-*-linux-*android*' targets.
+
+'-muclibc'
+     Use uClibc C library.  This is the default on '*-*-linux-*uclibc*'
+     targets.
+
+'-mbionic'
+     Use Bionic C library.  This is the default on '*-*-linux-*android*'
+     targets.
+
+'-mandroid'
+     Compile code compatible with Android platform.  This is the default
+     on '*-*-linux-*android*' targets.
+
+     When compiling, this option enables '-mbionic', '-fPIC',
+     '-fno-exceptions' and '-fno-rtti' by default.  When linking, this
+     option makes the GCC driver pass Android-specific options to the
+     linker.  Finally, this option causes the preprocessor macro
+     '__ANDROID__' to be defined.
+
+'-tno-android-cc'
+     Disable compilation effects of '-mandroid', i.e., do not enable
+     '-mbionic', '-fPIC', '-fno-exceptions' and '-fno-rtti' by default.
+
+'-tno-android-ld'
+     Disable linking effects of '-mandroid', i.e., pass standard Linux
+     linking options to the linker.
+
+
+File: gcc.info,  Node: H8/300 Options,  Next: HPPA Options,  Prev: GNU/Linux Options,  Up: Submodel Options
+
+3.17.15 H8/300 Options
+----------------------
+
+These '-m' options are defined for the H8/300 implementations:
+
+'-mrelax'
+     Shorten some address references at link time, when possible; uses
+     the linker option '-relax'.  *Note 'ld' and the H8/300: (ld)H8/300,
+     for a fuller description.
+
+'-mh'
+     Generate code for the H8/300H.
+
+'-ms'
+     Generate code for the H8S.
+
+'-mn'
+     Generate code for the H8S and H8/300H in the normal mode.  This
+     switch must be used either with '-mh' or '-ms'.
+
+'-ms2600'
+     Generate code for the H8S/2600.  This switch must be used with
+     '-ms'.
+
+'-mexr'
+     Extended registers are stored on stack before execution of function
+     with monitor attribute.  Default option is '-mexr'.  This option is
+     valid only for H8S targets.
+
+'-mno-exr'
+     Extended registers are not stored on stack before execution of
+     function with monitor attribute.  Default option is '-mno-exr'.
+     This option is valid only for H8S targets.
+
+'-mint32'
+     Make 'int' data 32 bits by default.
+
+'-malign-300'
+     On the H8/300H and H8S, use the same alignment rules as for the
+     H8/300.  The default for the H8/300H and H8S is to align longs and
+     floats on 4-byte boundaries.  '-malign-300' causes them to be
+     aligned on 2-byte boundaries.  This option has no effect on the
+     H8/300.
+
+
+File: gcc.info,  Node: HPPA Options,  Next: i386 and x86-64 Options,  Prev: H8/300 Options,  Up: Submodel Options
+
+3.17.16 HPPA Options
+--------------------
+
+These '-m' options are defined for the HPPA family of computers:
+
+'-march=ARCHITECTURE-TYPE'
+     Generate code for the specified architecture.  The choices for
+     ARCHITECTURE-TYPE are '1.0' for PA 1.0, '1.1' for PA 1.1, and '2.0'
+     for PA 2.0 processors.  Refer to '/usr/lib/sched.models' on an
+     HP-UX system to determine the proper architecture option for your
+     machine.  Code compiled for lower numbered architectures runs on
+     higher numbered architectures, but not the other way around.
+
+'-mpa-risc-1-0'
+'-mpa-risc-1-1'
+'-mpa-risc-2-0'
+     Synonyms for '-march=1.0', '-march=1.1', and '-march=2.0'
+     respectively.
+
+'-mjump-in-delay'
+     Fill delay slots of function calls with unconditional jump
+     instructions by modifying the return pointer for the function call
+     to be the target of the conditional jump.
+
+'-mdisable-fpregs'
+     Prevent floating-point registers from being used in any manner.
+     This is necessary for compiling kernels that perform lazy context
+     switching of floating-point registers.  If you use this option and
+     attempt to perform floating-point operations, the compiler aborts.
+
+'-mdisable-indexing'
+     Prevent the compiler from using indexing address modes.  This
+     avoids some rather obscure problems when compiling MIG generated
+     code under MACH.
+
+'-mno-space-regs'
+     Generate code that assumes the target has no space registers.  This
+     allows GCC to generate faster indirect calls and use unscaled index
+     address modes.
+
+     Such code is suitable for level 0 PA systems and kernels.
+
+'-mfast-indirect-calls'
+     Generate code that assumes calls never cross space boundaries.
+     This allows GCC to emit code that performs faster indirect calls.
+
+     This option does not work in the presence of shared libraries or
+     nested functions.
+
+'-mfixed-range=REGISTER-RANGE'
+     Generate code treating the given register range as fixed registers.
+     A fixed register is one that the register allocator cannot use.
+     This is useful when compiling kernel code.  A register range is
+     specified as two registers separated by a dash.  Multiple register
+     ranges can be specified separated by a comma.
+
+'-mlong-load-store'
+     Generate 3-instruction load and store sequences as sometimes
+     required by the HP-UX 10 linker.  This is equivalent to the '+k'
+     option to the HP compilers.
+
+'-mportable-runtime'
+     Use the portable calling conventions proposed by HP for ELF
+     systems.
+
+'-mgas'
+     Enable the use of assembler directives only GAS understands.
+
+'-mschedule=CPU-TYPE'
+     Schedule code according to the constraints for the machine type
+     CPU-TYPE.  The choices for CPU-TYPE are '700' '7100', '7100LC',
+     '7200', '7300' and '8000'.  Refer to '/usr/lib/sched.models' on an
+     HP-UX system to determine the proper scheduling option for your
+     machine.  The default scheduling is '8000'.
+
+'-mlinker-opt'
+     Enable the optimization pass in the HP-UX linker.  Note this makes
+     symbolic debugging impossible.  It also triggers a bug in the HP-UX
+     8 and HP-UX 9 linkers in which they give bogus error messages when
+     linking some programs.
+
+'-msoft-float'
+     Generate output containing library calls for floating point.
+     *Warning:* the requisite libraries are not available for all HPPA
+     targets.  Normally the facilities of the machine's usual C compiler
+     are used, but this cannot be done directly in cross-compilation.
+     You must make your own arrangements to provide suitable library
+     functions for cross-compilation.
+
+     '-msoft-float' changes the calling convention in the output file;
+     therefore, it is only useful if you compile _all_ of a program with
+     this option.  In particular, you need to compile 'libgcc.a', the
+     library that comes with GCC, with '-msoft-float' in order for this
+     to work.
+
+'-msio'
+     Generate the predefine, '_SIO', for server IO.  The default is
+     '-mwsio'.  This generates the predefines, '__hp9000s700',
+     '__hp9000s700__' and '_WSIO', for workstation IO.  These options
+     are available under HP-UX and HI-UX.
+
+'-mgnu-ld'
+     Use options specific to GNU 'ld'.  This passes '-shared' to 'ld'
+     when building a shared library.  It is the default when GCC is
+     configured, explicitly or implicitly, with the GNU linker.  This
+     option does not affect which 'ld' is called; it only changes what
+     parameters are passed to that 'ld'.  The 'ld' that is called is
+     determined by the '--with-ld' configure option, GCC's program
+     search path, and finally by the user's 'PATH'.  The linker used by
+     GCC can be printed using 'which `gcc -print-prog-name=ld`'.  This
+     option is only available on the 64-bit HP-UX GCC, i.e. configured
+     with 'hppa*64*-*-hpux*'.
+
+'-mhp-ld'
+     Use options specific to HP 'ld'.  This passes '-b' to 'ld' when
+     building a shared library and passes '+Accept TypeMismatch' to 'ld'
+     on all links.  It is the default when GCC is configured, explicitly
+     or implicitly, with the HP linker.  This option does not affect
+     which 'ld' is called; it only changes what parameters are passed to
+     that 'ld'.  The 'ld' that is called is determined by the
+     '--with-ld' configure option, GCC's program search path, and
+     finally by the user's 'PATH'.  The linker used by GCC can be
+     printed using 'which `gcc -print-prog-name=ld`'.  This option is
+     only available on the 64-bit HP-UX GCC, i.e. configured with
+     'hppa*64*-*-hpux*'.
+
+'-mlong-calls'
+     Generate code that uses long call sequences.  This ensures that a
+     call is always able to reach linker generated stubs.  The default
+     is to generate long calls only when the distance from the call site
+     to the beginning of the function or translation unit, as the case
+     may be, exceeds a predefined limit set by the branch type being
+     used.  The limits for normal calls are 7,600,000 and 240,000 bytes,
+     respectively for the PA 2.0 and PA 1.X architectures.  Sibcalls are
+     always limited at 240,000 bytes.
+
+     Distances are measured from the beginning of functions when using
+     the '-ffunction-sections' option, or when using the '-mgas' and
+     '-mno-portable-runtime' options together under HP-UX with the SOM
+     linker.
+
+     It is normally not desirable to use this option as it degrades
+     performance.  However, it may be useful in large applications,
+     particularly when partial linking is used to build the application.
+
+     The types of long calls used depends on the capabilities of the
+     assembler and linker, and the type of code being generated.  The
+     impact on systems that support long absolute calls, and long pic
+     symbol-difference or pc-relative calls should be relatively small.
+     However, an indirect call is used on 32-bit ELF systems in pic code
+     and it is quite long.
+
+'-munix=UNIX-STD'
+     Generate compiler predefines and select a startfile for the
+     specified UNIX standard.  The choices for UNIX-STD are '93', '95'
+     and '98'.  '93' is supported on all HP-UX versions.  '95' is
+     available on HP-UX 10.10 and later.  '98' is available on HP-UX
+     11.11 and later.  The default values are '93' for HP-UX 10.00, '95'
+     for HP-UX 10.10 though to 11.00, and '98' for HP-UX 11.11 and
+     later.
+
+     '-munix=93' provides the same predefines as GCC 3.3 and 3.4.
+     '-munix=95' provides additional predefines for 'XOPEN_UNIX' and
+     '_XOPEN_SOURCE_EXTENDED', and the startfile 'unix95.o'.
+     '-munix=98' provides additional predefines for '_XOPEN_UNIX',
+     '_XOPEN_SOURCE_EXTENDED', '_INCLUDE__STDC_A1_SOURCE' and
+     '_INCLUDE_XOPEN_SOURCE_500', and the startfile 'unix98.o'.
+
+     It is _important_ to note that this option changes the interfaces
+     for various library routines.  It also affects the operational
+     behavior of the C library.  Thus, _extreme_ care is needed in using
+     this option.
+
+     Library code that is intended to operate with more than one UNIX
+     standard must test, set and restore the variable
+     __XPG4_EXTENDED_MASK as appropriate.  Most GNU software doesn't
+     provide this capability.
+
+'-nolibdld'
+     Suppress the generation of link options to search libdld.sl when
+     the '-static' option is specified on HP-UX 10 and later.
+
+'-static'
+     The HP-UX implementation of setlocale in libc has a dependency on
+     libdld.sl.  There isn't an archive version of libdld.sl.  Thus,
+     when the '-static' option is specified, special link options are
+     needed to resolve this dependency.
+
+     On HP-UX 10 and later, the GCC driver adds the necessary options to
+     link with libdld.sl when the '-static' option is specified.  This
+     causes the resulting binary to be dynamic.  On the 64-bit port, the
+     linkers generate dynamic binaries by default in any case.  The
+     '-nolibdld' option can be used to prevent the GCC driver from
+     adding these link options.
+
+'-threads'
+     Add support for multithreading with the "dce thread" library under
+     HP-UX.  This option sets flags for both the preprocessor and
+     linker.
+
+
+File: gcc.info,  Node: i386 and x86-64 Options,  Next: i386 and x86-64 Windows Options,  Prev: HPPA Options,  Up: Submodel Options
+
+3.17.17 Intel 386 and AMD x86-64 Options
+----------------------------------------
+
+These '-m' options are defined for the i386 and x86-64 family of
+computers:
+
+'-march=CPU-TYPE'
+     Generate instructions for the machine type CPU-TYPE.  In contrast
+     to '-mtune=CPU-TYPE', which merely tunes the generated code for the
+     specified CPU-TYPE, '-march=CPU-TYPE' allows GCC to generate code
+     that may not run at all on processors other than the one indicated.
+     Specifying '-march=CPU-TYPE' implies '-mtune=CPU-TYPE'.
+
+     The choices for CPU-TYPE are:
+
+     'native'
+          This selects the CPU to generate code for at compilation time
+          by determining the processor type of the compiling machine.
+          Using '-march=native' enables all instruction subsets
+          supported by the local machine (hence the result might not run
+          on different machines).  Using '-mtune=native' produces code
+          optimized for the local machine under the constraints of the
+          selected instruction set.
+
+     'i386'
+          Original Intel i386 CPU.
+
+     'i486'
+          Intel i486 CPU.  (No scheduling is implemented for this chip.)
+
+     'i586'
+     'pentium'
+          Intel Pentium CPU with no MMX support.
+
+     'pentium-mmx'
+          Intel Pentium MMX CPU, based on Pentium core with MMX
+          instruction set support.
+
+     'pentiumpro'
+          Intel Pentium Pro CPU.
+
+     'i686'
+          When used with '-march', the Pentium Pro instruction set is
+          used, so the code runs on all i686 family chips.  When used
+          with '-mtune', it has the same meaning as 'generic'.
+
+     'pentium2'
+          Intel Pentium II CPU, based on Pentium Pro core with MMX
+          instruction set support.
+
+     'pentium3'
+     'pentium3m'
+          Intel Pentium III CPU, based on Pentium Pro core with MMX and
+          SSE instruction set support.
+
+     'pentium-m'
+          Intel Pentium M; low-power version of Intel Pentium III CPU
+          with MMX, SSE and SSE2 instruction set support.  Used by
+          Centrino notebooks.
+
+     'pentium4'
+     'pentium4m'
+          Intel Pentium 4 CPU with MMX, SSE and SSE2 instruction set
+          support.
+
+     'prescott'
+          Improved version of Intel Pentium 4 CPU with MMX, SSE, SSE2
+          and SSE3 instruction set support.
+
+     'nocona'
+          Improved version of Intel Pentium 4 CPU with 64-bit
+          extensions, MMX, SSE, SSE2 and SSE3 instruction set support.
+
+     'core2'
+          Intel Core 2 CPU with 64-bit extensions, MMX, SSE, SSE2, SSE3
+          and SSSE3 instruction set support.
+
+     'nehalem'
+          Intel Nehalem CPU with 64-bit extensions, MMX, SSE, SSE2,
+          SSE3, SSSE3, SSE4.1, SSE4.2 and POPCNT instruction set
+          support.
+
+     'westmere'
+          Intel Westmere CPU with 64-bit extensions, MMX, SSE, SSE2,
+          SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES and PCLMUL
+          instruction set support.
+
+     'sandybridge'
+          Intel Sandy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2,
+          SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AES and PCLMUL
+          instruction set support.
+
+     'ivybridge'
+          Intel Ivy Bridge CPU with 64-bit extensions, MMX, SSE, SSE2,
+          SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AES, PCLMUL,
+          FSGSBASE, RDRND and F16C instruction set support.
+
+     'haswell'
+          Intel Haswell CPU with 64-bit extensions, MOVBE, MMX, SSE,
+          SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES,
+          PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2 and F16C instruction
+          set support.
+
+     'broadwell'
+          Intel Broadwell CPU with 64-bit extensions, MOVBE, MMX, SSE,
+          SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AVX, AVX2, AES,
+          PCLMUL, FSGSBASE, RDRND, FMA, BMI, BMI2, F16C, RDSEED, ADCX
+          and PREFETCHW instruction set support.
+
+     'bonnell'
+          Intel Bonnell CPU with 64-bit extensions, MOVBE, MMX, SSE,
+          SSE2, SSE3 and SSSE3 instruction set support.
+
+     'silvermont'
+          Intel Silvermont CPU with 64-bit extensions, MOVBE, MMX, SSE,
+          SSE2, SSE3, SSSE3, SSE4.1, SSE4.2, POPCNT, AES, PCLMUL and
+          RDRND instruction set support.
+
+     'k6'
+          AMD K6 CPU with MMX instruction set support.
+
+     'k6-2'
+     'k6-3'
+          Improved versions of AMD K6 CPU with MMX and 3DNow!
+          instruction set support.
+
+     'athlon'
+     'athlon-tbird'
+          AMD Athlon CPU with MMX, 3dNOW!, enhanced 3DNow! and SSE
+          prefetch instructions support.
+
+     'athlon-4'
+     'athlon-xp'
+     'athlon-mp'
+          Improved AMD Athlon CPU with MMX, 3DNow!, enhanced 3DNow! and
+          full SSE instruction set support.
+
+     'k8'
+     'opteron'
+     'athlon64'
+     'athlon-fx'
+          Processors based on the AMD K8 core with x86-64 instruction
+          set support, including the AMD Opteron, Athlon 64, and Athlon
+          64 FX processors.  (This supersets MMX, SSE, SSE2, 3DNow!,
+          enhanced 3DNow! and 64-bit instruction set extensions.)
+
+     'k8-sse3'
+     'opteron-sse3'
+     'athlon64-sse3'
+          Improved versions of AMD K8 cores with SSE3 instruction set
+          support.
+
+     'amdfam10'
+     'barcelona'
+          CPUs based on AMD Family 10h cores with x86-64 instruction set
+          support.  (This supersets MMX, SSE, SSE2, SSE3, SSE4A, 3DNow!,
+          enhanced 3DNow!, ABM and 64-bit instruction set extensions.)
+
+     'bdver1'
+          CPUs based on AMD Family 15h cores with x86-64 instruction set
+          support.  (This supersets FMA4, AVX, XOP, LWP, AES, PCL_MUL,
+          CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM
+          and 64-bit instruction set extensions.)
+     'bdver2'
+          AMD Family 15h core based CPUs with x86-64 instruction set
+          support.  (This supersets BMI, TBM, F16C, FMA, FMA4, AVX, XOP,
+          LWP, AES, PCL_MUL, CX16, MMX, SSE, SSE2, SSE3, SSE4A, SSSE3,
+          SSE4.1, SSE4.2, ABM and 64-bit instruction set extensions.)
+     'bdver3'
+          AMD Family 15h core based CPUs with x86-64 instruction set
+          support.  (This supersets BMI, TBM, F16C, FMA, FMA4, FSGSBASE,
+          AVX, XOP, LWP, AES, PCL_MUL, CX16, MMX, SSE, SSE2, SSE3,
+          SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit instruction set
+          extensions.
+     'bdver4'
+          AMD Family 15h core based CPUs with x86-64 instruction set
+          support.  (This supersets BMI, BMI2, TBM, F16C, FMA, FMA4,
+          FSGSBASE, AVX, AVX2, XOP, LWP, AES, PCL_MUL, CX16, MOVBE, MMX,
+          SSE, SSE2, SSE3, SSE4A, SSSE3, SSE4.1, SSE4.2, ABM and 64-bit
+          instruction set extensions.
+
+     'btver1'
+          CPUs based on AMD Family 14h cores with x86-64 instruction set
+          support.  (This supersets MMX, SSE, SSE2, SSE3, SSSE3, SSE4A,
+          CX16, ABM and 64-bit instruction set extensions.)
+
+     'btver2'
+          CPUs based on AMD Family 16h cores with x86-64 instruction set
+          support.  This includes MOVBE, F16C, BMI, AVX, PCL_MUL, AES,
+          SSE4.2, SSE4.1, CX16, ABM, SSE4A, SSSE3, SSE3, SSE2, SSE, MMX
+          and 64-bit instruction set extensions.
+
+     'winchip-c6'
+          IDT WinChip C6 CPU, dealt in same way as i486 with additional
+          MMX instruction set support.
+
+     'winchip2'
+          IDT WinChip 2 CPU, dealt in same way as i486 with additional
+          MMX and 3DNow! instruction set support.
+
+     'c3'
+          VIA C3 CPU with MMX and 3DNow! instruction set support.  (No
+          scheduling is implemented for this chip.)
+
+     'c3-2'
+          VIA C3-2 (Nehemiah/C5XL) CPU with MMX and SSE instruction set
+          support.  (No scheduling is implemented for this chip.)
+
+     'geode'
+          AMD Geode embedded processor with MMX and 3DNow! instruction
+          set support.
+
+'-mtune=CPU-TYPE'
+     Tune to CPU-TYPE everything applicable about the generated code,
+     except for the ABI and the set of available instructions.  While
+     picking a specific CPU-TYPE schedules things appropriately for that
+     particular chip, the compiler does not generate any code that
+     cannot run on the default machine type unless you use a
+     '-march=CPU-TYPE' option.  For example, if GCC is configured for
+     i686-pc-linux-gnu then '-mtune=pentium4' generates code that is
+     tuned for Pentium 4 but still runs on i686 machines.
+
+     The choices for CPU-TYPE are the same as for '-march'.  In
+     addition, '-mtune' supports 2 extra choices for CPU-TYPE:
+
+     'generic'
+          Produce code optimized for the most common IA32/AMD64/EM64T
+          processors.  If you know the CPU on which your code will run,
+          then you should use the corresponding '-mtune' or '-march'
+          option instead of '-mtune=generic'.  But, if you do not know
+          exactly what CPU users of your application will have, then you
+          should use this option.
+
+          As new processors are deployed in the marketplace, the
+          behavior of this option will change.  Therefore, if you
+          upgrade to a newer version of GCC, code generation controlled
+          by this option will change to reflect the processors that are
+          most common at the time that version of GCC is released.
+
+          There is no '-march=generic' option because '-march' indicates
+          the instruction set the compiler can use, and there is no
+          generic instruction set applicable to all processors.  In
+          contrast, '-mtune' indicates the processor (or, in this case,
+          collection of processors) for which the code is optimized.
+
+     'intel'
+          Produce code optimized for the most current Intel processors,
+          which are Haswell and Silvermont for this version of GCC. If
+          you know the CPU on which your code will run, then you should
+          use the corresponding '-mtune' or '-march' option instead of
+          '-mtune=intel'.  But, if you want your application performs
+          better on both Haswell and Silvermont, then you should use
+          this option.
+
+          As new Intel processors are deployed in the marketplace, the
+          behavior of this option will change.  Therefore, if you
+          upgrade to a newer version of GCC, code generation controlled
+          by this option will change to reflect the most current Intel
+          processors at the time that version of GCC is released.
+
+          There is no '-march=intel' option because '-march' indicates
+          the instruction set the compiler can use, and there is no
+          common instruction set applicable to all processors.  In
+          contrast, '-mtune' indicates the processor (or, in this case,
+          collection of processors) for which the code is optimized.
+
+'-mcpu=CPU-TYPE'
+     A deprecated synonym for '-mtune'.
+
+'-mfpmath=UNIT'
+     Generate floating-point arithmetic for selected unit UNIT.  The
+     choices for UNIT are:
+
+     '387'
+          Use the standard 387 floating-point coprocessor present on the
+          majority of chips and emulated otherwise.  Code compiled with
+          this option runs almost everywhere.  The temporary results are
+          computed in 80-bit precision instead of the precision
+          specified by the type, resulting in slightly different results
+          compared to most of other chips.  See '-ffloat-store' for more
+          detailed description.
+
+          This is the default choice for i386 compiler.
+
+     'sse'
+          Use scalar floating-point instructions present in the SSE
+          instruction set.  This instruction set is supported by Pentium
+          III and newer chips, and in the AMD line by Athlon-4, Athlon
+          XP and Athlon MP chips.  The earlier version of the SSE
+          instruction set supports only single-precision arithmetic,
+          thus the double and extended-precision arithmetic are still
+          done using 387.  A later version, present only in Pentium 4
+          and AMD x86-64 chips, supports double-precision arithmetic
+          too.
+
+          For the i386 compiler, you must use '-march=CPU-TYPE', '-msse'
+          or '-msse2' switches to enable SSE extensions and make this
+          option effective.  For the x86-64 compiler, these extensions
+          are enabled by default.
+
+          The resulting code should be considerably faster in the
+          majority of cases and avoid the numerical instability problems
+          of 387 code, but may break some existing code that expects
+          temporaries to be 80 bits.
+
+          This is the default choice for the x86-64 compiler.
+
+     'sse,387'
+     'sse+387'
+     'both'
+          Attempt to utilize both instruction sets at once.  This
+          effectively doubles the amount of available registers, and on
+          chips with separate execution units for 387 and SSE the
+          execution resources too.  Use this option with care, as it is
+          still experimental, because the GCC register allocator does
+          not model separate functional units well, resulting in
+          unstable performance.
+
+'-masm=DIALECT'
+     Output assembly instructions using selected DIALECT.  Supported
+     choices are 'intel' or 'att' (the default).  Darwin does not
+     support 'intel'.
+
+'-mieee-fp'
+'-mno-ieee-fp'
+     Control whether or not the compiler uses IEEE floating-point
+     comparisons.  These correctly handle the case where the result of a
+     comparison is unordered.
+
+'-msoft-float'
+     Generate output containing library calls for floating point.
+
+     *Warning:* the requisite libraries are not part of GCC.  Normally
+     the facilities of the machine's usual C compiler are used, but this
+     can't be done directly in cross-compilation.  You must make your
+     own arrangements to provide suitable library functions for
+     cross-compilation.
+
+     On machines where a function returns floating-point results in the
+     80387 register stack, some floating-point opcodes may be emitted
+     even if '-msoft-float' is used.
+
+'-mno-fp-ret-in-387'
+     Do not use the FPU registers for return values of functions.
+
+     The usual calling convention has functions return values of types
+     'float' and 'double' in an FPU register, even if there is no FPU.
+     The idea is that the operating system should emulate an FPU.
+
+     The option '-mno-fp-ret-in-387' causes such values to be returned
+     in ordinary CPU registers instead.
+
+'-mno-fancy-math-387'
+     Some 387 emulators do not support the 'sin', 'cos' and 'sqrt'
+     instructions for the 387.  Specify this option to avoid generating
+     those instructions.  This option is the default on FreeBSD, OpenBSD
+     and NetBSD.  This option is overridden when '-march' indicates that
+     the target CPU always has an FPU and so the instruction does not
+     need emulation.  These instructions are not generated unless you
+     also use the '-funsafe-math-optimizations' switch.
+
+'-malign-double'
+'-mno-align-double'
+     Control whether GCC aligns 'double', 'long double', and 'long long'
+     variables on a two-word boundary or a one-word boundary.  Aligning
+     'double' variables on a two-word boundary produces code that runs
+     somewhat faster on a Pentium at the expense of more memory.
+
+     On x86-64, '-malign-double' is enabled by default.
+
+     *Warning:* if you use the '-malign-double' switch, structures
+     containing the above types are aligned differently than the
+     published application binary interface specifications for the 386
+     and are not binary compatible with structures in code compiled
+     without that switch.
+
+'-m96bit-long-double'
+'-m128bit-long-double'
+     These switches control the size of 'long double' type.  The i386
+     application binary interface specifies the size to be 96 bits, so
+     '-m96bit-long-double' is the default in 32-bit mode.
+
+     Modern architectures (Pentium and newer) prefer 'long double' to be
+     aligned to an 8- or 16-byte boundary.  In arrays or structures
+     conforming to the ABI, this is not possible.  So specifying
+     '-m128bit-long-double' aligns 'long double' to a 16-byte boundary
+     by padding the 'long double' with an additional 32-bit zero.
+
+     In the x86-64 compiler, '-m128bit-long-double' is the default
+     choice as its ABI specifies that 'long double' is aligned on
+     16-byte boundary.
+
+     Notice that neither of these options enable any extra precision
+     over the x87 standard of 80 bits for a 'long double'.
+
+     *Warning:* if you override the default value for your target ABI,
+     this changes the size of structures and arrays containing 'long
+     double' variables, as well as modifying the function calling
+     convention for functions taking 'long double'.  Hence they are not
+     binary-compatible with code compiled without that switch.
+
+'-mlong-double-64'
+'-mlong-double-80'
+'-mlong-double-128'
+     These switches control the size of 'long double' type.  A size of
+     64 bits makes the 'long double' type equivalent to the 'double'
+     type.  This is the default for 32-bit Bionic C library.  A size of
+     128 bits makes the 'long double' type equivalent to the
+     '__float128' type.  This is the default for 64-bit Bionic C
+     library.
+
+     *Warning:* if you override the default value for your target ABI,
+     this changes the size of structures and arrays containing 'long
+     double' variables, as well as modifying the function calling
+     convention for functions taking 'long double'.  Hence they are not
+     binary-compatible with code compiled without that switch.
+
+'-mlarge-data-threshold=THRESHOLD'
+     When '-mcmodel=medium' is specified, data objects larger than
+     THRESHOLD are placed in the large data section.  This value must be
+     the same across all objects linked into the binary, and defaults to
+     65535.
+
+'-mrtd'
+     Use a different function-calling convention, in which functions
+     that take a fixed number of arguments return with the 'ret NUM'
+     instruction, which pops their arguments while returning.  This
+     saves one instruction in the caller since there is no need to pop
+     the arguments there.
+
+     You can specify that an individual function is called with this
+     calling sequence with the function attribute 'stdcall'.  You can
+     also override the '-mrtd' option by using the function attribute
+     'cdecl'.  *Note Function Attributes::.
+
+     *Warning:* this calling convention is incompatible with the one
+     normally used on Unix, so you cannot use it if you need to call
+     libraries compiled with the Unix compiler.
+
+     Also, you must provide function prototypes for all functions that
+     take variable numbers of arguments (including 'printf'); otherwise
+     incorrect code is generated for calls to those functions.
+
+     In addition, seriously incorrect code results if you call a
+     function with too many arguments.  (Normally, extra arguments are
+     harmlessly ignored.)
+
+'-mregparm=NUM'
+     Control how many registers are used to pass integer arguments.  By
+     default, no registers are used to pass arguments, and at most 3
+     registers can be used.  You can control this behavior for a
+     specific function by using the function attribute 'regparm'.  *Note
+     Function Attributes::.
+
+     *Warning:* if you use this switch, and NUM is nonzero, then you
+     must build all modules with the same value, including any
+     libraries.  This includes the system libraries and startup modules.
+
+'-msseregparm'
+     Use SSE register passing conventions for float and double arguments
+     and return values.  You can control this behavior for a specific
+     function by using the function attribute 'sseregparm'.  *Note
+     Function Attributes::.
+
+     *Warning:* if you use this switch then you must build all modules
+     with the same value, including any libraries.  This includes the
+     system libraries and startup modules.
+
+'-mvect8-ret-in-mem'
+     Return 8-byte vectors in memory instead of MMX registers.  This is
+     the default on Solaris 8 and 9 and VxWorks to match the ABI of the
+     Sun Studio compilers until version 12.  Later compiler versions
+     (starting with Studio 12 Update 1) follow the ABI used by other x86
+     targets, which is the default on Solaris 10 and later.  _Only_ use
+     this option if you need to remain compatible with existing code
+     produced by those previous compiler versions or older versions of
+     GCC.
+
+'-mpc32'
+'-mpc64'
+'-mpc80'
+
+     Set 80387 floating-point precision to 32, 64 or 80 bits.  When
+     '-mpc32' is specified, the significands of results of
+     floating-point operations are rounded to 24 bits (single
+     precision); '-mpc64' rounds the significands of results of
+     floating-point operations to 53 bits (double precision) and
+     '-mpc80' rounds the significands of results of floating-point
+     operations to 64 bits (extended double precision), which is the
+     default.  When this option is used, floating-point operations in
+     higher precisions are not available to the programmer without
+     setting the FPU control word explicitly.
+
+     Setting the rounding of floating-point operations to less than the
+     default 80 bits can speed some programs by 2% or more.  Note that
+     some mathematical libraries assume that extended-precision (80-bit)
+     floating-point operations are enabled by default; routines in such
+     libraries could suffer significant loss of accuracy, typically
+     through so-called "catastrophic cancellation", when this option is
+     used to set the precision to less than extended precision.
+
+'-mstackrealign'
+     Realign the stack at entry.  On the Intel x86, the '-mstackrealign'
+     option generates an alternate prologue and epilogue that realigns
+     the run-time stack if necessary.  This supports mixing legacy codes
+     that keep 4-byte stack alignment with modern codes that keep
+     16-byte stack alignment for SSE compatibility.  See also the
+     attribute 'force_align_arg_pointer', applicable to individual
+     functions.
+
+'-mpreferred-stack-boundary=NUM'
+     Attempt to keep the stack boundary aligned to a 2 raised to NUM
+     byte boundary.  If '-mpreferred-stack-boundary' is not specified,
+     the default is 4 (16 bytes or 128 bits).
+
+     *Warning:* When generating code for the x86-64 architecture with
+     SSE extensions disabled, '-mpreferred-stack-boundary=3' can be used
+     to keep the stack boundary aligned to 8 byte boundary.  Since
+     x86-64 ABI require 16 byte stack alignment, this is ABI
+     incompatible and intended to be used in controlled environment
+     where stack space is important limitation.  This option will lead
+     to wrong code when functions compiled with 16 byte stack alignment
+     (such as functions from a standard library) are called with
+     misaligned stack.  In this case, SSE instructions may lead to
+     misaligned memory access traps.  In addition, variable arguments
+     will be handled incorrectly for 16 byte aligned objects (including
+     x87 long double and __int128), leading to wrong results.  You must
+     build all modules with '-mpreferred-stack-boundary=3', including
+     any libraries.  This includes the system libraries and startup
+     modules.
+
+'-mincoming-stack-boundary=NUM'
+     Assume the incoming stack is aligned to a 2 raised to NUM byte
+     boundary.  If '-mincoming-stack-boundary' is not specified, the one
+     specified by '-mpreferred-stack-boundary' is used.
+
+     On Pentium and Pentium Pro, 'double' and 'long double' values
+     should be aligned to an 8-byte boundary (see '-malign-double') or
+     suffer significant run time performance penalties.  On Pentium III,
+     the Streaming SIMD Extension (SSE) data type '__m128' may not work
+     properly if it is not 16-byte aligned.
+
+     To ensure proper alignment of this values on the stack, the stack
+     boundary must be as aligned as that required by any value stored on
+     the stack.  Further, every function must be generated such that it
+     keeps the stack aligned.  Thus calling a function compiled with a
+     higher preferred stack boundary from a function compiled with a
+     lower preferred stack boundary most likely misaligns the stack.  It
+     is recommended that libraries that use callbacks always use the
+     default setting.
+
+     This extra alignment does consume extra stack space, and generally
+     increases code size.  Code that is sensitive to stack space usage,
+     such as embedded systems and operating system kernels, may want to
+     reduce the preferred alignment to '-mpreferred-stack-boundary=2'.
+
+'-mmmx'
+'-mno-mmx'
+'-msse'
+'-mno-sse'
+'-msse2'
+'-mno-sse2'
+'-msse3'
+'-mno-sse3'
+'-mssse3'
+'-mno-ssse3'
+'-msse4.1'
+'-mno-sse4.1'
+'-msse4.2'
+'-mno-sse4.2'
+'-msse4'
+'-mno-sse4'
+'-mavx'
+'-mno-avx'
+'-mavx2'
+'-mno-avx2'
+'-mavx512f'
+'-mno-avx512f'
+'-mavx512pf'
+'-mno-avx512pf'
+'-mavx512er'
+'-mno-avx512er'
+'-mavx512cd'
+'-mno-avx512cd'
+'-msha'
+'-mno-sha'
+'-maes'
+'-mno-aes'
+'-mpclmul'
+'-mno-pclmul'
+'-mfsgsbase'
+'-mno-fsgsbase'
+'-mrdrnd'
+'-mno-rdrnd'
+'-mf16c'
+'-mno-f16c'
+'-mfma'
+'-mno-fma'
+'-mprefetchwt1'
+'-mno-prefetchwt1'
+'-msse4a'
+'-mno-sse4a'
+'-mfma4'
+'-mno-fma4'
+'-mxop'
+'-mno-xop'
+'-mlwp'
+'-mno-lwp'
+'-m3dnow'
+'-mno-3dnow'
+'-mpopcnt'
+'-mno-popcnt'
+'-mabm'
+'-mno-abm'
+'-mbmi'
+'-mbmi2'
+'-mno-bmi'
+'-mno-bmi2'
+'-mlzcnt'
+'-mno-lzcnt'
+'-mfxsr'
+'-mxsave'
+'-mxsaveopt'
+'-mrtm'
+'-mtbm'
+'-mno-tbm'
+     These switches enable or disable the use of instructions in the
+     MMX, SSE, SSE2, SSE3, SSSE3, SSE4.1, AVX, AVX2, AVX512F, AVX512PF,
+     AVX512ER, AVX512CD, SHA, AES, PCLMUL, FSGSBASE, RDRND, F16C, FMA,
+     SSE4A, FMA4, XOP, LWP, ABM, BMI, BMI2, FXSR, XSAVE, XSAVEOPT,
+     LZCNT, RTM, or 3DNow! extended instruction sets.  These extensions
+     are also available as built-in functions: see *note X86 Built-in
+     Functions::, for details of the functions enabled and disabled by
+     these switches.
+
+     To generate SSE/SSE2 instructions automatically from floating-point
+     code (as opposed to 387 instructions), see '-mfpmath=sse'.
+
+     GCC depresses SSEx instructions when '-mavx' is used.  Instead, it
+     generates new AVX instructions or AVX equivalence for all SSEx
+     instructions when needed.
+
+     These options enable GCC to use these extended instructions in
+     generated code, even without '-mfpmath=sse'.  Applications that
+     perform run-time CPU detection must compile separate files for each
+     supported architecture, using the appropriate flags.  In
+     particular, the file containing the CPU detection code should be
+     compiled without these options.
+
+'-mdump-tune-features'
+     This option instructs GCC to dump the names of the x86 performance
+     tuning features and default settings.  The names can be used in
+     '-mtune-ctrl=FEATURE-LIST'.
+
+'-mtune-ctrl=FEATURE-LIST'
+     This option is used to do fine grain control of x86 code generation
+     features.  FEATURE-LIST is a comma separated list of FEATURE names.
+     See also '-mdump-tune-features'.  When specified, the FEATURE will
+     be turned on if it is not preceded with '^', otherwise, it will be
+     turned off.  '-mtune-ctrl=FEATURE-LIST' is intended to be used by
+     GCC developers.  Using it may lead to code paths not covered by
+     testing and can potentially result in compiler ICEs or runtime
+     errors.
+
+'-mno-default'
+     This option instructs GCC to turn off all tunable features.  See
+     also '-mtune-ctrl=FEATURE-LIST' and '-mdump-tune-features'.
+
+'-mcld'
+     This option instructs GCC to emit a 'cld' instruction in the
+     prologue of functions that use string instructions.  String
+     instructions depend on the DF flag to select between autoincrement
+     or autodecrement mode.  While the ABI specifies the DF flag to be
+     cleared on function entry, some operating systems violate this
+     specification by not clearing the DF flag in their exception
+     dispatchers.  The exception handler can be invoked with the DF flag
+     set, which leads to wrong direction mode when string instructions
+     are used.  This option can be enabled by default on 32-bit x86
+     targets by configuring GCC with the '--enable-cld' configure
+     option.  Generation of 'cld' instructions can be suppressed with
+     the '-mno-cld' compiler option in this case.
+
+'-mvzeroupper'
+     This option instructs GCC to emit a 'vzeroupper' instruction before
+     a transfer of control flow out of the function to minimize the AVX
+     to SSE transition penalty as well as remove unnecessary 'zeroupper'
+     intrinsics.
+
+'-mprefer-avx128'
+     This option instructs GCC to use 128-bit AVX instructions instead
+     of 256-bit AVX instructions in the auto-vectorizer.
+
+'-mcx16'
+     This option enables GCC to generate 'CMPXCHG16B' instructions.
+     'CMPXCHG16B' allows for atomic operations on 128-bit double
+     quadword (or oword) data types.  This is useful for high-resolution
+     counters that can be updated by multiple processors (or cores).
+     This instruction is generated as part of atomic built-in functions:
+     see *note __sync Builtins:: or *note __atomic Builtins:: for
+     details.
+
+'-msahf'
+     This option enables generation of 'SAHF' instructions in 64-bit
+     code.  Early Intel Pentium 4 CPUs with Intel 64 support, prior to
+     the introduction of Pentium 4 G1 step in December 2005, lacked the
+     'LAHF' and 'SAHF' instructions which were supported by AMD64.
+     These are load and store instructions, respectively, for certain
+     status flags.  In 64-bit mode, the 'SAHF' instruction is used to
+     optimize 'fmod', 'drem', and 'remainder' built-in functions; see
+     *note Other Builtins:: for details.
+
+'-mmovbe'
+     This option enables use of the 'movbe' instruction to implement
+     '__builtin_bswap32' and '__builtin_bswap64'.
+
+'-mcrc32'
+     This option enables built-in functions '__builtin_ia32_crc32qi',
+     '__builtin_ia32_crc32hi', '__builtin_ia32_crc32si' and
+     '__builtin_ia32_crc32di' to generate the 'crc32' machine
+     instruction.
+
+'-mrecip'
+     This option enables use of 'RCPSS' and 'RSQRTSS' instructions (and
+     their vectorized variants 'RCPPS' and 'RSQRTPS') with an additional
+     Newton-Raphson step to increase precision instead of 'DIVSS' and
+     'SQRTSS' (and their vectorized variants) for single-precision
+     floating-point arguments.  These instructions are generated only
+     when '-funsafe-math-optimizations' is enabled together with
+     '-finite-math-only' and '-fno-trapping-math'.  Note that while the
+     throughput of the sequence is higher than the throughput of the
+     non-reciprocal instruction, the precision of the sequence can be
+     decreased by up to 2 ulp (i.e.  the inverse of 1.0 equals
+     0.99999994).
+
+     Note that GCC implements '1.0f/sqrtf(X)' in terms of 'RSQRTSS' (or
+     'RSQRTPS') already with '-ffast-math' (or the above option
+     combination), and doesn't need '-mrecip'.
+
+     Also note that GCC emits the above sequence with additional
+     Newton-Raphson step for vectorized single-float division and
+     vectorized 'sqrtf(X)' already with '-ffast-math' (or the above
+     option combination), and doesn't need '-mrecip'.
+
+'-mrecip=OPT'
+     This option controls which reciprocal estimate instructions may be
+     used.  OPT is a comma-separated list of options, which may be
+     preceded by a '!' to invert the option:
+
+     'all'
+          Enable all estimate instructions.
+
+     'default'
+          Enable the default instructions, equivalent to '-mrecip'.
+
+     'none'
+          Disable all estimate instructions, equivalent to '-mno-recip'.
+
+     'div'
+          Enable the approximation for scalar division.
+
+     'vec-div'
+          Enable the approximation for vectorized division.
+
+     'sqrt'
+          Enable the approximation for scalar square root.
+
+     'vec-sqrt'
+          Enable the approximation for vectorized square root.
+
+     So, for example, '-mrecip=all,!sqrt' enables all of the reciprocal
+     approximations, except for square root.
+
+'-mveclibabi=TYPE'
+     Specifies the ABI type to use for vectorizing intrinsics using an
+     external library.  Supported values for TYPE are 'svml' for the
+     Intel short vector math library and 'acml' for the AMD math core
+     library.  To use this option, both '-ftree-vectorize' and
+     '-funsafe-math-optimizations' have to be enabled, and an SVML or
+     ACML ABI-compatible library must be specified at link time.
+
+     GCC currently emits calls to 'vmldExp2', 'vmldLn2', 'vmldLog102',
+     'vmldLog102', 'vmldPow2', 'vmldTanh2', 'vmldTan2', 'vmldAtan2',
+     'vmldAtanh2', 'vmldCbrt2', 'vmldSinh2', 'vmldSin2', 'vmldAsinh2',
+     'vmldAsin2', 'vmldCosh2', 'vmldCos2', 'vmldAcosh2', 'vmldAcos2',
+     'vmlsExp4', 'vmlsLn4', 'vmlsLog104', 'vmlsLog104', 'vmlsPow4',
+     'vmlsTanh4', 'vmlsTan4', 'vmlsAtan4', 'vmlsAtanh4', 'vmlsCbrt4',
+     'vmlsSinh4', 'vmlsSin4', 'vmlsAsinh4', 'vmlsAsin4', 'vmlsCosh4',
+     'vmlsCos4', 'vmlsAcosh4' and 'vmlsAcos4' for corresponding function
+     type when '-mveclibabi=svml' is used, and '__vrd2_sin',
+     '__vrd2_cos', '__vrd2_exp', '__vrd2_log', '__vrd2_log2',
+     '__vrd2_log10', '__vrs4_sinf', '__vrs4_cosf', '__vrs4_expf',
+     '__vrs4_logf', '__vrs4_log2f', '__vrs4_log10f' and '__vrs4_powf'
+     for the corresponding function type when '-mveclibabi=acml' is
+     used.
+
+'-mabi=NAME'
+     Generate code for the specified calling convention.  Permissible
+     values are 'sysv' for the ABI used on GNU/Linux and other systems,
+     and 'ms' for the Microsoft ABI. The default is to use the Microsoft
+     ABI when targeting Microsoft Windows and the SysV ABI on all other
+     systems.  You can control this behavior for a specific function by
+     using the function attribute 'ms_abi'/'sysv_abi'.  *Note Function
+     Attributes::.
+
+'-mtls-dialect=TYPE'
+     Generate code to access thread-local storage using the 'gnu' or
+     'gnu2' conventions.  'gnu' is the conservative default; 'gnu2' is
+     more efficient, but it may add compile- and run-time requirements
+     that cannot be satisfied on all systems.
+
+'-mpush-args'
+'-mno-push-args'
+     Use PUSH operations to store outgoing parameters.  This method is
+     shorter and usually equally fast as method using SUB/MOV operations
+     and is enabled by default.  In some cases disabling it may improve
+     performance because of improved scheduling and reduced
+     dependencies.
+
+'-maccumulate-outgoing-args'
+     If enabled, the maximum amount of space required for outgoing
+     arguments is computed in the function prologue.  This is faster on
+     most modern CPUs because of reduced dependencies, improved
+     scheduling and reduced stack usage when the preferred stack
+     boundary is not equal to 2.  The drawback is a notable increase in
+     code size.  This switch implies '-mno-push-args'.
+
+'-mthreads'
+     Support thread-safe exception handling on MinGW. Programs that rely
+     on thread-safe exception handling must compile and link all code
+     with the '-mthreads' option.  When compiling, '-mthreads' defines
+     '-D_MT'; when linking, it links in a special thread helper library
+     '-lmingwthrd' which cleans up per-thread exception-handling data.
+
+'-mno-align-stringops'
+     Do not align the destination of inlined string operations.  This
+     switch reduces code size and improves performance in case the
+     destination is already aligned, but GCC doesn't know about it.
+
+'-minline-all-stringops'
+     By default GCC inlines string operations only when the destination
+     is known to be aligned to least a 4-byte boundary.  This enables
+     more inlining and increases code size, but may improve performance
+     of code that depends on fast 'memcpy', 'strlen', and 'memset' for
+     short lengths.
+
+'-minline-stringops-dynamically'
+     For string operations of unknown size, use run-time checks with
+     inline code for small blocks and a library call for large blocks.
+
+'-mstringop-strategy=ALG'
+     Override the internal decision heuristic for the particular
+     algorithm to use for inlining string operations.  The allowed
+     values for ALG are:
+
+     'rep_byte'
+     'rep_4byte'
+     'rep_8byte'
+          Expand using i386 'rep' prefix of the specified size.
+
+     'byte_loop'
+     'loop'
+     'unrolled_loop'
+          Expand into an inline loop.
+
+     'libcall'
+          Always use a library call.
+
+'-mmemcpy-strategy=STRATEGY'
+     Override the internal decision heuristic to decide if
+     '__builtin_memcpy' should be inlined and what inline algorithm to
+     use when the expected size of the copy operation is known.
+     STRATEGY is a comma-separated list of ALG:MAX_SIZE:DEST_ALIGN
+     triplets.  ALG is specified in '-mstringop-strategy', MAX_SIZE
+     specifies the max byte size with which inline algorithm ALG is
+     allowed.  For the last triplet, the MAX_SIZE must be '-1'.  The
+     MAX_SIZE of the triplets in the list must be specified in
+     increasing order.  The minimal byte size for ALG is '0' for the
+     first triplet and 'MAX_SIZE + 1' of the preceding range.
+
+'-mmemset-strategy=STRATEGY'
+     The option is similar to '-mmemcpy-strategy=' except that it is to
+     control '__builtin_memset' expansion.
+
+'-momit-leaf-frame-pointer'
+     Don't keep the frame pointer in a register for leaf functions.
+     This avoids the instructions to save, set up, and restore frame
+     pointers and makes an extra register available in leaf functions.
+     The option '-fomit-leaf-frame-pointer' removes the frame pointer
+     for leaf functions, which might make debugging harder.
+
+'-mtls-direct-seg-refs'
+'-mno-tls-direct-seg-refs'
+     Controls whether TLS variables may be accessed with offsets from
+     the TLS segment register ('%gs' for 32-bit, '%fs' for 64-bit), or
+     whether the thread base pointer must be added.  Whether or not this
+     is valid depends on the operating system, and whether it maps the
+     segment to cover the entire TLS area.
+
+     For systems that use the GNU C Library, the default is on.
+
+'-msse2avx'
+'-mno-sse2avx'
+     Specify that the assembler should encode SSE instructions with VEX
+     prefix.  The option '-mavx' turns this on by default.
+
+'-mfentry'
+'-mno-fentry'
+     If profiling is active ('-pg'), put the profiling counter call
+     before the prologue.  Note: On x86 architectures the attribute
+     'ms_hook_prologue' isn't possible at the moment for '-mfentry' and
+     '-pg'.
+
+'-m8bit-idiv'
+'-mno-8bit-idiv'
+     On some processors, like Intel Atom, 8-bit unsigned integer divide
+     is much faster than 32-bit/64-bit integer divide.  This option
+     generates a run-time check.  If both dividend and divisor are
+     within range of 0 to 255, 8-bit unsigned integer divide is used
+     instead of 32-bit/64-bit integer divide.
+
+'-mavx256-split-unaligned-load'
+'-mavx256-split-unaligned-store'
+     Split 32-byte AVX unaligned load and store.
+
+'-mstack-protector-guard=GUARD'
+     Generate stack protection code using canary at GUARD.  Supported
+     locations are 'global' for global canary or 'tls' for per-thread
+     canary in the TLS block (the default).  This option has effect only
+     when '-fstack-protector' or '-fstack-protector-all' is specified.
+
+ These '-m' switches are supported in addition to the above on x86-64
+processors in 64-bit environments.
+
+'-m32'
+'-m64'
+'-mx32'
+'-m16'
+     Generate code for a 16-bit, 32-bit or 64-bit environment.  The
+     '-m32' option sets 'int', 'long', and pointer types to 32 bits, and
+     generates code that runs on any i386 system.
+
+     The '-m64' option sets 'int' to 32 bits and 'long' and pointer
+     types to 64 bits, and generates code for the x86-64 architecture.
+     For Darwin only the '-m64' option also turns off the '-fno-pic' and
+     '-mdynamic-no-pic' options.
+
+     The '-mx32' option sets 'int', 'long', and pointer types to 32
+     bits, and generates code for the x86-64 architecture.
+
+     The '-m16' option is the same as '-m32', except for that it outputs
+     the '.code16gcc' assembly directive at the beginning of the
+     assembly output so that the binary can run in 16-bit mode.
+
+'-mno-red-zone'
+     Do not use a so-called "red zone" for x86-64 code.  The red zone is
+     mandated by the x86-64 ABI; it is a 128-byte area beyond the
+     location of the stack pointer that is not modified by signal or
+     interrupt handlers and therefore can be used for temporary data
+     without adjusting the stack pointer.  The flag '-mno-red-zone'
+     disables this red zone.
+
+'-mcmodel=small'
+     Generate code for the small code model: the program and its symbols
+     must be linked in the lower 2 GB of the address space.  Pointers
+     are 64 bits.  Programs can be statically or dynamically linked.
+     This is the default code model.
+
+'-mcmodel=kernel'
+     Generate code for the kernel code model.  The kernel runs in the
+     negative 2 GB of the address space.  This model has to be used for
+     Linux kernel code.
+
+'-mcmodel=medium'
+     Generate code for the medium model: the program is linked in the
+     lower 2 GB of the address space.  Small symbols are also placed
+     there.  Symbols with sizes larger than '-mlarge-data-threshold' are
+     put into large data or BSS sections and can be located above 2GB.
+     Programs can be statically or dynamically linked.
+
+'-mcmodel=large'
+     Generate code for the large model.  This model makes no assumptions
+     about addresses and sizes of sections.
+
+'-maddress-mode=long'
+     Generate code for long address mode.  This is only supported for
+     64-bit and x32 environments.  It is the default address mode for
+     64-bit environments.
+
+'-maddress-mode=short'
+     Generate code for short address mode.  This is only supported for
+     32-bit and x32 environments.  It is the default address mode for
+     32-bit and x32 environments.
+
+
+File: gcc.info,  Node: i386 and x86-64 Windows Options,  Next: IA-64 Options,  Prev: i386 and x86-64 Options,  Up: Submodel Options
+
+3.17.18 i386 and x86-64 Windows Options
+---------------------------------------
+
+These additional options are available for Microsoft Windows targets:
+
+'-mconsole'
+     This option specifies that a console application is to be
+     generated, by instructing the linker to set the PE header subsystem
+     type required for console applications.  This option is available
+     for Cygwin and MinGW targets and is enabled by default on those
+     targets.
+
+'-mdll'
+     This option is available for Cygwin and MinGW targets.  It
+     specifies that a DLL--a dynamic link library--is to be generated,
+     enabling the selection of the required runtime startup object and
+     entry point.
+
+'-mnop-fun-dllimport'
+     This option is available for Cygwin and MinGW targets.  It
+     specifies that the 'dllimport' attribute should be ignored.
+
+'-mthread'
+     This option is available for MinGW targets.  It specifies that
+     MinGW-specific thread support is to be used.
+
+'-municode'
+     This option is available for MinGW-w64 targets.  It causes the
+     'UNICODE' preprocessor macro to be predefined, and chooses
+     Unicode-capable runtime startup code.
+
+'-mwin32'
+     This option is available for Cygwin and MinGW targets.  It
+     specifies that the typical Microsoft Windows predefined macros are
+     to be set in the pre-processor, but does not influence the choice
+     of runtime library/startup code.
+
+'-mwindows'
+     This option is available for Cygwin and MinGW targets.  It
+     specifies that a GUI application is to be generated by instructing
+     the linker to set the PE header subsystem type appropriately.
+
+'-fno-set-stack-executable'
+     This option is available for MinGW targets.  It specifies that the
+     executable flag for the stack used by nested functions isn't set.
+     This is necessary for binaries running in kernel mode of Microsoft
+     Windows, as there the User32 API, which is used to set executable
+     privileges, isn't available.
+
+'-fwritable-relocated-rdata'
+     This option is available for MinGW and Cygwin targets.  It
+     specifies that relocated-data in read-only section is put into
+     .data section.  This is a necessary for older runtimes not
+     supporting modification of .rdata sections for pseudo-relocation.
+
+'-mpe-aligned-commons'
+     This option is available for Cygwin and MinGW targets.  It
+     specifies that the GNU extension to the PE file format that permits
+     the correct alignment of COMMON variables should be used when
+     generating code.  It is enabled by default if GCC detects that the
+     target assembler found during configuration supports the feature.
+
+ See also under *note i386 and x86-64 Options:: for standard options.
+
+
+File: gcc.info,  Node: IA-64 Options,  Next: LM32 Options,  Prev: i386 and x86-64 Windows Options,  Up: Submodel Options
+
+3.17.19 IA-64 Options
+---------------------
+
+These are the '-m' options defined for the Intel IA-64 architecture.
+
+'-mbig-endian'
+     Generate code for a big-endian target.  This is the default for
+     HP-UX.
+
+'-mlittle-endian'
+     Generate code for a little-endian target.  This is the default for
+     AIX5 and GNU/Linux.
+
+'-mgnu-as'
+'-mno-gnu-as'
+     Generate (or don't) code for the GNU assembler.  This is the
+     default.
+
+'-mgnu-ld'
+'-mno-gnu-ld'
+     Generate (or don't) code for the GNU linker.  This is the default.
+
+'-mno-pic'
+     Generate code that does not use a global pointer register.  The
+     result is not position independent code, and violates the IA-64
+     ABI.
+
+'-mvolatile-asm-stop'
+'-mno-volatile-asm-stop'
+     Generate (or don't) a stop bit immediately before and after
+     volatile asm statements.
+
+'-mregister-names'
+'-mno-register-names'
+     Generate (or don't) 'in', 'loc', and 'out' register names for the
+     stacked registers.  This may make assembler output more readable.
+
+'-mno-sdata'
+'-msdata'
+     Disable (or enable) optimizations that use the small data section.
+     This may be useful for working around optimizer bugs.
+
+'-mconstant-gp'
+     Generate code that uses a single constant global pointer value.
+     This is useful when compiling kernel code.
+
+'-mauto-pic'
+     Generate code that is self-relocatable.  This implies
+     '-mconstant-gp'.  This is useful when compiling firmware code.
+
+'-minline-float-divide-min-latency'
+     Generate code for inline divides of floating-point values using the
+     minimum latency algorithm.
+
+'-minline-float-divide-max-throughput'
+     Generate code for inline divides of floating-point values using the
+     maximum throughput algorithm.
+
+'-mno-inline-float-divide'
+     Do not generate inline code for divides of floating-point values.
+
+'-minline-int-divide-min-latency'
+     Generate code for inline divides of integer values using the
+     minimum latency algorithm.
+
+'-minline-int-divide-max-throughput'
+     Generate code for inline divides of integer values using the
+     maximum throughput algorithm.
+
+'-mno-inline-int-divide'
+     Do not generate inline code for divides of integer values.
+
+'-minline-sqrt-min-latency'
+     Generate code for inline square roots using the minimum latency
+     algorithm.
+
+'-minline-sqrt-max-throughput'
+     Generate code for inline square roots using the maximum throughput
+     algorithm.
+
+'-mno-inline-sqrt'
+     Do not generate inline code for 'sqrt'.
+
+'-mfused-madd'
+'-mno-fused-madd'
+     Do (don't) generate code that uses the fused multiply/add or
+     multiply/subtract instructions.  The default is to use these
+     instructions.
+
+'-mno-dwarf2-asm'
+'-mdwarf2-asm'
+     Don't (or do) generate assembler code for the DWARF 2 line number
+     debugging info.  This may be useful when not using the GNU
+     assembler.
+
+'-mearly-stop-bits'
+'-mno-early-stop-bits'
+     Allow stop bits to be placed earlier than immediately preceding the
+     instruction that triggered the stop bit.  This can improve
+     instruction scheduling, but does not always do so.
+
+'-mfixed-range=REGISTER-RANGE'
+     Generate code treating the given register range as fixed registers.
+     A fixed register is one that the register allocator cannot use.
+     This is useful when compiling kernel code.  A register range is
+     specified as two registers separated by a dash.  Multiple register
+     ranges can be specified separated by a comma.
+
+'-mtls-size=TLS-SIZE'
+     Specify bit size of immediate TLS offsets.  Valid values are 14,
+     22, and 64.
+
+'-mtune=CPU-TYPE'
+     Tune the instruction scheduling for a particular CPU, Valid values
+     are 'itanium', 'itanium1', 'merced', 'itanium2', and 'mckinley'.
+
+'-milp32'
+'-mlp64'
+     Generate code for a 32-bit or 64-bit environment.  The 32-bit
+     environment sets int, long and pointer to 32 bits.  The 64-bit
+     environment sets int to 32 bits and long and pointer to 64 bits.
+     These are HP-UX specific flags.
+
+'-mno-sched-br-data-spec'
+'-msched-br-data-spec'
+     (Dis/En)able data speculative scheduling before reload.  This
+     results in generation of 'ld.a' instructions and the corresponding
+     check instructions ('ld.c' / 'chk.a').  The default is 'disable'.
+
+'-msched-ar-data-spec'
+'-mno-sched-ar-data-spec'
+     (En/Dis)able data speculative scheduling after reload.  This
+     results in generation of 'ld.a' instructions and the corresponding
+     check instructions ('ld.c' / 'chk.a').  The default is 'enable'.
+
+'-mno-sched-control-spec'
+'-msched-control-spec'
+     (Dis/En)able control speculative scheduling.  This feature is
+     available only during region scheduling (i.e. before reload).  This
+     results in generation of the 'ld.s' instructions and the
+     corresponding check instructions 'chk.s'.  The default is
+     'disable'.
+
+'-msched-br-in-data-spec'
+'-mno-sched-br-in-data-spec'
+     (En/Dis)able speculative scheduling of the instructions that are
+     dependent on the data speculative loads before reload.  This is
+     effective only with '-msched-br-data-spec' enabled.  The default is
+     'enable'.
+
+'-msched-ar-in-data-spec'
+'-mno-sched-ar-in-data-spec'
+     (En/Dis)able speculative scheduling of the instructions that are
+     dependent on the data speculative loads after reload.  This is
+     effective only with '-msched-ar-data-spec' enabled.  The default is
+     'enable'.
+
+'-msched-in-control-spec'
+'-mno-sched-in-control-spec'
+     (En/Dis)able speculative scheduling of the instructions that are
+     dependent on the control speculative loads.  This is effective only
+     with '-msched-control-spec' enabled.  The default is 'enable'.
+
+'-mno-sched-prefer-non-data-spec-insns'
+'-msched-prefer-non-data-spec-insns'
+     If enabled, data-speculative instructions are chosen for schedule
+     only if there are no other choices at the moment.  This makes the
+     use of the data speculation much more conservative.  The default is
+     'disable'.
+
+'-mno-sched-prefer-non-control-spec-insns'
+'-msched-prefer-non-control-spec-insns'
+     If enabled, control-speculative instructions are chosen for
+     schedule only if there are no other choices at the moment.  This
+     makes the use of the control speculation much more conservative.
+     The default is 'disable'.
+
+'-mno-sched-count-spec-in-critical-path'
+'-msched-count-spec-in-critical-path'
+     If enabled, speculative dependencies are considered during
+     computation of the instructions priorities.  This makes the use of
+     the speculation a bit more conservative.  The default is 'disable'.
+
+'-msched-spec-ldc'
+     Use a simple data speculation check.  This option is on by default.
+
+'-msched-control-spec-ldc'
+     Use a simple check for control speculation.  This option is on by
+     default.
+
+'-msched-stop-bits-after-every-cycle'
+     Place a stop bit after every cycle when scheduling.  This option is
+     on by default.
+
+'-msched-fp-mem-deps-zero-cost'
+     Assume that floating-point stores and loads are not likely to cause
+     a conflict when placed into the same instruction group.  This
+     option is disabled by default.
+
+'-msel-sched-dont-check-control-spec'
+     Generate checks for control speculation in selective scheduling.
+     This flag is disabled by default.
+
+'-msched-max-memory-insns=MAX-INSNS'
+     Limit on the number of memory insns per instruction group, giving
+     lower priority to subsequent memory insns attempting to schedule in
+     the same instruction group.  Frequently useful to prevent cache
+     bank conflicts.  The default value is 1.
+
+'-msched-max-memory-insns-hard-limit'
+     Makes the limit specified by 'msched-max-memory-insns' a hard
+     limit, disallowing more than that number in an instruction group.
+     Otherwise, the limit is "soft", meaning that non-memory operations
+     are preferred when the limit is reached, but memory operations may
+     still be scheduled.
+
+
+File: gcc.info,  Node: LM32 Options,  Next: M32C Options,  Prev: IA-64 Options,  Up: Submodel Options
+
+3.17.20 LM32 Options
+--------------------
+
+These '-m' options are defined for the LatticeMico32 architecture:
+
+'-mbarrel-shift-enabled'
+     Enable barrel-shift instructions.
+
+'-mdivide-enabled'
+     Enable divide and modulus instructions.
+
+'-mmultiply-enabled'
+     Enable multiply instructions.
+
+'-msign-extend-enabled'
+     Enable sign extend instructions.
+
+'-muser-enabled'
+     Enable user-defined instructions.
+
+
+File: gcc.info,  Node: M32C Options,  Next: M32R/D Options,  Prev: LM32 Options,  Up: Submodel Options
+
+3.17.21 M32C Options
+--------------------
+
+'-mcpu=NAME'
+     Select the CPU for which code is generated.  NAME may be one of
+     'r8c' for the R8C/Tiny series, 'm16c' for the M16C (up to /60)
+     series, 'm32cm' for the M16C/80 series, or 'm32c' for the M32C/80
+     series.
+
+'-msim'
+     Specifies that the program will be run on the simulator.  This
+     causes an alternate runtime library to be linked in which supports,
+     for example, file I/O.  You must not use this option when
+     generating programs that will run on real hardware; you must
+     provide your own runtime library for whatever I/O functions are
+     needed.
+
+'-memregs=NUMBER'
+     Specifies the number of memory-based pseudo-registers GCC uses
+     during code generation.  These pseudo-registers are used like real
+     registers, so there is a tradeoff between GCC's ability to fit the
+     code into available registers, and the performance penalty of using
+     memory instead of registers.  Note that all modules in a program
+     must be compiled with the same value for this option.  Because of
+     that, you must not use this option with GCC's default runtime
+     libraries.
+
+
+File: gcc.info,  Node: M32R/D Options,  Next: M680x0 Options,  Prev: M32C Options,  Up: Submodel Options
+
+3.17.22 M32R/D Options
+----------------------
+
+These '-m' options are defined for Renesas M32R/D architectures:
+
+'-m32r2'
+     Generate code for the M32R/2.
+
+'-m32rx'
+     Generate code for the M32R/X.
+
+'-m32r'
+     Generate code for the M32R.  This is the default.
+
+'-mmodel=small'
+     Assume all objects live in the lower 16MB of memory (so that their
+     addresses can be loaded with the 'ld24' instruction), and assume
+     all subroutines are reachable with the 'bl' instruction.  This is
+     the default.
+
+     The addressability of a particular object can be set with the
+     'model' attribute.
+
+'-mmodel=medium'
+     Assume objects may be anywhere in the 32-bit address space (the
+     compiler generates 'seth/add3' instructions to load their
+     addresses), and assume all subroutines are reachable with the 'bl'
+     instruction.
+
+'-mmodel=large'
+     Assume objects may be anywhere in the 32-bit address space (the
+     compiler generates 'seth/add3' instructions to load their
+     addresses), and assume subroutines may not be reachable with the
+     'bl' instruction (the compiler generates the much slower
+     'seth/add3/jl' instruction sequence).
+
+'-msdata=none'
+     Disable use of the small data area.  Variables are put into one of
+     '.data', '.bss', or '.rodata' (unless the 'section' attribute has
+     been specified).  This is the default.
+
+     The small data area consists of sections '.sdata' and '.sbss'.
+     Objects may be explicitly put in the small data area with the
+     'section' attribute using one of these sections.
+
+'-msdata=sdata'
+     Put small global and static data in the small data area, but do not
+     generate special code to reference them.
+
+'-msdata=use'
+     Put small global and static data in the small data area, and
+     generate special instructions to reference them.
+
+'-G NUM'
+     Put global and static objects less than or equal to NUM bytes into
+     the small data or BSS sections instead of the normal data or BSS
+     sections.  The default value of NUM is 8.  The '-msdata' option
+     must be set to one of 'sdata' or 'use' for this option to have any
+     effect.
+
+     All modules should be compiled with the same '-G NUM' value.
+     Compiling with different values of NUM may or may not work; if it
+     doesn't the linker gives an error message--incorrect code is not
+     generated.
+
+'-mdebug'
+     Makes the M32R-specific code in the compiler display some
+     statistics that might help in debugging programs.
+
+'-malign-loops'
+     Align all loops to a 32-byte boundary.
+
+'-mno-align-loops'
+     Do not enforce a 32-byte alignment for loops.  This is the default.
+
+'-missue-rate=NUMBER'
+     Issue NUMBER instructions per cycle.  NUMBER can only be 1 or 2.
+
+'-mbranch-cost=NUMBER'
+     NUMBER can only be 1 or 2.  If it is 1 then branches are preferred
+     over conditional code, if it is 2, then the opposite applies.
+
+'-mflush-trap=NUMBER'
+     Specifies the trap number to use to flush the cache.  The default
+     is 12.  Valid numbers are between 0 and 15 inclusive.
+
+'-mno-flush-trap'
+     Specifies that the cache cannot be flushed by using a trap.
+
+'-mflush-func=NAME'
+     Specifies the name of the operating system function to call to
+     flush the cache.  The default is __flush_cache_, but a function
+     call is only used if a trap is not available.
+
+'-mno-flush-func'
+     Indicates that there is no OS function for flushing the cache.
+
+
+File: gcc.info,  Node: M680x0 Options,  Next: MCore Options,  Prev: M32R/D Options,  Up: Submodel Options
+
+3.17.23 M680x0 Options
+----------------------
+
+These are the '-m' options defined for M680x0 and ColdFire processors.
+The default settings depend on which architecture was selected when the
+compiler was configured; the defaults for the most common choices are
+given below.
+
+'-march=ARCH'
+     Generate code for a specific M680x0 or ColdFire instruction set
+     architecture.  Permissible values of ARCH for M680x0 architectures
+     are: '68000', '68010', '68020', '68030', '68040', '68060' and
+     'cpu32'.  ColdFire architectures are selected according to
+     Freescale's ISA classification and the permissible values are:
+     'isaa', 'isaaplus', 'isab' and 'isac'.
+
+     GCC defines a macro '__mcfARCH__' whenever it is generating code
+     for a ColdFire target.  The ARCH in this macro is one of the
+     '-march' arguments given above.
+
+     When used together, '-march' and '-mtune' select code that runs on
+     a family of similar processors but that is optimized for a
+     particular microarchitecture.
+
+'-mcpu=CPU'
+     Generate code for a specific M680x0 or ColdFire processor.  The
+     M680x0 CPUs are: '68000', '68010', '68020', '68030', '68040',
+     '68060', '68302', '68332' and 'cpu32'.  The ColdFire CPUs are given
+     by the table below, which also classifies the CPUs into families:
+
+     *Family*       *'-mcpu' arguments*
+     '51'           '51' '51ac' '51ag' '51cn' '51em' '51je' '51jf' '51jg'
+                    '51jm' '51mm' '51qe' '51qm'
+     '5206'         '5202' '5204' '5206'
+     '5206e'        '5206e'
+     '5208'         '5207' '5208'
+     '5211a'        '5210a' '5211a'
+     '5213'         '5211' '5212' '5213'
+     '5216'         '5214' '5216'
+     '52235'        '52230' '52231' '52232' '52233' '52234' '52235'
+     '5225'         '5224' '5225'
+     '52259'        '52252' '52254' '52255' '52256' '52258' '52259'
+     '5235'         '5232' '5233' '5234' '5235' '523x'
+     '5249'         '5249'
+     '5250'         '5250'
+     '5271'         '5270' '5271'
+     '5272'         '5272'
+     '5275'         '5274' '5275'
+     '5282'         '5280' '5281' '5282' '528x'
+     '53017'        '53011' '53012' '53013' '53014' '53015' '53016' '53017'
+     '5307'         '5307'
+     '5329'         '5327' '5328' '5329' '532x'
+     '5373'         '5372' '5373' '537x'
+     '5407'         '5407'
+     '5475'         '5470' '5471' '5472' '5473' '5474' '5475' '547x' '5480'
+                    '5481' '5482' '5483' '5484' '5485'
+
+     '-mcpu=CPU' overrides '-march=ARCH' if ARCH is compatible with CPU.
+     Other combinations of '-mcpu' and '-march' are rejected.
+
+     GCC defines the macro '__mcf_cpu_CPU' when ColdFire target CPU is
+     selected.  It also defines '__mcf_family_FAMILY', where the value
+     of FAMILY is given by the table above.
+
+'-mtune=TUNE'
+     Tune the code for a particular microarchitecture within the
+     constraints set by '-march' and '-mcpu'.  The M680x0
+     microarchitectures are: '68000', '68010', '68020', '68030',
+     '68040', '68060' and 'cpu32'.  The ColdFire microarchitectures are:
+     'cfv1', 'cfv2', 'cfv3', 'cfv4' and 'cfv4e'.
+
+     You can also use '-mtune=68020-40' for code that needs to run
+     relatively well on 68020, 68030 and 68040 targets.
+     '-mtune=68020-60' is similar but includes 68060 targets as well.
+     These two options select the same tuning decisions as '-m68020-40'
+     and '-m68020-60' respectively.
+
+     GCC defines the macros '__mcARCH' and '__mcARCH__' when tuning for
+     680x0 architecture ARCH.  It also defines 'mcARCH' unless either
+     '-ansi' or a non-GNU '-std' option is used.  If GCC is tuning for a
+     range of architectures, as selected by '-mtune=68020-40' or
+     '-mtune=68020-60', it defines the macros for every architecture in
+     the range.
+
+     GCC also defines the macro '__mUARCH__' when tuning for ColdFire
+     microarchitecture UARCH, where UARCH is one of the arguments given
+     above.
+
+'-m68000'
+'-mc68000'
+     Generate output for a 68000.  This is the default when the compiler
+     is configured for 68000-based systems.  It is equivalent to
+     '-march=68000'.
+
+     Use this option for microcontrollers with a 68000 or EC000 core,
+     including the 68008, 68302, 68306, 68307, 68322, 68328 and 68356.
+
+'-m68010'
+     Generate output for a 68010.  This is the default when the compiler
+     is configured for 68010-based systems.  It is equivalent to
+     '-march=68010'.
+
+'-m68020'
+'-mc68020'
+     Generate output for a 68020.  This is the default when the compiler
+     is configured for 68020-based systems.  It is equivalent to
+     '-march=68020'.
+
+'-m68030'
+     Generate output for a 68030.  This is the default when the compiler
+     is configured for 68030-based systems.  It is equivalent to
+     '-march=68030'.
+
+'-m68040'
+     Generate output for a 68040.  This is the default when the compiler
+     is configured for 68040-based systems.  It is equivalent to
+     '-march=68040'.
+
+     This option inhibits the use of 68881/68882 instructions that have
+     to be emulated by software on the 68040.  Use this option if your
+     68040 does not have code to emulate those instructions.
+
+'-m68060'
+     Generate output for a 68060.  This is the default when the compiler
+     is configured for 68060-based systems.  It is equivalent to
+     '-march=68060'.
+
+     This option inhibits the use of 68020 and 68881/68882 instructions
+     that have to be emulated by software on the 68060.  Use this option
+     if your 68060 does not have code to emulate those instructions.
+
+'-mcpu32'
+     Generate output for a CPU32.  This is the default when the compiler
+     is configured for CPU32-based systems.  It is equivalent to
+     '-march=cpu32'.
+
+     Use this option for microcontrollers with a CPU32 or CPU32+ core,
+     including the 68330, 68331, 68332, 68333, 68334, 68336, 68340,
+     68341, 68349 and 68360.
+
+'-m5200'
+     Generate output for a 520X ColdFire CPU.  This is the default when
+     the compiler is configured for 520X-based systems.  It is
+     equivalent to '-mcpu=5206', and is now deprecated in favor of that
+     option.
+
+     Use this option for microcontroller with a 5200 core, including the
+     MCF5202, MCF5203, MCF5204 and MCF5206.
+
+'-m5206e'
+     Generate output for a 5206e ColdFire CPU.  The option is now
+     deprecated in favor of the equivalent '-mcpu=5206e'.
+
+'-m528x'
+     Generate output for a member of the ColdFire 528X family.  The
+     option is now deprecated in favor of the equivalent '-mcpu=528x'.
+
+'-m5307'
+     Generate output for a ColdFire 5307 CPU.  The option is now
+     deprecated in favor of the equivalent '-mcpu=5307'.
+
+'-m5407'
+     Generate output for a ColdFire 5407 CPU.  The option is now
+     deprecated in favor of the equivalent '-mcpu=5407'.
+
+'-mcfv4e'
+     Generate output for a ColdFire V4e family CPU (e.g. 547x/548x).
+     This includes use of hardware floating-point instructions.  The
+     option is equivalent to '-mcpu=547x', and is now deprecated in
+     favor of that option.
+
+'-m68020-40'
+     Generate output for a 68040, without using any of the new
+     instructions.  This results in code that can run relatively
+     efficiently on either a 68020/68881 or a 68030 or a 68040.  The
+     generated code does use the 68881 instructions that are emulated on
+     the 68040.
+
+     The option is equivalent to '-march=68020' '-mtune=68020-40'.
+
+'-m68020-60'
+     Generate output for a 68060, without using any of the new
+     instructions.  This results in code that can run relatively
+     efficiently on either a 68020/68881 or a 68030 or a 68040.  The
+     generated code does use the 68881 instructions that are emulated on
+     the 68060.
+
+     The option is equivalent to '-march=68020' '-mtune=68020-60'.
+
+'-mhard-float'
+'-m68881'
+     Generate floating-point instructions.  This is the default for
+     68020 and above, and for ColdFire devices that have an FPU.  It
+     defines the macro '__HAVE_68881__' on M680x0 targets and
+     '__mcffpu__' on ColdFire targets.
+
+'-msoft-float'
+     Do not generate floating-point instructions; use library calls
+     instead.  This is the default for 68000, 68010, and 68832 targets.
+     It is also the default for ColdFire devices that have no FPU.
+
+'-mdiv'
+'-mno-div'
+     Generate (do not generate) ColdFire hardware divide and remainder
+     instructions.  If '-march' is used without '-mcpu', the default is
+     "on" for ColdFire architectures and "off" for M680x0 architectures.
+     Otherwise, the default is taken from the target CPU (either the
+     default CPU, or the one specified by '-mcpu').  For example, the
+     default is "off" for '-mcpu=5206' and "on" for '-mcpu=5206e'.
+
+     GCC defines the macro '__mcfhwdiv__' when this option is enabled.
+
+'-mshort'
+     Consider type 'int' to be 16 bits wide, like 'short int'.
+     Additionally, parameters passed on the stack are also aligned to a
+     16-bit boundary even on targets whose API mandates promotion to
+     32-bit.
+
+'-mno-short'
+     Do not consider type 'int' to be 16 bits wide.  This is the
+     default.
+
+'-mnobitfield'
+'-mno-bitfield'
+     Do not use the bit-field instructions.  The '-m68000', '-mcpu32'
+     and '-m5200' options imply '-mnobitfield'.
+
+'-mbitfield'
+     Do use the bit-field instructions.  The '-m68020' option implies
+     '-mbitfield'.  This is the default if you use a configuration
+     designed for a 68020.
+
+'-mrtd'
+     Use a different function-calling convention, in which functions
+     that take a fixed number of arguments return with the 'rtd'
+     instruction, which pops their arguments while returning.  This
+     saves one instruction in the caller since there is no need to pop
+     the arguments there.
+
+     This calling convention is incompatible with the one normally used
+     on Unix, so you cannot use it if you need to call libraries
+     compiled with the Unix compiler.
+
+     Also, you must provide function prototypes for all functions that
+     take variable numbers of arguments (including 'printf'); otherwise
+     incorrect code is generated for calls to those functions.
+
+     In addition, seriously incorrect code results if you call a
+     function with too many arguments.  (Normally, extra arguments are
+     harmlessly ignored.)
+
+     The 'rtd' instruction is supported by the 68010, 68020, 68030,
+     68040, 68060 and CPU32 processors, but not by the 68000 or 5200.
+
+'-mno-rtd'
+     Do not use the calling conventions selected by '-mrtd'.  This is
+     the default.
+
+'-malign-int'
+'-mno-align-int'
+     Control whether GCC aligns 'int', 'long', 'long long', 'float',
+     'double', and 'long double' variables on a 32-bit boundary
+     ('-malign-int') or a 16-bit boundary ('-mno-align-int').  Aligning
+     variables on 32-bit boundaries produces code that runs somewhat
+     faster on processors with 32-bit busses at the expense of more
+     memory.
+
+     *Warning:* if you use the '-malign-int' switch, GCC aligns
+     structures containing the above types differently than most
+     published application binary interface specifications for the m68k.
+
+'-mpcrel'
+     Use the pc-relative addressing mode of the 68000 directly, instead
+     of using a global offset table.  At present, this option implies
+     '-fpic', allowing at most a 16-bit offset for pc-relative
+     addressing.  '-fPIC' is not presently supported with '-mpcrel',
+     though this could be supported for 68020 and higher processors.
+
+'-mno-strict-align'
+'-mstrict-align'
+     Do not (do) assume that unaligned memory references are handled by
+     the system.
+
+'-msep-data'
+     Generate code that allows the data segment to be located in a
+     different area of memory from the text segment.  This allows for
+     execute-in-place in an environment without virtual memory
+     management.  This option implies '-fPIC'.
+
+'-mno-sep-data'
+     Generate code that assumes that the data segment follows the text
+     segment.  This is the default.
+
+'-mid-shared-library'
+     Generate code that supports shared libraries via the library ID
+     method.  This allows for execute-in-place and shared libraries in
+     an environment without virtual memory management.  This option
+     implies '-fPIC'.
+
+'-mno-id-shared-library'
+     Generate code that doesn't assume ID-based shared libraries are
+     being used.  This is the default.
+
+'-mshared-library-id=n'
+     Specifies the identification number of the ID-based shared library
+     being compiled.  Specifying a value of 0 generates more compact
+     code; specifying other values forces the allocation of that number
+     to the current library, but is no more space- or time-efficient
+     than omitting this option.
+
+'-mxgot'
+'-mno-xgot'
+     When generating position-independent code for ColdFire, generate
+     code that works if the GOT has more than 8192 entries.  This code
+     is larger and slower than code generated without this option.  On
+     M680x0 processors, this option is not needed; '-fPIC' suffices.
+
+     GCC normally uses a single instruction to load values from the GOT.
+     While this is relatively efficient, it only works if the GOT is
+     smaller than about 64k.  Anything larger causes the linker to
+     report an error such as:
+
+          relocation truncated to fit: R_68K_GOT16O foobar
+
+     If this happens, you should recompile your code with '-mxgot'.  It
+     should then work with very large GOTs.  However, code generated
+     with '-mxgot' is less efficient, since it takes 4 instructions to
+     fetch the value of a global symbol.
+
+     Note that some linkers, including newer versions of the GNU linker,
+     can create multiple GOTs and sort GOT entries.  If you have such a
+     linker, you should only need to use '-mxgot' when compiling a
+     single object file that accesses more than 8192 GOT entries.  Very
+     few do.
+
+     These options have no effect unless GCC is generating
+     position-independent code.
+
+
+File: gcc.info,  Node: MCore Options,  Next: MeP Options,  Prev: M680x0 Options,  Up: Submodel Options
+
+3.17.24 MCore Options
+---------------------
+
+These are the '-m' options defined for the Motorola M*Core processors.
+
+'-mhardlit'
+'-mno-hardlit'
+     Inline constants into the code stream if it can be done in two
+     instructions or less.
+
+'-mdiv'
+'-mno-div'
+     Use the divide instruction.  (Enabled by default).
+
+'-mrelax-immediate'
+'-mno-relax-immediate'
+     Allow arbitrary-sized immediates in bit operations.
+
+'-mwide-bitfields'
+'-mno-wide-bitfields'
+     Always treat bit-fields as 'int'-sized.
+
+'-m4byte-functions'
+'-mno-4byte-functions'
+     Force all functions to be aligned to a 4-byte boundary.
+
+'-mcallgraph-data'
+'-mno-callgraph-data'
+     Emit callgraph information.
+
+'-mslow-bytes'
+'-mno-slow-bytes'
+     Prefer word access when reading byte quantities.
+
+'-mlittle-endian'
+'-mbig-endian'
+     Generate code for a little-endian target.
+
+'-m210'
+'-m340'
+     Generate code for the 210 processor.
+
+'-mno-lsim'
+     Assume that runtime support has been provided and so omit the
+     simulator library ('libsim.a)' from the linker command line.
+
+'-mstack-increment=SIZE'
+     Set the maximum amount for a single stack increment operation.
+     Large values can increase the speed of programs that contain
+     functions that need a large amount of stack space, but they can
+     also trigger a segmentation fault if the stack is extended too
+     much.  The default value is 0x1000.
+
+
+File: gcc.info,  Node: MeP Options,  Next: MicroBlaze Options,  Prev: MCore Options,  Up: Submodel Options
+
+3.17.25 MeP Options
+-------------------
+
+'-mabsdiff'
+     Enables the 'abs' instruction, which is the absolute difference
+     between two registers.
+
+'-mall-opts'
+     Enables all the optional instructions--average, multiply, divide,
+     bit operations, leading zero, absolute difference, min/max, clip,
+     and saturation.
+
+'-maverage'
+     Enables the 'ave' instruction, which computes the average of two
+     registers.
+
+'-mbased=N'
+     Variables of size N bytes or smaller are placed in the '.based'
+     section by default.  Based variables use the '$tp' register as a
+     base register, and there is a 128-byte limit to the '.based'
+     section.
+
+'-mbitops'
+     Enables the bit operation instructions--bit test ('btstm'), set
+     ('bsetm'), clear ('bclrm'), invert ('bnotm'), and test-and-set
+     ('tas').
+
+'-mc=NAME'
+     Selects which section constant data is placed in.  NAME may be
+     'tiny', 'near', or 'far'.
+
+'-mclip'
+     Enables the 'clip' instruction.  Note that '-mclip' is not useful
+     unless you also provide '-mminmax'.
+
+'-mconfig=NAME'
+     Selects one of the built-in core configurations.  Each MeP chip has
+     one or more modules in it; each module has a core CPU and a variety
+     of coprocessors, optional instructions, and peripherals.  The
+     'MeP-Integrator' tool, not part of GCC, provides these
+     configurations through this option; using this option is the same
+     as using all the corresponding command-line options.  The default
+     configuration is 'default'.
+
+'-mcop'
+     Enables the coprocessor instructions.  By default, this is a 32-bit
+     coprocessor.  Note that the coprocessor is normally enabled via the
+     '-mconfig=' option.
+
+'-mcop32'
+     Enables the 32-bit coprocessor's instructions.
+
+'-mcop64'
+     Enables the 64-bit coprocessor's instructions.
+
+'-mivc2'
+     Enables IVC2 scheduling.  IVC2 is a 64-bit VLIW coprocessor.
+
+'-mdc'
+     Causes constant variables to be placed in the '.near' section.
+
+'-mdiv'
+     Enables the 'div' and 'divu' instructions.
+
+'-meb'
+     Generate big-endian code.
+
+'-mel'
+     Generate little-endian code.
+
+'-mio-volatile'
+     Tells the compiler that any variable marked with the 'io' attribute
+     is to be considered volatile.
+
+'-ml'
+     Causes variables to be assigned to the '.far' section by default.
+
+'-mleadz'
+     Enables the 'leadz' (leading zero) instruction.
+
+'-mm'
+     Causes variables to be assigned to the '.near' section by default.
+
+'-mminmax'
+     Enables the 'min' and 'max' instructions.
+
+'-mmult'
+     Enables the multiplication and multiply-accumulate instructions.
+
+'-mno-opts'
+     Disables all the optional instructions enabled by '-mall-opts'.
+
+'-mrepeat'
+     Enables the 'repeat' and 'erepeat' instructions, used for
+     low-overhead looping.
+
+'-ms'
+     Causes all variables to default to the '.tiny' section.  Note that
+     there is a 65536-byte limit to this section.  Accesses to these
+     variables use the '%gp' base register.
+
+'-msatur'
+     Enables the saturation instructions.  Note that the compiler does
+     not currently generate these itself, but this option is included
+     for compatibility with other tools, like 'as'.
+
+'-msdram'
+     Link the SDRAM-based runtime instead of the default ROM-based
+     runtime.
+
+'-msim'
+     Link the simulator run-time libraries.
+
+'-msimnovec'
+     Link the simulator runtime libraries, excluding built-in support
+     for reset and exception vectors and tables.
+
+'-mtf'
+     Causes all functions to default to the '.far' section.  Without
+     this option, functions default to the '.near' section.
+
+'-mtiny=N'
+     Variables that are N bytes or smaller are allocated to the '.tiny'
+     section.  These variables use the '$gp' base register.  The default
+     for this option is 4, but note that there's a 65536-byte limit to
+     the '.tiny' section.
+
+
+File: gcc.info,  Node: MicroBlaze Options,  Next: MIPS Options,  Prev: MeP Options,  Up: Submodel Options
+
+3.17.26 MicroBlaze Options
+--------------------------
+
+'-msoft-float'
+     Use software emulation for floating point (default).
+
+'-mhard-float'
+     Use hardware floating-point instructions.
+
+'-mmemcpy'
+     Do not optimize block moves, use 'memcpy'.
+
+'-mno-clearbss'
+     This option is deprecated.  Use '-fno-zero-initialized-in-bss'
+     instead.
+
+'-mcpu=CPU-TYPE'
+     Use features of, and schedule code for, the given CPU. Supported
+     values are in the format 'vX.YY.Z', where X is a major version, YY
+     is the minor version, and Z is compatibility code.  Example values
+     are 'v3.00.a', 'v4.00.b', 'v5.00.a', 'v5.00.b', 'v5.00.b',
+     'v6.00.a'.
+
+'-mxl-soft-mul'
+     Use software multiply emulation (default).
+
+'-mxl-soft-div'
+     Use software emulation for divides (default).
+
+'-mxl-barrel-shift'
+     Use the hardware barrel shifter.
+
+'-mxl-pattern-compare'
+     Use pattern compare instructions.
+
+'-msmall-divides'
+     Use table lookup optimization for small signed integer divisions.
+
+'-mxl-stack-check'
+     This option is deprecated.  Use '-fstack-check' instead.
+
+'-mxl-gp-opt'
+     Use GP-relative '.sdata'/'.sbss' sections.
+
+'-mxl-multiply-high'
+     Use multiply high instructions for high part of 32x32 multiply.
+
+'-mxl-float-convert'
+     Use hardware floating-point conversion instructions.
+
+'-mxl-float-sqrt'
+     Use hardware floating-point square root instruction.
+
+'-mbig-endian'
+     Generate code for a big-endian target.
+
+'-mlittle-endian'
+     Generate code for a little-endian target.
+
+'-mxl-reorder'
+     Use reorder instructions (swap and byte reversed load/store).
+
+'-mxl-mode-APP-MODEL'
+     Select application model APP-MODEL.  Valid models are
+     'executable'
+          normal executable (default), uses startup code 'crt0.o'.
+
+     'xmdstub'
+          for use with Xilinx Microprocessor Debugger (XMD) based
+          software intrusive debug agent called xmdstub.  This uses
+          startup file 'crt1.o' and sets the start address of the
+          program to 0x800.
+
+     'bootstrap'
+          for applications that are loaded using a bootloader.  This
+          model uses startup file 'crt2.o' which does not contain a
+          processor reset vector handler.  This is suitable for
+          transferring control on a processor reset to the bootloader
+          rather than the application.
+
+     'novectors'
+          for applications that do not require any of the MicroBlaze
+          vectors.  This option may be useful for applications running
+          within a monitoring application.  This model uses 'crt3.o' as
+          a startup file.
+
+     Option '-xl-mode-APP-MODEL' is a deprecated alias for
+     '-mxl-mode-APP-MODEL'.
+
+
+File: gcc.info,  Node: MIPS Options,  Next: MMIX Options,  Prev: MicroBlaze Options,  Up: Submodel Options
+
+3.17.27 MIPS Options
+--------------------
+
+'-EB'
+     Generate big-endian code.
+
+'-EL'
+     Generate little-endian code.  This is the default for 'mips*el-*-*'
+     configurations.
+
+'-march=ARCH'
+     Generate code that runs on ARCH, which can be the name of a generic
+     MIPS ISA, or the name of a particular processor.  The ISA names
+     are: 'mips1', 'mips2', 'mips3', 'mips4', 'mips32', 'mips32r2',
+     'mips64' and 'mips64r2'.  The processor names are: '4kc', '4km',
+     '4kp', '4ksc', '4kec', '4kem', '4kep', '4ksd', '5kc', '5kf',
+     '20kc', '24kc', '24kf2_1', '24kf1_1', '24kec', '24kef2_1',
+     '24kef1_1', '34kc', '34kf2_1', '34kf1_1', '34kn', '74kc',
+     '74kf2_1', '74kf1_1', '74kf3_2', '1004kc', '1004kf2_1',
+     '1004kf1_1', 'loongson2e', 'loongson2f', 'loongson3a', 'm4k',
+     'm14k', 'm14kc', 'm14ke', 'm14kec', 'octeon', 'octeon+', 'octeon2',
+     'orion', 'r2000', 'r3000', 'r3900', 'r4000', 'r4400', 'r4600',
+     'r4650', 'r4700', 'r6000', 'r8000', 'rm7000', 'rm9000', 'r10000',
+     'r12000', 'r14000', 'r16000', 'sb1', 'sr71000', 'vr4100', 'vr4111',
+     'vr4120', 'vr4130', 'vr4300', 'vr5000', 'vr5400', 'vr5500', 'xlr'
+     and 'xlp'.  The special value 'from-abi' selects the most
+     compatible architecture for the selected ABI (that is, 'mips1' for
+     32-bit ABIs and 'mips3' for 64-bit ABIs).
+
+     The native Linux/GNU toolchain also supports the value 'native',
+     which selects the best architecture option for the host processor.
+     '-march=native' has no effect if GCC does not recognize the
+     processor.
+
+     In processor names, a final '000' can be abbreviated as 'k' (for
+     example, '-march=r2k').  Prefixes are optional, and 'vr' may be
+     written 'r'.
+
+     Names of the form 'Nf2_1' refer to processors with FPUs clocked at
+     half the rate of the core, names of the form 'Nf1_1' refer to
+     processors with FPUs clocked at the same rate as the core, and
+     names of the form 'Nf3_2' refer to processors with FPUs clocked a
+     ratio of 3:2 with respect to the core.  For compatibility reasons,
+     'Nf' is accepted as a synonym for 'Nf2_1' while 'Nx' and 'Bfx' are
+     accepted as synonyms for 'Nf1_1'.
+
+     GCC defines two macros based on the value of this option.  The
+     first is '_MIPS_ARCH', which gives the name of target architecture,
+     as a string.  The second has the form '_MIPS_ARCH_FOO', where FOO
+     is the capitalized value of '_MIPS_ARCH'.  For example,
+     '-march=r2000' sets '_MIPS_ARCH' to '"r2000"' and defines the macro
+     '_MIPS_ARCH_R2000'.
+
+     Note that the '_MIPS_ARCH' macro uses the processor names given
+     above.  In other words, it has the full prefix and does not
+     abbreviate '000' as 'k'.  In the case of 'from-abi', the macro
+     names the resolved architecture (either '"mips1"' or '"mips3"').
+     It names the default architecture when no '-march' option is given.
+
+'-mtune=ARCH'
+     Optimize for ARCH.  Among other things, this option controls the
+     way instructions are scheduled, and the perceived cost of
+     arithmetic operations.  The list of ARCH values is the same as for
+     '-march'.
+
+     When this option is not used, GCC optimizes for the processor
+     specified by '-march'.  By using '-march' and '-mtune' together, it
+     is possible to generate code that runs on a family of processors,
+     but optimize the code for one particular member of that family.
+
+     '-mtune' defines the macros '_MIPS_TUNE' and '_MIPS_TUNE_FOO',
+     which work in the same way as the '-march' ones described above.
+
+'-mips1'
+     Equivalent to '-march=mips1'.
+
+'-mips2'
+     Equivalent to '-march=mips2'.
+
+'-mips3'
+     Equivalent to '-march=mips3'.
+
+'-mips4'
+     Equivalent to '-march=mips4'.
+
+'-mips32'
+     Equivalent to '-march=mips32'.
+
+'-mips32r2'
+     Equivalent to '-march=mips32r2'.
+
+'-mips64'
+     Equivalent to '-march=mips64'.
+
+'-mips64r2'
+     Equivalent to '-march=mips64r2'.
+
+'-mips16'
+'-mno-mips16'
+     Generate (do not generate) MIPS16 code.  If GCC is targeting a
+     MIPS32 or MIPS64 architecture, it makes use of the MIPS16e ASE.
+
+     MIPS16 code generation can also be controlled on a per-function
+     basis by means of 'mips16' and 'nomips16' attributes.  *Note
+     Function Attributes::, for more information.
+
+'-mflip-mips16'
+     Generate MIPS16 code on alternating functions.  This option is
+     provided for regression testing of mixed MIPS16/non-MIPS16 code
+     generation, and is not intended for ordinary use in compiling user
+     code.
+
+'-minterlink-compressed'
+'-mno-interlink-compressed'
+     Require (do not require) that code using the standard
+     (uncompressed) MIPS ISA be link-compatible with MIPS16 and
+     microMIPS code, and vice versa.
+
+     For example, code using the standard ISA encoding cannot jump
+     directly to MIPS16 or microMIPS code; it must either use a call or
+     an indirect jump.  '-minterlink-compressed' therefore disables
+     direct jumps unless GCC knows that the target of the jump is not
+     compressed.
+
+'-minterlink-mips16'
+'-mno-interlink-mips16'
+     Aliases of '-minterlink-compressed' and
+     '-mno-interlink-compressed'.  These options predate the microMIPS
+     ASE and are retained for backwards compatibility.
+
+'-mabi=32'
+'-mabi=o64'
+'-mabi=n32'
+'-mabi=64'
+'-mabi=eabi'
+     Generate code for the given ABI.
+
+     Note that the EABI has a 32-bit and a 64-bit variant.  GCC normally
+     generates 64-bit code when you select a 64-bit architecture, but
+     you can use '-mgp32' to get 32-bit code instead.
+
+     For information about the O64 ABI, see
+     <http://gcc.gnu.org/projects/mipso64-abi.html>.
+
+     GCC supports a variant of the o32 ABI in which floating-point
+     registers are 64 rather than 32 bits wide.  You can select this
+     combination with '-mabi=32' '-mfp64'.  This ABI relies on the
+     'mthc1' and 'mfhc1' instructions and is therefore only supported
+     for MIPS32R2 processors.
+
+     The register assignments for arguments and return values remain the
+     same, but each scalar value is passed in a single 64-bit register
+     rather than a pair of 32-bit registers.  For example, scalar
+     floating-point values are returned in '$f0' only, not a '$f0'/'$f1'
+     pair.  The set of call-saved registers also remains the same, but
+     all 64 bits are saved.
+
+'-mabicalls'
+'-mno-abicalls'
+     Generate (do not generate) code that is suitable for SVR4-style
+     dynamic objects.  '-mabicalls' is the default for SVR4-based
+     systems.
+
+'-mshared'
+'-mno-shared'
+     Generate (do not generate) code that is fully position-independent,
+     and that can therefore be linked into shared libraries.  This
+     option only affects '-mabicalls'.
+
+     All '-mabicalls' code has traditionally been position-independent,
+     regardless of options like '-fPIC' and '-fpic'.  However, as an
+     extension, the GNU toolchain allows executables to use absolute
+     accesses for locally-binding symbols.  It can also use shorter GP
+     initialization sequences and generate direct calls to
+     locally-defined functions.  This mode is selected by '-mno-shared'.
+
+     '-mno-shared' depends on binutils 2.16 or higher and generates
+     objects that can only be linked by the GNU linker.  However, the
+     option does not affect the ABI of the final executable; it only
+     affects the ABI of relocatable objects.  Using '-mno-shared'
+     generally makes executables both smaller and quicker.
+
+     '-mshared' is the default.
+
+'-mplt'
+'-mno-plt'
+     Assume (do not assume) that the static and dynamic linkers support
+     PLTs and copy relocations.  This option only affects '-mno-shared
+     -mabicalls'.  For the n64 ABI, this option has no effect without
+     '-msym32'.
+
+     You can make '-mplt' the default by configuring GCC with
+     '--with-mips-plt'.  The default is '-mno-plt' otherwise.
+
+'-mxgot'
+'-mno-xgot'
+     Lift (do not lift) the usual restrictions on the size of the global
+     offset table.
+
+     GCC normally uses a single instruction to load values from the GOT.
+     While this is relatively efficient, it only works if the GOT is
+     smaller than about 64k.  Anything larger causes the linker to
+     report an error such as:
+
+          relocation truncated to fit: R_MIPS_GOT16 foobar
+
+     If this happens, you should recompile your code with '-mxgot'.
+     This works with very large GOTs, although the code is also less
+     efficient, since it takes three instructions to fetch the value of
+     a global symbol.
+
+     Note that some linkers can create multiple GOTs.  If you have such
+     a linker, you should only need to use '-mxgot' when a single object
+     file accesses more than 64k's worth of GOT entries.  Very few do.
+
+     These options have no effect unless GCC is generating position
+     independent code.
+
+'-mgp32'
+     Assume that general-purpose registers are 32 bits wide.
+
+'-mgp64'
+     Assume that general-purpose registers are 64 bits wide.
+
+'-mfp32'
+     Assume that floating-point registers are 32 bits wide.
+
+'-mfp64'
+     Assume that floating-point registers are 64 bits wide.
+
+'-mhard-float'
+     Use floating-point coprocessor instructions.
+
+'-msoft-float'
+     Do not use floating-point coprocessor instructions.  Implement
+     floating-point calculations using library calls instead.
+
+'-mno-float'
+     Equivalent to '-msoft-float', but additionally asserts that the
+     program being compiled does not perform any floating-point
+     operations.  This option is presently supported only by some
+     bare-metal MIPS configurations, where it may select a special set
+     of libraries that lack all floating-point support (including, for
+     example, the floating-point 'printf' formats).  If code compiled
+     with '-mno-float' accidentally contains floating-point operations,
+     it is likely to suffer a link-time or run-time failure.
+
+'-msingle-float'
+     Assume that the floating-point coprocessor only supports
+     single-precision operations.
+
+'-mdouble-float'
+     Assume that the floating-point coprocessor supports
+     double-precision operations.  This is the default.
+
+'-mabs=2008'
+'-mabs=legacy'
+     These options control the treatment of the special not-a-number
+     (NaN) IEEE 754 floating-point data with the 'abs.fmt' and 'neg.fmt'
+     machine instructions.
+
+     By default or when the '-mabs=legacy' is used the legacy treatment
+     is selected.  In this case these instructions are considered
+     arithmetic and avoided where correct operation is required and the
+     input operand might be a NaN. A longer sequence of instructions
+     that manipulate the sign bit of floating-point datum manually is
+     used instead unless the '-ffinite-math-only' option has also been
+     specified.
+
+     The '-mabs=2008' option selects the IEEE 754-2008 treatment.  In
+     this case these instructions are considered non-arithmetic and
+     therefore operating correctly in all cases, including in particular
+     where the input operand is a NaN. These instructions are therefore
+     always used for the respective operations.
+
+'-mnan=2008'
+'-mnan=legacy'
+     These options control the encoding of the special not-a-number
+     (NaN) IEEE 754 floating-point data.
+
+     The '-mnan=legacy' option selects the legacy encoding.  In this
+     case quiet NaNs (qNaNs) are denoted by the first bit of their
+     trailing significand field being 0, whereas signalling NaNs (sNaNs)
+     are denoted by the first bit of their trailing significand field
+     being 1.
+
+     The '-mnan=2008' option selects the IEEE 754-2008 encoding.  In
+     this case qNaNs are denoted by the first bit of their trailing
+     significand field being 1, whereas sNaNs are denoted by the first
+     bit of their trailing significand field being 0.
+
+     The default is '-mnan=legacy' unless GCC has been configured with
+     '--with-nan=2008'.
+
+'-mllsc'
+'-mno-llsc'
+     Use (do not use) 'll', 'sc', and 'sync' instructions to implement
+     atomic memory built-in functions.  When neither option is
+     specified, GCC uses the instructions if the target architecture
+     supports them.
+
+     '-mllsc' is useful if the runtime environment can emulate the
+     instructions and '-mno-llsc' can be useful when compiling for
+     nonstandard ISAs.  You can make either option the default by
+     configuring GCC with '--with-llsc' and '--without-llsc'
+     respectively.  '--with-llsc' is the default for some
+     configurations; see the installation documentation for details.
+
+'-mdsp'
+'-mno-dsp'
+     Use (do not use) revision 1 of the MIPS DSP ASE.  *Note MIPS DSP
+     Built-in Functions::.  This option defines the preprocessor macro
+     '__mips_dsp'.  It also defines '__mips_dsp_rev' to 1.
+
+'-mdspr2'
+'-mno-dspr2'
+     Use (do not use) revision 2 of the MIPS DSP ASE.  *Note MIPS DSP
+     Built-in Functions::.  This option defines the preprocessor macros
+     '__mips_dsp' and '__mips_dspr2'.  It also defines '__mips_dsp_rev'
+     to 2.
+
+'-msmartmips'
+'-mno-smartmips'
+     Use (do not use) the MIPS SmartMIPS ASE.
+
+'-mpaired-single'
+'-mno-paired-single'
+     Use (do not use) paired-single floating-point instructions.  *Note
+     MIPS Paired-Single Support::.  This option requires hardware
+     floating-point support to be enabled.
+
+'-mdmx'
+'-mno-mdmx'
+     Use (do not use) MIPS Digital Media Extension instructions.  This
+     option can only be used when generating 64-bit code and requires
+     hardware floating-point support to be enabled.
+
+'-mips3d'
+'-mno-mips3d'
+     Use (do not use) the MIPS-3D ASE.  *Note MIPS-3D Built-in
+     Functions::.  The option '-mips3d' implies '-mpaired-single'.
+
+'-mmicromips'
+'-mno-micromips'
+     Generate (do not generate) microMIPS code.
+
+     MicroMIPS code generation can also be controlled on a per-function
+     basis by means of 'micromips' and 'nomicromips' attributes.  *Note
+     Function Attributes::, for more information.
+
+'-mmt'
+'-mno-mt'
+     Use (do not use) MT Multithreading instructions.
+
+'-mmcu'
+'-mno-mcu'
+     Use (do not use) the MIPS MCU ASE instructions.
+
+'-meva'
+'-mno-eva'
+     Use (do not use) the MIPS Enhanced Virtual Addressing instructions.
+
+'-mvirt'
+'-mno-virt'
+     Use (do not use) the MIPS Virtualization Application Specific
+     instructions.
+
+'-mlong64'
+     Force 'long' types to be 64 bits wide.  See '-mlong32' for an
+     explanation of the default and the way that the pointer size is
+     determined.
+
+'-mlong32'
+     Force 'long', 'int', and pointer types to be 32 bits wide.
+
+     The default size of 'int's, 'long's and pointers depends on the
+     ABI.  All the supported ABIs use 32-bit 'int's.  The n64 ABI uses
+     64-bit 'long's, as does the 64-bit EABI; the others use 32-bit
+     'long's.  Pointers are the same size as 'long's, or the same size
+     as integer registers, whichever is smaller.
+
+'-msym32'
+'-mno-sym32'
+     Assume (do not assume) that all symbols have 32-bit values,
+     regardless of the selected ABI.  This option is useful in
+     combination with '-mabi=64' and '-mno-abicalls' because it allows
+     GCC to generate shorter and faster references to symbolic
+     addresses.
+
+'-G NUM'
+     Put definitions of externally-visible data in a small data section
+     if that data is no bigger than NUM bytes.  GCC can then generate
+     more efficient accesses to the data; see '-mgpopt' for details.
+
+     The default '-G' option depends on the configuration.
+
+'-mlocal-sdata'
+'-mno-local-sdata'
+     Extend (do not extend) the '-G' behavior to local data too, such as
+     to static variables in C.  '-mlocal-sdata' is the default for all
+     configurations.
+
+     If the linker complains that an application is using too much small
+     data, you might want to try rebuilding the less
+     performance-critical parts with '-mno-local-sdata'.  You might also
+     want to build large libraries with '-mno-local-sdata', so that the
+     libraries leave more room for the main program.
+
+'-mextern-sdata'
+'-mno-extern-sdata'
+     Assume (do not assume) that externally-defined data is in a small
+     data section if the size of that data is within the '-G' limit.
+     '-mextern-sdata' is the default for all configurations.
+
+     If you compile a module MOD with '-mextern-sdata' '-G NUM'
+     '-mgpopt', and MOD references a variable VAR that is no bigger than
+     NUM bytes, you must make sure that VAR is placed in a small data
+     section.  If VAR is defined by another module, you must either
+     compile that module with a high-enough '-G' setting or attach a
+     'section' attribute to VAR's definition.  If VAR is common, you
+     must link the application with a high-enough '-G' setting.
+
+     The easiest way of satisfying these restrictions is to compile and
+     link every module with the same '-G' option.  However, you may wish
+     to build a library that supports several different small data
+     limits.  You can do this by compiling the library with the highest
+     supported '-G' setting and additionally using '-mno-extern-sdata'
+     to stop the library from making assumptions about
+     externally-defined data.
+
+'-mgpopt'
+'-mno-gpopt'
+     Use (do not use) GP-relative accesses for symbols that are known to
+     be in a small data section; see '-G', '-mlocal-sdata' and
+     '-mextern-sdata'.  '-mgpopt' is the default for all configurations.
+
+     '-mno-gpopt' is useful for cases where the '$gp' register might not
+     hold the value of '_gp'.  For example, if the code is part of a
+     library that might be used in a boot monitor, programs that call
+     boot monitor routines pass an unknown value in '$gp'.  (In such
+     situations, the boot monitor itself is usually compiled with
+     '-G0'.)
+
+     '-mno-gpopt' implies '-mno-local-sdata' and '-mno-extern-sdata'.
+
+'-membedded-data'
+'-mno-embedded-data'
+     Allocate variables to the read-only data section first if possible,
+     then next in the small data section if possible, otherwise in data.
+     This gives slightly slower code than the default, but reduces the
+     amount of RAM required when executing, and thus may be preferred
+     for some embedded systems.
+
+'-muninit-const-in-rodata'
+'-mno-uninit-const-in-rodata'
+     Put uninitialized 'const' variables in the read-only data section.
+     This option is only meaningful in conjunction with
+     '-membedded-data'.
+
+'-mcode-readable=SETTING'
+     Specify whether GCC may generate code that reads from executable
+     sections.  There are three possible settings:
+
+     '-mcode-readable=yes'
+          Instructions may freely access executable sections.  This is
+          the default setting.
+
+     '-mcode-readable=pcrel'
+          MIPS16 PC-relative load instructions can access executable
+          sections, but other instructions must not do so.  This option
+          is useful on 4KSc and 4KSd processors when the code TLBs have
+          the Read Inhibit bit set.  It is also useful on processors
+          that can be configured to have a dual instruction/data SRAM
+          interface and that, like the M4K, automatically redirect
+          PC-relative loads to the instruction RAM.
+
+     '-mcode-readable=no'
+          Instructions must not access executable sections.  This option
+          can be useful on targets that are configured to have a dual
+          instruction/data SRAM interface but that (unlike the M4K) do
+          not automatically redirect PC-relative loads to the
+          instruction RAM.
+
+'-msplit-addresses'
+'-mno-split-addresses'
+     Enable (disable) use of the '%hi()' and '%lo()' assembler
+     relocation operators.  This option has been superseded by
+     '-mexplicit-relocs' but is retained for backwards compatibility.
+
+'-mexplicit-relocs'
+'-mno-explicit-relocs'
+     Use (do not use) assembler relocation operators when dealing with
+     symbolic addresses.  The alternative, selected by
+     '-mno-explicit-relocs', is to use assembler macros instead.
+
+     '-mexplicit-relocs' is the default if GCC was configured to use an
+     assembler that supports relocation operators.
+
+'-mcheck-zero-division'
+'-mno-check-zero-division'
+     Trap (do not trap) on integer division by zero.
+
+     The default is '-mcheck-zero-division'.
+
+'-mdivide-traps'
+'-mdivide-breaks'
+     MIPS systems check for division by zero by generating either a
+     conditional trap or a break instruction.  Using traps 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 ('SIGFPE').  Use '-mdivide-traps'
+     to allow conditional traps on architectures that support them and
+     '-mdivide-breaks' to force the use of breaks.
+
+     The default is usually '-mdivide-traps', but this can be overridden
+     at configure time using '--with-divide=breaks'.  Divide-by-zero
+     checks can be completely disabled using '-mno-check-zero-division'.
+
+'-mmemcpy'
+'-mno-memcpy'
+     Force (do not force) the use of 'memcpy()' for non-trivial block
+     moves.  The default is '-mno-memcpy', which allows GCC to inline
+     most constant-sized copies.
+
+'-mlong-calls'
+'-mno-long-calls'
+     Disable (do not disable) use of the 'jal' instruction.  Calling
+     functions using 'jal' is more efficient but requires the caller and
+     callee to be in the same 256 megabyte segment.
+
+     This option has no effect on abicalls code.  The default is
+     '-mno-long-calls'.
+
+'-mmad'
+'-mno-mad'
+     Enable (disable) use of the 'mad', 'madu' and 'mul' instructions,
+     as provided by the R4650 ISA.
+
+'-mimadd'
+'-mno-imadd'
+     Enable (disable) use of the 'madd' and 'msub' integer instructions.
+     The default is '-mimadd' on architectures that support 'madd' and
+     'msub' except for the 74k architecture where it was found to
+     generate slower code.
+
+'-mfused-madd'
+'-mno-fused-madd'
+     Enable (disable) use of the floating-point multiply-accumulate
+     instructions, when they are available.  The default is
+     '-mfused-madd'.
+
+     On the R8000 CPU when multiply-accumulate instructions are used,
+     the intermediate product is calculated to infinite precision and is
+     not subject to the FCSR Flush to Zero bit.  This may be undesirable
+     in some circumstances.  On other processors the result is
+     numerically identical to the equivalent computation using separate
+     multiply, add, subtract and negate instructions.
+
+'-nocpp'
+     Tell the MIPS assembler to not run its preprocessor over user
+     assembler files (with a '.s' suffix) when assembling them.
+
+'-mfix-24k'
+'-mno-fix-24k'
+     Work around the 24K E48 (lost data on stores during refill) errata.
+     The workarounds are implemented by the assembler rather than by
+     GCC.
+
+'-mfix-r4000'
+'-mno-fix-r4000'
+     Work around certain R4000 CPU errata:
+        - A double-word or a variable shift may give an incorrect result
+          if executed immediately after starting an integer division.
+        - A double-word or a variable shift may give an incorrect result
+          if executed while an integer multiplication is in progress.
+        - An integer division may give an incorrect result if started in
+          a delay slot of a taken branch or a jump.
+
+'-mfix-r4400'
+'-mno-fix-r4400'
+     Work around certain R4400 CPU errata:
+        - A double-word or a variable shift may give an incorrect result
+          if executed immediately after starting an integer division.
+
+'-mfix-r10000'
+'-mno-fix-r10000'
+     Work around certain R10000 errata:
+        - 'll'/'sc' sequences may not behave atomically on revisions
+          prior to 3.0.  They may deadlock on revisions 2.6 and earlier.
+
+     This option can only be used if the target architecture supports
+     branch-likely instructions.  '-mfix-r10000' is the default when
+     '-march=r10000' is used; '-mno-fix-r10000' is the default
+     otherwise.
+
+'-mfix-rm7000'
+'-mno-fix-rm7000'
+     Work around the RM7000 'dmult'/'dmultu' errata.  The workarounds
+     are implemented by the assembler rather than by GCC.
+
+'-mfix-vr4120'
+'-mno-fix-vr4120'
+     Work around certain VR4120 errata:
+        - 'dmultu' does not always produce the correct result.
+        - 'div' and 'ddiv' do not always produce the correct result if
+          one of the operands is negative.
+     The workarounds for the division errata rely on special functions
+     in 'libgcc.a'.  At present, these functions are only provided by
+     the 'mips64vr*-elf' configurations.
+
+     Other VR4120 errata require a NOP to be inserted between certain
+     pairs of instructions.  These errata are handled by the assembler,
+     not by GCC itself.
+
+'-mfix-vr4130'
+     Work around the VR4130 'mflo'/'mfhi' errata.  The workarounds are
+     implemented by the assembler rather than by GCC, although GCC
+     avoids using 'mflo' and 'mfhi' if the VR4130 'macc', 'macchi',
+     'dmacc' and 'dmacchi' instructions are available instead.
+
+'-mfix-sb1'
+'-mno-fix-sb1'
+     Work around certain SB-1 CPU core errata.  (This flag currently
+     works around the SB-1 revision 2 "F1" and "F2" floating-point
+     errata.)
+
+'-mr10k-cache-barrier=SETTING'
+     Specify whether GCC should insert cache barriers to avoid the
+     side-effects of speculation on R10K processors.
+
+     In common with many processors, the R10K tries to predict the
+     outcome of a conditional branch and speculatively executes
+     instructions from the "taken" branch.  It later aborts these
+     instructions if the predicted outcome is wrong.  However, on the
+     R10K, even aborted instructions can have side effects.
+
+     This problem only affects kernel stores and, depending on the
+     system, kernel loads.  As an example, a speculatively-executed
+     store may load the target memory into cache and mark the cache line
+     as dirty, even if the store itself is later aborted.  If a DMA
+     operation writes to the same area of memory before the "dirty" line
+     is flushed, the cached data overwrites the DMA-ed data.  See the
+     R10K processor manual for a full description, including other
+     potential problems.
+
+     One workaround is to insert cache barrier instructions before every
+     memory access that might be speculatively executed and that might
+     have side effects even if aborted.  '-mr10k-cache-barrier=SETTING'
+     controls GCC's implementation of this workaround.  It assumes that
+     aborted accesses to any byte in the following regions does not have
+     side effects:
+
+       1. the memory occupied by the current function's stack frame;
+
+       2. the memory occupied by an incoming stack argument;
+
+       3. the memory occupied by an object with a link-time-constant
+          address.
+
+     It is the kernel's responsibility to ensure that speculative
+     accesses to these regions are indeed safe.
+
+     If the input program contains a function declaration such as:
+
+          void foo (void);
+
+     then the implementation of 'foo' must allow 'j foo' and 'jal foo'
+     to be executed speculatively.  GCC honors this restriction for
+     functions it compiles itself.  It expects non-GCC functions (such
+     as hand-written assembly code) to do the same.
+
+     The option has three forms:
+
+     '-mr10k-cache-barrier=load-store'
+          Insert a cache barrier before a load or store that might be
+          speculatively executed and that might have side effects even
+          if aborted.
+
+     '-mr10k-cache-barrier=store'
+          Insert a cache barrier before a store that might be
+          speculatively executed and that might have side effects even
+          if aborted.
+
+     '-mr10k-cache-barrier=none'
+          Disable the insertion of cache barriers.  This is the default
+          setting.
+
+'-mflush-func=FUNC'
+'-mno-flush-func'
+     Specifies the function to call to flush the I and D caches, or to
+     not call any such function.  If called, the function must take the
+     same arguments as the common '_flush_func()', that is, the address
+     of the memory range for which the cache is being flushed, the size
+     of the memory range, and the number 3 (to flush both caches).  The
+     default depends on the target GCC was configured for, but commonly
+     is either '_flush_func' or '__cpu_flush'.
+
+'mbranch-cost=NUM'
+     Set the cost of branches to roughly NUM "simple" instructions.
+     This cost is only a heuristic and is not guaranteed to produce
+     consistent results across releases.  A zero cost redundantly
+     selects the default, which is based on the '-mtune' setting.
+
+'-mbranch-likely'
+'-mno-branch-likely'
+     Enable or disable use of Branch Likely instructions, regardless of
+     the default for the selected architecture.  By default, Branch
+     Likely instructions may be generated if they are supported by the
+     selected architecture.  An exception is for the MIPS32 and MIPS64
+     architectures and processors that implement those architectures;
+     for those, Branch Likely instructions are not be generated by
+     default because the MIPS32 and MIPS64 architectures specifically
+     deprecate their use.
+
+'-mfp-exceptions'
+'-mno-fp-exceptions'
+     Specifies whether FP exceptions are enabled.  This affects how FP
+     instructions are scheduled for some processors.  The default is
+     that FP exceptions are enabled.
+
+     For instance, on the SB-1, if FP exceptions are disabled, and we
+     are emitting 64-bit code, then we can use both FP pipes.
+     Otherwise, we can only use one FP pipe.
+
+'-mvr4130-align'
+'-mno-vr4130-align'
+     The VR4130 pipeline is two-way superscalar, but can only issue two
+     instructions together if the first one is 8-byte aligned.  When
+     this option is enabled, GCC aligns pairs of instructions that it
+     thinks should execute in parallel.
+
+     This option only has an effect when optimizing for the VR4130.  It
+     normally makes code faster, but at the expense of making it bigger.
+     It is enabled by default at optimization level '-O3'.
+
+'-msynci'
+'-mno-synci'
+     Enable (disable) generation of 'synci' instructions on
+     architectures that support it.  The 'synci' instructions (if
+     enabled) are generated when '__builtin___clear_cache()' is
+     compiled.
+
+     This option defaults to '-mno-synci', but the default can be
+     overridden by configuring with '--with-synci'.
+
+     When compiling code for single processor systems, it is generally
+     safe to use 'synci'.  However, on many multi-core (SMP) systems, it
+     does not invalidate the instruction caches on all cores and may
+     lead to undefined behavior.
+
+'-mrelax-pic-calls'
+'-mno-relax-pic-calls'
+     Try to turn PIC calls that are normally dispatched via register
+     '$25' into direct calls.  This is only possible if the linker can
+     resolve the destination at link-time and if the destination is
+     within range for a direct call.
+
+     '-mrelax-pic-calls' is the default if GCC was configured to use an
+     assembler and a linker that support the '.reloc' assembly directive
+     and '-mexplicit-relocs' is in effect.  With '-mno-explicit-relocs',
+     this optimization can be performed by the assembler and the linker
+     alone without help from the compiler.
+
+'-mmcount-ra-address'
+'-mno-mcount-ra-address'
+     Emit (do not emit) code that allows '_mcount' to modify the calling
+     function's return address.  When enabled, this option extends the
+     usual '_mcount' interface with a new RA-ADDRESS parameter, which
+     has type 'intptr_t *' and is passed in register '$12'.  '_mcount'
+     can then modify the return address by doing both of the following:
+        * Returning the new address in register '$31'.
+        * Storing the new address in '*RA-ADDRESS', if RA-ADDRESS is
+          nonnull.
+
+     The default is '-mno-mcount-ra-address'.
+
+
+File: gcc.info,  Node: MMIX Options,  Next: MN10300 Options,  Prev: MIPS Options,  Up: Submodel Options
+
+3.17.28 MMIX Options
+--------------------
+
+These options are defined for the MMIX:
+
+'-mlibfuncs'
+'-mno-libfuncs'
+     Specify that intrinsic library functions are being compiled,
+     passing all values in registers, no matter the size.
+
+'-mepsilon'
+'-mno-epsilon'
+     Generate floating-point comparison instructions that compare with
+     respect to the 'rE' epsilon register.
+
+'-mabi=mmixware'
+'-mabi=gnu'
+     Generate code that passes function parameters and return values
+     that (in the called function) are seen as registers '$0' and up, as
+     opposed to the GNU ABI which uses global registers '$231' and up.
+
+'-mzero-extend'
+'-mno-zero-extend'
+     When reading data from memory in sizes shorter than 64 bits, use
+     (do not use) zero-extending load instructions by default, rather
+     than sign-extending ones.
+
+'-mknuthdiv'
+'-mno-knuthdiv'
+     Make the result of a division yielding a remainder have the same
+     sign as the divisor.  With the default, '-mno-knuthdiv', the sign
+     of the remainder follows the sign of the dividend.  Both methods
+     are arithmetically valid, the latter being almost exclusively used.
+
+'-mtoplevel-symbols'
+'-mno-toplevel-symbols'
+     Prepend (do not prepend) a ':' to all global symbols, so the
+     assembly code can be used with the 'PREFIX' assembly directive.
+
+'-melf'
+     Generate an executable in the ELF format, rather than the default
+     'mmo' format used by the 'mmix' simulator.
+
+'-mbranch-predict'
+'-mno-branch-predict'
+     Use (do not use) the probable-branch instructions, when static
+     branch prediction indicates a probable branch.
+
+'-mbase-addresses'
+'-mno-base-addresses'
+     Generate (do not generate) code that uses _base addresses_.  Using
+     a base address automatically generates a request (handled by the
+     assembler and the linker) for a constant to be set up in a global
+     register.  The register is used for one or more base address
+     requests within the range 0 to 255 from the value held in the
+     register.  The generally leads to short and fast code, but the
+     number of different data items that can be addressed is limited.
+     This means that a program that uses lots of static data may require
+     '-mno-base-addresses'.
+
+'-msingle-exit'
+'-mno-single-exit'
+     Force (do not force) generated code to have a single exit point in
+     each function.
+
+
+File: gcc.info,  Node: MN10300 Options,  Next: Moxie Options,  Prev: MMIX Options,  Up: Submodel Options
+
+3.17.29 MN10300 Options
+-----------------------
+
+These '-m' options are defined for Matsushita MN10300 architectures:
+
+'-mmult-bug'
+     Generate code to avoid bugs in the multiply instructions for the
+     MN10300 processors.  This is the default.
+
+'-mno-mult-bug'
+     Do not generate code to avoid bugs in the multiply instructions for
+     the MN10300 processors.
+
+'-mam33'
+     Generate code using features specific to the AM33 processor.
+
+'-mno-am33'
+     Do not generate code using features specific to the AM33 processor.
+     This is the default.
+
+'-mam33-2'
+     Generate code using features specific to the AM33/2.0 processor.
+
+'-mam34'
+     Generate code using features specific to the AM34 processor.
+
+'-mtune=CPU-TYPE'
+     Use the timing characteristics of the indicated CPU type when
+     scheduling instructions.  This does not change the targeted
+     processor type.  The CPU type must be one of 'mn10300', 'am33',
+     'am33-2' or 'am34'.
+
+'-mreturn-pointer-on-d0'
+     When generating a function that returns a pointer, return the
+     pointer in both 'a0' and 'd0'.  Otherwise, the pointer is returned
+     only in 'a0', and attempts to call such functions without a
+     prototype result in errors.  Note that this option is on by
+     default; use '-mno-return-pointer-on-d0' to disable it.
+
+'-mno-crt0'
+     Do not link in the C run-time initialization object file.
+
+'-mrelax'
+     Indicate to the linker that it should perform a relaxation
+     optimization pass to shorten branches, calls and absolute memory
+     addresses.  This option only has an effect when used on the command
+     line for the final link step.
+
+     This option makes symbolic debugging impossible.
+
+'-mliw'
+     Allow the compiler to generate _Long Instruction Word_ instructions
+     if the target is the 'AM33' or later.  This is the default.  This
+     option defines the preprocessor macro '__LIW__'.
+
+'-mnoliw'
+     Do not allow the compiler to generate _Long Instruction Word_
+     instructions.  This option defines the preprocessor macro
+     '__NO_LIW__'.
+
+'-msetlb'
+     Allow the compiler to generate the _SETLB_ and _Lcc_ instructions
+     if the target is the 'AM33' or later.  This is the default.  This
+     option defines the preprocessor macro '__SETLB__'.
+
+'-mnosetlb'
+     Do not allow the compiler to generate _SETLB_ or _Lcc_
+     instructions.  This option defines the preprocessor macro
+     '__NO_SETLB__'.
+
+
+File: gcc.info,  Node: Moxie Options,  Next: MSP430 Options,  Prev: MN10300 Options,  Up: Submodel Options
+
+3.17.30 Moxie Options
+---------------------
+
+'-meb'
+     Generate big-endian code.  This is the default for 'moxie-*-*'
+     configurations.
+
+'-mel'
+     Generate little-endian code.
+
+'-mno-crt0'
+     Do not link in the C run-time initialization object file.
+
+
+File: gcc.info,  Node: MSP430 Options,  Next: NDS32 Options,  Prev: Moxie Options,  Up: Submodel Options
+
+3.17.31 MSP430 Options
+----------------------
+
+These options are defined for the MSP430:
+
+'-masm-hex'
+     Force assembly output to always use hex constants.  Normally such
+     constants are signed decimals, but this option is available for
+     testsuite and/or aesthetic purposes.
+
+'-mmcu='
+     Select the MCU to target.  This is used to create a C preprocessor
+     symbol based upon the MCU name, converted to upper case and pre-
+     and post- fixed with '__'.  This in turn will be used by the
+     'msp430.h' header file to select an MCU specific supplimentary
+     header file.
+
+     The option also sets the ISA to use.  If the MCU name is one that
+     is known to only support the 430 ISA then that is selected,
+     otherwise the 430X ISA is selected.  A generic MCU name of 'msp430'
+     can also be used to select the 430 ISA. Similarly the generic
+     'msp430x' MCU name will select the 430X ISA.
+
+     In addition an MCU specific linker script will be added to the
+     linker command line.  The script's name is the name of the MCU with
+     '.ld' appended.  Thus specifying '-mmcu=xxx' on the gcc command
+     line will define the C preprocessor symbol '__XXX__' and cause the
+     linker to search for a script called 'xxx.ld'.
+
+     This option is also passed on to the assembler.
+
+'-mcpu='
+     Specifies the ISA to use.  Accepted values are 'msp430', 'msp430x'
+     and 'msp430xv2'.  This option is deprecated.  The '-mmcu=' option
+     should be used to select the ISA.
+
+'-msim'
+     Link to the simulator runtime libraries and linker script.
+     Overrides any scripts that would be selected by the '-mmcu='
+     option.
+
+'-mlarge'
+     Use large-model addressing (20-bit pointers, 32-bit 'size_t').
+
+'-msmall'
+     Use small-model addressing (16-bit pointers, 16-bit 'size_t').
+
+'-mrelax'
+     This option is passed to the assembler and linker, and allows the
+     linker to perform certain optimizations that cannot be done until
+     the final link.
+
+
+File: gcc.info,  Node: NDS32 Options,  Next: Nios II Options,  Prev: MSP430 Options,  Up: Submodel Options
+
+3.17.32 NDS32 Options
+---------------------
+
+These options are defined for NDS32 implementations:
+
+'-mbig-endian'
+     Generate code in big-endian mode.
+
+'-mlittle-endian'
+     Generate code in little-endian mode.
+
+'-mreduced-regs'
+     Use reduced-set registers for register allocation.
+
+'-mfull-regs'
+     Use full-set registers for register allocation.
+
+'-mcmov'
+     Generate conditional move instructions.
+
+'-mno-cmov'
+     Do not generate conditional move instructions.
+
+'-mperf-ext'
+     Generate performance extension instructions.
+
+'-mno-perf-ext'
+     Do not generate performance extension instructions.
+
+'-mv3push'
+     Generate v3 push25/pop25 instructions.
+
+'-mno-v3push'
+     Do not generate v3 push25/pop25 instructions.
+
+'-m16-bit'
+     Generate 16-bit instructions.
+
+'-mno-16-bit'
+     Do not generate 16-bit instructions.
+
+'-mgp-direct'
+     Generate GP base instructions directly.
+
+'-mno-gp-direct'
+     Do no generate GP base instructions directly.
+
+'-misr-vector-size=NUM'
+     Specify the size of each interrupt vector, which must be 4 or 16.
+
+'-mcache-block-size=NUM'
+     Specify the size of each cache block, which must be a power of 2
+     between 4 and 512.
+
+'-march=ARCH'
+     Specify the name of the target architecture.
+
+'-mforce-fp-as-gp'
+     Prevent $fp being allocated during register allocation so that
+     compiler is able to force performing fp-as-gp optimization.
+
+'-mforbid-fp-as-gp'
+     Forbid using $fp to access static and global variables.  This
+     option strictly forbids fp-as-gp optimization regardless of
+     '-mforce-fp-as-gp'.
+
+'-mex9'
+     Use special directives to guide linker doing ex9 optimization.
+
+'-mctor-dtor'
+     Enable constructor/destructor feature.
+
+'-mrelax'
+     Guide linker to relax instructions.
+
+
+File: gcc.info,  Node: Nios II Options,  Next: PDP-11 Options,  Prev: NDS32 Options,  Up: Submodel Options
+
+3.17.33 Nios II Options
+-----------------------
+
+These are the options defined for the Altera Nios II processor.
+
+'-G NUM'
+     Put global and static objects less than or equal to NUM bytes into
+     the small data or BSS sections instead of the normal data or BSS
+     sections.  The default value of NUM is 8.
+
+'-mgpopt'
+'-mno-gpopt'
+     Generate (do not generate) GP-relative accesses for objects in the
+     small data or BSS sections.  The default is '-mgpopt' except when
+     '-fpic' or '-fPIC' is specified to generate position-independent
+     code.  Note that the Nios II ABI does not permit GP-relative
+     accesses from shared libraries.
+
+     You may need to specify '-mno-gpopt' explicitly when building
+     programs that include large amounts of small data, including large
+     GOT data sections.  In this case, the 16-bit offset for GP-relative
+     addressing may not be large enough to allow access to the entire
+     small data section.
+
+'-mel'
+'-meb'
+     Generate little-endian (default) or big-endian (experimental) code,
+     respectively.
+
+'-mbypass-cache'
+'-mno-bypass-cache'
+     Force all load and store instructions to always bypass cache by
+     using I/O variants of the instructions.  The default is not to
+     bypass the cache.
+
+'-mno-cache-volatile'
+'-mcache-volatile'
+     Volatile memory access bypass the cache using the I/O variants of
+     the load and store instructions.  The default is not to bypass the
+     cache.
+
+'-mno-fast-sw-div'
+'-mfast-sw-div'
+     Do not use table-based fast divide for small numbers.  The default
+     is to use the fast divide at '-O3' and above.
+
+'-mno-hw-mul'
+'-mhw-mul'
+'-mno-hw-mulx'
+'-mhw-mulx'
+'-mno-hw-div'
+'-mhw-div'
+     Enable or disable emitting 'mul', 'mulx' and 'div' family of
+     instructions by the compiler.  The default is to emit 'mul' and not
+     emit 'div' and 'mulx'.
+
+'-mcustom-INSN=N'
+'-mno-custom-INSN'
+     Each '-mcustom-INSN=N' option enables use of a custom instruction
+     with encoding N when generating code that uses INSN.  For example,
+     '-mcustom-fadds=253' generates custom instruction 253 for
+     single-precision floating-point add operations instead of the
+     default behavior of using a library call.
+
+     The following values of INSN are supported.  Except as otherwise
+     noted, floating-point operations are expected to be implemented
+     with normal IEEE 754 semantics and correspond directly to the C
+     operators or the equivalent GCC built-in functions (*note Other
+     Builtins::).
+
+     Single-precision floating point:
+
+     'fadds', 'fsubs', 'fdivs', 'fmuls'
+          Binary arithmetic operations.
+
+     'fnegs'
+          Unary negation.
+
+     'fabss'
+          Unary absolute value.
+
+     'fcmpeqs', 'fcmpges', 'fcmpgts', 'fcmples', 'fcmplts', 'fcmpnes'
+          Comparison operations.
+
+     'fmins', 'fmaxs'
+          Floating-point minimum and maximum.  These instructions are
+          only generated if '-ffinite-math-only' is specified.
+
+     'fsqrts'
+          Unary square root operation.
+
+     'fcoss', 'fsins', 'ftans', 'fatans', 'fexps', 'flogs'
+          Floating-point trigonometric and exponential functions.  These
+          instructions are only generated if
+          '-funsafe-math-optimizations' is also specified.
+
+     Double-precision floating point:
+
+     'faddd', 'fsubd', 'fdivd', 'fmuld'
+          Binary arithmetic operations.
+
+     'fnegd'
+          Unary negation.
+
+     'fabsd'
+          Unary absolute value.
+
+     'fcmpeqd', 'fcmpged', 'fcmpgtd', 'fcmpled', 'fcmpltd', 'fcmpned'
+          Comparison operations.
+
+     'fmind', 'fmaxd'
+          Double-precision minimum and maximum.  These instructions are
+          only generated if '-ffinite-math-only' is specified.
+
+     'fsqrtd'
+          Unary square root operation.
+
+     'fcosd', 'fsind', 'ftand', 'fatand', 'fexpd', 'flogd'
+          Double-precision trigonometric and exponential functions.
+          These instructions are only generated if
+          '-funsafe-math-optimizations' is also specified.
+
+     Conversions:
+     'fextsd'
+          Conversion from single precision to double precision.
+
+     'ftruncds'
+          Conversion from double precision to single precision.
+
+     'fixsi', 'fixsu', 'fixdi', 'fixdu'
+          Conversion from floating point to signed or unsigned integer
+          types, with truncation towards zero.
+
+     'floatis', 'floatus', 'floatid', 'floatud'
+          Conversion from signed or unsigned integer types to
+          floating-point types.
+
+     In addition, all of the following transfer instructions for
+     internal registers X and Y must be provided to use any of the
+     double-precision floating-point instructions.  Custom instructions
+     taking two double-precision source operands expect the first
+     operand in the 64-bit register X. The other operand (or only
+     operand of a unary operation) is given to the custom arithmetic
+     instruction with the least significant half in source register SRC1
+     and the most significant half in SRC2.  A custom instruction that
+     returns a double-precision result returns the most significant 32
+     bits in the destination register and the other half in 32-bit
+     register Y. GCC automatically generates the necessary code
+     sequences to write register X and/or read register Y when
+     double-precision floating-point instructions are used.
+
+     'fwrx'
+          Write SRC1 into the least significant half of X and SRC2 into
+          the most significant half of X.
+
+     'fwry'
+          Write SRC1 into Y.
+
+     'frdxhi', 'frdxlo'
+          Read the most or least (respectively) significant half of X
+          and store it in DEST.
+
+     'frdy'
+          Read the value of Y and store it into DEST.
+
+     Note that you can gain more local control over generation of Nios
+     II custom instructions by using the 'target("custom-INSN=N")' and
+     'target("no-custom-INSN")' function attributes (*note Function
+     Attributes::) or pragmas (*note Function Specific Option
+     Pragmas::).
+
+'-mcustom-fpu-cfg=NAME'
+
+     This option enables a predefined, named set of custom instruction
+     encodings (see '-mcustom-INSN' above).  Currently, the following
+     sets are defined:
+
+     '-mcustom-fpu-cfg=60-1' is equivalent to:
+          -mcustom-fmuls=252
+          -mcustom-fadds=253
+          -mcustom-fsubs=254
+          -fsingle-precision-constant
+
+     '-mcustom-fpu-cfg=60-2' is equivalent to:
+          -mcustom-fmuls=252
+          -mcustom-fadds=253
+          -mcustom-fsubs=254
+          -mcustom-fdivs=255
+          -fsingle-precision-constant
+
+     '-mcustom-fpu-cfg=72-3' is equivalent to:
+          -mcustom-floatus=243
+          -mcustom-fixsi=244
+          -mcustom-floatis=245
+          -mcustom-fcmpgts=246
+          -mcustom-fcmples=249
+          -mcustom-fcmpeqs=250
+          -mcustom-fcmpnes=251
+          -mcustom-fmuls=252
+          -mcustom-fadds=253
+          -mcustom-fsubs=254
+          -mcustom-fdivs=255
+          -fsingle-precision-constant
+
+     Custom instruction assignments given by individual '-mcustom-INSN='
+     options override those given by '-mcustom-fpu-cfg=', regardless of
+     the order of the options on the command line.
+
+     Note that you can gain more local control over selection of a FPU
+     configuration by using the 'target("custom-fpu-cfg=NAME")' function
+     attribute (*note Function Attributes::) or pragma (*note Function
+     Specific Option Pragmas::).
+
+ These additional '-m' options are available for the Altera Nios II ELF
+(bare-metal) target:
+
+'-mhal'
+     Link with HAL BSP. This suppresses linking with the GCC-provided C
+     runtime startup and termination code, and is typically used in
+     conjunction with '-msys-crt0=' to specify the location of the
+     alternate startup code provided by the HAL BSP.
+
+'-msmallc'
+     Link with a limited version of the C library, '-lsmallc', rather
+     than Newlib.
+
+'-msys-crt0=STARTFILE'
+     STARTFILE is the file name of the startfile (crt0) to use when
+     linking.  This option is only useful in conjunction with '-mhal'.
+
+'-msys-lib=SYSTEMLIB'
+     SYSTEMLIB is the library name of the library that provides
+     low-level system calls required by the C library, e.g.  'read' and
+     'write'.  This option is typically used to link with a library
+     provided by a HAL BSP.
+
+
+File: gcc.info,  Node: PDP-11 Options,  Next: picoChip Options,  Prev: Nios II Options,  Up: Submodel Options
+
+3.17.34 PDP-11 Options
+----------------------
+
+These options are defined for the PDP-11:
+
+'-mfpu'
+     Use hardware FPP floating point.  This is the default.  (FIS
+     floating point on the PDP-11/40 is not supported.)
+
+'-msoft-float'
+     Do not use hardware floating point.
+
+'-mac0'
+     Return floating-point results in ac0 (fr0 in Unix assembler
+     syntax).
+
+'-mno-ac0'
+     Return floating-point results in memory.  This is the default.
+
+'-m40'
+     Generate code for a PDP-11/40.
+
+'-m45'
+     Generate code for a PDP-11/45.  This is the default.
+
+'-m10'
+     Generate code for a PDP-11/10.
+
+'-mbcopy-builtin'
+     Use inline 'movmemhi' patterns for copying memory.  This is the
+     default.
+
+'-mbcopy'
+     Do not use inline 'movmemhi' patterns for copying memory.
+
+'-mint16'
+'-mno-int32'
+     Use 16-bit 'int'.  This is the default.
+
+'-mint32'
+'-mno-int16'
+     Use 32-bit 'int'.
+
+'-mfloat64'
+'-mno-float32'
+     Use 64-bit 'float'.  This is the default.
+
+'-mfloat32'
+'-mno-float64'
+     Use 32-bit 'float'.
+
+'-mabshi'
+     Use 'abshi2' pattern.  This is the default.
+
+'-mno-abshi'
+     Do not use 'abshi2' pattern.
+
+'-mbranch-expensive'
+     Pretend that branches are expensive.  This is for experimenting
+     with code generation only.
+
+'-mbranch-cheap'
+     Do not pretend that branches are expensive.  This is the default.
+
+'-munix-asm'
+     Use Unix assembler syntax.  This is the default when configured for
+     'pdp11-*-bsd'.
+
+'-mdec-asm'
+     Use DEC assembler syntax.  This is the default when configured for
+     any PDP-11 target other than 'pdp11-*-bsd'.
+
+
+File: gcc.info,  Node: picoChip Options,  Next: PowerPC Options,  Prev: PDP-11 Options,  Up: Submodel Options
+
+3.17.35 picoChip Options
+------------------------
+
+These '-m' options are defined for picoChip implementations:
+
+'-mae=AE_TYPE'
+     Set the instruction set, register set, and instruction scheduling
+     parameters for array element type AE_TYPE.  Supported values for
+     AE_TYPE are 'ANY', 'MUL', and 'MAC'.
+
+     '-mae=ANY' selects a completely generic AE type.  Code generated
+     with this option runs on any of the other AE types.  The code is
+     not as efficient as it would be if compiled for a specific AE type,
+     and some types of operation (e.g., multiplication) do not work
+     properly on all types of AE.
+
+     '-mae=MUL' selects a MUL AE type.  This is the most useful AE type
+     for compiled code, and is the default.
+
+     '-mae=MAC' selects a DSP-style MAC AE. Code compiled with this
+     option may suffer from poor performance of byte (char)
+     manipulation, since the DSP AE does not provide hardware support
+     for byte load/stores.
+
+'-msymbol-as-address'
+     Enable the compiler to directly use a symbol name as an address in
+     a load/store instruction, without first loading it into a register.
+     Typically, the use of this option generates larger programs, which
+     run faster than when the option isn't used.  However, the results
+     vary from program to program, so it is left as a user option,
+     rather than being permanently enabled.
+
+'-mno-inefficient-warnings'
+     Disables warnings about the generation of inefficient code.  These
+     warnings can be generated, for example, when compiling code that
+     performs byte-level memory operations on the MAC AE type.  The MAC
+     AE has no hardware support for byte-level memory operations, so all
+     byte load/stores must be synthesized from word load/store
+     operations.  This is inefficient and a warning is generated to
+     indicate that you should rewrite the code to avoid byte operations,
+     or to target an AE type that has the necessary hardware support.
+     This option disables these warnings.
+
+
+File: gcc.info,  Node: PowerPC Options,  Next: RL78 Options,  Prev: picoChip Options,  Up: Submodel Options
+
+3.17.36 PowerPC Options
+-----------------------
+
+These are listed under *Note RS/6000 and PowerPC Options::.
+
+
+File: gcc.info,  Node: RL78 Options,  Next: RS/6000 and PowerPC Options,  Prev: PowerPC Options,  Up: Submodel Options
+
+3.17.37 RL78 Options
+--------------------
+
+'-msim'
+     Links in additional target libraries to support operation within a
+     simulator.
+
+'-mmul=none'
+'-mmul=g13'
+'-mmul=rl78'
+     Specifies the type of hardware multiplication support to be used.
+     The default is 'none', which uses software multiplication
+     functions.  The 'g13' option is for the hardware multiply/divide
+     peripheral only on the RL78/G13 targets.  The 'rl78' option is for
+     the standard hardware multiplication defined in the RL78 software
+     manual.
+
+
+File: gcc.info,  Node: RS/6000 and PowerPC Options,  Next: RX Options,  Prev: RL78 Options,  Up: Submodel Options
+
+3.17.38 IBM RS/6000 and PowerPC Options
+---------------------------------------
+
+These '-m' options are defined for the IBM RS/6000 and PowerPC:
+'-mpowerpc-gpopt'
+'-mno-powerpc-gpopt'
+'-mpowerpc-gfxopt'
+'-mno-powerpc-gfxopt'
+'-mpowerpc64'
+'-mno-powerpc64'
+'-mmfcrf'
+'-mno-mfcrf'
+'-mpopcntb'
+'-mno-popcntb'
+'-mpopcntd'
+'-mno-popcntd'
+'-mfprnd'
+'-mno-fprnd'
+'-mcmpb'
+'-mno-cmpb'
+'-mmfpgpr'
+'-mno-mfpgpr'
+'-mhard-dfp'
+'-mno-hard-dfp'
+     You use these options to specify which instructions are available
+     on the processor you are using.  The default value of these options
+     is determined when configuring GCC.  Specifying the
+     '-mcpu=CPU_TYPE' overrides the specification of these options.  We
+     recommend you use the '-mcpu=CPU_TYPE' option rather than the
+     options listed above.
+
+     Specifying '-mpowerpc-gpopt' allows GCC to use the optional PowerPC
+     architecture instructions in the General Purpose group, including
+     floating-point square root.  Specifying '-mpowerpc-gfxopt' allows
+     GCC to use the optional PowerPC architecture instructions in the
+     Graphics group, including floating-point select.
+
+     The '-mmfcrf' option allows GCC to generate the move from condition
+     register field instruction implemented on the POWER4 processor and
+     other processors that support the PowerPC V2.01 architecture.  The
+     '-mpopcntb' option allows GCC to generate the popcount and
+     double-precision FP reciprocal estimate instruction implemented on
+     the POWER5 processor and other processors that support the PowerPC
+     V2.02 architecture.  The '-mpopcntd' option allows GCC to generate
+     the popcount instruction implemented on the POWER7 processor and
+     other processors that support the PowerPC V2.06 architecture.  The
+     '-mfprnd' option allows GCC to generate the FP round to integer
+     instructions implemented on the POWER5+ processor and other
+     processors that support the PowerPC V2.03 architecture.  The
+     '-mcmpb' option allows GCC to generate the compare bytes
+     instruction implemented on the POWER6 processor and other
+     processors that support the PowerPC V2.05 architecture.  The
+     '-mmfpgpr' option allows GCC to generate the FP move to/from
+     general-purpose register instructions implemented on the POWER6X
+     processor and other processors that support the extended PowerPC
+     V2.05 architecture.  The '-mhard-dfp' option allows GCC to generate
+     the decimal floating-point instructions implemented on some POWER
+     processors.
+
+     The '-mpowerpc64' option allows GCC to generate the additional
+     64-bit instructions that are found in the full PowerPC64
+     architecture and to treat GPRs as 64-bit, doubleword quantities.
+     GCC defaults to '-mno-powerpc64'.
+
+'-mcpu=CPU_TYPE'
+     Set architecture type, register usage, and instruction scheduling
+     parameters for machine type CPU_TYPE.  Supported values for
+     CPU_TYPE are '401', '403', '405', '405fp', '440', '440fp', '464',
+     '464fp', '476', '476fp', '505', '601', '602', '603', '603e', '604',
+     '604e', '620', '630', '740', '7400', '7450', '750', '801', '821',
+     '823', '860', '970', '8540', 'a2', 'e300c2', 'e300c3', 'e500mc',
+     'e500mc64', 'e5500', 'e6500', 'ec603e', 'G3', 'G4', 'G5', 'titan',
+     'power3', 'power4', 'power5', 'power5+', 'power6', 'power6x',
+     'power7', 'power8', 'powerpc', 'powerpc64', and 'rs64'.
+
+     '-mcpu=powerpc', and '-mcpu=powerpc64' specify pure 32-bit PowerPC
+     and 64-bit PowerPC architecture machine types, with an appropriate,
+     generic processor model assumed for scheduling purposes.
+
+     The other options specify a specific processor.  Code generated
+     under those options runs best on that processor, and may not run at
+     all on others.
+
+     The '-mcpu' options automatically enable or disable the following
+     options:
+
+          -maltivec  -mfprnd  -mhard-float  -mmfcrf  -mmultiple
+          -mpopcntb -mpopcntd  -mpowerpc64
+          -mpowerpc-gpopt  -mpowerpc-gfxopt  -msingle-float -mdouble-float
+          -msimple-fpu -mstring  -mmulhw  -mdlmzb  -mmfpgpr -mvsx
+          -mcrypto -mdirect-move -mpower8-fusion -mpower8-vector
+          -mquad-memory -mquad-memory-atomic
+
+     The particular options set for any particular CPU varies between
+     compiler versions, depending on what setting seems to produce
+     optimal code for that CPU; it doesn't necessarily reflect the
+     actual hardware's capabilities.  If you wish to set an individual
+     option to a particular value, you may specify it after the '-mcpu'
+     option, like '-mcpu=970 -mno-altivec'.
+
+     On AIX, the '-maltivec' and '-mpowerpc64' options are not enabled
+     or disabled by the '-mcpu' option at present because AIX does not
+     have full support for these options.  You may still enable or
+     disable them individually if you're sure it'll work in your
+     environment.
+
+'-mtune=CPU_TYPE'
+     Set the instruction scheduling parameters for machine type
+     CPU_TYPE, but do not set the architecture type or register usage,
+     as '-mcpu=CPU_TYPE' does.  The same values for CPU_TYPE are used
+     for '-mtune' as for '-mcpu'.  If both are specified, the code
+     generated uses the architecture and registers set by '-mcpu', but
+     the scheduling parameters set by '-mtune'.
+
+'-mcmodel=small'
+     Generate PowerPC64 code for the small model: The TOC is limited to
+     64k.
+
+'-mcmodel=medium'
+     Generate PowerPC64 code for the medium model: The TOC and other
+     static data may be up to a total of 4G in size.
+
+'-mcmodel=large'
+     Generate PowerPC64 code for the large model: The TOC may be up to
+     4G in size.  Other data and code is only limited by the 64-bit
+     address space.
+
+'-maltivec'
+'-mno-altivec'
+     Generate code that uses (does not use) AltiVec instructions, and
+     also enable the use of built-in functions that allow more direct
+     access to the AltiVec instruction set.  You may also need to set
+     '-mabi=altivec' to adjust the current ABI with AltiVec ABI
+     enhancements.
+
+     When '-maltivec' is used, rather than '-maltivec=le' or
+     '-maltivec=be', the element order for Altivec intrinsics such as
+     'vec_splat', 'vec_extract', and 'vec_insert' will match array
+     element order corresponding to the endianness of the target.  That
+     is, element zero identifies the leftmost element in a vector
+     register when targeting a big-endian platform, and identifies the
+     rightmost element in a vector register when targeting a
+     little-endian platform.
+
+'-maltivec=be'
+     Generate Altivec instructions using big-endian element order,
+     regardless of whether the target is big- or little-endian.  This is
+     the default when targeting a big-endian platform.
+
+     The element order is used to interpret element numbers in Altivec
+     intrinsics such as 'vec_splat', 'vec_extract', and 'vec_insert'.
+     By default, these will match array element order corresponding to
+     the endianness for the target.
+
+'-maltivec=le'
+     Generate Altivec instructions using little-endian element order,
+     regardless of whether the target is big- or little-endian.  This is
+     the default when targeting a little-endian platform.  This option
+     is currently ignored when targeting a big-endian platform.
+
+     The element order is used to interpret element numbers in Altivec
+     intrinsics such as 'vec_splat', 'vec_extract', and 'vec_insert'.
+     By default, these will match array element order corresponding to
+     the endianness for the target.
+
+'-mvrsave'
+'-mno-vrsave'
+     Generate VRSAVE instructions when generating AltiVec code.
+
+'-mgen-cell-microcode'
+     Generate Cell microcode instructions.
+
+'-mwarn-cell-microcode'
+     Warn when a Cell microcode instruction is emitted.  An example of a
+     Cell microcode instruction is a variable shift.
+
+'-msecure-plt'
+     Generate code that allows 'ld' and 'ld.so' to build executables and
+     shared libraries with non-executable '.plt' and '.got' sections.
+     This is a PowerPC 32-bit SYSV ABI option.
+
+'-mbss-plt'
+     Generate code that uses a BSS '.plt' section that 'ld.so' fills in,
+     and requires '.plt' and '.got' sections that are both writable and
+     executable.  This is a PowerPC 32-bit SYSV ABI option.
+
+'-misel'
+'-mno-isel'
+     This switch enables or disables the generation of ISEL
+     instructions.
+
+'-misel=YES/NO'
+     This switch has been deprecated.  Use '-misel' and '-mno-isel'
+     instead.
+
+'-mspe'
+'-mno-spe'
+     This switch enables or disables the generation of SPE simd
+     instructions.
+
+'-mpaired'
+'-mno-paired'
+     This switch enables or disables the generation of PAIRED simd
+     instructions.
+
+'-mspe=YES/NO'
+     This option has been deprecated.  Use '-mspe' and '-mno-spe'
+     instead.
+
+'-mvsx'
+'-mno-vsx'
+     Generate code that uses (does not use) vector/scalar (VSX)
+     instructions, and also enable the use of built-in functions that
+     allow more direct access to the VSX instruction set.
+
+'-mcrypto'
+'-mno-crypto'
+     Enable the use (disable) of the built-in functions that allow
+     direct access to the cryptographic instructions that were added in
+     version 2.07 of the PowerPC ISA.
+
+'-mdirect-move'
+'-mno-direct-move'
+     Generate code that uses (does not use) the instructions to move
+     data between the general purpose registers and the vector/scalar
+     (VSX) registers that were added in version 2.07 of the PowerPC ISA.
+
+'-mpower8-fusion'
+'-mno-power8-fusion'
+     Generate code that keeps (does not keeps) some integer operations
+     adjacent so that the instructions can be fused together on power8
+     and later processors.
+
+'-mpower8-vector'
+'-mno-power8-vector'
+     Generate code that uses (does not use) the vector and scalar
+     instructions that were added in version 2.07 of the PowerPC ISA.
+     Also enable the use of built-in functions that allow more direct
+     access to the vector instructions.
+
+'-mquad-memory'
+'-mno-quad-memory'
+     Generate code that uses (does not use) the non-atomic quad word
+     memory instructions.  The '-mquad-memory' option requires use of
+     64-bit mode.
+
+'-mquad-memory-atomic'
+'-mno-quad-memory-atomic'
+     Generate code that uses (does not use) the atomic quad word memory
+     instructions.  The '-mquad-memory-atomic' option requires use of
+     64-bit mode.
+
+'-mfloat-gprs=YES/SINGLE/DOUBLE/NO'
+'-mfloat-gprs'
+     This switch enables or disables the generation of floating-point
+     operations on the general-purpose registers for architectures that
+     support it.
+
+     The argument YES or SINGLE enables the use of single-precision
+     floating-point operations.
+
+     The argument DOUBLE enables the use of single and double-precision
+     floating-point operations.
+
+     The argument NO disables floating-point operations on the
+     general-purpose registers.
+
+     This option is currently only available on the MPC854x.
+
+'-m32'
+'-m64'
+     Generate code for 32-bit or 64-bit environments of Darwin and SVR4
+     targets (including GNU/Linux).  The 32-bit environment sets int,
+     long and pointer to 32 bits and generates code that runs on any
+     PowerPC variant.  The 64-bit environment sets int to 32 bits and
+     long and pointer to 64 bits, and generates code for PowerPC64, as
+     for '-mpowerpc64'.
+
+'-mfull-toc'
+'-mno-fp-in-toc'
+'-mno-sum-in-toc'
+'-mminimal-toc'
+     Modify generation of the TOC (Table Of Contents), which is created
+     for every executable file.  The '-mfull-toc' option is selected by
+     default.  In that case, GCC allocates at least one TOC entry for
+     each unique non-automatic variable reference in your program.  GCC
+     also places floating-point constants in the TOC.  However, only
+     16,384 entries are available in the TOC.
+
+     If you receive a linker error message that saying you have
+     overflowed the available TOC space, you can reduce the amount of
+     TOC space used with the '-mno-fp-in-toc' and '-mno-sum-in-toc'
+     options.  '-mno-fp-in-toc' prevents GCC from putting floating-point
+     constants in the TOC and '-mno-sum-in-toc' forces GCC to generate
+     code to calculate the sum of an address and a constant at run time
+     instead of putting that sum into the TOC.  You may specify one or
+     both of these options.  Each causes GCC to produce very slightly
+     slower and larger code at the expense of conserving TOC space.
+
+     If you still run out of space in the TOC even when you specify both
+     of these options, specify '-mminimal-toc' instead.  This option
+     causes GCC to make only one TOC entry for every file.  When you
+     specify this option, GCC produces code that is slower and larger
+     but which uses extremely little TOC space.  You may wish to use
+     this option only on files that contain less frequently-executed
+     code.
+
+'-maix64'
+'-maix32'
+     Enable 64-bit AIX ABI and calling convention: 64-bit pointers,
+     64-bit 'long' type, and the infrastructure needed to support them.
+     Specifying '-maix64' implies '-mpowerpc64', while '-maix32'
+     disables the 64-bit ABI and implies '-mno-powerpc64'.  GCC defaults
+     to '-maix32'.
+
+'-mxl-compat'
+'-mno-xl-compat'
+     Produce code that conforms more closely to IBM XL compiler
+     semantics when using AIX-compatible ABI.  Pass floating-point
+     arguments to prototyped functions beyond the register save area
+     (RSA) on the stack in addition to argument FPRs.  Do not assume
+     that most significant double in 128-bit long double value is
+     properly rounded when comparing values and converting to double.
+     Use XL symbol names for long double support routines.
+
+     The AIX calling convention was extended but not initially
+     documented to handle an obscure K&R C case of calling a function
+     that takes the address of its arguments with fewer arguments than
+     declared.  IBM XL compilers access floating-point arguments that do
+     not fit in the RSA from the stack when a subroutine is compiled
+     without optimization.  Because always storing floating-point
+     arguments on the stack is inefficient and rarely needed, this
+     option is not enabled by default and only is necessary when calling
+     subroutines compiled by IBM XL compilers without optimization.
+
+'-mpe'
+     Support "IBM RS/6000 SP" "Parallel Environment" (PE).  Link an
+     application written to use message passing with special startup
+     code to enable the application to run.  The system must have PE
+     installed in the standard location ('/usr/lpp/ppe.poe/'), or the
+     'specs' file must be overridden with the '-specs=' option to
+     specify the appropriate directory location.  The Parallel
+     Environment does not support threads, so the '-mpe' option and the
+     '-pthread' option are incompatible.
+
+'-malign-natural'
+'-malign-power'
+     On AIX, 32-bit Darwin, and 64-bit PowerPC GNU/Linux, the option
+     '-malign-natural' overrides the ABI-defined alignment of larger
+     types, such as floating-point doubles, on their natural size-based
+     boundary.  The option '-malign-power' instructs GCC to follow the
+     ABI-specified alignment rules.  GCC defaults to the standard
+     alignment defined in the ABI.
+
+     On 64-bit Darwin, natural alignment is the default, and
+     '-malign-power' is not supported.
+
+'-msoft-float'
+'-mhard-float'
+     Generate code that does not use (uses) the floating-point register
+     set.  Software floating-point emulation is provided if you use the
+     '-msoft-float' option, and pass the option to GCC when linking.
+
+'-msingle-float'
+'-mdouble-float'
+     Generate code for single- or double-precision floating-point
+     operations.  '-mdouble-float' implies '-msingle-float'.
+
+'-msimple-fpu'
+     Do not generate 'sqrt' and 'div' instructions for hardware
+     floating-point unit.
+
+'-mfpu=NAME'
+     Specify type of floating-point unit.  Valid values for NAME are
+     'sp_lite' (equivalent to '-msingle-float -msimple-fpu'), 'dp_lite'
+     (equivalent to '-mdouble-float -msimple-fpu'), 'sp_full'
+     (equivalent to '-msingle-float'), and 'dp_full' (equivalent to
+     '-mdouble-float').
+
+'-mxilinx-fpu'
+     Perform optimizations for the floating-point unit on Xilinx PPC
+     405/440.
+
+'-mmultiple'
+'-mno-multiple'
+     Generate code that uses (does not use) the load multiple word
+     instructions and the store multiple word instructions.  These
+     instructions are generated by default on POWER systems, and not
+     generated on PowerPC systems.  Do not use '-mmultiple' on
+     little-endian PowerPC systems, since those instructions do not work
+     when the processor is in little-endian mode.  The exceptions are
+     PPC740 and PPC750 which permit these instructions in little-endian
+     mode.
+
+'-mstring'
+'-mno-string'
+     Generate code that uses (does not use) the load string instructions
+     and the store string word instructions to save multiple registers
+     and do small block moves.  These instructions are generated by
+     default on POWER systems, and not generated on PowerPC systems.  Do
+     not use '-mstring' on little-endian PowerPC systems, since those
+     instructions do not work when the processor is in little-endian
+     mode.  The exceptions are PPC740 and PPC750 which permit these
+     instructions in little-endian mode.
+
+'-mupdate'
+'-mno-update'
+     Generate code that uses (does not use) the load or store
+     instructions that update the base register to the address of the
+     calculated memory location.  These instructions are generated by
+     default.  If you use '-mno-update', there is a small window between
+     the time that the stack pointer is updated and the address of the
+     previous frame is stored, which means code that walks the stack
+     frame across interrupts or signals may get corrupted data.
+
+'-mavoid-indexed-addresses'
+'-mno-avoid-indexed-addresses'
+     Generate code that tries to avoid (not avoid) the use of indexed
+     load or store instructions.  These instructions can incur a
+     performance penalty on Power6 processors in certain situations,
+     such as when stepping through large arrays that cross a 16M
+     boundary.  This option is enabled by default when targeting Power6
+     and disabled otherwise.
+
+'-mfused-madd'
+'-mno-fused-madd'
+     Generate code that uses (does not use) the floating-point multiply
+     and accumulate instructions.  These instructions are generated by
+     default if hardware floating point is used.  The machine-dependent
+     '-mfused-madd' option is now mapped to the machine-independent
+     '-ffp-contract=fast' option, and '-mno-fused-madd' is mapped to
+     '-ffp-contract=off'.
+
+'-mmulhw'
+'-mno-mulhw'
+     Generate code that uses (does not use) the half-word multiply and
+     multiply-accumulate instructions on the IBM 405, 440, 464 and 476
+     processors.  These instructions are generated by default when
+     targeting those processors.
+
+'-mdlmzb'
+'-mno-dlmzb'
+     Generate code that uses (does not use) the string-search 'dlmzb'
+     instruction on the IBM 405, 440, 464 and 476 processors.  This
+     instruction is generated by default when targeting those
+     processors.
+
+'-mno-bit-align'
+'-mbit-align'
+     On System V.4 and embedded PowerPC systems do not (do) force
+     structures and unions that contain bit-fields to be aligned to the
+     base type of the bit-field.
+
+     For example, by default a structure containing nothing but 8
+     'unsigned' bit-fields of length 1 is aligned to a 4-byte boundary
+     and has a size of 4 bytes.  By using '-mno-bit-align', the
+     structure is aligned to a 1-byte boundary and is 1 byte in size.
+
+'-mno-strict-align'
+'-mstrict-align'
+     On System V.4 and embedded PowerPC systems do not (do) assume that
+     unaligned memory references are handled by the system.
+
+'-mrelocatable'
+'-mno-relocatable'
+     Generate code that allows (does not allow) a static executable to
+     be relocated to a different address at run time.  A simple embedded
+     PowerPC system loader should relocate the entire contents of
+     '.got2' and 4-byte locations listed in the '.fixup' section, a
+     table of 32-bit addresses generated by this option.  For this to
+     work, all objects linked together must be compiled with
+     '-mrelocatable' or '-mrelocatable-lib'.  '-mrelocatable' code
+     aligns the stack to an 8-byte boundary.
+
+'-mrelocatable-lib'
+'-mno-relocatable-lib'
+     Like '-mrelocatable', '-mrelocatable-lib' generates a '.fixup'
+     section to allow static executables to be relocated at run time,
+     but '-mrelocatable-lib' does not use the smaller stack alignment of
+     '-mrelocatable'.  Objects compiled with '-mrelocatable-lib' may be
+     linked with objects compiled with any combination of the
+     '-mrelocatable' options.
+
+'-mno-toc'
+'-mtoc'
+     On System V.4 and embedded PowerPC systems do not (do) assume that
+     register 2 contains a pointer to a global area pointing to the
+     addresses used in the program.
+
+'-mlittle'
+'-mlittle-endian'
+     On System V.4 and embedded PowerPC systems compile code for the
+     processor in little-endian mode.  The '-mlittle-endian' option is
+     the same as '-mlittle'.
+
+'-mbig'
+'-mbig-endian'
+     On System V.4 and embedded PowerPC systems compile code for the
+     processor in big-endian mode.  The '-mbig-endian' option is the
+     same as '-mbig'.
+
+'-mdynamic-no-pic'
+     On Darwin and Mac OS X systems, compile code so that it is not
+     relocatable, but that its external references are relocatable.  The
+     resulting code is suitable for applications, but not shared
+     libraries.
+
+'-msingle-pic-base'
+     Treat the register used for PIC addressing as read-only, rather
+     than loading it in the prologue for each function.  The runtime
+     system is responsible for initializing this register with an
+     appropriate value before execution begins.
+
+'-mprioritize-restricted-insns=PRIORITY'
+     This option controls the priority that is assigned to dispatch-slot
+     restricted instructions during the second scheduling pass.  The
+     argument PRIORITY takes the value '0', '1', or '2' to assign no,
+     highest, or second-highest (respectively) priority to dispatch-slot
+     restricted instructions.
+
+'-msched-costly-dep=DEPENDENCE_TYPE'
+     This option controls which dependences are considered costly by the
+     target during instruction scheduling.  The argument DEPENDENCE_TYPE
+     takes one of the following values:
+
+     'no'
+          No dependence is costly.
+
+     'all'
+          All dependences are costly.
+
+     'true_store_to_load'
+          A true dependence from store to load is costly.
+
+     'store_to_load'
+          Any dependence from store to load is costly.
+
+     NUMBER
+          Any dependence for which the latency is greater than or equal
+          to NUMBER is costly.
+
+'-minsert-sched-nops=SCHEME'
+     This option controls which NOP insertion scheme is used during the
+     second scheduling pass.  The argument SCHEME takes one of the
+     following values:
+
+     'no'
+          Don't insert NOPs.
+
+     'pad'
+          Pad with NOPs any dispatch group that has vacant issue slots,
+          according to the scheduler's grouping.
+
+     'regroup_exact'
+          Insert NOPs to force costly dependent insns into separate
+          groups.  Insert exactly as many NOPs as needed to force an
+          insn to a new group, according to the estimated processor
+          grouping.
+
+     NUMBER
+          Insert NOPs to force costly dependent insns into separate
+          groups.  Insert NUMBER NOPs to force an insn to a new group.
+
+'-mcall-sysv'
+     On System V.4 and embedded PowerPC systems compile code using
+     calling conventions that adhere to the March 1995 draft of the
+     System V Application Binary Interface, PowerPC processor
+     supplement.  This is the default unless you configured GCC using
+     'powerpc-*-eabiaix'.
+
+'-mcall-sysv-eabi'
+'-mcall-eabi'
+     Specify both '-mcall-sysv' and '-meabi' options.
+
+'-mcall-sysv-noeabi'
+     Specify both '-mcall-sysv' and '-mno-eabi' options.
+
+'-mcall-aixdesc'
+     On System V.4 and embedded PowerPC systems compile code for the AIX
+     operating system.
+
+'-mcall-linux'
+     On System V.4 and embedded PowerPC systems compile code for the
+     Linux-based GNU system.
+
+'-mcall-freebsd'
+     On System V.4 and embedded PowerPC systems compile code for the
+     FreeBSD operating system.
+
+'-mcall-netbsd'
+     On System V.4 and embedded PowerPC systems compile code for the
+     NetBSD operating system.
+
+'-mcall-openbsd'
+     On System V.4 and embedded PowerPC systems compile code for the
+     OpenBSD operating system.
+
+'-maix-struct-return'
+     Return all structures in memory (as specified by the AIX ABI).
+
+'-msvr4-struct-return'
+     Return structures smaller than 8 bytes in registers (as specified
+     by the SVR4 ABI).
+
+'-mabi=ABI-TYPE'
+     Extend the current ABI with a particular extension, or remove such
+     extension.  Valid values are ALTIVEC, NO-ALTIVEC, SPE, NO-SPE,
+     IBMLONGDOUBLE, IEEELONGDOUBLE, ELFV1, ELFV2.
+
+'-mabi=spe'
+     Extend the current ABI with SPE ABI extensions.  This does not
+     change the default ABI, instead it adds the SPE ABI extensions to
+     the current ABI.
+
+'-mabi=no-spe'
+     Disable Book-E SPE ABI extensions for the current ABI.
+
+'-mabi=ibmlongdouble'
+     Change the current ABI to use IBM extended-precision long double.
+     This is a PowerPC 32-bit SYSV ABI option.
+
+'-mabi=ieeelongdouble'
+     Change the current ABI to use IEEE extended-precision long double.
+     This is a PowerPC 32-bit Linux ABI option.
+
+'-mabi=elfv1'
+     Change the current ABI to use the ELFv1 ABI. This is the default
+     ABI for big-endian PowerPC 64-bit Linux.  Overriding the default
+     ABI requires special system support and is likely to fail in
+     spectacular ways.
+
+'-mabi=elfv2'
+     Change the current ABI to use the ELFv2 ABI. This is the default
+     ABI for little-endian PowerPC 64-bit Linux.  Overriding the default
+     ABI requires special system support and is likely to fail in
+     spectacular ways.
+
+'-mprototype'
+'-mno-prototype'
+     On System V.4 and embedded PowerPC systems assume that all calls to
+     variable argument functions are properly prototyped.  Otherwise,
+     the compiler must insert an instruction before every non-prototyped
+     call to set or clear bit 6 of the condition code register (CR) to
+     indicate whether floating-point values are passed in the
+     floating-point registers in case the function takes variable
+     arguments.  With '-mprototype', only calls to prototyped variable
+     argument functions set or clear the bit.
+
+'-msim'
+     On embedded PowerPC systems, assume that the startup module is
+     called 'sim-crt0.o' and that the standard C libraries are
+     'libsim.a' and 'libc.a'.  This is the default for
+     'powerpc-*-eabisim' configurations.
+
+'-mmvme'
+     On embedded PowerPC systems, assume that the startup module is
+     called 'crt0.o' and the standard C libraries are 'libmvme.a' and
+     'libc.a'.
+
+'-mads'
+     On embedded PowerPC systems, assume that the startup module is
+     called 'crt0.o' and the standard C libraries are 'libads.a' and
+     'libc.a'.
+
+'-myellowknife'
+     On embedded PowerPC systems, assume that the startup module is
+     called 'crt0.o' and the standard C libraries are 'libyk.a' and
+     'libc.a'.
+
+'-mvxworks'
+     On System V.4 and embedded PowerPC systems, specify that you are
+     compiling for a VxWorks system.
+
+'-memb'
+     On embedded PowerPC systems, set the PPC_EMB bit in the ELF flags
+     header to indicate that 'eabi' extended relocations are used.
+
+'-meabi'
+'-mno-eabi'
+     On System V.4 and embedded PowerPC systems do (do not) adhere to
+     the Embedded Applications Binary Interface (EABI), which is a set
+     of modifications to the System V.4 specifications.  Selecting
+     '-meabi' means that the stack is aligned to an 8-byte boundary, a
+     function '__eabi' is called from 'main' to set up the EABI
+     environment, and the '-msdata' option can use both 'r2' and 'r13'
+     to point to two separate small data areas.  Selecting '-mno-eabi'
+     means that the stack is aligned to a 16-byte boundary, no EABI
+     initialization function is called from 'main', and the '-msdata'
+     option only uses 'r13' to point to a single small data area.  The
+     '-meabi' option is on by default if you configured GCC using one of
+     the 'powerpc*-*-eabi*' options.
+
+'-msdata=eabi'
+     On System V.4 and embedded PowerPC systems, put small initialized
+     'const' global and static data in the '.sdata2' section, which is
+     pointed to by register 'r2'.  Put small initialized non-'const'
+     global and static data in the '.sdata' section, which is pointed to
+     by register 'r13'.  Put small uninitialized global and static data
+     in the '.sbss' section, which is adjacent to the '.sdata' section.
+     The '-msdata=eabi' option is incompatible with the '-mrelocatable'
+     option.  The '-msdata=eabi' option also sets the '-memb' option.
+
+'-msdata=sysv'
+     On System V.4 and embedded PowerPC systems, put small global and
+     static data in the '.sdata' section, which is pointed to by
+     register 'r13'.  Put small uninitialized global and static data in
+     the '.sbss' section, which is adjacent to the '.sdata' section.
+     The '-msdata=sysv' option is incompatible with the '-mrelocatable'
+     option.
+
+'-msdata=default'
+'-msdata'
+     On System V.4 and embedded PowerPC systems, if '-meabi' is used,
+     compile code the same as '-msdata=eabi', otherwise compile code the
+     same as '-msdata=sysv'.
+
+'-msdata=data'
+     On System V.4 and embedded PowerPC systems, put small global data
+     in the '.sdata' section.  Put small uninitialized global data in
+     the '.sbss' section.  Do not use register 'r13' to address small
+     data however.  This is the default behavior unless other '-msdata'
+     options are used.
+
+'-msdata=none'
+'-mno-sdata'
+     On embedded PowerPC systems, put all initialized global and static
+     data in the '.data' section, and all uninitialized data in the
+     '.bss' section.
+
+'-mblock-move-inline-limit=NUM'
+     Inline all block moves (such as calls to 'memcpy' or structure
+     copies) less than or equal to NUM bytes.  The minimum value for NUM
+     is 32 bytes on 32-bit targets and 64 bytes on 64-bit targets.  The
+     default value is target-specific.
+
+'-G NUM'
+     On embedded PowerPC systems, put global and static items less than
+     or equal to NUM bytes into the small data or BSS sections instead
+     of the normal data or BSS section.  By default, NUM is 8.  The '-G
+     NUM' switch is also passed to the linker.  All modules should be
+     compiled with the same '-G NUM' value.
+
+'-mregnames'
+'-mno-regnames'
+     On System V.4 and embedded PowerPC systems do (do not) emit
+     register names in the assembly language output using symbolic
+     forms.
+
+'-mlongcall'
+'-mno-longcall'
+     By default assume that all calls are far away so that a longer and
+     more expensive calling sequence is required.  This is required for
+     calls farther than 32 megabytes (33,554,432 bytes) from the current
+     location.  A short call is generated if the compiler knows the call
+     cannot be that far away.  This setting can be overridden by the
+     'shortcall' function attribute, or by '#pragma longcall(0)'.
+
+     Some linkers are capable of detecting out-of-range calls and
+     generating glue code on the fly.  On these systems, long calls are
+     unnecessary and generate slower code.  As of this writing, the AIX
+     linker can do this, as can the GNU linker for PowerPC/64.  It is
+     planned to add this feature to the GNU linker for 32-bit PowerPC
+     systems as well.
+
+     On Darwin/PPC systems, '#pragma longcall' generates 'jbsr callee,
+     L42', plus a "branch island" (glue code).  The two target addresses
+     represent the callee and the branch island.  The Darwin/PPC linker
+     prefers the first address and generates a 'bl callee' if the PPC
+     'bl' instruction reaches the callee directly; otherwise, the linker
+     generates 'bl L42' to call the branch island.  The branch island is
+     appended to the body of the calling function; it computes the full
+     32-bit address of the callee and jumps to it.
+
+     On Mach-O (Darwin) systems, this option directs the compiler emit
+     to the glue for every direct call, and the Darwin linker decides
+     whether to use or discard it.
+
+     In the future, GCC may ignore all longcall specifications when the
+     linker is known to generate glue.
+
+'-mtls-markers'
+'-mno-tls-markers'
+     Mark (do not mark) calls to '__tls_get_addr' with a relocation
+     specifying the function argument.  The relocation allows the linker
+     to reliably associate function call with argument setup
+     instructions for TLS optimization, which in turn allows GCC to
+     better schedule the sequence.
+
+'-pthread'
+     Adds support for multithreading with the "pthreads" library.  This
+     option sets flags for both the preprocessor and linker.
+
+'-mrecip'
+'-mno-recip'
+     This option enables use of the reciprocal estimate and reciprocal
+     square root estimate instructions with additional Newton-Raphson
+     steps to increase precision instead of doing a divide or square
+     root and divide for floating-point arguments.  You should use the
+     '-ffast-math' option when using '-mrecip' (or at least
+     '-funsafe-math-optimizations', '-finite-math-only',
+     '-freciprocal-math' and '-fno-trapping-math').  Note that while the
+     throughput of the sequence is generally higher than the throughput
+     of the non-reciprocal instruction, the precision of the sequence
+     can be decreased by up to 2 ulp (i.e. the inverse of 1.0 equals
+     0.99999994) for reciprocal square roots.
+
+'-mrecip=OPT'
+     This option controls which reciprocal estimate instructions may be
+     used.  OPT is a comma-separated list of options, which may be
+     preceded by a '!' to invert the option: 'all': enable all estimate
+     instructions, 'default': enable the default instructions,
+     equivalent to '-mrecip', 'none': disable all estimate instructions,
+     equivalent to '-mno-recip'; 'div': enable the reciprocal
+     approximation instructions for both single and double precision;
+     'divf': enable the single-precision reciprocal approximation
+     instructions; 'divd': enable the double-precision reciprocal
+     approximation instructions; 'rsqrt': enable the reciprocal square
+     root approximation instructions for both single and double
+     precision; 'rsqrtf': enable the single-precision reciprocal square
+     root approximation instructions; 'rsqrtd': enable the
+     double-precision reciprocal square root approximation instructions;
+
+     So, for example, '-mrecip=all,!rsqrtd' enables all of the
+     reciprocal estimate instructions, except for the 'FRSQRTE',
+     'XSRSQRTEDP', and 'XVRSQRTEDP' instructions which handle the
+     double-precision reciprocal square root calculations.
+
+'-mrecip-precision'
+'-mno-recip-precision'
+     Assume (do not assume) that the reciprocal estimate instructions
+     provide higher-precision estimates than is mandated by the PowerPC
+     ABI. Selecting '-mcpu=power6', '-mcpu=power7' or '-mcpu=power8'
+     automatically selects '-mrecip-precision'.  The double-precision
+     square root estimate instructions are not generated by default on
+     low-precision machines, since they do not provide an estimate that
+     converges after three steps.
+
+'-mveclibabi=TYPE'
+     Specifies the ABI type to use for vectorizing intrinsics using an
+     external library.  The only type supported at present is 'mass',
+     which specifies to use IBM's Mathematical Acceleration Subsystem
+     (MASS) libraries for vectorizing intrinsics using external
+     libraries.  GCC currently emits calls to 'acosd2', 'acosf4',
+     'acoshd2', 'acoshf4', 'asind2', 'asinf4', 'asinhd2', 'asinhf4',
+     'atan2d2', 'atan2f4', 'atand2', 'atanf4', 'atanhd2', 'atanhf4',
+     'cbrtd2', 'cbrtf4', 'cosd2', 'cosf4', 'coshd2', 'coshf4', 'erfcd2',
+     'erfcf4', 'erfd2', 'erff4', 'exp2d2', 'exp2f4', 'expd2', 'expf4',
+     'expm1d2', 'expm1f4', 'hypotd2', 'hypotf4', 'lgammad2', 'lgammaf4',
+     'log10d2', 'log10f4', 'log1pd2', 'log1pf4', 'log2d2', 'log2f4',
+     'logd2', 'logf4', 'powd2', 'powf4', 'sind2', 'sinf4', 'sinhd2',
+     'sinhf4', 'sqrtd2', 'sqrtf4', 'tand2', 'tanf4', 'tanhd2', and
+     'tanhf4' when generating code for power7.  Both '-ftree-vectorize'
+     and '-funsafe-math-optimizations' must also be enabled.  The MASS
+     libraries must be specified at link time.
+
+'-mfriz'
+'-mno-friz'
+     Generate (do not generate) the 'friz' instruction when the
+     '-funsafe-math-optimizations' option is used to optimize rounding
+     of floating-point values to 64-bit integer and back to floating
+     point.  The 'friz' instruction does not return the same value if
+     the floating-point number is too large to fit in an integer.
+
+'-mpointers-to-nested-functions'
+'-mno-pointers-to-nested-functions'
+     Generate (do not generate) code to load up the static chain
+     register (R11) when calling through a pointer on AIX and 64-bit
+     Linux systems where a function pointer points to a 3-word
+     descriptor giving the function address, TOC value to be loaded in
+     register R2, and static chain value to be loaded in register R11.
+     The '-mpointers-to-nested-functions' is on by default.  You cannot
+     call through pointers to nested functions or pointers to functions
+     compiled in other languages that use the static chain if you use
+     the '-mno-pointers-to-nested-functions'.
+
+'-msave-toc-indirect'
+'-mno-save-toc-indirect'
+     Generate (do not generate) code to save the TOC value in the
+     reserved stack location in the function prologue if the function
+     calls through a pointer on AIX and 64-bit Linux systems.  If the
+     TOC value is not saved in the prologue, it is saved just before the
+     call through the pointer.  The '-mno-save-toc-indirect' option is
+     the default.
+
+'-mcompat-align-parm'
+'-mno-compat-align-parm'
+     Generate (do not generate) code to pass structure parameters with a
+     maximum alignment of 64 bits, for compatibility with older versions
+     of GCC.
+
+     Older versions of GCC (prior to 4.9.0) incorrectly did not align a
+     structure parameter on a 128-bit boundary when that structure
+     contained a member requiring 128-bit alignment.  This is corrected
+     in more recent versions of GCC. This option may be used to generate
+     code that is compatible with functions compiled with older versions
+     of GCC.
+
+     The '-mno-compat-align-parm' option is the default.
+
+
+File: gcc.info,  Node: RX Options,  Next: S/390 and zSeries Options,  Prev: RS/6000 and PowerPC Options,  Up: Submodel Options
+
+3.17.39 RX Options
+------------------
+
+These command-line options are defined for RX targets:
+
+'-m64bit-doubles'
+'-m32bit-doubles'
+     Make the 'double' data type be 64 bits ('-m64bit-doubles') or 32
+     bits ('-m32bit-doubles') in size.  The default is
+     '-m32bit-doubles'.  _Note_ RX floating-point hardware only works on
+     32-bit values, which is why the default is '-m32bit-doubles'.
+
+'-fpu'
+'-nofpu'
+     Enables ('-fpu') or disables ('-nofpu') the use of RX
+     floating-point hardware.  The default is enabled for the RX600
+     series and disabled for the RX200 series.
+
+     Floating-point instructions are only generated for 32-bit
+     floating-point values, however, so the FPU hardware is not used for
+     doubles if the '-m64bit-doubles' option is used.
+
+     _Note_ If the '-fpu' option is enabled then
+     '-funsafe-math-optimizations' is also enabled automatically.  This
+     is because the RX FPU instructions are themselves unsafe.
+
+'-mcpu=NAME'
+     Selects the type of RX CPU to be targeted.  Currently three types
+     are supported, the generic RX600 and RX200 series hardware and the
+     specific RX610 CPU. The default is RX600.
+
+     The only difference between RX600 and RX610 is that the RX610 does
+     not support the 'MVTIPL' instruction.
+
+     The RX200 series does not have a hardware floating-point unit and
+     so '-nofpu' is enabled by default when this type is selected.
+
+'-mbig-endian-data'
+'-mlittle-endian-data'
+     Store data (but not code) in the big-endian format.  The default is
+     '-mlittle-endian-data', i.e. to store data in the little-endian
+     format.
+
+'-msmall-data-limit=N'
+     Specifies the maximum size in bytes of global and static variables
+     which can be placed into the small data area.  Using the small data
+     area can lead to smaller and faster code, but the size of area is
+     limited and it is up to the programmer to ensure that the area does
+     not overflow.  Also when the small data area is used one of the
+     RX's registers (usually 'r13') is reserved for use pointing to this
+     area, so it is no longer available for use by the compiler.  This
+     could result in slower and/or larger code if variables are pushed
+     onto the stack instead of being held in this register.
+
+     Note, common variables (variables that have not been initialized)
+     and constants are not placed into the small data area as they are
+     assigned to other sections in the output executable.
+
+     The default value is zero, which disables this feature.  Note, this
+     feature is not enabled by default with higher optimization levels
+     ('-O2' etc) because of the potentially detrimental effects of
+     reserving a register.  It is up to the programmer to experiment and
+     discover whether this feature is of benefit to their program.  See
+     the description of the '-mpid' option for a description of how the
+     actual register to hold the small data area pointer is chosen.
+
+'-msim'
+'-mno-sim'
+     Use the simulator runtime.  The default is to use the libgloss
+     board-specific runtime.
+
+'-mas100-syntax'
+'-mno-as100-syntax'
+     When generating assembler output use a syntax that is compatible
+     with Renesas's AS100 assembler.  This syntax can also be handled by
+     the GAS assembler, but it has some restrictions so it is not
+     generated by default.
+
+'-mmax-constant-size=N'
+     Specifies the maximum size, in bytes, of a constant that can be
+     used as an operand in a RX instruction.  Although the RX
+     instruction set does allow constants of up to 4 bytes in length to
+     be used in instructions, a longer value equates to a longer
+     instruction.  Thus in some circumstances it can be beneficial to
+     restrict the size of constants that are used in instructions.
+     Constants that are too big are instead placed into a constant pool
+     and referenced via register indirection.
+
+     The value N can be between 0 and 4.  A value of 0 (the default) or
+     4 means that constants of any size are allowed.
+
+'-mrelax'
+     Enable linker relaxation.  Linker relaxation is a process whereby
+     the linker attempts to reduce the size of a program by finding
+     shorter versions of various instructions.  Disabled by default.
+
+'-mint-register=N'
+     Specify the number of registers to reserve for fast interrupt
+     handler functions.  The value N can be between 0 and 4.  A value of
+     1 means that register 'r13' is reserved for the exclusive use of
+     fast interrupt handlers.  A value of 2 reserves 'r13' and 'r12'.  A
+     value of 3 reserves 'r13', 'r12' and 'r11', and a value of 4
+     reserves 'r13' through 'r10'.  A value of 0, the default, does not
+     reserve any registers.
+
+'-msave-acc-in-interrupts'
+     Specifies that interrupt handler functions should preserve the
+     accumulator register.  This is only necessary if normal code might
+     use the accumulator register, for example because it performs
+     64-bit multiplications.  The default is to ignore the accumulator
+     as this makes the interrupt handlers faster.
+
+'-mpid'
+'-mno-pid'
+     Enables the generation of position independent data.  When enabled
+     any access to constant data is done via an offset from a base
+     address held in a register.  This allows the location of constant
+     data to be determined at run time without requiring the executable
+     to be relocated, which is a benefit to embedded applications with
+     tight memory constraints.  Data that can be modified is not
+     affected by this option.
+
+     Note, using this feature reserves a register, usually 'r13', for
+     the constant data base address.  This can result in slower and/or
+     larger code, especially in complicated functions.
+
+     The actual register chosen to hold the constant data base address
+     depends upon whether the '-msmall-data-limit' and/or the
+     '-mint-register' command-line options are enabled.  Starting with
+     register 'r13' and proceeding downwards, registers are allocated
+     first to satisfy the requirements of '-mint-register', then '-mpid'
+     and finally '-msmall-data-limit'.  Thus it is possible for the
+     small data area register to be 'r8' if both '-mint-register=4' and
+     '-mpid' are specified on the command line.
+
+     By default this feature is not enabled.  The default can be
+     restored via the '-mno-pid' command-line option.
+
+'-mno-warn-multiple-fast-interrupts'
+'-mwarn-multiple-fast-interrupts'
+     Prevents GCC from issuing a warning message if it finds more than
+     one fast interrupt handler when it is compiling a file.  The
+     default is to issue a warning for each extra fast interrupt handler
+     found, as the RX only supports one such interrupt.
+
+ _Note:_ The generic GCC command-line option '-ffixed-REG' has special
+significance to the RX port when used with the 'interrupt' function
+attribute.  This attribute indicates a function intended to process fast
+interrupts.  GCC ensures that it only uses the registers 'r10', 'r11',
+'r12' and/or 'r13' and only provided that the normal use of the
+corresponding registers have been restricted via the '-ffixed-REG' or
+'-mint-register' command-line options.
+
+
+File: gcc.info,  Node: S/390 and zSeries Options,  Next: Score Options,  Prev: RX Options,  Up: Submodel Options
+
+3.17.40 S/390 and zSeries Options
+---------------------------------
+
+These are the '-m' options defined for the S/390 and zSeries
+architecture.
+
+'-mhard-float'
+'-msoft-float'
+     Use (do not use) the hardware floating-point instructions and
+     registers for floating-point operations.  When '-msoft-float' is
+     specified, functions in 'libgcc.a' are used to perform
+     floating-point operations.  When '-mhard-float' is specified, the
+     compiler generates IEEE floating-point instructions.  This is the
+     default.
+
+'-mhard-dfp'
+'-mno-hard-dfp'
+     Use (do not use) the hardware decimal-floating-point instructions
+     for decimal-floating-point operations.  When '-mno-hard-dfp' is
+     specified, functions in 'libgcc.a' are used to perform
+     decimal-floating-point operations.  When '-mhard-dfp' is specified,
+     the compiler generates decimal-floating-point hardware
+     instructions.  This is the default for '-march=z9-ec' or higher.
+
+'-mlong-double-64'
+'-mlong-double-128'
+     These switches control the size of 'long double' type.  A size of
+     64 bits makes the 'long double' type equivalent to the 'double'
+     type.  This is the default.
+
+'-mbackchain'
+'-mno-backchain'
+     Store (do not store) the address of the caller's frame as backchain
+     pointer into the callee's stack frame.  A backchain may be needed
+     to allow debugging using tools that do not understand DWARF 2 call
+     frame information.  When '-mno-packed-stack' is in effect, the
+     backchain pointer is stored at the bottom of the stack frame; when
+     '-mpacked-stack' is in effect, the backchain is placed into the
+     topmost word of the 96/160 byte register save area.
+
+     In general, code compiled with '-mbackchain' is call-compatible
+     with code compiled with '-mmo-backchain'; however, use of the
+     backchain for debugging purposes usually requires that the whole
+     binary is built with '-mbackchain'.  Note that the combination of
+     '-mbackchain', '-mpacked-stack' and '-mhard-float' is not
+     supported.  In order to build a linux kernel use '-msoft-float'.
+
+     The default is to not maintain the backchain.
+
+'-mpacked-stack'
+'-mno-packed-stack'
+     Use (do not use) the packed stack layout.  When '-mno-packed-stack'
+     is specified, the compiler uses the all fields of the 96/160 byte
+     register save area only for their default purpose; unused fields
+     still take up stack space.  When '-mpacked-stack' is specified,
+     register save slots are densely packed at the top of the register
+     save area; unused space is reused for other purposes, allowing for
+     more efficient use of the available stack space.  However, when
+     '-mbackchain' is also in effect, the topmost word of the save area
+     is always used to store the backchain, and the return address
+     register is always saved two words below the backchain.
+
+     As long as the stack frame backchain is not used, code generated
+     with '-mpacked-stack' is call-compatible with code generated with
+     '-mno-packed-stack'.  Note that some non-FSF releases of GCC 2.95
+     for S/390 or zSeries generated code that uses the stack frame
+     backchain at run time, not just for debugging purposes.  Such code
+     is not call-compatible with code compiled with '-mpacked-stack'.
+     Also, note that the combination of '-mbackchain', '-mpacked-stack'
+     and '-mhard-float' is not supported.  In order to build a linux
+     kernel use '-msoft-float'.
+
+     The default is to not use the packed stack layout.
+
+'-msmall-exec'
+'-mno-small-exec'
+     Generate (or do not generate) code using the 'bras' instruction to
+     do subroutine calls.  This only works reliably if the total
+     executable size does not exceed 64k.  The default is to use the
+     'basr' instruction instead, which does not have this limitation.
+
+'-m64'
+'-m31'
+     When '-m31' is specified, generate code compliant to the GNU/Linux
+     for S/390 ABI.  When '-m64' is specified, generate code compliant
+     to the GNU/Linux for zSeries ABI.  This allows GCC in particular to
+     generate 64-bit instructions.  For the 's390' targets, the default
+     is '-m31', while the 's390x' targets default to '-m64'.
+
+'-mzarch'
+'-mesa'
+     When '-mzarch' is specified, generate code using the instructions
+     available on z/Architecture.  When '-mesa' is specified, generate
+     code using the instructions available on ESA/390.  Note that
+     '-mesa' is not possible with '-m64'.  When generating code
+     compliant to the GNU/Linux for S/390 ABI, the default is '-mesa'.
+     When generating code compliant to the GNU/Linux for zSeries ABI,
+     the default is '-mzarch'.
+
+'-mmvcle'
+'-mno-mvcle'
+     Generate (or do not generate) code using the 'mvcle' instruction to
+     perform block moves.  When '-mno-mvcle' is specified, use a 'mvc'
+     loop instead.  This is the default unless optimizing for size.
+
+'-mdebug'
+'-mno-debug'
+     Print (or do not print) additional debug information when
+     compiling.  The default is to not print debug information.
+
+'-march=CPU-TYPE'
+     Generate code that runs on CPU-TYPE, which is the name of a system
+     representing a certain processor type.  Possible values for
+     CPU-TYPE are 'g5', 'g6', 'z900', 'z990', 'z9-109', 'z9-ec' and
+     'z10'.  When generating code using the instructions available on
+     z/Architecture, the default is '-march=z900'.  Otherwise, the
+     default is '-march=g5'.
+
+'-mtune=CPU-TYPE'
+     Tune to CPU-TYPE everything applicable about the generated code,
+     except for the ABI and the set of available instructions.  The list
+     of CPU-TYPE values is the same as for '-march'.  The default is the
+     value used for '-march'.
+
+'-mtpf-trace'
+'-mno-tpf-trace'
+     Generate code that adds (does not add) in TPF OS specific branches
+     to trace routines in the operating system.  This option is off by
+     default, even when compiling for the TPF OS.
+
+'-mfused-madd'
+'-mno-fused-madd'
+     Generate code that uses (does not use) the floating-point multiply
+     and accumulate instructions.  These instructions are generated by
+     default if hardware floating point is used.
+
+'-mwarn-framesize=FRAMESIZE'
+     Emit a warning if the current function exceeds the given frame
+     size.  Because this is a compile-time check it doesn't need to be a
+     real problem when the program runs.  It is intended to identify
+     functions that most probably cause a stack overflow.  It is useful
+     to be used in an environment with limited stack size e.g. the linux
+     kernel.
+
+'-mwarn-dynamicstack'
+     Emit a warning if the function calls 'alloca' or uses
+     dynamically-sized arrays.  This is generally a bad idea with a
+     limited stack size.
+
+'-mstack-guard=STACK-GUARD'
+'-mstack-size=STACK-SIZE'
+     If these options are provided the S/390 back end emits additional
+     instructions in the function prologue that trigger a trap if the
+     stack size is STACK-GUARD bytes above the STACK-SIZE (remember that
+     the stack on S/390 grows downward).  If the STACK-GUARD option is
+     omitted the smallest power of 2 larger than the frame size of the
+     compiled function is chosen.  These options are intended to be used
+     to help debugging stack overflow problems.  The additionally
+     emitted code causes only little overhead and hence can also be used
+     in production-like systems without greater performance degradation.
+     The given values have to be exact powers of 2 and STACK-SIZE has to
+     be greater than STACK-GUARD without exceeding 64k.  In order to be
+     efficient the extra code makes the assumption that the stack starts
+     at an address aligned to the value given by STACK-SIZE.  The
+     STACK-GUARD option can only be used in conjunction with STACK-SIZE.
+
+'-mhotpatch[=HALFWORDS]'
+'-mno-hotpatch'
+     If the hotpatch option is enabled, a "hot-patching" function
+     prologue is generated for all functions in the compilation unit.
+     The funtion label is prepended with the given number of two-byte
+     Nop instructions (HALFWORDS, maximum 1000000) or 12 Nop
+     instructions if no argument is present.  Functions with a
+     hot-patching prologue are never inlined automatically, and a
+     hot-patching prologue is never generated for functions functions
+     that are explicitly inline.
+
+     This option can be overridden for individual functions with the
+     'hotpatch' attribute.
+
+
+File: gcc.info,  Node: Score Options,  Next: SH Options,  Prev: S/390 and zSeries Options,  Up: Submodel Options
+
+3.17.41 Score Options
+---------------------
+
+These options are defined for Score implementations:
+
+'-meb'
+     Compile code for big-endian mode.  This is the default.
+
+'-mel'
+     Compile code for little-endian mode.
+
+'-mnhwloop'
+     Disable generation of 'bcnz' instructions.
+
+'-muls'
+     Enable generation of unaligned load and store instructions.
+
+'-mmac'
+     Enable the use of multiply-accumulate instructions.  Disabled by
+     default.
+
+'-mscore5'
+     Specify the SCORE5 as the target architecture.
+
+'-mscore5u'
+     Specify the SCORE5U of the target architecture.
+
+'-mscore7'
+     Specify the SCORE7 as the target architecture.  This is the
+     default.
+
+'-mscore7d'
+     Specify the SCORE7D as the target architecture.
+
+
+File: gcc.info,  Node: SH Options,  Next: Solaris 2 Options,  Prev: Score Options,  Up: Submodel Options
+
+3.17.42 SH Options
+------------------
+
+These '-m' options are defined for the SH implementations:
+
+'-m1'
+     Generate code for the SH1.
+
+'-m2'
+     Generate code for the SH2.
+
+'-m2e'
+     Generate code for the SH2e.
+
+'-m2a-nofpu'
+     Generate code for the SH2a without FPU, or for a SH2a-FPU in such a
+     way that the floating-point unit is not used.
+
+'-m2a-single-only'
+     Generate code for the SH2a-FPU, in such a way that no
+     double-precision floating-point operations are used.
+
+'-m2a-single'
+     Generate code for the SH2a-FPU assuming the floating-point unit is
+     in single-precision mode by default.
+
+'-m2a'
+     Generate code for the SH2a-FPU assuming the floating-point unit is
+     in double-precision mode by default.
+
+'-m3'
+     Generate code for the SH3.
+
+'-m3e'
+     Generate code for the SH3e.
+
+'-m4-nofpu'
+     Generate code for the SH4 without a floating-point unit.
+
+'-m4-single-only'
+     Generate code for the SH4 with a floating-point unit that only
+     supports single-precision arithmetic.
+
+'-m4-single'
+     Generate code for the SH4 assuming the floating-point unit is in
+     single-precision mode by default.
+
+'-m4'
+     Generate code for the SH4.
+
+'-m4a-nofpu'
+     Generate code for the SH4al-dsp, or for a SH4a in such a way that
+     the floating-point unit is not used.
+
+'-m4a-single-only'
+     Generate code for the SH4a, in such a way that no double-precision
+     floating-point operations are used.
+
+'-m4a-single'
+     Generate code for the SH4a assuming the floating-point unit is in
+     single-precision mode by default.
+
+'-m4a'
+     Generate code for the SH4a.
+
+'-m4al'
+     Same as '-m4a-nofpu', except that it implicitly passes '-dsp' to
+     the assembler.  GCC doesn't generate any DSP instructions at the
+     moment.
+
+'-mb'
+     Compile code for the processor in big-endian mode.
+
+'-ml'
+     Compile code for the processor in little-endian mode.
+
+'-mdalign'
+     Align doubles at 64-bit boundaries.  Note that this changes the
+     calling conventions, and thus some functions from the standard C
+     library do not work unless you recompile it first with '-mdalign'.
+
+'-mrelax'
+     Shorten some address references at link time, when possible; uses
+     the linker option '-relax'.
+
+'-mbigtable'
+     Use 32-bit offsets in 'switch' tables.  The default is to use
+     16-bit offsets.
+
+'-mbitops'
+     Enable the use of bit manipulation instructions on SH2A.
+
+'-mfmovd'
+     Enable the use of the instruction 'fmovd'.  Check '-mdalign' for
+     alignment constraints.
+
+'-mhitachi'
+     Comply with the calling conventions defined by Renesas.
+
+'-mrenesas'
+     Comply with the calling conventions defined by Renesas.
+
+'-mno-renesas'
+     Comply with the calling conventions defined for GCC before the
+     Renesas conventions were available.  This option is the default for
+     all targets of the SH toolchain.
+
+'-mnomacsave'
+     Mark the 'MAC' register as call-clobbered, even if '-mhitachi' is
+     given.
+
+'-mieee'
+'-mno-ieee'
+     Control the IEEE compliance of floating-point comparisons, which
+     affects the handling of cases where the result of a comparison is
+     unordered.  By default '-mieee' is implicitly enabled.  If
+     '-ffinite-math-only' is enabled '-mno-ieee' is implicitly set,
+     which results in faster floating-point greater-equal and less-equal
+     comparisons.  The implcit settings can be overridden by specifying
+     either '-mieee' or '-mno-ieee'.
+
+'-minline-ic_invalidate'
+     Inline code to invalidate instruction cache entries after setting
+     up nested function trampolines.  This option has no effect if
+     '-musermode' is in effect and the selected code generation option
+     (e.g.  '-m4') does not allow the use of the 'icbi' instruction.  If
+     the selected code generation option does not allow the use of the
+     'icbi' instruction, and '-musermode' is not in effect, the inlined
+     code manipulates the instruction cache address array directly with
+     an associative write.  This not only requires privileged mode at
+     run time, but it also fails if the cache line had been mapped via
+     the TLB and has become unmapped.
+
+'-misize'
+     Dump instruction size and location in the assembly code.
+
+'-mpadstruct'
+     This option is deprecated.  It pads structures to multiple of 4
+     bytes, which is incompatible with the SH ABI.
+
+'-matomic-model=MODEL'
+     Sets the model of atomic operations and additional parameters as a
+     comma separated list.  For details on the atomic built-in functions
+     see *note __atomic Builtins::.  The following models and parameters
+     are supported:
+
+     'none'
+          Disable compiler generated atomic sequences and emit library
+          calls for atomic operations.  This is the default if the
+          target is not 'sh-*-linux*'.
+
+     'soft-gusa'
+          Generate GNU/Linux compatible gUSA software atomic sequences
+          for the atomic built-in functions.  The generated atomic
+          sequences require additional support from the
+          interrupt/exception handling code of the system and are only
+          suitable for SH3* and SH4* single-core systems.  This option
+          is enabled by default when the target is 'sh-*-linux*' and
+          SH3* or SH4*.  When the target is SH4A, this option will also
+          partially utilize the hardware atomic instructions 'movli.l'
+          and 'movco.l' to create more efficient code, unless 'strict'
+          is specified.
+
+     'soft-tcb'
+          Generate software atomic sequences that use a variable in the
+          thread control block.  This is a variation of the gUSA
+          sequences which can also be used on SH1* and SH2* targets.
+          The generated atomic sequences require additional support from
+          the interrupt/exception handling code of the system and are
+          only suitable for single-core systems.  When using this model,
+          the 'gbr-offset=' parameter has to be specified as well.
+
+     'soft-imask'
+          Generate software atomic sequences that temporarily disable
+          interrupts by setting 'SR.IMASK = 1111'.  This model works
+          only when the program runs in privileged mode and is only
+          suitable for single-core systems.  Additional support from the
+          interrupt/exception handling code of the system is not
+          required.  This model is enabled by default when the target is
+          'sh-*-linux*' and SH1* or SH2*.
+
+     'hard-llcs'
+          Generate hardware atomic sequences using the 'movli.l' and
+          'movco.l' instructions only.  This is only available on SH4A
+          and is suitable for multi-core systems.  Since the hardware
+          instructions support only 32 bit atomic variables access to 8
+          or 16 bit variables is emulated with 32 bit accesses.  Code
+          compiled with this option will also be compatible with other
+          software atomic model interrupt/exception handling systems if
+          executed on an SH4A system.  Additional support from the
+          interrupt/exception handling code of the system is not
+          required for this model.
+
+     'gbr-offset='
+          This parameter specifies the offset in bytes of the variable
+          in the thread control block structure that should be used by
+          the generated atomic sequences when the 'soft-tcb' model has
+          been selected.  For other models this parameter is ignored.
+          The specified value must be an integer multiple of four and in
+          the range 0-1020.
+
+     'strict'
+          This parameter prevents mixed usage of multiple atomic models,
+          even though they would be compatible, and will make the
+          compiler generate atomic sequences of the specified model
+          only.
+
+'-mtas'
+     Generate the 'tas.b' opcode for '__atomic_test_and_set'.  Notice
+     that depending on the particular hardware and software
+     configuration this can degrade overall performance due to the
+     operand cache line flushes that are implied by the 'tas.b'
+     instruction.  On multi-core SH4A processors the 'tas.b' instruction
+     must be used with caution since it can result in data corruption
+     for certain cache configurations.
+
+'-mspace'
+     Optimize for space instead of speed.  Implied by '-Os'.
+
+'-mprefergot'
+     When generating position-independent code, emit function calls
+     using the Global Offset Table instead of the Procedure Linkage
+     Table.
+
+'-musermode'
+     Don't generate privileged mode only code.  This option implies
+     '-mno-inline-ic_invalidate' if the inlined code would not work in
+     user mode.  This is the default when the target is 'sh-*-linux*'.
+
+'-multcost=NUMBER'
+     Set the cost to assume for a multiply insn.
+
+'-mdiv=STRATEGY'
+     Set the division strategy to be used for integer division
+     operations.  For SHmedia STRATEGY can be one of:
+
+     'fp'
+          Performs the operation in floating point.  This has a very
+          high latency, but needs only a few instructions, so it might
+          be a good choice if your code has enough easily-exploitable
+          ILP to allow the compiler to schedule the floating-point
+          instructions together with other instructions.  Division by
+          zero causes a floating-point exception.
+
+     'inv'
+          Uses integer operations to calculate the inverse of the
+          divisor, and then multiplies the dividend with the inverse.
+          This strategy allows CSE and hoisting of the inverse
+          calculation.  Division by zero calculates an unspecified
+          result, but does not trap.
+
+     'inv:minlat'
+          A variant of 'inv' where, if no CSE or hoisting opportunities
+          have been found, or if the entire operation has been hoisted
+          to the same place, the last stages of the inverse calculation
+          are intertwined with the final multiply to reduce the overall
+          latency, at the expense of using a few more instructions, and
+          thus offering fewer scheduling opportunities with other code.
+
+     'call'
+          Calls a library function that usually implements the
+          'inv:minlat' strategy.  This gives high code density for
+          'm5-*media-nofpu' compilations.
+
+     'call2'
+          Uses a different entry point of the same library function,
+          where it assumes that a pointer to a lookup table has already
+          been set up, which exposes the pointer load to CSE and code
+          hoisting optimizations.
+
+     'inv:call'
+     'inv:call2'
+     'inv:fp'
+          Use the 'inv' algorithm for initial code generation, but if
+          the code stays unoptimized, revert to the 'call', 'call2', or
+          'fp' strategies, respectively.  Note that the
+          potentially-trapping side effect of division by zero is
+          carried by a separate instruction, so it is possible that all
+          the integer instructions are hoisted out, but the marker for
+          the side effect stays where it is.  A recombination to
+          floating-point operations or a call is not possible in that
+          case.
+
+     'inv20u'
+     'inv20l'
+          Variants of the 'inv:minlat' strategy.  In the case that the
+          inverse calculation is not separated from the multiply, they
+          speed up division where the dividend fits into 20 bits (plus
+          sign where applicable) by inserting a test to skip a number of
+          operations in this case; this test slows down the case of
+          larger dividends.  'inv20u' assumes the case of a such a small
+          dividend to be unlikely, and 'inv20l' assumes it to be likely.
+
+     For targets other than SHmedia STRATEGY can be one of:
+
+     'call-div1'
+          Calls a library function that uses the single-step division
+          instruction 'div1' to perform the operation.  Division by zero
+          calculates an unspecified result and does not trap.  This is
+          the default except for SH4, SH2A and SHcompact.
+
+     'call-fp'
+          Calls a library function that performs the operation in double
+          precision floating point.  Division by zero causes a
+          floating-point exception.  This is the default for SHcompact
+          with FPU. Specifying this for targets that do not have a
+          double precision FPU will default to 'call-div1'.
+
+     'call-table'
+          Calls a library function that uses a lookup table for small
+          divisors and the 'div1' instruction with case distinction for
+          larger divisors.  Division by zero calculates an unspecified
+          result and does not trap.  This is the default for SH4.
+          Specifying this for targets that do not have dynamic shift
+          instructions will default to 'call-div1'.
+
+     When a division strategy has not been specified the default
+     strategy will be selected based on the current target.  For SH2A
+     the default strategy is to use the 'divs' and 'divu' instructions
+     instead of library function calls.
+
+'-maccumulate-outgoing-args'
+     Reserve space once for outgoing arguments in the function prologue
+     rather than around each call.  Generally beneficial for performance
+     and size.  Also needed for unwinding to avoid changing the stack
+     frame around conditional code.
+
+'-mdivsi3_libfunc=NAME'
+     Set the name of the library function used for 32-bit signed
+     division to NAME.  This only affects the name used in the 'call'
+     and 'inv:call' division strategies, and the compiler still expects
+     the same sets of input/output/clobbered registers as if this option
+     were not present.
+
+'-mfixed-range=REGISTER-RANGE'
+     Generate code treating the given register range as fixed registers.
+     A fixed register is one that the register allocator can not use.
+     This is useful when compiling kernel code.  A register range is
+     specified as two registers separated by a dash.  Multiple register
+     ranges can be specified separated by a comma.
+
+'-mindexed-addressing'
+     Enable the use of the indexed addressing mode for
+     SHmedia32/SHcompact.  This is only safe if the hardware and/or OS
+     implement 32-bit wrap-around semantics for the indexed addressing
+     mode.  The architecture allows the implementation of processors
+     with 64-bit MMU, which the OS could use to get 32-bit addressing,
+     but since no current hardware implementation supports this or any
+     other way to make the indexed addressing mode safe to use in the
+     32-bit ABI, the default is '-mno-indexed-addressing'.
+
+'-mgettrcost=NUMBER'
+     Set the cost assumed for the 'gettr' instruction to NUMBER.  The
+     default is 2 if '-mpt-fixed' is in effect, 100 otherwise.
+
+'-mpt-fixed'
+     Assume 'pt*' instructions won't trap.  This generally generates
+     better-scheduled code, but is unsafe on current hardware.  The
+     current architecture definition says that 'ptabs' and 'ptrel' trap
+     when the target anded with 3 is 3.  This has the unintentional
+     effect of making it unsafe to schedule these instructions before a
+     branch, or hoist them out of a loop.  For example,
+     '__do_global_ctors', a part of 'libgcc' that runs constructors at
+     program startup, calls functions in a list which is delimited by
+     -1.  With the '-mpt-fixed' option, the 'ptabs' is done before
+     testing against -1.  That means that all the constructors run a bit
+     more quickly, but when the loop comes to the end of the list, the
+     program crashes because 'ptabs' loads -1 into a target register.
+
+     Since this option is unsafe for any hardware implementing the
+     current architecture specification, the default is '-mno-pt-fixed'.
+     Unless specified explicitly with '-mgettrcost', '-mno-pt-fixed'
+     also implies '-mgettrcost=100'; this deters register allocation
+     from using target registers for storing ordinary integers.
+
+'-minvalid-symbols'
+     Assume symbols might be invalid.  Ordinary function symbols
+     generated by the compiler are always valid to load with
+     'movi'/'shori'/'ptabs' or 'movi'/'shori'/'ptrel', but with
+     assembler and/or linker tricks it is possible to generate symbols
+     that cause 'ptabs' or 'ptrel' to trap.  This option is only
+     meaningful when '-mno-pt-fixed' is in effect.  It prevents
+     cross-basic-block CSE, hoisting and most scheduling of symbol
+     loads.  The default is '-mno-invalid-symbols'.
+
+'-mbranch-cost=NUM'
+     Assume NUM to be the cost for a branch instruction.  Higher numbers
+     make the compiler try to generate more branch-free code if
+     possible.  If not specified the value is selected depending on the
+     processor type that is being compiled for.
+
+'-mzdcbranch'
+'-mno-zdcbranch'
+     Assume (do not assume) that zero displacement conditional branch
+     instructions 'bt' and 'bf' are fast.  If '-mzdcbranch' is
+     specified, the compiler will try to prefer zero displacement branch
+     code sequences.  This is enabled by default when generating code
+     for SH4 and SH4A. It can be explicitly disabled by specifying
+     '-mno-zdcbranch'.
+
+'-mfused-madd'
+'-mno-fused-madd'
+     Generate code that uses (does not use) the floating-point multiply
+     and accumulate instructions.  These instructions are generated by
+     default if hardware floating point is used.  The machine-dependent
+     '-mfused-madd' option is now mapped to the machine-independent
+     '-ffp-contract=fast' option, and '-mno-fused-madd' is mapped to
+     '-ffp-contract=off'.
+
+'-mfsca'
+'-mno-fsca'
+     Allow or disallow the compiler to emit the 'fsca' instruction for
+     sine and cosine approximations.  The option '-mfsca' must be used
+     in combination with '-funsafe-math-optimizations'.  It is enabled
+     by default when generating code for SH4A. Using '-mno-fsca'
+     disables sine and cosine approximations even if
+     '-funsafe-math-optimizations' is in effect.
+
+'-mfsrra'
+'-mno-fsrra'
+     Allow or disallow the compiler to emit the 'fsrra' instruction for
+     reciprocal square root approximations.  The option '-mfsrra' must
+     be used in combination with '-funsafe-math-optimizations' and
+     '-ffinite-math-only'.  It is enabled by default when generating
+     code for SH4A. Using '-mno-fsrra' disables reciprocal square root
+     approximations even if '-funsafe-math-optimizations' and
+     '-ffinite-math-only' are in effect.
+
+'-mpretend-cmove'
+     Prefer zero-displacement conditional branches for conditional move
+     instruction patterns.  This can result in faster code on the SH4
+     processor.
+
+
+File: gcc.info,  Node: Solaris 2 Options,  Next: SPARC Options,  Prev: SH Options,  Up: Submodel Options
+
+3.17.43 Solaris 2 Options
+-------------------------
+
+These '-m' options are supported on Solaris 2:
+
+'-mimpure-text'
+     '-mimpure-text', used in addition to '-shared', tells the compiler
+     to not pass '-z text' to the linker when linking a shared object.
+     Using this option, you can link position-dependent code into a
+     shared object.
+
+     '-mimpure-text' suppresses the "relocations remain against
+     allocatable but non-writable sections" linker error message.
+     However, the necessary relocations trigger copy-on-write, and the
+     shared object is not actually shared across processes.  Instead of
+     using '-mimpure-text', you should compile all source code with
+     '-fpic' or '-fPIC'.
+
+ These switches are supported in addition to the above on Solaris 2:
+
+'-pthreads'
+     Add support for multithreading using the POSIX threads library.
+     This option sets flags for both the preprocessor and linker.  This
+     option does not affect the thread safety of object code produced by
+     the compiler or that of libraries supplied with it.
+
+'-pthread'
+     This is a synonym for '-pthreads'.
+
+
+File: gcc.info,  Node: SPARC Options,  Next: SPU Options,  Prev: Solaris 2 Options,  Up: Submodel Options
+
+3.17.44 SPARC Options
+---------------------
+
+These '-m' options are supported on the SPARC:
+
+'-mno-app-regs'
+'-mapp-regs'
+     Specify '-mapp-regs' to generate output using the global registers
+     2 through 4, which the SPARC SVR4 ABI reserves for applications.
+     Like the global register 1, each global register 2 through 4 is
+     then treated as an allocable register that is clobbered by function
+     calls.  This is the default.
+
+     To be fully SVR4 ABI-compliant at the cost of some performance
+     loss, specify '-mno-app-regs'.  You should compile libraries and
+     system software with this option.
+
+'-mflat'
+'-mno-flat'
+     With '-mflat', the compiler does not generate save/restore
+     instructions and uses a "flat" or single register window model.
+     This model is compatible with the regular register window model.
+     The local registers and the input registers (0-5) are still treated
+     as "call-saved" registers and are saved on the stack as needed.
+
+     With '-mno-flat' (the default), the compiler generates save/restore
+     instructions (except for leaf functions).  This is the normal
+     operating mode.
+
+'-mfpu'
+'-mhard-float'
+     Generate output containing floating-point instructions.  This is
+     the default.
+
+'-mno-fpu'
+'-msoft-float'
+     Generate output containing library calls for floating point.
+     *Warning:* the requisite libraries are not available for all SPARC
+     targets.  Normally the facilities of the machine's usual C compiler
+     are used, but this cannot be done directly in cross-compilation.
+     You must make your own arrangements to provide suitable library
+     functions for cross-compilation.  The embedded targets
+     'sparc-*-aout' and 'sparclite-*-*' do provide software
+     floating-point support.
+
+     '-msoft-float' changes the calling convention in the output file;
+     therefore, it is only useful if you compile _all_ of a program with
+     this option.  In particular, you need to compile 'libgcc.a', the
+     library that comes with GCC, with '-msoft-float' in order for this
+     to work.
+
+'-mhard-quad-float'
+     Generate output containing quad-word (long double) floating-point
+     instructions.
+
+'-msoft-quad-float'
+     Generate output containing library calls for quad-word (long
+     double) floating-point instructions.  The functions called are
+     those specified in the SPARC ABI.  This is the default.
+
+     As of this writing, there are no SPARC implementations that have
+     hardware support for the quad-word floating-point instructions.
+     They all invoke a trap handler for one of these instructions, and
+     then the trap handler emulates the effect of the instruction.
+     Because of the trap handler overhead, this is much slower than
+     calling the ABI library routines.  Thus the '-msoft-quad-float'
+     option is the default.
+
+'-mno-unaligned-doubles'
+'-munaligned-doubles'
+     Assume that doubles have 8-byte alignment.  This is the default.
+
+     With '-munaligned-doubles', GCC assumes that doubles have 8-byte
+     alignment only if they are contained in another type, or if they
+     have an absolute address.  Otherwise, it assumes they have 4-byte
+     alignment.  Specifying this option avoids some rare compatibility
+     problems with code generated by other compilers.  It is not the
+     default because it results in a performance loss, especially for
+     floating-point code.
+
+'-mno-faster-structs'
+'-mfaster-structs'
+     With '-mfaster-structs', the compiler assumes that structures
+     should have 8-byte alignment.  This enables the use of pairs of
+     'ldd' and 'std' instructions for copies in structure assignment, in
+     place of twice as many 'ld' and 'st' pairs.  However, the use of
+     this changed alignment directly violates the SPARC ABI.  Thus, it's
+     intended only for use on targets where the developer acknowledges
+     that their resulting code is not directly in line with the rules of
+     the ABI.
+
+'-mcpu=CPU_TYPE'
+     Set the instruction set, register set, and instruction scheduling
+     parameters for machine type CPU_TYPE.  Supported values for
+     CPU_TYPE are 'v7', 'cypress', 'v8', 'supersparc', 'hypersparc',
+     'leon', 'leon3', 'sparclite', 'f930', 'f934', 'sparclite86x',
+     'sparclet', 'tsc701', 'v9', 'ultrasparc', 'ultrasparc3', 'niagara',
+     'niagara2', 'niagara3' and 'niagara4'.
+
+     Native Solaris and GNU/Linux toolchains also support the value
+     'native', which selects the best architecture option for the host
+     processor.  '-mcpu=native' has no effect if GCC does not recognize
+     the processor.
+
+     Default instruction scheduling parameters are used for values that
+     select an architecture and not an implementation.  These are 'v7',
+     'v8', 'sparclite', 'sparclet', 'v9'.
+
+     Here is a list of each supported architecture and their supported
+     implementations.
+
+     v7
+          cypress
+
+     v8
+          supersparc, hypersparc, leon, leon3
+
+     sparclite
+          f930, f934, sparclite86x
+
+     sparclet
+          tsc701
+
+     v9
+          ultrasparc, ultrasparc3, niagara, niagara2, niagara3, niagara4
+
+     By default (unless configured otherwise), GCC generates code for
+     the V7 variant of the SPARC architecture.  With '-mcpu=cypress',
+     the compiler additionally optimizes it for the Cypress CY7C602
+     chip, as used in the SPARCStation/SPARCServer 3xx series.  This is
+     also appropriate for the older SPARCStation 1, 2, IPX etc.
+
+     With '-mcpu=v8', GCC generates code for the V8 variant of the SPARC
+     architecture.  The only difference from V7 code is that the
+     compiler emits the integer multiply and integer divide instructions
+     which exist in SPARC-V8 but not in SPARC-V7.  With
+     '-mcpu=supersparc', the compiler additionally optimizes it for the
+     SuperSPARC chip, as used in the SPARCStation 10, 1000 and 2000
+     series.
+
+     With '-mcpu=sparclite', GCC generates code for the SPARClite
+     variant of the SPARC architecture.  This adds the integer multiply,
+     integer divide step and scan ('ffs') instructions which exist in
+     SPARClite but not in SPARC-V7.  With '-mcpu=f930', the compiler
+     additionally optimizes it for the Fujitsu MB86930 chip, which is
+     the original SPARClite, with no FPU.  With '-mcpu=f934', the
+     compiler additionally optimizes it for the Fujitsu MB86934 chip,
+     which is the more recent SPARClite with FPU.
+
+     With '-mcpu=sparclet', GCC generates code for the SPARClet variant
+     of the SPARC architecture.  This adds the integer multiply,
+     multiply/accumulate, integer divide step and scan ('ffs')
+     instructions which exist in SPARClet but not in SPARC-V7.  With
+     '-mcpu=tsc701', the compiler additionally optimizes it for the
+     TEMIC SPARClet chip.
+
+     With '-mcpu=v9', GCC generates code for the V9 variant of the SPARC
+     architecture.  This adds 64-bit integer and floating-point move
+     instructions, 3 additional floating-point condition code registers
+     and conditional move instructions.  With '-mcpu=ultrasparc', the
+     compiler additionally optimizes it for the Sun UltraSPARC I/II/IIi
+     chips.  With '-mcpu=ultrasparc3', the compiler additionally
+     optimizes it for the Sun UltraSPARC III/III+/IIIi/IIIi+/IV/IV+
+     chips.  With '-mcpu=niagara', the compiler additionally optimizes
+     it for Sun UltraSPARC T1 chips.  With '-mcpu=niagara2', the
+     compiler additionally optimizes it for Sun UltraSPARC T2 chips.
+     With '-mcpu=niagara3', the compiler additionally optimizes it for
+     Sun UltraSPARC T3 chips.  With '-mcpu=niagara4', the compiler
+     additionally optimizes it for Sun UltraSPARC T4 chips.
+
+'-mtune=CPU_TYPE'
+     Set the instruction scheduling parameters for machine type
+     CPU_TYPE, but do not set the instruction set or register set that
+     the option '-mcpu=CPU_TYPE' does.
+
+     The same values for '-mcpu=CPU_TYPE' can be used for
+     '-mtune=CPU_TYPE', but the only useful values are those that select
+     a particular CPU implementation.  Those are 'cypress',
+     'supersparc', 'hypersparc', 'leon', 'leon3', 'f930', 'f934',
+     'sparclite86x', 'tsc701', 'ultrasparc', 'ultrasparc3', 'niagara',
+     'niagara2', 'niagara3' and 'niagara4'.  With native Solaris and
+     GNU/Linux toolchains, 'native' can also be used.
+
+'-mv8plus'
+'-mno-v8plus'
+     With '-mv8plus', GCC generates code for the SPARC-V8+ ABI.  The
+     difference from the V8 ABI is that the global and out registers are
+     considered 64 bits wide.  This is enabled by default on Solaris in
+     32-bit mode for all SPARC-V9 processors.
+
+'-mvis'
+'-mno-vis'
+     With '-mvis', GCC generates code that takes advantage of the
+     UltraSPARC Visual Instruction Set extensions.  The default is
+     '-mno-vis'.
+
+'-mvis2'
+'-mno-vis2'
+     With '-mvis2', GCC generates code that takes advantage of version
+     2.0 of the UltraSPARC Visual Instruction Set extensions.  The
+     default is '-mvis2' when targeting a cpu that supports such
+     instructions, such as UltraSPARC-III and later.  Setting '-mvis2'
+     also sets '-mvis'.
+
+'-mvis3'
+'-mno-vis3'
+     With '-mvis3', GCC generates code that takes advantage of version
+     3.0 of the UltraSPARC Visual Instruction Set extensions.  The
+     default is '-mvis3' when targeting a cpu that supports such
+     instructions, such as niagara-3 and later.  Setting '-mvis3' also
+     sets '-mvis2' and '-mvis'.
+
+'-mcbcond'
+'-mno-cbcond'
+     With '-mcbcond', GCC generates code that takes advantage of
+     compare-and-branch instructions, as defined in the Sparc
+     Architecture 2011.  The default is '-mcbcond' when targeting a cpu
+     that supports such instructions, such as niagara-4 and later.
+
+'-mpopc'
+'-mno-popc'
+     With '-mpopc', GCC generates code that takes advantage of the
+     UltraSPARC population count instruction.  The default is '-mpopc'
+     when targeting a cpu that supports such instructions, such as
+     Niagara-2 and later.
+
+'-mfmaf'
+'-mno-fmaf'
+     With '-mfmaf', GCC generates code that takes advantage of the
+     UltraSPARC Fused Multiply-Add Floating-point extensions.  The
+     default is '-mfmaf' when targeting a cpu that supports such
+     instructions, such as Niagara-3 and later.
+
+'-mfix-at697f'
+     Enable the documented workaround for the single erratum of the
+     Atmel AT697F processor (which corresponds to erratum #13 of the
+     AT697E processor).
+
+'-mfix-ut699'
+     Enable the documented workarounds for the floating-point errata and
+     the data cache nullify errata of the UT699 processor.
+
+ These '-m' options are supported in addition to the above on SPARC-V9
+processors in 64-bit environments:
+
+'-m32'
+'-m64'
+     Generate code for a 32-bit or 64-bit environment.  The 32-bit
+     environment sets int, long and pointer to 32 bits.  The 64-bit
+     environment sets int to 32 bits and long and pointer to 64 bits.
+
+'-mcmodel=WHICH'
+     Set the code model to one of
+
+     'medlow'
+          The Medium/Low code model: 64-bit addresses, programs must be
+          linked in the low 32 bits of memory.  Programs can be
+          statically or dynamically linked.
+
+     'medmid'
+          The Medium/Middle code model: 64-bit addresses, programs must
+          be linked in the low 44 bits of memory, the text and data
+          segments must be less than 2GB in size and the data segment
+          must be located within 2GB of the text segment.
+
+     'medany'
+          The Medium/Anywhere code model: 64-bit addresses, programs may
+          be linked anywhere in memory, the text and data segments must
+          be less than 2GB in size and the data segment must be located
+          within 2GB of the text segment.
+
+     'embmedany'
+          The Medium/Anywhere code model for embedded systems: 64-bit
+          addresses, the text and data segments must be less than 2GB in
+          size, both starting anywhere in memory (determined at link
+          time).  The global register %g4 points to the base of the data
+          segment.  Programs are statically linked and PIC is not
+          supported.
+
+'-mmemory-model=MEM-MODEL'
+     Set the memory model in force on the processor to one of
+
+     'default'
+          The default memory model for the processor and operating
+          system.
+
+     'rmo'
+          Relaxed Memory Order
+
+     'pso'
+          Partial Store Order
+
+     'tso'
+          Total Store Order
+
+     'sc'
+          Sequential Consistency
+
+     These memory models are formally defined in Appendix D of the Sparc
+     V9 architecture manual, as set in the processor's 'PSTATE.MM'
+     field.
+
+'-mstack-bias'
+'-mno-stack-bias'
+     With '-mstack-bias', GCC assumes that the stack pointer, and frame
+     pointer if present, are offset by -2047 which must be added back
+     when making stack frame references.  This is the default in 64-bit
+     mode.  Otherwise, assume no such offset is present.
+
+
+File: gcc.info,  Node: SPU Options,  Next: System V Options,  Prev: SPARC Options,  Up: Submodel Options
+
+3.17.45 SPU Options
+-------------------
+
+These '-m' options are supported on the SPU:
+
+'-mwarn-reloc'
+'-merror-reloc'
+
+     The loader for SPU does not handle dynamic relocations.  By
+     default, GCC gives an error when it generates code that requires a
+     dynamic relocation.  '-mno-error-reloc' disables the error,
+     '-mwarn-reloc' generates a warning instead.
+
+'-msafe-dma'
+'-munsafe-dma'
+
+     Instructions that initiate or test completion of DMA must not be
+     reordered with respect to loads and stores of the memory that is
+     being accessed.  With '-munsafe-dma' you must use the 'volatile'
+     keyword to protect memory accesses, but that can lead to
+     inefficient code in places where the memory is known to not change.
+     Rather than mark the memory as volatile, you can use '-msafe-dma'
+     to tell the compiler to treat the DMA instructions as potentially
+     affecting all memory.
+
+'-mbranch-hints'
+
+     By default, GCC generates a branch hint instruction to avoid
+     pipeline stalls for always-taken or probably-taken branches.  A
+     hint is not generated closer than 8 instructions away from its
+     branch.  There is little reason to disable them, except for
+     debugging purposes, or to make an object a little bit smaller.
+
+'-msmall-mem'
+'-mlarge-mem'
+
+     By default, GCC generates code assuming that addresses are never
+     larger than 18 bits.  With '-mlarge-mem' code is generated that
+     assumes a full 32-bit address.
+
+'-mstdmain'
+
+     By default, GCC links against startup code that assumes the
+     SPU-style main function interface (which has an unconventional
+     parameter list).  With '-mstdmain', GCC links your program against
+     startup code that assumes a C99-style interface to 'main',
+     including a local copy of 'argv' strings.
+
+'-mfixed-range=REGISTER-RANGE'
+     Generate code treating the given register range as fixed registers.
+     A fixed register is one that the register allocator cannot use.
+     This is useful when compiling kernel code.  A register range is
+     specified as two registers separated by a dash.  Multiple register
+     ranges can be specified separated by a comma.
+
+'-mea32'
+'-mea64'
+     Compile code assuming that pointers to the PPU address space
+     accessed via the '__ea' named address space qualifier are either 32
+     or 64 bits wide.  The default is 32 bits.  As this is an
+     ABI-changing option, all object code in an executable must be
+     compiled with the same setting.
+
+'-maddress-space-conversion'
+'-mno-address-space-conversion'
+     Allow/disallow treating the '__ea' address space as superset of the
+     generic address space.  This enables explicit type casts between
+     '__ea' and generic pointer as well as implicit conversions of
+     generic pointers to '__ea' pointers.  The default is to allow
+     address space pointer conversions.
+
+'-mcache-size=CACHE-SIZE'
+     This option controls the version of libgcc that the compiler links
+     to an executable and selects a software-managed cache for accessing
+     variables in the '__ea' address space with a particular cache size.
+     Possible options for CACHE-SIZE are '8', '16', '32', '64' and
+     '128'.  The default cache size is 64KB.
+
+'-matomic-updates'
+'-mno-atomic-updates'
+     This option controls the version of libgcc that the compiler links
+     to an executable and selects whether atomic updates to the
+     software-managed cache of PPU-side variables are used.  If you use
+     atomic updates, changes to a PPU variable from SPU code using the
+     '__ea' named address space qualifier do not interfere with changes
+     to other PPU variables residing in the same cache line from PPU
+     code.  If you do not use atomic updates, such interference may
+     occur; however, writing back cache lines is more efficient.  The
+     default behavior is to use atomic updates.
+
+'-mdual-nops'
+'-mdual-nops=N'
+     By default, GCC inserts nops to increase dual issue when it expects
+     it to increase performance.  N can be a value from 0 to 10.  A
+     smaller N inserts fewer nops.  10 is the default, 0 is the same as
+     '-mno-dual-nops'.  Disabled with '-Os'.
+
+'-mhint-max-nops=N'
+     Maximum number of nops to insert for a branch hint.  A branch hint
+     must be at least 8 instructions away from the branch it is
+     affecting.  GCC inserts up to N nops to enforce this, otherwise it
+     does not generate the branch hint.
+
+'-mhint-max-distance=N'
+     The encoding of the branch hint instruction limits the hint to be
+     within 256 instructions of the branch it is affecting.  By default,
+     GCC makes sure it is within 125.
+
+'-msafe-hints'
+     Work around a hardware bug that causes the SPU to stall
+     indefinitely.  By default, GCC inserts the 'hbrp' instruction to
+     make sure this stall won't happen.
+
+
+File: gcc.info,  Node: System V Options,  Next: TILE-Gx Options,  Prev: SPU Options,  Up: Submodel Options
+
+3.17.46 Options for System V
+----------------------------
+
+These additional options are available on System V Release 4 for
+compatibility with other compilers on those systems:
+
+'-G'
+     Create a shared object.  It is recommended that '-symbolic' or
+     '-shared' be used instead.
+
+'-Qy'
+     Identify the versions of each tool used by the compiler, in a
+     '.ident' assembler directive in the output.
+
+'-Qn'
+     Refrain from adding '.ident' directives to the output file (this is
+     the default).
+
+'-YP,DIRS'
+     Search the directories DIRS, and no others, for libraries specified
+     with '-l'.
+
+'-Ym,DIR'
+     Look in the directory DIR to find the M4 preprocessor.  The
+     assembler uses this option.
+
+
+File: gcc.info,  Node: TILE-Gx Options,  Next: TILEPro Options,  Prev: System V Options,  Up: Submodel Options
+
+3.17.47 TILE-Gx Options
+-----------------------
+
+These '-m' options are supported on the TILE-Gx:
+
+'-mcmodel=small'
+     Generate code for the small model.  The distance for direct calls
+     is limited to 500M in either direction.  PC-relative addresses are
+     32 bits.  Absolute addresses support the full address range.
+
+'-mcmodel=large'
+     Generate code for the large model.  There is no limitation on call
+     distance, pc-relative addresses, or absolute addresses.
+
+'-mcpu=NAME'
+     Selects the type of CPU to be targeted.  Currently the only
+     supported type is 'tilegx'.
+
+'-m32'
+'-m64'
+     Generate code for a 32-bit or 64-bit environment.  The 32-bit
+     environment sets int, long, and pointer to 32 bits.  The 64-bit
+     environment sets int to 32 bits and long and pointer to 64 bits.
+
+'-mbig-endian'
+'-mlittle-endian'
+     Generate code in big/little endian mode, respectively.
+
+
+File: gcc.info,  Node: TILEPro Options,  Next: V850 Options,  Prev: TILE-Gx Options,  Up: Submodel Options
+
+3.17.48 TILEPro Options
+-----------------------
+
+These '-m' options are supported on the TILEPro:
+
+'-mcpu=NAME'
+     Selects the type of CPU to be targeted.  Currently the only
+     supported type is 'tilepro'.
+
+'-m32'
+     Generate code for a 32-bit environment, which sets int, long, and
+     pointer to 32 bits.  This is the only supported behavior so the
+     flag is essentially ignored.
+
+
+File: gcc.info,  Node: V850 Options,  Next: VAX Options,  Prev: TILEPro Options,  Up: Submodel Options
+
+3.17.49 V850 Options
+--------------------
+
+These '-m' options are defined for V850 implementations:
+
+'-mlong-calls'
+'-mno-long-calls'
+     Treat all calls as being far away (near).  If calls are assumed to
+     be far away, the compiler always loads the function's address into
+     a register, and calls indirect through the pointer.
+
+'-mno-ep'
+'-mep'
+     Do not optimize (do optimize) basic blocks that use the same index
+     pointer 4 or more times to copy pointer into the 'ep' register, and
+     use the shorter 'sld' and 'sst' instructions.  The '-mep' option is
+     on by default if you optimize.
+
+'-mno-prolog-function'
+'-mprolog-function'
+     Do not use (do use) external functions to save and restore
+     registers at the prologue and epilogue of a function.  The external
+     functions are slower, but use less code space if more than one
+     function saves the same number of registers.  The
+     '-mprolog-function' option is on by default if you optimize.
+
+'-mspace'
+     Try to make the code as small as possible.  At present, this just
+     turns on the '-mep' and '-mprolog-function' options.
+
+'-mtda=N'
+     Put static or global variables whose size is N bytes or less into
+     the tiny data area that register 'ep' points to.  The tiny data
+     area can hold up to 256 bytes in total (128 bytes for byte
+     references).
+
+'-msda=N'
+     Put static or global variables whose size is N bytes or less into
+     the small data area that register 'gp' points to.  The small data
+     area can hold up to 64 kilobytes.
+
+'-mzda=N'
+     Put static or global variables whose size is N bytes or less into
+     the first 32 kilobytes of memory.
+
+'-mv850'
+     Specify that the target processor is the V850.
+
+'-mv850e3v5'
+     Specify that the target processor is the V850E3V5.  The
+     preprocessor constant '__v850e3v5__' is defined if this option is
+     used.
+
+'-mv850e2v4'
+     Specify that the target processor is the V850E3V5.  This is an
+     alias for the '-mv850e3v5' option.
+
+'-mv850e2v3'
+     Specify that the target processor is the V850E2V3.  The
+     preprocessor constant '__v850e2v3__' is defined if this option is
+     used.
+
+'-mv850e2'
+     Specify that the target processor is the V850E2.  The preprocessor
+     constant '__v850e2__' is defined if this option is used.
+
+'-mv850e1'
+     Specify that the target processor is the V850E1.  The preprocessor
+     constants '__v850e1__' and '__v850e__' are defined if this option
+     is used.
+
+'-mv850es'
+     Specify that the target processor is the V850ES. This is an alias
+     for the '-mv850e1' option.
+
+'-mv850e'
+     Specify that the target processor is the V850E.  The preprocessor
+     constant '__v850e__' is defined if this option is used.
+
+     If neither '-mv850' nor '-mv850e' nor '-mv850e1' nor '-mv850e2' nor
+     '-mv850e2v3' nor '-mv850e3v5' are defined then a default target
+     processor is chosen and the relevant '__v850*__' preprocessor
+     constant is defined.
+
+     The preprocessor constants '__v850' and '__v851__' are always
+     defined, regardless of which processor variant is the target.
+
+'-mdisable-callt'
+'-mno-disable-callt'
+     This option suppresses generation of the 'CALLT' instruction for
+     the v850e, v850e1, v850e2, v850e2v3 and v850e3v5 flavors of the
+     v850 architecture.
+
+     This option is enabled by default when the RH850 ABI is in use (see
+     '-mrh850-abi'), and disabled by default when the GCC ABI is in use.
+     If 'CALLT' instructions are being generated then the C preprocessor
+     symbol '__V850_CALLT__' will be defined.
+
+'-mrelax'
+'-mno-relax'
+     Pass on (or do not pass on) the '-mrelax' command line option to
+     the assembler.
+
+'-mlong-jumps'
+'-mno-long-jumps'
+     Disable (or re-enable) the generation of PC-relative jump
+     instructions.
+
+'-msoft-float'
+'-mhard-float'
+     Disable (or re-enable) the generation of hardware floating point
+     instructions.  This option is only significant when the target
+     architecture is 'V850E2V3' or higher.  If hardware floating point
+     instructions are being generated then the C preprocessor symbol
+     '__FPU_OK__' will be defined, otherwise the symbol '__NO_FPU__'
+     will be defined.
+
+'-mloop'
+     Enables the use of the e3v5 LOOP instruction.  The use of this
+     instruction is not enabled by default when the e3v5 architecture is
+     selected because its use is still experimental.
+
+'-mrh850-abi'
+'-mghs'
+     Enables support for the RH850 version of the V850 ABI. This is the
+     default.  With this version of the ABI the following rules apply:
+
+        * Integer sized structures and unions are returned via a memory
+          pointer rather than a register.
+
+        * Large structures and unions (more than 8 bytes in size) are
+          passed by value.
+
+        * Functions are aligned to 16-bit boundaries.
+
+        * The '-m8byte-align' command line option is supported.
+
+        * The '-mdisable-callt' command line option is enabled by
+          default.  The '-mno-disable-callt' command line option is not
+          supported.
+
+     When this version of the ABI is enabled the C preprocessor symbol
+     '__V850_RH850_ABI__' is defined.
+
+'-mgcc-abi'
+     Enables support for the old GCC version of the V850 ABI. With this
+     version of the ABI the following rules apply:
+
+        * Integer sized structures and unions are returned in register
+          'r10'.
+
+        * Large structures and unions (more than 8 bytes in size) are
+          passed by reference.
+
+        * Functions are aligned to 32-bit boundaries, unless optimizing
+          for size.
+
+        * The '-m8byte-align' command line option is not supported.
+
+        * The '-mdisable-callt' command line option is supported but not
+          enabled by default.
+
+     When this version of the ABI is enabled the C preprocessor symbol
+     '__V850_GCC_ABI__' is defined.
+
+'-m8byte-align'
+'-mno-8byte-align'
+     Enables support for 'doubles' and 'long long' types to be aligned
+     on 8-byte boundaries.  The default is to restrict the alignment of
+     all objects to at most 4-bytes.  When '-m8byte-align' is in effect
+     the C preprocessor symbol '__V850_8BYTE_ALIGN__' will be defined.
+
+'-mbig-switch'
+     Generate code suitable for big switch tables.  Use this option only
+     if the assembler/linker complain about out of range branches within
+     a switch table.
+
+'-mapp-regs'
+     This option causes r2 and r5 to be used in the code generated by
+     the compiler.  This setting is the default.
+
+'-mno-app-regs'
+     This option causes r2 and r5 to be treated as fixed registers.
+
+
+File: gcc.info,  Node: VAX Options,  Next: VMS Options,  Prev: V850 Options,  Up: Submodel Options
+
+3.17.50 VAX Options
+-------------------
+
+These '-m' options are defined for the VAX:
+
+'-munix'
+     Do not output certain jump instructions ('aobleq' and so on) that
+     the Unix assembler for the VAX cannot handle across long ranges.
+
+'-mgnu'
+     Do output those jump instructions, on the assumption that the GNU
+     assembler is being used.
+
+'-mg'
+     Output code for G-format floating-point numbers instead of
+     D-format.
+
+
+File: gcc.info,  Node: VMS Options,  Next: VxWorks Options,  Prev: VAX Options,  Up: Submodel Options
+
+3.17.51 VMS Options
+-------------------
+
+These '-m' options are defined for the VMS implementations:
+
+'-mvms-return-codes'
+     Return VMS condition codes from 'main'.  The default is to return
+     POSIX-style condition (e.g. error) codes.
+
+'-mdebug-main=PREFIX'
+     Flag the first routine whose name starts with PREFIX as the main
+     routine for the debugger.
+
+'-mmalloc64'
+     Default to 64-bit memory allocation routines.
+
+'-mpointer-size=SIZE'
+     Set the default size of pointers.  Possible options for SIZE are
+     '32' or 'short' for 32 bit pointers, '64' or 'long' for 64 bit
+     pointers, and 'no' for supporting only 32 bit pointers.  The later
+     option disables 'pragma pointer_size'.
+
+
+File: gcc.info,  Node: VxWorks Options,  Next: x86-64 Options,  Prev: VMS Options,  Up: Submodel Options
+
+3.17.52 VxWorks Options
+-----------------------
+
+The options in this section are defined for all VxWorks targets.
+Options specific to the target hardware are listed with the other
+options for that target.
+
+'-mrtp'
+     GCC can generate code for both VxWorks kernels and real time
+     processes (RTPs).  This option switches from the former to the
+     latter.  It also defines the preprocessor macro '__RTP__'.
+
+'-non-static'
+     Link an RTP executable against shared libraries rather than static
+     libraries.  The options '-static' and '-shared' can also be used
+     for RTPs (*note Link Options::); '-static' is the default.
+
+'-Bstatic'
+'-Bdynamic'
+     These options are passed down to the linker.  They are defined for
+     compatibility with Diab.
+
+'-Xbind-lazy'
+     Enable lazy binding of function calls.  This option is equivalent
+     to '-Wl,-z,now' and is defined for compatibility with Diab.
+
+'-Xbind-now'
+     Disable lazy binding of function calls.  This option is the default
+     and is defined for compatibility with Diab.
+
+
+File: gcc.info,  Node: x86-64 Options,  Next: Xstormy16 Options,  Prev: VxWorks Options,  Up: Submodel Options
+
+3.17.53 x86-64 Options
+----------------------
+
+These are listed under *Note i386 and x86-64 Options::.
+
+
+File: gcc.info,  Node: Xstormy16 Options,  Next: Xtensa Options,  Prev: x86-64 Options,  Up: Submodel Options
+
+3.17.54 Xstormy16 Options
+-------------------------
+
+These options are defined for Xstormy16:
+
+'-msim'
+     Choose startup files and linker script suitable for the simulator.
+
+
+File: gcc.info,  Node: Xtensa Options,  Next: zSeries Options,  Prev: Xstormy16 Options,  Up: Submodel Options
+
+3.17.55 Xtensa Options
+----------------------
+
+These options are supported for Xtensa targets:
+
+'-mconst16'
+'-mno-const16'
+     Enable or disable use of 'CONST16' instructions for loading
+     constant values.  The 'CONST16' instruction is currently not a
+     standard option from Tensilica.  When enabled, 'CONST16'
+     instructions are always used in place of the standard 'L32R'
+     instructions.  The use of 'CONST16' is enabled by default only if
+     the 'L32R' instruction is not available.
+
+'-mfused-madd'
+'-mno-fused-madd'
+     Enable or disable use of fused multiply/add and multiply/subtract
+     instructions in the floating-point option.  This has no effect if
+     the floating-point option is not also enabled.  Disabling fused
+     multiply/add and multiply/subtract instructions forces the compiler
+     to use separate instructions for the multiply and add/subtract
+     operations.  This may be desirable in some cases where strict IEEE
+     754-compliant results are required: the fused multiply add/subtract
+     instructions do not round the intermediate result, thereby
+     producing results with _more_ bits of precision than specified by
+     the IEEE standard.  Disabling fused multiply add/subtract
+     instructions also ensures that the program output is not sensitive
+     to the compiler's ability to combine multiply and add/subtract
+     operations.
+
+'-mserialize-volatile'
+'-mno-serialize-volatile'
+     When this option is enabled, GCC inserts 'MEMW' instructions before
+     'volatile' memory references to guarantee sequential consistency.
+     The default is '-mserialize-volatile'.  Use
+     '-mno-serialize-volatile' to omit the 'MEMW' instructions.
+
+'-mforce-no-pic'
+     For targets, like GNU/Linux, where all user-mode Xtensa code must
+     be position-independent code (PIC), this option disables PIC for
+     compiling kernel code.
+
+'-mtext-section-literals'
+'-mno-text-section-literals'
+     Control the treatment of literal pools.  The default is
+     '-mno-text-section-literals', which places literals in a separate
+     section in the output file.  This allows the literal pool to be
+     placed in a data RAM/ROM, and it also allows the linker to combine
+     literal pools from separate object files to remove redundant
+     literals and improve code size.  With '-mtext-section-literals',
+     the literals are interspersed in the text section in order to keep
+     them as close as possible to their references.  This may be
+     necessary for large assembly files.
+
+'-mtarget-align'
+'-mno-target-align'
+     When this option is enabled, GCC instructs the assembler to
+     automatically align instructions to reduce branch penalties at the
+     expense of some code density.  The assembler attempts to widen
+     density instructions to align branch targets and the instructions
+     following call instructions.  If there are not enough preceding
+     safe density instructions to align a target, no widening is
+     performed.  The default is '-mtarget-align'.  These options do not
+     affect the treatment of auto-aligned instructions like 'LOOP',
+     which the assembler always aligns, either by widening density
+     instructions or by inserting NOP instructions.
+
+'-mlongcalls'
+'-mno-longcalls'
+     When this option is enabled, GCC instructs the assembler to
+     translate direct calls to indirect calls unless it can determine
+     that the target of a direct call is in the range allowed by the
+     call instruction.  This translation typically occurs for calls to
+     functions in other source files.  Specifically, the assembler
+     translates a direct 'CALL' instruction into an 'L32R' followed by a
+     'CALLX' instruction.  The default is '-mno-longcalls'.  This option
+     should be used in programs where the call target can potentially be
+     out of range.  This option is implemented in the assembler, not the
+     compiler, so the assembly code generated by GCC still shows direct
+     call instructions--look at the disassembled object code to see the
+     actual instructions.  Note that the assembler uses an indirect call
+     for every cross-file call, not just those that really are out of
+     range.
+
+
+File: gcc.info,  Node: zSeries Options,  Prev: Xtensa Options,  Up: Submodel Options
+
+3.17.56 zSeries Options
+-----------------------
+
+These are listed under *Note S/390 and zSeries Options::.
+
+
+File: gcc.info,  Node: Code Gen Options,  Next: Environment Variables,  Prev: Submodel Options,  Up: Invoking GCC
+
+3.18 Options for Code Generation Conventions
+============================================
+
+These machine-independent options control the interface conventions used
+in code generation.
+
+ Most of them have both positive and negative forms; the negative form
+of '-ffoo' is '-fno-foo'.  In the table below, only one of the forms is
+listed--the one that is not the default.  You can figure out the other
+form by either removing 'no-' or adding it.
+
+'-fbounds-check'
+     For front ends that support it, generate additional code to check
+     that indices used to access arrays are within the declared range.
+     This is currently only supported by the Java and Fortran front
+     ends, where this option defaults to true and false respectively.
+
+'-fstack-reuse=REUSE-LEVEL'
+     This option controls stack space reuse for user declared local/auto
+     variables and compiler generated temporaries.  REUSE_LEVEL can be
+     'all', 'named_vars', or 'none'.  'all' enables stack reuse for all
+     local variables and temporaries, 'named_vars' enables the reuse
+     only for user defined local variables with names, and 'none'
+     disables stack reuse completely.  The default value is 'all'.  The
+     option is needed when the program extends the lifetime of a scoped
+     local variable or a compiler generated temporary beyond the end
+     point defined by the language.  When a lifetime of a variable ends,
+     and if the variable lives in memory, the optimizing compiler has
+     the freedom to reuse its stack space with other temporaries or
+     scoped local variables whose live range does not overlap with it.
+     Legacy code extending local lifetime will likely to break with the
+     stack reuse optimization.
+
+     For example,
+
+             int *p;
+             {
+               int local1;
+
+               p = &local1;
+               local1 = 10;
+               ....
+             }
+             {
+                int local2;
+                local2 = 20;
+                ...
+             }
+
+             if (*p == 10)  // out of scope use of local1
+               {
+
+               }
+
+     Another example:
+
+             struct A
+             {
+                 A(int k) : i(k), j(k) { }
+                 int i;
+                 int j;
+             };
+
+             A *ap;
+
+             void foo(const A& ar)
+             {
+                ap = &ar;
+             }
+
+             void bar()
+             {
+                foo(A(10)); // temp object's lifetime ends when foo returns
+
+                {
+                  A a(20);
+                  ....
+                }
+                ap->i+= 10;  // ap references out of scope temp whose space
+                             // is reused with a. What is the value of ap->i?
+             }
+
+     The lifetime of a compiler generated temporary is well defined by
+     the C++ standard.  When a lifetime of a temporary ends, and if the
+     temporary lives in memory, the optimizing compiler has the freedom
+     to reuse its stack space with other temporaries or scoped local
+     variables whose live range does not overlap with it.  However some
+     of the legacy code relies on the behavior of older compilers in
+     which temporaries' stack space is not reused, the aggressive stack
+     reuse can lead to runtime errors.  This option is used to control
+     the temporary stack reuse optimization.
+
+'-ftrapv'
+     This option generates traps for signed overflow on addition,
+     subtraction, multiplication operations.
+
+'-fwrapv'
+     This option instructs the compiler to assume that signed arithmetic
+     overflow of addition, subtraction and multiplication wraps around
+     using twos-complement representation.  This flag enables some
+     optimizations and disables others.  This option is enabled by
+     default for the Java front end, as required by the Java language
+     specification.
+
+'-fexceptions'
+     Enable exception handling.  Generates extra code needed to
+     propagate exceptions.  For some targets, this implies GCC generates
+     frame unwind information for all functions, which can produce
+     significant data size overhead, although it does not affect
+     execution.  If you do not specify this option, GCC enables it by
+     default for languages like C++ that normally require exception
+     handling, and disables it for languages like C that do not normally
+     require it.  However, you may need to enable this option when
+     compiling C code that needs to interoperate properly with exception
+     handlers written in C++.  You may also wish to disable this option
+     if you are compiling older C++ programs that don't use exception
+     handling.
+
+'-fnon-call-exceptions'
+     Generate code that allows trapping instructions to throw
+     exceptions.  Note that this requires platform-specific runtime
+     support that does not exist everywhere.  Moreover, it only allows
+     _trapping_ instructions to throw exceptions, i.e. memory references
+     or floating-point instructions.  It does not allow exceptions to be
+     thrown from arbitrary signal handlers such as 'SIGALRM'.
+
+'-fdelete-dead-exceptions'
+     Consider that instructions that may throw exceptions but don't
+     otherwise contribute to the execution of the program can be
+     optimized away.  This option is enabled by default for the Ada
+     front end, as permitted by the Ada language specification.
+     Optimization passes that cause dead exceptions to be removed are
+     enabled independently at different optimization levels.
+
+'-funwind-tables'
+     Similar to '-fexceptions', except that it just generates any needed
+     static data, but does not affect the generated code in any other
+     way.  You normally do not need to enable this option; instead, a
+     language processor that needs this handling enables it on your
+     behalf.
+
+'-fasynchronous-unwind-tables'
+     Generate unwind table in DWARF 2 format, if supported by target
+     machine.  The table is exact at each instruction boundary, so it
+     can be used for stack unwinding from asynchronous events (such as
+     debugger or garbage collector).
+
+'-fno-gnu-unique'
+     On systems with recent GNU assembler and C library, the C++
+     compiler uses the 'STB_GNU_UNIQUE' binding to make sure that
+     definitions of template static data members and static local
+     variables in inline functions are unique even in the presence of
+     'RTLD_LOCAL'; this is necessary to avoid problems with a library
+     used by two different 'RTLD_LOCAL' plugins depending on a
+     definition in one of them and therefore disagreeing with the other
+     one about the binding of the symbol.  But this causes 'dlclose' to
+     be ignored for affected DSOs; if your program relies on
+     reinitialization of a DSO via 'dlclose' and 'dlopen', you can use
+     '-fno-gnu-unique'.
+
+'-fpcc-struct-return'
+     Return "short" 'struct' and 'union' values in memory like longer
+     ones, rather than in registers.  This convention is less efficient,
+     but it has the advantage of allowing intercallability between
+     GCC-compiled files and files compiled with other compilers,
+     particularly the Portable C Compiler (pcc).
+
+     The precise convention for returning structures in memory depends
+     on the target configuration macros.
+
+     Short structures and unions are those whose size and alignment
+     match that of some integer type.
+
+     *Warning:* code compiled with the '-fpcc-struct-return' switch is
+     not binary compatible with code compiled with the
+     '-freg-struct-return' switch.  Use it to conform to a non-default
+     application binary interface.
+
+'-freg-struct-return'
+     Return 'struct' and 'union' values in registers when possible.
+     This is more efficient for small structures than
+     '-fpcc-struct-return'.
+
+     If you specify neither '-fpcc-struct-return' nor
+     '-freg-struct-return', GCC defaults to whichever convention is
+     standard for the target.  If there is no standard convention, GCC
+     defaults to '-fpcc-struct-return', except on targets where GCC is
+     the principal compiler.  In those cases, we can choose the
+     standard, and we chose the more efficient register return
+     alternative.
+
+     *Warning:* code compiled with the '-freg-struct-return' switch is
+     not binary compatible with code compiled with the
+     '-fpcc-struct-return' switch.  Use it to conform to a non-default
+     application binary interface.
+
+'-fshort-enums'
+     Allocate to an 'enum' type only as many bytes as it needs for the
+     declared range of possible values.  Specifically, the 'enum' type
+     is equivalent to the smallest integer type that has enough room.
+
+     *Warning:* the '-fshort-enums' switch causes GCC to generate code
+     that is not binary compatible with code generated without that
+     switch.  Use it to conform to a non-default application binary
+     interface.
+
+'-fshort-double'
+     Use the same size for 'double' as for 'float'.
+
+     *Warning:* the '-fshort-double' switch causes GCC to generate code
+     that is not binary compatible with code generated without that
+     switch.  Use it to conform to a non-default application binary
+     interface.
+
+'-fshort-wchar'
+     Override the underlying type for 'wchar_t' to be 'short unsigned
+     int' instead of the default for the target.  This option is useful
+     for building programs to run under WINE.
+
+     *Warning:* the '-fshort-wchar' switch causes GCC to generate code
+     that is not binary compatible with code generated without that
+     switch.  Use it to conform to a non-default application binary
+     interface.
+
+'-fno-common'
+     In C code, controls the placement of uninitialized global
+     variables.  Unix C compilers have traditionally permitted multiple
+     definitions of such variables in different compilation units by
+     placing the variables in a common block.  This is the behavior
+     specified by '-fcommon', and is the default for GCC on most
+     targets.  On the other hand, this behavior is not required by ISO
+     C, and on some targets may carry a speed or code size penalty on
+     variable references.  The '-fno-common' option specifies that the
+     compiler should place uninitialized global variables in the data
+     section of the object file, rather than generating them as common
+     blocks.  This has the effect that if the same variable is declared
+     (without 'extern') in two different compilations, you get a
+     multiple-definition error when you link them.  In this case, you
+     must compile with '-fcommon' instead.  Compiling with '-fno-common'
+     is useful on targets for which it provides better performance, or
+     if you wish to verify that the program will work on other systems
+     that always treat uninitialized variable declarations this way.
+
+'-fno-ident'
+     Ignore the '#ident' directive.
+
+'-finhibit-size-directive'
+     Don't output a '.size' assembler directive, or anything else that
+     would cause trouble if the function is split in the middle, and the
+     two halves are placed at locations far apart in memory.  This
+     option is used when compiling 'crtstuff.c'; you should not need to
+     use it for anything else.
+
+'-fverbose-asm'
+     Put extra commentary information in the generated assembly code to
+     make it more readable.  This option is generally only of use to
+     those who actually need to read the generated assembly code
+     (perhaps while debugging the compiler itself).
+
+     '-fno-verbose-asm', the default, causes the extra information to be
+     omitted and is useful when comparing two assembler files.
+
+'-frecord-gcc-switches'
+     This switch causes the command line used to invoke the compiler to
+     be recorded into the object file that is being created.  This
+     switch is only implemented on some targets and the exact format of
+     the recording is target and binary file format dependent, but it
+     usually takes the form of a section containing ASCII text.  This
+     switch is related to the '-fverbose-asm' switch, but that switch
+     only records information in the assembler output file as comments,
+     so it never reaches the object file.  See also
+     '-grecord-gcc-switches' for another way of storing compiler options
+     into the object file.
+
+'-fpic'
+     Generate position-independent code (PIC) suitable for use in a
+     shared library, if supported for the target machine.  Such code
+     accesses all constant addresses through a global offset table
+     (GOT).  The dynamic loader resolves the GOT entries when the
+     program starts (the dynamic loader is not part of GCC; it is part
+     of the operating system).  If the GOT size for the linked
+     executable exceeds a machine-specific maximum size, you get an
+     error message from the linker indicating that '-fpic' does not
+     work; in that case, recompile with '-fPIC' instead.  (These
+     maximums are 8k on the SPARC and 32k on the m68k and RS/6000.  The
+     386 has no such limit.)
+
+     Position-independent code requires special support, and therefore
+     works only on certain machines.  For the 386, GCC supports PIC for
+     System V but not for the Sun 386i.  Code generated for the IBM
+     RS/6000 is always position-independent.
+
+     When this flag is set, the macros '__pic__' and '__PIC__' are
+     defined to 1.
+
+'-fPIC'
+     If supported for the target machine, emit position-independent
+     code, suitable for dynamic linking and avoiding any limit on the
+     size of the global offset table.  This option makes a difference on
+     the m68k, PowerPC and SPARC.
+
+     Position-independent code requires special support, and therefore
+     works only on certain machines.
+
+     When this flag is set, the macros '__pic__' and '__PIC__' are
+     defined to 2.
+
+'-fpie'
+'-fPIE'
+     These options are similar to '-fpic' and '-fPIC', but generated
+     position independent code can be only linked into executables.
+     Usually these options are used when '-pie' GCC option is used
+     during linking.
+
+     '-fpie' and '-fPIE' both define the macros '__pie__' and '__PIE__'.
+     The macros have the value 1 for '-fpie' and 2 for '-fPIE'.
+
+'-fno-jump-tables'
+     Do not use jump tables for switch statements even where it would be
+     more efficient than other code generation strategies.  This option
+     is of use in conjunction with '-fpic' or '-fPIC' for building code
+     that forms part of a dynamic linker and cannot reference the
+     address of a jump table.  On some targets, jump tables do not
+     require a GOT and this option is not needed.
+
+'-ffixed-REG'
+     Treat the register named REG as a fixed register; generated code
+     should never refer to it (except perhaps as a stack pointer, frame
+     pointer or in some other fixed role).
+
+     REG must be the name of a register.  The register names accepted
+     are machine-specific and are defined in the 'REGISTER_NAMES' macro
+     in the machine description macro file.
+
+     This flag does not have a negative form, because it specifies a
+     three-way choice.
+
+'-fcall-used-REG'
+     Treat the register named REG as an allocable register that is
+     clobbered by function calls.  It may be allocated for temporaries
+     or variables that do not live across a call.  Functions compiled
+     this way do not save and restore the register REG.
+
+     It is an error to use this flag with the frame pointer or stack
+     pointer.  Use of this flag for other registers that have fixed
+     pervasive roles in the machine's execution model produces
+     disastrous results.
+
+     This flag does not have a negative form, because it specifies a
+     three-way choice.
+
+'-fcall-saved-REG'
+     Treat the register named REG as an allocable register saved by
+     functions.  It may be allocated even for temporaries or variables
+     that live across a call.  Functions compiled this way save and
+     restore the register REG if they use it.
+
+     It is an error to use this flag with the frame pointer or stack
+     pointer.  Use of this flag for other registers that have fixed
+     pervasive roles in the machine's execution model produces
+     disastrous results.
+
+     A different sort of disaster results from the use of this flag for
+     a register in which function values may be returned.
+
+     This flag does not have a negative form, because it specifies a
+     three-way choice.
+
+'-fpack-struct[=N]'
+     Without a value specified, pack all structure members together
+     without holes.  When a value is specified (which must be a small
+     power of two), pack structure members according to this value,
+     representing the maximum alignment (that is, objects with default
+     alignment requirements larger than this are output potentially
+     unaligned at the next fitting location.
+
+     *Warning:* the '-fpack-struct' switch causes GCC to generate code
+     that is not binary compatible with code generated without that
+     switch.  Additionally, it makes the code suboptimal.  Use it to
+     conform to a non-default application binary interface.
+
+'-finstrument-functions'
+     Generate instrumentation calls for entry and exit to functions.
+     Just after function entry and just before function exit, the
+     following profiling functions are called with the address of the
+     current function and its call site.  (On some platforms,
+     '__builtin_return_address' does not work beyond the current
+     function, so the call site information may not be available to the
+     profiling functions otherwise.)
+
+          void __cyg_profile_func_enter (void *this_fn,
+                                         void *call_site);
+          void __cyg_profile_func_exit  (void *this_fn,
+                                         void *call_site);
+
+     The first argument is the address of the start of the current
+     function, which may be looked up exactly in the symbol table.
+
+     This instrumentation is also done for functions expanded inline in
+     other functions.  The profiling calls indicate where, conceptually,
+     the inline function is entered and exited.  This means that
+     addressable versions of such functions must be available.  If all
+     your uses of a function are expanded inline, this may mean an
+     additional expansion of code size.  If you use 'extern inline' in
+     your C code, an addressable version of such functions must be
+     provided.  (This is normally the case anyway, but if you get lucky
+     and the optimizer always expands the functions inline, you might
+     have gotten away without providing static copies.)
+
+     A function may be given the attribute 'no_instrument_function', in
+     which case this instrumentation is not done.  This can be used, for
+     example, for the profiling functions listed above, high-priority
+     interrupt routines, and any functions from which the profiling
+     functions cannot safely be called (perhaps signal handlers, if the
+     profiling routines generate output or allocate memory).
+
+'-finstrument-functions-exclude-file-list=FILE,FILE,...'
+
+     Set the list of functions that are excluded from instrumentation
+     (see the description of '-finstrument-functions').  If the file
+     that contains a function definition matches with one of FILE, then
+     that function is not instrumented.  The match is done on
+     substrings: if the FILE parameter is a substring of the file name,
+     it is considered to be a match.
+
+     For example:
+
+          -finstrument-functions-exclude-file-list=/bits/stl,include/sys
+
+     excludes any inline function defined in files whose pathnames
+     contain '/bits/stl' or 'include/sys'.
+
+     If, for some reason, you want to include letter '','' in one of
+     SYM, write ''\,''.  For example,
+     '-finstrument-functions-exclude-file-list='\,\,tmp'' (note the
+     single quote surrounding the option).
+
+'-finstrument-functions-exclude-function-list=SYM,SYM,...'
+
+     This is similar to '-finstrument-functions-exclude-file-list', but
+     this option sets the list of function names to be excluded from
+     instrumentation.  The function name to be matched is its
+     user-visible name, such as 'vector<int> blah(const vector<int> &)',
+     not the internal mangled name (e.g., '_Z4blahRSt6vectorIiSaIiEE').
+     The match is done on substrings: if the SYM parameter is a
+     substring of the function name, it is considered to be a match.
+     For C99 and C++ extended identifiers, the function name must be
+     given in UTF-8, not using universal character names.
+
+'-fstack-check'
+     Generate code to verify that you do not go beyond the boundary of
+     the stack.  You should specify this flag if you are running in an
+     environment with multiple threads, but you only rarely need to
+     specify it in a single-threaded environment since stack overflow is
+     automatically detected on nearly all systems if there is only one
+     stack.
+
+     Note that this switch does not actually cause checking to be done;
+     the operating system or the language runtime must do that.  The
+     switch causes generation of code to ensure that they see the stack
+     being extended.
+
+     You can additionally specify a string parameter: 'no' means no
+     checking, 'generic' means force the use of old-style checking,
+     'specific' means use the best checking method and is equivalent to
+     bare '-fstack-check'.
+
+     Old-style checking is a generic mechanism that requires no specific
+     target support in the compiler but comes with the following
+     drawbacks:
+
+       1. Modified allocation strategy for large objects: they are
+          always allocated dynamically if their size exceeds a fixed
+          threshold.
+
+       2. Fixed limit on the size of the static frame of functions: when
+          it is topped by a particular function, stack checking is not
+          reliable and a warning is issued by the compiler.
+
+       3. Inefficiency: because of both the modified allocation strategy
+          and the generic implementation, code performance is hampered.
+
+     Note that old-style stack checking is also the fallback method for
+     'specific' if no target support has been added in the compiler.
+
+'-fstack-limit-register=REG'
+'-fstack-limit-symbol=SYM'
+'-fno-stack-limit'
+     Generate code to ensure that the stack does not grow beyond a
+     certain value, either the value of a register or the address of a
+     symbol.  If a larger stack is required, a signal is raised at run
+     time.  For most targets, the signal is raised before the stack
+     overruns the boundary, so it is possible to catch the signal
+     without taking special precautions.
+
+     For instance, if the stack starts at absolute address '0x80000000'
+     and grows downwards, you can use the flags
+     '-fstack-limit-symbol=__stack_limit' and
+     '-Wl,--defsym,__stack_limit=0x7ffe0000' to enforce a stack limit of
+     128KB.  Note that this may only work with the GNU linker.
+
+'-fsplit-stack'
+     Generate code to automatically split the stack before it overflows.
+     The resulting program has a discontiguous stack which can only
+     overflow if the program is unable to allocate any more memory.
+     This is most useful when running threaded programs, as it is no
+     longer necessary to calculate a good stack size to use for each
+     thread.  This is currently only implemented for the i386 and x86_64
+     back ends running GNU/Linux.
+
+     When code compiled with '-fsplit-stack' calls code compiled without
+     '-fsplit-stack', there may not be much stack space available for
+     the latter code to run.  If compiling all code, including library
+     code, with '-fsplit-stack' is not an option, then the linker can
+     fix up these calls so that the code compiled without
+     '-fsplit-stack' always has a large stack.  Support for this is
+     implemented in the gold linker in GNU binutils release 2.21 and
+     later.
+
+'-fleading-underscore'
+     This option and its counterpart, '-fno-leading-underscore',
+     forcibly change the way C symbols are represented in the object
+     file.  One use is to help link with legacy assembly code.
+
+     *Warning:* the '-fleading-underscore' switch causes GCC to generate
+     code that is not binary compatible with code generated without that
+     switch.  Use it to conform to a non-default application binary
+     interface.  Not all targets provide complete support for this
+     switch.
+
+'-ftls-model=MODEL'
+     Alter the thread-local storage model to be used (*note
+     Thread-Local::).  The MODEL argument should be one of
+     'global-dynamic', 'local-dynamic', 'initial-exec' or 'local-exec'.
+     Note that the choice is subject to optimization: the compiler may
+     use a more efficient model for symbols not visible outside of the
+     translation unit, or if '-fpic' is not given on the command line.
+
+     The default without '-fpic' is 'initial-exec'; with '-fpic' the
+     default is 'global-dynamic'.
+
+'-fvisibility=DEFAULT|INTERNAL|HIDDEN|PROTECTED'
+     Set the default ELF image symbol visibility to the specified
+     option--all symbols are marked with this unless overridden within
+     the code.  Using this feature can very substantially improve
+     linking and load times of shared object libraries, produce more
+     optimized code, provide near-perfect API export and prevent symbol
+     clashes.  It is *strongly* recommended that you use this in any
+     shared objects you distribute.
+
+     Despite the nomenclature, 'default' always means public; i.e.,
+     available to be linked against from outside the shared object.
+     'protected' and 'internal' are pretty useless in real-world usage
+     so the only other commonly used option is 'hidden'.  The default if
+     '-fvisibility' isn't specified is 'default', i.e., make every
+     symbol public--this causes the same behavior as previous versions
+     of GCC.
+
+     A good explanation of the benefits offered by ensuring ELF symbols
+     have the correct visibility is given by "How To Write Shared
+     Libraries" by Ulrich Drepper (which can be found at
+     <http://people.redhat.com/~drepper/>)--however a superior solution
+     made possible by this option to marking things hidden when the
+     default is public is to make the default hidden and mark things
+     public.  This is the norm with DLLs on Windows and with
+     '-fvisibility=hidden' and '__attribute__ ((visibility("default")))'
+     instead of '__declspec(dllexport)' you get almost identical
+     semantics with identical syntax.  This is a great boon to those
+     working with cross-platform projects.
+
+     For those adding visibility support to existing code, you may find
+     '#pragma GCC visibility' of use.  This works by you enclosing the
+     declarations you wish to set visibility for with (for example)
+     '#pragma GCC visibility push(hidden)' and '#pragma GCC visibility
+     pop'.  Bear in mind that symbol visibility should be viewed *as
+     part of the API interface contract* and thus all new code should
+     always specify visibility when it is not the default; i.e.,
+     declarations only for use within the local DSO should *always* be
+     marked explicitly as hidden as so to avoid PLT indirection
+     overheads--making this abundantly clear also aids readability and
+     self-documentation of the code.  Note that due to ISO C++
+     specification requirements, 'operator new' and 'operator delete'
+     must always be of default visibility.
+
+     Be aware that headers from outside your project, in particular
+     system headers and headers from any other library you use, may not
+     be expecting to be compiled with visibility other than the default.
+     You may need to explicitly say '#pragma GCC visibility
+     push(default)' before including any such headers.
+
+     'extern' declarations are not affected by '-fvisibility', so a lot
+     of code can be recompiled with '-fvisibility=hidden' with no
+     modifications.  However, this means that calls to 'extern'
+     functions with no explicit visibility use the PLT, so it is more
+     effective to use '__attribute ((visibility))' and/or '#pragma GCC
+     visibility' to tell the compiler which 'extern' declarations should
+     be treated as hidden.
+
+     Note that '-fvisibility' does affect C++ vague linkage entities.
+     This means that, for instance, an exception class that is be thrown
+     between DSOs must be explicitly marked with default visibility so
+     that the 'type_info' nodes are unified between the DSOs.
+
+     An overview of these techniques, their benefits and how to use them
+     is at <http://gcc.gnu.org/wiki/Visibility>.
+
+'-fstrict-volatile-bitfields'
+     This option should be used if accesses to volatile bit-fields (or
+     other structure fields, although the compiler usually honors those
+     types anyway) should use a single access of the width of the
+     field's type, aligned to a natural alignment if possible.  For
+     example, targets with memory-mapped peripheral registers might
+     require all such accesses to be 16 bits wide; with this flag you
+     can declare all peripheral bit-fields as 'unsigned short' (assuming
+     short is 16 bits on these targets) to force GCC to use 16-bit
+     accesses instead of, perhaps, a more efficient 32-bit access.
+
+     If this option is disabled, the compiler uses the most efficient
+     instruction.  In the previous example, that might be a 32-bit load
+     instruction, even though that accesses bytes that do not contain
+     any portion of the bit-field, or memory-mapped registers unrelated
+     to the one being updated.
+
+     In some cases, such as when the 'packed' attribute is applied to a
+     structure field, it may not be possible to access the field with a
+     single read or write that is correctly aligned for the target
+     machine.  In this case GCC falls back to generating multiple
+     accesses rather than code that will fault or truncate the result at
+     run time.
+
+     Note: Due to restrictions of the C/C++11 memory model, write
+     accesses are not allowed to touch non bit-field members.  It is
+     therefore recommended to define all bits of the field's type as
+     bit-field members.
+
+     The default value of this option is determined by the application
+     binary interface for the target processor.
+
+'-fsync-libcalls'
+     This option controls whether any out-of-line instance of the
+     '__sync' family of functions may be used to implement the C++11
+     '__atomic' family of functions.
+
+     The default value of this option is enabled, thus the only useful
+     form of the option is '-fno-sync-libcalls'.  This option is used in
+     the implementation of the 'libatomic' runtime library.
+
+
+File: gcc.info,  Node: Environment Variables,  Next: Precompiled Headers,  Prev: Code Gen Options,  Up: Invoking GCC
+
+3.19 Environment Variables Affecting GCC
+========================================
+
+This section describes several environment variables that affect how GCC
+operates.  Some of them work by specifying directories or prefixes to
+use when searching for various kinds of files.  Some are used to specify
+other aspects of the compilation environment.
+
+ Note that you can also specify places to search using options such as
+'-B', '-I' and '-L' (*note Directory Options::).  These take precedence
+over places specified using environment variables, which in turn take
+precedence over those specified by the configuration of GCC.  *Note
+Controlling the Compilation Driver 'gcc': (gccint)Driver.
+
+'LANG'
+'LC_CTYPE'
+'LC_MESSAGES'
+'LC_ALL'
+     These environment variables control the way that GCC uses
+     localization information which allows GCC to work with different
+     national conventions.  GCC inspects the locale categories
+     'LC_CTYPE' and 'LC_MESSAGES' if it has been configured to do so.
+     These locale categories can be set to any value supported by your
+     installation.  A typical value is 'en_GB.UTF-8' for English in the
+     United Kingdom encoded in UTF-8.
+
+     The 'LC_CTYPE' environment variable specifies character
+     classification.  GCC uses it to determine the character boundaries
+     in a string; this is needed for some multibyte encodings that
+     contain quote and escape characters that are otherwise interpreted
+     as a string end or escape.
+
+     The 'LC_MESSAGES' environment variable specifies the language to
+     use in diagnostic messages.
+
+     If the 'LC_ALL' environment variable is set, it overrides the value
+     of 'LC_CTYPE' and 'LC_MESSAGES'; otherwise, 'LC_CTYPE' and
+     'LC_MESSAGES' default to the value of the 'LANG' environment
+     variable.  If none of these variables are set, GCC defaults to
+     traditional C English behavior.
+
+'TMPDIR'
+     If 'TMPDIR' is set, it specifies the directory to use for temporary
+     files.  GCC uses temporary files to hold the output of one stage of
+     compilation which is to be used as input to the next stage: for
+     example, the output of the preprocessor, which is the input to the
+     compiler proper.
+
+'GCC_COMPARE_DEBUG'
+     Setting 'GCC_COMPARE_DEBUG' is nearly equivalent to passing
+     '-fcompare-debug' to the compiler driver.  See the documentation of
+     this option for more details.
+
+'GCC_EXEC_PREFIX'
+     If 'GCC_EXEC_PREFIX' is set, it specifies a prefix to use in the
+     names of the subprograms executed by the compiler.  No slash is
+     added when this prefix is combined with the name of a subprogram,
+     but you can specify a prefix that ends with a slash if you wish.
+
+     If 'GCC_EXEC_PREFIX' is not set, GCC attempts to figure out an
+     appropriate prefix to use based on the pathname it is invoked with.
+
+     If GCC cannot find the subprogram using the specified prefix, it
+     tries looking in the usual places for the subprogram.
+
+     The default value of 'GCC_EXEC_PREFIX' is 'PREFIX/lib/gcc/' where
+     PREFIX is the prefix to the installed compiler.  In many cases
+     PREFIX is the value of 'prefix' when you ran the 'configure'
+     script.
+
+     Other prefixes specified with '-B' take precedence over this
+     prefix.
+
+     This prefix is also used for finding files such as 'crt0.o' that
+     are used for linking.
+
+     In addition, the prefix is used in an unusual way in finding the
+     directories to search for header files.  For each of the standard
+     directories whose name normally begins with '/usr/local/lib/gcc'
+     (more precisely, with the value of 'GCC_INCLUDE_DIR'), GCC tries
+     replacing that beginning with the specified prefix to produce an
+     alternate directory name.  Thus, with '-Bfoo/', GCC searches
+     'foo/bar' just before it searches the standard directory
+     '/usr/local/lib/bar'.  If a standard directory begins with the
+     configured PREFIX then the value of PREFIX is replaced by
+     'GCC_EXEC_PREFIX' when looking for header files.
+
+'COMPILER_PATH'
+     The value of 'COMPILER_PATH' is a colon-separated list of
+     directories, much like 'PATH'.  GCC tries the directories thus
+     specified when searching for subprograms, if it can't find the
+     subprograms using 'GCC_EXEC_PREFIX'.
+
+'LIBRARY_PATH'
+     The value of 'LIBRARY_PATH' is a colon-separated list of
+     directories, much like 'PATH'.  When configured as a native
+     compiler, GCC tries the directories thus specified when searching
+     for special linker files, if it can't find them using
+     'GCC_EXEC_PREFIX'.  Linking using GCC also uses these directories
+     when searching for ordinary libraries for the '-l' option (but
+     directories specified with '-L' come first).
+
+'LANG'
+     This variable is used to pass locale information to the compiler.
+     One way in which this information is used is to determine the
+     character set to be used when character literals, string literals
+     and comments are parsed in C and C++.  When the compiler is
+     configured to allow multibyte characters, the following values for
+     'LANG' are recognized:
+
+     'C-JIS'
+          Recognize JIS characters.
+     'C-SJIS'
+          Recognize SJIS characters.
+     'C-EUCJP'
+          Recognize EUCJP characters.
+
+     If 'LANG' is not defined, or if it has some other value, then the
+     compiler uses 'mblen' and 'mbtowc' as defined by the default locale
+     to recognize and translate multibyte characters.
+
+Some additional environment variables affect the behavior of the
+preprocessor.
+
+'CPATH'
+'C_INCLUDE_PATH'
+'CPLUS_INCLUDE_PATH'
+'OBJC_INCLUDE_PATH'
+     Each variable's value is a list of directories separated by a
+     special character, much like 'PATH', in which to look for header
+     files.  The special character, 'PATH_SEPARATOR', is
+     target-dependent and determined at GCC build time.  For Microsoft
+     Windows-based targets it is a semicolon, and for almost all other
+     targets it is a colon.
+
+     'CPATH' specifies a list of directories to be searched as if
+     specified with '-I', but after any paths given with '-I' options on
+     the command line.  This environment variable is used regardless of
+     which language is being preprocessed.
+
+     The remaining environment variables apply only when preprocessing
+     the particular language indicated.  Each specifies a list of
+     directories to be searched as if specified with '-isystem', but
+     after any paths given with '-isystem' options on the command line.
+
+     In all these variables, an empty element instructs the compiler to
+     search its current working directory.  Empty elements can appear at
+     the beginning or end of a path.  For instance, if the value of
+     'CPATH' is ':/special/include', that has the same effect as
+     '-I. -I/special/include'.
+
+'DEPENDENCIES_OUTPUT'
+     If this variable is set, its value specifies how to output
+     dependencies for Make based on the non-system header files
+     processed by the compiler.  System header files are ignored in the
+     dependency output.
+
+     The value of 'DEPENDENCIES_OUTPUT' can be just a file name, in
+     which case the Make rules are written to that file, guessing the
+     target name from the source file name.  Or the value can have the
+     form 'FILE TARGET', in which case the rules are written to file
+     FILE using TARGET as the target name.
+
+     In other words, this environment variable is equivalent to
+     combining the options '-MM' and '-MF' (*note Preprocessor
+     Options::), with an optional '-MT' switch too.
+
+'SUNPRO_DEPENDENCIES'
+     This variable is the same as 'DEPENDENCIES_OUTPUT' (see above),
+     except that system header files are not ignored, so it implies '-M'
+     rather than '-MM'.  However, the dependence on the main input file
+     is omitted.  *Note Preprocessor Options::.
+
+
+File: gcc.info,  Node: Precompiled Headers,  Prev: Environment Variables,  Up: Invoking GCC
+
+3.20 Using Precompiled Headers
+==============================
+
+Often large projects have many header files that are included in every
+source file.  The time the compiler takes to process these header files
+over and over again can account for nearly all of the time required to
+build the project.  To make builds faster, GCC allows you to
+"precompile" a header file.
+
+ To create a precompiled header file, simply compile it as you would any
+other file, if necessary using the '-x' option to make the driver treat
+it as a C or C++ header file.  You may want to use a tool like 'make' to
+keep the precompiled header up-to-date when the headers it contains
+change.
+
+ A precompiled header file is searched for when '#include' is seen in
+the compilation.  As it searches for the included file (*note Search
+Path: (cpp)Search Path.) the compiler looks for a precompiled header in
+each directory just before it looks for the include file in that
+directory.  The name searched for is the name specified in the
+'#include' with '.gch' appended.  If the precompiled header file can't
+be used, it is ignored.
+
+ For instance, if you have '#include "all.h"', and you have 'all.h.gch'
+in the same directory as 'all.h', then the precompiled header file is
+used if possible, and the original header is used otherwise.
+
+ Alternatively, you might decide to put the precompiled header file in a
+directory and use '-I' to ensure that directory is searched before (or
+instead of) the directory containing the original header.  Then, if you
+want to check that the precompiled header file is always used, you can
+put a file of the same name as the original header in this directory
+containing an '#error' command.
+
+ This also works with '-include'.  So yet another way to use precompiled
+headers, good for projects not designed with precompiled header files in
+mind, is to simply take most of the header files used by a project,
+include them from another header file, precompile that header file, and
+'-include' the precompiled header.  If the header files have guards
+against multiple inclusion, they are skipped because they've already
+been included (in the precompiled header).
+
+ If you need to precompile the same header file for different languages,
+targets, or compiler options, you can instead make a _directory_ named
+like 'all.h.gch', and put each precompiled header in the directory,
+perhaps using '-o'.  It doesn't matter what you call the files in the
+directory; every precompiled header in the directory is considered.  The
+first precompiled header encountered in the directory that is valid for
+this compilation is used; they're searched in no particular order.
+
+ There are many other possibilities, limited only by your imagination,
+good sense, and the constraints of your build system.
+
+ A precompiled header file can be used only when these conditions apply:
+
+   * Only one precompiled header can be used in a particular
+     compilation.
+
+   * A precompiled header can't be used once the first C token is seen.
+     You can have preprocessor directives before a precompiled header;
+     you cannot include a precompiled header from inside another header.
+
+   * The precompiled header file must be produced for the same language
+     as the current compilation.  You can't use a C precompiled header
+     for a C++ compilation.
+
+   * The precompiled header file must have been produced by the same
+     compiler binary as the current compilation is using.
+
+   * Any macros defined before the precompiled header is included must
+     either be defined in the same way as when the precompiled header
+     was generated, or must not affect the precompiled header, which
+     usually means that they don't appear in the precompiled header at
+     all.
+
+     The '-D' option is one way to define a macro before a precompiled
+     header is included; using a '#define' can also do it.  There are
+     also some options that define macros implicitly, like '-O' and
+     '-Wdeprecated'; the same rule applies to macros defined this way.
+
+   * If debugging information is output when using the precompiled
+     header, using '-g' or similar, the same kind of debugging
+     information must have been output when building the precompiled
+     header.  However, a precompiled header built using '-g' can be used
+     in a compilation when no debugging information is being output.
+
+   * The same '-m' options must generally be used when building and
+     using the precompiled header.  *Note Submodel Options::, for any
+     cases where this rule is relaxed.
+
+   * Each of the following options must be the same when building and
+     using the precompiled header:
+
+          -fexceptions
+
+   * Some other command-line options starting with '-f', '-p', or '-O'
+     must be defined in the same way as when the precompiled header was
+     generated.  At present, it's not clear which options are safe to
+     change and which are not; the safest choice is to use exactly the
+     same options when generating and using the precompiled header.  The
+     following are known to be safe:
+
+          -fmessage-length=  -fpreprocessed  -fsched-interblock
+          -fsched-spec  -fsched-spec-load  -fsched-spec-load-dangerous
+          -fsched-verbose=NUMBER  -fschedule-insns  -fvisibility=
+          -pedantic-errors
+
+ For all of these except the last, the compiler automatically ignores
+the precompiled header if the conditions aren't met.  If you find an
+option combination that doesn't work and doesn't cause the precompiled
+header to be ignored, please consider filing a bug report, see *note
+Bugs::.
+
+ If you do use differing options when generating and using the
+precompiled header, the actual behavior is a mixture of the behavior for
+the options.  For instance, if you use '-g' to generate the precompiled
+header but not when using it, you may or may not get debugging
+information for routines in the precompiled header.
+
+
+File: gcc.info,  Node: C Implementation,  Next: C++ Implementation,  Prev: Invoking GCC,  Up: Top
+
+4 C Implementation-defined behavior
+***********************************
+
+A conforming implementation of ISO C is required to document its choice
+of behavior in each of the areas that are designated "implementation
+defined".  The following lists all such areas, along with the section
+numbers from the ISO/IEC 9899:1990, ISO/IEC 9899:1999 and ISO/IEC
+9899:2011 standards.  Some areas are only implementation-defined in one
+version of the standard.
+
+ Some choices depend on the externally determined ABI for the platform
+(including standard character encodings) which GCC follows; these are
+listed as "determined by ABI" below.  *Note Binary Compatibility:
+Compatibility, and <http://gcc.gnu.org/readings.html>.  Some choices are
+documented in the preprocessor manual.  *Note Implementation-defined
+behavior: (cpp)Implementation-defined behavior.  Some choices are made
+by the library and operating system (or other environment when compiling
+for a freestanding environment); refer to their documentation for
+details.
+
+* Menu:
+
+* Translation implementation::
+* Environment implementation::
+* Identifiers implementation::
+* Characters implementation::
+* Integers implementation::
+* Floating point implementation::
+* Arrays and pointers implementation::
+* Hints implementation::
+* Structures unions enumerations and bit-fields implementation::
+* Qualifiers implementation::
+* Declarators implementation::
+* Statements implementation::
+* Preprocessing directives implementation::
+* Library functions implementation::
+* Architecture implementation::
+* Locale-specific behavior implementation::
+
+
+File: gcc.info,  Node: Translation implementation,  Next: Environment implementation,  Up: C Implementation
+
+4.1 Translation
+===============
+
+   * 'How a diagnostic is identified (C90 3.7, C99 and C11 3.10, C90,
+     C99 and C11 5.1.1.3).'
+
+     Diagnostics consist of all the output sent to stderr by GCC.
+
+   * 'Whether each nonempty sequence of white-space characters other
+     than new-line is retained or replaced by one space character in
+     translation phase 3 (C90, C99 and C11 5.1.1.2).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.
+
+
+File: gcc.info,  Node: Environment implementation,  Next: Identifiers implementation,  Prev: Translation implementation,  Up: C Implementation
+
+4.2 Environment
+===============
+
+The behavior of most of these points are dependent on the implementation
+of the C library, and are not defined by GCC itself.
+
+   * 'The mapping between physical source file multibyte characters and
+     the source character set in translation phase 1 (C90, C99 and C11
+     5.1.1.2).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.
+
+
+File: gcc.info,  Node: Identifiers implementation,  Next: Characters implementation,  Prev: Environment implementation,  Up: C Implementation
+
+4.3 Identifiers
+===============
+
+   * 'Which additional multibyte characters may appear in identifiers
+     and their correspondence to universal character names (C99 and C11
+     6.4.2).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.
+
+   * 'The number of significant initial characters in an identifier (C90
+     6.1.2, C90, C99 and C11 5.2.4.1, C99 and C11 6.4.2).'
+
+     For internal names, all characters are significant.  For external
+     names, the number of significant characters are defined by the
+     linker; for almost all targets, all characters are significant.
+
+   * 'Whether case distinctions are significant in an identifier with
+     external linkage (C90 6.1.2).'
+
+     This is a property of the linker.  C99 and C11 require that case
+     distinctions are always significant in identifiers with external
+     linkage and systems without this property are not supported by GCC.
+
+
+File: gcc.info,  Node: Characters implementation,  Next: Integers implementation,  Prev: Identifiers implementation,  Up: C Implementation
+
+4.4 Characters
+==============
+
+   * 'The number of bits in a byte (C90 3.4, C99 and C11 3.6).'
+
+     Determined by ABI.
+
+   * 'The values of the members of the execution character set (C90, C99
+     and C11 5.2.1).'
+
+     Determined by ABI.
+
+   * 'The unique value of the member of the execution character set
+     produced for each of the standard alphabetic escape sequences (C90,
+     C99 and C11 5.2.2).'
+
+     Determined by ABI.
+
+   * 'The value of a 'char' object into which has been stored any
+     character other than a member of the basic execution character set
+     (C90 6.1.2.5, C99 and C11 6.2.5).'
+
+     Determined by ABI.
+
+   * 'Which of 'signed char' or 'unsigned char' has the same range,
+     representation, and behavior as "plain" 'char' (C90 6.1.2.5, C90
+     6.2.1.1, C99 and C11 6.2.5, C99 and C11 6.3.1.1).'
+
+     Determined by ABI.  The options '-funsigned-char' and
+     '-fsigned-char' change the default.  *Note Options Controlling C
+     Dialect: C Dialect Options.
+
+   * 'The mapping of members of the source character set (in character
+     constants and string literals) to members of the execution
+     character set (C90 6.1.3.4, C99 and C11 6.4.4.4, C90, C99 and C11
+     5.1.1.2).'
+
+     Determined by ABI.
+
+   * 'The value of an integer character constant containing more than
+     one character or containing a character or escape sequence that
+     does not map to a single-byte execution character (C90 6.1.3.4, C99
+     and C11 6.4.4.4).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.
+
+   * 'The value of a wide character constant containing more than one
+     multibyte character or a single multibyte character that maps to
+     multiple members of the extended execution character set, or
+     containing a multibyte character or escape sequence not represented
+     in the extended execution character set (C90 6.1.3.4, C99 and C11
+     6.4.4.4).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.
+
+   * 'The current locale used to convert a wide character constant
+     consisting of a single multibyte character that maps to a member of
+     the extended execution character set into a corresponding wide
+     character code (C90 6.1.3.4, C99 and C11 6.4.4.4).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.
+
+   * 'Whether differently-prefixed wide string literal tokens can be
+     concatenated and, if so, the treatment of the resulting multibyte
+     character sequence (C11 6.4.5).'
+
+     Such tokens may not be concatenated.
+
+   * 'The current locale used to convert a wide string literal into
+     corresponding wide character codes (C90 6.1.4, C99 and C11 6.4.5).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.
+
+   * 'The value of a string literal containing a multibyte character or
+     escape sequence not represented in the execution character set (C90
+     6.1.4, C99 and C11 6.4.5).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.
+
+   * 'The encoding of any of 'wchar_t', 'char16_t', and 'char32_t' where
+     the corresponding standard encoding macro ('__STDC_ISO_10646__',
+     '__STDC_UTF_16__', or '__STDC_UTF_32__') is not defined (C11
+     6.10.8.2).'
+
+     *Note Implementation-defined behavior: (cpp)Implementation-defined
+     behavior.  'char16_t' and 'char32_t' literals are always encoded in
+     UTF-16 and UTF-32 respectively.
+
+
+File: gcc.info,  Node: Integers implementation,  Next: Floating point implementation,  Prev: Characters implementation,  Up: C Implementation
+
+4.5 Integers
+============
+
+   * 'Any extended integer types that exist in the implementation (C99
+     and C11 6.2.5).'
+
+     GCC does not support any extended integer types.
+
+   * 'Whether signed integer types are represented using sign and
+     magnitude, two's complement, or one's complement, and whether the
+     extraordinary value is a trap representation or an ordinary value
+     (C99 and C11 6.2.6.2).'
+
+     GCC supports only two's complement integer types, and all bit
+     patterns are ordinary values.
+
+   * 'The rank of any extended integer type relative to another extended
+     integer type with the same precision (C99 and C11 6.3.1.1).'
+
+     GCC does not support any extended integer types.
+
+   * 'The result of, or the signal raised by, converting an integer to a
+     signed integer type when the value cannot be represented in an
+     object of that type (C90 6.2.1.2, C99 and C11 6.3.1.3).'
+
+     For conversion to a type of width N, the value is reduced modulo
+     2^N to be within range of the type; no signal is raised.
+
+   * 'The results of some bitwise operations on signed integers (C90
+     6.3, C99 and C11 6.5).'
+
+     Bitwise operators act on the representation of the value including
+     both the sign and value bits, where the sign bit is considered
+     immediately above the highest-value value bit.  Signed '>>' acts on
+     negative numbers by sign extension.
+
+     GCC does not use the latitude given in C99 and C11 only to treat
+     certain aspects of signed '<<' as undefined, but this is subject to
+     change.
+
+   * 'The sign of the remainder on integer division (C90 6.3.5).'
+
+     GCC always follows the C99 and C11 requirement that the result of
+     division is truncated towards zero.
+
+
+File: gcc.info,  Node: Floating point implementation,  Next: Arrays and pointers implementation,  Prev: Integers implementation,  Up: C Implementation
+
+4.6 Floating point
+==================
+
+   * 'The accuracy of the floating-point operations and of the library
+     functions in '<math.h>' and '<complex.h>' that return
+     floating-point results (C90, C99 and C11 5.2.4.2.2).'
+
+     The accuracy is unknown.
+
+   * 'The rounding behaviors characterized by non-standard values of
+     'FLT_ROUNDS' (C90, C99 and C11 5.2.4.2.2).'
+
+     GCC does not use such values.
+
+   * 'The evaluation methods characterized by non-standard negative
+     values of 'FLT_EVAL_METHOD' (C99 and C11 5.2.4.2.2).'
+
+     GCC does not use such values.
+
+   * 'The direction of rounding when an integer is converted to a
+     floating-point number that cannot exactly represent the original
+     value (C90 6.2.1.3, C99 and C11 6.3.1.4).'
+
+     C99 Annex F is followed.
+
+   * 'The direction of rounding when a floating-point number is
+     converted to a narrower floating-point number (C90 6.2.1.4, C99 and
+     C11 6.3.1.5).'
+
+     C99 Annex F is followed.
+
+   * 'How the nearest representable value or the larger or smaller
+     representable value immediately adjacent to the nearest
+     representable value is chosen for certain floating constants (C90
+     6.1.3.1, C99 and C11 6.4.4.2).'
+
+     C99 Annex F is followed.
+
+   * 'Whether and how floating expressions are contracted when not
+     disallowed by the 'FP_CONTRACT' pragma (C99 and C11 6.5).'
+
+     Expressions are currently only contracted if '-ffp-contract=fast',
+     '-funsafe-math-optimizations' or '-ffast-math' are used.  This is
+     subject to change.
+
+   * 'The default state for the 'FENV_ACCESS' pragma (C99 and C11
+     7.6.1).'
+
+     This pragma is not implemented, but the default is to "off" unless
+     '-frounding-math' is used in which case it is "on".
+
+   * 'Additional floating-point exceptions, rounding modes,
+     environments, and classifications, and their macro names (C99 and
+     C11 7.6, C99 and C11 7.12).'
+
+     This is dependent on the implementation of the C library, and is
+     not defined by GCC itself.
+
+   * 'The default state for the 'FP_CONTRACT' pragma (C99 and C11
+     7.12.2).'
+
+     This pragma is not implemented.  Expressions are currently only
+     contracted if '-ffp-contract=fast', '-funsafe-math-optimizations'
+     or '-ffast-math' are used.  This is subject to change.
+
+   * 'Whether the "inexact" floating-point exception can be raised when
+     the rounded result actually does equal the mathematical result in
+     an IEC 60559 conformant implementation (C99 F.9).'
+
+     This is dependent on the implementation of the C library, and is
+     not defined by GCC itself.
+
+   * 'Whether the "underflow" (and "inexact") floating-point exception
+     can be raised when a result is tiny but not inexact in an IEC 60559
+     conformant implementation (C99 F.9).'
+
+     This is dependent on the implementation of the C library, and is
+     not defined by GCC itself.
+
+
+File: gcc.info,  Node: Arrays and pointers implementation,  Next: Hints implementation,  Prev: Floating point implementation,  Up: C Implementation
+
+4.7 Arrays and pointers
+=======================
+
+   * 'The result of converting a pointer to an integer or vice versa
+     (C90 6.3.4, C99 and C11 6.3.2.3).'
+
+     A cast from pointer to integer discards most-significant bits if
+     the pointer representation is larger than the integer type,
+     sign-extends(1) if the pointer representation is smaller than the
+     integer type, otherwise the bits are unchanged.
+
+     A cast from integer to pointer discards most-significant bits if
+     the pointer representation is smaller than the integer type,
+     extends according to the signedness of the integer type if the
+     pointer representation is larger than the integer type, otherwise
+     the bits are unchanged.
+
+     When casting from pointer to integer and back again, the resulting
+     pointer must reference the same object as the original pointer,
+     otherwise the behavior is undefined.  That is, one may not use
+     integer arithmetic to avoid the undefined behavior of pointer
+     arithmetic as proscribed in C99 and C11 6.5.6/8.
+
+   * 'The size of the result of subtracting two pointers to elements of
+     the same array (C90 6.3.6, C99 and C11 6.5.6).'
+
+     The value is as specified in the standard and the type is
+     determined by the ABI.
+
+   ---------- Footnotes ----------
+
+   (1) Future versions of GCC may zero-extend, or use a target-defined
+'ptr_extend' pattern.  Do not rely on sign extension.
+
+
+File: gcc.info,  Node: Hints implementation,  Next: Structures unions enumerations and bit-fields implementation,  Prev: Arrays and pointers implementation,  Up: C Implementation
+
+4.8 Hints
+=========
+
+   * 'The extent to which suggestions made by using the 'register'
+     storage-class specifier are effective (C90 6.5.1, C99 and C11
+     6.7.1).'
+
+     The 'register' specifier affects code generation only in these
+     ways:
+
+        * When used as part of the register variable extension, see
+          *note Explicit Reg Vars::.
+
+        * When '-O0' is in use, the compiler allocates distinct stack
+          memory for all variables that do not have the 'register'
+          storage-class specifier; if 'register' is specified, the
+          variable may have a shorter lifespan than the code would
+          indicate and may never be placed in memory.
+
+        * On some rare x86 targets, 'setjmp' doesn't save the registers
+          in all circumstances.  In those cases, GCC doesn't allocate
+          any variables in registers unless they are marked 'register'.
+
+   * 'The extent to which suggestions made by using the inline function
+     specifier are effective (C99 and C11 6.7.4).'
+
+     GCC will not inline any functions if the '-fno-inline' option is
+     used or if '-O0' is used.  Otherwise, GCC may still be unable to
+     inline a function for many reasons; the '-Winline' option may be
+     used to determine if a function has not been inlined and why not.
+
+
+File: gcc.info,  Node: Structures unions enumerations and bit-fields implementation,  Next: Qualifiers implementation,  Prev: Hints implementation,  Up: C Implementation
+
+4.9 Structures, unions, enumerations, and bit-fields
+====================================================
+
+   * 'A member of a union object is accessed using a member of a
+     different type (C90 6.3.2.3).'
+
+     The relevant bytes of the representation of the object are treated
+     as an object of the type used for the access.  *Note
+     Type-punning::.  This may be a trap representation.
+
+   * 'Whether a "plain" 'int' bit-field is treated as a 'signed int'
+     bit-field or as an 'unsigned int' bit-field (C90 6.5.2, C90
+     6.5.2.1, C99 and C11 6.7.2, C99 and C11 6.7.2.1).'
+
+     By default it is treated as 'signed int' but this may be changed by
+     the '-funsigned-bitfields' option.
+
+   * 'Allowable bit-field types other than '_Bool', 'signed int', and
+     'unsigned int' (C99 and C11 6.7.2.1).'
+
+     Other integer types, such as 'long int', and enumerated types are
+     permitted even in strictly conforming mode.
+
+   * 'Whether atomic types are permitted for bit-fields (C11 6.7.2.1).'
+
+     Atomic types are not permitted for bit-fields.
+
+   * 'Whether a bit-field can straddle a storage-unit boundary (C90
+     6.5.2.1, C99 and C11 6.7.2.1).'
+
+     Determined by ABI.
+
+   * 'The order of allocation of bit-fields within a unit (C90 6.5.2.1,
+     C99 and C11 6.7.2.1).'
+
+     Determined by ABI.
+
+   * 'The alignment of non-bit-field members of structures (C90 6.5.2.1,
+     C99 and C11 6.7.2.1).'
+
+     Determined by ABI.
+
+   * 'The integer type compatible with each enumerated type (C90
+     6.5.2.2, C99 and C11 6.7.2.2).'
+
+     Normally, the type is 'unsigned int' if there are no negative
+     values in the enumeration, otherwise 'int'.  If '-fshort-enums' is
+     specified, then if there are negative values it is the first of
+     'signed char', 'short' and 'int' that can represent all the values,
+     otherwise it is the first of 'unsigned char', 'unsigned short' and
+     'unsigned int' that can represent all the values.
+
+     On some targets, '-fshort-enums' is the default; this is determined
+     by the ABI.
+
+
+File: gcc.info,  Node: Qualifiers implementation,  Next: Declarators implementation,  Prev: Structures unions enumerations and bit-fields implementation,  Up: C Implementation
+
+4.10 Qualifiers
+===============
+
+   * 'What constitutes an access to an object that has
+     volatile-qualified type (C90 6.5.3, C99 and C11 6.7.3).'
+
+     Such an object is normally accessed by pointers and used for
+     accessing hardware.  In most expressions, it is intuitively obvious
+     what is a read and what is a write.  For example
+
+          volatile int *dst = SOMEVALUE;
+          volatile int *src = SOMEOTHERVALUE;
+          *dst = *src;
+
+     will cause a read of the volatile object pointed to by SRC and
+     store the value into the volatile object pointed to by DST.  There
+     is no guarantee that these reads and writes are atomic, especially
+     for objects larger than 'int'.
+
+     However, if the volatile storage is not being modified, and the
+     value of the volatile storage is not used, then the situation is
+     less obvious.  For example
+
+          volatile int *src = SOMEVALUE;
+          *src;
+
+     According to the C standard, such an expression is an rvalue whose
+     type is the unqualified version of its original type, i.e.  'int'.
+     Whether GCC interprets this as a read of the volatile object being
+     pointed to or only as a request to evaluate the expression for its
+     side-effects depends on this type.
+
+     If it is a scalar type, or on most targets an aggregate type whose
+     only member object is of a scalar type, or a union type whose
+     member objects are of scalar types, the expression is interpreted
+     by GCC as a read of the volatile object; in the other cases, the
+     expression is only evaluated for its side-effects.
+
+
+File: gcc.info,  Node: Declarators implementation,  Next: Statements implementation,  Prev: Qualifiers implementation,  Up: C Implementation
+
+4.11 Declarators
+================
+
+   * 'The maximum number of declarators that may modify an arithmetic,
+     structure or union type (C90 6.5.4).'
+
+     GCC is only limited by available memory.
+
+
+File: gcc.info,  Node: Statements implementation,  Next: Preprocessing directives implementation,  Prev: Declarators implementation,  Up: C Implementation
+
+4.12 Statements
+===============
+
+   * 'The maximum number of 'case' values in a 'switch' statement (C90
+     6.6.4.2).'
+
+     GCC is only limited by available memory.
+
+
+File: gcc.info,  Node: Preprocessing directives implementation,  Next: Library functions implementation,  Prev: Statements implementation,  Up: C Implementation
+
+4.13 Preprocessing directives
+=============================
+
+*Note Implementation-defined behavior: (cpp)Implementation-defined
+behavior, for details of these aspects of implementation-defined
+behavior.
+
+   * 'The locations within '#pragma' directives where header name
+     preprocessing tokens are recognized (C11 6.4, C11 6.4.7).'
+
+   * 'How sequences in both forms of header names are mapped to headers
+     or external source file names (C90 6.1.7, C99 and C11 6.4.7).'
+
+   * 'Whether the value of a character constant in a constant expression
+     that controls conditional inclusion matches the value of the same
+     character constant in the execution character set (C90 6.8.1, C99
+     and C11 6.10.1).'
+
+   * 'Whether the value of a single-character character constant in a
+     constant expression that controls conditional inclusion may have a
+     negative value (C90 6.8.1, C99 and C11 6.10.1).'
+
+   * 'The places that are searched for an included '<>' delimited
+     header, and how the places are specified or the header is
+     identified (C90 6.8.2, C99 and C11 6.10.2).'
+
+   * 'How the named source file is searched for in an included '""'
+     delimited header (C90 6.8.2, C99 and C11 6.10.2).'
+
+   * 'The method by which preprocessing tokens (possibly resulting from
+     macro expansion) in a '#include' directive are combined into a
+     header name (C90 6.8.2, C99 and C11 6.10.2).'
+
+   * 'The nesting limit for '#include' processing (C90 6.8.2, C99 and
+     C11 6.10.2).'
+
+   * 'Whether the '#' operator inserts a '\' character before the '\'
+     character that begins a universal character name in a character
+     constant or string literal (C99 and C11 6.10.3.2).'
+
+   * 'The behavior on each recognized non-'STDC #pragma' directive (C90
+     6.8.6, C99 and C11 6.10.6).'
+
+     *Note Pragmas: (cpp)Pragmas, for details of pragmas accepted by GCC
+     on all targets.  *Note Pragmas Accepted by GCC: Pragmas, for
+     details of target-specific pragmas.
+
+   * 'The definitions for '__DATE__' and '__TIME__' when respectively,
+     the date and time of translation are not available (C90 6.8.8, C99
+     6.10.8, C11 6.10.8.1).'
+
+
+File: gcc.info,  Node: Library functions implementation,  Next: Architecture implementation,  Prev: Preprocessing directives implementation,  Up: C Implementation
+
+4.14 Library functions
+======================
+
+The behavior of most of these points are dependent on the implementation
+of the C library, and are not defined by GCC itself.
+
+   * 'The null pointer constant to which the macro 'NULL' expands (C90
+     7.1.6, C99 7.17, C11 7.19).'
+
+     In '<stddef.h>', 'NULL' expands to '((void *)0)'.  GCC does not
+     provide the other headers which define 'NULL' and some library
+     implementations may use other definitions in those headers.
+
+
+File: gcc.info,  Node: Architecture implementation,  Next: Locale-specific behavior implementation,  Prev: Library functions implementation,  Up: C Implementation
+
+4.15 Architecture
+=================
+
+   * 'The values or expressions assigned to the macros specified in the
+     headers '<float.h>', '<limits.h>', and '<stdint.h>' (C90, C99 and
+     C11 5.2.4.2, C99 7.18.2, C99 7.18.3, C11 7.20.2, C11 7.20.3).'
+
+     Determined by ABI.
+
+   * 'The result of attempting to indirectly access an object with
+     automatic or thread storage duration from a thread other than the
+     one with which it is associated (C11 6.2.4).'
+
+     Such accesses are supported, subject to the same requirements for
+     synchronization for concurrent accesses as for concurrent accesses
+     to any object.
+
+   * 'The number, order, and encoding of bytes in any object (when not
+     explicitly specified in this International Standard) (C99 and C11
+     6.2.6.1).'
+
+     Determined by ABI.
+
+   * 'Whether any extended alignments are supported and the contexts in
+     which they are supported (C11 6.2.8).'
+
+     Extended alignments up to 2^{28} (bytes) are supported for objects
+     of automatic storage duration.  Alignments supported for objects of
+     static and thread storage duration are determined by the ABI.
+
+   * 'Valid alignment values other than those returned by an _Alignof
+     expression for fundamental types, if any (C11 6.2.8).'
+
+     Valid alignments are powers of 2 up to and including 2^{28}.
+
+   * 'The value of the result of the 'sizeof' and '_Alignof' operators
+     (C90 6.3.3.4, C99 and C11 6.5.3.4).'
+
+     Determined by ABI.
+
+
+File: gcc.info,  Node: Locale-specific behavior implementation,  Prev: Architecture implementation,  Up: C Implementation
+
+4.16 Locale-specific behavior
+=============================
+
+The behavior of these points are dependent on the implementation of the
+C library, and are not defined by GCC itself.
+
+
+File: gcc.info,  Node: C++ Implementation,  Next: C Extensions,  Prev: C Implementation,  Up: Top
+
+5 C++ Implementation-defined behavior
+*************************************
+
+A conforming implementation of ISO C++ is required to document its
+choice of behavior in each of the areas that are designated
+"implementation defined".  The following lists all such areas, along
+with the section numbers from the ISO/IEC 14882:1998 and ISO/IEC
+14882:2003 standards.  Some areas are only implementation-defined in one
+version of the standard.
+
+ Some choices depend on the externally determined ABI for the platform
+(including standard character encodings) which GCC follows; these are
+listed as "determined by ABI" below.  *Note Binary Compatibility:
+Compatibility, and <http://gcc.gnu.org/readings.html>.  Some choices are
+documented in the preprocessor manual.  *Note Implementation-defined
+behavior: (cpp)Implementation-defined behavior.  Some choices are
+documented in the corresponding document for the C language.  *Note C
+Implementation::.  Some choices are made by the library and operating
+system (or other environment when compiling for a freestanding
+environment); refer to their documentation for details.
+
+* Menu:
+
+* Conditionally-supported behavior::
+* Exception handling::
+
+
+File: gcc.info,  Node: Conditionally-supported behavior,  Next: Exception handling,  Up: C++ Implementation
+
+5.1 Conditionally-supported behavior
+====================================
+
+'Each implementation shall include documentation that identifies all
+conditionally-supported constructs that it does not support (C++0x
+1.4).'
+
+   * 'Whether an argument of class type with a non-trivial copy
+     constructor or destructor can be passed to ... (C++0x 5.2.2).'
+
+     Such argument passing is not supported.
+
+
+File: gcc.info,  Node: Exception handling,  Prev: Conditionally-supported behavior,  Up: C++ Implementation
+
+5.2 Exception handling
+======================
+
+   * 'In the situation where no matching handler is found, it is
+     implementation-defined whether or not the stack is unwound before
+     std::terminate() is called (C++98 15.5.1).'
+
+     The stack is not unwound before std::terminate is called.
+
+
+File: gcc.info,  Node: C Extensions,  Next: C++ Extensions,  Prev: C++ Implementation,  Up: Top
+
+6 Extensions to the C Language Family
+*************************************
+
+GNU C provides several language features not found in ISO standard C.
+(The '-pedantic' option directs GCC to print a warning message if any of
+these features is used.)  To test for the availability of these features
+in conditional compilation, check for a predefined macro '__GNUC__',
+which is always defined under GCC.
+
+ These extensions are available in C and Objective-C.  Most of them are
+also available in C++.  *Note Extensions to the C++ Language: C++
+Extensions, for extensions that apply _only_ to C++.
+
+ Some features that are in ISO C99 but not C90 or C++ are also, as
+extensions, accepted by GCC in C90 mode and in C++.
+
+* Menu:
+
+* Statement Exprs::     Putting statements and declarations inside expressions.
+* Local Labels::        Labels local to a block.
+* Labels as Values::    Getting pointers to labels, and computed gotos.
+* Nested Functions::    As in Algol and Pascal, lexical scoping of functions.
+* Constructing Calls::  Dispatching a call to another function.
+* Typeof::              'typeof': referring to the type of an expression.
+* Conditionals::        Omitting the middle operand of a '?:' expression.
+* __int128::		128-bit integers--'__int128'.
+* Long Long::           Double-word integers--'long long int'.
+* Complex::             Data types for complex numbers.
+* Floating Types::      Additional Floating Types.
+* Half-Precision::      Half-Precision Floating Point.
+* Decimal Float::       Decimal Floating Types.
+* Hex Floats::          Hexadecimal floating-point constants.
+* Fixed-Point::         Fixed-Point Types.
+* Named Address Spaces::Named address spaces.
+* Zero Length::         Zero-length arrays.
+* Empty Structures::    Structures with no members.
+* Variable Length::     Arrays whose length is computed at run time.
+* Variadic Macros::     Macros with a variable number of arguments.
+* Escaped Newlines::    Slightly looser rules for escaped newlines.
+* Subscripting::        Any array can be subscripted, even if not an lvalue.
+* Pointer Arith::       Arithmetic on 'void'-pointers and function pointers.
+* Initializers::        Non-constant initializers.
+* Compound Literals::   Compound literals give structures, unions
+                        or arrays as values.
+* Designated Inits::    Labeling elements of initializers.
+* Case Ranges::         'case 1 ... 9' and such.
+* Cast to Union::       Casting to union type from any member of the union.
+* Mixed Declarations::  Mixing declarations and code.
+* Function Attributes:: Declaring that functions have no side effects,
+                        or that they can never return.
+* Attribute Syntax::    Formal syntax for attributes.
+* Function Prototypes:: Prototype declarations and old-style definitions.
+* C++ Comments::        C++ comments are recognized.
+* Dollar Signs::        Dollar sign is allowed in identifiers.
+* Character Escapes::   '\e' stands for the character <ESC>.
+* Variable Attributes:: Specifying attributes of variables.
+* Type Attributes::     Specifying attributes of types.
+* Alignment::           Inquiring about the alignment of a type or variable.
+* Inline::              Defining inline functions (as fast as macros).
+* Volatiles::           What constitutes an access to a volatile object.
+* Extended Asm::        Assembler instructions with C expressions as operands.
+                        (With them you can define "built-in" functions.)
+* Constraints::         Constraints for asm operands
+* Asm Labels::          Specifying the assembler name to use for a C symbol.
+* Explicit Reg Vars::   Defining variables residing in specified registers.
+* Alternate Keywords::  '__const__', '__asm__', etc., for header files.
+* Incomplete Enums::    'enum foo;', with details to follow.
+* Function Names::      Printable strings which are the name of the current
+                        function.
+* Return Address::      Getting the return or frame address of a function.
+* Vector Extensions::   Using vector instructions through built-in functions.
+* Offsetof::            Special syntax for implementing 'offsetof'.
+* __sync Builtins::     Legacy built-in functions for atomic memory access.
+* __atomic Builtins::   Atomic built-in functions with memory model.
+* x86 specific memory model extensions for transactional memory:: x86 memory models.
+* Object Size Checking:: Built-in functions for limited buffer overflow
+                        checking.
+* Cilk Plus Builtins::  Built-in functions for the Cilk Plus language extension.
+* Other Builtins::      Other built-in functions.
+* Target Builtins::     Built-in functions specific to particular targets.
+* Target Format Checks:: Format checks specific to particular targets.
+* Pragmas::             Pragmas accepted by GCC.
+* Unnamed Fields::      Unnamed struct/union fields within structs/unions.
+* Thread-Local::        Per-thread variables.
+* Binary constants::    Binary constants using the '0b' prefix.
+
+
+File: gcc.info,  Node: Statement Exprs,  Next: Local Labels,  Up: C Extensions
+
+6.1 Statements and Declarations in Expressions
+==============================================
+
+A compound statement enclosed in parentheses may appear as an expression
+in GNU C.  This allows you to use loops, switches, and local variables
+within an expression.
+
+ Recall that a compound statement is a sequence of statements surrounded
+by braces; in this construct, parentheses go around the braces.  For
+example:
+
+     ({ int y = foo (); int z;
+        if (y > 0) z = y;
+        else z = - y;
+        z; })
+
+is a valid (though slightly more complex than necessary) expression for
+the absolute value of 'foo ()'.
+
+ The last thing in the compound statement should be an expression
+followed by a semicolon; the value of this subexpression serves as the
+value of the entire construct.  (If you use some other kind of statement
+last within the braces, the construct has type 'void', and thus
+effectively no value.)
+
+ This feature is especially useful in making macro definitions "safe"
+(so that they evaluate each operand exactly once).  For example, the
+"maximum" function is commonly defined as a macro in standard C as
+follows:
+
+     #define max(a,b) ((a) > (b) ? (a) : (b))
+
+But this definition computes either A or B twice, with bad results if
+the operand has side effects.  In GNU C, if you know the type of the
+operands (here taken as 'int'), you can define the macro safely as
+follows:
+
+     #define maxint(a,b) \
+       ({int _a = (a), _b = (b); _a > _b ? _a : _b; })
+
+ Embedded statements are not allowed in constant expressions, such as
+the value of an enumeration constant, the width of a bit-field, or the
+initial value of a static variable.
+
+ If you don't know the type of the operand, you can still do this, but
+you must use 'typeof' or '__auto_type' (*note Typeof::).
+
+ In G++, the result value of a statement expression undergoes array and
+function pointer decay, and is returned by value to the enclosing
+expression.  For instance, if 'A' is a class, then
+
+             A a;
+
+             ({a;}).Foo ()
+
+constructs a temporary 'A' object to hold the result of the statement
+expression, and that is used to invoke 'Foo'.  Therefore the 'this'
+pointer observed by 'Foo' is not the address of 'a'.
+
+ In a statement expression, any temporaries created within a statement
+are destroyed at that statement's end.  This makes statement expressions
+inside macros slightly different from function calls.  In the latter
+case temporaries introduced during argument evaluation are destroyed at
+the end of the statement that includes the function call.  In the
+statement expression case they are destroyed during the statement
+expression.  For instance,
+
+     #define macro(a)  ({__typeof__(a) b = (a); b + 3; })
+     template<typename T> T function(T a) { T b = a; return b + 3; }
+
+     void foo ()
+     {
+       macro (X ());
+       function (X ());
+     }
+
+has different places where temporaries are destroyed.  For the 'macro'
+case, the temporary 'X' is destroyed just after the initialization of
+'b'.  In the 'function' case that temporary is destroyed when the
+function returns.
+
+ These considerations mean that it is probably a bad idea to use
+statement expressions of this form in header files that are designed to
+work with C++.  (Note that some versions of the GNU C Library contained
+header files using statement expressions that lead to precisely this
+bug.)
+
+ Jumping into a statement expression with 'goto' or using a 'switch'
+statement outside the statement expression with a 'case' or 'default'
+label inside the statement expression is not permitted.  Jumping into a
+statement expression with a computed 'goto' (*note Labels as Values::)
+has undefined behavior.  Jumping out of a statement expression is
+permitted, but if the statement expression is part of a larger
+expression then it is unspecified which other subexpressions of that
+expression have been evaluated except where the language definition
+requires certain subexpressions to be evaluated before or after the
+statement expression.  In any case, as with a function call, the
+evaluation of a statement expression is not interleaved with the
+evaluation of other parts of the containing expression.  For example,
+
+       foo (), (({ bar1 (); goto a; 0; }) + bar2 ()), baz();
+
+calls 'foo' and 'bar1' and does not call 'baz' but may or may not call
+'bar2'.  If 'bar2' is called, it is called after 'foo' and before
+'bar1'.
+
+
+File: gcc.info,  Node: Local Labels,  Next: Labels as Values,  Prev: Statement Exprs,  Up: C Extensions
+
+6.2 Locally Declared Labels
+===========================
+
+GCC allows you to declare "local labels" in any nested block scope.  A
+local label is just like an ordinary label, but you can only reference
+it (with a 'goto' statement, or by taking its address) within the block
+in which it is declared.
+
+ A local label declaration looks like this:
+
+     __label__ LABEL;
+
+or
+
+     __label__ LABEL1, LABEL2, /* ... */;
+
+ Local label declarations must come at the beginning of the block,
+before any ordinary declarations or statements.
+
+ The label declaration defines the label _name_, but does not define the
+label itself.  You must do this in the usual way, with 'LABEL:', within
+the statements of the statement expression.
+
+ The local label feature is useful for complex macros.  If a macro
+contains nested loops, a 'goto' can be useful for breaking out of them.
+However, an ordinary label whose scope is the whole function cannot be
+used: if the macro can be expanded several times in one function, the
+label is multiply defined in that function.  A local label avoids this
+problem.  For example:
+
+     #define SEARCH(value, array, target)              \
+     do {                                              \
+       __label__ found;                                \
+       typeof (target) _SEARCH_target = (target);      \
+       typeof (*(array)) *_SEARCH_array = (array);     \
+       int i, j;                                       \
+       int value;                                      \
+       for (i = 0; i < max; i++)                       \
+         for (j = 0; j < max; j++)                     \
+           if (_SEARCH_array[i][j] == _SEARCH_target)  \
+             { (value) = i; goto found; }              \
+       (value) = -1;                                   \
+      found:;                                          \
+     } while (0)
+
+ This could also be written using a statement expression:
+
+     #define SEARCH(array, target)                     \
+     ({                                                \
+       __label__ found;                                \
+       typeof (target) _SEARCH_target = (target);      \
+       typeof (*(array)) *_SEARCH_array = (array);     \
+       int i, j;                                       \
+       int value;                                      \
+       for (i = 0; i < max; i++)                       \
+         for (j = 0; j < max; j++)                     \
+           if (_SEARCH_array[i][j] == _SEARCH_target)  \
+             { value = i; goto found; }                \
+       value = -1;                                     \
+      found:                                           \
+       value;                                          \
+     })
+
+ Local label declarations also make the labels they declare visible to
+nested functions, if there are any.  *Note Nested Functions::, for
+details.
+
+
+File: gcc.info,  Node: Labels as Values,  Next: Nested Functions,  Prev: Local Labels,  Up: C Extensions
+
+6.3 Labels as Values
+====================
+
+You can get the address of a label defined in the current function (or a
+containing function) with the unary operator '&&'.  The value has type
+'void *'.  This value is a constant and can be used wherever a constant
+of that type is valid.  For example:
+
+     void *ptr;
+     /* ... */
+     ptr = &&foo;
+
+ To use these values, you need to be able to jump to one.  This is done
+with the computed goto statement(1), 'goto *EXP;'.  For example,
+
+     goto *ptr;
+
+Any expression of type 'void *' is allowed.
+
+ One way of using these constants is in initializing a static array that
+serves as a jump table:
+
+     static void *array[] = { &&foo, &&bar, &&hack };
+
+Then you can select a label with indexing, like this:
+
+     goto *array[i];
+
+Note that this does not check whether the subscript is in bounds--array
+indexing in C never does that.
+
+ Such an array of label values serves a purpose much like that of the
+'switch' statement.  The 'switch' statement is cleaner, so use that
+rather than an array unless the problem does not fit a 'switch'
+statement very well.
+
+ Another use of label values is in an interpreter for threaded code.
+The labels within the interpreter function can be stored in the threaded
+code for super-fast dispatching.
+
+ You may not use this mechanism to jump to code in a different function.
+If you do that, totally unpredictable things happen.  The best way to
+avoid this is to store the label address only in automatic variables and
+never pass it as an argument.
+
+ An alternate way to write the above example is
+
+     static const int array[] = { &&foo - &&foo, &&bar - &&foo,
+                                  &&hack - &&foo };
+     goto *(&&foo + array[i]);
+
+This is more friendly to code living in shared libraries, as it reduces
+the number of dynamic relocations that are needed, and by consequence,
+allows the data to be read-only.
+
+ The '&&foo' expressions for the same label might have different values
+if the containing function is inlined or cloned.  If a program relies on
+them being always the same, '__attribute__((__noinline__,__noclone__))'
+should be used to prevent inlining and cloning.  If '&&foo' is used in a
+static variable initializer, inlining and cloning is forbidden.
+
+   ---------- Footnotes ----------
+
+   (1) The analogous feature in Fortran is called an assigned goto, but
+that name seems inappropriate in C, where one can do more than simply
+store label addresses in label variables.
+
+
+File: gcc.info,  Node: Nested Functions,  Next: Constructing Calls,  Prev: Labels as Values,  Up: C Extensions
+
+6.4 Nested Functions
+====================
+
+A "nested function" is a function defined inside another function.
+Nested functions are supported as an extension in GNU C, but are not
+supported by GNU C++.
+
+ The nested function's name is local to the block where it is defined.
+For example, here we define a nested function named 'square', and call
+it twice:
+
+     foo (double a, double b)
+     {
+       double square (double z) { return z * z; }
+
+       return square (a) + square (b);
+     }
+
+ The nested function can access all the variables of the containing
+function that are visible at the point of its definition.  This is
+called "lexical scoping".  For example, here we show a nested function
+which uses an inherited variable named 'offset':
+
+     bar (int *array, int offset, int size)
+     {
+       int access (int *array, int index)
+         { return array[index + offset]; }
+       int i;
+       /* ... */
+       for (i = 0; i < size; i++)
+         /* ... */ access (array, i) /* ... */
+     }
+
+ Nested function definitions are permitted within functions in the
+places where variable definitions are allowed; that is, in any block,
+mixed with the other declarations and statements in the block.
+
+ It is possible to call the nested function from outside the scope of
+its name by storing its address or passing the address to another
+function:
+
+     hack (int *array, int size)
+     {
+       void store (int index, int value)
+         { array[index] = value; }
+
+       intermediate (store, size);
+     }
+
+ Here, the function 'intermediate' receives the address of 'store' as an
+argument.  If 'intermediate' calls 'store', the arguments given to
+'store' are used to store into 'array'.  But this technique works only
+so long as the containing function ('hack', in this example) does not
+exit.
+
+ If you try to call the nested function through its address after the
+containing function exits, all hell breaks loose.  If you try to call it
+after a containing scope level exits, and if it refers to some of the
+variables that are no longer in scope, you may be lucky, but it's not
+wise to take the risk.  If, however, the nested function does not refer
+to anything that has gone out of scope, you should be safe.
+
+ GCC implements taking the address of a nested function using a
+technique called "trampolines".  This technique was described in
+'Lexical Closures for C++' (Thomas M. Breuel, USENIX C++ Conference
+Proceedings, October 17-21, 1988).
+
+ A nested function can jump to a label inherited from a containing
+function, provided the label is explicitly declared in the containing
+function (*note Local Labels::).  Such a jump returns instantly to the
+containing function, exiting the nested function that did the 'goto' and
+any intermediate functions as well.  Here is an example:
+
+     bar (int *array, int offset, int size)
+     {
+       __label__ failure;
+       int access (int *array, int index)
+         {
+           if (index > size)
+             goto failure;
+           return array[index + offset];
+         }
+       int i;
+       /* ... */
+       for (i = 0; i < size; i++)
+         /* ... */ access (array, i) /* ... */
+       /* ... */
+       return 0;
+
+      /* Control comes here from 'access'
+         if it detects an error.  */
+      failure:
+       return -1;
+     }
+
+ A nested function always has no linkage.  Declaring one with 'extern'
+or 'static' is erroneous.  If you need to declare the nested function
+before its definition, use 'auto' (which is otherwise meaningless for
+function declarations).
+
+     bar (int *array, int offset, int size)
+     {
+       __label__ failure;
+       auto int access (int *, int);
+       /* ... */
+       int access (int *array, int index)
+         {
+           if (index > size)
+             goto failure;
+           return array[index + offset];
+         }
+       /* ... */
+     }
+
+
+File: gcc.info,  Node: Constructing Calls,  Next: Typeof,  Prev: Nested Functions,  Up: C Extensions
+
+6.5 Constructing Function Calls
+===============================
+
+Using the built-in functions described below, you can record the
+arguments a function received, and call another function with the same
+arguments, without knowing the number or types of the arguments.
+
+ You can also record the return value of that function call, and later
+return that value, without knowing what data type the function tried to
+return (as long as your caller expects that data type).
+
+ However, these built-in functions may interact badly with some
+sophisticated features or other extensions of the language.  It is,
+therefore, not recommended to use them outside very simple functions
+acting as mere forwarders for their arguments.
+
+ -- Built-in Function: void * __builtin_apply_args ()
+     This built-in function returns a pointer to data describing how to
+     perform a call with the same arguments as are passed to the current
+     function.
+
+     The function saves the arg pointer register, structure value
+     address, and all registers that might be used to pass arguments to
+     a function into a block of memory allocated on the stack.  Then it
+     returns the address of that block.
+
+ -- Built-in Function: void * __builtin_apply (void (*FUNCTION)(), void
+          *ARGUMENTS, size_t SIZE)
+     This built-in function invokes FUNCTION with a copy of the
+     parameters described by ARGUMENTS and SIZE.
+
+     The value of ARGUMENTS should be the value returned by
+     '__builtin_apply_args'.  The argument SIZE specifies the size of
+     the stack argument data, in bytes.
+
+     This function returns a pointer to data describing how to return
+     whatever value is returned by FUNCTION.  The data is saved in a
+     block of memory allocated on the stack.
+
+     It is not always simple to compute the proper value for SIZE.  The
+     value is used by '__builtin_apply' to compute the amount of data
+     that should be pushed on the stack and copied from the incoming
+     argument area.
+
+ -- Built-in Function: void __builtin_return (void *RESULT)
+     This built-in function returns the value described by RESULT from
+     the containing function.  You should specify, for RESULT, a value
+     returned by '__builtin_apply'.
+
+ -- Built-in Function: __builtin_va_arg_pack ()
+     This built-in function represents all anonymous arguments of an
+     inline function.  It can be used only in inline functions that are
+     always inlined, never compiled as a separate function, such as
+     those using '__attribute__ ((__always_inline__))' or '__attribute__
+     ((__gnu_inline__))' extern inline functions.  It must be only
+     passed as last argument to some other function with variable
+     arguments.  This is useful for writing small wrapper inlines for
+     variable argument functions, when using preprocessor macros is
+     undesirable.  For example:
+          extern int myprintf (FILE *f, const char *format, ...);
+          extern inline __attribute__ ((__gnu_inline__)) int
+          myprintf (FILE *f, const char *format, ...)
+          {
+            int r = fprintf (f, "myprintf: ");
+            if (r < 0)
+              return r;
+            int s = fprintf (f, format, __builtin_va_arg_pack ());
+            if (s < 0)
+              return s;
+            return r + s;
+          }
+
+ -- Built-in Function: size_t __builtin_va_arg_pack_len ()
+     This built-in function returns the number of anonymous arguments of
+     an inline function.  It can be used only in inline functions that
+     are always inlined, never compiled as a separate function, such as
+     those using '__attribute__ ((__always_inline__))' or '__attribute__
+     ((__gnu_inline__))' extern inline functions.  For example following
+     does link- or run-time checking of open arguments for optimized
+     code:
+          #ifdef __OPTIMIZE__
+          extern inline __attribute__((__gnu_inline__)) int
+          myopen (const char *path, int oflag, ...)
+          {
+            if (__builtin_va_arg_pack_len () > 1)
+              warn_open_too_many_arguments ();
+
+            if (__builtin_constant_p (oflag))
+              {
+                if ((oflag & O_CREAT) != 0 && __builtin_va_arg_pack_len () < 1)
+                  {
+                    warn_open_missing_mode ();
+                    return __open_2 (path, oflag);
+                  }
+                return open (path, oflag, __builtin_va_arg_pack ());
+              }
+
+            if (__builtin_va_arg_pack_len () < 1)
+              return __open_2 (path, oflag);
+
+            return open (path, oflag, __builtin_va_arg_pack ());
+          }
+          #endif
+
+
+File: gcc.info,  Node: Typeof,  Next: Conditionals,  Prev: Constructing Calls,  Up: C Extensions
+
+6.6 Referring to a Type with 'typeof'
+=====================================
+
+Another way to refer to the type of an expression is with 'typeof'.  The
+syntax of using of this keyword looks like 'sizeof', but the construct
+acts semantically like a type name defined with 'typedef'.
+
+ There are two ways of writing the argument to 'typeof': with an
+expression or with a type.  Here is an example with an expression:
+
+     typeof (x[0](1))
+
+This assumes that 'x' is an array of pointers to functions; the type
+described is that of the values of the functions.
+
+ Here is an example with a typename as the argument:
+
+     typeof (int *)
+
+Here the type described is that of pointers to 'int'.
+
+ If you are writing a header file that must work when included in ISO C
+programs, write '__typeof__' instead of 'typeof'.  *Note Alternate
+Keywords::.
+
+ A 'typeof' construct can be used anywhere a typedef name can be used.
+For example, you can use it in a declaration, in a cast, or inside of
+'sizeof' or 'typeof'.
+
+ The operand of 'typeof' is evaluated for its side effects if and only
+if it is an expression of variably modified type or the name of such a
+type.
+
+ 'typeof' is often useful in conjunction with statement expressions
+(*note Statement Exprs::).  Here is how the two together can be used to
+define a safe "maximum" macro which operates on any arithmetic type and
+evaluates each of its arguments exactly once:
+
+     #define max(a,b) \
+       ({ typeof (a) _a = (a); \
+           typeof (b) _b = (b); \
+         _a > _b ? _a : _b; })
+
+ The reason for using names that start with underscores for the local
+variables is to avoid conflicts with variable names that occur within
+the expressions that are substituted for 'a' and 'b'.  Eventually we
+hope to design a new form of declaration syntax that allows you to
+declare variables whose scopes start only after their initializers; this
+will be a more reliable way to prevent such conflicts.
+
+Some more examples of the use of 'typeof':
+
+   * This declares 'y' with the type of what 'x' points to.
+
+          typeof (*x) y;
+
+   * This declares 'y' as an array of such values.
+
+          typeof (*x) y[4];
+
+   * This declares 'y' as an array of pointers to characters:
+
+          typeof (typeof (char *)[4]) y;
+
+     It is equivalent to the following traditional C declaration:
+
+          char *y[4];
+
+     To see the meaning of the declaration using 'typeof', and why it
+     might be a useful way to write, rewrite it with these macros:
+
+          #define pointer(T)  typeof(T *)
+          #define array(T, N) typeof(T [N])
+
+     Now the declaration can be rewritten this way:
+
+          array (pointer (char), 4) y;
+
+     Thus, 'array (pointer (char), 4)' is the type of arrays of 4
+     pointers to 'char'.
+
+ In GNU C, but not GNU C++, you may also declare the type of a variable
+as '__auto_type'.  In that case, the declaration must declare only one
+variable, whose declarator must just be an identifier, the declaration
+must be initialized, and the type of the variable is determined by the
+initializer; the name of the variable is not in scope until after the
+initializer.  (In C++, you should use C++11 'auto' for this purpose.)
+Using '__auto_type', the "maximum" macro above could be written as:
+
+     #define max(a,b) \
+       ({ __auto_type _a = (a); \
+           __auto_type _b = (b); \
+         _a > _b ? _a : _b; })
+
+ Using '__auto_type' instead of 'typeof' has two advantages:
+
+   * Each argument to the macro appears only once in the expansion of
+     the macro.  This prevents the size of the macro expansion growing
+     exponentially when calls to such macros are nested inside arguments
+     of such macros.
+
+   * If the argument to the macro has variably modified type, it is
+     evaluated only once when using '__auto_type', but twice if 'typeof'
+     is used.
+
+ _Compatibility Note:_ In addition to 'typeof', GCC 2 supported a more
+limited extension that permitted one to write
+
+     typedef T = EXPR;
+
+with the effect of declaring T to have the type of the expression EXPR.
+This extension does not work with GCC 3 (versions between 3.0 and 3.2
+crash; 3.2.1 and later give an error).  Code that relies on it should be
+rewritten to use 'typeof':
+
+     typedef typeof(EXPR) T;
+
+This works with all versions of GCC.
+
+
+File: gcc.info,  Node: Conditionals,  Next: __int128,  Prev: Typeof,  Up: C Extensions
+
+6.7 Conditionals with Omitted Operands
+======================================
+
+The middle operand in a conditional expression may be omitted.  Then if
+the first operand is nonzero, its value is the value of the conditional
+expression.
+
+ Therefore, the expression
+
+     x ? : y
+
+has the value of 'x' if that is nonzero; otherwise, the value of 'y'.
+
+ This example is perfectly equivalent to
+
+     x ? x : y
+
+In this simple case, the ability to omit the middle operand is not
+especially useful.  When it becomes useful is when the first operand
+does, or may (if it is a macro argument), contain a side effect.  Then
+repeating the operand in the middle would perform the side effect twice.
+Omitting the middle operand uses the value already computed without the
+undesirable effects of recomputing it.
+
+
+File: gcc.info,  Node: __int128,  Next: Long Long,  Prev: Conditionals,  Up: C Extensions
+
+6.8 128-bit integers
+====================
+
+As an extension the integer scalar type '__int128' is supported for
+targets which have an integer mode wide enough to hold 128 bits.  Simply
+write '__int128' for a signed 128-bit integer, or 'unsigned __int128'
+for an unsigned 128-bit integer.  There is no support in GCC for
+expressing an integer constant of type '__int128' for targets with 'long
+long' integer less than 128 bits wide.
+
+
+File: gcc.info,  Node: Long Long,  Next: Complex,  Prev: __int128,  Up: C Extensions
+
+6.9 Double-Word Integers
+========================
+
+ISO C99 supports data types for integers that are at least 64 bits wide,
+and as an extension GCC supports them in C90 mode and in C++.  Simply
+write 'long long int' for a signed integer, or 'unsigned long long int'
+for an unsigned integer.  To make an integer constant of type 'long long
+int', add the suffix 'LL' to the integer.  To make an integer constant
+of type 'unsigned long long int', add the suffix 'ULL' to the integer.
+
+ You can use these types in arithmetic like any other integer types.
+Addition, subtraction, and bitwise boolean operations on these types are
+open-coded on all types of machines.  Multiplication is open-coded if
+the machine supports a fullword-to-doubleword widening multiply
+instruction.  Division and shifts are open-coded only on machines that
+provide special support.  The operations that are not open-coded use
+special library routines that come with GCC.
+
+ There may be pitfalls when you use 'long long' types for function
+arguments without function prototypes.  If a function expects type 'int'
+for its argument, and you pass a value of type 'long long int',
+confusion results because the caller and the subroutine disagree about
+the number of bytes for the argument.  Likewise, if the function expects
+'long long int' and you pass 'int'.  The best way to avoid such problems
+is to use prototypes.
+
+
+File: gcc.info,  Node: Complex,  Next: Floating Types,  Prev: Long Long,  Up: C Extensions
+
+6.10 Complex Numbers
+====================
+
+ISO C99 supports complex floating data types, and as an extension GCC
+supports them in C90 mode and in C++.  GCC also supports complex integer
+data types which are not part of ISO C99.  You can declare complex types
+using the keyword '_Complex'.  As an extension, the older GNU keyword
+'__complex__' is also supported.
+
+ For example, '_Complex double x;' declares 'x' as a variable whose real
+part and imaginary part are both of type 'double'.  '_Complex short int
+y;' declares 'y' to have real and imaginary parts of type 'short int';
+this is not likely to be useful, but it shows that the set of complex
+types is complete.
+
+ To write a constant with a complex data type, use the suffix 'i' or 'j'
+(either one; they are equivalent).  For example, '2.5fi' has type
+'_Complex float' and '3i' has type '_Complex int'.  Such a constant
+always has a pure imaginary value, but you can form any complex value
+you like by adding one to a real constant.  This is a GNU extension; if
+you have an ISO C99 conforming C library (such as the GNU C Library),
+and want to construct complex constants of floating type, you should
+include '<complex.h>' and use the macros 'I' or '_Complex_I' instead.
+
+ To extract the real part of a complex-valued expression EXP, write
+'__real__ EXP'.  Likewise, use '__imag__' to extract the imaginary part.
+This is a GNU extension; for values of floating type, you should use the
+ISO C99 functions 'crealf', 'creal', 'creall', 'cimagf', 'cimag' and
+'cimagl', declared in '<complex.h>' and also provided as built-in
+functions by GCC.
+
+ The operator '~' performs complex conjugation when used on a value with
+a complex type.  This is a GNU extension; for values of floating type,
+you should use the ISO C99 functions 'conjf', 'conj' and 'conjl',
+declared in '<complex.h>' and also provided as built-in functions by
+GCC.
+
+ GCC can allocate complex automatic variables in a noncontiguous
+fashion; it's even possible for the real part to be in a register while
+the imaginary part is on the stack (or vice versa).  Only the DWARF 2
+debug info format can represent this, so use of DWARF 2 is recommended.
+If you are using the stabs debug info format, GCC describes a
+noncontiguous complex variable as if it were two separate variables of
+noncomplex type.  If the variable's actual name is 'foo', the two
+fictitious variables are named 'foo$real' and 'foo$imag'.  You can
+examine and set these two fictitious variables with your debugger.
+
+
+File: gcc.info,  Node: Floating Types,  Next: Half-Precision,  Prev: Complex,  Up: C Extensions
+
+6.11 Additional Floating Types
+==============================
+
+As an extension, GNU C supports additional floating types, '__float80'
+and '__float128' to support 80-bit ('XFmode') and 128-bit ('TFmode')
+floating types.  Support for additional types includes the arithmetic
+operators: add, subtract, multiply, divide; unary arithmetic operators;
+relational operators; equality operators; and conversions to and from
+integer and other floating types.  Use a suffix 'w' or 'W' in a literal
+constant of type '__float80' and 'q' or 'Q' for '_float128'.  You can
+declare complex types using the corresponding internal complex type,
+'XCmode' for '__float80' type and 'TCmode' for '__float128' type:
+
+     typedef _Complex float __attribute__((mode(TC))) _Complex128;
+     typedef _Complex float __attribute__((mode(XC))) _Complex80;
+
+ Not all targets support additional floating-point types.  '__float80'
+and '__float128' types are supported on i386, x86_64 and IA-64 targets.
+The '__float128' type is supported on hppa HP-UX targets.
+
+
+File: gcc.info,  Node: Half-Precision,  Next: Decimal Float,  Prev: Floating Types,  Up: C Extensions
+
+6.12 Half-Precision Floating Point
+==================================
+
+On ARM targets, GCC supports half-precision (16-bit) floating point via
+the '__fp16' type.  You must enable this type explicitly with the
+'-mfp16-format' command-line option in order to use it.
+
+ ARM supports two incompatible representations for half-precision
+floating-point values.  You must choose one of the representations and
+use it consistently in your program.
+
+ Specifying '-mfp16-format=ieee' selects the IEEE 754-2008 format.  This
+format can represent normalized values in the range of 2^{-14} to 65504.
+There are 11 bits of significand precision, approximately 3 decimal
+digits.
+
+ Specifying '-mfp16-format=alternative' selects the ARM alternative
+format.  This representation is similar to the IEEE format, but does not
+support infinities or NaNs.  Instead, the range of exponents is
+extended, so that this format can represent normalized values in the
+range of 2^{-14} to 131008.
+
+ The '__fp16' type is a storage format only.  For purposes of arithmetic
+and other operations, '__fp16' values in C or C++ expressions are
+automatically promoted to 'float'.  In addition, you cannot declare a
+function with a return value or parameters of type '__fp16'.
+
+ Note that conversions from 'double' to '__fp16' involve an intermediate
+conversion to 'float'.  Because of rounding, this can sometimes produce
+a different result than a direct conversion.
+
+ ARM provides hardware support for conversions between '__fp16' and
+'float' values as an extension to VFP and NEON (Advanced SIMD). GCC
+generates code using these hardware instructions if you compile with
+options to select an FPU that provides them; for example,
+'-mfpu=neon-fp16 -mfloat-abi=softfp', in addition to the '-mfp16-format'
+option to select a half-precision format.
+
+ Language-level support for the '__fp16' data type is independent of
+whether GCC generates code using hardware floating-point instructions.
+In cases where hardware support is not specified, GCC implements
+conversions between '__fp16' and 'float' values as library calls.
+
+
+File: gcc.info,  Node: Decimal Float,  Next: Hex Floats,  Prev: Half-Precision,  Up: C Extensions
+
+6.13 Decimal Floating Types
+===========================
+
+As an extension, GNU C supports decimal floating types as defined in the
+N1312 draft of ISO/IEC WDTR24732.  Support for decimal floating types in
+GCC will evolve as the draft technical report changes.  Calling
+conventions for any target might also change.  Not all targets support
+decimal floating types.
+
+ The decimal floating types are '_Decimal32', '_Decimal64', and
+'_Decimal128'.  They use a radix of ten, unlike the floating types
+'float', 'double', and 'long double' whose radix is not specified by the
+C standard but is usually two.
+
+ Support for decimal floating types includes the arithmetic operators
+add, subtract, multiply, divide; unary arithmetic operators; relational
+operators; equality operators; and conversions to and from integer and
+other floating types.  Use a suffix 'df' or 'DF' in a literal constant
+of type '_Decimal32', 'dd' or 'DD' for '_Decimal64', and 'dl' or 'DL'
+for '_Decimal128'.
+
+ GCC support of decimal float as specified by the draft technical report
+is incomplete:
+
+   * When the value of a decimal floating type cannot be represented in
+     the integer type to which it is being converted, the result is
+     undefined rather than the result value specified by the draft
+     technical report.
+
+   * GCC does not provide the C library functionality associated with
+     'math.h', 'fenv.h', 'stdio.h', 'stdlib.h', and 'wchar.h', which
+     must come from a separate C library implementation.  Because of
+     this the GNU C compiler does not define macro '__STDC_DEC_FP__' to
+     indicate that the implementation conforms to the technical report.
+
+ Types '_Decimal32', '_Decimal64', and '_Decimal128' are supported by
+the DWARF 2 debug information format.
+
+
+File: gcc.info,  Node: Hex Floats,  Next: Fixed-Point,  Prev: Decimal Float,  Up: C Extensions
+
+6.14 Hex Floats
+===============
+
+ISO C99 supports floating-point numbers written not only in the usual
+decimal notation, such as '1.55e1', but also numbers such as '0x1.fp3'
+written in hexadecimal format.  As a GNU extension, GCC supports this in
+C90 mode (except in some cases when strictly conforming) and in C++.  In
+that format the '0x' hex introducer and the 'p' or 'P' exponent field
+are mandatory.  The exponent is a decimal number that indicates the
+power of 2 by which the significant part is multiplied.  Thus '0x1.f' is
+1 15/16, 'p3' multiplies it by 8, and the value of '0x1.fp3' is the same
+as '1.55e1'.
+
+ Unlike for floating-point numbers in the decimal notation the exponent
+is always required in the hexadecimal notation.  Otherwise the compiler
+would not be able to resolve the ambiguity of, e.g., '0x1.f'.  This
+could mean '1.0f' or '1.9375' since 'f' is also the extension for
+floating-point constants of type 'float'.
+
+
+File: gcc.info,  Node: Fixed-Point,  Next: Named Address Spaces,  Prev: Hex Floats,  Up: C Extensions
+
+6.15 Fixed-Point Types
+======================
+
+As an extension, GNU C supports fixed-point types as defined in the
+N1169 draft of ISO/IEC DTR 18037.  Support for fixed-point types in GCC
+will evolve as the draft technical report changes.  Calling conventions
+for any target might also change.  Not all targets support fixed-point
+types.
+
+ The fixed-point types are 'short _Fract', '_Fract', 'long _Fract',
+'long long _Fract', 'unsigned short _Fract', 'unsigned _Fract',
+'unsigned long _Fract', 'unsigned long long _Fract', '_Sat short
+_Fract', '_Sat _Fract', '_Sat long _Fract', '_Sat long long _Fract',
+'_Sat unsigned short _Fract', '_Sat unsigned _Fract', '_Sat unsigned
+long _Fract', '_Sat unsigned long long _Fract', 'short _Accum',
+'_Accum', 'long _Accum', 'long long _Accum', 'unsigned short _Accum',
+'unsigned _Accum', 'unsigned long _Accum', 'unsigned long long _Accum',
+'_Sat short _Accum', '_Sat _Accum', '_Sat long _Accum', '_Sat long long
+_Accum', '_Sat unsigned short _Accum', '_Sat unsigned _Accum', '_Sat
+unsigned long _Accum', '_Sat unsigned long long _Accum'.
+
+ Fixed-point data values contain fractional and optional integral parts.
+The format of fixed-point data varies and depends on the target machine.
+
+ Support for fixed-point types includes:
+   * prefix and postfix increment and decrement operators ('++', '--')
+   * unary arithmetic operators ('+', '-', '!')
+   * binary arithmetic operators ('+', '-', '*', '/')
+   * binary shift operators ('<<', '>>')
+   * relational operators ('<', '<=', '>=', '>')
+   * equality operators ('==', '!=')
+   * assignment operators ('+=', '-=', '*=', '/=', '<<=', '>>=')
+   * conversions to and from integer, floating-point, or fixed-point
+     types
+
+ Use a suffix in a fixed-point literal constant:
+   * 'hr' or 'HR' for 'short _Fract' and '_Sat short _Fract'
+   * 'r' or 'R' for '_Fract' and '_Sat _Fract'
+   * 'lr' or 'LR' for 'long _Fract' and '_Sat long _Fract'
+   * 'llr' or 'LLR' for 'long long _Fract' and '_Sat long long _Fract'
+   * 'uhr' or 'UHR' for 'unsigned short _Fract' and '_Sat unsigned short
+     _Fract'
+   * 'ur' or 'UR' for 'unsigned _Fract' and '_Sat unsigned _Fract'
+   * 'ulr' or 'ULR' for 'unsigned long _Fract' and '_Sat unsigned long
+     _Fract'
+   * 'ullr' or 'ULLR' for 'unsigned long long _Fract' and '_Sat unsigned
+     long long _Fract'
+   * 'hk' or 'HK' for 'short _Accum' and '_Sat short _Accum'
+   * 'k' or 'K' for '_Accum' and '_Sat _Accum'
+   * 'lk' or 'LK' for 'long _Accum' and '_Sat long _Accum'
+   * 'llk' or 'LLK' for 'long long _Accum' and '_Sat long long _Accum'
+   * 'uhk' or 'UHK' for 'unsigned short _Accum' and '_Sat unsigned short
+     _Accum'
+   * 'uk' or 'UK' for 'unsigned _Accum' and '_Sat unsigned _Accum'
+   * 'ulk' or 'ULK' for 'unsigned long _Accum' and '_Sat unsigned long
+     _Accum'
+   * 'ullk' or 'ULLK' for 'unsigned long long _Accum' and '_Sat unsigned
+     long long _Accum'
+
+ GCC support of fixed-point types as specified by the draft technical
+report is incomplete:
+
+   * Pragmas to control overflow and rounding behaviors are not
+     implemented.
+
+ Fixed-point types are supported by the DWARF 2 debug information
+format.
+
+
+File: gcc.info,  Node: Named Address Spaces,  Next: Zero Length,  Prev: Fixed-Point,  Up: C Extensions
+
+6.16 Named Address Spaces
+=========================
+
+As an extension, GNU C supports named address spaces as defined in the
+N1275 draft of ISO/IEC DTR 18037.  Support for named address spaces in
+GCC will evolve as the draft technical report changes.  Calling
+conventions for any target might also change.  At present, only the AVR,
+SPU, M32C, and RL78 targets support address spaces other than the
+generic address space.
+
+ Address space identifiers may be used exactly like any other C type
+qualifier (e.g., 'const' or 'volatile').  See the N1275 document for
+more details.
+
+6.16.1 AVR Named Address Spaces
+-------------------------------
+
+On the AVR target, there are several address spaces that can be used in
+order to put read-only data into the flash memory and access that data
+by means of the special instructions 'LPM' or 'ELPM' needed to read from
+flash.
+
+ Per default, any data including read-only data is located in RAM (the
+generic address space) so that non-generic address spaces are needed to
+locate read-only data in flash memory _and_ to generate the right
+instructions to access this data without using (inline) assembler code.
+
+'__flash'
+     The '__flash' qualifier locates data in the '.progmem.data'
+     section.  Data is read using the 'LPM' instruction.  Pointers to
+     this address space are 16 bits wide.
+
+'__flash1'
+'__flash2'
+'__flash3'
+'__flash4'
+'__flash5'
+     These are 16-bit address spaces locating data in section
+     '.progmemN.data' where N refers to address space '__flashN'.  The
+     compiler sets the 'RAMPZ' segment register appropriately before
+     reading data by means of the 'ELPM' instruction.
+
+'__memx'
+     This is a 24-bit address space that linearizes flash and RAM: If
+     the high bit of the address is set, data is read from RAM using the
+     lower two bytes as RAM address.  If the high bit of the address is
+     clear, data is read from flash with 'RAMPZ' set according to the
+     high byte of the address.  *Note '__builtin_avr_flash_segment': AVR
+     Built-in Functions.
+
+     Objects in this address space are located in '.progmemx.data'.
+
+ Example
+
+     char my_read (const __flash char ** p)
+     {
+         /* p is a pointer to RAM that points to a pointer to flash.
+            The first indirection of p reads that flash pointer
+            from RAM and the second indirection reads a char from this
+            flash address.  */
+
+         return **p;
+     }
+
+     /* Locate array[] in flash memory */
+     const __flash int array[] = { 3, 5, 7, 11, 13, 17, 19 };
+
+     int i = 1;
+
+     int main (void)
+     {
+        /* Return 17 by reading from flash memory */
+        return array[array[i]];
+     }
+
+For each named address space supported by avr-gcc there is an equally
+named but uppercase built-in macro defined.  The purpose is to
+facilitate testing if respective address space support is available or
+not:
+
+     #ifdef __FLASH
+     const __flash int var = 1;
+
+     int read_var (void)
+     {
+         return var;
+     }
+     #else
+     #include <avr/pgmspace.h> /* From AVR-LibC */
+
+     const int var PROGMEM = 1;
+
+     int read_var (void)
+     {
+         return (int) pgm_read_word (&var);
+     }
+     #endif /* __FLASH */
+
+Notice that attribute *note 'progmem': AVR Variable Attributes. locates
+data in flash but accesses to these data read from generic address
+space, i.e. from RAM, so that you need special accessors like
+'pgm_read_byte' from AVR-LibC (http://nongnu.org/avr-libc/user-manual/)
+together with attribute 'progmem'.
+
+Limitations and caveats
+
+   * Reading across the 64 KiB section boundary of the '__flash' or
+     '__flashN' address spaces shows undefined behavior.  The only
+     address space that supports reading across the 64 KiB flash segment
+     boundaries is '__memx'.
+
+   * If you use one of the '__flashN' address spaces you must arrange
+     your linker script to locate the '.progmemN.data' sections
+     according to your needs.
+
+   * Any data or pointers to the non-generic address spaces must be
+     qualified as 'const', i.e. as read-only data.  This still applies
+     if the data in one of these address spaces like software version
+     number or calibration lookup table are intended to be changed after
+     load time by, say, a boot loader.  In this case the right
+     qualification is 'const' 'volatile' so that the compiler must not
+     optimize away known values or insert them as immediates into
+     operands of instructions.
+
+   * The following code initializes a variable 'pfoo' located in static
+     storage with a 24-bit address:
+          extern const __memx char foo;
+          const __memx void *pfoo = &foo;
+
+     Such code requires at least binutils 2.23, see
+     PR13503 (http://sourceware.org/PR13503).
+
+6.16.2 M32C Named Address Spaces
+--------------------------------
+
+On the M32C target, with the R8C and M16C CPU variants, variables
+qualified with '__far' are accessed using 32-bit addresses in order to
+access memory beyond the first 64 Ki bytes.  If '__far' is used with the
+M32CM or M32C CPU variants, it has no effect.
+
+6.16.3 RL78 Named Address Spaces
+--------------------------------
+
+On the RL78 target, variables qualified with '__far' are accessed with
+32-bit pointers (20-bit addresses) rather than the default 16-bit
+addresses.  Non-far variables are assumed to appear in the topmost
+64 KiB of the address space.
+
+6.16.4 SPU Named Address Spaces
+-------------------------------
+
+On the SPU target variables may be declared as belonging to another
+address space by qualifying the type with the '__ea' address space
+identifier:
+
+     extern int __ea i;
+
+The compiler generates special code to access the variable 'i'.  It may
+use runtime library support, or generate special machine instructions to
+access that address space.
+
+
+File: gcc.info,  Node: Zero Length,  Next: Empty Structures,  Prev: Named Address Spaces,  Up: C Extensions
+
+6.17 Arrays of Length Zero
+==========================
+
+Zero-length arrays are allowed in GNU C.  They are very useful as the
+last element of a structure that is really a header for a
+variable-length object:
+
+     struct line {
+       int length;
+       char contents[0];
+     };
+
+     struct line *thisline = (struct line *)
+       malloc (sizeof (struct line) + this_length);
+     thisline->length = this_length;
+
+ In ISO C90, you would have to give 'contents' a length of 1, which
+means either you waste space or complicate the argument to 'malloc'.
+
+ In ISO C99, you would use a "flexible array member", which is slightly
+different in syntax and semantics:
+
+   * Flexible array members are written as 'contents[]' without the '0'.
+
+   * Flexible array members have incomplete type, and so the 'sizeof'
+     operator may not be applied.  As a quirk of the original
+     implementation of zero-length arrays, 'sizeof' evaluates to zero.
+
+   * Flexible array members may only appear as the last member of a
+     'struct' that is otherwise non-empty.
+
+   * A structure containing a flexible array member, or a union
+     containing such a structure (possibly recursively), may not be a
+     member of a structure or an element of an array.  (However, these
+     uses are permitted by GCC as extensions.)
+
+ GCC versions before 3.0 allowed zero-length arrays to be statically
+initialized, as if they were flexible arrays.  In addition to those
+cases that were useful, it also allowed initializations in situations
+that would corrupt later data.  Non-empty initialization of zero-length
+arrays is now treated like any case where there are more initializer
+elements than the array holds, in that a suitable warning about "excess
+elements in array" is given, and the excess elements (all of them, in
+this case) are ignored.
+
+ Instead GCC allows static initialization of flexible array members.
+This is equivalent to defining a new structure containing the original
+structure followed by an array of sufficient size to contain the data.
+E.g. in the following, 'f1' is constructed as if it were declared like
+'f2'.
+
+     struct f1 {
+       int x; int y[];
+     } f1 = { 1, { 2, 3, 4 } };
+
+     struct f2 {
+       struct f1 f1; int data[3];
+     } f2 = { { 1 }, { 2, 3, 4 } };
+
+The convenience of this extension is that 'f1' has the desired type,
+eliminating the need to consistently refer to 'f2.f1'.
+
+ This has symmetry with normal static arrays, in that an array of
+unknown size is also written with '[]'.
+
+ Of course, this extension only makes sense if the extra data comes at
+the end of a top-level object, as otherwise we would be overwriting data
+at subsequent offsets.  To avoid undue complication and confusion with
+initialization of deeply nested arrays, we simply disallow any non-empty
+initialization except when the structure is the top-level object.  For
+example:
+
+     struct foo { int x; int y[]; };
+     struct bar { struct foo z; };
+
+     struct foo a = { 1, { 2, 3, 4 } };        // Valid.
+     struct bar b = { { 1, { 2, 3, 4 } } };    // Invalid.
+     struct bar c = { { 1, { } } };            // Valid.
+     struct foo d[1] = { { 1 { 2, 3, 4 } } };  // Invalid.
+
+
+File: gcc.info,  Node: Empty Structures,  Next: Variable Length,  Prev: Zero Length,  Up: C Extensions
+
+6.18 Structures With No Members
+===============================
+
+GCC permits a C structure to have no members:
+
+     struct empty {
+     };
+
+ The structure has size zero.  In C++, empty structures are part of the
+language.  G++ treats empty structures as if they had a single member of
+type 'char'.
+
+
+File: gcc.info,  Node: Variable Length,  Next: Variadic Macros,  Prev: Empty Structures,  Up: C Extensions
+
+6.19 Arrays of Variable Length
+==============================
+
+Variable-length automatic arrays are allowed in ISO C99, and as an
+extension GCC accepts them in C90 mode and in C++.  These arrays are
+declared like any other automatic arrays, but with a length that is not
+a constant expression.  The storage is allocated at the point of
+declaration and deallocated when the block scope containing the
+declaration exits.  For example:
+
+     FILE *
+     concat_fopen (char *s1, char *s2, char *mode)
+     {
+       char str[strlen (s1) + strlen (s2) + 1];
+       strcpy (str, s1);
+       strcat (str, s2);
+       return fopen (str, mode);
+     }
+
+ Jumping or breaking out of the scope of the array name deallocates the
+storage.  Jumping into the scope is not allowed; you get an error
+message for it.
+
+ As an extension, GCC accepts variable-length arrays as a member of a
+structure or a union.  For example:
+
+     void
+     foo (int n)
+     {
+       struct S { int x[n]; };
+     }
+
+ You can use the function 'alloca' to get an effect much like
+variable-length arrays.  The function 'alloca' is available in many
+other C implementations (but not in all).  On the other hand,
+variable-length arrays are more elegant.
+
+ There are other differences between these two methods.  Space allocated
+with 'alloca' exists until the containing _function_ returns.  The space
+for a variable-length array is deallocated as soon as the array name's
+scope ends.  (If you use both variable-length arrays and 'alloca' in the
+same function, deallocation of a variable-length array also deallocates
+anything more recently allocated with 'alloca'.)
+
+ You can also use variable-length arrays as arguments to functions:
+
+     struct entry
+     tester (int len, char data[len][len])
+     {
+       /* ... */
+     }
+
+ The length of an array is computed once when the storage is allocated
+and is remembered for the scope of the array in case you access it with
+'sizeof'.
+
+ If you want to pass the array first and the length afterward, you can
+use a forward declaration in the parameter list--another GNU extension.
+
+     struct entry
+     tester (int len; char data[len][len], int len)
+     {
+       /* ... */
+     }
+
+ The 'int len' before the semicolon is a "parameter forward
+declaration", and it serves the purpose of making the name 'len' known
+when the declaration of 'data' is parsed.
+
+ You can write any number of such parameter forward declarations in the
+parameter list.  They can be separated by commas or semicolons, but the
+last one must end with a semicolon, which is followed by the "real"
+parameter declarations.  Each forward declaration must match a "real"
+declaration in parameter name and data type.  ISO C99 does not support
+parameter forward declarations.
+
+
+File: gcc.info,  Node: Variadic Macros,  Next: Escaped Newlines,  Prev: Variable Length,  Up: C Extensions
+
+6.20 Macros with a Variable Number of Arguments.
+================================================
+
+In the ISO C standard of 1999, a macro can be declared to accept a
+variable number of arguments much as a function can.  The syntax for
+defining the macro is similar to that of a function.  Here is an
+example:
+
+     #define debug(format, ...) fprintf (stderr, format, __VA_ARGS__)
+
+Here '...' is a "variable argument".  In the invocation of such a macro,
+it represents the zero or more tokens until the closing parenthesis that
+ends the invocation, including any commas.  This set of tokens replaces
+the identifier '__VA_ARGS__' in the macro body wherever it appears.  See
+the CPP manual for more information.
+
+ GCC has long supported variadic macros, and used a different syntax
+that allowed you to give a name to the variable arguments just like any
+other argument.  Here is an example:
+
+     #define debug(format, args...) fprintf (stderr, format, args)
+
+This is in all ways equivalent to the ISO C example above, but arguably
+more readable and descriptive.
+
+ GNU CPP has two further variadic macro extensions, and permits them to
+be used with either of the above forms of macro definition.
+
+ In standard C, you are not allowed to leave the variable argument out
+entirely; but you are allowed to pass an empty argument.  For example,
+this invocation is invalid in ISO C, because there is no comma after the
+string:
+
+     debug ("A message")
+
+ GNU CPP permits you to completely omit the variable arguments in this
+way.  In the above examples, the compiler would complain, though since
+the expansion of the macro still has the extra comma after the format
+string.
+
+ To help solve this problem, CPP behaves specially for variable
+arguments used with the token paste operator, '##'.  If instead you
+write
+
+     #define debug(format, ...) fprintf (stderr, format, ## __VA_ARGS__)
+
+and if the variable arguments are omitted or empty, the '##' operator
+causes the preprocessor to remove the comma before it.  If you do
+provide some variable arguments in your macro invocation, GNU CPP does
+not complain about the paste operation and instead places the variable
+arguments after the comma.  Just like any other pasted macro argument,
+these arguments are not macro expanded.
+
+
+File: gcc.info,  Node: Escaped Newlines,  Next: Subscripting,  Prev: Variadic Macros,  Up: C Extensions
+
+6.21 Slightly Looser Rules for Escaped Newlines
+===============================================
+
+Recently, the preprocessor has relaxed its treatment of escaped
+newlines.  Previously, the newline had to immediately follow a
+backslash.  The current implementation allows whitespace in the form of
+spaces, horizontal and vertical tabs, and form feeds between the
+backslash and the subsequent newline.  The preprocessor issues a
+warning, but treats it as a valid escaped newline and combines the two
+lines to form a single logical line.  This works within comments and
+tokens, as well as between tokens.  Comments are _not_ treated as
+whitespace for the purposes of this relaxation, since they have not yet
+been replaced with spaces.
+
+
+File: gcc.info,  Node: Subscripting,  Next: Pointer Arith,  Prev: Escaped Newlines,  Up: C Extensions
+
+6.22 Non-Lvalue Arrays May Have Subscripts
+==========================================
+
+In ISO C99, arrays that are not lvalues still decay to pointers, and may
+be subscripted, although they may not be modified or used after the next
+sequence point and the unary '&' operator may not be applied to them.
+As an extension, GNU C allows such arrays to be subscripted in C90 mode,
+though otherwise they do not decay to pointers outside C99 mode.  For
+example, this is valid in GNU C though not valid in C90:
+
+     struct foo {int a[4];};
+
+     struct foo f();
+
+     bar (int index)
+     {
+       return f().a[index];
+     }
+
+
+File: gcc.info,  Node: Pointer Arith,  Next: Initializers,  Prev: Subscripting,  Up: C Extensions
+
+6.23 Arithmetic on 'void'- and Function-Pointers
+================================================
+
+In GNU C, addition and subtraction operations are supported on pointers
+to 'void' and on pointers to functions.  This is done by treating the
+size of a 'void' or of a function as 1.
+
+ A consequence of this is that 'sizeof' is also allowed on 'void' and on
+function types, and returns 1.
+
+ The option '-Wpointer-arith' requests a warning if these extensions are
+used.
+
+
+File: gcc.info,  Node: Initializers,  Next: Compound Literals,  Prev: Pointer Arith,  Up: C Extensions
+
+6.24 Non-Constant Initializers
+==============================
+
+As in standard C++ and ISO C99, the elements of an aggregate initializer
+for an automatic variable are not required to be constant expressions in
+GNU C.  Here is an example of an initializer with run-time varying
+elements:
+
+     foo (float f, float g)
+     {
+       float beat_freqs[2] = { f-g, f+g };
+       /* ... */
+     }
+
+
+File: gcc.info,  Node: Compound Literals,  Next: Designated Inits,  Prev: Initializers,  Up: C Extensions
+
+6.25 Compound Literals
+======================
+
+ISO C99 supports compound literals.  A compound literal looks like a
+cast containing an initializer.  Its value is an object of the type
+specified in the cast, containing the elements specified in the
+initializer; it is an lvalue.  As an extension, GCC supports compound
+literals in C90 mode and in C++, though the semantics are somewhat
+different in C++.
+
+ Usually, the specified type is a structure.  Assume that 'struct foo'
+and 'structure' are declared as shown:
+
+     struct foo {int a; char b[2];} structure;
+
+Here is an example of constructing a 'struct foo' with a compound
+literal:
+
+     structure = ((struct foo) {x + y, 'a', 0});
+
+This is equivalent to writing the following:
+
+     {
+       struct foo temp = {x + y, 'a', 0};
+       structure = temp;
+     }
+
+ You can also construct an array, though this is dangerous in C++, as
+explained below.  If all the elements of the compound literal are (made
+up of) simple constant expressions, suitable for use in initializers of
+objects of static storage duration, then the compound literal can be
+coerced to a pointer to its first element and used in such an
+initializer, as shown here:
+
+     char **foo = (char *[]) { "x", "y", "z" };
+
+ Compound literals for scalar types and union types are also allowed,
+but then the compound literal is equivalent to a cast.
+
+ As a GNU extension, GCC allows initialization of objects with static
+storage duration by compound literals (which is not possible in ISO C99,
+because the initializer is not a constant).  It is handled as if the
+object is initialized only with the bracket enclosed list if the types
+of the compound literal and the object match.  The initializer list of
+the compound literal must be constant.  If the object being initialized
+has array type of unknown size, the size is determined by compound
+literal size.
+
+     static struct foo x = (struct foo) {1, 'a', 'b'};
+     static int y[] = (int []) {1, 2, 3};
+     static int z[] = (int [3]) {1};
+
+The above lines are equivalent to the following:
+     static struct foo x = {1, 'a', 'b'};
+     static int y[] = {1, 2, 3};
+     static int z[] = {1, 0, 0};
+
+ In C, a compound literal designates an unnamed object with static or
+automatic storage duration.  In C++, a compound literal designates a
+temporary object, which only lives until the end of its full-expression.
+As a result, well-defined C code that takes the address of a subobject
+of a compound literal can be undefined in C++.  For instance, if the
+array compound literal example above appeared inside a function, any
+subsequent use of 'foo' in C++ has undefined behavior because the
+lifetime of the array ends after the declaration of 'foo'.  As a result,
+the C++ compiler now rejects the conversion of a temporary array to a
+pointer.
+
+ As an optimization, the C++ compiler sometimes gives array compound
+literals longer lifetimes: when the array either appears outside a
+function or has const-qualified type.  If 'foo' and its initializer had
+elements of 'char *const' type rather than 'char *', or if 'foo' were a
+global variable, the array would have static storage duration.  But it
+is probably safest just to avoid the use of array compound literals in
+code compiled as C++.
+
+
+File: gcc.info,  Node: Designated Inits,  Next: Case Ranges,  Prev: Compound Literals,  Up: C Extensions
+
+6.26 Designated Initializers
+============================
+
+Standard C90 requires the elements of an initializer to appear in a
+fixed order, the same as the order of the elements in the array or
+structure being initialized.
+
+ In ISO C99 you can give the elements in any order, specifying the array
+indices or structure field names they apply to, and GNU C allows this as
+an extension in C90 mode as well.  This extension is not implemented in
+GNU C++.
+
+ To specify an array index, write '[INDEX] =' before the element value.
+For example,
+
+     int a[6] = { [4] = 29, [2] = 15 };
+
+is equivalent to
+
+     int a[6] = { 0, 0, 15, 0, 29, 0 };
+
+The index values must be constant expressions, even if the array being
+initialized is automatic.
+
+ An alternative syntax for this that has been obsolete since GCC 2.5 but
+GCC still accepts is to write '[INDEX]' before the element value, with
+no '='.
+
+ To initialize a range of elements to the same value, write '[FIRST ...
+LAST] = VALUE'.  This is a GNU extension.  For example,
+
+     int widths[] = { [0 ... 9] = 1, [10 ... 99] = 2, [100] = 3 };
+
+If the value in it has side-effects, the side-effects happen only once,
+not for each initialized field by the range initializer.
+
+Note that the length of the array is the highest value specified plus
+one.
+
+ In a structure initializer, specify the name of a field to initialize
+with '.FIELDNAME =' before the element value.  For example, given the
+following structure,
+
+     struct point { int x, y; };
+
+the following initialization
+
+     struct point p = { .y = yvalue, .x = xvalue };
+
+is equivalent to
+
+     struct point p = { xvalue, yvalue };
+
+ Another syntax that has the same meaning, obsolete since GCC 2.5, is
+'FIELDNAME:', as shown here:
+
+     struct point p = { y: yvalue, x: xvalue };
+
+ Omitted field members are implicitly initialized the same as objects
+that have static storage duration.
+
+ The '[INDEX]' or '.FIELDNAME' is known as a "designator".  You can also
+use a designator (or the obsolete colon syntax) when initializing a
+union, to specify which element of the union should be used.  For
+example,
+
+     union foo { int i; double d; };
+
+     union foo f = { .d = 4 };
+
+converts 4 to a 'double' to store it in the union using the second
+element.  By contrast, casting 4 to type 'union foo' stores it into the
+union as the integer 'i', since it is an integer.  (*Note Cast to
+Union::.)
+
+ You can combine this technique of naming elements with ordinary C
+initialization of successive elements.  Each initializer element that
+does not have a designator applies to the next consecutive element of
+the array or structure.  For example,
+
+     int a[6] = { [1] = v1, v2, [4] = v4 };
+
+is equivalent to
+
+     int a[6] = { 0, v1, v2, 0, v4, 0 };
+
+ Labeling the elements of an array initializer is especially useful when
+the indices are characters or belong to an 'enum' type.  For example:
+
+     int whitespace[256]
+       = { [' '] = 1, ['\t'] = 1, ['\h'] = 1,
+           ['\f'] = 1, ['\n'] = 1, ['\r'] = 1 };
+
+ You can also write a series of '.FIELDNAME' and '[INDEX]' designators
+before an '=' to specify a nested subobject to initialize; the list is
+taken relative to the subobject corresponding to the closest surrounding
+brace pair.  For example, with the 'struct point' declaration above:
+
+     struct point ptarray[10] = { [2].y = yv2, [2].x = xv2, [0].x = xv0 };
+
+If the same field is initialized multiple times, it has the value from
+the last initialization.  If any such overridden initialization has
+side-effect, it is unspecified whether the side-effect happens or not.
+Currently, GCC discards them and issues a warning.
+
+
+File: gcc.info,  Node: Case Ranges,  Next: Cast to Union,  Prev: Designated Inits,  Up: C Extensions
+
+6.27 Case Ranges
+================
+
+You can specify a range of consecutive values in a single 'case' label,
+like this:
+
+     case LOW ... HIGH:
+
+This has the same effect as the proper number of individual 'case'
+labels, one for each integer value from LOW to HIGH, inclusive.
+
+ This feature is especially useful for ranges of ASCII character codes:
+
+     case 'A' ... 'Z':
+
+ *Be careful:* Write spaces around the '...', for otherwise it may be
+parsed wrong when you use it with integer values.  For example, write
+this:
+
+     case 1 ... 5:
+
+rather than this:
+
+     case 1...5:
+
+
+File: gcc.info,  Node: Cast to Union,  Next: Mixed Declarations,  Prev: Case Ranges,  Up: C Extensions
+
+6.28 Cast to a Union Type
+=========================
+
+A cast to union type is similar to other casts, except that the type
+specified is a union type.  You can specify the type either with 'union
+TAG' or with a typedef name.  A cast to union is actually a constructor,
+not a cast, and hence does not yield an lvalue like normal casts.
+(*Note Compound Literals::.)
+
+ The types that may be cast to the union type are those of the members
+of the union.  Thus, given the following union and variables:
+
+     union foo { int i; double d; };
+     int x;
+     double y;
+
+both 'x' and 'y' can be cast to type 'union foo'.
+
+ Using the cast as the right-hand side of an assignment to a variable of
+union type is equivalent to storing in a member of the union:
+
+     union foo u;
+     /* ... */
+     u = (union foo) x  ==  u.i = x
+     u = (union foo) y  ==  u.d = y
+
+ You can also use the union cast as a function argument:
+
+     void hack (union foo);
+     /* ... */
+     hack ((union foo) x);
+
+
+File: gcc.info,  Node: Mixed Declarations,  Next: Function Attributes,  Prev: Cast to Union,  Up: C Extensions
+
+6.29 Mixed Declarations and Code
+================================
+
+ISO C99 and ISO C++ allow declarations and code to be freely mixed
+within compound statements.  As an extension, GNU C also allows this in
+C90 mode.  For example, you could do:
+
+     int i;
+     /* ... */
+     i++;
+     int j = i + 2;
+
+ Each identifier is visible from where it is declared until the end of
+the enclosing block.
+
+
+File: gcc.info,  Node: Function Attributes,  Next: Attribute Syntax,  Prev: Mixed Declarations,  Up: C Extensions
+
+6.30 Declaring Attributes of Functions
+======================================
+
+In GNU C, you declare certain things about functions called in your
+program which help the compiler optimize function calls and check your
+code more carefully.
+
+ The keyword '__attribute__' allows you to specify special attributes
+when making a declaration.  This keyword is followed by an attribute
+specification inside double parentheses.  The following attributes are
+currently defined for functions on all targets: 'aligned', 'alloc_size',
+'alloc_align', 'assume_aligned', 'noreturn', 'returns_twice',
+'noinline', 'noclone', 'always_inline', 'flatten', 'pure', 'const',
+'nothrow', 'sentinel', 'format', 'format_arg', 'no_instrument_function',
+'no_split_stack', 'section', 'constructor', 'destructor', 'used',
+'unused', 'deprecated', 'weak', 'malloc', 'alias', 'ifunc',
+'warn_unused_result', 'nonnull', 'returns_nonnull', 'gnu_inline',
+'externally_visible', 'hot', 'cold', 'artificial',
+'no_sanitize_address', 'no_address_safety_analysis',
+'no_sanitize_undefined', 'error' and 'warning'.  Several other
+attributes are defined for functions on particular target systems.
+Other attributes, including 'section' are supported for variables
+declarations (*note Variable Attributes::) and for types (*note Type
+Attributes::).
+
+ GCC plugins may provide their own attributes.
+
+ You may also specify attributes with '__' preceding and following each
+keyword.  This allows you to use them in header files without being
+concerned about a possible macro of the same name.  For example, you may
+use '__noreturn__' instead of 'noreturn'.
+
+ *Note Attribute Syntax::, for details of the exact syntax for using
+attributes.
+
+'alias ("TARGET")'
+     The 'alias' attribute causes the declaration to be emitted as an
+     alias for another symbol, which must be specified.  For instance,
+
+          void __f () { /* Do something. */; }
+          void f () __attribute__ ((weak, alias ("__f")));
+
+     defines 'f' to be a weak alias for '__f'.  In C++, the mangled name
+     for the target must be used.  It is an error if '__f' is not
+     defined in the same translation unit.
+
+     Not all target machines support this attribute.
+
+'aligned (ALIGNMENT)'
+     This attribute specifies a minimum alignment for the function,
+     measured in bytes.
+
+     You cannot use this attribute to decrease the alignment of a
+     function, only to increase it.  However, when you explicitly
+     specify a function alignment this overrides the effect of the
+     '-falign-functions' (*note Optimize Options::) option for this
+     function.
+
+     Note that the effectiveness of 'aligned' attributes may be limited
+     by inherent limitations in your linker.  On many systems, the
+     linker is only able to arrange for functions to be aligned up to a
+     certain maximum alignment.  (For some linkers, the maximum
+     supported alignment may be very very small.)  See your linker
+     documentation for further information.
+
+     The 'aligned' attribute can also be used for variables and fields
+     (*note Variable Attributes::.)
+
+'alloc_size'
+     The 'alloc_size' attribute is used to tell the compiler that the
+     function return value points to memory, where the size is given by
+     one or two of the functions parameters.  GCC uses this information
+     to improve the correctness of '__builtin_object_size'.
+
+     The function parameter(s) denoting the allocated size are specified
+     by one or two integer arguments supplied to the attribute.  The
+     allocated size is either the value of the single function argument
+     specified or the product of the two function arguments specified.
+     Argument numbering starts at one.
+
+     For instance,
+
+          void* my_calloc(size_t, size_t) __attribute__((alloc_size(1,2)))
+          void* my_realloc(void*, size_t) __attribute__((alloc_size(2)))
+
+     declares that 'my_calloc' returns memory of the size given by the
+     product of parameter 1 and 2 and that 'my_realloc' returns memory
+     of the size given by parameter 2.
+
+'alloc_align'
+     The 'alloc_align' attribute is used to tell the compiler that the
+     function return value points to memory, where the returned pointer
+     minimum alignment is given by one of the functions parameters.  GCC
+     uses this information to improve pointer alignment analysis.
+
+     The function parameter denoting the allocated alignment is
+     specified by one integer argument, whose number is the argument of
+     the attribute.  Argument numbering starts at one.
+
+     For instance,
+
+          void* my_memalign(size_t, size_t) __attribute__((alloc_align(1)))
+
+     declares that 'my_memalign' returns memory with minimum alignment
+     given by parameter 1.
+
+'assume_aligned'
+     The 'assume_aligned' attribute is used to tell the compiler that
+     the function return value points to memory, where the returned
+     pointer minimum alignment is given by the first argument.  If the
+     attribute has two arguments, the second argument is misalignment
+     offset.
+
+     For instance
+
+          void* my_alloc1(size_t) __attribute__((assume_aligned(16)))
+          void* my_alloc2(size_t) __attribute__((assume_aligned(32, 8)))
+
+     declares that 'my_alloc1' returns 16-byte aligned pointer and that
+     'my_alloc2' returns a pointer whose value modulo 32 is equal to 8.
+
+'always_inline'
+     Generally, functions are not inlined unless optimization is
+     specified.  For functions declared inline, this attribute inlines
+     the function even if no optimization level is specified.
+
+'gnu_inline'
+     This attribute should be used with a function that is also declared
+     with the 'inline' keyword.  It directs GCC to treat the function as
+     if it were defined in gnu90 mode even when compiling in C99 or
+     gnu99 mode.
+
+     If the function is declared 'extern', then this definition of the
+     function is used only for inlining.  In no case is the function
+     compiled as a standalone function, not even if you take its address
+     explicitly.  Such an address becomes an external reference, as if
+     you had only declared the function, and had not defined it.  This
+     has almost the effect of a macro.  The way to use this is to put a
+     function definition in a header file with this attribute, and put
+     another copy of the function, without 'extern', in a library file.
+     The definition in the header file causes most calls to the function
+     to be inlined.  If any uses of the function remain, they refer to
+     the single copy in the library.  Note that the two definitions of
+     the functions need not be precisely the same, although if they do
+     not have the same effect your program may behave oddly.
+
+     In C, if the function is neither 'extern' nor 'static', then the
+     function is compiled as a standalone function, as well as being
+     inlined where possible.
+
+     This is how GCC traditionally handled functions declared 'inline'.
+     Since ISO C99 specifies a different semantics for 'inline', this
+     function attribute is provided as a transition measure and as a
+     useful feature in its own right.  This attribute is available in
+     GCC 4.1.3 and later.  It is available if either of the preprocessor
+     macros '__GNUC_GNU_INLINE__' or '__GNUC_STDC_INLINE__' are defined.
+     *Note An Inline Function is As Fast As a Macro: Inline.
+
+     In C++, this attribute does not depend on 'extern' in any way, but
+     it still requires the 'inline' keyword to enable its special
+     behavior.
+
+'artificial'
+     This attribute is useful for small inline wrappers that if possible
+     should appear during debugging as a unit.  Depending on the debug
+     info format it either means marking the function as artificial or
+     using the caller location for all instructions within the inlined
+     body.
+
+'bank_switch'
+     When added to an interrupt handler with the M32C port, causes the
+     prologue and epilogue to use bank switching to preserve the
+     registers rather than saving them on the stack.
+
+'flatten'
+     Generally, inlining into a function is limited.  For a function
+     marked with this attribute, every call inside this function is
+     inlined, if possible.  Whether the function itself is considered
+     for inlining depends on its size and the current inlining
+     parameters.
+
+'error ("MESSAGE")'
+     If this attribute is used on a function declaration and a call to
+     such a function is not eliminated through dead code elimination or
+     other optimizations, an error that includes MESSAGE is diagnosed.
+     This is useful for compile-time checking, especially together with
+     '__builtin_constant_p' and inline functions where checking the
+     inline function arguments is not possible through 'extern char
+     [(condition) ? 1 : -1];' tricks.  While it is possible to leave the
+     function undefined and thus invoke a link failure, when using this
+     attribute the problem is diagnosed earlier and with exact location
+     of the call even in presence of inline functions or when not
+     emitting debugging information.
+
+'warning ("MESSAGE")'
+     If this attribute is used on a function declaration and a call to
+     such a function is not eliminated through dead code elimination or
+     other optimizations, a warning that includes MESSAGE is diagnosed.
+     This is useful for compile-time checking, especially together with
+     '__builtin_constant_p' and inline functions.  While it is possible
+     to define the function with a message in '.gnu.warning*' section,
+     when using this attribute the problem is diagnosed earlier and with
+     exact location of the call even in presence of inline functions or
+     when not emitting debugging information.
+
+'cdecl'
+     On the Intel 386, the 'cdecl' attribute causes the compiler to
+     assume that the calling function pops off the stack space used to
+     pass arguments.  This is useful to override the effects of the
+     '-mrtd' switch.
+
+'const'
+     Many functions do not examine any values except their arguments,
+     and have no effects except the return value.  Basically this is
+     just slightly more strict class than the 'pure' attribute below,
+     since function is not allowed to read global memory.
+
+     Note that a function that has pointer arguments and examines the
+     data pointed to must _not_ be declared 'const'.  Likewise, a
+     function that calls a non-'const' function usually must not be
+     'const'.  It does not make sense for a 'const' function to return
+     'void'.
+
+     The attribute 'const' is not implemented in GCC versions earlier
+     than 2.5.  An alternative way to declare that a function has no
+     side effects, which works in the current version and in some older
+     versions, is as follows:
+
+          typedef int intfn ();
+
+          extern const intfn square;
+
+     This approach does not work in GNU C++ from 2.6.0 on, since the
+     language specifies that the 'const' must be attached to the return
+     value.
+
+'constructor'
+'destructor'
+'constructor (PRIORITY)'
+'destructor (PRIORITY)'
+     The 'constructor' attribute causes the function to be called
+     automatically before execution enters 'main ()'.  Similarly, the
+     'destructor' attribute causes the function to be called
+     automatically after 'main ()' completes or 'exit ()' is called.
+     Functions with these attributes are useful for initializing data
+     that is used implicitly during the execution of the program.
+
+     You may provide an optional integer priority to control the order
+     in which constructor and destructor functions are run.  A
+     constructor with a smaller priority number runs before a
+     constructor with a larger priority number; the opposite
+     relationship holds for destructors.  So, if you have a constructor
+     that allocates a resource and a destructor that deallocates the
+     same resource, both functions typically have the same priority.
+     The priorities for constructor and destructor functions are the
+     same as those specified for namespace-scope C++ objects (*note C++
+     Attributes::).
+
+     These attributes are not currently implemented for Objective-C.
+
+'deprecated'
+'deprecated (MSG)'
+     The 'deprecated' attribute results in a warning if the function is
+     used anywhere in the source file.  This is useful when identifying
+     functions that are expected to be removed in a future version of a
+     program.  The warning also includes the location of the declaration
+     of the deprecated function, to enable users to easily find further
+     information about why the function is deprecated, or what they
+     should do instead.  Note that the warnings only occurs for uses:
+
+          int old_fn () __attribute__ ((deprecated));
+          int old_fn ();
+          int (*fn_ptr)() = old_fn;
+
+     results in a warning on line 3 but not line 2.  The optional MSG
+     argument, which must be a string, is printed in the warning if
+     present.
+
+     The 'deprecated' attribute can also be used for variables and types
+     (*note Variable Attributes::, *note Type Attributes::.)
+
+'disinterrupt'
+     On Epiphany and MeP targets, this attribute causes the compiler to
+     emit instructions to disable interrupts for the duration of the
+     given function.
+
+'dllexport'
+     On Microsoft Windows targets and Symbian OS targets the 'dllexport'
+     attribute causes the compiler to provide a global pointer to a
+     pointer in a DLL, so that it can be referenced with the 'dllimport'
+     attribute.  On Microsoft Windows targets, the pointer name is
+     formed by combining '_imp__' and the function or variable name.
+
+     You can use '__declspec(dllexport)' as a synonym for '__attribute__
+     ((dllexport))' for compatibility with other compilers.
+
+     On systems that support the 'visibility' attribute, this attribute
+     also implies "default" visibility.  It is an error to explicitly
+     specify any other visibility.
+
+     In previous versions of GCC, the 'dllexport' attribute was ignored
+     for inlined functions, unless the '-fkeep-inline-functions' flag
+     had been used.  The default behavior now is to emit all dllexported
+     inline functions; however, this can cause object file-size bloat,
+     in which case the old behavior can be restored by using
+     '-fno-keep-inline-dllexport'.
+
+     The attribute is also ignored for undefined symbols.
+
+     When applied to C++ classes, the attribute marks defined
+     non-inlined member functions and static data members as exports.
+     Static consts initialized in-class are not marked unless they are
+     also defined out-of-class.
+
+     For Microsoft Windows targets there are alternative methods for
+     including the symbol in the DLL's export table such as using a
+     '.def' file with an 'EXPORTS' section or, with GNU ld, using the
+     '--export-all' linker flag.
+
+'dllimport'
+     On Microsoft Windows and Symbian OS targets, the 'dllimport'
+     attribute causes the compiler to reference a function or variable
+     via a global pointer to a pointer that is set up by the DLL
+     exporting the symbol.  The attribute implies 'extern'.  On
+     Microsoft Windows targets, the pointer name is formed by combining
+     '_imp__' and the function or variable name.
+
+     You can use '__declspec(dllimport)' as a synonym for '__attribute__
+     ((dllimport))' for compatibility with other compilers.
+
+     On systems that support the 'visibility' attribute, this attribute
+     also implies "default" visibility.  It is an error to explicitly
+     specify any other visibility.
+
+     Currently, the attribute is ignored for inlined functions.  If the
+     attribute is applied to a symbol _definition_, an error is
+     reported.  If a symbol previously declared 'dllimport' is later
+     defined, the attribute is ignored in subsequent references, and a
+     warning is emitted.  The attribute is also overridden by a
+     subsequent declaration as 'dllexport'.
+
+     When applied to C++ classes, the attribute marks non-inlined member
+     functions and static data members as imports.  However, the
+     attribute is ignored for virtual methods to allow creation of
+     vtables using thunks.
+
+     On the SH Symbian OS target the 'dllimport' attribute also has
+     another affect--it can cause the vtable and run-time type
+     information for a class to be exported.  This happens when the
+     class has a dllimported constructor or a non-inline, non-pure
+     virtual function and, for either of those two conditions, the class
+     also has an inline constructor or destructor and has a key function
+     that is defined in the current translation unit.
+
+     For Microsoft Windows targets the use of the 'dllimport' attribute
+     on functions is not necessary, but provides a small performance
+     benefit by eliminating a thunk in the DLL.  The use of the
+     'dllimport' attribute on imported variables was required on older
+     versions of the GNU linker, but can now be avoided by passing the
+     '--enable-auto-import' switch to the GNU linker.  As with
+     functions, using the attribute for a variable eliminates a thunk in
+     the DLL.
+
+     One drawback to using this attribute is that a pointer to a
+     _variable_ marked as 'dllimport' cannot be used as a constant
+     address.  However, a pointer to a _function_ with the 'dllimport'
+     attribute can be used as a constant initializer; in this case, the
+     address of a stub function in the import lib is referenced.  On
+     Microsoft Windows targets, the attribute can be disabled for
+     functions by setting the '-mnop-fun-dllimport' flag.
+
+'eightbit_data'
+     Use this attribute on the H8/300, H8/300H, and H8S to indicate that
+     the specified variable should be placed into the eight-bit data
+     section.  The compiler generates more efficient code for certain
+     operations on data in the eight-bit data area.  Note the eight-bit
+     data area is limited to 256 bytes of data.
+
+     You must use GAS and GLD from GNU binutils version 2.7 or later for
+     this attribute to work correctly.
+
+'exception'
+     Use this attribute on the NDS32 target to indicate that the
+     specified function is an exception handler.  The compiler will
+     generate corresponding sections for use in an exception handler.
+
+'exception_handler'
+     Use this attribute on the Blackfin to indicate that the specified
+     function is an exception handler.  The compiler generates function
+     entry and exit sequences suitable for use in an exception handler
+     when this attribute is present.
+
+'externally_visible'
+     This attribute, attached to a global variable or function,
+     nullifies the effect of the '-fwhole-program' command-line option,
+     so the object remains visible outside the current compilation unit.
+
+     If '-fwhole-program' is used together with '-flto' and 'gold' is
+     used as the linker plugin, 'externally_visible' attributes are
+     automatically added to functions (not variable yet due to a current
+     'gold' issue) that are accessed outside of LTO objects according to
+     resolution file produced by 'gold'.  For other linkers that cannot
+     generate resolution file, explicit 'externally_visible' attributes
+     are still necessary.
+
+'far'
+     On 68HC11 and 68HC12 the 'far' attribute causes the compiler to use
+     a calling convention that takes care of switching memory banks when
+     entering and leaving a function.  This calling convention is also
+     the default when using the '-mlong-calls' option.
+
+     On 68HC12 the compiler uses the 'call' and 'rtc' instructions to
+     call and return from a function.
+
+     On 68HC11 the compiler generates a sequence of instructions to
+     invoke a board-specific routine to switch the memory bank and call
+     the real function.  The board-specific routine simulates a 'call'.
+     At the end of a function, it jumps to a board-specific routine
+     instead of using 'rts'.  The board-specific return routine
+     simulates the 'rtc'.
+
+     On MeP targets this causes the compiler to use a calling convention
+     that assumes the called function is too far away for the built-in
+     addressing modes.
+
+'fast_interrupt'
+     Use this attribute on the M32C and RX ports to indicate that the
+     specified function is a fast interrupt handler.  This is just like
+     the 'interrupt' attribute, except that 'freit' is used to return
+     instead of 'reit'.
+
+'fastcall'
+     On the Intel 386, the 'fastcall' attribute causes the compiler to
+     pass the first argument (if of integral type) in the register ECX
+     and the second argument (if of integral type) in the register EDX.
+     Subsequent and other typed arguments are passed on the stack.  The
+     called function pops the arguments off the stack.  If the number of
+     arguments is variable all arguments are pushed on the stack.
+
+'thiscall'
+     On the Intel 386, the 'thiscall' attribute causes the compiler to
+     pass the first argument (if of integral type) in the register ECX.
+     Subsequent and other typed arguments are passed on the stack.  The
+     called function pops the arguments off the stack.  If the number of
+     arguments is variable all arguments are pushed on the stack.  The
+     'thiscall' attribute is intended for C++ non-static member
+     functions.  As a GCC extension, this calling convention can be used
+     for C functions and for static member methods.
+
+'format (ARCHETYPE, STRING-INDEX, FIRST-TO-CHECK)'
+     The 'format' attribute specifies that a function takes 'printf',
+     'scanf', 'strftime' or 'strfmon' style arguments that should be
+     type-checked against a format string.  For example, the
+     declaration:
+
+          extern int
+          my_printf (void *my_object, const char *my_format, ...)
+                __attribute__ ((format (printf, 2, 3)));
+
+     causes the compiler to check the arguments in calls to 'my_printf'
+     for consistency with the 'printf' style format string argument
+     'my_format'.
+
+     The parameter ARCHETYPE determines how the format string is
+     interpreted, and should be 'printf', 'scanf', 'strftime',
+     'gnu_printf', 'gnu_scanf', 'gnu_strftime' or 'strfmon'.  (You can
+     also use '__printf__', '__scanf__', '__strftime__' or
+     '__strfmon__'.)  On MinGW targets, 'ms_printf', 'ms_scanf', and
+     'ms_strftime' are also present.  ARCHETYPE values such as 'printf'
+     refer to the formats accepted by the system's C runtime library,
+     while values prefixed with 'gnu_' always refer to the formats
+     accepted by the GNU C Library.  On Microsoft Windows targets,
+     values prefixed with 'ms_' refer to the formats accepted by the
+     'msvcrt.dll' library.  The parameter STRING-INDEX specifies which
+     argument is the format string argument (starting from 1), while
+     FIRST-TO-CHECK is the number of the first argument to check against
+     the format string.  For functions where the arguments are not
+     available to be checked (such as 'vprintf'), specify the third
+     parameter as zero.  In this case the compiler only checks the
+     format string for consistency.  For 'strftime' formats, the third
+     parameter is required to be zero.  Since non-static C++ methods
+     have an implicit 'this' argument, the arguments of such methods
+     should be counted from two, not one, when giving values for
+     STRING-INDEX and FIRST-TO-CHECK.
+
+     In the example above, the format string ('my_format') is the second
+     argument of the function 'my_print', and the arguments to check
+     start with the third argument, so the correct parameters for the
+     format attribute are 2 and 3.
+
+     The 'format' attribute allows you to identify your own functions
+     that take format strings as arguments, so that GCC can check the
+     calls to these functions for errors.  The compiler always (unless
+     '-ffreestanding' or '-fno-builtin' is used) checks formats for the
+     standard library functions 'printf', 'fprintf', 'sprintf', 'scanf',
+     'fscanf', 'sscanf', 'strftime', 'vprintf', 'vfprintf' and
+     'vsprintf' whenever such warnings are requested (using '-Wformat'),
+     so there is no need to modify the header file 'stdio.h'.  In C99
+     mode, the functions 'snprintf', 'vsnprintf', 'vscanf', 'vfscanf'
+     and 'vsscanf' are also checked.  Except in strictly conforming C
+     standard modes, the X/Open function 'strfmon' is also checked as
+     are 'printf_unlocked' and 'fprintf_unlocked'.  *Note Options
+     Controlling C Dialect: C Dialect Options.
+
+     For Objective-C dialects, 'NSString' (or '__NSString__') is
+     recognized in the same context.  Declarations including these
+     format attributes are parsed for correct syntax, however the result
+     of checking of such format strings is not yet defined, and is not
+     carried out by this version of the compiler.
+
+     The target may also provide additional types of format checks.
+     *Note Format Checks Specific to Particular Target Machines: Target
+     Format Checks.
+
+'format_arg (STRING-INDEX)'
+     The 'format_arg' attribute specifies that a function takes a format
+     string for a 'printf', 'scanf', 'strftime' or 'strfmon' style
+     function and modifies it (for example, to translate it into another
+     language), so the result can be passed to a 'printf', 'scanf',
+     'strftime' or 'strfmon' style function (with the remaining
+     arguments to the format function the same as they would have been
+     for the unmodified string).  For example, the declaration:
+
+          extern char *
+          my_dgettext (char *my_domain, const char *my_format)
+                __attribute__ ((format_arg (2)));
+
+     causes the compiler to check the arguments in calls to a 'printf',
+     'scanf', 'strftime' or 'strfmon' type function, whose format string
+     argument is a call to the 'my_dgettext' function, for consistency
+     with the format string argument 'my_format'.  If the 'format_arg'
+     attribute had not been specified, all the compiler could tell in
+     such calls to format functions would be that the format string
+     argument is not constant; this would generate a warning when
+     '-Wformat-nonliteral' is used, but the calls could not be checked
+     without the attribute.
+
+     The parameter STRING-INDEX specifies which argument is the format
+     string argument (starting from one).  Since non-static C++ methods
+     have an implicit 'this' argument, the arguments of such methods
+     should be counted from two.
+
+     The 'format_arg' attribute allows you to identify your own
+     functions that modify format strings, so that GCC can check the
+     calls to 'printf', 'scanf', 'strftime' or 'strfmon' type function
+     whose operands are a call to one of your own function.  The
+     compiler always treats 'gettext', 'dgettext', and 'dcgettext' in
+     this manner except when strict ISO C support is requested by
+     '-ansi' or an appropriate '-std' option, or '-ffreestanding' or
+     '-fno-builtin' is used.  *Note Options Controlling C Dialect: C
+     Dialect Options.
+
+     For Objective-C dialects, the 'format-arg' attribute may refer to
+     an 'NSString' reference for compatibility with the 'format'
+     attribute above.
+
+     The target may also allow additional types in 'format-arg'
+     attributes.  *Note Format Checks Specific to Particular Target
+     Machines: Target Format Checks.
+
+'function_vector'
+     Use this attribute on the H8/300, H8/300H, and H8S to indicate that
+     the specified function should be called through the function
+     vector.  Calling a function through the function vector reduces
+     code size, however; the function vector has a limited size (maximum
+     128 entries on the H8/300 and 64 entries on the H8/300H and H8S)
+     and shares space with the interrupt vector.
+
+     On SH2A targets, this attribute declares a function to be called
+     using the TBR relative addressing mode.  The argument to this
+     attribute is the entry number of the same function in a vector
+     table containing all the TBR relative addressable functions.  For
+     correct operation the TBR must be setup accordingly to point to the
+     start of the vector table before any functions with this attribute
+     are invoked.  Usually a good place to do the initialization is the
+     startup routine.  The TBR relative vector table can have at max 256
+     function entries.  The jumps to these functions are generated using
+     a SH2A specific, non delayed branch instruction JSR/N @(disp8,TBR).
+     You must use GAS and GLD from GNU binutils version 2.7 or later for
+     this attribute to work correctly.
+
+     Please refer the example of M16C target, to see the use of this
+     attribute while declaring a function,
+
+     In an application, for a function being called once, this attribute
+     saves at least 8 bytes of code; and if other successive calls are
+     being made to the same function, it saves 2 bytes of code per each
+     of these calls.
+
+     On M16C/M32C targets, the 'function_vector' attribute declares a
+     special page subroutine call function.  Use of this attribute
+     reduces the code size by 2 bytes for each call generated to the
+     subroutine.  The argument to the attribute is the vector number
+     entry from the special page vector table which contains the 16
+     low-order bits of the subroutine's entry address.  Each vector
+     table has special page number (18 to 255) that is used in 'jsrs'
+     instructions.  Jump addresses of the routines are generated by
+     adding 0x0F0000 (in case of M16C targets) or 0xFF0000 (in case of
+     M32C targets), to the 2-byte addresses set in the vector table.
+     Therefore you need to ensure that all the special page vector
+     routines should get mapped within the address range 0x0F0000 to
+     0x0FFFFF (for M16C) and 0xFF0000 to 0xFFFFFF (for M32C).
+
+     In the following example 2 bytes are saved for each call to
+     function 'foo'.
+
+          void foo (void) __attribute__((function_vector(0x18)));
+          void foo (void)
+          {
+          }
+
+          void bar (void)
+          {
+              foo();
+          }
+
+     If functions are defined in one file and are called in another
+     file, then be sure to write this declaration in both files.
+
+     This attribute is ignored for R8C target.
+
+'ifunc ("RESOLVER")'
+     The 'ifunc' attribute is used to mark a function as an indirect
+     function using the STT_GNU_IFUNC symbol type extension to the ELF
+     standard.  This allows the resolution of the symbol value to be
+     determined dynamically at load time, and an optimized version of
+     the routine can be selected for the particular processor or other
+     system characteristics determined then.  To use this attribute,
+     first define the implementation functions available, and a resolver
+     function that returns a pointer to the selected implementation
+     function.  The implementation functions' declarations must match
+     the API of the function being implemented, the resolver's
+     declaration is be a function returning pointer to void function
+     returning void:
+
+          void *my_memcpy (void *dst, const void *src, size_t len)
+          {
+            ...
+          }
+
+          static void (*resolve_memcpy (void)) (void)
+          {
+            return my_memcpy; // we'll just always select this routine
+          }
+
+     The exported header file declaring the function the user calls
+     would contain:
+
+          extern void *memcpy (void *, const void *, size_t);
+
+     allowing the user to call this as a regular function, unaware of
+     the implementation.  Finally, the indirect function needs to be
+     defined in the same translation unit as the resolver function:
+
+          void *memcpy (void *, const void *, size_t)
+               __attribute__ ((ifunc ("resolve_memcpy")));
+
+     Indirect functions cannot be weak, and require a recent binutils
+     (at least version 2.20.1), and GNU C library (at least version
+     2.11.1).
+
+'interrupt'
+     Use this attribute on the ARC, ARM, AVR, CR16, Epiphany, M32C,
+     M32R/D, m68k, MeP, MIPS, MSP430, RL78, RX and Xstormy16 ports to
+     indicate that the specified function is an interrupt handler.  The
+     compiler generates function entry and exit sequences suitable for
+     use in an interrupt handler when this attribute is present.  With
+     Epiphany targets it may also generate a special section with code
+     to initialize the interrupt vector table.
+
+     Note, interrupt handlers for the Blackfin, H8/300, H8/300H, H8S,
+     MicroBlaze, and SH processors can be specified via the
+     'interrupt_handler' attribute.
+
+     Note, on the ARC, you must specify the kind of interrupt to be
+     handled in a parameter to the interrupt attribute like this:
+
+          void f () __attribute__ ((interrupt ("ilink1")));
+
+     Permissible values for this parameter are: 'ilink1' and 'ilink2'.
+
+     Note, on the AVR, the hardware globally disables interrupts when an
+     interrupt is executed.  The first instruction of an interrupt
+     handler declared with this attribute is a 'SEI' instruction to
+     re-enable interrupts.  See also the 'signal' function attribute
+     that does not insert a 'SEI' instruction.  If both 'signal' and
+     'interrupt' are specified for the same function, 'signal' is
+     silently ignored.
+
+     Note, for the ARM, you can specify the kind of interrupt to be
+     handled by adding an optional parameter to the interrupt attribute
+     like this:
+
+          void f () __attribute__ ((interrupt ("IRQ")));
+
+     Permissible values for this parameter are: 'IRQ', 'FIQ', 'SWI',
+     'ABORT' and 'UNDEF'.
+
+     On ARMv7-M the interrupt type is ignored, and the attribute means
+     the function may be called with a word-aligned stack pointer.
+
+     Note, for the MSP430 you can provide an argument to the interrupt
+     attribute which specifies a name or number.  If the argument is a
+     number it indicates the slot in the interrupt vector table (0 - 31)
+     to which this handler should be assigned.  If the argument is a
+     name it is treated as a symbolic name for the vector slot.  These
+     names should match up with appropriate entries in the linker
+     script.  By default the names 'watchdog' for vector 26, 'nmi' for
+     vector 30 and 'reset' for vector 31 are recognised.
+
+     You can also use the following function attributes to modify how
+     normal functions interact with interrupt functions:
+
+     'critical'
+          Critical functions disable interrupts upon entry and restore
+          the previous interrupt state upon exit.  Critical functions
+          cannot also have the 'naked' or 'reentrant' attributes.  They
+          can have the 'interrupt' attribute.
+
+     'reentrant'
+          Reentrant functions disable interrupts upon entry and enable
+          them upon exit.  Reentrant functions cannot also have the
+          'naked' or 'critical' attributes.  They can have the
+          'interrupt' attribute.
+
+     'wakeup'
+          This attribute only applies to interrupt functions.  It is
+          silently ignored if applied to a non-interrupt function.  A
+          wakeup interrupt function will rouse the processor from any
+          low-power state that it might be in when the function exits.
+
+     On Epiphany targets one or more optional parameters can be added
+     like this:
+
+          void __attribute__ ((interrupt ("dma0, dma1"))) universal_dma_handler ();
+
+     Permissible values for these parameters are: 'reset',
+     'software_exception', 'page_miss', 'timer0', 'timer1', 'message',
+     'dma0', 'dma1', 'wand' and 'swi'.  Multiple parameters indicate
+     that multiple entries in the interrupt vector table should be
+     initialized for this function, i.e. for each parameter NAME, a jump
+     to the function is emitted in the section ivt_entry_NAME.  The
+     parameter(s) may be omitted entirely, in which case no interrupt
+     vector table entry is provided.
+
+     Note, on Epiphany targets, interrupts are enabled inside the
+     function unless the 'disinterrupt' attribute is also specified.
+
+     On Epiphany targets, you can also use the following attribute to
+     modify the behavior of an interrupt handler:
+     'forwarder_section'
+          The interrupt handler may be in external memory which cannot
+          be reached by a branch instruction, so generate a local memory
+          trampoline to transfer control.  The single parameter
+          identifies the section where the trampoline is placed.
+
+     The following examples are all valid uses of these attributes on
+     Epiphany targets:
+          void __attribute__ ((interrupt)) universal_handler ();
+          void __attribute__ ((interrupt ("dma1"))) dma1_handler ();
+          void __attribute__ ((interrupt ("dma0, dma1"))) universal_dma_handler ();
+          void __attribute__ ((interrupt ("timer0"), disinterrupt))
+            fast_timer_handler ();
+          void __attribute__ ((interrupt ("dma0, dma1"), forwarder_section ("tramp")))
+            external_dma_handler ();
+
+     On MIPS targets, you can use the following attributes to modify the
+     behavior of an interrupt handler:
+     'use_shadow_register_set'
+          Assume that the handler uses a shadow register set, instead of
+          the main general-purpose registers.
+
+     'keep_interrupts_masked'
+          Keep interrupts masked for the whole function.  Without this
+          attribute, GCC tries to reenable interrupts for as much of the
+          function as it can.
+
+     'use_debug_exception_return'
+          Return using the 'deret' instruction.  Interrupt handlers that
+          don't have this attribute return using 'eret' instead.
+
+     You can use any combination of these attributes, as shown below:
+          void __attribute__ ((interrupt)) v0 ();
+          void __attribute__ ((interrupt, use_shadow_register_set)) v1 ();
+          void __attribute__ ((interrupt, keep_interrupts_masked)) v2 ();
+          void __attribute__ ((interrupt, use_debug_exception_return)) v3 ();
+          void __attribute__ ((interrupt, use_shadow_register_set,
+                               keep_interrupts_masked)) v4 ();
+          void __attribute__ ((interrupt, use_shadow_register_set,
+                               use_debug_exception_return)) v5 ();
+          void __attribute__ ((interrupt, keep_interrupts_masked,
+                               use_debug_exception_return)) v6 ();
+          void __attribute__ ((interrupt, use_shadow_register_set,
+                               keep_interrupts_masked,
+                               use_debug_exception_return)) v7 ();
+
+     On NDS32 target, this attribute is to indicate that the specified
+     function is an interrupt handler.  The compiler will generate
+     corresponding sections for use in an interrupt handler.  You can
+     use the following attributes to modify the behavior:
+     'nested'
+          This interrupt service routine is interruptible.
+     'not_nested'
+          This interrupt service routine is not interruptible.
+     'nested_ready'
+          This interrupt service routine is interruptible after
+          'PSW.GIE' (global interrupt enable) is set.  This allows
+          interrupt service routine to finish some short critical code
+          before enabling interrupts.
+     'save_all'
+          The system will help save all registers into stack before
+          entering interrupt handler.
+     'partial_save'
+          The system will help save caller registers into stack before
+          entering interrupt handler.
+
+     On RL78, use 'brk_interrupt' instead of 'interrupt' for handlers
+     intended to be used with the 'BRK' opcode (i.e. those that must end
+     with 'RETB' instead of 'RETI').
+
+'interrupt_handler'
+     Use this attribute on the Blackfin, m68k, H8/300, H8/300H, H8S, and
+     SH to indicate that the specified function is an interrupt handler.
+     The compiler generates function entry and exit sequences suitable
+     for use in an interrupt handler when this attribute is present.
+
+'interrupt_thread'
+     Use this attribute on fido, a subarchitecture of the m68k, to
+     indicate that the specified function is an interrupt handler that
+     is designed to run as a thread.  The compiler omits generate
+     prologue/epilogue sequences and replaces the return instruction
+     with a 'sleep' instruction.  This attribute is available only on
+     fido.
+
+'isr'
+     Use this attribute on ARM to write Interrupt Service Routines.
+     This is an alias to the 'interrupt' attribute above.
+
+'kspisusp'
+     When used together with 'interrupt_handler', 'exception_handler' or
+     'nmi_handler', code is generated to load the stack pointer from the
+     USP register in the function prologue.
+
+'l1_text'
+     This attribute specifies a function to be placed into L1
+     Instruction SRAM.  The function is put into a specific section
+     named '.l1.text'.  With '-mfdpic', function calls with a such
+     function as the callee or caller uses inlined PLT.
+
+'l2'
+     On the Blackfin, this attribute specifies a function to be placed
+     into L2 SRAM. The function is put into a specific section named
+     '.l1.text'.  With '-mfdpic', callers of such functions use an
+     inlined PLT.
+
+'leaf'
+     Calls to external functions with this attribute must return to the
+     current compilation unit only by return or by exception handling.
+     In particular, leaf functions are not allowed to call callback
+     function passed to it from the current compilation unit or directly
+     call functions exported by the unit or longjmp into the unit.  Leaf
+     function might still call functions from other compilation units
+     and thus they are not necessarily leaf in the sense that they
+     contain no function calls at all.
+
+     The attribute is intended for library functions to improve dataflow
+     analysis.  The compiler takes the hint that any data not escaping
+     the current compilation unit can not be used or modified by the
+     leaf function.  For example, the 'sin' function is a leaf function,
+     but 'qsort' is not.
+
+     Note that leaf functions might invoke signals and signal handlers
+     might be defined in the current compilation unit and use static
+     variables.  The only compliant way to write such a signal handler
+     is to declare such variables 'volatile'.
+
+     The attribute has no effect on functions defined within the current
+     compilation unit.  This is to allow easy merging of multiple
+     compilation units into one, for example, by using the link-time
+     optimization.  For this reason the attribute is not allowed on
+     types to annotate indirect calls.
+
+'long_call/medium_call/short_call'
+     These attributes specify how a particular function is called on
+     ARC, ARM and Epiphany - with 'medium_call' being specific to ARC.
+     These attributes override the '-mlong-calls' (*note ARM Options::
+     and *note ARC Options::) and '-mmedium-calls' (*note ARC Options::)
+     command-line switches and '#pragma long_calls' settings.  For ARM,
+     the 'long_call' attribute indicates that the function might be far
+     away from the call site and require a different (more expensive)
+     calling sequence.  The 'short_call' attribute always places the
+     offset to the function from the call site into the 'BL' instruction
+     directly.
+
+     For ARC, a function marked with the 'long_call' attribute is always
+     called using register-indirect jump-and-link instructions, thereby
+     enabling the called function to be placed anywhere within the
+     32-bit address space.  A function marked with the 'medium_call'
+     attribute will always be close enough to be called with an
+     unconditional branch-and-link instruction, which has a 25-bit
+     offset from the call site.  A function marked with the 'short_call'
+     attribute will always be close enough to be called with a
+     conditional branch-and-link instruction, which has a 21-bit offset
+     from the call site.
+
+'longcall/shortcall'
+     On the Blackfin, RS/6000 and PowerPC, the 'longcall' attribute
+     indicates that the function might be far away from the call site
+     and require a different (more expensive) calling sequence.  The
+     'shortcall' attribute indicates that the function is always close
+     enough for the shorter calling sequence to be used.  These
+     attributes override both the '-mlongcall' switch and, on the
+     RS/6000 and PowerPC, the '#pragma longcall' setting.
+
+     *Note RS/6000 and PowerPC Options::, for more information on
+     whether long calls are necessary.
+
+'long_call/near/far'
+     These attributes specify how a particular function is called on
+     MIPS.  The attributes override the '-mlong-calls' (*note MIPS
+     Options::) command-line switch.  The 'long_call' and 'far'
+     attributes are synonyms, and cause the compiler to always call the
+     function by first loading its address into a register, and then
+     using the contents of that register.  The 'near' attribute has the
+     opposite effect; it specifies that non-PIC calls should be made
+     using the more efficient 'jal' instruction.
+
+'malloc'
+     The 'malloc' attribute is used to tell the compiler that a function
+     may be treated as if any non-'NULL' pointer it returns cannot alias
+     any other pointer valid when the function returns and that the
+     memory has undefined content.  This often improves optimization.
+     Standard functions with this property include 'malloc' and
+     'calloc'.  'realloc'-like functions do not have this property as
+     the memory pointed to does not have undefined content.
+
+'mips16/nomips16'
+
+     On MIPS targets, you can use the 'mips16' and 'nomips16' function
+     attributes to locally select or turn off MIPS16 code generation.  A
+     function with the 'mips16' attribute is emitted as MIPS16 code,
+     while MIPS16 code generation is disabled for functions with the
+     'nomips16' attribute.  These attributes override the '-mips16' and
+     '-mno-mips16' options on the command line (*note MIPS Options::).
+
+     When compiling files containing mixed MIPS16 and non-MIPS16 code,
+     the preprocessor symbol '__mips16' reflects the setting on the
+     command line, not that within individual functions.  Mixed MIPS16
+     and non-MIPS16 code may interact badly with some GCC extensions
+     such as '__builtin_apply' (*note Constructing Calls::).
+
+'micromips/nomicromips'
+
+     On MIPS targets, you can use the 'micromips' and 'nomicromips'
+     function attributes to locally select or turn off microMIPS code
+     generation.  A function with the 'micromips' attribute is emitted
+     as microMIPS code, while microMIPS code generation is disabled for
+     functions with the 'nomicromips' attribute.  These attributes
+     override the '-mmicromips' and '-mno-micromips' options on the
+     command line (*note MIPS Options::).
+
+     When compiling files containing mixed microMIPS and non-microMIPS
+     code, the preprocessor symbol '__mips_micromips' reflects the
+     setting on the command line, not that within individual functions.
+     Mixed microMIPS and non-microMIPS code may interact badly with some
+     GCC extensions such as '__builtin_apply' (*note Constructing
+     Calls::).
+
+'model (MODEL-NAME)'
+
+     On the M32R/D, use this attribute to set the addressability of an
+     object, and of the code generated for a function.  The identifier
+     MODEL-NAME is one of 'small', 'medium', or 'large', representing
+     each of the code models.
+
+     Small model objects live in the lower 16MB of memory (so that their
+     addresses can be loaded with the 'ld24' instruction), and are
+     callable with the 'bl' instruction.
+
+     Medium model objects may live anywhere in the 32-bit address space
+     (the compiler generates 'seth/add3' instructions to load their
+     addresses), and are callable with the 'bl' instruction.
+
+     Large model objects may live anywhere in the 32-bit address space
+     (the compiler generates 'seth/add3' instructions to load their
+     addresses), and may not be reachable with the 'bl' instruction (the
+     compiler generates the much slower 'seth/add3/jl' instruction
+     sequence).
+
+     On IA-64, use this attribute to set the addressability of an
+     object.  At present, the only supported identifier for MODEL-NAME
+     is 'small', indicating addressability via "small" (22-bit)
+     addresses (so that their addresses can be loaded with the 'addl'
+     instruction).  Caveat: such addressing is by definition not
+     position independent and hence this attribute must not be used for
+     objects defined by shared libraries.
+
+'ms_abi/sysv_abi'
+
+     On 32-bit and 64-bit (i?86|x86_64)-*-* targets, you can use an ABI
+     attribute to indicate which calling convention should be used for a
+     function.  The 'ms_abi' attribute tells the compiler to use the
+     Microsoft ABI, while the 'sysv_abi' attribute tells the compiler to
+     use the ABI used on GNU/Linux and other systems.  The default is to
+     use the Microsoft ABI when targeting Windows.  On all other
+     systems, the default is the x86/AMD ABI.
+
+     Note, the 'ms_abi' attribute for Microsoft Windows 64-bit targets
+     currently requires the '-maccumulate-outgoing-args' option.
+
+'callee_pop_aggregate_return (NUMBER)'
+
+     On 32-bit i?86-*-* targets, you can use this attribute to control
+     how aggregates are returned in memory.  If the caller is
+     responsible for popping the hidden pointer together with the rest
+     of the arguments, specify NUMBER equal to zero.  If callee is
+     responsible for popping the hidden pointer, specify NUMBER equal to
+     one.
+
+     The default i386 ABI assumes that the callee pops the stack for
+     hidden pointer.  However, on 32-bit i386 Microsoft Windows targets,
+     the compiler assumes that the caller pops the stack for hidden
+     pointer.
+
+'ms_hook_prologue'
+
+     On 32-bit i[34567]86-*-* targets and 64-bit x86_64-*-* targets, you
+     can use this function attribute to make GCC generate the
+     "hot-patching" function prologue used in Win32 API functions in
+     Microsoft Windows XP Service Pack 2 and newer.
+
+'hotpatch [(PROLOGUE-HALFWORDS)]'
+
+     On S/390 System z targets, you can use this function attribute to
+     make GCC generate a "hot-patching" function prologue.  The
+     'hotpatch' has no effect on funtions that are explicitly inline.
+     If the '-mhotpatch' or '-mno-hotpatch' command-line option is used
+     at the same time, the 'hotpatch' attribute takes precedence.  If an
+     argument is given, the maximum allowed value is 1000000.
+
+'naked'
+     Use this attribute on the ARM, AVR, MCORE, MSP430, NDS32, RL78, RX
+     and SPU ports to indicate that the specified function does not need
+     prologue/epilogue sequences generated by the compiler.  It is up to
+     the programmer to provide these sequences.  The only statements
+     that can be safely included in naked functions are 'asm' statements
+     that do not have operands.  All other statements, including
+     declarations of local variables, 'if' statements, and so forth,
+     should be avoided.  Naked functions should be used to implement the
+     body of an assembly function, while allowing the compiler to
+     construct the requisite function declaration for the assembler.
+
+'near'
+     On 68HC11 and 68HC12 the 'near' attribute causes the compiler to
+     use the normal calling convention based on 'jsr' and 'rts'.  This
+     attribute can be used to cancel the effect of the '-mlong-calls'
+     option.
+
+     On MeP targets this attribute causes the compiler to assume the
+     called function is close enough to use the normal calling
+     convention, overriding the '-mtf' command-line option.
+
+'nesting'
+     Use this attribute together with 'interrupt_handler',
+     'exception_handler' or 'nmi_handler' to indicate that the function
+     entry code should enable nested interrupts or exceptions.
+
+'nmi_handler'
+     Use this attribute on the Blackfin to indicate that the specified
+     function is an NMI handler.  The compiler generates function entry
+     and exit sequences suitable for use in an NMI handler when this
+     attribute is present.
+
+'nocompression'
+     On MIPS targets, you can use the 'nocompression' function attribute
+     to locally turn off MIPS16 and microMIPS code generation.  This
+     attribute overrides the '-mips16' and '-mmicromips' options on the
+     command line (*note MIPS Options::).
+
+'no_instrument_function'
+     If '-finstrument-functions' is given, profiling function calls are
+     generated at entry and exit of most user-compiled functions.
+     Functions with this attribute are not so instrumented.
+
+'no_split_stack'
+     If '-fsplit-stack' is given, functions have a small prologue which
+     decides whether to split the stack.  Functions with the
+     'no_split_stack' attribute do not have that prologue, and thus may
+     run with only a small amount of stack space available.
+
+'noinline'
+     This function attribute prevents a function from being considered
+     for inlining.  If the function does not have side-effects, there
+     are optimizations other than inlining that cause function calls to
+     be optimized away, although the function call is live.  To keep
+     such calls from being optimized away, put
+          asm ("");
+
+     (*note Extended Asm::) in the called function, to serve as a
+     special side-effect.
+
+'noclone'
+     This function attribute prevents a function from being considered
+     for cloning--a mechanism that produces specialized copies of
+     functions and which is (currently) performed by interprocedural
+     constant propagation.
+
+'nonnull (ARG-INDEX, ...)'
+     The 'nonnull' attribute specifies that some function parameters
+     should be non-null pointers.  For instance, the declaration:
+
+          extern void *
+          my_memcpy (void *dest, const void *src, size_t len)
+                  __attribute__((nonnull (1, 2)));
+
+     causes the compiler to check that, in calls to 'my_memcpy',
+     arguments DEST and SRC are non-null.  If the compiler determines
+     that a null pointer is passed in an argument slot marked as
+     non-null, and the '-Wnonnull' option is enabled, a warning is
+     issued.  The compiler may also choose to make optimizations based
+     on the knowledge that certain function arguments will never be
+     null.
+
+     If no argument index list is given to the 'nonnull' attribute, all
+     pointer arguments are marked as non-null.  To illustrate, the
+     following declaration is equivalent to the previous example:
+
+          extern void *
+          my_memcpy (void *dest, const void *src, size_t len)
+                  __attribute__((nonnull));
+
+'returns_nonnull'
+     The 'returns_nonnull' attribute specifies that the function return
+     value should be a non-null pointer.  For instance, the declaration:
+
+          extern void *
+          mymalloc (size_t len) __attribute__((returns_nonnull));
+
+     lets the compiler optimize callers based on the knowledge that the
+     return value will never be null.
+
+'noreturn'
+     A few standard library functions, such as 'abort' and 'exit',
+     cannot return.  GCC knows this automatically.  Some programs define
+     their own functions that never return.  You can declare them
+     'noreturn' to tell the compiler this fact.  For example,
+
+          void fatal () __attribute__ ((noreturn));
+
+          void
+          fatal (/* ... */)
+          {
+            /* ... */ /* Print error message. */ /* ... */
+            exit (1);
+          }
+
+     The 'noreturn' keyword tells the compiler to assume that 'fatal'
+     cannot return.  It can then optimize without regard to what would
+     happen if 'fatal' ever did return.  This makes slightly better
+     code.  More importantly, it helps avoid spurious warnings of
+     uninitialized variables.
+
+     The 'noreturn' keyword does not affect the exceptional path when
+     that applies: a 'noreturn'-marked function may still return to the
+     caller by throwing an exception or calling 'longjmp'.
+
+     Do not assume that registers saved by the calling function are
+     restored before calling the 'noreturn' function.
+
+     It does not make sense for a 'noreturn' function to have a return
+     type other than 'void'.
+
+     The attribute 'noreturn' is not implemented in GCC versions earlier
+     than 2.5.  An alternative way to declare that a function does not
+     return, which works in the current version and in some older
+     versions, is as follows:
+
+          typedef void voidfn ();
+
+          volatile voidfn fatal;
+
+     This approach does not work in GNU C++.
+
+'nothrow'
+     The 'nothrow' attribute is used to inform the compiler that a
+     function cannot throw an exception.  For example, most functions in
+     the standard C library can be guaranteed not to throw an exception
+     with the notable exceptions of 'qsort' and 'bsearch' that take
+     function pointer arguments.  The 'nothrow' attribute is not
+     implemented in GCC versions earlier than 3.3.
+
+'nosave_low_regs'
+     Use this attribute on SH targets to indicate that an
+     'interrupt_handler' function should not save and restore registers
+     R0..R7.  This can be used on SH3* and SH4* targets that have a
+     second R0..R7 register bank for non-reentrant interrupt handlers.
+
+'optimize'
+     The 'optimize' attribute is used to specify that a function is to
+     be compiled with different optimization options than specified on
+     the command line.  Arguments can either be numbers or strings.
+     Numbers are assumed to be an optimization level.  Strings that
+     begin with 'O' are assumed to be an optimization option, while
+     other options are assumed to be used with a '-f' prefix.  You can
+     also use the '#pragma GCC optimize' pragma to set the optimization
+     options that affect more than one function.  *Note Function
+     Specific Option Pragmas::, for details about the '#pragma GCC
+     optimize' pragma.
+
+     This can be used for instance to have frequently-executed functions
+     compiled with more aggressive optimization options that produce
+     faster and larger code, while other functions can be compiled with
+     less aggressive options.
+
+'OS_main/OS_task'
+     On AVR, functions with the 'OS_main' or 'OS_task' attribute do not
+     save/restore any call-saved register in their prologue/epilogue.
+
+     The 'OS_main' attribute can be used when there _is guarantee_ that
+     interrupts are disabled at the time when the function is entered.
+     This saves resources when the stack pointer has to be changed to
+     set up a frame for local variables.
+
+     The 'OS_task' attribute can be used when there is _no guarantee_
+     that interrupts are disabled at that time when the function is
+     entered like for, e.g.  task functions in a multi-threading
+     operating system.  In that case, changing the stack pointer
+     register is guarded by save/clear/restore of the global interrupt
+     enable flag.
+
+     The differences to the 'naked' function attribute are:
+        * 'naked' functions do not have a return instruction whereas
+          'OS_main' and 'OS_task' functions have a 'RET' or 'RETI'
+          return instruction.
+        * 'naked' functions do not set up a frame for local variables or
+          a frame pointer whereas 'OS_main' and 'OS_task' do this as
+          needed.
+
+'pcs'
+
+     The 'pcs' attribute can be used to control the calling convention
+     used for a function on ARM. The attribute takes an argument that
+     specifies the calling convention to use.
+
+     When compiling using the AAPCS ABI (or a variant of it) then valid
+     values for the argument are '"aapcs"' and '"aapcs-vfp"'.  In order
+     to use a variant other than '"aapcs"' then the compiler must be
+     permitted to use the appropriate co-processor registers (i.e., the
+     VFP registers must be available in order to use '"aapcs-vfp"').
+     For example,
+
+          /* Argument passed in r0, and result returned in r0+r1.  */
+          double f2d (float) __attribute__((pcs("aapcs")));
+
+     Variadic functions always use the '"aapcs"' calling convention and
+     the compiler rejects attempts to specify an alternative.
+
+'pure'
+     Many functions have no effects except the return value and their
+     return value depends only on the parameters and/or global
+     variables.  Such a function can be subject to common subexpression
+     elimination and loop optimization just as an arithmetic operator
+     would be.  These functions should be declared with the attribute
+     'pure'.  For example,
+
+          int square (int) __attribute__ ((pure));
+
+     says that the hypothetical function 'square' is safe to call fewer
+     times than the program says.
+
+     Some of common examples of pure functions are 'strlen' or 'memcmp'.
+     Interesting non-pure functions are functions with infinite loops or
+     those depending on volatile memory or other system resource, that
+     may change between two consecutive calls (such as 'feof' in a
+     multithreading environment).
+
+     The attribute 'pure' is not implemented in GCC versions earlier
+     than 2.96.
+
+'hot'
+     The 'hot' attribute on a function is used to inform the compiler
+     that the function is a hot spot of the compiled program.  The
+     function is optimized more aggressively and on many target it is
+     placed into special subsection of the text section so all hot
+     functions appears close together improving locality.
+
+     When profile feedback is available, via '-fprofile-use', hot
+     functions are automatically detected and this attribute is ignored.
+
+     The 'hot' attribute on functions is not implemented in GCC versions
+     earlier than 4.3.
+
+     The 'hot' attribute on a label is used to inform the compiler that
+     path following the label are more likely than paths that are not so
+     annotated.  This attribute is used in cases where
+     '__builtin_expect' cannot be used, for instance with computed goto
+     or 'asm goto'.
+
+     The 'hot' attribute on labels is not implemented in GCC versions
+     earlier than 4.8.
+
+'cold'
+     The 'cold' attribute on functions is used to inform the compiler
+     that the function is unlikely to be executed.  The function is
+     optimized for size rather than speed and on many targets it is
+     placed into special subsection of the text section so all cold
+     functions appears close together improving code locality of
+     non-cold parts of program.  The paths leading to call of cold
+     functions within code are marked as unlikely by the branch
+     prediction mechanism.  It is thus useful to mark functions used to
+     handle unlikely conditions, such as 'perror', as cold to improve
+     optimization of hot functions that do call marked functions in rare
+     occasions.
+
+     When profile feedback is available, via '-fprofile-use', cold
+     functions are automatically detected and this attribute is ignored.
+
+     The 'cold' attribute on functions is not implemented in GCC
+     versions earlier than 4.3.
+
+     The 'cold' attribute on labels is used to inform the compiler that
+     the path following the label is unlikely to be executed.  This
+     attribute is used in cases where '__builtin_expect' cannot be used,
+     for instance with computed goto or 'asm goto'.
+
+     The 'cold' attribute on labels is not implemented in GCC versions
+     earlier than 4.8.
+
+'no_sanitize_address'
+'no_address_safety_analysis'
+     The 'no_sanitize_address' attribute on functions is used to inform
+     the compiler that it should not instrument memory accesses in the
+     function when compiling with the '-fsanitize=address' option.  The
+     'no_address_safety_analysis' is a deprecated alias of the
+     'no_sanitize_address' attribute, new code should use
+     'no_sanitize_address'.
+
+'no_sanitize_undefined'
+     The 'no_sanitize_undefined' attribute on functions is used to
+     inform the compiler that it should not check for undefined behavior
+     in the function when compiling with the '-fsanitize=undefined'
+     option.
+
+'regparm (NUMBER)'
+     On the Intel 386, the 'regparm' attribute causes the compiler to
+     pass arguments number one to NUMBER if they are of integral type in
+     registers EAX, EDX, and ECX instead of on the stack.  Functions
+     that take a variable number of arguments continue to be passed all
+     of their arguments on the stack.
+
+     Beware that on some ELF systems this attribute is unsuitable for
+     global functions in shared libraries with lazy binding (which is
+     the default).  Lazy binding sends the first call via resolving code
+     in the loader, which might assume EAX, EDX and ECX can be
+     clobbered, as per the standard calling conventions.  Solaris 8 is
+     affected by this.  Systems with the GNU C Library version 2.1 or
+     higher and FreeBSD are believed to be safe since the loaders there
+     save EAX, EDX and ECX. (Lazy binding can be disabled with the
+     linker or the loader if desired, to avoid the problem.)
+
+'reset'
+     Use this attribute on the NDS32 target to indicate that the
+     specified function is a reset handler.  The compiler will generate
+     corresponding sections for use in a reset handler.  You can use the
+     following attributes to provide extra exception handling:
+     'nmi'
+          Provide a user-defined function to handle NMI exception.
+     'warm'
+          Provide a user-defined function to handle warm reset
+          exception.
+
+'sseregparm'
+     On the Intel 386 with SSE support, the 'sseregparm' attribute
+     causes the compiler to pass up to 3 floating-point arguments in SSE
+     registers instead of on the stack.  Functions that take a variable
+     number of arguments continue to pass all of their floating-point
+     arguments on the stack.
+
+'force_align_arg_pointer'
+     On the Intel x86, the 'force_align_arg_pointer' attribute may be
+     applied to individual function definitions, generating an alternate
+     prologue and epilogue that realigns the run-time stack if
+     necessary.  This supports mixing legacy codes that run with a
+     4-byte aligned stack with modern codes that keep a 16-byte stack
+     for SSE compatibility.
+
+'renesas'
+     On SH targets this attribute specifies that the function or struct
+     follows the Renesas ABI.
+
+'resbank'
+     On the SH2A target, this attribute enables the high-speed register
+     saving and restoration using a register bank for
+     'interrupt_handler' routines.  Saving to the bank is performed
+     automatically after the CPU accepts an interrupt that uses a
+     register bank.
+
+     The nineteen 32-bit registers comprising general register R0 to
+     R14, control register GBR, and system registers MACH, MACL, and PR
+     and the vector table address offset are saved into a register bank.
+     Register banks are stacked in first-in last-out (FILO) sequence.
+     Restoration from the bank is executed by issuing a RESBANK
+     instruction.
+
+'returns_twice'
+     The 'returns_twice' attribute tells the compiler that a function
+     may return more than one time.  The compiler ensures that all
+     registers are dead before calling such a function and emits a
+     warning about the variables that may be clobbered after the second
+     return from the function.  Examples of such functions are 'setjmp'
+     and 'vfork'.  The 'longjmp'-like counterpart of such function, if
+     any, might need to be marked with the 'noreturn' attribute.
+
+'saveall'
+     Use this attribute on the Blackfin, H8/300, H8/300H, and H8S to
+     indicate that all registers except the stack pointer should be
+     saved in the prologue regardless of whether they are used or not.
+
+'save_volatiles'
+     Use this attribute on the MicroBlaze to indicate that the function
+     is an interrupt handler.  All volatile registers (in addition to
+     non-volatile registers) are saved in the function prologue.  If the
+     function is a leaf function, only volatiles used by the function
+     are saved.  A normal function return is generated instead of a
+     return from interrupt.
+
+'section ("SECTION-NAME")'
+     Normally, the compiler places the code it generates in the 'text'
+     section.  Sometimes, however, you need additional sections, or you
+     need certain particular functions to appear in special sections.
+     The 'section' attribute specifies that a function lives in a
+     particular section.  For example, the declaration:
+
+          extern void foobar (void) __attribute__ ((section ("bar")));
+
+     puts the function 'foobar' in the 'bar' section.
+
+     Some file formats do not support arbitrary sections so the
+     'section' attribute is not available on all platforms.  If you need
+     to map the entire contents of a module to a particular section,
+     consider using the facilities of the linker instead.
+
+'sentinel'
+     This function attribute ensures that a parameter in a function call
+     is an explicit 'NULL'.  The attribute is only valid on variadic
+     functions.  By default, the sentinel is located at position zero,
+     the last parameter of the function call.  If an optional integer
+     position argument P is supplied to the attribute, the sentinel must
+     be located at position P counting backwards from the end of the
+     argument list.
+
+          __attribute__ ((sentinel))
+          is equivalent to
+          __attribute__ ((sentinel(0)))
+
+     The attribute is automatically set with a position of 0 for the
+     built-in functions 'execl' and 'execlp'.  The built-in function
+     'execle' has the attribute set with a position of 1.
+
+     A valid 'NULL' in this context is defined as zero with any pointer
+     type.  If your system defines the 'NULL' macro with an integer type
+     then you need to add an explicit cast.  GCC replaces 'stddef.h'
+     with a copy that redefines NULL appropriately.
+
+     The warnings for missing or incorrect sentinels are enabled with
+     '-Wformat'.
+
+'short_call'
+     See 'long_call/short_call'.
+
+'shortcall'
+     See 'longcall/shortcall'.
+
+'signal'
+     Use this attribute on the AVR to indicate that the specified
+     function is an interrupt handler.  The compiler generates function
+     entry and exit sequences suitable for use in an interrupt handler
+     when this attribute is present.
+
+     See also the 'interrupt' function attribute.
+
+     The AVR hardware globally disables interrupts when an interrupt is
+     executed.  Interrupt handler functions defined with the 'signal'
+     attribute do not re-enable interrupts.  It is save to enable
+     interrupts in a 'signal' handler.  This "save" only applies to the
+     code generated by the compiler and not to the IRQ layout of the
+     application which is responsibility of the application.
+
+     If both 'signal' and 'interrupt' are specified for the same
+     function, 'signal' is silently ignored.
+
+'sp_switch'
+     Use this attribute on the SH to indicate an 'interrupt_handler'
+     function should switch to an alternate stack.  It expects a string
+     argument that names a global variable holding the address of the
+     alternate stack.
+
+          void *alt_stack;
+          void f () __attribute__ ((interrupt_handler,
+                                    sp_switch ("alt_stack")));
+
+'stdcall'
+     On the Intel 386, the 'stdcall' attribute causes the compiler to
+     assume that the called function pops off the stack space used to
+     pass arguments, unless it takes a variable number of arguments.
+
+'syscall_linkage'
+     This attribute is used to modify the IA-64 calling convention by
+     marking all input registers as live at all function exits.  This
+     makes it possible to restart a system call after an interrupt
+     without having to save/restore the input registers.  This also
+     prevents kernel data from leaking into application code.
+
+'target'
+     The 'target' attribute is used to specify that a function is to be
+     compiled with different target options than specified on the
+     command line.  This can be used for instance to have functions
+     compiled with a different ISA (instruction set architecture) than
+     the default.  You can also use the '#pragma GCC target' pragma to
+     set more than one function to be compiled with specific target
+     options.  *Note Function Specific Option Pragmas::, for details
+     about the '#pragma GCC target' pragma.
+
+     For instance on a 386, you could compile one function with
+     'target("sse4.1,arch=core2")' and another with
+     'target("sse4a,arch=amdfam10")'.  This is equivalent to compiling
+     the first function with '-msse4.1' and '-march=core2' options, and
+     the second function with '-msse4a' and '-march=amdfam10' options.
+     It is up to the user to make sure that a function is only invoked
+     on a machine that supports the particular ISA it is compiled for
+     (for example by using 'cpuid' on 386 to determine what feature bits
+     and architecture family are used).
+
+          int core2_func (void) __attribute__ ((__target__ ("arch=core2")));
+          int sse3_func (void) __attribute__ ((__target__ ("sse3")));
+
+     You can either use multiple strings to specify multiple options, or
+     separate the options with a comma (',').
+
+     The 'target' attribute is presently implemented for i386/x86_64,
+     PowerPC, and Nios II targets only.  The options supported are
+     specific to each target.
+
+     On the 386, the following options are allowed:
+
+     'abm'
+     'no-abm'
+          Enable/disable the generation of the advanced bit
+          instructions.
+
+     'aes'
+     'no-aes'
+          Enable/disable the generation of the AES instructions.
+
+     'default'
+          *Note Function Multiversioning::, where it is used to specify
+          the default function version.
+
+     'mmx'
+     'no-mmx'
+          Enable/disable the generation of the MMX instructions.
+
+     'pclmul'
+     'no-pclmul'
+          Enable/disable the generation of the PCLMUL instructions.
+
+     'popcnt'
+     'no-popcnt'
+          Enable/disable the generation of the POPCNT instruction.
+
+     'sse'
+     'no-sse'
+          Enable/disable the generation of the SSE instructions.
+
+     'sse2'
+     'no-sse2'
+          Enable/disable the generation of the SSE2 instructions.
+
+     'sse3'
+     'no-sse3'
+          Enable/disable the generation of the SSE3 instructions.
+
+     'sse4'
+     'no-sse4'
+          Enable/disable the generation of the SSE4 instructions (both
+          SSE4.1 and SSE4.2).
+
+     'sse4.1'
+     'no-sse4.1'
+          Enable/disable the generation of the sse4.1 instructions.
+
+     'sse4.2'
+     'no-sse4.2'
+          Enable/disable the generation of the sse4.2 instructions.
+
+     'sse4a'
+     'no-sse4a'
+          Enable/disable the generation of the SSE4A instructions.
+
+     'fma4'
+     'no-fma4'
+          Enable/disable the generation of the FMA4 instructions.
+
+     'xop'
+     'no-xop'
+          Enable/disable the generation of the XOP instructions.
+
+     'lwp'
+     'no-lwp'
+          Enable/disable the generation of the LWP instructions.
+
+     'ssse3'
+     'no-ssse3'
+          Enable/disable the generation of the SSSE3 instructions.
+
+     'cld'
+     'no-cld'
+          Enable/disable the generation of the CLD before string moves.
+
+     'fancy-math-387'
+     'no-fancy-math-387'
+          Enable/disable the generation of the 'sin', 'cos', and 'sqrt'
+          instructions on the 387 floating-point unit.
+
+     'fused-madd'
+     'no-fused-madd'
+          Enable/disable the generation of the fused multiply/add
+          instructions.
+
+     'ieee-fp'
+     'no-ieee-fp'
+          Enable/disable the generation of floating point that depends
+          on IEEE arithmetic.
+
+     'inline-all-stringops'
+     'no-inline-all-stringops'
+          Enable/disable inlining of string operations.
+
+     'inline-stringops-dynamically'
+     'no-inline-stringops-dynamically'
+          Enable/disable the generation of the inline code to do small
+          string operations and calling the library routines for large
+          operations.
+
+     'align-stringops'
+     'no-align-stringops'
+          Do/do not align destination of inlined string operations.
+
+     'recip'
+     'no-recip'
+          Enable/disable the generation of RCPSS, RCPPS, RSQRTSS and
+          RSQRTPS instructions followed an additional Newton-Raphson
+          step instead of doing a floating-point division.
+
+     'arch=ARCH'
+          Specify the architecture to generate code for in compiling the
+          function.
+
+     'tune=TUNE'
+          Specify the architecture to tune for in compiling the
+          function.
+
+     'fpmath=FPMATH'
+          Specify which floating-point unit to use.  The
+          'target("fpmath=sse,387")' option must be specified as
+          'target("fpmath=sse+387")' because the comma would separate
+          different options.
+
+     On the PowerPC, the following options are allowed:
+
+     'altivec'
+     'no-altivec'
+          Generate code that uses (does not use) AltiVec instructions.
+          In 32-bit code, you cannot enable AltiVec instructions unless
+          '-mabi=altivec' is used on the command line.
+
+     'cmpb'
+     'no-cmpb'
+          Generate code that uses (does not use) the compare bytes
+          instruction implemented on the POWER6 processor and other
+          processors that support the PowerPC V2.05 architecture.
+
+     'dlmzb'
+     'no-dlmzb'
+          Generate code that uses (does not use) the string-search
+          'dlmzb' instruction on the IBM 405, 440, 464 and 476
+          processors.  This instruction is generated by default when
+          targeting those processors.
+
+     'fprnd'
+     'no-fprnd'
+          Generate code that uses (does not use) the FP round to integer
+          instructions implemented on the POWER5+ processor and other
+          processors that support the PowerPC V2.03 architecture.
+
+     'hard-dfp'
+     'no-hard-dfp'
+          Generate code that uses (does not use) the decimal
+          floating-point instructions implemented on some POWER
+          processors.
+
+     'isel'
+     'no-isel'
+          Generate code that uses (does not use) ISEL instruction.
+
+     'mfcrf'
+     'no-mfcrf'
+          Generate code that uses (does not use) the move from condition
+          register field instruction implemented on the POWER4 processor
+          and other processors that support the PowerPC V2.01
+          architecture.
+
+     'mfpgpr'
+     'no-mfpgpr'
+          Generate code that uses (does not use) the FP move to/from
+          general purpose register instructions implemented on the
+          POWER6X processor and other processors that support the
+          extended PowerPC V2.05 architecture.
+
+     'mulhw'
+     'no-mulhw'
+          Generate code that uses (does not use) the half-word multiply
+          and multiply-accumulate instructions on the IBM 405, 440, 464
+          and 476 processors.  These instructions are generated by
+          default when targeting those processors.
+
+     'multiple'
+     'no-multiple'
+          Generate code that uses (does not use) the load multiple word
+          instructions and the store multiple word instructions.
+
+     'update'
+     'no-update'
+          Generate code that uses (does not use) the load or store
+          instructions that update the base register to the address of
+          the calculated memory location.
+
+     'popcntb'
+     'no-popcntb'
+          Generate code that uses (does not use) the popcount and
+          double-precision FP reciprocal estimate instruction
+          implemented on the POWER5 processor and other processors that
+          support the PowerPC V2.02 architecture.
+
+     'popcntd'
+     'no-popcntd'
+          Generate code that uses (does not use) the popcount
+          instruction implemented on the POWER7 processor and other
+          processors that support the PowerPC V2.06 architecture.
+
+     'powerpc-gfxopt'
+     'no-powerpc-gfxopt'
+          Generate code that uses (does not use) the optional PowerPC
+          architecture instructions in the Graphics group, including
+          floating-point select.
+
+     'powerpc-gpopt'
+     'no-powerpc-gpopt'
+          Generate code that uses (does not use) the optional PowerPC
+          architecture instructions in the General Purpose group,
+          including floating-point square root.
+
+     'recip-precision'
+     'no-recip-precision'
+          Assume (do not assume) that the reciprocal estimate
+          instructions provide higher-precision estimates than is
+          mandated by the powerpc ABI.
+
+     'string'
+     'no-string'
+          Generate code that uses (does not use) the load string
+          instructions and the store string word instructions to save
+          multiple registers and do small block moves.
+
+     'vsx'
+     'no-vsx'
+          Generate code that uses (does not use) vector/scalar (VSX)
+          instructions, and also enable the use of built-in functions
+          that allow more direct access to the VSX instruction set.  In
+          32-bit code, you cannot enable VSX or AltiVec instructions
+          unless '-mabi=altivec' is used on the command line.
+
+     'friz'
+     'no-friz'
+          Generate (do not generate) the 'friz' instruction when the
+          '-funsafe-math-optimizations' option is used to optimize
+          rounding a floating-point value to 64-bit integer and back to
+          floating point.  The 'friz' instruction does not return the
+          same value if the floating-point number is too large to fit in
+          an integer.
+
+     'avoid-indexed-addresses'
+     'no-avoid-indexed-addresses'
+          Generate code that tries to avoid (not avoid) the use of
+          indexed load or store instructions.
+
+     'paired'
+     'no-paired'
+          Generate code that uses (does not use) the generation of
+          PAIRED simd instructions.
+
+     'longcall'
+     'no-longcall'
+          Generate code that assumes (does not assume) that all calls
+          are far away so that a longer more expensive calling sequence
+          is required.
+
+     'cpu=CPU'
+          Specify the architecture to generate code for when compiling
+          the function.  If you select the 'target("cpu=power7")'
+          attribute when generating 32-bit code, VSX and AltiVec
+          instructions are not generated unless you use the
+          '-mabi=altivec' option on the command line.
+
+     'tune=TUNE'
+          Specify the architecture to tune for when compiling the
+          function.  If you do not specify the 'target("tune=TUNE")'
+          attribute and you do specify the 'target("cpu=CPU")'
+          attribute, compilation tunes for the CPU architecture, and not
+          the default tuning specified on the command line.
+
+     When compiling for Nios II, the following options are allowed:
+
+     'custom-INSN=N'
+     'no-custom-INSN'
+          Each 'custom-INSN=N' attribute locally enables use of a custom
+          instruction with encoding N when generating code that uses
+          INSN.  Similarly, 'no-custom-INSN' locally inhibits use of the
+          custom instruction INSN.  These target attributes correspond
+          to the '-mcustom-INSN=N' and '-mno-custom-INSN' command-line
+          options, and support the same set of INSN keywords.  *Note
+          Nios II Options::, for more information.
+
+     'custom-fpu-cfg=NAME'
+          This attribute corresponds to the '-mcustom-fpu-cfg=NAME'
+          command-line option, to select a predefined set of custom
+          instructions named NAME.  *Note Nios II Options::, for more
+          information.
+
+     On the 386/x86_64 and PowerPC back ends, the inliner does not
+     inline a function that has different target options than the
+     caller, unless the callee has a subset of the target options of the
+     caller.  For example a function declared with 'target("sse3")' can
+     inline a function with 'target("sse2")', since '-msse3' implies
+     '-msse2'.
+
+'tiny_data'
+     Use this attribute on the H8/300H and H8S to indicate that the
+     specified variable should be placed into the tiny data section.
+     The compiler generates more efficient code for loads and stores on
+     data in the tiny data section.  Note the tiny data area is limited
+     to slightly under 32KB of data.
+
+'trap_exit'
+     Use this attribute on the SH for an 'interrupt_handler' to return
+     using 'trapa' instead of 'rte'.  This attribute expects an integer
+     argument specifying the trap number to be used.
+
+'trapa_handler'
+     On SH targets this function attribute is similar to
+     'interrupt_handler' but it does not save and restore all registers.
+
+'unused'
+     This attribute, attached to a function, means that the function is
+     meant to be possibly unused.  GCC does not produce a warning for
+     this function.
+
+'used'
+     This attribute, attached to a function, means that code must be
+     emitted for the function even if it appears that the function is
+     not referenced.  This is useful, for example, when the function is
+     referenced only in inline assembly.
+
+     When applied to a member function of a C++ class template, the
+     attribute also means that the function is instantiated if the class
+     itself is instantiated.
+
+'version_id'
+     This IA-64 HP-UX attribute, attached to a global variable or
+     function, renames a symbol to contain a version string, thus
+     allowing for function level versioning.  HP-UX system header files
+     may use function level versioning for some system calls.
+
+          extern int foo () __attribute__((version_id ("20040821")));
+
+     Calls to FOO are mapped to calls to FOO{20040821}.
+
+'visibility ("VISIBILITY_TYPE")'
+     This attribute affects the linkage of the declaration to which it
+     is attached.  There are four supported VISIBILITY_TYPE values:
+     default, hidden, protected or internal visibility.
+
+          void __attribute__ ((visibility ("protected")))
+          f () { /* Do something. */; }
+          int i __attribute__ ((visibility ("hidden")));
+
+     The possible values of VISIBILITY_TYPE correspond to the visibility
+     settings in the ELF gABI.
+
+     "default"
+          Default visibility is the normal case for the object file
+          format.  This value is available for the visibility attribute
+          to override other options that may change the assumed
+          visibility of entities.
+
+          On ELF, default visibility means that the declaration is
+          visible to other modules and, in shared libraries, means that
+          the declared entity may be overridden.
+
+          On Darwin, default visibility means that the declaration is
+          visible to other modules.
+
+          Default visibility corresponds to "external linkage" in the
+          language.
+
+     "hidden"
+          Hidden visibility indicates that the entity declared has a new
+          form of linkage, which we call "hidden linkage".  Two
+          declarations of an object with hidden linkage refer to the
+          same object if they are in the same shared object.
+
+     "internal"
+          Internal visibility is like hidden visibility, but with
+          additional processor specific semantics.  Unless otherwise
+          specified by the psABI, GCC defines internal visibility to
+          mean that a function is _never_ called from another module.
+          Compare this with hidden functions which, while they cannot be
+          referenced directly by other modules, can be referenced
+          indirectly via function pointers.  By indicating that a
+          function cannot be called from outside the module, GCC may for
+          instance omit the load of a PIC register since it is known
+          that the calling function loaded the correct value.
+
+     "protected"
+          Protected visibility is like default visibility except that it
+          indicates that references within the defining module bind to
+          the definition in that module.  That is, the declared entity
+          cannot be overridden by another module.
+
+     All visibilities are supported on many, but not all, ELF targets
+     (supported when the assembler supports the '.visibility'
+     pseudo-op).  Default visibility is supported everywhere.  Hidden
+     visibility is supported on Darwin targets.
+
+     The visibility attribute should be applied only to declarations
+     that would otherwise have external linkage.  The attribute should
+     be applied consistently, so that the same entity should not be
+     declared with different settings of the attribute.
+
+     In C++, the visibility attribute applies to types as well as
+     functions and objects, because in C++ types have linkage.  A class
+     must not have greater visibility than its non-static data member
+     types and bases, and class members default to the visibility of
+     their class.  Also, a declaration without explicit visibility is
+     limited to the visibility of its type.
+
+     In C++, you can mark member functions and static member variables
+     of a class with the visibility attribute.  This is useful if you
+     know a particular method or static member variable should only be
+     used from one shared object; then you can mark it hidden while the
+     rest of the class has default visibility.  Care must be taken to
+     avoid breaking the One Definition Rule; for example, it is usually
+     not useful to mark an inline method as hidden without marking the
+     whole class as hidden.
+
+     A C++ namespace declaration can also have the visibility attribute.
+
+          namespace nspace1 __attribute__ ((visibility ("protected")))
+          { /* Do something. */; }
+
+     This attribute applies only to the particular namespace body, not
+     to other definitions of the same namespace; it is equivalent to
+     using '#pragma GCC visibility' before and after the namespace
+     definition (*note Visibility Pragmas::).
+
+     In C++, if a template argument has limited visibility, this
+     restriction is implicitly propagated to the template instantiation.
+     Otherwise, template instantiations and specializations default to
+     the visibility of their template.
+
+     If both the template and enclosing class have explicit visibility,
+     the visibility from the template is used.
+
+'vliw'
+     On MeP, the 'vliw' attribute tells the compiler to emit
+     instructions in VLIW mode instead of core mode.  Note that this
+     attribute is not allowed unless a VLIW coprocessor has been
+     configured and enabled through command-line options.
+
+'warn_unused_result'
+     The 'warn_unused_result' attribute causes a warning to be emitted
+     if a caller of the function with this attribute does not use its
+     return value.  This is useful for functions where not checking the
+     result is either a security problem or always a bug, such as
+     'realloc'.
+
+          int fn () __attribute__ ((warn_unused_result));
+          int foo ()
+          {
+            if (fn () < 0) return -1;
+            fn ();
+            return 0;
+          }
+
+     results in warning on line 5.
+
+'weak'
+     The 'weak' attribute causes the declaration to be emitted as a weak
+     symbol rather than a global.  This is primarily useful in defining
+     library functions that can be overridden in user code, though it
+     can also be used with non-function declarations.  Weak symbols are
+     supported for ELF targets, and also for a.out targets when using
+     the GNU assembler and linker.
+
+'weakref'
+'weakref ("TARGET")'
+     The 'weakref' attribute marks a declaration as a weak reference.
+     Without arguments, it should be accompanied by an 'alias' attribute
+     naming the target symbol.  Optionally, the TARGET may be given as
+     an argument to 'weakref' itself.  In either case, 'weakref'
+     implicitly marks the declaration as 'weak'.  Without a TARGET,
+     given as an argument to 'weakref' or to 'alias', 'weakref' is
+     equivalent to 'weak'.
+
+          static int x() __attribute__ ((weakref ("y")));
+          /* is equivalent to... */
+          static int x() __attribute__ ((weak, weakref, alias ("y")));
+          /* and to... */
+          static int x() __attribute__ ((weakref));
+          static int x() __attribute__ ((alias ("y")));
+
+     A weak reference is an alias that does not by itself require a
+     definition to be given for the target symbol.  If the target symbol
+     is only referenced through weak references, then it becomes a
+     'weak' undefined symbol.  If it is directly referenced, however,
+     then such strong references prevail, and a definition is required
+     for the symbol, not necessarily in the same translation unit.
+
+     The effect is equivalent to moving all references to the alias to a
+     separate translation unit, renaming the alias to the aliased
+     symbol, declaring it as weak, compiling the two separate
+     translation units and performing a reloadable link on them.
+
+     At present, a declaration to which 'weakref' is attached can only
+     be 'static'.
+
+ You can specify multiple attributes in a declaration by separating them
+by commas within the double parentheses or by immediately following an
+attribute declaration with another attribute declaration.
+
+ Some people object to the '__attribute__' feature, suggesting that ISO
+C's '#pragma' should be used instead.  At the time '__attribute__' was
+designed, there were two reasons for not doing this.
+
+  1. It is impossible to generate '#pragma' commands from a macro.
+
+  2. There is no telling what the same '#pragma' might mean in another
+     compiler.
+
+ These two reasons applied to almost any application that might have
+been proposed for '#pragma'.  It was basically a mistake to use
+'#pragma' for _anything_.
+
+ The ISO C99 standard includes '_Pragma', which now allows pragmas to be
+generated from macros.  In addition, a '#pragma GCC' namespace is now in
+use for GCC-specific pragmas.  However, it has been found convenient to
+use '__attribute__' to achieve a natural attachment of attributes to
+their corresponding declarations, whereas '#pragma GCC' is of use for
+constructs that do not naturally form part of the grammar.  *Note
+Pragmas Accepted by GCC: Pragmas.
+
+
+File: gcc.info,  Node: Attribute Syntax,  Next: Function Prototypes,  Prev: Function Attributes,  Up: C Extensions
+
+6.31 Attribute Syntax
+=====================
+
+This section describes the syntax with which '__attribute__' may be
+used, and the constructs to which attribute specifiers bind, for the C
+language.  Some details may vary for C++ and Objective-C.  Because of
+infelicities in the grammar for attributes, some forms described here
+may not be successfully parsed in all cases.
+
+ There are some problems with the semantics of attributes in C++.  For
+example, there are no manglings for attributes, although they may affect
+code generation, so problems may arise when attributed types are used in
+conjunction with templates or overloading.  Similarly, 'typeid' does not
+distinguish between types with different attributes.  Support for
+attributes in C++ may be restricted in future to attributes on
+declarations only, but not on nested declarators.
+
+ *Note Function Attributes::, for details of the semantics of attributes
+applying to functions.  *Note Variable Attributes::, for details of the
+semantics of attributes applying to variables.  *Note Type Attributes::,
+for details of the semantics of attributes applying to structure, union
+and enumerated types.
+
+ An "attribute specifier" is of the form '__attribute__
+((ATTRIBUTE-LIST))'.  An "attribute list" is a possibly empty
+comma-separated sequence of "attributes", where each attribute is one of
+the following:
+
+   * Empty.  Empty attributes are ignored.
+
+   * A word (which may be an identifier such as 'unused', or a reserved
+     word such as 'const').
+
+   * A word, followed by, in parentheses, parameters for the attribute.
+     These parameters take one of the following forms:
+
+        * An identifier.  For example, 'mode' attributes use this form.
+
+        * An identifier followed by a comma and a non-empty
+          comma-separated list of expressions.  For example, 'format'
+          attributes use this form.
+
+        * A possibly empty comma-separated list of expressions.  For
+          example, 'format_arg' attributes use this form with the list
+          being a single integer constant expression, and 'alias'
+          attributes use this form with the list being a single string
+          constant.
+
+ An "attribute specifier list" is a sequence of one or more attribute
+specifiers, not separated by any other tokens.
+
+ In GNU C, an attribute specifier list may appear after the colon
+following a label, other than a 'case' or 'default' label.  The only
+attribute it makes sense to use after a label is 'unused'.  This feature
+is intended for program-generated code that may contain unused labels,
+but which is compiled with '-Wall'.  It is not normally appropriate to
+use in it human-written code, though it could be useful in cases where
+the code that jumps to the label is contained within an '#ifdef'
+conditional.  GNU C++ only permits attributes on labels if the attribute
+specifier is immediately followed by a semicolon (i.e., the label
+applies to an empty statement).  If the semicolon is missing, C++ label
+attributes are ambiguous, as it is permissible for a declaration, which
+could begin with an attribute list, to be labelled in C++.  Declarations
+cannot be labelled in C90 or C99, so the ambiguity does not arise there.
+
+ An attribute specifier list may appear as part of a 'struct', 'union'
+or 'enum' specifier.  It may go either immediately after the 'struct',
+'union' or 'enum' keyword, or after the closing brace.  The former
+syntax is preferred.  Where attribute specifiers follow the closing
+brace, they are considered to relate to the structure, union or
+enumerated type defined, not to any enclosing declaration the type
+specifier appears in, and the type defined is not complete until after
+the attribute specifiers.
+
+ Otherwise, an attribute specifier appears as part of a declaration,
+counting declarations of unnamed parameters and type names, and relates
+to that declaration (which may be nested in another declaration, for
+example in the case of a parameter declaration), or to a particular
+declarator within a declaration.  Where an attribute specifier is
+applied to a parameter declared as a function or an array, it should
+apply to the function or array rather than the pointer to which the
+parameter is implicitly converted, but this is not yet correctly
+implemented.
+
+ Any list of specifiers and qualifiers at the start of a declaration may
+contain attribute specifiers, whether or not such a list may in that
+context contain storage class specifiers.  (Some attributes, however,
+are essentially in the nature of storage class specifiers, and only make
+sense where storage class specifiers may be used; for example,
+'section'.)  There is one necessary limitation to this syntax: the first
+old-style parameter declaration in a function definition cannot begin
+with an attribute specifier, because such an attribute applies to the
+function instead by syntax described below (which, however, is not yet
+implemented in this case).  In some other cases, attribute specifiers
+are permitted by this grammar but not yet supported by the compiler.
+All attribute specifiers in this place relate to the declaration as a
+whole.  In the obsolescent usage where a type of 'int' is implied by the
+absence of type specifiers, such a list of specifiers and qualifiers may
+be an attribute specifier list with no other specifiers or qualifiers.
+
+ At present, the first parameter in a function prototype must have some
+type specifier that is not an attribute specifier; this resolves an
+ambiguity in the interpretation of 'void f(int (__attribute__((foo))
+x))', but is subject to change.  At present, if the parentheses of a
+function declarator contain only attributes then those attributes are
+ignored, rather than yielding an error or warning or implying a single
+parameter of type int, but this is subject to change.
+
+ An attribute specifier list may appear immediately before a declarator
+(other than the first) in a comma-separated list of declarators in a
+declaration of more than one identifier using a single list of
+specifiers and qualifiers.  Such attribute specifiers apply only to the
+identifier before whose declarator they appear.  For example, in
+
+     __attribute__((noreturn)) void d0 (void),
+         __attribute__((format(printf, 1, 2))) d1 (const char *, ...),
+          d2 (void)
+
+the 'noreturn' attribute applies to all the functions declared; the
+'format' attribute only applies to 'd1'.
+
+ An attribute specifier list may appear immediately before the comma,
+'=' or semicolon terminating the declaration of an identifier other than
+a function definition.  Such attribute specifiers apply to the declared
+object or function.  Where an assembler name for an object or function
+is specified (*note Asm Labels::), the attribute must follow the 'asm'
+specification.
+
+ An attribute specifier list may, in future, be permitted to appear
+after the declarator in a function definition (before any old-style
+parameter declarations or the function body).
+
+ Attribute specifiers may be mixed with type qualifiers appearing inside
+the '[]' of a parameter array declarator, in the C99 construct by which
+such qualifiers are applied to the pointer to which the array is
+implicitly converted.  Such attribute specifiers apply to the pointer,
+not to the array, but at present this is not implemented and they are
+ignored.
+
+ An attribute specifier list may appear at the start of a nested
+declarator.  At present, there are some limitations in this usage: the
+attributes correctly apply to the declarator, but for most individual
+attributes the semantics this implies are not implemented.  When
+attribute specifiers follow the '*' of a pointer declarator, they may be
+mixed with any type qualifiers present.  The following describes the
+formal semantics of this syntax.  It makes the most sense if you are
+familiar with the formal specification of declarators in the ISO C
+standard.
+
+ Consider (as in C99 subclause 6.7.5 paragraph 4) a declaration 'T D1',
+where 'T' contains declaration specifiers that specify a type TYPE (such
+as 'int') and 'D1' is a declarator that contains an identifier IDENT.
+The type specified for IDENT for derived declarators whose type does not
+include an attribute specifier is as in the ISO C standard.
+
+ If 'D1' has the form '( ATTRIBUTE-SPECIFIER-LIST D )', and the
+declaration 'T D' specifies the type "DERIVED-DECLARATOR-TYPE-LIST TYPE"
+for IDENT, then 'T D1' specifies the type "DERIVED-DECLARATOR-TYPE-LIST
+ATTRIBUTE-SPECIFIER-LIST TYPE" for IDENT.
+
+ If 'D1' has the form '* TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST D',
+and the declaration 'T D' specifies the type
+"DERIVED-DECLARATOR-TYPE-LIST TYPE" for IDENT, then 'T D1' specifies the
+type "DERIVED-DECLARATOR-TYPE-LIST
+TYPE-QUALIFIER-AND-ATTRIBUTE-SPECIFIER-LIST pointer to TYPE" for IDENT.
+
+ For example,
+
+     void (__attribute__((noreturn)) ****f) (void);
+
+specifies the type "pointer to pointer to pointer to pointer to
+non-returning function returning 'void'".  As another example,
+
+     char *__attribute__((aligned(8))) *f;
+
+specifies the type "pointer to 8-byte-aligned pointer to 'char'".  Note
+again that this does not work with most attributes; for example, the
+usage of 'aligned' and 'noreturn' attributes given above is not yet
+supported.
+
+ For compatibility with existing code written for compiler versions that
+did not implement attributes on nested declarators, some laxity is
+allowed in the placing of attributes.  If an attribute that only applies
+to types is applied to a declaration, it is treated as applying to the
+type of that declaration.  If an attribute that only applies to
+declarations is applied to the type of a declaration, it is treated as
+applying to that declaration; and, for compatibility with code placing
+the attributes immediately before the identifier declared, such an
+attribute applied to a function return type is treated as applying to
+the function type, and such an attribute applied to an array element
+type is treated as applying to the array type.  If an attribute that
+only applies to function types is applied to a pointer-to-function type,
+it is treated as applying to the pointer target type; if such an
+attribute is applied to a function return type that is not a
+pointer-to-function type, it is treated as applying to the function
+type.
+
+
+File: gcc.info,  Node: Function Prototypes,  Next: C++ Comments,  Prev: Attribute Syntax,  Up: C Extensions
+
+6.32 Prototypes and Old-Style Function Definitions
+==================================================
+
+GNU C extends ISO C to allow a function prototype to override a later
+old-style non-prototype definition.  Consider the following example:
+
+     /* Use prototypes unless the compiler is old-fashioned.  */
+     #ifdef __STDC__
+     #define P(x) x
+     #else
+     #define P(x) ()
+     #endif
+
+     /* Prototype function declaration.  */
+     int isroot P((uid_t));
+
+     /* Old-style function definition.  */
+     int
+     isroot (x)   /* ??? lossage here ??? */
+          uid_t x;
+     {
+       return x == 0;
+     }
+
+ Suppose the type 'uid_t' happens to be 'short'.  ISO C does not allow
+this example, because subword arguments in old-style non-prototype
+definitions are promoted.  Therefore in this example the function
+definition's argument is really an 'int', which does not match the
+prototype argument type of 'short'.
+
+ This restriction of ISO C makes it hard to write code that is portable
+to traditional C compilers, because the programmer does not know whether
+the 'uid_t' type is 'short', 'int', or 'long'.  Therefore, in cases like
+these GNU C allows a prototype to override a later old-style definition.
+More precisely, in GNU C, a function prototype argument type overrides
+the argument type specified by a later old-style definition if the
+former type is the same as the latter type before promotion.  Thus in
+GNU C the above example is equivalent to the following:
+
+     int isroot (uid_t);
+
+     int
+     isroot (uid_t x)
+     {
+       return x == 0;
+     }
+
+GNU C++ does not support old-style function definitions, so this
+extension is irrelevant.
+
+
+File: gcc.info,  Node: C++ Comments,  Next: Dollar Signs,  Prev: Function Prototypes,  Up: C Extensions
+
+6.33 C++ Style Comments
+=======================
+
+In GNU C, you may use C++ style comments, which start with '//' and
+continue until the end of the line.  Many other C implementations allow
+such comments, and they are included in the 1999 C standard.  However,
+C++ style comments are not recognized if you specify an '-std' option
+specifying a version of ISO C before C99, or '-ansi' (equivalent to
+'-std=c90').
+
+
+File: gcc.info,  Node: Dollar Signs,  Next: Character Escapes,  Prev: C++ Comments,  Up: C Extensions
+
+6.34 Dollar Signs in Identifier Names
+=====================================
+
+In GNU C, you may normally use dollar signs in identifier names.  This
+is because many traditional C implementations allow such identifiers.
+However, dollar signs in identifiers are not supported on a few target
+machines, typically because the target assembler does not allow them.
+
+
+File: gcc.info,  Node: Character Escapes,  Next: Variable Attributes,  Prev: Dollar Signs,  Up: C Extensions
+
+6.35 The Character <ESC> in Constants
+=====================================
+
+You can use the sequence '\e' in a string or character constant to stand
+for the ASCII character <ESC>.
+
+
+File: gcc.info,  Node: Variable Attributes,  Next: Type Attributes,  Prev: Character Escapes,  Up: C Extensions
+
+6.36 Specifying Attributes of Variables
+=======================================
+
+The keyword '__attribute__' allows you to specify special attributes of
+variables or structure fields.  This keyword is followed by an attribute
+specification inside double parentheses.  Some attributes are currently
+defined generically for variables.  Other attributes are defined for
+variables on particular target systems.  Other attributes are available
+for functions (*note Function Attributes::) and for types (*note Type
+Attributes::).  Other front ends might define more attributes (*note
+Extensions to the C++ Language: C++ Extensions.).
+
+ You may also specify attributes with '__' preceding and following each
+keyword.  This allows you to use them in header files without being
+concerned about a possible macro of the same name.  For example, you may
+use '__aligned__' instead of 'aligned'.
+
+ *Note Attribute Syntax::, for details of the exact syntax for using
+attributes.
+
+'aligned (ALIGNMENT)'
+     This attribute specifies a minimum alignment for the variable or
+     structure field, measured in bytes.  For example, the declaration:
+
+          int x __attribute__ ((aligned (16))) = 0;
+
+     causes the compiler to allocate the global variable 'x' on a
+     16-byte boundary.  On a 68040, this could be used in conjunction
+     with an 'asm' expression to access the 'move16' instruction which
+     requires 16-byte aligned operands.
+
+     You can also specify the alignment of structure fields.  For
+     example, to create a double-word aligned 'int' pair, you could
+     write:
+
+          struct foo { int x[2] __attribute__ ((aligned (8))); };
+
+     This is an alternative to creating a union with a 'double' member,
+     which forces the union to be double-word aligned.
+
+     As in the preceding examples, you can explicitly specify the
+     alignment (in bytes) that you wish the compiler to use for a given
+     variable or structure field.  Alternatively, you can leave out the
+     alignment factor and just ask the compiler to align a variable or
+     field to the default alignment for the target architecture you are
+     compiling for.  The default alignment is sufficient for all scalar
+     types, but may not be enough for all vector types on a target that
+     supports vector operations.  The default alignment is fixed for a
+     particular target ABI.
+
+     GCC also provides a target specific macro '__BIGGEST_ALIGNMENT__',
+     which is the largest alignment ever used for any data type on the
+     target machine you are compiling for.  For example, you could
+     write:
+
+          short array[3] __attribute__ ((aligned (__BIGGEST_ALIGNMENT__)));
+
+     The compiler automatically sets the alignment for the declared
+     variable or field to '__BIGGEST_ALIGNMENT__'.  Doing this can often
+     make copy operations more efficient, because the compiler can use
+     whatever instructions copy the biggest chunks of memory when
+     performing copies to or from the variables or fields that you have
+     aligned this way.  Note that the value of '__BIGGEST_ALIGNMENT__'
+     may change depending on command-line options.
+
+     When used on a struct, or struct member, the 'aligned' attribute
+     can only increase the alignment; in order to decrease it, the
+     'packed' attribute must be specified as well.  When used as part of
+     a typedef, the 'aligned' attribute can both increase and decrease
+     alignment, and specifying the 'packed' attribute generates a
+     warning.
+
+     Note that the effectiveness of 'aligned' attributes may be limited
+     by inherent limitations in your linker.  On many systems, the
+     linker is only able to arrange for variables to be aligned up to a
+     certain maximum alignment.  (For some linkers, the maximum
+     supported alignment may be very very small.)  If your linker is
+     only able to align variables up to a maximum of 8-byte alignment,
+     then specifying 'aligned(16)' in an '__attribute__' still only
+     provides you with 8-byte alignment.  See your linker documentation
+     for further information.
+
+     The 'aligned' attribute can also be used for functions (*note
+     Function Attributes::.)
+
+'cleanup (CLEANUP_FUNCTION)'
+     The 'cleanup' attribute runs a function when the variable goes out
+     of scope.  This attribute can only be applied to auto function
+     scope variables; it may not be applied to parameters or variables
+     with static storage duration.  The function must take one
+     parameter, a pointer to a type compatible with the variable.  The
+     return value of the function (if any) is ignored.
+
+     If '-fexceptions' is enabled, then CLEANUP_FUNCTION is run during
+     the stack unwinding that happens during the processing of the
+     exception.  Note that the 'cleanup' attribute does not allow the
+     exception to be caught, only to perform an action.  It is undefined
+     what happens if CLEANUP_FUNCTION does not return normally.
+
+'common'
+'nocommon'
+     The 'common' attribute requests GCC to place a variable in "common"
+     storage.  The 'nocommon' attribute requests the opposite--to
+     allocate space for it directly.
+
+     These attributes override the default chosen by the '-fno-common'
+     and '-fcommon' flags respectively.
+
+'deprecated'
+'deprecated (MSG)'
+     The 'deprecated' attribute results in a warning if the variable is
+     used anywhere in the source file.  This is useful when identifying
+     variables that are expected to be removed in a future version of a
+     program.  The warning also includes the location of the declaration
+     of the deprecated variable, to enable users to easily find further
+     information about why the variable is deprecated, or what they
+     should do instead.  Note that the warning only occurs for uses:
+
+          extern int old_var __attribute__ ((deprecated));
+          extern int old_var;
+          int new_fn () { return old_var; }
+
+     results in a warning on line 3 but not line 2.  The optional MSG
+     argument, which must be a string, is printed in the warning if
+     present.
+
+     The 'deprecated' attribute can also be used for functions and types
+     (*note Function Attributes::, *note Type Attributes::.)
+
+'mode (MODE)'
+     This attribute specifies the data type for the
+     declaration--whichever type corresponds to the mode MODE.  This in
+     effect lets you request an integer or floating-point type according
+     to its width.
+
+     You may also specify a mode of 'byte' or '__byte__' to indicate the
+     mode corresponding to a one-byte integer, 'word' or '__word__' for
+     the mode of a one-word integer, and 'pointer' or '__pointer__' for
+     the mode used to represent pointers.
+
+'packed'
+     The 'packed' attribute specifies that a variable or structure field
+     should have the smallest possible alignment--one byte for a
+     variable, and one bit for a field, unless you specify a larger
+     value with the 'aligned' attribute.
+
+     Here is a structure in which the field 'x' is packed, so that it
+     immediately follows 'a':
+
+          struct foo
+          {
+            char a;
+            int x[2] __attribute__ ((packed));
+          };
+
+     _Note:_ The 4.1, 4.2 and 4.3 series of GCC ignore the 'packed'
+     attribute on bit-fields of type 'char'.  This has been fixed in GCC
+     4.4 but the change can lead to differences in the structure layout.
+     See the documentation of '-Wpacked-bitfield-compat' for more
+     information.
+
+'section ("SECTION-NAME")'
+     Normally, the compiler places the objects it generates in sections
+     like 'data' and 'bss'.  Sometimes, however, you need additional
+     sections, or you need certain particular variables to appear in
+     special sections, for example to map to special hardware.  The
+     'section' attribute specifies that a variable (or function) lives
+     in a particular section.  For example, this small program uses
+     several specific section names:
+
+          struct duart a __attribute__ ((section ("DUART_A"))) = { 0 };
+          struct duart b __attribute__ ((section ("DUART_B"))) = { 0 };
+          char stack[10000] __attribute__ ((section ("STACK"))) = { 0 };
+          int init_data __attribute__ ((section ("INITDATA")));
+
+          main()
+          {
+            /* Initialize stack pointer */
+            init_sp (stack + sizeof (stack));
+
+            /* Initialize initialized data */
+            memcpy (&init_data, &data, &edata - &data);
+
+            /* Turn on the serial ports */
+            init_duart (&a);
+            init_duart (&b);
+          }
+
+     Use the 'section' attribute with _global_ variables and not _local_
+     variables, as shown in the example.
+
+     You may use the 'section' attribute with initialized or
+     uninitialized global variables but the linker requires each object
+     be defined once, with the exception that uninitialized variables
+     tentatively go in the 'common' (or 'bss') section and can be
+     multiply "defined".  Using the 'section' attribute changes what
+     section the variable goes into and may cause the linker to issue an
+     error if an uninitialized variable has multiple definitions.  You
+     can force a variable to be initialized with the '-fno-common' flag
+     or the 'nocommon' attribute.
+
+     Some file formats do not support arbitrary sections so the
+     'section' attribute is not available on all platforms.  If you need
+     to map the entire contents of a module to a particular section,
+     consider using the facilities of the linker instead.
+
+'shared'
+     On Microsoft Windows, in addition to putting variable definitions
+     in a named section, the section can also be shared among all
+     running copies of an executable or DLL.  For example, this small
+     program defines shared data by putting it in a named section
+     'shared' and marking the section shareable:
+
+          int foo __attribute__((section ("shared"), shared)) = 0;
+
+          int
+          main()
+          {
+            /* Read and write foo.  All running
+               copies see the same value.  */
+            return 0;
+          }
+
+     You may only use the 'shared' attribute along with 'section'
+     attribute with a fully-initialized global definition because of the
+     way linkers work.  See 'section' attribute for more information.
+
+     The 'shared' attribute is only available on Microsoft Windows.
+
+'tls_model ("TLS_MODEL")'
+     The 'tls_model' attribute sets thread-local storage model (*note
+     Thread-Local::) of a particular '__thread' variable, overriding
+     '-ftls-model=' command-line switch on a per-variable basis.  The
+     TLS_MODEL argument should be one of 'global-dynamic',
+     'local-dynamic', 'initial-exec' or 'local-exec'.
+
+     Not all targets support this attribute.
+
+'unused'
+     This attribute, attached to a variable, means that the variable is
+     meant to be possibly unused.  GCC does not produce a warning for
+     this variable.
+
+'used'
+     This attribute, attached to a variable with the static storage,
+     means that the variable must be emitted even if it appears that the
+     variable is not referenced.
+
+     When applied to a static data member of a C++ class template, the
+     attribute also means that the member is instantiated if the class
+     itself is instantiated.
+
+'vector_size (BYTES)'
+     This attribute specifies the vector size for the variable, measured
+     in bytes.  For example, the declaration:
+
+          int foo __attribute__ ((vector_size (16)));
+
+     causes the compiler to set the mode for 'foo', to be 16 bytes,
+     divided into 'int' sized units.  Assuming a 32-bit int (a vector of
+     4 units of 4 bytes), the corresponding mode of 'foo' is V4SI.
+
+     This attribute is only applicable to integral and float scalars,
+     although arrays, pointers, and function return values are allowed
+     in conjunction with this construct.
+
+     Aggregates with this attribute are invalid, even if they are of the
+     same size as a corresponding scalar.  For example, the declaration:
+
+          struct S { int a; };
+          struct S  __attribute__ ((vector_size (16))) foo;
+
+     is invalid even if the size of the structure is the same as the
+     size of the 'int'.
+
+'selectany'
+     The 'selectany' attribute causes an initialized global variable to
+     have link-once semantics.  When multiple definitions of the
+     variable are encountered by the linker, the first is selected and
+     the remainder are discarded.  Following usage by the Microsoft
+     compiler, the linker is told _not_ to warn about size or content
+     differences of the multiple definitions.
+
+     Although the primary usage of this attribute is for POD types, the
+     attribute can also be applied to global C++ objects that are
+     initialized by a constructor.  In this case, the static
+     initialization and destruction code for the object is emitted in
+     each translation defining the object, but the calls to the
+     constructor and destructor are protected by a link-once guard
+     variable.
+
+     The 'selectany' attribute is only available on Microsoft Windows
+     targets.  You can use '__declspec (selectany)' as a synonym for
+     '__attribute__ ((selectany))' for compatibility with other
+     compilers.
+
+'weak'
+     The 'weak' attribute is described in *note Function Attributes::.
+
+'dllimport'
+     The 'dllimport' attribute is described in *note Function
+     Attributes::.
+
+'dllexport'
+     The 'dllexport' attribute is described in *note Function
+     Attributes::.
+
+6.36.1 AVR Variable Attributes
+------------------------------
+
+'progmem'
+     The 'progmem' attribute is used on the AVR to place read-only data
+     in the non-volatile program memory (flash).  The 'progmem'
+     attribute accomplishes this by putting respective variables into a
+     section whose name starts with '.progmem'.
+
+     This attribute works similar to the 'section' attribute but adds
+     additional checking.  Notice that just like the 'section'
+     attribute, 'progmem' affects the location of the data but not how
+     this data is accessed.
+
+     In order to read data located with the 'progmem' attribute (inline)
+     assembler must be used.
+          /* Use custom macros from AVR-LibC (http://nongnu.org/avr-libc/user-manual/) */
+          #include <avr/pgmspace.h>
+
+          /* Locate var in flash memory */
+          const int var[2] PROGMEM = { 1, 2 };
+
+          int read_var (int i)
+          {
+              /* Access var[] by accessor macro from avr/pgmspace.h */
+              return (int) pgm_read_word (& var[i]);
+          }
+
+     AVR is a Harvard architecture processor and data and read-only data
+     normally resides in the data memory (RAM).
+
+     See also the *note AVR Named Address Spaces:: section for an
+     alternate way to locate and access data in flash memory.
+
+6.36.2 Blackfin Variable Attributes
+-----------------------------------
+
+Three attributes are currently defined for the Blackfin.
+
+'l1_data'
+'l1_data_A'
+'l1_data_B'
+     Use these attributes on the Blackfin to place the variable into L1
+     Data SRAM. Variables with 'l1_data' attribute are put into the
+     specific section named '.l1.data'.  Those with 'l1_data_A'
+     attribute are put into the specific section named '.l1.data.A'.
+     Those with 'l1_data_B' attribute are put into the specific section
+     named '.l1.data.B'.
+
+'l2'
+     Use this attribute on the Blackfin to place the variable into L2
+     SRAM. Variables with 'l2' attribute are put into the specific
+     section named '.l2.data'.
+
+6.36.3 M32R/D Variable Attributes
+---------------------------------
+
+One attribute is currently defined for the M32R/D.
+
+'model (MODEL-NAME)'
+     Use this attribute on the M32R/D to set the addressability of an
+     object.  The identifier MODEL-NAME is one of 'small', 'medium', or
+     'large', representing each of the code models.
+
+     Small model objects live in the lower 16MB of memory (so that their
+     addresses can be loaded with the 'ld24' instruction).
+
+     Medium and large model objects may live anywhere in the 32-bit
+     address space (the compiler generates 'seth/add3' instructions to
+     load their addresses).
+
+6.36.4 MeP Variable Attributes
+------------------------------
+
+The MeP target has a number of addressing modes and busses.  The 'near'
+space spans the standard memory space's first 16 megabytes (24 bits).
+The 'far' space spans the entire 32-bit memory space.  The 'based' space
+is a 128-byte region in the memory space that is addressed relative to
+the '$tp' register.  The 'tiny' space is a 65536-byte region relative to
+the '$gp' register.  In addition to these memory regions, the MeP target
+has a separate 16-bit control bus which is specified with 'cb'
+attributes.
+
+'based'
+     Any variable with the 'based' attribute is assigned to the '.based'
+     section, and is accessed with relative to the '$tp' register.
+
+'tiny'
+     Likewise, the 'tiny' attribute assigned variables to the '.tiny'
+     section, relative to the '$gp' register.
+
+'near'
+     Variables with the 'near' attribute are assumed to have addresses
+     that fit in a 24-bit addressing mode.  This is the default for
+     large variables ('-mtiny=4' is the default) but this attribute can
+     override '-mtiny=' for small variables, or override '-ml'.
+
+'far'
+     Variables with the 'far' attribute are addressed using a full
+     32-bit address.  Since this covers the entire memory space, this
+     allows modules to make no assumptions about where variables might
+     be stored.
+
+'io'
+'io (ADDR)'
+     Variables with the 'io' attribute are used to address memory-mapped
+     peripherals.  If an address is specified, the variable is assigned
+     that address, else it is not assigned an address (it is assumed
+     some other module assigns an address).  Example:
+
+          int timer_count __attribute__((io(0x123)));
+
+'cb'
+'cb (ADDR)'
+     Variables with the 'cb' attribute are used to access the control
+     bus, using special instructions.  'addr' indicates the control bus
+     address.  Example:
+
+          int cpu_clock __attribute__((cb(0x123)));
+
+6.36.5 i386 Variable Attributes
+-------------------------------
+
+Two attributes are currently defined for i386 configurations:
+'ms_struct' and 'gcc_struct'
+
+'ms_struct'
+'gcc_struct'
+
+     If 'packed' is used on a structure, or if bit-fields are used, it
+     may be that the Microsoft ABI lays out the structure differently
+     than the way GCC normally does.  Particularly when moving packed
+     data between functions compiled with GCC and the native Microsoft
+     compiler (either via function call or as data in a file), it may be
+     necessary to access either format.
+
+     Currently '-m[no-]ms-bitfields' is provided for the Microsoft
+     Windows X86 compilers to match the native Microsoft compiler.
+
+     The Microsoft structure layout algorithm is fairly simple with the
+     exception of the bit-field packing.  The padding and alignment of
+     members of structures and whether a bit-field can straddle a
+     storage-unit boundary are determine by these rules:
+
+       1. Structure members are stored sequentially in the order in
+          which they are declared: the first member has the lowest
+          memory address and the last member the highest.
+
+       2. Every data object has an alignment requirement.  The alignment
+          requirement for all data except structures, unions, and arrays
+          is either the size of the object or the current packing size
+          (specified with either the 'aligned' attribute or the 'pack'
+          pragma), whichever is less.  For structures, unions, and
+          arrays, the alignment requirement is the largest alignment
+          requirement of its members.  Every object is allocated an
+          offset so that:
+
+               offset % alignment_requirement == 0
+
+       3. Adjacent bit-fields are packed into the same 1-, 2-, or 4-byte
+          allocation unit if the integral types are the same size and if
+          the next bit-field fits into the current allocation unit
+          without crossing the boundary imposed by the common alignment
+          requirements of the bit-fields.
+
+     MSVC interprets zero-length bit-fields in the following ways:
+
+       1. If a zero-length bit-field is inserted between two bit-fields
+          that are normally coalesced, the bit-fields are not coalesced.
+
+          For example:
+
+               struct
+                {
+                  unsigned long bf_1 : 12;
+                  unsigned long : 0;
+                  unsigned long bf_2 : 12;
+                } t1;
+
+          The size of 't1' is 8 bytes with the zero-length bit-field.
+          If the zero-length bit-field were removed, 't1''s size would
+          be 4 bytes.
+
+       2. If a zero-length bit-field is inserted after a bit-field,
+          'foo', and the alignment of the zero-length bit-field is
+          greater than the member that follows it, 'bar', 'bar' is
+          aligned as the type of the zero-length bit-field.
+
+          For example:
+
+               struct
+                {
+                  char foo : 4;
+                  short : 0;
+                  char bar;
+                } t2;
+
+               struct
+                {
+                  char foo : 4;
+                  short : 0;
+                  double bar;
+                } t3;
+
+          For 't2', 'bar' is placed at offset 2, rather than offset 1.
+          Accordingly, the size of 't2' is 4.  For 't3', the zero-length
+          bit-field does not affect the alignment of 'bar' or, as a
+          result, the size of the structure.
+
+          Taking this into account, it is important to note the
+          following:
+
+            1. If a zero-length bit-field follows a normal bit-field,
+               the type of the zero-length bit-field may affect the
+               alignment of the structure as whole.  For example, 't2'
+               has a size of 4 bytes, since the zero-length bit-field
+               follows a normal bit-field, and is of type short.
+
+            2. Even if a zero-length bit-field is not followed by a
+               normal bit-field, it may still affect the alignment of
+               the structure:
+
+                    struct
+                     {
+                       char foo : 6;
+                       long : 0;
+                     } t4;
+
+               Here, 't4' takes up 4 bytes.
+
+       3. Zero-length bit-fields following non-bit-field members are
+          ignored:
+
+               struct
+                {
+                  char foo;
+                  long : 0;
+                  char bar;
+                } t5;
+
+          Here, 't5' takes up 2 bytes.
+
+6.36.6 PowerPC Variable Attributes
+----------------------------------
+
+Three attributes currently are defined for PowerPC configurations:
+'altivec', 'ms_struct' and 'gcc_struct'.
+
+ For full documentation of the struct attributes please see the
+documentation in *note i386 Variable Attributes::.
+
+ For documentation of 'altivec' attribute please see the documentation
+in *note PowerPC Type Attributes::.
+
+6.36.7 SPU Variable Attributes
+------------------------------
+
+The SPU supports the 'spu_vector' attribute for variables.  For
+documentation of this attribute please see the documentation in *note
+SPU Type Attributes::.
+
+6.36.8 Xstormy16 Variable Attributes
+------------------------------------
+
+One attribute is currently defined for xstormy16 configurations:
+'below100'.
+
+'below100'
+
+     If a variable has the 'below100' attribute ('BELOW100' is allowed
+     also), GCC places the variable in the first 0x100 bytes of memory
+     and use special opcodes to access it.  Such variables are placed in
+     either the '.bss_below100' section or the '.data_below100' section.
+
+
+File: gcc.info,  Node: Type Attributes,  Next: Alignment,  Prev: Variable Attributes,  Up: C Extensions
+
+6.37 Specifying Attributes of Types
+===================================
+
+The keyword '__attribute__' allows you to specify special attributes of
+'struct' and 'union' types when you define such types.  This keyword is
+followed by an attribute specification inside double parentheses.  Seven
+attributes are currently defined for types: 'aligned', 'packed',
+'transparent_union', 'unused', 'deprecated', 'visibility', and
+'may_alias'.  Other attributes are defined for functions (*note Function
+Attributes::) and for variables (*note Variable Attributes::).
+
+ You may also specify any one of these attributes with '__' preceding
+and following its keyword.  This allows you to use these attributes in
+header files without being concerned about a possible macro of the same
+name.  For example, you may use '__aligned__' instead of 'aligned'.
+
+ You may specify type attributes in an enum, struct or union type
+declaration or definition, or for other types in a 'typedef'
+declaration.
+
+ For an enum, struct or union type, you may specify attributes either
+between the enum, struct or union tag and the name of the type, or just
+past the closing curly brace of the _definition_.  The former syntax is
+preferred.
+
+ *Note Attribute Syntax::, for details of the exact syntax for using
+attributes.
+
+'aligned (ALIGNMENT)'
+     This attribute specifies a minimum alignment (in bytes) for
+     variables of the specified type.  For example, the declarations:
+
+          struct S { short f[3]; } __attribute__ ((aligned (8)));
+          typedef int more_aligned_int __attribute__ ((aligned (8)));
+
+     force the compiler to ensure (as far as it can) that each variable
+     whose type is 'struct S' or 'more_aligned_int' is allocated and
+     aligned _at least_ on a 8-byte boundary.  On a SPARC, having all
+     variables of type 'struct S' aligned to 8-byte boundaries allows
+     the compiler to use the 'ldd' and 'std' (doubleword load and store)
+     instructions when copying one variable of type 'struct S' to
+     another, thus improving run-time efficiency.
+
+     Note that the alignment of any given 'struct' or 'union' type is
+     required by the ISO C standard to be at least a perfect multiple of
+     the lowest common multiple of the alignments of all of the members
+     of the 'struct' or 'union' in question.  This means that you _can_
+     effectively adjust the alignment of a 'struct' or 'union' type by
+     attaching an 'aligned' attribute to any one of the members of such
+     a type, but the notation illustrated in the example above is a more
+     obvious, intuitive, and readable way to request the compiler to
+     adjust the alignment of an entire 'struct' or 'union' type.
+
+     As in the preceding example, you can explicitly specify the
+     alignment (in bytes) that you wish the compiler to use for a given
+     'struct' or 'union' type.  Alternatively, you can leave out the
+     alignment factor and just ask the compiler to align a type to the
+     maximum useful alignment for the target machine you are compiling
+     for.  For example, you could write:
+
+          struct S { short f[3]; } __attribute__ ((aligned));
+
+     Whenever you leave out the alignment factor in an 'aligned'
+     attribute specification, the compiler automatically sets the
+     alignment for the type to the largest alignment that is ever used
+     for any data type on the target machine you are compiling for.
+     Doing this can often make copy operations more efficient, because
+     the compiler can use whatever instructions copy the biggest chunks
+     of memory when performing copies to or from the variables that have
+     types that you have aligned this way.
+
+     In the example above, if the size of each 'short' is 2 bytes, then
+     the size of the entire 'struct S' type is 6 bytes.  The smallest
+     power of two that is greater than or equal to that is 8, so the
+     compiler sets the alignment for the entire 'struct S' type to 8
+     bytes.
+
+     Note that although you can ask the compiler to select a
+     time-efficient alignment for a given type and then declare only
+     individual stand-alone objects of that type, the compiler's ability
+     to select a time-efficient alignment is primarily useful only when
+     you plan to create arrays of variables having the relevant
+     (efficiently aligned) type.  If you declare or use arrays of
+     variables of an efficiently-aligned type, then it is likely that
+     your program also does pointer arithmetic (or subscripting, which
+     amounts to the same thing) on pointers to the relevant type, and
+     the code that the compiler generates for these pointer arithmetic
+     operations is often more efficient for efficiently-aligned types
+     than for other types.
+
+     The 'aligned' attribute can only increase the alignment; but you
+     can decrease it by specifying 'packed' as well.  See below.
+
+     Note that the effectiveness of 'aligned' attributes may be limited
+     by inherent limitations in your linker.  On many systems, the
+     linker is only able to arrange for variables to be aligned up to a
+     certain maximum alignment.  (For some linkers, the maximum
+     supported alignment may be very very small.)  If your linker is
+     only able to align variables up to a maximum of 8-byte alignment,
+     then specifying 'aligned(16)' in an '__attribute__' still only
+     provides you with 8-byte alignment.  See your linker documentation
+     for further information.
+
+'packed'
+     This attribute, attached to 'struct' or 'union' type definition,
+     specifies that each member (other than zero-width bit-fields) of
+     the structure or union is placed to minimize the memory required.
+     When attached to an 'enum' definition, it indicates that the
+     smallest integral type should be used.
+
+     Specifying this attribute for 'struct' and 'union' types is
+     equivalent to specifying the 'packed' attribute on each of the
+     structure or union members.  Specifying the '-fshort-enums' flag on
+     the line is equivalent to specifying the 'packed' attribute on all
+     'enum' definitions.
+
+     In the following example 'struct my_packed_struct''s members are
+     packed closely together, but the internal layout of its 's' member
+     is not packed--to do that, 'struct my_unpacked_struct' needs to be
+     packed too.
+
+          struct my_unpacked_struct
+           {
+              char c;
+              int i;
+           };
+
+          struct __attribute__ ((__packed__)) my_packed_struct
+            {
+               char c;
+               int  i;
+               struct my_unpacked_struct s;
+            };
+
+     You may only specify this attribute on the definition of an 'enum',
+     'struct' or 'union', not on a 'typedef' that does not also define
+     the enumerated type, structure or union.
+
+'transparent_union'
+     This attribute, attached to a 'union' type definition, indicates
+     that any function parameter having that union type causes calls to
+     that function to be treated in a special way.
+
+     First, the argument corresponding to a transparent union type can
+     be of any type in the union; no cast is required.  Also, if the
+     union contains a pointer type, the corresponding argument can be a
+     null pointer constant or a void pointer expression; and if the
+     union contains a void pointer type, the corresponding argument can
+     be any pointer expression.  If the union member type is a pointer,
+     qualifiers like 'const' on the referenced type must be respected,
+     just as with normal pointer conversions.
+
+     Second, the argument is passed to the function using the calling
+     conventions of the first member of the transparent union, not the
+     calling conventions of the union itself.  All members of the union
+     must have the same machine representation; this is necessary for
+     this argument passing to work properly.
+
+     Transparent unions are designed for library functions that have
+     multiple interfaces for compatibility reasons.  For example,
+     suppose the 'wait' function must accept either a value of type 'int
+     *' to comply with POSIX, or a value of type 'union wait *' to
+     comply with the 4.1BSD interface.  If 'wait''s parameter were 'void
+     *', 'wait' would accept both kinds of arguments, but it would also
+     accept any other pointer type and this would make argument type
+     checking less useful.  Instead, '<sys/wait.h>' might define the
+     interface as follows:
+
+          typedef union __attribute__ ((__transparent_union__))
+            {
+              int *__ip;
+              union wait *__up;
+            } wait_status_ptr_t;
+
+          pid_t wait (wait_status_ptr_t);
+
+     This interface allows either 'int *' or 'union wait *' arguments to
+     be passed, using the 'int *' calling convention.  The program can
+     call 'wait' with arguments of either type:
+
+          int w1 () { int w; return wait (&w); }
+          int w2 () { union wait w; return wait (&w); }
+
+     With this interface, 'wait''s implementation might look like this:
+
+          pid_t wait (wait_status_ptr_t p)
+          {
+            return waitpid (-1, p.__ip, 0);
+          }
+
+'unused'
+     When attached to a type (including a 'union' or a 'struct'), this
+     attribute means that variables of that type are meant to appear
+     possibly unused.  GCC does not produce a warning for any variables
+     of that type, even if the variable appears to do nothing.  This is
+     often the case with lock or thread classes, which are usually
+     defined and then not referenced, but contain constructors and
+     destructors that have nontrivial bookkeeping functions.
+
+'deprecated'
+'deprecated (MSG)'
+     The 'deprecated' attribute results in a warning if the type is used
+     anywhere in the source file.  This is useful when identifying types
+     that are expected to be removed in a future version of a program.
+     If possible, the warning also includes the location of the
+     declaration of the deprecated type, to enable users to easily find
+     further information about why the type is deprecated, or what they
+     should do instead.  Note that the warnings only occur for uses and
+     then only if the type is being applied to an identifier that itself
+     is not being declared as deprecated.
+
+          typedef int T1 __attribute__ ((deprecated));
+          T1 x;
+          typedef T1 T2;
+          T2 y;
+          typedef T1 T3 __attribute__ ((deprecated));
+          T3 z __attribute__ ((deprecated));
+
+     results in a warning on line 2 and 3 but not lines 4, 5, or 6.  No
+     warning is issued for line 4 because T2 is not explicitly
+     deprecated.  Line 5 has no warning because T3 is explicitly
+     deprecated.  Similarly for line 6.  The optional MSG argument,
+     which must be a string, is printed in the warning if present.
+
+     The 'deprecated' attribute can also be used for functions and
+     variables (*note Function Attributes::, *note Variable
+     Attributes::.)
+
+'may_alias'
+     Accesses through pointers to types with this attribute are not
+     subject to type-based alias analysis, but are instead assumed to be
+     able to alias any other type of objects.  In the context of section
+     6.5 paragraph 7 of the C99 standard, an lvalue expression
+     dereferencing such a pointer is treated like having a character
+     type.  See '-fstrict-aliasing' for more information on aliasing
+     issues.  This extension exists to support some vector APIs, in
+     which pointers to one vector type are permitted to alias pointers
+     to a different vector type.
+
+     Note that an object of a type with this attribute does not have any
+     special semantics.
+
+     Example of use:
+
+          typedef short __attribute__((__may_alias__)) short_a;
+
+          int
+          main (void)
+          {
+            int a = 0x12345678;
+            short_a *b = (short_a *) &a;
+
+            b[1] = 0;
+
+            if (a == 0x12345678)
+              abort();
+
+            exit(0);
+          }
+
+     If you replaced 'short_a' with 'short' in the variable declaration,
+     the above program would abort when compiled with
+     '-fstrict-aliasing', which is on by default at '-O2' or above in
+     recent GCC versions.
+
+'visibility'
+     In C++, attribute visibility (*note Function Attributes::) can also
+     be applied to class, struct, union and enum types.  Unlike other
+     type attributes, the attribute must appear between the initial
+     keyword and the name of the type; it cannot appear after the body
+     of the type.
+
+     Note that the type visibility is applied to vague linkage entities
+     associated with the class (vtable, typeinfo node, etc.).  In
+     particular, if a class is thrown as an exception in one shared
+     object and caught in another, the class must have default
+     visibility.  Otherwise the two shared objects are unable to use the
+     same typeinfo node and exception handling will break.
+
+ To specify multiple attributes, separate them by commas within the
+double parentheses: for example, '__attribute__ ((aligned (16),
+packed))'.
+
+6.37.1 ARM Type Attributes
+--------------------------
+
+On those ARM targets that support 'dllimport' (such as Symbian OS), you
+can use the 'notshared' attribute to indicate that the virtual table and
+other similar data for a class should not be exported from a DLL.  For
+example:
+
+     class __declspec(notshared) C {
+     public:
+       __declspec(dllimport) C();
+       virtual void f();
+     }
+
+     __declspec(dllexport)
+     C::C() {}
+
+In this code, 'C::C' is exported from the current DLL, but the virtual
+table for 'C' is not exported.  (You can use '__attribute__' instead of
+'__declspec' if you prefer, but most Symbian OS code uses '__declspec'.)
+
+6.37.2 MeP Type Attributes
+--------------------------
+
+Many of the MeP variable attributes may be applied to types as well.
+Specifically, the 'based', 'tiny', 'near', and 'far' attributes may be
+applied to either.  The 'io' and 'cb' attributes may not be applied to
+types.
+
+6.37.3 i386 Type Attributes
+---------------------------
+
+Two attributes are currently defined for i386 configurations:
+'ms_struct' and 'gcc_struct'.
+
+'ms_struct'
+'gcc_struct'
+
+     If 'packed' is used on a structure, or if bit-fields are used it
+     may be that the Microsoft ABI packs them differently than GCC
+     normally packs them.  Particularly when moving packed data between
+     functions compiled with GCC and the native Microsoft compiler
+     (either via function call or as data in a file), it may be
+     necessary to access either format.
+
+     Currently '-m[no-]ms-bitfields' is provided for the Microsoft
+     Windows X86 compilers to match the native Microsoft compiler.
+
+6.37.4 PowerPC Type Attributes
+------------------------------
+
+Three attributes currently are defined for PowerPC configurations:
+'altivec', 'ms_struct' and 'gcc_struct'.
+
+ For full documentation of the 'ms_struct' and 'gcc_struct' attributes
+please see the documentation in *note i386 Type Attributes::.
+
+ The 'altivec' attribute allows one to declare AltiVec vector data types
+supported by the AltiVec Programming Interface Manual.  The attribute
+requires an argument to specify one of three vector types: 'vector__',
+'pixel__' (always followed by unsigned short), and 'bool__' (always
+followed by unsigned).
+
+     __attribute__((altivec(vector__)))
+     __attribute__((altivec(pixel__))) unsigned short
+     __attribute__((altivec(bool__))) unsigned
+
+ These attributes mainly are intended to support the '__vector',
+'__pixel', and '__bool' AltiVec keywords.
+
+6.37.5 SPU Type Attributes
+--------------------------
+
+The SPU supports the 'spu_vector' attribute for types.  This attribute
+allows one to declare vector data types supported by the
+Sony/Toshiba/IBM SPU Language Extensions Specification.  It is intended
+to support the '__vector' keyword.
+
+
+File: gcc.info,  Node: Alignment,  Next: Inline,  Prev: Type Attributes,  Up: C Extensions
+
+6.38 Inquiring on Alignment of Types or Variables
+=================================================
+
+The keyword '__alignof__' allows you to inquire about how an object is
+aligned, or the minimum alignment usually required by a type.  Its
+syntax is just like 'sizeof'.
+
+ For example, if the target machine requires a 'double' value to be
+aligned on an 8-byte boundary, then '__alignof__ (double)' is 8.  This
+is true on many RISC machines.  On more traditional machine designs,
+'__alignof__ (double)' is 4 or even 2.
+
+ Some machines never actually require alignment; they allow reference to
+any data type even at an odd address.  For these machines, '__alignof__'
+reports the smallest alignment that GCC gives the data type, usually as
+mandated by the target ABI.
+
+ If the operand of '__alignof__' is an lvalue rather than a type, its
+value is the required alignment for its type, taking into account any
+minimum alignment specified with GCC's '__attribute__' extension (*note
+Variable Attributes::).  For example, after this declaration:
+
+     struct foo { int x; char y; } foo1;
+
+the value of '__alignof__ (foo1.y)' is 1, even though its actual
+alignment is probably 2 or 4, the same as '__alignof__ (int)'.
+
+ It is an error to ask for the alignment of an incomplete type.
+
+
+File: gcc.info,  Node: Inline,  Next: Volatiles,  Prev: Alignment,  Up: C Extensions
+
+6.39 An Inline Function is As Fast As a Macro
+=============================================
+
+By declaring a function inline, you can direct GCC to make calls to that
+function faster.  One way GCC can achieve this is to integrate that
+function's code into the code for its callers.  This makes execution
+faster by eliminating the function-call overhead; in addition, if any of
+the actual argument values are constant, their known values may permit
+simplifications at compile time so that not all of the inline function's
+code needs to be included.  The effect on code size is less predictable;
+object code may be larger or smaller with function inlining, depending
+on the particular case.  You can also direct GCC to try to integrate all
+"simple enough" functions into their callers with the option
+'-finline-functions'.
+
+ GCC implements three different semantics of declaring a function
+inline.  One is available with '-std=gnu89' or '-fgnu89-inline' or when
+'gnu_inline' attribute is present on all inline declarations, another
+when '-std=c99', '-std=c11', '-std=gnu99' or '-std=gnu11' (without
+'-fgnu89-inline'), and the third is used when compiling C++.
+
+ To declare a function inline, use the 'inline' keyword in its
+declaration, like this:
+
+     static inline int
+     inc (int *a)
+     {
+       return (*a)++;
+     }
+
+ If you are writing a header file to be included in ISO C90 programs,
+write '__inline__' instead of 'inline'.  *Note Alternate Keywords::.
+
+ The three types of inlining behave similarly in two important cases:
+when the 'inline' keyword is used on a 'static' function, like the
+example above, and when a function is first declared without using the
+'inline' keyword and then is defined with 'inline', like this:
+
+     extern int inc (int *a);
+     inline int
+     inc (int *a)
+     {
+       return (*a)++;
+     }
+
+ In both of these common cases, the program behaves the same as if you
+had not used the 'inline' keyword, except for its speed.
+
+ When a function is both inline and 'static', if all calls to the
+function are integrated into the caller, and the function's address is
+never used, then the function's own assembler code is never referenced.
+In this case, GCC does not actually output assembler code for the
+function, unless you specify the option '-fkeep-inline-functions'.  Some
+calls cannot be integrated for various reasons (in particular, calls
+that precede the function's definition cannot be integrated, and neither
+can recursive calls within the definition).  If there is a nonintegrated
+call, then the function is compiled to assembler code as usual.  The
+function must also be compiled as usual if the program refers to its
+address, because that can't be inlined.
+
+ Note that certain usages in a function definition can make it
+unsuitable for inline substitution.  Among these usages are: variadic
+functions, use of 'alloca', use of variable-length data types (*note
+Variable Length::), use of computed goto (*note Labels as Values::), use
+of nonlocal goto, and nested functions (*note Nested Functions::).
+Using '-Winline' warns when a function marked 'inline' could not be
+substituted, and gives the reason for the failure.
+
+ As required by ISO C++, GCC considers member functions defined within
+the body of a class to be marked inline even if they are not explicitly
+declared with the 'inline' keyword.  You can override this with
+'-fno-default-inline'; *note Options Controlling C++ Dialect: C++
+Dialect Options.
+
+ GCC does not inline any functions when not optimizing unless you
+specify the 'always_inline' attribute for the function, like this:
+
+     /* Prototype.  */
+     inline void foo (const char) __attribute__((always_inline));
+
+ The remainder of this section is specific to GNU C90 inlining.
+
+ When an inline function is not 'static', then the compiler must assume
+that there may be calls from other source files; since a global symbol
+can be defined only once in any program, the function must not be
+defined in the other source files, so the calls therein cannot be
+integrated.  Therefore, a non-'static' inline function is always
+compiled on its own in the usual fashion.
+
+ If you specify both 'inline' and 'extern' in the function definition,
+then the definition is used only for inlining.  In no case is the
+function compiled on its own, not even if you refer to its address
+explicitly.  Such an address becomes an external reference, as if you
+had only declared the function, and had not defined it.
+
+ This combination of 'inline' and 'extern' has almost the effect of a
+macro.  The way to use it is to put a function definition in a header
+file with these keywords, and put another copy of the definition
+(lacking 'inline' and 'extern') in a library file.  The definition in
+the header file causes most calls to the function to be inlined.  If any
+uses of the function remain, they refer to the single copy in the
+library.
+
+
+File: gcc.info,  Node: Volatiles,  Next: Extended Asm,  Prev: Inline,  Up: C Extensions
+
+6.40 When is a Volatile Object Accessed?
+========================================
+
+C has the concept of volatile objects.  These are normally accessed by
+pointers and used for accessing hardware or inter-thread communication.
+The standard encourages compilers to refrain from optimizations
+concerning accesses to volatile objects, but leaves it implementation
+defined as to what constitutes a volatile access.  The minimum
+requirement is that at a sequence point all previous accesses to
+volatile objects have stabilized and no subsequent accesses have
+occurred.  Thus an implementation is free to reorder and combine
+volatile accesses that occur between sequence points, but cannot do so
+for accesses across a sequence point.  The use of volatile does not
+allow you to violate the restriction on updating objects multiple times
+between two sequence points.
+
+ Accesses to non-volatile objects are not ordered with respect to
+volatile accesses.  You cannot use a volatile object as a memory barrier
+to order a sequence of writes to non-volatile memory.  For instance:
+
+     int *ptr = SOMETHING;
+     volatile int vobj;
+     *ptr = SOMETHING;
+     vobj = 1;
+
+Unless *PTR and VOBJ can be aliased, it is not guaranteed that the write
+to *PTR occurs by the time the update of VOBJ happens.  If you need this
+guarantee, you must use a stronger memory barrier such as:
+
+     int *ptr = SOMETHING;
+     volatile int vobj;
+     *ptr = SOMETHING;
+     asm volatile ("" : : : "memory");
+     vobj = 1;
+
+ A scalar volatile object is read when it is accessed in a void context:
+
+     volatile int *src = SOMEVALUE;
+     *src;
+
+ Such expressions are rvalues, and GCC implements this as a read of the
+volatile object being pointed to.
+
+ Assignments are also expressions and have an rvalue.  However when
+assigning to a scalar volatile, the volatile object is not reread,
+regardless of whether the assignment expression's rvalue is used or not.
+If the assignment's rvalue is used, the value is that assigned to the
+volatile object.  For instance, there is no read of VOBJ in all the
+following cases:
+
+     int obj;
+     volatile int vobj;
+     vobj = SOMETHING;
+     obj = vobj = SOMETHING;
+     obj ? vobj = ONETHING : vobj = ANOTHERTHING;
+     obj = (SOMETHING, vobj = ANOTHERTHING);
+
+ If you need to read the volatile object after an assignment has
+occurred, you must use a separate expression with an intervening
+sequence point.
+
+ As bit-fields are not individually addressable, volatile bit-fields may
+be implicitly read when written to, or when adjacent bit-fields are
+accessed.  Bit-field operations may be optimized such that adjacent
+bit-fields are only partially accessed, if they straddle a storage unit
+boundary.  For these reasons it is unwise to use volatile bit-fields to
+access hardware.
+
+
+File: gcc.info,  Node: Extended Asm,  Next: Constraints,  Prev: Volatiles,  Up: C Extensions
+
+6.41 Assembler Instructions with C Expression Operands
+======================================================
+
+In an assembler instruction using 'asm', you can specify the operands of
+the instruction using C expressions.  This means you need not guess
+which registers or memory locations contain the data you want to use.
+
+ You must specify an assembler instruction template much like what
+appears in a machine description, plus an operand constraint string for
+each operand.
+
+ For example, here is how to use the 68881's 'fsinx' instruction:
+
+     asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
+
+Here 'angle' is the C expression for the input operand while 'result' is
+that of the output operand.  Each has '"f"' as its operand constraint,
+saying that a floating-point register is required.  The '=' in '=f'
+indicates that the operand is an output; all output operands'
+constraints must use '='.  The constraints use the same language used in
+the machine description (*note Constraints::).
+
+ Each operand is described by an operand-constraint string followed by
+the C expression in parentheses.  A colon separates the assembler
+template from the first output operand and another separates the last
+output operand from the first input, if any.  Commas separate the
+operands within each group.  The total number of operands is currently
+limited to 30; this limitation may be lifted in some future version of
+GCC.
+
+ If there are no output operands but there are input operands, you must
+place two consecutive colons surrounding the place where the output
+operands would go.
+
+ As of GCC version 3.1, it is also possible to specify input and output
+operands using symbolic names which can be referenced within the
+assembler code.  These names are specified inside square brackets
+preceding the constraint string, and can be referenced inside the
+assembler code using '%[NAME]' instead of a percentage sign followed by
+the operand number.  Using named operands the above example could look
+like:
+
+     asm ("fsinx %[angle],%[output]"
+          : [output] "=f" (result)
+          : [angle] "f" (angle));
+
+Note that the symbolic operand names have no relation whatsoever to
+other C identifiers.  You may use any name you like, even those of
+existing C symbols, but you must ensure that no two operands within the
+same assembler construct use the same symbolic name.
+
+ Output operand expressions must be lvalues; the compiler can check
+this.  The input operands need not be lvalues.  The compiler cannot
+check whether the operands have data types that are reasonable for the
+instruction being executed.  It does not parse the assembler instruction
+template and does not know what it means or even whether it is valid
+assembler input.  The extended 'asm' feature is most often used for
+machine instructions the compiler itself does not know exist.  If the
+output expression cannot be directly addressed (for example, it is a
+bit-field), your constraint must allow a register.  In that case, GCC
+uses the register as the output of the 'asm', and then stores that
+register into the output.
+
+ The ordinary output operands must be write-only; GCC assumes that the
+values in these operands before the instruction are dead and need not be
+generated.  Extended asm supports input-output or read-write operands.
+Use the constraint character '+' to indicate such an operand and list it
+with the output operands.
+
+ You may, as an alternative, logically split its function into two
+separate operands, one input operand and one write-only output operand.
+The connection between them is expressed by constraints that say they
+need to be in the same location when the instruction executes.  You can
+use the same C expression for both operands, or different expressions.
+For example, here we write the (fictitious) 'combine' instruction with
+'bar' as its read-only source operand and 'foo' as its read-write
+destination:
+
+     asm ("combine %2,%0" : "=r" (foo) : "0" (foo), "g" (bar));
+
+The constraint '"0"' for operand 1 says that it must occupy the same
+location as operand 0.  A number in constraint is allowed only in an
+input operand and it must refer to an output operand.
+
+ Only a number in the constraint can guarantee that one operand is in
+the same place as another.  The mere fact that 'foo' is the value of
+both operands is not enough to guarantee that they are in the same place
+in the generated assembler code.  The following does not work reliably:
+
+     asm ("combine %2,%0" : "=r" (foo) : "r" (foo), "g" (bar));
+
+ Various optimizations or reloading could cause operands 0 and 1 to be
+in different registers; GCC knows no reason not to do so.  For example,
+the compiler might find a copy of the value of 'foo' in one register and
+use it for operand 1, but generate the output operand 0 in a different
+register (copying it afterward to 'foo''s own address).  Of course,
+since the register for operand 1 is not even mentioned in the assembler
+code, the result will not work, but GCC can't tell that.
+
+ As of GCC version 3.1, one may write '[NAME]' instead of the operand
+number for a matching constraint.  For example:
+
+     asm ("cmoveq %1,%2,%[result]"
+          : [result] "=r"(result)
+          : "r" (test), "r"(new), "[result]"(old));
+
+ Sometimes you need to make an 'asm' operand be a specific register, but
+there's no matching constraint letter for that register _by itself_.  To
+force the operand into that register, use a local variable for the
+operand and specify the register in the variable declaration.  *Note
+Explicit Reg Vars::.  Then for the 'asm' operand, use any register
+constraint letter that matches the register:
+
+     register int *p1 asm ("r0") = ...;
+     register int *p2 asm ("r1") = ...;
+     register int *result asm ("r0");
+     asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
+
+ In the above example, beware that a register that is call-clobbered by
+the target ABI will be overwritten by any function call in the
+assignment, including library calls for arithmetic operators.  Also a
+register may be clobbered when generating some operations, like variable
+shift, memory copy or memory move on x86.  Assuming it is a
+call-clobbered register, this may happen to 'r0' above by the assignment
+to 'p2'.  If you have to use such a register, use temporary variables
+for expressions between the register assignment and use:
+
+     int t1 = ...;
+     register int *p1 asm ("r0") = ...;
+     register int *p2 asm ("r1") = t1;
+     register int *result asm ("r0");
+     asm ("sysint" : "=r" (result) : "0" (p1), "r" (p2));
+
+ Some instructions clobber specific hard registers.  To describe this,
+write a third colon after the input operands, followed by the names of
+the clobbered hard registers (given as strings).  Here is a realistic
+example for the VAX:
+
+     asm volatile ("movc3 %0,%1,%2"
+                   : /* no outputs */
+                   : "g" (from), "g" (to), "g" (count)
+                   : "r0", "r1", "r2", "r3", "r4", "r5");
+
+ You may not write a clobber description in a way that overlaps with an
+input or output operand.  For example, you may not have an operand
+describing a register class with one member if you mention that register
+in the clobber list.  Variables declared to live in specific registers
+(*note Explicit Reg Vars::), and used as asm input or output operands
+must have no part mentioned in the clobber description.  There is no way
+for you to specify that an input operand is modified without also
+specifying it as an output operand.  Note that if all the output
+operands you specify are for this purpose (and hence unused), you then
+also need to specify 'volatile' for the 'asm' construct, as described
+below, to prevent GCC from deleting the 'asm' statement as unused.
+
+ If you refer to a particular hardware register from the assembler code,
+you probably have to list the register after the third colon to tell the
+compiler the register's value is modified.  In some assemblers, the
+register names begin with '%'; to produce one '%' in the assembler code,
+you must write '%%' in the input.
+
+ If your assembler instruction can alter the condition code register,
+add 'cc' to the list of clobbered registers.  GCC on some machines
+represents the condition codes as a specific hardware register; 'cc'
+serves to name this register.  On other machines, the condition code is
+handled differently, and specifying 'cc' has no effect.  But it is valid
+no matter what the machine.
+
+ If your assembler instructions access memory in an unpredictable
+fashion, add 'memory' to the list of clobbered registers.  This causes
+GCC to not keep memory values cached in registers across the assembler
+instruction and not optimize stores or loads to that memory.  You also
+should add the 'volatile' keyword if the memory affected is not listed
+in the inputs or outputs of the 'asm', as the 'memory' clobber does not
+count as a side-effect of the 'asm'.  If you know how large the accessed
+memory is, you can add it as input or output but if this is not known,
+you should add 'memory'.  As an example, if you access ten bytes of a
+string, you can use a memory input like:
+
+     {"m"( ({ struct { char x[10]; } *p = (void *)ptr ; *p; }) )}.
+
+ Note that in the following example the memory input is necessary,
+otherwise GCC might optimize the store to 'x' away:
+     int foo ()
+     {
+       int x = 42;
+       int *y = &x;
+       int result;
+       asm ("magic stuff accessing an 'int' pointed to by '%1'"
+            : "=&d" (result) : "a" (y), "m" (*y));
+       return result;
+     }
+
+ You can put multiple assembler instructions together in a single 'asm'
+template, separated by the characters normally used in assembly code for
+the system.  A combination that works in most places is a newline to
+break the line, plus a tab character to move to the instruction field
+(written as '\n\t').  Sometimes semicolons can be used, if the assembler
+allows semicolons as a line-breaking character.  Note that some
+assembler dialects use semicolons to start a comment.  The input
+operands are guaranteed not to use any of the clobbered registers, and
+neither do the output operands' addresses, so you can read and write the
+clobbered registers as many times as you like.  Here is an example of
+multiple instructions in a template; it assumes the subroutine '_foo'
+accepts arguments in registers 9 and 10:
+
+     asm ("movl %0,r9\n\tmovl %1,r10\n\tcall _foo"
+          : /* no outputs */
+          : "g" (from), "g" (to)
+          : "r9", "r10");
+
+ Unless an output operand has the '&' constraint modifier, GCC may
+allocate it in the same register as an unrelated input operand, on the
+assumption the inputs are consumed before the outputs are produced.
+This assumption may be false if the assembler code actually consists of
+more than one instruction.  In such a case, use '&' for each output
+operand that may not overlap an input.  *Note Modifiers::.
+
+ If you want to test the condition code produced by an assembler
+instruction, you must include a branch and a label in the 'asm'
+construct, as follows:
+
+     asm ("clr %0\n\tfrob %1\n\tbeq 0f\n\tmov #1,%0\n0:"
+          : "g" (result)
+          : "g" (input));
+
+This assumes your assembler supports local labels, as the GNU assembler
+and most Unix assemblers do.
+
+ Speaking of labels, jumps from one 'asm' to another are not supported.
+The compiler's optimizers do not know about these jumps, and therefore
+they cannot take account of them when deciding how to optimize.  *Note
+Extended asm with goto::.
+
+ Usually the most convenient way to use these 'asm' instructions is to
+encapsulate them in macros that look like functions.  For example,
+
+     #define sin(x)       \
+     ({ double __value, __arg = (x);   \
+        asm ("fsinx %1,%0": "=f" (__value): "f" (__arg));  \
+        __value; })
+
+Here the variable '__arg' is used to make sure that the instruction
+operates on a proper 'double' value, and to accept only those arguments
+'x' that can convert automatically to a 'double'.
+
+ Another way to make sure the instruction operates on the correct data
+type is to use a cast in the 'asm'.  This is different from using a
+variable '__arg' in that it converts more different types.  For example,
+if the desired type is 'int', casting the argument to 'int' accepts a
+pointer with no complaint, while assigning the argument to an 'int'
+variable named '__arg' warns about using a pointer unless the caller
+explicitly casts it.
+
+ If an 'asm' has output operands, GCC assumes for optimization purposes
+the instruction has no side effects except to change the output
+operands.  This does not mean instructions with a side effect cannot be
+used, but you must be careful, because the compiler may eliminate them
+if the output operands aren't used, or move them out of loops, or
+replace two with one if they constitute a common subexpression.  Also,
+if your instruction does have a side effect on a variable that otherwise
+appears not to change, the old value of the variable may be reused later
+if it happens to be found in a register.
+
+ You can prevent an 'asm' instruction from being deleted by writing the
+keyword 'volatile' after the 'asm'.  For example:
+
+     #define get_and_set_priority(new)              \
+     ({ int __old;                                  \
+        asm volatile ("get_and_set_priority %0, %1" \
+                      : "=g" (__old) : "g" (new));  \
+        __old; })
+
+The 'volatile' keyword indicates that the instruction has important
+side-effects.  GCC does not delete a volatile 'asm' if it is reachable.
+(The instruction can still be deleted if GCC can prove that control flow
+never reaches the location of the instruction.)  Note that even a
+volatile 'asm' instruction can be moved relative to other code,
+including across jump instructions.  For example, on many targets there
+is a system register that can be set to control the rounding mode of
+floating-point operations.  You might try setting it with a volatile
+'asm', like this PowerPC example:
+
+            asm volatile("mtfsf 255,%0" : : "f" (fpenv));
+            sum = x + y;
+
+This does not work reliably, as the compiler may move the addition back
+before the volatile 'asm'.  To make it work you need to add an
+artificial dependency to the 'asm' referencing a variable in the code
+you don't want moved, for example:
+
+         asm volatile ("mtfsf 255,%1" : "=X"(sum): "f"(fpenv));
+         sum = x + y;
+
+ Similarly, you can't expect a sequence of volatile 'asm' instructions
+to remain perfectly consecutive.  If you want consecutive output, use a
+single 'asm'.  Also, GCC performs some optimizations across a volatile
+'asm' instruction; GCC does not "forget everything" when it encounters a
+volatile 'asm' instruction the way some other compilers do.
+
+ An 'asm' instruction without any output operands is treated identically
+to a volatile 'asm' instruction.
+
+ It is a natural idea to look for a way to give access to the condition
+code left by the assembler instruction.  However, when we attempted to
+implement this, we found no way to make it work reliably.  The problem
+is that output operands might need reloading, which result in additional
+following "store" instructions.  On most machines, these instructions
+alter the condition code before there is time to test it.  This problem
+doesn't arise for ordinary "test" and "compare" instructions because
+they don't have any output operands.
+
+ For reasons similar to those described above, it is not possible to
+give an assembler instruction access to the condition code left by
+previous instructions.
+
+ As of GCC version 4.5, 'asm goto' may be used to have the assembly jump
+to one or more C labels.  In this form, a fifth section after the
+clobber list contains a list of all C labels to which the assembly may
+jump.  Each label operand is implicitly self-named.  The 'asm' is also
+assumed to fall through to the next statement.
+
+ This form of 'asm' is restricted to not have outputs.  This is due to a
+internal restriction in the compiler that control transfer instructions
+cannot have outputs.  This restriction on 'asm goto' may be lifted in
+some future version of the compiler.  In the meantime, 'asm goto' may
+include a memory clobber, and so leave outputs in memory.
+
+     int frob(int x)
+     {
+       int y;
+       asm goto ("frob %%r5, %1; jc %l[error]; mov (%2), %%r5"
+                 : : "r"(x), "r"(&y) : "r5", "memory" : error);
+       return y;
+      error:
+       return -1;
+     }
+
+In this (inefficient) example, the 'frob' instruction sets the carry bit
+to indicate an error.  The 'jc' instruction detects this and branches to
+the 'error' label.  Finally, the output of the 'frob' instruction
+('%r5') is stored into the memory for variable 'y', which is later read
+by the 'return' statement.
+
+     void doit(void)
+     {
+       int i = 0;
+       asm goto ("mfsr %%r1, 123; jmp %%r1;"
+                 ".pushsection doit_table;"
+                 ".long %l0, %l1, %l2, %l3;"
+                 ".popsection"
+                 : : : "r1" : label1, label2, label3, label4);
+       __builtin_unreachable ();
+
+      label1:
+       f1();
+       return;
+      label2:
+       f2();
+       return;
+      label3:
+       i = 1;
+      label4:
+       f3(i);
+     }
+
+In this (also inefficient) example, the 'mfsr' instruction reads an
+address from some out-of-band machine register, and the following 'jmp'
+instruction branches to that address.  The address read by the 'mfsr'
+instruction is assumed to have been previously set via some
+application-specific mechanism to be one of the four values stored in
+the 'doit_table' section.  Finally, the 'asm' is followed by a call to
+'__builtin_unreachable' to indicate that the 'asm' does not in fact fall
+through.
+
+     #define TRACE1(NUM)                         \
+       do {                                      \
+         asm goto ("0: nop;"                     \
+                   ".pushsection trace_table;"   \
+                   ".long 0b, %l0;"              \
+                   ".popsection"                 \
+                   : : : : trace#NUM);           \
+         if (0) { trace#NUM: trace(); }          \
+       } while (0)
+     #define TRACE  TRACE1(__COUNTER__)
+
+In this example (which in fact inspired the 'asm goto' feature) we want
+on rare occasions to call the 'trace' function; on other occasions we'd
+like to keep the overhead to the absolute minimum.  The normal code path
+consists of a single 'nop' instruction.  However, we record the address
+of this 'nop' together with the address of a label that calls the
+'trace' function.  This allows the 'nop' instruction to be patched at
+run time to be an unconditional branch to the stored label.  It is
+assumed that an optimizing compiler moves the labeled block out of line,
+to optimize the fall through path from the 'asm'.
+
+ If you are writing a header file that should be includable in ISO C
+programs, write '__asm__' instead of 'asm'.  *Note Alternate Keywords::.
+
+6.41.1 Size of an 'asm'
+-----------------------
+
+Some targets require that GCC track the size of each instruction used in
+order to generate correct code.  Because the final length of an 'asm' is
+only known by the assembler, GCC must make an estimate as to how big it
+will be.  The estimate is formed by counting the number of statements in
+the pattern of the 'asm' and multiplying that by the length of the
+longest instruction on that processor.  Statements in the 'asm' are
+identified by newline characters and whatever statement separator
+characters are supported by the assembler; on most processors this is
+the ';' character.
+
+ Normally, GCC's estimate is perfectly adequate to ensure that correct
+code is generated, but it is possible to confuse the compiler if you use
+pseudo instructions or assembler macros that expand into multiple real
+instructions or if you use assembler directives that expand to more
+space in the object file than is needed for a single instruction.  If
+this happens then the assembler produces a diagnostic saying that a
+label is unreachable.
+
+6.41.2 i386 floating-point asm operands
+---------------------------------------
+
+On i386 targets, there are several rules on the usage of stack-like
+registers in the operands of an 'asm'.  These rules apply only to the
+operands that are stack-like registers:
+
+  1. Given a set of input registers that die in an 'asm', it is
+     necessary to know which are implicitly popped by the 'asm', and
+     which must be explicitly popped by GCC.
+
+     An input register that is implicitly popped by the 'asm' must be
+     explicitly clobbered, unless it is constrained to match an output
+     operand.
+
+  2. For any input register that is implicitly popped by an 'asm', it is
+     necessary to know how to adjust the stack to compensate for the
+     pop.  If any non-popped input is closer to the top of the reg-stack
+     than the implicitly popped register, it would not be possible to
+     know what the stack looked like--it's not clear how the rest of the
+     stack "slides up".
+
+     All implicitly popped input registers must be closer to the top of
+     the reg-stack than any input that is not implicitly popped.
+
+     It is possible that if an input dies in an 'asm', the compiler
+     might use the input register for an output reload.  Consider this
+     example:
+
+          asm ("foo" : "=t" (a) : "f" (b));
+
+     This code says that input 'b' is not popped by the 'asm', and that
+     the 'asm' pushes a result onto the reg-stack, i.e., the stack is
+     one deeper after the 'asm' than it was before.  But, it is possible
+     that reload may think that it can use the same register for both
+     the input and the output.
+
+     To prevent this from happening, if any input operand uses the 'f'
+     constraint, all output register constraints must use the '&'
+     early-clobber modifier.
+
+     The example above would be correctly written as:
+
+          asm ("foo" : "=&t" (a) : "f" (b));
+
+  3. Some operands need to be in particular places on the stack.  All
+     output operands fall in this category--GCC has no other way to know
+     which registers the outputs appear in unless you indicate this in
+     the constraints.
+
+     Output operands must specifically indicate which register an output
+     appears in after an 'asm'.  '=f' is not allowed: the operand
+     constraints must select a class with a single register.
+
+  4. Output operands may not be "inserted" between existing stack
+     registers.  Since no 387 opcode uses a read/write operand, all
+     output operands are dead before the 'asm', and are pushed by the
+     'asm'.  It makes no sense to push anywhere but the top of the
+     reg-stack.
+
+     Output operands must start at the top of the reg-stack: output
+     operands may not "skip" a register.
+
+  5. Some 'asm' statements may need extra stack space for internal
+     calculations.  This can be guaranteed by clobbering stack registers
+     unrelated to the inputs and outputs.
+
+ Here are a couple of reasonable 'asm's to want to write.  This 'asm'
+takes one input, which is internally popped, and produces two outputs.
+
+     asm ("fsincos" : "=t" (cos), "=u" (sin) : "0" (inp));
+
+This 'asm' takes two inputs, which are popped by the 'fyl2xp1' opcode,
+and replaces them with one output.  The 'st(1)' clobber is necessary for
+the compiler to know that 'fyl2xp1' pops both inputs.
+
+     asm ("fyl2xp1" : "=t" (result) : "0" (x), "u" (y) : "st(1)");
+
+
+File: gcc.info,  Node: Constraints,  Next: Asm Labels,  Prev: Extended Asm,  Up: C Extensions
+
+6.42 Constraints for 'asm' Operands
+===================================
+
+Here are specific details on what constraint letters you can use with
+'asm' operands.  Constraints can say whether an operand may be in a
+register, and which kinds of register; whether the operand can be a
+memory reference, and which kinds of address; whether the operand may be
+an immediate constant, and which possible values it may have.
+Constraints can also require two operands to match.  Side-effects aren't
+allowed in operands of inline 'asm', unless '<' or '>' constraints are
+used, because there is no guarantee that the side-effects will happen
+exactly once in an instruction that can update the addressing register.
+
+* Menu:
+
+* Simple Constraints::  Basic use of constraints.
+* Multi-Alternative::   When an insn has two alternative constraint-patterns.
+* Modifiers::           More precise control over effects of constraints.
+* Machine Constraints:: Special constraints for some particular machines.
+
+
+File: gcc.info,  Node: Simple Constraints,  Next: Multi-Alternative,  Up: Constraints
+
+6.42.1 Simple Constraints
+-------------------------
+
+The simplest kind of constraint is a string full of letters, each of
+which describes one kind of operand that is permitted.  Here are the
+letters that are allowed:
+
+whitespace
+     Whitespace characters are ignored and can be inserted at any
+     position except the first.  This enables each alternative for
+     different operands to be visually aligned in the machine
+     description even if they have different number of constraints and
+     modifiers.
+
+'m'
+     A memory operand is allowed, with any kind of address that the
+     machine supports in general.  Note that the letter used for the
+     general memory constraint can be re-defined by a back end using the
+     'TARGET_MEM_CONSTRAINT' macro.
+
+'o'
+     A memory operand is allowed, but only if the address is
+     "offsettable".  This means that adding a small integer (actually,
+     the width in bytes of the operand, as determined by its machine
+     mode) may be added to the address and the result is also a valid
+     memory address.
+
+     For example, an address which is constant is offsettable; so is an
+     address that is the sum of a register and a constant (as long as a
+     slightly larger constant is also within the range of
+     address-offsets supported by the machine); but an autoincrement or
+     autodecrement address is not offsettable.  More complicated
+     indirect/indexed addresses may or may not be offsettable depending
+     on the other addressing modes that the machine supports.
+
+     Note that in an output operand which can be matched by another
+     operand, the constraint letter 'o' is valid only when accompanied
+     by both '<' (if the target machine has predecrement addressing) and
+     '>' (if the target machine has preincrement addressing).
+
+'V'
+     A memory operand that is not offsettable.  In other words, anything
+     that would fit the 'm' constraint but not the 'o' constraint.
+
+'<'
+     A memory operand with autodecrement addressing (either predecrement
+     or postdecrement) is allowed.  In inline 'asm' this constraint is
+     only allowed if the operand is used exactly once in an instruction
+     that can handle the side-effects.  Not using an operand with '<' in
+     constraint string in the inline 'asm' pattern at all or using it in
+     multiple instructions isn't valid, because the side-effects
+     wouldn't be performed or would be performed more than once.
+     Furthermore, on some targets the operand with '<' in constraint
+     string must be accompanied by special instruction suffixes like
+     '%U0' instruction suffix on PowerPC or '%P0' on IA-64.
+
+'>'
+     A memory operand with autoincrement addressing (either preincrement
+     or postincrement) is allowed.  In inline 'asm' the same
+     restrictions as for '<' apply.
+
+'r'
+     A register operand is allowed provided that it is in a general
+     register.
+
+'i'
+     An immediate integer operand (one with constant value) is allowed.
+     This includes symbolic constants whose values will be known only at
+     assembly time or later.
+
+'n'
+     An immediate integer operand with a known numeric value is allowed.
+     Many systems cannot support assembly-time constants for operands
+     less than a word wide.  Constraints for these operands should use
+     'n' rather than 'i'.
+
+'I', 'J', 'K', ... 'P'
+     Other letters in the range 'I' through 'P' may be defined in a
+     machine-dependent fashion to permit immediate integer operands with
+     explicit integer values in specified ranges.  For example, on the
+     68000, 'I' is defined to stand for the range of values 1 to 8.
+     This is the range permitted as a shift count in the shift
+     instructions.
+
+'E'
+     An immediate floating operand (expression code 'const_double') is
+     allowed, but only if the target floating point format is the same
+     as that of the host machine (on which the compiler is running).
+
+'F'
+     An immediate floating operand (expression code 'const_double' or
+     'const_vector') is allowed.
+
+'G', 'H'
+     'G' and 'H' may be defined in a machine-dependent fashion to permit
+     immediate floating operands in particular ranges of values.
+
+'s'
+     An immediate integer operand whose value is not an explicit integer
+     is allowed.
+
+     This might appear strange; if an insn allows a constant operand
+     with a value not known at compile time, it certainly must allow any
+     known value.  So why use 's' instead of 'i'?  Sometimes it allows
+     better code to be generated.
+
+     For example, on the 68000 in a fullword instruction it is possible
+     to use an immediate operand; but if the immediate value is between
+     -128 and 127, better code results from loading the value into a
+     register and using the register.  This is because the load into the
+     register can be done with a 'moveq' instruction.  We arrange for
+     this to happen by defining the letter 'K' to mean "any integer
+     outside the range -128 to 127", and then specifying 'Ks' in the
+     operand constraints.
+
+'g'
+     Any register, memory or immediate integer operand is allowed,
+     except for registers that are not general registers.
+
+'X'
+     Any operand whatsoever is allowed.
+
+'0', '1', '2', ... '9'
+     An operand that matches the specified operand number is allowed.
+     If a digit is used together with letters within the same
+     alternative, the digit should come last.
+
+     This number is allowed to be more than a single digit.  If multiple
+     digits are encountered consecutively, they are interpreted as a
+     single decimal integer.  There is scant chance for ambiguity, since
+     to-date it has never been desirable that '10' be interpreted as
+     matching either operand 1 _or_ operand 0.  Should this be desired,
+     one can use multiple alternatives instead.
+
+     This is called a "matching constraint" and what it really means is
+     that the assembler has only a single operand that fills two roles
+     which 'asm' distinguishes.  For example, an add instruction uses
+     two input operands and an output operand, but on most CISC machines
+     an add instruction really has only two operands, one of them an
+     input-output operand:
+
+          addl #35,r12
+
+     Matching constraints are used in these circumstances.  More
+     precisely, the two operands that match must include one input-only
+     operand and one output-only operand.  Moreover, the digit must be a
+     smaller number than the number of the operand that uses it in the
+     constraint.
+
+'p'
+     An operand that is a valid memory address is allowed.  This is for
+     "load address" and "push address" instructions.
+
+     'p' in the constraint must be accompanied by 'address_operand' as
+     the predicate in the 'match_operand'.  This predicate interprets
+     the mode specified in the 'match_operand' as the mode of the memory
+     reference for which the address would be valid.
+
+OTHER-LETTERS
+     Other letters can be defined in machine-dependent fashion to stand
+     for particular classes of registers or other arbitrary operand
+     types.  'd', 'a' and 'f' are defined on the 68000/68020 to stand
+     for data, address and floating point registers.
+
+
+File: gcc.info,  Node: Multi-Alternative,  Next: Modifiers,  Prev: Simple Constraints,  Up: Constraints
+
+6.42.2 Multiple Alternative Constraints
+---------------------------------------
+
+Sometimes a single instruction has multiple alternative sets of possible
+operands.  For example, on the 68000, a logical-or instruction can
+combine register or an immediate value into memory, or it can combine
+any kind of operand into a register; but it cannot combine one memory
+location into another.
+
+ These constraints are represented as multiple alternatives.  An
+alternative can be described by a series of letters for each operand.
+The overall constraint for an operand is made from the letters for this
+operand from the first alternative, a comma, the letters for this
+operand from the second alternative, a comma, and so on until the last
+alternative.
+
+ If all the operands fit any one alternative, the instruction is valid.
+Otherwise, for each alternative, the compiler counts how many
+instructions must be added to copy the operands so that that alternative
+applies.  The alternative requiring the least copying is chosen.  If two
+alternatives need the same amount of copying, the one that comes first
+is chosen.  These choices can be altered with the '?' and '!'
+characters:
+
+'?'
+     Disparage slightly the alternative that the '?' appears in, as a
+     choice when no alternative applies exactly.  The compiler regards
+     this alternative as one unit more costly for each '?' that appears
+     in it.
+
+'!'
+     Disparage severely the alternative that the '!' appears in.  This
+     alternative can still be used if it fits without reloading, but if
+     reloading is needed, some other alternative will be used.
+
+
+File: gcc.info,  Node: Modifiers,  Next: Machine Constraints,  Prev: Multi-Alternative,  Up: Constraints
+
+6.42.3 Constraint Modifier Characters
+-------------------------------------
+
+Here are constraint modifier characters.
+
+'='
+     Means that this operand is write-only for this instruction: the
+     previous value is discarded and replaced by output data.
+
+'+'
+     Means that this operand is both read and written by the
+     instruction.
+
+     When the compiler fixes up the operands to satisfy the constraints,
+     it needs to know which operands are inputs to the instruction and
+     which are outputs from it.  '=' identifies an output; '+'
+     identifies an operand that is both input and output; all other
+     operands are assumed to be input only.
+
+     If you specify '=' or '+' in a constraint, you put it in the first
+     character of the constraint string.
+
+'&'
+     Means (in a particular alternative) that this operand is an
+     "earlyclobber" operand, which is modified before the instruction is
+     finished using the input operands.  Therefore, this operand may not
+     lie in a register that is used as an input operand or as part of
+     any memory address.
+
+     '&' applies only to the alternative in which it is written.  In
+     constraints with multiple alternatives, sometimes one alternative
+     requires '&' while others do not.  See, for example, the 'movdf'
+     insn of the 68000.
+
+     An input operand can be tied to an earlyclobber operand if its only
+     use as an input occurs before the early result is written.  Adding
+     alternatives of this form often allows GCC to produce better code
+     when only some of the inputs can be affected by the earlyclobber.
+     See, for example, the 'mulsi3' insn of the ARM.
+
+     '&' does not obviate the need to write '='.
+
+'%'
+     Declares the instruction to be commutative for this operand and the
+     following operand.  This means that the compiler may interchange
+     the two operands if that is the cheapest way to make all operands
+     fit the constraints.  GCC can only handle one commutative pair in
+     an asm; if you use more, the compiler may fail.  Note that you need
+     not use the modifier if the two alternatives are strictly
+     identical; this would only waste time in the reload pass.  The
+     modifier is not operational after register allocation, so the
+     result of 'define_peephole2' and 'define_split's performed after
+     reload cannot rely on '%' to make the intended insn match.
+
+'#'
+     Says that all following characters, up to the next comma, are to be
+     ignored as a constraint.  They are significant only for choosing
+     register preferences.
+
+'*'
+     Says that the following character should be ignored when choosing
+     register preferences.  '*' has no effect on the meaning of the
+     constraint as a constraint, and no effect on reloading.  For LRA
+     '*' additionally disparages slightly the alternative if the
+     following character matches the operand.
+
+
+File: gcc.info,  Node: Machine Constraints,  Prev: Modifiers,  Up: Constraints
+
+6.42.4 Constraints for Particular Machines
+------------------------------------------
+
+Whenever possible, you should use the general-purpose constraint letters
+in 'asm' arguments, since they will convey meaning more readily to
+people reading your code.  Failing that, use the constraint letters that
+usually have very similar meanings across architectures.  The most
+commonly used constraints are 'm' and 'r' (for memory and
+general-purpose registers respectively; *note Simple Constraints::), and
+'I', usually the letter indicating the most common immediate-constant
+format.
+
+ Each architecture defines additional constraints.  These constraints
+are used by the compiler itself for instruction generation, as well as
+for 'asm' statements; therefore, some of the constraints are not
+particularly useful for 'asm'.  Here is a summary of some of the
+machine-dependent constraints available on some particular machines; it
+includes both constraints that are useful for 'asm' and constraints that
+aren't.  The compiler source file mentioned in the table heading for
+each architecture is the definitive reference for the meanings of that
+architecture's constraints.
+
+_AArch64 family--'config/aarch64/constraints.md'_
+     'k'
+          The stack pointer register ('SP')
+
+     'w'
+          Floating point or SIMD vector register
+
+     'I'
+          Integer constant that is valid as an immediate operand in an
+          'ADD' instruction
+
+     'J'
+          Integer constant that is valid as an immediate operand in a
+          'SUB' instruction (once negated)
+
+     'K'
+          Integer constant that can be used with a 32-bit logical
+          instruction
+
+     'L'
+          Integer constant that can be used with a 64-bit logical
+          instruction
+
+     'M'
+          Integer constant that is valid as an immediate operand in a
+          32-bit 'MOV' pseudo instruction.  The 'MOV' may be assembled
+          to one of several different machine instructions depending on
+          the value
+
+     'N'
+          Integer constant that is valid as an immediate operand in a
+          64-bit 'MOV' pseudo instruction
+
+     'S'
+          An absolute symbolic address or a label reference
+
+     'Y'
+          Floating point constant zero
+
+     'Z'
+          Integer constant zero
+
+     'Ush'
+          The high part (bits 12 and upwards) of the pc-relative address
+          of a symbol within 4GB of the instruction
+
+     'Q'
+          A memory address which uses a single base register with no
+          offset
+
+     'Ump'
+          A memory address suitable for a load/store pair instruction in
+          SI, DI, SF and DF modes
+
+_ARC --'config/arc/constraints.md'_
+     'q'
+          Registers usable in ARCompact 16-bit instructions: 'r0'-'r3',
+          'r12'-'r15'.  This constraint can only match when the '-mq'
+          option is in effect.
+
+     'e'
+          Registers usable as base-regs of memory addresses in ARCompact
+          16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'.
+          This constraint can only match when the '-mq' option is in
+          effect.
+     'D'
+          ARC FPX (dpfp) 64-bit registers.  'D0', 'D1'.
+
+     'I'
+          A signed 12-bit integer constant.
+
+     'Cal'
+          constant for arithmetic/logical operations.  This might be any
+          constant that can be put into a long immediate by the assmbler
+          or linker without involving a PIC relocation.
+
+     'K'
+          A 3-bit unsigned integer constant.
+
+     'L'
+          A 6-bit unsigned integer constant.
+
+     'CnL'
+          One's complement of a 6-bit unsigned integer constant.
+
+     'CmL'
+          Two's complement of a 6-bit unsigned integer constant.
+
+     'M'
+          A 5-bit unsigned integer constant.
+
+     'O'
+          A 7-bit unsigned integer constant.
+
+     'P'
+          A 8-bit unsigned integer constant.
+
+     'H'
+          Any const_double value.
+
+_ARM family--'config/arm/constraints.md'_
+     'w'
+          VFP floating-point register
+
+     'G'
+          The floating-point constant 0.0
+
+     'I'
+          Integer that is valid as an immediate operand in a data
+          processing instruction.  That is, an integer in the range 0 to
+          255 rotated by a multiple of 2
+
+     'J'
+          Integer in the range -4095 to 4095
+
+     'K'
+          Integer that satisfies constraint 'I' when inverted (ones
+          complement)
+
+     'L'
+          Integer that satisfies constraint 'I' when negated (twos
+          complement)
+
+     'M'
+          Integer in the range 0 to 32
+
+     'Q'
+          A memory reference where the exact address is in a single
+          register (''m'' is preferable for 'asm' statements)
+
+     'R'
+          An item in the constant pool
+
+     'S'
+          A symbol in the text segment of the current file
+
+     'Uv'
+          A memory reference suitable for VFP load/store insns
+          (reg+constant offset)
+
+     'Uy'
+          A memory reference suitable for iWMMXt load/store
+          instructions.
+
+     'Uq'
+          A memory reference suitable for the ARMv4 ldrsb instruction.
+
+_AVR family--'config/avr/constraints.md'_
+     'l'
+          Registers from r0 to r15
+
+     'a'
+          Registers from r16 to r23
+
+     'd'
+          Registers from r16 to r31
+
+     'w'
+          Registers from r24 to r31.  These registers can be used in
+          'adiw' command
+
+     'e'
+          Pointer register (r26-r31)
+
+     'b'
+          Base pointer register (r28-r31)
+
+     'q'
+          Stack pointer register (SPH:SPL)
+
+     't'
+          Temporary register r0
+
+     'x'
+          Register pair X (r27:r26)
+
+     'y'
+          Register pair Y (r29:r28)
+
+     'z'
+          Register pair Z (r31:r30)
+
+     'I'
+          Constant greater than -1, less than 64
+
+     'J'
+          Constant greater than -64, less than 1
+
+     'K'
+          Constant integer 2
+
+     'L'
+          Constant integer 0
+
+     'M'
+          Constant that fits in 8 bits
+
+     'N'
+          Constant integer -1
+
+     'O'
+          Constant integer 8, 16, or 24
+
+     'P'
+          Constant integer 1
+
+     'G'
+          A floating point constant 0.0
+
+     'Q'
+          A memory address based on Y or Z pointer with displacement.
+
+_Epiphany--'config/epiphany/constraints.md'_
+     'U16'
+          An unsigned 16-bit constant.
+
+     'K'
+          An unsigned 5-bit constant.
+
+     'L'
+          A signed 11-bit constant.
+
+     'Cm1'
+          A signed 11-bit constant added to -1.  Can only match when the
+          '-m1reg-REG' option is active.
+
+     'Cl1'
+          Left-shift of -1, i.e., a bit mask with a block of leading
+          ones, the rest being a block of trailing zeroes.  Can only
+          match when the '-m1reg-REG' option is active.
+
+     'Cr1'
+          Right-shift of -1, i.e., a bit mask with a trailing block of
+          ones, the rest being zeroes.  Or to put it another way, one
+          less than a power of two.  Can only match when the
+          '-m1reg-REG' option is active.
+
+     'Cal'
+          Constant for arithmetic/logical operations.  This is like 'i',
+          except that for position independent code, no symbols /
+          expressions needing relocations are allowed.
+
+     'Csy'
+          Symbolic constant for call/jump instruction.
+
+     'Rcs'
+          The register class usable in short insns.  This is a register
+          class constraint, and can thus drive register allocation.
+          This constraint won't match unless '-mprefer-short-insn-regs'
+          is in effect.
+
+     'Rsc'
+          The the register class of registers that can be used to hold a
+          sibcall call address.  I.e., a caller-saved register.
+
+     'Rct'
+          Core control register class.
+
+     'Rgs'
+          The register group usable in short insns.  This constraint
+          does not use a register class, so that it only passively
+          matches suitable registers, and doesn't drive register
+          allocation.
+
+     'Rra'
+          Matches the return address if it can be replaced with the link
+          register.
+
+     'Rcc'
+          Matches the integer condition code register.
+
+     'Sra'
+          Matches the return address if it is in a stack slot.
+
+     'Cfm'
+          Matches control register values to switch fp mode, which are
+          encapsulated in 'UNSPEC_FP_MODE'.
+
+_CR16 Architecture--'config/cr16/cr16.h'_
+
+     'b'
+          Registers from r0 to r14 (registers without stack pointer)
+
+     't'
+          Register from r0 to r11 (all 16-bit registers)
+
+     'p'
+          Register from r12 to r15 (all 32-bit registers)
+
+     'I'
+          Signed constant that fits in 4 bits
+
+     'J'
+          Signed constant that fits in 5 bits
+
+     'K'
+          Signed constant that fits in 6 bits
+
+     'L'
+          Unsigned constant that fits in 4 bits
+
+     'M'
+          Signed constant that fits in 32 bits
+
+     'N'
+          Check for 64 bits wide constants for add/sub instructions
+
+     'G'
+          Floating point constant that is legal for store immediate
+
+_Hewlett-Packard PA-RISC--'config/pa/pa.h'_
+     'a'
+          General register 1
+
+     'f'
+          Floating point register
+
+     'q'
+          Shift amount register
+
+     'x'
+          Floating point register (deprecated)
+
+     'y'
+          Upper floating point register (32-bit), floating point
+          register (64-bit)
+
+     'Z'
+          Any register
+
+     'I'
+          Signed 11-bit integer constant
+
+     'J'
+          Signed 14-bit integer constant
+
+     'K'
+          Integer constant that can be deposited with a 'zdepi'
+          instruction
+
+     'L'
+          Signed 5-bit integer constant
+
+     'M'
+          Integer constant 0
+
+     'N'
+          Integer constant that can be loaded with a 'ldil' instruction
+
+     'O'
+          Integer constant whose value plus one is a power of 2
+
+     'P'
+          Integer constant that can be used for 'and' operations in
+          'depi' and 'extru' instructions
+
+     'S'
+          Integer constant 31
+
+     'U'
+          Integer constant 63
+
+     'G'
+          Floating-point constant 0.0
+
+     'A'
+          A 'lo_sum' data-linkage-table memory operand
+
+     'Q'
+          A memory operand that can be used as the destination operand
+          of an integer store instruction
+
+     'R'
+          A scaled or unscaled indexed memory operand
+
+     'T'
+          A memory operand for floating-point loads and stores
+
+     'W'
+          A register indirect memory operand
+
+_picoChip family--'picochip.h'_
+     'k'
+          Stack register.
+
+     'f'
+          Pointer register.  A register which can be used to access
+          memory without supplying an offset.  Any other register can be
+          used to access memory, but will need a constant offset.  In
+          the case of the offset being zero, it is more efficient to use
+          a pointer register, since this reduces code size.
+
+     't'
+          A twin register.  A register which may be paired with an
+          adjacent register to create a 32-bit register.
+
+     'a'
+          Any absolute memory address (e.g., symbolic constant, symbolic
+          constant + offset).
+
+     'I'
+          4-bit signed integer.
+
+     'J'
+          4-bit unsigned integer.
+
+     'K'
+          8-bit signed integer.
+
+     'M'
+          Any constant whose absolute value is no greater than 4-bits.
+
+     'N'
+          10-bit signed integer
+
+     'O'
+          16-bit signed integer.
+
+_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_
+     'b'
+          Address base register
+
+     'd'
+          Floating point register (containing 64-bit value)
+
+     'f'
+          Floating point register (containing 32-bit value)
+
+     'v'
+          Altivec vector register
+
+     'wa'
+          Any VSX register if the -mvsx option was used or NO_REGS.
+
+     'wd'
+          VSX vector register to hold vector double data or NO_REGS.
+
+     'wf'
+          VSX vector register to hold vector float data or NO_REGS.
+
+     'wg'
+          If '-mmfpgpr' was used, a floating point register or NO_REGS.
+
+     'wl'
+          Floating point register if the LFIWAX instruction is enabled
+          or NO_REGS.
+
+     'wm'
+          VSX register if direct move instructions are enabled, or
+          NO_REGS.
+
+     'wn'
+          No register (NO_REGS).
+
+     'wr'
+          General purpose register if 64-bit instructions are enabled or
+          NO_REGS.
+
+     'ws'
+          VSX vector register to hold scalar double values or NO_REGS.
+
+     'wt'
+          VSX vector register to hold 128 bit integer or NO_REGS.
+
+     'wu'
+          Altivec register to use for float/32-bit int loads/stores or
+          NO_REGS.
+
+     'wv'
+          Altivec register to use for double loads/stores or NO_REGS.
+
+     'ww'
+          FP or VSX register to perform float operations under '-mvsx'
+          or NO_REGS.
+
+     'wx'
+          Floating point register if the STFIWX instruction is enabled
+          or NO_REGS.
+
+     'wy'
+          VSX vector register to hold scalar float values or NO_REGS.
+
+     'wz'
+          Floating point register if the LFIWZX instruction is enabled
+          or NO_REGS.
+
+     'wD'
+          Int constant that is the element number of the 64-bit scalar
+          in a vector.
+
+     'wQ'
+          A memory address that will work with the 'lq' and 'stq'
+          instructions.
+
+     'h'
+          'MQ', 'CTR', or 'LINK' register
+
+     'q'
+          'MQ' register
+
+     'c'
+          'CTR' register
+
+     'l'
+          'LINK' register
+
+     'x'
+          'CR' register (condition register) number 0
+
+     'y'
+          'CR' register (condition register)
+
+     'z'
+          'XER[CA]' carry bit (part of the XER register)
+
+     'I'
+          Signed 16-bit constant
+
+     'J'
+          Unsigned 16-bit constant shifted left 16 bits (use 'L' instead
+          for 'SImode' constants)
+
+     'K'
+          Unsigned 16-bit constant
+
+     'L'
+          Signed 16-bit constant shifted left 16 bits
+
+     'M'
+          Constant larger than 31
+
+     'N'
+          Exact power of 2
+
+     'O'
+          Zero
+
+     'P'
+          Constant whose negation is a signed 16-bit constant
+
+     'G'
+          Floating point constant that can be loaded into a register
+          with one instruction per word
+
+     'H'
+          Integer/Floating point constant that can be loaded into a
+          register using three instructions
+
+     'm'
+          Memory operand.  Normally, 'm' does not allow addresses that
+          update the base register.  If '<' or '>' constraint is also
+          used, they are allowed and therefore on PowerPC targets in
+          that case it is only safe to use 'm<>' in an 'asm' statement
+          if that 'asm' statement accesses the operand exactly once.
+          The 'asm' statement must also use '%U<OPNO>' as a placeholder
+          for the "update" flag in the corresponding load or store
+          instruction.  For example:
+
+               asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val));
+
+          is correct but:
+
+               asm ("st %1,%0" : "=m<>" (mem) : "r" (val));
+
+          is not.
+
+     'es'
+          A "stable" memory operand; that is, one which does not include
+          any automodification of the base register.  This used to be
+          useful when 'm' allowed automodification of the base register,
+          but as those are now only allowed when '<' or '>' is used,
+          'es' is basically the same as 'm' without '<' and '>'.
+
+     'Q'
+          Memory operand that is an offset from a register (it is
+          usually better to use 'm' or 'es' in 'asm' statements)
+
+     'Z'
+          Memory operand that is an indexed or indirect from a register
+          (it is usually better to use 'm' or 'es' in 'asm' statements)
+
+     'R'
+          AIX TOC entry
+
+     'a'
+          Address operand that is an indexed or indirect from a register
+          ('p' is preferable for 'asm' statements)
+
+     'S'
+          Constant suitable as a 64-bit mask operand
+
+     'T'
+          Constant suitable as a 32-bit mask operand
+
+     'U'
+          System V Release 4 small data area reference
+
+     't'
+          AND masks that can be performed by two rldic{l, r}
+          instructions
+
+     'W'
+          Vector constant that does not require memory
+
+     'j'
+          Vector constant that is all zeros.
+
+_Intel 386--'config/i386/constraints.md'_
+     'R'
+          Legacy register--the eight integer registers available on all
+          i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp').
+
+     'q'
+          Any register accessible as 'Rl'.  In 32-bit mode, 'a', 'b',
+          'c', and 'd'; in 64-bit mode, any integer register.
+
+     'Q'
+          Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'.
+
+     'a'
+          The 'a' register.
+
+     'b'
+          The 'b' register.
+
+     'c'
+          The 'c' register.
+
+     'd'
+          The 'd' register.
+
+     'S'
+          The 'si' register.
+
+     'D'
+          The 'di' register.
+
+     'A'
+          The 'a' and 'd' registers.  This class is used for
+          instructions that return double word results in the 'ax:dx'
+          register pair.  Single word values will be allocated either in
+          'ax' or 'dx'.  For example on i386 the following implements
+          'rdtsc':
+
+               unsigned long long rdtsc (void)
+               {
+                 unsigned long long tick;
+                 __asm__ __volatile__("rdtsc":"=A"(tick));
+                 return tick;
+               }
+
+          This is not correct on x86_64 as it would allocate tick in
+          either 'ax' or 'dx'.  You have to use the following variant
+          instead:
+
+               unsigned long long rdtsc (void)
+               {
+                 unsigned int tickl, tickh;
+                 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh));
+                 return ((unsigned long long)tickh << 32)|tickl;
+               }
+
+     'f'
+          Any 80387 floating-point (stack) register.
+
+     't'
+          Top of 80387 floating-point stack ('%st(0)').
+
+     'u'
+          Second from top of 80387 floating-point stack ('%st(1)').
+
+     'y'
+          Any MMX register.
+
+     'x'
+          Any SSE register.
+
+     'Yz'
+          First SSE register ('%xmm0').
+
+     'I'
+          Integer constant in the range 0 ... 31, for 32-bit shifts.
+
+     'J'
+          Integer constant in the range 0 ... 63, for 64-bit shifts.
+
+     'K'
+          Signed 8-bit integer constant.
+
+     'L'
+          '0xFF' or '0xFFFF', for andsi as a zero-extending move.
+
+     'M'
+          0, 1, 2, or 3 (shifts for the 'lea' instruction).
+
+     'N'
+          Unsigned 8-bit integer constant (for 'in' and 'out'
+          instructions).
+
+     'G'
+          Standard 80387 floating point constant.
+
+     'C'
+          Standard SSE floating point constant.
+
+     'e'
+          32-bit signed integer constant, or a symbolic reference known
+          to fit that range (for immediate operands in sign-extending
+          x86-64 instructions).
+
+     'Z'
+          32-bit unsigned integer constant, or a symbolic reference
+          known to fit that range (for immediate operands in
+          zero-extending x86-64 instructions).
+
+_Intel IA-64--'config/ia64/ia64.h'_
+     'a'
+          General register 'r0' to 'r3' for 'addl' instruction
+
+     'b'
+          Branch register
+
+     'c'
+          Predicate register ('c' as in "conditional")
+
+     'd'
+          Application register residing in M-unit
+
+     'e'
+          Application register residing in I-unit
+
+     'f'
+          Floating-point register
+
+     'm'
+          Memory operand.  If used together with '<' or '>', the operand
+          can have postincrement and postdecrement which require
+          printing with '%Pn' on IA-64.
+
+     'G'
+          Floating-point constant 0.0 or 1.0
+
+     'I'
+          14-bit signed integer constant
+
+     'J'
+          22-bit signed integer constant
+
+     'K'
+          8-bit signed integer constant for logical instructions
+
+     'L'
+          8-bit adjusted signed integer constant for compare pseudo-ops
+
+     'M'
+          6-bit unsigned integer constant for shift counts
+
+     'N'
+          9-bit signed integer constant for load and store
+          postincrements
+
+     'O'
+          The constant zero
+
+     'P'
+          0 or -1 for 'dep' instruction
+
+     'Q'
+          Non-volatile memory for floating-point loads and stores
+
+     'R'
+          Integer constant in the range 1 to 4 for 'shladd' instruction
+
+     'S'
+          Memory operand except postincrement and postdecrement.  This
+          is now roughly the same as 'm' when not used together with '<'
+          or '>'.
+
+_FRV--'config/frv/frv.h'_
+     'a'
+          Register in the class 'ACC_REGS' ('acc0' to 'acc7').
+
+     'b'
+          Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7').
+
+     'c'
+          Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0'
+          to 'icc3').
+
+     'd'
+          Register in the class 'GPR_REGS' ('gr0' to 'gr63').
+
+     'e'
+          Register in the class 'EVEN_REGS' ('gr0' to 'gr63').  Odd
+          registers are excluded not in the class but through the use of
+          a machine mode larger than 4 bytes.
+
+     'f'
+          Register in the class 'FPR_REGS' ('fr0' to 'fr63').
+
+     'h'
+          Register in the class 'FEVEN_REGS' ('fr0' to 'fr63').  Odd
+          registers are excluded not in the class but through the use of
+          a machine mode larger than 4 bytes.
+
+     'l'
+          Register in the class 'LR_REG' (the 'lr' register).
+
+     'q'
+          Register in the class 'QUAD_REGS' ('gr2' to 'gr63').  Register
+          numbers not divisible by 4 are excluded not in the class but
+          through the use of a machine mode larger than 8 bytes.
+
+     't'
+          Register in the class 'ICC_REGS' ('icc0' to 'icc3').
+
+     'u'
+          Register in the class 'FCC_REGS' ('fcc0' to 'fcc3').
+
+     'v'
+          Register in the class 'ICR_REGS' ('cc4' to 'cc7').
+
+     'w'
+          Register in the class 'FCR_REGS' ('cc0' to 'cc3').
+
+     'x'
+          Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63').
+          Register numbers not divisible by 4 are excluded not in the
+          class but through the use of a machine mode larger than 8
+          bytes.
+
+     'z'
+          Register in the class 'SPR_REGS' ('lcr' and 'lr').
+
+     'A'
+          Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7').
+
+     'B'
+          Register in the class 'ACCG_REGS' ('accg0' to 'accg7').
+
+     'C'
+          Register in the class 'CR_REGS' ('cc0' to 'cc7').
+
+     'G'
+          Floating point constant zero
+
+     'I'
+          6-bit signed integer constant
+
+     'J'
+          10-bit signed integer constant
+
+     'L'
+          16-bit signed integer constant
+
+     'M'
+          16-bit unsigned integer constant
+
+     'N'
+          12-bit signed integer constant that is negative--i.e. in the
+          range of -2048 to -1
+
+     'O'
+          Constant zero
+
+     'P'
+          12-bit signed integer constant that is greater than zero--i.e.
+          in the range of 1 to 2047.
+
+_Blackfin family--'config/bfin/constraints.md'_
+     'a'
+          P register
+
+     'd'
+          D register
+
+     'z'
+          A call clobbered P register.
+
+     'qN'
+          A single register.  If N is in the range 0 to 7, the
+          corresponding D register.  If it is 'A', then the register P0.
+
+     'D'
+          Even-numbered D register
+
+     'W'
+          Odd-numbered D register
+
+     'e'
+          Accumulator register.
+
+     'A'
+          Even-numbered accumulator register.
+
+     'B'
+          Odd-numbered accumulator register.
+
+     'b'
+          I register
+
+     'v'
+          B register
+
+     'f'
+          M register
+
+     'c'
+          Registers used for circular buffering, i.e.  I, B, or L
+          registers.
+
+     'C'
+          The CC register.
+
+     't'
+          LT0 or LT1.
+
+     'k'
+          LC0 or LC1.
+
+     'u'
+          LB0 or LB1.
+
+     'x'
+          Any D, P, B, M, I or L register.
+
+     'y'
+          Additional registers typically used only in prologues and
+          epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and
+          USP.
+
+     'w'
+          Any register except accumulators or CC.
+
+     'Ksh'
+          Signed 16 bit integer (in the range -32768 to 32767)
+
+     'Kuh'
+          Unsigned 16 bit integer (in the range 0 to 65535)
+
+     'Ks7'
+          Signed 7 bit integer (in the range -64 to 63)
+
+     'Ku7'
+          Unsigned 7 bit integer (in the range 0 to 127)
+
+     'Ku5'
+          Unsigned 5 bit integer (in the range 0 to 31)
+
+     'Ks4'
+          Signed 4 bit integer (in the range -8 to 7)
+
+     'Ks3'
+          Signed 3 bit integer (in the range -3 to 4)
+
+     'Ku3'
+          Unsigned 3 bit integer (in the range 0 to 7)
+
+     'PN'
+          Constant N, where N is a single-digit constant in the range 0
+          to 4.
+
+     'PA'
+          An integer equal to one of the MACFLAG_XXX constants that is
+          suitable for use with either accumulator.
+
+     'PB'
+          An integer equal to one of the MACFLAG_XXX constants that is
+          suitable for use only with accumulator A1.
+
+     'M1'
+          Constant 255.
+
+     'M2'
+          Constant 65535.
+
+     'J'
+          An integer constant with exactly a single bit set.
+
+     'L'
+          An integer constant with all bits set except exactly one.
+
+     'H'
+
+     'Q'
+          Any SYMBOL_REF.
+
+_M32C--'config/m32c/m32c.c'_
+     'Rsp'
+     'Rfb'
+     'Rsb'
+          '$sp', '$fb', '$sb'.
+
+     'Rcr'
+          Any control register, when they're 16 bits wide (nothing if
+          control registers are 24 bits wide)
+
+     'Rcl'
+          Any control register, when they're 24 bits wide.
+
+     'R0w'
+     'R1w'
+     'R2w'
+     'R3w'
+          $r0, $r1, $r2, $r3.
+
+     'R02'
+          $r0 or $r2, or $r2r0 for 32 bit values.
+
+     'R13'
+          $r1 or $r3, or $r3r1 for 32 bit values.
+
+     'Rdi'
+          A register that can hold a 64 bit value.
+
+     'Rhl'
+          $r0 or $r1 (registers with addressable high/low bytes)
+
+     'R23'
+          $r2 or $r3
+
+     'Raa'
+          Address registers
+
+     'Raw'
+          Address registers when they're 16 bits wide.
+
+     'Ral'
+          Address registers when they're 24 bits wide.
+
+     'Rqi'
+          Registers that can hold QI values.
+
+     'Rad'
+          Registers that can be used with displacements ($a0, $a1, $sb).
+
+     'Rsi'
+          Registers that can hold 32 bit values.
+
+     'Rhi'
+          Registers that can hold 16 bit values.
+
+     'Rhc'
+          Registers chat can hold 16 bit values, including all control
+          registers.
+
+     'Rra'
+          $r0 through R1, plus $a0 and $a1.
+
+     'Rfl'
+          The flags register.
+
+     'Rmm'
+          The memory-based pseudo-registers $mem0 through $mem15.
+
+     'Rpi'
+          Registers that can hold pointers (16 bit registers for r8c,
+          m16c; 24 bit registers for m32cm, m32c).
+
+     'Rpa'
+          Matches multiple registers in a PARALLEL to form a larger
+          register.  Used to match function return values.
+
+     'Is3'
+          -8 ... 7
+
+     'IS1'
+          -128 ... 127
+
+     'IS2'
+          -32768 ... 32767
+
+     'IU2'
+          0 ... 65535
+
+     'In4'
+          -8 ... -1 or 1 ... 8
+
+     'In5'
+          -16 ... -1 or 1 ... 16
+
+     'In6'
+          -32 ... -1 or 1 ... 32
+
+     'IM2'
+          -65536 ... -1
+
+     'Ilb'
+          An 8 bit value with exactly one bit set.
+
+     'Ilw'
+          A 16 bit value with exactly one bit set.
+
+     'Sd'
+          The common src/dest memory addressing modes.
+
+     'Sa'
+          Memory addressed using $a0 or $a1.
+
+     'Si'
+          Memory addressed with immediate addresses.
+
+     'Ss'
+          Memory addressed using the stack pointer ($sp).
+
+     'Sf'
+          Memory addressed using the frame base register ($fb).
+
+     'Ss'
+          Memory addressed using the small base register ($sb).
+
+     'S1'
+          $r1h
+
+_MeP--'config/mep/constraints.md'_
+
+     'a'
+          The $sp register.
+
+     'b'
+          The $tp register.
+
+     'c'
+          Any control register.
+
+     'd'
+          Either the $hi or the $lo register.
+
+     'em'
+          Coprocessor registers that can be directly loaded ($c0-$c15).
+
+     'ex'
+          Coprocessor registers that can be moved to each other.
+
+     'er'
+          Coprocessor registers that can be moved to core registers.
+
+     'h'
+          The $hi register.
+
+     'j'
+          The $rpc register.
+
+     'l'
+          The $lo register.
+
+     't'
+          Registers which can be used in $tp-relative addressing.
+
+     'v'
+          The $gp register.
+
+     'x'
+          The coprocessor registers.
+
+     'y'
+          The coprocessor control registers.
+
+     'z'
+          The $0 register.
+
+     'A'
+          User-defined register set A.
+
+     'B'
+          User-defined register set B.
+
+     'C'
+          User-defined register set C.
+
+     'D'
+          User-defined register set D.
+
+     'I'
+          Offsets for $gp-rel addressing.
+
+     'J'
+          Constants that can be used directly with boolean insns.
+
+     'K'
+          Constants that can be moved directly to registers.
+
+     'L'
+          Small constants that can be added to registers.
+
+     'M'
+          Long shift counts.
+
+     'N'
+          Small constants that can be compared to registers.
+
+     'O'
+          Constants that can be loaded into the top half of registers.
+
+     'S'
+          Signed 8-bit immediates.
+
+     'T'
+          Symbols encoded for $tp-rel or $gp-rel addressing.
+
+     'U'
+          Non-constant addresses for loading/saving coprocessor
+          registers.
+
+     'W'
+          The top half of a symbol's value.
+
+     'Y'
+          A register indirect address without offset.
+
+     'Z'
+          Symbolic references to the control bus.
+
+_MicroBlaze--'config/microblaze/constraints.md'_
+     'd'
+          A general register ('r0' to 'r31').
+
+     'z'
+          A status register ('rmsr', '$fcc1' to '$fcc7').
+
+_MIPS--'config/mips/constraints.md'_
+     'd'
+          An address register.  This is equivalent to 'r' unless
+          generating MIPS16 code.
+
+     'f'
+          A floating-point register (if available).
+
+     'h'
+          Formerly the 'hi' register.  This constraint is no longer
+          supported.
+
+     'l'
+          The 'lo' register.  Use this register to store values that are
+          no bigger than a word.
+
+     'x'
+          The concatenated 'hi' and 'lo' registers.  Use this register
+          to store doubleword values.
+
+     'c'
+          A register suitable for use in an indirect jump.  This will
+          always be '$25' for '-mabicalls'.
+
+     'v'
+          Register '$3'.  Do not use this constraint in new code; it is
+          retained only for compatibility with glibc.
+
+     'y'
+          Equivalent to 'r'; retained for backwards compatibility.
+
+     'z'
+          A floating-point condition code register.
+
+     'I'
+          A signed 16-bit constant (for arithmetic instructions).
+
+     'J'
+          Integer zero.
+
+     'K'
+          An unsigned 16-bit constant (for logic instructions).
+
+     'L'
+          A signed 32-bit constant in which the lower 16 bits are zero.
+          Such constants can be loaded using 'lui'.
+
+     'M'
+          A constant that cannot be loaded using 'lui', 'addiu' or
+          'ori'.
+
+     'N'
+          A constant in the range -65535 to -1 (inclusive).
+
+     'O'
+          A signed 15-bit constant.
+
+     'P'
+          A constant in the range 1 to 65535 (inclusive).
+
+     'G'
+          Floating-point zero.
+
+     'R'
+          An address that can be used in a non-macro load or store.
+
+     'ZC'
+          When compiling microMIPS code, this constraint matches a
+          memory operand whose address is formed from a base register
+          and a 12-bit offset.  These operands can be used for microMIPS
+          instructions such as 'll' and 'sc'.  When not compiling for
+          microMIPS code, 'ZC' is equivalent to 'R'.
+
+     'ZD'
+          When compiling microMIPS code, this constraint matches an
+          address operand that is formed from a base register and a
+          12-bit offset.  These operands can be used for microMIPS
+          instructions such as 'prefetch'.  When not compiling for
+          microMIPS code, 'ZD' is equivalent to 'p'.
+
+_Motorola 680x0--'config/m68k/constraints.md'_
+     'a'
+          Address register
+
+     'd'
+          Data register
+
+     'f'
+          68881 floating-point register, if available
+
+     'I'
+          Integer in the range 1 to 8
+
+     'J'
+          16-bit signed number
+
+     'K'
+          Signed number whose magnitude is greater than 0x80
+
+     'L'
+          Integer in the range -8 to -1
+
+     'M'
+          Signed number whose magnitude is greater than 0x100
+
+     'N'
+          Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
+
+     'O'
+          16 (for rotate using swap)
+
+     'P'
+          Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
+
+     'R'
+          Numbers that mov3q can handle
+
+     'G'
+          Floating point constant that is not a 68881 constant
+
+     'S'
+          Operands that satisfy 'm' when -mpcrel is in effect
+
+     'T'
+          Operands that satisfy 's' when -mpcrel is not in effect
+
+     'Q'
+          Address register indirect addressing mode
+
+     'U'
+          Register offset addressing
+
+     'W'
+          const_call_operand
+
+     'Cs'
+          symbol_ref or const
+
+     'Ci'
+          const_int
+
+     'C0'
+          const_int 0
+
+     'Cj'
+          Range of signed numbers that don't fit in 16 bits
+
+     'Cmvq'
+          Integers valid for mvq
+
+     'Capsw'
+          Integers valid for a moveq followed by a swap
+
+     'Cmvz'
+          Integers valid for mvz
+
+     'Cmvs'
+          Integers valid for mvs
+
+     'Ap'
+          push_operand
+
+     'Ac'
+          Non-register operands allowed in clr
+
+_Moxie--'config/moxie/constraints.md'_
+     'A'
+          An absolute address
+
+     'B'
+          An offset address
+
+     'W'
+          A register indirect memory operand
+
+     'I'
+          A constant in the range of 0 to 255.
+
+     'N'
+          A constant in the range of 0 to -255.
+
+_MSP430-'config/msp430/constraints.md'_
+
+     'R12'
+          Register R12.
+
+     'R13'
+          Register R13.
+
+     'K'
+          Integer constant 1.
+
+     'L'
+          Integer constant -1^20..1^19.
+
+     'M'
+          Integer constant 1-4.
+
+     'Ya'
+          Memory references which do not require an extended MOVX
+          instruction.
+
+     'Yl'
+          Memory reference, labels only.
+
+     'Ys'
+          Memory reference, stack only.
+
+_NDS32--'config/nds32/constraints.md'_
+     'w'
+          LOW register class $r0 to $r7 constraint for V3/V3M ISA.
+     'l'
+          LOW register class $r0 to $r7.
+     'd'
+          MIDDLE register class $r0 to $r11, $r16 to $r19.
+     'h'
+          HIGH register class $r12 to $r14, $r20 to $r31.
+     't'
+          Temporary assist register $ta (i.e. $r15).
+     'k'
+          Stack register $sp.
+     'Iu03'
+          Unsigned immediate 3-bit value.
+     'In03'
+          Negative immediate 3-bit value in the range of -7-0.
+     'Iu04'
+          Unsigned immediate 4-bit value.
+     'Is05'
+          Signed immediate 5-bit value.
+     'Iu05'
+          Unsigned immediate 5-bit value.
+     'In05'
+          Negative immediate 5-bit value in the range of -31-0.
+     'Ip05'
+          Unsigned immediate 5-bit value for movpi45 instruction with
+          range 16-47.
+     'Iu06'
+          Unsigned immediate 6-bit value constraint for addri36.sp
+          instruction.
+     'Iu08'
+          Unsigned immediate 8-bit value.
+     'Iu09'
+          Unsigned immediate 9-bit value.
+     'Is10'
+          Signed immediate 10-bit value.
+     'Is11'
+          Signed immediate 11-bit value.
+     'Is15'
+          Signed immediate 15-bit value.
+     'Iu15'
+          Unsigned immediate 15-bit value.
+     'Ic15'
+          A constant which is not in the range of imm15u but ok for bclr
+          instruction.
+     'Ie15'
+          A constant which is not in the range of imm15u but ok for bset
+          instruction.
+     'It15'
+          A constant which is not in the range of imm15u but ok for btgl
+          instruction.
+     'Ii15'
+          A constant whose compliment value is in the range of imm15u
+          and ok for bitci instruction.
+     'Is16'
+          Signed immediate 16-bit value.
+     'Is17'
+          Signed immediate 17-bit value.
+     'Is19'
+          Signed immediate 19-bit value.
+     'Is20'
+          Signed immediate 20-bit value.
+     'Ihig'
+          The immediate value that can be simply set high 20-bit.
+     'Izeb'
+          The immediate value 0xff.
+     'Izeh'
+          The immediate value 0xffff.
+     'Ixls'
+          The immediate value 0x01.
+     'Ix11'
+          The immediate value 0x7ff.
+     'Ibms'
+          The immediate value with power of 2.
+     'Ifex'
+          The immediate value with power of 2 minus 1.
+     'U33'
+          Memory constraint for 333 format.
+     'U45'
+          Memory constraint for 45 format.
+     'U37'
+          Memory constraint for 37 format.
+
+_Nios II family--'config/nios2/constraints.md'_
+
+     'I'
+          Integer that is valid as an immediate operand in an
+          instruction taking a signed 16-bit number.  Range -32768 to
+          32767.
+
+     'J'
+          Integer that is valid as an immediate operand in an
+          instruction taking an unsigned 16-bit number.  Range 0 to
+          65535.
+
+     'K'
+          Integer that is valid as an immediate operand in an
+          instruction taking only the upper 16-bits of a 32-bit number.
+          Range 32-bit numbers with the lower 16-bits being 0.
+
+     'L'
+          Integer that is valid as an immediate operand for a shift
+          instruction.  Range 0 to 31.
+
+     'M'
+          Integer that is valid as an immediate operand for only the
+          value 0.  Can be used in conjunction with the format modifier
+          'z' to use 'r0' instead of '0' in the assembly output.
+
+     'N'
+          Integer that is valid as an immediate operand for a custom
+          instruction opcode.  Range 0 to 255.
+
+     'S'
+          Matches immediates which are addresses in the small data
+          section and therefore can be added to 'gp' as a 16-bit
+          immediate to re-create their 32-bit value.
+
+_PDP-11--'config/pdp11/constraints.md'_
+     'a'
+          Floating point registers AC0 through AC3.  These can be loaded
+          from/to memory with a single instruction.
+
+     'd'
+          Odd numbered general registers (R1, R3, R5).  These are used
+          for 16-bit multiply operations.
+
+     'f'
+          Any of the floating point registers (AC0 through AC5).
+
+     'G'
+          Floating point constant 0.
+
+     'I'
+          An integer constant that fits in 16 bits.
+
+     'J'
+          An integer constant whose low order 16 bits are zero.
+
+     'K'
+          An integer constant that does not meet the constraints for
+          codes 'I' or 'J'.
+
+     'L'
+          The integer constant 1.
+
+     'M'
+          The integer constant -1.
+
+     'N'
+          The integer constant 0.
+
+     'O'
+          Integer constants -4 through -1 and 1 through 4; shifts by
+          these amounts are handled as multiple single-bit shifts rather
+          than a single variable-length shift.
+
+     'Q'
+          A memory reference which requires an additional word (address
+          or offset) after the opcode.
+
+     'R'
+          A memory reference that is encoded within the opcode.
+
+_RL78--'config/rl78/constraints.md'_
+
+     'Int3'
+          An integer constant in the range 1 ... 7.
+     'Int8'
+          An integer constant in the range 0 ... 255.
+     'J'
+          An integer constant in the range -255 ... 0
+     'K'
+          The integer constant 1.
+     'L'
+          The integer constant -1.
+     'M'
+          The integer constant 0.
+     'N'
+          The integer constant 2.
+     'O'
+          The integer constant -2.
+     'P'
+          An integer constant in the range 1 ... 15.
+     'Qbi'
+          The built-in compare types-eq, ne, gtu, ltu, geu, and leu.
+     'Qsc'
+          The synthetic compare types-gt, lt, ge, and le.
+     'Wab'
+          A memory reference with an absolute address.
+     'Wbc'
+          A memory reference using 'BC' as a base register, with an
+          optional offset.
+     'Wca'
+          A memory reference using 'AX', 'BC', 'DE', or 'HL' for the
+          address, for calls.
+     'Wcv'
+          A memory reference using any 16-bit register pair for the
+          address, for calls.
+     'Wd2'
+          A memory reference using 'DE' as a base register, with an
+          optional offset.
+     'Wde'
+          A memory reference using 'DE' as a base register, without any
+          offset.
+     'Wfr'
+          Any memory reference to an address in the far address space.
+     'Wh1'
+          A memory reference using 'HL' as a base register, with an
+          optional one-byte offset.
+     'Whb'
+          A memory reference using 'HL' as a base register, with 'B' or
+          'C' as the index register.
+     'Whl'
+          A memory reference using 'HL' as a base register, without any
+          offset.
+     'Ws1'
+          A memory reference using 'SP' as a base register, with an
+          optional one-byte offset.
+     'Y'
+          Any memory reference to an address in the near address space.
+     'A'
+          The 'AX' register.
+     'B'
+          The 'BC' register.
+     'D'
+          The 'DE' register.
+     'R'
+          'A' through 'L' registers.
+     'S'
+          The 'SP' register.
+     'T'
+          The 'HL' register.
+     'Z08W'
+          The 16-bit 'R8' register.
+     'Z10W'
+          The 16-bit 'R10' register.
+     'Zint'
+          The registers reserved for interrupts ('R24' to 'R31').
+     'a'
+          The 'A' register.
+     'b'
+          The 'B' register.
+     'c'
+          The 'C' register.
+     'd'
+          The 'D' register.
+     'e'
+          The 'E' register.
+     'h'
+          The 'H' register.
+     'l'
+          The 'L' register.
+     'v'
+          The virtual registers.
+     'w'
+          The 'PSW' register.
+     'x'
+          The 'X' register.
+
+_RX--'config/rx/constraints.md'_
+     'Q'
+          An address which does not involve register indirect addressing
+          or pre/post increment/decrement addressing.
+
+     'Symbol'
+          A symbol reference.
+
+     'Int08'
+          A constant in the range -256 to 255, inclusive.
+
+     'Sint08'
+          A constant in the range -128 to 127, inclusive.
+
+     'Sint16'
+          A constant in the range -32768 to 32767, inclusive.
+
+     'Sint24'
+          A constant in the range -8388608 to 8388607, inclusive.
+
+     'Uint04'
+          A constant in the range 0 to 15, inclusive.
+
+_SPARC--'config/sparc/sparc.h'_
+     'f'
+          Floating-point register on the SPARC-V8 architecture and lower
+          floating-point register on the SPARC-V9 architecture.
+
+     'e'
+          Floating-point register.  It is equivalent to 'f' on the
+          SPARC-V8 architecture and contains both lower and upper
+          floating-point registers on the SPARC-V9 architecture.
+
+     'c'
+          Floating-point condition code register.
+
+     'd'
+          Lower floating-point register.  It is only valid on the
+          SPARC-V9 architecture when the Visual Instruction Set is
+          available.
+
+     'b'
+          Floating-point register.  It is only valid on the SPARC-V9
+          architecture when the Visual Instruction Set is available.
+
+     'h'
+          64-bit global or out register for the SPARC-V8+ architecture.
+
+     'C'
+          The constant all-ones, for floating-point.
+
+     'A'
+          Signed 5-bit constant
+
+     'D'
+          A vector constant
+
+     'I'
+          Signed 13-bit constant
+
+     'J'
+          Zero
+
+     'K'
+          32-bit constant with the low 12 bits clear (a constant that
+          can be loaded with the 'sethi' instruction)
+
+     'L'
+          A constant in the range supported by 'movcc' instructions
+          (11-bit signed immediate)
+
+     'M'
+          A constant in the range supported by 'movrcc' instructions
+          (10-bit signed immediate)
+
+     'N'
+          Same as 'K', except that it verifies that bits that are not in
+          the lower 32-bit range are all zero.  Must be used instead of
+          'K' for modes wider than 'SImode'
+
+     'O'
+          The constant 4096
+
+     'G'
+          Floating-point zero
+
+     'H'
+          Signed 13-bit constant, sign-extended to 32 or 64 bits
+
+     'P'
+          The constant -1
+
+     'Q'
+          Floating-point constant whose integral representation can be
+          moved into an integer register using a single sethi
+          instruction
+
+     'R'
+          Floating-point constant whose integral representation can be
+          moved into an integer register using a single mov instruction
+
+     'S'
+          Floating-point constant whose integral representation can be
+          moved into an integer register using a high/lo_sum instruction
+          sequence
+
+     'T'
+          Memory address aligned to an 8-byte boundary
+
+     'U'
+          Even register
+
+     'W'
+          Memory address for 'e' constraint registers
+
+     'w'
+          Memory address with only a base register
+
+     'Y'
+          Vector zero
+
+_SPU--'config/spu/spu.h'_
+     'a'
+          An immediate which can be loaded with the il/ila/ilh/ilhu
+          instructions.  const_int is treated as a 64 bit value.
+
+     'c'
+          An immediate for and/xor/or instructions.  const_int is
+          treated as a 64 bit value.
+
+     'd'
+          An immediate for the 'iohl' instruction.  const_int is treated
+          as a 64 bit value.
+
+     'f'
+          An immediate which can be loaded with 'fsmbi'.
+
+     'A'
+          An immediate which can be loaded with the il/ila/ilh/ilhu
+          instructions.  const_int is treated as a 32 bit value.
+
+     'B'
+          An immediate for most arithmetic instructions.  const_int is
+          treated as a 32 bit value.
+
+     'C'
+          An immediate for and/xor/or instructions.  const_int is
+          treated as a 32 bit value.
+
+     'D'
+          An immediate for the 'iohl' instruction.  const_int is treated
+          as a 32 bit value.
+
+     'I'
+          A constant in the range [-64, 63] for shift/rotate
+          instructions.
+
+     'J'
+          An unsigned 7-bit constant for conversion/nop/channel
+          instructions.
+
+     'K'
+          A signed 10-bit constant for most arithmetic instructions.
+
+     'M'
+          A signed 16 bit immediate for 'stop'.
+
+     'N'
+          An unsigned 16-bit constant for 'iohl' and 'fsmbi'.
+
+     'O'
+          An unsigned 7-bit constant whose 3 least significant bits are
+          0.
+
+     'P'
+          An unsigned 3-bit constant for 16-byte rotates and shifts
+
+     'R'
+          Call operand, reg, for indirect calls
+
+     'S'
+          Call operand, symbol, for relative calls.
+
+     'T'
+          Call operand, const_int, for absolute calls.
+
+     'U'
+          An immediate which can be loaded with the il/ila/ilh/ilhu
+          instructions.  const_int is sign extended to 128 bit.
+
+     'W'
+          An immediate for shift and rotate instructions.  const_int is
+          treated as a 32 bit value.
+
+     'Y'
+          An immediate for and/xor/or instructions.  const_int is sign
+          extended as a 128 bit.
+
+     'Z'
+          An immediate for the 'iohl' instruction.  const_int is sign
+          extended to 128 bit.
+
+_S/390 and zSeries--'config/s390/s390.h'_
+     'a'
+          Address register (general purpose register except r0)
+
+     'c'
+          Condition code register
+
+     'd'
+          Data register (arbitrary general purpose register)
+
+     'f'
+          Floating-point register
+
+     'I'
+          Unsigned 8-bit constant (0-255)
+
+     'J'
+          Unsigned 12-bit constant (0-4095)
+
+     'K'
+          Signed 16-bit constant (-32768-32767)
+
+     'L'
+          Value appropriate as displacement.
+          '(0..4095)'
+               for short displacement
+          '(-524288..524287)'
+               for long displacement
+
+     'M'
+          Constant integer with a value of 0x7fffffff.
+
+     'N'
+          Multiple letter constraint followed by 4 parameter letters.
+          '0..9:'
+               number of the part counting from most to least
+               significant
+          'H,Q:'
+               mode of the part
+          'D,S,H:'
+               mode of the containing operand
+          '0,F:'
+               value of the other parts (F--all bits set)
+          The constraint matches if the specified part of a constant has
+          a value different from its other parts.
+
+     'Q'
+          Memory reference without index register and with short
+          displacement.
+
+     'R'
+          Memory reference with index register and short displacement.
+
+     'S'
+          Memory reference without index register but with long
+          displacement.
+
+     'T'
+          Memory reference with index register and long displacement.
+
+     'U'
+          Pointer with short displacement.
+
+     'W'
+          Pointer with long displacement.
+
+     'Y'
+          Shift count operand.
+
+_Score family--'config/score/score.h'_
+     'd'
+          Registers from r0 to r32.
+
+     'e'
+          Registers from r0 to r16.
+
+     't'
+          r8--r11 or r22--r27 registers.
+
+     'h'
+          hi register.
+
+     'l'
+          lo register.
+
+     'x'
+          hi + lo register.
+
+     'q'
+          cnt register.
+
+     'y'
+          lcb register.
+
+     'z'
+          scb register.
+
+     'a'
+          cnt + lcb + scb register.
+
+     'c'
+          cr0--cr15 register.
+
+     'b'
+          cp1 registers.
+
+     'f'
+          cp2 registers.
+
+     'i'
+          cp3 registers.
+
+     'j'
+          cp1 + cp2 + cp3 registers.
+
+     'I'
+          High 16-bit constant (32-bit constant with 16 LSBs zero).
+
+     'J'
+          Unsigned 5 bit integer (in the range 0 to 31).
+
+     'K'
+          Unsigned 16 bit integer (in the range 0 to 65535).
+
+     'L'
+          Signed 16 bit integer (in the range -32768 to 32767).
+
+     'M'
+          Unsigned 14 bit integer (in the range 0 to 16383).
+
+     'N'
+          Signed 14 bit integer (in the range -8192 to 8191).
+
+     'Z'
+          Any SYMBOL_REF.
+
+_Xstormy16--'config/stormy16/stormy16.h'_
+     'a'
+          Register r0.
+
+     'b'
+          Register r1.
+
+     'c'
+          Register r2.
+
+     'd'
+          Register r8.
+
+     'e'
+          Registers r0 through r7.
+
+     't'
+          Registers r0 and r1.
+
+     'y'
+          The carry register.
+
+     'z'
+          Registers r8 and r9.
+
+     'I'
+          A constant between 0 and 3 inclusive.
+
+     'J'
+          A constant that has exactly one bit set.
+
+     'K'
+          A constant that has exactly one bit clear.
+
+     'L'
+          A constant between 0 and 255 inclusive.
+
+     'M'
+          A constant between -255 and 0 inclusive.
+
+     'N'
+          A constant between -3 and 0 inclusive.
+
+     'O'
+          A constant between 1 and 4 inclusive.
+
+     'P'
+          A constant between -4 and -1 inclusive.
+
+     'Q'
+          A memory reference that is a stack push.
+
+     'R'
+          A memory reference that is a stack pop.
+
+     'S'
+          A memory reference that refers to a constant address of known
+          value.
+
+     'T'
+          The register indicated by Rx (not implemented yet).
+
+     'U'
+          A constant that is not between 2 and 15 inclusive.
+
+     'Z'
+          The constant 0.
+
+_TI C6X family--'config/c6x/constraints.md'_
+     'a'
+          Register file A (A0-A31).
+
+     'b'
+          Register file B (B0-B31).
+
+     'A'
+          Predicate registers in register file A (A0-A2 on C64X and
+          higher, A1 and A2 otherwise).
+
+     'B'
+          Predicate registers in register file B (B0-B2).
+
+     'C'
+          A call-used register in register file B (B0-B9, B16-B31).
+
+     'Da'
+          Register file A, excluding predicate registers (A3-A31, plus
+          A0 if not C64X or higher).
+
+     'Db'
+          Register file B, excluding predicate registers (B3-B31).
+
+     'Iu4'
+          Integer constant in the range 0 ... 15.
+
+     'Iu5'
+          Integer constant in the range 0 ... 31.
+
+     'In5'
+          Integer constant in the range -31 ... 0.
+
+     'Is5'
+          Integer constant in the range -16 ... 15.
+
+     'I5x'
+          Integer constant that can be the operand of an ADDA or a SUBA
+          insn.
+
+     'IuB'
+          Integer constant in the range 0 ... 65535.
+
+     'IsB'
+          Integer constant in the range -32768 ... 32767.
+
+     'IsC'
+          Integer constant in the range -2^{20} ... 2^{20} - 1.
+
+     'Jc'
+          Integer constant that is a valid mask for the clr instruction.
+
+     'Js'
+          Integer constant that is a valid mask for the set instruction.
+
+     'Q'
+          Memory location with A base register.
+
+     'R'
+          Memory location with B base register.
+
+     'Z'
+          Register B14 (aka DP).
+
+_TILE-Gx--'config/tilegx/constraints.md'_
+     'R00'
+     'R01'
+     'R02'
+     'R03'
+     'R04'
+     'R05'
+     'R06'
+     'R07'
+     'R08'
+     'R09'
+     'R10'
+          Each of these represents a register constraint for an
+          individual register, from r0 to r10.
+
+     'I'
+          Signed 8-bit integer constant.
+
+     'J'
+          Signed 16-bit integer constant.
+
+     'K'
+          Unsigned 16-bit integer constant.
+
+     'L'
+          Integer constant that fits in one signed byte when incremented
+          by one (-129 ... 126).
+
+     'm'
+          Memory operand.  If used together with '<' or '>', the operand
+          can have postincrement which requires printing with '%In' and
+          '%in' on TILE-Gx.  For example:
+
+               asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val));
+
+     'M'
+          A bit mask suitable for the BFINS instruction.
+
+     'N'
+          Integer constant that is a byte tiled out eight times.
+
+     'O'
+          The integer zero constant.
+
+     'P'
+          Integer constant that is a sign-extended byte tiled out as
+          four shorts.
+
+     'Q'
+          Integer constant that fits in one signed byte when incremented
+          (-129 ... 126), but excluding -1.
+
+     'S'
+          Integer constant that has all 1 bits consecutive and starting
+          at bit 0.
+
+     'T'
+          A 16-bit fragment of a got, tls, or pc-relative reference.
+
+     'U'
+          Memory operand except postincrement.  This is roughly the same
+          as 'm' when not used together with '<' or '>'.
+
+     'W'
+          An 8-element vector constant with identical elements.
+
+     'Y'
+          A 4-element vector constant with identical elements.
+
+     'Z0'
+          The integer constant 0xffffffff.
+
+     'Z1'
+          The integer constant 0xffffffff00000000.
+
+_TILEPro--'config/tilepro/constraints.md'_
+     'R00'
+     'R01'
+     'R02'
+     'R03'
+     'R04'
+     'R05'
+     'R06'
+     'R07'
+     'R08'
+     'R09'
+     'R10'
+          Each of these represents a register constraint for an
+          individual register, from r0 to r10.
+
+     'I'
+          Signed 8-bit integer constant.
+
+     'J'
+          Signed 16-bit integer constant.
+
+     'K'
+          Nonzero integer constant with low 16 bits zero.
+
+     'L'
+          Integer constant that fits in one signed byte when incremented
+          by one (-129 ... 126).
+
+     'm'
+          Memory operand.  If used together with '<' or '>', the operand
+          can have postincrement which requires printing with '%In' and
+          '%in' on TILEPro.  For example:
+
+               asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val));
+
+     'M'
+          A bit mask suitable for the MM instruction.
+
+     'N'
+          Integer constant that is a byte tiled out four times.
+
+     'O'
+          The integer zero constant.
+
+     'P'
+          Integer constant that is a sign-extended byte tiled out as two
+          shorts.
+
+     'Q'
+          Integer constant that fits in one signed byte when incremented
+          (-129 ... 126), but excluding -1.
+
+     'T'
+          A symbolic operand, or a 16-bit fragment of a got, tls, or
+          pc-relative reference.
+
+     'U'
+          Memory operand except postincrement.  This is roughly the same
+          as 'm' when not used together with '<' or '>'.
+
+     'W'
+          A 4-element vector constant with identical elements.
+
+     'Y'
+          A 2-element vector constant with identical elements.
+
+_Xtensa--'config/xtensa/constraints.md'_
+     'a'
+          General-purpose 32-bit register
+
+     'b'
+          One-bit boolean register
+
+     'A'
+          MAC16 40-bit accumulator register
+
+     'I'
+          Signed 12-bit integer constant, for use in MOVI instructions
+
+     'J'
+          Signed 8-bit integer constant, for use in ADDI instructions
+
+     'K'
+          Integer constant valid for BccI instructions
+
+     'L'
+          Unsigned constant valid for BccUI instructions
+
+
+File: gcc.info,  Node: Asm Labels,  Next: Explicit Reg Vars,  Prev: Constraints,  Up: C Extensions
+
+6.43 Controlling Names Used in Assembler Code
+=============================================
+
+You can specify the name to be used in the assembler code for a C
+function or variable by writing the 'asm' (or '__asm__') keyword after
+the declarator as follows:
+
+     int foo asm ("myfoo") = 2;
+
+This specifies that the name to be used for the variable 'foo' in the
+assembler code should be 'myfoo' rather than the usual '_foo'.
+
+ On systems where an underscore is normally prepended to the name of a C
+function or variable, this feature allows you to define names for the
+linker that do not start with an underscore.
+
+ It does not make sense to use this feature with a non-static local
+variable since such variables do not have assembler names.  If you are
+trying to put the variable in a particular register, see *note Explicit
+Reg Vars::.  GCC presently accepts such code with a warning, but will
+probably be changed to issue an error, rather than a warning, in the
+future.
+
+ You cannot use 'asm' in this way in a function _definition_; but you
+can get the same effect by writing a declaration for the function before
+its definition and putting 'asm' there, like this:
+
+     extern func () asm ("FUNC");
+
+     func (x, y)
+          int x, y;
+     /* ... */
+
+ It is up to you to make sure that the assembler names you choose do not
+conflict with any other assembler symbols.  Also, you must not use a
+register name; that would produce completely invalid assembler code.
+GCC does not as yet have the ability to store static variables in
+registers.  Perhaps that will be added.
+
+
+File: gcc.info,  Node: Explicit Reg Vars,  Next: Alternate Keywords,  Prev: Asm Labels,  Up: C Extensions
+
+6.44 Variables in Specified Registers
+=====================================
+
+GNU C allows you to put a few global variables into specified hardware
+registers.  You can also specify the register in which an ordinary
+register variable should be allocated.
+
+   * Global register variables reserve registers throughout the program.
+     This may be useful in programs such as programming language
+     interpreters that have a couple of global variables that are
+     accessed very often.
+
+   * Local register variables in specific registers do not reserve the
+     registers, except at the point where they are used as input or
+     output operands in an 'asm' statement and the 'asm' statement
+     itself is not deleted.  The compiler's data flow analysis is
+     capable of determining where the specified registers contain live
+     values, and where they are available for other uses.  Stores into
+     local register variables may be deleted when they appear to be dead
+     according to dataflow analysis.  References to local register
+     variables may be deleted or moved or simplified.
+
+     These local variables are sometimes convenient for use with the
+     extended 'asm' feature (*note Extended Asm::), if you want to write
+     one output of the assembler instruction directly into a particular
+     register.  (This works provided the register you specify fits the
+     constraints specified for that operand in the 'asm'.)
+
+* Menu:
+
+* Global Reg Vars::
+* Local Reg Vars::
+
+
+File: gcc.info,  Node: Global Reg Vars,  Next: Local Reg Vars,  Up: Explicit Reg Vars
+
+6.44.1 Defining Global Register Variables
+-----------------------------------------
+
+You can define a global register variable in GNU C like this:
+
+     register int *foo asm ("a5");
+
+Here 'a5' is the name of the register that should be used.  Choose a
+register that is normally saved and restored by function calls on your
+machine, so that library routines will not clobber it.
+
+ Naturally the register name is cpu-dependent, so you need to
+conditionalize your program according to cpu type.  The register 'a5' is
+a good choice on a 68000 for a variable of pointer type.  On machines
+with register windows, be sure to choose a "global" register that is not
+affected magically by the function call mechanism.
+
+ In addition, different operating systems on the same CPU may differ in
+how they name the registers; then you need additional conditionals.  For
+example, some 68000 operating systems call this register '%a5'.
+
+ Eventually there may be a way of asking the compiler to choose a
+register automatically, but first we need to figure out how it should
+choose and how to enable you to guide the choice.  No solution is
+evident.
+
+ Defining a global register variable in a certain register reserves that
+register entirely for this use, at least within the current compilation.
+The register is not allocated for any other purpose in the functions in
+the current compilation, and is not saved and restored by these
+functions.  Stores into this register are never deleted even if they
+appear to be dead, but references may be deleted or moved or simplified.
+
+ It is not safe to access the global register variables from signal
+handlers, or from more than one thread of control, because the system
+library routines may temporarily use the register for other things
+(unless you recompile them specially for the task at hand).
+
+ It is not safe for one function that uses a global register variable to
+call another such function 'foo' by way of a third function 'lose' that
+is compiled without knowledge of this variable (i.e. in a different
+source file in which the variable isn't declared).  This is because
+'lose' might save the register and put some other value there.  For
+example, you can't expect a global register variable to be available in
+the comparison-function that you pass to 'qsort', since 'qsort' might
+have put something else in that register.  (If you are prepared to
+recompile 'qsort' with the same global register variable, you can solve
+this problem.)
+
+ If you want to recompile 'qsort' or other source files that do not
+actually use your global register variable, so that they do not use that
+register for any other purpose, then it suffices to specify the compiler
+option '-ffixed-REG'.  You need not actually add a global register
+declaration to their source code.
+
+ A function that can alter the value of a global register variable
+cannot safely be called from a function compiled without this variable,
+because it could clobber the value the caller expects to find there on
+return.  Therefore, the function that is the entry point into the part
+of the program that uses the global register variable must explicitly
+save and restore the value that belongs to its caller.
+
+ On most machines, 'longjmp' restores to each global register variable
+the value it had at the time of the 'setjmp'.  On some machines,
+however, 'longjmp' does not change the value of global register
+variables.  To be portable, the function that called 'setjmp' should
+make other arrangements to save the values of the global register
+variables, and to restore them in a 'longjmp'.  This way, the same thing
+happens regardless of what 'longjmp' does.
+
+ All global register variable declarations must precede all function
+definitions.  If such a declaration could appear after function
+definitions, the declaration would be too late to prevent the register
+from being used for other purposes in the preceding functions.
+
+ Global register variables may not have initial values, because an
+executable file has no means to supply initial contents for a register.
+
+ On the SPARC, there are reports that g3 ... g7 are suitable registers,
+but certain library functions, such as 'getwd', as well as the
+subroutines for division and remainder, modify g3 and g4.  g1 and g2 are
+local temporaries.
+
+ On the 68000, a2 ... a5 should be suitable, as should d2 ... d7.  Of
+course, it does not do to use more than a few of those.
+
+
+File: gcc.info,  Node: Local Reg Vars,  Prev: Global Reg Vars,  Up: Explicit Reg Vars
+
+6.44.2 Specifying Registers for Local Variables
+-----------------------------------------------
+
+You can define a local register variable with a specified register like
+this:
+
+     register int *foo asm ("a5");
+
+Here 'a5' is the name of the register that should be used.  Note that
+this is the same syntax used for defining global register variables, but
+for a local variable it appears within a function.
+
+ Naturally the register name is cpu-dependent, but this is not a
+problem, since specific registers are most often useful with explicit
+assembler instructions (*note Extended Asm::).  Both of these things
+generally require that you conditionalize your program according to cpu
+type.
+
+ In addition, operating systems on one type of cpu may differ in how
+they name the registers; then you need additional conditionals.  For
+example, some 68000 operating systems call this register '%a5'.
+
+ Defining such a register variable does not reserve the register; it
+remains available for other uses in places where flow control determines
+the variable's value is not live.
+
+ This option does not guarantee that GCC generates code that has this
+variable in the register you specify at all times.  You may not code an
+explicit reference to this register in the _assembler instruction
+template_ part of an 'asm' statement and assume it always refers to this
+variable.  However, using the variable as an 'asm' _operand_ guarantees
+that the specified register is used for the operand.
+
+ Stores into local register variables may be deleted when they appear to
+be dead according to dataflow analysis.  References to local register
+variables may be deleted or moved or simplified.
+
+ As for global register variables, it's recommended that you choose a
+register that is normally saved and restored by function calls on your
+machine, so that library routines will not clobber it.  A common pitfall
+is to initialize multiple call-clobbered registers with arbitrary
+expressions, where a function call or library call for an arithmetic
+operator overwrites a register value from a previous assignment, for
+example 'r0' below:
+     register int *p1 asm ("r0") = ...;
+     register int *p2 asm ("r1") = ...;
+
+In those cases, a solution is to use a temporary variable for each
+arbitrary expression.  *Note Example of asm with clobbered asm reg::.
+
+
+File: gcc.info,  Node: Alternate Keywords,  Next: Incomplete Enums,  Prev: Explicit Reg Vars,  Up: C Extensions
+
+6.45 Alternate Keywords
+=======================
+
+'-ansi' and the various '-std' options disable certain keywords.  This
+causes trouble when you want to use GNU C extensions, or a
+general-purpose header file that should be usable by all programs,
+including ISO C programs.  The keywords 'asm', 'typeof' and 'inline' are
+not available in programs compiled with '-ansi' or '-std' (although
+'inline' can be used in a program compiled with '-std=c99' or
+'-std=c11').  The ISO C99 keyword 'restrict' is only available when
+'-std=gnu99' (which will eventually be the default) or '-std=c99' (or
+the equivalent '-std=iso9899:1999'), or an option for a later standard
+version, is used.
+
+ The way to solve these problems is to put '__' at the beginning and end
+of each problematical keyword.  For example, use '__asm__' instead of
+'asm', and '__inline__' instead of 'inline'.
+
+ Other C compilers won't accept these alternative keywords; if you want
+to compile with another compiler, you can define the alternate keywords
+as macros to replace them with the customary keywords.  It looks like
+this:
+
+     #ifndef __GNUC__
+     #define __asm__ asm
+     #endif
+
+ '-pedantic' and other options cause warnings for many GNU C extensions.
+You can prevent such warnings within one expression by writing
+'__extension__' before the expression.  '__extension__' has no effect
+aside from this.
+
+
+File: gcc.info,  Node: Incomplete Enums,  Next: Function Names,  Prev: Alternate Keywords,  Up: C Extensions
+
+6.46 Incomplete 'enum' Types
+============================
+
+You can define an 'enum' tag without specifying its possible values.
+This results in an incomplete type, much like what you get if you write
+'struct foo' without describing the elements.  A later declaration that
+does specify the possible values completes the type.
+
+ You can't allocate variables or storage using the type while it is
+incomplete.  However, you can work with pointers to that type.
+
+ This extension may not be very useful, but it makes the handling of
+'enum' more consistent with the way 'struct' and 'union' are handled.
+
+ This extension is not supported by GNU C++.
+
+
+File: gcc.info,  Node: Function Names,  Next: Return Address,  Prev: Incomplete Enums,  Up: C Extensions
+
+6.47 Function Names as Strings
+==============================
+
+GCC provides three magic variables that hold the name of the current
+function, as a string.  The first of these is '__func__', which is part
+of the C99 standard:
+
+ The identifier '__func__' is implicitly declared by the translator as
+if, immediately following the opening brace of each function definition,
+the declaration
+
+     static const char __func__[] = "function-name";
+
+appeared, where function-name is the name of the lexically-enclosing
+function.  This name is the unadorned name of the function.
+
+ '__FUNCTION__' is another name for '__func__'.  Older versions of GCC
+recognize only this name.  However, it is not standardized.  For maximum
+portability, we recommend you use '__func__', but provide a fallback
+definition with the preprocessor:
+
+     #if __STDC_VERSION__ < 199901L
+     # if __GNUC__ >= 2
+     #  define __func__ __FUNCTION__
+     # else
+     #  define __func__ "<unknown>"
+     # endif
+     #endif
+
+ In C, '__PRETTY_FUNCTION__' is yet another name for '__func__'.
+However, in C++, '__PRETTY_FUNCTION__' contains the type signature of
+the function as well as its bare name.  For example, this program:
+
+     extern "C" {
+     extern int printf (char *, ...);
+     }
+
+     class a {
+      public:
+       void sub (int i)
+         {
+           printf ("__FUNCTION__ = %s\n", __FUNCTION__);
+           printf ("__PRETTY_FUNCTION__ = %s\n", __PRETTY_FUNCTION__);
+         }
+     };
+
+     int
+     main (void)
+     {
+       a ax;
+       ax.sub (0);
+       return 0;
+     }
+
+gives this output:
+
+     __FUNCTION__ = sub
+     __PRETTY_FUNCTION__ = void a::sub(int)
+
+ These identifiers are not preprocessor macros.  In GCC 3.3 and earlier,
+in C only, '__FUNCTION__' and '__PRETTY_FUNCTION__' were treated as
+string literals; they could be used to initialize 'char' arrays, and
+they could be concatenated with other string literals.  GCC 3.4 and
+later treat them as variables, like '__func__'.  In C++, '__FUNCTION__'
+and '__PRETTY_FUNCTION__' have always been variables.
+
+
+File: gcc.info,  Node: Return Address,  Next: Vector Extensions,  Prev: Function Names,  Up: C Extensions
+
+6.48 Getting the Return or Frame Address of a Function
+======================================================
+
+These functions may be used to get information about the callers of a
+function.
+
+ -- Built-in Function: void * __builtin_return_address (unsigned int
+          LEVEL)
+     This function returns the return address of the current function,
+     or of one of its callers.  The LEVEL argument is number of frames
+     to scan up the call stack.  A value of '0' yields the return
+     address of the current function, a value of '1' yields the return
+     address of the caller of the current function, and so forth.  When
+     inlining the expected behavior is that the function returns the
+     address of the function that is returned to.  To work around this
+     behavior use the 'noinline' function attribute.
+
+     The LEVEL argument must be a constant integer.
+
+     On some machines it may be impossible to determine the return
+     address of any function other than the current one; in such cases,
+     or when the top of the stack has been reached, this function
+     returns '0' or a random value.  In addition,
+     '__builtin_frame_address' may be used to determine if the top of
+     the stack has been reached.
+
+     Additional post-processing of the returned value may be needed, see
+     '__builtin_extract_return_addr'.
+
+     This function should only be used with a nonzero argument for
+     debugging purposes.
+
+ -- Built-in Function: void * __builtin_extract_return_addr (void *ADDR)
+     The address as returned by '__builtin_return_address' may have to
+     be fed through this function to get the actual encoded address.
+     For example, on the 31-bit S/390 platform the highest bit has to be
+     masked out, or on SPARC platforms an offset has to be added for the
+     true next instruction to be executed.
+
+     If no fixup is needed, this function simply passes through ADDR.
+
+ -- Built-in Function: void * __builtin_frob_return_address (void *ADDR)
+     This function does the reverse of '__builtin_extract_return_addr'.
+
+ -- Built-in Function: void * __builtin_frame_address (unsigned int
+          LEVEL)
+     This function is similar to '__builtin_return_address', but it
+     returns the address of the function frame rather than the return
+     address of the function.  Calling '__builtin_frame_address' with a
+     value of '0' yields the frame address of the current function, a
+     value of '1' yields the frame address of the caller of the current
+     function, and so forth.
+
+     The frame is the area on the stack that holds local variables and
+     saved registers.  The frame address is normally the address of the
+     first word pushed on to the stack by the function.  However, the
+     exact definition depends upon the processor and the calling
+     convention.  If the processor has a dedicated frame pointer
+     register, and the function has a frame, then
+     '__builtin_frame_address' returns the value of the frame pointer
+     register.
+
+     On some machines it may be impossible to determine the frame
+     address of any function other than the current one; in such cases,
+     or when the top of the stack has been reached, this function
+     returns '0' if the first frame pointer is properly initialized by
+     the startup code.
+
+     This function should only be used with a nonzero argument for
+     debugging purposes.
+
+
+File: gcc.info,  Node: Vector Extensions,  Next: Offsetof,  Prev: Return Address,  Up: C Extensions
+
+6.49 Using Vector Instructions through Built-in Functions
+=========================================================
+
+On some targets, the instruction set contains SIMD vector instructions
+which operate on multiple values contained in one large register at the
+same time.  For example, on the i386 the MMX, 3DNow! and SSE extensions
+can be used this way.
+
+ The first step in using these extensions is to provide the necessary
+data types.  This should be done using an appropriate 'typedef':
+
+     typedef int v4si __attribute__ ((vector_size (16)));
+
+The 'int' type specifies the base type, while the attribute specifies
+the vector size for the variable, measured in bytes.  For example, the
+declaration above causes the compiler to set the mode for the 'v4si'
+type to be 16 bytes wide and divided into 'int' sized units.  For a
+32-bit 'int' this means a vector of 4 units of 4 bytes, and the
+corresponding mode of 'foo' is V4SI.
+
+ The 'vector_size' attribute is only applicable to integral and float
+scalars, although arrays, pointers, and function return values are
+allowed in conjunction with this construct.  Only sizes that are a power
+of two are currently allowed.
+
+ All the basic integer types can be used as base types, both as signed
+and as unsigned: 'char', 'short', 'int', 'long', 'long long'.  In
+addition, 'float' and 'double' can be used to build floating-point
+vector types.
+
+ Specifying a combination that is not valid for the current architecture
+causes GCC to synthesize the instructions using a narrower mode.  For
+example, if you specify a variable of type 'V4SI' and your architecture
+does not allow for this specific SIMD type, GCC produces code that uses
+4 'SIs'.
+
+ The types defined in this manner can be used with a subset of normal C
+operations.  Currently, GCC allows using the following operators on
+these types: '+, -, *, /, unary minus, ^, |, &, ~, %'.
+
+ The operations behave like C++ 'valarrays'.  Addition is defined as the
+addition of the corresponding elements of the operands.  For example, in
+the code below, each of the 4 elements in A is added to the
+corresponding 4 elements in B and the resulting vector is stored in C.
+
+     typedef int v4si __attribute__ ((vector_size (16)));
+
+     v4si a, b, c;
+
+     c = a + b;
+
+ Subtraction, multiplication, division, and the logical operations
+operate in a similar manner.  Likewise, the result of using the unary
+minus or complement operators on a vector type is a vector whose
+elements are the negative or complemented values of the corresponding
+elements in the operand.
+
+ It is possible to use shifting operators '<<', '>>' on integer-type
+vectors.  The operation is defined as following: '{a0, a1, ..., an} >>
+{b0, b1, ..., bn} == {a0 >> b0, a1 >> b1, ..., an >> bn}'.  Vector
+operands must have the same number of elements.
+
+ For convenience, it is allowed to use a binary vector operation where
+one operand is a scalar.  In that case the compiler transforms the
+scalar operand into a vector where each element is the scalar from the
+operation.  The transformation happens only if the scalar could be
+safely converted to the vector-element type.  Consider the following
+code.
+
+     typedef int v4si __attribute__ ((vector_size (16)));
+
+     v4si a, b, c;
+     long l;
+
+     a = b + 1;    /* a = b + {1,1,1,1}; */
+     a = 2 * b;    /* a = {2,2,2,2} * b; */
+
+     a = l + a;    /* Error, cannot convert long to int. */
+
+ Vectors can be subscripted as if the vector were an array with the same
+number of elements and base type.  Out of bound accesses invoke
+undefined behavior at run time.  Warnings for out of bound accesses for
+vector subscription can be enabled with '-Warray-bounds'.
+
+ Vector comparison is supported with standard comparison operators: '==,
+!=, <, <=, >, >='.  Comparison operands can be vector expressions of
+integer-type or real-type.  Comparison between integer-type vectors and
+real-type vectors are not supported.  The result of the comparison is a
+vector of the same width and number of elements as the comparison
+operands with a signed integral element type.
+
+ Vectors are compared element-wise producing 0 when comparison is false
+and -1 (constant of the appropriate type where all bits are set)
+otherwise.  Consider the following example.
+
+     typedef int v4si __attribute__ ((vector_size (16)));
+
+     v4si a = {1,2,3,4};
+     v4si b = {3,2,1,4};
+     v4si c;
+
+     c = a >  b;     /* The result would be {0, 0,-1, 0}  */
+     c = a == b;     /* The result would be {0,-1, 0,-1}  */
+
+ In C++, the ternary operator '?:' is available.  'a?b:c', where 'b' and
+'c' are vectors of the same type and 'a' is an integer vector with the
+same number of elements of the same size as 'b' and 'c', computes all
+three arguments and creates a vector '{a[0]?b[0]:c[0], a[1]?b[1]:c[1],
+...}'.  Note that unlike in OpenCL, 'a' is thus interpreted as 'a != 0'
+and not 'a < 0'.  As in the case of binary operations, this syntax is
+also accepted when one of 'b' or 'c' is a scalar that is then
+transformed into a vector.  If both 'b' and 'c' are scalars and the type
+of 'true?b:c' has the same size as the element type of 'a', then 'b' and
+'c' are converted to a vector type whose elements have this type and
+with the same number of elements as 'a'.
+
+ Vector shuffling is available using functions '__builtin_shuffle (vec,
+mask)' and '__builtin_shuffle (vec0, vec1, mask)'.  Both functions
+construct a permutation of elements from one or two vectors and return a
+vector of the same type as the input vector(s).  The MASK is an integral
+vector with the same width (W) and element count (N) as the output
+vector.
+
+ The elements of the input vectors are numbered in memory ordering of
+VEC0 beginning at 0 and VEC1 beginning at N.  The elements of MASK are
+considered modulo N in the single-operand case and modulo 2*N in the
+two-operand case.
+
+ Consider the following example,
+
+     typedef int v4si __attribute__ ((vector_size (16)));
+
+     v4si a = {1,2,3,4};
+     v4si b = {5,6,7,8};
+     v4si mask1 = {0,1,1,3};
+     v4si mask2 = {0,4,2,5};
+     v4si res;
+
+     res = __builtin_shuffle (a, mask1);       /* res is {1,2,2,4}  */
+     res = __builtin_shuffle (a, b, mask2);    /* res is {1,5,3,6}  */
+
+ Note that '__builtin_shuffle' is intentionally semantically compatible
+with the OpenCL 'shuffle' and 'shuffle2' functions.
+
+ You can declare variables and use them in function calls and returns,
+as well as in assignments and some casts.  You can specify a vector type
+as a return type for a function.  Vector types can also be used as
+function arguments.  It is possible to cast from one vector type to
+another, provided they are of the same size (in fact, you can also cast
+vectors to and from other datatypes of the same size).
+
+ You cannot operate between vectors of different lengths or different
+signedness without a cast.
+
+
+File: gcc.info,  Node: Offsetof,  Next: __sync Builtins,  Prev: Vector Extensions,  Up: C Extensions
+
+6.50 Offsetof
+=============
+
+GCC implements for both C and C++ a syntactic extension to implement the
+'offsetof' macro.
+
+     primary:
+             "__builtin_offsetof" "(" typename "," offsetof_member_designator ")"
+
+     offsetof_member_designator:
+               identifier
+             | offsetof_member_designator "." identifier
+             | offsetof_member_designator "[" expr "]"
+
+ This extension is sufficient such that
+
+     #define offsetof(TYPE, MEMBER)  __builtin_offsetof (TYPE, MEMBER)
+
+is a suitable definition of the 'offsetof' macro.  In C++, TYPE may be
+dependent.  In either case, MEMBER may consist of a single identifier,
+or a sequence of member accesses and array references.
+
+
+File: gcc.info,  Node: __sync Builtins,  Next: __atomic Builtins,  Prev: Offsetof,  Up: C Extensions
+
+6.51 Legacy __sync Built-in Functions for Atomic Memory Access
+==============================================================
+
+The following built-in functions are intended to be compatible with
+those described in the 'Intel Itanium Processor-specific Application
+Binary Interface', section 7.4.  As such, they depart from the normal
+GCC practice of using the '__builtin_' prefix, and further that they are
+overloaded such that they work on multiple types.
+
+ The definition given in the Intel documentation allows only for the use
+of the types 'int', 'long', 'long long' as well as their unsigned
+counterparts.  GCC allows any integral scalar or pointer type that is 1,
+2, 4 or 8 bytes in length.
+
+ Not all operations are supported by all target processors.  If a
+particular operation cannot be implemented on the target processor, a
+warning is generated and a call an external function is generated.  The
+external function carries the same name as the built-in version, with an
+additional suffix '_N' where N is the size of the data type.
+
+ In most cases, these built-in functions are considered a "full
+barrier".  That is, no memory operand is moved across the operation,
+either forward or backward.  Further, instructions are issued as
+necessary to prevent the processor from speculating loads across the
+operation and from queuing stores after the operation.
+
+ All of the routines are described in the Intel documentation to take
+"an optional list of variables protected by the memory barrier".  It's
+not clear what is meant by that; it could mean that _only_ the following
+variables are protected, or it could mean that these variables should in
+addition be protected.  At present GCC ignores this list and protects
+all variables that are globally accessible.  If in the future we make
+some use of this list, an empty list will continue to mean all globally
+accessible variables.
+
+'TYPE __sync_fetch_and_add (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_fetch_and_sub (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_fetch_and_or (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_fetch_and_and (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_fetch_and_xor (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_fetch_and_nand (TYPE *ptr, TYPE value, ...)'
+     These built-in functions perform the operation suggested by the
+     name, and returns the value that had previously been in memory.
+     That is,
+
+          { tmp = *ptr; *ptr OP= value; return tmp; }
+          { tmp = *ptr; *ptr = ~(tmp & value); return tmp; }   // nand
+
+     _Note:_ GCC 4.4 and later implement '__sync_fetch_and_nand' as
+     '*ptr = ~(tmp & value)' instead of '*ptr = ~tmp & value'.
+
+'TYPE __sync_add_and_fetch (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_sub_and_fetch (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_or_and_fetch (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_and_and_fetch (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_xor_and_fetch (TYPE *ptr, TYPE value, ...)'
+'TYPE __sync_nand_and_fetch (TYPE *ptr, TYPE value, ...)'
+     These built-in functions perform the operation suggested by the
+     name, and return the new value.  That is,
+
+          { *ptr OP= value; return *ptr; }
+          { *ptr = ~(*ptr & value); return *ptr; }   // nand
+
+     _Note:_ GCC 4.4 and later implement '__sync_nand_and_fetch' as
+     '*ptr = ~(*ptr & value)' instead of '*ptr = ~*ptr & value'.
+
+'bool __sync_bool_compare_and_swap (TYPE *ptr, TYPE oldval, TYPE newval, ...)'
+'TYPE __sync_val_compare_and_swap (TYPE *ptr, TYPE oldval, TYPE newval, ...)'
+     These built-in functions perform an atomic compare and swap.  That
+     is, if the current value of '*PTR' is OLDVAL, then write NEWVAL
+     into '*PTR'.
+
+     The "bool" version returns true if the comparison is successful and
+     NEWVAL is written.  The "val" version returns the contents of
+     '*PTR' before the operation.
+
+'__sync_synchronize (...)'
+     This built-in function issues a full memory barrier.
+
+'TYPE __sync_lock_test_and_set (TYPE *ptr, TYPE value, ...)'
+     This built-in function, as described by Intel, is not a traditional
+     test-and-set operation, but rather an atomic exchange operation.
+     It writes VALUE into '*PTR', and returns the previous contents of
+     '*PTR'.
+
+     Many targets have only minimal support for such locks, and do not
+     support a full exchange operation.  In this case, a target may
+     support reduced functionality here by which the _only_ valid value
+     to store is the immediate constant 1.  The exact value actually
+     stored in '*PTR' is implementation defined.
+
+     This built-in function is not a full barrier, but rather an
+     "acquire barrier".  This means that references after the operation
+     cannot move to (or be speculated to) before the operation, but
+     previous memory stores may not be globally visible yet, and
+     previous memory loads may not yet be satisfied.
+
+'void __sync_lock_release (TYPE *ptr, ...)'
+     This built-in function releases the lock acquired by
+     '__sync_lock_test_and_set'.  Normally this means writing the
+     constant 0 to '*PTR'.
+
+     This built-in function is not a full barrier, but rather a "release
+     barrier".  This means that all previous memory stores are globally
+     visible, and all previous memory loads have been satisfied, but
+     following memory reads are not prevented from being speculated to
+     before the barrier.
+
+
+File: gcc.info,  Node: __atomic Builtins,  Next: x86 specific memory model extensions for transactional memory,  Prev: __sync Builtins,  Up: C Extensions
+
+6.52 Built-in functions for memory model aware atomic operations
+================================================================
+
+The following built-in functions approximately match the requirements
+for C++11 memory model.  Many are similar to the '__sync' prefixed
+built-in functions, but all also have a memory model parameter.  These
+are all identified by being prefixed with '__atomic', and most are
+overloaded such that they work with multiple types.
+
+ GCC allows any integral scalar or pointer type that is 1, 2, 4, or 8
+bytes in length.  16-byte integral types are also allowed if '__int128'
+(*note __int128::) is supported by the architecture.
+
+ Target architectures are encouraged to provide their own patterns for
+each of these built-in functions.  If no target is provided, the
+original non-memory model set of '__sync' atomic built-in functions are
+utilized, along with any required synchronization fences surrounding it
+in order to achieve the proper behavior.  Execution in this case is
+subject to the same restrictions as those built-in functions.
+
+ If there is no pattern or mechanism to provide a lock free instruction
+sequence, a call is made to an external routine with the same parameters
+to be resolved at run time.
+
+ The four non-arithmetic functions (load, store, exchange, and
+compare_exchange) all have a generic version as well.  This generic
+version works on any data type.  If the data type size maps to one of
+the integral sizes that may have lock free support, the generic version
+utilizes the lock free built-in function.  Otherwise an external call is
+left to be resolved at run time.  This external call is the same format
+with the addition of a 'size_t' parameter inserted as the first
+parameter indicating the size of the object being pointed to.  All
+objects must be the same size.
+
+ There are 6 different memory models that can be specified.  These map
+to the same names in the C++11 standard.  Refer there or to the GCC wiki
+on atomic synchronization
+(http://gcc.gnu.org/wiki/Atomic/GCCMM/AtomicSync) for more detailed
+definitions.  These memory models integrate both barriers to code motion
+as well as synchronization requirements with other threads.  These are
+listed in approximately ascending order of strength.  It is also
+possible to use target specific flags for memory model flags, like
+Hardware Lock Elision.
+
+'__ATOMIC_RELAXED'
+     No barriers or synchronization.
+'__ATOMIC_CONSUME'
+     Data dependency only for both barrier and synchronization with
+     another thread.
+'__ATOMIC_ACQUIRE'
+     Barrier to hoisting of code and synchronizes with release (or
+     stronger) semantic stores from another thread.
+'__ATOMIC_RELEASE'
+     Barrier to sinking of code and synchronizes with acquire (or
+     stronger) semantic loads from another thread.
+'__ATOMIC_ACQ_REL'
+     Full barrier in both directions and synchronizes with acquire loads
+     and release stores in another thread.
+'__ATOMIC_SEQ_CST'
+     Full barrier in both directions and synchronizes with acquire loads
+     and release stores in all threads.
+
+ When implementing patterns for these built-in functions, the memory
+model parameter can be ignored as long as the pattern implements the
+most restrictive '__ATOMIC_SEQ_CST' model.  Any of the other memory
+models execute correctly with this memory model but they may not execute
+as efficiently as they could with a more appropriate implementation of
+the relaxed requirements.
+
+ Note that the C++11 standard allows for the memory model parameter to
+be determined at run time rather than at compile time.  These built-in
+functions map any run-time value to '__ATOMIC_SEQ_CST' rather than
+invoke a runtime library call or inline a switch statement.  This is
+standard compliant, safe, and the simplest approach for now.
+
+ The memory model parameter is a signed int, but only the lower 8 bits
+are reserved for the memory model.  The remainder of the signed int is
+reserved for future use and should be 0.  Use of the predefined atomic
+values ensures proper usage.
+
+ -- Built-in Function: TYPE __atomic_load_n (TYPE *ptr, int memmodel)
+     This built-in function implements an atomic load operation.  It
+     returns the contents of '*PTR'.
+
+     The valid memory model variants are '__ATOMIC_RELAXED',
+     '__ATOMIC_SEQ_CST', '__ATOMIC_ACQUIRE', and '__ATOMIC_CONSUME'.
+
+ -- Built-in Function: void __atomic_load (TYPE *ptr, TYPE *ret, int
+          memmodel)
+     This is the generic version of an atomic load.  It returns the
+     contents of '*PTR' in '*RET'.
+
+ -- Built-in Function: void __atomic_store_n (TYPE *ptr, TYPE val, int
+          memmodel)
+     This built-in function implements an atomic store operation.  It
+     writes 'VAL' into '*PTR'.
+
+     The valid memory model variants are '__ATOMIC_RELAXED',
+     '__ATOMIC_SEQ_CST', and '__ATOMIC_RELEASE'.
+
+ -- Built-in Function: void __atomic_store (TYPE *ptr, TYPE *val, int
+          memmodel)
+     This is the generic version of an atomic store.  It stores the
+     value of '*VAL' into '*PTR'.
+
+ -- Built-in Function: TYPE __atomic_exchange_n (TYPE *ptr, TYPE val,
+          int memmodel)
+     This built-in function implements an atomic exchange operation.  It
+     writes VAL into '*PTR', and returns the previous contents of
+     '*PTR'.
+
+     The valid memory model variants are '__ATOMIC_RELAXED',
+     '__ATOMIC_SEQ_CST', '__ATOMIC_ACQUIRE', '__ATOMIC_RELEASE', and
+     '__ATOMIC_ACQ_REL'.
+
+ -- Built-in Function: void __atomic_exchange (TYPE *ptr, TYPE *val,
+          TYPE *ret, int memmodel)
+     This is the generic version of an atomic exchange.  It stores the
+     contents of '*VAL' into '*PTR'.  The original value of '*PTR' is
+     copied into '*RET'.
+
+ -- Built-in Function: bool __atomic_compare_exchange_n (TYPE *ptr, TYPE
+          *expected, TYPE desired, bool weak, int success_memmodel, int
+          failure_memmodel)
+     This built-in function implements an atomic compare and exchange
+     operation.  This compares the contents of '*PTR' with the contents
+     of '*EXPECTED' and if equal, writes DESIRED into '*PTR'.  If they
+     are not equal, the current contents of '*PTR' is written into
+     '*EXPECTED'.  WEAK is true for weak compare_exchange, and false for
+     the strong variation.  Many targets only offer the strong variation
+     and ignore the parameter.  When in doubt, use the strong variation.
+
+     True is returned if DESIRED is written into '*PTR' and the
+     execution is considered to conform to the memory model specified by
+     SUCCESS_MEMMODEL.  There are no restrictions on what memory model
+     can be used here.
+
+     False is returned otherwise, and the execution is considered to
+     conform to FAILURE_MEMMODEL.  This memory model cannot be
+     '__ATOMIC_RELEASE' nor '__ATOMIC_ACQ_REL'.  It also cannot be a
+     stronger model than that specified by SUCCESS_MEMMODEL.
+
+ -- Built-in Function: bool __atomic_compare_exchange (TYPE *ptr, TYPE
+          *expected, TYPE *desired, bool weak, int success_memmodel, int
+          failure_memmodel)
+     This built-in function implements the generic version of
+     '__atomic_compare_exchange'.  The function is virtually identical
+     to '__atomic_compare_exchange_n', except the desired value is also
+     a pointer.
+
+ -- Built-in Function: TYPE __atomic_add_fetch (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_sub_fetch (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_and_fetch (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_xor_fetch (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_or_fetch (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_nand_fetch (TYPE *ptr, TYPE val,
+          int memmodel)
+     These built-in functions perform the operation suggested by the
+     name, and return the result of the operation.  That is,
+
+          { *ptr OP= val; return *ptr; }
+
+     All memory models are valid.
+
+ -- Built-in Function: TYPE __atomic_fetch_add (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_fetch_sub (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_fetch_and (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_fetch_xor (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_fetch_or (TYPE *ptr, TYPE val, int
+          memmodel)
+ -- Built-in Function: TYPE __atomic_fetch_nand (TYPE *ptr, TYPE val,
+          int memmodel)
+     These built-in functions perform the operation suggested by the
+     name, and return the value that had previously been in '*PTR'.
+     That is,
+
+          { tmp = *ptr; *ptr OP= val; return tmp; }
+
+     All memory models are valid.
+
+ -- Built-in Function: bool __atomic_test_and_set (void *ptr, int
+          memmodel)
+
+     This built-in function performs an atomic test-and-set operation on
+     the byte at '*PTR'.  The byte is set to some implementation defined
+     nonzero "set" value and the return value is 'true' if and only if
+     the previous contents were "set".  It should be only used for
+     operands of type 'bool' or 'char'.  For other types only part of
+     the value may be set.
+
+     All memory models are valid.
+
+ -- Built-in Function: void __atomic_clear (bool *ptr, int memmodel)
+
+     This built-in function performs an atomic clear operation on
+     '*PTR'.  After the operation, '*PTR' contains 0.  It should be only
+     used for operands of type 'bool' or 'char' and in conjunction with
+     '__atomic_test_and_set'.  For other types it may only clear
+     partially.  If the type is not 'bool' prefer using
+     '__atomic_store'.
+
+     The valid memory model variants are '__ATOMIC_RELAXED',
+     '__ATOMIC_SEQ_CST', and '__ATOMIC_RELEASE'.
+
+ -- Built-in Function: void __atomic_thread_fence (int memmodel)
+
+     This built-in function acts as a synchronization fence between
+     threads based on the specified memory model.
+
+     All memory orders are valid.
+
+ -- Built-in Function: void __atomic_signal_fence (int memmodel)
+
+     This built-in function acts as a synchronization fence between a
+     thread and signal handlers based in the same thread.
+
+     All memory orders are valid.
+
+ -- Built-in Function: bool __atomic_always_lock_free (size_t size, void
+          *ptr)
+
+     This built-in function returns true if objects of SIZE bytes always
+     generate lock free atomic instructions for the target architecture.
+     SIZE must resolve to a compile-time constant and the result also
+     resolves to a compile-time constant.
+
+     PTR is an optional pointer to the object that may be used to
+     determine alignment.  A value of 0 indicates typical alignment
+     should be used.  The compiler may also ignore this parameter.
+
+          if (_atomic_always_lock_free (sizeof (long long), 0))
+
+ -- Built-in Function: bool __atomic_is_lock_free (size_t size, void
+          *ptr)
+
+     This built-in function returns true if objects of SIZE bytes always
+     generate lock free atomic instructions for the target architecture.
+     If it is not known to be lock free a call is made to a runtime
+     routine named '__atomic_is_lock_free'.
+
+     PTR is an optional pointer to the object that may be used to
+     determine alignment.  A value of 0 indicates typical alignment
+     should be used.  The compiler may also ignore this parameter.
+
+
+File: gcc.info,  Node: x86 specific memory model extensions for transactional memory,  Next: Object Size Checking,  Prev: __atomic Builtins,  Up: C Extensions
+
+6.53 x86 specific memory model extensions for transactional memory
+==================================================================
+
+The i386 architecture supports additional memory ordering flags to mark
+lock critical sections for hardware lock elision.  These must be
+specified in addition to an existing memory model to atomic intrinsics.
+
+'__ATOMIC_HLE_ACQUIRE'
+     Start lock elision on a lock variable.  Memory model must be
+     '__ATOMIC_ACQUIRE' or stronger.
+'__ATOMIC_HLE_RELEASE'
+     End lock elision on a lock variable.  Memory model must be
+     '__ATOMIC_RELEASE' or stronger.
+
+ When a lock acquire fails it is required for good performance to abort
+the transaction quickly.  This can be done with a '_mm_pause'
+
+     #include <immintrin.h> // For _mm_pause
+
+     int lockvar;
+
+     /* Acquire lock with lock elision */
+     while (__atomic_exchange_n(&lockvar, 1, __ATOMIC_ACQUIRE|__ATOMIC_HLE_ACQUIRE))
+         _mm_pause(); /* Abort failed transaction */
+     ...
+     /* Free lock with lock elision */
+     __atomic_store_n(&lockvar, 0, __ATOMIC_RELEASE|__ATOMIC_HLE_RELEASE);
+
+
+File: gcc.info,  Node: Object Size Checking,  Next: Cilk Plus Builtins,  Prev: x86 specific memory model extensions for transactional memory,  Up: C Extensions
+
+6.54 Object Size Checking Built-in Functions
+============================================
+
+GCC implements a limited buffer overflow protection mechanism that can
+prevent some buffer overflow attacks.
+
+ -- Built-in Function: size_t __builtin_object_size (void * PTR, int
+          TYPE)
+     is a built-in construct that returns a constant number of bytes
+     from PTR to the end of the object PTR pointer points to (if known
+     at compile time).  '__builtin_object_size' never evaluates its
+     arguments for side-effects.  If there are any side-effects in them,
+     it returns '(size_t) -1' for TYPE 0 or 1 and '(size_t) 0' for TYPE
+     2 or 3.  If there are multiple objects PTR can point to and all of
+     them are known at compile time, the returned number is the maximum
+     of remaining byte counts in those objects if TYPE & 2 is 0 and
+     minimum if nonzero.  If it is not possible to determine which
+     objects PTR points to at compile time, '__builtin_object_size'
+     should return '(size_t) -1' for TYPE 0 or 1 and '(size_t) 0' for
+     TYPE 2 or 3.
+
+     TYPE is an integer constant from 0 to 3.  If the least significant
+     bit is clear, objects are whole variables, if it is set, a closest
+     surrounding subobject is considered the object a pointer points to.
+     The second bit determines if maximum or minimum of remaining bytes
+     is computed.
+
+          struct V { char buf1[10]; int b; char buf2[10]; } var;
+          char *p = &var.buf1[1], *q = &var.b;
+
+          /* Here the object p points to is var.  */
+          assert (__builtin_object_size (p, 0) == sizeof (var) - 1);
+          /* The subobject p points to is var.buf1.  */
+          assert (__builtin_object_size (p, 1) == sizeof (var.buf1) - 1);
+          /* The object q points to is var.  */
+          assert (__builtin_object_size (q, 0)
+                  == (char *) (&var + 1) - (char *) &var.b);
+          /* The subobject q points to is var.b.  */
+          assert (__builtin_object_size (q, 1) == sizeof (var.b));
+
+ There are built-in functions added for many common string operation
+functions, e.g., for 'memcpy' '__builtin___memcpy_chk' built-in is
+provided.  This built-in has an additional last argument, which is the
+number of bytes remaining in object the DEST argument points to or
+'(size_t) -1' if the size is not known.
+
+ The built-in functions are optimized into the normal string functions
+like 'memcpy' if the last argument is '(size_t) -1' or if it is known at
+compile time that the destination object will not be overflown.  If the
+compiler can determine at compile time the object will be always
+overflown, it issues a warning.
+
+ The intended use can be e.g.
+
+     #undef memcpy
+     #define bos0(dest) __builtin_object_size (dest, 0)
+     #define memcpy(dest, src, n) \
+       __builtin___memcpy_chk (dest, src, n, bos0 (dest))
+
+     char *volatile p;
+     char buf[10];
+     /* It is unknown what object p points to, so this is optimized
+        into plain memcpy - no checking is possible.  */
+     memcpy (p, "abcde", n);
+     /* Destination is known and length too.  It is known at compile
+        time there will be no overflow.  */
+     memcpy (&buf[5], "abcde", 5);
+     /* Destination is known, but the length is not known at compile time.
+        This will result in __memcpy_chk call that can check for overflow
+        at run time.  */
+     memcpy (&buf[5], "abcde", n);
+     /* Destination is known and it is known at compile time there will
+        be overflow.  There will be a warning and __memcpy_chk call that
+        will abort the program at run time.  */
+     memcpy (&buf[6], "abcde", 5);
+
+ Such built-in functions are provided for 'memcpy', 'mempcpy',
+'memmove', 'memset', 'strcpy', 'stpcpy', 'strncpy', 'strcat' and
+'strncat'.
+
+ There are also checking built-in functions for formatted output
+functions.
+     int __builtin___sprintf_chk (char *s, int flag, size_t os, const char *fmt, ...);
+     int __builtin___snprintf_chk (char *s, size_t maxlen, int flag, size_t os,
+                                   const char *fmt, ...);
+     int __builtin___vsprintf_chk (char *s, int flag, size_t os, const char *fmt,
+                                   va_list ap);
+     int __builtin___vsnprintf_chk (char *s, size_t maxlen, int flag, size_t os,
+                                    const char *fmt, va_list ap);
+
+ The added FLAG argument is passed unchanged to '__sprintf_chk' etc.
+functions and can contain implementation specific flags on what
+additional security measures the checking function might take, such as
+handling '%n' differently.
+
+ The OS argument is the object size S points to, like in the other
+built-in functions.  There is a small difference in the behavior though,
+if OS is '(size_t) -1', the built-in functions are optimized into the
+non-checking functions only if FLAG is 0, otherwise the checking
+function is called with OS argument set to '(size_t) -1'.
+
+ In addition to this, there are checking built-in functions
+'__builtin___printf_chk', '__builtin___vprintf_chk',
+'__builtin___fprintf_chk' and '__builtin___vfprintf_chk'.  These have
+just one additional argument, FLAG, right before format string FMT.  If
+the compiler is able to optimize them to 'fputc' etc. functions, it
+does, otherwise the checking function is called and the FLAG argument
+passed to it.
+
+
+File: gcc.info,  Node: Cilk Plus Builtins,  Next: Other Builtins,  Prev: Object Size Checking,  Up: C Extensions
+
+6.55 Cilk Plus C/C++ language extension Built-in Functions.
+===========================================================
+
+GCC provides support for the following built-in reduction funtions if
+Cilk Plus is enabled.  Cilk Plus can be enabled using the '-fcilkplus'
+flag.
+
+   * __sec_implicit_index
+   * __sec_reduce
+   * __sec_reduce_add
+   * __sec_reduce_all_nonzero
+   * __sec_reduce_all_zero
+   * __sec_reduce_any_nonzero
+   * __sec_reduce_any_zero
+   * __sec_reduce_max
+   * __sec_reduce_min
+   * __sec_reduce_max_ind
+   * __sec_reduce_min_ind
+   * __sec_reduce_mul
+   * __sec_reduce_mutating
+
+ Further details and examples about these built-in functions are
+described in the Cilk Plus language manual which can be found at
+<http://www.cilkplus.org>.
+
+
+File: gcc.info,  Node: Other Builtins,  Next: Target Builtins,  Prev: Cilk Plus Builtins,  Up: C Extensions
+
+6.56 Other Built-in Functions Provided by GCC
+=============================================
+
+GCC provides a large number of built-in functions other than the ones
+mentioned above.  Some of these are for internal use in the processing
+of exceptions or variable-length argument lists and are not documented
+here because they may change from time to time; we do not recommend
+general use of these functions.
+
+ The remaining functions are provided for optimization purposes.
+
+ GCC includes built-in versions of many of the functions in the standard
+C library.  The versions prefixed with '__builtin_' are always treated
+as having the same meaning as the C library function even if you specify
+the '-fno-builtin' option.  (*note C Dialect Options::) Many of these
+functions are only optimized in certain cases; if they are not optimized
+in a particular case, a call to the library function is emitted.
+
+ Outside strict ISO C mode ('-ansi', '-std=c90', '-std=c99' or
+'-std=c11'), the functions '_exit', 'alloca', 'bcmp', 'bzero',
+'dcgettext', 'dgettext', 'dremf', 'dreml', 'drem', 'exp10f', 'exp10l',
+'exp10', 'ffsll', 'ffsl', 'ffs', 'fprintf_unlocked', 'fputs_unlocked',
+'gammaf', 'gammal', 'gamma', 'gammaf_r', 'gammal_r', 'gamma_r',
+'gettext', 'index', 'isascii', 'j0f', 'j0l', 'j0', 'j1f', 'j1l', 'j1',
+'jnf', 'jnl', 'jn', 'lgammaf_r', 'lgammal_r', 'lgamma_r', 'mempcpy',
+'pow10f', 'pow10l', 'pow10', 'printf_unlocked', 'rindex', 'scalbf',
+'scalbl', 'scalb', 'signbit', 'signbitf', 'signbitl', 'signbitd32',
+'signbitd64', 'signbitd128', 'significandf', 'significandl',
+'significand', 'sincosf', 'sincosl', 'sincos', 'stpcpy', 'stpncpy',
+'strcasecmp', 'strdup', 'strfmon', 'strncasecmp', 'strndup', 'toascii',
+'y0f', 'y0l', 'y0', 'y1f', 'y1l', 'y1', 'ynf', 'ynl' and 'yn' may be
+handled as built-in functions.  All these functions have corresponding
+versions prefixed with '__builtin_', which may be used even in strict
+C90 mode.
+
+ The ISO C99 functions '_Exit', 'acoshf', 'acoshl', 'acosh', 'asinhf',
+'asinhl', 'asinh', 'atanhf', 'atanhl', 'atanh', 'cabsf', 'cabsl',
+'cabs', 'cacosf', 'cacoshf', 'cacoshl', 'cacosh', 'cacosl', 'cacos',
+'cargf', 'cargl', 'carg', 'casinf', 'casinhf', 'casinhl', 'casinh',
+'casinl', 'casin', 'catanf', 'catanhf', 'catanhl', 'catanh', 'catanl',
+'catan', 'cbrtf', 'cbrtl', 'cbrt', 'ccosf', 'ccoshf', 'ccoshl', 'ccosh',
+'ccosl', 'ccos', 'cexpf', 'cexpl', 'cexp', 'cimagf', 'cimagl', 'cimag',
+'clogf', 'clogl', 'clog', 'conjf', 'conjl', 'conj', 'copysignf',
+'copysignl', 'copysign', 'cpowf', 'cpowl', 'cpow', 'cprojf', 'cprojl',
+'cproj', 'crealf', 'creall', 'creal', 'csinf', 'csinhf', 'csinhl',
+'csinh', 'csinl', 'csin', 'csqrtf', 'csqrtl', 'csqrt', 'ctanf',
+'ctanhf', 'ctanhl', 'ctanh', 'ctanl', 'ctan', 'erfcf', 'erfcl', 'erfc',
+'erff', 'erfl', 'erf', 'exp2f', 'exp2l', 'exp2', 'expm1f', 'expm1l',
+'expm1', 'fdimf', 'fdiml', 'fdim', 'fmaf', 'fmal', 'fmaxf', 'fmaxl',
+'fmax', 'fma', 'fminf', 'fminl', 'fmin', 'hypotf', 'hypotl', 'hypot',
+'ilogbf', 'ilogbl', 'ilogb', 'imaxabs', 'isblank', 'iswblank',
+'lgammaf', 'lgammal', 'lgamma', 'llabs', 'llrintf', 'llrintl', 'llrint',
+'llroundf', 'llroundl', 'llround', 'log1pf', 'log1pl', 'log1p', 'log2f',
+'log2l', 'log2', 'logbf', 'logbl', 'logb', 'lrintf', 'lrintl', 'lrint',
+'lroundf', 'lroundl', 'lround', 'nearbyintf', 'nearbyintl', 'nearbyint',
+'nextafterf', 'nextafterl', 'nextafter', 'nexttowardf', 'nexttowardl',
+'nexttoward', 'remainderf', 'remainderl', 'remainder', 'remquof',
+'remquol', 'remquo', 'rintf', 'rintl', 'rint', 'roundf', 'roundl',
+'round', 'scalblnf', 'scalblnl', 'scalbln', 'scalbnf', 'scalbnl',
+'scalbn', 'snprintf', 'tgammaf', 'tgammal', 'tgamma', 'truncf',
+'truncl', 'trunc', 'vfscanf', 'vscanf', 'vsnprintf' and 'vsscanf' are
+handled as built-in functions except in strict ISO C90 mode ('-ansi' or
+'-std=c90').
+
+ There are also built-in versions of the ISO C99 functions 'acosf',
+'acosl', 'asinf', 'asinl', 'atan2f', 'atan2l', 'atanf', 'atanl',
+'ceilf', 'ceill', 'cosf', 'coshf', 'coshl', 'cosl', 'expf', 'expl',
+'fabsf', 'fabsl', 'floorf', 'floorl', 'fmodf', 'fmodl', 'frexpf',
+'frexpl', 'ldexpf', 'ldexpl', 'log10f', 'log10l', 'logf', 'logl',
+'modfl', 'modf', 'powf', 'powl', 'sinf', 'sinhf', 'sinhl', 'sinl',
+'sqrtf', 'sqrtl', 'tanf', 'tanhf', 'tanhl' and 'tanl' that are
+recognized in any mode since ISO C90 reserves these names for the
+purpose to which ISO C99 puts them.  All these functions have
+corresponding versions prefixed with '__builtin_'.
+
+ The ISO C94 functions 'iswalnum', 'iswalpha', 'iswcntrl', 'iswdigit',
+'iswgraph', 'iswlower', 'iswprint', 'iswpunct', 'iswspace', 'iswupper',
+'iswxdigit', 'towlower' and 'towupper' are handled as built-in functions
+except in strict ISO C90 mode ('-ansi' or '-std=c90').
+
+ The ISO C90 functions 'abort', 'abs', 'acos', 'asin', 'atan2', 'atan',
+'calloc', 'ceil', 'cosh', 'cos', 'exit', 'exp', 'fabs', 'floor', 'fmod',
+'fprintf', 'fputs', 'frexp', 'fscanf', 'isalnum', 'isalpha', 'iscntrl',
+'isdigit', 'isgraph', 'islower', 'isprint', 'ispunct', 'isspace',
+'isupper', 'isxdigit', 'tolower', 'toupper', 'labs', 'ldexp', 'log10',
+'log', 'malloc', 'memchr', 'memcmp', 'memcpy', 'memset', 'modf', 'pow',
+'printf', 'putchar', 'puts', 'scanf', 'sinh', 'sin', 'snprintf',
+'sprintf', 'sqrt', 'sscanf', 'strcat', 'strchr', 'strcmp', 'strcpy',
+'strcspn', 'strlen', 'strncat', 'strncmp', 'strncpy', 'strpbrk',
+'strrchr', 'strspn', 'strstr', 'tanh', 'tan', 'vfprintf', 'vprintf' and
+'vsprintf' are all recognized as built-in functions unless
+'-fno-builtin' is specified (or '-fno-builtin-FUNCTION' is specified for
+an individual function).  All of these functions have corresponding
+versions prefixed with '__builtin_'.
+
+ GCC provides built-in versions of the ISO C99 floating-point comparison
+macros that avoid raising exceptions for unordered operands.  They have
+the same names as the standard macros ( 'isgreater', 'isgreaterequal',
+'isless', 'islessequal', 'islessgreater', and 'isunordered') , with
+'__builtin_' prefixed.  We intend for a library implementor to be able
+to simply '#define' each standard macro to its built-in equivalent.  In
+the same fashion, GCC provides 'fpclassify', 'isfinite', 'isinf_sign'
+and 'isnormal' built-ins used with '__builtin_' prefixed.  The 'isinf'
+and 'isnan' built-in functions appear both with and without the
+'__builtin_' prefix.
+
+ -- Built-in Function: int __builtin_types_compatible_p (TYPE1, TYPE2)
+
+     You can use the built-in function '__builtin_types_compatible_p' to
+     determine whether two types are the same.
+
+     This built-in function returns 1 if the unqualified versions of the
+     types TYPE1 and TYPE2 (which are types, not expressions) are
+     compatible, 0 otherwise.  The result of this built-in function can
+     be used in integer constant expressions.
+
+     This built-in function ignores top level qualifiers (e.g., 'const',
+     'volatile').  For example, 'int' is equivalent to 'const int'.
+
+     The type 'int[]' and 'int[5]' are compatible.  On the other hand,
+     'int' and 'char *' are not compatible, even if the size of their
+     types, on the particular architecture are the same.  Also, the
+     amount of pointer indirection is taken into account when
+     determining similarity.  Consequently, 'short *' is not similar to
+     'short **'.  Furthermore, two types that are typedefed are
+     considered compatible if their underlying types are compatible.
+
+     An 'enum' type is not considered to be compatible with another
+     'enum' type even if both are compatible with the same integer type;
+     this is what the C standard specifies.  For example, 'enum {foo,
+     bar}' is not similar to 'enum {hot, dog}'.
+
+     You typically use this function in code whose execution varies
+     depending on the arguments' types.  For example:
+
+          #define foo(x)                                                  \
+            ({                                                           \
+              typeof (x) tmp = (x);                                       \
+              if (__builtin_types_compatible_p (typeof (x), long double)) \
+                tmp = foo_long_double (tmp);                              \
+              else if (__builtin_types_compatible_p (typeof (x), double)) \
+                tmp = foo_double (tmp);                                   \
+              else if (__builtin_types_compatible_p (typeof (x), float))  \
+                tmp = foo_float (tmp);                                    \
+              else                                                        \
+                abort ();                                                 \
+              tmp;                                                        \
+            })
+
+     _Note:_ This construct is only available for C.
+
+ -- Built-in Function: TYPE __builtin_choose_expr (CONST_EXP, EXP1,
+          EXP2)
+
+     You can use the built-in function '__builtin_choose_expr' to
+     evaluate code depending on the value of a constant expression.
+     This built-in function returns EXP1 if CONST_EXP, which is an
+     integer constant expression, is nonzero.  Otherwise it returns
+     EXP2.
+
+     This built-in function is analogous to the '? :' operator in C,
+     except that the expression returned has its type unaltered by
+     promotion rules.  Also, the built-in function does not evaluate the
+     expression that is not chosen.  For example, if CONST_EXP evaluates
+     to true, EXP2 is not evaluated even if it has side-effects.
+
+     This built-in function can return an lvalue if the chosen argument
+     is an lvalue.
+
+     If EXP1 is returned, the return type is the same as EXP1's type.
+     Similarly, if EXP2 is returned, its return type is the same as
+     EXP2.
+
+     Example:
+
+          #define foo(x)                                                    \
+            __builtin_choose_expr (                                         \
+              __builtin_types_compatible_p (typeof (x), double),            \
+              foo_double (x),                                               \
+              __builtin_choose_expr (                                       \
+                __builtin_types_compatible_p (typeof (x), float),           \
+                foo_float (x),                                              \
+                /* The void expression results in a compile-time error  \
+                   when assigning the result to something.  */          \
+                (void)0))
+
+     _Note:_ This construct is only available for C.  Furthermore, the
+     unused expression (EXP1 or EXP2 depending on the value of
+     CONST_EXP) may still generate syntax errors.  This may change in
+     future revisions.
+
+ -- Built-in Function: TYPE __builtin_complex (REAL, IMAG)
+
+     The built-in function '__builtin_complex' is provided for use in
+     implementing the ISO C11 macros 'CMPLXF', 'CMPLX' and 'CMPLXL'.
+     REAL and IMAG must have the same type, a real binary floating-point
+     type, and the result has the corresponding complex type with real
+     and imaginary parts REAL and IMAG.  Unlike 'REAL + I * IMAG', this
+     works even when infinities, NaNs and negative zeros are involved.
+
+ -- Built-in Function: int __builtin_constant_p (EXP)
+     You can use the built-in function '__builtin_constant_p' to
+     determine if a value is known to be constant at compile time and
+     hence that GCC can perform constant-folding on expressions
+     involving that value.  The argument of the function is the value to
+     test.  The function returns the integer 1 if the argument is known
+     to be a compile-time constant and 0 if it is not known to be a
+     compile-time constant.  A return of 0 does not indicate that the
+     value is _not_ a constant, but merely that GCC cannot prove it is a
+     constant with the specified value of the '-O' option.
+
+     You typically use this function in an embedded application where
+     memory is a critical resource.  If you have some complex
+     calculation, you may want it to be folded if it involves constants,
+     but need to call a function if it does not.  For example:
+
+          #define Scale_Value(X)      \
+            (__builtin_constant_p (X) \
+            ? ((X) * SCALE + OFFSET) : Scale (X))
+
+     You may use this built-in function in either a macro or an inline
+     function.  However, if you use it in an inlined function and pass
+     an argument of the function as the argument to the built-in, GCC
+     never returns 1 when you call the inline function with a string
+     constant or compound literal (*note Compound Literals::) and does
+     not return 1 when you pass a constant numeric value to the inline
+     function unless you specify the '-O' option.
+
+     You may also use '__builtin_constant_p' in initializers for static
+     data.  For instance, you can write
+
+          static const int table[] = {
+             __builtin_constant_p (EXPRESSION) ? (EXPRESSION) : -1,
+             /* ... */
+          };
+
+     This is an acceptable initializer even if EXPRESSION is not a
+     constant expression, including the case where
+     '__builtin_constant_p' returns 1 because EXPRESSION can be folded
+     to a constant but EXPRESSION contains operands that are not
+     otherwise permitted in a static initializer (for example, '0 && foo
+     ()').  GCC must be more conservative about evaluating the built-in
+     in this case, because it has no opportunity to perform
+     optimization.
+
+     Previous versions of GCC did not accept this built-in in data
+     initializers.  The earliest version where it is completely safe is
+     3.0.1.
+
+ -- Built-in Function: long __builtin_expect (long EXP, long C)
+     You may use '__builtin_expect' to provide the compiler with branch
+     prediction information.  In general, you should prefer to use
+     actual profile feedback for this ('-fprofile-arcs'), as programmers
+     are notoriously bad at predicting how their programs actually
+     perform.  However, there are applications in which this data is
+     hard to collect.
+
+     The return value is the value of EXP, which should be an integral
+     expression.  The semantics of the built-in are that it is expected
+     that EXP == C.  For example:
+
+          if (__builtin_expect (x, 0))
+            foo ();
+
+     indicates that we do not expect to call 'foo', since we expect 'x'
+     to be zero.  Since you are limited to integral expressions for EXP,
+     you should use constructions such as
+
+          if (__builtin_expect (ptr != NULL, 1))
+            foo (*ptr);
+
+     when testing pointer or floating-point values.
+
+ -- Built-in Function: void __builtin_trap (void)
+     This function causes the program to exit abnormally.  GCC
+     implements this function by using a target-dependent mechanism
+     (such as intentionally executing an illegal instruction) or by
+     calling 'abort'.  The mechanism used may vary from release to
+     release so you should not rely on any particular implementation.
+
+ -- Built-in Function: void __builtin_unreachable (void)
+     If control flow reaches the point of the '__builtin_unreachable',
+     the program is undefined.  It is useful in situations where the
+     compiler cannot deduce the unreachability of the code.
+
+     One such case is immediately following an 'asm' statement that
+     either never terminates, or one that transfers control elsewhere
+     and never returns.  In this example, without the
+     '__builtin_unreachable', GCC issues a warning that control reaches
+     the end of a non-void function.  It also generates code to return
+     after the 'asm'.
+
+          int f (int c, int v)
+          {
+            if (c)
+              {
+                return v;
+              }
+            else
+              {
+                asm("jmp error_handler");
+                __builtin_unreachable ();
+              }
+          }
+
+     Because the 'asm' statement unconditionally transfers control out
+     of the function, control never reaches the end of the function
+     body.  The '__builtin_unreachable' is in fact unreachable and
+     communicates this fact to the compiler.
+
+     Another use for '__builtin_unreachable' is following a call a
+     function that never returns but that is not declared
+     '__attribute__((noreturn))', as in this example:
+
+          void function_that_never_returns (void);
+
+          int g (int c)
+          {
+            if (c)
+              {
+                return 1;
+              }
+            else
+              {
+                function_that_never_returns ();
+                __builtin_unreachable ();
+              }
+          }
+
+ -- Built-in Function: void *__builtin_assume_aligned (const void *EXP,
+          size_t ALIGN, ...)
+     This function returns its first argument, and allows the compiler
+     to assume that the returned pointer is at least ALIGN bytes
+     aligned.  This built-in can have either two or three arguments, if
+     it has three, the third argument should have integer type, and if
+     it is nonzero means misalignment offset.  For example:
+
+          void *x = __builtin_assume_aligned (arg, 16);
+
+     means that the compiler can assume 'x', set to 'arg', is at least
+     16-byte aligned, while:
+
+          void *x = __builtin_assume_aligned (arg, 32, 8);
+
+     means that the compiler can assume for 'x', set to 'arg', that
+     '(char *) x - 8' is 32-byte aligned.
+
+ -- Built-in Function: int __builtin_LINE ()
+     This function is the equivalent to the preprocessor '__LINE__'
+     macro and returns the line number of the invocation of the
+     built-in.  In a C++ default argument for a function F, it gets the
+     line number of the call to F.
+
+ -- Built-in Function: const char * __builtin_FUNCTION ()
+     This function is the equivalent to the preprocessor '__FUNCTION__'
+     macro and returns the function name the invocation of the built-in
+     is in.
+
+ -- Built-in Function: const char * __builtin_FILE ()
+     This function is the equivalent to the preprocessor '__FILE__'
+     macro and returns the file name the invocation of the built-in is
+     in.  In a C++ default argument for a function F, it gets the file
+     name of the call to F.
+
+ -- Built-in Function: void __builtin___clear_cache (char *BEGIN, char
+          *END)
+     This function is used to flush the processor's instruction cache
+     for the region of memory between BEGIN inclusive and END exclusive.
+     Some targets require that the instruction cache be flushed, after
+     modifying memory containing code, in order to obtain deterministic
+     behavior.
+
+     If the target does not require instruction cache flushes,
+     '__builtin___clear_cache' has no effect.  Otherwise either
+     instructions are emitted in-line to clear the instruction cache or
+     a call to the '__clear_cache' function in libgcc is made.
+
+ -- Built-in Function: void __builtin_prefetch (const void *ADDR, ...)
+     This function is used to minimize cache-miss latency by moving data
+     into a cache before it is accessed.  You can insert calls to
+     '__builtin_prefetch' into code for which you know addresses of data
+     in memory that is likely to be accessed soon.  If the target
+     supports them, data prefetch instructions are generated.  If the
+     prefetch is done early enough before the access then the data will
+     be in the cache by the time it is accessed.
+
+     The value of ADDR is the address of the memory to prefetch.  There
+     are two optional arguments, RW and LOCALITY.  The value of RW is a
+     compile-time constant one or zero; one means that the prefetch is
+     preparing for a write to the memory address and zero, the default,
+     means that the prefetch is preparing for a read.  The value
+     LOCALITY must be a compile-time constant integer between zero and
+     three.  A value of zero means that the data has no temporal
+     locality, so it need not be left in the cache after the access.  A
+     value of three means that the data has a high degree of temporal
+     locality and should be left in all levels of cache possible.
+     Values of one and two mean, respectively, a low or moderate degree
+     of temporal locality.  The default is three.
+
+          for (i = 0; i < n; i++)
+            {
+              a[i] = a[i] + b[i];
+              __builtin_prefetch (&a[i+j], 1, 1);
+              __builtin_prefetch (&b[i+j], 0, 1);
+              /* ... */
+            }
+
+     Data prefetch does not generate faults if ADDR is invalid, but the
+     address expression itself must be valid.  For example, a prefetch
+     of 'p->next' does not fault if 'p->next' is not a valid address,
+     but evaluation faults if 'p' is not a valid address.
+
+     If the target does not support data prefetch, the address
+     expression is evaluated if it includes side effects but no other
+     code is generated and GCC does not issue a warning.
+
+ -- Built-in Function: double __builtin_huge_val (void)
+     Returns a positive infinity, if supported by the floating-point
+     format, else 'DBL_MAX'.  This function is suitable for implementing
+     the ISO C macro 'HUGE_VAL'.
+
+ -- Built-in Function: float __builtin_huge_valf (void)
+     Similar to '__builtin_huge_val', except the return type is 'float'.
+
+ -- Built-in Function: long double __builtin_huge_vall (void)
+     Similar to '__builtin_huge_val', except the return type is 'long
+     double'.
+
+ -- Built-in Function: int __builtin_fpclassify (int, int, int, int,
+          int, ...)
+     This built-in implements the C99 fpclassify functionality.  The
+     first five int arguments should be the target library's notion of
+     the possible FP classes and are used for return values.  They must
+     be constant values and they must appear in this order: 'FP_NAN',
+     'FP_INFINITE', 'FP_NORMAL', 'FP_SUBNORMAL' and 'FP_ZERO'.  The
+     ellipsis is for exactly one floating-point value to classify.  GCC
+     treats the last argument as type-generic, which means it does not
+     do default promotion from float to double.
+
+ -- Built-in Function: double __builtin_inf (void)
+     Similar to '__builtin_huge_val', except a warning is generated if
+     the target floating-point format does not support infinities.
+
+ -- Built-in Function: _Decimal32 __builtin_infd32 (void)
+     Similar to '__builtin_inf', except the return type is '_Decimal32'.
+
+ -- Built-in Function: _Decimal64 __builtin_infd64 (void)
+     Similar to '__builtin_inf', except the return type is '_Decimal64'.
+
+ -- Built-in Function: _Decimal128 __builtin_infd128 (void)
+     Similar to '__builtin_inf', except the return type is
+     '_Decimal128'.
+
+ -- Built-in Function: float __builtin_inff (void)
+     Similar to '__builtin_inf', except the return type is 'float'.
+     This function is suitable for implementing the ISO C99 macro
+     'INFINITY'.
+
+ -- Built-in Function: long double __builtin_infl (void)
+     Similar to '__builtin_inf', except the return type is 'long
+     double'.
+
+ -- Built-in Function: int __builtin_isinf_sign (...)
+     Similar to 'isinf', except the return value is -1 for an argument
+     of '-Inf' and 1 for an argument of '+Inf'.  Note while the
+     parameter list is an ellipsis, this function only accepts exactly
+     one floating-point argument.  GCC treats this parameter as
+     type-generic, which means it does not do default promotion from
+     float to double.
+
+ -- Built-in Function: double __builtin_nan (const char *str)
+     This is an implementation of the ISO C99 function 'nan'.
+
+     Since ISO C99 defines this function in terms of 'strtod', which we
+     do not implement, a description of the parsing is in order.  The
+     string is parsed as by 'strtol'; that is, the base is recognized by
+     leading '0' or '0x' prefixes.  The number parsed is placed in the
+     significand such that the least significant bit of the number is at
+     the least significant bit of the significand.  The number is
+     truncated to fit the significand field provided.  The significand
+     is forced to be a quiet NaN.
+
+     This function, if given a string literal all of which would have
+     been consumed by 'strtol', is evaluated early enough that it is
+     considered a compile-time constant.
+
+ -- Built-in Function: _Decimal32 __builtin_nand32 (const char *str)
+     Similar to '__builtin_nan', except the return type is '_Decimal32'.
+
+ -- Built-in Function: _Decimal64 __builtin_nand64 (const char *str)
+     Similar to '__builtin_nan', except the return type is '_Decimal64'.
+
+ -- Built-in Function: _Decimal128 __builtin_nand128 (const char *str)
+     Similar to '__builtin_nan', except the return type is
+     '_Decimal128'.
+
+ -- Built-in Function: float __builtin_nanf (const char *str)
+     Similar to '__builtin_nan', except the return type is 'float'.
+
+ -- Built-in Function: long double __builtin_nanl (const char *str)
+     Similar to '__builtin_nan', except the return type is 'long
+     double'.
+
+ -- Built-in Function: double __builtin_nans (const char *str)
+     Similar to '__builtin_nan', except the significand is forced to be
+     a signaling NaN.  The 'nans' function is proposed by WG14 N965.
+
+ -- Built-in Function: float __builtin_nansf (const char *str)
+     Similar to '__builtin_nans', except the return type is 'float'.
+
+ -- Built-in Function: long double __builtin_nansl (const char *str)
+     Similar to '__builtin_nans', except the return type is 'long
+     double'.
+
+ -- Built-in Function: int __builtin_ffs (int x)
+     Returns one plus the index of the least significant 1-bit of X, or
+     if X is zero, returns zero.
+
+ -- Built-in Function: int __builtin_clz (unsigned int x)
+     Returns the number of leading 0-bits in X, starting at the most
+     significant bit position.  If X is 0, the result is undefined.
+
+ -- Built-in Function: int __builtin_ctz (unsigned int x)
+     Returns the number of trailing 0-bits in X, starting at the least
+     significant bit position.  If X is 0, the result is undefined.
+
+ -- Built-in Function: int __builtin_clrsb (int x)
+     Returns the number of leading redundant sign bits in X, i.e. the
+     number of bits following the most significant bit that are
+     identical to it.  There are no special cases for 0 or other values.
+
+ -- Built-in Function: int __builtin_popcount (unsigned int x)
+     Returns the number of 1-bits in X.
+
+ -- Built-in Function: int __builtin_parity (unsigned int x)
+     Returns the parity of X, i.e. the number of 1-bits in X modulo 2.
+
+ -- Built-in Function: int __builtin_ffsl (long)
+     Similar to '__builtin_ffs', except the argument type is 'long'.
+
+ -- Built-in Function: int __builtin_clzl (unsigned long)
+     Similar to '__builtin_clz', except the argument type is 'unsigned
+     long'.
+
+ -- Built-in Function: int __builtin_ctzl (unsigned long)
+     Similar to '__builtin_ctz', except the argument type is 'unsigned
+     long'.
+
+ -- Built-in Function: int __builtin_clrsbl (long)
+     Similar to '__builtin_clrsb', except the argument type is 'long'.
+
+ -- Built-in Function: int __builtin_popcountl (unsigned long)
+     Similar to '__builtin_popcount', except the argument type is
+     'unsigned long'.
+
+ -- Built-in Function: int __builtin_parityl (unsigned long)
+     Similar to '__builtin_parity', except the argument type is
+     'unsigned long'.
+
+ -- Built-in Function: int __builtin_ffsll (long long)
+     Similar to '__builtin_ffs', except the argument type is 'long
+     long'.
+
+ -- Built-in Function: int __builtin_clzll (unsigned long long)
+     Similar to '__builtin_clz', except the argument type is 'unsigned
+     long long'.
+
+ -- Built-in Function: int __builtin_ctzll (unsigned long long)
+     Similar to '__builtin_ctz', except the argument type is 'unsigned
+     long long'.
+
+ -- Built-in Function: int __builtin_clrsbll (long long)
+     Similar to '__builtin_clrsb', except the argument type is 'long
+     long'.
+
+ -- Built-in Function: int __builtin_popcountll (unsigned long long)
+     Similar to '__builtin_popcount', except the argument type is
+     'unsigned long long'.
+
+ -- Built-in Function: int __builtin_parityll (unsigned long long)
+     Similar to '__builtin_parity', except the argument type is
+     'unsigned long long'.
+
+ -- Built-in Function: double __builtin_powi (double, int)
+     Returns the first argument raised to the power of the second.
+     Unlike the 'pow' function no guarantees about precision and
+     rounding are made.
+
+ -- Built-in Function: float __builtin_powif (float, int)
+     Similar to '__builtin_powi', except the argument and return types
+     are 'float'.
+
+ -- Built-in Function: long double __builtin_powil (long double, int)
+     Similar to '__builtin_powi', except the argument and return types
+     are 'long double'.
+
+ -- Built-in Function: uint16_t __builtin_bswap16 (uint16_t x)
+     Returns X with the order of the bytes reversed; for example,
+     '0xaabb' becomes '0xbbaa'.  Byte here always means exactly 8 bits.
+
+ -- Built-in Function: uint32_t __builtin_bswap32 (uint32_t x)
+     Similar to '__builtin_bswap16', except the argument and return
+     types are 32 bit.
+
+ -- Built-in Function: uint64_t __builtin_bswap64 (uint64_t x)
+     Similar to '__builtin_bswap32', except the argument and return
+     types are 64 bit.
+
+
+File: gcc.info,  Node: Target Builtins,  Next: Target Format Checks,  Prev: Other Builtins,  Up: C Extensions
+
+6.57 Built-in Functions Specific to Particular Target Machines
+==============================================================
+
+On some target machines, GCC supports many built-in functions specific
+to those machines.  Generally these generate calls to specific machine
+instructions, but allow the compiler to schedule those calls.
+
+* Menu:
+
+* Alpha Built-in Functions::
+* Altera Nios II Built-in Functions::
+* ARC Built-in Functions::
+* ARC SIMD Built-in Functions::
+* ARM iWMMXt Built-in Functions::
+* ARM NEON Intrinsics::
+* ARM ACLE Intrinsics::
+* AVR Built-in Functions::
+* Blackfin Built-in Functions::
+* FR-V Built-in Functions::
+* X86 Built-in Functions::
+* X86 transactional memory intrinsics::
+* MIPS DSP Built-in Functions::
+* MIPS Paired-Single Support::
+* MIPS Loongson Built-in Functions::
+* Other MIPS Built-in Functions::
+* MSP430 Built-in Functions::
+* NDS32 Built-in Functions::
+* picoChip Built-in Functions::
+* PowerPC Built-in Functions::
+* PowerPC AltiVec/VSX Built-in Functions::
+* PowerPC Hardware Transactional Memory Built-in Functions::
+* RX Built-in Functions::
+* S/390 System z Built-in Functions::
+* SH Built-in Functions::
+* SPARC VIS Built-in Functions::
+* SPU Built-in Functions::
+* TI C6X Built-in Functions::
+* TILE-Gx Built-in Functions::
+* TILEPro Built-in Functions::
+
+
+File: gcc.info,  Node: Alpha Built-in Functions,  Next: Altera Nios II Built-in Functions,  Up: Target Builtins
+
+6.57.1 Alpha Built-in Functions
+-------------------------------
+
+These built-in functions are available for the Alpha family of
+processors, depending on the command-line switches used.
+
+ The following built-in functions are always available.  They all
+generate the machine instruction that is part of the name.
+
+     long __builtin_alpha_implver (void)
+     long __builtin_alpha_rpcc (void)
+     long __builtin_alpha_amask (long)
+     long __builtin_alpha_cmpbge (long, long)
+     long __builtin_alpha_extbl (long, long)
+     long __builtin_alpha_extwl (long, long)
+     long __builtin_alpha_extll (long, long)
+     long __builtin_alpha_extql (long, long)
+     long __builtin_alpha_extwh (long, long)
+     long __builtin_alpha_extlh (long, long)
+     long __builtin_alpha_extqh (long, long)
+     long __builtin_alpha_insbl (long, long)
+     long __builtin_alpha_inswl (long, long)
+     long __builtin_alpha_insll (long, long)
+     long __builtin_alpha_insql (long, long)
+     long __builtin_alpha_inswh (long, long)
+     long __builtin_alpha_inslh (long, long)
+     long __builtin_alpha_insqh (long, long)
+     long __builtin_alpha_mskbl (long, long)
+     long __builtin_alpha_mskwl (long, long)
+     long __builtin_alpha_mskll (long, long)
+     long __builtin_alpha_mskql (long, long)
+     long __builtin_alpha_mskwh (long, long)
+     long __builtin_alpha_msklh (long, long)
+     long __builtin_alpha_mskqh (long, long)
+     long __builtin_alpha_umulh (long, long)
+     long __builtin_alpha_zap (long, long)
+     long __builtin_alpha_zapnot (long, long)
+
+ The following built-in functions are always with '-mmax' or '-mcpu=CPU'
+where CPU is 'pca56' or later.  They all generate the machine
+instruction that is part of the name.
+
+     long __builtin_alpha_pklb (long)
+     long __builtin_alpha_pkwb (long)
+     long __builtin_alpha_unpkbl (long)
+     long __builtin_alpha_unpkbw (long)
+     long __builtin_alpha_minub8 (long, long)
+     long __builtin_alpha_minsb8 (long, long)
+     long __builtin_alpha_minuw4 (long, long)
+     long __builtin_alpha_minsw4 (long, long)
+     long __builtin_alpha_maxub8 (long, long)
+     long __builtin_alpha_maxsb8 (long, long)
+     long __builtin_alpha_maxuw4 (long, long)
+     long __builtin_alpha_maxsw4 (long, long)
+     long __builtin_alpha_perr (long, long)
+
+ The following built-in functions are always with '-mcix' or '-mcpu=CPU'
+where CPU is 'ev67' or later.  They all generate the machine instruction
+that is part of the name.
+
+     long __builtin_alpha_cttz (long)
+     long __builtin_alpha_ctlz (long)
+     long __builtin_alpha_ctpop (long)
+
+ The following built-in functions are available on systems that use the
+OSF/1 PALcode.  Normally they invoke the 'rduniq' and 'wruniq' PAL
+calls, but when invoked with '-mtls-kernel', they invoke 'rdval' and
+'wrval'.
+
+     void *__builtin_thread_pointer (void)
+     void __builtin_set_thread_pointer (void *)
+
+
+File: gcc.info,  Node: Altera Nios II Built-in Functions,  Next: ARC Built-in Functions,  Prev: Alpha Built-in Functions,  Up: Target Builtins
+
+6.57.2 Altera Nios II Built-in Functions
+----------------------------------------
+
+These built-in functions are available for the Altera Nios II family of
+processors.
+
+ The following built-in functions are always available.  They all
+generate the machine instruction that is part of the name.
+
+     int __builtin_ldbio (volatile const void *)
+     int __builtin_ldbuio (volatile const void *)
+     int __builtin_ldhio (volatile const void *)
+     int __builtin_ldhuio (volatile const void *)
+     int __builtin_ldwio (volatile const void *)
+     void __builtin_stbio (volatile void *, int)
+     void __builtin_sthio (volatile void *, int)
+     void __builtin_stwio (volatile void *, int)
+     void __builtin_sync (void)
+     int __builtin_rdctl (int)
+     void __builtin_wrctl (int, int)
+
+ The following built-in functions are always available.  They all
+generate a Nios II Custom Instruction.  The name of the function
+represents the types that the function takes and returns.  The letter
+before the 'n' is the return type or void if absent.  The 'n' represents
+the first parameter to all the custom instructions, the custom
+instruction number.  The two letters after the 'n' represent the up to
+two parameters to the function.
+
+ The letters represent the following data types:
+'<no letter>'
+     'void' for return type and no parameter for parameter types.
+
+'i'
+     'int' for return type and parameter type
+
+'f'
+     'float' for return type and parameter type
+
+'p'
+     'void *' for return type and parameter type
+
+ And the function names are:
+     void __builtin_custom_n (void)
+     void __builtin_custom_ni (int)
+     void __builtin_custom_nf (float)
+     void __builtin_custom_np (void *)
+     void __builtin_custom_nii (int, int)
+     void __builtin_custom_nif (int, float)
+     void __builtin_custom_nip (int, void *)
+     void __builtin_custom_nfi (float, int)
+     void __builtin_custom_nff (float, float)
+     void __builtin_custom_nfp (float, void *)
+     void __builtin_custom_npi (void *, int)
+     void __builtin_custom_npf (void *, float)
+     void __builtin_custom_npp (void *, void *)
+     int __builtin_custom_in (void)
+     int __builtin_custom_ini (int)
+     int __builtin_custom_inf (float)
+     int __builtin_custom_inp (void *)
+     int __builtin_custom_inii (int, int)
+     int __builtin_custom_inif (int, float)
+     int __builtin_custom_inip (int, void *)
+     int __builtin_custom_infi (float, int)
+     int __builtin_custom_inff (float, float)
+     int __builtin_custom_infp (float, void *)
+     int __builtin_custom_inpi (void *, int)
+     int __builtin_custom_inpf (void *, float)
+     int __builtin_custom_inpp (void *, void *)
+     float __builtin_custom_fn (void)
+     float __builtin_custom_fni (int)
+     float __builtin_custom_fnf (float)
+     float __builtin_custom_fnp (void *)
+     float __builtin_custom_fnii (int, int)
+     float __builtin_custom_fnif (int, float)
+     float __builtin_custom_fnip (int, void *)
+     float __builtin_custom_fnfi (float, int)
+     float __builtin_custom_fnff (float, float)
+     float __builtin_custom_fnfp (float, void *)
+     float __builtin_custom_fnpi (void *, int)
+     float __builtin_custom_fnpf (void *, float)
+     float __builtin_custom_fnpp (void *, void *)
+     void * __builtin_custom_pn (void)
+     void * __builtin_custom_pni (int)
+     void * __builtin_custom_pnf (float)
+     void * __builtin_custom_pnp (void *)
+     void * __builtin_custom_pnii (int, int)
+     void * __builtin_custom_pnif (int, float)
+     void * __builtin_custom_pnip (int, void *)
+     void * __builtin_custom_pnfi (float, int)
+     void * __builtin_custom_pnff (float, float)
+     void * __builtin_custom_pnfp (float, void *)
+     void * __builtin_custom_pnpi (void *, int)
+     void * __builtin_custom_pnpf (void *, float)
+     void * __builtin_custom_pnpp (void *, void *)
+
+
+File: gcc.info,  Node: ARC Built-in Functions,  Next: ARC SIMD Built-in Functions,  Prev: Altera Nios II Built-in Functions,  Up: Target Builtins
+
+6.57.3 ARC Built-in Functions
+-----------------------------
+
+The following built-in functions are provided for ARC targets.  The
+built-ins generate the corresponding assembly instructions.  In the
+examples given below, the generated code often requires an operand or
+result to be in a register.  Where necessary further code will be
+generated to ensure this is true, but for brevity this is not described
+in each case.
+
+ _Note:_ Using a built-in to generate an instruction not supported by a
+target may cause problems.  At present the compiler is not guaranteed to
+detect such misuse, and as a result an internal compiler error may be
+generated.
+
+ -- Built-in Function: int __builtin_arc_aligned (void *VAL, int
+          ALIGNVAL)
+     Return 1 if VAL is known to have the byte alignment given by
+     ALIGNVAL, otherwise return 0.  Note that this is different from
+          __alignof__(*(char *)VAL) >= alignval
+     because __alignof__ sees only the type of the dereference, whereas
+     __builtin_arc_align uses alignment information from the pointer as
+     well as from the pointed-to type.  The information available will
+     depend on optimization level.
+
+ -- Built-in Function: void __builtin_arc_brk (void)
+     Generates
+          brk
+
+ -- Built-in Function: unsigned int __builtin_arc_core_read (unsigned
+          int REGNO)
+     The operand is the number of a register to be read.  Generates:
+          mov  DEST, rREGNO
+     where the value in DEST will be the result returned from the
+     built-in.
+
+ -- Built-in Function: void __builtin_arc_core_write (unsigned int
+          REGNO, unsigned int VAL)
+     The first operand is the number of a register to be written, the
+     second operand is a compile time constant to write into that
+     register.  Generates:
+          mov  rREGNO, VAL
+
+ -- Built-in Function: int __builtin_arc_divaw (int A, int B)
+     Only available if either '-mcpu=ARC700' or '-meA' is set.
+     Generates:
+          divaw  DEST, A, B
+     where the value in DEST will be the result returned from the
+     built-in.
+
+ -- Built-in Function: void __builtin_arc_flag (unsigned int A)
+     Generates
+          flag  A
+
+ -- Built-in Function: unsigned int __builtin_arc_lr (unsigned int AUXR)
+     The operand, AUXV, is the address of an auxiliary register and must
+     be a compile time constant.  Generates:
+          lr  DEST, [AUXR]
+     Where the value in DEST will be the result returned from the
+     built-in.
+
+ -- Built-in Function: void __builtin_arc_mul64 (int A, int B)
+     Only available with '-mmul64'.  Generates:
+          mul64  A, B
+
+ -- Built-in Function: void __builtin_arc_mulu64 (unsigned int A,
+          unsigned int B)
+     Only available with '-mmul64'.  Generates:
+          mulu64  A, B
+
+ -- Built-in Function: void __builtin_arc_nop (void)
+     Generates:
+          nop
+
+ -- Built-in Function: int __builtin_arc_norm (int SRC)
+     Only valid if the 'norm' instruction is available through the
+     '-mnorm' option or by default with '-mcpu=ARC700'.  Generates:
+          norm  DEST, SRC
+     Where the value in DEST will be the result returned from the
+     built-in.
+
+ -- Built-in Function: short int __builtin_arc_normw (short int SRC)
+     Only valid if the 'normw' instruction is available through the
+     '-mnorm' option or by default with '-mcpu=ARC700'.  Generates:
+          normw  DEST, SRC
+     Where the value in DEST will be the result returned from the
+     built-in.
+
+ -- Built-in Function: void __builtin_arc_rtie (void)
+     Generates:
+          rtie
+
+ -- Built-in Function: void __builtin_arc_sleep (int A
+     Generates:
+          sleep  A
+
+ -- Built-in Function: void __builtin_arc_sr (unsigned int AUXR,
+          unsigned int VAL)
+     The first argument, AUXV, is the address of an auxiliary register,
+     the second argument, VAL, is a compile time constant to be written
+     to the register.  Generates:
+          sr  AUXR, [VAL]
+
+ -- Built-in Function: int __builtin_arc_swap (int SRC)
+     Only valid with '-mswap'.  Generates:
+          swap  DEST, SRC
+     Where the value in DEST will be the result returned from the
+     built-in.
+
+ -- Built-in Function: void __builtin_arc_swi (void)
+     Generates:
+          swi
+
+ -- Built-in Function: void __builtin_arc_sync (void)
+     Only available with '-mcpu=ARC700'.  Generates:
+          sync
+
+ -- Built-in Function: void __builtin_arc_trap_s (unsigned int C)
+     Only available with '-mcpu=ARC700'.  Generates:
+          trap_s  C
+
+ -- Built-in Function: void __builtin_arc_unimp_s (void)
+     Only available with '-mcpu=ARC700'.  Generates:
+          unimp_s
+
+ The instructions generated by the following builtins are not considered
+as candidates for scheduling.  They are not moved around by the compiler
+during scheduling, and thus can be expected to appear where they are put
+in the C code:
+     __builtin_arc_brk()
+     __builtin_arc_core_read()
+     __builtin_arc_core_write()
+     __builtin_arc_flag()
+     __builtin_arc_lr()
+     __builtin_arc_sleep()
+     __builtin_arc_sr()
+     __builtin_arc_swi()
+
+
+File: gcc.info,  Node: ARC SIMD Built-in Functions,  Next: ARM iWMMXt Built-in Functions,  Prev: ARC Built-in Functions,  Up: Target Builtins
+
+6.57.4 ARC SIMD Built-in Functions
+----------------------------------
+
+SIMD builtins provided by the compiler can be used to generate the
+vector instructions.  This section describes the available builtins and
+their usage in programs.  With the '-msimd' option, the compiler
+provides 128-bit vector types, which can be specified using the
+'vector_size' attribute.  The header file 'arc-simd.h' can be included
+to use the following predefined types:
+     typedef int __v4si   __attribute__((vector_size(16)));
+     typedef short __v8hi __attribute__((vector_size(16)));
+
+ These types can be used to define 128-bit variables.  The built-in
+functions listed in the following section can be used on these variables
+to generate the vector operations.
+
+ For all builtins, '__builtin_arc_SOMEINSN', the header file
+'arc-simd.h' also provides equivalent macros called '_SOMEINSN' that can
+be used for programming ease and improved readability.  The following
+macros for DMA control are also provided:
+     #define _setup_dma_in_channel_reg _vdiwr
+     #define _setup_dma_out_channel_reg _vdowr
+
+ The following is a complete list of all the SIMD built-ins provided for
+ARC, grouped by calling signature.
+
+ The following take two '__v8hi' arguments and return a '__v8hi' result:
+     __v8hi __builtin_arc_vaddaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vaddw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vand (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vandaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vavb (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vavrb (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vbic (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vbicaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vdifaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vdifw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_veqw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vh264f (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vh264ft (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vh264fw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vlew (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vltw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmaxaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmaxw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vminaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vminw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr1aw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr1w (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr2aw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr2w (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr3aw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr3w (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr4aw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr4w (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr5aw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr5w (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr6aw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr6w (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr7aw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmr7w (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmrb (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmulaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmulfaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmulfw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vmulw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vnew (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vor (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vsubaw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vsubw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vsummw (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vvc1f (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vvc1ft (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vxor (__v8hi, __v8hi)
+     __v8hi __builtin_arc_vxoraw (__v8hi, __v8hi)
+
+ The following take one '__v8hi' and one 'int' argument and return a
+'__v8hi' result:
+
+     __v8hi __builtin_arc_vbaddw (__v8hi, int)
+     __v8hi __builtin_arc_vbmaxw (__v8hi, int)
+     __v8hi __builtin_arc_vbminw (__v8hi, int)
+     __v8hi __builtin_arc_vbmulaw (__v8hi, int)
+     __v8hi __builtin_arc_vbmulfw (__v8hi, int)
+     __v8hi __builtin_arc_vbmulw (__v8hi, int)
+     __v8hi __builtin_arc_vbrsubw (__v8hi, int)
+     __v8hi __builtin_arc_vbsubw (__v8hi, int)
+
+ The following take one '__v8hi' argument and one 'int' argument which
+must be a 3-bit compile time constant indicating a register number
+I0-I7.  They return a '__v8hi' result.
+     __v8hi __builtin_arc_vasrw (__v8hi, const int)
+     __v8hi __builtin_arc_vsr8 (__v8hi, const int)
+     __v8hi __builtin_arc_vsr8aw (__v8hi, const int)
+
+ The following take one '__v8hi' argument and one 'int' argument which
+must be a 6-bit compile time constant.  They return a '__v8hi' result.
+     __v8hi __builtin_arc_vasrpwbi (__v8hi, const int)
+     __v8hi __builtin_arc_vasrrpwbi (__v8hi, const int)
+     __v8hi __builtin_arc_vasrrwi (__v8hi, const int)
+     __v8hi __builtin_arc_vasrsrwi (__v8hi, const int)
+     __v8hi __builtin_arc_vasrwi (__v8hi, const int)
+     __v8hi __builtin_arc_vsr8awi (__v8hi, const int)
+     __v8hi __builtin_arc_vsr8i (__v8hi, const int)
+
+ The following take one '__v8hi' argument and one 'int' argument which
+must be a 8-bit compile time constant.  They return a '__v8hi' result.
+     __v8hi __builtin_arc_vd6tapf (__v8hi, const int)
+     __v8hi __builtin_arc_vmvaw (__v8hi, const int)
+     __v8hi __builtin_arc_vmvw (__v8hi, const int)
+     __v8hi __builtin_arc_vmvzw (__v8hi, const int)
+
+ The following take two 'int' arguments, the second of which which must
+be a 8-bit compile time constant.  They return a '__v8hi' result:
+     __v8hi __builtin_arc_vmovaw (int, const int)
+     __v8hi __builtin_arc_vmovw (int, const int)
+     __v8hi __builtin_arc_vmovzw (int, const int)
+
+ The following take a single '__v8hi' argument and return a '__v8hi'
+result:
+     __v8hi __builtin_arc_vabsaw (__v8hi)
+     __v8hi __builtin_arc_vabsw (__v8hi)
+     __v8hi __builtin_arc_vaddsuw (__v8hi)
+     __v8hi __builtin_arc_vexch1 (__v8hi)
+     __v8hi __builtin_arc_vexch2 (__v8hi)
+     __v8hi __builtin_arc_vexch4 (__v8hi)
+     __v8hi __builtin_arc_vsignw (__v8hi)
+     __v8hi __builtin_arc_vupbaw (__v8hi)
+     __v8hi __builtin_arc_vupbw (__v8hi)
+     __v8hi __builtin_arc_vupsbaw (__v8hi)
+     __v8hi __builtin_arc_vupsbw (__v8hi)
+
+ The followign take two 'int' arguments and return no result:
+     void __builtin_arc_vdirun (int, int)
+     void __builtin_arc_vdorun (int, int)
+
+ The following take two 'int' arguments and return no result.  The first
+argument must a 3-bit compile time constant indicating one of the
+DR0-DR7 DMA setup channels:
+     void __builtin_arc_vdiwr (const int, int)
+     void __builtin_arc_vdowr (const int, int)
+
+ The following take an 'int' argument and return no result:
+     void __builtin_arc_vendrec (int)
+     void __builtin_arc_vrec (int)
+     void __builtin_arc_vrecrun (int)
+     void __builtin_arc_vrun (int)
+
+ The following take a '__v8hi' argument and two 'int' arguments and
+return a '__v8hi' result.  The second argument must be a 3-bit compile
+time constants, indicating one the registers I0-I7, and the third
+argument must be an 8-bit compile time constant.
+
+ _Note:_ Although the equivalent hardware instructions do not take an
+SIMD register as an operand, these builtins overwrite the relevant bits
+of the '__v8hi' register provided as the first argument with the value
+loaded from the '[Ib, u8]' location in the SDM.
+
+     __v8hi __builtin_arc_vld32 (__v8hi, const int, const int)
+     __v8hi __builtin_arc_vld32wh (__v8hi, const int, const int)
+     __v8hi __builtin_arc_vld32wl (__v8hi, const int, const int)
+     __v8hi __builtin_arc_vld64 (__v8hi, const int, const int)
+
+ The following take two 'int' arguments and return a '__v8hi' result.
+The first argument must be a 3-bit compile time constants, indicating
+one the registers I0-I7, and the second argument must be an 8-bit
+compile time constant.
+
+     __v8hi __builtin_arc_vld128 (const int, const int)
+     __v8hi __builtin_arc_vld64w (const int, const int)
+
+ The following take a '__v8hi' argument and two 'int' arguments and
+return no result.  The second argument must be a 3-bit compile time
+constants, indicating one the registers I0-I7, and the third argument
+must be an 8-bit compile time constant.
+
+     void __builtin_arc_vst128 (__v8hi, const int, const int)
+     void __builtin_arc_vst64 (__v8hi, const int, const int)
+
+ The following take a '__v8hi' argument and three 'int' arguments and
+return no result.  The second argument must be a 3-bit compile-time
+constant, identifying the 16-bit sub-register to be stored, the third
+argument must be a 3-bit compile time constants, indicating one the
+registers I0-I7, and the fourth argument must be an 8-bit compile time
+constant.
+
+     void __builtin_arc_vst16_n (__v8hi, const int, const int, const int)
+     void __builtin_arc_vst32_n (__v8hi, const int, const int, const int)
+
+
+File: gcc.info,  Node: ARM iWMMXt Built-in Functions,  Next: ARM NEON Intrinsics,  Prev: ARC SIMD Built-in Functions,  Up: Target Builtins
+
+6.57.5 ARM iWMMXt Built-in Functions
+------------------------------------
+
+These built-in functions are available for the ARM family of processors
+when the '-mcpu=iwmmxt' switch is used:
+
+     typedef int v2si __attribute__ ((vector_size (8)));
+     typedef short v4hi __attribute__ ((vector_size (8)));
+     typedef char v8qi __attribute__ ((vector_size (8)));
+
+     int __builtin_arm_getwcgr0 (void)
+     void __builtin_arm_setwcgr0 (int)
+     int __builtin_arm_getwcgr1 (void)
+     void __builtin_arm_setwcgr1 (int)
+     int __builtin_arm_getwcgr2 (void)
+     void __builtin_arm_setwcgr2 (int)
+     int __builtin_arm_getwcgr3 (void)
+     void __builtin_arm_setwcgr3 (int)
+     int __builtin_arm_textrmsb (v8qi, int)
+     int __builtin_arm_textrmsh (v4hi, int)
+     int __builtin_arm_textrmsw (v2si, int)
+     int __builtin_arm_textrmub (v8qi, int)
+     int __builtin_arm_textrmuh (v4hi, int)
+     int __builtin_arm_textrmuw (v2si, int)
+     v8qi __builtin_arm_tinsrb (v8qi, int, int)
+     v4hi __builtin_arm_tinsrh (v4hi, int, int)
+     v2si __builtin_arm_tinsrw (v2si, int, int)
+     long long __builtin_arm_tmia (long long, int, int)
+     long long __builtin_arm_tmiabb (long long, int, int)
+     long long __builtin_arm_tmiabt (long long, int, int)
+     long long __builtin_arm_tmiaph (long long, int, int)
+     long long __builtin_arm_tmiatb (long long, int, int)
+     long long __builtin_arm_tmiatt (long long, int, int)
+     int __builtin_arm_tmovmskb (v8qi)
+     int __builtin_arm_tmovmskh (v4hi)
+     int __builtin_arm_tmovmskw (v2si)
+     long long __builtin_arm_waccb (v8qi)
+     long long __builtin_arm_wacch (v4hi)
+     long long __builtin_arm_waccw (v2si)
+     v8qi __builtin_arm_waddb (v8qi, v8qi)
+     v8qi __builtin_arm_waddbss (v8qi, v8qi)
+     v8qi __builtin_arm_waddbus (v8qi, v8qi)
+     v4hi __builtin_arm_waddh (v4hi, v4hi)
+     v4hi __builtin_arm_waddhss (v4hi, v4hi)
+     v4hi __builtin_arm_waddhus (v4hi, v4hi)
+     v2si __builtin_arm_waddw (v2si, v2si)
+     v2si __builtin_arm_waddwss (v2si, v2si)
+     v2si __builtin_arm_waddwus (v2si, v2si)
+     v8qi __builtin_arm_walign (v8qi, v8qi, int)
+     long long __builtin_arm_wand(long long, long long)
+     long long __builtin_arm_wandn (long long, long long)
+     v8qi __builtin_arm_wavg2b (v8qi, v8qi)
+     v8qi __builtin_arm_wavg2br (v8qi, v8qi)
+     v4hi __builtin_arm_wavg2h (v4hi, v4hi)
+     v4hi __builtin_arm_wavg2hr (v4hi, v4hi)
+     v8qi __builtin_arm_wcmpeqb (v8qi, v8qi)
+     v4hi __builtin_arm_wcmpeqh (v4hi, v4hi)
+     v2si __builtin_arm_wcmpeqw (v2si, v2si)
+     v8qi __builtin_arm_wcmpgtsb (v8qi, v8qi)
+     v4hi __builtin_arm_wcmpgtsh (v4hi, v4hi)
+     v2si __builtin_arm_wcmpgtsw (v2si, v2si)
+     v8qi __builtin_arm_wcmpgtub (v8qi, v8qi)
+     v4hi __builtin_arm_wcmpgtuh (v4hi, v4hi)
+     v2si __builtin_arm_wcmpgtuw (v2si, v2si)
+     long long __builtin_arm_wmacs (long long, v4hi, v4hi)
+     long long __builtin_arm_wmacsz (v4hi, v4hi)
+     long long __builtin_arm_wmacu (long long, v4hi, v4hi)
+     long long __builtin_arm_wmacuz (v4hi, v4hi)
+     v4hi __builtin_arm_wmadds (v4hi, v4hi)
+     v4hi __builtin_arm_wmaddu (v4hi, v4hi)
+     v8qi __builtin_arm_wmaxsb (v8qi, v8qi)
+     v4hi __builtin_arm_wmaxsh (v4hi, v4hi)
+     v2si __builtin_arm_wmaxsw (v2si, v2si)
+     v8qi __builtin_arm_wmaxub (v8qi, v8qi)
+     v4hi __builtin_arm_wmaxuh (v4hi, v4hi)
+     v2si __builtin_arm_wmaxuw (v2si, v2si)
+     v8qi __builtin_arm_wminsb (v8qi, v8qi)
+     v4hi __builtin_arm_wminsh (v4hi, v4hi)
+     v2si __builtin_arm_wminsw (v2si, v2si)
+     v8qi __builtin_arm_wminub (v8qi, v8qi)
+     v4hi __builtin_arm_wminuh (v4hi, v4hi)
+     v2si __builtin_arm_wminuw (v2si, v2si)
+     v4hi __builtin_arm_wmulsm (v4hi, v4hi)
+     v4hi __builtin_arm_wmulul (v4hi, v4hi)
+     v4hi __builtin_arm_wmulum (v4hi, v4hi)
+     long long __builtin_arm_wor (long long, long long)
+     v2si __builtin_arm_wpackdss (long long, long long)
+     v2si __builtin_arm_wpackdus (long long, long long)
+     v8qi __builtin_arm_wpackhss (v4hi, v4hi)
+     v8qi __builtin_arm_wpackhus (v4hi, v4hi)
+     v4hi __builtin_arm_wpackwss (v2si, v2si)
+     v4hi __builtin_arm_wpackwus (v2si, v2si)
+     long long __builtin_arm_wrord (long long, long long)
+     long long __builtin_arm_wrordi (long long, int)
+     v4hi __builtin_arm_wrorh (v4hi, long long)
+     v4hi __builtin_arm_wrorhi (v4hi, int)
+     v2si __builtin_arm_wrorw (v2si, long long)
+     v2si __builtin_arm_wrorwi (v2si, int)
+     v2si __builtin_arm_wsadb (v2si, v8qi, v8qi)
+     v2si __builtin_arm_wsadbz (v8qi, v8qi)
+     v2si __builtin_arm_wsadh (v2si, v4hi, v4hi)
+     v2si __builtin_arm_wsadhz (v4hi, v4hi)
+     v4hi __builtin_arm_wshufh (v4hi, int)
+     long long __builtin_arm_wslld (long long, long long)
+     long long __builtin_arm_wslldi (long long, int)
+     v4hi __builtin_arm_wsllh (v4hi, long long)
+     v4hi __builtin_arm_wsllhi (v4hi, int)
+     v2si __builtin_arm_wsllw (v2si, long long)
+     v2si __builtin_arm_wsllwi (v2si, int)
+     long long __builtin_arm_wsrad (long long, long long)
+     long long __builtin_arm_wsradi (long long, int)
+     v4hi __builtin_arm_wsrah (v4hi, long long)
+     v4hi __builtin_arm_wsrahi (v4hi, int)
+     v2si __builtin_arm_wsraw (v2si, long long)
+     v2si __builtin_arm_wsrawi (v2si, int)
+     long long __builtin_arm_wsrld (long long, long long)
+     long long __builtin_arm_wsrldi (long long, int)
+     v4hi __builtin_arm_wsrlh (v4hi, long long)
+     v4hi __builtin_arm_wsrlhi (v4hi, int)
+     v2si __builtin_arm_wsrlw (v2si, long long)
+     v2si __builtin_arm_wsrlwi (v2si, int)
+     v8qi __builtin_arm_wsubb (v8qi, v8qi)
+     v8qi __builtin_arm_wsubbss (v8qi, v8qi)
+     v8qi __builtin_arm_wsubbus (v8qi, v8qi)
+     v4hi __builtin_arm_wsubh (v4hi, v4hi)
+     v4hi __builtin_arm_wsubhss (v4hi, v4hi)
+     v4hi __builtin_arm_wsubhus (v4hi, v4hi)
+     v2si __builtin_arm_wsubw (v2si, v2si)
+     v2si __builtin_arm_wsubwss (v2si, v2si)
+     v2si __builtin_arm_wsubwus (v2si, v2si)
+     v4hi __builtin_arm_wunpckehsb (v8qi)
+     v2si __builtin_arm_wunpckehsh (v4hi)
+     long long __builtin_arm_wunpckehsw (v2si)
+     v4hi __builtin_arm_wunpckehub (v8qi)
+     v2si __builtin_arm_wunpckehuh (v4hi)
+     long long __builtin_arm_wunpckehuw (v2si)
+     v4hi __builtin_arm_wunpckelsb (v8qi)
+     v2si __builtin_arm_wunpckelsh (v4hi)
+     long long __builtin_arm_wunpckelsw (v2si)
+     v4hi __builtin_arm_wunpckelub (v8qi)
+     v2si __builtin_arm_wunpckeluh (v4hi)
+     long long __builtin_arm_wunpckeluw (v2si)
+     v8qi __builtin_arm_wunpckihb (v8qi, v8qi)
+     v4hi __builtin_arm_wunpckihh (v4hi, v4hi)
+     v2si __builtin_arm_wunpckihw (v2si, v2si)
+     v8qi __builtin_arm_wunpckilb (v8qi, v8qi)
+     v4hi __builtin_arm_wunpckilh (v4hi, v4hi)
+     v2si __builtin_arm_wunpckilw (v2si, v2si)
+     long long __builtin_arm_wxor (long long, long long)
+     long long __builtin_arm_wzero ()
+
+
+File: gcc.info,  Node: ARM NEON Intrinsics,  Next: ARM ACLE Intrinsics,  Prev: ARM iWMMXt Built-in Functions,  Up: Target Builtins
+
+6.57.6 ARM NEON Intrinsics
+--------------------------
+
+These built-in intrinsics for the ARM Advanced SIMD extension are
+available when the '-mfpu=neon' switch is used:
+
+6.57.6.1 Addition
+.................
+
+   * uint32x2_t vadd_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vadd.i32 D0, D0, D0'
+
+   * uint16x4_t vadd_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vadd.i16 D0, D0, D0'
+
+   * uint8x8_t vadd_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vadd.i8 D0, D0, D0'
+
+   * int32x2_t vadd_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vadd.i32 D0, D0, D0'
+
+   * int16x4_t vadd_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vadd.i16 D0, D0, D0'
+
+   * int8x8_t vadd_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vadd.i8 D0, D0, D0'
+
+   * float32x2_t vadd_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vadd.f32 D0, D0, D0'
+
+   * uint64x1_t vadd_u64 (uint64x1_t, uint64x1_t)
+
+   * int64x1_t vadd_s64 (int64x1_t, int64x1_t)
+
+   * uint32x4_t vaddq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vadd.i32 Q0, Q0, Q0'
+
+   * uint16x8_t vaddq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vadd.i16 Q0, Q0, Q0'
+
+   * uint8x16_t vaddq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vadd.i8 Q0, Q0, Q0'
+
+   * int32x4_t vaddq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vadd.i32 Q0, Q0, Q0'
+
+   * int16x8_t vaddq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vadd.i16 Q0, Q0, Q0'
+
+   * int8x16_t vaddq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vadd.i8 Q0, Q0, Q0'
+
+   * uint64x2_t vaddq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vadd.i64 Q0, Q0, Q0'
+
+   * int64x2_t vaddq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vadd.i64 Q0, Q0, Q0'
+
+   * float32x4_t vaddq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vadd.f32 Q0, Q0, Q0'
+
+   * uint64x2_t vaddl_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vaddl.u32 Q0, D0, D0'
+
+   * uint32x4_t vaddl_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vaddl.u16 Q0, D0, D0'
+
+   * uint16x8_t vaddl_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vaddl.u8 Q0, D0, D0'
+
+   * int64x2_t vaddl_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vaddl.s32 Q0, D0, D0'
+
+   * int32x4_t vaddl_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vaddl.s16 Q0, D0, D0'
+
+   * int16x8_t vaddl_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vaddl.s8 Q0, D0, D0'
+
+   * uint64x2_t vaddw_u32 (uint64x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vaddw.u32 Q0, Q0, D0'
+
+   * uint32x4_t vaddw_u16 (uint32x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vaddw.u16 Q0, Q0, D0'
+
+   * uint16x8_t vaddw_u8 (uint16x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vaddw.u8 Q0, Q0, D0'
+
+   * int64x2_t vaddw_s32 (int64x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vaddw.s32 Q0, Q0, D0'
+
+   * int32x4_t vaddw_s16 (int32x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vaddw.s16 Q0, Q0, D0'
+
+   * int16x8_t vaddw_s8 (int16x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vaddw.s8 Q0, Q0, D0'
+
+   * uint32x2_t vhadd_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vhadd.u32 D0, D0, D0'
+
+   * uint16x4_t vhadd_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vhadd.u16 D0, D0, D0'
+
+   * uint8x8_t vhadd_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vhadd.u8 D0, D0, D0'
+
+   * int32x2_t vhadd_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vhadd.s32 D0, D0, D0'
+
+   * int16x4_t vhadd_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vhadd.s16 D0, D0, D0'
+
+   * int8x8_t vhadd_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vhadd.s8 D0, D0, D0'
+
+   * uint32x4_t vhaddq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vhadd.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vhaddq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vhadd.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vhaddq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vhadd.u8 Q0, Q0, Q0'
+
+   * int32x4_t vhaddq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vhadd.s32 Q0, Q0, Q0'
+
+   * int16x8_t vhaddq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vhadd.s16 Q0, Q0, Q0'
+
+   * int8x16_t vhaddq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vhadd.s8 Q0, Q0, Q0'
+
+   * uint32x2_t vrhadd_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vrhadd.u32 D0, D0, D0'
+
+   * uint16x4_t vrhadd_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vrhadd.u16 D0, D0, D0'
+
+   * uint8x8_t vrhadd_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vrhadd.u8 D0, D0, D0'
+
+   * int32x2_t vrhadd_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vrhadd.s32 D0, D0, D0'
+
+   * int16x4_t vrhadd_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vrhadd.s16 D0, D0, D0'
+
+   * int8x8_t vrhadd_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vrhadd.s8 D0, D0, D0'
+
+   * uint32x4_t vrhaddq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vrhadd.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vrhaddq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vrhadd.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vrhaddq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vrhadd.u8 Q0, Q0, Q0'
+
+   * int32x4_t vrhaddq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vrhadd.s32 Q0, Q0, Q0'
+
+   * int16x8_t vrhaddq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vrhadd.s16 Q0, Q0, Q0'
+
+   * int8x16_t vrhaddq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vrhadd.s8 Q0, Q0, Q0'
+
+   * uint32x2_t vqadd_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vqadd.u32 D0, D0, D0'
+
+   * uint16x4_t vqadd_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vqadd.u16 D0, D0, D0'
+
+   * uint8x8_t vqadd_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vqadd.u8 D0, D0, D0'
+
+   * int32x2_t vqadd_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqadd.s32 D0, D0, D0'
+
+   * int16x4_t vqadd_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqadd.s16 D0, D0, D0'
+
+   * int8x8_t vqadd_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vqadd.s8 D0, D0, D0'
+
+   * uint64x1_t vqadd_u64 (uint64x1_t, uint64x1_t)
+     _Form of expected instruction(s):_ 'vqadd.u64 D0, D0, D0'
+
+   * int64x1_t vqadd_s64 (int64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vqadd.s64 D0, D0, D0'
+
+   * uint32x4_t vqaddq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vqadd.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vqaddq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vqadd.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vqaddq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vqadd.u8 Q0, Q0, Q0'
+
+   * int32x4_t vqaddq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vqadd.s32 Q0, Q0, Q0'
+
+   * int16x8_t vqaddq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vqadd.s16 Q0, Q0, Q0'
+
+   * int8x16_t vqaddq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vqadd.s8 Q0, Q0, Q0'
+
+   * uint64x2_t vqaddq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vqadd.u64 Q0, Q0, Q0'
+
+   * int64x2_t vqaddq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vqadd.s64 Q0, Q0, Q0'
+
+   * uint32x2_t vaddhn_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vaddhn.i64 D0, Q0, Q0'
+
+   * uint16x4_t vaddhn_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vaddhn.i32 D0, Q0, Q0'
+
+   * uint8x8_t vaddhn_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vaddhn.i16 D0, Q0, Q0'
+
+   * int32x2_t vaddhn_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vaddhn.i64 D0, Q0, Q0'
+
+   * int16x4_t vaddhn_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vaddhn.i32 D0, Q0, Q0'
+
+   * int8x8_t vaddhn_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vaddhn.i16 D0, Q0, Q0'
+
+   * uint32x2_t vraddhn_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vraddhn.i64 D0, Q0, Q0'
+
+   * uint16x4_t vraddhn_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vraddhn.i32 D0, Q0, Q0'
+
+   * uint8x8_t vraddhn_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vraddhn.i16 D0, Q0, Q0'
+
+   * int32x2_t vraddhn_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vraddhn.i64 D0, Q0, Q0'
+
+   * int16x4_t vraddhn_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vraddhn.i32 D0, Q0, Q0'
+
+   * int8x8_t vraddhn_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vraddhn.i16 D0, Q0, Q0'
+
+6.57.6.2 Multiplication
+.......................
+
+   * uint32x2_t vmul_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vmul.i32 D0, D0, D0'
+
+   * uint16x4_t vmul_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vmul.i16 D0, D0, D0'
+
+   * uint8x8_t vmul_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vmul.i8 D0, D0, D0'
+
+   * int32x2_t vmul_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vmul.i32 D0, D0, D0'
+
+   * int16x4_t vmul_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vmul.i16 D0, D0, D0'
+
+   * int8x8_t vmul_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vmul.i8 D0, D0, D0'
+
+   * float32x2_t vmul_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vmul.f32 D0, D0, D0'
+
+   * poly8x8_t vmul_p8 (poly8x8_t, poly8x8_t)
+     _Form of expected instruction(s):_ 'vmul.p8 D0, D0, D0'
+
+   * uint32x4_t vmulq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vmul.i32 Q0, Q0, Q0'
+
+   * uint16x8_t vmulq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vmul.i16 Q0, Q0, Q0'
+
+   * uint8x16_t vmulq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vmul.i8 Q0, Q0, Q0'
+
+   * int32x4_t vmulq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vmul.i32 Q0, Q0, Q0'
+
+   * int16x8_t vmulq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vmul.i16 Q0, Q0, Q0'
+
+   * int8x16_t vmulq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vmul.i8 Q0, Q0, Q0'
+
+   * float32x4_t vmulq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vmul.f32 Q0, Q0, Q0'
+
+   * poly8x16_t vmulq_p8 (poly8x16_t, poly8x16_t)
+     _Form of expected instruction(s):_ 'vmul.p8 Q0, Q0, Q0'
+
+   * int32x2_t vqdmulh_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqdmulh.s32 D0, D0, D0'
+
+   * int16x4_t vqdmulh_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqdmulh.s16 D0, D0, D0'
+
+   * int32x4_t vqdmulhq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vqdmulh.s32 Q0, Q0, Q0'
+
+   * int16x8_t vqdmulhq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vqdmulh.s16 Q0, Q0, Q0'
+
+   * int32x2_t vqrdmulh_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqrdmulh.s32 D0, D0, D0'
+
+   * int16x4_t vqrdmulh_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqrdmulh.s16 D0, D0, D0'
+
+   * int32x4_t vqrdmulhq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vqrdmulh.s32 Q0, Q0, Q0'
+
+   * int16x8_t vqrdmulhq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vqrdmulh.s16 Q0, Q0, Q0'
+
+   * uint64x2_t vmull_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vmull.u32 Q0, D0, D0'
+
+   * uint32x4_t vmull_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vmull.u16 Q0, D0, D0'
+
+   * uint16x8_t vmull_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vmull.u8 Q0, D0, D0'
+
+   * int64x2_t vmull_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vmull.s32 Q0, D0, D0'
+
+   * int32x4_t vmull_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vmull.s16 Q0, D0, D0'
+
+   * int16x8_t vmull_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vmull.s8 Q0, D0, D0'
+
+   * poly16x8_t vmull_p8 (poly8x8_t, poly8x8_t)
+     _Form of expected instruction(s):_ 'vmull.p8 Q0, D0, D0'
+
+   * int64x2_t vqdmull_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqdmull.s32 Q0, D0, D0'
+
+   * int32x4_t vqdmull_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqdmull.s16 Q0, D0, D0'
+
+6.57.6.3 Multiply-accumulate
+............................
+
+   * uint32x2_t vmla_u32 (uint32x2_t, uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vmla.i32 D0, D0, D0'
+
+   * uint16x4_t vmla_u16 (uint16x4_t, uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vmla.i16 D0, D0, D0'
+
+   * uint8x8_t vmla_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vmla.i8 D0, D0, D0'
+
+   * int32x2_t vmla_s32 (int32x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vmla.i32 D0, D0, D0'
+
+   * int16x4_t vmla_s16 (int16x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vmla.i16 D0, D0, D0'
+
+   * int8x8_t vmla_s8 (int8x8_t, int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vmla.i8 D0, D0, D0'
+
+   * float32x2_t vmla_f32 (float32x2_t, float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vmla.f32 D0, D0, D0'
+
+   * uint32x4_t vmlaq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vmla.i32 Q0, Q0, Q0'
+
+   * uint16x8_t vmlaq_u16 (uint16x8_t, uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vmla.i16 Q0, Q0, Q0'
+
+   * uint8x16_t vmlaq_u8 (uint8x16_t, uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vmla.i8 Q0, Q0, Q0'
+
+   * int32x4_t vmlaq_s32 (int32x4_t, int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vmla.i32 Q0, Q0, Q0'
+
+   * int16x8_t vmlaq_s16 (int16x8_t, int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vmla.i16 Q0, Q0, Q0'
+
+   * int8x16_t vmlaq_s8 (int8x16_t, int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vmla.i8 Q0, Q0, Q0'
+
+   * float32x4_t vmlaq_f32 (float32x4_t, float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vmla.f32 Q0, Q0, Q0'
+
+   * uint64x2_t vmlal_u32 (uint64x2_t, uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vmlal.u32 Q0, D0, D0'
+
+   * uint32x4_t vmlal_u16 (uint32x4_t, uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vmlal.u16 Q0, D0, D0'
+
+   * uint16x8_t vmlal_u8 (uint16x8_t, uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vmlal.u8 Q0, D0, D0'
+
+   * int64x2_t vmlal_s32 (int64x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vmlal.s32 Q0, D0, D0'
+
+   * int32x4_t vmlal_s16 (int32x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vmlal.s16 Q0, D0, D0'
+
+   * int16x8_t vmlal_s8 (int16x8_t, int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vmlal.s8 Q0, D0, D0'
+
+   * int64x2_t vqdmlal_s32 (int64x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqdmlal.s32 Q0, D0, D0'
+
+   * int32x4_t vqdmlal_s16 (int32x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqdmlal.s16 Q0, D0, D0'
+
+6.57.6.4 Multiply-subtract
+..........................
+
+   * uint32x2_t vmls_u32 (uint32x2_t, uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vmls.i32 D0, D0, D0'
+
+   * uint16x4_t vmls_u16 (uint16x4_t, uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vmls.i16 D0, D0, D0'
+
+   * uint8x8_t vmls_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vmls.i8 D0, D0, D0'
+
+   * int32x2_t vmls_s32 (int32x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vmls.i32 D0, D0, D0'
+
+   * int16x4_t vmls_s16 (int16x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vmls.i16 D0, D0, D0'
+
+   * int8x8_t vmls_s8 (int8x8_t, int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vmls.i8 D0, D0, D0'
+
+   * float32x2_t vmls_f32 (float32x2_t, float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vmls.f32 D0, D0, D0'
+
+   * uint32x4_t vmlsq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vmls.i32 Q0, Q0, Q0'
+
+   * uint16x8_t vmlsq_u16 (uint16x8_t, uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vmls.i16 Q0, Q0, Q0'
+
+   * uint8x16_t vmlsq_u8 (uint8x16_t, uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vmls.i8 Q0, Q0, Q0'
+
+   * int32x4_t vmlsq_s32 (int32x4_t, int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vmls.i32 Q0, Q0, Q0'
+
+   * int16x8_t vmlsq_s16 (int16x8_t, int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vmls.i16 Q0, Q0, Q0'
+
+   * int8x16_t vmlsq_s8 (int8x16_t, int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vmls.i8 Q0, Q0, Q0'
+
+   * float32x4_t vmlsq_f32 (float32x4_t, float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vmls.f32 Q0, Q0, Q0'
+
+   * uint64x2_t vmlsl_u32 (uint64x2_t, uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vmlsl.u32 Q0, D0, D0'
+
+   * uint32x4_t vmlsl_u16 (uint32x4_t, uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vmlsl.u16 Q0, D0, D0'
+
+   * uint16x8_t vmlsl_u8 (uint16x8_t, uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vmlsl.u8 Q0, D0, D0'
+
+   * int64x2_t vmlsl_s32 (int64x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vmlsl.s32 Q0, D0, D0'
+
+   * int32x4_t vmlsl_s16 (int32x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vmlsl.s16 Q0, D0, D0'
+
+   * int16x8_t vmlsl_s8 (int16x8_t, int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vmlsl.s8 Q0, D0, D0'
+
+   * int64x2_t vqdmlsl_s32 (int64x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqdmlsl.s32 Q0, D0, D0'
+
+   * int32x4_t vqdmlsl_s16 (int32x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqdmlsl.s16 Q0, D0, D0'
+
+6.57.6.5 Fused-multiply-accumulate
+..................................
+
+   * float32x2_t vfma_f32 (float32x2_t, float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vfma.f32 D0, D0, D0'
+
+   * float32x4_t vfmaq_f32 (float32x4_t, float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vfma.f32 Q0, Q0, Q0'
+
+6.57.6.6 Fused-multiply-subtract
+................................
+
+   * float32x2_t vfms_f32 (float32x2_t, float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vfms.f32 D0, D0, D0'
+
+   * float32x4_t vfmsq_f32 (float32x4_t, float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vfms.f32 Q0, Q0, Q0'
+
+6.57.6.7 Round to integral (to nearest, ties to even)
+.....................................................
+
+   * float32x2_t vrndn_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vrintn.f32 D0, D0'
+
+   * float32x4_t vrndqn_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vrintn.f32 Q0, Q0'
+
+6.57.6.8 Round to integral (to nearest, ties away from zero)
+............................................................
+
+   * float32x2_t vrnda_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vrinta.f32 D0, D0'
+
+   * float32x4_t vrndqa_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vrinta.f32 Q0, Q0'
+
+6.57.6.9 Round to integral (towards +Inf)
+.........................................
+
+   * float32x2_t vrndp_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vrintp.f32 D0, D0'
+
+   * float32x4_t vrndqp_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vrintp.f32 Q0, Q0'
+
+6.57.6.10 Round to integral (towards -Inf)
+..........................................
+
+   * float32x2_t vrndm_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vrintm.f32 D0, D0'
+
+   * float32x4_t vrndqm_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vrintm.f32 Q0, Q0'
+
+6.57.6.11 Round to integral (towards 0)
+.......................................
+
+   * float32x2_t vrnd_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vrintz.f32 D0, D0'
+
+   * float32x4_t vrndq_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vrintz.f32 Q0, Q0'
+
+6.57.6.12 Subtraction
+.....................
+
+   * uint32x2_t vsub_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vsub.i32 D0, D0, D0'
+
+   * uint16x4_t vsub_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vsub.i16 D0, D0, D0'
+
+   * uint8x8_t vsub_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vsub.i8 D0, D0, D0'
+
+   * int32x2_t vsub_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vsub.i32 D0, D0, D0'
+
+   * int16x4_t vsub_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vsub.i16 D0, D0, D0'
+
+   * int8x8_t vsub_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vsub.i8 D0, D0, D0'
+
+   * float32x2_t vsub_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vsub.f32 D0, D0, D0'
+
+   * uint64x1_t vsub_u64 (uint64x1_t, uint64x1_t)
+
+   * int64x1_t vsub_s64 (int64x1_t, int64x1_t)
+
+   * uint32x4_t vsubq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vsub.i32 Q0, Q0, Q0'
+
+   * uint16x8_t vsubq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vsub.i16 Q0, Q0, Q0'
+
+   * uint8x16_t vsubq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vsub.i8 Q0, Q0, Q0'
+
+   * int32x4_t vsubq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vsub.i32 Q0, Q0, Q0'
+
+   * int16x8_t vsubq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vsub.i16 Q0, Q0, Q0'
+
+   * int8x16_t vsubq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vsub.i8 Q0, Q0, Q0'
+
+   * uint64x2_t vsubq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vsub.i64 Q0, Q0, Q0'
+
+   * int64x2_t vsubq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vsub.i64 Q0, Q0, Q0'
+
+   * float32x4_t vsubq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vsub.f32 Q0, Q0, Q0'
+
+   * uint64x2_t vsubl_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vsubl.u32 Q0, D0, D0'
+
+   * uint32x4_t vsubl_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vsubl.u16 Q0, D0, D0'
+
+   * uint16x8_t vsubl_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vsubl.u8 Q0, D0, D0'
+
+   * int64x2_t vsubl_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vsubl.s32 Q0, D0, D0'
+
+   * int32x4_t vsubl_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vsubl.s16 Q0, D0, D0'
+
+   * int16x8_t vsubl_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vsubl.s8 Q0, D0, D0'
+
+   * uint64x2_t vsubw_u32 (uint64x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vsubw.u32 Q0, Q0, D0'
+
+   * uint32x4_t vsubw_u16 (uint32x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vsubw.u16 Q0, Q0, D0'
+
+   * uint16x8_t vsubw_u8 (uint16x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vsubw.u8 Q0, Q0, D0'
+
+   * int64x2_t vsubw_s32 (int64x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vsubw.s32 Q0, Q0, D0'
+
+   * int32x4_t vsubw_s16 (int32x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vsubw.s16 Q0, Q0, D0'
+
+   * int16x8_t vsubw_s8 (int16x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vsubw.s8 Q0, Q0, D0'
+
+   * uint32x2_t vhsub_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vhsub.u32 D0, D0, D0'
+
+   * uint16x4_t vhsub_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vhsub.u16 D0, D0, D0'
+
+   * uint8x8_t vhsub_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vhsub.u8 D0, D0, D0'
+
+   * int32x2_t vhsub_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vhsub.s32 D0, D0, D0'
+
+   * int16x4_t vhsub_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vhsub.s16 D0, D0, D0'
+
+   * int8x8_t vhsub_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vhsub.s8 D0, D0, D0'
+
+   * uint32x4_t vhsubq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vhsub.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vhsubq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vhsub.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vhsubq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vhsub.u8 Q0, Q0, Q0'
+
+   * int32x4_t vhsubq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vhsub.s32 Q0, Q0, Q0'
+
+   * int16x8_t vhsubq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vhsub.s16 Q0, Q0, Q0'
+
+   * int8x16_t vhsubq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vhsub.s8 Q0, Q0, Q0'
+
+   * uint32x2_t vqsub_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vqsub.u32 D0, D0, D0'
+
+   * uint16x4_t vqsub_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vqsub.u16 D0, D0, D0'
+
+   * uint8x8_t vqsub_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vqsub.u8 D0, D0, D0'
+
+   * int32x2_t vqsub_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqsub.s32 D0, D0, D0'
+
+   * int16x4_t vqsub_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqsub.s16 D0, D0, D0'
+
+   * int8x8_t vqsub_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vqsub.s8 D0, D0, D0'
+
+   * uint64x1_t vqsub_u64 (uint64x1_t, uint64x1_t)
+     _Form of expected instruction(s):_ 'vqsub.u64 D0, D0, D0'
+
+   * int64x1_t vqsub_s64 (int64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vqsub.s64 D0, D0, D0'
+
+   * uint32x4_t vqsubq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vqsub.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vqsubq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vqsub.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vqsubq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vqsub.u8 Q0, Q0, Q0'
+
+   * int32x4_t vqsubq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vqsub.s32 Q0, Q0, Q0'
+
+   * int16x8_t vqsubq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vqsub.s16 Q0, Q0, Q0'
+
+   * int8x16_t vqsubq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vqsub.s8 Q0, Q0, Q0'
+
+   * uint64x2_t vqsubq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vqsub.u64 Q0, Q0, Q0'
+
+   * int64x2_t vqsubq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vqsub.s64 Q0, Q0, Q0'
+
+   * uint32x2_t vsubhn_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vsubhn.i64 D0, Q0, Q0'
+
+   * uint16x4_t vsubhn_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vsubhn.i32 D0, Q0, Q0'
+
+   * uint8x8_t vsubhn_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vsubhn.i16 D0, Q0, Q0'
+
+   * int32x2_t vsubhn_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vsubhn.i64 D0, Q0, Q0'
+
+   * int16x4_t vsubhn_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vsubhn.i32 D0, Q0, Q0'
+
+   * int8x8_t vsubhn_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vsubhn.i16 D0, Q0, Q0'
+
+   * uint32x2_t vrsubhn_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vrsubhn.i64 D0, Q0, Q0'
+
+   * uint16x4_t vrsubhn_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vrsubhn.i32 D0, Q0, Q0'
+
+   * uint8x8_t vrsubhn_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vrsubhn.i16 D0, Q0, Q0'
+
+   * int32x2_t vrsubhn_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vrsubhn.i64 D0, Q0, Q0'
+
+   * int16x4_t vrsubhn_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vrsubhn.i32 D0, Q0, Q0'
+
+   * int8x8_t vrsubhn_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vrsubhn.i16 D0, Q0, Q0'
+
+6.57.6.13 Comparison (equal-to)
+...............................
+
+   * uint32x2_t vceq_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vceq.i32 D0, D0, D0'
+
+   * uint16x4_t vceq_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vceq.i16 D0, D0, D0'
+
+   * uint8x8_t vceq_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vceq.i8 D0, D0, D0'
+
+   * uint32x2_t vceq_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vceq.i32 D0, D0, D0'
+
+   * uint16x4_t vceq_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vceq.i16 D0, D0, D0'
+
+   * uint8x8_t vceq_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vceq.i8 D0, D0, D0'
+
+   * uint32x2_t vceq_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vceq.f32 D0, D0, D0'
+
+   * uint8x8_t vceq_p8 (poly8x8_t, poly8x8_t)
+     _Form of expected instruction(s):_ 'vceq.i8 D0, D0, D0'
+
+   * uint32x4_t vceqq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vceq.i32 Q0, Q0, Q0'
+
+   * uint16x8_t vceqq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vceq.i16 Q0, Q0, Q0'
+
+   * uint8x16_t vceqq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vceq.i8 Q0, Q0, Q0'
+
+   * uint32x4_t vceqq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vceq.i32 Q0, Q0, Q0'
+
+   * uint16x8_t vceqq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vceq.i16 Q0, Q0, Q0'
+
+   * uint8x16_t vceqq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vceq.i8 Q0, Q0, Q0'
+
+   * uint32x4_t vceqq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vceq.f32 Q0, Q0, Q0'
+
+   * uint8x16_t vceqq_p8 (poly8x16_t, poly8x16_t)
+     _Form of expected instruction(s):_ 'vceq.i8 Q0, Q0, Q0'
+
+6.57.6.14 Comparison (greater-than-or-equal-to)
+...............................................
+
+   * uint32x2_t vcge_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vcge.s32 D0, D0, D0'
+
+   * uint16x4_t vcge_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vcge.s16 D0, D0, D0'
+
+   * uint8x8_t vcge_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vcge.s8 D0, D0, D0'
+
+   * uint32x2_t vcge_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vcge.f32 D0, D0, D0'
+
+   * uint32x2_t vcge_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vcge.u32 D0, D0, D0'
+
+   * uint16x4_t vcge_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vcge.u16 D0, D0, D0'
+
+   * uint8x8_t vcge_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vcge.u8 D0, D0, D0'
+
+   * uint32x4_t vcgeq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vcge.s32 Q0, Q0, Q0'
+
+   * uint16x8_t vcgeq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vcge.s16 Q0, Q0, Q0'
+
+   * uint8x16_t vcgeq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vcge.s8 Q0, Q0, Q0'
+
+   * uint32x4_t vcgeq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vcge.f32 Q0, Q0, Q0'
+
+   * uint32x4_t vcgeq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vcge.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vcgeq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vcge.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vcgeq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vcge.u8 Q0, Q0, Q0'
+
+6.57.6.15 Comparison (less-than-or-equal-to)
+............................................
+
+   * uint32x2_t vcle_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vcge.s32 D0, D0, D0'
+
+   * uint16x4_t vcle_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vcge.s16 D0, D0, D0'
+
+   * uint8x8_t vcle_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vcge.s8 D0, D0, D0'
+
+   * uint32x2_t vcle_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vcge.f32 D0, D0, D0'
+
+   * uint32x2_t vcle_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vcge.u32 D0, D0, D0'
+
+   * uint16x4_t vcle_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vcge.u16 D0, D0, D0'
+
+   * uint8x8_t vcle_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vcge.u8 D0, D0, D0'
+
+   * uint32x4_t vcleq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vcge.s32 Q0, Q0, Q0'
+
+   * uint16x8_t vcleq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vcge.s16 Q0, Q0, Q0'
+
+   * uint8x16_t vcleq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vcge.s8 Q0, Q0, Q0'
+
+   * uint32x4_t vcleq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vcge.f32 Q0, Q0, Q0'
+
+   * uint32x4_t vcleq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vcge.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vcleq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vcge.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vcleq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vcge.u8 Q0, Q0, Q0'
+
+6.57.6.16 Comparison (greater-than)
+...................................
+
+   * uint32x2_t vcgt_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vcgt.s32 D0, D0, D0'
+
+   * uint16x4_t vcgt_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vcgt.s16 D0, D0, D0'
+
+   * uint8x8_t vcgt_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vcgt.s8 D0, D0, D0'
+
+   * uint32x2_t vcgt_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vcgt.f32 D0, D0, D0'
+
+   * uint32x2_t vcgt_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vcgt.u32 D0, D0, D0'
+
+   * uint16x4_t vcgt_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vcgt.u16 D0, D0, D0'
+
+   * uint8x8_t vcgt_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vcgt.u8 D0, D0, D0'
+
+   * uint32x4_t vcgtq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vcgt.s32 Q0, Q0, Q0'
+
+   * uint16x8_t vcgtq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vcgt.s16 Q0, Q0, Q0'
+
+   * uint8x16_t vcgtq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vcgt.s8 Q0, Q0, Q0'
+
+   * uint32x4_t vcgtq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vcgt.f32 Q0, Q0, Q0'
+
+   * uint32x4_t vcgtq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vcgt.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vcgtq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vcgt.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vcgtq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vcgt.u8 Q0, Q0, Q0'
+
+6.57.6.17 Comparison (less-than)
+................................
+
+   * uint32x2_t vclt_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vcgt.s32 D0, D0, D0'
+
+   * uint16x4_t vclt_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vcgt.s16 D0, D0, D0'
+
+   * uint8x8_t vclt_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vcgt.s8 D0, D0, D0'
+
+   * uint32x2_t vclt_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vcgt.f32 D0, D0, D0'
+
+   * uint32x2_t vclt_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vcgt.u32 D0, D0, D0'
+
+   * uint16x4_t vclt_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vcgt.u16 D0, D0, D0'
+
+   * uint8x8_t vclt_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vcgt.u8 D0, D0, D0'
+
+   * uint32x4_t vcltq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vcgt.s32 Q0, Q0, Q0'
+
+   * uint16x8_t vcltq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vcgt.s16 Q0, Q0, Q0'
+
+   * uint8x16_t vcltq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vcgt.s8 Q0, Q0, Q0'
+
+   * uint32x4_t vcltq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vcgt.f32 Q0, Q0, Q0'
+
+   * uint32x4_t vcltq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vcgt.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vcltq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vcgt.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vcltq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vcgt.u8 Q0, Q0, Q0'
+
+6.57.6.18 Comparison (absolute greater-than-or-equal-to)
+........................................................
+
+   * uint32x2_t vcage_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vacge.f32 D0, D0, D0'
+
+   * uint32x4_t vcageq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vacge.f32 Q0, Q0, Q0'
+
+6.57.6.19 Comparison (absolute less-than-or-equal-to)
+.....................................................
+
+   * uint32x2_t vcale_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vacge.f32 D0, D0, D0'
+
+   * uint32x4_t vcaleq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vacge.f32 Q0, Q0, Q0'
+
+6.57.6.20 Comparison (absolute greater-than)
+............................................
+
+   * uint32x2_t vcagt_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vacgt.f32 D0, D0, D0'
+
+   * uint32x4_t vcagtq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vacgt.f32 Q0, Q0, Q0'
+
+6.57.6.21 Comparison (absolute less-than)
+.........................................
+
+   * uint32x2_t vcalt_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vacgt.f32 D0, D0, D0'
+
+   * uint32x4_t vcaltq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vacgt.f32 Q0, Q0, Q0'
+
+6.57.6.22 Test bits
+...................
+
+   * uint32x2_t vtst_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vtst.32 D0, D0, D0'
+
+   * uint16x4_t vtst_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vtst.16 D0, D0, D0'
+
+   * uint8x8_t vtst_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtst.8 D0, D0, D0'
+
+   * uint32x2_t vtst_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vtst.32 D0, D0, D0'
+
+   * uint16x4_t vtst_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vtst.16 D0, D0, D0'
+
+   * uint8x8_t vtst_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtst.8 D0, D0, D0'
+
+   * uint8x8_t vtst_p8 (poly8x8_t, poly8x8_t)
+     _Form of expected instruction(s):_ 'vtst.8 D0, D0, D0'
+
+   * uint32x4_t vtstq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vtst.32 Q0, Q0, Q0'
+
+   * uint16x8_t vtstq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vtst.16 Q0, Q0, Q0'
+
+   * uint8x16_t vtstq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vtst.8 Q0, Q0, Q0'
+
+   * uint32x4_t vtstq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vtst.32 Q0, Q0, Q0'
+
+   * uint16x8_t vtstq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vtst.16 Q0, Q0, Q0'
+
+   * uint8x16_t vtstq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vtst.8 Q0, Q0, Q0'
+
+   * uint8x16_t vtstq_p8 (poly8x16_t, poly8x16_t)
+     _Form of expected instruction(s):_ 'vtst.8 Q0, Q0, Q0'
+
+6.57.6.23 Absolute difference
+.............................
+
+   * uint32x2_t vabd_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vabd.u32 D0, D0, D0'
+
+   * uint16x4_t vabd_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vabd.u16 D0, D0, D0'
+
+   * uint8x8_t vabd_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vabd.u8 D0, D0, D0'
+
+   * int32x2_t vabd_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vabd.s32 D0, D0, D0'
+
+   * int16x4_t vabd_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vabd.s16 D0, D0, D0'
+
+   * int8x8_t vabd_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vabd.s8 D0, D0, D0'
+
+   * float32x2_t vabd_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vabd.f32 D0, D0, D0'
+
+   * uint32x4_t vabdq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vabd.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vabdq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vabd.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vabdq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vabd.u8 Q0, Q0, Q0'
+
+   * int32x4_t vabdq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vabd.s32 Q0, Q0, Q0'
+
+   * int16x8_t vabdq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vabd.s16 Q0, Q0, Q0'
+
+   * int8x16_t vabdq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vabd.s8 Q0, Q0, Q0'
+
+   * float32x4_t vabdq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vabd.f32 Q0, Q0, Q0'
+
+   * uint64x2_t vabdl_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vabdl.u32 Q0, D0, D0'
+
+   * uint32x4_t vabdl_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vabdl.u16 Q0, D0, D0'
+
+   * uint16x8_t vabdl_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vabdl.u8 Q0, D0, D0'
+
+   * int64x2_t vabdl_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vabdl.s32 Q0, D0, D0'
+
+   * int32x4_t vabdl_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vabdl.s16 Q0, D0, D0'
+
+   * int16x8_t vabdl_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vabdl.s8 Q0, D0, D0'
+
+6.57.6.24 Absolute difference and accumulate
+............................................
+
+   * uint32x2_t vaba_u32 (uint32x2_t, uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vaba.u32 D0, D0, D0'
+
+   * uint16x4_t vaba_u16 (uint16x4_t, uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vaba.u16 D0, D0, D0'
+
+   * uint8x8_t vaba_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vaba.u8 D0, D0, D0'
+
+   * int32x2_t vaba_s32 (int32x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vaba.s32 D0, D0, D0'
+
+   * int16x4_t vaba_s16 (int16x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vaba.s16 D0, D0, D0'
+
+   * int8x8_t vaba_s8 (int8x8_t, int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vaba.s8 D0, D0, D0'
+
+   * uint32x4_t vabaq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vaba.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vabaq_u16 (uint16x8_t, uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vaba.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vabaq_u8 (uint8x16_t, uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vaba.u8 Q0, Q0, Q0'
+
+   * int32x4_t vabaq_s32 (int32x4_t, int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vaba.s32 Q0, Q0, Q0'
+
+   * int16x8_t vabaq_s16 (int16x8_t, int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vaba.s16 Q0, Q0, Q0'
+
+   * int8x16_t vabaq_s8 (int8x16_t, int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vaba.s8 Q0, Q0, Q0'
+
+   * uint64x2_t vabal_u32 (uint64x2_t, uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vabal.u32 Q0, D0, D0'
+
+   * uint32x4_t vabal_u16 (uint32x4_t, uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vabal.u16 Q0, D0, D0'
+
+   * uint16x8_t vabal_u8 (uint16x8_t, uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vabal.u8 Q0, D0, D0'
+
+   * int64x2_t vabal_s32 (int64x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vabal.s32 Q0, D0, D0'
+
+   * int32x4_t vabal_s16 (int32x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vabal.s16 Q0, D0, D0'
+
+   * int16x8_t vabal_s8 (int16x8_t, int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vabal.s8 Q0, D0, D0'
+
+6.57.6.25 Maximum
+.................
+
+   * uint32x2_t vmax_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vmax.u32 D0, D0, D0'
+
+   * uint16x4_t vmax_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vmax.u16 D0, D0, D0'
+
+   * uint8x8_t vmax_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vmax.u8 D0, D0, D0'
+
+   * int32x2_t vmax_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vmax.s32 D0, D0, D0'
+
+   * int16x4_t vmax_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vmax.s16 D0, D0, D0'
+
+   * int8x8_t vmax_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vmax.s8 D0, D0, D0'
+
+   * float32x2_t vmax_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vmax.f32 D0, D0, D0'
+
+   * uint32x4_t vmaxq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vmax.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vmaxq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vmax.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vmaxq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vmax.u8 Q0, Q0, Q0'
+
+   * int32x4_t vmaxq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vmax.s32 Q0, Q0, Q0'
+
+   * int16x8_t vmaxq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vmax.s16 Q0, Q0, Q0'
+
+   * int8x16_t vmaxq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vmax.s8 Q0, Q0, Q0'
+
+   * float32x4_t vmaxq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vmax.f32 Q0, Q0, Q0'
+
+6.57.6.26 Minimum
+.................
+
+   * uint32x2_t vmin_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vmin.u32 D0, D0, D0'
+
+   * uint16x4_t vmin_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vmin.u16 D0, D0, D0'
+
+   * uint8x8_t vmin_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vmin.u8 D0, D0, D0'
+
+   * int32x2_t vmin_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vmin.s32 D0, D0, D0'
+
+   * int16x4_t vmin_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vmin.s16 D0, D0, D0'
+
+   * int8x8_t vmin_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vmin.s8 D0, D0, D0'
+
+   * float32x2_t vmin_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vmin.f32 D0, D0, D0'
+
+   * uint32x4_t vminq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vmin.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vminq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vmin.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vminq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vmin.u8 Q0, Q0, Q0'
+
+   * int32x4_t vminq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vmin.s32 Q0, Q0, Q0'
+
+   * int16x8_t vminq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vmin.s16 Q0, Q0, Q0'
+
+   * int8x16_t vminq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vmin.s8 Q0, Q0, Q0'
+
+   * float32x4_t vminq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vmin.f32 Q0, Q0, Q0'
+
+6.57.6.27 Pairwise add
+......................
+
+   * uint32x2_t vpadd_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vpadd.i32 D0, D0, D0'
+
+   * uint16x4_t vpadd_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vpadd.i16 D0, D0, D0'
+
+   * uint8x8_t vpadd_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vpadd.i8 D0, D0, D0'
+
+   * int32x2_t vpadd_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vpadd.i32 D0, D0, D0'
+
+   * int16x4_t vpadd_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vpadd.i16 D0, D0, D0'
+
+   * int8x8_t vpadd_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vpadd.i8 D0, D0, D0'
+
+   * float32x2_t vpadd_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vpadd.f32 D0, D0, D0'
+
+   * uint64x1_t vpaddl_u32 (uint32x2_t)
+     _Form of expected instruction(s):_ 'vpaddl.u32 D0, D0'
+
+   * uint32x2_t vpaddl_u16 (uint16x4_t)
+     _Form of expected instruction(s):_ 'vpaddl.u16 D0, D0'
+
+   * uint16x4_t vpaddl_u8 (uint8x8_t)
+     _Form of expected instruction(s):_ 'vpaddl.u8 D0, D0'
+
+   * int64x1_t vpaddl_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vpaddl.s32 D0, D0'
+
+   * int32x2_t vpaddl_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vpaddl.s16 D0, D0'
+
+   * int16x4_t vpaddl_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vpaddl.s8 D0, D0'
+
+   * uint64x2_t vpaddlq_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vpaddl.u32 Q0, Q0'
+
+   * uint32x4_t vpaddlq_u16 (uint16x8_t)
+     _Form of expected instruction(s):_ 'vpaddl.u16 Q0, Q0'
+
+   * uint16x8_t vpaddlq_u8 (uint8x16_t)
+     _Form of expected instruction(s):_ 'vpaddl.u8 Q0, Q0'
+
+   * int64x2_t vpaddlq_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vpaddl.s32 Q0, Q0'
+
+   * int32x4_t vpaddlq_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vpaddl.s16 Q0, Q0'
+
+   * int16x8_t vpaddlq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vpaddl.s8 Q0, Q0'
+
+6.57.6.28 Pairwise add, single_opcode widen and accumulate
+..........................................................
+
+   * uint64x1_t vpadal_u32 (uint64x1_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vpadal.u32 D0, D0'
+
+   * uint32x2_t vpadal_u16 (uint32x2_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vpadal.u16 D0, D0'
+
+   * uint16x4_t vpadal_u8 (uint16x4_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vpadal.u8 D0, D0'
+
+   * int64x1_t vpadal_s32 (int64x1_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vpadal.s32 D0, D0'
+
+   * int32x2_t vpadal_s16 (int32x2_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vpadal.s16 D0, D0'
+
+   * int16x4_t vpadal_s8 (int16x4_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vpadal.s8 D0, D0'
+
+   * uint64x2_t vpadalq_u32 (uint64x2_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vpadal.u32 Q0, Q0'
+
+   * uint32x4_t vpadalq_u16 (uint32x4_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vpadal.u16 Q0, Q0'
+
+   * uint16x8_t vpadalq_u8 (uint16x8_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vpadal.u8 Q0, Q0'
+
+   * int64x2_t vpadalq_s32 (int64x2_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vpadal.s32 Q0, Q0'
+
+   * int32x4_t vpadalq_s16 (int32x4_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vpadal.s16 Q0, Q0'
+
+   * int16x8_t vpadalq_s8 (int16x8_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vpadal.s8 Q0, Q0'
+
+6.57.6.29 Folding maximum
+.........................
+
+   * uint32x2_t vpmax_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vpmax.u32 D0, D0, D0'
+
+   * uint16x4_t vpmax_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vpmax.u16 D0, D0, D0'
+
+   * uint8x8_t vpmax_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vpmax.u8 D0, D0, D0'
+
+   * int32x2_t vpmax_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vpmax.s32 D0, D0, D0'
+
+   * int16x4_t vpmax_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vpmax.s16 D0, D0, D0'
+
+   * int8x8_t vpmax_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vpmax.s8 D0, D0, D0'
+
+   * float32x2_t vpmax_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vpmax.f32 D0, D0, D0'
+
+6.57.6.30 Folding minimum
+.........................
+
+   * uint32x2_t vpmin_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vpmin.u32 D0, D0, D0'
+
+   * uint16x4_t vpmin_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vpmin.u16 D0, D0, D0'
+
+   * uint8x8_t vpmin_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vpmin.u8 D0, D0, D0'
+
+   * int32x2_t vpmin_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vpmin.s32 D0, D0, D0'
+
+   * int16x4_t vpmin_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vpmin.s16 D0, D0, D0'
+
+   * int8x8_t vpmin_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vpmin.s8 D0, D0, D0'
+
+   * float32x2_t vpmin_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vpmin.f32 D0, D0, D0'
+
+6.57.6.31 Reciprocal step
+.........................
+
+   * float32x2_t vrecps_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vrecps.f32 D0, D0, D0'
+
+   * float32x4_t vrecpsq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vrecps.f32 Q0, Q0, Q0'
+
+   * float32x2_t vrsqrts_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vrsqrts.f32 D0, D0, D0'
+
+   * float32x4_t vrsqrtsq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vrsqrts.f32 Q0, Q0, Q0'
+
+6.57.6.32 Vector shift left
+...........................
+
+   * uint32x2_t vshl_u32 (uint32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vshl.u32 D0, D0, D0'
+
+   * uint16x4_t vshl_u16 (uint16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vshl.u16 D0, D0, D0'
+
+   * uint8x8_t vshl_u8 (uint8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vshl.u8 D0, D0, D0'
+
+   * int32x2_t vshl_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vshl.s32 D0, D0, D0'
+
+   * int16x4_t vshl_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vshl.s16 D0, D0, D0'
+
+   * int8x8_t vshl_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vshl.s8 D0, D0, D0'
+
+   * uint64x1_t vshl_u64 (uint64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vshl.u64 D0, D0, D0'
+
+   * int64x1_t vshl_s64 (int64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vshl.s64 D0, D0, D0'
+
+   * uint32x4_t vshlq_u32 (uint32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vshl.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vshlq_u16 (uint16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vshl.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vshlq_u8 (uint8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vshl.u8 Q0, Q0, Q0'
+
+   * int32x4_t vshlq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vshl.s32 Q0, Q0, Q0'
+
+   * int16x8_t vshlq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vshl.s16 Q0, Q0, Q0'
+
+   * int8x16_t vshlq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vshl.s8 Q0, Q0, Q0'
+
+   * uint64x2_t vshlq_u64 (uint64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vshl.u64 Q0, Q0, Q0'
+
+   * int64x2_t vshlq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vshl.s64 Q0, Q0, Q0'
+
+   * uint32x2_t vrshl_u32 (uint32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vrshl.u32 D0, D0, D0'
+
+   * uint16x4_t vrshl_u16 (uint16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vrshl.u16 D0, D0, D0'
+
+   * uint8x8_t vrshl_u8 (uint8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vrshl.u8 D0, D0, D0'
+
+   * int32x2_t vrshl_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vrshl.s32 D0, D0, D0'
+
+   * int16x4_t vrshl_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vrshl.s16 D0, D0, D0'
+
+   * int8x8_t vrshl_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vrshl.s8 D0, D0, D0'
+
+   * uint64x1_t vrshl_u64 (uint64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vrshl.u64 D0, D0, D0'
+
+   * int64x1_t vrshl_s64 (int64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vrshl.s64 D0, D0, D0'
+
+   * uint32x4_t vrshlq_u32 (uint32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vrshl.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vrshlq_u16 (uint16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vrshl.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vrshlq_u8 (uint8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vrshl.u8 Q0, Q0, Q0'
+
+   * int32x4_t vrshlq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vrshl.s32 Q0, Q0, Q0'
+
+   * int16x8_t vrshlq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vrshl.s16 Q0, Q0, Q0'
+
+   * int8x16_t vrshlq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vrshl.s8 Q0, Q0, Q0'
+
+   * uint64x2_t vrshlq_u64 (uint64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vrshl.u64 Q0, Q0, Q0'
+
+   * int64x2_t vrshlq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vrshl.s64 Q0, Q0, Q0'
+
+   * uint32x2_t vqshl_u32 (uint32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqshl.u32 D0, D0, D0'
+
+   * uint16x4_t vqshl_u16 (uint16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqshl.u16 D0, D0, D0'
+
+   * uint8x8_t vqshl_u8 (uint8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vqshl.u8 D0, D0, D0'
+
+   * int32x2_t vqshl_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqshl.s32 D0, D0, D0'
+
+   * int16x4_t vqshl_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqshl.s16 D0, D0, D0'
+
+   * int8x8_t vqshl_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vqshl.s8 D0, D0, D0'
+
+   * uint64x1_t vqshl_u64 (uint64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vqshl.u64 D0, D0, D0'
+
+   * int64x1_t vqshl_s64 (int64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vqshl.s64 D0, D0, D0'
+
+   * uint32x4_t vqshlq_u32 (uint32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vqshl.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vqshlq_u16 (uint16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vqshl.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vqshlq_u8 (uint8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vqshl.u8 Q0, Q0, Q0'
+
+   * int32x4_t vqshlq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vqshl.s32 Q0, Q0, Q0'
+
+   * int16x8_t vqshlq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vqshl.s16 Q0, Q0, Q0'
+
+   * int8x16_t vqshlq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vqshl.s8 Q0, Q0, Q0'
+
+   * uint64x2_t vqshlq_u64 (uint64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vqshl.u64 Q0, Q0, Q0'
+
+   * int64x2_t vqshlq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vqshl.s64 Q0, Q0, Q0'
+
+   * uint32x2_t vqrshl_u32 (uint32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqrshl.u32 D0, D0, D0'
+
+   * uint16x4_t vqrshl_u16 (uint16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqrshl.u16 D0, D0, D0'
+
+   * uint8x8_t vqrshl_u8 (uint8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vqrshl.u8 D0, D0, D0'
+
+   * int32x2_t vqrshl_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vqrshl.s32 D0, D0, D0'
+
+   * int16x4_t vqrshl_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vqrshl.s16 D0, D0, D0'
+
+   * int8x8_t vqrshl_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vqrshl.s8 D0, D0, D0'
+
+   * uint64x1_t vqrshl_u64 (uint64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vqrshl.u64 D0, D0, D0'
+
+   * int64x1_t vqrshl_s64 (int64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vqrshl.s64 D0, D0, D0'
+
+   * uint32x4_t vqrshlq_u32 (uint32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vqrshl.u32 Q0, Q0, Q0'
+
+   * uint16x8_t vqrshlq_u16 (uint16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vqrshl.u16 Q0, Q0, Q0'
+
+   * uint8x16_t vqrshlq_u8 (uint8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vqrshl.u8 Q0, Q0, Q0'
+
+   * int32x4_t vqrshlq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vqrshl.s32 Q0, Q0, Q0'
+
+   * int16x8_t vqrshlq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vqrshl.s16 Q0, Q0, Q0'
+
+   * int8x16_t vqrshlq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vqrshl.s8 Q0, Q0, Q0'
+
+   * uint64x2_t vqrshlq_u64 (uint64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vqrshl.u64 Q0, Q0, Q0'
+
+   * int64x2_t vqrshlq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vqrshl.s64 Q0, Q0, Q0'
+
+6.57.6.33 Vector shift left by constant
+.......................................
+
+   * uint32x2_t vshl_n_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i32 D0, D0, #0'
+
+   * uint16x4_t vshl_n_u16 (uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i16 D0, D0, #0'
+
+   * uint8x8_t vshl_n_u8 (uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i8 D0, D0, #0'
+
+   * int32x2_t vshl_n_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i32 D0, D0, #0'
+
+   * int16x4_t vshl_n_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i16 D0, D0, #0'
+
+   * int8x8_t vshl_n_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i8 D0, D0, #0'
+
+   * uint64x1_t vshl_n_u64 (uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i64 D0, D0, #0'
+
+   * int64x1_t vshl_n_s64 (int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i64 D0, D0, #0'
+
+   * uint32x4_t vshlq_n_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i32 Q0, Q0, #0'
+
+   * uint16x8_t vshlq_n_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i16 Q0, Q0, #0'
+
+   * uint8x16_t vshlq_n_u8 (uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i8 Q0, Q0, #0'
+
+   * int32x4_t vshlq_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i32 Q0, Q0, #0'
+
+   * int16x8_t vshlq_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i16 Q0, Q0, #0'
+
+   * int8x16_t vshlq_n_s8 (int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i8 Q0, Q0, #0'
+
+   * uint64x2_t vshlq_n_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i64 Q0, Q0, #0'
+
+   * int64x2_t vshlq_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vshl.i64 Q0, Q0, #0'
+
+   * uint32x2_t vqshl_n_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.u32 D0, D0, #0'
+
+   * uint16x4_t vqshl_n_u16 (uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.u16 D0, D0, #0'
+
+   * uint8x8_t vqshl_n_u8 (uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.u8 D0, D0, #0'
+
+   * int32x2_t vqshl_n_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.s32 D0, D0, #0'
+
+   * int16x4_t vqshl_n_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.s16 D0, D0, #0'
+
+   * int8x8_t vqshl_n_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.s8 D0, D0, #0'
+
+   * uint64x1_t vqshl_n_u64 (uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.u64 D0, D0, #0'
+
+   * int64x1_t vqshl_n_s64 (int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.s64 D0, D0, #0'
+
+   * uint32x4_t vqshlq_n_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.u32 Q0, Q0, #0'
+
+   * uint16x8_t vqshlq_n_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.u16 Q0, Q0, #0'
+
+   * uint8x16_t vqshlq_n_u8 (uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.u8 Q0, Q0, #0'
+
+   * int32x4_t vqshlq_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.s32 Q0, Q0, #0'
+
+   * int16x8_t vqshlq_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.s16 Q0, Q0, #0'
+
+   * int8x16_t vqshlq_n_s8 (int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.s8 Q0, Q0, #0'
+
+   * uint64x2_t vqshlq_n_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.u64 Q0, Q0, #0'
+
+   * int64x2_t vqshlq_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshl.s64 Q0, Q0, #0'
+
+   * uint64x1_t vqshlu_n_s64 (int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vqshlu.s64 D0, D0, #0'
+
+   * uint32x2_t vqshlu_n_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshlu.s32 D0, D0, #0'
+
+   * uint16x4_t vqshlu_n_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshlu.s16 D0, D0, #0'
+
+   * uint8x8_t vqshlu_n_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshlu.s8 D0, D0, #0'
+
+   * uint64x2_t vqshluq_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshlu.s64 Q0, Q0, #0'
+
+   * uint32x4_t vqshluq_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshlu.s32 Q0, Q0, #0'
+
+   * uint16x8_t vqshluq_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshlu.s16 Q0, Q0, #0'
+
+   * uint8x16_t vqshluq_n_s8 (int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vqshlu.s8 Q0, Q0, #0'
+
+   * uint64x2_t vshll_n_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vshll.u32 Q0, D0, #0'
+
+   * uint32x4_t vshll_n_u16 (uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vshll.u16 Q0, D0, #0'
+
+   * uint16x8_t vshll_n_u8 (uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vshll.u8 Q0, D0, #0'
+
+   * int64x2_t vshll_n_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vshll.s32 Q0, D0, #0'
+
+   * int32x4_t vshll_n_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vshll.s16 Q0, D0, #0'
+
+   * int16x8_t vshll_n_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vshll.s8 Q0, D0, #0'
+
+6.57.6.34 Vector shift right by constant
+........................................
+
+   * uint32x2_t vshr_n_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vshr.u32 D0, D0, #0'
+
+   * uint16x4_t vshr_n_u16 (uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vshr.u16 D0, D0, #0'
+
+   * uint8x8_t vshr_n_u8 (uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vshr.u8 D0, D0, #0'
+
+   * int32x2_t vshr_n_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vshr.s32 D0, D0, #0'
+
+   * int16x4_t vshr_n_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vshr.s16 D0, D0, #0'
+
+   * int8x8_t vshr_n_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vshr.s8 D0, D0, #0'
+
+   * uint64x1_t vshr_n_u64 (uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vshr.u64 D0, D0, #0'
+
+   * int64x1_t vshr_n_s64 (int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vshr.s64 D0, D0, #0'
+
+   * uint32x4_t vshrq_n_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vshr.u32 Q0, Q0, #0'
+
+   * uint16x8_t vshrq_n_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vshr.u16 Q0, Q0, #0'
+
+   * uint8x16_t vshrq_n_u8 (uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vshr.u8 Q0, Q0, #0'
+
+   * int32x4_t vshrq_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vshr.s32 Q0, Q0, #0'
+
+   * int16x8_t vshrq_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vshr.s16 Q0, Q0, #0'
+
+   * int8x16_t vshrq_n_s8 (int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vshr.s8 Q0, Q0, #0'
+
+   * uint64x2_t vshrq_n_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vshr.u64 Q0, Q0, #0'
+
+   * int64x2_t vshrq_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vshr.s64 Q0, Q0, #0'
+
+   * uint32x2_t vrshr_n_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.u32 D0, D0, #0'
+
+   * uint16x4_t vrshr_n_u16 (uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.u16 D0, D0, #0'
+
+   * uint8x8_t vrshr_n_u8 (uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.u8 D0, D0, #0'
+
+   * int32x2_t vrshr_n_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.s32 D0, D0, #0'
+
+   * int16x4_t vrshr_n_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.s16 D0, D0, #0'
+
+   * int8x8_t vrshr_n_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.s8 D0, D0, #0'
+
+   * uint64x1_t vrshr_n_u64 (uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.u64 D0, D0, #0'
+
+   * int64x1_t vrshr_n_s64 (int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.s64 D0, D0, #0'
+
+   * uint32x4_t vrshrq_n_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.u32 Q0, Q0, #0'
+
+   * uint16x8_t vrshrq_n_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.u16 Q0, Q0, #0'
+
+   * uint8x16_t vrshrq_n_u8 (uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.u8 Q0, Q0, #0'
+
+   * int32x4_t vrshrq_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.s32 Q0, Q0, #0'
+
+   * int16x8_t vrshrq_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.s16 Q0, Q0, #0'
+
+   * int8x16_t vrshrq_n_s8 (int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.s8 Q0, Q0, #0'
+
+   * uint64x2_t vrshrq_n_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.u64 Q0, Q0, #0'
+
+   * int64x2_t vrshrq_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vrshr.s64 Q0, Q0, #0'
+
+   * uint32x2_t vshrn_n_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vshrn.i64 D0, Q0, #0'
+
+   * uint16x4_t vshrn_n_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vshrn.i32 D0, Q0, #0'
+
+   * uint8x8_t vshrn_n_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vshrn.i16 D0, Q0, #0'
+
+   * int32x2_t vshrn_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vshrn.i64 D0, Q0, #0'
+
+   * int16x4_t vshrn_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vshrn.i32 D0, Q0, #0'
+
+   * int8x8_t vshrn_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vshrn.i16 D0, Q0, #0'
+
+   * uint32x2_t vrshrn_n_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vrshrn.i64 D0, Q0, #0'
+
+   * uint16x4_t vrshrn_n_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vrshrn.i32 D0, Q0, #0'
+
+   * uint8x8_t vrshrn_n_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vrshrn.i16 D0, Q0, #0'
+
+   * int32x2_t vrshrn_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vrshrn.i64 D0, Q0, #0'
+
+   * int16x4_t vrshrn_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vrshrn.i32 D0, Q0, #0'
+
+   * int8x8_t vrshrn_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vrshrn.i16 D0, Q0, #0'
+
+   * uint32x2_t vqshrn_n_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshrn.u64 D0, Q0, #0'
+
+   * uint16x4_t vqshrn_n_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshrn.u32 D0, Q0, #0'
+
+   * uint8x8_t vqshrn_n_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshrn.u16 D0, Q0, #0'
+
+   * int32x2_t vqshrn_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshrn.s64 D0, Q0, #0'
+
+   * int16x4_t vqshrn_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshrn.s32 D0, Q0, #0'
+
+   * int8x8_t vqshrn_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshrn.s16 D0, Q0, #0'
+
+   * uint32x2_t vqrshrn_n_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrn.u64 D0, Q0, #0'
+
+   * uint16x4_t vqrshrn_n_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrn.u32 D0, Q0, #0'
+
+   * uint8x8_t vqrshrn_n_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrn.u16 D0, Q0, #0'
+
+   * int32x2_t vqrshrn_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrn.s64 D0, Q0, #0'
+
+   * int16x4_t vqrshrn_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrn.s32 D0, Q0, #0'
+
+   * int8x8_t vqrshrn_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrn.s16 D0, Q0, #0'
+
+   * uint32x2_t vqshrun_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqshrun.s64 D0, Q0, #0'
+
+   * uint16x4_t vqshrun_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqshrun.s32 D0, Q0, #0'
+
+   * uint8x8_t vqshrun_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqshrun.s16 D0, Q0, #0'
+
+   * uint32x2_t vqrshrun_n_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrun.s64 D0, Q0, #0'
+
+   * uint16x4_t vqrshrun_n_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrun.s32 D0, Q0, #0'
+
+   * uint8x8_t vqrshrun_n_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vqrshrun.s16 D0, Q0, #0'
+
+6.57.6.35 Vector shift right by constant and accumulate
+.......................................................
+
+   * uint32x2_t vsra_n_u32 (uint32x2_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vsra.u32 D0, D0, #0'
+
+   * uint16x4_t vsra_n_u16 (uint16x4_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vsra.u16 D0, D0, #0'
+
+   * uint8x8_t vsra_n_u8 (uint8x8_t, uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vsra.u8 D0, D0, #0'
+
+   * int32x2_t vsra_n_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vsra.s32 D0, D0, #0'
+
+   * int16x4_t vsra_n_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vsra.s16 D0, D0, #0'
+
+   * int8x8_t vsra_n_s8 (int8x8_t, int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vsra.s8 D0, D0, #0'
+
+   * uint64x1_t vsra_n_u64 (uint64x1_t, uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vsra.u64 D0, D0, #0'
+
+   * int64x1_t vsra_n_s64 (int64x1_t, int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vsra.s64 D0, D0, #0'
+
+   * uint32x4_t vsraq_n_u32 (uint32x4_t, uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vsra.u32 Q0, Q0, #0'
+
+   * uint16x8_t vsraq_n_u16 (uint16x8_t, uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vsra.u16 Q0, Q0, #0'
+
+   * uint8x16_t vsraq_n_u8 (uint8x16_t, uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vsra.u8 Q0, Q0, #0'
+
+   * int32x4_t vsraq_n_s32 (int32x4_t, int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vsra.s32 Q0, Q0, #0'
+
+   * int16x8_t vsraq_n_s16 (int16x8_t, int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vsra.s16 Q0, Q0, #0'
+
+   * int8x16_t vsraq_n_s8 (int8x16_t, int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vsra.s8 Q0, Q0, #0'
+
+   * uint64x2_t vsraq_n_u64 (uint64x2_t, uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vsra.u64 Q0, Q0, #0'
+
+   * int64x2_t vsraq_n_s64 (int64x2_t, int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vsra.s64 Q0, Q0, #0'
+
+   * uint32x2_t vrsra_n_u32 (uint32x2_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.u32 D0, D0, #0'
+
+   * uint16x4_t vrsra_n_u16 (uint16x4_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.u16 D0, D0, #0'
+
+   * uint8x8_t vrsra_n_u8 (uint8x8_t, uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.u8 D0, D0, #0'
+
+   * int32x2_t vrsra_n_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.s32 D0, D0, #0'
+
+   * int16x4_t vrsra_n_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.s16 D0, D0, #0'
+
+   * int8x8_t vrsra_n_s8 (int8x8_t, int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.s8 D0, D0, #0'
+
+   * uint64x1_t vrsra_n_u64 (uint64x1_t, uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.u64 D0, D0, #0'
+
+   * int64x1_t vrsra_n_s64 (int64x1_t, int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.s64 D0, D0, #0'
+
+   * uint32x4_t vrsraq_n_u32 (uint32x4_t, uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.u32 Q0, Q0, #0'
+
+   * uint16x8_t vrsraq_n_u16 (uint16x8_t, uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.u16 Q0, Q0, #0'
+
+   * uint8x16_t vrsraq_n_u8 (uint8x16_t, uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.u8 Q0, Q0, #0'
+
+   * int32x4_t vrsraq_n_s32 (int32x4_t, int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.s32 Q0, Q0, #0'
+
+   * int16x8_t vrsraq_n_s16 (int16x8_t, int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.s16 Q0, Q0, #0'
+
+   * int8x16_t vrsraq_n_s8 (int8x16_t, int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.s8 Q0, Q0, #0'
+
+   * uint64x2_t vrsraq_n_u64 (uint64x2_t, uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.u64 Q0, Q0, #0'
+
+   * int64x2_t vrsraq_n_s64 (int64x2_t, int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vrsra.s64 Q0, Q0, #0'
+
+6.57.6.36 Vector shift right and insert
+.......................................
+
+   * poly64x1_t vsri_n_p64 (poly64x1_t, poly64x1_t, const int)
+     _Form of expected instruction(s):_ 'vsri.64 D0, D0, #0'
+
+   * uint32x2_t vsri_n_u32 (uint32x2_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vsri.32 D0, D0, #0'
+
+   * uint16x4_t vsri_n_u16 (uint16x4_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vsri.16 D0, D0, #0'
+
+   * uint8x8_t vsri_n_u8 (uint8x8_t, uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vsri.8 D0, D0, #0'
+
+   * int32x2_t vsri_n_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vsri.32 D0, D0, #0'
+
+   * int16x4_t vsri_n_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vsri.16 D0, D0, #0'
+
+   * int8x8_t vsri_n_s8 (int8x8_t, int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vsri.8 D0, D0, #0'
+
+   * uint64x1_t vsri_n_u64 (uint64x1_t, uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vsri.64 D0, D0, #0'
+
+   * int64x1_t vsri_n_s64 (int64x1_t, int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vsri.64 D0, D0, #0'
+
+   * poly16x4_t vsri_n_p16 (poly16x4_t, poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vsri.16 D0, D0, #0'
+
+   * poly8x8_t vsri_n_p8 (poly8x8_t, poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vsri.8 D0, D0, #0'
+
+   * poly64x2_t vsriq_n_p64 (poly64x2_t, poly64x2_t, const int)
+     _Form of expected instruction(s):_ 'vsri.64 Q0, Q0, #0'
+
+   * uint32x4_t vsriq_n_u32 (uint32x4_t, uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vsri.32 Q0, Q0, #0'
+
+   * uint16x8_t vsriq_n_u16 (uint16x8_t, uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vsri.16 Q0, Q0, #0'
+
+   * uint8x16_t vsriq_n_u8 (uint8x16_t, uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vsri.8 Q0, Q0, #0'
+
+   * int32x4_t vsriq_n_s32 (int32x4_t, int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vsri.32 Q0, Q0, #0'
+
+   * int16x8_t vsriq_n_s16 (int16x8_t, int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vsri.16 Q0, Q0, #0'
+
+   * int8x16_t vsriq_n_s8 (int8x16_t, int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vsri.8 Q0, Q0, #0'
+
+   * uint64x2_t vsriq_n_u64 (uint64x2_t, uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vsri.64 Q0, Q0, #0'
+
+   * int64x2_t vsriq_n_s64 (int64x2_t, int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vsri.64 Q0, Q0, #0'
+
+   * poly16x8_t vsriq_n_p16 (poly16x8_t, poly16x8_t, const int)
+     _Form of expected instruction(s):_ 'vsri.16 Q0, Q0, #0'
+
+   * poly8x16_t vsriq_n_p8 (poly8x16_t, poly8x16_t, const int)
+     _Form of expected instruction(s):_ 'vsri.8 Q0, Q0, #0'
+
+6.57.6.37 Vector shift left and insert
+......................................
+
+   * poly64x1_t vsli_n_p64 (poly64x1_t, poly64x1_t, const int)
+     _Form of expected instruction(s):_ 'vsli.64 D0, D0, #0'
+
+   * uint32x2_t vsli_n_u32 (uint32x2_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vsli.32 D0, D0, #0'
+
+   * uint16x4_t vsli_n_u16 (uint16x4_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vsli.16 D0, D0, #0'
+
+   * uint8x8_t vsli_n_u8 (uint8x8_t, uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vsli.8 D0, D0, #0'
+
+   * int32x2_t vsli_n_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vsli.32 D0, D0, #0'
+
+   * int16x4_t vsli_n_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vsli.16 D0, D0, #0'
+
+   * int8x8_t vsli_n_s8 (int8x8_t, int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vsli.8 D0, D0, #0'
+
+   * uint64x1_t vsli_n_u64 (uint64x1_t, uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vsli.64 D0, D0, #0'
+
+   * int64x1_t vsli_n_s64 (int64x1_t, int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vsli.64 D0, D0, #0'
+
+   * poly16x4_t vsli_n_p16 (poly16x4_t, poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vsli.16 D0, D0, #0'
+
+   * poly8x8_t vsli_n_p8 (poly8x8_t, poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vsli.8 D0, D0, #0'
+
+   * poly64x2_t vsliq_n_p64 (poly64x2_t, poly64x2_t, const int)
+     _Form of expected instruction(s):_ 'vsli.64 Q0, Q0, #0'
+
+   * uint32x4_t vsliq_n_u32 (uint32x4_t, uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vsli.32 Q0, Q0, #0'
+
+   * uint16x8_t vsliq_n_u16 (uint16x8_t, uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vsli.16 Q0, Q0, #0'
+
+   * uint8x16_t vsliq_n_u8 (uint8x16_t, uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vsli.8 Q0, Q0, #0'
+
+   * int32x4_t vsliq_n_s32 (int32x4_t, int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vsli.32 Q0, Q0, #0'
+
+   * int16x8_t vsliq_n_s16 (int16x8_t, int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vsli.16 Q0, Q0, #0'
+
+   * int8x16_t vsliq_n_s8 (int8x16_t, int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vsli.8 Q0, Q0, #0'
+
+   * uint64x2_t vsliq_n_u64 (uint64x2_t, uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vsli.64 Q0, Q0, #0'
+
+   * int64x2_t vsliq_n_s64 (int64x2_t, int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vsli.64 Q0, Q0, #0'
+
+   * poly16x8_t vsliq_n_p16 (poly16x8_t, poly16x8_t, const int)
+     _Form of expected instruction(s):_ 'vsli.16 Q0, Q0, #0'
+
+   * poly8x16_t vsliq_n_p8 (poly8x16_t, poly8x16_t, const int)
+     _Form of expected instruction(s):_ 'vsli.8 Q0, Q0, #0'
+
+6.57.6.38 Absolute value
+........................
+
+   * float32x2_t vabs_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vabs.f32 D0, D0'
+
+   * int32x2_t vabs_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vabs.s32 D0, D0'
+
+   * int16x4_t vabs_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vabs.s16 D0, D0'
+
+   * int8x8_t vabs_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vabs.s8 D0, D0'
+
+   * float32x4_t vabsq_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vabs.f32 Q0, Q0'
+
+   * int32x4_t vabsq_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vabs.s32 Q0, Q0'
+
+   * int16x8_t vabsq_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vabs.s16 Q0, Q0'
+
+   * int8x16_t vabsq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vabs.s8 Q0, Q0'
+
+   * int32x2_t vqabs_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vqabs.s32 D0, D0'
+
+   * int16x4_t vqabs_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vqabs.s16 D0, D0'
+
+   * int8x8_t vqabs_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vqabs.s8 D0, D0'
+
+   * int32x4_t vqabsq_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vqabs.s32 Q0, Q0'
+
+   * int16x8_t vqabsq_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vqabs.s16 Q0, Q0'
+
+   * int8x16_t vqabsq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vqabs.s8 Q0, Q0'
+
+6.57.6.39 Negation
+..................
+
+   * float32x2_t vneg_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vneg.f32 D0, D0'
+
+   * int32x2_t vneg_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vneg.s32 D0, D0'
+
+   * int16x4_t vneg_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vneg.s16 D0, D0'
+
+   * int8x8_t vneg_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vneg.s8 D0, D0'
+
+   * float32x4_t vnegq_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vneg.f32 Q0, Q0'
+
+   * int32x4_t vnegq_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vneg.s32 Q0, Q0'
+
+   * int16x8_t vnegq_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vneg.s16 Q0, Q0'
+
+   * int8x16_t vnegq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vneg.s8 Q0, Q0'
+
+   * int32x2_t vqneg_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vqneg.s32 D0, D0'
+
+   * int16x4_t vqneg_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vqneg.s16 D0, D0'
+
+   * int8x8_t vqneg_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vqneg.s8 D0, D0'
+
+   * int32x4_t vqnegq_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vqneg.s32 Q0, Q0'
+
+   * int16x8_t vqnegq_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vqneg.s16 Q0, Q0'
+
+   * int8x16_t vqnegq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vqneg.s8 Q0, Q0'
+
+6.57.6.40 Bitwise not
+.....................
+
+   * uint32x2_t vmvn_u32 (uint32x2_t)
+     _Form of expected instruction(s):_ 'vmvn D0, D0'
+
+   * uint16x4_t vmvn_u16 (uint16x4_t)
+     _Form of expected instruction(s):_ 'vmvn D0, D0'
+
+   * uint8x8_t vmvn_u8 (uint8x8_t)
+     _Form of expected instruction(s):_ 'vmvn D0, D0'
+
+   * int32x2_t vmvn_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vmvn D0, D0'
+
+   * int16x4_t vmvn_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vmvn D0, D0'
+
+   * int8x8_t vmvn_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vmvn D0, D0'
+
+   * poly8x8_t vmvn_p8 (poly8x8_t)
+     _Form of expected instruction(s):_ 'vmvn D0, D0'
+
+   * uint32x4_t vmvnq_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vmvn Q0, Q0'
+
+   * uint16x8_t vmvnq_u16 (uint16x8_t)
+     _Form of expected instruction(s):_ 'vmvn Q0, Q0'
+
+   * uint8x16_t vmvnq_u8 (uint8x16_t)
+     _Form of expected instruction(s):_ 'vmvn Q0, Q0'
+
+   * int32x4_t vmvnq_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vmvn Q0, Q0'
+
+   * int16x8_t vmvnq_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vmvn Q0, Q0'
+
+   * int8x16_t vmvnq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vmvn Q0, Q0'
+
+   * poly8x16_t vmvnq_p8 (poly8x16_t)
+     _Form of expected instruction(s):_ 'vmvn Q0, Q0'
+
+6.57.6.41 Count leading sign bits
+.................................
+
+   * int32x2_t vcls_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vcls.s32 D0, D0'
+
+   * int16x4_t vcls_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vcls.s16 D0, D0'
+
+   * int8x8_t vcls_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vcls.s8 D0, D0'
+
+   * int32x4_t vclsq_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vcls.s32 Q0, Q0'
+
+   * int16x8_t vclsq_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vcls.s16 Q0, Q0'
+
+   * int8x16_t vclsq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vcls.s8 Q0, Q0'
+
+6.57.6.42 Count leading zeros
+.............................
+
+   * uint32x2_t vclz_u32 (uint32x2_t)
+     _Form of expected instruction(s):_ 'vclz.i32 D0, D0'
+
+   * uint16x4_t vclz_u16 (uint16x4_t)
+     _Form of expected instruction(s):_ 'vclz.i16 D0, D0'
+
+   * uint8x8_t vclz_u8 (uint8x8_t)
+     _Form of expected instruction(s):_ 'vclz.i8 D0, D0'
+
+   * int32x2_t vclz_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vclz.i32 D0, D0'
+
+   * int16x4_t vclz_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vclz.i16 D0, D0'
+
+   * int8x8_t vclz_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vclz.i8 D0, D0'
+
+   * uint32x4_t vclzq_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vclz.i32 Q0, Q0'
+
+   * uint16x8_t vclzq_u16 (uint16x8_t)
+     _Form of expected instruction(s):_ 'vclz.i16 Q0, Q0'
+
+   * uint8x16_t vclzq_u8 (uint8x16_t)
+     _Form of expected instruction(s):_ 'vclz.i8 Q0, Q0'
+
+   * int32x4_t vclzq_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vclz.i32 Q0, Q0'
+
+   * int16x8_t vclzq_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vclz.i16 Q0, Q0'
+
+   * int8x16_t vclzq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vclz.i8 Q0, Q0'
+
+6.57.6.43 Count number of set bits
+..................................
+
+   * uint8x8_t vcnt_u8 (uint8x8_t)
+     _Form of expected instruction(s):_ 'vcnt.8 D0, D0'
+
+   * int8x8_t vcnt_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vcnt.8 D0, D0'
+
+   * poly8x8_t vcnt_p8 (poly8x8_t)
+     _Form of expected instruction(s):_ 'vcnt.8 D0, D0'
+
+   * uint8x16_t vcntq_u8 (uint8x16_t)
+     _Form of expected instruction(s):_ 'vcnt.8 Q0, Q0'
+
+   * int8x16_t vcntq_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vcnt.8 Q0, Q0'
+
+   * poly8x16_t vcntq_p8 (poly8x16_t)
+     _Form of expected instruction(s):_ 'vcnt.8 Q0, Q0'
+
+6.57.6.44 Reciprocal estimate
+.............................
+
+   * float32x2_t vrecpe_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vrecpe.f32 D0, D0'
+
+   * uint32x2_t vrecpe_u32 (uint32x2_t)
+     _Form of expected instruction(s):_ 'vrecpe.u32 D0, D0'
+
+   * float32x4_t vrecpeq_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vrecpe.f32 Q0, Q0'
+
+   * uint32x4_t vrecpeq_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vrecpe.u32 Q0, Q0'
+
+6.57.6.45 Reciprocal square-root estimate
+.........................................
+
+   * float32x2_t vrsqrte_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vrsqrte.f32 D0, D0'
+
+   * uint32x2_t vrsqrte_u32 (uint32x2_t)
+     _Form of expected instruction(s):_ 'vrsqrte.u32 D0, D0'
+
+   * float32x4_t vrsqrteq_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vrsqrte.f32 Q0, Q0'
+
+   * uint32x4_t vrsqrteq_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vrsqrte.u32 Q0, Q0'
+
+6.57.6.46 Get lanes from a vector
+.................................
+
+   * uint32_t vget_lane_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 R0, D0[0]'
+
+   * uint16_t vget_lane_u16 (uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.u16 R0, D0[0]'
+
+   * uint8_t vget_lane_u8 (uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.u8 R0, D0[0]'
+
+   * int32_t vget_lane_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 R0, D0[0]'
+
+   * int16_t vget_lane_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.s16 R0, D0[0]'
+
+   * int8_t vget_lane_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.s8 R0, D0[0]'
+
+   * float32_t vget_lane_f32 (float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 R0, D0[0]'
+
+   * poly16_t vget_lane_p16 (poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.u16 R0, D0[0]'
+
+   * poly8_t vget_lane_p8 (poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.u8 R0, D0[0]'
+
+   * uint64_t vget_lane_u64 (uint64x1_t, const int)
+
+   * int64_t vget_lane_s64 (int64x1_t, const int)
+
+   * uint32_t vgetq_lane_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 R0, D0[0]'
+
+   * uint16_t vgetq_lane_u16 (uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.u16 R0, D0[0]'
+
+   * uint8_t vgetq_lane_u8 (uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vmov.u8 R0, D0[0]'
+
+   * int32_t vgetq_lane_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 R0, D0[0]'
+
+   * int16_t vgetq_lane_s16 (int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.s16 R0, D0[0]'
+
+   * int8_t vgetq_lane_s8 (int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vmov.s8 R0, D0[0]'
+
+   * float32_t vgetq_lane_f32 (float32x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 R0, D0[0]'
+
+   * poly16_t vgetq_lane_p16 (poly16x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.u16 R0, D0[0]'
+
+   * poly8_t vgetq_lane_p8 (poly8x16_t, const int)
+     _Form of expected instruction(s):_ 'vmov.u8 R0, D0[0]'
+
+   * uint64_t vgetq_lane_u64 (uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov R0, R0, D0' _or_ 'fmrrd
+     R0, R0, D0'
+
+   * int64_t vgetq_lane_s64 (int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov R0, R0, D0' _or_ 'fmrrd
+     R0, R0, D0'
+
+6.57.6.47 Set lanes in a vector
+...............................
+
+   * uint32x2_t vset_lane_u32 (uint32_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 D0[0], R0'
+
+   * uint16x4_t vset_lane_u16 (uint16_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.16 D0[0], R0'
+
+   * uint8x8_t vset_lane_u8 (uint8_t, uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.8 D0[0], R0'
+
+   * int32x2_t vset_lane_s32 (int32_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 D0[0], R0'
+
+   * int16x4_t vset_lane_s16 (int16_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.16 D0[0], R0'
+
+   * int8x8_t vset_lane_s8 (int8_t, int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.8 D0[0], R0'
+
+   * float32x2_t vset_lane_f32 (float32_t, float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 D0[0], R0'
+
+   * poly16x4_t vset_lane_p16 (poly16_t, poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.16 D0[0], R0'
+
+   * poly8x8_t vset_lane_p8 (poly8_t, poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.8 D0[0], R0'
+
+   * uint64x1_t vset_lane_u64 (uint64_t, uint64x1_t, const int)
+
+   * int64x1_t vset_lane_s64 (int64_t, int64x1_t, const int)
+
+   * uint32x4_t vsetq_lane_u32 (uint32_t, uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 D0[0], R0'
+
+   * uint16x8_t vsetq_lane_u16 (uint16_t, uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.16 D0[0], R0'
+
+   * uint8x16_t vsetq_lane_u8 (uint8_t, uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vmov.8 D0[0], R0'
+
+   * int32x4_t vsetq_lane_s32 (int32_t, int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 D0[0], R0'
+
+   * int16x8_t vsetq_lane_s16 (int16_t, int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.16 D0[0], R0'
+
+   * int8x16_t vsetq_lane_s8 (int8_t, int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vmov.8 D0[0], R0'
+
+   * float32x4_t vsetq_lane_f32 (float32_t, float32x4_t, const int)
+     _Form of expected instruction(s):_ 'vmov.32 D0[0], R0'
+
+   * poly16x8_t vsetq_lane_p16 (poly16_t, poly16x8_t, const int)
+     _Form of expected instruction(s):_ 'vmov.16 D0[0], R0'
+
+   * poly8x16_t vsetq_lane_p8 (poly8_t, poly8x16_t, const int)
+     _Form of expected instruction(s):_ 'vmov.8 D0[0], R0'
+
+   * uint64x2_t vsetq_lane_u64 (uint64_t, uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov D0, R0, R0'
+
+   * int64x2_t vsetq_lane_s64 (int64_t, int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vmov D0, R0, R0'
+
+6.57.6.48 Create vector from literal bit pattern
+................................................
+
+   * poly64x1_t vcreate_p64 (uint64_t)
+
+   * uint32x2_t vcreate_u32 (uint64_t)
+
+   * uint16x4_t vcreate_u16 (uint64_t)
+
+   * uint8x8_t vcreate_u8 (uint64_t)
+
+   * int32x2_t vcreate_s32 (uint64_t)
+
+   * int16x4_t vcreate_s16 (uint64_t)
+
+   * int8x8_t vcreate_s8 (uint64_t)
+
+   * uint64x1_t vcreate_u64 (uint64_t)
+
+   * int64x1_t vcreate_s64 (uint64_t)
+
+   * float32x2_t vcreate_f32 (uint64_t)
+
+   * poly16x4_t vcreate_p16 (uint64_t)
+
+   * poly8x8_t vcreate_p8 (uint64_t)
+
+6.57.6.49 Set all lanes to the same value
+.........................................
+
+   * uint32x2_t vdup_n_u32 (uint32_t)
+     _Form of expected instruction(s):_ 'vdup.32 D0, R0'
+
+   * uint16x4_t vdup_n_u16 (uint16_t)
+     _Form of expected instruction(s):_ 'vdup.16 D0, R0'
+
+   * uint8x8_t vdup_n_u8 (uint8_t)
+     _Form of expected instruction(s):_ 'vdup.8 D0, R0'
+
+   * int32x2_t vdup_n_s32 (int32_t)
+     _Form of expected instruction(s):_ 'vdup.32 D0, R0'
+
+   * int16x4_t vdup_n_s16 (int16_t)
+     _Form of expected instruction(s):_ 'vdup.16 D0, R0'
+
+   * int8x8_t vdup_n_s8 (int8_t)
+     _Form of expected instruction(s):_ 'vdup.8 D0, R0'
+
+   * float32x2_t vdup_n_f32 (float32_t)
+     _Form of expected instruction(s):_ 'vdup.32 D0, R0'
+
+   * poly16x4_t vdup_n_p16 (poly16_t)
+     _Form of expected instruction(s):_ 'vdup.16 D0, R0'
+
+   * poly8x8_t vdup_n_p8 (poly8_t)
+     _Form of expected instruction(s):_ 'vdup.8 D0, R0'
+
+   * poly64x1_t vdup_n_p64 (poly64_t)
+
+   * uint64x1_t vdup_n_u64 (uint64_t)
+
+   * int64x1_t vdup_n_s64 (int64_t)
+
+   * poly64x2_t vdupq_n_p64 (poly64_t)
+
+   * uint32x4_t vdupq_n_u32 (uint32_t)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, R0'
+
+   * uint16x8_t vdupq_n_u16 (uint16_t)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, R0'
+
+   * uint8x16_t vdupq_n_u8 (uint8_t)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, R0'
+
+   * int32x4_t vdupq_n_s32 (int32_t)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, R0'
+
+   * int16x8_t vdupq_n_s16 (int16_t)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, R0'
+
+   * int8x16_t vdupq_n_s8 (int8_t)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, R0'
+
+   * float32x4_t vdupq_n_f32 (float32_t)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, R0'
+
+   * poly16x8_t vdupq_n_p16 (poly16_t)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, R0'
+
+   * poly8x16_t vdupq_n_p8 (poly8_t)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, R0'
+
+   * uint64x2_t vdupq_n_u64 (uint64_t)
+
+   * int64x2_t vdupq_n_s64 (int64_t)
+
+   * uint32x2_t vmov_n_u32 (uint32_t)
+     _Form of expected instruction(s):_ 'vdup.32 D0, R0'
+
+   * uint16x4_t vmov_n_u16 (uint16_t)
+     _Form of expected instruction(s):_ 'vdup.16 D0, R0'
+
+   * uint8x8_t vmov_n_u8 (uint8_t)
+     _Form of expected instruction(s):_ 'vdup.8 D0, R0'
+
+   * int32x2_t vmov_n_s32 (int32_t)
+     _Form of expected instruction(s):_ 'vdup.32 D0, R0'
+
+   * int16x4_t vmov_n_s16 (int16_t)
+     _Form of expected instruction(s):_ 'vdup.16 D0, R0'
+
+   * int8x8_t vmov_n_s8 (int8_t)
+     _Form of expected instruction(s):_ 'vdup.8 D0, R0'
+
+   * float32x2_t vmov_n_f32 (float32_t)
+     _Form of expected instruction(s):_ 'vdup.32 D0, R0'
+
+   * poly16x4_t vmov_n_p16 (poly16_t)
+     _Form of expected instruction(s):_ 'vdup.16 D0, R0'
+
+   * poly8x8_t vmov_n_p8 (poly8_t)
+     _Form of expected instruction(s):_ 'vdup.8 D0, R0'
+
+   * uint64x1_t vmov_n_u64 (uint64_t)
+
+   * int64x1_t vmov_n_s64 (int64_t)
+
+   * uint32x4_t vmovq_n_u32 (uint32_t)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, R0'
+
+   * uint16x8_t vmovq_n_u16 (uint16_t)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, R0'
+
+   * uint8x16_t vmovq_n_u8 (uint8_t)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, R0'
+
+   * int32x4_t vmovq_n_s32 (int32_t)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, R0'
+
+   * int16x8_t vmovq_n_s16 (int16_t)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, R0'
+
+   * int8x16_t vmovq_n_s8 (int8_t)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, R0'
+
+   * float32x4_t vmovq_n_f32 (float32_t)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, R0'
+
+   * poly16x8_t vmovq_n_p16 (poly16_t)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, R0'
+
+   * poly8x16_t vmovq_n_p8 (poly8_t)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, R0'
+
+   * uint64x2_t vmovq_n_u64 (uint64_t)
+
+   * int64x2_t vmovq_n_s64 (int64_t)
+
+   * uint32x2_t vdup_lane_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vdup.32 D0, D0[0]'
+
+   * uint16x4_t vdup_lane_u16 (uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vdup.16 D0, D0[0]'
+
+   * uint8x8_t vdup_lane_u8 (uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vdup.8 D0, D0[0]'
+
+   * int32x2_t vdup_lane_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vdup.32 D0, D0[0]'
+
+   * int16x4_t vdup_lane_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vdup.16 D0, D0[0]'
+
+   * int8x8_t vdup_lane_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vdup.8 D0, D0[0]'
+
+   * float32x2_t vdup_lane_f32 (float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vdup.32 D0, D0[0]'
+
+   * poly16x4_t vdup_lane_p16 (poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vdup.16 D0, D0[0]'
+
+   * poly8x8_t vdup_lane_p8 (poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vdup.8 D0, D0[0]'
+
+   * poly64x1_t vdup_lane_p64 (poly64x1_t, const int)
+
+   * uint64x1_t vdup_lane_u64 (uint64x1_t, const int)
+
+   * int64x1_t vdup_lane_s64 (int64x1_t, const int)
+
+   * uint32x4_t vdupq_lane_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, D0[0]'
+
+   * uint16x8_t vdupq_lane_u16 (uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, D0[0]'
+
+   * uint8x16_t vdupq_lane_u8 (uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, D0[0]'
+
+   * int32x4_t vdupq_lane_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, D0[0]'
+
+   * int16x8_t vdupq_lane_s16 (int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, D0[0]'
+
+   * int8x16_t vdupq_lane_s8 (int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, D0[0]'
+
+   * float32x4_t vdupq_lane_f32 (float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vdup.32 Q0, D0[0]'
+
+   * poly16x8_t vdupq_lane_p16 (poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vdup.16 Q0, D0[0]'
+
+   * poly8x16_t vdupq_lane_p8 (poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vdup.8 Q0, D0[0]'
+
+   * poly64x2_t vdupq_lane_p64 (poly64x1_t, const int)
+
+   * uint64x2_t vdupq_lane_u64 (uint64x1_t, const int)
+
+   * int64x2_t vdupq_lane_s64 (int64x1_t, const int)
+
+6.57.6.50 Combining vectors
+...........................
+
+   * poly64x2_t vcombine_p64 (poly64x1_t, poly64x1_t)
+
+   * uint32x4_t vcombine_u32 (uint32x2_t, uint32x2_t)
+
+   * uint16x8_t vcombine_u16 (uint16x4_t, uint16x4_t)
+
+   * uint8x16_t vcombine_u8 (uint8x8_t, uint8x8_t)
+
+   * int32x4_t vcombine_s32 (int32x2_t, int32x2_t)
+
+   * int16x8_t vcombine_s16 (int16x4_t, int16x4_t)
+
+   * int8x16_t vcombine_s8 (int8x8_t, int8x8_t)
+
+   * uint64x2_t vcombine_u64 (uint64x1_t, uint64x1_t)
+
+   * int64x2_t vcombine_s64 (int64x1_t, int64x1_t)
+
+   * float32x4_t vcombine_f32 (float32x2_t, float32x2_t)
+
+   * poly16x8_t vcombine_p16 (poly16x4_t, poly16x4_t)
+
+   * poly8x16_t vcombine_p8 (poly8x8_t, poly8x8_t)
+
+6.57.6.51 Splitting vectors
+...........................
+
+   * poly64x1_t vget_high_p64 (poly64x2_t)
+
+   * uint32x2_t vget_high_u32 (uint32x4_t)
+
+   * uint16x4_t vget_high_u16 (uint16x8_t)
+
+   * uint8x8_t vget_high_u8 (uint8x16_t)
+
+   * int32x2_t vget_high_s32 (int32x4_t)
+
+   * int16x4_t vget_high_s16 (int16x8_t)
+
+   * int8x8_t vget_high_s8 (int8x16_t)
+
+   * uint64x1_t vget_high_u64 (uint64x2_t)
+
+   * int64x1_t vget_high_s64 (int64x2_t)
+
+   * float32x2_t vget_high_f32 (float32x4_t)
+
+   * poly16x4_t vget_high_p16 (poly16x8_t)
+
+   * poly8x8_t vget_high_p8 (poly8x16_t)
+
+   * uint32x2_t vget_low_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * uint16x4_t vget_low_u16 (uint16x8_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * uint8x8_t vget_low_u8 (uint8x16_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * int32x2_t vget_low_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * int16x4_t vget_low_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * int8x8_t vget_low_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * float32x2_t vget_low_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * poly16x4_t vget_low_p16 (poly16x8_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * poly8x8_t vget_low_p8 (poly8x16_t)
+     _Form of expected instruction(s):_ 'vmov D0, D0'
+
+   * poly64x1_t vget_low_p64 (poly64x2_t)
+
+   * uint64x1_t vget_low_u64 (uint64x2_t)
+
+   * int64x1_t vget_low_s64 (int64x2_t)
+
+6.57.6.52 Conversions
+.....................
+
+   * float32x2_t vcvt_f32_u32 (uint32x2_t)
+     _Form of expected instruction(s):_ 'vcvt.f32.u32 D0, D0'
+
+   * float32x2_t vcvt_f32_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vcvt.f32.s32 D0, D0'
+
+   * uint32x2_t vcvt_u32_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vcvt.u32.f32 D0, D0'
+
+   * int32x2_t vcvt_s32_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vcvt.s32.f32 D0, D0'
+
+   * float32x4_t vcvtq_f32_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vcvt.f32.u32 Q0, Q0'
+
+   * float32x4_t vcvtq_f32_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vcvt.f32.s32 Q0, Q0'
+
+   * uint32x4_t vcvtq_u32_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vcvt.u32.f32 Q0, Q0'
+
+   * int32x4_t vcvtq_s32_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vcvt.s32.f32 Q0, Q0'
+
+   * float16x4_t vcvt_f16_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vcvt.f16.f32 D0, Q0'
+
+   * float32x4_t vcvt_f32_f16 (float16x4_t)
+     _Form of expected instruction(s):_ 'vcvt.f32.f16 Q0, D0'
+
+   * float32x2_t vcvt_n_f32_u32 (uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vcvt.f32.u32 D0, D0, #0'
+
+   * float32x2_t vcvt_n_f32_s32 (int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vcvt.f32.s32 D0, D0, #0'
+
+   * uint32x2_t vcvt_n_u32_f32 (float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vcvt.u32.f32 D0, D0, #0'
+
+   * int32x2_t vcvt_n_s32_f32 (float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vcvt.s32.f32 D0, D0, #0'
+
+   * float32x4_t vcvtq_n_f32_u32 (uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vcvt.f32.u32 Q0, Q0, #0'
+
+   * float32x4_t vcvtq_n_f32_s32 (int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vcvt.f32.s32 Q0, Q0, #0'
+
+   * uint32x4_t vcvtq_n_u32_f32 (float32x4_t, const int)
+     _Form of expected instruction(s):_ 'vcvt.u32.f32 Q0, Q0, #0'
+
+   * int32x4_t vcvtq_n_s32_f32 (float32x4_t, const int)
+     _Form of expected instruction(s):_ 'vcvt.s32.f32 Q0, Q0, #0'
+
+6.57.6.53 Move, single_opcode narrowing
+.......................................
+
+   * uint32x2_t vmovn_u64 (uint64x2_t)
+     _Form of expected instruction(s):_ 'vmovn.i64 D0, Q0'
+
+   * uint16x4_t vmovn_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vmovn.i32 D0, Q0'
+
+   * uint8x8_t vmovn_u16 (uint16x8_t)
+     _Form of expected instruction(s):_ 'vmovn.i16 D0, Q0'
+
+   * int32x2_t vmovn_s64 (int64x2_t)
+     _Form of expected instruction(s):_ 'vmovn.i64 D0, Q0'
+
+   * int16x4_t vmovn_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vmovn.i32 D0, Q0'
+
+   * int8x8_t vmovn_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vmovn.i16 D0, Q0'
+
+   * uint32x2_t vqmovn_u64 (uint64x2_t)
+     _Form of expected instruction(s):_ 'vqmovn.u64 D0, Q0'
+
+   * uint16x4_t vqmovn_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vqmovn.u32 D0, Q0'
+
+   * uint8x8_t vqmovn_u16 (uint16x8_t)
+     _Form of expected instruction(s):_ 'vqmovn.u16 D0, Q0'
+
+   * int32x2_t vqmovn_s64 (int64x2_t)
+     _Form of expected instruction(s):_ 'vqmovn.s64 D0, Q0'
+
+   * int16x4_t vqmovn_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vqmovn.s32 D0, Q0'
+
+   * int8x8_t vqmovn_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vqmovn.s16 D0, Q0'
+
+   * uint32x2_t vqmovun_s64 (int64x2_t)
+     _Form of expected instruction(s):_ 'vqmovun.s64 D0, Q0'
+
+   * uint16x4_t vqmovun_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vqmovun.s32 D0, Q0'
+
+   * uint8x8_t vqmovun_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vqmovun.s16 D0, Q0'
+
+6.57.6.54 Move, single_opcode long
+..................................
+
+   * uint64x2_t vmovl_u32 (uint32x2_t)
+     _Form of expected instruction(s):_ 'vmovl.u32 Q0, D0'
+
+   * uint32x4_t vmovl_u16 (uint16x4_t)
+     _Form of expected instruction(s):_ 'vmovl.u16 Q0, D0'
+
+   * uint16x8_t vmovl_u8 (uint8x8_t)
+     _Form of expected instruction(s):_ 'vmovl.u8 Q0, D0'
+
+   * int64x2_t vmovl_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vmovl.s32 Q0, D0'
+
+   * int32x4_t vmovl_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vmovl.s16 Q0, D0'
+
+   * int16x8_t vmovl_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vmovl.s8 Q0, D0'
+
+6.57.6.55 Table lookup
+......................
+
+   * poly8x8_t vtbl1_p8 (poly8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0}, D0'
+
+   * int8x8_t vtbl1_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0}, D0'
+
+   * uint8x8_t vtbl1_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0}, D0'
+
+   * poly8x8_t vtbl2_p8 (poly8x8x2_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1}, D0'
+
+   * int8x8_t vtbl2_s8 (int8x8x2_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1}, D0'
+
+   * uint8x8_t vtbl2_u8 (uint8x8x2_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1}, D0'
+
+   * poly8x8_t vtbl3_p8 (poly8x8x3_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1, D2}, D0'
+
+   * int8x8_t vtbl3_s8 (int8x8x3_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1, D2}, D0'
+
+   * uint8x8_t vtbl3_u8 (uint8x8x3_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1, D2}, D0'
+
+   * poly8x8_t vtbl4_p8 (poly8x8x4_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1, D2, D3},
+     D0'
+
+   * int8x8_t vtbl4_s8 (int8x8x4_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1, D2, D3},
+     D0'
+
+   * uint8x8_t vtbl4_u8 (uint8x8x4_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbl.8 D0, {D0, D1, D2, D3},
+     D0'
+
+6.57.6.56 Extended table lookup
+...............................
+
+   * poly8x8_t vtbx1_p8 (poly8x8_t, poly8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0}, D0'
+
+   * int8x8_t vtbx1_s8 (int8x8_t, int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0}, D0'
+
+   * uint8x8_t vtbx1_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0}, D0'
+
+   * poly8x8_t vtbx2_p8 (poly8x8_t, poly8x8x2_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1}, D0'
+
+   * int8x8_t vtbx2_s8 (int8x8_t, int8x8x2_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1}, D0'
+
+   * uint8x8_t vtbx2_u8 (uint8x8_t, uint8x8x2_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1}, D0'
+
+   * poly8x8_t vtbx3_p8 (poly8x8_t, poly8x8x3_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1, D2}, D0'
+
+   * int8x8_t vtbx3_s8 (int8x8_t, int8x8x3_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1, D2}, D0'
+
+   * uint8x8_t vtbx3_u8 (uint8x8_t, uint8x8x3_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1, D2}, D0'
+
+   * poly8x8_t vtbx4_p8 (poly8x8_t, poly8x8x4_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1, D2, D3},
+     D0'
+
+   * int8x8_t vtbx4_s8 (int8x8_t, int8x8x4_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1, D2, D3},
+     D0'
+
+   * uint8x8_t vtbx4_u8 (uint8x8_t, uint8x8x4_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtbx.8 D0, {D0, D1, D2, D3},
+     D0'
+
+6.57.6.57 Multiply, lane
+........................
+
+   * float32x2_t vmul_lane_f32 (float32x2_t, float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmul.f32 D0, D0, D0[0]'
+
+   * uint32x2_t vmul_lane_u32 (uint32x2_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmul.i32 D0, D0, D0[0]'
+
+   * uint16x4_t vmul_lane_u16 (uint16x4_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmul.i16 D0, D0, D0[0]'
+
+   * int32x2_t vmul_lane_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmul.i32 D0, D0, D0[0]'
+
+   * int16x4_t vmul_lane_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmul.i16 D0, D0, D0[0]'
+
+   * float32x4_t vmulq_lane_f32 (float32x4_t, float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmul.f32 Q0, Q0, D0[0]'
+
+   * uint32x4_t vmulq_lane_u32 (uint32x4_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmul.i32 Q0, Q0, D0[0]'
+
+   * uint16x8_t vmulq_lane_u16 (uint16x8_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmul.i16 Q0, Q0, D0[0]'
+
+   * int32x4_t vmulq_lane_s32 (int32x4_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmul.i32 Q0, Q0, D0[0]'
+
+   * int16x8_t vmulq_lane_s16 (int16x8_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmul.i16 Q0, Q0, D0[0]'
+
+6.57.6.58 Long multiply, lane
+.............................
+
+   * uint64x2_t vmull_lane_u32 (uint32x2_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmull.u32 Q0, D0, D0[0]'
+
+   * uint32x4_t vmull_lane_u16 (uint16x4_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmull.u16 Q0, D0, D0[0]'
+
+   * int64x2_t vmull_lane_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vmull.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vmull_lane_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vmull.s16 Q0, D0, D0[0]'
+
+6.57.6.59 Saturating doubling long multiply, lane
+.................................................
+
+   * int64x2_t vqdmull_lane_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vqdmull.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vqdmull_lane_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vqdmull.s16 Q0, D0, D0[0]'
+
+6.57.6.60 Saturating doubling multiply high, lane
+.................................................
+
+   * int32x4_t vqdmulhq_lane_s32 (int32x4_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vqdmulh.s32 Q0, Q0, D0[0]'
+
+   * int16x8_t vqdmulhq_lane_s16 (int16x8_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vqdmulh.s16 Q0, Q0, D0[0]'
+
+   * int32x2_t vqdmulh_lane_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vqdmulh.s32 D0, D0, D0[0]'
+
+   * int16x4_t vqdmulh_lane_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vqdmulh.s16 D0, D0, D0[0]'
+
+   * int32x4_t vqrdmulhq_lane_s32 (int32x4_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vqrdmulh.s32 Q0, Q0, D0[0]'
+
+   * int16x8_t vqrdmulhq_lane_s16 (int16x8_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vqrdmulh.s16 Q0, Q0, D0[0]'
+
+   * int32x2_t vqrdmulh_lane_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vqrdmulh.s32 D0, D0, D0[0]'
+
+   * int16x4_t vqrdmulh_lane_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vqrdmulh.s16 D0, D0, D0[0]'
+
+6.57.6.61 Multiply-accumulate, lane
+...................................
+
+   * float32x2_t vmla_lane_f32 (float32x2_t, float32x2_t, float32x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmla.f32 D0, D0, D0[0]'
+
+   * uint32x2_t vmla_lane_u32 (uint32x2_t, uint32x2_t, uint32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmla.i32 D0, D0, D0[0]'
+
+   * uint16x4_t vmla_lane_u16 (uint16x4_t, uint16x4_t, uint16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmla.i16 D0, D0, D0[0]'
+
+   * int32x2_t vmla_lane_s32 (int32x2_t, int32x2_t, int32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmla.i32 D0, D0, D0[0]'
+
+   * int16x4_t vmla_lane_s16 (int16x4_t, int16x4_t, int16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmla.i16 D0, D0, D0[0]'
+
+   * float32x4_t vmlaq_lane_f32 (float32x4_t, float32x4_t, float32x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmla.f32 Q0, Q0, D0[0]'
+
+   * uint32x4_t vmlaq_lane_u32 (uint32x4_t, uint32x4_t, uint32x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmla.i32 Q0, Q0, D0[0]'
+
+   * uint16x8_t vmlaq_lane_u16 (uint16x8_t, uint16x8_t, uint16x4_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmla.i16 Q0, Q0, D0[0]'
+
+   * int32x4_t vmlaq_lane_s32 (int32x4_t, int32x4_t, int32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmla.i32 Q0, Q0, D0[0]'
+
+   * int16x8_t vmlaq_lane_s16 (int16x8_t, int16x8_t, int16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmla.i16 Q0, Q0, D0[0]'
+
+   * uint64x2_t vmlal_lane_u32 (uint64x2_t, uint32x2_t, uint32x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmlal.u32 Q0, D0, D0[0]'
+
+   * uint32x4_t vmlal_lane_u16 (uint32x4_t, uint16x4_t, uint16x4_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmlal.u16 Q0, D0, D0[0]'
+
+   * int64x2_t vmlal_lane_s32 (int64x2_t, int32x2_t, int32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmlal.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vmlal_lane_s16 (int32x4_t, int16x4_t, int16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmlal.s16 Q0, D0, D0[0]'
+
+   * int64x2_t vqdmlal_lane_s32 (int64x2_t, int32x2_t, int32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vqdmlal.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vqdmlal_lane_s16 (int32x4_t, int16x4_t, int16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vqdmlal.s16 Q0, D0, D0[0]'
+
+6.57.6.62 Multiply-subtract, lane
+.................................
+
+   * float32x2_t vmls_lane_f32 (float32x2_t, float32x2_t, float32x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmls.f32 D0, D0, D0[0]'
+
+   * uint32x2_t vmls_lane_u32 (uint32x2_t, uint32x2_t, uint32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmls.i32 D0, D0, D0[0]'
+
+   * uint16x4_t vmls_lane_u16 (uint16x4_t, uint16x4_t, uint16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmls.i16 D0, D0, D0[0]'
+
+   * int32x2_t vmls_lane_s32 (int32x2_t, int32x2_t, int32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmls.i32 D0, D0, D0[0]'
+
+   * int16x4_t vmls_lane_s16 (int16x4_t, int16x4_t, int16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmls.i16 D0, D0, D0[0]'
+
+   * float32x4_t vmlsq_lane_f32 (float32x4_t, float32x4_t, float32x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmls.f32 Q0, Q0, D0[0]'
+
+   * uint32x4_t vmlsq_lane_u32 (uint32x4_t, uint32x4_t, uint32x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmls.i32 Q0, Q0, D0[0]'
+
+   * uint16x8_t vmlsq_lane_u16 (uint16x8_t, uint16x8_t, uint16x4_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmls.i16 Q0, Q0, D0[0]'
+
+   * int32x4_t vmlsq_lane_s32 (int32x4_t, int32x4_t, int32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmls.i32 Q0, Q0, D0[0]'
+
+   * int16x8_t vmlsq_lane_s16 (int16x8_t, int16x8_t, int16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmls.i16 Q0, Q0, D0[0]'
+
+   * uint64x2_t vmlsl_lane_u32 (uint64x2_t, uint32x2_t, uint32x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmlsl.u32 Q0, D0, D0[0]'
+
+   * uint32x4_t vmlsl_lane_u16 (uint32x4_t, uint16x4_t, uint16x4_t,
+     const int)
+     _Form of expected instruction(s):_ 'vmlsl.u16 Q0, D0, D0[0]'
+
+   * int64x2_t vmlsl_lane_s32 (int64x2_t, int32x2_t, int32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmlsl.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vmlsl_lane_s16 (int32x4_t, int16x4_t, int16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vmlsl.s16 Q0, D0, D0[0]'
+
+   * int64x2_t vqdmlsl_lane_s32 (int64x2_t, int32x2_t, int32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vqdmlsl.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vqdmlsl_lane_s16 (int32x4_t, int16x4_t, int16x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vqdmlsl.s16 Q0, D0, D0[0]'
+
+6.57.6.63 Vector multiply by scalar
+...................................
+
+   * float32x2_t vmul_n_f32 (float32x2_t, float32_t)
+     _Form of expected instruction(s):_ 'vmul.f32 D0, D0, D0[0]'
+
+   * uint32x2_t vmul_n_u32 (uint32x2_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmul.i32 D0, D0, D0[0]'
+
+   * uint16x4_t vmul_n_u16 (uint16x4_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmul.i16 D0, D0, D0[0]'
+
+   * int32x2_t vmul_n_s32 (int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vmul.i32 D0, D0, D0[0]'
+
+   * int16x4_t vmul_n_s16 (int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vmul.i16 D0, D0, D0[0]'
+
+   * float32x4_t vmulq_n_f32 (float32x4_t, float32_t)
+     _Form of expected instruction(s):_ 'vmul.f32 Q0, Q0, D0[0]'
+
+   * uint32x4_t vmulq_n_u32 (uint32x4_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmul.i32 Q0, Q0, D0[0]'
+
+   * uint16x8_t vmulq_n_u16 (uint16x8_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmul.i16 Q0, Q0, D0[0]'
+
+   * int32x4_t vmulq_n_s32 (int32x4_t, int32_t)
+     _Form of expected instruction(s):_ 'vmul.i32 Q0, Q0, D0[0]'
+
+   * int16x8_t vmulq_n_s16 (int16x8_t, int16_t)
+     _Form of expected instruction(s):_ 'vmul.i16 Q0, Q0, D0[0]'
+
+6.57.6.64 Vector long multiply by scalar
+........................................
+
+   * uint64x2_t vmull_n_u32 (uint32x2_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmull.u32 Q0, D0, D0[0]'
+
+   * uint32x4_t vmull_n_u16 (uint16x4_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmull.u16 Q0, D0, D0[0]'
+
+   * int64x2_t vmull_n_s32 (int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vmull.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vmull_n_s16 (int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vmull.s16 Q0, D0, D0[0]'
+
+6.57.6.65 Vector saturating doubling long multiply by scalar
+............................................................
+
+   * int64x2_t vqdmull_n_s32 (int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vqdmull.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vqdmull_n_s16 (int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vqdmull.s16 Q0, D0, D0[0]'
+
+6.57.6.66 Vector saturating doubling multiply high by scalar
+............................................................
+
+   * int32x4_t vqdmulhq_n_s32 (int32x4_t, int32_t)
+     _Form of expected instruction(s):_ 'vqdmulh.s32 Q0, Q0, D0[0]'
+
+   * int16x8_t vqdmulhq_n_s16 (int16x8_t, int16_t)
+     _Form of expected instruction(s):_ 'vqdmulh.s16 Q0, Q0, D0[0]'
+
+   * int32x2_t vqdmulh_n_s32 (int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vqdmulh.s32 D0, D0, D0[0]'
+
+   * int16x4_t vqdmulh_n_s16 (int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vqdmulh.s16 D0, D0, D0[0]'
+
+   * int32x4_t vqrdmulhq_n_s32 (int32x4_t, int32_t)
+     _Form of expected instruction(s):_ 'vqrdmulh.s32 Q0, Q0, D0[0]'
+
+   * int16x8_t vqrdmulhq_n_s16 (int16x8_t, int16_t)
+     _Form of expected instruction(s):_ 'vqrdmulh.s16 Q0, Q0, D0[0]'
+
+   * int32x2_t vqrdmulh_n_s32 (int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vqrdmulh.s32 D0, D0, D0[0]'
+
+   * int16x4_t vqrdmulh_n_s16 (int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vqrdmulh.s16 D0, D0, D0[0]'
+
+6.57.6.67 Vector multiply-accumulate by scalar
+..............................................
+
+   * float32x2_t vmla_n_f32 (float32x2_t, float32x2_t, float32_t)
+     _Form of expected instruction(s):_ 'vmla.f32 D0, D0, D0[0]'
+
+   * uint32x2_t vmla_n_u32 (uint32x2_t, uint32x2_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmla.i32 D0, D0, D0[0]'
+
+   * uint16x4_t vmla_n_u16 (uint16x4_t, uint16x4_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmla.i16 D0, D0, D0[0]'
+
+   * int32x2_t vmla_n_s32 (int32x2_t, int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vmla.i32 D0, D0, D0[0]'
+
+   * int16x4_t vmla_n_s16 (int16x4_t, int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vmla.i16 D0, D0, D0[0]'
+
+   * float32x4_t vmlaq_n_f32 (float32x4_t, float32x4_t, float32_t)
+     _Form of expected instruction(s):_ 'vmla.f32 Q0, Q0, D0[0]'
+
+   * uint32x4_t vmlaq_n_u32 (uint32x4_t, uint32x4_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmla.i32 Q0, Q0, D0[0]'
+
+   * uint16x8_t vmlaq_n_u16 (uint16x8_t, uint16x8_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmla.i16 Q0, Q0, D0[0]'
+
+   * int32x4_t vmlaq_n_s32 (int32x4_t, int32x4_t, int32_t)
+     _Form of expected instruction(s):_ 'vmla.i32 Q0, Q0, D0[0]'
+
+   * int16x8_t vmlaq_n_s16 (int16x8_t, int16x8_t, int16_t)
+     _Form of expected instruction(s):_ 'vmla.i16 Q0, Q0, D0[0]'
+
+   * uint64x2_t vmlal_n_u32 (uint64x2_t, uint32x2_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmlal.u32 Q0, D0, D0[0]'
+
+   * uint32x4_t vmlal_n_u16 (uint32x4_t, uint16x4_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmlal.u16 Q0, D0, D0[0]'
+
+   * int64x2_t vmlal_n_s32 (int64x2_t, int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vmlal.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vmlal_n_s16 (int32x4_t, int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vmlal.s16 Q0, D0, D0[0]'
+
+   * int64x2_t vqdmlal_n_s32 (int64x2_t, int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vqdmlal.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vqdmlal_n_s16 (int32x4_t, int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vqdmlal.s16 Q0, D0, D0[0]'
+
+6.57.6.68 Vector multiply-subtract by scalar
+............................................
+
+   * float32x2_t vmls_n_f32 (float32x2_t, float32x2_t, float32_t)
+     _Form of expected instruction(s):_ 'vmls.f32 D0, D0, D0[0]'
+
+   * uint32x2_t vmls_n_u32 (uint32x2_t, uint32x2_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmls.i32 D0, D0, D0[0]'
+
+   * uint16x4_t vmls_n_u16 (uint16x4_t, uint16x4_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmls.i16 D0, D0, D0[0]'
+
+   * int32x2_t vmls_n_s32 (int32x2_t, int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vmls.i32 D0, D0, D0[0]'
+
+   * int16x4_t vmls_n_s16 (int16x4_t, int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vmls.i16 D0, D0, D0[0]'
+
+   * float32x4_t vmlsq_n_f32 (float32x4_t, float32x4_t, float32_t)
+     _Form of expected instruction(s):_ 'vmls.f32 Q0, Q0, D0[0]'
+
+   * uint32x4_t vmlsq_n_u32 (uint32x4_t, uint32x4_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmls.i32 Q0, Q0, D0[0]'
+
+   * uint16x8_t vmlsq_n_u16 (uint16x8_t, uint16x8_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmls.i16 Q0, Q0, D0[0]'
+
+   * int32x4_t vmlsq_n_s32 (int32x4_t, int32x4_t, int32_t)
+     _Form of expected instruction(s):_ 'vmls.i32 Q0, Q0, D0[0]'
+
+   * int16x8_t vmlsq_n_s16 (int16x8_t, int16x8_t, int16_t)
+     _Form of expected instruction(s):_ 'vmls.i16 Q0, Q0, D0[0]'
+
+   * uint64x2_t vmlsl_n_u32 (uint64x2_t, uint32x2_t, uint32_t)
+     _Form of expected instruction(s):_ 'vmlsl.u32 Q0, D0, D0[0]'
+
+   * uint32x4_t vmlsl_n_u16 (uint32x4_t, uint16x4_t, uint16_t)
+     _Form of expected instruction(s):_ 'vmlsl.u16 Q0, D0, D0[0]'
+
+   * int64x2_t vmlsl_n_s32 (int64x2_t, int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vmlsl.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vmlsl_n_s16 (int32x4_t, int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vmlsl.s16 Q0, D0, D0[0]'
+
+   * int64x2_t vqdmlsl_n_s32 (int64x2_t, int32x2_t, int32_t)
+     _Form of expected instruction(s):_ 'vqdmlsl.s32 Q0, D0, D0[0]'
+
+   * int32x4_t vqdmlsl_n_s16 (int32x4_t, int16x4_t, int16_t)
+     _Form of expected instruction(s):_ 'vqdmlsl.s16 Q0, D0, D0[0]'
+
+6.57.6.69 Vector extract
+........................
+
+   * poly64x1_t vext_p64 (poly64x1_t, poly64x1_t, const int)
+     _Form of expected instruction(s):_ 'vext.64 D0, D0, D0, #0'
+
+   * uint32x2_t vext_u32 (uint32x2_t, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vext.32 D0, D0, D0, #0'
+
+   * uint16x4_t vext_u16 (uint16x4_t, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vext.16 D0, D0, D0, #0'
+
+   * uint8x8_t vext_u8 (uint8x8_t, uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vext.8 D0, D0, D0, #0'
+
+   * int32x2_t vext_s32 (int32x2_t, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vext.32 D0, D0, D0, #0'
+
+   * int16x4_t vext_s16 (int16x4_t, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vext.16 D0, D0, D0, #0'
+
+   * int8x8_t vext_s8 (int8x8_t, int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vext.8 D0, D0, D0, #0'
+
+   * uint64x1_t vext_u64 (uint64x1_t, uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vext.64 D0, D0, D0, #0'
+
+   * int64x1_t vext_s64 (int64x1_t, int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vext.64 D0, D0, D0, #0'
+
+   * float32x2_t vext_f32 (float32x2_t, float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vext.32 D0, D0, D0, #0'
+
+   * poly16x4_t vext_p16 (poly16x4_t, poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vext.16 D0, D0, D0, #0'
+
+   * poly8x8_t vext_p8 (poly8x8_t, poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vext.8 D0, D0, D0, #0'
+
+   * poly64x2_t vextq_p64 (poly64x2_t, poly64x2_t, const int)
+     _Form of expected instruction(s):_ 'vext.64 Q0, Q0, Q0, #0'
+
+   * uint32x4_t vextq_u32 (uint32x4_t, uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vext.32 Q0, Q0, Q0, #0'
+
+   * uint16x8_t vextq_u16 (uint16x8_t, uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vext.16 Q0, Q0, Q0, #0'
+
+   * uint8x16_t vextq_u8 (uint8x16_t, uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vext.8 Q0, Q0, Q0, #0'
+
+   * int32x4_t vextq_s32 (int32x4_t, int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vext.32 Q0, Q0, Q0, #0'
+
+   * int16x8_t vextq_s16 (int16x8_t, int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vext.16 Q0, Q0, Q0, #0'
+
+   * int8x16_t vextq_s8 (int8x16_t, int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vext.8 Q0, Q0, Q0, #0'
+
+   * uint64x2_t vextq_u64 (uint64x2_t, uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vext.64 Q0, Q0, Q0, #0'
+
+   * int64x2_t vextq_s64 (int64x2_t, int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vext.64 Q0, Q0, Q0, #0'
+
+   * float32x4_t vextq_f32 (float32x4_t, float32x4_t, const int)
+     _Form of expected instruction(s):_ 'vext.32 Q0, Q0, Q0, #0'
+
+   * poly16x8_t vextq_p16 (poly16x8_t, poly16x8_t, const int)
+     _Form of expected instruction(s):_ 'vext.16 Q0, Q0, Q0, #0'
+
+   * poly8x16_t vextq_p8 (poly8x16_t, poly8x16_t, const int)
+     _Form of expected instruction(s):_ 'vext.8 Q0, Q0, Q0, #0'
+
+6.57.6.70 Reverse elements
+..........................
+
+   * uint32x2_t vrev64_u32 (uint32x2_t)
+     _Form of expected instruction(s):_ 'vrev64.32 D0, D0'
+
+   * uint16x4_t vrev64_u16 (uint16x4_t)
+     _Form of expected instruction(s):_ 'vrev64.16 D0, D0'
+
+   * uint8x8_t vrev64_u8 (uint8x8_t)
+     _Form of expected instruction(s):_ 'vrev64.8 D0, D0'
+
+   * int32x2_t vrev64_s32 (int32x2_t)
+     _Form of expected instruction(s):_ 'vrev64.32 D0, D0'
+
+   * int16x4_t vrev64_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vrev64.16 D0, D0'
+
+   * int8x8_t vrev64_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vrev64.8 D0, D0'
+
+   * float32x2_t vrev64_f32 (float32x2_t)
+     _Form of expected instruction(s):_ 'vrev64.32 D0, D0'
+
+   * poly16x4_t vrev64_p16 (poly16x4_t)
+     _Form of expected instruction(s):_ 'vrev64.16 D0, D0'
+
+   * poly8x8_t vrev64_p8 (poly8x8_t)
+     _Form of expected instruction(s):_ 'vrev64.8 D0, D0'
+
+   * uint32x4_t vrev64q_u32 (uint32x4_t)
+     _Form of expected instruction(s):_ 'vrev64.32 Q0, Q0'
+
+   * uint16x8_t vrev64q_u16 (uint16x8_t)
+     _Form of expected instruction(s):_ 'vrev64.16 Q0, Q0'
+
+   * uint8x16_t vrev64q_u8 (uint8x16_t)
+     _Form of expected instruction(s):_ 'vrev64.8 Q0, Q0'
+
+   * int32x4_t vrev64q_s32 (int32x4_t)
+     _Form of expected instruction(s):_ 'vrev64.32 Q0, Q0'
+
+   * int16x8_t vrev64q_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vrev64.16 Q0, Q0'
+
+   * int8x16_t vrev64q_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vrev64.8 Q0, Q0'
+
+   * float32x4_t vrev64q_f32 (float32x4_t)
+     _Form of expected instruction(s):_ 'vrev64.32 Q0, Q0'
+
+   * poly16x8_t vrev64q_p16 (poly16x8_t)
+     _Form of expected instruction(s):_ 'vrev64.16 Q0, Q0'
+
+   * poly8x16_t vrev64q_p8 (poly8x16_t)
+     _Form of expected instruction(s):_ 'vrev64.8 Q0, Q0'
+
+   * uint16x4_t vrev32_u16 (uint16x4_t)
+     _Form of expected instruction(s):_ 'vrev32.16 D0, D0'
+
+   * int16x4_t vrev32_s16 (int16x4_t)
+     _Form of expected instruction(s):_ 'vrev32.16 D0, D0'
+
+   * uint8x8_t vrev32_u8 (uint8x8_t)
+     _Form of expected instruction(s):_ 'vrev32.8 D0, D0'
+
+   * int8x8_t vrev32_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vrev32.8 D0, D0'
+
+   * poly16x4_t vrev32_p16 (poly16x4_t)
+     _Form of expected instruction(s):_ 'vrev32.16 D0, D0'
+
+   * poly8x8_t vrev32_p8 (poly8x8_t)
+     _Form of expected instruction(s):_ 'vrev32.8 D0, D0'
+
+   * uint16x8_t vrev32q_u16 (uint16x8_t)
+     _Form of expected instruction(s):_ 'vrev32.16 Q0, Q0'
+
+   * int16x8_t vrev32q_s16 (int16x8_t)
+     _Form of expected instruction(s):_ 'vrev32.16 Q0, Q0'
+
+   * uint8x16_t vrev32q_u8 (uint8x16_t)
+     _Form of expected instruction(s):_ 'vrev32.8 Q0, Q0'
+
+   * int8x16_t vrev32q_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vrev32.8 Q0, Q0'
+
+   * poly16x8_t vrev32q_p16 (poly16x8_t)
+     _Form of expected instruction(s):_ 'vrev32.16 Q0, Q0'
+
+   * poly8x16_t vrev32q_p8 (poly8x16_t)
+     _Form of expected instruction(s):_ 'vrev32.8 Q0, Q0'
+
+   * uint8x8_t vrev16_u8 (uint8x8_t)
+     _Form of expected instruction(s):_ 'vrev16.8 D0, D0'
+
+   * int8x8_t vrev16_s8 (int8x8_t)
+     _Form of expected instruction(s):_ 'vrev16.8 D0, D0'
+
+   * poly8x8_t vrev16_p8 (poly8x8_t)
+     _Form of expected instruction(s):_ 'vrev16.8 D0, D0'
+
+   * uint8x16_t vrev16q_u8 (uint8x16_t)
+     _Form of expected instruction(s):_ 'vrev16.8 Q0, Q0'
+
+   * int8x16_t vrev16q_s8 (int8x16_t)
+     _Form of expected instruction(s):_ 'vrev16.8 Q0, Q0'
+
+   * poly8x16_t vrev16q_p8 (poly8x16_t)
+     _Form of expected instruction(s):_ 'vrev16.8 Q0, Q0'
+
+6.57.6.71 Bit selection
+.......................
+
+   * poly64x1_t vbsl_p64 (uint64x1_t, poly64x1_t, poly64x1_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * uint32x2_t vbsl_u32 (uint32x2_t, uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * uint16x4_t vbsl_u16 (uint16x4_t, uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * uint8x8_t vbsl_u8 (uint8x8_t, uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * int32x2_t vbsl_s32 (uint32x2_t, int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * int16x4_t vbsl_s16 (uint16x4_t, int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * int8x8_t vbsl_s8 (uint8x8_t, int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * uint64x1_t vbsl_u64 (uint64x1_t, uint64x1_t, uint64x1_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * int64x1_t vbsl_s64 (uint64x1_t, int64x1_t, int64x1_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * float32x2_t vbsl_f32 (uint32x2_t, float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * poly16x4_t vbsl_p16 (uint16x4_t, poly16x4_t, poly16x4_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * poly8x8_t vbsl_p8 (uint8x8_t, poly8x8_t, poly8x8_t)
+     _Form of expected instruction(s):_ 'vbsl D0, D0, D0' _or_ 'vbit D0,
+     D0, D0' _or_ 'vbif D0, D0, D0'
+
+   * poly64x2_t vbslq_p64 (uint64x2_t, poly64x2_t, poly64x2_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * uint32x4_t vbslq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * uint16x8_t vbslq_u16 (uint16x8_t, uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * uint8x16_t vbslq_u8 (uint8x16_t, uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * int32x4_t vbslq_s32 (uint32x4_t, int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * int16x8_t vbslq_s16 (uint16x8_t, int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * int8x16_t vbslq_s8 (uint8x16_t, int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * uint64x2_t vbslq_u64 (uint64x2_t, uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * int64x2_t vbslq_s64 (uint64x2_t, int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * float32x4_t vbslq_f32 (uint32x4_t, float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * poly16x8_t vbslq_p16 (uint16x8_t, poly16x8_t, poly16x8_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+   * poly8x16_t vbslq_p8 (uint8x16_t, poly8x16_t, poly8x16_t)
+     _Form of expected instruction(s):_ 'vbsl Q0, Q0, Q0' _or_ 'vbit Q0,
+     Q0, Q0' _or_ 'vbif Q0, Q0, Q0'
+
+6.57.6.72 Transpose elements
+............................
+
+   * uint16x4x2_t vtrn_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vtrn.16 D0, D1'
+
+   * uint8x8x2_t vtrn_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vtrn.8 D0, D1'
+
+   * int16x4x2_t vtrn_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vtrn.16 D0, D1'
+
+   * int8x8x2_t vtrn_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vtrn.8 D0, D1'
+
+   * poly16x4x2_t vtrn_p16 (poly16x4_t, poly16x4_t)
+     _Form of expected instruction(s):_ 'vtrn.16 D0, D1'
+
+   * poly8x8x2_t vtrn_p8 (poly8x8_t, poly8x8_t)
+     _Form of expected instruction(s):_ 'vtrn.8 D0, D1'
+
+   * float32x2x2_t vtrn_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * uint32x2x2_t vtrn_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * int32x2x2_t vtrn_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * uint32x4x2_t vtrnq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vtrn.32 Q0, Q1'
+
+   * uint16x8x2_t vtrnq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vtrn.16 Q0, Q1'
+
+   * uint8x16x2_t vtrnq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vtrn.8 Q0, Q1'
+
+   * int32x4x2_t vtrnq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vtrn.32 Q0, Q1'
+
+   * int16x8x2_t vtrnq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vtrn.16 Q0, Q1'
+
+   * int8x16x2_t vtrnq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vtrn.8 Q0, Q1'
+
+   * float32x4x2_t vtrnq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vtrn.32 Q0, Q1'
+
+   * poly16x8x2_t vtrnq_p16 (poly16x8_t, poly16x8_t)
+     _Form of expected instruction(s):_ 'vtrn.16 Q0, Q1'
+
+   * poly8x16x2_t vtrnq_p8 (poly8x16_t, poly8x16_t)
+     _Form of expected instruction(s):_ 'vtrn.8 Q0, Q1'
+
+6.57.6.73 Zip elements
+......................
+
+   * uint16x4x2_t vzip_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vzip.16 D0, D1'
+
+   * uint8x8x2_t vzip_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vzip.8 D0, D1'
+
+   * int16x4x2_t vzip_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vzip.16 D0, D1'
+
+   * int8x8x2_t vzip_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vzip.8 D0, D1'
+
+   * poly16x4x2_t vzip_p16 (poly16x4_t, poly16x4_t)
+     _Form of expected instruction(s):_ 'vzip.16 D0, D1'
+
+   * poly8x8x2_t vzip_p8 (poly8x8_t, poly8x8_t)
+     _Form of expected instruction(s):_ 'vzip.8 D0, D1'
+
+   * float32x2x2_t vzip_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * uint32x2x2_t vzip_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * int32x2x2_t vzip_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * uint32x4x2_t vzipq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vzip.32 Q0, Q1'
+
+   * uint16x8x2_t vzipq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vzip.16 Q0, Q1'
+
+   * uint8x16x2_t vzipq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vzip.8 Q0, Q1'
+
+   * int32x4x2_t vzipq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vzip.32 Q0, Q1'
+
+   * int16x8x2_t vzipq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vzip.16 Q0, Q1'
+
+   * int8x16x2_t vzipq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vzip.8 Q0, Q1'
+
+   * float32x4x2_t vzipq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vzip.32 Q0, Q1'
+
+   * poly16x8x2_t vzipq_p16 (poly16x8_t, poly16x8_t)
+     _Form of expected instruction(s):_ 'vzip.16 Q0, Q1'
+
+   * poly8x16x2_t vzipq_p8 (poly8x16_t, poly8x16_t)
+     _Form of expected instruction(s):_ 'vzip.8 Q0, Q1'
+
+6.57.6.74 Unzip elements
+........................
+
+   * uint32x2x2_t vuzp_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * uint16x4x2_t vuzp_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vuzp.16 D0, D1'
+
+   * uint8x8x2_t vuzp_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vuzp.8 D0, D1'
+
+   * int32x2x2_t vuzp_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * int16x4x2_t vuzp_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vuzp.16 D0, D1'
+
+   * int8x8x2_t vuzp_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vuzp.8 D0, D1'
+
+   * float32x2x2_t vuzp_f32 (float32x2_t, float32x2_t)
+     _Form of expected instruction(s):_ 'vuzp.32 D0, D1'
+
+   * poly16x4x2_t vuzp_p16 (poly16x4_t, poly16x4_t)
+     _Form of expected instruction(s):_ 'vuzp.16 D0, D1'
+
+   * poly8x8x2_t vuzp_p8 (poly8x8_t, poly8x8_t)
+     _Form of expected instruction(s):_ 'vuzp.8 D0, D1'
+
+   * uint32x4x2_t vuzpq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vuzp.32 Q0, Q1'
+
+   * uint16x8x2_t vuzpq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vuzp.16 Q0, Q1'
+
+   * uint8x16x2_t vuzpq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vuzp.8 Q0, Q1'
+
+   * int32x4x2_t vuzpq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vuzp.32 Q0, Q1'
+
+   * int16x8x2_t vuzpq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vuzp.16 Q0, Q1'
+
+   * int8x16x2_t vuzpq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vuzp.8 Q0, Q1'
+
+   * float32x4x2_t vuzpq_f32 (float32x4_t, float32x4_t)
+     _Form of expected instruction(s):_ 'vuzp.32 Q0, Q1'
+
+   * poly16x8x2_t vuzpq_p16 (poly16x8_t, poly16x8_t)
+     _Form of expected instruction(s):_ 'vuzp.16 Q0, Q1'
+
+   * poly8x16x2_t vuzpq_p8 (poly8x16_t, poly8x16_t)
+     _Form of expected instruction(s):_ 'vuzp.8 Q0, Q1'
+
+6.57.6.75 Element/structure loads, VLD1 variants
+................................................
+
+   * poly64x1_t vld1_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * uint32x2_t vld1_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0}, [R0]'
+
+   * uint16x4_t vld1_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0}, [R0]'
+
+   * uint8x8_t vld1_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0}, [R0]'
+
+   * int32x2_t vld1_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0}, [R0]'
+
+   * int16x4_t vld1_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0}, [R0]'
+
+   * int8x8_t vld1_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0}, [R0]'
+
+   * uint64x1_t vld1_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * int64x1_t vld1_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * float32x2_t vld1_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0}, [R0]'
+
+   * poly16x4_t vld1_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0}, [R0]'
+
+   * poly8x8_t vld1_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0}, [R0]'
+
+   * poly64x2_t vld1q_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+   * uint32x4_t vld1q_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0, D1}, [R0]'
+
+   * uint16x8_t vld1q_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0, D1}, [R0]'
+
+   * uint8x16_t vld1q_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0, D1}, [R0]'
+
+   * int32x4_t vld1q_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0, D1}, [R0]'
+
+   * int16x8_t vld1q_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0, D1}, [R0]'
+
+   * int8x16_t vld1q_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0, D1}, [R0]'
+
+   * uint64x2_t vld1q_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+   * int64x2_t vld1q_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+   * float32x4_t vld1q_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0, D1}, [R0]'
+
+   * poly16x8_t vld1q_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0, D1}, [R0]'
+
+   * poly8x16_t vld1q_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0, D1}, [R0]'
+
+   * uint32x2_t vld1_lane_u32 (const uint32_t *, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[0]}, [R0]'
+
+   * uint16x4_t vld1_lane_u16 (const uint16_t *, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[0]}, [R0]'
+
+   * uint8x8_t vld1_lane_u8 (const uint8_t *, uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[0]}, [R0]'
+
+   * int32x2_t vld1_lane_s32 (const int32_t *, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[0]}, [R0]'
+
+   * int16x4_t vld1_lane_s16 (const int16_t *, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[0]}, [R0]'
+
+   * int8x8_t vld1_lane_s8 (const int8_t *, int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[0]}, [R0]'
+
+   * float32x2_t vld1_lane_f32 (const float32_t *, float32x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[0]}, [R0]'
+
+   * poly16x4_t vld1_lane_p16 (const poly16_t *, poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[0]}, [R0]'
+
+   * poly8x8_t vld1_lane_p8 (const poly8_t *, poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[0]}, [R0]'
+
+   * poly64x1_t vld1_lane_p64 (const poly64_t *, poly64x1_t, const int)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * uint64x1_t vld1_lane_u64 (const uint64_t *, uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * int64x1_t vld1_lane_s64 (const int64_t *, int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * uint32x4_t vld1q_lane_u32 (const uint32_t *, uint32x4_t, const int)
+
+     _Form of expected instruction(s):_ 'vld1.32 {D0[0]}, [R0]'
+
+   * uint16x8_t vld1q_lane_u16 (const uint16_t *, uint16x8_t, const int)
+
+     _Form of expected instruction(s):_ 'vld1.16 {D0[0]}, [R0]'
+
+   * uint8x16_t vld1q_lane_u8 (const uint8_t *, uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[0]}, [R0]'
+
+   * int32x4_t vld1q_lane_s32 (const int32_t *, int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[0]}, [R0]'
+
+   * int16x8_t vld1q_lane_s16 (const int16_t *, int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[0]}, [R0]'
+
+   * int8x16_t vld1q_lane_s8 (const int8_t *, int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[0]}, [R0]'
+
+   * float32x4_t vld1q_lane_f32 (const float32_t *, float32x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[0]}, [R0]'
+
+   * poly16x8_t vld1q_lane_p16 (const poly16_t *, poly16x8_t, const int)
+
+     _Form of expected instruction(s):_ 'vld1.16 {D0[0]}, [R0]'
+
+   * poly8x16_t vld1q_lane_p8 (const poly8_t *, poly8x16_t, const int)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[0]}, [R0]'
+
+   * poly64x2_t vld1q_lane_p64 (const poly64_t *, poly64x2_t, const int)
+
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * uint64x2_t vld1q_lane_u64 (const uint64_t *, uint64x2_t, const int)
+
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * int64x2_t vld1q_lane_s64 (const int64_t *, int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * uint32x2_t vld1_dup_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[]}, [R0]'
+
+   * uint16x4_t vld1_dup_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[]}, [R0]'
+
+   * uint8x8_t vld1_dup_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[]}, [R0]'
+
+   * int32x2_t vld1_dup_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[]}, [R0]'
+
+   * int16x4_t vld1_dup_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[]}, [R0]'
+
+   * int8x8_t vld1_dup_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[]}, [R0]'
+
+   * float32x2_t vld1_dup_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[]}, [R0]'
+
+   * poly16x4_t vld1_dup_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[]}, [R0]'
+
+   * poly8x8_t vld1_dup_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[]}, [R0]'
+
+   * poly64x1_t vld1_dup_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * uint64x1_t vld1_dup_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * int64x1_t vld1_dup_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * uint32x4_t vld1q_dup_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[], D1[]}, [R0]'
+
+   * uint16x8_t vld1q_dup_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[], D1[]}, [R0]'
+
+   * uint8x16_t vld1q_dup_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[], D1[]}, [R0]'
+
+   * int32x4_t vld1q_dup_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[], D1[]}, [R0]'
+
+   * int16x8_t vld1q_dup_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[], D1[]}, [R0]'
+
+   * int8x16_t vld1q_dup_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[], D1[]}, [R0]'
+
+   * float32x4_t vld1q_dup_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld1.32 {D0[], D1[]}, [R0]'
+
+   * poly16x8_t vld1q_dup_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld1.16 {D0[], D1[]}, [R0]'
+
+   * poly8x16_t vld1q_dup_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld1.8 {D0[], D1[]}, [R0]'
+
+   * poly64x2_t vld1q_dup_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * uint64x2_t vld1q_dup_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+   * int64x2_t vld1q_dup_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0}, [R0]'
+
+6.57.6.76 Element/structure stores, VST1 variants
+.................................................
+
+   * void vst1_p64 (poly64_t *, poly64x1_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+   * void vst1_u32 (uint32_t *, uint32x2_t)
+     _Form of expected instruction(s):_ 'vst1.32 {D0}, [R0]'
+
+   * void vst1_u16 (uint16_t *, uint16x4_t)
+     _Form of expected instruction(s):_ 'vst1.16 {D0}, [R0]'
+
+   * void vst1_u8 (uint8_t *, uint8x8_t)
+     _Form of expected instruction(s):_ 'vst1.8 {D0}, [R0]'
+
+   * void vst1_s32 (int32_t *, int32x2_t)
+     _Form of expected instruction(s):_ 'vst1.32 {D0}, [R0]'
+
+   * void vst1_s16 (int16_t *, int16x4_t)
+     _Form of expected instruction(s):_ 'vst1.16 {D0}, [R0]'
+
+   * void vst1_s8 (int8_t *, int8x8_t)
+     _Form of expected instruction(s):_ 'vst1.8 {D0}, [R0]'
+
+   * void vst1_u64 (uint64_t *, uint64x1_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+   * void vst1_s64 (int64_t *, int64x1_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+   * void vst1_f32 (float32_t *, float32x2_t)
+     _Form of expected instruction(s):_ 'vst1.32 {D0}, [R0]'
+
+   * void vst1_p16 (poly16_t *, poly16x4_t)
+     _Form of expected instruction(s):_ 'vst1.16 {D0}, [R0]'
+
+   * void vst1_p8 (poly8_t *, poly8x8_t)
+     _Form of expected instruction(s):_ 'vst1.8 {D0}, [R0]'
+
+   * void vst1q_p64 (poly64_t *, poly64x2_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1}, [R0]'
+
+   * void vst1q_u32 (uint32_t *, uint32x4_t)
+     _Form of expected instruction(s):_ 'vst1.32 {D0, D1}, [R0]'
+
+   * void vst1q_u16 (uint16_t *, uint16x8_t)
+     _Form of expected instruction(s):_ 'vst1.16 {D0, D1}, [R0]'
+
+   * void vst1q_u8 (uint8_t *, uint8x16_t)
+     _Form of expected instruction(s):_ 'vst1.8 {D0, D1}, [R0]'
+
+   * void vst1q_s32 (int32_t *, int32x4_t)
+     _Form of expected instruction(s):_ 'vst1.32 {D0, D1}, [R0]'
+
+   * void vst1q_s16 (int16_t *, int16x8_t)
+     _Form of expected instruction(s):_ 'vst1.16 {D0, D1}, [R0]'
+
+   * void vst1q_s8 (int8_t *, int8x16_t)
+     _Form of expected instruction(s):_ 'vst1.8 {D0, D1}, [R0]'
+
+   * void vst1q_u64 (uint64_t *, uint64x2_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1}, [R0]'
+
+   * void vst1q_s64 (int64_t *, int64x2_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1}, [R0]'
+
+   * void vst1q_f32 (float32_t *, float32x4_t)
+     _Form of expected instruction(s):_ 'vst1.32 {D0, D1}, [R0]'
+
+   * void vst1q_p16 (poly16_t *, poly16x8_t)
+     _Form of expected instruction(s):_ 'vst1.16 {D0, D1}, [R0]'
+
+   * void vst1q_p8 (poly8_t *, poly8x16_t)
+     _Form of expected instruction(s):_ 'vst1.8 {D0, D1}, [R0]'
+
+   * void vst1_lane_u32 (uint32_t *, uint32x2_t, const int)
+     _Form of expected instruction(s):_ 'vst1.32 {D0[0]}, [R0]'
+
+   * void vst1_lane_u16 (uint16_t *, uint16x4_t, const int)
+     _Form of expected instruction(s):_ 'vst1.16 {D0[0]}, [R0]'
+
+   * void vst1_lane_u8 (uint8_t *, uint8x8_t, const int)
+     _Form of expected instruction(s):_ 'vst1.8 {D0[0]}, [R0]'
+
+   * void vst1_lane_s32 (int32_t *, int32x2_t, const int)
+     _Form of expected instruction(s):_ 'vst1.32 {D0[0]}, [R0]'
+
+   * void vst1_lane_s16 (int16_t *, int16x4_t, const int)
+     _Form of expected instruction(s):_ 'vst1.16 {D0[0]}, [R0]'
+
+   * void vst1_lane_s8 (int8_t *, int8x8_t, const int)
+     _Form of expected instruction(s):_ 'vst1.8 {D0[0]}, [R0]'
+
+   * void vst1_lane_f32 (float32_t *, float32x2_t, const int)
+     _Form of expected instruction(s):_ 'vst1.32 {D0[0]}, [R0]'
+
+   * void vst1_lane_p16 (poly16_t *, poly16x4_t, const int)
+     _Form of expected instruction(s):_ 'vst1.16 {D0[0]}, [R0]'
+
+   * void vst1_lane_p8 (poly8_t *, poly8x8_t, const int)
+     _Form of expected instruction(s):_ 'vst1.8 {D0[0]}, [R0]'
+
+   * void vst1_lane_p64 (poly64_t *, poly64x1_t, const int)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+   * void vst1_lane_s64 (int64_t *, int64x1_t, const int)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+   * void vst1_lane_u64 (uint64_t *, uint64x1_t, const int)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+   * void vst1q_lane_u32 (uint32_t *, uint32x4_t, const int)
+     _Form of expected instruction(s):_ 'vst1.32 {D0[0]}, [R0]'
+
+   * void vst1q_lane_u16 (uint16_t *, uint16x8_t, const int)
+     _Form of expected instruction(s):_ 'vst1.16 {D0[0]}, [R0]'
+
+   * void vst1q_lane_u8 (uint8_t *, uint8x16_t, const int)
+     _Form of expected instruction(s):_ 'vst1.8 {D0[0]}, [R0]'
+
+   * void vst1q_lane_s32 (int32_t *, int32x4_t, const int)
+     _Form of expected instruction(s):_ 'vst1.32 {D0[0]}, [R0]'
+
+   * void vst1q_lane_s16 (int16_t *, int16x8_t, const int)
+     _Form of expected instruction(s):_ 'vst1.16 {D0[0]}, [R0]'
+
+   * void vst1q_lane_s8 (int8_t *, int8x16_t, const int)
+     _Form of expected instruction(s):_ 'vst1.8 {D0[0]}, [R0]'
+
+   * void vst1q_lane_f32 (float32_t *, float32x4_t, const int)
+     _Form of expected instruction(s):_ 'vst1.32 {D0[0]}, [R0]'
+
+   * void vst1q_lane_p16 (poly16_t *, poly16x8_t, const int)
+     _Form of expected instruction(s):_ 'vst1.16 {D0[0]}, [R0]'
+
+   * void vst1q_lane_p8 (poly8_t *, poly8x16_t, const int)
+     _Form of expected instruction(s):_ 'vst1.8 {D0[0]}, [R0]'
+
+   * void vst1q_lane_p64 (poly64_t *, poly64x2_t, const int)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+   * void vst1q_lane_s64 (int64_t *, int64x2_t, const int)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+   * void vst1q_lane_u64 (uint64_t *, uint64x2_t, const int)
+     _Form of expected instruction(s):_ 'vst1.64 {D0}, [R0]'
+
+6.57.6.77 Element/structure loads, VLD2 variants
+................................................
+
+   * uint32x2x2_t vld2_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0, D1}, [R0]'
+
+   * uint16x4x2_t vld2_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0, D1}, [R0]'
+
+   * uint8x8x2_t vld2_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0, D1}, [R0]'
+
+   * int32x2x2_t vld2_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0, D1}, [R0]'
+
+   * int16x4x2_t vld2_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0, D1}, [R0]'
+
+   * int8x8x2_t vld2_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0, D1}, [R0]'
+
+   * float32x2x2_t vld2_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0, D1}, [R0]'
+
+   * poly16x4x2_t vld2_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0, D1}, [R0]'
+
+   * poly8x8x2_t vld2_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0, D1}, [R0]'
+
+   * poly64x1x2_t vld2_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+   * uint64x1x2_t vld2_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+   * int64x1x2_t vld2_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+   * uint32x4x2_t vld2q_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0, D1}, [R0]'
+
+   * uint16x8x2_t vld2q_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0, D1}, [R0]'
+
+   * uint8x16x2_t vld2q_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0, D1}, [R0]'
+
+   * int32x4x2_t vld2q_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0, D1}, [R0]'
+
+   * int16x8x2_t vld2q_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0, D1}, [R0]'
+
+   * int8x16x2_t vld2q_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0, D1}, [R0]'
+
+   * float32x4x2_t vld2q_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0, D1}, [R0]'
+
+   * poly16x8x2_t vld2q_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0, D1}, [R0]'
+
+   * poly8x16x2_t vld2q_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0, D1}, [R0]'
+
+   * uint32x2x2_t vld2_lane_u32 (const uint32_t *, uint32x2x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld2.32 {D0[0], D1[0]}, [R0]'
+
+   * uint16x4x2_t vld2_lane_u16 (const uint16_t *, uint16x4x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld2.16 {D0[0], D1[0]}, [R0]'
+
+   * uint8x8x2_t vld2_lane_u8 (const uint8_t *, uint8x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vld2.8 {D0[0], D1[0]}, [R0]'
+
+   * int32x2x2_t vld2_lane_s32 (const int32_t *, int32x2x2_t, const int)
+
+     _Form of expected instruction(s):_ 'vld2.32 {D0[0], D1[0]}, [R0]'
+
+   * int16x4x2_t vld2_lane_s16 (const int16_t *, int16x4x2_t, const int)
+
+     _Form of expected instruction(s):_ 'vld2.16 {D0[0], D1[0]}, [R0]'
+
+   * int8x8x2_t vld2_lane_s8 (const int8_t *, int8x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vld2.8 {D0[0], D1[0]}, [R0]'
+
+   * float32x2x2_t vld2_lane_f32 (const float32_t *, float32x2x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vld2.32 {D0[0], D1[0]}, [R0]'
+
+   * poly16x4x2_t vld2_lane_p16 (const poly16_t *, poly16x4x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld2.16 {D0[0], D1[0]}, [R0]'
+
+   * poly8x8x2_t vld2_lane_p8 (const poly8_t *, poly8x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vld2.8 {D0[0], D1[0]}, [R0]'
+
+   * int32x4x2_t vld2q_lane_s32 (const int32_t *, int32x4x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld2.32 {D0[0], D1[0]}, [R0]'
+
+   * int16x8x2_t vld2q_lane_s16 (const int16_t *, int16x8x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld2.16 {D0[0], D1[0]}, [R0]'
+
+   * uint32x4x2_t vld2q_lane_u32 (const uint32_t *, uint32x4x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld2.32 {D0[0], D1[0]}, [R0]'
+
+   * uint16x8x2_t vld2q_lane_u16 (const uint16_t *, uint16x8x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld2.16 {D0[0], D1[0]}, [R0]'
+
+   * float32x4x2_t vld2q_lane_f32 (const float32_t *, float32x4x2_t,
+     const int)
+     _Form of expected instruction(s):_ 'vld2.32 {D0[0], D1[0]}, [R0]'
+
+   * poly16x8x2_t vld2q_lane_p16 (const poly16_t *, poly16x8x2_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld2.16 {D0[0], D1[0]}, [R0]'
+
+   * uint32x2x2_t vld2_dup_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0[], D1[]}, [R0]'
+
+   * uint16x4x2_t vld2_dup_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0[], D1[]}, [R0]'
+
+   * uint8x8x2_t vld2_dup_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0[], D1[]}, [R0]'
+
+   * int32x2x2_t vld2_dup_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0[], D1[]}, [R0]'
+
+   * int16x4x2_t vld2_dup_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0[], D1[]}, [R0]'
+
+   * int8x8x2_t vld2_dup_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0[], D1[]}, [R0]'
+
+   * float32x2x2_t vld2_dup_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld2.32 {D0[], D1[]}, [R0]'
+
+   * poly16x4x2_t vld2_dup_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld2.16 {D0[], D1[]}, [R0]'
+
+   * poly8x8x2_t vld2_dup_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld2.8 {D0[], D1[]}, [R0]'
+
+   * poly64x1x2_t vld2_dup_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+   * uint64x1x2_t vld2_dup_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+   * int64x1x2_t vld2_dup_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1}, [R0]'
+
+6.57.6.78 Element/structure stores, VST2 variants
+.................................................
+
+   * void vst2_u32 (uint32_t *, uint32x2x2_t)
+     _Form of expected instruction(s):_ 'vst2.32 {D0, D1}, [R0]'
+
+   * void vst2_u16 (uint16_t *, uint16x4x2_t)
+     _Form of expected instruction(s):_ 'vst2.16 {D0, D1}, [R0]'
+
+   * void vst2_u8 (uint8_t *, uint8x8x2_t)
+     _Form of expected instruction(s):_ 'vst2.8 {D0, D1}, [R0]'
+
+   * void vst2_s32 (int32_t *, int32x2x2_t)
+     _Form of expected instruction(s):_ 'vst2.32 {D0, D1}, [R0]'
+
+   * void vst2_s16 (int16_t *, int16x4x2_t)
+     _Form of expected instruction(s):_ 'vst2.16 {D0, D1}, [R0]'
+
+   * void vst2_s8 (int8_t *, int8x8x2_t)
+     _Form of expected instruction(s):_ 'vst2.8 {D0, D1}, [R0]'
+
+   * void vst2_f32 (float32_t *, float32x2x2_t)
+     _Form of expected instruction(s):_ 'vst2.32 {D0, D1}, [R0]'
+
+   * void vst2_p16 (poly16_t *, poly16x4x2_t)
+     _Form of expected instruction(s):_ 'vst2.16 {D0, D1}, [R0]'
+
+   * void vst2_p8 (poly8_t *, poly8x8x2_t)
+     _Form of expected instruction(s):_ 'vst2.8 {D0, D1}, [R0]'
+
+   * void vst2_p64 (poly64_t *, poly64x1x2_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1}, [R0]'
+
+   * void vst2_u64 (uint64_t *, uint64x1x2_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1}, [R0]'
+
+   * void vst2_s64 (int64_t *, int64x1x2_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1}, [R0]'
+
+   * void vst2q_u32 (uint32_t *, uint32x4x2_t)
+     _Form of expected instruction(s):_ 'vst2.32 {D0, D1}, [R0]'
+
+   * void vst2q_u16 (uint16_t *, uint16x8x2_t)
+     _Form of expected instruction(s):_ 'vst2.16 {D0, D1}, [R0]'
+
+   * void vst2q_u8 (uint8_t *, uint8x16x2_t)
+     _Form of expected instruction(s):_ 'vst2.8 {D0, D1}, [R0]'
+
+   * void vst2q_s32 (int32_t *, int32x4x2_t)
+     _Form of expected instruction(s):_ 'vst2.32 {D0, D1}, [R0]'
+
+   * void vst2q_s16 (int16_t *, int16x8x2_t)
+     _Form of expected instruction(s):_ 'vst2.16 {D0, D1}, [R0]'
+
+   * void vst2q_s8 (int8_t *, int8x16x2_t)
+     _Form of expected instruction(s):_ 'vst2.8 {D0, D1}, [R0]'
+
+   * void vst2q_f32 (float32_t *, float32x4x2_t)
+     _Form of expected instruction(s):_ 'vst2.32 {D0, D1}, [R0]'
+
+   * void vst2q_p16 (poly16_t *, poly16x8x2_t)
+     _Form of expected instruction(s):_ 'vst2.16 {D0, D1}, [R0]'
+
+   * void vst2q_p8 (poly8_t *, poly8x16x2_t)
+     _Form of expected instruction(s):_ 'vst2.8 {D0, D1}, [R0]'
+
+   * void vst2_lane_u32 (uint32_t *, uint32x2x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.32 {D0[0], D1[0]}, [R0]'
+
+   * void vst2_lane_u16 (uint16_t *, uint16x4x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.16 {D0[0], D1[0]}, [R0]'
+
+   * void vst2_lane_u8 (uint8_t *, uint8x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.8 {D0[0], D1[0]}, [R0]'
+
+   * void vst2_lane_s32 (int32_t *, int32x2x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.32 {D0[0], D1[0]}, [R0]'
+
+   * void vst2_lane_s16 (int16_t *, int16x4x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.16 {D0[0], D1[0]}, [R0]'
+
+   * void vst2_lane_s8 (int8_t *, int8x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.8 {D0[0], D1[0]}, [R0]'
+
+   * void vst2_lane_f32 (float32_t *, float32x2x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.32 {D0[0], D1[0]}, [R0]'
+
+   * void vst2_lane_p16 (poly16_t *, poly16x4x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.16 {D0[0], D1[0]}, [R0]'
+
+   * void vst2_lane_p8 (poly8_t *, poly8x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.8 {D0[0], D1[0]}, [R0]'
+
+   * void vst2q_lane_s32 (int32_t *, int32x4x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.32 {D0[0], D1[0]}, [R0]'
+
+   * void vst2q_lane_s16 (int16_t *, int16x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.16 {D0[0], D1[0]}, [R0]'
+
+   * void vst2q_lane_u32 (uint32_t *, uint32x4x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.32 {D0[0], D1[0]}, [R0]'
+
+   * void vst2q_lane_u16 (uint16_t *, uint16x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.16 {D0[0], D1[0]}, [R0]'
+
+   * void vst2q_lane_f32 (float32_t *, float32x4x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.32 {D0[0], D1[0]}, [R0]'
+
+   * void vst2q_lane_p16 (poly16_t *, poly16x8x2_t, const int)
+     _Form of expected instruction(s):_ 'vst2.16 {D0[0], D1[0]}, [R0]'
+
+6.57.6.79 Element/structure loads, VLD3 variants
+................................................
+
+   * uint32x2x3_t vld3_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0, D1, D2}, [R0]'
+
+   * uint16x4x3_t vld3_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0, D1, D2}, [R0]'
+
+   * uint8x8x3_t vld3_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0, D1, D2}, [R0]'
+
+   * int32x2x3_t vld3_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0, D1, D2}, [R0]'
+
+   * int16x4x3_t vld3_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0, D1, D2}, [R0]'
+
+   * int8x8x3_t vld3_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0, D1, D2}, [R0]'
+
+   * float32x2x3_t vld3_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0, D1, D2}, [R0]'
+
+   * poly16x4x3_t vld3_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0, D1, D2}, [R0]'
+
+   * poly8x8x3_t vld3_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0, D1, D2}, [R0]'
+
+   * poly64x1x3_t vld3_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2}, [R0]'
+
+   * uint64x1x3_t vld3_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2}, [R0]'
+
+   * int64x1x3_t vld3_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2}, [R0]'
+
+   * uint32x4x3_t vld3q_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0, D1, D2}, [R0]'
+
+   * uint16x8x3_t vld3q_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0, D1, D2}, [R0]'
+
+   * uint8x16x3_t vld3q_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0, D1, D2}, [R0]'
+
+   * int32x4x3_t vld3q_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0, D1, D2}, [R0]'
+
+   * int16x8x3_t vld3q_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0, D1, D2}, [R0]'
+
+   * int8x16x3_t vld3q_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0, D1, D2}, [R0]'
+
+   * float32x4x3_t vld3q_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0, D1, D2}, [R0]'
+
+   * poly16x8x3_t vld3q_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0, D1, D2}, [R0]'
+
+   * poly8x16x3_t vld3q_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0, D1, D2}, [R0]'
+
+   * uint32x2x3_t vld3_lane_u32 (const uint32_t *, uint32x2x3_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * uint16x4x3_t vld3_lane_u16 (const uint16_t *, uint16x4x3_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * uint8x8x3_t vld3_lane_u8 (const uint8_t *, uint8x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vld3.8 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * int32x2x3_t vld3_lane_s32 (const int32_t *, int32x2x3_t, const int)
+
+     _Form of expected instruction(s):_ 'vld3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * int16x4x3_t vld3_lane_s16 (const int16_t *, int16x4x3_t, const int)
+
+     _Form of expected instruction(s):_ 'vld3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * int8x8x3_t vld3_lane_s8 (const int8_t *, int8x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vld3.8 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * float32x2x3_t vld3_lane_f32 (const float32_t *, float32x2x3_t,
+     const int)
+     _Form of expected instruction(s):_ 'vld3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * poly16x4x3_t vld3_lane_p16 (const poly16_t *, poly16x4x3_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * poly8x8x3_t vld3_lane_p8 (const poly8_t *, poly8x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vld3.8 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * int32x4x3_t vld3q_lane_s32 (const int32_t *, int32x4x3_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * int16x8x3_t vld3q_lane_s16 (const int16_t *, int16x8x3_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * uint32x4x3_t vld3q_lane_u32 (const uint32_t *, uint32x4x3_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * uint16x8x3_t vld3q_lane_u16 (const uint16_t *, uint16x8x3_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * float32x4x3_t vld3q_lane_f32 (const float32_t *, float32x4x3_t,
+     const int)
+     _Form of expected instruction(s):_ 'vld3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * poly16x8x3_t vld3q_lane_p16 (const poly16_t *, poly16x8x3_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * uint32x2x3_t vld3_dup_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0[], D1[], D2[]},
+     [R0]'
+
+   * uint16x4x3_t vld3_dup_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0[], D1[], D2[]},
+     [R0]'
+
+   * uint8x8x3_t vld3_dup_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0[], D1[], D2[]},
+     [R0]'
+
+   * int32x2x3_t vld3_dup_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0[], D1[], D2[]},
+     [R0]'
+
+   * int16x4x3_t vld3_dup_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0[], D1[], D2[]},
+     [R0]'
+
+   * int8x8x3_t vld3_dup_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0[], D1[], D2[]},
+     [R0]'
+
+   * float32x2x3_t vld3_dup_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld3.32 {D0[], D1[], D2[]},
+     [R0]'
+
+   * poly16x4x3_t vld3_dup_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld3.16 {D0[], D1[], D2[]},
+     [R0]'
+
+   * poly8x8x3_t vld3_dup_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld3.8 {D0[], D1[], D2[]},
+     [R0]'
+
+   * poly64x1x3_t vld3_dup_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2}, [R0]'
+
+   * uint64x1x3_t vld3_dup_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2}, [R0]'
+
+   * int64x1x3_t vld3_dup_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2}, [R0]'
+
+6.57.6.80 Element/structure stores, VST3 variants
+.................................................
+
+   * void vst3_u32 (uint32_t *, uint32x2x3_t)
+     _Form of expected instruction(s):_ 'vst3.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_u16 (uint16_t *, uint16x4x3_t)
+     _Form of expected instruction(s):_ 'vst3.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_u8 (uint8_t *, uint8x8x3_t)
+     _Form of expected instruction(s):_ 'vst3.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_s32 (int32_t *, int32x2x3_t)
+     _Form of expected instruction(s):_ 'vst3.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_s16 (int16_t *, int16x4x3_t)
+     _Form of expected instruction(s):_ 'vst3.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_s8 (int8_t *, int8x8x3_t)
+     _Form of expected instruction(s):_ 'vst3.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_f32 (float32_t *, float32x2x3_t)
+     _Form of expected instruction(s):_ 'vst3.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_p16 (poly16_t *, poly16x4x3_t)
+     _Form of expected instruction(s):_ 'vst3.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_p8 (poly8_t *, poly8x8x3_t)
+     _Form of expected instruction(s):_ 'vst3.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_p64 (poly64_t *, poly64x1x3_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_u64 (uint64_t *, uint64x1x3_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3_s64 (int64_t *, int64x1x3_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1, D2, D3}, [R0]'
+
+   * void vst3q_u32 (uint32_t *, uint32x4x3_t)
+     _Form of expected instruction(s):_ 'vst3.32 {D0, D1, D2}, [R0]'
+
+   * void vst3q_u16 (uint16_t *, uint16x8x3_t)
+     _Form of expected instruction(s):_ 'vst3.16 {D0, D1, D2}, [R0]'
+
+   * void vst3q_u8 (uint8_t *, uint8x16x3_t)
+     _Form of expected instruction(s):_ 'vst3.8 {D0, D1, D2}, [R0]'
+
+   * void vst3q_s32 (int32_t *, int32x4x3_t)
+     _Form of expected instruction(s):_ 'vst3.32 {D0, D1, D2}, [R0]'
+
+   * void vst3q_s16 (int16_t *, int16x8x3_t)
+     _Form of expected instruction(s):_ 'vst3.16 {D0, D1, D2}, [R0]'
+
+   * void vst3q_s8 (int8_t *, int8x16x3_t)
+     _Form of expected instruction(s):_ 'vst3.8 {D0, D1, D2}, [R0]'
+
+   * void vst3q_f32 (float32_t *, float32x4x3_t)
+     _Form of expected instruction(s):_ 'vst3.32 {D0, D1, D2}, [R0]'
+
+   * void vst3q_p16 (poly16_t *, poly16x8x3_t)
+     _Form of expected instruction(s):_ 'vst3.16 {D0, D1, D2}, [R0]'
+
+   * void vst3q_p8 (poly8_t *, poly8x16x3_t)
+     _Form of expected instruction(s):_ 'vst3.8 {D0, D1, D2}, [R0]'
+
+   * void vst3_lane_u32 (uint32_t *, uint32x2x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3_lane_u16 (uint16_t *, uint16x4x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3_lane_u8 (uint8_t *, uint8x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.8 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3_lane_s32 (int32_t *, int32x2x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3_lane_s16 (int16_t *, int16x4x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3_lane_s8 (int8_t *, int8x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.8 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3_lane_f32 (float32_t *, float32x2x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3_lane_p16 (poly16_t *, poly16x4x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3_lane_p8 (poly8_t *, poly8x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.8 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3q_lane_s32 (int32_t *, int32x4x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3q_lane_s16 (int16_t *, int16x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3q_lane_u32 (uint32_t *, uint32x4x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3q_lane_u16 (uint16_t *, uint16x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3q_lane_f32 (float32_t *, float32x4x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.32 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+   * void vst3q_lane_p16 (poly16_t *, poly16x8x3_t, const int)
+     _Form of expected instruction(s):_ 'vst3.16 {D0[0], D1[0], D2[0]},
+     [R0]'
+
+6.57.6.81 Element/structure loads, VLD4 variants
+................................................
+
+   * uint32x2x4_t vld4_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0, D1, D2, D3}, [R0]'
+
+   * uint16x4x4_t vld4_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0, D1, D2, D3}, [R0]'
+
+   * uint8x8x4_t vld4_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0, D1, D2, D3}, [R0]'
+
+   * int32x2x4_t vld4_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0, D1, D2, D3}, [R0]'
+
+   * int16x4x4_t vld4_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0, D1, D2, D3}, [R0]'
+
+   * int8x8x4_t vld4_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0, D1, D2, D3}, [R0]'
+
+   * float32x2x4_t vld4_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0, D1, D2, D3}, [R0]'
+
+   * poly16x4x4_t vld4_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0, D1, D2, D3}, [R0]'
+
+   * poly8x8x4_t vld4_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0, D1, D2, D3}, [R0]'
+
+   * poly64x1x4_t vld4_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2, D3}, [R0]'
+
+   * uint64x1x4_t vld4_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2, D3}, [R0]'
+
+   * int64x1x4_t vld4_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2, D3}, [R0]'
+
+   * uint32x4x4_t vld4q_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0, D1, D2, D3}, [R0]'
+
+   * uint16x8x4_t vld4q_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0, D1, D2, D3}, [R0]'
+
+   * uint8x16x4_t vld4q_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0, D1, D2, D3}, [R0]'
+
+   * int32x4x4_t vld4q_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0, D1, D2, D3}, [R0]'
+
+   * int16x8x4_t vld4q_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0, D1, D2, D3}, [R0]'
+
+   * int8x16x4_t vld4q_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0, D1, D2, D3}, [R0]'
+
+   * float32x4x4_t vld4q_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0, D1, D2, D3}, [R0]'
+
+   * poly16x8x4_t vld4q_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0, D1, D2, D3}, [R0]'
+
+   * poly8x16x4_t vld4q_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0, D1, D2, D3}, [R0]'
+
+   * uint32x2x4_t vld4_lane_u32 (const uint32_t *, uint32x2x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * uint16x4x4_t vld4_lane_u16 (const uint16_t *, uint16x4x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * uint8x8x4_t vld4_lane_u8 (const uint8_t *, uint8x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vld4.8 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * int32x2x4_t vld4_lane_s32 (const int32_t *, int32x2x4_t, const int)
+
+     _Form of expected instruction(s):_ 'vld4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * int16x4x4_t vld4_lane_s16 (const int16_t *, int16x4x4_t, const int)
+
+     _Form of expected instruction(s):_ 'vld4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * int8x8x4_t vld4_lane_s8 (const int8_t *, int8x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vld4.8 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * float32x2x4_t vld4_lane_f32 (const float32_t *, float32x2x4_t,
+     const int)
+     _Form of expected instruction(s):_ 'vld4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * poly16x4x4_t vld4_lane_p16 (const poly16_t *, poly16x4x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * poly8x8x4_t vld4_lane_p8 (const poly8_t *, poly8x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vld4.8 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * int32x4x4_t vld4q_lane_s32 (const int32_t *, int32x4x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * int16x8x4_t vld4q_lane_s16 (const int16_t *, int16x8x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * uint32x4x4_t vld4q_lane_u32 (const uint32_t *, uint32x4x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * uint16x8x4_t vld4q_lane_u16 (const uint16_t *, uint16x8x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * float32x4x4_t vld4q_lane_f32 (const float32_t *, float32x4x4_t,
+     const int)
+     _Form of expected instruction(s):_ 'vld4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * poly16x8x4_t vld4q_lane_p16 (const poly16_t *, poly16x8x4_t, const
+     int)
+     _Form of expected instruction(s):_ 'vld4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * uint32x2x4_t vld4_dup_u32 (const uint32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * uint16x4x4_t vld4_dup_u16 (const uint16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * uint8x8x4_t vld4_dup_u8 (const uint8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * int32x2x4_t vld4_dup_s32 (const int32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * int16x4x4_t vld4_dup_s16 (const int16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * int8x8x4_t vld4_dup_s8 (const int8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * float32x2x4_t vld4_dup_f32 (const float32_t *)
+     _Form of expected instruction(s):_ 'vld4.32 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * poly16x4x4_t vld4_dup_p16 (const poly16_t *)
+     _Form of expected instruction(s):_ 'vld4.16 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * poly8x8x4_t vld4_dup_p8 (const poly8_t *)
+     _Form of expected instruction(s):_ 'vld4.8 {D0[], D1[], D2[],
+     D3[]}, [R0]'
+
+   * poly64x1x4_t vld4_dup_p64 (const poly64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2, D3}, [R0]'
+
+   * uint64x1x4_t vld4_dup_u64 (const uint64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2, D3}, [R0]'
+
+   * int64x1x4_t vld4_dup_s64 (const int64_t *)
+     _Form of expected instruction(s):_ 'vld1.64 {D0, D1, D2, D3}, [R0]'
+
+6.57.6.82 Element/structure stores, VST4 variants
+.................................................
+
+   * void vst4_u32 (uint32_t *, uint32x2x4_t)
+     _Form of expected instruction(s):_ 'vst4.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_u16 (uint16_t *, uint16x4x4_t)
+     _Form of expected instruction(s):_ 'vst4.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_u8 (uint8_t *, uint8x8x4_t)
+     _Form of expected instruction(s):_ 'vst4.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_s32 (int32_t *, int32x2x4_t)
+     _Form of expected instruction(s):_ 'vst4.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_s16 (int16_t *, int16x4x4_t)
+     _Form of expected instruction(s):_ 'vst4.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_s8 (int8_t *, int8x8x4_t)
+     _Form of expected instruction(s):_ 'vst4.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_f32 (float32_t *, float32x2x4_t)
+     _Form of expected instruction(s):_ 'vst4.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_p16 (poly16_t *, poly16x4x4_t)
+     _Form of expected instruction(s):_ 'vst4.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_p8 (poly8_t *, poly8x8x4_t)
+     _Form of expected instruction(s):_ 'vst4.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_p64 (poly64_t *, poly64x1x4_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_u64 (uint64_t *, uint64x1x4_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_s64 (int64_t *, int64x1x4_t)
+     _Form of expected instruction(s):_ 'vst1.64 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_u32 (uint32_t *, uint32x4x4_t)
+     _Form of expected instruction(s):_ 'vst4.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_u16 (uint16_t *, uint16x8x4_t)
+     _Form of expected instruction(s):_ 'vst4.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_u8 (uint8_t *, uint8x16x4_t)
+     _Form of expected instruction(s):_ 'vst4.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_s32 (int32_t *, int32x4x4_t)
+     _Form of expected instruction(s):_ 'vst4.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_s16 (int16_t *, int16x8x4_t)
+     _Form of expected instruction(s):_ 'vst4.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_s8 (int8_t *, int8x16x4_t)
+     _Form of expected instruction(s):_ 'vst4.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_f32 (float32_t *, float32x4x4_t)
+     _Form of expected instruction(s):_ 'vst4.32 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_p16 (poly16_t *, poly16x8x4_t)
+     _Form of expected instruction(s):_ 'vst4.16 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4q_p8 (poly8_t *, poly8x16x4_t)
+     _Form of expected instruction(s):_ 'vst4.8 {D0, D1, D2, D3}, [R0]'
+
+   * void vst4_lane_u32 (uint32_t *, uint32x2x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4_lane_u16 (uint16_t *, uint16x4x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4_lane_u8 (uint8_t *, uint8x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.8 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4_lane_s32 (int32_t *, int32x2x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4_lane_s16 (int16_t *, int16x4x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4_lane_s8 (int8_t *, int8x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.8 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4_lane_f32 (float32_t *, float32x2x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4_lane_p16 (poly16_t *, poly16x4x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4_lane_p8 (poly8_t *, poly8x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.8 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4q_lane_s32 (int32_t *, int32x4x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4q_lane_s16 (int16_t *, int16x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4q_lane_u32 (uint32_t *, uint32x4x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4q_lane_u16 (uint16_t *, uint16x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4q_lane_f32 (float32_t *, float32x4x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.32 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+   * void vst4q_lane_p16 (poly16_t *, poly16x8x4_t, const int)
+     _Form of expected instruction(s):_ 'vst4.16 {D0[0], D1[0], D2[0],
+     D3[0]}, [R0]'
+
+6.57.6.83 Logical operations (AND)
+..................................
+
+   * uint32x2_t vand_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vand D0, D0, D0'
+
+   * uint16x4_t vand_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vand D0, D0, D0'
+
+   * uint8x8_t vand_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vand D0, D0, D0'
+
+   * int32x2_t vand_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vand D0, D0, D0'
+
+   * int16x4_t vand_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vand D0, D0, D0'
+
+   * int8x8_t vand_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vand D0, D0, D0'
+
+   * uint64x1_t vand_u64 (uint64x1_t, uint64x1_t)
+
+   * int64x1_t vand_s64 (int64x1_t, int64x1_t)
+
+   * uint32x4_t vandq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vand Q0, Q0, Q0'
+
+   * uint16x8_t vandq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vand Q0, Q0, Q0'
+
+   * uint8x16_t vandq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vand Q0, Q0, Q0'
+
+   * int32x4_t vandq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vand Q0, Q0, Q0'
+
+   * int16x8_t vandq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vand Q0, Q0, Q0'
+
+   * int8x16_t vandq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vand Q0, Q0, Q0'
+
+   * uint64x2_t vandq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vand Q0, Q0, Q0'
+
+   * int64x2_t vandq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vand Q0, Q0, Q0'
+
+6.57.6.84 Logical operations (OR)
+.................................
+
+   * uint32x2_t vorr_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vorr D0, D0, D0'
+
+   * uint16x4_t vorr_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vorr D0, D0, D0'
+
+   * uint8x8_t vorr_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vorr D0, D0, D0'
+
+   * int32x2_t vorr_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vorr D0, D0, D0'
+
+   * int16x4_t vorr_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vorr D0, D0, D0'
+
+   * int8x8_t vorr_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vorr D0, D0, D0'
+
+   * uint64x1_t vorr_u64 (uint64x1_t, uint64x1_t)
+
+   * int64x1_t vorr_s64 (int64x1_t, int64x1_t)
+
+   * uint32x4_t vorrq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vorr Q0, Q0, Q0'
+
+   * uint16x8_t vorrq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vorr Q0, Q0, Q0'
+
+   * uint8x16_t vorrq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vorr Q0, Q0, Q0'
+
+   * int32x4_t vorrq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vorr Q0, Q0, Q0'
+
+   * int16x8_t vorrq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vorr Q0, Q0, Q0'
+
+   * int8x16_t vorrq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vorr Q0, Q0, Q0'
+
+   * uint64x2_t vorrq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vorr Q0, Q0, Q0'
+
+   * int64x2_t vorrq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vorr Q0, Q0, Q0'
+
+6.57.6.85 Logical operations (exclusive OR)
+...........................................
+
+   * uint32x2_t veor_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'veor D0, D0, D0'
+
+   * uint16x4_t veor_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'veor D0, D0, D0'
+
+   * uint8x8_t veor_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'veor D0, D0, D0'
+
+   * int32x2_t veor_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'veor D0, D0, D0'
+
+   * int16x4_t veor_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'veor D0, D0, D0'
+
+   * int8x8_t veor_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'veor D0, D0, D0'
+
+   * uint64x1_t veor_u64 (uint64x1_t, uint64x1_t)
+
+   * int64x1_t veor_s64 (int64x1_t, int64x1_t)
+
+   * uint32x4_t veorq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'veor Q0, Q0, Q0'
+
+   * uint16x8_t veorq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'veor Q0, Q0, Q0'
+
+   * uint8x16_t veorq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'veor Q0, Q0, Q0'
+
+   * int32x4_t veorq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'veor Q0, Q0, Q0'
+
+   * int16x8_t veorq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'veor Q0, Q0, Q0'
+
+   * int8x16_t veorq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'veor Q0, Q0, Q0'
+
+   * uint64x2_t veorq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'veor Q0, Q0, Q0'
+
+   * int64x2_t veorq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'veor Q0, Q0, Q0'
+
+6.57.6.86 Logical operations (AND-NOT)
+......................................
+
+   * uint32x2_t vbic_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vbic D0, D0, D0'
+
+   * uint16x4_t vbic_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vbic D0, D0, D0'
+
+   * uint8x8_t vbic_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vbic D0, D0, D0'
+
+   * int32x2_t vbic_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vbic D0, D0, D0'
+
+   * int16x4_t vbic_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vbic D0, D0, D0'
+
+   * int8x8_t vbic_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vbic D0, D0, D0'
+
+   * uint64x1_t vbic_u64 (uint64x1_t, uint64x1_t)
+
+   * int64x1_t vbic_s64 (int64x1_t, int64x1_t)
+
+   * uint32x4_t vbicq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vbic Q0, Q0, Q0'
+
+   * uint16x8_t vbicq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vbic Q0, Q0, Q0'
+
+   * uint8x16_t vbicq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vbic Q0, Q0, Q0'
+
+   * int32x4_t vbicq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vbic Q0, Q0, Q0'
+
+   * int16x8_t vbicq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vbic Q0, Q0, Q0'
+
+   * int8x16_t vbicq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vbic Q0, Q0, Q0'
+
+   * uint64x2_t vbicq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vbic Q0, Q0, Q0'
+
+   * int64x2_t vbicq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vbic Q0, Q0, Q0'
+
+6.57.6.87 Logical operations (OR-NOT)
+.....................................
+
+   * uint32x2_t vorn_u32 (uint32x2_t, uint32x2_t)
+     _Form of expected instruction(s):_ 'vorn D0, D0, D0'
+
+   * uint16x4_t vorn_u16 (uint16x4_t, uint16x4_t)
+     _Form of expected instruction(s):_ 'vorn D0, D0, D0'
+
+   * uint8x8_t vorn_u8 (uint8x8_t, uint8x8_t)
+     _Form of expected instruction(s):_ 'vorn D0, D0, D0'
+
+   * int32x2_t vorn_s32 (int32x2_t, int32x2_t)
+     _Form of expected instruction(s):_ 'vorn D0, D0, D0'
+
+   * int16x4_t vorn_s16 (int16x4_t, int16x4_t)
+     _Form of expected instruction(s):_ 'vorn D0, D0, D0'
+
+   * int8x8_t vorn_s8 (int8x8_t, int8x8_t)
+     _Form of expected instruction(s):_ 'vorn D0, D0, D0'
+
+   * uint64x1_t vorn_u64 (uint64x1_t, uint64x1_t)
+
+   * int64x1_t vorn_s64 (int64x1_t, int64x1_t)
+
+   * uint32x4_t vornq_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'vorn Q0, Q0, Q0'
+
+   * uint16x8_t vornq_u16 (uint16x8_t, uint16x8_t)
+     _Form of expected instruction(s):_ 'vorn Q0, Q0, Q0'
+
+   * uint8x16_t vornq_u8 (uint8x16_t, uint8x16_t)
+     _Form of expected instruction(s):_ 'vorn Q0, Q0, Q0'
+
+   * int32x4_t vornq_s32 (int32x4_t, int32x4_t)
+     _Form of expected instruction(s):_ 'vorn Q0, Q0, Q0'
+
+   * int16x8_t vornq_s16 (int16x8_t, int16x8_t)
+     _Form of expected instruction(s):_ 'vorn Q0, Q0, Q0'
+
+   * int8x16_t vornq_s8 (int8x16_t, int8x16_t)
+     _Form of expected instruction(s):_ 'vorn Q0, Q0, Q0'
+
+   * uint64x2_t vornq_u64 (uint64x2_t, uint64x2_t)
+     _Form of expected instruction(s):_ 'vorn Q0, Q0, Q0'
+
+   * int64x2_t vornq_s64 (int64x2_t, int64x2_t)
+     _Form of expected instruction(s):_ 'vorn Q0, Q0, Q0'
+
+6.57.6.88 Reinterpret casts
+...........................
+
+   * poly8x8_t vreinterpret_p8_p16 (poly16x4_t)
+
+   * poly8x8_t vreinterpret_p8_f32 (float32x2_t)
+
+   * poly8x8_t vreinterpret_p8_p64 (poly64x1_t)
+
+   * poly8x8_t vreinterpret_p8_s64 (int64x1_t)
+
+   * poly8x8_t vreinterpret_p8_u64 (uint64x1_t)
+
+   * poly8x8_t vreinterpret_p8_s8 (int8x8_t)
+
+   * poly8x8_t vreinterpret_p8_s16 (int16x4_t)
+
+   * poly8x8_t vreinterpret_p8_s32 (int32x2_t)
+
+   * poly8x8_t vreinterpret_p8_u8 (uint8x8_t)
+
+   * poly8x8_t vreinterpret_p8_u16 (uint16x4_t)
+
+   * poly8x8_t vreinterpret_p8_u32 (uint32x2_t)
+
+   * poly16x4_t vreinterpret_p16_p8 (poly8x8_t)
+
+   * poly16x4_t vreinterpret_p16_f32 (float32x2_t)
+
+   * poly16x4_t vreinterpret_p16_p64 (poly64x1_t)
+
+   * poly16x4_t vreinterpret_p16_s64 (int64x1_t)
+
+   * poly16x4_t vreinterpret_p16_u64 (uint64x1_t)
+
+   * poly16x4_t vreinterpret_p16_s8 (int8x8_t)
+
+   * poly16x4_t vreinterpret_p16_s16 (int16x4_t)
+
+   * poly16x4_t vreinterpret_p16_s32 (int32x2_t)
+
+   * poly16x4_t vreinterpret_p16_u8 (uint8x8_t)
+
+   * poly16x4_t vreinterpret_p16_u16 (uint16x4_t)
+
+   * poly16x4_t vreinterpret_p16_u32 (uint32x2_t)
+
+   * float32x2_t vreinterpret_f32_p8 (poly8x8_t)
+
+   * float32x2_t vreinterpret_f32_p16 (poly16x4_t)
+
+   * float32x2_t vreinterpret_f32_p64 (poly64x1_t)
+
+   * float32x2_t vreinterpret_f32_s64 (int64x1_t)
+
+   * float32x2_t vreinterpret_f32_u64 (uint64x1_t)
+
+   * float32x2_t vreinterpret_f32_s8 (int8x8_t)
+
+   * float32x2_t vreinterpret_f32_s16 (int16x4_t)
+
+   * float32x2_t vreinterpret_f32_s32 (int32x2_t)
+
+   * float32x2_t vreinterpret_f32_u8 (uint8x8_t)
+
+   * float32x2_t vreinterpret_f32_u16 (uint16x4_t)
+
+   * float32x2_t vreinterpret_f32_u32 (uint32x2_t)
+
+   * poly64x1_t vreinterpret_p64_p8 (poly8x8_t)
+
+   * poly64x1_t vreinterpret_p64_p16 (poly16x4_t)
+
+   * poly64x1_t vreinterpret_p64_f32 (float32x2_t)
+
+   * poly64x1_t vreinterpret_p64_s64 (int64x1_t)
+
+   * poly64x1_t vreinterpret_p64_u64 (uint64x1_t)
+
+   * poly64x1_t vreinterpret_p64_s8 (int8x8_t)
+
+   * poly64x1_t vreinterpret_p64_s16 (int16x4_t)
+
+   * poly64x1_t vreinterpret_p64_s32 (int32x2_t)
+
+   * poly64x1_t vreinterpret_p64_u8 (uint8x8_t)
+
+   * poly64x1_t vreinterpret_p64_u16 (uint16x4_t)
+
+   * poly64x1_t vreinterpret_p64_u32 (uint32x2_t)
+
+   * int64x1_t vreinterpret_s64_p8 (poly8x8_t)
+
+   * int64x1_t vreinterpret_s64_p16 (poly16x4_t)
+
+   * int64x1_t vreinterpret_s64_f32 (float32x2_t)
+
+   * int64x1_t vreinterpret_s64_p64 (poly64x1_t)
+
+   * int64x1_t vreinterpret_s64_u64 (uint64x1_t)
+
+   * int64x1_t vreinterpret_s64_s8 (int8x8_t)
+
+   * int64x1_t vreinterpret_s64_s16 (int16x4_t)
+
+   * int64x1_t vreinterpret_s64_s32 (int32x2_t)
+
+   * int64x1_t vreinterpret_s64_u8 (uint8x8_t)
+
+   * int64x1_t vreinterpret_s64_u16 (uint16x4_t)
+
+   * int64x1_t vreinterpret_s64_u32 (uint32x2_t)
+
+   * uint64x1_t vreinterpret_u64_p8 (poly8x8_t)
+
+   * uint64x1_t vreinterpret_u64_p16 (poly16x4_t)
+
+   * uint64x1_t vreinterpret_u64_f32 (float32x2_t)
+
+   * uint64x1_t vreinterpret_u64_p64 (poly64x1_t)
+
+   * uint64x1_t vreinterpret_u64_s64 (int64x1_t)
+
+   * uint64x1_t vreinterpret_u64_s8 (int8x8_t)
+
+   * uint64x1_t vreinterpret_u64_s16 (int16x4_t)
+
+   * uint64x1_t vreinterpret_u64_s32 (int32x2_t)
+
+   * uint64x1_t vreinterpret_u64_u8 (uint8x8_t)
+
+   * uint64x1_t vreinterpret_u64_u16 (uint16x4_t)
+
+   * uint64x1_t vreinterpret_u64_u32 (uint32x2_t)
+
+   * int8x8_t vreinterpret_s8_p8 (poly8x8_t)
+
+   * int8x8_t vreinterpret_s8_p16 (poly16x4_t)
+
+   * int8x8_t vreinterpret_s8_f32 (float32x2_t)
+
+   * int8x8_t vreinterpret_s8_p64 (poly64x1_t)
+
+   * int8x8_t vreinterpret_s8_s64 (int64x1_t)
+
+   * int8x8_t vreinterpret_s8_u64 (uint64x1_t)
+
+   * int8x8_t vreinterpret_s8_s16 (int16x4_t)
+
+   * int8x8_t vreinterpret_s8_s32 (int32x2_t)
+
+   * int8x8_t vreinterpret_s8_u8 (uint8x8_t)
+
+   * int8x8_t vreinterpret_s8_u16 (uint16x4_t)
+
+   * int8x8_t vreinterpret_s8_u32 (uint32x2_t)
+
+   * int16x4_t vreinterpret_s16_p8 (poly8x8_t)
+
+   * int16x4_t vreinterpret_s16_p16 (poly16x4_t)
+
+   * int16x4_t vreinterpret_s16_f32 (float32x2_t)
+
+   * int16x4_t vreinterpret_s16_p64 (poly64x1_t)
+
+   * int16x4_t vreinterpret_s16_s64 (int64x1_t)
+
+   * int16x4_t vreinterpret_s16_u64 (uint64x1_t)
+
+   * int16x4_t vreinterpret_s16_s8 (int8x8_t)
+
+   * int16x4_t vreinterpret_s16_s32 (int32x2_t)
+
+   * int16x4_t vreinterpret_s16_u8 (uint8x8_t)
+
+   * int16x4_t vreinterpret_s16_u16 (uint16x4_t)
+
+   * int16x4_t vreinterpret_s16_u32 (uint32x2_t)
+
+   * int32x2_t vreinterpret_s32_p8 (poly8x8_t)
+
+   * int32x2_t vreinterpret_s32_p16 (poly16x4_t)
+
+   * int32x2_t vreinterpret_s32_f32 (float32x2_t)
+
+   * int32x2_t vreinterpret_s32_p64 (poly64x1_t)
+
+   * int32x2_t vreinterpret_s32_s64 (int64x1_t)
+
+   * int32x2_t vreinterpret_s32_u64 (uint64x1_t)
+
+   * int32x2_t vreinterpret_s32_s8 (int8x8_t)
+
+   * int32x2_t vreinterpret_s32_s16 (int16x4_t)
+
+   * int32x2_t vreinterpret_s32_u8 (uint8x8_t)
+
+   * int32x2_t vreinterpret_s32_u16 (uint16x4_t)
+
+   * int32x2_t vreinterpret_s32_u32 (uint32x2_t)
+
+   * uint8x8_t vreinterpret_u8_p8 (poly8x8_t)
+
+   * uint8x8_t vreinterpret_u8_p16 (poly16x4_t)
+
+   * uint8x8_t vreinterpret_u8_f32 (float32x2_t)
+
+   * uint8x8_t vreinterpret_u8_p64 (poly64x1_t)
+
+   * uint8x8_t vreinterpret_u8_s64 (int64x1_t)
+
+   * uint8x8_t vreinterpret_u8_u64 (uint64x1_t)
+
+   * uint8x8_t vreinterpret_u8_s8 (int8x8_t)
+
+   * uint8x8_t vreinterpret_u8_s16 (int16x4_t)
+
+   * uint8x8_t vreinterpret_u8_s32 (int32x2_t)
+
+   * uint8x8_t vreinterpret_u8_u16 (uint16x4_t)
+
+   * uint8x8_t vreinterpret_u8_u32 (uint32x2_t)
+
+   * uint16x4_t vreinterpret_u16_p8 (poly8x8_t)
+
+   * uint16x4_t vreinterpret_u16_p16 (poly16x4_t)
+
+   * uint16x4_t vreinterpret_u16_f32 (float32x2_t)
+
+   * uint16x4_t vreinterpret_u16_p64 (poly64x1_t)
+
+   * uint16x4_t vreinterpret_u16_s64 (int64x1_t)
+
+   * uint16x4_t vreinterpret_u16_u64 (uint64x1_t)
+
+   * uint16x4_t vreinterpret_u16_s8 (int8x8_t)
+
+   * uint16x4_t vreinterpret_u16_s16 (int16x4_t)
+
+   * uint16x4_t vreinterpret_u16_s32 (int32x2_t)
+
+   * uint16x4_t vreinterpret_u16_u8 (uint8x8_t)
+
+   * uint16x4_t vreinterpret_u16_u32 (uint32x2_t)
+
+   * uint32x2_t vreinterpret_u32_p8 (poly8x8_t)
+
+   * uint32x2_t vreinterpret_u32_p16 (poly16x4_t)
+
+   * uint32x2_t vreinterpret_u32_f32 (float32x2_t)
+
+   * uint32x2_t vreinterpret_u32_p64 (poly64x1_t)
+
+   * uint32x2_t vreinterpret_u32_s64 (int64x1_t)
+
+   * uint32x2_t vreinterpret_u32_u64 (uint64x1_t)
+
+   * uint32x2_t vreinterpret_u32_s8 (int8x8_t)
+
+   * uint32x2_t vreinterpret_u32_s16 (int16x4_t)
+
+   * uint32x2_t vreinterpret_u32_s32 (int32x2_t)
+
+   * uint32x2_t vreinterpret_u32_u8 (uint8x8_t)
+
+   * uint32x2_t vreinterpret_u32_u16 (uint16x4_t)
+
+   * poly8x16_t vreinterpretq_p8_p16 (poly16x8_t)
+
+   * poly8x16_t vreinterpretq_p8_f32 (float32x4_t)
+
+   * poly8x16_t vreinterpretq_p8_p64 (poly64x2_t)
+
+   * poly8x16_t vreinterpretq_p8_p128 (poly128_t)
+
+   * poly8x16_t vreinterpretq_p8_s64 (int64x2_t)
+
+   * poly8x16_t vreinterpretq_p8_u64 (uint64x2_t)
+
+   * poly8x16_t vreinterpretq_p8_s8 (int8x16_t)
+
+   * poly8x16_t vreinterpretq_p8_s16 (int16x8_t)
+
+   * poly8x16_t vreinterpretq_p8_s32 (int32x4_t)
+
+   * poly8x16_t vreinterpretq_p8_u8 (uint8x16_t)
+
+   * poly8x16_t vreinterpretq_p8_u16 (uint16x8_t)
+
+   * poly8x16_t vreinterpretq_p8_u32 (uint32x4_t)
+
+   * poly16x8_t vreinterpretq_p16_p8 (poly8x16_t)
+
+   * poly16x8_t vreinterpretq_p16_f32 (float32x4_t)
+
+   * poly16x8_t vreinterpretq_p16_p64 (poly64x2_t)
+
+   * poly16x8_t vreinterpretq_p16_p128 (poly128_t)
+
+   * poly16x8_t vreinterpretq_p16_s64 (int64x2_t)
+
+   * poly16x8_t vreinterpretq_p16_u64 (uint64x2_t)
+
+   * poly16x8_t vreinterpretq_p16_s8 (int8x16_t)
+
+   * poly16x8_t vreinterpretq_p16_s16 (int16x8_t)
+
+   * poly16x8_t vreinterpretq_p16_s32 (int32x4_t)
+
+   * poly16x8_t vreinterpretq_p16_u8 (uint8x16_t)
+
+   * poly16x8_t vreinterpretq_p16_u16 (uint16x8_t)
+
+   * poly16x8_t vreinterpretq_p16_u32 (uint32x4_t)
+
+   * float32x4_t vreinterpretq_f32_p8 (poly8x16_t)
+
+   * float32x4_t vreinterpretq_f32_p16 (poly16x8_t)
+
+   * float32x4_t vreinterpretq_f32_p64 (poly64x2_t)
+
+   * float32x4_t vreinterpretq_f32_p128 (poly128_t)
+
+   * float32x4_t vreinterpretq_f32_s64 (int64x2_t)
+
+   * float32x4_t vreinterpretq_f32_u64 (uint64x2_t)
+
+   * float32x4_t vreinterpretq_f32_s8 (int8x16_t)
+
+   * float32x4_t vreinterpretq_f32_s16 (int16x8_t)
+
+   * float32x4_t vreinterpretq_f32_s32 (int32x4_t)
+
+   * float32x4_t vreinterpretq_f32_u8 (uint8x16_t)
+
+   * float32x4_t vreinterpretq_f32_u16 (uint16x8_t)
+
+   * float32x4_t vreinterpretq_f32_u32 (uint32x4_t)
+
+   * poly64x2_t vreinterpretq_p64_p8 (poly8x16_t)
+
+   * poly64x2_t vreinterpretq_p64_p16 (poly16x8_t)
+
+   * poly64x2_t vreinterpretq_p64_f32 (float32x4_t)
+
+   * poly64x2_t vreinterpretq_p64_p128 (poly128_t)
+
+   * poly64x2_t vreinterpretq_p64_s64 (int64x2_t)
+
+   * poly64x2_t vreinterpretq_p64_u64 (uint64x2_t)
+
+   * poly64x2_t vreinterpretq_p64_s8 (int8x16_t)
+
+   * poly64x2_t vreinterpretq_p64_s16 (int16x8_t)
+
+   * poly64x2_t vreinterpretq_p64_s32 (int32x4_t)
+
+   * poly64x2_t vreinterpretq_p64_u8 (uint8x16_t)
+
+   * poly64x2_t vreinterpretq_p64_u16 (uint16x8_t)
+
+   * poly64x2_t vreinterpretq_p64_u32 (uint32x4_t)
+
+   * poly128_t vreinterpretq_p128_p8 (poly8x16_t)
+
+   * poly128_t vreinterpretq_p128_p16 (poly16x8_t)
+
+   * poly128_t vreinterpretq_p128_f32 (float32x4_t)
+
+   * poly128_t vreinterpretq_p128_p64 (poly64x2_t)
+
+   * poly128_t vreinterpretq_p128_s64 (int64x2_t)
+
+   * poly128_t vreinterpretq_p128_u64 (uint64x2_t)
+
+   * poly128_t vreinterpretq_p128_s8 (int8x16_t)
+
+   * poly128_t vreinterpretq_p128_s16 (int16x8_t)
+
+   * poly128_t vreinterpretq_p128_s32 (int32x4_t)
+
+   * poly128_t vreinterpretq_p128_u8 (uint8x16_t)
+
+   * poly128_t vreinterpretq_p128_u16 (uint16x8_t)
+
+   * poly128_t vreinterpretq_p128_u32 (uint32x4_t)
+
+   * int64x2_t vreinterpretq_s64_p8 (poly8x16_t)
+
+   * int64x2_t vreinterpretq_s64_p16 (poly16x8_t)
+
+   * int64x2_t vreinterpretq_s64_f32 (float32x4_t)
+
+   * int64x2_t vreinterpretq_s64_p64 (poly64x2_t)
+
+   * int64x2_t vreinterpretq_s64_p128 (poly128_t)
+
+   * int64x2_t vreinterpretq_s64_u64 (uint64x2_t)
+
+   * int64x2_t vreinterpretq_s64_s8 (int8x16_t)
+
+   * int64x2_t vreinterpretq_s64_s16 (int16x8_t)
+
+   * int64x2_t vreinterpretq_s64_s32 (int32x4_t)
+
+   * int64x2_t vreinterpretq_s64_u8 (uint8x16_t)
+
+   * int64x2_t vreinterpretq_s64_u16 (uint16x8_t)
+
+   * int64x2_t vreinterpretq_s64_u32 (uint32x4_t)
+
+   * uint64x2_t vreinterpretq_u64_p8 (poly8x16_t)
+
+   * uint64x2_t vreinterpretq_u64_p16 (poly16x8_t)
+
+   * uint64x2_t vreinterpretq_u64_f32 (float32x4_t)
+
+   * uint64x2_t vreinterpretq_u64_p64 (poly64x2_t)
+
+   * uint64x2_t vreinterpretq_u64_p128 (poly128_t)
+
+   * uint64x2_t vreinterpretq_u64_s64 (int64x2_t)
+
+   * uint64x2_t vreinterpretq_u64_s8 (int8x16_t)
+
+   * uint64x2_t vreinterpretq_u64_s16 (int16x8_t)
+
+   * uint64x2_t vreinterpretq_u64_s32 (int32x4_t)
+
+   * uint64x2_t vreinterpretq_u64_u8 (uint8x16_t)
+
+   * uint64x2_t vreinterpretq_u64_u16 (uint16x8_t)
+
+   * uint64x2_t vreinterpretq_u64_u32 (uint32x4_t)
+
+   * int8x16_t vreinterpretq_s8_p8 (poly8x16_t)
+
+   * int8x16_t vreinterpretq_s8_p16 (poly16x8_t)
+
+   * int8x16_t vreinterpretq_s8_f32 (float32x4_t)
+
+   * int8x16_t vreinterpretq_s8_p64 (poly64x2_t)
+
+   * int8x16_t vreinterpretq_s8_p128 (poly128_t)
+
+   * int8x16_t vreinterpretq_s8_s64 (int64x2_t)
+
+   * int8x16_t vreinterpretq_s8_u64 (uint64x2_t)
+
+   * int8x16_t vreinterpretq_s8_s16 (int16x8_t)
+
+   * int8x16_t vreinterpretq_s8_s32 (int32x4_t)
+
+   * int8x16_t vreinterpretq_s8_u8 (uint8x16_t)
+
+   * int8x16_t vreinterpretq_s8_u16 (uint16x8_t)
+
+   * int8x16_t vreinterpretq_s8_u32 (uint32x4_t)
+
+   * int16x8_t vreinterpretq_s16_p8 (poly8x16_t)
+
+   * int16x8_t vreinterpretq_s16_p16 (poly16x8_t)
+
+   * int16x8_t vreinterpretq_s16_f32 (float32x4_t)
+
+   * int16x8_t vreinterpretq_s16_p64 (poly64x2_t)
+
+   * int16x8_t vreinterpretq_s16_p128 (poly128_t)
+
+   * int16x8_t vreinterpretq_s16_s64 (int64x2_t)
+
+   * int16x8_t vreinterpretq_s16_u64 (uint64x2_t)
+
+   * int16x8_t vreinterpretq_s16_s8 (int8x16_t)
+
+   * int16x8_t vreinterpretq_s16_s32 (int32x4_t)
+
+   * int16x8_t vreinterpretq_s16_u8 (uint8x16_t)
+
+   * int16x8_t vreinterpretq_s16_u16 (uint16x8_t)
+
+   * int16x8_t vreinterpretq_s16_u32 (uint32x4_t)
+
+   * int32x4_t vreinterpretq_s32_p8 (poly8x16_t)
+
+   * int32x4_t vreinterpretq_s32_p16 (poly16x8_t)
+
+   * int32x4_t vreinterpretq_s32_f32 (float32x4_t)
+
+   * int32x4_t vreinterpretq_s32_p64 (poly64x2_t)
+
+   * int32x4_t vreinterpretq_s32_p128 (poly128_t)
+
+   * int32x4_t vreinterpretq_s32_s64 (int64x2_t)
+
+   * int32x4_t vreinterpretq_s32_u64 (uint64x2_t)
+
+   * int32x4_t vreinterpretq_s32_s8 (int8x16_t)
+
+   * int32x4_t vreinterpretq_s32_s16 (int16x8_t)
+
+   * int32x4_t vreinterpretq_s32_u8 (uint8x16_t)
+
+   * int32x4_t vreinterpretq_s32_u16 (uint16x8_t)
+
+   * int32x4_t vreinterpretq_s32_u32 (uint32x4_t)
+
+   * uint8x16_t vreinterpretq_u8_p8 (poly8x16_t)
+
+   * uint8x16_t vreinterpretq_u8_p16 (poly16x8_t)
+
+   * uint8x16_t vreinterpretq_u8_f32 (float32x4_t)
+
+   * uint8x16_t vreinterpretq_u8_p64 (poly64x2_t)
+
+   * uint8x16_t vreinterpretq_u8_p128 (poly128_t)
+
+   * uint8x16_t vreinterpretq_u8_s64 (int64x2_t)
+
+   * uint8x16_t vreinterpretq_u8_u64 (uint64x2_t)
+
+   * uint8x16_t vreinterpretq_u8_s8 (int8x16_t)
+
+   * uint8x16_t vreinterpretq_u8_s16 (int16x8_t)
+
+   * uint8x16_t vreinterpretq_u8_s32 (int32x4_t)
+
+   * uint8x16_t vreinterpretq_u8_u16 (uint16x8_t)
+
+   * uint8x16_t vreinterpretq_u8_u32 (uint32x4_t)
+
+   * uint16x8_t vreinterpretq_u16_p8 (poly8x16_t)
+
+   * uint16x8_t vreinterpretq_u16_p16 (poly16x8_t)
+
+   * uint16x8_t vreinterpretq_u16_f32 (float32x4_t)
+
+   * uint16x8_t vreinterpretq_u16_p64 (poly64x2_t)
+
+   * uint16x8_t vreinterpretq_u16_p128 (poly128_t)
+
+   * uint16x8_t vreinterpretq_u16_s64 (int64x2_t)
+
+   * uint16x8_t vreinterpretq_u16_u64 (uint64x2_t)
+
+   * uint16x8_t vreinterpretq_u16_s8 (int8x16_t)
+
+   * uint16x8_t vreinterpretq_u16_s16 (int16x8_t)
+
+   * uint16x8_t vreinterpretq_u16_s32 (int32x4_t)
+
+   * uint16x8_t vreinterpretq_u16_u8 (uint8x16_t)
+
+   * uint16x8_t vreinterpretq_u16_u32 (uint32x4_t)
+
+   * uint32x4_t vreinterpretq_u32_p8 (poly8x16_t)
+
+   * uint32x4_t vreinterpretq_u32_p16 (poly16x8_t)
+
+   * uint32x4_t vreinterpretq_u32_f32 (float32x4_t)
+
+   * uint32x4_t vreinterpretq_u32_p64 (poly64x2_t)
+
+   * uint32x4_t vreinterpretq_u32_p128 (poly128_t)
+
+   * uint32x4_t vreinterpretq_u32_s64 (int64x2_t)
+
+   * uint32x4_t vreinterpretq_u32_u64 (uint64x2_t)
+
+   * uint32x4_t vreinterpretq_u32_s8 (int8x16_t)
+
+   * uint32x4_t vreinterpretq_u32_s16 (int16x8_t)
+
+   * uint32x4_t vreinterpretq_u32_s32 (int32x4_t)
+
+   * uint32x4_t vreinterpretq_u32_u8 (uint8x16_t)
+
+   * uint32x4_t vreinterpretq_u32_u16 (uint16x8_t)
+
+   * poly128_t vldrq_p128(poly128_t const *)
+
+   * void vstrq_p128(poly128_t *, poly128_t)
+
+   * uint64x1_t vceq_p64 (poly64x1_t, poly64x1_t)
+
+   * uint64x1_t vtst_p64 (poly64x1_t, poly64x1_t)
+
+   * uint32_t vsha1h_u32 (uint32_t)
+     _Form of expected instruction(s):_ 'sha1h.32 Q0, Q1'
+
+   * uint32x4_t vsha1cq_u32 (uint32x4_t, uint32_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha1c.32 Q0, Q1, Q2'
+
+   * uint32x4_t vsha1pq_u32 (uint32x4_t, uint32_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha1p.32 Q0, Q1, Q2'
+
+   * uint32x4_t vsha1mq_u32 (uint32x4_t, uint32_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha1m.32 Q0, Q1, Q2'
+
+   * uint32x4_t vsha1su0q_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha1su0.32 Q0, Q1, Q2'
+
+   * uint32x4_t vsha1su1q_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha1su1.32 Q0, Q1, Q2'
+
+   * uint32x4_t vsha256hq_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha256h.32 Q0, Q1, Q2'
+
+   * uint32x4_t vsha256h2q_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha256h2.32 Q0, Q1, Q2'
+
+   * uint32x4_t vsha256su0q_u32 (uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha256su0.32 Q0, Q1'
+
+   * uint32x4_t vsha256su1q_u32 (uint32x4_t, uint32x4_t, uint32x4_t)
+     _Form of expected instruction(s):_ 'sha256su1.32 Q0, Q1, Q2'
+
+   * poly128_t vmull_p64 (poly64_t a, poly64_t b)
+     _Form of expected instruction(s):_ 'vmull.p64 Q0, D1, D2'
+
+   * poly128_t vmull_high_p64 (poly64x2_t a, poly64x2_t b)
+     _Form of expected instruction(s):_ 'vmull.p64 Q0, D1, D2'
+
+
+File: gcc.info,  Node: ARM ACLE Intrinsics,  Next: AVR Built-in Functions,  Prev: ARM NEON Intrinsics,  Up: Target Builtins
+
+6.57.7 ARM ACLE Intrinsics
+--------------------------
+
+These built-in intrinsics for the ARMv8-A CRC32 extension are available
+when the '-march=armv8-a+crc' switch is used:
+
+6.57.7.1 CRC32 intrinsics
+.........................
+
+   * uint32_t __crc32b (uint32_t, uint8_t)
+     _Form of expected instruction(s):_ 'crc32b R0, R0, R0'
+
+   * uint32_t __crc32h (uint32_t, uint16_t)
+     _Form of expected instruction(s):_ 'crc32h R0, R0, R0'
+
+   * uint32_t __crc32w (uint32_t, uint32_t)
+     _Form of expected instruction(s):_ 'crc32w R0, R0, R0'
+
+   * uint32_t __crc32d (uint32_t, uint64_t)
+     _Form of expected instruction(s):_ Two 'crc32w R0, R0, R0'
+     instructions for AArch32.  One 'crc32w W0, W0, X0' instruction for
+     AArch64.
+
+   * uint32_t __crc32cb (uint32_t, uint8_t)
+     _Form of expected instruction(s):_ 'crc32cb R0, R0, R0'
+
+   * uint32_t __crc32ch (uint32_t, uint16_t)
+     _Form of expected instruction(s):_ 'crc32ch R0, R0, R0'
+
+   * uint32_t __crc32cw (uint32_t, uint32_t)
+     _Form of expected instruction(s):_ 'crc32cw R0, R0, R0'
+
+   * uint32_t __crc32cd (uint32_t, uint64_t)
+     _Form of expected instruction(s):_ Two 'crc32cw R0, R0, R0'
+     instructions for AArch32.  One 'crc32cw W0, W0, X0' instruction for
+     AArch64.
+
+
+File: gcc.info,  Node: AVR Built-in Functions,  Next: Blackfin Built-in Functions,  Prev: ARM ACLE Intrinsics,  Up: Target Builtins
+
+6.57.8 AVR Built-in Functions
+-----------------------------
+
+For each built-in function for AVR, there is an equally named, uppercase
+built-in macro defined.  That way users can easily query if or if not a
+specific built-in is implemented or not.  For example, if
+'__builtin_avr_nop' is available the macro '__BUILTIN_AVR_NOP' is
+defined to '1' and undefined otherwise.
+
+ The following built-in functions map to the respective machine
+instruction, i.e. 'nop', 'sei', 'cli', 'sleep', 'wdr', 'swap', 'fmul',
+'fmuls' resp.  'fmulsu'.  The three 'fmul*' built-ins are implemented as
+library call if no hardware multiplier is available.
+
+     void __builtin_avr_nop (void)
+     void __builtin_avr_sei (void)
+     void __builtin_avr_cli (void)
+     void __builtin_avr_sleep (void)
+     void __builtin_avr_wdr (void)
+     unsigned char __builtin_avr_swap (unsigned char)
+     unsigned int __builtin_avr_fmul (unsigned char, unsigned char)
+     int __builtin_avr_fmuls (char, char)
+     int __builtin_avr_fmulsu (char, unsigned char)
+
+ In order to delay execution for a specific number of cycles, GCC
+implements
+     void __builtin_avr_delay_cycles (unsigned long ticks)
+
+'ticks' is the number of ticks to delay execution.  Note that this
+built-in does not take into account the effect of interrupts that might
+increase delay time.  'ticks' must be a compile-time integer constant;
+delays with a variable number of cycles are not supported.
+
+     char __builtin_avr_flash_segment (const __memx void*)
+
+This built-in takes a byte address to the 24-bit *note address space:
+AVR Named Address Spaces. '__memx' and returns the number of the flash
+segment (the 64 KiB chunk) where the address points to.  Counting starts
+at '0'.  If the address does not point to flash memory, return '-1'.
+
+     unsigned char __builtin_avr_insert_bits (unsigned long map, unsigned char bits, unsigned char val)
+
+Insert bits from BITS into VAL and return the resulting value.  The
+nibbles of MAP determine how the insertion is performed: Let X be the
+N-th nibble of MAP
+  1. If X is '0xf', then the N-th bit of VAL is returned unaltered.
+
+  2. If X is in the range 0...7, then the N-th result bit is set to the
+     X-th bit of BITS
+
+  3. If X is in the range 8...'0xe', then the N-th result bit is
+     undefined.
+
+One typical use case for this built-in is adjusting input and output
+values to non-contiguous port layouts.  Some examples:
+
+     // same as val, bits is unused
+     __builtin_avr_insert_bits (0xffffffff, bits, val)
+
+     // same as bits, val is unused
+     __builtin_avr_insert_bits (0x76543210, bits, val)
+
+     // same as rotating bits by 4
+     __builtin_avr_insert_bits (0x32107654, bits, 0)
+
+     // high nibble of result is the high nibble of val
+     // low nibble of result is the low nibble of bits
+     __builtin_avr_insert_bits (0xffff3210, bits, val)
+
+     // reverse the bit order of bits
+     __builtin_avr_insert_bits (0x01234567, bits, 0)
+
+
+File: gcc.info,  Node: Blackfin Built-in Functions,  Next: FR-V Built-in Functions,  Prev: AVR Built-in Functions,  Up: Target Builtins
+
+6.57.9 Blackfin Built-in Functions
+----------------------------------
+
+Currently, there are two Blackfin-specific built-in functions.  These
+are used for generating 'CSYNC' and 'SSYNC' machine insns without using
+inline assembly; by using these built-in functions the compiler can
+automatically add workarounds for hardware errata involving these
+instructions.  These functions are named as follows:
+
+     void __builtin_bfin_csync (void)
+     void __builtin_bfin_ssync (void)
+
+
+File: gcc.info,  Node: FR-V Built-in Functions,  Next: X86 Built-in Functions,  Prev: Blackfin Built-in Functions,  Up: Target Builtins
+
+6.57.10 FR-V Built-in Functions
+-------------------------------
+
+GCC provides many FR-V-specific built-in functions.  In general, these
+functions are intended to be compatible with those described by 'FR-V
+Family, Softune C/C++ Compiler Manual (V6), Fujitsu Semiconductor'.  The
+two exceptions are '__MDUNPACKH' and '__MBTOHE', the GCC forms of which
+pass 128-bit values by pointer rather than by value.
+
+ Most of the functions are named after specific FR-V instructions.  Such
+functions are said to be "directly mapped" and are summarized here in
+tabular form.
+
+* Menu:
+
+* Argument Types::
+* Directly-mapped Integer Functions::
+* Directly-mapped Media Functions::
+* Raw read/write Functions::
+* Other Built-in Functions::
+
+
+File: gcc.info,  Node: Argument Types,  Next: Directly-mapped Integer Functions,  Up: FR-V Built-in Functions
+
+6.57.10.1 Argument Types
+........................
+
+The arguments to the built-in functions can be divided into three
+groups: register numbers, compile-time constants and run-time values.
+In order to make this classification clear at a glance, the arguments
+and return values are given the following pseudo types:
+
+Pseudo type    Real C type            Constant?   Description
+'uh'           'unsigned short'       No          an unsigned halfword
+'uw1'          'unsigned int'         No          an unsigned word
+'sw1'          'int'                  No          a signed word
+'uw2'          'unsigned long long'   No          an unsigned doubleword
+'sw2'          'long long'            No          a signed doubleword
+'const'        'int'                  Yes         an integer constant
+'acc'          'int'                  Yes         an ACC register number
+'iacc'         'int'                  Yes         an IACC register number
+
+ These pseudo types are not defined by GCC, they are simply a notational
+convenience used in this manual.
+
+ Arguments of type 'uh', 'uw1', 'sw1', 'uw2' and 'sw2' are evaluated at
+run time.  They correspond to register operands in the underlying FR-V
+instructions.
+
+ 'const' arguments represent immediate operands in the underlying FR-V
+instructions.  They must be compile-time constants.
+
+ 'acc' arguments are evaluated at compile time and specify the number of
+an accumulator register.  For example, an 'acc' argument of 2 selects
+the ACC2 register.
+
+ 'iacc' arguments are similar to 'acc' arguments but specify the number
+of an IACC register.  See *note Other Built-in Functions:: for more
+details.
+
+
+File: gcc.info,  Node: Directly-mapped Integer Functions,  Next: Directly-mapped Media Functions,  Prev: Argument Types,  Up: FR-V Built-in Functions
+
+6.57.10.2 Directly-mapped Integer Functions
+...........................................
+
+The functions listed below map directly to FR-V I-type instructions.
+
+Function prototype               Example usage           Assembly output
+'sw1 __ADDSS (sw1, sw1)'         'C = __ADDSS (A, B)'    'ADDSS A,B,C'
+'sw1 __SCAN (sw1, sw1)'          'C = __SCAN (A, B)'     'SCAN A,B,C'
+'sw1 __SCUTSS (sw1)'             'B = __SCUTSS (A)'      'SCUTSS A,B'
+'sw1 __SLASS (sw1, sw1)'         'C = __SLASS (A, B)'    'SLASS A,B,C'
+'void __SMASS (sw1, sw1)'        '__SMASS (A, B)'        'SMASS A,B'
+'void __SMSSS (sw1, sw1)'        '__SMSSS (A, B)'        'SMSSS A,B'
+'void __SMU (sw1, sw1)'          '__SMU (A, B)'          'SMU A,B'
+'sw2 __SMUL (sw1, sw1)'          'C = __SMUL (A, B)'     'SMUL A,B,C'
+'sw1 __SUBSS (sw1, sw1)'         'C = __SUBSS (A, B)'    'SUBSS A,B,C'
+'uw2 __UMUL (uw1, uw1)'          'C = __UMUL (A, B)'     'UMUL A,B,C'
+
+
+File: gcc.info,  Node: Directly-mapped Media Functions,  Next: Raw read/write Functions,  Prev: Directly-mapped Integer Functions,  Up: FR-V Built-in Functions
+
+6.57.10.3 Directly-mapped Media Functions
+.........................................
+
+The functions listed below map directly to FR-V M-type instructions.
+
+Function prototype               Example usage           Assembly output
+'uw1 __MABSHS (sw1)'             'B = __MABSHS (A)'      'MABSHS A,B'
+'void __MADDACCS (acc, acc)'     '__MADDACCS (B, A)'     'MADDACCS A,B'
+'sw1 __MADDHSS (sw1, sw1)'       'C = __MADDHSS (A,      'MADDHSS A,B,C'
+                                 B)'
+'uw1 __MADDHUS (uw1, uw1)'       'C = __MADDHUS (A,      'MADDHUS A,B,C'
+                                 B)'
+'uw1 __MAND (uw1, uw1)'          'C = __MAND (A, B)'     'MAND A,B,C'
+'void __MASACCS (acc, acc)'      '__MASACCS (B, A)'      'MASACCS A,B'
+'uw1 __MAVEH (uw1, uw1)'         'C = __MAVEH (A, B)'    'MAVEH A,B,C'
+'uw2 __MBTOH (uw1)'              'B = __MBTOH (A)'       'MBTOH A,B'
+'void __MBTOHE (uw1 *, uw1)'     '__MBTOHE (&B, A)'      'MBTOHE A,B'
+'void __MCLRACC (acc)'           '__MCLRACC (A)'         'MCLRACC A'
+'void __MCLRACCA (void)'         '__MCLRACCA ()'         'MCLRACCA'
+'uw1 __Mcop1 (uw1, uw1)'         'C = __Mcop1 (A, B)'    'Mcop1 A,B,C'
+'uw1 __Mcop2 (uw1, uw1)'         'C = __Mcop2 (A, B)'    'Mcop2 A,B,C'
+'uw1 __MCPLHI (uw2, const)'      'C = __MCPLHI (A, B)'   'MCPLHI A,#B,C'
+'uw1 __MCPLI (uw2, const)'       'C = __MCPLI (A, B)'    'MCPLI A,#B,C'
+'void __MCPXIS (acc, sw1,        '__MCPXIS (C, A, B)'    'MCPXIS A,B,C'
+sw1)'
+'void __MCPXIU (acc, uw1,        '__MCPXIU (C, A, B)'    'MCPXIU A,B,C'
+uw1)'
+'void __MCPXRS (acc, sw1,        '__MCPXRS (C, A, B)'    'MCPXRS A,B,C'
+sw1)'
+'void __MCPXRU (acc, uw1,        '__MCPXRU (C, A, B)'    'MCPXRU A,B,C'
+uw1)'
+'uw1 __MCUT (acc, uw1)'          'C = __MCUT (A, B)'     'MCUT A,B,C'
+'uw1 __MCUTSS (acc, sw1)'        'C = __MCUTSS (A, B)'   'MCUTSS A,B,C'
+'void __MDADDACCS (acc, acc)'    '__MDADDACCS (B, A)'    'MDADDACCS A,B'
+'void __MDASACCS (acc, acc)'     '__MDASACCS (B, A)'     'MDASACCS A,B'
+'uw2 __MDCUTSSI (acc, const)'    'C = __MDCUTSSI (A,     'MDCUTSSI
+                                 B)'                     A,#B,C'
+'uw2 __MDPACKH (uw2, uw2)'       'C = __MDPACKH (A,      'MDPACKH A,B,C'
+                                 B)'
+'uw2 __MDROTLI (uw2, const)'     'C = __MDROTLI (A,      'MDROTLI
+                                 B)'                     A,#B,C'
+'void __MDSUBACCS (acc, acc)'    '__MDSUBACCS (B, A)'    'MDSUBACCS A,B'
+'void __MDUNPACKH (uw1 *,        '__MDUNPACKH (&B, A)'   'MDUNPACKH A,B'
+uw2)'
+'uw2 __MEXPDHD (uw1, const)'     'C = __MEXPDHD (A,      'MEXPDHD
+                                 B)'                     A,#B,C'
+'uw1 __MEXPDHW (uw1, const)'     'C = __MEXPDHW (A,      'MEXPDHW
+                                 B)'                     A,#B,C'
+'uw1 __MHDSETH (uw1, const)'     'C = __MHDSETH (A,      'MHDSETH
+                                 B)'                     A,#B,C'
+'sw1 __MHDSETS (const)'          'B = __MHDSETS (A)'     'MHDSETS #A,B'
+'uw1 __MHSETHIH (uw1, const)'    'B = __MHSETHIH (B,     'MHSETHIH #A,B'
+                                 A)'
+'sw1 __MHSETHIS (sw1, const)'    'B = __MHSETHIS (B,     'MHSETHIS #A,B'
+                                 A)'
+'uw1 __MHSETLOH (uw1, const)'    'B = __MHSETLOH (B,     'MHSETLOH #A,B'
+                                 A)'
+'sw1 __MHSETLOS (sw1, const)'    'B = __MHSETLOS (B,     'MHSETLOS #A,B'
+                                 A)'
+'uw1 __MHTOB (uw2)'              'B = __MHTOB (A)'       'MHTOB A,B'
+'void __MMACHS (acc, sw1,        '__MMACHS (C, A, B)'    'MMACHS A,B,C'
+sw1)'
+'void __MMACHU (acc, uw1,        '__MMACHU (C, A, B)'    'MMACHU A,B,C'
+uw1)'
+'void __MMRDHS (acc, sw1,        '__MMRDHS (C, A, B)'    'MMRDHS A,B,C'
+sw1)'
+'void __MMRDHU (acc, uw1,        '__MMRDHU (C, A, B)'    'MMRDHU A,B,C'
+uw1)'
+'void __MMULHS (acc, sw1,        '__MMULHS (C, A, B)'    'MMULHS A,B,C'
+sw1)'
+'void __MMULHU (acc, uw1,        '__MMULHU (C, A, B)'    'MMULHU A,B,C'
+uw1)'
+'void __MMULXHS (acc, sw1,       '__MMULXHS (C, A, B)'   'MMULXHS A,B,C'
+sw1)'
+'void __MMULXHU (acc, uw1,       '__MMULXHU (C, A, B)'   'MMULXHU A,B,C'
+uw1)'
+'uw1 __MNOT (uw1)'               'B = __MNOT (A)'        'MNOT A,B'
+'uw1 __MOR (uw1, uw1)'           'C = __MOR (A, B)'      'MOR A,B,C'
+'uw1 __MPACKH (uh, uh)'          'C = __MPACKH (A, B)'   'MPACKH A,B,C'
+'sw2 __MQADDHSS (sw2, sw2)'      'C = __MQADDHSS (A,     'MQADDHSS
+                                 B)'                     A,B,C'
+'uw2 __MQADDHUS (uw2, uw2)'      'C = __MQADDHUS (A,     'MQADDHUS
+                                 B)'                     A,B,C'
+'void __MQCPXIS (acc, sw2,       '__MQCPXIS (C, A, B)'   'MQCPXIS A,B,C'
+sw2)'
+'void __MQCPXIU (acc, uw2,       '__MQCPXIU (C, A, B)'   'MQCPXIU A,B,C'
+uw2)'
+'void __MQCPXRS (acc, sw2,       '__MQCPXRS (C, A, B)'   'MQCPXRS A,B,C'
+sw2)'
+'void __MQCPXRU (acc, uw2,       '__MQCPXRU (C, A, B)'   'MQCPXRU A,B,C'
+uw2)'
+'sw2 __MQLCLRHS (sw2, sw2)'      'C = __MQLCLRHS (A,     'MQLCLRHS
+                                 B)'                     A,B,C'
+'sw2 __MQLMTHS (sw2, sw2)'       'C = __MQLMTHS (A,      'MQLMTHS A,B,C'
+                                 B)'
+'void __MQMACHS (acc, sw2,       '__MQMACHS (C, A, B)'   'MQMACHS A,B,C'
+sw2)'
+'void __MQMACHU (acc, uw2,       '__MQMACHU (C, A, B)'   'MQMACHU A,B,C'
+uw2)'
+'void __MQMACXHS (acc, sw2,      '__MQMACXHS (C, A,      'MQMACXHS
+sw2)'                            B)'                     A,B,C'
+'void __MQMULHS (acc, sw2,       '__MQMULHS (C, A, B)'   'MQMULHS A,B,C'
+sw2)'
+'void __MQMULHU (acc, uw2,       '__MQMULHU (C, A, B)'   'MQMULHU A,B,C'
+uw2)'
+'void __MQMULXHS (acc, sw2,      '__MQMULXHS (C, A,      'MQMULXHS
+sw2)'                            B)'                     A,B,C'
+'void __MQMULXHU (acc, uw2,      '__MQMULXHU (C, A,      'MQMULXHU
+uw2)'                            B)'                     A,B,C'
+'sw2 __MQSATHS (sw2, sw2)'       'C = __MQSATHS (A,      'MQSATHS A,B,C'
+                                 B)'
+'uw2 __MQSLLHI (uw2, int)'       'C = __MQSLLHI (A,      'MQSLLHI A,B,C'
+                                 B)'
+'sw2 __MQSRAHI (sw2, int)'       'C = __MQSRAHI (A,      'MQSRAHI A,B,C'
+                                 B)'
+'sw2 __MQSUBHSS (sw2, sw2)'      'C = __MQSUBHSS (A,     'MQSUBHSS
+                                 B)'                     A,B,C'
+'uw2 __MQSUBHUS (uw2, uw2)'      'C = __MQSUBHUS (A,     'MQSUBHUS
+                                 B)'                     A,B,C'
+'void __MQXMACHS (acc, sw2,      '__MQXMACHS (C, A,      'MQXMACHS
+sw2)'                            B)'                     A,B,C'
+'void __MQXMACXHS (acc, sw2,     '__MQXMACXHS (C, A,     'MQXMACXHS
+sw2)'                            B)'                     A,B,C'
+'uw1 __MRDACC (acc)'             'B = __MRDACC (A)'      'MRDACC A,B'
+'uw1 __MRDACCG (acc)'            'B = __MRDACCG (A)'     'MRDACCG A,B'
+'uw1 __MROTLI (uw1, const)'      'C = __MROTLI (A, B)'   'MROTLI A,#B,C'
+'uw1 __MROTRI (uw1, const)'      'C = __MROTRI (A, B)'   'MROTRI A,#B,C'
+'sw1 __MSATHS (sw1, sw1)'        'C = __MSATHS (A, B)'   'MSATHS A,B,C'
+'uw1 __MSATHU (uw1, uw1)'        'C = __MSATHU (A, B)'   'MSATHU A,B,C'
+'uw1 __MSLLHI (uw1, const)'      'C = __MSLLHI (A, B)'   'MSLLHI A,#B,C'
+'sw1 __MSRAHI (sw1, const)'      'C = __MSRAHI (A, B)'   'MSRAHI A,#B,C'
+'uw1 __MSRLHI (uw1, const)'      'C = __MSRLHI (A, B)'   'MSRLHI A,#B,C'
+'void __MSUBACCS (acc, acc)'     '__MSUBACCS (B, A)'     'MSUBACCS A,B'
+'sw1 __MSUBHSS (sw1, sw1)'       'C = __MSUBHSS (A,      'MSUBHSS A,B,C'
+                                 B)'
+'uw1 __MSUBHUS (uw1, uw1)'       'C = __MSUBHUS (A,      'MSUBHUS A,B,C'
+                                 B)'
+'void __MTRAP (void)'            '__MTRAP ()'            'MTRAP'
+'uw2 __MUNPACKH (uw1)'           'B = __MUNPACKH (A)'    'MUNPACKH A,B'
+'uw1 __MWCUT (uw2, uw1)'         'C = __MWCUT (A, B)'    'MWCUT A,B,C'
+'void __MWTACC (acc, uw1)'       '__MWTACC (B, A)'       'MWTACC A,B'
+'void __MWTACCG (acc, uw1)'      '__MWTACCG (B, A)'      'MWTACCG A,B'
+'uw1 __MXOR (uw1, uw1)'          'C = __MXOR (A, B)'     'MXOR A,B,C'
+
+
+File: gcc.info,  Node: Raw read/write Functions,  Next: Other Built-in Functions,  Prev: Directly-mapped Media Functions,  Up: FR-V Built-in Functions
+
+6.57.10.4 Raw read/write Functions
+..................................
+
+This sections describes built-in functions related to read and write
+instructions to access memory.  These functions generate 'membar'
+instructions to flush the I/O load and stores where appropriate, as
+described in Fujitsu's manual described above.
+
+'unsigned char __builtin_read8 (void *DATA)'
+'unsigned short __builtin_read16 (void *DATA)'
+'unsigned long __builtin_read32 (void *DATA)'
+'unsigned long long __builtin_read64 (void *DATA)'
+
+'void __builtin_write8 (void *DATA, unsigned char DATUM)'
+'void __builtin_write16 (void *DATA, unsigned short DATUM)'
+'void __builtin_write32 (void *DATA, unsigned long DATUM)'
+'void __builtin_write64 (void *DATA, unsigned long long DATUM)'
+
+
+File: gcc.info,  Node: Other Built-in Functions,  Prev: Raw read/write Functions,  Up: FR-V Built-in Functions
+
+6.57.10.5 Other Built-in Functions
+..................................
+
+This section describes built-in functions that are not named after a
+specific FR-V instruction.
+
+'sw2 __IACCreadll (iacc REG)'
+     Return the full 64-bit value of IACC0.  The REG argument is
+     reserved for future expansion and must be 0.
+
+'sw1 __IACCreadl (iacc REG)'
+     Return the value of IACC0H if REG is 0 and IACC0L if REG is 1.
+     Other values of REG are rejected as invalid.
+
+'void __IACCsetll (iacc REG, sw2 X)'
+     Set the full 64-bit value of IACC0 to X.  The REG argument is
+     reserved for future expansion and must be 0.
+
+'void __IACCsetl (iacc REG, sw1 X)'
+     Set IACC0H to X if REG is 0 and IACC0L to X if REG is 1.  Other
+     values of REG are rejected as invalid.
+
+'void __data_prefetch0 (const void *X)'
+     Use the 'dcpl' instruction to load the contents of address X into
+     the data cache.
+
+'void __data_prefetch (const void *X)'
+     Use the 'nldub' instruction to load the contents of address X into
+     the data cache.  The instruction is issued in slot I1.
+
+
+File: gcc.info,  Node: X86 Built-in Functions,  Next: X86 transactional memory intrinsics,  Prev: FR-V Built-in Functions,  Up: Target Builtins
+
+6.57.11 X86 Built-in Functions
+------------------------------
+
+These built-in functions are available for the i386 and x86-64 family of
+computers, depending on the command-line switches used.
+
+ If you specify command-line switches such as '-msse', the compiler
+could use the extended instruction sets even if the built-ins are not
+used explicitly in the program.  For this reason, applications that
+perform run-time CPU detection must compile separate files for each
+supported architecture, using the appropriate flags.  In particular, the
+file containing the CPU detection code should be compiled without these
+options.
+
+ The following machine modes are available for use with MMX built-in
+functions (*note Vector Extensions::): 'V2SI' for a vector of two 32-bit
+integers, 'V4HI' for a vector of four 16-bit integers, and 'V8QI' for a
+vector of eight 8-bit integers.  Some of the built-in functions operate
+on MMX registers as a whole 64-bit entity, these use 'V1DI' as their
+mode.
+
+ If 3DNow! extensions are enabled, 'V2SF' is used as a mode for a vector
+of two 32-bit floating-point values.
+
+ If SSE extensions are enabled, 'V4SF' is used for a vector of four
+32-bit floating-point values.  Some instructions use a vector of four
+32-bit integers, these use 'V4SI'.  Finally, some instructions operate
+on an entire vector register, interpreting it as a 128-bit integer,
+these use mode 'TI'.
+
+ In 64-bit mode, the x86-64 family of processors uses additional
+built-in functions for efficient use of 'TF' ('__float128') 128-bit
+floating point and 'TC' 128-bit complex floating-point values.
+
+ The following floating-point built-in functions are available in 64-bit
+mode.  All of them implement the function that is part of the name.
+
+     __float128 __builtin_fabsq (__float128)
+     __float128 __builtin_copysignq (__float128, __float128)
+
+ The following built-in function is always available.
+
+'void __builtin_ia32_pause (void)'
+     Generates the 'pause' machine instruction with a compiler memory
+     barrier.
+
+ The following floating-point built-in functions are made available in
+the 64-bit mode.
+
+'__float128 __builtin_infq (void)'
+     Similar to '__builtin_inf', except the return type is '__float128'.
+
+'__float128 __builtin_huge_valq (void)'
+     Similar to '__builtin_huge_val', except the return type is
+     '__float128'.
+
+ The following built-in functions are always available and can be used
+to check the target platform type.
+
+ -- Built-in Function: void __builtin_cpu_init (void)
+     This function runs the CPU detection code to check the type of CPU
+     and the features supported.  This built-in function needs to be
+     invoked along with the built-in functions to check CPU type and
+     features, '__builtin_cpu_is' and '__builtin_cpu_supports', only
+     when used in a function that is executed before any constructors
+     are called.  The CPU detection code is automatically executed in a
+     very high priority constructor.
+
+     For example, this function has to be used in 'ifunc' resolvers that
+     check for CPU type using the built-in functions '__builtin_cpu_is'
+     and '__builtin_cpu_supports', or in constructors on targets that
+     don't support constructor priority.
+
+          static void (*resolve_memcpy (void)) (void)
+          {
+            // ifunc resolvers fire before constructors, explicitly call the init
+            // function.
+            __builtin_cpu_init ();
+            if (__builtin_cpu_supports ("ssse3"))
+              return ssse3_memcpy; // super fast memcpy with ssse3 instructions.
+            else
+              return default_memcpy;
+          }
+
+          void *memcpy (void *, const void *, size_t)
+               __attribute__ ((ifunc ("resolve_memcpy")));
+
+ -- Built-in Function: int __builtin_cpu_is (const char *CPUNAME)
+     This function returns a positive integer if the run-time CPU is of
+     type CPUNAME and returns '0' otherwise.  The following CPU names
+     can be detected:
+
+     'intel'
+          Intel CPU.
+
+     'atom'
+          Intel Atom CPU.
+
+     'core2'
+          Intel Core 2 CPU.
+
+     'corei7'
+          Intel Core i7 CPU.
+
+     'nehalem'
+          Intel Core i7 Nehalem CPU.
+
+     'westmere'
+          Intel Core i7 Westmere CPU.
+
+     'sandybridge'
+          Intel Core i7 Sandy Bridge CPU.
+
+     'amd'
+          AMD CPU.
+
+     'amdfam10h'
+          AMD Family 10h CPU.
+
+     'barcelona'
+          AMD Family 10h Barcelona CPU.
+
+     'shanghai'
+          AMD Family 10h Shanghai CPU.
+
+     'istanbul'
+          AMD Family 10h Istanbul CPU.
+
+     'btver1'
+          AMD Family 14h CPU.
+
+     'amdfam15h'
+          AMD Family 15h CPU.
+
+     'bdver1'
+          AMD Family 15h Bulldozer version 1.
+
+     'bdver2'
+          AMD Family 15h Bulldozer version 2.
+
+     'bdver3'
+          AMD Family 15h Bulldozer version 3.
+
+     'bdver4'
+          AMD Family 15h Bulldozer version 4.
+
+     'btver2'
+          AMD Family 16h CPU.
+
+     Here is an example:
+          if (__builtin_cpu_is ("corei7"))
+            {
+               do_corei7 (); // Core i7 specific implementation.
+            }
+          else
+            {
+               do_generic (); // Generic implementation.
+            }
+
+ -- Built-in Function: int __builtin_cpu_supports (const char *FEATURE)
+     This function returns a positive integer if the run-time CPU
+     supports FEATURE and returns '0' otherwise.  The following features
+     can be detected:
+
+     'cmov'
+          CMOV instruction.
+     'mmx'
+          MMX instructions.
+     'popcnt'
+          POPCNT instruction.
+     'sse'
+          SSE instructions.
+     'sse2'
+          SSE2 instructions.
+     'sse3'
+          SSE3 instructions.
+     'ssse3'
+          SSSE3 instructions.
+     'sse4.1'
+          SSE4.1 instructions.
+     'sse4.2'
+          SSE4.2 instructions.
+     'avx'
+          AVX instructions.
+     'avx2'
+          AVX2 instructions.
+
+     Here is an example:
+          if (__builtin_cpu_supports ("popcnt"))
+            {
+               asm("popcnt %1,%0" : "=r"(count) : "rm"(n) : "cc");
+            }
+          else
+            {
+               count = generic_countbits (n); //generic implementation.
+            }
+
+ The following built-in functions are made available by '-mmmx'.  All of
+them generate the machine instruction that is part of the name.
+
+     v8qi __builtin_ia32_paddb (v8qi, v8qi)
+     v4hi __builtin_ia32_paddw (v4hi, v4hi)
+     v2si __builtin_ia32_paddd (v2si, v2si)
+     v8qi __builtin_ia32_psubb (v8qi, v8qi)
+     v4hi __builtin_ia32_psubw (v4hi, v4hi)
+     v2si __builtin_ia32_psubd (v2si, v2si)
+     v8qi __builtin_ia32_paddsb (v8qi, v8qi)
+     v4hi __builtin_ia32_paddsw (v4hi, v4hi)
+     v8qi __builtin_ia32_psubsb (v8qi, v8qi)
+     v4hi __builtin_ia32_psubsw (v4hi, v4hi)
+     v8qi __builtin_ia32_paddusb (v8qi, v8qi)
+     v4hi __builtin_ia32_paddusw (v4hi, v4hi)
+     v8qi __builtin_ia32_psubusb (v8qi, v8qi)
+     v4hi __builtin_ia32_psubusw (v4hi, v4hi)
+     v4hi __builtin_ia32_pmullw (v4hi, v4hi)
+     v4hi __builtin_ia32_pmulhw (v4hi, v4hi)
+     di __builtin_ia32_pand (di, di)
+     di __builtin_ia32_pandn (di,di)
+     di __builtin_ia32_por (di, di)
+     di __builtin_ia32_pxor (di, di)
+     v8qi __builtin_ia32_pcmpeqb (v8qi, v8qi)
+     v4hi __builtin_ia32_pcmpeqw (v4hi, v4hi)
+     v2si __builtin_ia32_pcmpeqd (v2si, v2si)
+     v8qi __builtin_ia32_pcmpgtb (v8qi, v8qi)
+     v4hi __builtin_ia32_pcmpgtw (v4hi, v4hi)
+     v2si __builtin_ia32_pcmpgtd (v2si, v2si)
+     v8qi __builtin_ia32_punpckhbw (v8qi, v8qi)
+     v4hi __builtin_ia32_punpckhwd (v4hi, v4hi)
+     v2si __builtin_ia32_punpckhdq (v2si, v2si)
+     v8qi __builtin_ia32_punpcklbw (v8qi, v8qi)
+     v4hi __builtin_ia32_punpcklwd (v4hi, v4hi)
+     v2si __builtin_ia32_punpckldq (v2si, v2si)
+     v8qi __builtin_ia32_packsswb (v4hi, v4hi)
+     v4hi __builtin_ia32_packssdw (v2si, v2si)
+     v8qi __builtin_ia32_packuswb (v4hi, v4hi)
+
+     v4hi __builtin_ia32_psllw (v4hi, v4hi)
+     v2si __builtin_ia32_pslld (v2si, v2si)
+     v1di __builtin_ia32_psllq (v1di, v1di)
+     v4hi __builtin_ia32_psrlw (v4hi, v4hi)
+     v2si __builtin_ia32_psrld (v2si, v2si)
+     v1di __builtin_ia32_psrlq (v1di, v1di)
+     v4hi __builtin_ia32_psraw (v4hi, v4hi)
+     v2si __builtin_ia32_psrad (v2si, v2si)
+     v4hi __builtin_ia32_psllwi (v4hi, int)
+     v2si __builtin_ia32_pslldi (v2si, int)
+     v1di __builtin_ia32_psllqi (v1di, int)
+     v4hi __builtin_ia32_psrlwi (v4hi, int)
+     v2si __builtin_ia32_psrldi (v2si, int)
+     v1di __builtin_ia32_psrlqi (v1di, int)
+     v4hi __builtin_ia32_psrawi (v4hi, int)
+     v2si __builtin_ia32_psradi (v2si, int)
+
+ The following built-in functions are made available either with
+'-msse', or with a combination of '-m3dnow' and '-march=athlon'.  All of
+them generate the machine instruction that is part of the name.
+
+     v4hi __builtin_ia32_pmulhuw (v4hi, v4hi)
+     v8qi __builtin_ia32_pavgb (v8qi, v8qi)
+     v4hi __builtin_ia32_pavgw (v4hi, v4hi)
+     v1di __builtin_ia32_psadbw (v8qi, v8qi)
+     v8qi __builtin_ia32_pmaxub (v8qi, v8qi)
+     v4hi __builtin_ia32_pmaxsw (v4hi, v4hi)
+     v8qi __builtin_ia32_pminub (v8qi, v8qi)
+     v4hi __builtin_ia32_pminsw (v4hi, v4hi)
+     int __builtin_ia32_pmovmskb (v8qi)
+     void __builtin_ia32_maskmovq (v8qi, v8qi, char *)
+     void __builtin_ia32_movntq (di *, di)
+     void __builtin_ia32_sfence (void)
+
+ The following built-in functions are available when '-msse' is used.
+All of them generate the machine instruction that is part of the name.
+
+     int __builtin_ia32_comieq (v4sf, v4sf)
+     int __builtin_ia32_comineq (v4sf, v4sf)
+     int __builtin_ia32_comilt (v4sf, v4sf)
+     int __builtin_ia32_comile (v4sf, v4sf)
+     int __builtin_ia32_comigt (v4sf, v4sf)
+     int __builtin_ia32_comige (v4sf, v4sf)
+     int __builtin_ia32_ucomieq (v4sf, v4sf)
+     int __builtin_ia32_ucomineq (v4sf, v4sf)
+     int __builtin_ia32_ucomilt (v4sf, v4sf)
+     int __builtin_ia32_ucomile (v4sf, v4sf)
+     int __builtin_ia32_ucomigt (v4sf, v4sf)
+     int __builtin_ia32_ucomige (v4sf, v4sf)
+     v4sf __builtin_ia32_addps (v4sf, v4sf)
+     v4sf __builtin_ia32_subps (v4sf, v4sf)
+     v4sf __builtin_ia32_mulps (v4sf, v4sf)
+     v4sf __builtin_ia32_divps (v4sf, v4sf)
+     v4sf __builtin_ia32_addss (v4sf, v4sf)
+     v4sf __builtin_ia32_subss (v4sf, v4sf)
+     v4sf __builtin_ia32_mulss (v4sf, v4sf)
+     v4sf __builtin_ia32_divss (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpeqps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpltps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpleps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpgtps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpgeps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpunordps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpneqps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpnltps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpnleps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpngtps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpngeps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpordps (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpeqss (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpltss (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpless (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpunordss (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpneqss (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpnltss (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpnless (v4sf, v4sf)
+     v4sf __builtin_ia32_cmpordss (v4sf, v4sf)
+     v4sf __builtin_ia32_maxps (v4sf, v4sf)
+     v4sf __builtin_ia32_maxss (v4sf, v4sf)
+     v4sf __builtin_ia32_minps (v4sf, v4sf)
+     v4sf __builtin_ia32_minss (v4sf, v4sf)
+     v4sf __builtin_ia32_andps (v4sf, v4sf)
+     v4sf __builtin_ia32_andnps (v4sf, v4sf)
+     v4sf __builtin_ia32_orps (v4sf, v4sf)
+     v4sf __builtin_ia32_xorps (v4sf, v4sf)
+     v4sf __builtin_ia32_movss (v4sf, v4sf)
+     v4sf __builtin_ia32_movhlps (v4sf, v4sf)
+     v4sf __builtin_ia32_movlhps (v4sf, v4sf)
+     v4sf __builtin_ia32_unpckhps (v4sf, v4sf)
+     v4sf __builtin_ia32_unpcklps (v4sf, v4sf)
+     v4sf __builtin_ia32_cvtpi2ps (v4sf, v2si)
+     v4sf __builtin_ia32_cvtsi2ss (v4sf, int)
+     v2si __builtin_ia32_cvtps2pi (v4sf)
+     int __builtin_ia32_cvtss2si (v4sf)
+     v2si __builtin_ia32_cvttps2pi (v4sf)
+     int __builtin_ia32_cvttss2si (v4sf)
+     v4sf __builtin_ia32_rcpps (v4sf)
+     v4sf __builtin_ia32_rsqrtps (v4sf)
+     v4sf __builtin_ia32_sqrtps (v4sf)
+     v4sf __builtin_ia32_rcpss (v4sf)
+     v4sf __builtin_ia32_rsqrtss (v4sf)
+     v4sf __builtin_ia32_sqrtss (v4sf)
+     v4sf __builtin_ia32_shufps (v4sf, v4sf, int)
+     void __builtin_ia32_movntps (float *, v4sf)
+     int __builtin_ia32_movmskps (v4sf)
+
+ The following built-in functions are available when '-msse' is used.
+
+'v4sf __builtin_ia32_loadups (float *)'
+     Generates the 'movups' machine instruction as a load from memory.
+'void __builtin_ia32_storeups (float *, v4sf)'
+     Generates the 'movups' machine instruction as a store to memory.
+'v4sf __builtin_ia32_loadss (float *)'
+     Generates the 'movss' machine instruction as a load from memory.
+'v4sf __builtin_ia32_loadhps (v4sf, const v2sf *)'
+     Generates the 'movhps' machine instruction as a load from memory.
+'v4sf __builtin_ia32_loadlps (v4sf, const v2sf *)'
+     Generates the 'movlps' machine instruction as a load from memory
+'void __builtin_ia32_storehps (v2sf *, v4sf)'
+     Generates the 'movhps' machine instruction as a store to memory.
+'void __builtin_ia32_storelps (v2sf *, v4sf)'
+     Generates the 'movlps' machine instruction as a store to memory.
+
+ The following built-in functions are available when '-msse2' is used.
+All of them generate the machine instruction that is part of the name.
+
+     int __builtin_ia32_comisdeq (v2df, v2df)
+     int __builtin_ia32_comisdlt (v2df, v2df)
+     int __builtin_ia32_comisdle (v2df, v2df)
+     int __builtin_ia32_comisdgt (v2df, v2df)
+     int __builtin_ia32_comisdge (v2df, v2df)
+     int __builtin_ia32_comisdneq (v2df, v2df)
+     int __builtin_ia32_ucomisdeq (v2df, v2df)
+     int __builtin_ia32_ucomisdlt (v2df, v2df)
+     int __builtin_ia32_ucomisdle (v2df, v2df)
+     int __builtin_ia32_ucomisdgt (v2df, v2df)
+     int __builtin_ia32_ucomisdge (v2df, v2df)
+     int __builtin_ia32_ucomisdneq (v2df, v2df)
+     v2df __builtin_ia32_cmpeqpd (v2df, v2df)
+     v2df __builtin_ia32_cmpltpd (v2df, v2df)
+     v2df __builtin_ia32_cmplepd (v2df, v2df)
+     v2df __builtin_ia32_cmpgtpd (v2df, v2df)
+     v2df __builtin_ia32_cmpgepd (v2df, v2df)
+     v2df __builtin_ia32_cmpunordpd (v2df, v2df)
+     v2df __builtin_ia32_cmpneqpd (v2df, v2df)
+     v2df __builtin_ia32_cmpnltpd (v2df, v2df)
+     v2df __builtin_ia32_cmpnlepd (v2df, v2df)
+     v2df __builtin_ia32_cmpngtpd (v2df, v2df)
+     v2df __builtin_ia32_cmpngepd (v2df, v2df)
+     v2df __builtin_ia32_cmpordpd (v2df, v2df)
+     v2df __builtin_ia32_cmpeqsd (v2df, v2df)
+     v2df __builtin_ia32_cmpltsd (v2df, v2df)
+     v2df __builtin_ia32_cmplesd (v2df, v2df)
+     v2df __builtin_ia32_cmpunordsd (v2df, v2df)
+     v2df __builtin_ia32_cmpneqsd (v2df, v2df)
+     v2df __builtin_ia32_cmpnltsd (v2df, v2df)
+     v2df __builtin_ia32_cmpnlesd (v2df, v2df)
+     v2df __builtin_ia32_cmpordsd (v2df, v2df)
+     v2di __builtin_ia32_paddq (v2di, v2di)
+     v2di __builtin_ia32_psubq (v2di, v2di)
+     v2df __builtin_ia32_addpd (v2df, v2df)
+     v2df __builtin_ia32_subpd (v2df, v2df)
+     v2df __builtin_ia32_mulpd (v2df, v2df)
+     v2df __builtin_ia32_divpd (v2df, v2df)
+     v2df __builtin_ia32_addsd (v2df, v2df)
+     v2df __builtin_ia32_subsd (v2df, v2df)
+     v2df __builtin_ia32_mulsd (v2df, v2df)
+     v2df __builtin_ia32_divsd (v2df, v2df)
+     v2df __builtin_ia32_minpd (v2df, v2df)
+     v2df __builtin_ia32_maxpd (v2df, v2df)
+     v2df __builtin_ia32_minsd (v2df, v2df)
+     v2df __builtin_ia32_maxsd (v2df, v2df)
+     v2df __builtin_ia32_andpd (v2df, v2df)
+     v2df __builtin_ia32_andnpd (v2df, v2df)
+     v2df __builtin_ia32_orpd (v2df, v2df)
+     v2df __builtin_ia32_xorpd (v2df, v2df)
+     v2df __builtin_ia32_movsd (v2df, v2df)
+     v2df __builtin_ia32_unpckhpd (v2df, v2df)
+     v2df __builtin_ia32_unpcklpd (v2df, v2df)
+     v16qi __builtin_ia32_paddb128 (v16qi, v16qi)
+     v8hi __builtin_ia32_paddw128 (v8hi, v8hi)
+     v4si __builtin_ia32_paddd128 (v4si, v4si)
+     v2di __builtin_ia32_paddq128 (v2di, v2di)
+     v16qi __builtin_ia32_psubb128 (v16qi, v16qi)
+     v8hi __builtin_ia32_psubw128 (v8hi, v8hi)
+     v4si __builtin_ia32_psubd128 (v4si, v4si)
+     v2di __builtin_ia32_psubq128 (v2di, v2di)
+     v8hi __builtin_ia32_pmullw128 (v8hi, v8hi)
+     v8hi __builtin_ia32_pmulhw128 (v8hi, v8hi)
+     v2di __builtin_ia32_pand128 (v2di, v2di)
+     v2di __builtin_ia32_pandn128 (v2di, v2di)
+     v2di __builtin_ia32_por128 (v2di, v2di)
+     v2di __builtin_ia32_pxor128 (v2di, v2di)
+     v16qi __builtin_ia32_pavgb128 (v16qi, v16qi)
+     v8hi __builtin_ia32_pavgw128 (v8hi, v8hi)
+     v16qi __builtin_ia32_pcmpeqb128 (v16qi, v16qi)
+     v8hi __builtin_ia32_pcmpeqw128 (v8hi, v8hi)
+     v4si __builtin_ia32_pcmpeqd128 (v4si, v4si)
+     v16qi __builtin_ia32_pcmpgtb128 (v16qi, v16qi)
+     v8hi __builtin_ia32_pcmpgtw128 (v8hi, v8hi)
+     v4si __builtin_ia32_pcmpgtd128 (v4si, v4si)
+     v16qi __builtin_ia32_pmaxub128 (v16qi, v16qi)
+     v8hi __builtin_ia32_pmaxsw128 (v8hi, v8hi)
+     v16qi __builtin_ia32_pminub128 (v16qi, v16qi)
+     v8hi __builtin_ia32_pminsw128 (v8hi, v8hi)
+     v16qi __builtin_ia32_punpckhbw128 (v16qi, v16qi)
+     v8hi __builtin_ia32_punpckhwd128 (v8hi, v8hi)
+     v4si __builtin_ia32_punpckhdq128 (v4si, v4si)
+     v2di __builtin_ia32_punpckhqdq128 (v2di, v2di)
+     v16qi __builtin_ia32_punpcklbw128 (v16qi, v16qi)
+     v8hi __builtin_ia32_punpcklwd128 (v8hi, v8hi)
+     v4si __builtin_ia32_punpckldq128 (v4si, v4si)
+     v2di __builtin_ia32_punpcklqdq128 (v2di, v2di)
+     v16qi __builtin_ia32_packsswb128 (v8hi, v8hi)
+     v8hi __builtin_ia32_packssdw128 (v4si, v4si)
+     v16qi __builtin_ia32_packuswb128 (v8hi, v8hi)
+     v8hi __builtin_ia32_pmulhuw128 (v8hi, v8hi)
+     void __builtin_ia32_maskmovdqu (v16qi, v16qi)
+     v2df __builtin_ia32_loadupd (double *)
+     void __builtin_ia32_storeupd (double *, v2df)
+     v2df __builtin_ia32_loadhpd (v2df, double const *)
+     v2df __builtin_ia32_loadlpd (v2df, double const *)
+     int __builtin_ia32_movmskpd (v2df)
+     int __builtin_ia32_pmovmskb128 (v16qi)
+     void __builtin_ia32_movnti (int *, int)
+     void __builtin_ia32_movnti64 (long long int *, long long int)
+     void __builtin_ia32_movntpd (double *, v2df)
+     void __builtin_ia32_movntdq (v2df *, v2df)
+     v4si __builtin_ia32_pshufd (v4si, int)
+     v8hi __builtin_ia32_pshuflw (v8hi, int)
+     v8hi __builtin_ia32_pshufhw (v8hi, int)
+     v2di __builtin_ia32_psadbw128 (v16qi, v16qi)
+     v2df __builtin_ia32_sqrtpd (v2df)
+     v2df __builtin_ia32_sqrtsd (v2df)
+     v2df __builtin_ia32_shufpd (v2df, v2df, int)
+     v2df __builtin_ia32_cvtdq2pd (v4si)
+     v4sf __builtin_ia32_cvtdq2ps (v4si)
+     v4si __builtin_ia32_cvtpd2dq (v2df)
+     v2si __builtin_ia32_cvtpd2pi (v2df)
+     v4sf __builtin_ia32_cvtpd2ps (v2df)
+     v4si __builtin_ia32_cvttpd2dq (v2df)
+     v2si __builtin_ia32_cvttpd2pi (v2df)
+     v2df __builtin_ia32_cvtpi2pd (v2si)
+     int __builtin_ia32_cvtsd2si (v2df)
+     int __builtin_ia32_cvttsd2si (v2df)
+     long long __builtin_ia32_cvtsd2si64 (v2df)
+     long long __builtin_ia32_cvttsd2si64 (v2df)
+     v4si __builtin_ia32_cvtps2dq (v4sf)
+     v2df __builtin_ia32_cvtps2pd (v4sf)
+     v4si __builtin_ia32_cvttps2dq (v4sf)
+     v2df __builtin_ia32_cvtsi2sd (v2df, int)
+     v2df __builtin_ia32_cvtsi642sd (v2df, long long)
+     v4sf __builtin_ia32_cvtsd2ss (v4sf, v2df)
+     v2df __builtin_ia32_cvtss2sd (v2df, v4sf)
+     void __builtin_ia32_clflush (const void *)
+     void __builtin_ia32_lfence (void)
+     void __builtin_ia32_mfence (void)
+     v16qi __builtin_ia32_loaddqu (const char *)
+     void __builtin_ia32_storedqu (char *, v16qi)
+     v1di __builtin_ia32_pmuludq (v2si, v2si)
+     v2di __builtin_ia32_pmuludq128 (v4si, v4si)
+     v8hi __builtin_ia32_psllw128 (v8hi, v8hi)
+     v4si __builtin_ia32_pslld128 (v4si, v4si)
+     v2di __builtin_ia32_psllq128 (v2di, v2di)
+     v8hi __builtin_ia32_psrlw128 (v8hi, v8hi)
+     v4si __builtin_ia32_psrld128 (v4si, v4si)
+     v2di __builtin_ia32_psrlq128 (v2di, v2di)
+     v8hi __builtin_ia32_psraw128 (v8hi, v8hi)
+     v4si __builtin_ia32_psrad128 (v4si, v4si)
+     v2di __builtin_ia32_pslldqi128 (v2di, int)
+     v8hi __builtin_ia32_psllwi128 (v8hi, int)
+     v4si __builtin_ia32_pslldi128 (v4si, int)
+     v2di __builtin_ia32_psllqi128 (v2di, int)
+     v2di __builtin_ia32_psrldqi128 (v2di, int)
+     v8hi __builtin_ia32_psrlwi128 (v8hi, int)
+     v4si __builtin_ia32_psrldi128 (v4si, int)
+     v2di __builtin_ia32_psrlqi128 (v2di, int)
+     v8hi __builtin_ia32_psrawi128 (v8hi, int)
+     v4si __builtin_ia32_psradi128 (v4si, int)
+     v4si __builtin_ia32_pmaddwd128 (v8hi, v8hi)
+     v2di __builtin_ia32_movq128 (v2di)
+
+ The following built-in functions are available when '-msse3' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v2df __builtin_ia32_addsubpd (v2df, v2df)
+     v4sf __builtin_ia32_addsubps (v4sf, v4sf)
+     v2df __builtin_ia32_haddpd (v2df, v2df)
+     v4sf __builtin_ia32_haddps (v4sf, v4sf)
+     v2df __builtin_ia32_hsubpd (v2df, v2df)
+     v4sf __builtin_ia32_hsubps (v4sf, v4sf)
+     v16qi __builtin_ia32_lddqu (char const *)
+     void __builtin_ia32_monitor (void *, unsigned int, unsigned int)
+     v4sf __builtin_ia32_movshdup (v4sf)
+     v4sf __builtin_ia32_movsldup (v4sf)
+     void __builtin_ia32_mwait (unsigned int, unsigned int)
+
+ The following built-in functions are available when '-mssse3' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v2si __builtin_ia32_phaddd (v2si, v2si)
+     v4hi __builtin_ia32_phaddw (v4hi, v4hi)
+     v4hi __builtin_ia32_phaddsw (v4hi, v4hi)
+     v2si __builtin_ia32_phsubd (v2si, v2si)
+     v4hi __builtin_ia32_phsubw (v4hi, v4hi)
+     v4hi __builtin_ia32_phsubsw (v4hi, v4hi)
+     v4hi __builtin_ia32_pmaddubsw (v8qi, v8qi)
+     v4hi __builtin_ia32_pmulhrsw (v4hi, v4hi)
+     v8qi __builtin_ia32_pshufb (v8qi, v8qi)
+     v8qi __builtin_ia32_psignb (v8qi, v8qi)
+     v2si __builtin_ia32_psignd (v2si, v2si)
+     v4hi __builtin_ia32_psignw (v4hi, v4hi)
+     v1di __builtin_ia32_palignr (v1di, v1di, int)
+     v8qi __builtin_ia32_pabsb (v8qi)
+     v2si __builtin_ia32_pabsd (v2si)
+     v4hi __builtin_ia32_pabsw (v4hi)
+
+ The following built-in functions are available when '-mssse3' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v4si __builtin_ia32_phaddd128 (v4si, v4si)
+     v8hi __builtin_ia32_phaddw128 (v8hi, v8hi)
+     v8hi __builtin_ia32_phaddsw128 (v8hi, v8hi)
+     v4si __builtin_ia32_phsubd128 (v4si, v4si)
+     v8hi __builtin_ia32_phsubw128 (v8hi, v8hi)
+     v8hi __builtin_ia32_phsubsw128 (v8hi, v8hi)
+     v8hi __builtin_ia32_pmaddubsw128 (v16qi, v16qi)
+     v8hi __builtin_ia32_pmulhrsw128 (v8hi, v8hi)
+     v16qi __builtin_ia32_pshufb128 (v16qi, v16qi)
+     v16qi __builtin_ia32_psignb128 (v16qi, v16qi)
+     v4si __builtin_ia32_psignd128 (v4si, v4si)
+     v8hi __builtin_ia32_psignw128 (v8hi, v8hi)
+     v2di __builtin_ia32_palignr128 (v2di, v2di, int)
+     v16qi __builtin_ia32_pabsb128 (v16qi)
+     v4si __builtin_ia32_pabsd128 (v4si)
+     v8hi __builtin_ia32_pabsw128 (v8hi)
+
+ The following built-in functions are available when '-msse4.1' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v2df __builtin_ia32_blendpd (v2df, v2df, const int)
+     v4sf __builtin_ia32_blendps (v4sf, v4sf, const int)
+     v2df __builtin_ia32_blendvpd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_blendvps (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_dppd (v2df, v2df, const int)
+     v4sf __builtin_ia32_dpps (v4sf, v4sf, const int)
+     v4sf __builtin_ia32_insertps128 (v4sf, v4sf, const int)
+     v2di __builtin_ia32_movntdqa (v2di *);
+     v16qi __builtin_ia32_mpsadbw128 (v16qi, v16qi, const int)
+     v8hi __builtin_ia32_packusdw128 (v4si, v4si)
+     v16qi __builtin_ia32_pblendvb128 (v16qi, v16qi, v16qi)
+     v8hi __builtin_ia32_pblendw128 (v8hi, v8hi, const int)
+     v2di __builtin_ia32_pcmpeqq (v2di, v2di)
+     v8hi __builtin_ia32_phminposuw128 (v8hi)
+     v16qi __builtin_ia32_pmaxsb128 (v16qi, v16qi)
+     v4si __builtin_ia32_pmaxsd128 (v4si, v4si)
+     v4si __builtin_ia32_pmaxud128 (v4si, v4si)
+     v8hi __builtin_ia32_pmaxuw128 (v8hi, v8hi)
+     v16qi __builtin_ia32_pminsb128 (v16qi, v16qi)
+     v4si __builtin_ia32_pminsd128 (v4si, v4si)
+     v4si __builtin_ia32_pminud128 (v4si, v4si)
+     v8hi __builtin_ia32_pminuw128 (v8hi, v8hi)
+     v4si __builtin_ia32_pmovsxbd128 (v16qi)
+     v2di __builtin_ia32_pmovsxbq128 (v16qi)
+     v8hi __builtin_ia32_pmovsxbw128 (v16qi)
+     v2di __builtin_ia32_pmovsxdq128 (v4si)
+     v4si __builtin_ia32_pmovsxwd128 (v8hi)
+     v2di __builtin_ia32_pmovsxwq128 (v8hi)
+     v4si __builtin_ia32_pmovzxbd128 (v16qi)
+     v2di __builtin_ia32_pmovzxbq128 (v16qi)
+     v8hi __builtin_ia32_pmovzxbw128 (v16qi)
+     v2di __builtin_ia32_pmovzxdq128 (v4si)
+     v4si __builtin_ia32_pmovzxwd128 (v8hi)
+     v2di __builtin_ia32_pmovzxwq128 (v8hi)
+     v2di __builtin_ia32_pmuldq128 (v4si, v4si)
+     v4si __builtin_ia32_pmulld128 (v4si, v4si)
+     int __builtin_ia32_ptestc128 (v2di, v2di)
+     int __builtin_ia32_ptestnzc128 (v2di, v2di)
+     int __builtin_ia32_ptestz128 (v2di, v2di)
+     v2df __builtin_ia32_roundpd (v2df, const int)
+     v4sf __builtin_ia32_roundps (v4sf, const int)
+     v2df __builtin_ia32_roundsd (v2df, v2df, const int)
+     v4sf __builtin_ia32_roundss (v4sf, v4sf, const int)
+
+ The following built-in functions are available when '-msse4.1' is used.
+
+'v4sf __builtin_ia32_vec_set_v4sf (v4sf, float, const int)'
+     Generates the 'insertps' machine instruction.
+'int __builtin_ia32_vec_ext_v16qi (v16qi, const int)'
+     Generates the 'pextrb' machine instruction.
+'v16qi __builtin_ia32_vec_set_v16qi (v16qi, int, const int)'
+     Generates the 'pinsrb' machine instruction.
+'v4si __builtin_ia32_vec_set_v4si (v4si, int, const int)'
+     Generates the 'pinsrd' machine instruction.
+'v2di __builtin_ia32_vec_set_v2di (v2di, long long, const int)'
+     Generates the 'pinsrq' machine instruction in 64bit mode.
+
+ The following built-in functions are changed to generate new SSE4.1
+instructions when '-msse4.1' is used.
+
+'float __builtin_ia32_vec_ext_v4sf (v4sf, const int)'
+     Generates the 'extractps' machine instruction.
+'int __builtin_ia32_vec_ext_v4si (v4si, const int)'
+     Generates the 'pextrd' machine instruction.
+'long long __builtin_ia32_vec_ext_v2di (v2di, const int)'
+     Generates the 'pextrq' machine instruction in 64bit mode.
+
+ The following built-in functions are available when '-msse4.2' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v16qi __builtin_ia32_pcmpestrm128 (v16qi, int, v16qi, int, const int)
+     int __builtin_ia32_pcmpestri128 (v16qi, int, v16qi, int, const int)
+     int __builtin_ia32_pcmpestria128 (v16qi, int, v16qi, int, const int)
+     int __builtin_ia32_pcmpestric128 (v16qi, int, v16qi, int, const int)
+     int __builtin_ia32_pcmpestrio128 (v16qi, int, v16qi, int, const int)
+     int __builtin_ia32_pcmpestris128 (v16qi, int, v16qi, int, const int)
+     int __builtin_ia32_pcmpestriz128 (v16qi, int, v16qi, int, const int)
+     v16qi __builtin_ia32_pcmpistrm128 (v16qi, v16qi, const int)
+     int __builtin_ia32_pcmpistri128 (v16qi, v16qi, const int)
+     int __builtin_ia32_pcmpistria128 (v16qi, v16qi, const int)
+     int __builtin_ia32_pcmpistric128 (v16qi, v16qi, const int)
+     int __builtin_ia32_pcmpistrio128 (v16qi, v16qi, const int)
+     int __builtin_ia32_pcmpistris128 (v16qi, v16qi, const int)
+     int __builtin_ia32_pcmpistriz128 (v16qi, v16qi, const int)
+     v2di __builtin_ia32_pcmpgtq (v2di, v2di)
+
+ The following built-in functions are available when '-msse4.2' is used.
+
+'unsigned int __builtin_ia32_crc32qi (unsigned int, unsigned char)'
+     Generates the 'crc32b' machine instruction.
+'unsigned int __builtin_ia32_crc32hi (unsigned int, unsigned short)'
+     Generates the 'crc32w' machine instruction.
+'unsigned int __builtin_ia32_crc32si (unsigned int, unsigned int)'
+     Generates the 'crc32l' machine instruction.
+'unsigned long long __builtin_ia32_crc32di (unsigned long long, unsigned long long)'
+     Generates the 'crc32q' machine instruction.
+
+ The following built-in functions are changed to generate new SSE4.2
+instructions when '-msse4.2' is used.
+
+'int __builtin_popcount (unsigned int)'
+     Generates the 'popcntl' machine instruction.
+'int __builtin_popcountl (unsigned long)'
+     Generates the 'popcntl' or 'popcntq' machine instruction, depending
+     on the size of 'unsigned long'.
+'int __builtin_popcountll (unsigned long long)'
+     Generates the 'popcntq' machine instruction.
+
+ The following built-in functions are available when '-mavx' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v4df __builtin_ia32_addpd256 (v4df,v4df)
+     v8sf __builtin_ia32_addps256 (v8sf,v8sf)
+     v4df __builtin_ia32_addsubpd256 (v4df,v4df)
+     v8sf __builtin_ia32_addsubps256 (v8sf,v8sf)
+     v4df __builtin_ia32_andnpd256 (v4df,v4df)
+     v8sf __builtin_ia32_andnps256 (v8sf,v8sf)
+     v4df __builtin_ia32_andpd256 (v4df,v4df)
+     v8sf __builtin_ia32_andps256 (v8sf,v8sf)
+     v4df __builtin_ia32_blendpd256 (v4df,v4df,int)
+     v8sf __builtin_ia32_blendps256 (v8sf,v8sf,int)
+     v4df __builtin_ia32_blendvpd256 (v4df,v4df,v4df)
+     v8sf __builtin_ia32_blendvps256 (v8sf,v8sf,v8sf)
+     v2df __builtin_ia32_cmppd (v2df,v2df,int)
+     v4df __builtin_ia32_cmppd256 (v4df,v4df,int)
+     v4sf __builtin_ia32_cmpps (v4sf,v4sf,int)
+     v8sf __builtin_ia32_cmpps256 (v8sf,v8sf,int)
+     v2df __builtin_ia32_cmpsd (v2df,v2df,int)
+     v4sf __builtin_ia32_cmpss (v4sf,v4sf,int)
+     v4df __builtin_ia32_cvtdq2pd256 (v4si)
+     v8sf __builtin_ia32_cvtdq2ps256 (v8si)
+     v4si __builtin_ia32_cvtpd2dq256 (v4df)
+     v4sf __builtin_ia32_cvtpd2ps256 (v4df)
+     v8si __builtin_ia32_cvtps2dq256 (v8sf)
+     v4df __builtin_ia32_cvtps2pd256 (v4sf)
+     v4si __builtin_ia32_cvttpd2dq256 (v4df)
+     v8si __builtin_ia32_cvttps2dq256 (v8sf)
+     v4df __builtin_ia32_divpd256 (v4df,v4df)
+     v8sf __builtin_ia32_divps256 (v8sf,v8sf)
+     v8sf __builtin_ia32_dpps256 (v8sf,v8sf,int)
+     v4df __builtin_ia32_haddpd256 (v4df,v4df)
+     v8sf __builtin_ia32_haddps256 (v8sf,v8sf)
+     v4df __builtin_ia32_hsubpd256 (v4df,v4df)
+     v8sf __builtin_ia32_hsubps256 (v8sf,v8sf)
+     v32qi __builtin_ia32_lddqu256 (pcchar)
+     v32qi __builtin_ia32_loaddqu256 (pcchar)
+     v4df __builtin_ia32_loadupd256 (pcdouble)
+     v8sf __builtin_ia32_loadups256 (pcfloat)
+     v2df __builtin_ia32_maskloadpd (pcv2df,v2df)
+     v4df __builtin_ia32_maskloadpd256 (pcv4df,v4df)
+     v4sf __builtin_ia32_maskloadps (pcv4sf,v4sf)
+     v8sf __builtin_ia32_maskloadps256 (pcv8sf,v8sf)
+     void __builtin_ia32_maskstorepd (pv2df,v2df,v2df)
+     void __builtin_ia32_maskstorepd256 (pv4df,v4df,v4df)
+     void __builtin_ia32_maskstoreps (pv4sf,v4sf,v4sf)
+     void __builtin_ia32_maskstoreps256 (pv8sf,v8sf,v8sf)
+     v4df __builtin_ia32_maxpd256 (v4df,v4df)
+     v8sf __builtin_ia32_maxps256 (v8sf,v8sf)
+     v4df __builtin_ia32_minpd256 (v4df,v4df)
+     v8sf __builtin_ia32_minps256 (v8sf,v8sf)
+     v4df __builtin_ia32_movddup256 (v4df)
+     int __builtin_ia32_movmskpd256 (v4df)
+     int __builtin_ia32_movmskps256 (v8sf)
+     v8sf __builtin_ia32_movshdup256 (v8sf)
+     v8sf __builtin_ia32_movsldup256 (v8sf)
+     v4df __builtin_ia32_mulpd256 (v4df,v4df)
+     v8sf __builtin_ia32_mulps256 (v8sf,v8sf)
+     v4df __builtin_ia32_orpd256 (v4df,v4df)
+     v8sf __builtin_ia32_orps256 (v8sf,v8sf)
+     v2df __builtin_ia32_pd_pd256 (v4df)
+     v4df __builtin_ia32_pd256_pd (v2df)
+     v4sf __builtin_ia32_ps_ps256 (v8sf)
+     v8sf __builtin_ia32_ps256_ps (v4sf)
+     int __builtin_ia32_ptestc256 (v4di,v4di,ptest)
+     int __builtin_ia32_ptestnzc256 (v4di,v4di,ptest)
+     int __builtin_ia32_ptestz256 (v4di,v4di,ptest)
+     v8sf __builtin_ia32_rcpps256 (v8sf)
+     v4df __builtin_ia32_roundpd256 (v4df,int)
+     v8sf __builtin_ia32_roundps256 (v8sf,int)
+     v8sf __builtin_ia32_rsqrtps_nr256 (v8sf)
+     v8sf __builtin_ia32_rsqrtps256 (v8sf)
+     v4df __builtin_ia32_shufpd256 (v4df,v4df,int)
+     v8sf __builtin_ia32_shufps256 (v8sf,v8sf,int)
+     v4si __builtin_ia32_si_si256 (v8si)
+     v8si __builtin_ia32_si256_si (v4si)
+     v4df __builtin_ia32_sqrtpd256 (v4df)
+     v8sf __builtin_ia32_sqrtps_nr256 (v8sf)
+     v8sf __builtin_ia32_sqrtps256 (v8sf)
+     void __builtin_ia32_storedqu256 (pchar,v32qi)
+     void __builtin_ia32_storeupd256 (pdouble,v4df)
+     void __builtin_ia32_storeups256 (pfloat,v8sf)
+     v4df __builtin_ia32_subpd256 (v4df,v4df)
+     v8sf __builtin_ia32_subps256 (v8sf,v8sf)
+     v4df __builtin_ia32_unpckhpd256 (v4df,v4df)
+     v8sf __builtin_ia32_unpckhps256 (v8sf,v8sf)
+     v4df __builtin_ia32_unpcklpd256 (v4df,v4df)
+     v8sf __builtin_ia32_unpcklps256 (v8sf,v8sf)
+     v4df __builtin_ia32_vbroadcastf128_pd256 (pcv2df)
+     v8sf __builtin_ia32_vbroadcastf128_ps256 (pcv4sf)
+     v4df __builtin_ia32_vbroadcastsd256 (pcdouble)
+     v4sf __builtin_ia32_vbroadcastss (pcfloat)
+     v8sf __builtin_ia32_vbroadcastss256 (pcfloat)
+     v2df __builtin_ia32_vextractf128_pd256 (v4df,int)
+     v4sf __builtin_ia32_vextractf128_ps256 (v8sf,int)
+     v4si __builtin_ia32_vextractf128_si256 (v8si,int)
+     v4df __builtin_ia32_vinsertf128_pd256 (v4df,v2df,int)
+     v8sf __builtin_ia32_vinsertf128_ps256 (v8sf,v4sf,int)
+     v8si __builtin_ia32_vinsertf128_si256 (v8si,v4si,int)
+     v4df __builtin_ia32_vperm2f128_pd256 (v4df,v4df,int)
+     v8sf __builtin_ia32_vperm2f128_ps256 (v8sf,v8sf,int)
+     v8si __builtin_ia32_vperm2f128_si256 (v8si,v8si,int)
+     v2df __builtin_ia32_vpermil2pd (v2df,v2df,v2di,int)
+     v4df __builtin_ia32_vpermil2pd256 (v4df,v4df,v4di,int)
+     v4sf __builtin_ia32_vpermil2ps (v4sf,v4sf,v4si,int)
+     v8sf __builtin_ia32_vpermil2ps256 (v8sf,v8sf,v8si,int)
+     v2df __builtin_ia32_vpermilpd (v2df,int)
+     v4df __builtin_ia32_vpermilpd256 (v4df,int)
+     v4sf __builtin_ia32_vpermilps (v4sf,int)
+     v8sf __builtin_ia32_vpermilps256 (v8sf,int)
+     v2df __builtin_ia32_vpermilvarpd (v2df,v2di)
+     v4df __builtin_ia32_vpermilvarpd256 (v4df,v4di)
+     v4sf __builtin_ia32_vpermilvarps (v4sf,v4si)
+     v8sf __builtin_ia32_vpermilvarps256 (v8sf,v8si)
+     int __builtin_ia32_vtestcpd (v2df,v2df,ptest)
+     int __builtin_ia32_vtestcpd256 (v4df,v4df,ptest)
+     int __builtin_ia32_vtestcps (v4sf,v4sf,ptest)
+     int __builtin_ia32_vtestcps256 (v8sf,v8sf,ptest)
+     int __builtin_ia32_vtestnzcpd (v2df,v2df,ptest)
+     int __builtin_ia32_vtestnzcpd256 (v4df,v4df,ptest)
+     int __builtin_ia32_vtestnzcps (v4sf,v4sf,ptest)
+     int __builtin_ia32_vtestnzcps256 (v8sf,v8sf,ptest)
+     int __builtin_ia32_vtestzpd (v2df,v2df,ptest)
+     int __builtin_ia32_vtestzpd256 (v4df,v4df,ptest)
+     int __builtin_ia32_vtestzps (v4sf,v4sf,ptest)
+     int __builtin_ia32_vtestzps256 (v8sf,v8sf,ptest)
+     void __builtin_ia32_vzeroall (void)
+     void __builtin_ia32_vzeroupper (void)
+     v4df __builtin_ia32_xorpd256 (v4df,v4df)
+     v8sf __builtin_ia32_xorps256 (v8sf,v8sf)
+
+ The following built-in functions are available when '-mavx2' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v32qi __builtin_ia32_mpsadbw256 (v32qi,v32qi,v32qi,int)
+     v32qi __builtin_ia32_pabsb256 (v32qi)
+     v16hi __builtin_ia32_pabsw256 (v16hi)
+     v8si __builtin_ia32_pabsd256 (v8si)
+     v16hi __builtin_ia32_packssdw256 (v8si,v8si)
+     v32qi __builtin_ia32_packsswb256 (v16hi,v16hi)
+     v16hi __builtin_ia32_packusdw256 (v8si,v8si)
+     v32qi __builtin_ia32_packuswb256 (v16hi,v16hi)
+     v32qi __builtin_ia32_paddb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_paddw256 (v16hi,v16hi)
+     v8si __builtin_ia32_paddd256 (v8si,v8si)
+     v4di __builtin_ia32_paddq256 (v4di,v4di)
+     v32qi __builtin_ia32_paddsb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_paddsw256 (v16hi,v16hi)
+     v32qi __builtin_ia32_paddusb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_paddusw256 (v16hi,v16hi)
+     v4di __builtin_ia32_palignr256 (v4di,v4di,int)
+     v4di __builtin_ia32_andsi256 (v4di,v4di)
+     v4di __builtin_ia32_andnotsi256 (v4di,v4di)
+     v32qi __builtin_ia32_pavgb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_pavgw256 (v16hi,v16hi)
+     v32qi __builtin_ia32_pblendvb256 (v32qi,v32qi,v32qi)
+     v16hi __builtin_ia32_pblendw256 (v16hi,v16hi,int)
+     v32qi __builtin_ia32_pcmpeqb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_pcmpeqw256 (v16hi,v16hi)
+     v8si __builtin_ia32_pcmpeqd256 (c8si,v8si)
+     v4di __builtin_ia32_pcmpeqq256 (v4di,v4di)
+     v32qi __builtin_ia32_pcmpgtb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_pcmpgtw256 (16hi,v16hi)
+     v8si __builtin_ia32_pcmpgtd256 (v8si,v8si)
+     v4di __builtin_ia32_pcmpgtq256 (v4di,v4di)
+     v16hi __builtin_ia32_phaddw256 (v16hi,v16hi)
+     v8si __builtin_ia32_phaddd256 (v8si,v8si)
+     v16hi __builtin_ia32_phaddsw256 (v16hi,v16hi)
+     v16hi __builtin_ia32_phsubw256 (v16hi,v16hi)
+     v8si __builtin_ia32_phsubd256 (v8si,v8si)
+     v16hi __builtin_ia32_phsubsw256 (v16hi,v16hi)
+     v32qi __builtin_ia32_pmaddubsw256 (v32qi,v32qi)
+     v16hi __builtin_ia32_pmaddwd256 (v16hi,v16hi)
+     v32qi __builtin_ia32_pmaxsb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_pmaxsw256 (v16hi,v16hi)
+     v8si __builtin_ia32_pmaxsd256 (v8si,v8si)
+     v32qi __builtin_ia32_pmaxub256 (v32qi,v32qi)
+     v16hi __builtin_ia32_pmaxuw256 (v16hi,v16hi)
+     v8si __builtin_ia32_pmaxud256 (v8si,v8si)
+     v32qi __builtin_ia32_pminsb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_pminsw256 (v16hi,v16hi)
+     v8si __builtin_ia32_pminsd256 (v8si,v8si)
+     v32qi __builtin_ia32_pminub256 (v32qi,v32qi)
+     v16hi __builtin_ia32_pminuw256 (v16hi,v16hi)
+     v8si __builtin_ia32_pminud256 (v8si,v8si)
+     int __builtin_ia32_pmovmskb256 (v32qi)
+     v16hi __builtin_ia32_pmovsxbw256 (v16qi)
+     v8si __builtin_ia32_pmovsxbd256 (v16qi)
+     v4di __builtin_ia32_pmovsxbq256 (v16qi)
+     v8si __builtin_ia32_pmovsxwd256 (v8hi)
+     v4di __builtin_ia32_pmovsxwq256 (v8hi)
+     v4di __builtin_ia32_pmovsxdq256 (v4si)
+     v16hi __builtin_ia32_pmovzxbw256 (v16qi)
+     v8si __builtin_ia32_pmovzxbd256 (v16qi)
+     v4di __builtin_ia32_pmovzxbq256 (v16qi)
+     v8si __builtin_ia32_pmovzxwd256 (v8hi)
+     v4di __builtin_ia32_pmovzxwq256 (v8hi)
+     v4di __builtin_ia32_pmovzxdq256 (v4si)
+     v4di __builtin_ia32_pmuldq256 (v8si,v8si)
+     v16hi __builtin_ia32_pmulhrsw256 (v16hi, v16hi)
+     v16hi __builtin_ia32_pmulhuw256 (v16hi,v16hi)
+     v16hi __builtin_ia32_pmulhw256 (v16hi,v16hi)
+     v16hi __builtin_ia32_pmullw256 (v16hi,v16hi)
+     v8si __builtin_ia32_pmulld256 (v8si,v8si)
+     v4di __builtin_ia32_pmuludq256 (v8si,v8si)
+     v4di __builtin_ia32_por256 (v4di,v4di)
+     v16hi __builtin_ia32_psadbw256 (v32qi,v32qi)
+     v32qi __builtin_ia32_pshufb256 (v32qi,v32qi)
+     v8si __builtin_ia32_pshufd256 (v8si,int)
+     v16hi __builtin_ia32_pshufhw256 (v16hi,int)
+     v16hi __builtin_ia32_pshuflw256 (v16hi,int)
+     v32qi __builtin_ia32_psignb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_psignw256 (v16hi,v16hi)
+     v8si __builtin_ia32_psignd256 (v8si,v8si)
+     v4di __builtin_ia32_pslldqi256 (v4di,int)
+     v16hi __builtin_ia32_psllwi256 (16hi,int)
+     v16hi __builtin_ia32_psllw256(v16hi,v8hi)
+     v8si __builtin_ia32_pslldi256 (v8si,int)
+     v8si __builtin_ia32_pslld256(v8si,v4si)
+     v4di __builtin_ia32_psllqi256 (v4di,int)
+     v4di __builtin_ia32_psllq256(v4di,v2di)
+     v16hi __builtin_ia32_psrawi256 (v16hi,int)
+     v16hi __builtin_ia32_psraw256 (v16hi,v8hi)
+     v8si __builtin_ia32_psradi256 (v8si,int)
+     v8si __builtin_ia32_psrad256 (v8si,v4si)
+     v4di __builtin_ia32_psrldqi256 (v4di, int)
+     v16hi __builtin_ia32_psrlwi256 (v16hi,int)
+     v16hi __builtin_ia32_psrlw256 (v16hi,v8hi)
+     v8si __builtin_ia32_psrldi256 (v8si,int)
+     v8si __builtin_ia32_psrld256 (v8si,v4si)
+     v4di __builtin_ia32_psrlqi256 (v4di,int)
+     v4di __builtin_ia32_psrlq256(v4di,v2di)
+     v32qi __builtin_ia32_psubb256 (v32qi,v32qi)
+     v32hi __builtin_ia32_psubw256 (v16hi,v16hi)
+     v8si __builtin_ia32_psubd256 (v8si,v8si)
+     v4di __builtin_ia32_psubq256 (v4di,v4di)
+     v32qi __builtin_ia32_psubsb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_psubsw256 (v16hi,v16hi)
+     v32qi __builtin_ia32_psubusb256 (v32qi,v32qi)
+     v16hi __builtin_ia32_psubusw256 (v16hi,v16hi)
+     v32qi __builtin_ia32_punpckhbw256 (v32qi,v32qi)
+     v16hi __builtin_ia32_punpckhwd256 (v16hi,v16hi)
+     v8si __builtin_ia32_punpckhdq256 (v8si,v8si)
+     v4di __builtin_ia32_punpckhqdq256 (v4di,v4di)
+     v32qi __builtin_ia32_punpcklbw256 (v32qi,v32qi)
+     v16hi __builtin_ia32_punpcklwd256 (v16hi,v16hi)
+     v8si __builtin_ia32_punpckldq256 (v8si,v8si)
+     v4di __builtin_ia32_punpcklqdq256 (v4di,v4di)
+     v4di __builtin_ia32_pxor256 (v4di,v4di)
+     v4di __builtin_ia32_movntdqa256 (pv4di)
+     v4sf __builtin_ia32_vbroadcastss_ps (v4sf)
+     v8sf __builtin_ia32_vbroadcastss_ps256 (v4sf)
+     v4df __builtin_ia32_vbroadcastsd_pd256 (v2df)
+     v4di __builtin_ia32_vbroadcastsi256 (v2di)
+     v4si __builtin_ia32_pblendd128 (v4si,v4si)
+     v8si __builtin_ia32_pblendd256 (v8si,v8si)
+     v32qi __builtin_ia32_pbroadcastb256 (v16qi)
+     v16hi __builtin_ia32_pbroadcastw256 (v8hi)
+     v8si __builtin_ia32_pbroadcastd256 (v4si)
+     v4di __builtin_ia32_pbroadcastq256 (v2di)
+     v16qi __builtin_ia32_pbroadcastb128 (v16qi)
+     v8hi __builtin_ia32_pbroadcastw128 (v8hi)
+     v4si __builtin_ia32_pbroadcastd128 (v4si)
+     v2di __builtin_ia32_pbroadcastq128 (v2di)
+     v8si __builtin_ia32_permvarsi256 (v8si,v8si)
+     v4df __builtin_ia32_permdf256 (v4df,int)
+     v8sf __builtin_ia32_permvarsf256 (v8sf,v8sf)
+     v4di __builtin_ia32_permdi256 (v4di,int)
+     v4di __builtin_ia32_permti256 (v4di,v4di,int)
+     v4di __builtin_ia32_extract128i256 (v4di,int)
+     v4di __builtin_ia32_insert128i256 (v4di,v2di,int)
+     v8si __builtin_ia32_maskloadd256 (pcv8si,v8si)
+     v4di __builtin_ia32_maskloadq256 (pcv4di,v4di)
+     v4si __builtin_ia32_maskloadd (pcv4si,v4si)
+     v2di __builtin_ia32_maskloadq (pcv2di,v2di)
+     void __builtin_ia32_maskstored256 (pv8si,v8si,v8si)
+     void __builtin_ia32_maskstoreq256 (pv4di,v4di,v4di)
+     void __builtin_ia32_maskstored (pv4si,v4si,v4si)
+     void __builtin_ia32_maskstoreq (pv2di,v2di,v2di)
+     v8si __builtin_ia32_psllv8si (v8si,v8si)
+     v4si __builtin_ia32_psllv4si (v4si,v4si)
+     v4di __builtin_ia32_psllv4di (v4di,v4di)
+     v2di __builtin_ia32_psllv2di (v2di,v2di)
+     v8si __builtin_ia32_psrav8si (v8si,v8si)
+     v4si __builtin_ia32_psrav4si (v4si,v4si)
+     v8si __builtin_ia32_psrlv8si (v8si,v8si)
+     v4si __builtin_ia32_psrlv4si (v4si,v4si)
+     v4di __builtin_ia32_psrlv4di (v4di,v4di)
+     v2di __builtin_ia32_psrlv2di (v2di,v2di)
+     v2df __builtin_ia32_gathersiv2df (v2df, pcdouble,v4si,v2df,int)
+     v4df __builtin_ia32_gathersiv4df (v4df, pcdouble,v4si,v4df,int)
+     v2df __builtin_ia32_gatherdiv2df (v2df, pcdouble,v2di,v2df,int)
+     v4df __builtin_ia32_gatherdiv4df (v4df, pcdouble,v4di,v4df,int)
+     v4sf __builtin_ia32_gathersiv4sf (v4sf, pcfloat,v4si,v4sf,int)
+     v8sf __builtin_ia32_gathersiv8sf (v8sf, pcfloat,v8si,v8sf,int)
+     v4sf __builtin_ia32_gatherdiv4sf (v4sf, pcfloat,v2di,v4sf,int)
+     v4sf __builtin_ia32_gatherdiv4sf256 (v4sf, pcfloat,v4di,v4sf,int)
+     v2di __builtin_ia32_gathersiv2di (v2di, pcint64,v4si,v2di,int)
+     v4di __builtin_ia32_gathersiv4di (v4di, pcint64,v4si,v4di,int)
+     v2di __builtin_ia32_gatherdiv2di (v2di, pcint64,v2di,v2di,int)
+     v4di __builtin_ia32_gatherdiv4di (v4di, pcint64,v4di,v4di,int)
+     v4si __builtin_ia32_gathersiv4si (v4si, pcint,v4si,v4si,int)
+     v8si __builtin_ia32_gathersiv8si (v8si, pcint,v8si,v8si,int)
+     v4si __builtin_ia32_gatherdiv4si (v4si, pcint,v2di,v4si,int)
+     v4si __builtin_ia32_gatherdiv4si256 (v4si, pcint,v4di,v4si,int)
+
+ The following built-in functions are available when '-maes' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v2di __builtin_ia32_aesenc128 (v2di, v2di)
+     v2di __builtin_ia32_aesenclast128 (v2di, v2di)
+     v2di __builtin_ia32_aesdec128 (v2di, v2di)
+     v2di __builtin_ia32_aesdeclast128 (v2di, v2di)
+     v2di __builtin_ia32_aeskeygenassist128 (v2di, const int)
+     v2di __builtin_ia32_aesimc128 (v2di)
+
+ The following built-in function is available when '-mpclmul' is used.
+
+'v2di __builtin_ia32_pclmulqdq128 (v2di, v2di, const int)'
+     Generates the 'pclmulqdq' machine instruction.
+
+ The following built-in function is available when '-mfsgsbase' is used.
+All of them generate the machine instruction that is part of the name.
+
+     unsigned int __builtin_ia32_rdfsbase32 (void)
+     unsigned long long __builtin_ia32_rdfsbase64 (void)
+     unsigned int __builtin_ia32_rdgsbase32 (void)
+     unsigned long long __builtin_ia32_rdgsbase64 (void)
+     void _writefsbase_u32 (unsigned int)
+     void _writefsbase_u64 (unsigned long long)
+     void _writegsbase_u32 (unsigned int)
+     void _writegsbase_u64 (unsigned long long)
+
+ The following built-in function is available when '-mrdrnd' is used.
+All of them generate the machine instruction that is part of the name.
+
+     unsigned int __builtin_ia32_rdrand16_step (unsigned short *)
+     unsigned int __builtin_ia32_rdrand32_step (unsigned int *)
+     unsigned int __builtin_ia32_rdrand64_step (unsigned long long *)
+
+ The following built-in functions are available when '-msse4a' is used.
+All of them generate the machine instruction that is part of the name.
+
+     void __builtin_ia32_movntsd (double *, v2df)
+     void __builtin_ia32_movntss (float *, v4sf)
+     v2di __builtin_ia32_extrq  (v2di, v16qi)
+     v2di __builtin_ia32_extrqi (v2di, const unsigned int, const unsigned int)
+     v2di __builtin_ia32_insertq (v2di, v2di)
+     v2di __builtin_ia32_insertqi (v2di, v2di, const unsigned int, const unsigned int)
+
+ The following built-in functions are available when '-mxop' is used.
+     v2df __builtin_ia32_vfrczpd (v2df)
+     v4sf __builtin_ia32_vfrczps (v4sf)
+     v2df __builtin_ia32_vfrczsd (v2df, v2df)
+     v4sf __builtin_ia32_vfrczss (v4sf, v4sf)
+     v4df __builtin_ia32_vfrczpd256 (v4df)
+     v8sf __builtin_ia32_vfrczps256 (v8sf)
+     v2di __builtin_ia32_vpcmov (v2di, v2di, v2di)
+     v2di __builtin_ia32_vpcmov_v2di (v2di, v2di, v2di)
+     v4si __builtin_ia32_vpcmov_v4si (v4si, v4si, v4si)
+     v8hi __builtin_ia32_vpcmov_v8hi (v8hi, v8hi, v8hi)
+     v16qi __builtin_ia32_vpcmov_v16qi (v16qi, v16qi, v16qi)
+     v2df __builtin_ia32_vpcmov_v2df (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vpcmov_v4sf (v4sf, v4sf, v4sf)
+     v4di __builtin_ia32_vpcmov_v4di256 (v4di, v4di, v4di)
+     v8si __builtin_ia32_vpcmov_v8si256 (v8si, v8si, v8si)
+     v16hi __builtin_ia32_vpcmov_v16hi256 (v16hi, v16hi, v16hi)
+     v32qi __builtin_ia32_vpcmov_v32qi256 (v32qi, v32qi, v32qi)
+     v4df __builtin_ia32_vpcmov_v4df256 (v4df, v4df, v4df)
+     v8sf __builtin_ia32_vpcmov_v8sf256 (v8sf, v8sf, v8sf)
+     v16qi __builtin_ia32_vpcomeqb (v16qi, v16qi)
+     v8hi __builtin_ia32_vpcomeqw (v8hi, v8hi)
+     v4si __builtin_ia32_vpcomeqd (v4si, v4si)
+     v2di __builtin_ia32_vpcomeqq (v2di, v2di)
+     v16qi __builtin_ia32_vpcomequb (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomequd (v4si, v4si)
+     v2di __builtin_ia32_vpcomequq (v2di, v2di)
+     v8hi __builtin_ia32_vpcomequw (v8hi, v8hi)
+     v8hi __builtin_ia32_vpcomeqw (v8hi, v8hi)
+     v16qi __builtin_ia32_vpcomfalseb (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomfalsed (v4si, v4si)
+     v2di __builtin_ia32_vpcomfalseq (v2di, v2di)
+     v16qi __builtin_ia32_vpcomfalseub (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomfalseud (v4si, v4si)
+     v2di __builtin_ia32_vpcomfalseuq (v2di, v2di)
+     v8hi __builtin_ia32_vpcomfalseuw (v8hi, v8hi)
+     v8hi __builtin_ia32_vpcomfalsew (v8hi, v8hi)
+     v16qi __builtin_ia32_vpcomgeb (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomged (v4si, v4si)
+     v2di __builtin_ia32_vpcomgeq (v2di, v2di)
+     v16qi __builtin_ia32_vpcomgeub (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomgeud (v4si, v4si)
+     v2di __builtin_ia32_vpcomgeuq (v2di, v2di)
+     v8hi __builtin_ia32_vpcomgeuw (v8hi, v8hi)
+     v8hi __builtin_ia32_vpcomgew (v8hi, v8hi)
+     v16qi __builtin_ia32_vpcomgtb (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomgtd (v4si, v4si)
+     v2di __builtin_ia32_vpcomgtq (v2di, v2di)
+     v16qi __builtin_ia32_vpcomgtub (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomgtud (v4si, v4si)
+     v2di __builtin_ia32_vpcomgtuq (v2di, v2di)
+     v8hi __builtin_ia32_vpcomgtuw (v8hi, v8hi)
+     v8hi __builtin_ia32_vpcomgtw (v8hi, v8hi)
+     v16qi __builtin_ia32_vpcomleb (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomled (v4si, v4si)
+     v2di __builtin_ia32_vpcomleq (v2di, v2di)
+     v16qi __builtin_ia32_vpcomleub (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomleud (v4si, v4si)
+     v2di __builtin_ia32_vpcomleuq (v2di, v2di)
+     v8hi __builtin_ia32_vpcomleuw (v8hi, v8hi)
+     v8hi __builtin_ia32_vpcomlew (v8hi, v8hi)
+     v16qi __builtin_ia32_vpcomltb (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomltd (v4si, v4si)
+     v2di __builtin_ia32_vpcomltq (v2di, v2di)
+     v16qi __builtin_ia32_vpcomltub (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomltud (v4si, v4si)
+     v2di __builtin_ia32_vpcomltuq (v2di, v2di)
+     v8hi __builtin_ia32_vpcomltuw (v8hi, v8hi)
+     v8hi __builtin_ia32_vpcomltw (v8hi, v8hi)
+     v16qi __builtin_ia32_vpcomneb (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomned (v4si, v4si)
+     v2di __builtin_ia32_vpcomneq (v2di, v2di)
+     v16qi __builtin_ia32_vpcomneub (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomneud (v4si, v4si)
+     v2di __builtin_ia32_vpcomneuq (v2di, v2di)
+     v8hi __builtin_ia32_vpcomneuw (v8hi, v8hi)
+     v8hi __builtin_ia32_vpcomnew (v8hi, v8hi)
+     v16qi __builtin_ia32_vpcomtrueb (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomtrued (v4si, v4si)
+     v2di __builtin_ia32_vpcomtrueq (v2di, v2di)
+     v16qi __builtin_ia32_vpcomtrueub (v16qi, v16qi)
+     v4si __builtin_ia32_vpcomtrueud (v4si, v4si)
+     v2di __builtin_ia32_vpcomtrueuq (v2di, v2di)
+     v8hi __builtin_ia32_vpcomtrueuw (v8hi, v8hi)
+     v8hi __builtin_ia32_vpcomtruew (v8hi, v8hi)
+     v4si __builtin_ia32_vphaddbd (v16qi)
+     v2di __builtin_ia32_vphaddbq (v16qi)
+     v8hi __builtin_ia32_vphaddbw (v16qi)
+     v2di __builtin_ia32_vphadddq (v4si)
+     v4si __builtin_ia32_vphaddubd (v16qi)
+     v2di __builtin_ia32_vphaddubq (v16qi)
+     v8hi __builtin_ia32_vphaddubw (v16qi)
+     v2di __builtin_ia32_vphaddudq (v4si)
+     v4si __builtin_ia32_vphadduwd (v8hi)
+     v2di __builtin_ia32_vphadduwq (v8hi)
+     v4si __builtin_ia32_vphaddwd (v8hi)
+     v2di __builtin_ia32_vphaddwq (v8hi)
+     v8hi __builtin_ia32_vphsubbw (v16qi)
+     v2di __builtin_ia32_vphsubdq (v4si)
+     v4si __builtin_ia32_vphsubwd (v8hi)
+     v4si __builtin_ia32_vpmacsdd (v4si, v4si, v4si)
+     v2di __builtin_ia32_vpmacsdqh (v4si, v4si, v2di)
+     v2di __builtin_ia32_vpmacsdql (v4si, v4si, v2di)
+     v4si __builtin_ia32_vpmacssdd (v4si, v4si, v4si)
+     v2di __builtin_ia32_vpmacssdqh (v4si, v4si, v2di)
+     v2di __builtin_ia32_vpmacssdql (v4si, v4si, v2di)
+     v4si __builtin_ia32_vpmacsswd (v8hi, v8hi, v4si)
+     v8hi __builtin_ia32_vpmacssww (v8hi, v8hi, v8hi)
+     v4si __builtin_ia32_vpmacswd (v8hi, v8hi, v4si)
+     v8hi __builtin_ia32_vpmacsww (v8hi, v8hi, v8hi)
+     v4si __builtin_ia32_vpmadcsswd (v8hi, v8hi, v4si)
+     v4si __builtin_ia32_vpmadcswd (v8hi, v8hi, v4si)
+     v16qi __builtin_ia32_vpperm (v16qi, v16qi, v16qi)
+     v16qi __builtin_ia32_vprotb (v16qi, v16qi)
+     v4si __builtin_ia32_vprotd (v4si, v4si)
+     v2di __builtin_ia32_vprotq (v2di, v2di)
+     v8hi __builtin_ia32_vprotw (v8hi, v8hi)
+     v16qi __builtin_ia32_vpshab (v16qi, v16qi)
+     v4si __builtin_ia32_vpshad (v4si, v4si)
+     v2di __builtin_ia32_vpshaq (v2di, v2di)
+     v8hi __builtin_ia32_vpshaw (v8hi, v8hi)
+     v16qi __builtin_ia32_vpshlb (v16qi, v16qi)
+     v4si __builtin_ia32_vpshld (v4si, v4si)
+     v2di __builtin_ia32_vpshlq (v2di, v2di)
+     v8hi __builtin_ia32_vpshlw (v8hi, v8hi)
+
+ The following built-in functions are available when '-mfma4' is used.
+All of them generate the machine instruction that is part of the name.
+
+     v2df __builtin_ia32_vfmaddpd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfmaddps (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfmaddsd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfmaddss (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfmsubpd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfmsubps (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfmsubsd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfmsubss (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfnmaddpd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfnmaddps (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfnmaddsd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfnmaddss (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfnmsubpd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfnmsubps (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfnmsubsd (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfnmsubss (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfmaddsubpd  (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfmaddsubps  (v4sf, v4sf, v4sf)
+     v2df __builtin_ia32_vfmsubaddpd  (v2df, v2df, v2df)
+     v4sf __builtin_ia32_vfmsubaddps  (v4sf, v4sf, v4sf)
+     v4df __builtin_ia32_vfmaddpd256 (v4df, v4df, v4df)
+     v8sf __builtin_ia32_vfmaddps256 (v8sf, v8sf, v8sf)
+     v4df __builtin_ia32_vfmsubpd256 (v4df, v4df, v4df)
+     v8sf __builtin_ia32_vfmsubps256 (v8sf, v8sf, v8sf)
+     v4df __builtin_ia32_vfnmaddpd256 (v4df, v4df, v4df)
+     v8sf __builtin_ia32_vfnmaddps256 (v8sf, v8sf, v8sf)
+     v4df __builtin_ia32_vfnmsubpd256 (v4df, v4df, v4df)
+     v8sf __builtin_ia32_vfnmsubps256 (v8sf, v8sf, v8sf)
+     v4df __builtin_ia32_vfmaddsubpd256 (v4df, v4df, v4df)
+     v8sf __builtin_ia32_vfmaddsubps256 (v8sf, v8sf, v8sf)
+     v4df __builtin_ia32_vfmsubaddpd256 (v4df, v4df, v4df)
+     v8sf __builtin_ia32_vfmsubaddps256 (v8sf, v8sf, v8sf)
+
+ The following built-in functions are available when '-mlwp' is used.
+
+     void __builtin_ia32_llwpcb16 (void *);
+     void __builtin_ia32_llwpcb32 (void *);
+     void __builtin_ia32_llwpcb64 (void *);
+     void * __builtin_ia32_llwpcb16 (void);
+     void * __builtin_ia32_llwpcb32 (void);
+     void * __builtin_ia32_llwpcb64 (void);
+     void __builtin_ia32_lwpval16 (unsigned short, unsigned int, unsigned short)
+     void __builtin_ia32_lwpval32 (unsigned int, unsigned int, unsigned int)
+     void __builtin_ia32_lwpval64 (unsigned __int64, unsigned int, unsigned int)
+     unsigned char __builtin_ia32_lwpins16 (unsigned short, unsigned int, unsigned short)
+     unsigned char __builtin_ia32_lwpins32 (unsigned int, unsigned int, unsigned int)
+     unsigned char __builtin_ia32_lwpins64 (unsigned __int64, unsigned int, unsigned int)
+
+ The following built-in functions are available when '-mbmi' is used.
+All of them generate the machine instruction that is part of the name.
+     unsigned int __builtin_ia32_bextr_u32(unsigned int, unsigned int);
+     unsigned long long __builtin_ia32_bextr_u64 (unsigned long long, unsigned long long);
+
+ The following built-in functions are available when '-mbmi2' is used.
+All of them generate the machine instruction that is part of the name.
+     unsigned int _bzhi_u32 (unsigned int, unsigned int)
+     unsigned int _pdep_u32 (unsigned int, unsigned int)
+     unsigned int _pext_u32 (unsigned int, unsigned int)
+     unsigned long long _bzhi_u64 (unsigned long long, unsigned long long)
+     unsigned long long _pdep_u64 (unsigned long long, unsigned long long)
+     unsigned long long _pext_u64 (unsigned long long, unsigned long long)
+
+ The following built-in functions are available when '-mlzcnt' is used.
+All of them generate the machine instruction that is part of the name.
+     unsigned short __builtin_ia32_lzcnt_16(unsigned short);
+     unsigned int __builtin_ia32_lzcnt_u32(unsigned int);
+     unsigned long long __builtin_ia32_lzcnt_u64 (unsigned long long);
+
+ The following built-in functions are available when '-mfxsr' is used.
+All of them generate the machine instruction that is part of the name.
+     void __builtin_ia32_fxsave (void *)
+     void __builtin_ia32_fxrstor (void *)
+     void __builtin_ia32_fxsave64 (void *)
+     void __builtin_ia32_fxrstor64 (void *)
+
+ The following built-in functions are available when '-mxsave' is used.
+All of them generate the machine instruction that is part of the name.
+     void __builtin_ia32_xsave (void *, long long)
+     void __builtin_ia32_xrstor (void *, long long)
+     void __builtin_ia32_xsave64 (void *, long long)
+     void __builtin_ia32_xrstor64 (void *, long long)
+
+ The following built-in functions are available when '-mxsaveopt' is
+used.  All of them generate the machine instruction that is part of the
+name.
+     void __builtin_ia32_xsaveopt (void *, long long)
+     void __builtin_ia32_xsaveopt64 (void *, long long)
+
+ The following built-in functions are available when '-mtbm' is used.
+Both of them generate the immediate form of the bextr machine
+instruction.
+     unsigned int __builtin_ia32_bextri_u32 (unsigned int, const unsigned int);
+     unsigned long long __builtin_ia32_bextri_u64 (unsigned long long, const unsigned long long);
+
+ The following built-in functions are available when '-m3dnow' is used.
+All of them generate the machine instruction that is part of the name.
+
+     void __builtin_ia32_femms (void)
+     v8qi __builtin_ia32_pavgusb (v8qi, v8qi)
+     v2si __builtin_ia32_pf2id (v2sf)
+     v2sf __builtin_ia32_pfacc (v2sf, v2sf)
+     v2sf __builtin_ia32_pfadd (v2sf, v2sf)
+     v2si __builtin_ia32_pfcmpeq (v2sf, v2sf)
+     v2si __builtin_ia32_pfcmpge (v2sf, v2sf)
+     v2si __builtin_ia32_pfcmpgt (v2sf, v2sf)
+     v2sf __builtin_ia32_pfmax (v2sf, v2sf)
+     v2sf __builtin_ia32_pfmin (v2sf, v2sf)
+     v2sf __builtin_ia32_pfmul (v2sf, v2sf)
+     v2sf __builtin_ia32_pfrcp (v2sf)
+     v2sf __builtin_ia32_pfrcpit1 (v2sf, v2sf)
+     v2sf __builtin_ia32_pfrcpit2 (v2sf, v2sf)
+     v2sf __builtin_ia32_pfrsqrt (v2sf)
+     v2sf __builtin_ia32_pfsub (v2sf, v2sf)
+     v2sf __builtin_ia32_pfsubr (v2sf, v2sf)
+     v2sf __builtin_ia32_pi2fd (v2si)
+     v4hi __builtin_ia32_pmulhrw (v4hi, v4hi)
+
+ The following built-in functions are available when both '-m3dnow' and
+'-march=athlon' are used.  All of them generate the machine instruction
+that is part of the name.
+
+     v2si __builtin_ia32_pf2iw (v2sf)
+     v2sf __builtin_ia32_pfnacc (v2sf, v2sf)
+     v2sf __builtin_ia32_pfpnacc (v2sf, v2sf)
+     v2sf __builtin_ia32_pi2fw (v2si)
+     v2sf __builtin_ia32_pswapdsf (v2sf)
+     v2si __builtin_ia32_pswapdsi (v2si)
+
+ The following built-in functions are available when '-mrtm' is used
+They are used for restricted transactional memory.  These are the
+internal low level functions.  Normally the functions in *note X86
+transactional memory intrinsics:: should be used instead.
+
+     int __builtin_ia32_xbegin ()
+     void __builtin_ia32_xend ()
+     void __builtin_ia32_xabort (status)
+     int __builtin_ia32_xtest ()
+
+
+File: gcc.info,  Node: X86 transactional memory intrinsics,  Next: MIPS DSP Built-in Functions,  Prev: X86 Built-in Functions,  Up: Target Builtins
+
+6.57.12 X86 transaction memory intrinsics
+-----------------------------------------
+
+Hardware transactional memory intrinsics for i386.  These allow to use
+memory transactions with RTM (Restricted Transactional Memory).  For
+using HLE (Hardware Lock Elision) see *note x86 specific memory model
+extensions for transactional memory:: instead.  This support is enabled
+with the '-mrtm' option.
+
+ A memory transaction commits all changes to memory in an atomic way, as
+visible to other threads.  If the transaction fails it is rolled back
+and all side effects discarded.
+
+ Generally there is no guarantee that a memory transaction ever succeeds
+and suitable fallback code always needs to be supplied.
+
+ -- RTM Function: unsigned _xbegin ()
+     Start a RTM (Restricted Transactional Memory) transaction.  Returns
+     _XBEGIN_STARTED when the transaction started successfully (note
+     this is not 0, so the constant has to be explicitely tested).  When
+     the transaction aborts all side effects are undone and an abort
+     code is returned.  There is no guarantee any transaction ever
+     succeeds, so there always needs to be a valid tested fallback path.
+
+     #include <immintrin.h>
+
+     if ((status = _xbegin ()) == _XBEGIN_STARTED) {
+         ... transaction code...
+         _xend ();
+     } else {
+         ... non transactional fallback path...
+     }
+
+ Valid abort status bits (when the value is not '_XBEGIN_STARTED') are:
+
+'_XABORT_EXPLICIT'
+     Transaction explicitely aborted with '_xabort'.  The parameter
+     passed to '_xabort' is available with '_XABORT_CODE(status)'
+'_XABORT_RETRY'
+     Transaction retry is possible.
+'_XABORT_CONFLICT'
+     Transaction abort due to a memory conflict with another thread
+'_XABORT_CAPACITY'
+     Transaction abort due to the transaction using too much memory
+'_XABORT_DEBUG'
+     Transaction abort due to a debug trap
+'_XABORT_NESTED'
+     Transaction abort in a inner nested transaction
+
+ -- RTM Function: void _xend ()
+     Commit the current transaction.  When no transaction is active this
+     will fault.  All memory side effects of the transactions will
+     become visible to other threads in an atomic matter.
+
+ -- RTM Function: int _xtest ()
+     Return a value not zero when a transaction is currently active,
+     otherwise 0.
+
+ -- RTM Function: void _xabort (status)
+     Abort the current transaction.  When no transaction is active this
+     is a no-op.  status must be a 8bit constant, that is included in
+     the status code returned by '_xbegin'
+
+
+File: gcc.info,  Node: MIPS DSP Built-in Functions,  Next: MIPS Paired-Single Support,  Prev: X86 transactional memory intrinsics,  Up: Target Builtins
+
+6.57.13 MIPS DSP Built-in Functions
+-----------------------------------
+
+The MIPS DSP Application-Specific Extension (ASE) includes new
+instructions that are designed to improve the performance of DSP and
+media applications.  It provides instructions that operate on packed
+8-bit/16-bit integer data, Q7, Q15 and Q31 fractional data.
+
+ GCC supports MIPS DSP operations using both the generic vector
+extensions (*note Vector Extensions::) and a collection of MIPS-specific
+built-in functions.  Both kinds of support are enabled by the '-mdsp'
+command-line option.
+
+ Revision 2 of the ASE was introduced in the second half of 2006.  This
+revision adds extra instructions to the original ASE, but is otherwise
+backwards-compatible with it.  You can select revision 2 using the
+command-line option '-mdspr2'; this option implies '-mdsp'.
+
+ The SCOUNT and POS bits of the DSP control register are global.  The
+WRDSP, EXTPDP, EXTPDPV and MTHLIP instructions modify the SCOUNT and POS
+bits.  During optimization, the compiler does not delete these
+instructions and it does not delete calls to functions containing these
+instructions.
+
+ At present, GCC only provides support for operations on 32-bit vectors.
+The vector type associated with 8-bit integer data is usually called
+'v4i8', the vector type associated with Q7 is usually called 'v4q7', the
+vector type associated with 16-bit integer data is usually called
+'v2i16', and the vector type associated with Q15 is usually called
+'v2q15'.  They can be defined in C as follows:
+
+     typedef signed char v4i8 __attribute__ ((vector_size(4)));
+     typedef signed char v4q7 __attribute__ ((vector_size(4)));
+     typedef short v2i16 __attribute__ ((vector_size(4)));
+     typedef short v2q15 __attribute__ ((vector_size(4)));
+
+ 'v4i8', 'v4q7', 'v2i16' and 'v2q15' values are initialized in the same
+way as aggregates.  For example:
+
+     v4i8 a = {1, 2, 3, 4};
+     v4i8 b;
+     b = (v4i8) {5, 6, 7, 8};
+
+     v2q15 c = {0x0fcb, 0x3a75};
+     v2q15 d;
+     d = (v2q15) {0.1234 * 0x1.0p15, 0.4567 * 0x1.0p15};
+
+ _Note:_ The CPU's endianness determines the order in which values are
+packed.  On little-endian targets, the first value is the least
+significant and the last value is the most significant.  The opposite
+order applies to big-endian targets.  For example, the code above sets
+the lowest byte of 'a' to '1' on little-endian targets and '4' on
+big-endian targets.
+
+ _Note:_ Q7, Q15 and Q31 values must be initialized with their integer
+representation.  As shown in this example, the integer representation of
+a Q7 value can be obtained by multiplying the fractional value by
+'0x1.0p7'.  The equivalent for Q15 values is to multiply by '0x1.0p15'.
+The equivalent for Q31 values is to multiply by '0x1.0p31'.
+
+ The table below lists the 'v4i8' and 'v2q15' operations for which
+hardware support exists.  'a' and 'b' are 'v4i8' values, and 'c' and 'd'
+are 'v2q15' values.
+
+C code                               MIPS instruction
+'a + b'                              'addu.qb'
+'c + d'                              'addq.ph'
+'a - b'                              'subu.qb'
+'c - d'                              'subq.ph'
+
+ The table below lists the 'v2i16' operation for which hardware support
+exists for the DSP ASE REV 2.  'e' and 'f' are 'v2i16' values.
+
+C code                               MIPS instruction
+'e * f'                              'mul.ph'
+
+ It is easier to describe the DSP built-in functions if we first define
+the following types:
+
+     typedef int q31;
+     typedef int i32;
+     typedef unsigned int ui32;
+     typedef long long a64;
+
+ 'q31' and 'i32' are actually the same as 'int', but we use 'q31' to
+indicate a Q31 fractional value and 'i32' to indicate a 32-bit integer
+value.  Similarly, 'a64' is the same as 'long long', but we use 'a64' to
+indicate values that are placed in one of the four DSP accumulators
+('$ac0', '$ac1', '$ac2' or '$ac3').
+
+ Also, some built-in functions prefer or require immediate numbers as
+parameters, because the corresponding DSP instructions accept both
+immediate numbers and register operands, or accept immediate numbers
+only.  The immediate parameters are listed as follows.
+
+     imm0_3: 0 to 3.
+     imm0_7: 0 to 7.
+     imm0_15: 0 to 15.
+     imm0_31: 0 to 31.
+     imm0_63: 0 to 63.
+     imm0_255: 0 to 255.
+     imm_n32_31: -32 to 31.
+     imm_n512_511: -512 to 511.
+
+ The following built-in functions map directly to a particular MIPS DSP
+instruction.  Please refer to the architecture specification for details
+on what each instruction does.
+
+     v2q15 __builtin_mips_addq_ph (v2q15, v2q15)
+     v2q15 __builtin_mips_addq_s_ph (v2q15, v2q15)
+     q31 __builtin_mips_addq_s_w (q31, q31)
+     v4i8 __builtin_mips_addu_qb (v4i8, v4i8)
+     v4i8 __builtin_mips_addu_s_qb (v4i8, v4i8)
+     v2q15 __builtin_mips_subq_ph (v2q15, v2q15)
+     v2q15 __builtin_mips_subq_s_ph (v2q15, v2q15)
+     q31 __builtin_mips_subq_s_w (q31, q31)
+     v4i8 __builtin_mips_subu_qb (v4i8, v4i8)
+     v4i8 __builtin_mips_subu_s_qb (v4i8, v4i8)
+     i32 __builtin_mips_addsc (i32, i32)
+     i32 __builtin_mips_addwc (i32, i32)
+     i32 __builtin_mips_modsub (i32, i32)
+     i32 __builtin_mips_raddu_w_qb (v4i8)
+     v2q15 __builtin_mips_absq_s_ph (v2q15)
+     q31 __builtin_mips_absq_s_w (q31)
+     v4i8 __builtin_mips_precrq_qb_ph (v2q15, v2q15)
+     v2q15 __builtin_mips_precrq_ph_w (q31, q31)
+     v2q15 __builtin_mips_precrq_rs_ph_w (q31, q31)
+     v4i8 __builtin_mips_precrqu_s_qb_ph (v2q15, v2q15)
+     q31 __builtin_mips_preceq_w_phl (v2q15)
+     q31 __builtin_mips_preceq_w_phr (v2q15)
+     v2q15 __builtin_mips_precequ_ph_qbl (v4i8)
+     v2q15 __builtin_mips_precequ_ph_qbr (v4i8)
+     v2q15 __builtin_mips_precequ_ph_qbla (v4i8)
+     v2q15 __builtin_mips_precequ_ph_qbra (v4i8)
+     v2q15 __builtin_mips_preceu_ph_qbl (v4i8)
+     v2q15 __builtin_mips_preceu_ph_qbr (v4i8)
+     v2q15 __builtin_mips_preceu_ph_qbla (v4i8)
+     v2q15 __builtin_mips_preceu_ph_qbra (v4i8)
+     v4i8 __builtin_mips_shll_qb (v4i8, imm0_7)
+     v4i8 __builtin_mips_shll_qb (v4i8, i32)
+     v2q15 __builtin_mips_shll_ph (v2q15, imm0_15)
+     v2q15 __builtin_mips_shll_ph (v2q15, i32)
+     v2q15 __builtin_mips_shll_s_ph (v2q15, imm0_15)
+     v2q15 __builtin_mips_shll_s_ph (v2q15, i32)
+     q31 __builtin_mips_shll_s_w (q31, imm0_31)
+     q31 __builtin_mips_shll_s_w (q31, i32)
+     v4i8 __builtin_mips_shrl_qb (v4i8, imm0_7)
+     v4i8 __builtin_mips_shrl_qb (v4i8, i32)
+     v2q15 __builtin_mips_shra_ph (v2q15, imm0_15)
+     v2q15 __builtin_mips_shra_ph (v2q15, i32)
+     v2q15 __builtin_mips_shra_r_ph (v2q15, imm0_15)
+     v2q15 __builtin_mips_shra_r_ph (v2q15, i32)
+     q31 __builtin_mips_shra_r_w (q31, imm0_31)
+     q31 __builtin_mips_shra_r_w (q31, i32)
+     v2q15 __builtin_mips_muleu_s_ph_qbl (v4i8, v2q15)
+     v2q15 __builtin_mips_muleu_s_ph_qbr (v4i8, v2q15)
+     v2q15 __builtin_mips_mulq_rs_ph (v2q15, v2q15)
+     q31 __builtin_mips_muleq_s_w_phl (v2q15, v2q15)
+     q31 __builtin_mips_muleq_s_w_phr (v2q15, v2q15)
+     a64 __builtin_mips_dpau_h_qbl (a64, v4i8, v4i8)
+     a64 __builtin_mips_dpau_h_qbr (a64, v4i8, v4i8)
+     a64 __builtin_mips_dpsu_h_qbl (a64, v4i8, v4i8)
+     a64 __builtin_mips_dpsu_h_qbr (a64, v4i8, v4i8)
+     a64 __builtin_mips_dpaq_s_w_ph (a64, v2q15, v2q15)
+     a64 __builtin_mips_dpaq_sa_l_w (a64, q31, q31)
+     a64 __builtin_mips_dpsq_s_w_ph (a64, v2q15, v2q15)
+     a64 __builtin_mips_dpsq_sa_l_w (a64, q31, q31)
+     a64 __builtin_mips_mulsaq_s_w_ph (a64, v2q15, v2q15)
+     a64 __builtin_mips_maq_s_w_phl (a64, v2q15, v2q15)
+     a64 __builtin_mips_maq_s_w_phr (a64, v2q15, v2q15)
+     a64 __builtin_mips_maq_sa_w_phl (a64, v2q15, v2q15)
+     a64 __builtin_mips_maq_sa_w_phr (a64, v2q15, v2q15)
+     i32 __builtin_mips_bitrev (i32)
+     i32 __builtin_mips_insv (i32, i32)
+     v4i8 __builtin_mips_repl_qb (imm0_255)
+     v4i8 __builtin_mips_repl_qb (i32)
+     v2q15 __builtin_mips_repl_ph (imm_n512_511)
+     v2q15 __builtin_mips_repl_ph (i32)
+     void __builtin_mips_cmpu_eq_qb (v4i8, v4i8)
+     void __builtin_mips_cmpu_lt_qb (v4i8, v4i8)
+     void __builtin_mips_cmpu_le_qb (v4i8, v4i8)
+     i32 __builtin_mips_cmpgu_eq_qb (v4i8, v4i8)
+     i32 __builtin_mips_cmpgu_lt_qb (v4i8, v4i8)
+     i32 __builtin_mips_cmpgu_le_qb (v4i8, v4i8)
+     void __builtin_mips_cmp_eq_ph (v2q15, v2q15)
+     void __builtin_mips_cmp_lt_ph (v2q15, v2q15)
+     void __builtin_mips_cmp_le_ph (v2q15, v2q15)
+     v4i8 __builtin_mips_pick_qb (v4i8, v4i8)
+     v2q15 __builtin_mips_pick_ph (v2q15, v2q15)
+     v2q15 __builtin_mips_packrl_ph (v2q15, v2q15)
+     i32 __builtin_mips_extr_w (a64, imm0_31)
+     i32 __builtin_mips_extr_w (a64, i32)
+     i32 __builtin_mips_extr_r_w (a64, imm0_31)
+     i32 __builtin_mips_extr_s_h (a64, i32)
+     i32 __builtin_mips_extr_rs_w (a64, imm0_31)
+     i32 __builtin_mips_extr_rs_w (a64, i32)
+     i32 __builtin_mips_extr_s_h (a64, imm0_31)
+     i32 __builtin_mips_extr_r_w (a64, i32)
+     i32 __builtin_mips_extp (a64, imm0_31)
+     i32 __builtin_mips_extp (a64, i32)
+     i32 __builtin_mips_extpdp (a64, imm0_31)
+     i32 __builtin_mips_extpdp (a64, i32)
+     a64 __builtin_mips_shilo (a64, imm_n32_31)
+     a64 __builtin_mips_shilo (a64, i32)
+     a64 __builtin_mips_mthlip (a64, i32)
+     void __builtin_mips_wrdsp (i32, imm0_63)
+     i32 __builtin_mips_rddsp (imm0_63)
+     i32 __builtin_mips_lbux (void *, i32)
+     i32 __builtin_mips_lhx (void *, i32)
+     i32 __builtin_mips_lwx (void *, i32)
+     a64 __builtin_mips_ldx (void *, i32) [MIPS64 only]
+     i32 __builtin_mips_bposge32 (void)
+     a64 __builtin_mips_madd (a64, i32, i32);
+     a64 __builtin_mips_maddu (a64, ui32, ui32);
+     a64 __builtin_mips_msub (a64, i32, i32);
+     a64 __builtin_mips_msubu (a64, ui32, ui32);
+     a64 __builtin_mips_mult (i32, i32);
+     a64 __builtin_mips_multu (ui32, ui32);
+
+ The following built-in functions map directly to a particular MIPS DSP
+REV 2 instruction.  Please refer to the architecture specification for
+details on what each instruction does.
+
+     v4q7 __builtin_mips_absq_s_qb (v4q7);
+     v2i16 __builtin_mips_addu_ph (v2i16, v2i16);
+     v2i16 __builtin_mips_addu_s_ph (v2i16, v2i16);
+     v4i8 __builtin_mips_adduh_qb (v4i8, v4i8);
+     v4i8 __builtin_mips_adduh_r_qb (v4i8, v4i8);
+     i32 __builtin_mips_append (i32, i32, imm0_31);
+     i32 __builtin_mips_balign (i32, i32, imm0_3);
+     i32 __builtin_mips_cmpgdu_eq_qb (v4i8, v4i8);
+     i32 __builtin_mips_cmpgdu_lt_qb (v4i8, v4i8);
+     i32 __builtin_mips_cmpgdu_le_qb (v4i8, v4i8);
+     a64 __builtin_mips_dpa_w_ph (a64, v2i16, v2i16);
+     a64 __builtin_mips_dps_w_ph (a64, v2i16, v2i16);
+     v2i16 __builtin_mips_mul_ph (v2i16, v2i16);
+     v2i16 __builtin_mips_mul_s_ph (v2i16, v2i16);
+     q31 __builtin_mips_mulq_rs_w (q31, q31);
+     v2q15 __builtin_mips_mulq_s_ph (v2q15, v2q15);
+     q31 __builtin_mips_mulq_s_w (q31, q31);
+     a64 __builtin_mips_mulsa_w_ph (a64, v2i16, v2i16);
+     v4i8 __builtin_mips_precr_qb_ph (v2i16, v2i16);
+     v2i16 __builtin_mips_precr_sra_ph_w (i32, i32, imm0_31);
+     v2i16 __builtin_mips_precr_sra_r_ph_w (i32, i32, imm0_31);
+     i32 __builtin_mips_prepend (i32, i32, imm0_31);
+     v4i8 __builtin_mips_shra_qb (v4i8, imm0_7);
+     v4i8 __builtin_mips_shra_r_qb (v4i8, imm0_7);
+     v4i8 __builtin_mips_shra_qb (v4i8, i32);
+     v4i8 __builtin_mips_shra_r_qb (v4i8, i32);
+     v2i16 __builtin_mips_shrl_ph (v2i16, imm0_15);
+     v2i16 __builtin_mips_shrl_ph (v2i16, i32);
+     v2i16 __builtin_mips_subu_ph (v2i16, v2i16);
+     v2i16 __builtin_mips_subu_s_ph (v2i16, v2i16);
+     v4i8 __builtin_mips_subuh_qb (v4i8, v4i8);
+     v4i8 __builtin_mips_subuh_r_qb (v4i8, v4i8);
+     v2q15 __builtin_mips_addqh_ph (v2q15, v2q15);
+     v2q15 __builtin_mips_addqh_r_ph (v2q15, v2q15);
+     q31 __builtin_mips_addqh_w (q31, q31);
+     q31 __builtin_mips_addqh_r_w (q31, q31);
+     v2q15 __builtin_mips_subqh_ph (v2q15, v2q15);
+     v2q15 __builtin_mips_subqh_r_ph (v2q15, v2q15);
+     q31 __builtin_mips_subqh_w (q31, q31);
+     q31 __builtin_mips_subqh_r_w (q31, q31);
+     a64 __builtin_mips_dpax_w_ph (a64, v2i16, v2i16);
+     a64 __builtin_mips_dpsx_w_ph (a64, v2i16, v2i16);
+     a64 __builtin_mips_dpaqx_s_w_ph (a64, v2q15, v2q15);
+     a64 __builtin_mips_dpaqx_sa_w_ph (a64, v2q15, v2q15);
+     a64 __builtin_mips_dpsqx_s_w_ph (a64, v2q15, v2q15);
+     a64 __builtin_mips_dpsqx_sa_w_ph (a64, v2q15, v2q15);
+
+
+File: gcc.info,  Node: MIPS Paired-Single Support,  Next: MIPS Loongson Built-in Functions,  Prev: MIPS DSP Built-in Functions,  Up: Target Builtins
+
+6.57.14 MIPS Paired-Single Support
+----------------------------------
+
+The MIPS64 architecture includes a number of instructions that operate
+on pairs of single-precision floating-point values.  Each pair is packed
+into a 64-bit floating-point register, with one element being designated
+the "upper half" and the other being designated the "lower half".
+
+ GCC supports paired-single operations using both the generic vector
+extensions (*note Vector Extensions::) and a collection of MIPS-specific
+built-in functions.  Both kinds of support are enabled by the
+'-mpaired-single' command-line option.
+
+ The vector type associated with paired-single values is usually called
+'v2sf'.  It can be defined in C as follows:
+
+     typedef float v2sf __attribute__ ((vector_size (8)));
+
+ 'v2sf' values are initialized in the same way as aggregates.  For
+example:
+
+     v2sf a = {1.5, 9.1};
+     v2sf b;
+     float e, f;
+     b = (v2sf) {e, f};
+
+ _Note:_ The CPU's endianness determines which value is stored in the
+upper half of a register and which value is stored in the lower half.
+On little-endian targets, the first value is the lower one and the
+second value is the upper one.  The opposite order applies to big-endian
+targets.  For example, the code above sets the lower half of 'a' to
+'1.5' on little-endian targets and '9.1' on big-endian targets.
+
+
+File: gcc.info,  Node: MIPS Loongson Built-in Functions,  Next: Other MIPS Built-in Functions,  Prev: MIPS Paired-Single Support,  Up: Target Builtins
+
+6.57.15 MIPS Loongson Built-in Functions
+----------------------------------------
+
+GCC provides intrinsics to access the SIMD instructions provided by the
+ST Microelectronics Loongson-2E and -2F processors.  These intrinsics,
+available after inclusion of the 'loongson.h' header file, operate on
+the following 64-bit vector types:
+
+   * 'uint8x8_t', a vector of eight unsigned 8-bit integers;
+   * 'uint16x4_t', a vector of four unsigned 16-bit integers;
+   * 'uint32x2_t', a vector of two unsigned 32-bit integers;
+   * 'int8x8_t', a vector of eight signed 8-bit integers;
+   * 'int16x4_t', a vector of four signed 16-bit integers;
+   * 'int32x2_t', a vector of two signed 32-bit integers.
+
+ The intrinsics provided are listed below; each is named after the
+machine instruction to which it corresponds, with suffixes added as
+appropriate to distinguish intrinsics that expand to the same machine
+instruction yet have different argument types.  Refer to the
+architecture documentation for a description of the functionality of
+each instruction.
+
+     int16x4_t packsswh (int32x2_t s, int32x2_t t);
+     int8x8_t packsshb (int16x4_t s, int16x4_t t);
+     uint8x8_t packushb (uint16x4_t s, uint16x4_t t);
+     uint32x2_t paddw_u (uint32x2_t s, uint32x2_t t);
+     uint16x4_t paddh_u (uint16x4_t s, uint16x4_t t);
+     uint8x8_t paddb_u (uint8x8_t s, uint8x8_t t);
+     int32x2_t paddw_s (int32x2_t s, int32x2_t t);
+     int16x4_t paddh_s (int16x4_t s, int16x4_t t);
+     int8x8_t paddb_s (int8x8_t s, int8x8_t t);
+     uint64_t paddd_u (uint64_t s, uint64_t t);
+     int64_t paddd_s (int64_t s, int64_t t);
+     int16x4_t paddsh (int16x4_t s, int16x4_t t);
+     int8x8_t paddsb (int8x8_t s, int8x8_t t);
+     uint16x4_t paddush (uint16x4_t s, uint16x4_t t);
+     uint8x8_t paddusb (uint8x8_t s, uint8x8_t t);
+     uint64_t pandn_ud (uint64_t s, uint64_t t);
+     uint32x2_t pandn_uw (uint32x2_t s, uint32x2_t t);
+     uint16x4_t pandn_uh (uint16x4_t s, uint16x4_t t);
+     uint8x8_t pandn_ub (uint8x8_t s, uint8x8_t t);
+     int64_t pandn_sd (int64_t s, int64_t t);
+     int32x2_t pandn_sw (int32x2_t s, int32x2_t t);
+     int16x4_t pandn_sh (int16x4_t s, int16x4_t t);
+     int8x8_t pandn_sb (int8x8_t s, int8x8_t t);
+     uint16x4_t pavgh (uint16x4_t s, uint16x4_t t);
+     uint8x8_t pavgb (uint8x8_t s, uint8x8_t t);
+     uint32x2_t pcmpeqw_u (uint32x2_t s, uint32x2_t t);
+     uint16x4_t pcmpeqh_u (uint16x4_t s, uint16x4_t t);
+     uint8x8_t pcmpeqb_u (uint8x8_t s, uint8x8_t t);
+     int32x2_t pcmpeqw_s (int32x2_t s, int32x2_t t);
+     int16x4_t pcmpeqh_s (int16x4_t s, int16x4_t t);
+     int8x8_t pcmpeqb_s (int8x8_t s, int8x8_t t);
+     uint32x2_t pcmpgtw_u (uint32x2_t s, uint32x2_t t);
+     uint16x4_t pcmpgth_u (uint16x4_t s, uint16x4_t t);
+     uint8x8_t pcmpgtb_u (uint8x8_t s, uint8x8_t t);
+     int32x2_t pcmpgtw_s (int32x2_t s, int32x2_t t);
+     int16x4_t pcmpgth_s (int16x4_t s, int16x4_t t);
+     int8x8_t pcmpgtb_s (int8x8_t s, int8x8_t t);
+     uint16x4_t pextrh_u (uint16x4_t s, int field);
+     int16x4_t pextrh_s (int16x4_t s, int field);
+     uint16x4_t pinsrh_0_u (uint16x4_t s, uint16x4_t t);
+     uint16x4_t pinsrh_1_u (uint16x4_t s, uint16x4_t t);
+     uint16x4_t pinsrh_2_u (uint16x4_t s, uint16x4_t t);
+     uint16x4_t pinsrh_3_u (uint16x4_t s, uint16x4_t t);
+     int16x4_t pinsrh_0_s (int16x4_t s, int16x4_t t);
+     int16x4_t pinsrh_1_s (int16x4_t s, int16x4_t t);
+     int16x4_t pinsrh_2_s (int16x4_t s, int16x4_t t);
+     int16x4_t pinsrh_3_s (int16x4_t s, int16x4_t t);
+     int32x2_t pmaddhw (int16x4_t s, int16x4_t t);
+     int16x4_t pmaxsh (int16x4_t s, int16x4_t t);
+     uint8x8_t pmaxub (uint8x8_t s, uint8x8_t t);
+     int16x4_t pminsh (int16x4_t s, int16x4_t t);
+     uint8x8_t pminub (uint8x8_t s, uint8x8_t t);
+     uint8x8_t pmovmskb_u (uint8x8_t s);
+     int8x8_t pmovmskb_s (int8x8_t s);
+     uint16x4_t pmulhuh (uint16x4_t s, uint16x4_t t);
+     int16x4_t pmulhh (int16x4_t s, int16x4_t t);
+     int16x4_t pmullh (int16x4_t s, int16x4_t t);
+     int64_t pmuluw (uint32x2_t s, uint32x2_t t);
+     uint8x8_t pasubub (uint8x8_t s, uint8x8_t t);
+     uint16x4_t biadd (uint8x8_t s);
+     uint16x4_t psadbh (uint8x8_t s, uint8x8_t t);
+     uint16x4_t pshufh_u (uint16x4_t dest, uint16x4_t s, uint8_t order);
+     int16x4_t pshufh_s (int16x4_t dest, int16x4_t s, uint8_t order);
+     uint16x4_t psllh_u (uint16x4_t s, uint8_t amount);
+     int16x4_t psllh_s (int16x4_t s, uint8_t amount);
+     uint32x2_t psllw_u (uint32x2_t s, uint8_t amount);
+     int32x2_t psllw_s (int32x2_t s, uint8_t amount);
+     uint16x4_t psrlh_u (uint16x4_t s, uint8_t amount);
+     int16x4_t psrlh_s (int16x4_t s, uint8_t amount);
+     uint32x2_t psrlw_u (uint32x2_t s, uint8_t amount);
+     int32x2_t psrlw_s (int32x2_t s, uint8_t amount);
+     uint16x4_t psrah_u (uint16x4_t s, uint8_t amount);
+     int16x4_t psrah_s (int16x4_t s, uint8_t amount);
+     uint32x2_t psraw_u (uint32x2_t s, uint8_t amount);
+     int32x2_t psraw_s (int32x2_t s, uint8_t amount);
+     uint32x2_t psubw_u (uint32x2_t s, uint32x2_t t);
+     uint16x4_t psubh_u (uint16x4_t s, uint16x4_t t);
+     uint8x8_t psubb_u (uint8x8_t s, uint8x8_t t);
+     int32x2_t psubw_s (int32x2_t s, int32x2_t t);
+     int16x4_t psubh_s (int16x4_t s, int16x4_t t);
+     int8x8_t psubb_s (int8x8_t s, int8x8_t t);
+     uint64_t psubd_u (uint64_t s, uint64_t t);
+     int64_t psubd_s (int64_t s, int64_t t);
+     int16x4_t psubsh (int16x4_t s, int16x4_t t);
+     int8x8_t psubsb (int8x8_t s, int8x8_t t);
+     uint16x4_t psubush (uint16x4_t s, uint16x4_t t);
+     uint8x8_t psubusb (uint8x8_t s, uint8x8_t t);
+     uint32x2_t punpckhwd_u (uint32x2_t s, uint32x2_t t);
+     uint16x4_t punpckhhw_u (uint16x4_t s, uint16x4_t t);
+     uint8x8_t punpckhbh_u (uint8x8_t s, uint8x8_t t);
+     int32x2_t punpckhwd_s (int32x2_t s, int32x2_t t);
+     int16x4_t punpckhhw_s (int16x4_t s, int16x4_t t);
+     int8x8_t punpckhbh_s (int8x8_t s, int8x8_t t);
+     uint32x2_t punpcklwd_u (uint32x2_t s, uint32x2_t t);
+     uint16x4_t punpcklhw_u (uint16x4_t s, uint16x4_t t);
+     uint8x8_t punpcklbh_u (uint8x8_t s, uint8x8_t t);
+     int32x2_t punpcklwd_s (int32x2_t s, int32x2_t t);
+     int16x4_t punpcklhw_s (int16x4_t s, int16x4_t t);
+     int8x8_t punpcklbh_s (int8x8_t s, int8x8_t t);
+
+* Menu:
+
+* Paired-Single Arithmetic::
+* Paired-Single Built-in Functions::
+* MIPS-3D Built-in Functions::
+
+
+File: gcc.info,  Node: Paired-Single Arithmetic,  Next: Paired-Single Built-in Functions,  Up: MIPS Loongson Built-in Functions
+
+6.57.15.1 Paired-Single Arithmetic
+..................................
+
+The table below lists the 'v2sf' operations for which hardware support
+exists.  'a', 'b' and 'c' are 'v2sf' values and 'x' is an integral
+value.
+
+C code                               MIPS instruction
+'a + b'                              'add.ps'
+'a - b'                              'sub.ps'
+'-a'                                 'neg.ps'
+'a * b'                              'mul.ps'
+'a * b + c'                          'madd.ps'
+'a * b - c'                          'msub.ps'
+'-(a * b + c)'                       'nmadd.ps'
+'-(a * b - c)'                       'nmsub.ps'
+'x ? a : b'                          'movn.ps'/'movz.ps'
+
+ Note that the multiply-accumulate instructions can be disabled using
+the command-line option '-mno-fused-madd'.
+
+
+File: gcc.info,  Node: Paired-Single Built-in Functions,  Next: MIPS-3D Built-in Functions,  Prev: Paired-Single Arithmetic,  Up: MIPS Loongson Built-in Functions
+
+6.57.15.2 Paired-Single Built-in Functions
+..........................................
+
+The following paired-single functions map directly to a particular MIPS
+instruction.  Please refer to the architecture specification for details
+on what each instruction does.
+
+'v2sf __builtin_mips_pll_ps (v2sf, v2sf)'
+     Pair lower lower ('pll.ps').
+
+'v2sf __builtin_mips_pul_ps (v2sf, v2sf)'
+     Pair upper lower ('pul.ps').
+
+'v2sf __builtin_mips_plu_ps (v2sf, v2sf)'
+     Pair lower upper ('plu.ps').
+
+'v2sf __builtin_mips_puu_ps (v2sf, v2sf)'
+     Pair upper upper ('puu.ps').
+
+'v2sf __builtin_mips_cvt_ps_s (float, float)'
+     Convert pair to paired single ('cvt.ps.s').
+
+'float __builtin_mips_cvt_s_pl (v2sf)'
+     Convert pair lower to single ('cvt.s.pl').
+
+'float __builtin_mips_cvt_s_pu (v2sf)'
+     Convert pair upper to single ('cvt.s.pu').
+
+'v2sf __builtin_mips_abs_ps (v2sf)'
+     Absolute value ('abs.ps').
+
+'v2sf __builtin_mips_alnv_ps (v2sf, v2sf, int)'
+     Align variable ('alnv.ps').
+
+     _Note:_ The value of the third parameter must be 0 or 4 modulo 8,
+     otherwise the result is unpredictable.  Please read the instruction
+     description for details.
+
+ The following multi-instruction functions are also available.  In each
+case, COND can be any of the 16 floating-point conditions: 'f', 'un',
+'eq', 'ueq', 'olt', 'ult', 'ole', 'ule', 'sf', 'ngle', 'seq', 'ngl',
+'lt', 'nge', 'le' or 'ngt'.
+
+'v2sf __builtin_mips_movt_c_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
+'v2sf __builtin_mips_movf_c_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
+     Conditional move based on floating-point comparison ('c.COND.ps',
+     'movt.ps'/'movf.ps').
+
+     The 'movt' functions return the value X computed by:
+
+          c.COND.ps CC,A,B
+          mov.ps X,C
+          movt.ps X,D,CC
+
+     The 'movf' functions are similar but use 'movf.ps' instead of
+     'movt.ps'.
+
+'int __builtin_mips_upper_c_COND_ps (v2sf A, v2sf B)'
+'int __builtin_mips_lower_c_COND_ps (v2sf A, v2sf B)'
+     Comparison of two paired-single values ('c.COND.ps',
+     'bc1t'/'bc1f').
+
+     These functions compare A and B using 'c.COND.ps' and return either
+     the upper or lower half of the result.  For example:
+
+          v2sf a, b;
+          if (__builtin_mips_upper_c_eq_ps (a, b))
+            upper_halves_are_equal ();
+          else
+            upper_halves_are_unequal ();
+
+          if (__builtin_mips_lower_c_eq_ps (a, b))
+            lower_halves_are_equal ();
+          else
+            lower_halves_are_unequal ();
+
+
+File: gcc.info,  Node: MIPS-3D Built-in Functions,  Prev: Paired-Single Built-in Functions,  Up: MIPS Loongson Built-in Functions
+
+6.57.15.3 MIPS-3D Built-in Functions
+....................................
+
+The MIPS-3D Application-Specific Extension (ASE) includes additional
+paired-single instructions that are designed to improve the performance
+of 3D graphics operations.  Support for these instructions is controlled
+by the '-mips3d' command-line option.
+
+ The functions listed below map directly to a particular MIPS-3D
+instruction.  Please refer to the architecture specification for more
+details on what each instruction does.
+
+'v2sf __builtin_mips_addr_ps (v2sf, v2sf)'
+     Reduction add ('addr.ps').
+
+'v2sf __builtin_mips_mulr_ps (v2sf, v2sf)'
+     Reduction multiply ('mulr.ps').
+
+'v2sf __builtin_mips_cvt_pw_ps (v2sf)'
+     Convert paired single to paired word ('cvt.pw.ps').
+
+'v2sf __builtin_mips_cvt_ps_pw (v2sf)'
+     Convert paired word to paired single ('cvt.ps.pw').
+
+'float __builtin_mips_recip1_s (float)'
+'double __builtin_mips_recip1_d (double)'
+'v2sf __builtin_mips_recip1_ps (v2sf)'
+     Reduced-precision reciprocal (sequence step 1) ('recip1.FMT').
+
+'float __builtin_mips_recip2_s (float, float)'
+'double __builtin_mips_recip2_d (double, double)'
+'v2sf __builtin_mips_recip2_ps (v2sf, v2sf)'
+     Reduced-precision reciprocal (sequence step 2) ('recip2.FMT').
+
+'float __builtin_mips_rsqrt1_s (float)'
+'double __builtin_mips_rsqrt1_d (double)'
+'v2sf __builtin_mips_rsqrt1_ps (v2sf)'
+     Reduced-precision reciprocal square root (sequence step 1)
+     ('rsqrt1.FMT').
+
+'float __builtin_mips_rsqrt2_s (float, float)'
+'double __builtin_mips_rsqrt2_d (double, double)'
+'v2sf __builtin_mips_rsqrt2_ps (v2sf, v2sf)'
+     Reduced-precision reciprocal square root (sequence step 2)
+     ('rsqrt2.FMT').
+
+ The following multi-instruction functions are also available.  In each
+case, COND can be any of the 16 floating-point conditions: 'f', 'un',
+'eq', 'ueq', 'olt', 'ult', 'ole', 'ule', 'sf', 'ngle', 'seq', 'ngl',
+'lt', 'nge', 'le' or 'ngt'.
+
+'int __builtin_mips_cabs_COND_s (float A, float B)'
+'int __builtin_mips_cabs_COND_d (double A, double B)'
+     Absolute comparison of two scalar values ('cabs.COND.FMT',
+     'bc1t'/'bc1f').
+
+     These functions compare A and B using 'cabs.COND.s' or
+     'cabs.COND.d' and return the result as a boolean value.  For
+     example:
+
+          float a, b;
+          if (__builtin_mips_cabs_eq_s (a, b))
+            true ();
+          else
+            false ();
+
+'int __builtin_mips_upper_cabs_COND_ps (v2sf A, v2sf B)'
+'int __builtin_mips_lower_cabs_COND_ps (v2sf A, v2sf B)'
+     Absolute comparison of two paired-single values ('cabs.COND.ps',
+     'bc1t'/'bc1f').
+
+     These functions compare A and B using 'cabs.COND.ps' and return
+     either the upper or lower half of the result.  For example:
+
+          v2sf a, b;
+          if (__builtin_mips_upper_cabs_eq_ps (a, b))
+            upper_halves_are_equal ();
+          else
+            upper_halves_are_unequal ();
+
+          if (__builtin_mips_lower_cabs_eq_ps (a, b))
+            lower_halves_are_equal ();
+          else
+            lower_halves_are_unequal ();
+
+'v2sf __builtin_mips_movt_cabs_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
+'v2sf __builtin_mips_movf_cabs_COND_ps (v2sf A, v2sf B, v2sf C, v2sf D)'
+     Conditional move based on absolute comparison ('cabs.COND.ps',
+     'movt.ps'/'movf.ps').
+
+     The 'movt' functions return the value X computed by:
+
+          cabs.COND.ps CC,A,B
+          mov.ps X,C
+          movt.ps X,D,CC
+
+     The 'movf' functions are similar but use 'movf.ps' instead of
+     'movt.ps'.
+
+'int __builtin_mips_any_c_COND_ps (v2sf A, v2sf B)'
+'int __builtin_mips_all_c_COND_ps (v2sf A, v2sf B)'
+'int __builtin_mips_any_cabs_COND_ps (v2sf A, v2sf B)'
+'int __builtin_mips_all_cabs_COND_ps (v2sf A, v2sf B)'
+     Comparison of two paired-single values ('c.COND.ps'/'cabs.COND.ps',
+     'bc1any2t'/'bc1any2f').
+
+     These functions compare A and B using 'c.COND.ps' or
+     'cabs.COND.ps'.  The 'any' forms return true if either result is
+     true and the 'all' forms return true if both results are true.  For
+     example:
+
+          v2sf a, b;
+          if (__builtin_mips_any_c_eq_ps (a, b))
+            one_is_true ();
+          else
+            both_are_false ();
+
+          if (__builtin_mips_all_c_eq_ps (a, b))
+            both_are_true ();
+          else
+            one_is_false ();
+
+'int __builtin_mips_any_c_COND_4s (v2sf A, v2sf B, v2sf C, v2sf D)'
+'int __builtin_mips_all_c_COND_4s (v2sf A, v2sf B, v2sf C, v2sf D)'
+'int __builtin_mips_any_cabs_COND_4s (v2sf A, v2sf B, v2sf C, v2sf D)'
+'int __builtin_mips_all_cabs_COND_4s (v2sf A, v2sf B, v2sf C, v2sf D)'
+     Comparison of four paired-single values
+     ('c.COND.ps'/'cabs.COND.ps', 'bc1any4t'/'bc1any4f').
+
+     These functions use 'c.COND.ps' or 'cabs.COND.ps' to compare A with
+     B and to compare C with D.  The 'any' forms return true if any of
+     the four results are true and the 'all' forms return true if all
+     four results are true.  For example:
+
+          v2sf a, b, c, d;
+          if (__builtin_mips_any_c_eq_4s (a, b, c, d))
+            some_are_true ();
+          else
+            all_are_false ();
+
+          if (__builtin_mips_all_c_eq_4s (a, b, c, d))
+            all_are_true ();
+          else
+            some_are_false ();
+
+
+File: gcc.info,  Node: Other MIPS Built-in Functions,  Next: MSP430 Built-in Functions,  Prev: MIPS Loongson Built-in Functions,  Up: Target Builtins
+
+6.57.16 Other MIPS Built-in Functions
+-------------------------------------
+
+GCC provides other MIPS-specific built-in functions:
+
+'void __builtin_mips_cache (int OP, const volatile void *ADDR)'
+     Insert a 'cache' instruction with operands OP and ADDR.  GCC
+     defines the preprocessor macro '___GCC_HAVE_BUILTIN_MIPS_CACHE'
+     when this function is available.
+
+'unsigned int __builtin_mips_get_fcsr (void)'
+'void __builtin_mips_set_fcsr (unsigned int VALUE)'
+     Get and set the contents of the floating-point control and status
+     register (FPU control register 31).  These functions are only
+     available in hard-float code but can be called in both MIPS16 and
+     non-MIPS16 contexts.
+
+     '__builtin_mips_set_fcsr' can be used to change any bit of the
+     register except the condition codes, which GCC assumes are
+     preserved.
+
+
+File: gcc.info,  Node: MSP430 Built-in Functions,  Next: NDS32 Built-in Functions,  Prev: Other MIPS Built-in Functions,  Up: Target Builtins
+
+6.57.17 MSP430 Built-in Functions
+---------------------------------
+
+GCC provides a couple of special builtin functions to aid in the writing
+of interrupt handlers in C.
+
+'__bic_SR_register_on_exit (int MASK)'
+     This clears the indicated bits in the saved copy of the status
+     register currently residing on the stack.  This only works inside
+     interrupt handlers and the changes to the status register will only
+     take affect once the handler returns.
+
+'__bis_SR_register_on_exit (int MASK)'
+     This sets the indicated bits in the saved copy of the status
+     register currently residing on the stack.  This only works inside
+     interrupt handlers and the changes to the status register will only
+     take affect once the handler returns.
+
+
+File: gcc.info,  Node: NDS32 Built-in Functions,  Next: picoChip Built-in Functions,  Prev: MSP430 Built-in Functions,  Up: Target Builtins
+
+6.57.18 NDS32 Built-in Functions
+--------------------------------
+
+These built-in functions are available for the NDS32 target:
+
+ -- Built-in Function: void __builtin_nds32_isync (int *ADDR)
+     Insert an ISYNC instruction into the instruction stream where ADDR
+     is an instruction address for serialization.
+
+ -- Built-in Function: void __builtin_nds32_isb (void)
+     Insert an ISB instruction into the instruction stream.
+
+ -- Built-in Function: int __builtin_nds32_mfsr (int SR)
+     Return the content of a system register which is mapped by SR.
+
+ -- Built-in Function: int __builtin_nds32_mfusr (int USR)
+     Return the content of a user space register which is mapped by USR.
+
+ -- Built-in Function: void __builtin_nds32_mtsr (int VALUE, int SR)
+     Move the VALUE to a system register which is mapped by SR.
+
+ -- Built-in Function: void __builtin_nds32_mtusr (int VALUE, int USR)
+     Move the VALUE to a user space register which is mapped by USR.
+
+ -- Built-in Function: void __builtin_nds32_setgie_en (void)
+     Enable global interrupt.
+
+ -- Built-in Function: void __builtin_nds32_setgie_dis (void)
+     Disable global interrupt.
+
+
+File: gcc.info,  Node: picoChip Built-in Functions,  Next: PowerPC Built-in Functions,  Prev: NDS32 Built-in Functions,  Up: Target Builtins
+
+6.57.19 picoChip Built-in Functions
+-----------------------------------
+
+GCC provides an interface to selected machine instructions from the
+picoChip instruction set.
+
+'int __builtin_sbc (int VALUE)'
+     Sign bit count.  Return the number of consecutive bits in VALUE
+     that have the same value as the sign bit.  The result is the number
+     of leading sign bits minus one, giving the number of redundant sign
+     bits in VALUE.
+
+'int __builtin_byteswap (int VALUE)'
+     Byte swap.  Return the result of swapping the upper and lower bytes
+     of VALUE.
+
+'int __builtin_brev (int VALUE)'
+     Bit reversal.  Return the result of reversing the bits in VALUE.
+     Bit 15 is swapped with bit 0, bit 14 is swapped with bit 1, and so
+     on.
+
+'int __builtin_adds (int X, int Y)'
+     Saturating addition.  Return the result of adding X and Y, storing
+     the value 32767 if the result overflows.
+
+'int __builtin_subs (int X, int Y)'
+     Saturating subtraction.  Return the result of subtracting Y from X,
+     storing the value -32768 if the result overflows.
+
+'void __builtin_halt (void)'
+     Halt.  The processor stops execution.  This built-in is useful for
+     implementing assertions.
+
+
+File: gcc.info,  Node: PowerPC Built-in Functions,  Next: PowerPC AltiVec/VSX Built-in Functions,  Prev: picoChip Built-in Functions,  Up: Target Builtins
+
+6.57.20 PowerPC Built-in Functions
+----------------------------------
+
+These built-in functions are available for the PowerPC family of
+processors:
+     float __builtin_recipdivf (float, float);
+     float __builtin_rsqrtf (float);
+     double __builtin_recipdiv (double, double);
+     double __builtin_rsqrt (double);
+     long __builtin_bpermd (long, long);
+     uint64_t __builtin_ppc_get_timebase ();
+     unsigned long __builtin_ppc_mftb ();
+
+ The 'vec_rsqrt', '__builtin_rsqrt', and '__builtin_rsqrtf' functions
+generate multiple instructions to implement the reciprocal sqrt
+functionality using reciprocal sqrt estimate instructions.
+
+ The '__builtin_recipdiv', and '__builtin_recipdivf' functions generate
+multiple instructions to implement division using the reciprocal
+estimate instructions.
+
+ The '__builtin_ppc_get_timebase' and '__builtin_ppc_mftb' functions
+generate instructions to read the Time Base Register.  The
+'__builtin_ppc_get_timebase' function may generate multiple instructions
+and always returns the 64 bits of the Time Base Register.  The
+'__builtin_ppc_mftb' function always generates one instruction and
+returns the Time Base Register value as an unsigned long, throwing away
+the most significant word on 32-bit environments.
+
+
+File: gcc.info,  Node: PowerPC AltiVec/VSX Built-in Functions,  Next: PowerPC Hardware Transactional Memory Built-in Functions,  Prev: PowerPC Built-in Functions,  Up: Target Builtins
+
+6.57.21 PowerPC AltiVec Built-in Functions
+------------------------------------------
+
+GCC provides an interface for the PowerPC family of processors to access
+the AltiVec operations described in Motorola's AltiVec Programming
+Interface Manual.  The interface is made available by including
+'<altivec.h>' and using '-maltivec' and '-mabi=altivec'.  The interface
+supports the following vector types.
+
+     vector unsigned char
+     vector signed char
+     vector bool char
+
+     vector unsigned short
+     vector signed short
+     vector bool short
+     vector pixel
+
+     vector unsigned int
+     vector signed int
+     vector bool int
+     vector float
+
+ If '-mvsx' is used the following additional vector types are
+implemented.
+
+     vector unsigned long
+     vector signed long
+     vector double
+
+ The long types are only implemented for 64-bit code generation, and the
+long type is only used in the floating point/integer conversion
+instructions.
+
+ GCC's implementation of the high-level language interface available
+from C and C++ code differs from Motorola's documentation in several
+ways.
+
+   * A vector constant is a list of constant expressions within curly
+     braces.
+
+   * A vector initializer requires no cast if the vector constant is of
+     the same type as the variable it is initializing.
+
+   * If 'signed' or 'unsigned' is omitted, the signedness of the vector
+     type is the default signedness of the base type.  The default
+     varies depending on the operating system, so a portable program
+     should always specify the signedness.
+
+   * Compiling with '-maltivec' adds keywords '__vector', 'vector',
+     '__pixel', 'pixel', '__bool' and 'bool'.  When compiling ISO C, the
+     context-sensitive substitution of the keywords 'vector', 'pixel'
+     and 'bool' is disabled.  To use them, you must include
+     '<altivec.h>' instead.
+
+   * GCC allows using a 'typedef' name as the type specifier for a
+     vector type.
+
+   * For C, overloaded functions are implemented with macros so the
+     following does not work:
+
+            vec_add ((vector signed int){1, 2, 3, 4}, foo);
+
+     Since 'vec_add' is a macro, the vector constant in the example is
+     treated as four separate arguments.  Wrap the entire argument in
+     parentheses for this to work.
+
+ _Note:_ Only the '<altivec.h>' interface is supported.  Internally, GCC
+uses built-in functions to achieve the functionality in the
+aforementioned header file, but they are not supported and are subject
+to change without notice.
+
+ The following interfaces are supported for the generic and specific
+AltiVec operations and the AltiVec predicates.  In cases where there is
+a direct mapping between generic and specific operations, only the
+generic names are shown here, although the specific operations can also
+be used.
+
+ Arguments that are documented as 'const int' require literal integral
+values within the range required for that operation.
+
+     vector signed char vec_abs (vector signed char);
+     vector signed short vec_abs (vector signed short);
+     vector signed int vec_abs (vector signed int);
+     vector float vec_abs (vector float);
+
+     vector signed char vec_abss (vector signed char);
+     vector signed short vec_abss (vector signed short);
+     vector signed int vec_abss (vector signed int);
+
+     vector signed char vec_add (vector bool char, vector signed char);
+     vector signed char vec_add (vector signed char, vector bool char);
+     vector signed char vec_add (vector signed char, vector signed char);
+     vector unsigned char vec_add (vector bool char, vector unsigned char);
+     vector unsigned char vec_add (vector unsigned char, vector bool char);
+     vector unsigned char vec_add (vector unsigned char,
+                                   vector unsigned char);
+     vector signed short vec_add (vector bool short, vector signed short);
+     vector signed short vec_add (vector signed short, vector bool short);
+     vector signed short vec_add (vector signed short, vector signed short);
+     vector unsigned short vec_add (vector bool short,
+                                    vector unsigned short);
+     vector unsigned short vec_add (vector unsigned short,
+                                    vector bool short);
+     vector unsigned short vec_add (vector unsigned short,
+                                    vector unsigned short);
+     vector signed int vec_add (vector bool int, vector signed int);
+     vector signed int vec_add (vector signed int, vector bool int);
+     vector signed int vec_add (vector signed int, vector signed int);
+     vector unsigned int vec_add (vector bool int, vector unsigned int);
+     vector unsigned int vec_add (vector unsigned int, vector bool int);
+     vector unsigned int vec_add (vector unsigned int, vector unsigned int);
+     vector float vec_add (vector float, vector float);
+
+     vector float vec_vaddfp (vector float, vector float);
+
+     vector signed int vec_vadduwm (vector bool int, vector signed int);
+     vector signed int vec_vadduwm (vector signed int, vector bool int);
+     vector signed int vec_vadduwm (vector signed int, vector signed int);
+     vector unsigned int vec_vadduwm (vector bool int, vector unsigned int);
+     vector unsigned int vec_vadduwm (vector unsigned int, vector bool int);
+     vector unsigned int vec_vadduwm (vector unsigned int,
+                                      vector unsigned int);
+
+     vector signed short vec_vadduhm (vector bool short,
+                                      vector signed short);
+     vector signed short vec_vadduhm (vector signed short,
+                                      vector bool short);
+     vector signed short vec_vadduhm (vector signed short,
+                                      vector signed short);
+     vector unsigned short vec_vadduhm (vector bool short,
+                                        vector unsigned short);
+     vector unsigned short vec_vadduhm (vector unsigned short,
+                                        vector bool short);
+     vector unsigned short vec_vadduhm (vector unsigned short,
+                                        vector unsigned short);
+
+     vector signed char vec_vaddubm (vector bool char, vector signed char);
+     vector signed char vec_vaddubm (vector signed char, vector bool char);
+     vector signed char vec_vaddubm (vector signed char, vector signed char);
+     vector unsigned char vec_vaddubm (vector bool char,
+                                       vector unsigned char);
+     vector unsigned char vec_vaddubm (vector unsigned char,
+                                       vector bool char);
+     vector unsigned char vec_vaddubm (vector unsigned char,
+                                       vector unsigned char);
+
+     vector unsigned int vec_addc (vector unsigned int, vector unsigned int);
+
+     vector unsigned char vec_adds (vector bool char, vector unsigned char);
+     vector unsigned char vec_adds (vector unsigned char, vector bool char);
+     vector unsigned char vec_adds (vector unsigned char,
+                                    vector unsigned char);
+     vector signed char vec_adds (vector bool char, vector signed char);
+     vector signed char vec_adds (vector signed char, vector bool char);
+     vector signed char vec_adds (vector signed char, vector signed char);
+     vector unsigned short vec_adds (vector bool short,
+                                     vector unsigned short);
+     vector unsigned short vec_adds (vector unsigned short,
+                                     vector bool short);
+     vector unsigned short vec_adds (vector unsigned short,
+                                     vector unsigned short);
+     vector signed short vec_adds (vector bool short, vector signed short);
+     vector signed short vec_adds (vector signed short, vector bool short);
+     vector signed short vec_adds (vector signed short, vector signed short);
+     vector unsigned int vec_adds (vector bool int, vector unsigned int);
+     vector unsigned int vec_adds (vector unsigned int, vector bool int);
+     vector unsigned int vec_adds (vector unsigned int, vector unsigned int);
+     vector signed int vec_adds (vector bool int, vector signed int);
+     vector signed int vec_adds (vector signed int, vector bool int);
+     vector signed int vec_adds (vector signed int, vector signed int);
+
+     vector signed int vec_vaddsws (vector bool int, vector signed int);
+     vector signed int vec_vaddsws (vector signed int, vector bool int);
+     vector signed int vec_vaddsws (vector signed int, vector signed int);
+
+     vector unsigned int vec_vadduws (vector bool int, vector unsigned int);
+     vector unsigned int vec_vadduws (vector unsigned int, vector bool int);
+     vector unsigned int vec_vadduws (vector unsigned int,
+                                      vector unsigned int);
+
+     vector signed short vec_vaddshs (vector bool short,
+                                      vector signed short);
+     vector signed short vec_vaddshs (vector signed short,
+                                      vector bool short);
+     vector signed short vec_vaddshs (vector signed short,
+                                      vector signed short);
+
+     vector unsigned short vec_vadduhs (vector bool short,
+                                        vector unsigned short);
+     vector unsigned short vec_vadduhs (vector unsigned short,
+                                        vector bool short);
+     vector unsigned short vec_vadduhs (vector unsigned short,
+                                        vector unsigned short);
+
+     vector signed char vec_vaddsbs (vector bool char, vector signed char);
+     vector signed char vec_vaddsbs (vector signed char, vector bool char);
+     vector signed char vec_vaddsbs (vector signed char, vector signed char);
+
+     vector unsigned char vec_vaddubs (vector bool char,
+                                       vector unsigned char);
+     vector unsigned char vec_vaddubs (vector unsigned char,
+                                       vector bool char);
+     vector unsigned char vec_vaddubs (vector unsigned char,
+                                       vector unsigned char);
+
+     vector float vec_and (vector float, vector float);
+     vector float vec_and (vector float, vector bool int);
+     vector float vec_and (vector bool int, vector float);
+     vector bool int vec_and (vector bool int, vector bool int);
+     vector signed int vec_and (vector bool int, vector signed int);
+     vector signed int vec_and (vector signed int, vector bool int);
+     vector signed int vec_and (vector signed int, vector signed int);
+     vector unsigned int vec_and (vector bool int, vector unsigned int);
+     vector unsigned int vec_and (vector unsigned int, vector bool int);
+     vector unsigned int vec_and (vector unsigned int, vector unsigned int);
+     vector bool short vec_and (vector bool short, vector bool short);
+     vector signed short vec_and (vector bool short, vector signed short);
+     vector signed short vec_and (vector signed short, vector bool short);
+     vector signed short vec_and (vector signed short, vector signed short);
+     vector unsigned short vec_and (vector bool short,
+                                    vector unsigned short);
+     vector unsigned short vec_and (vector unsigned short,
+                                    vector bool short);
+     vector unsigned short vec_and (vector unsigned short,
+                                    vector unsigned short);
+     vector signed char vec_and (vector bool char, vector signed char);
+     vector bool char vec_and (vector bool char, vector bool char);
+     vector signed char vec_and (vector signed char, vector bool char);
+     vector signed char vec_and (vector signed char, vector signed char);
+     vector unsigned char vec_and (vector bool char, vector unsigned char);
+     vector unsigned char vec_and (vector unsigned char, vector bool char);
+     vector unsigned char vec_and (vector unsigned char,
+                                   vector unsigned char);
+
+     vector float vec_andc (vector float, vector float);
+     vector float vec_andc (vector float, vector bool int);
+     vector float vec_andc (vector bool int, vector float);
+     vector bool int vec_andc (vector bool int, vector bool int);
+     vector signed int vec_andc (vector bool int, vector signed int);
+     vector signed int vec_andc (vector signed int, vector bool int);
+     vector signed int vec_andc (vector signed int, vector signed int);
+     vector unsigned int vec_andc (vector bool int, vector unsigned int);
+     vector unsigned int vec_andc (vector unsigned int, vector bool int);
+     vector unsigned int vec_andc (vector unsigned int, vector unsigned int);
+     vector bool short vec_andc (vector bool short, vector bool short);
+     vector signed short vec_andc (vector bool short, vector signed short);
+     vector signed short vec_andc (vector signed short, vector bool short);
+     vector signed short vec_andc (vector signed short, vector signed short);
+     vector unsigned short vec_andc (vector bool short,
+                                     vector unsigned short);
+     vector unsigned short vec_andc (vector unsigned short,
+                                     vector bool short);
+     vector unsigned short vec_andc (vector unsigned short,
+                                     vector unsigned short);
+     vector signed char vec_andc (vector bool char, vector signed char);
+     vector bool char vec_andc (vector bool char, vector bool char);
+     vector signed char vec_andc (vector signed char, vector bool char);
+     vector signed char vec_andc (vector signed char, vector signed char);
+     vector unsigned char vec_andc (vector bool char, vector unsigned char);
+     vector unsigned char vec_andc (vector unsigned char, vector bool char);
+     vector unsigned char vec_andc (vector unsigned char,
+                                    vector unsigned char);
+
+     vector unsigned char vec_avg (vector unsigned char,
+                                   vector unsigned char);
+     vector signed char vec_avg (vector signed char, vector signed char);
+     vector unsigned short vec_avg (vector unsigned short,
+                                    vector unsigned short);
+     vector signed short vec_avg (vector signed short, vector signed short);
+     vector unsigned int vec_avg (vector unsigned int, vector unsigned int);
+     vector signed int vec_avg (vector signed int, vector signed int);
+
+     vector signed int vec_vavgsw (vector signed int, vector signed int);
+
+     vector unsigned int vec_vavguw (vector unsigned int,
+                                     vector unsigned int);
+
+     vector signed short vec_vavgsh (vector signed short,
+                                     vector signed short);
+
+     vector unsigned short vec_vavguh (vector unsigned short,
+                                       vector unsigned short);
+
+     vector signed char vec_vavgsb (vector signed char, vector signed char);
+
+     vector unsigned char vec_vavgub (vector unsigned char,
+                                      vector unsigned char);
+
+     vector float vec_copysign (vector float);
+
+     vector float vec_ceil (vector float);
+
+     vector signed int vec_cmpb (vector float, vector float);
+
+     vector bool char vec_cmpeq (vector signed char, vector signed char);
+     vector bool char vec_cmpeq (vector unsigned char, vector unsigned char);
+     vector bool short vec_cmpeq (vector signed short, vector signed short);
+     vector bool short vec_cmpeq (vector unsigned short,
+                                  vector unsigned short);
+     vector bool int vec_cmpeq (vector signed int, vector signed int);
+     vector bool int vec_cmpeq (vector unsigned int, vector unsigned int);
+     vector bool int vec_cmpeq (vector float, vector float);
+
+     vector bool int vec_vcmpeqfp (vector float, vector float);
+
+     vector bool int vec_vcmpequw (vector signed int, vector signed int);
+     vector bool int vec_vcmpequw (vector unsigned int, vector unsigned int);
+
+     vector bool short vec_vcmpequh (vector signed short,
+                                     vector signed short);
+     vector bool short vec_vcmpequh (vector unsigned short,
+                                     vector unsigned short);
+
+     vector bool char vec_vcmpequb (vector signed char, vector signed char);
+     vector bool char vec_vcmpequb (vector unsigned char,
+                                    vector unsigned char);
+
+     vector bool int vec_cmpge (vector float, vector float);
+
+     vector bool char vec_cmpgt (vector unsigned char, vector unsigned char);
+     vector bool char vec_cmpgt (vector signed char, vector signed char);
+     vector bool short vec_cmpgt (vector unsigned short,
+                                  vector unsigned short);
+     vector bool short vec_cmpgt (vector signed short, vector signed short);
+     vector bool int vec_cmpgt (vector unsigned int, vector unsigned int);
+     vector bool int vec_cmpgt (vector signed int, vector signed int);
+     vector bool int vec_cmpgt (vector float, vector float);
+
+     vector bool int vec_vcmpgtfp (vector float, vector float);
+
+     vector bool int vec_vcmpgtsw (vector signed int, vector signed int);
+
+     vector bool int vec_vcmpgtuw (vector unsigned int, vector unsigned int);
+
+     vector bool short vec_vcmpgtsh (vector signed short,
+                                     vector signed short);
+
+     vector bool short vec_vcmpgtuh (vector unsigned short,
+                                     vector unsigned short);
+
+     vector bool char vec_vcmpgtsb (vector signed char, vector signed char);
+
+     vector bool char vec_vcmpgtub (vector unsigned char,
+                                    vector unsigned char);
+
+     vector bool int vec_cmple (vector float, vector float);
+
+     vector bool char vec_cmplt (vector unsigned char, vector unsigned char);
+     vector bool char vec_cmplt (vector signed char, vector signed char);
+     vector bool short vec_cmplt (vector unsigned short,
+                                  vector unsigned short);
+     vector bool short vec_cmplt (vector signed short, vector signed short);
+     vector bool int vec_cmplt (vector unsigned int, vector unsigned int);
+     vector bool int vec_cmplt (vector signed int, vector signed int);
+     vector bool int vec_cmplt (vector float, vector float);
+
+     vector float vec_ctf (vector unsigned int, const int);
+     vector float vec_ctf (vector signed int, const int);
+
+     vector float vec_vcfsx (vector signed int, const int);
+
+     vector float vec_vcfux (vector unsigned int, const int);
+
+     vector signed int vec_cts (vector float, const int);
+
+     vector unsigned int vec_ctu (vector float, const int);
+
+     void vec_dss (const int);
+
+     void vec_dssall (void);
+
+     void vec_dst (const vector unsigned char *, int, const int);
+     void vec_dst (const vector signed char *, int, const int);
+     void vec_dst (const vector bool char *, int, const int);
+     void vec_dst (const vector unsigned short *, int, const int);
+     void vec_dst (const vector signed short *, int, const int);
+     void vec_dst (const vector bool short *, int, const int);
+     void vec_dst (const vector pixel *, int, const int);
+     void vec_dst (const vector unsigned int *, int, const int);
+     void vec_dst (const vector signed int *, int, const int);
+     void vec_dst (const vector bool int *, int, const int);
+     void vec_dst (const vector float *, int, const int);
+     void vec_dst (const unsigned char *, int, const int);
+     void vec_dst (const signed char *, int, const int);
+     void vec_dst (const unsigned short *, int, const int);
+     void vec_dst (const short *, int, const int);
+     void vec_dst (const unsigned int *, int, const int);
+     void vec_dst (const int *, int, const int);
+     void vec_dst (const unsigned long *, int, const int);
+     void vec_dst (const long *, int, const int);
+     void vec_dst (const float *, int, const int);
+
+     void vec_dstst (const vector unsigned char *, int, const int);
+     void vec_dstst (const vector signed char *, int, const int);
+     void vec_dstst (const vector bool char *, int, const int);
+     void vec_dstst (const vector unsigned short *, int, const int);
+     void vec_dstst (const vector signed short *, int, const int);
+     void vec_dstst (const vector bool short *, int, const int);
+     void vec_dstst (const vector pixel *, int, const int);
+     void vec_dstst (const vector unsigned int *, int, const int);
+     void vec_dstst (const vector signed int *, int, const int);
+     void vec_dstst (const vector bool int *, int, const int);
+     void vec_dstst (const vector float *, int, const int);
+     void vec_dstst (const unsigned char *, int, const int);
+     void vec_dstst (const signed char *, int, const int);
+     void vec_dstst (const unsigned short *, int, const int);
+     void vec_dstst (const short *, int, const int);
+     void vec_dstst (const unsigned int *, int, const int);
+     void vec_dstst (const int *, int, const int);
+     void vec_dstst (const unsigned long *, int, const int);
+     void vec_dstst (const long *, int, const int);
+     void vec_dstst (const float *, int, const int);
+
+     void vec_dststt (const vector unsigned char *, int, const int);
+     void vec_dststt (const vector signed char *, int, const int);
+     void vec_dststt (const vector bool char *, int, const int);
+     void vec_dststt (const vector unsigned short *, int, const int);
+     void vec_dststt (const vector signed short *, int, const int);
+     void vec_dststt (const vector bool short *, int, const int);
+     void vec_dststt (const vector pixel *, int, const int);
+     void vec_dststt (const vector unsigned int *, int, const int);
+     void vec_dststt (const vector signed int *, int, const int);
+     void vec_dststt (const vector bool int *, int, const int);
+     void vec_dststt (const vector float *, int, const int);
+     void vec_dststt (const unsigned char *, int, const int);
+     void vec_dststt (const signed char *, int, const int);
+     void vec_dststt (const unsigned short *, int, const int);
+     void vec_dststt (const short *, int, const int);
+     void vec_dststt (const unsigned int *, int, const int);
+     void vec_dststt (const int *, int, const int);
+     void vec_dststt (const unsigned long *, int, const int);
+     void vec_dststt (const long *, int, const int);
+     void vec_dststt (const float *, int, const int);
+
+     void vec_dstt (const vector unsigned char *, int, const int);
+     void vec_dstt (const vector signed char *, int, const int);
+     void vec_dstt (const vector bool char *, int, const int);
+     void vec_dstt (const vector unsigned short *, int, const int);
+     void vec_dstt (const vector signed short *, int, const int);
+     void vec_dstt (const vector bool short *, int, const int);
+     void vec_dstt (const vector pixel *, int, const int);
+     void vec_dstt (const vector unsigned int *, int, const int);
+     void vec_dstt (const vector signed int *, int, const int);
+     void vec_dstt (const vector bool int *, int, const int);
+     void vec_dstt (const vector float *, int, const int);
+     void vec_dstt (const unsigned char *, int, const int);
+     void vec_dstt (const signed char *, int, const int);
+     void vec_dstt (const unsigned short *, int, const int);
+     void vec_dstt (const short *, int, const int);
+     void vec_dstt (const unsigned int *, int, const int);
+     void vec_dstt (const int *, int, const int);
+     void vec_dstt (const unsigned long *, int, const int);
+     void vec_dstt (const long *, int, const int);
+     void vec_dstt (const float *, int, const int);
+
+     vector float vec_expte (vector float);
+
+     vector float vec_floor (vector float);
+
+     vector float vec_ld (int, const vector float *);
+     vector float vec_ld (int, const float *);
+     vector bool int vec_ld (int, const vector bool int *);
+     vector signed int vec_ld (int, const vector signed int *);
+     vector signed int vec_ld (int, const int *);
+     vector signed int vec_ld (int, const long *);
+     vector unsigned int vec_ld (int, const vector unsigned int *);
+     vector unsigned int vec_ld (int, const unsigned int *);
+     vector unsigned int vec_ld (int, const unsigned long *);
+     vector bool short vec_ld (int, const vector bool short *);
+     vector pixel vec_ld (int, const vector pixel *);
+     vector signed short vec_ld (int, const vector signed short *);
+     vector signed short vec_ld (int, const short *);
+     vector unsigned short vec_ld (int, const vector unsigned short *);
+     vector unsigned short vec_ld (int, const unsigned short *);
+     vector bool char vec_ld (int, const vector bool char *);
+     vector signed char vec_ld (int, const vector signed char *);
+     vector signed char vec_ld (int, const signed char *);
+     vector unsigned char vec_ld (int, const vector unsigned char *);
+     vector unsigned char vec_ld (int, const unsigned char *);
+
+     vector signed char vec_lde (int, const signed char *);
+     vector unsigned char vec_lde (int, const unsigned char *);
+     vector signed short vec_lde (int, const short *);
+     vector unsigned short vec_lde (int, const unsigned short *);
+     vector float vec_lde (int, const float *);
+     vector signed int vec_lde (int, const int *);
+     vector unsigned int vec_lde (int, const unsigned int *);
+     vector signed int vec_lde (int, const long *);
+     vector unsigned int vec_lde (int, const unsigned long *);
+
+     vector float vec_lvewx (int, float *);
+     vector signed int vec_lvewx (int, int *);
+     vector unsigned int vec_lvewx (int, unsigned int *);
+     vector signed int vec_lvewx (int, long *);
+     vector unsigned int vec_lvewx (int, unsigned long *);
+
+     vector signed short vec_lvehx (int, short *);
+     vector unsigned short vec_lvehx (int, unsigned short *);
+
+     vector signed char vec_lvebx (int, char *);
+     vector unsigned char vec_lvebx (int, unsigned char *);
+
+     vector float vec_ldl (int, const vector float *);
+     vector float vec_ldl (int, const float *);
+     vector bool int vec_ldl (int, const vector bool int *);
+     vector signed int vec_ldl (int, const vector signed int *);
+     vector signed int vec_ldl (int, const int *);
+     vector signed int vec_ldl (int, const long *);
+     vector unsigned int vec_ldl (int, const vector unsigned int *);
+     vector unsigned int vec_ldl (int, const unsigned int *);
+     vector unsigned int vec_ldl (int, const unsigned long *);
+     vector bool short vec_ldl (int, const vector bool short *);
+     vector pixel vec_ldl (int, const vector pixel *);
+     vector signed short vec_ldl (int, const vector signed short *);
+     vector signed short vec_ldl (int, const short *);
+     vector unsigned short vec_ldl (int, const vector unsigned short *);
+     vector unsigned short vec_ldl (int, const unsigned short *);
+     vector bool char vec_ldl (int, const vector bool char *);
+     vector signed char vec_ldl (int, const vector signed char *);
+     vector signed char vec_ldl (int, const signed char *);
+     vector unsigned char vec_ldl (int, const vector unsigned char *);
+     vector unsigned char vec_ldl (int, const unsigned char *);
+
+     vector float vec_loge (vector float);
+
+     vector unsigned char vec_lvsl (int, const volatile unsigned char *);
+     vector unsigned char vec_lvsl (int, const volatile signed char *);
+     vector unsigned char vec_lvsl (int, const volatile unsigned short *);
+     vector unsigned char vec_lvsl (int, const volatile short *);
+     vector unsigned char vec_lvsl (int, const volatile unsigned int *);
+     vector unsigned char vec_lvsl (int, const volatile int *);
+     vector unsigned char vec_lvsl (int, const volatile unsigned long *);
+     vector unsigned char vec_lvsl (int, const volatile long *);
+     vector unsigned char vec_lvsl (int, const volatile float *);
+
+     vector unsigned char vec_lvsr (int, const volatile unsigned char *);
+     vector unsigned char vec_lvsr (int, const volatile signed char *);
+     vector unsigned char vec_lvsr (int, const volatile unsigned short *);
+     vector unsigned char vec_lvsr (int, const volatile short *);
+     vector unsigned char vec_lvsr (int, const volatile unsigned int *);
+     vector unsigned char vec_lvsr (int, const volatile int *);
+     vector unsigned char vec_lvsr (int, const volatile unsigned long *);
+     vector unsigned char vec_lvsr (int, const volatile long *);
+     vector unsigned char vec_lvsr (int, const volatile float *);
+
+     vector float vec_madd (vector float, vector float, vector float);
+
+     vector signed short vec_madds (vector signed short,
+                                    vector signed short,
+                                    vector signed short);
+
+     vector unsigned char vec_max (vector bool char, vector unsigned char);
+     vector unsigned char vec_max (vector unsigned char, vector bool char);
+     vector unsigned char vec_max (vector unsigned char,
+                                   vector unsigned char);
+     vector signed char vec_max (vector bool char, vector signed char);
+     vector signed char vec_max (vector signed char, vector bool char);
+     vector signed char vec_max (vector signed char, vector signed char);
+     vector unsigned short vec_max (vector bool short,
+                                    vector unsigned short);
+     vector unsigned short vec_max (vector unsigned short,
+                                    vector bool short);
+     vector unsigned short vec_max (vector unsigned short,
+                                    vector unsigned short);
+     vector signed short vec_max (vector bool short, vector signed short);
+     vector signed short vec_max (vector signed short, vector bool short);
+     vector signed short vec_max (vector signed short, vector signed short);
+     vector unsigned int vec_max (vector bool int, vector unsigned int);
+     vector unsigned int vec_max (vector unsigned int, vector bool int);
+     vector unsigned int vec_max (vector unsigned int, vector unsigned int);
+     vector signed int vec_max (vector bool int, vector signed int);
+     vector signed int vec_max (vector signed int, vector bool int);
+     vector signed int vec_max (vector signed int, vector signed int);
+     vector float vec_max (vector float, vector float);
+
+     vector float vec_vmaxfp (vector float, vector float);
+
+     vector signed int vec_vmaxsw (vector bool int, vector signed int);
+     vector signed int vec_vmaxsw (vector signed int, vector bool int);
+     vector signed int vec_vmaxsw (vector signed int, vector signed int);
+
+     vector unsigned int vec_vmaxuw (vector bool int, vector unsigned int);
+     vector unsigned int vec_vmaxuw (vector unsigned int, vector bool int);
+     vector unsigned int vec_vmaxuw (vector unsigned int,
+                                     vector unsigned int);
+
+     vector signed short vec_vmaxsh (vector bool short, vector signed short);
+     vector signed short vec_vmaxsh (vector signed short, vector bool short);
+     vector signed short vec_vmaxsh (vector signed short,
+                                     vector signed short);
+
+     vector unsigned short vec_vmaxuh (vector bool short,
+                                       vector unsigned short);
+     vector unsigned short vec_vmaxuh (vector unsigned short,
+                                       vector bool short);
+     vector unsigned short vec_vmaxuh (vector unsigned short,
+                                       vector unsigned short);
+
+     vector signed char vec_vmaxsb (vector bool char, vector signed char);
+     vector signed char vec_vmaxsb (vector signed char, vector bool char);
+     vector signed char vec_vmaxsb (vector signed char, vector signed char);
+
+     vector unsigned char vec_vmaxub (vector bool char,
+                                      vector unsigned char);
+     vector unsigned char vec_vmaxub (vector unsigned char,
+                                      vector bool char);
+     vector unsigned char vec_vmaxub (vector unsigned char,
+                                      vector unsigned char);
+
+     vector bool char vec_mergeh (vector bool char, vector bool char);
+     vector signed char vec_mergeh (vector signed char, vector signed char);
+     vector unsigned char vec_mergeh (vector unsigned char,
+                                      vector unsigned char);
+     vector bool short vec_mergeh (vector bool short, vector bool short);
+     vector pixel vec_mergeh (vector pixel, vector pixel);
+     vector signed short vec_mergeh (vector signed short,
+                                     vector signed short);
+     vector unsigned short vec_mergeh (vector unsigned short,
+                                       vector unsigned short);
+     vector float vec_mergeh (vector float, vector float);
+     vector bool int vec_mergeh (vector bool int, vector bool int);
+     vector signed int vec_mergeh (vector signed int, vector signed int);
+     vector unsigned int vec_mergeh (vector unsigned int,
+                                     vector unsigned int);
+
+     vector float vec_vmrghw (vector float, vector float);
+     vector bool int vec_vmrghw (vector bool int, vector bool int);
+     vector signed int vec_vmrghw (vector signed int, vector signed int);
+     vector unsigned int vec_vmrghw (vector unsigned int,
+                                     vector unsigned int);
+
+     vector bool short vec_vmrghh (vector bool short, vector bool short);
+     vector signed short vec_vmrghh (vector signed short,
+                                     vector signed short);
+     vector unsigned short vec_vmrghh (vector unsigned short,
+                                       vector unsigned short);
+     vector pixel vec_vmrghh (vector pixel, vector pixel);
+
+     vector bool char vec_vmrghb (vector bool char, vector bool char);
+     vector signed char vec_vmrghb (vector signed char, vector signed char);
+     vector unsigned char vec_vmrghb (vector unsigned char,
+                                      vector unsigned char);
+
+     vector bool char vec_mergel (vector bool char, vector bool char);
+     vector signed char vec_mergel (vector signed char, vector signed char);
+     vector unsigned char vec_mergel (vector unsigned char,
+                                      vector unsigned char);
+     vector bool short vec_mergel (vector bool short, vector bool short);
+     vector pixel vec_mergel (vector pixel, vector pixel);
+     vector signed short vec_mergel (vector signed short,
+                                     vector signed short);
+     vector unsigned short vec_mergel (vector unsigned short,
+                                       vector unsigned short);
+     vector float vec_mergel (vector float, vector float);
+     vector bool int vec_mergel (vector bool int, vector bool int);
+     vector signed int vec_mergel (vector signed int, vector signed int);
+     vector unsigned int vec_mergel (vector unsigned int,
+                                     vector unsigned int);
+
+     vector float vec_vmrglw (vector float, vector float);
+     vector signed int vec_vmrglw (vector signed int, vector signed int);
+     vector unsigned int vec_vmrglw (vector unsigned int,
+                                     vector unsigned int);
+     vector bool int vec_vmrglw (vector bool int, vector bool int);
+
+     vector bool short vec_vmrglh (vector bool short, vector bool short);
+     vector signed short vec_vmrglh (vector signed short,
+                                     vector signed short);
+     vector unsigned short vec_vmrglh (vector unsigned short,
+                                       vector unsigned short);
+     vector pixel vec_vmrglh (vector pixel, vector pixel);
+
+     vector bool char vec_vmrglb (vector bool char, vector bool char);
+     vector signed char vec_vmrglb (vector signed char, vector signed char);
+     vector unsigned char vec_vmrglb (vector unsigned char,
+                                      vector unsigned char);
+
+     vector unsigned short vec_mfvscr (void);
+
+     vector unsigned char vec_min (vector bool char, vector unsigned char);
+     vector unsigned char vec_min (vector unsigned char, vector bool char);
+     vector unsigned char vec_min (vector unsigned char,
+                                   vector unsigned char);
+     vector signed char vec_min (vector bool char, vector signed char);
+     vector signed char vec_min (vector signed char, vector bool char);
+     vector signed char vec_min (vector signed char, vector signed char);
+     vector unsigned short vec_min (vector bool short,
+                                    vector unsigned short);
+     vector unsigned short vec_min (vector unsigned short,
+                                    vector bool short);
+     vector unsigned short vec_min (vector unsigned short,
+                                    vector unsigned short);
+     vector signed short vec_min (vector bool short, vector signed short);
+     vector signed short vec_min (vector signed short, vector bool short);
+     vector signed short vec_min (vector signed short, vector signed short);
+     vector unsigned int vec_min (vector bool int, vector unsigned int);
+     vector unsigned int vec_min (vector unsigned int, vector bool int);
+     vector unsigned int vec_min (vector unsigned int, vector unsigned int);
+     vector signed int vec_min (vector bool int, vector signed int);
+     vector signed int vec_min (vector signed int, vector bool int);
+     vector signed int vec_min (vector signed int, vector signed int);
+     vector float vec_min (vector float, vector float);
+
+     vector float vec_vminfp (vector float, vector float);
+
+     vector signed int vec_vminsw (vector bool int, vector signed int);
+     vector signed int vec_vminsw (vector signed int, vector bool int);
+     vector signed int vec_vminsw (vector signed int, vector signed int);
+
+     vector unsigned int vec_vminuw (vector bool int, vector unsigned int);
+     vector unsigned int vec_vminuw (vector unsigned int, vector bool int);
+     vector unsigned int vec_vminuw (vector unsigned int,
+                                     vector unsigned int);
+
+     vector signed short vec_vminsh (vector bool short, vector signed short);
+     vector signed short vec_vminsh (vector signed short, vector bool short);
+     vector signed short vec_vminsh (vector signed short,
+                                     vector signed short);
+
+     vector unsigned short vec_vminuh (vector bool short,
+                                       vector unsigned short);
+     vector unsigned short vec_vminuh (vector unsigned short,
+                                       vector bool short);
+     vector unsigned short vec_vminuh (vector unsigned short,
+                                       vector unsigned short);
+
+     vector signed char vec_vminsb (vector bool char, vector signed char);
+     vector signed char vec_vminsb (vector signed char, vector bool char);
+     vector signed char vec_vminsb (vector signed char, vector signed char);
+
+     vector unsigned char vec_vminub (vector bool char,
+                                      vector unsigned char);
+     vector unsigned char vec_vminub (vector unsigned char,
+                                      vector bool char);
+     vector unsigned char vec_vminub (vector unsigned char,
+                                      vector unsigned char);
+
+     vector signed short vec_mladd (vector signed short,
+                                    vector signed short,
+                                    vector signed short);
+     vector signed short vec_mladd (vector signed short,
+                                    vector unsigned short,
+                                    vector unsigned short);
+     vector signed short vec_mladd (vector unsigned short,
+                                    vector signed short,
+                                    vector signed short);
+     vector unsigned short vec_mladd (vector unsigned short,
+                                      vector unsigned short,
+                                      vector unsigned short);
+
+     vector signed short vec_mradds (vector signed short,
+                                     vector signed short,
+                                     vector signed short);
+
+     vector unsigned int vec_msum (vector unsigned char,
+                                   vector unsigned char,
+                                   vector unsigned int);
+     vector signed int vec_msum (vector signed char,
+                                 vector unsigned char,
+                                 vector signed int);
+     vector unsigned int vec_msum (vector unsigned short,
+                                   vector unsigned short,
+                                   vector unsigned int);
+     vector signed int vec_msum (vector signed short,
+                                 vector signed short,
+                                 vector signed int);
+
+     vector signed int vec_vmsumshm (vector signed short,
+                                     vector signed short,
+                                     vector signed int);
+
+     vector unsigned int vec_vmsumuhm (vector unsigned short,
+                                       vector unsigned short,
+                                       vector unsigned int);
+
+     vector signed int vec_vmsummbm (vector signed char,
+                                     vector unsigned char,
+                                     vector signed int);
+
+     vector unsigned int vec_vmsumubm (vector unsigned char,
+                                       vector unsigned char,
+                                       vector unsigned int);
+
+     vector unsigned int vec_msums (vector unsigned short,
+                                    vector unsigned short,
+                                    vector unsigned int);
+     vector signed int vec_msums (vector signed short,
+                                  vector signed short,
+                                  vector signed int);
+
+     vector signed int vec_vmsumshs (vector signed short,
+                                     vector signed short,
+                                     vector signed int);
+
+     vector unsigned int vec_vmsumuhs (vector unsigned short,
+                                       vector unsigned short,
+                                       vector unsigned int);
+
+     void vec_mtvscr (vector signed int);
+     void vec_mtvscr (vector unsigned int);
+     void vec_mtvscr (vector bool int);
+     void vec_mtvscr (vector signed short);
+     void vec_mtvscr (vector unsigned short);
+     void vec_mtvscr (vector bool short);
+     void vec_mtvscr (vector pixel);
+     void vec_mtvscr (vector signed char);
+     void vec_mtvscr (vector unsigned char);
+     void vec_mtvscr (vector bool char);
+
+     vector unsigned short vec_mule (vector unsigned char,
+                                     vector unsigned char);
+     vector signed short vec_mule (vector signed char,
+                                   vector signed char);
+     vector unsigned int vec_mule (vector unsigned short,
+                                   vector unsigned short);
+     vector signed int vec_mule (vector signed short, vector signed short);
+
+     vector signed int vec_vmulesh (vector signed short,
+                                    vector signed short);
+
+     vector unsigned int vec_vmuleuh (vector unsigned short,
+                                      vector unsigned short);
+
+     vector signed short vec_vmulesb (vector signed char,
+                                      vector signed char);
+
+     vector unsigned short vec_vmuleub (vector unsigned char,
+                                       vector unsigned char);
+
+     vector unsigned short vec_mulo (vector unsigned char,
+                                     vector unsigned char);
+     vector signed short vec_mulo (vector signed char, vector signed char);
+     vector unsigned int vec_mulo (vector unsigned short,
+                                   vector unsigned short);
+     vector signed int vec_mulo (vector signed short, vector signed short);
+
+     vector signed int vec_vmulosh (vector signed short,
+                                    vector signed short);
+
+     vector unsigned int vec_vmulouh (vector unsigned short,
+                                      vector unsigned short);
+
+     vector signed short vec_vmulosb (vector signed char,
+                                      vector signed char);
+
+     vector unsigned short vec_vmuloub (vector unsigned char,
+                                        vector unsigned char);
+
+     vector float vec_nmsub (vector float, vector float, vector float);
+
+     vector float vec_nor (vector float, vector float);
+     vector signed int vec_nor (vector signed int, vector signed int);
+     vector unsigned int vec_nor (vector unsigned int, vector unsigned int);
+     vector bool int vec_nor (vector bool int, vector bool int);
+     vector signed short vec_nor (vector signed short, vector signed short);
+     vector unsigned short vec_nor (vector unsigned short,
+                                    vector unsigned short);
+     vector bool short vec_nor (vector bool short, vector bool short);
+     vector signed char vec_nor (vector signed char, vector signed char);
+     vector unsigned char vec_nor (vector unsigned char,
+                                   vector unsigned char);
+     vector bool char vec_nor (vector bool char, vector bool char);
+
+     vector float vec_or (vector float, vector float);
+     vector float vec_or (vector float, vector bool int);
+     vector float vec_or (vector bool int, vector float);
+     vector bool int vec_or (vector bool int, vector bool int);
+     vector signed int vec_or (vector bool int, vector signed int);
+     vector signed int vec_or (vector signed int, vector bool int);
+     vector signed int vec_or (vector signed int, vector signed int);
+     vector unsigned int vec_or (vector bool int, vector unsigned int);
+     vector unsigned int vec_or (vector unsigned int, vector bool int);
+     vector unsigned int vec_or (vector unsigned int, vector unsigned int);
+     vector bool short vec_or (vector bool short, vector bool short);
+     vector signed short vec_or (vector bool short, vector signed short);
+     vector signed short vec_or (vector signed short, vector bool short);
+     vector signed short vec_or (vector signed short, vector signed short);
+     vector unsigned short vec_or (vector bool short, vector unsigned short);
+     vector unsigned short vec_or (vector unsigned short, vector bool short);
+     vector unsigned short vec_or (vector unsigned short,
+                                   vector unsigned short);
+     vector signed char vec_or (vector bool char, vector signed char);
+     vector bool char vec_or (vector bool char, vector bool char);
+     vector signed char vec_or (vector signed char, vector bool char);
+     vector signed char vec_or (vector signed char, vector signed char);
+     vector unsigned char vec_or (vector bool char, vector unsigned char);
+     vector unsigned char vec_or (vector unsigned char, vector bool char);
+     vector unsigned char vec_or (vector unsigned char,
+                                  vector unsigned char);
+
+     vector signed char vec_pack (vector signed short, vector signed short);
+     vector unsigned char vec_pack (vector unsigned short,
+                                    vector unsigned short);
+     vector bool char vec_pack (vector bool short, vector bool short);
+     vector signed short vec_pack (vector signed int, vector signed int);
+     vector unsigned short vec_pack (vector unsigned int,
+                                     vector unsigned int);
+     vector bool short vec_pack (vector bool int, vector bool int);
+
+     vector bool short vec_vpkuwum (vector bool int, vector bool int);
+     vector signed short vec_vpkuwum (vector signed int, vector signed int);
+     vector unsigned short vec_vpkuwum (vector unsigned int,
+                                        vector unsigned int);
+
+     vector bool char vec_vpkuhum (vector bool short, vector bool short);
+     vector signed char vec_vpkuhum (vector signed short,
+                                     vector signed short);
+     vector unsigned char vec_vpkuhum (vector unsigned short,
+                                       vector unsigned short);
+
+     vector pixel vec_packpx (vector unsigned int, vector unsigned int);
+
+     vector unsigned char vec_packs (vector unsigned short,
+                                     vector unsigned short);
+     vector signed char vec_packs (vector signed short, vector signed short);
+     vector unsigned short vec_packs (vector unsigned int,
+                                      vector unsigned int);
+     vector signed short vec_packs (vector signed int, vector signed int);
+
+     vector signed short vec_vpkswss (vector signed int, vector signed int);
+
+     vector unsigned short vec_vpkuwus (vector unsigned int,
+                                        vector unsigned int);
+
+     vector signed char vec_vpkshss (vector signed short,
+                                     vector signed short);
+
+     vector unsigned char vec_vpkuhus (vector unsigned short,
+                                       vector unsigned short);
+
+     vector unsigned char vec_packsu (vector unsigned short,
+                                      vector unsigned short);
+     vector unsigned char vec_packsu (vector signed short,
+                                      vector signed short);
+     vector unsigned short vec_packsu (vector unsigned int,
+                                       vector unsigned int);
+     vector unsigned short vec_packsu (vector signed int, vector signed int);
+
+     vector unsigned short vec_vpkswus (vector signed int,
+                                        vector signed int);
+
+     vector unsigned char vec_vpkshus (vector signed short,
+                                       vector signed short);
+
+     vector float vec_perm (vector float,
+                            vector float,
+                            vector unsigned char);
+     vector signed int vec_perm (vector signed int,
+                                 vector signed int,
+                                 vector unsigned char);
+     vector unsigned int vec_perm (vector unsigned int,
+                                   vector unsigned int,
+                                   vector unsigned char);
+     vector bool int vec_perm (vector bool int,
+                               vector bool int,
+                               vector unsigned char);
+     vector signed short vec_perm (vector signed short,
+                                   vector signed short,
+                                   vector unsigned char);
+     vector unsigned short vec_perm (vector unsigned short,
+                                     vector unsigned short,
+                                     vector unsigned char);
+     vector bool short vec_perm (vector bool short,
+                                 vector bool short,
+                                 vector unsigned char);
+     vector pixel vec_perm (vector pixel,
+                            vector pixel,
+                            vector unsigned char);
+     vector signed char vec_perm (vector signed char,
+                                  vector signed char,
+                                  vector unsigned char);
+     vector unsigned char vec_perm (vector unsigned char,
+                                    vector unsigned char,
+                                    vector unsigned char);
+     vector bool char vec_perm (vector bool char,
+                                vector bool char,
+                                vector unsigned char);
+
+     vector float vec_re (vector float);
+
+     vector signed char vec_rl (vector signed char,
+                                vector unsigned char);
+     vector unsigned char vec_rl (vector unsigned char,
+                                  vector unsigned char);
+     vector signed short vec_rl (vector signed short, vector unsigned short);
+     vector unsigned short vec_rl (vector unsigned short,
+                                   vector unsigned short);
+     vector signed int vec_rl (vector signed int, vector unsigned int);
+     vector unsigned int vec_rl (vector unsigned int, vector unsigned int);
+
+     vector signed int vec_vrlw (vector signed int, vector unsigned int);
+     vector unsigned int vec_vrlw (vector unsigned int, vector unsigned int);
+
+     vector signed short vec_vrlh (vector signed short,
+                                   vector unsigned short);
+     vector unsigned short vec_vrlh (vector unsigned short,
+                                     vector unsigned short);
+
+     vector signed char vec_vrlb (vector signed char, vector unsigned char);
+     vector unsigned char vec_vrlb (vector unsigned char,
+                                    vector unsigned char);
+
+     vector float vec_round (vector float);
+
+     vector float vec_recip (vector float, vector float);
+
+     vector float vec_rsqrt (vector float);
+
+     vector float vec_rsqrte (vector float);
+
+     vector float vec_sel (vector float, vector float, vector bool int);
+     vector float vec_sel (vector float, vector float, vector unsigned int);
+     vector signed int vec_sel (vector signed int,
+                                vector signed int,
+                                vector bool int);
+     vector signed int vec_sel (vector signed int,
+                                vector signed int,
+                                vector unsigned int);
+     vector unsigned int vec_sel (vector unsigned int,
+                                  vector unsigned int,
+                                  vector bool int);
+     vector unsigned int vec_sel (vector unsigned int,
+                                  vector unsigned int,
+                                  vector unsigned int);
+     vector bool int vec_sel (vector bool int,
+                              vector bool int,
+                              vector bool int);
+     vector bool int vec_sel (vector bool int,
+                              vector bool int,
+                              vector unsigned int);
+     vector signed short vec_sel (vector signed short,
+                                  vector signed short,
+                                  vector bool short);
+     vector signed short vec_sel (vector signed short,
+                                  vector signed short,
+                                  vector unsigned short);
+     vector unsigned short vec_sel (vector unsigned short,
+                                    vector unsigned short,
+                                    vector bool short);
+     vector unsigned short vec_sel (vector unsigned short,
+                                    vector unsigned short,
+                                    vector unsigned short);
+     vector bool short vec_sel (vector bool short,
+                                vector bool short,
+                                vector bool short);
+     vector bool short vec_sel (vector bool short,
+                                vector bool short,
+                                vector unsigned short);
+     vector signed char vec_sel (vector signed char,
+                                 vector signed char,
+                                 vector bool char);
+     vector signed char vec_sel (vector signed char,
+                                 vector signed char,
+                                 vector unsigned char);
+     vector unsigned char vec_sel (vector unsigned char,
+                                   vector unsigned char,
+                                   vector bool char);
+     vector unsigned char vec_sel (vector unsigned char,
+                                   vector unsigned char,
+                                   vector unsigned char);
+     vector bool char vec_sel (vector bool char,
+                               vector bool char,
+                               vector bool char);
+     vector bool char vec_sel (vector bool char,
+                               vector bool char,
+                               vector unsigned char);
+
+     vector signed char vec_sl (vector signed char,
+                                vector unsigned char);
+     vector unsigned char vec_sl (vector unsigned char,
+                                  vector unsigned char);
+     vector signed short vec_sl (vector signed short, vector unsigned short);
+     vector unsigned short vec_sl (vector unsigned short,
+                                   vector unsigned short);
+     vector signed int vec_sl (vector signed int, vector unsigned int);
+     vector unsigned int vec_sl (vector unsigned int, vector unsigned int);
+
+     vector signed int vec_vslw (vector signed int, vector unsigned int);
+     vector unsigned int vec_vslw (vector unsigned int, vector unsigned int);
+
+     vector signed short vec_vslh (vector signed short,
+                                   vector unsigned short);
+     vector unsigned short vec_vslh (vector unsigned short,
+                                     vector unsigned short);
+
+     vector signed char vec_vslb (vector signed char, vector unsigned char);
+     vector unsigned char vec_vslb (vector unsigned char,
+                                    vector unsigned char);
+
+     vector float vec_sld (vector float, vector float, const int);
+     vector signed int vec_sld (vector signed int,
+                                vector signed int,
+                                const int);
+     vector unsigned int vec_sld (vector unsigned int,
+                                  vector unsigned int,
+                                  const int);
+     vector bool int vec_sld (vector bool int,
+                              vector bool int,
+                              const int);
+     vector signed short vec_sld (vector signed short,
+                                  vector signed short,
+                                  const int);
+     vector unsigned short vec_sld (vector unsigned short,
+                                    vector unsigned short,
+                                    const int);
+     vector bool short vec_sld (vector bool short,
+                                vector bool short,
+                                const int);
+     vector pixel vec_sld (vector pixel,
+                           vector pixel,
+                           const int);
+     vector signed char vec_sld (vector signed char,
+                                 vector signed char,
+                                 const int);
+     vector unsigned char vec_sld (vector unsigned char,
+                                   vector unsigned char,
+                                   const int);
+     vector bool char vec_sld (vector bool char,
+                               vector bool char,
+                               const int);
+
+     vector signed int vec_sll (vector signed int,
+                                vector unsigned int);
+     vector signed int vec_sll (vector signed int,
+                                vector unsigned short);
+     vector signed int vec_sll (vector signed int,
+                                vector unsigned char);
+     vector unsigned int vec_sll (vector unsigned int,
+                                  vector unsigned int);
+     vector unsigned int vec_sll (vector unsigned int,
+                                  vector unsigned short);
+     vector unsigned int vec_sll (vector unsigned int,
+                                  vector unsigned char);
+     vector bool int vec_sll (vector bool int,
+                              vector unsigned int);
+     vector bool int vec_sll (vector bool int,
+                              vector unsigned short);
+     vector bool int vec_sll (vector bool int,
+                              vector unsigned char);
+     vector signed short vec_sll (vector signed short,
+                                  vector unsigned int);
+     vector signed short vec_sll (vector signed short,
+                                  vector unsigned short);
+     vector signed short vec_sll (vector signed short,
+                                  vector unsigned char);
+     vector unsigned short vec_sll (vector unsigned short,
+                                    vector unsigned int);
+     vector unsigned short vec_sll (vector unsigned short,
+                                    vector unsigned short);
+     vector unsigned short vec_sll (vector unsigned short,
+                                    vector unsigned char);
+     vector bool short vec_sll (vector bool short, vector unsigned int);
+     vector bool short vec_sll (vector bool short, vector unsigned short);
+     vector bool short vec_sll (vector bool short, vector unsigned char);
+     vector pixel vec_sll (vector pixel, vector unsigned int);
+     vector pixel vec_sll (vector pixel, vector unsigned short);
+     vector pixel vec_sll (vector pixel, vector unsigned char);
+     vector signed char vec_sll (vector signed char, vector unsigned int);
+     vector signed char vec_sll (vector signed char, vector unsigned short);
+     vector signed char vec_sll (vector signed char, vector unsigned char);
+     vector unsigned char vec_sll (vector unsigned char,
+                                   vector unsigned int);
+     vector unsigned char vec_sll (vector unsigned char,
+                                   vector unsigned short);
+     vector unsigned char vec_sll (vector unsigned char,
+                                   vector unsigned char);
+     vector bool char vec_sll (vector bool char, vector unsigned int);
+     vector bool char vec_sll (vector bool char, vector unsigned short);
+     vector bool char vec_sll (vector bool char, vector unsigned char);
+
+     vector float vec_slo (vector float, vector signed char);
+     vector float vec_slo (vector float, vector unsigned char);
+     vector signed int vec_slo (vector signed int, vector signed char);
+     vector signed int vec_slo (vector signed int, vector unsigned char);
+     vector unsigned int vec_slo (vector unsigned int, vector signed char);
+     vector unsigned int vec_slo (vector unsigned int, vector unsigned char);
+     vector signed short vec_slo (vector signed short, vector signed char);
+     vector signed short vec_slo (vector signed short, vector unsigned char);
+     vector unsigned short vec_slo (vector unsigned short,
+                                    vector signed char);
+     vector unsigned short vec_slo (vector unsigned short,
+                                    vector unsigned char);
+     vector pixel vec_slo (vector pixel, vector signed char);
+     vector pixel vec_slo (vector pixel, vector unsigned char);
+     vector signed char vec_slo (vector signed char, vector signed char);
+     vector signed char vec_slo (vector signed char, vector unsigned char);
+     vector unsigned char vec_slo (vector unsigned char, vector signed char);
+     vector unsigned char vec_slo (vector unsigned char,
+                                   vector unsigned char);
+
+     vector signed char vec_splat (vector signed char, const int);
+     vector unsigned char vec_splat (vector unsigned char, const int);
+     vector bool char vec_splat (vector bool char, const int);
+     vector signed short vec_splat (vector signed short, const int);
+     vector unsigned short vec_splat (vector unsigned short, const int);
+     vector bool short vec_splat (vector bool short, const int);
+     vector pixel vec_splat (vector pixel, const int);
+     vector float vec_splat (vector float, const int);
+     vector signed int vec_splat (vector signed int, const int);
+     vector unsigned int vec_splat (vector unsigned int, const int);
+     vector bool int vec_splat (vector bool int, const int);
+
+     vector float vec_vspltw (vector float, const int);
+     vector signed int vec_vspltw (vector signed int, const int);
+     vector unsigned int vec_vspltw (vector unsigned int, const int);
+     vector bool int vec_vspltw (vector bool int, const int);
+
+     vector bool short vec_vsplth (vector bool short, const int);
+     vector signed short vec_vsplth (vector signed short, const int);
+     vector unsigned short vec_vsplth (vector unsigned short, const int);
+     vector pixel vec_vsplth (vector pixel, const int);
+
+     vector signed char vec_vspltb (vector signed char, const int);
+     vector unsigned char vec_vspltb (vector unsigned char, const int);
+     vector bool char vec_vspltb (vector bool char, const int);
+
+     vector signed char vec_splat_s8 (const int);
+
+     vector signed short vec_splat_s16 (const int);
+
+     vector signed int vec_splat_s32 (const int);
+
+     vector unsigned char vec_splat_u8 (const int);
+
+     vector unsigned short vec_splat_u16 (const int);
+
+     vector unsigned int vec_splat_u32 (const int);
+
+     vector signed char vec_sr (vector signed char, vector unsigned char);
+     vector unsigned char vec_sr (vector unsigned char,
+                                  vector unsigned char);
+     vector signed short vec_sr (vector signed short,
+                                 vector unsigned short);
+     vector unsigned short vec_sr (vector unsigned short,
+                                   vector unsigned short);
+     vector signed int vec_sr (vector signed int, vector unsigned int);
+     vector unsigned int vec_sr (vector unsigned int, vector unsigned int);
+
+     vector signed int vec_vsrw (vector signed int, vector unsigned int);
+     vector unsigned int vec_vsrw (vector unsigned int, vector unsigned int);
+
+     vector signed short vec_vsrh (vector signed short,
+                                   vector unsigned short);
+     vector unsigned short vec_vsrh (vector unsigned short,
+                                     vector unsigned short);
+
+     vector signed char vec_vsrb (vector signed char, vector unsigned char);
+     vector unsigned char vec_vsrb (vector unsigned char,
+                                    vector unsigned char);
+
+     vector signed char vec_sra (vector signed char, vector unsigned char);
+     vector unsigned char vec_sra (vector unsigned char,
+                                   vector unsigned char);
+     vector signed short vec_sra (vector signed short,
+                                  vector unsigned short);
+     vector unsigned short vec_sra (vector unsigned short,
+                                    vector unsigned short);
+     vector signed int vec_sra (vector signed int, vector unsigned int);
+     vector unsigned int vec_sra (vector unsigned int, vector unsigned int);
+
+     vector signed int vec_vsraw (vector signed int, vector unsigned int);
+     vector unsigned int vec_vsraw (vector unsigned int,
+                                    vector unsigned int);
+
+     vector signed short vec_vsrah (vector signed short,
+                                    vector unsigned short);
+     vector unsigned short vec_vsrah (vector unsigned short,
+                                      vector unsigned short);
+
+     vector signed char vec_vsrab (vector signed char, vector unsigned char);
+     vector unsigned char vec_vsrab (vector unsigned char,
+                                     vector unsigned char);
+
+     vector signed int vec_srl (vector signed int, vector unsigned int);
+     vector signed int vec_srl (vector signed int, vector unsigned short);
+     vector signed int vec_srl (vector signed int, vector unsigned char);
+     vector unsigned int vec_srl (vector unsigned int, vector unsigned int);
+     vector unsigned int vec_srl (vector unsigned int,
+                                  vector unsigned short);
+     vector unsigned int vec_srl (vector unsigned int, vector unsigned char);
+     vector bool int vec_srl (vector bool int, vector unsigned int);
+     vector bool int vec_srl (vector bool int, vector unsigned short);
+     vector bool int vec_srl (vector bool int, vector unsigned char);
+     vector signed short vec_srl (vector signed short, vector unsigned int);
+     vector signed short vec_srl (vector signed short,
+                                  vector unsigned short);
+     vector signed short vec_srl (vector signed short, vector unsigned char);
+     vector unsigned short vec_srl (vector unsigned short,
+                                    vector unsigned int);
+     vector unsigned short vec_srl (vector unsigned short,
+                                    vector unsigned short);
+     vector unsigned short vec_srl (vector unsigned short,
+                                    vector unsigned char);
+     vector bool short vec_srl (vector bool short, vector unsigned int);
+     vector bool short vec_srl (vector bool short, vector unsigned short);
+     vector bool short vec_srl (vector bool short, vector unsigned char);
+     vector pixel vec_srl (vector pixel, vector unsigned int);
+     vector pixel vec_srl (vector pixel, vector unsigned short);
+     vector pixel vec_srl (vector pixel, vector unsigned char);
+     vector signed char vec_srl (vector signed char, vector unsigned int);
+     vector signed char vec_srl (vector signed char, vector unsigned short);
+     vector signed char vec_srl (vector signed char, vector unsigned char);
+     vector unsigned char vec_srl (vector unsigned char,
+                                   vector unsigned int);
+     vector unsigned char vec_srl (vector unsigned char,
+                                   vector unsigned short);
+     vector unsigned char vec_srl (vector unsigned char,
+                                   vector unsigned char);
+     vector bool char vec_srl (vector bool char, vector unsigned int);
+     vector bool char vec_srl (vector bool char, vector unsigned short);
+     vector bool char vec_srl (vector bool char, vector unsigned char);
+
+     vector float vec_sro (vector float, vector signed char);
+     vector float vec_sro (vector float, vector unsigned char);
+     vector signed int vec_sro (vector signed int, vector signed char);
+     vector signed int vec_sro (vector signed int, vector unsigned char);
+     vector unsigned int vec_sro (vector unsigned int, vector signed char);
+     vector unsigned int vec_sro (vector unsigned int, vector unsigned char);
+     vector signed short vec_sro (vector signed short, vector signed char);
+     vector signed short vec_sro (vector signed short, vector unsigned char);
+     vector unsigned short vec_sro (vector unsigned short,
+                                    vector signed char);
+     vector unsigned short vec_sro (vector unsigned short,
+                                    vector unsigned char);
+     vector pixel vec_sro (vector pixel, vector signed char);
+     vector pixel vec_sro (vector pixel, vector unsigned char);
+     vector signed char vec_sro (vector signed char, vector signed char);
+     vector signed char vec_sro (vector signed char, vector unsigned char);
+     vector unsigned char vec_sro (vector unsigned char, vector signed char);
+     vector unsigned char vec_sro (vector unsigned char,
+                                   vector unsigned char);
+
+     void vec_st (vector float, int, vector float *);
+     void vec_st (vector float, int, float *);
+     void vec_st (vector signed int, int, vector signed int *);
+     void vec_st (vector signed int, int, int *);
+     void vec_st (vector unsigned int, int, vector unsigned int *);
+     void vec_st (vector unsigned int, int, unsigned int *);
+     void vec_st (vector bool int, int, vector bool int *);
+     void vec_st (vector bool int, int, unsigned int *);
+     void vec_st (vector bool int, int, int *);
+     void vec_st (vector signed short, int, vector signed short *);
+     void vec_st (vector signed short, int, short *);
+     void vec_st (vector unsigned short, int, vector unsigned short *);
+     void vec_st (vector unsigned short, int, unsigned short *);
+     void vec_st (vector bool short, int, vector bool short *);
+     void vec_st (vector bool short, int, unsigned short *);
+     void vec_st (vector pixel, int, vector pixel *);
+     void vec_st (vector pixel, int, unsigned short *);
+     void vec_st (vector pixel, int, short *);
+     void vec_st (vector bool short, int, short *);
+     void vec_st (vector signed char, int, vector signed char *);
+     void vec_st (vector signed char, int, signed char *);
+     void vec_st (vector unsigned char, int, vector unsigned char *);
+     void vec_st (vector unsigned char, int, unsigned char *);
+     void vec_st (vector bool char, int, vector bool char *);
+     void vec_st (vector bool char, int, unsigned char *);
+     void vec_st (vector bool char, int, signed char *);
+
+     void vec_ste (vector signed char, int, signed char *);
+     void vec_ste (vector unsigned char, int, unsigned char *);
+     void vec_ste (vector bool char, int, signed char *);
+     void vec_ste (vector bool char, int, unsigned char *);
+     void vec_ste (vector signed short, int, short *);
+     void vec_ste (vector unsigned short, int, unsigned short *);
+     void vec_ste (vector bool short, int, short *);
+     void vec_ste (vector bool short, int, unsigned short *);
+     void vec_ste (vector pixel, int, short *);
+     void vec_ste (vector pixel, int, unsigned short *);
+     void vec_ste (vector float, int, float *);
+     void vec_ste (vector signed int, int, int *);
+     void vec_ste (vector unsigned int, int, unsigned int *);
+     void vec_ste (vector bool int, int, int *);
+     void vec_ste (vector bool int, int, unsigned int *);
+
+     void vec_stvewx (vector float, int, float *);
+     void vec_stvewx (vector signed int, int, int *);
+     void vec_stvewx (vector unsigned int, int, unsigned int *);
+     void vec_stvewx (vector bool int, int, int *);
+     void vec_stvewx (vector bool int, int, unsigned int *);
+
+     void vec_stvehx (vector signed short, int, short *);
+     void vec_stvehx (vector unsigned short, int, unsigned short *);
+     void vec_stvehx (vector bool short, int, short *);
+     void vec_stvehx (vector bool short, int, unsigned short *);
+     void vec_stvehx (vector pixel, int, short *);
+     void vec_stvehx (vector pixel, int, unsigned short *);
+
+     void vec_stvebx (vector signed char, int, signed char *);
+     void vec_stvebx (vector unsigned char, int, unsigned char *);
+     void vec_stvebx (vector bool char, int, signed char *);
+     void vec_stvebx (vector bool char, int, unsigned char *);
+
+     void vec_stl (vector float, int, vector float *);
+     void vec_stl (vector float, int, float *);
+     void vec_stl (vector signed int, int, vector signed int *);
+     void vec_stl (vector signed int, int, int *);
+     void vec_stl (vector unsigned int, int, vector unsigned int *);
+     void vec_stl (vector unsigned int, int, unsigned int *);
+     void vec_stl (vector bool int, int, vector bool int *);
+     void vec_stl (vector bool int, int, unsigned int *);
+     void vec_stl (vector bool int, int, int *);
+     void vec_stl (vector signed short, int, vector signed short *);
+     void vec_stl (vector signed short, int, short *);
+     void vec_stl (vector unsigned short, int, vector unsigned short *);
+     void vec_stl (vector unsigned short, int, unsigned short *);
+     void vec_stl (vector bool short, int, vector bool short *);
+     void vec_stl (vector bool short, int, unsigned short *);
+     void vec_stl (vector bool short, int, short *);
+     void vec_stl (vector pixel, int, vector pixel *);
+     void vec_stl (vector pixel, int, unsigned short *);
+     void vec_stl (vector pixel, int, short *);
+     void vec_stl (vector signed char, int, vector signed char *);
+     void vec_stl (vector signed char, int, signed char *);
+     void vec_stl (vector unsigned char, int, vector unsigned char *);
+     void vec_stl (vector unsigned char, int, unsigned char *);
+     void vec_stl (vector bool char, int, vector bool char *);
+     void vec_stl (vector bool char, int, unsigned char *);
+     void vec_stl (vector bool char, int, signed char *);
+
+     vector signed char vec_sub (vector bool char, vector signed char);
+     vector signed char vec_sub (vector signed char, vector bool char);
+     vector signed char vec_sub (vector signed char, vector signed char);
+     vector unsigned char vec_sub (vector bool char, vector unsigned char);
+     vector unsigned char vec_sub (vector unsigned char, vector bool char);
+     vector unsigned char vec_sub (vector unsigned char,
+                                   vector unsigned char);
+     vector signed short vec_sub (vector bool short, vector signed short);
+     vector signed short vec_sub (vector signed short, vector bool short);
+     vector signed short vec_sub (vector signed short, vector signed short);
+     vector unsigned short vec_sub (vector bool short,
+                                    vector unsigned short);
+     vector unsigned short vec_sub (vector unsigned short,
+                                    vector bool short);
+     vector unsigned short vec_sub (vector unsigned short,
+                                    vector unsigned short);
+     vector signed int vec_sub (vector bool int, vector signed int);
+     vector signed int vec_sub (vector signed int, vector bool int);
+     vector signed int vec_sub (vector signed int, vector signed int);
+     vector unsigned int vec_sub (vector bool int, vector unsigned int);
+     vector unsigned int vec_sub (vector unsigned int, vector bool int);
+     vector unsigned int vec_sub (vector unsigned int, vector unsigned int);
+     vector float vec_sub (vector float, vector float);
+
+     vector float vec_vsubfp (vector float, vector float);
+
+     vector signed int vec_vsubuwm (vector bool int, vector signed int);
+     vector signed int vec_vsubuwm (vector signed int, vector bool int);
+     vector signed int vec_vsubuwm (vector signed int, vector signed int);
+     vector unsigned int vec_vsubuwm (vector bool int, vector unsigned int);
+     vector unsigned int vec_vsubuwm (vector unsigned int, vector bool int);
+     vector unsigned int vec_vsubuwm (vector unsigned int,
+                                      vector unsigned int);
+
+     vector signed short vec_vsubuhm (vector bool short,
+                                      vector signed short);
+     vector signed short vec_vsubuhm (vector signed short,
+                                      vector bool short);
+     vector signed short vec_vsubuhm (vector signed short,
+                                      vector signed short);
+     vector unsigned short vec_vsubuhm (vector bool short,
+                                        vector unsigned short);
+     vector unsigned short vec_vsubuhm (vector unsigned short,
+                                        vector bool short);
+     vector unsigned short vec_vsubuhm (vector unsigned short,
+                                        vector unsigned short);
+
+     vector signed char vec_vsububm (vector bool char, vector signed char);
+     vector signed char vec_vsububm (vector signed char, vector bool char);
+     vector signed char vec_vsububm (vector signed char, vector signed char);
+     vector unsigned char vec_vsububm (vector bool char,
+                                       vector unsigned char);
+     vector unsigned char vec_vsububm (vector unsigned char,
+                                       vector bool char);
+     vector unsigned char vec_vsububm (vector unsigned char,
+                                       vector unsigned char);
+
+     vector unsigned int vec_subc (vector unsigned int, vector unsigned int);
+
+     vector unsigned char vec_subs (vector bool char, vector unsigned char);
+     vector unsigned char vec_subs (vector unsigned char, vector bool char);
+     vector unsigned char vec_subs (vector unsigned char,
+                                    vector unsigned char);
+     vector signed char vec_subs (vector bool char, vector signed char);
+     vector signed char vec_subs (vector signed char, vector bool char);
+     vector signed char vec_subs (vector signed char, vector signed char);
+     vector unsigned short vec_subs (vector bool short,
+                                     vector unsigned short);
+     vector unsigned short vec_subs (vector unsigned short,
+                                     vector bool short);
+     vector unsigned short vec_subs (vector unsigned short,
+                                     vector unsigned short);
+     vector signed short vec_subs (vector bool short, vector signed short);
+     vector signed short vec_subs (vector signed short, vector bool short);
+     vector signed short vec_subs (vector signed short, vector signed short);
+     vector unsigned int vec_subs (vector bool int, vector unsigned int);
+     vector unsigned int vec_subs (vector unsigned int, vector bool int);
+     vector unsigned int vec_subs (vector unsigned int, vector unsigned int);
+     vector signed int vec_subs (vector bool int, vector signed int);
+     vector signed int vec_subs (vector signed int, vector bool int);
+     vector signed int vec_subs (vector signed int, vector signed int);
+
+     vector signed int vec_vsubsws (vector bool int, vector signed int);
+     vector signed int vec_vsubsws (vector signed int, vector bool int);
+     vector signed int vec_vsubsws (vector signed int, vector signed int);
+
+     vector unsigned int vec_vsubuws (vector bool int, vector unsigned int);
+     vector unsigned int vec_vsubuws (vector unsigned int, vector bool int);
+     vector unsigned int vec_vsubuws (vector unsigned int,
+                                      vector unsigned int);
+
+     vector signed short vec_vsubshs (vector bool short,
+                                      vector signed short);
+     vector signed short vec_vsubshs (vector signed short,
+                                      vector bool short);
+     vector signed short vec_vsubshs (vector signed short,
+                                      vector signed short);
+
+     vector unsigned short vec_vsubuhs (vector bool short,
+                                        vector unsigned short);
+     vector unsigned short vec_vsubuhs (vector unsigned short,
+                                        vector bool short);
+     vector unsigned short vec_vsubuhs (vector unsigned short,
+                                        vector unsigned short);
+
+     vector signed char vec_vsubsbs (vector bool char, vector signed char);
+     vector signed char vec_vsubsbs (vector signed char, vector bool char);
+     vector signed char vec_vsubsbs (vector signed char, vector signed char);
+
+     vector unsigned char vec_vsububs (vector bool char,
+                                       vector unsigned char);
+     vector unsigned char vec_vsububs (vector unsigned char,
+                                       vector bool char);
+     vector unsigned char vec_vsububs (vector unsigned char,
+                                       vector unsigned char);
+
+     vector unsigned int vec_sum4s (vector unsigned char,
+                                    vector unsigned int);
+     vector signed int vec_sum4s (vector signed char, vector signed int);
+     vector signed int vec_sum4s (vector signed short, vector signed int);
+
+     vector signed int vec_vsum4shs (vector signed short, vector signed int);
+
+     vector signed int vec_vsum4sbs (vector signed char, vector signed int);
+
+     vector unsigned int vec_vsum4ubs (vector unsigned char,
+                                       vector unsigned int);
+
+     vector signed int vec_sum2s (vector signed int, vector signed int);
+
+     vector signed int vec_sums (vector signed int, vector signed int);
+
+     vector float vec_trunc (vector float);
+
+     vector signed short vec_unpackh (vector signed char);
+     vector bool short vec_unpackh (vector bool char);
+     vector signed int vec_unpackh (vector signed short);
+     vector bool int vec_unpackh (vector bool short);
+     vector unsigned int vec_unpackh (vector pixel);
+
+     vector bool int vec_vupkhsh (vector bool short);
+     vector signed int vec_vupkhsh (vector signed short);
+
+     vector unsigned int vec_vupkhpx (vector pixel);
+
+     vector bool short vec_vupkhsb (vector bool char);
+     vector signed short vec_vupkhsb (vector signed char);
+
+     vector signed short vec_unpackl (vector signed char);
+     vector bool short vec_unpackl (vector bool char);
+     vector unsigned int vec_unpackl (vector pixel);
+     vector signed int vec_unpackl (vector signed short);
+     vector bool int vec_unpackl (vector bool short);
+
+     vector unsigned int vec_vupklpx (vector pixel);
+
+     vector bool int vec_vupklsh (vector bool short);
+     vector signed int vec_vupklsh (vector signed short);
+
+     vector bool short vec_vupklsb (vector bool char);
+     vector signed short vec_vupklsb (vector signed char);
+
+     vector float vec_xor (vector float, vector float);
+     vector float vec_xor (vector float, vector bool int);
+     vector float vec_xor (vector bool int, vector float);
+     vector bool int vec_xor (vector bool int, vector bool int);
+     vector signed int vec_xor (vector bool int, vector signed int);
+     vector signed int vec_xor (vector signed int, vector bool int);
+     vector signed int vec_xor (vector signed int, vector signed int);
+     vector unsigned int vec_xor (vector bool int, vector unsigned int);
+     vector unsigned int vec_xor (vector unsigned int, vector bool int);
+     vector unsigned int vec_xor (vector unsigned int, vector unsigned int);
+     vector bool short vec_xor (vector bool short, vector bool short);
+     vector signed short vec_xor (vector bool short, vector signed short);
+     vector signed short vec_xor (vector signed short, vector bool short);
+     vector signed short vec_xor (vector signed short, vector signed short);
+     vector unsigned short vec_xor (vector bool short,
+                                    vector unsigned short);
+     vector unsigned short vec_xor (vector unsigned short,
+                                    vector bool short);
+     vector unsigned short vec_xor (vector unsigned short,
+                                    vector unsigned short);
+     vector signed char vec_xor (vector bool char, vector signed char);
+     vector bool char vec_xor (vector bool char, vector bool char);
+     vector signed char vec_xor (vector signed char, vector bool char);
+     vector signed char vec_xor (vector signed char, vector signed char);
+     vector unsigned char vec_xor (vector bool char, vector unsigned char);
+     vector unsigned char vec_xor (vector unsigned char, vector bool char);
+     vector unsigned char vec_xor (vector unsigned char,
+                                   vector unsigned char);
+
+     int vec_all_eq (vector signed char, vector bool char);
+     int vec_all_eq (vector signed char, vector signed char);
+     int vec_all_eq (vector unsigned char, vector bool char);
+     int vec_all_eq (vector unsigned char, vector unsigned char);
+     int vec_all_eq (vector bool char, vector bool char);
+     int vec_all_eq (vector bool char, vector unsigned char);
+     int vec_all_eq (vector bool char, vector signed char);
+     int vec_all_eq (vector signed short, vector bool short);
+     int vec_all_eq (vector signed short, vector signed short);
+     int vec_all_eq (vector unsigned short, vector bool short);
+     int vec_all_eq (vector unsigned short, vector unsigned short);
+     int vec_all_eq (vector bool short, vector bool short);
+     int vec_all_eq (vector bool short, vector unsigned short);
+     int vec_all_eq (vector bool short, vector signed short);
+     int vec_all_eq (vector pixel, vector pixel);
+     int vec_all_eq (vector signed int, vector bool int);
+     int vec_all_eq (vector signed int, vector signed int);
+     int vec_all_eq (vector unsigned int, vector bool int);
+     int vec_all_eq (vector unsigned int, vector unsigned int);
+     int vec_all_eq (vector bool int, vector bool int);
+     int vec_all_eq (vector bool int, vector unsigned int);
+     int vec_all_eq (vector bool int, vector signed int);
+     int vec_all_eq (vector float, vector float);
+
+     int vec_all_ge (vector bool char, vector unsigned char);
+     int vec_all_ge (vector unsigned char, vector bool char);
+     int vec_all_ge (vector unsigned char, vector unsigned char);
+     int vec_all_ge (vector bool char, vector signed char);
+     int vec_all_ge (vector signed char, vector bool char);
+     int vec_all_ge (vector signed char, vector signed char);
+     int vec_all_ge (vector bool short, vector unsigned short);
+     int vec_all_ge (vector unsigned short, vector bool short);
+     int vec_all_ge (vector unsigned short, vector unsigned short);
+     int vec_all_ge (vector signed short, vector signed short);
+     int vec_all_ge (vector bool short, vector signed short);
+     int vec_all_ge (vector signed short, vector bool short);
+     int vec_all_ge (vector bool int, vector unsigned int);
+     int vec_all_ge (vector unsigned int, vector bool int);
+     int vec_all_ge (vector unsigned int, vector unsigned int);
+     int vec_all_ge (vector bool int, vector signed int);
+     int vec_all_ge (vector signed int, vector bool int);
+     int vec_all_ge (vector signed int, vector signed int);
+     int vec_all_ge (vector float, vector float);
+
+     int vec_all_gt (vector bool char, vector unsigned char);
+     int vec_all_gt (vector unsigned char, vector bool char);
+     int vec_all_gt (vector unsigned char, vector unsigned char);
+     int vec_all_gt (vector bool char, vector signed char);
+     int vec_all_gt (vector signed char, vector bool char);
+     int vec_all_gt (vector signed char, vector signed char);
+     int vec_all_gt (vector bool short, vector unsigned short);
+     int vec_all_gt (vector unsigned short, vector bool short);
+     int vec_all_gt (vector unsigned short, vector unsigned short);
+     int vec_all_gt (vector bool short, vector signed short);
+     int vec_all_gt (vector signed short, vector bool short);
+     int vec_all_gt (vector signed short, vector signed short);
+     int vec_all_gt (vector bool int, vector unsigned int);
+     int vec_all_gt (vector unsigned int, vector bool int);
+     int vec_all_gt (vector unsigned int, vector unsigned int);
+     int vec_all_gt (vector bool int, vector signed int);
+     int vec_all_gt (vector signed int, vector bool int);
+     int vec_all_gt (vector signed int, vector signed int);
+     int vec_all_gt (vector float, vector float);
+
+     int vec_all_in (vector float, vector float);
+
+     int vec_all_le (vector bool char, vector unsigned char);
+     int vec_all_le (vector unsigned char, vector bool char);
+     int vec_all_le (vector unsigned char, vector unsigned char);
+     int vec_all_le (vector bool char, vector signed char);
+     int vec_all_le (vector signed char, vector bool char);
+     int vec_all_le (vector signed char, vector signed char);
+     int vec_all_le (vector bool short, vector unsigned short);
+     int vec_all_le (vector unsigned short, vector bool short);
+     int vec_all_le (vector unsigned short, vector unsigned short);
+     int vec_all_le (vector bool short, vector signed short);
+     int vec_all_le (vector signed short, vector bool short);
+     int vec_all_le (vector signed short, vector signed short);
+     int vec_all_le (vector bool int, vector unsigned int);
+     int vec_all_le (vector unsigned int, vector bool int);
+     int vec_all_le (vector unsigned int, vector unsigned int);
+     int vec_all_le (vector bool int, vector signed int);
+     int vec_all_le (vector signed int, vector bool int);
+     int vec_all_le (vector signed int, vector signed int);
+     int vec_all_le (vector float, vector float);
+
+     int vec_all_lt (vector bool char, vector unsigned char);
+     int vec_all_lt (vector unsigned char, vector bool char);
+     int vec_all_lt (vector unsigned char, vector unsigned char);
+     int vec_all_lt (vector bool char, vector signed char);
+     int vec_all_lt (vector signed char, vector bool char);
+     int vec_all_lt (vector signed char, vector signed char);
+     int vec_all_lt (vector bool short, vector unsigned short);
+     int vec_all_lt (vector unsigned short, vector bool short);
+     int vec_all_lt (vector unsigned short, vector unsigned short);
+     int vec_all_lt (vector bool short, vector signed short);
+     int vec_all_lt (vector signed short, vector bool short);
+     int vec_all_lt (vector signed short, vector signed short);
+     int vec_all_lt (vector bool int, vector unsigned int);
+     int vec_all_lt (vector unsigned int, vector bool int);
+     int vec_all_lt (vector unsigned int, vector unsigned int);
+     int vec_all_lt (vector bool int, vector signed int);
+     int vec_all_lt (vector signed int, vector bool int);
+     int vec_all_lt (vector signed int, vector signed int);
+     int vec_all_lt (vector float, vector float);
+
+     int vec_all_nan (vector float);
+
+     int vec_all_ne (vector signed char, vector bool char);
+     int vec_all_ne (vector signed char, vector signed char);
+     int vec_all_ne (vector unsigned char, vector bool char);
+     int vec_all_ne (vector unsigned char, vector unsigned char);
+     int vec_all_ne (vector bool char, vector bool char);
+     int vec_all_ne (vector bool char, vector unsigned char);
+     int vec_all_ne (vector bool char, vector signed char);
+     int vec_all_ne (vector signed short, vector bool short);
+     int vec_all_ne (vector signed short, vector signed short);
+     int vec_all_ne (vector unsigned short, vector bool short);
+     int vec_all_ne (vector unsigned short, vector unsigned short);
+     int vec_all_ne (vector bool short, vector bool short);
+     int vec_all_ne (vector bool short, vector unsigned short);
+     int vec_all_ne (vector bool short, vector signed short);
+     int vec_all_ne (vector pixel, vector pixel);
+     int vec_all_ne (vector signed int, vector bool int);
+     int vec_all_ne (vector signed int, vector signed int);
+     int vec_all_ne (vector unsigned int, vector bool int);
+     int vec_all_ne (vector unsigned int, vector unsigned int);
+     int vec_all_ne (vector bool int, vector bool int);
+     int vec_all_ne (vector bool int, vector unsigned int);
+     int vec_all_ne (vector bool int, vector signed int);
+     int vec_all_ne (vector float, vector float);
+
+     int vec_all_nge (vector float, vector float);
+
+     int vec_all_ngt (vector float, vector float);
+
+     int vec_all_nle (vector float, vector float);
+
+     int vec_all_nlt (vector float, vector float);
+
+     int vec_all_numeric (vector float);
+
+     int vec_any_eq (vector signed char, vector bool char);
+     int vec_any_eq (vector signed char, vector signed char);
+     int vec_any_eq (vector unsigned char, vector bool char);
+     int vec_any_eq (vector unsigned char, vector unsigned char);
+     int vec_any_eq (vector bool char, vector bool char);
+     int vec_any_eq (vector bool char, vector unsigned char);
+     int vec_any_eq (vector bool char, vector signed char);
+     int vec_any_eq (vector signed short, vector bool short);
+     int vec_any_eq (vector signed short, vector signed short);
+     int vec_any_eq (vector unsigned short, vector bool short);
+     int vec_any_eq (vector unsigned short, vector unsigned short);
+     int vec_any_eq (vector bool short, vector bool short);
+     int vec_any_eq (vector bool short, vector unsigned short);
+     int vec_any_eq (vector bool short, vector signed short);
+     int vec_any_eq (vector pixel, vector pixel);
+     int vec_any_eq (vector signed int, vector bool int);
+     int vec_any_eq (vector signed int, vector signed int);
+     int vec_any_eq (vector unsigned int, vector bool int);
+     int vec_any_eq (vector unsigned int, vector unsigned int);
+     int vec_any_eq (vector bool int, vector bool int);
+     int vec_any_eq (vector bool int, vector unsigned int);
+     int vec_any_eq (vector bool int, vector signed int);
+     int vec_any_eq (vector float, vector float);
+
+     int vec_any_ge (vector signed char, vector bool char);
+     int vec_any_ge (vector unsigned char, vector bool char);
+     int vec_any_ge (vector unsigned char, vector unsigned char);
+     int vec_any_ge (vector signed char, vector signed char);
+     int vec_any_ge (vector bool char, vector unsigned char);
+     int vec_any_ge (vector bool char, vector signed char);
+     int vec_any_ge (vector unsigned short, vector bool short);
+     int vec_any_ge (vector unsigned short, vector unsigned short);
+     int vec_any_ge (vector signed short, vector signed short);
+     int vec_any_ge (vector signed short, vector bool short);
+     int vec_any_ge (vector bool short, vector unsigned short);
+     int vec_any_ge (vector bool short, vector signed short);
+     int vec_any_ge (vector signed int, vector bool int);
+     int vec_any_ge (vector unsigned int, vector bool int);
+     int vec_any_ge (vector unsigned int, vector unsigned int);
+     int vec_any_ge (vector signed int, vector signed int);
+     int vec_any_ge (vector bool int, vector unsigned int);
+     int vec_any_ge (vector bool int, vector signed int);
+     int vec_any_ge (vector float, vector float);
+
+     int vec_any_gt (vector bool char, vector unsigned char);
+     int vec_any_gt (vector unsigned char, vector bool char);
+     int vec_any_gt (vector unsigned char, vector unsigned char);
+     int vec_any_gt (vector bool char, vector signed char);
+     int vec_any_gt (vector signed char, vector bool char);
+     int vec_any_gt (vector signed char, vector signed char);
+     int vec_any_gt (vector bool short, vector unsigned short);
+     int vec_any_gt (vector unsigned short, vector bool short);
+     int vec_any_gt (vector unsigned short, vector unsigned short);
+     int vec_any_gt (vector bool short, vector signed short);
+     int vec_any_gt (vector signed short, vector bool short);
+     int vec_any_gt (vector signed short, vector signed short);
+     int vec_any_gt (vector bool int, vector unsigned int);
+     int vec_any_gt (vector unsigned int, vector bool int);
+     int vec_any_gt (vector unsigned int, vector unsigned int);
+     int vec_any_gt (vector bool int, vector signed int);
+     int vec_any_gt (vector signed int, vector bool int);
+     int vec_any_gt (vector signed int, vector signed int);
+     int vec_any_gt (vector float, vector float);
+
+     int vec_any_le (vector bool char, vector unsigned char);
+     int vec_any_le (vector unsigned char, vector bool char);
+     int vec_any_le (vector unsigned char, vector unsigned char);
+     int vec_any_le (vector bool char, vector signed char);
+     int vec_any_le (vector signed char, vector bool char);
+     int vec_any_le (vector signed char, vector signed char);
+     int vec_any_le (vector bool short, vector unsigned short);
+     int vec_any_le (vector unsigned short, vector bool short);
+     int vec_any_le (vector unsigned short, vector unsigned short);
+     int vec_any_le (vector bool short, vector signed short);
+     int vec_any_le (vector signed short, vector bool short);
+     int vec_any_le (vector signed short, vector signed short);
+     int vec_any_le (vector bool int, vector unsigned int);
+     int vec_any_le (vector unsigned int, vector bool int);
+     int vec_any_le (vector unsigned int, vector unsigned int);
+     int vec_any_le (vector bool int, vector signed int);
+     int vec_any_le (vector signed int, vector bool int);
+     int vec_any_le (vector signed int, vector signed int);
+     int vec_any_le (vector float, vector float);
+
+     int vec_any_lt (vector bool char, vector unsigned char);
+     int vec_any_lt (vector unsigned char, vector bool char);
+     int vec_any_lt (vector unsigned char, vector unsigned char);
+     int vec_any_lt (vector bool char, vector signed char);
+     int vec_any_lt (vector signed char, vector bool char);
+     int vec_any_lt (vector signed char, vector signed char);
+     int vec_any_lt (vector bool short, vector unsigned short);
+     int vec_any_lt (vector unsigned short, vector bool short);
+     int vec_any_lt (vector unsigned short, vector unsigned short);
+     int vec_any_lt (vector bool short, vector signed short);
+     int vec_any_lt (vector signed short, vector bool short);
+     int vec_any_lt (vector signed short, vector signed short);
+     int vec_any_lt (vector bool int, vector unsigned int);
+     int vec_any_lt (vector unsigned int, vector bool int);
+     int vec_any_lt (vector unsigned int, vector unsigned int);
+     int vec_any_lt (vector bool int, vector signed int);
+     int vec_any_lt (vector signed int, vector bool int);
+     int vec_any_lt (vector signed int, vector signed int);
+     int vec_any_lt (vector float, vector float);
+
+     int vec_any_nan (vector float);
+
+     int vec_any_ne (vector signed char, vector bool char);
+     int vec_any_ne (vector signed char, vector signed char);
+     int vec_any_ne (vector unsigned char, vector bool char);
+     int vec_any_ne (vector unsigned char, vector unsigned char);
+     int vec_any_ne (vector bool char, vector bool char);
+     int vec_any_ne (vector bool char, vector unsigned char);
+     int vec_any_ne (vector bool char, vector signed char);
+     int vec_any_ne (vector signed short, vector bool short);
+     int vec_any_ne (vector signed short, vector signed short);
+     int vec_any_ne (vector unsigned short, vector bool short);
+     int vec_any_ne (vector unsigned short, vector unsigned short);
+     int vec_any_ne (vector bool short, vector bool short);
+     int vec_any_ne (vector bool short, vector unsigned short);
+     int vec_any_ne (vector bool short, vector signed short);
+     int vec_any_ne (vector pixel, vector pixel);
+     int vec_any_ne (vector signed int, vector bool int);
+     int vec_any_ne (vector signed int, vector signed int);
+     int vec_any_ne (vector unsigned int, vector bool int);
+     int vec_any_ne (vector unsigned int, vector unsigned int);
+     int vec_any_ne (vector bool int, vector bool int);
+     int vec_any_ne (vector bool int, vector unsigned int);
+     int vec_any_ne (vector bool int, vector signed int);
+     int vec_any_ne (vector float, vector float);
+
+     int vec_any_nge (vector float, vector float);
+
+     int vec_any_ngt (vector float, vector float);
+
+     int vec_any_nle (vector float, vector float);
+
+     int vec_any_nlt (vector float, vector float);
+
+     int vec_any_numeric (vector float);
+
+     int vec_any_out (vector float, vector float);
+
+ If the vector/scalar (VSX) instruction set is available, the following
+additional functions are available:
+
+     vector double vec_abs (vector double);
+     vector double vec_add (vector double, vector double);
+     vector double vec_and (vector double, vector double);
+     vector double vec_and (vector double, vector bool long);
+     vector double vec_and (vector bool long, vector double);
+     vector double vec_andc (vector double, vector double);
+     vector double vec_andc (vector double, vector bool long);
+     vector double vec_andc (vector bool long, vector double);
+     vector double vec_ceil (vector double);
+     vector bool long vec_cmpeq (vector double, vector double);
+     vector bool long vec_cmpge (vector double, vector double);
+     vector bool long vec_cmpgt (vector double, vector double);
+     vector bool long vec_cmple (vector double, vector double);
+     vector bool long vec_cmplt (vector double, vector double);
+     vector float vec_div (vector float, vector float);
+     vector double vec_div (vector double, vector double);
+     vector double vec_floor (vector double);
+     vector double vec_ld (int, const vector double *);
+     vector double vec_ld (int, const double *);
+     vector double vec_ldl (int, const vector double *);
+     vector double vec_ldl (int, const double *);
+     vector unsigned char vec_lvsl (int, const volatile double *);
+     vector unsigned char vec_lvsr (int, const volatile double *);
+     vector double vec_madd (vector double, vector double, vector double);
+     vector double vec_max (vector double, vector double);
+     vector double vec_min (vector double, vector double);
+     vector float vec_msub (vector float, vector float, vector float);
+     vector double vec_msub (vector double, vector double, vector double);
+     vector float vec_mul (vector float, vector float);
+     vector double vec_mul (vector double, vector double);
+     vector float vec_nearbyint (vector float);
+     vector double vec_nearbyint (vector double);
+     vector float vec_nmadd (vector float, vector float, vector float);
+     vector double vec_nmadd (vector double, vector double, vector double);
+     vector double vec_nmsub (vector double, vector double, vector double);
+     vector double vec_nor (vector double, vector double);
+     vector double vec_or (vector double, vector double);
+     vector double vec_or (vector double, vector bool long);
+     vector double vec_or (vector bool long, vector double);
+     vector double vec_perm (vector double,
+                             vector double,
+                             vector unsigned char);
+     vector double vec_rint (vector double);
+     vector double vec_recip (vector double, vector double);
+     vector double vec_rsqrt (vector double);
+     vector double vec_rsqrte (vector double);
+     vector double vec_sel (vector double, vector double, vector bool long);
+     vector double vec_sel (vector double, vector double, vector unsigned long);
+     vector double vec_sub (vector double, vector double);
+     vector float vec_sqrt (vector float);
+     vector double vec_sqrt (vector double);
+     void vec_st (vector double, int, vector double *);
+     void vec_st (vector double, int, double *);
+     vector double vec_trunc (vector double);
+     vector double vec_xor (vector double, vector double);
+     vector double vec_xor (vector double, vector bool long);
+     vector double vec_xor (vector bool long, vector double);
+     int vec_all_eq (vector double, vector double);
+     int vec_all_ge (vector double, vector double);
+     int vec_all_gt (vector double, vector double);
+     int vec_all_le (vector double, vector double);
+     int vec_all_lt (vector double, vector double);
+     int vec_all_nan (vector double);
+     int vec_all_ne (vector double, vector double);
+     int vec_all_nge (vector double, vector double);
+     int vec_all_ngt (vector double, vector double);
+     int vec_all_nle (vector double, vector double);
+     int vec_all_nlt (vector double, vector double);
+     int vec_all_numeric (vector double);
+     int vec_any_eq (vector double, vector double);
+     int vec_any_ge (vector double, vector double);
+     int vec_any_gt (vector double, vector double);
+     int vec_any_le (vector double, vector double);
+     int vec_any_lt (vector double, vector double);
+     int vec_any_nan (vector double);
+     int vec_any_ne (vector double, vector double);
+     int vec_any_nge (vector double, vector double);
+     int vec_any_ngt (vector double, vector double);
+     int vec_any_nle (vector double, vector double);
+     int vec_any_nlt (vector double, vector double);
+     int vec_any_numeric (vector double);
+
+     vector double vec_vsx_ld (int, const vector double *);
+     vector double vec_vsx_ld (int, const double *);
+     vector float vec_vsx_ld (int, const vector float *);
+     vector float vec_vsx_ld (int, const float *);
+     vector bool int vec_vsx_ld (int, const vector bool int *);
+     vector signed int vec_vsx_ld (int, const vector signed int *);
+     vector signed int vec_vsx_ld (int, const int *);
+     vector signed int vec_vsx_ld (int, const long *);
+     vector unsigned int vec_vsx_ld (int, const vector unsigned int *);
+     vector unsigned int vec_vsx_ld (int, const unsigned int *);
+     vector unsigned int vec_vsx_ld (int, const unsigned long *);
+     vector bool short vec_vsx_ld (int, const vector bool short *);
+     vector pixel vec_vsx_ld (int, const vector pixel *);
+     vector signed short vec_vsx_ld (int, const vector signed short *);
+     vector signed short vec_vsx_ld (int, const short *);
+     vector unsigned short vec_vsx_ld (int, const vector unsigned short *);
+     vector unsigned short vec_vsx_ld (int, const unsigned short *);
+     vector bool char vec_vsx_ld (int, const vector bool char *);
+     vector signed char vec_vsx_ld (int, const vector signed char *);
+     vector signed char vec_vsx_ld (int, const signed char *);
+     vector unsigned char vec_vsx_ld (int, const vector unsigned char *);
+     vector unsigned char vec_vsx_ld (int, const unsigned char *);
+
+     void vec_vsx_st (vector double, int, vector double *);
+     void vec_vsx_st (vector double, int, double *);
+     void vec_vsx_st (vector float, int, vector float *);
+     void vec_vsx_st (vector float, int, float *);
+     void vec_vsx_st (vector signed int, int, vector signed int *);
+     void vec_vsx_st (vector signed int, int, int *);
+     void vec_vsx_st (vector unsigned int, int, vector unsigned int *);
+     void vec_vsx_st (vector unsigned int, int, unsigned int *);
+     void vec_vsx_st (vector bool int, int, vector bool int *);
+     void vec_vsx_st (vector bool int, int, unsigned int *);
+     void vec_vsx_st (vector bool int, int, int *);
+     void vec_vsx_st (vector signed short, int, vector signed short *);
+     void vec_vsx_st (vector signed short, int, short *);
+     void vec_vsx_st (vector unsigned short, int, vector unsigned short *);
+     void vec_vsx_st (vector unsigned short, int, unsigned short *);
+     void vec_vsx_st (vector bool short, int, vector bool short *);
+     void vec_vsx_st (vector bool short, int, unsigned short *);
+     void vec_vsx_st (vector pixel, int, vector pixel *);
+     void vec_vsx_st (vector pixel, int, unsigned short *);
+     void vec_vsx_st (vector pixel, int, short *);
+     void vec_vsx_st (vector bool short, int, short *);
+     void vec_vsx_st (vector signed char, int, vector signed char *);
+     void vec_vsx_st (vector signed char, int, signed char *);
+     void vec_vsx_st (vector unsigned char, int, vector unsigned char *);
+     void vec_vsx_st (vector unsigned char, int, unsigned char *);
+     void vec_vsx_st (vector bool char, int, vector bool char *);
+     void vec_vsx_st (vector bool char, int, unsigned char *);
+     void vec_vsx_st (vector bool char, int, signed char *);
+
+     vector double vec_xxpermdi (vector double, vector double, int);
+     vector float vec_xxpermdi (vector float, vector float, int);
+     vector long long vec_xxpermdi (vector long long, vector long long, int);
+     vector unsigned long long vec_xxpermdi (vector unsigned long long,
+                                             vector unsigned long long, int);
+     vector int vec_xxpermdi (vector int, vector int, int);
+     vector unsigned int vec_xxpermdi (vector unsigned int,
+                                       vector unsigned int, int);
+     vector short vec_xxpermdi (vector short, vector short, int);
+     vector unsigned short vec_xxpermdi (vector unsigned short,
+                                         vector unsigned short, int);
+     vector signed char vec_xxpermdi (vector signed char, vector signed char, int);
+     vector unsigned char vec_xxpermdi (vector unsigned char,
+                                        vector unsigned char, int);
+
+     vector double vec_xxsldi (vector double, vector double, int);
+     vector float vec_xxsldi (vector float, vector float, int);
+     vector long long vec_xxsldi (vector long long, vector long long, int);
+     vector unsigned long long vec_xxsldi (vector unsigned long long,
+                                           vector unsigned long long, int);
+     vector int vec_xxsldi (vector int, vector int, int);
+     vector unsigned int vec_xxsldi (vector unsigned int, vector unsigned int, int);
+     vector short vec_xxsldi (vector short, vector short, int);
+     vector unsigned short vec_xxsldi (vector unsigned short,
+                                       vector unsigned short, int);
+     vector signed char vec_xxsldi (vector signed char, vector signed char, int);
+     vector unsigned char vec_xxsldi (vector unsigned char,
+                                      vector unsigned char, int);
+
+ Note that the 'vec_ld' and 'vec_st' built-in functions always generate
+the AltiVec 'LVX' and 'STVX' instructions even if the VSX instruction
+set is available.  The 'vec_vsx_ld' and 'vec_vsx_st' built-in functions
+always generate the VSX 'LXVD2X', 'LXVW4X', 'STXVD2X', and 'STXVW4X'
+instructions.
+
+ If the ISA 2.07 additions to the vector/scalar (power8-vector)
+instruction set is available, the following additional functions are
+available for both 32-bit and 64-bit targets.  For 64-bit targets, you
+can use VECTOR LONG instead of VECTOR LONG LONG, VECTOR BOOL LONG
+instead of VECTOR BOOL LONG LONG, and VECTOR UNSIGNED LONG instead of
+VECTOR UNSIGNED LONG LONG.
+
+     vector long long vec_abs (vector long long);
+
+     vector long long vec_add (vector long long, vector long long);
+     vector unsigned long long vec_add (vector unsigned long long,
+                                        vector unsigned long long);
+
+     int vec_all_eq (vector long long, vector long long);
+     int vec_all_ge (vector long long, vector long long);
+     int vec_all_gt (vector long long, vector long long);
+     int vec_all_le (vector long long, vector long long);
+     int vec_all_lt (vector long long, vector long long);
+     int vec_all_ne (vector long long, vector long long);
+     int vec_any_eq (vector long long, vector long long);
+     int vec_any_ge (vector long long, vector long long);
+     int vec_any_gt (vector long long, vector long long);
+     int vec_any_le (vector long long, vector long long);
+     int vec_any_lt (vector long long, vector long long);
+     int vec_any_ne (vector long long, vector long long);
+
+     vector long long vec_eqv (vector long long, vector long long);
+     vector long long vec_eqv (vector bool long long, vector long long);
+     vector long long vec_eqv (vector long long, vector bool long long);
+     vector unsigned long long vec_eqv (vector unsigned long long,
+                                        vector unsigned long long);
+     vector unsigned long long vec_eqv (vector bool long long,
+                                        vector unsigned long long);
+     vector unsigned long long vec_eqv (vector unsigned long long,
+                                        vector bool long long);
+     vector int vec_eqv (vector int, vector int);
+     vector int vec_eqv (vector bool int, vector int);
+     vector int vec_eqv (vector int, vector bool int);
+     vector unsigned int vec_eqv (vector unsigned int, vector unsigned int);
+     vector unsigned int vec_eqv (vector bool unsigned int,
+                                  vector unsigned int);
+     vector unsigned int vec_eqv (vector unsigned int,
+                                  vector bool unsigned int);
+     vector short vec_eqv (vector short, vector short);
+     vector short vec_eqv (vector bool short, vector short);
+     vector short vec_eqv (vector short, vector bool short);
+     vector unsigned short vec_eqv (vector unsigned short, vector unsigned short);
+     vector unsigned short vec_eqv (vector bool unsigned short,
+                                    vector unsigned short);
+     vector unsigned short vec_eqv (vector unsigned short,
+                                    vector bool unsigned short);
+     vector signed char vec_eqv (vector signed char, vector signed char);
+     vector signed char vec_eqv (vector bool signed char, vector signed char);
+     vector signed char vec_eqv (vector signed char, vector bool signed char);
+     vector unsigned char vec_eqv (vector unsigned char, vector unsigned char);
+     vector unsigned char vec_eqv (vector bool unsigned char, vector unsigned char);
+     vector unsigned char vec_eqv (vector unsigned char, vector bool unsigned char);
+
+     vector long long vec_max (vector long long, vector long long);
+     vector unsigned long long vec_max (vector unsigned long long,
+                                        vector unsigned long long);
+
+     vector long long vec_min (vector long long, vector long long);
+     vector unsigned long long vec_min (vector unsigned long long,
+                                        vector unsigned long long);
+
+     vector long long vec_nand (vector long long, vector long long);
+     vector long long vec_nand (vector bool long long, vector long long);
+     vector long long vec_nand (vector long long, vector bool long long);
+     vector unsigned long long vec_nand (vector unsigned long long,
+                                         vector unsigned long long);
+     vector unsigned long long vec_nand (vector bool long long,
+                                        vector unsigned long long);
+     vector unsigned long long vec_nand (vector unsigned long long,
+                                         vector bool long long);
+     vector int vec_nand (vector int, vector int);
+     vector int vec_nand (vector bool int, vector int);
+     vector int vec_nand (vector int, vector bool int);
+     vector unsigned int vec_nand (vector unsigned int, vector unsigned int);
+     vector unsigned int vec_nand (vector bool unsigned int,
+                                   vector unsigned int);
+     vector unsigned int vec_nand (vector unsigned int,
+                                   vector bool unsigned int);
+     vector short vec_nand (vector short, vector short);
+     vector short vec_nand (vector bool short, vector short);
+     vector short vec_nand (vector short, vector bool short);
+     vector unsigned short vec_nand (vector unsigned short, vector unsigned short);
+     vector unsigned short vec_nand (vector bool unsigned short,
+                                     vector unsigned short);
+     vector unsigned short vec_nand (vector unsigned short,
+                                     vector bool unsigned short);
+     vector signed char vec_nand (vector signed char, vector signed char);
+     vector signed char vec_nand (vector bool signed char, vector signed char);
+     vector signed char vec_nand (vector signed char, vector bool signed char);
+     vector unsigned char vec_nand (vector unsigned char, vector unsigned char);
+     vector unsigned char vec_nand (vector bool unsigned char, vector unsigned char);
+     vector unsigned char vec_nand (vector unsigned char, vector bool unsigned char);
+
+     vector long long vec_orc (vector long long, vector long long);
+     vector long long vec_orc (vector bool long long, vector long long);
+     vector long long vec_orc (vector long long, vector bool long long);
+     vector unsigned long long vec_orc (vector unsigned long long,
+                                        vector unsigned long long);
+     vector unsigned long long vec_orc (vector bool long long,
+                                        vector unsigned long long);
+     vector unsigned long long vec_orc (vector unsigned long long,
+                                        vector bool long long);
+     vector int vec_orc (vector int, vector int);
+     vector int vec_orc (vector bool int, vector int);
+     vector int vec_orc (vector int, vector bool int);
+     vector unsigned int vec_orc (vector unsigned int, vector unsigned int);
+     vector unsigned int vec_orc (vector bool unsigned int,
+                                  vector unsigned int);
+     vector unsigned int vec_orc (vector unsigned int,
+                                  vector bool unsigned int);
+     vector short vec_orc (vector short, vector short);
+     vector short vec_orc (vector bool short, vector short);
+     vector short vec_orc (vector short, vector bool short);
+     vector unsigned short vec_orc (vector unsigned short, vector unsigned short);
+     vector unsigned short vec_orc (vector bool unsigned short,
+                                    vector unsigned short);
+     vector unsigned short vec_orc (vector unsigned short,
+                                    vector bool unsigned short);
+     vector signed char vec_orc (vector signed char, vector signed char);
+     vector signed char vec_orc (vector bool signed char, vector signed char);
+     vector signed char vec_orc (vector signed char, vector bool signed char);
+     vector unsigned char vec_orc (vector unsigned char, vector unsigned char);
+     vector unsigned char vec_orc (vector bool unsigned char, vector unsigned char);
+     vector unsigned char vec_orc (vector unsigned char, vector bool unsigned char);
+
+     vector int vec_pack (vector long long, vector long long);
+     vector unsigned int vec_pack (vector unsigned long long,
+                                   vector unsigned long long);
+     vector bool int vec_pack (vector bool long long, vector bool long long);
+
+     vector int vec_packs (vector long long, vector long long);
+     vector unsigned int vec_packs (vector unsigned long long,
+                                    vector unsigned long long);
+
+     vector unsigned int vec_packsu (vector long long, vector long long);
+
+     vector long long vec_rl (vector long long,
+                              vector unsigned long long);
+     vector long long vec_rl (vector unsigned long long,
+                              vector unsigned long long);
+
+     vector long long vec_sl (vector long long, vector unsigned long long);
+     vector long long vec_sl (vector unsigned long long,
+                              vector unsigned long long);
+
+     vector long long vec_sr (vector long long, vector unsigned long long);
+     vector unsigned long long char vec_sr (vector unsigned long long,
+                                            vector unsigned long long);
+
+     vector long long vec_sra (vector long long, vector unsigned long long);
+     vector unsigned long long vec_sra (vector unsigned long long,
+                                        vector unsigned long long);
+
+     vector long long vec_sub (vector long long, vector long long);
+     vector unsigned long long vec_sub (vector unsigned long long,
+                                        vector unsigned long long);
+
+     vector long long vec_unpackh (vector int);
+     vector unsigned long long vec_unpackh (vector unsigned int);
+
+     vector long long vec_unpackl (vector int);
+     vector unsigned long long vec_unpackl (vector unsigned int);
+
+     vector long long vec_vaddudm (vector long long, vector long long);
+     vector long long vec_vaddudm (vector bool long long, vector long long);
+     vector long long vec_vaddudm (vector long long, vector bool long long);
+     vector unsigned long long vec_vaddudm (vector unsigned long long,
+                                            vector unsigned long long);
+     vector unsigned long long vec_vaddudm (vector bool unsigned long long,
+                                            vector unsigned long long);
+     vector unsigned long long vec_vaddudm (vector unsigned long long,
+                                            vector bool unsigned long long);
+
+     vector long long vec_vbpermq (vector signed char, vector signed char);
+     vector long long vec_vbpermq (vector unsigned char, vector unsigned char);
+
+     vector long long vec_vclz (vector long long);
+     vector unsigned long long vec_vclz (vector unsigned long long);
+     vector int vec_vclz (vector int);
+     vector unsigned int vec_vclz (vector int);
+     vector short vec_vclz (vector short);
+     vector unsigned short vec_vclz (vector unsigned short);
+     vector signed char vec_vclz (vector signed char);
+     vector unsigned char vec_vclz (vector unsigned char);
+
+     vector signed char vec_vclzb (vector signed char);
+     vector unsigned char vec_vclzb (vector unsigned char);
+
+     vector long long vec_vclzd (vector long long);
+     vector unsigned long long vec_vclzd (vector unsigned long long);
+
+     vector short vec_vclzh (vector short);
+     vector unsigned short vec_vclzh (vector unsigned short);
+
+     vector int vec_vclzw (vector int);
+     vector unsigned int vec_vclzw (vector int);
+
+     vector signed char vec_vgbbd (vector signed char);
+     vector unsigned char vec_vgbbd (vector unsigned char);
+
+     vector long long vec_vmaxsd (vector long long, vector long long);
+
+     vector unsigned long long vec_vmaxud (vector unsigned long long,
+                                           unsigned vector long long);
+
+     vector long long vec_vminsd (vector long long, vector long long);
+
+     vector unsigned long long vec_vminud (vector long long,
+                                           vector long long);
+
+     vector int vec_vpksdss (vector long long, vector long long);
+     vector unsigned int vec_vpksdss (vector long long, vector long long);
+
+     vector unsigned int vec_vpkudus (vector unsigned long long,
+                                      vector unsigned long long);
+
+     vector int vec_vpkudum (vector long long, vector long long);
+     vector unsigned int vec_vpkudum (vector unsigned long long,
+                                      vector unsigned long long);
+     vector bool int vec_vpkudum (vector bool long long, vector bool long long);
+
+     vector long long vec_vpopcnt (vector long long);
+     vector unsigned long long vec_vpopcnt (vector unsigned long long);
+     vector int vec_vpopcnt (vector int);
+     vector unsigned int vec_vpopcnt (vector int);
+     vector short vec_vpopcnt (vector short);
+     vector unsigned short vec_vpopcnt (vector unsigned short);
+     vector signed char vec_vpopcnt (vector signed char);
+     vector unsigned char vec_vpopcnt (vector unsigned char);
+
+     vector signed char vec_vpopcntb (vector signed char);
+     vector unsigned char vec_vpopcntb (vector unsigned char);
+
+     vector long long vec_vpopcntd (vector long long);
+     vector unsigned long long vec_vpopcntd (vector unsigned long long);
+
+     vector short vec_vpopcnth (vector short);
+     vector unsigned short vec_vpopcnth (vector unsigned short);
+
+     vector int vec_vpopcntw (vector int);
+     vector unsigned int vec_vpopcntw (vector int);
+
+     vector long long vec_vrld (vector long long, vector unsigned long long);
+     vector unsigned long long vec_vrld (vector unsigned long long,
+                                         vector unsigned long long);
+
+     vector long long vec_vsld (vector long long, vector unsigned long long);
+     vector long long vec_vsld (vector unsigned long long,
+                                vector unsigned long long);
+
+     vector long long vec_vsrad (vector long long, vector unsigned long long);
+     vector unsigned long long vec_vsrad (vector unsigned long long,
+                                          vector unsigned long long);
+
+     vector long long vec_vsrd (vector long long, vector unsigned long long);
+     vector unsigned long long char vec_vsrd (vector unsigned long long,
+                                              vector unsigned long long);
+
+     vector long long vec_vsubudm (vector long long, vector long long);
+     vector long long vec_vsubudm (vector bool long long, vector long long);
+     vector long long vec_vsubudm (vector long long, vector bool long long);
+     vector unsigned long long vec_vsubudm (vector unsigned long long,
+                                            vector unsigned long long);
+     vector unsigned long long vec_vsubudm (vector bool long long,
+                                            vector unsigned long long);
+     vector unsigned long long vec_vsubudm (vector unsigned long long,
+                                            vector bool long long);
+
+     vector long long vec_vupkhsw (vector int);
+     vector unsigned long long vec_vupkhsw (vector unsigned int);
+
+     vector long long vec_vupklsw (vector int);
+     vector unsigned long long vec_vupklsw (vector int);
+
+ If the ISA 2.07 additions to the vector/scalar (power8-vector)
+instruction set is available, the following additional functions are
+available for 64-bit targets.  New vector types (VECTOR __INT128_T and
+VECTOR __UINT128_T) are available to hold the __INT128_T and __UINT128_T
+types to use these builtins.
+
+ The normal vector extract, and set operations work on VECTOR __INT128_T
+and VECTOR __UINT128_T types, but the index value must be 0.
+
+     vector __int128_t vec_vaddcuq (vector __int128_t, vector __int128_t);
+     vector __uint128_t vec_vaddcuq (vector __uint128_t, vector __uint128_t);
+
+     vector __int128_t vec_vadduqm (vector __int128_t, vector __int128_t);
+     vector __uint128_t vec_vadduqm (vector __uint128_t, vector __uint128_t);
+
+     vector __int128_t vec_vaddecuq (vector __int128_t, vector __int128_t,
+                                     vector __int128_t);
+     vector __uint128_t vec_vaddecuq (vector __uint128_t, vector __uint128_t,
+                                      vector __uint128_t);
+
+     vector __int128_t vec_vaddeuqm (vector __int128_t, vector __int128_t,
+                                     vector __int128_t);
+     vector __uint128_t vec_vaddeuqm (vector __uint128_t, vector __uint128_t,
+                                      vector __uint128_t);
+
+     vector __int128_t vec_vsubecuq (vector __int128_t, vector __int128_t,
+                                     vector __int128_t);
+     vector __uint128_t vec_vsubecuq (vector __uint128_t, vector __uint128_t,
+                                      vector __uint128_t);
+
+     vector __int128_t vec_vsubeuqm (vector __int128_t, vector __int128_t,
+                                     vector __int128_t);
+     vector __uint128_t vec_vsubeuqm (vector __uint128_t, vector __uint128_t,
+                                      vector __uint128_t);
+
+     vector __int128_t vec_vsubcuq (vector __int128_t, vector __int128_t);
+     vector __uint128_t vec_vsubcuq (vector __uint128_t, vector __uint128_t);
+
+     __int128_t vec_vsubuqm (__int128_t, __int128_t);
+     __uint128_t vec_vsubuqm (__uint128_t, __uint128_t);
+
+ If the cryptographic instructions are enabled ('-mcrypto' or
+'-mcpu=power8'), the following builtins are enabled.
+
+     vector unsigned long long __builtin_crypto_vsbox (vector unsigned long long);
+
+     vector unsigned long long __builtin_crypto_vcipher (vector unsigned long long,
+                                                         vector unsigned long long);
+
+     vector unsigned long long __builtin_crypto_vcipherlast
+                                          (vector unsigned long long,
+                                           vector unsigned long long);
+
+     vector unsigned long long __builtin_crypto_vncipher (vector unsigned long long,
+                                                          vector unsigned long long);
+
+     vector unsigned long long __builtin_crypto_vncipherlast
+                                          (vector unsigned long long,
+                                           vector unsigned long long);
+
+     vector unsigned char __builtin_crypto_vpermxor (vector unsigned char,
+                                                     vector unsigned char,
+                                                     vector unsigned char);
+
+     vector unsigned short __builtin_crypto_vpermxor (vector unsigned short,
+                                                      vector unsigned short,
+                                                      vector unsigned short);
+
+     vector unsigned int __builtin_crypto_vpermxor (vector unsigned int,
+                                                    vector unsigned int,
+                                                    vector unsigned int);
+
+     vector unsigned long long __builtin_crypto_vpermxor (vector unsigned long long,
+                                                          vector unsigned long long,
+                                                          vector unsigned long long);
+
+     vector unsigned char __builtin_crypto_vpmsumb (vector unsigned char,
+                                                    vector unsigned char);
+
+     vector unsigned short __builtin_crypto_vpmsumb (vector unsigned short,
+                                                     vector unsigned short);
+
+     vector unsigned int __builtin_crypto_vpmsumb (vector unsigned int,
+                                                   vector unsigned int);
+
+     vector unsigned long long __builtin_crypto_vpmsumb (vector unsigned long long,
+                                                         vector unsigned long long);
+
+     vector unsigned long long __builtin_crypto_vshasigmad
+                                    (vector unsigned long long, int, int);
+
+     vector unsigned int __builtin_crypto_vshasigmaw (vector unsigned int,
+                                                      int, int);
+
+ The second argument to the __BUILTIN_CRYPTO_VSHASIGMAD and
+__BUILTIN_CRYPTO_VSHASIGMAW builtin functions must be a constant integer
+that is 0 or 1.  The third argument to these builtin functions must be a
+constant integer in the range of 0 to 15.
+
+
+File: gcc.info,  Node: PowerPC Hardware Transactional Memory Built-in Functions,  Next: RX Built-in Functions,  Prev: PowerPC AltiVec/VSX Built-in Functions,  Up: Target Builtins
+
+6.57.22 PowerPC Hardware Transactional Memory Built-in Functions
+----------------------------------------------------------------
+
+GCC provides two interfaces for accessing the Hardware Transactional
+Memory (HTM) instructions available on some of the PowerPC family of
+prcoessors (eg, POWER8).  The two interfaces come in a low level
+interface, consisting of built-in functions specific to PowerPC and a
+higher level interface consisting of inline functions that are common
+between PowerPC and S/390.
+
+6.57.22.1 PowerPC HTM Low Level Built-in Functions
+..................................................
+
+The following low level built-in functions are available with '-mhtm' or
+'-mcpu=CPU' where CPU is 'power8' or later.  They all generate the
+machine instruction that is part of the name.
+
+ The HTM built-ins return true or false depending on their success and
+their arguments match exactly the type and order of the associated
+hardware instruction's operands.  Refer to the ISA manual for a
+description of each instruction's operands.
+
+     unsigned int __builtin_tbegin (unsigned int)
+     unsigned int __builtin_tend (unsigned int)
+
+     unsigned int __builtin_tabort (unsigned int)
+     unsigned int __builtin_tabortdc (unsigned int, unsigned int, unsigned int)
+     unsigned int __builtin_tabortdci (unsigned int, unsigned int, int)
+     unsigned int __builtin_tabortwc (unsigned int, unsigned int, unsigned int)
+     unsigned int __builtin_tabortwci (unsigned int, unsigned int, int)
+
+     unsigned int __builtin_tcheck (unsigned int)
+     unsigned int __builtin_treclaim (unsigned int)
+     unsigned int __builtin_trechkpt (void)
+     unsigned int __builtin_tsr (unsigned int)
+
+ In addition to the above HTM built-ins, we have added built-ins for
+some common extended mnemonics of the HTM instructions:
+
+     unsigned int __builtin_tendall (void)
+     unsigned int __builtin_tresume (void)
+     unsigned int __builtin_tsuspend (void)
+
+ The following set of built-in functions are available to gain access to
+the HTM specific special purpose registers.
+
+     unsigned long __builtin_get_texasr (void)
+     unsigned long __builtin_get_texasru (void)
+     unsigned long __builtin_get_tfhar (void)
+     unsigned long __builtin_get_tfiar (void)
+
+     void __builtin_set_texasr (unsigned long);
+     void __builtin_set_texasru (unsigned long);
+     void __builtin_set_tfhar (unsigned long);
+     void __builtin_set_tfiar (unsigned long);
+
+ Example usage of these low level built-in functions may look like:
+
+     #include <htmintrin.h>
+
+     int num_retries = 10;
+
+     while (1)
+       {
+         if (__builtin_tbegin (0))
+           {
+             /* Transaction State Initiated.  */
+             if (is_locked (lock))
+               __builtin_tabort (0);
+             ... transaction code...
+             __builtin_tend (0);
+             break;
+           }
+         else
+           {
+             /* Transaction State Failed.  Use locks if the transaction
+                failure is "persistent" or we've tried too many times.  */
+             if (num_retries-- <= 0
+                 || _TEXASRU_FAILURE_PERSISTENT (__builtin_get_texasru ()))
+               {
+                 acquire_lock (lock);
+                 ... non transactional fallback path...
+                 release_lock (lock);
+                 break;
+               }
+           }
+       }
+
+ One final built-in function has been added that returns the value of
+the 2-bit Transaction State field of the Machine Status Register (MSR)
+as stored in 'CR0'.
+
+     unsigned long __builtin_ttest (void)
+
+ This built-in can be used to determine the current transaction state
+using the following code example:
+
+     #include <htmintrin.h>
+
+     unsigned char tx_state = _HTM_STATE (__builtin_ttest ());
+
+     if (tx_state == _HTM_TRANSACTIONAL)
+       {
+         /* Code to use in transactional state.  */
+       }
+     else if (tx_state == _HTM_NONTRANSACTIONAL)
+       {
+         /* Code to use in non-transactional state.  */
+       }
+     else if (tx_state == _HTM_SUSPENDED)
+       {
+         /* Code to use in transaction suspended state.  */
+       }
+
+6.57.22.2 PowerPC HTM High Level Inline Functions
+.................................................
+
+The following high level HTM interface is made available by including
+'<htmxlintrin.h>' and using '-mhtm' or '-mcpu=CPU' where CPU is 'power8'
+or later.  This interface is common between PowerPC and S/390, allowing
+users to write one HTM source implementation that can be compiled and
+executed on either system.
+
+     long __TM_simple_begin (void)
+     long __TM_begin (void* const TM_buff)
+     long __TM_end (void)
+     void __TM_abort (void)
+     void __TM_named_abort (unsigned char const code)
+     void __TM_resume (void)
+     void __TM_suspend (void)
+
+     long __TM_is_user_abort (void* const TM_buff)
+     long __TM_is_named_user_abort (void* const TM_buff, unsigned char *code)
+     long __TM_is_illegal (void* const TM_buff)
+     long __TM_is_footprint_exceeded (void* const TM_buff)
+     long __TM_nesting_depth (void* const TM_buff)
+     long __TM_is_nested_too_deep(void* const TM_buff)
+     long __TM_is_conflict(void* const TM_buff)
+     long __TM_is_failure_persistent(void* const TM_buff)
+     long __TM_failure_address(void* const TM_buff)
+     long long __TM_failure_code(void* const TM_buff)
+
+ Using these common set of HTM inline functions, we can create a more
+portable version of the HTM example in the previous section that will
+work on either PowerPC or S/390:
+
+     #include <htmxlintrin.h>
+
+     int num_retries = 10;
+     TM_buff_type TM_buff;
+
+     while (1)
+       {
+         if (__TM_begin (TM_buff))
+           {
+             /* Transaction State Initiated.  */
+             if (is_locked (lock))
+               __TM_abort ();
+             ... transaction code...
+             __TM_end ();
+             break;
+           }
+         else
+           {
+             /* Transaction State Failed.  Use locks if the transaction
+                failure is "persistent" or we've tried too many times.  */
+             if (num_retries-- <= 0
+                 || __TM_is_failure_persistent (TM_buff))
+               {
+                 acquire_lock (lock);
+                 ... non transactional fallback path...
+                 release_lock (lock);
+                 break;
+               }
+           }
+       }
+
+
+File: gcc.info,  Node: RX Built-in Functions,  Next: S/390 System z Built-in Functions,  Prev: PowerPC Hardware Transactional Memory Built-in Functions,  Up: Target Builtins
+
+6.57.23 RX Built-in Functions
+-----------------------------
+
+GCC supports some of the RX instructions which cannot be expressed in
+the C programming language via the use of built-in functions.  The
+following functions are supported:
+
+ -- Built-in Function: void __builtin_rx_brk (void)
+     Generates the 'brk' machine instruction.
+
+ -- Built-in Function: void __builtin_rx_clrpsw (int)
+     Generates the 'clrpsw' machine instruction to clear the specified
+     bit in the processor status word.
+
+ -- Built-in Function: void __builtin_rx_int (int)
+     Generates the 'int' machine instruction to generate an interrupt
+     with the specified value.
+
+ -- Built-in Function: void __builtin_rx_machi (int, int)
+     Generates the 'machi' machine instruction to add the result of
+     multiplying the top 16 bits of the two arguments into the
+     accumulator.
+
+ -- Built-in Function: void __builtin_rx_maclo (int, int)
+     Generates the 'maclo' machine instruction to add the result of
+     multiplying the bottom 16 bits of the two arguments into the
+     accumulator.
+
+ -- Built-in Function: void __builtin_rx_mulhi (int, int)
+     Generates the 'mulhi' machine instruction to place the result of
+     multiplying the top 16 bits of the two arguments into the
+     accumulator.
+
+ -- Built-in Function: void __builtin_rx_mullo (int, int)
+     Generates the 'mullo' machine instruction to place the result of
+     multiplying the bottom 16 bits of the two arguments into the
+     accumulator.
+
+ -- Built-in Function: int __builtin_rx_mvfachi (void)
+     Generates the 'mvfachi' machine instruction to read the top 32 bits
+     of the accumulator.
+
+ -- Built-in Function: int __builtin_rx_mvfacmi (void)
+     Generates the 'mvfacmi' machine instruction to read the middle 32
+     bits of the accumulator.
+
+ -- Built-in Function: int __builtin_rx_mvfc (int)
+     Generates the 'mvfc' machine instruction which reads the control
+     register specified in its argument and returns its value.
+
+ -- Built-in Function: void __builtin_rx_mvtachi (int)
+     Generates the 'mvtachi' machine instruction to set the top 32 bits
+     of the accumulator.
+
+ -- Built-in Function: void __builtin_rx_mvtaclo (int)
+     Generates the 'mvtaclo' machine instruction to set the bottom 32
+     bits of the accumulator.
+
+ -- Built-in Function: void __builtin_rx_mvtc (int reg, int val)
+     Generates the 'mvtc' machine instruction which sets control
+     register number 'reg' to 'val'.
+
+ -- Built-in Function: void __builtin_rx_mvtipl (int)
+     Generates the 'mvtipl' machine instruction set the interrupt
+     priority level.
+
+ -- Built-in Function: void __builtin_rx_racw (int)
+     Generates the 'racw' machine instruction to round the accumulator
+     according to the specified mode.
+
+ -- Built-in Function: int __builtin_rx_revw (int)
+     Generates the 'revw' machine instruction which swaps the bytes in
+     the argument so that bits 0-7 now occupy bits 8-15 and vice versa,
+     and also bits 16-23 occupy bits 24-31 and vice versa.
+
+ -- Built-in Function: void __builtin_rx_rmpa (void)
+     Generates the 'rmpa' machine instruction which initiates a repeated
+     multiply and accumulate sequence.
+
+ -- Built-in Function: void __builtin_rx_round (float)
+     Generates the 'round' machine instruction which returns the
+     floating-point argument rounded according to the current rounding
+     mode set in the floating-point status word register.
+
+ -- Built-in Function: int __builtin_rx_sat (int)
+     Generates the 'sat' machine instruction which returns the saturated
+     value of the argument.
+
+ -- Built-in Function: void __builtin_rx_setpsw (int)
+     Generates the 'setpsw' machine instruction to set the specified bit
+     in the processor status word.
+
+ -- Built-in Function: void __builtin_rx_wait (void)
+     Generates the 'wait' machine instruction.
+
+
+File: gcc.info,  Node: S/390 System z Built-in Functions,  Next: SH Built-in Functions,  Prev: RX Built-in Functions,  Up: Target Builtins
+
+6.57.24 S/390 System z Built-in Functions
+-----------------------------------------
+
+ -- Built-in Function: int __builtin_tbegin (void*)
+     Generates the 'tbegin' machine instruction starting a
+     non-constraint hardware transaction.  If the parameter is non-NULL
+     the memory area is used to store the transaction diagnostic buffer
+     and will be passed as first operand to 'tbegin'.  This buffer can
+     be defined using the 'struct __htm_tdb' C struct defined in
+     'htmintrin.h' and must reside on a double-word boundary.  The
+     second tbegin operand is set to '0xff0c'.  This enables
+     save/restore of all GPRs and disables aborts for FPR and AR
+     manipulations inside the transaction body.  The condition code set
+     by the tbegin instruction is returned as integer value.  The tbegin
+     instruction by definition overwrites the content of all FPRs.  The
+     compiler will generate code which saves and restores the FPRs.  For
+     soft-float code it is recommended to used the '*_nofloat' variant.
+     In order to prevent a TDB from being written it is required to pass
+     an constant zero value as parameter.  Passing the zero value
+     through a variable is not sufficient.  Although modifications of
+     access registers inside the transaction will not trigger an
+     transaction abort it is not supported to actually modify them.
+     Access registers do not get saved when entering a transaction.
+     They will have undefined state when reaching the abort code.
+
+ Macros for the possible return codes of tbegin are defined in the
+'htmintrin.h' header file:
+
+'_HTM_TBEGIN_STARTED'
+     'tbegin' has been executed as part of normal processing.  The
+     transaction body is supposed to be executed.
+'_HTM_TBEGIN_INDETERMINATE'
+     The transaction was aborted due to an indeterminate condition which
+     might be persistent.
+'_HTM_TBEGIN_TRANSIENT'
+     The transaction aborted due to a transient failure.  The
+     transaction should be re-executed in that case.
+'_HTM_TBEGIN_PERSISTENT'
+     The transaction aborted due to a persistent failure.  Re-execution
+     under same circumstances will not be productive.
+
+ -- Macro: _HTM_FIRST_USER_ABORT_CODE
+     The '_HTM_FIRST_USER_ABORT_CODE' defined in 'htmintrin.h' specifies
+     the first abort code which can be used for '__builtin_tabort'.
+     Values below this threshold are reserved for machine use.
+
+ -- Data type: struct __htm_tdb
+     The 'struct __htm_tdb' defined in 'htmintrin.h' describes the
+     structure of the transaction diagnostic block as specified in the
+     Principles of Operation manual chapter 5-91.
+
+ -- Built-in Function: int __builtin_tbegin_nofloat (void*)
+     Same as '__builtin_tbegin' but without FPR saves and restores.
+     Using this variant in code making use of FPRs will leave the FPRs
+     in undefined state when entering the transaction abort handler
+     code.
+
+ -- Built-in Function: int __builtin_tbegin_retry (void*, int)
+     In addition to '__builtin_tbegin' a loop for transient failures is
+     generated.  If tbegin returns a condition code of 2 the transaction
+     will be retried as often as specified in the second argument.  The
+     perform processor assist instruction is used to tell the CPU about
+     the number of fails so far.
+
+ -- Built-in Function: int __builtin_tbegin_retry_nofloat (void*, int)
+     Same as '__builtin_tbegin_retry' but without FPR saves and
+     restores.  Using this variant in code making use of FPRs will leave
+     the FPRs in undefined state when entering the transaction abort
+     handler code.
+
+ -- Built-in Function: void __builtin_tbeginc (void)
+     Generates the 'tbeginc' machine instruction starting a constraint
+     hardware transaction.  The second operand is set to '0xff08'.
+
+ -- Built-in Function: int __builtin_tend (void)
+     Generates the 'tend' machine instruction finishing a transaction
+     and making the changes visible to other threads.  The condition
+     code generated by tend is returned as integer value.
+
+ -- Built-in Function: void __builtin_tabort (int)
+     Generates the 'tabort' machine instruction with the specified abort
+     code.  Abort codes from 0 through 255 are reserved and will result
+     in an error message.
+
+ -- Built-in Function: void __builtin_tx_assist (int)
+     Generates the 'ppa rX,rY,1' machine instruction.  Where the integer
+     parameter is loaded into rX and a value of zero is loaded into rY.
+     The integer parameter specifies the number of times the transaction
+     repeatedly aborted.
+
+ -- Built-in Function: int __builtin_tx_nesting_depth (void)
+     Generates the 'etnd' machine instruction.  The current nesting
+     depth is returned as integer value.  For a nesting depth of 0 the
+     code is not executed as part of an transaction.
+
+ -- Built-in Function: void __builtin_non_tx_store (uint64_t *,
+          uint64_t)
+
+     Generates the 'ntstg' machine instruction.  The second argument is
+     written to the first arguments location.  The store operation will
+     not be rolled-back in case of an transaction abort.
+
+
+File: gcc.info,  Node: SH Built-in Functions,  Next: SPARC VIS Built-in Functions,  Prev: S/390 System z Built-in Functions,  Up: Target Builtins
+
+6.57.25 SH Built-in Functions
+-----------------------------
+
+The following built-in functions are supported on the SH1, SH2, SH3 and
+SH4 families of processors:
+
+ -- Built-in Function: void __builtin_set_thread_pointer (void *PTR)
+     Sets the 'GBR' register to the specified value PTR.  This is
+     usually used by system code that manages threads and execution
+     contexts.  The compiler normally does not generate code that
+     modifies the contents of 'GBR' and thus the value is preserved
+     across function calls.  Changing the 'GBR' value in user code must
+     be done with caution, since the compiler might use 'GBR' in order
+     to access thread local variables.
+
+ -- Built-in Function: void * __builtin_thread_pointer (void)
+     Returns the value that is currently set in the 'GBR' register.
+     Memory loads and stores that use the thread pointer as a base
+     address are turned into 'GBR' based displacement loads and stores,
+     if possible.  For example:
+          struct my_tcb
+          {
+             int a, b, c, d, e;
+          };
+
+          int get_tcb_value (void)
+          {
+            // Generate 'mov.l @(8,gbr),r0' instruction
+            return ((my_tcb*)__builtin_thread_pointer ())->c;
+          }
+
+
+File: gcc.info,  Node: SPARC VIS Built-in Functions,  Next: SPU Built-in Functions,  Prev: SH Built-in Functions,  Up: Target Builtins
+
+6.57.26 SPARC VIS Built-in Functions
+------------------------------------
+
+GCC supports SIMD operations on the SPARC using both the generic vector
+extensions (*note Vector Extensions::) as well as built-in functions for
+the SPARC Visual Instruction Set (VIS). When you use the '-mvis' switch,
+the VIS extension is exposed as the following built-in functions:
+
+     typedef int v1si __attribute__ ((vector_size (4)));
+     typedef int v2si __attribute__ ((vector_size (8)));
+     typedef short v4hi __attribute__ ((vector_size (8)));
+     typedef short v2hi __attribute__ ((vector_size (4)));
+     typedef unsigned char v8qi __attribute__ ((vector_size (8)));
+     typedef unsigned char v4qi __attribute__ ((vector_size (4)));
+
+     void __builtin_vis_write_gsr (int64_t);
+     int64_t __builtin_vis_read_gsr (void);
+
+     void * __builtin_vis_alignaddr (void *, long);
+     void * __builtin_vis_alignaddrl (void *, long);
+     int64_t __builtin_vis_faligndatadi (int64_t, int64_t);
+     v2si __builtin_vis_faligndatav2si (v2si, v2si);
+     v4hi __builtin_vis_faligndatav4hi (v4si, v4si);
+     v8qi __builtin_vis_faligndatav8qi (v8qi, v8qi);
+
+     v4hi __builtin_vis_fexpand (v4qi);
+
+     v4hi __builtin_vis_fmul8x16 (v4qi, v4hi);
+     v4hi __builtin_vis_fmul8x16au (v4qi, v2hi);
+     v4hi __builtin_vis_fmul8x16al (v4qi, v2hi);
+     v4hi __builtin_vis_fmul8sux16 (v8qi, v4hi);
+     v4hi __builtin_vis_fmul8ulx16 (v8qi, v4hi);
+     v2si __builtin_vis_fmuld8sux16 (v4qi, v2hi);
+     v2si __builtin_vis_fmuld8ulx16 (v4qi, v2hi);
+
+     v4qi __builtin_vis_fpack16 (v4hi);
+     v8qi __builtin_vis_fpack32 (v2si, v8qi);
+     v2hi __builtin_vis_fpackfix (v2si);
+     v8qi __builtin_vis_fpmerge (v4qi, v4qi);
+
+     int64_t __builtin_vis_pdist (v8qi, v8qi, int64_t);
+
+     long __builtin_vis_edge8 (void *, void *);
+     long __builtin_vis_edge8l (void *, void *);
+     long __builtin_vis_edge16 (void *, void *);
+     long __builtin_vis_edge16l (void *, void *);
+     long __builtin_vis_edge32 (void *, void *);
+     long __builtin_vis_edge32l (void *, void *);
+
+     long __builtin_vis_fcmple16 (v4hi, v4hi);
+     long __builtin_vis_fcmple32 (v2si, v2si);
+     long __builtin_vis_fcmpne16 (v4hi, v4hi);
+     long __builtin_vis_fcmpne32 (v2si, v2si);
+     long __builtin_vis_fcmpgt16 (v4hi, v4hi);
+     long __builtin_vis_fcmpgt32 (v2si, v2si);
+     long __builtin_vis_fcmpeq16 (v4hi, v4hi);
+     long __builtin_vis_fcmpeq32 (v2si, v2si);
+
+     v4hi __builtin_vis_fpadd16 (v4hi, v4hi);
+     v2hi __builtin_vis_fpadd16s (v2hi, v2hi);
+     v2si __builtin_vis_fpadd32 (v2si, v2si);
+     v1si __builtin_vis_fpadd32s (v1si, v1si);
+     v4hi __builtin_vis_fpsub16 (v4hi, v4hi);
+     v2hi __builtin_vis_fpsub16s (v2hi, v2hi);
+     v2si __builtin_vis_fpsub32 (v2si, v2si);
+     v1si __builtin_vis_fpsub32s (v1si, v1si);
+
+     long __builtin_vis_array8 (long, long);
+     long __builtin_vis_array16 (long, long);
+     long __builtin_vis_array32 (long, long);
+
+ When you use the '-mvis2' switch, the VIS version 2.0 built-in
+functions also become available:
+
+     long __builtin_vis_bmask (long, long);
+     int64_t __builtin_vis_bshuffledi (int64_t, int64_t);
+     v2si __builtin_vis_bshufflev2si (v2si, v2si);
+     v4hi __builtin_vis_bshufflev2si (v4hi, v4hi);
+     v8qi __builtin_vis_bshufflev2si (v8qi, v8qi);
+
+     long __builtin_vis_edge8n (void *, void *);
+     long __builtin_vis_edge8ln (void *, void *);
+     long __builtin_vis_edge16n (void *, void *);
+     long __builtin_vis_edge16ln (void *, void *);
+     long __builtin_vis_edge32n (void *, void *);
+     long __builtin_vis_edge32ln (void *, void *);
+
+ When you use the '-mvis3' switch, the VIS version 3.0 built-in
+functions also become available:
+
+     void __builtin_vis_cmask8 (long);
+     void __builtin_vis_cmask16 (long);
+     void __builtin_vis_cmask32 (long);
+
+     v4hi __builtin_vis_fchksm16 (v4hi, v4hi);
+
+     v4hi __builtin_vis_fsll16 (v4hi, v4hi);
+     v4hi __builtin_vis_fslas16 (v4hi, v4hi);
+     v4hi __builtin_vis_fsrl16 (v4hi, v4hi);
+     v4hi __builtin_vis_fsra16 (v4hi, v4hi);
+     v2si __builtin_vis_fsll16 (v2si, v2si);
+     v2si __builtin_vis_fslas16 (v2si, v2si);
+     v2si __builtin_vis_fsrl16 (v2si, v2si);
+     v2si __builtin_vis_fsra16 (v2si, v2si);
+
+     long __builtin_vis_pdistn (v8qi, v8qi);
+
+     v4hi __builtin_vis_fmean16 (v4hi, v4hi);
+
+     int64_t __builtin_vis_fpadd64 (int64_t, int64_t);
+     int64_t __builtin_vis_fpsub64 (int64_t, int64_t);
+
+     v4hi __builtin_vis_fpadds16 (v4hi, v4hi);
+     v2hi __builtin_vis_fpadds16s (v2hi, v2hi);
+     v4hi __builtin_vis_fpsubs16 (v4hi, v4hi);
+     v2hi __builtin_vis_fpsubs16s (v2hi, v2hi);
+     v2si __builtin_vis_fpadds32 (v2si, v2si);
+     v1si __builtin_vis_fpadds32s (v1si, v1si);
+     v2si __builtin_vis_fpsubs32 (v2si, v2si);
+     v1si __builtin_vis_fpsubs32s (v1si, v1si);
+
+     long __builtin_vis_fucmple8 (v8qi, v8qi);
+     long __builtin_vis_fucmpne8 (v8qi, v8qi);
+     long __builtin_vis_fucmpgt8 (v8qi, v8qi);
+     long __builtin_vis_fucmpeq8 (v8qi, v8qi);
+
+     float __builtin_vis_fhadds (float, float);
+     double __builtin_vis_fhaddd (double, double);
+     float __builtin_vis_fhsubs (float, float);
+     double __builtin_vis_fhsubd (double, double);
+     float __builtin_vis_fnhadds (float, float);
+     double __builtin_vis_fnhaddd (double, double);
+
+     int64_t __builtin_vis_umulxhi (int64_t, int64_t);
+     int64_t __builtin_vis_xmulx (int64_t, int64_t);
+     int64_t __builtin_vis_xmulxhi (int64_t, int64_t);
+
+
+File: gcc.info,  Node: SPU Built-in Functions,  Next: TI C6X Built-in Functions,  Prev: SPARC VIS Built-in Functions,  Up: Target Builtins
+
+6.57.27 SPU Built-in Functions
+------------------------------
+
+GCC provides extensions for the SPU processor as described in the
+Sony/Toshiba/IBM SPU Language Extensions Specification, which can be
+found at <http://cell.scei.co.jp/> or
+<http://www.ibm.com/developerworks/power/cell/>.  GCC's implementation
+differs in several ways.
+
+   * The optional extension of specifying vector constants in
+     parentheses is not supported.
+
+   * A vector initializer requires no cast if the vector constant is of
+     the same type as the variable it is initializing.
+
+   * If 'signed' or 'unsigned' is omitted, the signedness of the vector
+     type is the default signedness of the base type.  The default
+     varies depending on the operating system, so a portable program
+     should always specify the signedness.
+
+   * By default, the keyword '__vector' is added.  The macro 'vector' is
+     defined in '<spu_intrinsics.h>' and can be undefined.
+
+   * GCC allows using a 'typedef' name as the type specifier for a
+     vector type.
+
+   * For C, overloaded functions are implemented with macros so the
+     following does not work:
+
+            spu_add ((vector signed int){1, 2, 3, 4}, foo);
+
+     Since 'spu_add' is a macro, the vector constant in the example is
+     treated as four separate arguments.  Wrap the entire argument in
+     parentheses for this to work.
+
+   * The extended version of '__builtin_expect' is not supported.
+
+ _Note:_ Only the interface described in the aforementioned
+specification is supported.  Internally, GCC uses built-in functions to
+implement the required functionality, but these are not supported and
+are subject to change without notice.
+
+
+File: gcc.info,  Node: TI C6X Built-in Functions,  Next: TILE-Gx Built-in Functions,  Prev: SPU Built-in Functions,  Up: Target Builtins
+
+6.57.28 TI C6X Built-in Functions
+---------------------------------
+
+GCC provides intrinsics to access certain instructions of the TI C6X
+processors.  These intrinsics, listed below, are available after
+inclusion of the 'c6x_intrinsics.h' header file.  They map directly to
+C6X instructions.
+
+
+     int _sadd (int, int)
+     int _ssub (int, int)
+     int _sadd2 (int, int)
+     int _ssub2 (int, int)
+     long long _mpy2 (int, int)
+     long long _smpy2 (int, int)
+     int _add4 (int, int)
+     int _sub4 (int, int)
+     int _saddu4 (int, int)
+
+     int _smpy (int, int)
+     int _smpyh (int, int)
+     int _smpyhl (int, int)
+     int _smpylh (int, int)
+
+     int _sshl (int, int)
+     int _subc (int, int)
+
+     int _avg2 (int, int)
+     int _avgu4 (int, int)
+
+     int _clrr (int, int)
+     int _extr (int, int)
+     int _extru (int, int)
+     int _abs (int)
+     int _abs2 (int)
+
+
+File: gcc.info,  Node: TILE-Gx Built-in Functions,  Next: TILEPro Built-in Functions,  Prev: TI C6X Built-in Functions,  Up: Target Builtins
+
+6.57.29 TILE-Gx Built-in Functions
+----------------------------------
+
+GCC provides intrinsics to access every instruction of the TILE-Gx
+processor.  The intrinsics are of the form:
+
+
+     unsigned long long __insn_OP (...)
+
+ Where OP is the name of the instruction.  Refer to the ISA manual for
+the complete list of instructions.
+
+ GCC also provides intrinsics to directly access the network registers.
+The intrinsics are:
+
+
+     unsigned long long __tile_idn0_receive (void)
+     unsigned long long __tile_idn1_receive (void)
+     unsigned long long __tile_udn0_receive (void)
+     unsigned long long __tile_udn1_receive (void)
+     unsigned long long __tile_udn2_receive (void)
+     unsigned long long __tile_udn3_receive (void)
+     void __tile_idn_send (unsigned long long)
+     void __tile_udn_send (unsigned long long)
+
+ The intrinsic 'void __tile_network_barrier (void)' is used to guarantee
+that no network operations before it are reordered with those after it.
+
+
+File: gcc.info,  Node: TILEPro Built-in Functions,  Prev: TILE-Gx Built-in Functions,  Up: Target Builtins
+
+6.57.30 TILEPro Built-in Functions
+----------------------------------
+
+GCC provides intrinsics to access every instruction of the TILEPro
+processor.  The intrinsics are of the form:
+
+
+     unsigned __insn_OP (...)
+
+where OP is the name of the instruction.  Refer to the ISA manual for
+the complete list of instructions.
+
+ GCC also provides intrinsics to directly access the network registers.
+The intrinsics are:
+
+
+     unsigned __tile_idn0_receive (void)
+     unsigned __tile_idn1_receive (void)
+     unsigned __tile_sn_receive (void)
+     unsigned __tile_udn0_receive (void)
+     unsigned __tile_udn1_receive (void)
+     unsigned __tile_udn2_receive (void)
+     unsigned __tile_udn3_receive (void)
+     void __tile_idn_send (unsigned)
+     void __tile_sn_send (unsigned)
+     void __tile_udn_send (unsigned)
+
+ The intrinsic 'void __tile_network_barrier (void)' is used to guarantee
+that no network operations before it are reordered with those after it.
+
+
+File: gcc.info,  Node: Target Format Checks,  Next: Pragmas,  Prev: Target Builtins,  Up: C Extensions
+
+6.58 Format Checks Specific to Particular Target Machines
+=========================================================
+
+For some target machines, GCC supports additional options to the format
+attribute (*note Declaring Attributes of Functions: Function
+Attributes.).
+
+* Menu:
+
+* Solaris Format Checks::
+* Darwin Format Checks::
+
+
+File: gcc.info,  Node: Solaris Format Checks,  Next: Darwin Format Checks,  Up: Target Format Checks
+
+6.58.1 Solaris Format Checks
+----------------------------
+
+Solaris targets support the 'cmn_err' (or '__cmn_err__') format check.
+'cmn_err' accepts a subset of the standard 'printf' conversions, and the
+two-argument '%b' conversion for displaying bit-fields.  See the Solaris
+man page for 'cmn_err' for more information.
+
+
+File: gcc.info,  Node: Darwin Format Checks,  Prev: Solaris Format Checks,  Up: Target Format Checks
+
+6.58.2 Darwin Format Checks
+---------------------------
+
+Darwin targets support the 'CFString' (or '__CFString__') in the format
+attribute context.  Declarations made with such attribution are parsed
+for correct syntax and format argument types.  However, parsing of the
+format string itself is currently undefined and is not carried out by
+this version of the compiler.
+
+ Additionally, 'CFStringRefs' (defined by the 'CoreFoundation' headers)
+may also be used as format arguments.  Note that the relevant headers
+are only likely to be available on Darwin (OSX) installations.  On such
+installations, the XCode and system documentation provide descriptions
+of 'CFString', 'CFStringRefs' and associated functions.
+
+
+File: gcc.info,  Node: Pragmas,  Next: Unnamed Fields,  Prev: Target Format Checks,  Up: C Extensions
+
+6.59 Pragmas Accepted by GCC
+============================
+
+GCC supports several types of pragmas, primarily in order to compile
+code originally written for other compilers.  Note that in general we do
+not recommend the use of pragmas; *Note Function Attributes::, for
+further explanation.
+
+* Menu:
+
+* ARM Pragmas::
+* M32C Pragmas::
+* MeP Pragmas::
+* RS/6000 and PowerPC Pragmas::
+* Darwin Pragmas::
+* Solaris Pragmas::
+* Symbol-Renaming Pragmas::
+* Structure-Packing Pragmas::
+* Weak Pragmas::
+* Diagnostic Pragmas::
+* Visibility Pragmas::
+* Push/Pop Macro Pragmas::
+* Function Specific Option Pragmas::
+* Loop-Specific Pragmas::
+
+
+File: gcc.info,  Node: ARM Pragmas,  Next: M32C Pragmas,  Up: Pragmas
+
+6.59.1 ARM Pragmas
+------------------
+
+The ARM target defines pragmas for controlling the default addition of
+'long_call' and 'short_call' attributes to functions.  *Note Function
+Attributes::, for information about the effects of these attributes.
+
+'long_calls'
+     Set all subsequent functions to have the 'long_call' attribute.
+
+'no_long_calls'
+     Set all subsequent functions to have the 'short_call' attribute.
+
+'long_calls_off'
+     Do not affect the 'long_call' or 'short_call' attributes of
+     subsequent functions.
+
+
+File: gcc.info,  Node: M32C Pragmas,  Next: MeP Pragmas,  Prev: ARM Pragmas,  Up: Pragmas
+
+6.59.2 M32C Pragmas
+-------------------
+
+'GCC memregs NUMBER'
+     Overrides the command-line option '-memregs=' for the current file.
+     Use with care!  This pragma must be before any function in the
+     file, and mixing different memregs values in different objects may
+     make them incompatible.  This pragma is useful when a
+     performance-critical function uses a memreg for temporary values,
+     as it may allow you to reduce the number of memregs used.
+
+'ADDRESS NAME ADDRESS'
+     For any declared symbols matching NAME, this does three things to
+     that symbol: it forces the symbol to be located at the given
+     address (a number), it forces the symbol to be volatile, and it
+     changes the symbol's scope to be static.  This pragma exists for
+     compatibility with other compilers, but note that the common
+     '1234H' numeric syntax is not supported (use '0x1234' instead).
+     Example:
+
+          #pragma ADDRESS port3 0x103
+          char port3;
+
+
+File: gcc.info,  Node: MeP Pragmas,  Next: RS/6000 and PowerPC Pragmas,  Prev: M32C Pragmas,  Up: Pragmas
+
+6.59.3 MeP Pragmas
+------------------
+
+'custom io_volatile (on|off)'
+     Overrides the command-line option '-mio-volatile' for the current
+     file.  Note that for compatibility with future GCC releases, this
+     option should only be used once before any 'io' variables in each
+     file.
+
+'GCC coprocessor available REGISTERS'
+     Specifies which coprocessor registers are available to the register
+     allocator.  REGISTERS may be a single register, register range
+     separated by ellipses, or comma-separated list of those.  Example:
+
+          #pragma GCC coprocessor available $c0...$c10, $c28
+
+'GCC coprocessor call_saved REGISTERS'
+     Specifies which coprocessor registers are to be saved and restored
+     by any function using them.  REGISTERS may be a single register,
+     register range separated by ellipses, or comma-separated list of
+     those.  Example:
+
+          #pragma GCC coprocessor call_saved $c4...$c6, $c31
+
+'GCC coprocessor subclass '(A|B|C|D)' = REGISTERS'
+     Creates and defines a register class.  These register classes can
+     be used by inline 'asm' constructs.  REGISTERS may be a single
+     register, register range separated by ellipses, or comma-separated
+     list of those.  Example:
+
+          #pragma GCC coprocessor subclass 'B' = $c2, $c4, $c6
+
+          asm ("cpfoo %0" : "=B" (x));
+
+'GCC disinterrupt NAME , NAME ...'
+     For the named functions, the compiler adds code to disable
+     interrupts for the duration of those functions.  If any functions
+     so named are not encountered in the source, a warning is emitted
+     that the pragma is not used.  Examples:
+
+          #pragma disinterrupt foo
+          #pragma disinterrupt bar, grill
+          int foo () { ... }
+
+'GCC call NAME , NAME ...'
+     For the named functions, the compiler always uses a
+     register-indirect call model when calling the named functions.
+     Examples:
+
+          extern int foo ();
+          #pragma call foo
+
+
+File: gcc.info,  Node: RS/6000 and PowerPC Pragmas,  Next: Darwin Pragmas,  Prev: MeP Pragmas,  Up: Pragmas
+
+6.59.4 RS/6000 and PowerPC Pragmas
+----------------------------------
+
+The RS/6000 and PowerPC targets define one pragma for controlling
+whether or not the 'longcall' attribute is added to function
+declarations by default.  This pragma overrides the '-mlongcall' option,
+but not the 'longcall' and 'shortcall' attributes.  *Note RS/6000 and
+PowerPC Options::, for more information about when long calls are and
+are not necessary.
+
+'longcall (1)'
+     Apply the 'longcall' attribute to all subsequent function
+     declarations.
+
+'longcall (0)'
+     Do not apply the 'longcall' attribute to subsequent function
+     declarations.
+
+
+File: gcc.info,  Node: Darwin Pragmas,  Next: Solaris Pragmas,  Prev: RS/6000 and PowerPC Pragmas,  Up: Pragmas
+
+6.59.5 Darwin Pragmas
+---------------------
+
+The following pragmas are available for all architectures running the
+Darwin operating system.  These are useful for compatibility with other
+Mac OS compilers.
+
+'mark TOKENS...'
+     This pragma is accepted, but has no effect.
+
+'options align=ALIGNMENT'
+     This pragma sets the alignment of fields in structures.  The values
+     of ALIGNMENT may be 'mac68k', to emulate m68k alignment, or
+     'power', to emulate PowerPC alignment.  Uses of this pragma nest
+     properly; to restore the previous setting, use 'reset' for the
+     ALIGNMENT.
+
+'segment TOKENS...'
+     This pragma is accepted, but has no effect.
+
+'unused (VAR [, VAR]...)'
+     This pragma declares variables to be possibly unused.  GCC does not
+     produce warnings for the listed variables.  The effect is similar
+     to that of the 'unused' attribute, except that this pragma may
+     appear anywhere within the variables' scopes.
+
+
+File: gcc.info,  Node: Solaris Pragmas,  Next: Symbol-Renaming Pragmas,  Prev: Darwin Pragmas,  Up: Pragmas
+
+6.59.6 Solaris Pragmas
+----------------------
+
+The Solaris target supports '#pragma redefine_extname' (*note
+Symbol-Renaming Pragmas::).  It also supports additional '#pragma'
+directives for compatibility with the system compiler.
+
+'align ALIGNMENT (VARIABLE [, VARIABLE]...)'
+
+     Increase the minimum alignment of each VARIABLE to ALIGNMENT.  This
+     is the same as GCC's 'aligned' attribute *note Variable
+     Attributes::).  Macro expansion occurs on the arguments to this
+     pragma when compiling C and Objective-C.  It does not currently
+     occur when compiling C++, but this is a bug which may be fixed in a
+     future release.
+
+'fini (FUNCTION [, FUNCTION]...)'
+
+     This pragma causes each listed FUNCTION to be called after main, or
+     during shared module unloading, by adding a call to the '.fini'
+     section.
+
+'init (FUNCTION [, FUNCTION]...)'
+
+     This pragma causes each listed FUNCTION to be called during
+     initialization (before 'main') or during shared module loading, by
+     adding a call to the '.init' section.
+
+
+File: gcc.info,  Node: Symbol-Renaming Pragmas,  Next: Structure-Packing Pragmas,  Prev: Solaris Pragmas,  Up: Pragmas
+
+6.59.7 Symbol-Renaming Pragmas
+------------------------------
+
+For compatibility with the Solaris system headers, GCC supports two
+'#pragma' directives that change the name used in assembly for a given
+declaration.  To get this effect on all platforms supported by GCC, use
+the asm labels extension (*note Asm Labels::).
+
+'redefine_extname OLDNAME NEWNAME'
+
+     This pragma gives the C function OLDNAME the assembly symbol
+     NEWNAME.  The preprocessor macro '__PRAGMA_REDEFINE_EXTNAME' is
+     defined if this pragma is available (currently on all platforms).
+
+ This pragma and the asm labels extension interact in a complicated
+manner.  Here are some corner cases you may want to be aware of.
+
+  1. Both pragmas silently apply only to declarations with external
+     linkage.  Asm labels do not have this restriction.
+
+  2. In C++, both pragmas silently apply only to declarations with "C"
+     linkage.  Again, asm labels do not have this restriction.
+
+  3. If any of the three ways of changing the assembly name of a
+     declaration is applied to a declaration whose assembly name has
+     already been determined (either by a previous use of one of these
+     features, or because the compiler needed the assembly name in order
+     to generate code), and the new name is different, a warning issues
+     and the name does not change.
+
+  4. The OLDNAME used by '#pragma redefine_extname' is always the
+     C-language name.
+
+
+File: gcc.info,  Node: Structure-Packing Pragmas,  Next: Weak Pragmas,  Prev: Symbol-Renaming Pragmas,  Up: Pragmas
+
+6.59.8 Structure-Packing Pragmas
+--------------------------------
+
+For compatibility with Microsoft Windows compilers, GCC supports a set
+of '#pragma' directives that change the maximum alignment of members of
+structures (other than zero-width bit-fields), unions, and classes
+subsequently defined.  The N value below always is required to be a
+small power of two and specifies the new alignment in bytes.
+
+  1. '#pragma pack(N)' simply sets the new alignment.
+  2. '#pragma pack()' sets the alignment to the one that was in effect
+     when compilation started (see also command-line option
+     '-fpack-struct[=N]' *note Code Gen Options::).
+  3. '#pragma pack(push[,N])' pushes the current alignment setting on an
+     internal stack and then optionally sets the new alignment.
+  4. '#pragma pack(pop)' restores the alignment setting to the one saved
+     at the top of the internal stack (and removes that stack entry).
+     Note that '#pragma pack([N])' does not influence this internal
+     stack; thus it is possible to have '#pragma pack(push)' followed by
+     multiple '#pragma pack(N)' instances and finalized by a single
+     '#pragma pack(pop)'.
+
+ Some targets, e.g. i386 and PowerPC, support the 'ms_struct' '#pragma'
+which lays out a structure as the documented '__attribute__
+((ms_struct))'.
+  1. '#pragma ms_struct on' turns on the layout for structures declared.
+  2. '#pragma ms_struct off' turns off the layout for structures
+     declared.
+  3. '#pragma ms_struct reset' goes back to the default layout.
+
+
+File: gcc.info,  Node: Weak Pragmas,  Next: Diagnostic Pragmas,  Prev: Structure-Packing Pragmas,  Up: Pragmas
+
+6.59.9 Weak Pragmas
+-------------------
+
+For compatibility with SVR4, GCC supports a set of '#pragma' directives
+for declaring symbols to be weak, and defining weak aliases.
+
+'#pragma weak SYMBOL'
+     This pragma declares SYMBOL to be weak, as if the declaration had
+     the attribute of the same name.  The pragma may appear before or
+     after the declaration of SYMBOL.  It is not an error for SYMBOL to
+     never be defined at all.
+
+'#pragma weak SYMBOL1 = SYMBOL2'
+     This pragma declares SYMBOL1 to be a weak alias of SYMBOL2.  It is
+     an error if SYMBOL2 is not defined in the current translation unit.
+
+
+File: gcc.info,  Node: Diagnostic Pragmas,  Next: Visibility Pragmas,  Prev: Weak Pragmas,  Up: Pragmas
+
+6.59.10 Diagnostic Pragmas
+--------------------------
+
+GCC allows the user to selectively enable or disable certain types of
+diagnostics, and change the kind of the diagnostic.  For example, a
+project's policy might require that all sources compile with '-Werror'
+but certain files might have exceptions allowing specific types of
+warnings.  Or, a project might selectively enable diagnostics and treat
+them as errors depending on which preprocessor macros are defined.
+
+'#pragma GCC diagnostic KIND OPTION'
+
+     Modifies the disposition of a diagnostic.  Note that not all
+     diagnostics are modifiable; at the moment only warnings (normally
+     controlled by '-W...') can be controlled, and not all of them.  Use
+     '-fdiagnostics-show-option' to determine which diagnostics are
+     controllable and which option controls them.
+
+     KIND is 'error' to treat this diagnostic as an error, 'warning' to
+     treat it like a warning (even if '-Werror' is in effect), or
+     'ignored' if the diagnostic is to be ignored.  OPTION is a double
+     quoted string that matches the command-line option.
+
+          #pragma GCC diagnostic warning "-Wformat"
+          #pragma GCC diagnostic error "-Wformat"
+          #pragma GCC diagnostic ignored "-Wformat"
+
+     Note that these pragmas override any command-line options.  GCC
+     keeps track of the location of each pragma, and issues diagnostics
+     according to the state as of that point in the source file.  Thus,
+     pragmas occurring after a line do not affect diagnostics caused by
+     that line.
+
+'#pragma GCC diagnostic push'
+'#pragma GCC diagnostic pop'
+
+     Causes GCC to remember the state of the diagnostics as of each
+     'push', and restore to that point at each 'pop'.  If a 'pop' has no
+     matching 'push', the command-line options are restored.
+
+          #pragma GCC diagnostic error "-Wuninitialized"
+            foo(a);                       /* error is given for this one */
+          #pragma GCC diagnostic push
+          #pragma GCC diagnostic ignored "-Wuninitialized"
+            foo(b);                       /* no diagnostic for this one */
+          #pragma GCC diagnostic pop
+            foo(c);                       /* error is given for this one */
+          #pragma GCC diagnostic pop
+            foo(d);                       /* depends on command-line options */
+
+ GCC also offers a simple mechanism for printing messages during
+compilation.
+
+'#pragma message STRING'
+
+     Prints STRING as a compiler message on compilation.  The message is
+     informational only, and is neither a compilation warning nor an
+     error.
+
+          #pragma message "Compiling " __FILE__ "..."
+
+     STRING may be parenthesized, and is printed with location
+     information.  For example,
+
+          #define DO_PRAGMA(x) _Pragma (#x)
+          #define TODO(x) DO_PRAGMA(message ("TODO - " #x))
+
+          TODO(Remember to fix this)
+
+     prints '/tmp/file.c:4: note: #pragma message: TODO - Remember to
+     fix this'.
+
+
+File: gcc.info,  Node: Visibility Pragmas,  Next: Push/Pop Macro Pragmas,  Prev: Diagnostic Pragmas,  Up: Pragmas
+
+6.59.11 Visibility Pragmas
+--------------------------
+
+'#pragma GCC visibility push(VISIBILITY)'
+'#pragma GCC visibility pop'
+
+     This pragma allows the user to set the visibility for multiple
+     declarations without having to give each a visibility attribute
+     *Note Function Attributes::, for more information about visibility
+     and the attribute syntax.
+
+     In C++, '#pragma GCC visibility' affects only namespace-scope
+     declarations.  Class members and template specializations are not
+     affected; if you want to override the visibility for a particular
+     member or instantiation, you must use an attribute.
+
+
+File: gcc.info,  Node: Push/Pop Macro Pragmas,  Next: Function Specific Option Pragmas,  Prev: Visibility Pragmas,  Up: Pragmas
+
+6.59.12 Push/Pop Macro Pragmas
+------------------------------
+
+For compatibility with Microsoft Windows compilers, GCC supports
+'#pragma push_macro("MACRO_NAME")' and '#pragma
+pop_macro("MACRO_NAME")'.
+
+'#pragma push_macro("MACRO_NAME")'
+     This pragma saves the value of the macro named as MACRO_NAME to the
+     top of the stack for this macro.
+
+'#pragma pop_macro("MACRO_NAME")'
+     This pragma sets the value of the macro named as MACRO_NAME to the
+     value on top of the stack for this macro.  If the stack for
+     MACRO_NAME is empty, the value of the macro remains unchanged.
+
+ For example:
+
+     #define X  1
+     #pragma push_macro("X")
+     #undef X
+     #define X -1
+     #pragma pop_macro("X")
+     int x [X];
+
+In this example, the definition of X as 1 is saved by '#pragma
+push_macro' and restored by '#pragma pop_macro'.
+
+
+File: gcc.info,  Node: Function Specific Option Pragmas,  Next: Loop-Specific Pragmas,  Prev: Push/Pop Macro Pragmas,  Up: Pragmas
+
+6.59.13 Function Specific Option Pragmas
+----------------------------------------
+
+'#pragma GCC target ("STRING"...)'
+
+     This pragma allows you to set target specific options for functions
+     defined later in the source file.  One or more strings can be
+     specified.  Each function that is defined after this point is as if
+     'attribute((target("STRING")))' was specified for that function.
+     The parenthesis around the options is optional.  *Note Function
+     Attributes::, for more information about the 'target' attribute and
+     the attribute syntax.
+
+     The '#pragma GCC target' pragma is presently implemented for
+     i386/x86_64, PowerPC, and Nios II targets only.
+
+'#pragma GCC optimize ("STRING"...)'
+
+     This pragma allows you to set global optimization options for
+     functions defined later in the source file.  One or more strings
+     can be specified.  Each function that is defined after this point
+     is as if 'attribute((optimize("STRING")))' was specified for that
+     function.  The parenthesis around the options is optional.  *Note
+     Function Attributes::, for more information about the 'optimize'
+     attribute and the attribute syntax.
+
+     The '#pragma GCC optimize' pragma is not implemented in GCC
+     versions earlier than 4.4.
+
+'#pragma GCC push_options'
+'#pragma GCC pop_options'
+
+     These pragmas maintain a stack of the current target and
+     optimization options.  It is intended for include files where you
+     temporarily want to switch to using a different '#pragma GCC
+     target' or '#pragma GCC optimize' and then to pop back to the
+     previous options.
+
+     The '#pragma GCC push_options' and '#pragma GCC pop_options'
+     pragmas are not implemented in GCC versions earlier than 4.4.
+
+'#pragma GCC reset_options'
+
+     This pragma clears the current '#pragma GCC target' and '#pragma
+     GCC optimize' to use the default switches as specified on the
+     command line.
+
+     The '#pragma GCC reset_options' pragma is not implemented in GCC
+     versions earlier than 4.4.
+
+
+File: gcc.info,  Node: Loop-Specific Pragmas,  Prev: Function Specific Option Pragmas,  Up: Pragmas
+
+6.59.14 Loop-Specific Pragmas
+-----------------------------
+
+'#pragma GCC ivdep'
+
+ With this pragma, the programmer asserts that there are no loop-carried
+dependencies which would prevent that consecutive iterations of the
+following loop can be executed concurrently with SIMD (single
+instruction multiple data) instructions.
+
+ For example, the compiler can only unconditionally vectorize the
+following loop with the pragma:
+
+     void foo (int n, int *a, int *b, int *c)
+     {
+       int i, j;
+     #pragma GCC ivdep
+       for (i = 0; i < n; ++i)
+         a[i] = b[i] + c[i];
+     }
+
+In this example, using the 'restrict' qualifier had the same effect.  In
+the following example, that would not be possible.  Assume k < -m or k
+>= m.  Only with the pragma, the compiler knows that it can
+unconditionally vectorize the following loop:
+
+     void ignore_vec_dep (int *a, int k, int c, int m)
+     {
+     #pragma GCC ivdep
+       for (int i = 0; i < m; i++)
+         a[i] = a[i + k] * c;
+     }
+
+
+File: gcc.info,  Node: Unnamed Fields,  Next: Thread-Local,  Prev: Pragmas,  Up: C Extensions
+
+6.60 Unnamed struct/union fields within structs/unions
+======================================================
+
+As permitted by ISO C11 and for compatibility with other compilers, GCC
+allows you to define a structure or union that contains, as fields,
+structures and unions without names.  For example:
+
+     struct {
+       int a;
+       union {
+         int b;
+         float c;
+       };
+       int d;
+     } foo;
+
+In this example, you are able to access members of the unnamed union
+with code like 'foo.b'.  Note that only unnamed structs and unions are
+allowed, you may not have, for example, an unnamed 'int'.
+
+ You must never create such structures that cause ambiguous field
+definitions.  For example, in this structure:
+
+     struct {
+       int a;
+       struct {
+         int a;
+       };
+     } foo;
+
+it is ambiguous which 'a' is being referred to with 'foo.a'.  The
+compiler gives errors for such constructs.
+
+ Unless '-fms-extensions' is used, the unnamed field must be a structure
+or union definition without a tag (for example, 'struct { int a; };').
+If '-fms-extensions' is used, the field may also be a definition with a
+tag such as 'struct foo { int a; };', a reference to a previously
+defined structure or union such as 'struct foo;', or a reference to a
+'typedef' name for a previously defined structure or union type.
+
+ The option '-fplan9-extensions' enables '-fms-extensions' as well as
+two other extensions.  First, a pointer to a structure is automatically
+converted to a pointer to an anonymous field for assignments and
+function calls.  For example:
+
+     struct s1 { int a; };
+     struct s2 { struct s1; };
+     extern void f1 (struct s1 *);
+     void f2 (struct s2 *p) { f1 (p); }
+
+In the call to 'f1' inside 'f2', the pointer 'p' is converted into a
+pointer to the anonymous field.
+
+ Second, when the type of an anonymous field is a 'typedef' for a
+'struct' or 'union', code may refer to the field using the name of the
+'typedef'.
+
+     typedef struct { int a; } s1;
+     struct s2 { s1; };
+     s1 f1 (struct s2 *p) { return p->s1; }
+
+ These usages are only permitted when they are not ambiguous.
+
+
+File: gcc.info,  Node: Thread-Local,  Next: Binary constants,  Prev: Unnamed Fields,  Up: C Extensions
+
+6.61 Thread-Local Storage
+=========================
+
+Thread-local storage (TLS) is a mechanism by which variables are
+allocated such that there is one instance of the variable per extant
+thread.  The runtime model GCC uses to implement this originates in the
+IA-64 processor-specific ABI, but has since been migrated to other
+processors as well.  It requires significant support from the linker
+('ld'), dynamic linker ('ld.so'), and system libraries ('libc.so' and
+'libpthread.so'), so it is not available everywhere.
+
+ At the user level, the extension is visible with a new storage class
+keyword: '__thread'.  For example:
+
+     __thread int i;
+     extern __thread struct state s;
+     static __thread char *p;
+
+ The '__thread' specifier may be used alone, with the 'extern' or
+'static' specifiers, but with no other storage class specifier.  When
+used with 'extern' or 'static', '__thread' must appear immediately after
+the other storage class specifier.
+
+ The '__thread' specifier may be applied to any global, file-scoped
+static, function-scoped static, or static data member of a class.  It
+may not be applied to block-scoped automatic or non-static data member.
+
+ When the address-of operator is applied to a thread-local variable, it
+is evaluated at run time and returns the address of the current thread's
+instance of that variable.  An address so obtained may be used by any
+thread.  When a thread terminates, any pointers to thread-local
+variables in that thread become invalid.
+
+ No static initialization may refer to the address of a thread-local
+variable.
+
+ In C++, if an initializer is present for a thread-local variable, it
+must be a CONSTANT-EXPRESSION, as defined in 5.19.2 of the ANSI/ISO C++
+standard.
+
+ See ELF Handling For Thread-Local Storage
+(http://www.akkadia.org/drepper/tls.pdf) for a detailed explanation of
+the four thread-local storage addressing models, and how the runtime is
+expected to function.
+
+* Menu:
+
+* C99 Thread-Local Edits::
+* C++98 Thread-Local Edits::
+
+
+File: gcc.info,  Node: C99 Thread-Local Edits,  Next: C++98 Thread-Local Edits,  Up: Thread-Local
+
+6.61.1 ISO/IEC 9899:1999 Edits for Thread-Local Storage
+-------------------------------------------------------
+
+The following are a set of changes to ISO/IEC 9899:1999 (aka C99) that
+document the exact semantics of the language extension.
+
+   * '5.1.2 Execution environments'
+
+     Add new text after paragraph 1
+
+          Within either execution environment, a "thread" is a flow of
+          control within a program.  It is implementation defined
+          whether or not there may be more than one thread associated
+          with a program.  It is implementation defined how threads
+          beyond the first are created, the name and type of the
+          function called at thread startup, and how threads may be
+          terminated.  However, objects with thread storage duration
+          shall be initialized before thread startup.
+
+   * '6.2.4 Storage durations of objects'
+
+     Add new text before paragraph 3
+
+          An object whose identifier is declared with the storage-class
+          specifier '__thread' has "thread storage duration".  Its
+          lifetime is the entire execution of the thread, and its stored
+          value is initialized only once, prior to thread startup.
+
+   * '6.4.1 Keywords'
+
+     Add '__thread'.
+
+   * '6.7.1 Storage-class specifiers'
+
+     Add '__thread' to the list of storage class specifiers in paragraph
+     1.
+
+     Change paragraph 2 to
+
+          With the exception of '__thread', at most one storage-class
+          specifier may be given [...].  The '__thread' specifier may be
+          used alone, or immediately following 'extern' or 'static'.
+
+     Add new text after paragraph 6
+
+          The declaration of an identifier for a variable that has block
+          scope that specifies '__thread' shall also specify either
+          'extern' or 'static'.
+
+          The '__thread' specifier shall be used only with variables.
+
+
+File: gcc.info,  Node: C++98 Thread-Local Edits,  Prev: C99 Thread-Local Edits,  Up: Thread-Local
+
+6.61.2 ISO/IEC 14882:1998 Edits for Thread-Local Storage
+--------------------------------------------------------
+
+The following are a set of changes to ISO/IEC 14882:1998 (aka C++98)
+that document the exact semantics of the language extension.
+
+   * [intro.execution]
+
+     New text after paragraph 4
+
+          A "thread" is a flow of control within the abstract machine.
+          It is implementation defined whether or not there may be more
+          than one thread.
+
+     New text after paragraph 7
+
+          It is unspecified whether additional action must be taken to
+          ensure when and whether side effects are visible to other
+          threads.
+
+   * [lex.key]
+
+     Add '__thread'.
+
+   * [basic.start.main]
+
+     Add after paragraph 5
+
+          The thread that begins execution at the 'main' function is
+          called the "main thread".  It is implementation defined how
+          functions beginning threads other than the main thread are
+          designated or typed.  A function so designated, as well as the
+          'main' function, is called a "thread startup function".  It is
+          implementation defined what happens if a thread startup
+          function returns.  It is implementation defined what happens
+          to other threads when any thread calls 'exit'.
+
+   * [basic.start.init]
+
+     Add after paragraph 4
+
+          The storage for an object of thread storage duration shall be
+          statically initialized before the first statement of the
+          thread startup function.  An object of thread storage duration
+          shall not require dynamic initialization.
+
+   * [basic.start.term]
+
+     Add after paragraph 3
+
+          The type of an object with thread storage duration shall not
+          have a non-trivial destructor, nor shall it be an array type
+          whose elements (directly or indirectly) have non-trivial
+          destructors.
+
+   * [basic.stc]
+
+     Add "thread storage duration" to the list in paragraph 1.
+
+     Change paragraph 2
+
+          Thread, static, and automatic storage durations are associated
+          with objects introduced by declarations [...].
+
+     Add '__thread' to the list of specifiers in paragraph 3.
+
+   * [basic.stc.thread]
+
+     New section before [basic.stc.static]
+
+          The keyword '__thread' applied to a non-local object gives the
+          object thread storage duration.
+
+          A local variable or class data member declared both 'static'
+          and '__thread' gives the variable or member thread storage
+          duration.
+
+   * [basic.stc.static]
+
+     Change paragraph 1
+
+          All objects that have neither thread storage duration, dynamic
+          storage duration nor are local [...].
+
+   * [dcl.stc]
+
+     Add '__thread' to the list in paragraph 1.
+
+     Change paragraph 1
+
+          With the exception of '__thread', at most one
+          STORAGE-CLASS-SPECIFIER shall appear in a given
+          DECL-SPECIFIER-SEQ.  The '__thread' specifier may be used
+          alone, or immediately following the 'extern' or 'static'
+          specifiers.  [...]
+
+     Add after paragraph 5
+
+          The '__thread' specifier can be applied only to the names of
+          objects and to anonymous unions.
+
+   * [class.mem]
+
+     Add after paragraph 6
+
+          Non-'static' members shall not be '__thread'.
+
+
+File: gcc.info,  Node: Binary constants,  Prev: Thread-Local,  Up: C Extensions
+
+6.62 Binary constants using the '0b' prefix
+===========================================
+
+Integer constants can be written as binary constants, consisting of a
+sequence of '0' and '1' digits, prefixed by '0b' or '0B'.  This is
+particularly useful in environments that operate a lot on the bit level
+(like microcontrollers).
+
+ The following statements are identical:
+
+     i =       42;
+     i =     0x2a;
+     i =      052;
+     i = 0b101010;
+
+ The type of these constants follows the same rules as for octal or
+hexadecimal integer constants, so suffixes like 'L' or 'UL' can be
+applied.
+
+
+File: gcc.info,  Node: C++ Extensions,  Next: Objective-C,  Prev: C Extensions,  Up: Top
+
+7 Extensions to the C++ Language
+********************************
+
+The GNU compiler provides these extensions to the C++ language (and you
+can also use most of the C language extensions in your C++ programs).
+If you want to write code that checks whether these features are
+available, you can test for the GNU compiler the same way as for C
+programs: check for a predefined macro '__GNUC__'.  You can also use
+'__GNUG__' to test specifically for GNU C++ (*note Predefined Macros:
+(cpp)Common Predefined Macros.).
+
+* Menu:
+
+* C++ Volatiles::       What constitutes an access to a volatile object.
+* Restricted Pointers:: C99 restricted pointers and references.
+* Vague Linkage::       Where G++ puts inlines, vtables and such.
+* C++ Interface::       You can use a single C++ header file for both
+                        declarations and definitions.
+* Template Instantiation:: Methods for ensuring that exactly one copy of
+                        each needed template instantiation is emitted.
+* Bound member functions:: You can extract a function pointer to the
+                        method denoted by a '->*' or '.*' expression.
+* C++ Attributes::      Variable, function, and type attributes for C++ only.
+* Function Multiversioning::   Declaring multiple function versions.
+* Namespace Association:: Strong using-directives for namespace association.
+* Type Traits::         Compiler support for type traits
+* Java Exceptions::     Tweaking exception handling to work with Java.
+* Deprecated Features:: Things will disappear from G++.
+* Backwards Compatibility:: Compatibilities with earlier definitions of C++.
+
+
+File: gcc.info,  Node: C++ Volatiles,  Next: Restricted Pointers,  Up: C++ Extensions
+
+7.1 When is a Volatile C++ Object Accessed?
+===========================================
+
+The C++ standard differs from the C standard in its treatment of
+volatile objects.  It fails to specify what constitutes a volatile
+access, except to say that C++ should behave in a similar manner to C
+with respect to volatiles, where possible.  However, the different
+lvalueness of expressions between C and C++ complicate the behavior.
+G++ behaves the same as GCC for volatile access, *Note Volatiles: C
+Extensions, for a description of GCC's behavior.
+
+ The C and C++ language specifications differ when an object is accessed
+in a void context:
+
+     volatile int *src = SOMEVALUE;
+     *src;
+
+ The C++ standard specifies that such expressions do not undergo lvalue
+to rvalue conversion, and that the type of the dereferenced object may
+be incomplete.  The C++ standard does not specify explicitly that it is
+lvalue to rvalue conversion that is responsible for causing an access.
+There is reason to believe that it is, because otherwise certain simple
+expressions become undefined.  However, because it would surprise most
+programmers, G++ treats dereferencing a pointer to volatile object of
+complete type as GCC would do for an equivalent type in C.  When the
+object has incomplete type, G++ issues a warning; if you wish to force
+an error, you must force a conversion to rvalue with, for instance, a
+static cast.
+
+ When using a reference to volatile, G++ does not treat equivalent
+expressions as accesses to volatiles, but instead issues a warning that
+no volatile is accessed.  The rationale for this is that otherwise it
+becomes difficult to determine where volatile access occur, and not
+possible to ignore the return value from functions returning volatile
+references.  Again, if you wish to force a read, cast the reference to
+an rvalue.
+
+ G++ implements the same behavior as GCC does when assigning to a
+volatile object--there is no reread of the assigned-to object, the
+assigned rvalue is reused.  Note that in C++ assignment expressions are
+lvalues, and if used as an lvalue, the volatile object is referred to.
+For instance, VREF refers to VOBJ, as expected, in the following
+example:
+
+     volatile int vobj;
+     volatile int &vref = vobj = SOMETHING;
+
+
+File: gcc.info,  Node: Restricted Pointers,  Next: Vague Linkage,  Prev: C++ Volatiles,  Up: C++ Extensions
+
+7.2 Restricting Pointer Aliasing
+================================
+
+As with the C front end, G++ understands the C99 feature of restricted
+pointers, specified with the '__restrict__', or '__restrict' type
+qualifier.  Because you cannot compile C++ by specifying the '-std=c99'
+language flag, 'restrict' is not a keyword in C++.
+
+ In addition to allowing restricted pointers, you can specify restricted
+references, which indicate that the reference is not aliased in the
+local context.
+
+     void fn (int *__restrict__ rptr, int &__restrict__ rref)
+     {
+       /* ... */
+     }
+
+In the body of 'fn', RPTR points to an unaliased integer and RREF refers
+to a (different) unaliased integer.
+
+ You may also specify whether a member function's THIS pointer is
+unaliased by using '__restrict__' as a member function qualifier.
+
+     void T::fn () __restrict__
+     {
+       /* ... */
+     }
+
+Within the body of 'T::fn', THIS has the effective definition 'T
+*__restrict__ const this'.  Notice that the interpretation of a
+'__restrict__' member function qualifier is different to that of 'const'
+or 'volatile' qualifier, in that it is applied to the pointer rather
+than the object.  This is consistent with other compilers that implement
+restricted pointers.
+
+ As with all outermost parameter qualifiers, '__restrict__' is ignored
+in function definition matching.  This means you only need to specify
+'__restrict__' in a function definition, rather than in a function
+prototype as well.
+
+
+File: gcc.info,  Node: Vague Linkage,  Next: C++ Interface,  Prev: Restricted Pointers,  Up: C++ Extensions
+
+7.3 Vague Linkage
+=================
+
+There are several constructs in C++ that require space in the object
+file but are not clearly tied to a single translation unit.  We say that
+these constructs have "vague linkage".  Typically such constructs are
+emitted wherever they are needed, though sometimes we can be more
+clever.
+
+Inline Functions
+     Inline functions are typically defined in a header file which can
+     be included in many different compilations.  Hopefully they can
+     usually be inlined, but sometimes an out-of-line copy is necessary,
+     if the address of the function is taken or if inlining fails.  In
+     general, we emit an out-of-line copy in all translation units where
+     one is needed.  As an exception, we only emit inline virtual
+     functions with the vtable, since it always requires a copy.
+
+     Local static variables and string constants used in an inline
+     function are also considered to have vague linkage, since they must
+     be shared between all inlined and out-of-line instances of the
+     function.
+
+VTables
+     C++ virtual functions are implemented in most compilers using a
+     lookup table, known as a vtable.  The vtable contains pointers to
+     the virtual functions provided by a class, and each object of the
+     class contains a pointer to its vtable (or vtables, in some
+     multiple-inheritance situations).  If the class declares any
+     non-inline, non-pure virtual functions, the first one is chosen as
+     the "key method" for the class, and the vtable is only emitted in
+     the translation unit where the key method is defined.
+
+     _Note:_ If the chosen key method is later defined as inline, the
+     vtable is still emitted in every translation unit that defines it.
+     Make sure that any inline virtuals are declared inline in the class
+     body, even if they are not defined there.
+
+'type_info' objects
+     C++ requires information about types to be written out in order to
+     implement 'dynamic_cast', 'typeid' and exception handling.  For
+     polymorphic classes (classes with virtual functions), the
+     'type_info' object is written out along with the vtable so that
+     'dynamic_cast' can determine the dynamic type of a class object at
+     run time.  For all other types, we write out the 'type_info' object
+     when it is used: when applying 'typeid' to an expression, throwing
+     an object, or referring to a type in a catch clause or exception
+     specification.
+
+Template Instantiations
+     Most everything in this section also applies to template
+     instantiations, but there are other options as well.  *Note Where's
+     the Template?: Template Instantiation.
+
+ When used with GNU ld version 2.8 or later on an ELF system such as
+GNU/Linux or Solaris 2, or on Microsoft Windows, duplicate copies of
+these constructs will be discarded at link time.  This is known as
+COMDAT support.
+
+ On targets that don't support COMDAT, but do support weak symbols, GCC
+uses them.  This way one copy overrides all the others, but the unused
+copies still take up space in the executable.
+
+ For targets that do not support either COMDAT or weak symbols, most
+entities with vague linkage are emitted as local symbols to avoid
+duplicate definition errors from the linker.  This does not happen for
+local statics in inlines, however, as having multiple copies almost
+certainly breaks things.
+
+ *Note Declarations and Definitions in One Header: C++ Interface, for
+another way to control placement of these constructs.
+
+
+File: gcc.info,  Node: C++ Interface,  Next: Template Instantiation,  Prev: Vague Linkage,  Up: C++ Extensions
+
+7.4 #pragma interface and implementation
+========================================
+
+'#pragma interface' and '#pragma implementation' provide the user with a
+way of explicitly directing the compiler to emit entities with vague
+linkage (and debugging information) in a particular translation unit.
+
+ _Note:_ As of GCC 2.7.2, these '#pragma's are not useful in most cases,
+because of COMDAT support and the "key method" heuristic mentioned in
+*note Vague Linkage::.  Using them can actually cause your program to
+grow due to unnecessary out-of-line copies of inline functions.
+Currently (3.4) the only benefit of these '#pragma's is reduced
+duplication of debugging information, and that should be addressed soon
+on DWARF 2 targets with the use of COMDAT groups.
+
+'#pragma interface'
+'#pragma interface "SUBDIR/OBJECTS.h"'
+     Use this directive in _header files_ that define object classes, to
+     save space in most of the object files that use those classes.
+     Normally, local copies of certain information (backup copies of
+     inline member functions, debugging information, and the internal
+     tables that implement virtual functions) must be kept in each
+     object file that includes class definitions.  You can use this
+     pragma to avoid such duplication.  When a header file containing
+     '#pragma interface' is included in a compilation, this auxiliary
+     information is not generated (unless the main input source file
+     itself uses '#pragma implementation').  Instead, the object files
+     contain references to be resolved at link time.
+
+     The second form of this directive is useful for the case where you
+     have multiple headers with the same name in different directories.
+     If you use this form, you must specify the same string to '#pragma
+     implementation'.
+
+'#pragma implementation'
+'#pragma implementation "OBJECTS.h"'
+     Use this pragma in a _main input file_, when you want full output
+     from included header files to be generated (and made globally
+     visible).  The included header file, in turn, should use '#pragma
+     interface'.  Backup copies of inline member functions, debugging
+     information, and the internal tables used to implement virtual
+     functions are all generated in implementation files.
+
+     If you use '#pragma implementation' with no argument, it applies to
+     an include file with the same basename(1) as your source file.  For
+     example, in 'allclass.cc', giving just '#pragma implementation' by
+     itself is equivalent to '#pragma implementation "allclass.h"'.
+
+     In versions of GNU C++ prior to 2.6.0 'allclass.h' was treated as
+     an implementation file whenever you would include it from
+     'allclass.cc' even if you never specified '#pragma implementation'.
+     This was deemed to be more trouble than it was worth, however, and
+     disabled.
+
+     Use the string argument if you want a single implementation file to
+     include code from multiple header files.  (You must also use
+     '#include' to include the header file; '#pragma implementation'
+     only specifies how to use the file--it doesn't actually include
+     it.)
+
+     There is no way to split up the contents of a single header file
+     into multiple implementation files.
+
+ '#pragma implementation' and '#pragma interface' also have an effect on
+function inlining.
+
+ If you define a class in a header file marked with '#pragma interface',
+the effect on an inline function defined in that class is similar to an
+explicit 'extern' declaration--the compiler emits no code at all to
+define an independent version of the function.  Its definition is used
+only for inlining with its callers.
+
+ Conversely, when you include the same header file in a main source file
+that declares it as '#pragma implementation', the compiler emits code
+for the function itself; this defines a version of the function that can
+be found via pointers (or by callers compiled without inlining).  If all
+calls to the function can be inlined, you can avoid emitting the
+function by compiling with '-fno-implement-inlines'.  If any calls are
+not inlined, you will get linker errors.
+
+   ---------- Footnotes ----------
+
+   (1) A file's "basename" is the name stripped of all leading path
+information and of trailing suffixes, such as '.h' or '.C' or '.cc'.
+
+
+File: gcc.info,  Node: Template Instantiation,  Next: Bound member functions,  Prev: C++ Interface,  Up: C++ Extensions
+
+7.5 Where's the Template?
+=========================
+
+C++ templates are the first language feature to require more
+intelligence from the environment than one usually finds on a UNIX
+system.  Somehow the compiler and linker have to make sure that each
+template instance occurs exactly once in the executable if it is needed,
+and not at all otherwise.  There are two basic approaches to this
+problem, which are referred to as the Borland model and the Cfront
+model.
+
+Borland model
+     Borland C++ solved the template instantiation problem by adding the
+     code equivalent of common blocks to their linker; the compiler
+     emits template instances in each translation unit that uses them,
+     and the linker collapses them together.  The advantage of this
+     model is that the linker only has to consider the object files
+     themselves; there is no external complexity to worry about.  This
+     disadvantage is that compilation time is increased because the
+     template code is being compiled repeatedly.  Code written for this
+     model tends to include definitions of all templates in the header
+     file, since they must be seen to be instantiated.
+
+Cfront model
+     The AT&T C++ translator, Cfront, solved the template instantiation
+     problem by creating the notion of a template repository, an
+     automatically maintained place where template instances are stored.
+     A more modern version of the repository works as follows: As
+     individual object files are built, the compiler places any template
+     definitions and instantiations encountered in the repository.  At
+     link time, the link wrapper adds in the objects in the repository
+     and compiles any needed instances that were not previously emitted.
+     The advantages of this model are more optimal compilation speed and
+     the ability to use the system linker; to implement the Borland
+     model a compiler vendor also needs to replace the linker.  The
+     disadvantages are vastly increased complexity, and thus potential
+     for error; for some code this can be just as transparent, but in
+     practice it can been very difficult to build multiple programs in
+     one directory and one program in multiple directories.  Code
+     written for this model tends to separate definitions of non-inline
+     member templates into a separate file, which should be compiled
+     separately.
+
+ When used with GNU ld version 2.8 or later on an ELF system such as
+GNU/Linux or Solaris 2, or on Microsoft Windows, G++ supports the
+Borland model.  On other systems, G++ implements neither automatic
+model.
+
+ You have the following options for dealing with template
+instantiations:
+
+  1. Compile your template-using code with '-frepo'.  The compiler
+     generates files with the extension '.rpo' listing all of the
+     template instantiations used in the corresponding object files that
+     could be instantiated there; the link wrapper, 'collect2', then
+     updates the '.rpo' files to tell the compiler where to place those
+     instantiations and rebuild any affected object files.  The
+     link-time overhead is negligible after the first pass, as the
+     compiler continues to place the instantiations in the same files.
+
+     This is your best option for application code written for the
+     Borland model, as it just works.  Code written for the Cfront model
+     needs to be modified so that the template definitions are available
+     at one or more points of instantiation; usually this is as simple
+     as adding '#include <tmethods.cc>' to the end of each template
+     header.
+
+     For library code, if you want the library to provide all of the
+     template instantiations it needs, just try to link all of its
+     object files together; the link will fail, but cause the
+     instantiations to be generated as a side effect.  Be warned,
+     however, that this may cause conflicts if multiple libraries try to
+     provide the same instantiations.  For greater control, use explicit
+     instantiation as described in the next option.
+
+  2. Compile your code with '-fno-implicit-templates' to disable the
+     implicit generation of template instances, and explicitly
+     instantiate all the ones you use.  This approach requires more
+     knowledge of exactly which instances you need than do the others,
+     but it's less mysterious and allows greater control.  You can
+     scatter the explicit instantiations throughout your program,
+     perhaps putting them in the translation units where the instances
+     are used or the translation units that define the templates
+     themselves; you can put all of the explicit instantiations you need
+     into one big file; or you can create small files like
+
+          #include "Foo.h"
+          #include "Foo.cc"
+
+          template class Foo<int>;
+          template ostream& operator <<
+                          (ostream&, const Foo<int>&);
+
+     for each of the instances you need, and create a template
+     instantiation library from those.
+
+     If you are using Cfront-model code, you can probably get away with
+     not using '-fno-implicit-templates' when compiling files that don't
+     '#include' the member template definitions.
+
+     If you use one big file to do the instantiations, you may want to
+     compile it without '-fno-implicit-templates' so you get all of the
+     instances required by your explicit instantiations (but not by any
+     other files) without having to specify them as well.
+
+     The ISO C++ 2011 standard allows forward declaration of explicit
+     instantiations (with 'extern').  G++ supports explicit
+     instantiation declarations in C++98 mode and has extended the
+     template instantiation syntax to support instantiation of the
+     compiler support data for a template class (i.e. the vtable)
+     without instantiating any of its members (with 'inline'), and
+     instantiation of only the static data members of a template class,
+     without the support data or member functions (with ('static'):
+
+          extern template int max (int, int);
+          inline template class Foo<int>;
+          static template class Foo<int>;
+
+  3. Do nothing.  Pretend G++ does implement automatic instantiation
+     management.  Code written for the Borland model works fine, but
+     each translation unit contains instances of each of the templates
+     it uses.  In a large program, this can lead to an unacceptable
+     amount of code duplication.
+
+
+File: gcc.info,  Node: Bound member functions,  Next: C++ Attributes,  Prev: Template Instantiation,  Up: C++ Extensions
+
+7.6 Extracting the function pointer from a bound pointer to member function
+===========================================================================
+
+In C++, pointer to member functions (PMFs) are implemented using a wide
+pointer of sorts to handle all the possible call mechanisms; the PMF
+needs to store information about how to adjust the 'this' pointer, and
+if the function pointed to is virtual, where to find the vtable, and
+where in the vtable to look for the member function.  If you are using
+PMFs in an inner loop, you should really reconsider that decision.  If
+that is not an option, you can extract the pointer to the function that
+would be called for a given object/PMF pair and call it directly inside
+the inner loop, to save a bit of time.
+
+ Note that you still pay the penalty for the call through a function
+pointer; on most modern architectures, such a call defeats the branch
+prediction features of the CPU.  This is also true of normal virtual
+function calls.
+
+ The syntax for this extension is
+
+     extern A a;
+     extern int (A::*fp)();
+     typedef int (*fptr)(A *);
+
+     fptr p = (fptr)(a.*fp);
+
+ For PMF constants (i.e. expressions of the form '&Klasse::Member'), no
+object is needed to obtain the address of the function.  They can be
+converted to function pointers directly:
+
+     fptr p1 = (fptr)(&A::foo);
+
+ You must specify '-Wno-pmf-conversions' to use this extension.
+
+
+File: gcc.info,  Node: C++ Attributes,  Next: Function Multiversioning,  Prev: Bound member functions,  Up: C++ Extensions
+
+7.7 C++-Specific Variable, Function, and Type Attributes
+========================================================
+
+Some attributes only make sense for C++ programs.
+
+'abi_tag ("TAG", ...)'
+     The 'abi_tag' attribute can be applied to a function or class
+     declaration.  It modifies the mangled name of the function or class
+     to incorporate the tag name, in order to distinguish the function
+     or class from an earlier version with a different ABI; perhaps the
+     class has changed size, or the function has a different return type
+     that is not encoded in the mangled name.
+
+     The argument can be a list of strings of arbitrary length.  The
+     strings are sorted on output, so the order of the list is
+     unimportant.
+
+     A redeclaration of a function or class must not add new ABI tags,
+     since doing so would change the mangled name.
+
+     The ABI tags apply to a name, so all instantiations and
+     specializations of a template have the same tags.  The attribute
+     will be ignored if applied to an explicit specialization or
+     instantiation.
+
+     The '-Wabi-tag' flag enables a warning about a class which does not
+     have all the ABI tags used by its subobjects and virtual functions;
+     for users with code that needs to coexist with an earlier ABI,
+     using this option can help to find all affected types that need to
+     be tagged.
+
+'init_priority (PRIORITY)'
+
+     In Standard C++, objects defined at namespace scope are guaranteed
+     to be initialized in an order in strict accordance with that of
+     their definitions _in a given translation unit_.  No guarantee is
+     made for initializations across translation units.  However, GNU
+     C++ allows users to control the order of initialization of objects
+     defined at namespace scope with the 'init_priority' attribute by
+     specifying a relative PRIORITY, a constant integral expression
+     currently bounded between 101 and 65535 inclusive.  Lower numbers
+     indicate a higher priority.
+
+     In the following example, 'A' would normally be created before 'B',
+     but the 'init_priority' attribute reverses that order:
+
+          Some_Class  A  __attribute__ ((init_priority (2000)));
+          Some_Class  B  __attribute__ ((init_priority (543)));
+
+     Note that the particular values of PRIORITY do not matter; only
+     their relative ordering.
+
+'java_interface'
+
+     This type attribute informs C++ that the class is a Java interface.
+     It may only be applied to classes declared within an 'extern
+     "Java"' block.  Calls to methods declared in this interface are
+     dispatched using GCJ's interface table mechanism, instead of
+     regular virtual table dispatch.
+
+'warn_unused'
+
+     For C++ types with non-trivial constructors and/or destructors it
+     is impossible for the compiler to determine whether a variable of
+     this type is truly unused if it is not referenced.  This type
+     attribute informs the compiler that variables of this type should
+     be warned about if they appear to be unused, just like variables of
+     fundamental types.
+
+     This attribute is appropriate for types which just represent a
+     value, such as 'std::string'; it is not appropriate for types which
+     control a resource, such as 'std::mutex'.
+
+     This attribute is also accepted in C, but it is unnecessary because
+     C does not have constructors or destructors.
+
+ See also *note Namespace Association::.
+
+
+File: gcc.info,  Node: Function Multiversioning,  Next: Namespace Association,  Prev: C++ Attributes,  Up: C++ Extensions
+
+7.8 Function Multiversioning
+============================
+
+With the GNU C++ front end, for target i386, you may specify multiple
+versions of a function, where each function is specialized for a
+specific target feature.  At runtime, the appropriate version of the
+function is automatically executed depending on the characteristics of
+the execution platform.  Here is an example.
+
+     __attribute__ ((target ("default")))
+     int foo ()
+     {
+       // The default version of foo.
+       return 0;
+     }
+
+     __attribute__ ((target ("sse4.2")))
+     int foo ()
+     {
+       // foo version for SSE4.2
+       return 1;
+     }
+
+     __attribute__ ((target ("arch=atom")))
+     int foo ()
+     {
+       // foo version for the Intel ATOM processor
+       return 2;
+     }
+
+     __attribute__ ((target ("arch=amdfam10")))
+     int foo ()
+     {
+       // foo version for the AMD Family 0x10 processors.
+       return 3;
+     }
+
+     int main ()
+     {
+       int (*p)() = &foo;
+       assert ((*p) () == foo ());
+       return 0;
+     }
+
+ In the above example, four versions of function foo are created.  The
+first version of foo with the target attribute "default" is the default
+version.  This version gets executed when no other target specific
+version qualifies for execution on a particular platform.  A new version
+of foo is created by using the same function signature but with a
+different target string.  Function foo is called or a pointer to it is
+taken just like a regular function.  GCC takes care of doing the
+dispatching to call the right version at runtime.  Refer to the GCC wiki
+on Function Multiversioning
+(http://gcc.gnu.org/wiki/FunctionMultiVersioning) for more details.
+
+
+File: gcc.info,  Node: Namespace Association,  Next: Type Traits,  Prev: Function Multiversioning,  Up: C++ Extensions
+
+7.9 Namespace Association
+=========================
+
+*Caution:* The semantics of this extension are equivalent to C++ 2011
+inline namespaces.  Users should use inline namespaces instead as this
+extension will be removed in future versions of G++.
+
+ A using-directive with '__attribute ((strong))' is stronger than a
+normal using-directive in two ways:
+
+   * Templates from the used namespace can be specialized and explicitly
+     instantiated as though they were members of the using namespace.
+
+   * The using namespace is considered an associated namespace of all
+     templates in the used namespace for purposes of argument-dependent
+     name lookup.
+
+ The used namespace must be nested within the using namespace so that
+normal unqualified lookup works properly.
+
+ This is useful for composing a namespace transparently from
+implementation namespaces.  For example:
+
+     namespace std {
+       namespace debug {
+         template <class T> struct A { };
+       }
+       using namespace debug __attribute ((__strong__));
+       template <> struct A<int> { };   // OK to specialize
+
+       template <class T> void f (A<T>);
+     }
+
+     int main()
+     {
+       f (std::A<float>());             // lookup finds std::f
+       f (std::A<int>());
+     }
+
+
+File: gcc.info,  Node: Type Traits,  Next: Java Exceptions,  Prev: Namespace Association,  Up: C++ Extensions
+
+7.10 Type Traits
+================
+
+The C++ front end implements syntactic extensions that allow
+compile-time determination of various characteristics of a type (or of a
+pair of types).
+
+'__has_nothrow_assign (type)'
+     If 'type' is const qualified or is a reference type then the trait
+     is false.  Otherwise if '__has_trivial_assign (type)' is true then
+     the trait is true, else if 'type' is a cv class or union type with
+     copy assignment operators that are known not to throw an exception
+     then the trait is true, else it is false.  Requires: 'type' shall
+     be a complete type, (possibly cv-qualified) 'void', or an array of
+     unknown bound.
+
+'__has_nothrow_copy (type)'
+     If '__has_trivial_copy (type)' is true then the trait is true, else
+     if 'type' is a cv class or union type with copy constructors that
+     are known not to throw an exception then the trait is true, else it
+     is false.  Requires: 'type' shall be a complete type, (possibly
+     cv-qualified) 'void', or an array of unknown bound.
+
+'__has_nothrow_constructor (type)'
+     If '__has_trivial_constructor (type)' is true then the trait is
+     true, else if 'type' is a cv class or union type (or array thereof)
+     with a default constructor that is known not to throw an exception
+     then the trait is true, else it is false.  Requires: 'type' shall
+     be a complete type, (possibly cv-qualified) 'void', or an array of
+     unknown bound.
+
+'__has_trivial_assign (type)'
+     If 'type' is const qualified or is a reference type then the trait
+     is false.  Otherwise if '__is_pod (type)' is true then the trait is
+     true, else if 'type' is a cv class or union type with a trivial
+     copy assignment ([class.copy]) then the trait is true, else it is
+     false.  Requires: 'type' shall be a complete type, (possibly
+     cv-qualified) 'void', or an array of unknown bound.
+
+'__has_trivial_copy (type)'
+     If '__is_pod (type)' is true or 'type' is a reference type then the
+     trait is true, else if 'type' is a cv class or union type with a
+     trivial copy constructor ([class.copy]) then the trait is true,
+     else it is false.  Requires: 'type' shall be a complete type,
+     (possibly cv-qualified) 'void', or an array of unknown bound.
+
+'__has_trivial_constructor (type)'
+     If '__is_pod (type)' is true then the trait is true, else if 'type'
+     is a cv class or union type (or array thereof) with a trivial
+     default constructor ([class.ctor]) then the trait is true, else it
+     is false.  Requires: 'type' shall be a complete type, (possibly
+     cv-qualified) 'void', or an array of unknown bound.
+
+'__has_trivial_destructor (type)'
+     If '__is_pod (type)' is true or 'type' is a reference type then the
+     trait is true, else if 'type' is a cv class or union type (or array
+     thereof) with a trivial destructor ([class.dtor]) then the trait is
+     true, else it is false.  Requires: 'type' shall be a complete type,
+     (possibly cv-qualified) 'void', or an array of unknown bound.
+
+'__has_virtual_destructor (type)'
+     If 'type' is a class type with a virtual destructor ([class.dtor])
+     then the trait is true, else it is false.  Requires: 'type' shall
+     be a complete type, (possibly cv-qualified) 'void', or an array of
+     unknown bound.
+
+'__is_abstract (type)'
+     If 'type' is an abstract class ([class.abstract]) then the trait is
+     true, else it is false.  Requires: 'type' shall be a complete type,
+     (possibly cv-qualified) 'void', or an array of unknown bound.
+
+'__is_base_of (base_type, derived_type)'
+     If 'base_type' is a base class of 'derived_type' ([class.derived])
+     then the trait is true, otherwise it is false.  Top-level cv
+     qualifications of 'base_type' and 'derived_type' are ignored.  For
+     the purposes of this trait, a class type is considered is own base.
+     Requires: if '__is_class (base_type)' and '__is_class
+     (derived_type)' are true and 'base_type' and 'derived_type' are not
+     the same type (disregarding cv-qualifiers), 'derived_type' shall be
+     a complete type.  Diagnostic is produced if this requirement is not
+     met.
+
+'__is_class (type)'
+     If 'type' is a cv class type, and not a union type
+     ([basic.compound]) the trait is true, else it is false.
+
+'__is_empty (type)'
+     If '__is_class (type)' is false then the trait is false.  Otherwise
+     'type' is considered empty if and only if: 'type' has no non-static
+     data members, or all non-static data members, if any, are
+     bit-fields of length 0, and 'type' has no virtual members, and
+     'type' has no virtual base classes, and 'type' has no base classes
+     'base_type' for which '__is_empty (base_type)' is false.  Requires:
+     'type' shall be a complete type, (possibly cv-qualified) 'void', or
+     an array of unknown bound.
+
+'__is_enum (type)'
+     If 'type' is a cv enumeration type ([basic.compound]) the trait is
+     true, else it is false.
+
+'__is_literal_type (type)'
+     If 'type' is a literal type ([basic.types]) the trait is true, else
+     it is false.  Requires: 'type' shall be a complete type, (possibly
+     cv-qualified) 'void', or an array of unknown bound.
+
+'__is_pod (type)'
+     If 'type' is a cv POD type ([basic.types]) then the trait is true,
+     else it is false.  Requires: 'type' shall be a complete type,
+     (possibly cv-qualified) 'void', or an array of unknown bound.
+
+'__is_polymorphic (type)'
+     If 'type' is a polymorphic class ([class.virtual]) then the trait
+     is true, else it is false.  Requires: 'type' shall be a complete
+     type, (possibly cv-qualified) 'void', or an array of unknown bound.
+
+'__is_standard_layout (type)'
+     If 'type' is a standard-layout type ([basic.types]) the trait is
+     true, else it is false.  Requires: 'type' shall be a complete type,
+     (possibly cv-qualified) 'void', or an array of unknown bound.
+
+'__is_trivial (type)'
+     If 'type' is a trivial type ([basic.types]) the trait is true, else
+     it is false.  Requires: 'type' shall be a complete type, (possibly
+     cv-qualified) 'void', or an array of unknown bound.
+
+'__is_union (type)'
+     If 'type' is a cv union type ([basic.compound]) the trait is true,
+     else it is false.
+
+'__underlying_type (type)'
+     The underlying type of 'type'.  Requires: 'type' shall be an
+     enumeration type ([dcl.enum]).
+
+
+File: gcc.info,  Node: Java Exceptions,  Next: Deprecated Features,  Prev: Type Traits,  Up: C++ Extensions
+
+7.11 Java Exceptions
+====================
+
+The Java language uses a slightly different exception handling model
+from C++.  Normally, GNU C++ automatically detects when you are writing
+C++ code that uses Java exceptions, and handle them appropriately.
+However, if C++ code only needs to execute destructors when Java
+exceptions are thrown through it, GCC guesses incorrectly.  Sample
+problematic code is:
+
+       struct S { ~S(); };
+       extern void bar();    // is written in Java, and may throw exceptions
+       void foo()
+       {
+         S s;
+         bar();
+       }
+
+The usual effect of an incorrect guess is a link failure, complaining of
+a missing routine called '__gxx_personality_v0'.
+
+ You can inform the compiler that Java exceptions are to be used in a
+translation unit, irrespective of what it might think, by writing
+'#pragma GCC java_exceptions' at the head of the file.  This '#pragma'
+must appear before any functions that throw or catch exceptions, or run
+destructors when exceptions are thrown through them.
+
+ You cannot mix Java and C++ exceptions in the same translation unit.
+It is believed to be safe to throw a C++ exception from one file through
+another file compiled for the Java exception model, or vice versa, but
+there may be bugs in this area.
+
+
+File: gcc.info,  Node: Deprecated Features,  Next: Backwards Compatibility,  Prev: Java Exceptions,  Up: C++ Extensions
+
+7.12 Deprecated Features
+========================
+
+In the past, the GNU C++ compiler was extended to experiment with new
+features, at a time when the C++ language was still evolving.  Now that
+the C++ standard is complete, some of those features are superseded by
+superior alternatives.  Using the old features might cause a warning in
+some cases that the feature will be dropped in the future.  In other
+cases, the feature might be gone already.
+
+ While the list below is not exhaustive, it documents some of the
+options that are now deprecated:
+
+'-fexternal-templates'
+'-falt-external-templates'
+     These are two of the many ways for G++ to implement template
+     instantiation.  *Note Template Instantiation::.  The C++ standard
+     clearly defines how template definitions have to be organized
+     across implementation units.  G++ has an implicit instantiation
+     mechanism that should work just fine for standard-conforming code.
+
+'-fstrict-prototype'
+'-fno-strict-prototype'
+     Previously it was possible to use an empty prototype parameter list
+     to indicate an unspecified number of parameters (like C), rather
+     than no parameters, as C++ demands.  This feature has been removed,
+     except where it is required for backwards compatibility.  *Note
+     Backwards Compatibility::.
+
+ G++ allows a virtual function returning 'void *' to be overridden by
+one returning a different pointer type.  This extension to the covariant
+return type rules is now deprecated and will be removed from a future
+version.
+
+ The G++ minimum and maximum operators ('<?' and '>?') and their
+compound forms ('<?=') and '>?=') have been deprecated and are now
+removed from G++.  Code using these operators should be modified to use
+'std::min' and 'std::max' instead.
+
+ The named return value extension has been deprecated, and is now
+removed from G++.
+
+ The use of initializer lists with new expressions has been deprecated,
+and is now removed from G++.
+
+ Floating and complex non-type template parameters have been deprecated,
+and are now removed from G++.
+
+ The implicit typename extension has been deprecated and is now removed
+from G++.
+
+ The use of default arguments in function pointers, function typedefs
+and other places where they are not permitted by the standard is
+deprecated and will be removed from a future version of G++.
+
+ G++ allows floating-point literals to appear in integral constant
+expressions, e.g. ' enum E { e = int(2.2 * 3.7) } ' This extension is
+deprecated and will be removed from a future version.
+
+ G++ allows static data members of const floating-point type to be
+declared with an initializer in a class definition.  The standard only
+allows initializers for static members of const integral types and const
+enumeration types so this extension has been deprecated and will be
+removed from a future version.
+
+
+File: gcc.info,  Node: Backwards Compatibility,  Prev: Deprecated Features,  Up: C++ Extensions
+
+7.13 Backwards Compatibility
+============================
+
+Now that there is a definitive ISO standard C++, G++ has a specification
+to adhere to.  The C++ language evolved over time, and features that
+used to be acceptable in previous drafts of the standard, such as the
+ARM [Annotated C++ Reference Manual], are no longer accepted.  In order
+to allow compilation of C++ written to such drafts, G++ contains some
+backwards compatibilities.  _All such backwards compatibility features
+are liable to disappear in future versions of G++._  They should be
+considered deprecated.  *Note Deprecated Features::.
+
+'For scope'
+     If a variable is declared at for scope, it used to remain in scope
+     until the end of the scope that contained the for statement (rather
+     than just within the for scope).  G++ retains this, but issues a
+     warning, if such a variable is accessed outside the for scope.
+
+'Implicit C language'
+     Old C system header files did not contain an 'extern "C" {...}'
+     scope to set the language.  On such systems, all header files are
+     implicitly scoped inside a C language scope.  Also, an empty
+     prototype '()' is treated as an unspecified number of arguments,
+     rather than no arguments, as C++ demands.
+
+
+File: gcc.info,  Node: Objective-C,  Next: Compatibility,  Prev: C++ Extensions,  Up: Top
+
+8 GNU Objective-C features
+**************************
+
+This document is meant to describe some of the GNU Objective-C features.
+It is not intended to teach you Objective-C. There are several resources
+on the Internet that present the language.
+
+* Menu:
+
+* GNU Objective-C runtime API::
+* Executing code before main::
+* Type encoding::
+* Garbage Collection::
+* Constant string objects::
+* compatibility_alias::
+* Exceptions::
+* Synchronization::
+* Fast enumeration::
+* Messaging with the GNU Objective-C runtime::
+
+
+File: gcc.info,  Node: GNU Objective-C runtime API,  Next: Executing code before main,  Up: Objective-C
+
+8.1 GNU Objective-C runtime API
+===============================
+
+This section is specific for the GNU Objective-C runtime.  If you are
+using a different runtime, you can skip it.
+
+ The GNU Objective-C runtime provides an API that allows you to interact
+with the Objective-C runtime system, querying the live runtime
+structures and even manipulating them.  This allows you for example to
+inspect and navigate classes, methods and protocols; to define new
+classes or new methods, and even to modify existing classes or
+protocols.
+
+ If you are using a "Foundation" library such as GNUstep-Base, this
+library will provide you with a rich set of functionality to do most of
+the inspection tasks, and you probably will only need direct access to
+the GNU Objective-C runtime API to define new classes or methods.
+
+* Menu:
+
+* Modern GNU Objective-C runtime API::
+* Traditional GNU Objective-C runtime API::
+
+
+File: gcc.info,  Node: Modern GNU Objective-C runtime API,  Next: Traditional GNU Objective-C runtime API,  Up: GNU Objective-C runtime API
+
+8.1.1 Modern GNU Objective-C runtime API
+----------------------------------------
+
+The GNU Objective-C runtime provides an API which is similar to the one
+provided by the "Objective-C 2.0" Apple/NeXT Objective-C runtime.  The
+API is documented in the public header files of the GNU Objective-C
+runtime:
+
+   * 'objc/objc.h': this is the basic Objective-C header file, defining
+     the basic Objective-C types such as 'id', 'Class' and 'BOOL'.  You
+     have to include this header to do almost anything with Objective-C.
+
+   * 'objc/runtime.h': this header declares most of the public runtime
+     API functions allowing you to inspect and manipulate the
+     Objective-C runtime data structures.  These functions are fairly
+     standardized across Objective-C runtimes and are almost identical
+     to the Apple/NeXT Objective-C runtime ones.  It does not declare
+     functions in some specialized areas (constructing and forwarding
+     message invocations, threading) which are in the other headers
+     below.  You have to include 'objc/objc.h' and 'objc/runtime.h' to
+     use any of the functions, such as 'class_getName()', declared in
+     'objc/runtime.h'.
+
+   * 'objc/message.h': this header declares public functions used to
+     construct, deconstruct and forward message invocations.  Because
+     messaging is done in quite a different way on different runtimes,
+     functions in this header are specific to the GNU Objective-C
+     runtime implementation.
+
+   * 'objc/objc-exception.h': this header declares some public functions
+     related to Objective-C exceptions.  For example functions in this
+     header allow you to throw an Objective-C exception from plain C/C++
+     code.
+
+   * 'objc/objc-sync.h': this header declares some public functions
+     related to the Objective-C '@synchronized()' syntax, allowing you
+     to emulate an Objective-C '@synchronized()' block in plain C/C++
+     code.
+
+   * 'objc/thr.h': this header declares a public runtime API threading
+     layer that is only provided by the GNU Objective-C runtime.  It
+     declares functions such as 'objc_mutex_lock()', which provide a
+     platform-independent set of threading functions.
+
+ The header files contain detailed documentation for each function in
+the GNU Objective-C runtime API.
+
+
+File: gcc.info,  Node: Traditional GNU Objective-C runtime API,  Prev: Modern GNU Objective-C runtime API,  Up: GNU Objective-C runtime API
+
+8.1.2 Traditional GNU Objective-C runtime API
+---------------------------------------------
+
+The GNU Objective-C runtime used to provide a different API, which we
+call the "traditional" GNU Objective-C runtime API. Functions belonging
+to this API are easy to recognize because they use a different naming
+convention, such as 'class_get_super_class()' (traditional API) instead
+of 'class_getSuperclass()' (modern API). Software using this API
+includes the file 'objc/objc-api.h' where it is declared.
+
+ Starting with GCC 4.7.0, the traditional GNU runtime API is no longer
+available.
+
+
+File: gcc.info,  Node: Executing code before main,  Next: Type encoding,  Prev: GNU Objective-C runtime API,  Up: Objective-C
+
+8.2 '+load': Executing code before main
+=======================================
+
+This section is specific for the GNU Objective-C runtime.  If you are
+using a different runtime, you can skip it.
+
+ The GNU Objective-C runtime provides a way that allows you to execute
+code before the execution of the program enters the 'main' function.
+The code is executed on a per-class and a per-category basis, through a
+special class method '+load'.
+
+ This facility is very useful if you want to initialize global variables
+which can be accessed by the program directly, without sending a message
+to the class first.  The usual way to initialize global variables, in
+the '+initialize' method, might not be useful because '+initialize' is
+only called when the first message is sent to a class object, which in
+some cases could be too late.
+
+ Suppose for example you have a 'FileStream' class that declares
+'Stdin', 'Stdout' and 'Stderr' as global variables, like below:
+
+
+     FileStream *Stdin = nil;
+     FileStream *Stdout = nil;
+     FileStream *Stderr = nil;
+
+     @implementation FileStream
+
+     + (void)initialize
+     {
+         Stdin = [[FileStream new] initWithFd:0];
+         Stdout = [[FileStream new] initWithFd:1];
+         Stderr = [[FileStream new] initWithFd:2];
+     }
+
+     /* Other methods here */
+     @end
+
+ In this example, the initialization of 'Stdin', 'Stdout' and 'Stderr'
+in '+initialize' occurs too late.  The programmer can send a message to
+one of these objects before the variables are actually initialized, thus
+sending messages to the 'nil' object.  The '+initialize' method which
+actually initializes the global variables is not invoked until the first
+message is sent to the class object.  The solution would require these
+variables to be initialized just before entering 'main'.
+
+ The correct solution of the above problem is to use the '+load' method
+instead of '+initialize':
+
+
+     @implementation FileStream
+
+     + (void)load
+     {
+         Stdin = [[FileStream new] initWithFd:0];
+         Stdout = [[FileStream new] initWithFd:1];
+         Stderr = [[FileStream new] initWithFd:2];
+     }
+
+     /* Other methods here */
+     @end
+
+ The '+load' is a method that is not overridden by categories.  If a
+class and a category of it both implement '+load', both methods are
+invoked.  This allows some additional initializations to be performed in
+a category.
+
+ This mechanism is not intended to be a replacement for '+initialize'.
+You should be aware of its limitations when you decide to use it instead
+of '+initialize'.
+
+* Menu:
+
+* What you can and what you cannot do in +load::
+
+
+File: gcc.info,  Node: What you can and what you cannot do in +load,  Up: Executing code before main
+
+8.2.1 What you can and what you cannot do in '+load'
+----------------------------------------------------
+
+'+load' is to be used only as a last resort.  Because it is executed
+very early, most of the Objective-C runtime machinery will not be ready
+when '+load' is executed; hence '+load' works best for executing C code
+that is independent on the Objective-C runtime.
+
+ The '+load' implementation in the GNU runtime guarantees you the
+following things:
+
+   * you can write whatever C code you like;
+
+   * you can allocate and send messages to objects whose class is
+     implemented in the same file;
+
+   * the '+load' implementation of all super classes of a class are
+     executed before the '+load' of that class is executed;
+
+   * the '+load' implementation of a class is executed before the
+     '+load' implementation of any category.
+
+ In particular, the following things, even if they can work in a
+particular case, are not guaranteed:
+
+   * allocation of or sending messages to arbitrary objects;
+
+   * allocation of or sending messages to objects whose classes have a
+     category implemented in the same file;
+
+   * sending messages to Objective-C constant strings ('@"this is a
+     constant string"');
+
+ You should make no assumptions about receiving '+load' in sibling
+classes when you write '+load' of a class.  The order in which sibling
+classes receive '+load' is not guaranteed.
+
+ The order in which '+load' and '+initialize' are called could be
+problematic if this matters.  If you don't allocate objects inside
+'+load', it is guaranteed that '+load' is called before '+initialize'.
+If you create an object inside '+load' the '+initialize' method of
+object's class is invoked even if '+load' was not invoked.  Note if you
+explicitly call '+load' on a class, '+initialize' will be called first.
+To avoid possible problems try to implement only one of these methods.
+
+ The '+load' method is also invoked when a bundle is dynamically loaded
+into your running program.  This happens automatically without any
+intervening operation from you.  When you write bundles and you need to
+write '+load' you can safely create and send messages to objects whose
+classes already exist in the running program.  The same restrictions as
+above apply to classes defined in bundle.
+
+
+File: gcc.info,  Node: Type encoding,  Next: Garbage Collection,  Prev: Executing code before main,  Up: Objective-C
+
+8.3 Type encoding
+=================
+
+This is an advanced section.  Type encodings are used extensively by the
+compiler and by the runtime, but you generally do not need to know about
+them to use Objective-C.
+
+ The Objective-C compiler generates type encodings for all the types.
+These type encodings are used at runtime to find out information about
+selectors and methods and about objects and classes.
+
+ The types are encoded in the following way:
+
+'_Bool'            'B'
+'char'             'c'
+'unsigned char'    'C'
+'short'            's'
+'unsigned short'   'S'
+'int'              'i'
+'unsigned int'     'I'
+'long'             'l'
+'unsigned long'    'L'
+'long long'        'q'
+'unsigned long     'Q'
+long'
+'float'            'f'
+'double'           'd'
+'long double'      'D'
+'void'             'v'
+'id'               '@'
+'Class'            '#'
+'SEL'              ':'
+'char*'            '*'
+'enum'             an 'enum' is encoded exactly as the integer type
+                   that the compiler uses for it, which depends on the
+                   enumeration values.  Often the compiler users
+                   'unsigned int', which is then encoded as 'I'.
+unknown type       '?'
+Complex types      'j' followed by the inner type.  For example
+                   '_Complex double' is encoded as "jd".
+bit-fields         'b' followed by the starting position of the
+                   bit-field, the type of the bit-field and the size of
+                   the bit-field (the bit-fields encoding was changed
+                   from the NeXT's compiler encoding, see below)
+
+ The encoding of bit-fields has changed to allow bit-fields to be
+properly handled by the runtime functions that compute sizes and
+alignments of types that contain bit-fields.  The previous encoding
+contained only the size of the bit-field.  Using only this information
+it is not possible to reliably compute the size occupied by the
+bit-field.  This is very important in the presence of the Boehm's
+garbage collector because the objects are allocated using the typed
+memory facility available in this collector.  The typed memory
+allocation requires information about where the pointers are located
+inside the object.
+
+ The position in the bit-field is the position, counting in bits, of the
+bit closest to the beginning of the structure.
+
+ The non-atomic types are encoded as follows:
+
+pointers       '^' followed by the pointed type.
+arrays         '[' followed by the number of elements in the array
+               followed by the type of the elements followed by ']'
+structures     '{' followed by the name of the structure (or '?' if the
+               structure is unnamed), the '=' sign, the type of the
+               members and by '}'
+unions         '(' followed by the name of the structure (or '?' if the
+               union is unnamed), the '=' sign, the type of the members
+               followed by ')'
+vectors        '![' followed by the vector_size (the number of bytes
+               composing the vector) followed by a comma, followed by
+               the alignment (in bytes) of the vector, followed by the
+               type of the elements followed by ']'
+
+ Here are some types and their encodings, as they are generated by the
+compiler on an i386 machine:
+
+
+Objective-C type   Compiler encoding
+     int a[10];    '[10i]'
+     struct {      '{?=i[3f]b128i3b131i2c}'
+       int i;
+       float f[3];
+       int a:3;
+       int b:2;
+       char c;
+     }
+     int a __attribute__ ((vector_size (16)));'![16,16i]' (alignment would depend on the machine)
+
+
+ In addition to the types the compiler also encodes the type specifiers.
+The table below describes the encoding of the current Objective-C type
+specifiers:
+
+
+Specifier          Encoding
+'const'            'r'
+'in'               'n'
+'inout'            'N'
+'out'              'o'
+'bycopy'           'O'
+'byref'            'R'
+'oneway'           'V'
+
+
+ The type specifiers are encoded just before the type.  Unlike types
+however, the type specifiers are only encoded when they appear in method
+argument types.
+
+ Note how 'const' interacts with pointers:
+
+
+Objective-C type   Compiler encoding
+     const int     'ri'
+     const int*    '^ri'
+     int *const    'r^i'
+
+
+ 'const int*' is a pointer to a 'const int', and so is encoded as '^ri'.
+'int* const', instead, is a 'const' pointer to an 'int', and so is
+encoded as 'r^i'.
+
+ Finally, there is a complication when encoding 'const char *' versus
+'char * const'.  Because 'char *' is encoded as '*' and not as '^c',
+there is no way to express the fact that 'r' applies to the pointer or
+to the pointee.
+
+ Hence, it is assumed as a convention that 'r*' means 'const char *'
+(since it is what is most often meant), and there is no way to encode
+'char *const'.  'char *const' would simply be encoded as '*', and the
+'const' is lost.
+
+* Menu:
+
+* Legacy type encoding::
+* @encode::
+* Method signatures::
+
+
+File: gcc.info,  Node: Legacy type encoding,  Next: @encode,  Up: Type encoding
+
+8.3.1 Legacy type encoding
+--------------------------
+
+Unfortunately, historically GCC used to have a number of bugs in its
+encoding code.  The NeXT runtime expects GCC to emit type encodings in
+this historical format (compatible with GCC-3.3), so when using the NeXT
+runtime, GCC will introduce on purpose a number of incorrect encodings:
+
+   * the read-only qualifier of the pointee gets emitted before the '^'.
+     The read-only qualifier of the pointer itself gets ignored, unless
+     it is a typedef.  Also, the 'r' is only emitted for the outermost
+     type.
+
+   * 32-bit longs are encoded as 'l' or 'L', but not always.  For
+     typedefs, the compiler uses 'i' or 'I' instead if encoding a struct
+     field or a pointer.
+
+   * 'enum's are always encoded as 'i' (int) even if they are actually
+     unsigned or long.
+
+ In addition to that, the NeXT runtime uses a different encoding for
+bitfields.  It encodes them as 'b' followed by the size, without a bit
+offset or the underlying field type.
+
+
+File: gcc.info,  Node: @encode,  Next: Method signatures,  Prev: Legacy type encoding,  Up: Type encoding
+
+8.3.2 @encode
+-------------
+
+GNU Objective-C supports the '@encode' syntax that allows you to create
+a type encoding from a C/Objective-C type.  For example, '@encode(int)'
+is compiled by the compiler into '"i"'.
+
+ '@encode' does not support type qualifiers other than 'const'.  For
+example, '@encode(const char*)' is valid and is compiled into '"r*"',
+while '@encode(bycopy char *)' is invalid and will cause a compilation
+error.
+
+
+File: gcc.info,  Node: Method signatures,  Prev: @encode,  Up: Type encoding
+
+8.3.3 Method signatures
+-----------------------
+
+This section documents the encoding of method types, which is rarely
+needed to use Objective-C. You should skip it at a first reading; the
+runtime provides functions that will work on methods and can walk
+through the list of parameters and interpret them for you.  These
+functions are part of the public "API" and are the preferred way to
+interact with method signatures from user code.
+
+ But if you need to debug a problem with method signatures and need to
+know how they are implemented (i.e., the "ABI"), read on.
+
+ Methods have their "signature" encoded and made available to the
+runtime.  The "signature" encodes all the information required to
+dynamically build invocations of the method at runtime: return type and
+arguments.
+
+ The "signature" is a null-terminated string, composed of the following:
+
+   * The return type, including type qualifiers.  For example, a method
+     returning 'int' would have 'i' here.
+
+   * The total size (in bytes) required to pass all the parameters.
+     This includes the two hidden parameters (the object 'self' and the
+     method selector '_cmd').
+
+   * Each argument, with the type encoding, followed by the offset (in
+     bytes) of the argument in the list of parameters.
+
+ For example, a method with no arguments and returning 'int' would have
+the signature 'i8@0:4' if the size of a pointer is 4.  The signature is
+interpreted as follows: the 'i' is the return type (an 'int'), the '8'
+is the total size of the parameters in bytes (two pointers each of size
+4), the '@0' is the first parameter (an object at byte offset '0') and
+':4' is the second parameter (a 'SEL' at byte offset '4').
+
+ You can easily find more examples by running the "strings" program on
+an Objective-C object file compiled by GCC. You'll see a lot of strings
+that look very much like 'i8@0:4'.  They are signatures of Objective-C
+methods.
+
+
+File: gcc.info,  Node: Garbage Collection,  Next: Constant string objects,  Prev: Type encoding,  Up: Objective-C
+
+8.4 Garbage Collection
+======================
+
+This section is specific for the GNU Objective-C runtime.  If you are
+using a different runtime, you can skip it.
+
+ Support for garbage collection with the GNU runtime has been added by
+using a powerful conservative garbage collector, known as the
+Boehm-Demers-Weiser conservative garbage collector.
+
+ To enable the support for it you have to configure the compiler using
+an additional argument, '--enable-objc-gc'.  This will build the
+boehm-gc library, and build an additional runtime library which has
+several enhancements to support the garbage collector.  The new library
+has a new name, 'libobjc_gc.a' to not conflict with the
+non-garbage-collected library.
+
+ When the garbage collector is used, the objects are allocated using the
+so-called typed memory allocation mechanism available in the
+Boehm-Demers-Weiser collector.  This mode requires precise information
+on where pointers are located inside objects.  This information is
+computed once per class, immediately after the class has been
+initialized.
+
+ There is a new runtime function 'class_ivar_set_gcinvisible()' which
+can be used to declare a so-called "weak pointer" reference.  Such a
+pointer is basically hidden for the garbage collector; this can be
+useful in certain situations, especially when you want to keep track of
+the allocated objects, yet allow them to be collected.  This kind of
+pointers can only be members of objects, you cannot declare a global
+pointer as a weak reference.  Every type which is a pointer type can be
+declared a weak pointer, including 'id', 'Class' and 'SEL'.
+
+ Here is an example of how to use this feature.  Suppose you want to
+implement a class whose instances hold a weak pointer reference; the
+following class does this:
+
+
+     @interface WeakPointer : Object
+     {
+         const void* weakPointer;
+     }
+
+     - initWithPointer:(const void*)p;
+     - (const void*)weakPointer;
+     @end
+
+
+     @implementation WeakPointer
+
+     + (void)initialize
+     {
+       if (self == objc_lookUpClass ("WeakPointer"))
+         class_ivar_set_gcinvisible (self, "weakPointer", YES);
+     }
+
+     - initWithPointer:(const void*)p
+     {
+       weakPointer = p;
+       return self;
+     }
+
+     - (const void*)weakPointer
+     {
+       return weakPointer;
+     }
+
+     @end
+
+ Weak pointers are supported through a new type character specifier
+represented by the '!' character.  The 'class_ivar_set_gcinvisible()'
+function adds or removes this specifier to the string type description
+of the instance variable named as argument.
+
+
+File: gcc.info,  Node: Constant string objects,  Next: compatibility_alias,  Prev: Garbage Collection,  Up: Objective-C
+
+8.5 Constant string objects
+===========================
+
+GNU Objective-C provides constant string objects that are generated
+directly by the compiler.  You declare a constant string object by
+prefixing a C constant string with the character '@':
+
+       id myString = @"this is a constant string object";
+
+ The constant string objects are by default instances of the
+'NXConstantString' class which is provided by the GNU Objective-C
+runtime.  To get the definition of this class you must include the
+'objc/NXConstStr.h' header file.
+
+ User defined libraries may want to implement their own constant string
+class.  To be able to support them, the GNU Objective-C compiler
+provides a new command line options
+'-fconstant-string-class=CLASS-NAME'.  The provided class should adhere
+to a strict structure, the same as 'NXConstantString''s structure:
+
+
+     @interface MyConstantStringClass
+     {
+       Class isa;
+       char *c_string;
+       unsigned int len;
+     }
+     @end
+
+ 'NXConstantString' inherits from 'Object'; user class libraries may
+choose to inherit the customized constant string class from a different
+class than 'Object'.  There is no requirement in the methods the
+constant string class has to implement, but the final ivar layout of the
+class must be the compatible with the given structure.
+
+ When the compiler creates the statically allocated constant string
+object, the 'c_string' field will be filled by the compiler with the
+string; the 'length' field will be filled by the compiler with the
+string length; the 'isa' pointer will be filled with 'NULL' by the
+compiler, and it will later be fixed up automatically at runtime by the
+GNU Objective-C runtime library to point to the class which was set by
+the '-fconstant-string-class' option when the object file is loaded (if
+you wonder how it works behind the scenes, the name of the class to use,
+and the list of static objects to fixup, are stored by the compiler in
+the object file in a place where the GNU runtime library will find them
+at runtime).
+
+ As a result, when a file is compiled with the '-fconstant-string-class'
+option, all the constant string objects will be instances of the class
+specified as argument to this option.  It is possible to have multiple
+compilation units referring to different constant string classes,
+neither the compiler nor the linker impose any restrictions in doing
+this.
+
+
+File: gcc.info,  Node: compatibility_alias,  Next: Exceptions,  Prev: Constant string objects,  Up: Objective-C
+
+8.6 compatibility_alias
+=======================
+
+The keyword '@compatibility_alias' allows you to define a class name as
+equivalent to another class name.  For example:
+
+     @compatibility_alias WOApplication GSWApplication;
+
+ tells the compiler that each time it encounters 'WOApplication' as a
+class name, it should replace it with 'GSWApplication' (that is,
+'WOApplication' is just an alias for 'GSWApplication').
+
+ There are some constraints on how this can be used--
+
+   * 'WOApplication' (the alias) must not be an existing class;
+
+   * 'GSWApplication' (the real class) must be an existing class.
+
+
+File: gcc.info,  Node: Exceptions,  Next: Synchronization,  Prev: compatibility_alias,  Up: Objective-C
+
+8.7 Exceptions
+==============
+
+GNU Objective-C provides exception support built into the language, as
+in the following example:
+
+       @try {
+         ...
+            @throw expr;
+         ...
+       }
+       @catch (AnObjCClass *exc) {
+         ...
+           @throw expr;
+         ...
+           @throw;
+         ...
+       }
+       @catch (AnotherClass *exc) {
+         ...
+       }
+       @catch (id allOthers) {
+         ...
+       }
+       @finally {
+         ...
+           @throw expr;
+         ...
+       }
+
+ The '@throw' statement may appear anywhere in an Objective-C or
+Objective-C++ program; when used inside of a '@catch' block, the
+'@throw' may appear without an argument (as shown above), in which case
+the object caught by the '@catch' will be rethrown.
+
+ Note that only (pointers to) Objective-C objects may be thrown and
+caught using this scheme.  When an object is thrown, it will be caught
+by the nearest '@catch' clause capable of handling objects of that type,
+analogously to how 'catch' blocks work in C++ and Java.  A '@catch(id
+...)' clause (as shown above) may also be provided to catch any and all
+Objective-C exceptions not caught by previous '@catch' clauses (if any).
+
+ The '@finally' clause, if present, will be executed upon exit from the
+immediately preceding '@try ... @catch' section.  This will happen
+regardless of whether any exceptions are thrown, caught or rethrown
+inside the '@try ... @catch' section, analogously to the behavior of the
+'finally' clause in Java.
+
+ There are several caveats to using the new exception mechanism:
+
+   * The '-fobjc-exceptions' command line option must be used when
+     compiling Objective-C files that use exceptions.
+
+   * With the GNU runtime, exceptions are always implemented as "native"
+     exceptions and it is recommended that the '-fexceptions' and
+     '-shared-libgcc' options are used when linking.
+
+   * With the NeXT runtime, although currently designed to be binary
+     compatible with 'NS_HANDLER'-style idioms provided by the
+     'NSException' class, the new exceptions can only be used on Mac OS
+     X 10.3 (Panther) and later systems, due to additional functionality
+     needed in the NeXT Objective-C runtime.
+
+   * As mentioned above, the new exceptions do not support handling
+     types other than Objective-C objects.  Furthermore, when used from
+     Objective-C++, the Objective-C exception model does not
+     interoperate with C++ exceptions at this time.  This means you
+     cannot '@throw' an exception from Objective-C and 'catch' it in
+     C++, or vice versa (i.e., 'throw ... @catch').
+
+
+File: gcc.info,  Node: Synchronization,  Next: Fast enumeration,  Prev: Exceptions,  Up: Objective-C
+
+8.8 Synchronization
+===================
+
+GNU Objective-C provides support for synchronized blocks:
+
+       @synchronized (ObjCClass *guard) {
+         ...
+       }
+
+ Upon entering the '@synchronized' block, a thread of execution shall
+first check whether a lock has been placed on the corresponding 'guard'
+object by another thread.  If it has, the current thread shall wait
+until the other thread relinquishes its lock.  Once 'guard' becomes
+available, the current thread will place its own lock on it, execute the
+code contained in the '@synchronized' block, and finally relinquish the
+lock (thereby making 'guard' available to other threads).
+
+ Unlike Java, Objective-C does not allow for entire methods to be marked
+'@synchronized'.  Note that throwing exceptions out of '@synchronized'
+blocks is allowed, and will cause the guarding object to be unlocked
+properly.
+
+ Because of the interactions between synchronization and exception
+handling, you can only use '@synchronized' when compiling with
+exceptions enabled, that is with the command line option
+'-fobjc-exceptions'.
+
+
+File: gcc.info,  Node: Fast enumeration,  Next: Messaging with the GNU Objective-C runtime,  Prev: Synchronization,  Up: Objective-C
+
+8.9 Fast enumeration
+====================
+
+* Menu:
+
+* Using fast enumeration::
+* c99-like fast enumeration syntax::
+* Fast enumeration details::
+* Fast enumeration protocol::
+
+
+File: gcc.info,  Node: Using fast enumeration,  Next: c99-like fast enumeration syntax,  Up: Fast enumeration
+
+8.9.1 Using fast enumeration
+----------------------------
+
+GNU Objective-C provides support for the fast enumeration syntax:
+
+       id array = ...;
+       id object;
+
+       for (object in array)
+       {
+         /* Do something with 'object' */
+       }
+
+ 'array' needs to be an Objective-C object (usually a collection object,
+for example an array, a dictionary or a set) which implements the "Fast
+Enumeration Protocol" (see below).  If you are using a Foundation
+library such as GNUstep Base or Apple Cocoa Foundation, all collection
+objects in the library implement this protocol and can be used in this
+way.
+
+ The code above would iterate over all objects in 'array'.  For each of
+them, it assigns it to 'object', then executes the 'Do something with
+'object'' statements.
+
+ Here is a fully worked-out example using a Foundation library (which
+provides the implementation of 'NSArray', 'NSString' and 'NSLog'):
+
+       NSArray *array = [NSArray arrayWithObjects: @"1", @"2", @"3", nil];
+       NSString *object;
+
+       for (object in array)
+         NSLog (@"Iterating over %@", object);
+
+
+File: gcc.info,  Node: c99-like fast enumeration syntax,  Next: Fast enumeration details,  Prev: Using fast enumeration,  Up: Fast enumeration
+
+8.9.2 c99-like fast enumeration syntax
+--------------------------------------
+
+A c99-like declaration syntax is also allowed:
+
+       id array = ...;
+
+       for (id object in array)
+       {
+         /* Do something with 'object'  */
+       }
+
+ this is completely equivalent to:
+
+       id array = ...;
+
+       {
+         id object;
+         for (object in array)
+         {
+           /* Do something with 'object'  */
+         }
+       }
+
+ but can save some typing.
+
+ Note that the option '-std=c99' is not required to allow this syntax in
+Objective-C.
+
+
+File: gcc.info,  Node: Fast enumeration details,  Next: Fast enumeration protocol,  Prev: c99-like fast enumeration syntax,  Up: Fast enumeration
+
+8.9.3 Fast enumeration details
+------------------------------
+
+Here is a more technical description with the gory details.  Consider
+the code
+
+       for (OBJECT EXPRESSION in COLLECTION EXPRESSION)
+       {
+         STATEMENTS
+       }
+
+ here is what happens when you run it:
+
+   * 'COLLECTION EXPRESSION' is evaluated exactly once and the result is
+     used as the collection object to iterate over.  This means it is
+     safe to write code such as 'for (object in [NSDictionary
+     keyEnumerator]) ...'.
+
+   * the iteration is implemented by the compiler by repeatedly getting
+     batches of objects from the collection object using the fast
+     enumeration protocol (see below), then iterating over all objects
+     in the batch.  This is faster than a normal enumeration where
+     objects are retrieved one by one (hence the name "fast
+     enumeration").
+
+   * if there are no objects in the collection, then 'OBJECT EXPRESSION'
+     is set to 'nil' and the loop immediately terminates.
+
+   * if there are objects in the collection, then for each object in the
+     collection (in the order they are returned) 'OBJECT EXPRESSION' is
+     set to the object, then 'STATEMENTS' are executed.
+
+   * 'STATEMENTS' can contain 'break' and 'continue' commands, which
+     will abort the iteration or skip to the next loop iteration as
+     expected.
+
+   * when the iteration ends because there are no more objects to
+     iterate over, 'OBJECT EXPRESSION' is set to 'nil'.  This allows you
+     to determine whether the iteration finished because a 'break'
+     command was used (in which case 'OBJECT EXPRESSION' will remain set
+     to the last object that was iterated over) or because it iterated
+     over all the objects (in which case 'OBJECT EXPRESSION' will be set
+     to 'nil').
+
+   * 'STATEMENTS' must not make any changes to the collection object; if
+     they do, it is a hard error and the fast enumeration terminates by
+     invoking 'objc_enumerationMutation', a runtime function that
+     normally aborts the program but which can be customized by
+     Foundation libraries via 'objc_set_mutation_handler' to do
+     something different, such as raising an exception.
+
+
+File: gcc.info,  Node: Fast enumeration protocol,  Prev: Fast enumeration details,  Up: Fast enumeration
+
+8.9.4 Fast enumeration protocol
+-------------------------------
+
+If you want your own collection object to be usable with fast
+enumeration, you need to have it implement the method
+
+     - (unsigned long) countByEnumeratingWithState: (NSFastEnumerationState *)state
+                                           objects: (id *)objects
+                                             count: (unsigned long)len;
+
+ where 'NSFastEnumerationState' must be defined in your code as follows:
+
+     typedef struct
+     {
+       unsigned long state;
+       id            *itemsPtr;
+       unsigned long *mutationsPtr;
+       unsigned long extra[5];
+     } NSFastEnumerationState;
+
+ If no 'NSFastEnumerationState' is defined in your code, the compiler
+will automatically replace 'NSFastEnumerationState *' with 'struct
+__objcFastEnumerationState *', where that type is silently defined by
+the compiler in an identical way.  This can be confusing and we
+recommend that you define 'NSFastEnumerationState' (as shown above)
+instead.
+
+ The method is called repeatedly during a fast enumeration to retrieve
+batches of objects.  Each invocation of the method should retrieve the
+next batch of objects.
+
+ The return value of the method is the number of objects in the current
+batch; this should not exceed 'len', which is the maximum size of a
+batch as requested by the caller.  The batch itself is returned in the
+'itemsPtr' field of the 'NSFastEnumerationState' struct.
+
+ To help with returning the objects, the 'objects' array is a C array
+preallocated by the caller (on the stack) of size 'len'.  In many cases
+you can put the objects you want to return in that 'objects' array, then
+do 'itemsPtr = objects'.  But you don't have to; if your collection
+already has the objects to return in some form of C array, it could
+return them from there instead.
+
+ The 'state' and 'extra' fields of the 'NSFastEnumerationState'
+structure allows your collection object to keep track of the state of
+the enumeration.  In a simple array implementation, 'state' may keep
+track of the index of the last object that was returned, and 'extra' may
+be unused.
+
+ The 'mutationsPtr' field of the 'NSFastEnumerationState' is used to
+keep track of mutations.  It should point to a number; before working on
+each object, the fast enumeration loop will check that this number has
+not changed.  If it has, a mutation has happened and the fast
+enumeration will abort.  So, 'mutationsPtr' could be set to point to
+some sort of version number of your collection, which is increased by
+one every time there is a change (for example when an object is added or
+removed).  Or, if you are content with less strict mutation checks, it
+could point to the number of objects in your collection or some other
+value that can be checked to perform an approximate check that the
+collection has not been mutated.
+
+ Finally, note how we declared the 'len' argument and the return value
+to be of type 'unsigned long'.  They could also be declared to be of
+type 'unsigned int' and everything would still work.
+
+
+File: gcc.info,  Node: Messaging with the GNU Objective-C runtime,  Prev: Fast enumeration,  Up: Objective-C
+
+8.10 Messaging with the GNU Objective-C runtime
+===============================================
+
+This section is specific for the GNU Objective-C runtime.  If you are
+using a different runtime, you can skip it.
+
+ The implementation of messaging in the GNU Objective-C runtime is
+designed to be portable, and so is based on standard C.
+
+ Sending a message in the GNU Objective-C runtime is composed of two
+separate steps.  First, there is a call to the lookup function,
+'objc_msg_lookup ()' (or, in the case of messages to super,
+'objc_msg_lookup_super ()').  This runtime function takes as argument
+the receiver and the selector of the method to be called; it returns the
+'IMP', that is a pointer to the function implementing the method.  The
+second step of method invocation consists of casting this pointer
+function to the appropriate function pointer type, and calling the
+function pointed to it with the right arguments.
+
+ For example, when the compiler encounters a method invocation such as
+'[object init]', it compiles it into a call to 'objc_msg_lookup (object,
+@selector(init))' followed by a cast of the returned value to the
+appropriate function pointer type, and then it calls it.
+
+* Menu:
+
+* Dynamically registering methods::
+* Forwarding hook::
+
+
+File: gcc.info,  Node: Dynamically registering methods,  Next: Forwarding hook,  Up: Messaging with the GNU Objective-C runtime
+
+8.10.1 Dynamically registering methods
+--------------------------------------
+
+If 'objc_msg_lookup()' does not find a suitable method implementation,
+because the receiver does not implement the required method, it tries to
+see if the class can dynamically register the method.
+
+ To do so, the runtime checks if the class of the receiver implements
+the method
+
+     + (BOOL) resolveInstanceMethod: (SEL)selector;
+
+ in the case of an instance method, or
+
+     + (BOOL) resolveClassMethod: (SEL)selector;
+
+ in the case of a class method.  If the class implements it, the runtime
+invokes it, passing as argument the selector of the original method, and
+if it returns 'YES', the runtime tries the lookup again, which could now
+succeed if a matching method was added dynamically by
+'+resolveInstanceMethod:' or '+resolveClassMethod:'.
+
+ This allows classes to dynamically register methods (by adding them to
+the class using 'class_addMethod') when they are first called.  To do
+so, a class should implement '+resolveInstanceMethod:' (or, depending on
+the case, '+resolveClassMethod:') and have it recognize the selectors of
+methods that can be registered dynamically at runtime, register them,
+and return 'YES'.  It should return 'NO' for methods that it does not
+dynamically registered at runtime.
+
+ If '+resolveInstanceMethod:' (or '+resolveClassMethod:') is not
+implemented or returns 'NO', the runtime then tries the forwarding hook.
+
+ Support for '+resolveInstanceMethod:' and 'resolveClassMethod:' was
+added to the GNU Objective-C runtime in GCC version 4.6.
+
+
+File: gcc.info,  Node: Forwarding hook,  Prev: Dynamically registering methods,  Up: Messaging with the GNU Objective-C runtime
+
+8.10.2 Forwarding hook
+----------------------
+
+The GNU Objective-C runtime provides a hook, called
+'__objc_msg_forward2', which is called by 'objc_msg_lookup()' when it
+can't find a method implementation in the runtime tables and after
+calling '+resolveInstanceMethod:' and '+resolveClassMethod:' has been
+attempted and did not succeed in dynamically registering the method.
+
+ To configure the hook, you set the global variable
+'__objc_msg_forward2' to a function with the same argument and return
+types of 'objc_msg_lookup()'.  When 'objc_msg_lookup()' can not find a
+method implementation, it invokes the hook function you provided to get
+a method implementation to return.  So, in practice
+'__objc_msg_forward2' allows you to extend 'objc_msg_lookup()' by adding
+some custom code that is called to do a further lookup when no standard
+method implementation can be found using the normal lookup.
+
+ This hook is generally reserved for "Foundation" libraries such as
+GNUstep Base, which use it to implement their high-level method
+forwarding API, typically based around the 'forwardInvocation:' method.
+So, unless you are implementing your own "Foundation" library, you
+should not set this hook.
+
+ In a typical forwarding implementation, the '__objc_msg_forward2' hook
+function determines the argument and return type of the method that is
+being looked up, and then creates a function that takes these arguments
+and has that return type, and returns it to the caller.  Creating this
+function is non-trivial and is typically performed using a dedicated
+library such as 'libffi'.
+
+ The forwarding method implementation thus created is returned by
+'objc_msg_lookup()' and is executed as if it was a normal method
+implementation.  When the forwarding method implementation is called, it
+is usually expected to pack all arguments into some sort of object
+(typically, an 'NSInvocation' in a "Foundation" library), and hand it
+over to the programmer ('forwardInvocation:') who is then allowed to
+manipulate the method invocation using a high-level API provided by the
+"Foundation" library.  For example, the programmer may want to examine
+the method invocation arguments and name and potentially change them
+before forwarding the method invocation to one or more local objects
+('performInvocation:') or even to remote objects (by using Distributed
+Objects or some other mechanism).  When all this completes, the return
+value is passed back and must be returned correctly to the original
+caller.
+
+ Note that the GNU Objective-C runtime currently provides no support for
+method forwarding or method invocations other than the
+'__objc_msg_forward2' hook.
+
+ If the forwarding hook does not exist or returns 'NULL', the runtime
+currently attempts forwarding using an older, deprecated API, and if
+that fails, it aborts the program.  In future versions of the GNU
+Objective-C runtime, the runtime will immediately abort.
+
+
+File: gcc.info,  Node: Compatibility,  Next: Gcov,  Prev: Objective-C,  Up: Top
+
+9 Binary Compatibility
+**********************
+
+Binary compatibility encompasses several related concepts:
+
+"application binary interface (ABI)"
+     The set of runtime conventions followed by all of the tools that
+     deal with binary representations of a program, including compilers,
+     assemblers, linkers, and language runtime support.  Some ABIs are
+     formal with a written specification, possibly designed by multiple
+     interested parties.  Others are simply the way things are actually
+     done by a particular set of tools.
+
+"ABI conformance"
+     A compiler conforms to an ABI if it generates code that follows all
+     of the specifications enumerated by that ABI.  A library conforms
+     to an ABI if it is implemented according to that ABI.  An
+     application conforms to an ABI if it is built using tools that
+     conform to that ABI and does not contain source code that
+     specifically changes behavior specified by the ABI.
+
+"calling conventions"
+     Calling conventions are a subset of an ABI that specify of how
+     arguments are passed and function results are returned.
+
+"interoperability"
+     Different sets of tools are interoperable if they generate files
+     that can be used in the same program.  The set of tools includes
+     compilers, assemblers, linkers, libraries, header files, startup
+     files, and debuggers.  Binaries produced by different sets of tools
+     are not interoperable unless they implement the same ABI.  This
+     applies to different versions of the same tools as well as tools
+     from different vendors.
+
+"intercallability"
+     Whether a function in a binary built by one set of tools can call a
+     function in a binary built by a different set of tools is a subset
+     of interoperability.
+
+"implementation-defined features"
+     Language standards include lists of implementation-defined features
+     whose behavior can vary from one implementation to another.  Some
+     of these features are normally covered by a platform's ABI and
+     others are not.  The features that are not covered by an ABI
+     generally affect how a program behaves, but not intercallability.
+
+"compatibility"
+     Conformance to the same ABI and the same behavior of
+     implementation-defined features are both relevant for
+     compatibility.
+
+ The application binary interface implemented by a C or C++ compiler
+affects code generation and runtime support for:
+
+   * size and alignment of data types
+   * layout of structured types
+   * calling conventions
+   * register usage conventions
+   * interfaces for runtime arithmetic support
+   * object file formats
+
+ In addition, the application binary interface implemented by a C++
+compiler affects code generation and runtime support for:
+   * name mangling
+   * exception handling
+   * invoking constructors and destructors
+   * layout, alignment, and padding of classes
+   * layout and alignment of virtual tables
+
+ Some GCC compilation options cause the compiler to generate code that
+does not conform to the platform's default ABI.  Other options cause
+different program behavior for implementation-defined features that are
+not covered by an ABI.  These options are provided for consistency with
+other compilers that do not follow the platform's default ABI or the
+usual behavior of implementation-defined features for the platform.  Be
+very careful about using such options.
+
+ Most platforms have a well-defined ABI that covers C code, but ABIs
+that cover C++ functionality are not yet common.
+
+ Starting with GCC 3.2, GCC binary conventions for C++ are based on a
+written, vendor-neutral C++ ABI that was designed to be specific to
+64-bit Itanium but also includes generic specifications that apply to
+any platform.  This C++ ABI is also implemented by other compiler
+vendors on some platforms, notably GNU/Linux and BSD systems.  We have
+tried hard to provide a stable ABI that will be compatible with future
+GCC releases, but it is possible that we will encounter problems that
+make this difficult.  Such problems could include different
+interpretations of the C++ ABI by different vendors, bugs in the ABI, or
+bugs in the implementation of the ABI in different compilers.  GCC's
+'-Wabi' switch warns when G++ generates code that is probably not
+compatible with the C++ ABI.
+
+ The C++ library used with a C++ compiler includes the Standard C++
+Library, with functionality defined in the C++ Standard, plus language
+runtime support.  The runtime support is included in a C++ ABI, but
+there is no formal ABI for the Standard C++ Library.  Two
+implementations of that library are interoperable if one follows the
+de-facto ABI of the other and if they are both built with the same
+compiler, or with compilers that conform to the same ABI for C++
+compiler and runtime support.
+
+ When G++ and another C++ compiler conform to the same C++ ABI, but the
+implementations of the Standard C++ Library that they normally use do
+not follow the same ABI for the Standard C++ Library, object files built
+with those compilers can be used in the same program only if they use
+the same C++ library.  This requires specifying the location of the C++
+library header files when invoking the compiler whose usual library is
+not being used.  The location of GCC's C++ header files depends on how
+the GCC build was configured, but can be seen by using the G++ '-v'
+option.  With default configuration options for G++ 3.3 the compile line
+for a different C++ compiler needs to include
+
+         -IGCC_INSTALL_DIRECTORY/include/c++/3.3
+
+ Similarly, compiling code with G++ that must use a C++ library other
+than the GNU C++ library requires specifying the location of the header
+files for that other library.
+
+ The most straightforward way to link a program to use a particular C++
+library is to use a C++ driver that specifies that C++ library by
+default.  The 'g++' driver, for example, tells the linker where to find
+GCC's C++ library ('libstdc++') plus the other libraries and startup
+files it needs, in the proper order.
+
+ If a program must use a different C++ library and it's not possible to
+do the final link using a C++ driver that uses that library by default,
+it is necessary to tell 'g++' the location and name of that library.  It
+might also be necessary to specify different startup files and other
+runtime support libraries, and to suppress the use of GCC's support
+libraries with one or more of the options '-nostdlib', '-nostartfiles',
+and '-nodefaultlibs'.
+
+
+File: gcc.info,  Node: Gcov,  Next: Trouble,  Prev: Compatibility,  Up: Top
+
+10 'gcov'--a Test Coverage Program
+**********************************
+
+'gcov' is a tool you can use in conjunction with GCC to test code
+coverage in your programs.
+
+* Menu:
+
+* Gcov Intro::                  Introduction to gcov.
+* Invoking Gcov::               How to use gcov.
+* Gcov and Optimization::       Using gcov with GCC optimization.
+* Gcov Data Files::             The files used by gcov.
+* Cross-profiling::             Data file relocation.
+
+
+File: gcc.info,  Node: Gcov Intro,  Next: Invoking Gcov,  Up: Gcov
+
+10.1 Introduction to 'gcov'
+===========================
+
+'gcov' is a test coverage program.  Use it in concert with GCC to
+analyze your programs to help create more efficient, faster running code
+and to discover untested parts of your program.  You can use 'gcov' as a
+profiling tool to help discover where your optimization efforts will
+best affect your code.  You can also use 'gcov' along with the other
+profiling tool, 'gprof', to assess which parts of your code use the
+greatest amount of computing time.
+
+ Profiling tools help you analyze your code's performance.  Using a
+profiler such as 'gcov' or 'gprof', you can find out some basic
+performance statistics, such as:
+
+   * how often each line of code executes
+
+   * what lines of code are actually executed
+
+   * how much computing time each section of code uses
+
+ Once you know these things about how your code works when compiled, you
+can look at each module to see which modules should be optimized.
+'gcov' helps you determine where to work on optimization.
+
+ Software developers also use coverage testing in concert with
+testsuites, to make sure software is actually good enough for a release.
+Testsuites can verify that a program works as expected; a coverage
+program tests to see how much of the program is exercised by the
+testsuite.  Developers can then determine what kinds of test cases need
+to be added to the testsuites to create both better testing and a better
+final product.
+
+ You should compile your code without optimization if you plan to use
+'gcov' because the optimization, by combining some lines of code into
+one function, may not give you as much information as you need to look
+for 'hot spots' where the code is using a great deal of computer time.
+Likewise, because 'gcov' accumulates statistics by line (at the lowest
+resolution), it works best with a programming style that places only one
+statement on each line.  If you use complicated macros that expand to
+loops or to other control structures, the statistics are less
+helpful--they only report on the line where the macro call appears.  If
+your complex macros behave like functions, you can replace them with
+inline functions to solve this problem.
+
+ 'gcov' creates a logfile called 'SOURCEFILE.gcov' which indicates how
+many times each line of a source file 'SOURCEFILE.c' has executed.  You
+can use these logfiles along with 'gprof' to aid in fine-tuning the
+performance of your programs.  'gprof' gives timing information you can
+use along with the information you get from 'gcov'.
+
+ 'gcov' works only on code compiled with GCC.  It is not compatible with
+any other profiling or test coverage mechanism.
+
+
+File: gcc.info,  Node: Invoking Gcov,  Next: Gcov and Optimization,  Prev: Gcov Intro,  Up: Gcov
+
+10.2 Invoking 'gcov'
+====================
+
+     gcov [OPTIONS] FILES
+
+ 'gcov' accepts the following options:
+
+'-h'
+'--help'
+     Display help about using 'gcov' (on the standard output), and exit
+     without doing any further processing.
+
+'-v'
+'--version'
+     Display the 'gcov' version number (on the standard output), and
+     exit without doing any further processing.
+
+'-a'
+'--all-blocks'
+     Write individual execution counts for every basic block.  Normally
+     gcov outputs execution counts only for the main blocks of a line.
+     With this option you can determine if blocks within a single line
+     are not being executed.
+
+'-b'
+'--branch-probabilities'
+     Write branch frequencies to the output file, and write branch
+     summary info to the standard output.  This option allows you to see
+     how often each branch in your program was taken.  Unconditional
+     branches will not be shown, unless the '-u' option is given.
+
+'-c'
+'--branch-counts'
+     Write branch frequencies as the number of branches taken, rather
+     than the percentage of branches taken.
+
+'-n'
+'--no-output'
+     Do not create the 'gcov' output file.
+
+'-l'
+'--long-file-names'
+     Create long file names for included source files.  For example, if
+     the header file 'x.h' contains code, and was included in the file
+     'a.c', then running 'gcov' on the file 'a.c' will produce an output
+     file called 'a.c##x.h.gcov' instead of 'x.h.gcov'.  This can be
+     useful if 'x.h' is included in multiple source files and you want
+     to see the individual contributions.  If you use the '-p' option,
+     both the including and included file names will be complete path
+     names.
+
+'-p'
+'--preserve-paths'
+     Preserve complete path information in the names of generated
+     '.gcov' files.  Without this option, just the filename component is
+     used.  With this option, all directories are used, with '/'
+     characters translated to '#' characters, '.' directory components
+     removed and unremoveable '..' components renamed to '^'.  This is
+     useful if sourcefiles are in several different directories.
+
+'-r'
+'--relative-only'
+     Only output information about source files with a relative pathname
+     (after source prefix elision).  Absolute paths are usually system
+     header files and coverage of any inline functions therein is
+     normally uninteresting.
+
+'-f'
+'--function-summaries'
+     Output summaries for each function in addition to the file level
+     summary.
+
+'-o DIRECTORY|FILE'
+'--object-directory DIRECTORY'
+'--object-file FILE'
+     Specify either the directory containing the gcov data files, or the
+     object path name.  The '.gcno', and '.gcda' data files are searched
+     for using this option.  If a directory is specified, the data files
+     are in that directory and named after the input file name, without
+     its extension.  If a file is specified here, the data files are
+     named after that file, without its extension.
+
+'-s DIRECTORY'
+'--source-prefix DIRECTORY'
+     A prefix for source file names to remove when generating the output
+     coverage files.  This option is useful when building in a separate
+     directory, and the pathname to the source directory is not wanted
+     when determining the output file names.  Note that this prefix
+     detection is applied before determining whether the source file is
+     absolute.
+
+'-u'
+'--unconditional-branches'
+     When branch probabilities are given, include those of unconditional
+     branches.  Unconditional branches are normally not interesting.
+
+'-d'
+'--display-progress'
+     Display the progress on the standard output.
+
+'-i'
+'--intermediate-format'
+     Output gcov file in an easy-to-parse intermediate text format that
+     can be used by 'lcov' or other tools.  The output is a single
+     '.gcov' file per '.gcda' file.  No source code is required.
+
+     The format of the intermediate '.gcov' file is plain text with one
+     entry per line
+
+          file:SOURCE_FILE_NAME
+          function:LINE_NUMBER,EXECUTION_COUNT,FUNCTION_NAME
+          lcount:LINE NUMBER,EXECUTION_COUNT
+          branch:LINE_NUMBER,BRANCH_COVERAGE_TYPE
+
+          Where the BRANCH_COVERAGE_TYPE is
+             notexec (Branch not executed)
+             taken (Branch executed and taken)
+             nottaken (Branch executed, but not taken)
+
+          There can be multiple FILE entries in an intermediate gcov
+          file. All entries following a FILE pertain to that source file
+          until the next FILE entry.
+
+     Here is a sample when '-i' is used in conjunction with '-b' option:
+
+          file:array.cc
+          function:11,1,_Z3sumRKSt6vectorIPiSaIS0_EE
+          function:22,1,main
+          lcount:11,1
+          lcount:12,1
+          lcount:14,1
+          branch:14,taken
+          lcount:26,1
+          branch:28,nottaken
+
+'-m'
+'--demangled-names'
+     Display demangled function names in output.  The default is to show
+     mangled function names.
+
+ 'gcov' should be run with the current directory the same as that when
+you invoked the compiler.  Otherwise it will not be able to locate the
+source files.  'gcov' produces files called 'MANGLEDNAME.gcov' in the
+current directory.  These contain the coverage information of the source
+file they correspond to.  One '.gcov' file is produced for each source
+(or header) file containing code, which was compiled to produce the data
+files.  The MANGLEDNAME part of the output file name is usually simply
+the source file name, but can be something more complicated if the '-l'
+or '-p' options are given.  Refer to those options for details.
+
+ If you invoke 'gcov' with multiple input files, the contributions from
+each input file are summed.  Typically you would invoke it with the same
+list of files as the final link of your executable.
+
+ The '.gcov' files contain the ':' separated fields along with program
+source code.  The format is
+
+     EXECUTION_COUNT:LINE_NUMBER:SOURCE LINE TEXT
+
+ Additional block information may succeed each line, when requested by
+command line option.  The EXECUTION_COUNT is '-' for lines containing no
+code.  Unexecuted lines are marked '#####' or '====', depending on
+whether they are reachable by non-exceptional paths or only exceptional
+paths such as C++ exception handlers, respectively.
+
+ Some lines of information at the start have LINE_NUMBER of zero.  These
+preamble lines are of the form
+
+     -:0:TAG:VALUE
+
+ The ordering and number of these preamble lines will be augmented as
+'gcov' development progresses -- do not rely on them remaining
+unchanged.  Use TAG to locate a particular preamble line.
+
+ The additional block information is of the form
+
+     TAG INFORMATION
+
+ The INFORMATION is human readable, but designed to be simple enough for
+machine parsing too.
+
+ When printing percentages, 0% and 100% are only printed when the values
+are _exactly_ 0% and 100% respectively.  Other values which would
+conventionally be rounded to 0% or 100% are instead printed as the
+nearest non-boundary value.
+
+ When using 'gcov', you must first compile your program with two special
+GCC options: '-fprofile-arcs -ftest-coverage'.  This tells the compiler
+to generate additional information needed by gcov (basically a flow
+graph of the program) and also includes additional code in the object
+files for generating the extra profiling information needed by gcov.
+These additional files are placed in the directory where the object file
+is located.
+
+ Running the program will cause profile output to be generated.  For
+each source file compiled with '-fprofile-arcs', an accompanying '.gcda'
+file will be placed in the object file directory.
+
+ Running 'gcov' with your program's source file names as arguments will
+now produce a listing of the code along with frequency of execution for
+each line.  For example, if your program is called 'tmp.c', this is what
+you see when you use the basic 'gcov' facility:
+
+     $ gcc -fprofile-arcs -ftest-coverage tmp.c
+     $ a.out
+     $ gcov tmp.c
+     90.00% of 10 source lines executed in file tmp.c
+     Creating tmp.c.gcov.
+
+ The file 'tmp.c.gcov' contains output from 'gcov'.  Here is a sample:
+
+             -:    0:Source:tmp.c
+             -:    0:Graph:tmp.gcno
+             -:    0:Data:tmp.gcda
+             -:    0:Runs:1
+             -:    0:Programs:1
+             -:    1:#include <stdio.h>
+             -:    2:
+             -:    3:int main (void)
+             1:    4:{
+             1:    5:  int i, total;
+             -:    6:
+             1:    7:  total = 0;
+             -:    8:
+            11:    9:  for (i = 0; i < 10; i++)
+            10:   10:    total += i;
+             -:   11:
+             1:   12:  if (total != 45)
+         #####:   13:    printf ("Failure\n");
+             -:   14:  else
+             1:   15:    printf ("Success\n");
+             1:   16:  return 0;
+             -:   17:}
+
+ When you use the '-a' option, you will get individual block counts, and
+the output looks like this:
+
+             -:    0:Source:tmp.c
+             -:    0:Graph:tmp.gcno
+             -:    0:Data:tmp.gcda
+             -:    0:Runs:1
+             -:    0:Programs:1
+             -:    1:#include <stdio.h>
+             -:    2:
+             -:    3:int main (void)
+             1:    4:{
+             1:    4-block  0
+             1:    5:  int i, total;
+             -:    6:
+             1:    7:  total = 0;
+             -:    8:
+            11:    9:  for (i = 0; i < 10; i++)
+            11:    9-block  0
+            10:   10:    total += i;
+            10:   10-block  0
+             -:   11:
+             1:   12:  if (total != 45)
+             1:   12-block  0
+         #####:   13:    printf ("Failure\n");
+         $$$$$:   13-block  0
+             -:   14:  else
+             1:   15:    printf ("Success\n");
+             1:   15-block  0
+             1:   16:  return 0;
+             1:   16-block  0
+             -:   17:}
+
+ In this mode, each basic block is only shown on one line - the last
+line of the block.  A multi-line block will only contribute to the
+execution count of that last line, and other lines will not be shown to
+contain code, unless previous blocks end on those lines.  The total
+execution count of a line is shown and subsequent lines show the
+execution counts for individual blocks that end on that line.  After
+each block, the branch and call counts of the block will be shown, if
+the '-b' option is given.
+
+ Because of the way GCC instruments calls, a call count can be shown
+after a line with no individual blocks.  As you can see, line 13
+contains a basic block that was not executed.
+
+ When you use the '-b' option, your output looks like this:
+
+     $ gcov -b tmp.c
+     90.00% of 10 source lines executed in file tmp.c
+     80.00% of 5 branches executed in file tmp.c
+     80.00% of 5 branches taken at least once in file tmp.c
+     50.00% of 2 calls executed in file tmp.c
+     Creating tmp.c.gcov.
+
+ Here is a sample of a resulting 'tmp.c.gcov' file:
+
+             -:    0:Source:tmp.c
+             -:    0:Graph:tmp.gcno
+             -:    0:Data:tmp.gcda
+             -:    0:Runs:1
+             -:    0:Programs:1
+             -:    1:#include <stdio.h>
+             -:    2:
+             -:    3:int main (void)
+     function main called 1 returned 1 blocks executed 75%
+             1:    4:{
+             1:    5:  int i, total;
+             -:    6:
+             1:    7:  total = 0;
+             -:    8:
+            11:    9:  for (i = 0; i < 10; i++)
+     branch  0 taken 91% (fallthrough)
+     branch  1 taken 9%
+            10:   10:    total += i;
+             -:   11:
+             1:   12:  if (total != 45)
+     branch  0 taken 0% (fallthrough)
+     branch  1 taken 100%
+         #####:   13:    printf ("Failure\n");
+     call    0 never executed
+             -:   14:  else
+             1:   15:    printf ("Success\n");
+     call    0 called 1 returned 100%
+             1:   16:  return 0;
+             -:   17:}
+
+ For each function, a line is printed showing how many times the
+function is called, how many times it returns and what percentage of the
+function's blocks were executed.
+
+ For each basic block, a line is printed after the last line of the
+basic block describing the branch or call that ends the basic block.
+There can be multiple branches and calls listed for a single source line
+if there are multiple basic blocks that end on that line.  In this case,
+the branches and calls are each given a number.  There is no simple way
+to map these branches and calls back to source constructs.  In general,
+though, the lowest numbered branch or call will correspond to the
+leftmost construct on the source line.
+
+ For a branch, if it was executed at least once, then a percentage
+indicating the number of times the branch was taken divided by the
+number of times the branch was executed will be printed.  Otherwise, the
+message "never executed" is printed.
+
+ For a call, if it was executed at least once, then a percentage
+indicating the number of times the call returned divided by the number
+of times the call was executed will be printed.  This will usually be
+100%, but may be less for functions that call 'exit' or 'longjmp', and
+thus may not return every time they are called.
+
+ The execution counts are cumulative.  If the example program were
+executed again without removing the '.gcda' file, the count for the
+number of times each line in the source was executed would be added to
+the results of the previous run(s).  This is potentially useful in
+several ways.  For example, it could be used to accumulate data over a
+number of program runs as part of a test verification suite, or to
+provide more accurate long-term information over a large number of
+program runs.
+
+ The data in the '.gcda' files is saved immediately before the program
+exits.  For each source file compiled with '-fprofile-arcs', the
+profiling code first attempts to read in an existing '.gcda' file; if
+the file doesn't match the executable (differing number of basic block
+counts) it will ignore the contents of the file.  It then adds in the
+new execution counts and finally writes the data to the file.
+
+
+File: gcc.info,  Node: Gcov and Optimization,  Next: Gcov Data Files,  Prev: Invoking Gcov,  Up: Gcov
+
+10.3 Using 'gcov' with GCC Optimization
+=======================================
+
+If you plan to use 'gcov' to help optimize your code, you must first
+compile your program with two special GCC options: '-fprofile-arcs
+-ftest-coverage'.  Aside from that, you can use any other GCC options;
+but if you want to prove that every single line in your program was
+executed, you should not compile with optimization at the same time.  On
+some machines the optimizer can eliminate some simple code lines by
+combining them with other lines.  For example, code like this:
+
+     if (a != b)
+       c = 1;
+     else
+       c = 0;
+
+can be compiled into one instruction on some machines.  In this case,
+there is no way for 'gcov' to calculate separate execution counts for
+each line because there isn't separate code for each line.  Hence the
+'gcov' output looks like this if you compiled the program with
+optimization:
+
+           100:   12:if (a != b)
+           100:   13:  c = 1;
+           100:   14:else
+           100:   15:  c = 0;
+
+ The output shows that this block of code, combined by optimization,
+executed 100 times.  In one sense this result is correct, because there
+was only one instruction representing all four of these lines.  However,
+the output does not indicate how many times the result was 0 and how
+many times the result was 1.
+
+ Inlineable functions can create unexpected line counts.  Line counts
+are shown for the source code of the inlineable function, but what is
+shown depends on where the function is inlined, or if it is not inlined
+at all.
+
+ If the function is not inlined, the compiler must emit an out of line
+copy of the function, in any object file that needs it.  If 'fileA.o'
+and 'fileB.o' both contain out of line bodies of a particular inlineable
+function, they will also both contain coverage counts for that function.
+When 'fileA.o' and 'fileB.o' are linked together, the linker will, on
+many systems, select one of those out of line bodies for all calls to
+that function, and remove or ignore the other.  Unfortunately, it will
+not remove the coverage counters for the unused function body.  Hence
+when instrumented, all but one use of that function will show zero
+counts.
+
+ If the function is inlined in several places, the block structure in
+each location might not be the same.  For instance, a condition might
+now be calculable at compile time in some instances.  Because the
+coverage of all the uses of the inline function will be shown for the
+same source lines, the line counts themselves might seem inconsistent.
+
+ Long-running applications can use the '_gcov_reset' and '_gcov_dump'
+facilities to restrict profile collection to the program region of
+interest.  Calling '_gcov_reset(void)' will clear all profile counters
+to zero, and calling '_gcov_dump(void)' will cause the profile
+information collected at that point to be dumped to '.gcda' output
+files.
+
+
+File: gcc.info,  Node: Gcov Data Files,  Next: Cross-profiling,  Prev: Gcov and Optimization,  Up: Gcov
+
+10.4 Brief description of 'gcov' data files
+===========================================
+
+'gcov' uses two files for profiling.  The names of these files are
+derived from the original _object_ file by substituting the file suffix
+with either '.gcno', or '.gcda'.  The files contain coverage and profile
+data stored in a platform-independent format.  The '.gcno' files are
+placed in the same directory as the object file.  By default, the
+'.gcda' files are also stored in the same directory as the object file,
+but the GCC '-fprofile-dir' option may be used to store the '.gcda'
+files in a separate directory.
+
+ The '.gcno' notes file is generated when the source file is compiled
+with the GCC '-ftest-coverage' option.  It contains information to
+reconstruct the basic block graphs and assign source line numbers to
+blocks.
+
+ The '.gcda' count data file is generated when a program containing
+object files built with the GCC '-fprofile-arcs' option is executed.  A
+separate '.gcda' file is created for each object file compiled with this
+option.  It contains arc transition counts, value profile counts, and
+some summary information.
+
+ The full details of the file format is specified in 'gcov-io.h', and
+functions provided in that header file should be used to access the
+coverage files.
+
+
+File: gcc.info,  Node: Cross-profiling,  Prev: Gcov Data Files,  Up: Gcov
+
+10.5 Data file relocation to support cross-profiling
+====================================================
+
+Running the program will cause profile output to be generated.  For each
+source file compiled with '-fprofile-arcs', an accompanying '.gcda' file
+will be placed in the object file directory.  That implicitly requires
+running the program on the same system as it was built or having the
+same absolute directory structure on the target system.  The program
+will try to create the needed directory structure, if it is not already
+present.
+
+ To support cross-profiling, a program compiled with '-fprofile-arcs'
+can relocate the data files based on two environment variables:
+
+   * GCOV_PREFIX contains the prefix to add to the absolute paths in the
+     object file.  Prefix can be absolute, or relative.  The default is
+     no prefix.
+
+   * GCOV_PREFIX_STRIP indicates the how many initial directory names to
+     strip off the hardwired absolute paths.  Default value is 0.
+
+     _Note:_ If GCOV_PREFIX_STRIP is set without GCOV_PREFIX is
+     undefined, then a relative path is made out of the hardwired
+     absolute paths.
+
+ For example, if the object file '/user/build/foo.o' was built with
+'-fprofile-arcs', the final executable will try to create the data file
+'/user/build/foo.gcda' when running on the target system.  This will
+fail if the corresponding directory does not exist and it is unable to
+create it.  This can be overcome by, for example, setting the
+environment as 'GCOV_PREFIX=/target/run' and 'GCOV_PREFIX_STRIP=1'.
+Such a setting will name the data file '/target/run/build/foo.gcda'.
+
+ You must move the data files to the expected directory tree in order to
+use them for profile directed optimizations ('--use-profile'), or to use
+the 'gcov' tool.
+
+
+File: gcc.info,  Node: Trouble,  Next: Bugs,  Prev: Gcov,  Up: Top
+
+11 Known Causes of Trouble with GCC
+***********************************
+
+This section describes known problems that affect users of GCC.  Most of
+these are not GCC bugs per se--if they were, we would fix them.  But the
+result for a user may be like the result of a bug.
+
+ Some of these problems are due to bugs in other software, some are
+missing features that are too much work to add, and some are places
+where people's opinions differ as to what is best.
+
+* Menu:
+
+* Actual Bugs::         Bugs we will fix later.
+* Interoperation::      Problems using GCC with other compilers,
+                        and with certain linkers, assemblers and debuggers.
+* Incompatibilities::   GCC is incompatible with traditional C.
+* Fixed Headers::       GCC uses corrected versions of system header files.
+                        This is necessary, but doesn't always work smoothly.
+* Standard Libraries::  GCC uses the system C library, which might not be
+                        compliant with the ISO C standard.
+* Disappointments::     Regrettable things we can't change, but not quite bugs.
+* C++ Misunderstandings:: Common misunderstandings with GNU C++.
+* Non-bugs::            Things we think are right, but some others disagree.
+* Warnings and Errors:: Which problems in your code get warnings,
+                        and which get errors.
+
+
+File: gcc.info,  Node: Actual Bugs,  Next: Interoperation,  Up: Trouble
+
+11.1 Actual Bugs We Haven't Fixed Yet
+=====================================
+
+   * The 'fixincludes' script interacts badly with automounters; if the
+     directory of system header files is automounted, it tends to be
+     unmounted while 'fixincludes' is running.  This would seem to be a
+     bug in the automounter.  We don't know any good way to work around
+     it.
+
+
+File: gcc.info,  Node: Interoperation,  Next: Incompatibilities,  Prev: Actual Bugs,  Up: Trouble
+
+11.2 Interoperation
+===================
+
+This section lists various difficulties encountered in using GCC
+together with other compilers or with the assemblers, linkers, libraries
+and debuggers on certain systems.
+
+   * On many platforms, GCC supports a different ABI for C++ than do
+     other compilers, so the object files compiled by GCC cannot be used
+     with object files generated by another C++ compiler.
+
+     An area where the difference is most apparent is name mangling.
+     The use of different name mangling is intentional, to protect you
+     from more subtle problems.  Compilers differ as to many internal
+     details of C++ implementation, including: how class instances are
+     laid out, how multiple inheritance is implemented, and how virtual
+     function calls are handled.  If the name encoding were made the
+     same, your programs would link against libraries provided from
+     other compilers--but the programs would then crash when run.
+     Incompatible libraries are then detected at link time, rather than
+     at run time.
+
+   * On some BSD systems, including some versions of Ultrix, use of
+     profiling causes static variable destructors (currently used only
+     in C++) not to be run.
+
+   * On a SPARC, GCC aligns all values of type 'double' on an 8-byte
+     boundary, and it expects every 'double' to be so aligned.  The Sun
+     compiler usually gives 'double' values 8-byte alignment, with one
+     exception: function arguments of type 'double' may not be aligned.
+
+     As a result, if a function compiled with Sun CC takes the address
+     of an argument of type 'double' and passes this pointer of type
+     'double *' to a function compiled with GCC, dereferencing the
+     pointer may cause a fatal signal.
+
+     One way to solve this problem is to compile your entire program
+     with GCC.  Another solution is to modify the function that is
+     compiled with Sun CC to copy the argument into a local variable;
+     local variables are always properly aligned.  A third solution is
+     to modify the function that uses the pointer to dereference it via
+     the following function 'access_double' instead of directly with
+     '*':
+
+          inline double
+          access_double (double *unaligned_ptr)
+          {
+            union d2i { double d; int i[2]; };
+
+            union d2i *p = (union d2i *) unaligned_ptr;
+            union d2i u;
+
+            u.i[0] = p->i[0];
+            u.i[1] = p->i[1];
+
+            return u.d;
+          }
+
+     Storing into the pointer can be done likewise with the same union.
+
+   * On Solaris, the 'malloc' function in the 'libmalloc.a' library may
+     allocate memory that is only 4 byte aligned.  Since GCC on the
+     SPARC assumes that doubles are 8 byte aligned, this may result in a
+     fatal signal if doubles are stored in memory allocated by the
+     'libmalloc.a' library.
+
+     The solution is to not use the 'libmalloc.a' library.  Use instead
+     'malloc' and related functions from 'libc.a'; they do not have this
+     problem.
+
+   * On the HP PA machine, ADB sometimes fails to work on functions
+     compiled with GCC.  Specifically, it fails to work on functions
+     that use 'alloca' or variable-size arrays.  This is because GCC
+     doesn't generate HP-UX unwind descriptors for such functions.  It
+     may even be impossible to generate them.
+
+   * Debugging ('-g') is not supported on the HP PA machine, unless you
+     use the preliminary GNU tools.
+
+   * Taking the address of a label may generate errors from the HP-UX PA
+     assembler.  GAS for the PA does not have this problem.
+
+   * Using floating point parameters for indirect calls to static
+     functions will not work when using the HP assembler.  There simply
+     is no way for GCC to specify what registers hold arguments for
+     static functions when using the HP assembler.  GAS for the PA does
+     not have this problem.
+
+   * In extremely rare cases involving some very large functions you may
+     receive errors from the HP linker complaining about an out of
+     bounds unconditional branch offset.  This used to occur more often
+     in previous versions of GCC, but is now exceptionally rare.  If you
+     should run into it, you can work around by making your function
+     smaller.
+
+   * GCC compiled code sometimes emits warnings from the HP-UX assembler
+     of the form:
+
+          (warning) Use of GR3 when
+            frame >= 8192 may cause conflict.
+
+     These warnings are harmless and can be safely ignored.
+
+   * In extremely rare cases involving some very large functions you may
+     receive errors from the AIX Assembler complaining about a
+     displacement that is too large.  If you should run into it, you can
+     work around by making your function smaller.
+
+   * The 'libstdc++.a' library in GCC relies on the SVR4 dynamic linker
+     semantics which merges global symbols between libraries and
+     applications, especially necessary for C++ streams functionality.
+     This is not the default behavior of AIX shared libraries and
+     dynamic linking.  'libstdc++.a' is built on AIX with
+     "runtime-linking" enabled so that symbol merging can occur.  To
+     utilize this feature, the application linked with 'libstdc++.a'
+     must include the '-Wl,-brtl' flag on the link line.  G++ cannot
+     impose this because this option may interfere with the semantics of
+     the user program and users may not always use 'g++' to link his or
+     her application.  Applications are not required to use the
+     '-Wl,-brtl' flag on the link line--the rest of the 'libstdc++.a'
+     library which is not dependent on the symbol merging semantics will
+     continue to function correctly.
+
+   * An application can interpose its own definition of functions for
+     functions invoked by 'libstdc++.a' with "runtime-linking" enabled
+     on AIX.  To accomplish this the application must be linked with
+     "runtime-linking" option and the functions explicitly must be
+     exported by the application ('-Wl,-brtl,-bE:exportfile').
+
+   * AIX on the RS/6000 provides support (NLS) for environments outside
+     of the United States.  Compilers and assemblers use NLS to support
+     locale-specific representations of various objects including
+     floating-point numbers ('.' vs ',' for separating decimal
+     fractions).  There have been problems reported where the library
+     linked with GCC does not produce the same floating-point formats
+     that the assembler accepts.  If you have this problem, set the
+     'LANG' environment variable to 'C' or 'En_US'.
+
+   * Even if you specify '-fdollars-in-identifiers', you cannot
+     successfully use '$' in identifiers on the RS/6000 due to a
+     restriction in the IBM assembler.  GAS supports these identifiers.
+
+
+File: gcc.info,  Node: Incompatibilities,  Next: Fixed Headers,  Prev: Interoperation,  Up: Trouble
+
+11.3 Incompatibilities of GCC
+=============================
+
+There are several noteworthy incompatibilities between GNU C and K&R
+(non-ISO) versions of C.
+
+   * GCC normally makes string constants read-only.  If several
+     identical-looking string constants are used, GCC stores only one
+     copy of the string.
+
+     One consequence is that you cannot call 'mktemp' with a string
+     constant argument.  The function 'mktemp' always alters the string
+     its argument points to.
+
+     Another consequence is that 'sscanf' does not work on some very old
+     systems when passed a string constant as its format control string
+     or input.  This is because 'sscanf' incorrectly tries to write into
+     the string constant.  Likewise 'fscanf' and 'scanf'.
+
+     The solution to these problems is to change the program to use
+     'char'-array variables with initialization strings for these
+     purposes instead of string constants.
+
+   * '-2147483648' is positive.
+
+     This is because 2147483648 cannot fit in the type 'int', so
+     (following the ISO C rules) its data type is 'unsigned long int'.
+     Negating this value yields 2147483648 again.
+
+   * GCC does not substitute macro arguments when they appear inside of
+     string constants.  For example, the following macro in GCC
+
+          #define foo(a) "a"
+
+     will produce output '"a"' regardless of what the argument A is.
+
+   * When you use 'setjmp' and 'longjmp', the only automatic variables
+     guaranteed to remain valid are those declared 'volatile'.  This is
+     a consequence of automatic register allocation.  Consider this
+     function:
+
+          jmp_buf j;
+
+          foo ()
+          {
+            int a, b;
+
+            a = fun1 ();
+            if (setjmp (j))
+              return a;
+
+            a = fun2 ();
+            /* 'longjmp (j)' may occur in 'fun3'. */
+            return a + fun3 ();
+          }
+
+     Here 'a' may or may not be restored to its first value when the
+     'longjmp' occurs.  If 'a' is allocated in a register, then its
+     first value is restored; otherwise, it keeps the last value stored
+     in it.
+
+     If you use the '-W' option with the '-O' option, you will get a
+     warning when GCC thinks such a problem might be possible.
+
+   * Programs that use preprocessing directives in the middle of macro
+     arguments do not work with GCC.  For example, a program like this
+     will not work:
+
+          foobar (
+          #define luser
+                  hack)
+
+     ISO C does not permit such a construct.
+
+   * K&R compilers allow comments to cross over an inclusion boundary
+     (i.e. started in an include file and ended in the including file).
+
+   * Declarations of external variables and functions within a block
+     apply only to the block containing the declaration.  In other
+     words, they have the same scope as any other declaration in the
+     same place.
+
+     In some other C compilers, an 'extern' declaration affects all the
+     rest of the file even if it happens within a block.
+
+   * In traditional C, you can combine 'long', etc., with a typedef
+     name, as shown here:
+
+          typedef int foo;
+          typedef long foo bar;
+
+     In ISO C, this is not allowed: 'long' and other type modifiers
+     require an explicit 'int'.
+
+   * PCC allows typedef names to be used as function parameters.
+
+   * Traditional C allows the following erroneous pair of declarations
+     to appear together in a given scope:
+
+          typedef int foo;
+          typedef foo foo;
+
+   * GCC treats all characters of identifiers as significant.  According
+     to K&R-1 (2.2), "No more than the first eight characters are
+     significant, although more may be used.".  Also according to K&R-1
+     (2.2), "An identifier is a sequence of letters and digits; the
+     first character must be a letter.  The underscore _ counts as a
+     letter.", but GCC also allows dollar signs in identifiers.
+
+   * PCC allows whitespace in the middle of compound assignment
+     operators such as '+='.  GCC, following the ISO standard, does not
+     allow this.
+
+   * GCC complains about unterminated character constants inside of
+     preprocessing conditionals that fail.  Some programs have English
+     comments enclosed in conditionals that are guaranteed to fail; if
+     these comments contain apostrophes, GCC will probably report an
+     error.  For example, this code would produce an error:
+
+          #if 0
+          You can't expect this to work.
+          #endif
+
+     The best solution to such a problem is to put the text into an
+     actual C comment delimited by '/*...*/'.
+
+   * Many user programs contain the declaration 'long time ();'.  In the
+     past, the system header files on many systems did not actually
+     declare 'time', so it did not matter what type your program
+     declared it to return.  But in systems with ISO C headers, 'time'
+     is declared to return 'time_t', and if that is not the same as
+     'long', then 'long time ();' is erroneous.
+
+     The solution is to change your program to use appropriate system
+     headers ('<time.h>' on systems with ISO C headers) and not to
+     declare 'time' if the system header files declare it, or failing
+     that to use 'time_t' as the return type of 'time'.
+
+   * When compiling functions that return 'float', PCC converts it to a
+     double.  GCC actually returns a 'float'.  If you are concerned with
+     PCC compatibility, you should declare your functions to return
+     'double'; you might as well say what you mean.
+
+   * When compiling functions that return structures or unions, GCC
+     output code normally uses a method different from that used on most
+     versions of Unix.  As a result, code compiled with GCC cannot call
+     a structure-returning function compiled with PCC, and vice versa.
+
+     The method used by GCC is as follows: a structure or union which is
+     1, 2, 4 or 8 bytes long is returned like a scalar.  A structure or
+     union with any other size is stored into an address supplied by the
+     caller (usually in a special, fixed register, but on some machines
+     it is passed on the stack).  The target hook
+     'TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address.
+
+     By contrast, PCC on most target machines returns structures and
+     unions of any size by copying the data into an area of static
+     storage, and then returning the address of that storage as if it
+     were a pointer value.  The caller must copy the data from that
+     memory area to the place where the value is wanted.  GCC does not
+     use this method because it is slower and nonreentrant.
+
+     On some newer machines, PCC uses a reentrant convention for all
+     structure and union returning.  GCC on most of these machines uses
+     a compatible convention when returning structures and unions in
+     memory, but still returns small structures and unions in registers.
+
+     You can tell GCC to use a compatible convention for all structure
+     and union returning with the option '-fpcc-struct-return'.
+
+   * GCC complains about program fragments such as '0x74ae-0x4000' which
+     appear to be two hexadecimal constants separated by the minus
+     operator.  Actually, this string is a single "preprocessing token".
+     Each such token must correspond to one token in C.  Since this does
+     not, GCC prints an error message.  Although it may appear obvious
+     that what is meant is an operator and two values, the ISO C
+     standard specifically requires that this be treated as erroneous.
+
+     A "preprocessing token" is a "preprocessing number" if it begins
+     with a digit and is followed by letters, underscores, digits,
+     periods and 'e+', 'e-', 'E+', 'E-', 'p+', 'p-', 'P+', or 'P-'
+     character sequences.  (In strict C90 mode, the sequences 'p+',
+     'p-', 'P+' and 'P-' cannot appear in preprocessing numbers.)
+
+     To make the above program fragment valid, place whitespace in front
+     of the minus sign.  This whitespace will end the preprocessing
+     number.
+
+
+File: gcc.info,  Node: Fixed Headers,  Next: Standard Libraries,  Prev: Incompatibilities,  Up: Trouble
+
+11.4 Fixed Header Files
+=======================
+
+GCC needs to install corrected versions of some system header files.
+This is because most target systems have some header files that won't
+work with GCC unless they are changed.  Some have bugs, some are
+incompatible with ISO C, and some depend on special features of other
+compilers.
+
+ Installing GCC automatically creates and installs the fixed header
+files, by running a program called 'fixincludes'.  Normally, you don't
+need to pay attention to this.  But there are cases where it doesn't do
+the right thing automatically.
+
+   * If you update the system's header files, such as by installing a
+     new system version, the fixed header files of GCC are not
+     automatically updated.  They can be updated using the 'mkheaders'
+     script installed in 'LIBEXECDIR/gcc/TARGET/VERSION/install-tools/'.
+
+   * On some systems, header file directories contain machine-specific
+     symbolic links in certain places.  This makes it possible to share
+     most of the header files among hosts running the same version of
+     the system on different machine models.
+
+     The programs that fix the header files do not understand this
+     special way of using symbolic links; therefore, the directory of
+     fixed header files is good only for the machine model used to build
+     it.
+
+     It is possible to make separate sets of fixed header files for the
+     different machine models, and arrange a structure of symbolic links
+     so as to use the proper set, but you'll have to do this by hand.
+
+
+File: gcc.info,  Node: Standard Libraries,  Next: Disappointments,  Prev: Fixed Headers,  Up: Trouble
+
+11.5 Standard Libraries
+=======================
+
+GCC by itself attempts to be a conforming freestanding implementation.
+*Note Language Standards Supported by GCC: Standards, for details of
+what this means.  Beyond the library facilities required of such an
+implementation, the rest of the C library is supplied by the vendor of
+the operating system.  If that C library doesn't conform to the C
+standards, then your programs might get warnings (especially when using
+'-Wall') that you don't expect.
+
+ For example, the 'sprintf' function on SunOS 4.1.3 returns 'char *'
+while the C standard says that 'sprintf' returns an 'int'.  The
+'fixincludes' program could make the prototype for this function match
+the Standard, but that would be wrong, since the function will still
+return 'char *'.
+
+ If you need a Standard compliant library, then you need to find one, as
+GCC does not provide one.  The GNU C library (called 'glibc') provides
+ISO C, POSIX, BSD, SystemV and X/Open compatibility for GNU/Linux and
+HURD-based GNU systems; no recent version of it supports other systems,
+though some very old versions did.  Version 2.2 of the GNU C library
+includes nearly complete C99 support.  You could also ask your operating
+system vendor if newer libraries are available.
+
+
+File: gcc.info,  Node: Disappointments,  Next: C++ Misunderstandings,  Prev: Standard Libraries,  Up: Trouble
+
+11.6 Disappointments and Misunderstandings
+==========================================
+
+These problems are perhaps regrettable, but we don't know any practical
+way around them.
+
+   * Certain local variables aren't recognized by debuggers when you
+     compile with optimization.
+
+     This occurs because sometimes GCC optimizes the variable out of
+     existence.  There is no way to tell the debugger how to compute the
+     value such a variable "would have had", and it is not clear that
+     would be desirable anyway.  So GCC simply does not mention the
+     eliminated variable when it writes debugging information.
+
+     You have to expect a certain amount of disagreement between the
+     executable and your source code, when you use optimization.
+
+   * Users often think it is a bug when GCC reports an error for code
+     like this:
+
+          int foo (struct mumble *);
+
+          struct mumble { ... };
+
+          int foo (struct mumble *x)
+          { ... }
+
+     This code really is erroneous, because the scope of 'struct mumble'
+     in the prototype is limited to the argument list containing it.  It
+     does not refer to the 'struct mumble' defined with file scope
+     immediately below--they are two unrelated types with similar names
+     in different scopes.
+
+     But in the definition of 'foo', the file-scope type is used because
+     that is available to be inherited.  Thus, the definition and the
+     prototype do not match, and you get an error.
+
+     This behavior may seem silly, but it's what the ISO standard
+     specifies.  It is easy enough for you to make your code work by
+     moving the definition of 'struct mumble' above the prototype.  It's
+     not worth being incompatible with ISO C just to avoid an error for
+     the example shown above.
+
+   * Accesses to bit-fields even in volatile objects works by accessing
+     larger objects, such as a byte or a word.  You cannot rely on what
+     size of object is accessed in order to read or write the bit-field;
+     it may even vary for a given bit-field according to the precise
+     usage.
+
+     If you care about controlling the amount of memory that is
+     accessed, use volatile but do not use bit-fields.
+
+   * GCC comes with shell scripts to fix certain known problems in
+     system header files.  They install corrected copies of various
+     header files in a special directory where only GCC will normally
+     look for them.  The scripts adapt to various systems by searching
+     all the system header files for the problem cases that we know
+     about.
+
+     If new system header files are installed, nothing automatically
+     arranges to update the corrected header files.  They can be updated
+     using the 'mkheaders' script installed in
+     'LIBEXECDIR/gcc/TARGET/VERSION/install-tools/'.
+
+   * On 68000 and x86 systems, for instance, you can get paradoxical
+     results if you test the precise values of floating point numbers.
+     For example, you can find that a floating point value which is not
+     a NaN is not equal to itself.  This results from the fact that the
+     floating point registers hold a few more bits of precision than fit
+     in a 'double' in memory.  Compiled code moves values between memory
+     and floating point registers at its convenience, and moving them
+     into memory truncates them.
+
+     You can partially avoid this problem by using the '-ffloat-store'
+     option (*note Optimize Options::).
+
+   * On AIX and other platforms without weak symbol support, templates
+     need to be instantiated explicitly and symbols for static members
+     of templates will not be generated.
+
+   * On AIX, GCC scans object files and library archives for static
+     constructors and destructors when linking an application before the
+     linker prunes unreferenced symbols.  This is necessary to prevent
+     the AIX linker from mistakenly assuming that static constructor or
+     destructor are unused and removing them before the scanning can
+     occur.  All static constructors and destructors found will be
+     referenced even though the modules in which they occur may not be
+     used by the program.  This may lead to both increased executable
+     size and unexpected symbol references.
+
+
+File: gcc.info,  Node: C++ Misunderstandings,  Next: Non-bugs,  Prev: Disappointments,  Up: Trouble
+
+11.7 Common Misunderstandings with GNU C++
+==========================================
+
+C++ is a complex language and an evolving one, and its standard
+definition (the ISO C++ standard) was only recently completed.  As a
+result, your C++ compiler may occasionally surprise you, even when its
+behavior is correct.  This section discusses some areas that frequently
+give rise to questions of this sort.
+
+* Menu:
+
+* Static Definitions::  Static member declarations are not definitions
+* Name lookup::         Name lookup, templates, and accessing members of base classes
+* Temporaries::         Temporaries may vanish before you expect
+* Copy Assignment::     Copy Assignment operators copy virtual bases twice
+
+
+File: gcc.info,  Node: Static Definitions,  Next: Name lookup,  Up: C++ Misunderstandings
+
+11.7.1 Declare _and_ Define Static Members
+------------------------------------------
+
+When a class has static data members, it is not enough to _declare_ the
+static member; you must also _define_ it.  For example:
+
+     class Foo
+     {
+       ...
+       void method();
+       static int bar;
+     };
+
+ This declaration only establishes that the class 'Foo' has an 'int'
+named 'Foo::bar', and a member function named 'Foo::method'.  But you
+still need to define _both_ 'method' and 'bar' elsewhere.  According to
+the ISO standard, you must supply an initializer in one (and only one)
+source file, such as:
+
+     int Foo::bar = 0;
+
+ Other C++ compilers may not correctly implement the standard behavior.
+As a result, when you switch to 'g++' from one of these compilers, you
+may discover that a program that appeared to work correctly in fact does
+not conform to the standard: 'g++' reports as undefined symbols any
+static data members that lack definitions.
+
+
+File: gcc.info,  Node: Name lookup,  Next: Temporaries,  Prev: Static Definitions,  Up: C++ Misunderstandings
+
+11.7.2 Name lookup, templates, and accessing members of base classes
+--------------------------------------------------------------------
+
+The C++ standard prescribes that all names that are not dependent on
+template parameters are bound to their present definitions when parsing
+a template function or class.(1)  Only names that are dependent are
+looked up at the point of instantiation.  For example, consider
+
+       void foo(double);
+
+       struct A {
+         template <typename T>
+         void f () {
+           foo (1);        // 1
+           int i = N;      // 2
+           T t;
+           t.bar();        // 3
+           foo (t);        // 4
+         }
+
+         static const int N;
+       };
+
+ Here, the names 'foo' and 'N' appear in a context that does not depend
+on the type of 'T'.  The compiler will thus require that they are
+defined in the context of use in the template, not only before the point
+of instantiation, and will here use '::foo(double)' and 'A::N',
+respectively.  In particular, it will convert the integer value to a
+'double' when passing it to '::foo(double)'.
+
+ Conversely, 'bar' and the call to 'foo' in the fourth marked line are
+used in contexts that do depend on the type of 'T', so they are only
+looked up at the point of instantiation, and you can provide
+declarations for them after declaring the template, but before
+instantiating it.  In particular, if you instantiate 'A::f<int>', the
+last line will call an overloaded '::foo(int)' if one was provided, even
+if after the declaration of 'struct A'.
+
+ This distinction between lookup of dependent and non-dependent names is
+called two-stage (or dependent) name lookup.  G++ implements it since
+version 3.4.
+
+ Two-stage name lookup sometimes leads to situations with behavior
+different from non-template codes.  The most common is probably this:
+
+       template <typename T> struct Base {
+         int i;
+       };
+
+       template <typename T> struct Derived : public Base<T> {
+         int get_i() { return i; }
+       };
+
+ In 'get_i()', 'i' is not used in a dependent context, so the compiler
+will look for a name declared at the enclosing namespace scope (which is
+the global scope here).  It will not look into the base class, since
+that is dependent and you may declare specializations of 'Base' even
+after declaring 'Derived', so the compiler can't really know what 'i'
+would refer to.  If there is no global variable 'i', then you will get
+an error message.
+
+ In order to make it clear that you want the member of the base class,
+you need to defer lookup until instantiation time, at which the base
+class is known.  For this, you need to access 'i' in a dependent
+context, by either using 'this->i' (remember that 'this' is of type
+'Derived<T>*', so is obviously dependent), or using 'Base<T>::i'.
+Alternatively, 'Base<T>::i' might be brought into scope by a
+'using'-declaration.
+
+ Another, similar example involves calling member functions of a base
+class:
+
+       template <typename T> struct Base {
+           int f();
+       };
+
+       template <typename T> struct Derived : Base<T> {
+           int g() { return f(); };
+       };
+
+ Again, the call to 'f()' is not dependent on template arguments (there
+are no arguments that depend on the type 'T', and it is also not
+otherwise specified that the call should be in a dependent context).
+Thus a global declaration of such a function must be available, since
+the one in the base class is not visible until instantiation time.  The
+compiler will consequently produce the following error message:
+
+       x.cc: In member function `int Derived<T>::g()':
+       x.cc:6: error: there are no arguments to `f' that depend on a template
+          parameter, so a declaration of `f' must be available
+       x.cc:6: error: (if you use `-fpermissive', G++ will accept your code, but
+          allowing the use of an undeclared name is deprecated)
+
+ To make the code valid either use 'this->f()', or 'Base<T>::f()'.
+Using the '-fpermissive' flag will also let the compiler accept the
+code, by marking all function calls for which no declaration is visible
+at the time of definition of the template for later lookup at
+instantiation time, as if it were a dependent call.  We do not recommend
+using '-fpermissive' to work around invalid code, and it will also only
+catch cases where functions in base classes are called, not where
+variables in base classes are used (as in the example above).
+
+ Note that some compilers (including G++ versions prior to 3.4) get
+these examples wrong and accept above code without an error.  Those
+compilers do not implement two-stage name lookup correctly.
+
+   ---------- Footnotes ----------
+
+   (1) The C++ standard just uses the term "dependent" for names that
+depend on the type or value of template parameters.  This shorter term
+will also be used in the rest of this section.
+
+
+File: gcc.info,  Node: Temporaries,  Next: Copy Assignment,  Prev: Name lookup,  Up: C++ Misunderstandings
+
+11.7.3 Temporaries May Vanish Before You Expect
+-----------------------------------------------
+
+It is dangerous to use pointers or references to _portions_ of a
+temporary object.  The compiler may very well delete the object before
+you expect it to, leaving a pointer to garbage.  The most common place
+where this problem crops up is in classes like string classes,
+especially ones that define a conversion function to type 'char *' or
+'const char *'--which is one reason why the standard 'string' class
+requires you to call the 'c_str' member function.  However, any class
+that returns a pointer to some internal structure is potentially subject
+to this problem.
+
+ For example, a program may use a function 'strfunc' that returns
+'string' objects, and another function 'charfunc' that operates on
+pointers to 'char':
+
+     string strfunc ();
+     void charfunc (const char *);
+
+     void
+     f ()
+     {
+       const char *p = strfunc().c_str();
+       ...
+       charfunc (p);
+       ...
+       charfunc (p);
+     }
+
+In this situation, it may seem reasonable to save a pointer to the C
+string returned by the 'c_str' member function and use that rather than
+call 'c_str' repeatedly.  However, the temporary string created by the
+call to 'strfunc' is destroyed after 'p' is initialized, at which point
+'p' is left pointing to freed memory.
+
+ Code like this may run successfully under some other compilers,
+particularly obsolete cfront-based compilers that delete temporaries
+along with normal local variables.  However, the GNU C++ behavior is
+standard-conforming, so if your program depends on late destruction of
+temporaries it is not portable.
+
+ The safe way to write such code is to give the temporary a name, which
+forces it to remain until the end of the scope of the name.  For
+example:
+
+     const string& tmp = strfunc ();
+     charfunc (tmp.c_str ());
+
+
+File: gcc.info,  Node: Copy Assignment,  Prev: Temporaries,  Up: C++ Misunderstandings
+
+11.7.4 Implicit Copy-Assignment for Virtual Bases
+-------------------------------------------------
+
+When a base class is virtual, only one subobject of the base class
+belongs to each full object.  Also, the constructors and destructors are
+invoked only once, and called from the most-derived class.  However,
+such objects behave unspecified when being assigned.  For example:
+
+     struct Base{
+       char *name;
+       Base(char *n) : name(strdup(n)){}
+       Base& operator= (const Base& other){
+        free (name);
+        name = strdup (other.name);
+       }
+     };
+
+     struct A:virtual Base{
+       int val;
+       A():Base("A"){}
+     };
+
+     struct B:virtual Base{
+       int bval;
+       B():Base("B"){}
+     };
+
+     struct Derived:public A, public B{
+       Derived():Base("Derived"){}
+     };
+
+     void func(Derived &d1, Derived &d2)
+     {
+       d1 = d2;
+     }
+
+ The C++ standard specifies that 'Base::Base' is only called once when
+constructing or copy-constructing a Derived object.  It is unspecified
+whether 'Base::operator=' is called more than once when the implicit
+copy-assignment for Derived objects is invoked (as it is inside 'func'
+in the example).
+
+ G++ implements the "intuitive" algorithm for copy-assignment: assign
+all direct bases, then assign all members.  In that algorithm, the
+virtual base subobject can be encountered more than once.  In the
+example, copying proceeds in the following order: 'val', 'name' (via
+'strdup'), 'bval', and 'name' again.
+
+ If application code relies on copy-assignment, a user-defined
+copy-assignment operator removes any uncertainties.  With such an
+operator, the application can define whether and how the virtual base
+subobject is assigned.
+
+
+File: gcc.info,  Node: Non-bugs,  Next: Warnings and Errors,  Prev: C++ Misunderstandings,  Up: Trouble
+
+11.8 Certain Changes We Don't Want to Make
+==========================================
+
+This section lists changes that people frequently request, but which we
+do not make because we think GCC is better without them.
+
+   * Checking the number and type of arguments to a function which has
+     an old-fashioned definition and no prototype.
+
+     Such a feature would work only occasionally--only for calls that
+     appear in the same file as the called function, following the
+     definition.  The only way to check all calls reliably is to add a
+     prototype for the function.  But adding a prototype eliminates the
+     motivation for this feature.  So the feature is not worthwhile.
+
+   * Warning about using an expression whose type is signed as a shift
+     count.
+
+     Shift count operands are probably signed more often than unsigned.
+     Warning about this would cause far more annoyance than good.
+
+   * Warning about assigning a signed value to an unsigned variable.
+
+     Such assignments must be very common; warning about them would
+     cause more annoyance than good.
+
+   * Warning when a non-void function value is ignored.
+
+     C contains many standard functions that return a value that most
+     programs choose to ignore.  One obvious example is 'printf'.
+     Warning about this practice only leads the defensive programmer to
+     clutter programs with dozens of casts to 'void'.  Such casts are
+     required so frequently that they become visual noise.  Writing
+     those casts becomes so automatic that they no longer convey useful
+     information about the intentions of the programmer.  For functions
+     where the return value should never be ignored, use the
+     'warn_unused_result' function attribute (*note Function
+     Attributes::).
+
+   * Making '-fshort-enums' the default.
+
+     This would cause storage layout to be incompatible with most other
+     C compilers.  And it doesn't seem very important, given that you
+     can get the same result in other ways.  The case where it matters
+     most is when the enumeration-valued object is inside a structure,
+     and in that case you can specify a field width explicitly.
+
+   * Making bit-fields unsigned by default on particular machines where
+     "the ABI standard" says to do so.
+
+     The ISO C standard leaves it up to the implementation whether a
+     bit-field declared plain 'int' is signed or not.  This in effect
+     creates two alternative dialects of C.
+
+     The GNU C compiler supports both dialects; you can specify the
+     signed dialect with '-fsigned-bitfields' and the unsigned dialect
+     with '-funsigned-bitfields'.  However, this leaves open the
+     question of which dialect to use by default.
+
+     Currently, the preferred dialect makes plain bit-fields signed,
+     because this is simplest.  Since 'int' is the same as 'signed int'
+     in every other context, it is cleanest for them to be the same in
+     bit-fields as well.
+
+     Some computer manufacturers have published Application Binary
+     Interface standards which specify that plain bit-fields should be
+     unsigned.  It is a mistake, however, to say anything about this
+     issue in an ABI.  This is because the handling of plain bit-fields
+     distinguishes two dialects of C.  Both dialects are meaningful on
+     every type of machine.  Whether a particular object file was
+     compiled using signed bit-fields or unsigned is of no concern to
+     other object files, even if they access the same bit-fields in the
+     same data structures.
+
+     A given program is written in one or the other of these two
+     dialects.  The program stands a chance to work on most any machine
+     if it is compiled with the proper dialect.  It is unlikely to work
+     at all if compiled with the wrong dialect.
+
+     Many users appreciate the GNU C compiler because it provides an
+     environment that is uniform across machines.  These users would be
+     inconvenienced if the compiler treated plain bit-fields differently
+     on certain machines.
+
+     Occasionally users write programs intended only for a particular
+     machine type.  On these occasions, the users would benefit if the
+     GNU C compiler were to support by default the same dialect as the
+     other compilers on that machine.  But such applications are rare.
+     And users writing a program to run on more than one type of machine
+     cannot possibly benefit from this kind of compatibility.
+
+     This is why GCC does and will treat plain bit-fields in the same
+     fashion on all types of machines (by default).
+
+     There are some arguments for making bit-fields unsigned by default
+     on all machines.  If, for example, this becomes a universal de
+     facto standard, it would make sense for GCC to go along with it.
+     This is something to be considered in the future.
+
+     (Of course, users strongly concerned about portability should
+     indicate explicitly in each bit-field whether it is signed or not.
+     In this way, they write programs which have the same meaning in
+     both C dialects.)
+
+   * Undefining '__STDC__' when '-ansi' is not used.
+
+     Currently, GCC defines '__STDC__' unconditionally.  This provides
+     good results in practice.
+
+     Programmers normally use conditionals on '__STDC__' to ask whether
+     it is safe to use certain features of ISO C, such as function
+     prototypes or ISO token concatenation.  Since plain 'gcc' supports
+     all the features of ISO C, the correct answer to these questions is
+     "yes".
+
+     Some users try to use '__STDC__' to check for the availability of
+     certain library facilities.  This is actually incorrect usage in an
+     ISO C program, because the ISO C standard says that a conforming
+     freestanding implementation should define '__STDC__' even though it
+     does not have the library facilities.  'gcc -ansi -pedantic' is a
+     conforming freestanding implementation, and it is therefore
+     required to define '__STDC__', even though it does not come with an
+     ISO C library.
+
+     Sometimes people say that defining '__STDC__' in a compiler that
+     does not completely conform to the ISO C standard somehow violates
+     the standard.  This is illogical.  The standard is a standard for
+     compilers that claim to support ISO C, such as 'gcc -ansi'--not for
+     other compilers such as plain 'gcc'.  Whatever the ISO C standard
+     says is relevant to the design of plain 'gcc' without '-ansi' only
+     for pragmatic reasons, not as a requirement.
+
+     GCC normally defines '__STDC__' to be 1, and in addition defines
+     '__STRICT_ANSI__' if you specify the '-ansi' option, or a '-std'
+     option for strict conformance to some version of ISO C.  On some
+     hosts, system include files use a different convention, where
+     '__STDC__' is normally 0, but is 1 if the user specifies strict
+     conformance to the C Standard.  GCC follows the host convention
+     when processing system include files, but when processing user
+     files it follows the usual GNU C convention.
+
+   * Undefining '__STDC__' in C++.
+
+     Programs written to compile with C++-to-C translators get the value
+     of '__STDC__' that goes with the C compiler that is subsequently
+     used.  These programs must test '__STDC__' to determine what kind
+     of C preprocessor that compiler uses: whether they should
+     concatenate tokens in the ISO C fashion or in the traditional
+     fashion.
+
+     These programs work properly with GNU C++ if '__STDC__' is defined.
+     They would not work otherwise.
+
+     In addition, many header files are written to provide prototypes in
+     ISO C but not in traditional C.  Many of these header files can
+     work without change in C++ provided '__STDC__' is defined.  If
+     '__STDC__' is not defined, they will all fail, and will all need to
+     be changed to test explicitly for C++ as well.
+
+   * Deleting "empty" loops.
+
+     Historically, GCC has not deleted "empty" loops under the
+     assumption that the most likely reason you would put one in a
+     program is to have a delay, so deleting them will not make real
+     programs run any faster.
+
+     However, the rationale here is that optimization of a nonempty loop
+     cannot produce an empty one.  This held for carefully written C
+     compiled with less powerful optimizers but is not always the case
+     for carefully written C++ or with more powerful optimizers.  Thus
+     GCC will remove operations from loops whenever it can determine
+     those operations are not externally visible (apart from the time
+     taken to execute them, of course).  In case the loop can be proved
+     to be finite, GCC will also remove the loop itself.
+
+     Be aware of this when performing timing tests, for instance the
+     following loop can be completely removed, provided
+     'some_expression' can provably not change any global state.
+
+          {
+             int sum = 0;
+             int ix;
+
+             for (ix = 0; ix != 10000; ix++)
+                sum += some_expression;
+          }
+
+     Even though 'sum' is accumulated in the loop, no use is made of
+     that summation, so the accumulation can be removed.
+
+   * Making side effects happen in the same order as in some other
+     compiler.
+
+     It is never safe to depend on the order of evaluation of side
+     effects.  For example, a function call like this may very well
+     behave differently from one compiler to another:
+
+          void func (int, int);
+
+          int i = 2;
+          func (i++, i++);
+
+     There is no guarantee (in either the C or the C++ standard language
+     definitions) that the increments will be evaluated in any
+     particular order.  Either increment might happen first.  'func'
+     might get the arguments '2, 3', or it might get '3, 2', or even '2,
+     2'.
+
+   * Making certain warnings into errors by default.
+
+     Some ISO C testsuites report failure when the compiler does not
+     produce an error message for a certain program.
+
+     ISO C requires a "diagnostic" message for certain kinds of invalid
+     programs, but a warning is defined by GCC to count as a diagnostic.
+     If GCC produces a warning but not an error, that is correct ISO C
+     support.  If testsuites call this "failure", they should be run
+     with the GCC option '-pedantic-errors', which will turn these
+     warnings into errors.
+
+
+File: gcc.info,  Node: Warnings and Errors,  Prev: Non-bugs,  Up: Trouble
+
+11.9 Warning Messages and Error Messages
+========================================
+
+The GNU compiler can produce two kinds of diagnostics: errors and
+warnings.  Each kind has a different purpose:
+
+     "Errors" report problems that make it impossible to compile your
+     program.  GCC reports errors with the source file name and line
+     number where the problem is apparent.
+
+     "Warnings" report other unusual conditions in your code that _may_
+     indicate a problem, although compilation can (and does) proceed.
+     Warning messages also report the source file name and line number,
+     but include the text 'warning:' to distinguish them from error
+     messages.
+
+ Warnings may indicate danger points where you should check to make sure
+that your program really does what you intend; or the use of obsolete
+features; or the use of nonstandard features of GNU C or C++.  Many
+warnings are issued only if you ask for them, with one of the '-W'
+options (for instance, '-Wall' requests a variety of useful warnings).
+
+ GCC always tries to compile your program if possible; it never
+gratuitously rejects a program whose meaning is clear merely because
+(for instance) it fails to conform to a standard.  In some cases,
+however, the C and C++ standards specify that certain extensions are
+forbidden, and a diagnostic _must_ be issued by a conforming compiler.
+The '-pedantic' option tells GCC to issue warnings in such cases;
+'-pedantic-errors' says to make them errors instead.  This does not mean
+that _all_ non-ISO constructs get warnings or errors.
+
+ *Note Options to Request or Suppress Warnings: Warning Options, for
+more detail on these and related command-line options.
+
+
+File: gcc.info,  Node: Bugs,  Next: Service,  Prev: Trouble,  Up: Top
+
+12 Reporting Bugs
+*****************
+
+Your bug reports play an essential role in making GCC reliable.
+
+ When you encounter a problem, the first thing to do is to see if it is
+already known.  *Note Trouble::.  If it isn't known, then you should
+report the problem.
+
+* Menu:
+
+* Criteria:  Bug Criteria.   Have you really found a bug?
+* Reporting: Bug Reporting.  How to report a bug effectively.
+
+
+File: gcc.info,  Node: Bug Criteria,  Next: Bug Reporting,  Up: Bugs
+
+12.1 Have You Found a Bug?
+==========================
+
+If you are not sure whether you have found a bug, here are some
+guidelines:
+
+   * If the compiler gets a fatal signal, for any input whatever, that
+     is a compiler bug.  Reliable compilers never crash.
+
+   * If the compiler produces invalid assembly code, for any input
+     whatever (except an 'asm' statement), that is a compiler bug,
+     unless the compiler reports errors (not just warnings) which would
+     ordinarily prevent the assembler from being run.
+
+   * If the compiler produces valid assembly code that does not
+     correctly execute the input source code, that is a compiler bug.
+
+     However, you must double-check to make sure, because you may have a
+     program whose behavior is undefined, which happened by chance to
+     give the desired results with another C or C++ compiler.
+
+     For example, in many nonoptimizing compilers, you can write 'x;' at
+     the end of a function instead of 'return x;', with the same
+     results.  But the value of the function is undefined if 'return' is
+     omitted; it is not a bug when GCC produces different results.
+
+     Problems often result from expressions with two increment
+     operators, as in 'f (*p++, *p++)'.  Your previous compiler might
+     have interpreted that expression the way you intended; GCC might
+     interpret it another way.  Neither compiler is wrong.  The bug is
+     in your code.
+
+     After you have localized the error to a single source line, it
+     should be easy to check for these things.  If your program is
+     correct and well defined, you have found a compiler bug.
+
+   * If the compiler produces an error message for valid input, that is
+     a compiler bug.
+
+   * If the compiler does not produce an error message for invalid
+     input, that is a compiler bug.  However, you should note that your
+     idea of "invalid input" might be someone else's idea of "an
+     extension" or "support for traditional practice".
+
+   * If you are an experienced user of one of the languages GCC
+     supports, your suggestions for improvement of GCC are welcome in
+     any case.
+
+
+File: gcc.info,  Node: Bug Reporting,  Prev: Bug Criteria,  Up: Bugs
+
+12.2 How and where to Report Bugs
+=================================
+
+Bugs should be reported to the bug database at
+<http://gcc.gnu.org/bugs.html>.
+
+
+File: gcc.info,  Node: Service,  Next: Contributing,  Prev: Bugs,  Up: Top
+
+13 How To Get Help with GCC
+***************************
+
+If you need help installing, using or changing GCC, there are two ways
+to find it:
+
+   * Send a message to a suitable network mailing list.  First try
+     <gcc-help@gcc.gnu.org> (for help installing or using GCC), and if
+     that brings no response, try <gcc@gcc.gnu.org>.  For help changing
+     GCC, ask <gcc@gcc.gnu.org>.  If you think you have found a bug in
+     GCC, please report it following the instructions at *note Bug
+     Reporting::.
+
+   * Look in the service directory for someone who might help you for a
+     fee.  The service directory is found at
+     <http://www.fsf.org/resources/service>.
+
+ For further information, see <http://gcc.gnu.org/faq.html#support>.
+
+
+File: gcc.info,  Node: Contributing,  Next: Funding,  Prev: Service,  Up: Top
+
+14 Contributing to GCC Development
+**********************************
+
+If you would like to help pretest GCC releases to assure they work well,
+current development sources are available by SVN (see
+<http://gcc.gnu.org/svn.html>).  Source and binary snapshots are also
+available for FTP; see <http://gcc.gnu.org/snapshots.html>.
+
+ If you would like to work on improvements to GCC, please read the
+advice at these URLs:
+
+     <http://gcc.gnu.org/contribute.html>
+     <http://gcc.gnu.org/contributewhy.html>
+
+for information on how to make useful contributions and avoid
+duplication of effort.  Suggested projects are listed at
+<http://gcc.gnu.org/projects/>.
+
+
+File: gcc.info,  Node: Funding,  Next: GNU Project,  Prev: Contributing,  Up: Top
+
+Funding Free Software
+*********************
+
+If you want to have more free software a few years from now, it makes
+sense for you to help encourage people to contribute funds for its
+development.  The most effective approach known is to encourage
+commercial redistributors to donate.
+
+ Users of free software systems can boost the pace of development by
+encouraging for-a-fee distributors to donate part of their selling price
+to free software developers--the Free Software Foundation, and others.
+
+ The way to convince distributors to do this is to demand it and expect
+it from them.  So when you compare distributors, judge them partly by
+how much they give to free software development.  Show distributors they
+must compete to be the one who gives the most.
+
+ To make this approach work, you must insist on numbers that you can
+compare, such as, "We will donate ten dollars to the Frobnitz project
+for each disk sold."  Don't be satisfied with a vague promise, such as
+"A portion of the profits are donated," since it doesn't give a basis
+for comparison.
+
+ Even a precise fraction "of the profits from this disk" is not very
+meaningful, since creative accounting and unrelated business decisions
+can greatly alter what fraction of the sales price counts as profit.  If
+the price you pay is $50, ten percent of the profit is probably less
+than a dollar; it might be a few cents, or nothing at all.
+
+ Some redistributors do development work themselves.  This is useful
+too; but to keep everyone honest, you need to inquire how much they do,
+and what kind.  Some kinds of development make much more long-term
+difference than others.  For example, maintaining a separate version of
+a program contributes very little; maintaining the standard version of a
+program for the whole community contributes much.  Easy new ports
+contribute little, since someone else would surely do them; difficult
+ports such as adding a new CPU to the GNU Compiler Collection contribute
+more; major new features or packages contribute the most.
+
+ By establishing the idea that supporting further development is "the
+proper thing to do" when distributing free software for a fee, we can
+assure a steady flow of resources into making more free software.
+
+     Copyright (C) 1994 Free Software Foundation, Inc.
+     Verbatim copying and redistribution of this section is permitted
+     without royalty; alteration is not permitted.
+
+
+File: gcc.info,  Node: GNU Project,  Next: Copying,  Prev: Funding,  Up: Top
+
+The GNU Project and GNU/Linux
+*****************************
+
+The GNU Project was launched in 1984 to develop a complete Unix-like
+operating system which is free software: the GNU system.  (GNU is a
+recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".)
+Variants of the GNU operating system, which use the kernel Linux, are
+now widely used; though these systems are often referred to as "Linux",
+they are more accurately called GNU/Linux systems.
+
+ For more information, see:
+     <http://www.gnu.org/>
+     <http://www.gnu.org/gnu/linux-and-gnu.html>
+
+
+File: gcc.info,  Node: Copying,  Next: GNU Free Documentation License,  Prev: GNU Project,  Up: Top
+
+GNU General Public License
+**************************
+
+                        Version 3, 29 June 2007
+
+     Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+
+     Everyone is permitted to copy and distribute verbatim copies of this
+     license document, but changing it is not allowed.
+
+Preamble
+========
+
+The GNU General Public License is a free, copyleft license for software
+and other kinds of works.
+
+ The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program-to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not price.
+Our General Public Licenses are designed to make sure that you have the
+freedom to distribute copies of free software (and charge for them if
+you wish), that you receive source code or can get it if you want it,
+that you can change the software or use pieces of it in new free
+programs, and that you know you can do these things.
+
+ To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+ For example, if you distribute copies of such a program, whether gratis
+or for a fee, you must pass on to the recipients the same freedoms that
+you received.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+ Developers that use the GNU GPL protect your rights with two steps: (1)
+assert copyright on the software, and (2) offer you this License giving
+you legal permission to copy, distribute and/or modify it.
+
+ For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+ Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+ Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+TERMS AND CONDITIONS
+====================
+
+  0. Definitions.
+
+     "This License" refers to version 3 of the GNU General Public
+     License.
+
+     "Copyright" also means copyright-like laws that apply to other
+     kinds of works, such as semiconductor masks.
+
+     "The Program" refers to any copyrightable work licensed under this
+     License.  Each licensee is addressed as "you".  "Licensees" and
+     "recipients" may be individuals or organizations.
+
+     To "modify" a work means to copy from or adapt all or part of the
+     work in a fashion requiring copyright permission, other than the
+     making of an exact copy.  The resulting work is called a "modified
+     version" of the earlier work or a work "based on" the earlier work.
+
+     A "covered work" means either the unmodified Program or a work
+     based on the Program.
+
+     To "propagate" a work means to do anything with it that, without
+     permission, would make you directly or secondarily liable for
+     infringement under applicable copyright law, except executing it on
+     a computer or modifying a private copy.  Propagation includes
+     copying, distribution (with or without modification), making
+     available to the public, and in some countries other activities as
+     well.
+
+     To "convey" a work means any kind of propagation that enables other
+     parties to make or receive copies.  Mere interaction with a user
+     through a computer network, with no transfer of a copy, is not
+     conveying.
+
+     An interactive user interface displays "Appropriate Legal Notices"
+     to the extent that it includes a convenient and prominently visible
+     feature that (1) displays an appropriate copyright notice, and (2)
+     tells the user that there is no warranty for the work (except to
+     the extent that warranties are provided), that licensees may convey
+     the work under this License, and how to view a copy of this
+     License.  If the interface presents a list of user commands or
+     options, such as a menu, a prominent item in the list meets this
+     criterion.
+
+  1. Source Code.
+
+     The "source code" for a work means the preferred form of the work
+     for making modifications to it.  "Object code" means any non-source
+     form of a work.
+
+     A "Standard Interface" means an interface that either is an
+     official standard defined by a recognized standards body, or, in
+     the case of interfaces specified for a particular programming
+     language, one that is widely used among developers working in that
+     language.
+
+     The "System Libraries" of an executable work include anything,
+     other than the work as a whole, that (a) is included in the normal
+     form of packaging a Major Component, but which is not part of that
+     Major Component, and (b) serves only to enable use of the work with
+     that Major Component, or to implement a Standard Interface for
+     which an implementation is available to the public in source code
+     form.  A "Major Component", in this context, means a major
+     essential component (kernel, window system, and so on) of the
+     specific operating system (if any) on which the executable work
+     runs, or a compiler used to produce the work, or an object code
+     interpreter used to run it.
+
+     The "Corresponding Source" for a work in object code form means all
+     the source code needed to generate, install, and (for an executable
+     work) run the object code and to modify the work, including scripts
+     to control those activities.  However, it does not include the
+     work's System Libraries, or general-purpose tools or generally
+     available free programs which are used unmodified in performing
+     those activities but which are not part of the work.  For example,
+     Corresponding Source includes interface definition files associated
+     with source files for the work, and the source code for shared
+     libraries and dynamically linked subprograms that the work is
+     specifically designed to require, such as by intimate data
+     communication or control flow between those subprograms and other
+     parts of the work.
+
+     The Corresponding Source need not include anything that users can
+     regenerate automatically from other parts of the Corresponding
+     Source.
+
+     The Corresponding Source for a work in source code form is that
+     same work.
+
+  2. Basic Permissions.
+
+     All rights granted under this License are granted for the term of
+     copyright on the Program, and are irrevocable provided the stated
+     conditions are met.  This License explicitly affirms your unlimited
+     permission to run the unmodified Program.  The output from running
+     a covered work is covered by this License only if the output, given
+     its content, constitutes a covered work.  This License acknowledges
+     your rights of fair use or other equivalent, as provided by
+     copyright law.
+
+     You may make, run and propagate covered works that you do not
+     convey, without conditions so long as your license otherwise
+     remains in force.  You may convey covered works to others for the
+     sole purpose of having them make modifications exclusively for you,
+     or provide you with facilities for running those works, provided
+     that you comply with the terms of this License in conveying all
+     material for which you do not control copyright.  Those thus making
+     or running the covered works for you must do so exclusively on your
+     behalf, under your direction and control, on terms that prohibit
+     them from making any copies of your copyrighted material outside
+     their relationship with you.
+
+     Conveying under any other circumstances is permitted solely under
+     the conditions stated below.  Sublicensing is not allowed; section
+     10 makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+     No covered work shall be deemed part of an effective technological
+     measure under any applicable law fulfilling obligations under
+     article 11 of the WIPO copyright treaty adopted on 20 December
+     1996, or similar laws prohibiting or restricting circumvention of
+     such measures.
+
+     When you convey a covered work, you waive any legal power to forbid
+     circumvention of technological measures to the extent such
+     circumvention is effected by exercising rights under this License
+     with respect to the covered work, and you disclaim any intention to
+     limit operation or modification of the work as a means of
+     enforcing, against the work's users, your or third parties' legal
+     rights to forbid circumvention of technological measures.
+
+  4. Conveying Verbatim Copies.
+
+     You may convey verbatim copies of the Program's source code as you
+     receive it, in any medium, provided that you conspicuously and
+     appropriately publish on each copy an appropriate copyright notice;
+     keep intact all notices stating that this License and any
+     non-permissive terms added in accord with section 7 apply to the
+     code; keep intact all notices of the absence of any warranty; and
+     give all recipients a copy of this License along with the Program.
+
+     You may charge any price or no price for each copy that you convey,
+     and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+     You may convey a work based on the Program, or the modifications to
+     produce it from the Program, in the form of source code under the
+     terms of section 4, provided that you also meet all of these
+     conditions:
+
+       a. The work must carry prominent notices stating that you
+          modified it, and giving a relevant date.
+
+       b. The work must carry prominent notices stating that it is
+          released under this License and any conditions added under
+          section 7.  This requirement modifies the requirement in
+          section 4 to "keep intact all notices".
+
+       c. You must license the entire work, as a whole, under this
+          License to anyone who comes into possession of a copy.  This
+          License will therefore apply, along with any applicable
+          section 7 additional terms, to the whole of the work, and all
+          its parts, regardless of how they are packaged.  This License
+          gives no permission to license the work in any other way, but
+          it does not invalidate such permission if you have separately
+          received it.
+
+       d. If the work has interactive user interfaces, each must display
+          Appropriate Legal Notices; however, if the Program has
+          interactive interfaces that do not display Appropriate Legal
+          Notices, your work need not make them do so.
+
+     A compilation of a covered work with other separate and independent
+     works, which are not by their nature extensions of the covered
+     work, and which are not combined with it such as to form a larger
+     program, in or on a volume of a storage or distribution medium, is
+     called an "aggregate" if the compilation and its resulting
+     copyright are not used to limit the access or legal rights of the
+     compilation's users beyond what the individual works permit.
+     Inclusion of a covered work in an aggregate does not cause this
+     License to apply to the other parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+     You may convey a covered work in object code form under the terms
+     of sections 4 and 5, provided that you also convey the
+     machine-readable Corresponding Source under the terms of this
+     License, in one of these ways:
+
+       a. Convey the object code in, or embodied in, a physical product
+          (including a physical distribution medium), accompanied by the
+          Corresponding Source fixed on a durable physical medium
+          customarily used for software interchange.
+
+       b. Convey the object code in, or embodied in, a physical product
+          (including a physical distribution medium), accompanied by a
+          written offer, valid for at least three years and valid for as
+          long as you offer spare parts or customer support for that
+          product model, to give anyone who possesses the object code
+          either (1) a copy of the Corresponding Source for all the
+          software in the product that is covered by this License, on a
+          durable physical medium customarily used for software
+          interchange, for a price no more than your reasonable cost of
+          physically performing this conveying of source, or (2) access
+          to copy the Corresponding Source from a network server at no
+          charge.
+
+       c. Convey individual copies of the object code with a copy of the
+          written offer to provide the Corresponding Source.  This
+          alternative is allowed only occasionally and noncommercially,
+          and only if you received the object code with such an offer,
+          in accord with subsection 6b.
+
+       d. Convey the object code by offering access from a designated
+          place (gratis or for a charge), and offer equivalent access to
+          the Corresponding Source in the same way through the same
+          place at no further charge.  You need not require recipients
+          to copy the Corresponding Source along with the object code.
+          If the place to copy the object code is a network server, the
+          Corresponding Source may be on a different server (operated by
+          you or a third party) that supports equivalent copying
+          facilities, provided you maintain clear directions next to the
+          object code saying where to find the Corresponding Source.
+          Regardless of what server hosts the Corresponding Source, you
+          remain obligated to ensure that it is available for as long as
+          needed to satisfy these requirements.
+
+       e. Convey the object code using peer-to-peer transmission,
+          provided you inform other peers where the object code and
+          Corresponding Source of the work are being offered to the
+          general public at no charge under subsection 6d.
+
+     A separable portion of the object code, whose source code is
+     excluded from the Corresponding Source as a System Library, need
+     not be included in conveying the object code work.
+
+     A "User Product" is either (1) a "consumer product", which means
+     any tangible personal property which is normally used for personal,
+     family, or household purposes, or (2) anything designed or sold for
+     incorporation into a dwelling.  In determining whether a product is
+     a consumer product, doubtful cases shall be resolved in favor of
+     coverage.  For a particular product received by a particular user,
+     "normally used" refers to a typical or common use of that class of
+     product, regardless of the status of the particular user or of the
+     way in which the particular user actually uses, or expects or is
+     expected to use, the product.  A product is a consumer product
+     regardless of whether the product has substantial commercial,
+     industrial or non-consumer uses, unless such uses represent the
+     only significant mode of use of the product.
+
+     "Installation Information" for a User Product means any methods,
+     procedures, authorization keys, or other information required to
+     install and execute modified versions of a covered work in that
+     User Product from a modified version of its Corresponding Source.
+     The information must suffice to ensure that the continued
+     functioning of the modified object code is in no case prevented or
+     interfered with solely because modification has been made.
+
+     If you convey an object code work under this section in, or with,
+     or specifically for use in, a User Product, and the conveying
+     occurs as part of a transaction in which the right of possession
+     and use of the User Product is transferred to the recipient in
+     perpetuity or for a fixed term (regardless of how the transaction
+     is characterized), the Corresponding Source conveyed under this
+     section must be accompanied by the Installation Information.  But
+     this requirement does not apply if neither you nor any third party
+     retains the ability to install modified object code on the User
+     Product (for example, the work has been installed in ROM).
+
+     The requirement to provide Installation Information does not
+     include a requirement to continue to provide support service,
+     warranty, or updates for a work that has been modified or installed
+     by the recipient, or for the User Product in which it has been
+     modified or installed.  Access to a network may be denied when the
+     modification itself materially and adversely affects the operation
+     of the network or violates the rules and protocols for
+     communication across the network.
+
+     Corresponding Source conveyed, and Installation Information
+     provided, in accord with this section must be in a format that is
+     publicly documented (and with an implementation available to the
+     public in source code form), and must require no special password
+     or key for unpacking, reading or copying.
+
+  7. Additional Terms.
+
+     "Additional permissions" are terms that supplement the terms of
+     this License by making exceptions from one or more of its
+     conditions.  Additional permissions that are applicable to the
+     entire Program shall be treated as though they were included in
+     this License, to the extent that they are valid under applicable
+     law.  If additional permissions apply only to part of the Program,
+     that part may be used separately under those permissions, but the
+     entire Program remains governed by this License without regard to
+     the additional permissions.
+
+     When you convey a copy of a covered work, you may at your option
+     remove any additional permissions from that copy, or from any part
+     of it.  (Additional permissions may be written to require their own
+     removal in certain cases when you modify the work.)  You may place
+     additional permissions on material, added by you to a covered work,
+     for which you have or can give appropriate copyright permission.
+
+     Notwithstanding any other provision of this License, for material
+     you add to a covered work, you may (if authorized by the copyright
+     holders of that material) supplement the terms of this License with
+     terms:
+
+       a. Disclaiming warranty or limiting liability differently from
+          the terms of sections 15 and 16 of this License; or
+
+       b. Requiring preservation of specified reasonable legal notices
+          or author attributions in that material or in the Appropriate
+          Legal Notices displayed by works containing it; or
+
+       c. Prohibiting misrepresentation of the origin of that material,
+          or requiring that modified versions of such material be marked
+          in reasonable ways as different from the original version; or
+
+       d. Limiting the use for publicity purposes of names of licensors
+          or authors of the material; or
+
+       e. Declining to grant rights under trademark law for use of some
+          trade names, trademarks, or service marks; or
+
+       f. Requiring indemnification of licensors and authors of that
+          material by anyone who conveys the material (or modified
+          versions of it) with contractual assumptions of liability to
+          the recipient, for any liability that these contractual
+          assumptions directly impose on those licensors and authors.
+
+     All other non-permissive additional terms are considered "further
+     restrictions" within the meaning of section 10.  If the Program as
+     you received it, or any part of it, contains a notice stating that
+     it is governed by this License along with a term that is a further
+     restriction, you may remove that term.  If a license document
+     contains a further restriction but permits relicensing or conveying
+     under this License, you may add to a covered work material governed
+     by the terms of that license document, provided that the further
+     restriction does not survive such relicensing or conveying.
+
+     If you add terms to a covered work in accord with this section, you
+     must place, in the relevant source files, a statement of the
+     additional terms that apply to those files, or a notice indicating
+     where to find the applicable terms.
+
+     Additional terms, permissive or non-permissive, may be stated in
+     the form of a separately written license, or stated as exceptions;
+     the above requirements apply either way.
+
+  8. Termination.
+
+     You may not propagate or modify a covered work except as expressly
+     provided under this License.  Any attempt otherwise to propagate or
+     modify it is void, and will automatically terminate your rights
+     under this License (including any patent licenses granted under the
+     third paragraph of section 11).
+
+     However, if you cease all violation of this License, then your
+     license from a particular copyright holder is reinstated (a)
+     provisionally, unless and until the copyright holder explicitly and
+     finally terminates your license, and (b) permanently, if the
+     copyright holder fails to notify you of the violation by some
+     reasonable means prior to 60 days after the cessation.
+
+     Moreover, your license from a particular copyright holder is
+     reinstated permanently if the copyright holder notifies you of the
+     violation by some reasonable means, this is the first time you have
+     received notice of violation of this License (for any work) from
+     that copyright holder, and you cure the violation prior to 30 days
+     after your receipt of the notice.
+
+     Termination of your rights under this section does not terminate
+     the licenses of parties who have received copies or rights from you
+     under this License.  If your rights have been terminated and not
+     permanently reinstated, you do not qualify to receive new licenses
+     for the same material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+     You are not required to accept this License in order to receive or
+     run a copy of the Program.  Ancillary propagation of a covered work
+     occurring solely as a consequence of using peer-to-peer
+     transmission to receive a copy likewise does not require
+     acceptance.  However, nothing other than this License grants you
+     permission to propagate or modify any covered work.  These actions
+     infringe copyright if you do not accept this License.  Therefore,
+     by modifying or propagating a covered work, you indicate your
+     acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+     Each time you convey a covered work, the recipient automatically
+     receives a license from the original licensors, to run, modify and
+     propagate that work, subject to this License.  You are not
+     responsible for enforcing compliance by third parties with this
+     License.
+
+     An "entity transaction" is a transaction transferring control of an
+     organization, or substantially all assets of one, or subdividing an
+     organization, or merging organizations.  If propagation of a
+     covered work results from an entity transaction, each party to that
+     transaction who receives a copy of the work also receives whatever
+     licenses to the work the party's predecessor in interest had or
+     could give under the previous paragraph, plus a right to possession
+     of the Corresponding Source of the work from the predecessor in
+     interest, if the predecessor has it or can get it with reasonable
+     efforts.
+
+     You may not impose any further restrictions on the exercise of the
+     rights granted or affirmed under this License.  For example, you
+     may not impose a license fee, royalty, or other charge for exercise
+     of rights granted under this License, and you may not initiate
+     litigation (including a cross-claim or counterclaim in a lawsuit)
+     alleging that any patent claim is infringed by making, using,
+     selling, offering for sale, or importing the Program or any portion
+     of it.
+
+  11. Patents.
+
+     A "contributor" is a copyright holder who authorizes use under this
+     License of the Program or a work on which the Program is based.
+     The work thus licensed is called the contributor's "contributor
+     version".
+
+     A contributor's "essential patent claims" are all patent claims
+     owned or controlled by the contributor, whether already acquired or
+     hereafter acquired, that would be infringed by some manner,
+     permitted by this License, of making, using, or selling its
+     contributor version, but do not include claims that would be
+     infringed only as a consequence of further modification of the
+     contributor version.  For purposes of this definition, "control"
+     includes the right to grant patent sublicenses in a manner
+     consistent with the requirements of this License.
+
+     Each contributor grants you a non-exclusive, worldwide,
+     royalty-free patent license under the contributor's essential
+     patent claims, to make, use, sell, offer for sale, import and
+     otherwise run, modify and propagate the contents of its contributor
+     version.
+
+     In the following three paragraphs, a "patent license" is any
+     express agreement or commitment, however denominated, not to
+     enforce a patent (such as an express permission to practice a
+     patent or covenant not to sue for patent infringement).  To "grant"
+     such a patent license to a party means to make such an agreement or
+     commitment not to enforce a patent against the party.
+
+     If you convey a covered work, knowingly relying on a patent
+     license, and the Corresponding Source of the work is not available
+     for anyone to copy, free of charge and under the terms of this
+     License, through a publicly available network server or other
+     readily accessible means, then you must either (1) cause the
+     Corresponding Source to be so available, or (2) arrange to deprive
+     yourself of the benefit of the patent license for this particular
+     work, or (3) arrange, in a manner consistent with the requirements
+     of this License, to extend the patent license to downstream
+     recipients.  "Knowingly relying" means you have actual knowledge
+     that, but for the patent license, your conveying the covered work
+     in a country, or your recipient's use of the covered work in a
+     country, would infringe one or more identifiable patents in that
+     country that you have reason to believe are valid.
+
+     If, pursuant to or in connection with a single transaction or
+     arrangement, you convey, or propagate by procuring conveyance of, a
+     covered work, and grant a patent license to some of the parties
+     receiving the covered work authorizing them to use, propagate,
+     modify or convey a specific copy of the covered work, then the
+     patent license you grant is automatically extended to all
+     recipients of the covered work and works based on it.
+
+     A patent license is "discriminatory" if it does not include within
+     the scope of its coverage, prohibits the exercise of, or is
+     conditioned on the non-exercise of one or more of the rights that
+     are specifically granted under this License.  You may not convey a
+     covered work if you are a party to an arrangement with a third
+     party that is in the business of distributing software, under which
+     you make payment to the third party based on the extent of your
+     activity of conveying the work, and under which the third party
+     grants, to any of the parties who would receive the covered work
+     from you, a discriminatory patent license (a) in connection with
+     copies of the covered work conveyed by you (or copies made from
+     those copies), or (b) primarily for and in connection with specific
+     products or compilations that contain the covered work, unless you
+     entered into that arrangement, or that patent license was granted,
+     prior to 28 March 2007.
+
+     Nothing in this License shall be construed as excluding or limiting
+     any implied license or other defenses to infringement that may
+     otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+     If conditions are imposed on you (whether by court order, agreement
+     or otherwise) that contradict the conditions of this License, they
+     do not excuse you from the conditions of this License.  If you
+     cannot convey a covered work so as to satisfy simultaneously your
+     obligations under this License and any other pertinent obligations,
+     then as a consequence you may not convey it at all.  For example,
+     if you agree to terms that obligate you to collect a royalty for
+     further conveying from those to whom you convey the Program, the
+     only way you could satisfy both those terms and this License would
+     be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+     Notwithstanding any other provision of this License, you have
+     permission to link or combine any covered work with a work licensed
+     under version 3 of the GNU Affero General Public License into a
+     single combined work, and to convey the resulting work.  The terms
+     of this License will continue to apply to the part which is the
+     covered work, but the special requirements of the GNU Affero
+     General Public License, section 13, concerning interaction through
+     a network will apply to the combination as such.
+
+  14. Revised Versions of this License.
+
+     The Free Software Foundation may publish revised and/or new
+     versions of the GNU General Public License from time to time.  Such
+     new versions will be similar in spirit to the present version, but
+     may differ in detail to address new problems or concerns.
+
+     Each version is given a distinguishing version number.  If the
+     Program specifies that a certain numbered version of the GNU
+     General Public License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that numbered version or of any later version published by the Free
+     Software Foundation.  If the Program does not specify a version
+     number of the GNU General Public License, you may choose any
+     version ever published by the Free Software Foundation.
+
+     If the Program specifies that a proxy can decide which future
+     versions of the GNU General Public License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Program.
+
+     Later license versions may give you additional or different
+     permissions.  However, no additional obligations are imposed on any
+     author or copyright holder as a result of your choosing to follow a
+     later version.
+
+  15. Disclaimer of Warranty.
+
+     THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+     APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
+     COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
+     WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
+     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
+     RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
+     SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
+     NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+     IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+     WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
+     AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR
+     DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+     CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
+     THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
+     BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+     PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+     PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
+     THE POSSIBILITY OF SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+     If the disclaimer of warranty and limitation of liability provided
+     above cannot be given local legal effect according to their terms,
+     reviewing courts shall apply local law that most closely
+     approximates an absolute waiver of all civil liability in
+     connection with the Program, unless a warranty or assumption of
+     liability accompanies a copy of the Program in return for a fee.
+
+END OF TERMS AND CONDITIONS
+===========================
+
+How to Apply These Terms to Your New Programs
+=============================================
+
+If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+
+ To do so, attach the following notices to the program.  It is safest to
+attach them to the start of each source file to most effectively state
+the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+     ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
+     Copyright (C) YEAR NAME OF AUTHOR
+
+     This program is free software: you can redistribute it and/or modify
+     it under the terms of the GNU General Public License as published by
+     the Free Software Foundation, either version 3 of the License, or (at
+     your option) any later version.
+
+     This program is distributed in the hope that it will be useful, but
+     WITHOUT ANY WARRANTY; without even the implied warranty of
+     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+     General Public License for more details.
+
+     You should have received a copy of the GNU General Public License
+     along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+ Also add information on how to contact you by electronic and paper
+mail.
+
+ If the program does terminal interaction, make it output a short notice
+like this when it starts in an interactive mode:
+
+     PROGRAM Copyright (C) YEAR NAME OF AUTHOR
+     This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'.
+     This is free software, and you are welcome to redistribute it
+     under certain conditions; type 'show c' for details.
+
+ The hypothetical commands 'show w' and 'show c' should show the
+appropriate parts of the General Public License.  Of course, your
+program's commands might be different; for a GUI interface, you would
+use an "about box".
+
+ You should also get your employer (if you work as a programmer) or
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  For more information on this, and how to apply and follow
+the GNU GPL, see <http://www.gnu.org/licenses/>.
+
+ The GNU General Public License does not permit incorporating your
+program into proprietary programs.  If your program is a subroutine
+library, you may consider it more useful to permit linking proprietary
+applications with the library.  If this is what you want to do, use the
+GNU Lesser General Public License instead of this License.  But first,
+please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.
+
+
+File: gcc.info,  Node: GNU Free Documentation License,  Next: Contributors,  Prev: Copying,  Up: Top
+
+GNU Free Documentation License
+******************************
+
+                     Version 1.3, 3 November 2008
+
+     Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
+     <http://fsf.org/>
+
+     Everyone is permitted to copy and distribute verbatim copies
+     of this license document, but changing it is not allowed.
+
+  0. PREAMBLE
+
+     The purpose of this License is to make a manual, textbook, or other
+     functional and useful document "free" in the sense of freedom: to
+     assure everyone the effective freedom to copy and redistribute it,
+     with or without modifying it, either commercially or
+     noncommercially.  Secondarily, this License preserves for the
+     author and publisher a way to get credit for their work, while not
+     being considered responsible for modifications made by others.
+
+     This License is a kind of "copyleft", which means that derivative
+     works of the document must themselves be free in the same sense.
+     It complements the GNU General Public License, which is a copyleft
+     license designed for free software.
+
+     We have designed this License in order to use it for manuals for
+     free software, because free software needs free documentation: a
+     free program should come with manuals providing the same freedoms
+     that the software does.  But this License is not limited to
+     software manuals; it can be used for any textual work, regardless
+     of subject matter or whether it is published as a printed book.  We
+     recommend this License principally for works whose purpose is
+     instruction or reference.
+
+  1. APPLICABILITY AND DEFINITIONS
+
+     This License applies to any manual or other work, in any medium,
+     that contains a notice placed by the copyright holder saying it can
+     be distributed under the terms of this License.  Such a notice
+     grants a world-wide, royalty-free license, unlimited in duration,
+     to use that work under the conditions stated herein.  The
+     "Document", below, refers to any such manual or work.  Any member
+     of the public is a licensee, and is addressed as "you".  You accept
+     the license if you copy, modify or distribute the work in a way
+     requiring permission under copyright law.
+
+     A "Modified Version" of the Document means any work containing the
+     Document or a portion of it, either copied verbatim, or with
+     modifications and/or translated into another language.
+
+     A "Secondary Section" is a named appendix or a front-matter section
+     of the Document that deals exclusively with the relationship of the
+     publishers or authors of the Document to the Document's overall
+     subject (or to related matters) and contains nothing that could
+     fall directly within that overall subject.  (Thus, if the Document
+     is in part a textbook of mathematics, a Secondary Section may not
+     explain any mathematics.)  The relationship could be a matter of
+     historical connection with the subject or with related matters, or
+     of legal, commercial, philosophical, ethical or political position
+     regarding them.
+
+     The "Invariant Sections" are certain Secondary Sections whose
+     titles are designated, as being those of Invariant Sections, in the
+     notice that says that the Document is released under this License.
+     If a section does not fit the above definition of Secondary then it
+     is not allowed to be designated as Invariant.  The Document may
+     contain zero Invariant Sections.  If the Document does not identify
+     any Invariant Sections then there are none.
+
+     The "Cover Texts" are certain short passages of text that are
+     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
+     that says that the Document is released under this License.  A
+     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
+     be at most 25 words.
+
+     A "Transparent" copy of the Document means a machine-readable copy,
+     represented in a format whose specification is available to the
+     general public, that is suitable for revising the document
+     straightforwardly with generic text editors or (for images composed
+     of pixels) generic paint programs or (for drawings) some widely
+     available drawing editor, and that is suitable for input to text
+     formatters or for automatic translation to a variety of formats
+     suitable for input to text formatters.  A copy made in an otherwise
+     Transparent file format whose markup, or absence of markup, has
+     been arranged to thwart or discourage subsequent modification by
+     readers is not Transparent.  An image format is not Transparent if
+     used for any substantial amount of text.  A copy that is not
+     "Transparent" is called "Opaque".
+
+     Examples of suitable formats for Transparent copies include plain
+     ASCII without markup, Texinfo input format, LaTeX input format,
+     SGML or XML using a publicly available DTD, and standard-conforming
+     simple HTML, PostScript or PDF designed for human modification.
+     Examples of transparent image formats include PNG, XCF and JPG.
+     Opaque formats include proprietary formats that can be read and
+     edited only by proprietary word processors, SGML or XML for which
+     the DTD and/or processing tools are not generally available, and
+     the machine-generated HTML, PostScript or PDF produced by some word
+     processors for output purposes only.
+
+     The "Title Page" means, for a printed book, the title page itself,
+     plus such following pages as are needed to hold, legibly, the
+     material this License requires to appear in the title page.  For
+     works in formats which do not have any title page as such, "Title
+     Page" means the text near the most prominent appearance of the
+     work's title, preceding the beginning of the body of the text.
+
+     The "publisher" means any person or entity that distributes copies
+     of the Document to the public.
+
+     A section "Entitled XYZ" means a named subunit of the Document
+     whose title either is precisely XYZ or contains XYZ in parentheses
+     following text that translates XYZ in another language.  (Here XYZ
+     stands for a specific section name mentioned below, such as
+     "Acknowledgements", "Dedications", "Endorsements", or "History".)
+     To "Preserve the Title" of such a section when you modify the
+     Document means that it remains a section "Entitled XYZ" according
+     to this definition.
+
+     The Document may include Warranty Disclaimers next to the notice
+     which states that this License applies to the Document.  These
+     Warranty Disclaimers are considered to be included by reference in
+     this License, but only as regards disclaiming warranties: any other
+     implication that these Warranty Disclaimers may have is void and
+     has no effect on the meaning of this License.
+
+  2. VERBATIM COPYING
+
+     You may copy and distribute the Document in any medium, either
+     commercially or noncommercially, provided that this License, the
+     copyright notices, and the license notice saying this License
+     applies to the Document are reproduced in all copies, and that you
+     add no other conditions whatsoever to those of this License.  You
+     may not use technical measures to obstruct or control the reading
+     or further copying of the copies you make or distribute.  However,
+     you may accept compensation in exchange for copies.  If you
+     distribute a large enough number of copies you must also follow the
+     conditions in section 3.
+
+     You may also lend copies, under the same conditions stated above,
+     and you may publicly display copies.
+
+  3. COPYING IN QUANTITY
+
+     If you publish printed copies (or copies in media that commonly
+     have printed covers) of the Document, numbering more than 100, and
+     the Document's license notice requires Cover Texts, you must
+     enclose the copies in covers that carry, clearly and legibly, all
+     these Cover Texts: Front-Cover Texts on the front cover, and
+     Back-Cover Texts on the back cover.  Both covers must also clearly
+     and legibly identify you as the publisher of these copies.  The
+     front cover must present the full title with all words of the title
+     equally prominent and visible.  You may add other material on the
+     covers in addition.  Copying with changes limited to the covers, as
+     long as they preserve the title of the Document and satisfy these
+     conditions, can be treated as verbatim copying in other respects.
+
+     If the required texts for either cover are too voluminous to fit
+     legibly, you should put the first ones listed (as many as fit
+     reasonably) on the actual cover, and continue the rest onto
+     adjacent pages.
+
+     If you publish or distribute Opaque copies of the Document
+     numbering more than 100, you must either include a machine-readable
+     Transparent copy along with each Opaque copy, or state in or with
+     each Opaque copy a computer-network location from which the general
+     network-using public has access to download using public-standard
+     network protocols a complete Transparent copy of the Document, free
+     of added material.  If you use the latter option, you must take
+     reasonably prudent steps, when you begin distribution of Opaque
+     copies in quantity, to ensure that this Transparent copy will
+     remain thus accessible at the stated location until at least one
+     year after the last time you distribute an Opaque copy (directly or
+     through your agents or retailers) of that edition to the public.
+
+     It is requested, but not required, that you contact the authors of
+     the Document well before redistributing any large number of copies,
+     to give them a chance to provide you with an updated version of the
+     Document.
+
+  4. MODIFICATIONS
+
+     You may copy and distribute a Modified Version of the Document
+     under the conditions of sections 2 and 3 above, provided that you
+     release the Modified Version under precisely this License, with the
+     Modified Version filling the role of the Document, thus licensing
+     distribution and modification of the Modified Version to whoever
+     possesses a copy of it.  In addition, you must do these things in
+     the Modified Version:
+
+       A. Use in the Title Page (and on the covers, if any) a title
+          distinct from that of the Document, and from those of previous
+          versions (which should, if there were any, be listed in the
+          History section of the Document).  You may use the same title
+          as a previous version if the original publisher of that
+          version gives permission.
+
+       B. List on the Title Page, as authors, one or more persons or
+          entities responsible for authorship of the modifications in
+          the Modified Version, together with at least five of the
+          principal authors of the Document (all of its principal
+          authors, if it has fewer than five), unless they release you
+          from this requirement.
+
+       C. State on the Title page the name of the publisher of the
+          Modified Version, as the publisher.
+
+       D. Preserve all the copyright notices of the Document.
+
+       E. Add an appropriate copyright notice for your modifications
+          adjacent to the other copyright notices.
+
+       F. Include, immediately after the copyright notices, a license
+          notice giving the public permission to use the Modified
+          Version under the terms of this License, in the form shown in
+          the Addendum below.
+
+       G. Preserve in that license notice the full lists of Invariant
+          Sections and required Cover Texts given in the Document's
+          license notice.
+
+       H. Include an unaltered copy of this License.
+
+       I. Preserve the section Entitled "History", Preserve its Title,
+          and add to it an item stating at least the title, year, new
+          authors, and publisher of the Modified Version as given on the
+          Title Page.  If there is no section Entitled "History" in the
+          Document, create one stating the title, year, authors, and
+          publisher of the Document as given on its Title Page, then add
+          an item describing the Modified Version as stated in the
+          previous sentence.
+
+       J. Preserve the network location, if any, given in the Document
+          for public access to a Transparent copy of the Document, and
+          likewise the network locations given in the Document for
+          previous versions it was based on.  These may be placed in the
+          "History" section.  You may omit a network location for a work
+          that was published at least four years before the Document
+          itself, or if the original publisher of the version it refers
+          to gives permission.
+
+       K. For any section Entitled "Acknowledgements" or "Dedications",
+          Preserve the Title of the section, and preserve in the section
+          all the substance and tone of each of the contributor
+          acknowledgements and/or dedications given therein.
+
+       L. Preserve all the Invariant Sections of the Document, unaltered
+          in their text and in their titles.  Section numbers or the
+          equivalent are not considered part of the section titles.
+
+       M. Delete any section Entitled "Endorsements".  Such a section
+          may not be included in the Modified Version.
+
+       N. Do not retitle any existing section to be Entitled
+          "Endorsements" or to conflict in title with any Invariant
+          Section.
+
+       O. Preserve any Warranty Disclaimers.
+
+     If the Modified Version includes new front-matter sections or
+     appendices that qualify as Secondary Sections and contain no
+     material copied from the Document, you may at your option designate
+     some or all of these sections as invariant.  To do this, add their
+     titles to the list of Invariant Sections in the Modified Version's
+     license notice.  These titles must be distinct from any other
+     section titles.
+
+     You may add a section Entitled "Endorsements", provided it contains
+     nothing but endorsements of your Modified Version by various
+     parties--for example, statements of peer review or that the text
+     has been approved by an organization as the authoritative
+     definition of a standard.
+
+     You may add a passage of up to five words as a Front-Cover Text,
+     and a passage of up to 25 words as a Back-Cover Text, to the end of
+     the list of Cover Texts in the Modified Version.  Only one passage
+     of Front-Cover Text and one of Back-Cover Text may be added by (or
+     through arrangements made by) any one entity.  If the Document
+     already includes a cover text for the same cover, previously added
+     by you or by arrangement made by the same entity you are acting on
+     behalf of, you may not add another; but you may replace the old
+     one, on explicit permission from the previous publisher that added
+     the old one.
+
+     The author(s) and publisher(s) of the Document do not by this
+     License give permission to use their names for publicity for or to
+     assert or imply endorsement of any Modified Version.
+
+  5. COMBINING DOCUMENTS
+
+     You may combine the Document with other documents released under
+     this License, under the terms defined in section 4 above for
+     modified versions, provided that you include in the combination all
+     of the Invariant Sections of all of the original documents,
+     unmodified, and list them all as Invariant Sections of your
+     combined work in its license notice, and that you preserve all
+     their Warranty Disclaimers.
+
+     The combined work need only contain one copy of this License, and
+     multiple identical Invariant Sections may be replaced with a single
+     copy.  If there are multiple Invariant Sections with the same name
+     but different contents, make the title of each such section unique
+     by adding at the end of it, in parentheses, the name of the
+     original author or publisher of that section if known, or else a
+     unique number.  Make the same adjustment to the section titles in
+     the list of Invariant Sections in the license notice of the
+     combined work.
+
+     In the combination, you must combine any sections Entitled
+     "History" in the various original documents, forming one section
+     Entitled "History"; likewise combine any sections Entitled
+     "Acknowledgements", and any sections Entitled "Dedications".  You
+     must delete all sections Entitled "Endorsements."
+
+  6. COLLECTIONS OF DOCUMENTS
+
+     You may make a collection consisting of the Document and other
+     documents released under this License, and replace the individual
+     copies of this License in the various documents with a single copy
+     that is included in the collection, provided that you follow the
+     rules of this License for verbatim copying of each of the documents
+     in all other respects.
+
+     You may extract a single document from such a collection, and
+     distribute it individually under this License, provided you insert
+     a copy of this License into the extracted document, and follow this
+     License in all other respects regarding verbatim copying of that
+     document.
+
+  7. AGGREGATION WITH INDEPENDENT WORKS
+
+     A compilation of the Document or its derivatives with other
+     separate and independent documents or works, in or on a volume of a
+     storage or distribution medium, is called an "aggregate" if the
+     copyright resulting from the compilation is not used to limit the
+     legal rights of the compilation's users beyond what the individual
+     works permit.  When the Document is included in an aggregate, this
+     License does not apply to the other works in the aggregate which
+     are not themselves derivative works of the Document.
+
+     If the Cover Text requirement of section 3 is applicable to these
+     copies of the Document, then if the Document is less than one half
+     of the entire aggregate, the Document's Cover Texts may be placed
+     on covers that bracket the Document within the aggregate, or the
+     electronic equivalent of covers if the Document is in electronic
+     form.  Otherwise they must appear on printed covers that bracket
+     the whole aggregate.
+
+  8. TRANSLATION
+
+     Translation is considered a kind of modification, so you may
+     distribute translations of the Document under the terms of section
+     4.  Replacing Invariant Sections with translations requires special
+     permission from their copyright holders, but you may include
+     translations of some or all Invariant Sections in addition to the
+     original versions of these Invariant Sections.  You may include a
+     translation of this License, and all the license notices in the
+     Document, and any Warranty Disclaimers, provided that you also
+     include the original English version of this License and the
+     original versions of those notices and disclaimers.  In case of a
+     disagreement between the translation and the original version of
+     this License or a notice or disclaimer, the original version will
+     prevail.
+
+     If a section in the Document is Entitled "Acknowledgements",
+     "Dedications", or "History", the requirement (section 4) to
+     Preserve its Title (section 1) will typically require changing the
+     actual title.
+
+  9. TERMINATION
+
+     You may not copy, modify, sublicense, or distribute the Document
+     except as expressly provided under this License.  Any attempt
+     otherwise to copy, modify, sublicense, or distribute it is void,
+     and will automatically terminate your rights under this License.
+
+     However, if you cease all violation of this License, then your
+     license from a particular copyright holder is reinstated (a)
+     provisionally, unless and until the copyright holder explicitly and
+     finally terminates your license, and (b) permanently, if the
+     copyright holder fails to notify you of the violation by some
+     reasonable means prior to 60 days after the cessation.
+
+     Moreover, your license from a particular copyright holder is
+     reinstated permanently if the copyright holder notifies you of the
+     violation by some reasonable means, this is the first time you have
+     received notice of violation of this License (for any work) from
+     that copyright holder, and you cure the violation prior to 30 days
+     after your receipt of the notice.
+
+     Termination of your rights under this section does not terminate
+     the licenses of parties who have received copies or rights from you
+     under this License.  If your rights have been terminated and not
+     permanently reinstated, receipt of a copy of some or all of the
+     same material does not give you any rights to use it.
+
+  10. FUTURE REVISIONS OF THIS LICENSE
+
+     The Free Software Foundation may publish new, revised versions of
+     the GNU Free Documentation License from time to time.  Such new
+     versions will be similar in spirit to the present version, but may
+     differ in detail to address new problems or concerns.  See
+     <http://www.gnu.org/copyleft/>.
+
+     Each version of the License is given a distinguishing version
+     number.  If the Document specifies that a particular numbered
+     version of this License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that specified version or of any later version that has been
+     published (not as a draft) by the Free Software Foundation.  If the
+     Document does not specify a version number of this License, you may
+     choose any version ever published (not as a draft) by the Free
+     Software Foundation.  If the Document specifies that a proxy can
+     decide which future versions of this License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Document.
+
+  11. RELICENSING
+
+     "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
+     World Wide Web server that publishes copyrightable works and also
+     provides prominent facilities for anybody to edit those works.  A
+     public wiki that anybody can edit is an example of such a server.
+     A "Massive Multiauthor Collaboration" (or "MMC") contained in the
+     site means any set of copyrightable works thus published on the MMC
+     site.
+
+     "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
+     license published by Creative Commons Corporation, a not-for-profit
+     corporation with a principal place of business in San Francisco,
+     California, as well as future copyleft versions of that license
+     published by that same organization.
+
+     "Incorporate" means to publish or republish a Document, in whole or
+     in part, as part of another Document.
+
+     An MMC is "eligible for relicensing" if it is licensed under this
+     License, and if all works that were first published under this
+     License somewhere other than this MMC, and subsequently
+     incorporated in whole or in part into the MMC, (1) had no cover
+     texts or invariant sections, and (2) were thus incorporated prior
+     to November 1, 2008.
+
+     The operator of an MMC Site may republish an MMC contained in the
+     site under CC-BY-SA on the same site at any time before August 1,
+     2009, provided the MMC is eligible for relicensing.
+
+ADDENDUM: How to use this License for your documents
+====================================================
+
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and license
+notices just after the title page:
+
+       Copyright (C)  YEAR  YOUR NAME.
+       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, no Front-Cover Texts, and no Back-Cover
+       Texts.  A copy of the license is included in the section entitled ``GNU
+       Free Documentation License''.
+
+ If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
+replace the "with...Texts."  line with this:
+
+         with the Invariant Sections being LIST THEIR TITLES, with
+         the Front-Cover Texts being LIST, and with the Back-Cover Texts
+         being LIST.
+
+ If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+
+ If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of free
+software license, such as the GNU General Public License, to permit
+their use in free software.
+
+
+File: gcc.info,  Node: Contributors,  Next: Option Index,  Prev: GNU Free Documentation License,  Up: Top
+
+Contributors to GCC
+*******************
+
+The GCC project would like to thank its many contributors.  Without them
+the project would not have been nearly as successful as it has been.
+Any omissions in this list are accidental.  Feel free to contact
+<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or
+some of your contributions are not listed.  Please keep this list in
+alphabetical order.
+
+   * Analog Devices helped implement the support for complex data types
+     and iterators.
+
+   * John David Anglin for threading-related fixes and improvements to
+     libstdc++-v3, and the HP-UX port.
+
+   * James van Artsdalen wrote the code that makes efficient use of the
+     Intel 80387 register stack.
+
+   * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta
+     Series port.
+
+   * Alasdair Baird for various bug fixes.
+
+   * Giovanni Bajo for analyzing lots of complicated C++ problem
+     reports.
+
+   * Peter Barada for his work to improve code generation for new
+     ColdFire cores.
+
+   * Gerald Baumgartner added the signature extension to the C++ front
+     end.
+
+   * Godmar Back for his Java improvements and encouragement.
+
+   * Scott Bambrough for help porting the Java compiler.
+
+   * Wolfgang Bangerth for processing tons of bug reports.
+
+   * Jon Beniston for his Microsoft Windows port of Java and port to
+     Lattice Mico32.
+
+   * Daniel Berlin for better DWARF2 support, faster/better
+     optimizations, improved alias analysis, plus migrating GCC to
+     Bugzilla.
+
+   * Geoff Berry for his Java object serialization work and various
+     patches.
+
+   * David Binderman tests weekly snapshots of GCC trunk against Fedora
+     Rawhide for several architectures.
+
+   * Uros Bizjak for the implementation of x87 math built-in functions
+     and for various middle end and i386 back end improvements and bug
+     fixes.
+
+   * Eric Blake for helping to make GCJ and libgcj conform to the
+     specifications.
+
+   * Janne Blomqvist for contributions to GNU Fortran.
+
+   * Segher Boessenkool for various fixes.
+
+   * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
+     other Java work.
+
+   * Neil Booth for work on cpplib, lang hooks, debug hooks and other
+     miscellaneous clean-ups.
+
+   * Steven Bosscher for integrating the GNU Fortran front end into GCC
+     and for contributing to the tree-ssa branch.
+
+   * Eric Botcazou for fixing middle- and backend bugs left and right.
+
+   * Per Bothner for his direction via the steering committee and
+     various improvements to the infrastructure for supporting new
+     languages.  Chill front end implementation.  Initial
+     implementations of cpplib, fix-header, config.guess, libio, and
+     past C++ library (libg++) maintainer.  Dreaming up, designing and
+     implementing much of GCJ.
+
+   * Devon Bowen helped port GCC to the Tahoe.
+
+   * Don Bowman for mips-vxworks contributions.
+
+   * Dave Brolley for work on cpplib and Chill.
+
+   * Paul Brook for work on the ARM architecture and maintaining GNU
+     Fortran.
+
+   * Robert Brown implemented the support for Encore 32000 systems.
+
+   * Christian Bruel for improvements to local store elimination.
+
+   * Herman A.J. ten Brugge for various fixes.
+
+   * Joerg Brunsmann for Java compiler hacking and help with the GCJ
+     FAQ.
+
+   * Joe Buck for his direction via the steering committee.
+
+   * Craig Burley for leadership of the G77 Fortran effort.
+
+   * Stephan Buys for contributing Doxygen notes for libstdc++.
+
+   * Paolo Carlini for libstdc++ work: lots of efficiency improvements
+     to the C++ strings, streambufs and formatted I/O, hard detective
+     work on the frustrating localization issues, and keeping up with
+     the problem reports.
+
+   * John Carr for his alias work, SPARC hacking, infrastructure
+     improvements, previous contributions to the steering committee,
+     loop optimizations, etc.
+
+   * Stephane Carrez for 68HC11 and 68HC12 ports.
+
+   * Steve Chamberlain for support for the Renesas SH and H8 processors
+     and the PicoJava processor, and for GCJ config fixes.
+
+   * Glenn Chambers for help with the GCJ FAQ.
+
+   * John-Marc Chandonia for various libgcj patches.
+
+   * Denis Chertykov for contributing and maintaining the AVR port, the
+     first GCC port for an 8-bit architecture.
+
+   * Scott Christley for his Objective-C contributions.
+
+   * Eric Christopher for his Java porting help and clean-ups.
+
+   * Branko Cibej for more warning contributions.
+
+   * The GNU Classpath project for all of their merged runtime code.
+
+   * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work,
+     '--help', and other random hacking.
+
+   * Michael Cook for libstdc++ cleanup patches to reduce warnings.
+
+   * R. Kelley Cook for making GCC buildable from a read-only directory
+     as well as other miscellaneous build process and documentation
+     clean-ups.
+
+   * Ralf Corsepius for SH testing and minor bug fixing.
+
+   * Stan Cox for care and feeding of the x86 port and lots of behind
+     the scenes hacking.
+
+   * Alex Crain provided changes for the 3b1.
+
+   * Ian Dall for major improvements to the NS32k port.
+
+   * Paul Dale for his work to add uClinux platform support to the m68k
+     backend.
+
+   * Dario Dariol contributed the four varieties of sample programs that
+     print a copy of their source.
+
+   * Russell Davidson for fstream and stringstream fixes in libstdc++.
+
+   * Bud Davis for work on the G77 and GNU Fortran compilers.
+
+   * Mo DeJong for GCJ and libgcj bug fixes.
+
+   * DJ Delorie for the DJGPP port, build and libiberty maintenance,
+     various bug fixes, and the M32C, MeP, MSP430, and RL78 ports.
+
+   * Arnaud Desitter for helping to debug GNU Fortran.
+
+   * Gabriel Dos Reis for contributions to G++, contributions and
+     maintenance of GCC diagnostics infrastructure, libstdc++-v3,
+     including 'valarray<>', 'complex<>', maintaining the numerics
+     library (including that pesky '<limits>' :-) and keeping up-to-date
+     anything to do with numbers.
+
+   * Ulrich Drepper for his work on glibc, testing of GCC using glibc,
+     ISO C99 support, CFG dumping support, etc., plus support of the C++
+     runtime libraries including for all kinds of C interface issues,
+     contributing and maintaining 'complex<>', sanity checking and
+     disbursement, configuration architecture, libio maintenance, and
+     early math work.
+
+   * Franc,ois Dumont for his work on libstdc++-v3, especially
+     maintaining and improving 'debug-mode' and associative and
+     unordered containers.
+
+   * Zdenek Dvorak for a new loop unroller and various fixes.
+
+   * Michael Eager for his work on the Xilinx MicroBlaze port.
+
+   * Richard Earnshaw for his ongoing work with the ARM.
+
+   * David Edelsohn for his direction via the steering committee,
+     ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
+     loop changes, doing the entire AIX port of libstdc++ with his bare
+     hands, and for ensuring GCC properly keeps working on AIX.
+
+   * Kevin Ediger for the floating point formatting of num_put::do_put
+     in libstdc++.
+
+   * Phil Edwards for libstdc++ work including configuration hackery,
+     documentation maintainer, chief breaker of the web pages, the
+     occasional iostream bug fix, and work on shared library symbol
+     versioning.
+
+   * Paul Eggert for random hacking all over GCC.
+
+   * Mark Elbrecht for various DJGPP improvements, and for libstdc++
+     configuration support for locales and fstream-related fixes.
+
+   * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
+     iostreams.
+
+   * Christian Ehrhardt for dealing with bug reports.
+
+   * Ben Elliston for his work to move the Objective-C runtime into its
+     own subdirectory and for his work on autoconf.
+
+   * Revital Eres for work on the PowerPC 750CL port.
+
+   * Marc Espie for OpenBSD support.
+
+   * Doug Evans for much of the global optimization framework, arc,
+     m32r, and SPARC work.
+
+   * Christopher Faylor for his work on the Cygwin port and for caring
+     and feeding the gcc.gnu.org box and saving its users tons of spam.
+
+   * Fred Fish for BeOS support and Ada fixes.
+
+   * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
+
+   * Peter Gerwinski for various bug fixes and the Pascal front end.
+
+   * Kaveh R. Ghazi for his direction via the steering committee,
+     amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC
+     on a plethora of platforms.  Kaveh extends his gratitude to the
+     CAIP Center at Rutgers University for providing him with computing
+     resources to work on Free Software from the late 1980s to 2010.
+
+   * John Gilmore for a donation to the FSF earmarked improving GNU
+     Java.
+
+   * Judy Goldberg for c++ contributions.
+
+   * Torbjorn Granlund for various fixes and the c-torture testsuite,
+     multiply- and divide-by-constant optimization, improved long long
+     support, improved leaf function register allocation, and his
+     direction via the steering committee.
+
+   * Anthony Green for his '-Os' contributions, the moxie port, and Java
+     front end work.
+
+   * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java
+     code.
+
+   * Michael K. Gschwind contributed the port to the PDP-11.
+
+   * Richard Biener for his ongoing middle-end contributions and bug
+     fixes and for release management.
+
+   * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools,
+     the support for Dwarf symbolic debugging information, and much of
+     the support for System V Release 4.  He has also worked heavily on
+     the Intel 386 and 860 support.
+
+   * Sumanth Gundapaneni for contributing the CR16 port.
+
+   * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
+     GCSE.
+
+   * Bruno Haible for improvements in the runtime overhead for EH, new
+     warnings and assorted bug fixes.
+
+   * Andrew Haley for his amazing Java compiler and library efforts.
+
+   * Chris Hanson assisted in making GCC work on HP-UX for the 9000
+     series 300.
+
+   * Michael Hayes for various thankless work he's done trying to get
+     the c30/c40 ports functional.  Lots of loop and unroll improvements
+     and fixes.
+
+   * Dara Hazeghi for wading through myriads of target-specific bug
+     reports.
+
+   * Kate Hedstrom for staking the G77 folks with an initial testsuite.
+
+   * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
+     work, loop opts, and generally fixing lots of old problems we've
+     ignored for years, flow rewrite and lots of further stuff,
+     including reviewing tons of patches.
+
+   * Aldy Hernandez for working on the PowerPC port, SIMD support, and
+     various fixes.
+
+   * Nobuyuki Hikichi of Software Research Associates, Tokyo,
+     contributed the support for the Sony NEWS machine.
+
+   * Kazu Hirata for caring and feeding the Renesas H8/300 port and
+     various fixes.
+
+   * Katherine Holcomb for work on GNU Fortran.
+
+   * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
+     of testing and bug fixing, particularly of GCC configury code.
+
+   * Steve Holmgren for MachTen patches.
+
+   * Mat Hostetter for work on the TILE-Gx and TILEPro ports.
+
+   * Jan Hubicka for his x86 port improvements.
+
+   * Falk Hueffner for working on C and optimization bug reports.
+
+   * Bernardo Innocenti for his m68k work, including merging of ColdFire
+     improvements and uClinux support.
+
+   * Christian Iseli for various bug fixes.
+
+   * Kamil Iskra for general m68k hacking.
+
+   * Lee Iverson for random fixes and MIPS testing.
+
+   * Andreas Jaeger for testing and benchmarking of GCC and various bug
+     fixes.
+
+   * Jakub Jelinek for his SPARC work and sibling call optimizations as
+     well as lots of bug fixes and test cases, and for improving the
+     Java build system.
+
+   * Janis Johnson for ia64 testing and fixes, her quality improvement
+     sidetracks, and web page maintenance.
+
+   * Kean Johnston for SCO OpenServer support and various fixes.
+
+   * Tim Josling for the sample language treelang based originally on
+     Richard Kenner's "toy" language.
+
+   * Nicolai Josuttis for additional libstdc++ documentation.
+
+   * Klaus Kaempf for his ongoing work to make alpha-vms a viable
+     target.
+
+   * Steven G. Kargl for work on GNU Fortran.
+
+   * David Kashtan of SRI adapted GCC to VMS.
+
+   * Ryszard Kabatek for many, many libstdc++ bug fixes and
+     optimizations of strings, especially member functions, and for
+     auto_ptr fixes.
+
+   * Geoffrey Keating for his ongoing work to make the PPC work for
+     GNU/Linux and his automatic regression tester.
+
+   * Brendan Kehoe for his ongoing work with G++ and for a lot of early
+     work in just about every part of libstdc++.
+
+   * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
+     MIL-STD-1750A.
+
+   * Richard Kenner of the New York University Ultracomputer Research
+     Laboratory wrote the machine descriptions for the AMD 29000, the
+     DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
+     support for instruction attributes.  He also made changes to better
+     support RISC processors including changes to common subexpression
+     elimination, strength reduction, function calling sequence
+     handling, and condition code support, in addition to generalizing
+     the code for frame pointer elimination and delay slot scheduling.
+     Richard Kenner was also the head maintainer of GCC for several
+     years.
+
+   * Mumit Khan for various contributions to the Cygwin and Mingw32
+     ports and maintaining binary releases for Microsoft Windows hosts,
+     and for massive libstdc++ porting work to Cygwin/Mingw32.
+
+   * Robin Kirkham for cpu32 support.
+
+   * Mark Klein for PA improvements.
+
+   * Thomas Koenig for various bug fixes.
+
+   * Bruce Korb for the new and improved fixincludes code.
+
+   * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3
+     effort.
+
+   * Charles LaBrec contributed the support for the Integrated Solutions
+     68020 system.
+
+   * Asher Langton and Mike Kumbera for contributing Cray pointer
+     support to GNU Fortran, and for other GNU Fortran improvements.
+
+   * Jeff Law for his direction via the steering committee, coordinating
+     the entire egcs project and GCC 2.95, rolling out snapshots and
+     releases, handling merges from GCC2, reviewing tons of patches that
+     might have fallen through the cracks else, and random but extensive
+     hacking.
+
+   * Walter Lee for work on the TILE-Gx and TILEPro ports.
+
+   * Marc Lehmann for his direction via the steering committee and
+     helping with analysis and improvements of x86 performance.
+
+   * Victor Leikehman for work on GNU Fortran.
+
+   * Ted Lemon wrote parts of the RTL reader and printer.
+
+   * Kriang Lerdsuwanakij for C++ improvements including template as
+     template parameter support, and many C++ fixes.
+
+   * Warren Levy for tremendous work on libgcj (Java Runtime Library)
+     and random work on the Java front end.
+
+   * Alain Lichnewsky ported GCC to the MIPS CPU.
+
+   * Oskar Liljeblad for hacking on AWT and his many Java bug reports
+     and patches.
+
+   * Robert Lipe for OpenServer support, new testsuites, testing, etc.
+
+   * Chen Liqin for various S+core related fixes/improvement, and for
+     maintaining the S+core port.
+
+   * Weiwen Liu for testing and various bug fixes.
+
+   * Manuel Lo'pez-Iba'n~ez for improving '-Wconversion' and many other
+     diagnostics fixes and improvements.
+
+   * Dave Love for his ongoing work with the Fortran front end and
+     runtime libraries.
+
+   * Martin von Lo"wis for internal consistency checking infrastructure,
+     various C++ improvements including namespace support, and tons of
+     assistance with libstdc++/compiler merges.
+
+   * H.J. Lu for his previous contributions to the steering committee,
+     many x86 bug reports, prototype patches, and keeping the GNU/Linux
+     ports working.
+
+   * Greg McGary for random fixes and (someday) bounded pointers.
+
+   * Andrew MacLeod for his ongoing work in building a real EH system,
+     various code generation improvements, work on the global optimizer,
+     etc.
+
+   * Vladimir Makarov for hacking some ugly i960 problems, PowerPC
+     hacking improvements to compile-time performance, overall knowledge
+     and direction in the area of instruction scheduling, and design and
+     implementation of the automaton based instruction scheduler.
+
+   * Bob Manson for his behind the scenes work on dejagnu.
+
+   * Philip Martin for lots of libstdc++ string and vector iterator
+     fixes and improvements, and string clean up and testsuites.
+
+   * All of the Mauve project contributors, for Java test code.
+
+   * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
+
+   * Adam Megacz for his work on the Microsoft Windows port of GCJ.
+
+   * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
+     powerpc, haifa, ECOFF debug support, and other assorted hacking.
+
+   * Jason Merrill for his direction via the steering committee and
+     leading the G++ effort.
+
+   * Martin Michlmayr for testing GCC on several architectures using the
+     entire Debian archive.
+
+   * David Miller for his direction via the steering committee, lots of
+     SPARC work, improvements in jump.c and interfacing with the Linux
+     kernel developers.
+
+   * Gary Miller ported GCC to Charles River Data Systems machines.
+
+   * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
+     the entire libstdc++ testsuite namespace-compatible.
+
+   * Mark Mitchell for his direction via the steering committee,
+     mountains of C++ work, load/store hoisting out of loops, alias
+     analysis improvements, ISO C 'restrict' support, and serving as
+     release manager from 2000 to 2011.
+
+   * Alan Modra for various GNU/Linux bits and testing.
+
+   * Toon Moene for his direction via the steering committee, Fortran
+     maintenance, and his ongoing work to make us make Fortran run fast.
+
+   * Jason Molenda for major help in the care and feeding of all the
+     services on the gcc.gnu.org (formerly egcs.cygnus.com)
+     machine--mail, web services, ftp services, etc etc.  Doing all this
+     work on scrap paper and the backs of envelopes would have been...
+     difficult.
+
+   * Catherine Moore for fixing various ugly problems we have sent her
+     way, including the haifa bug which was killing the Alpha & PowerPC
+     Linux kernels.
+
+   * Mike Moreton for his various Java patches.
+
+   * David Mosberger-Tang for various Alpha improvements, and for the
+     initial IA-64 port.
+
+   * Stephen Moshier contributed the floating point emulator that
+     assists in cross-compilation and permits support for floating point
+     numbers wider than 64 bits and for ISO C99 support.
+
+   * Bill Moyer for his behind the scenes work on various issues.
+
+   * Philippe De Muyter for his work on the m68k port.
+
+   * Joseph S. Myers for his work on the PDP-11 port, format checking
+     and ISO C99 support, and continuous emphasis on (and contributions
+     to) documentation.
+
+   * Nathan Myers for his work on libstdc++-v3: architecture and
+     authorship through the first three snapshots, including
+     implementation of locale infrastructure, string, shadow C headers,
+     and the initial project documentation (DESIGN, CHECKLIST, and so
+     forth).  Later, more work on MT-safe string and shadow headers.
+
+   * Felix Natter for documentation on porting libstdc++.
+
+   * Nathanael Nerode for cleaning up the configuration/build process.
+
+   * NeXT, Inc. donated the front end that supports the Objective-C
+     language.
+
+   * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the
+     search engine setup, various documentation fixes and other small
+     fixes.
+
+   * Geoff Noer for his work on getting cygwin native builds working.
+
+   * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance
+     tracking web pages, GIMPLE tuples, and assorted fixes.
+
+   * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64,
+     FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related
+     infrastructure improvements.
+
+   * Alexandre Oliva for various build infrastructure improvements,
+     scripts and amazing testing work, including keeping libtool issues
+     sane and happy.
+
+   * Stefan Olsson for work on mt_alloc.
+
+   * Melissa O'Neill for various NeXT fixes.
+
+   * Rainer Orth for random MIPS work, including improvements to GCC's
+     o32 ABI support, improvements to dejagnu's MIPS support, Java
+     configuration clean-ups and porting work, and maintaining the IRIX,
+     Solaris 2, and Tru64 UNIX ports.
+
+   * Hartmut Penner for work on the s390 port.
+
+   * Paul Petersen wrote the machine description for the Alliant FX/8.
+
+   * Alexandre Petit-Bianco for implementing much of the Java compiler
+     and continued Java maintainership.
+
+   * Matthias Pfaller for major improvements to the NS32k port.
+
+   * Gerald Pfeifer for his direction via the steering committee,
+     pointing out lots of problems we need to solve, maintenance of the
+     web pages, and taking care of documentation maintenance in general.
+
+   * Andrew Pinski for processing bug reports by the dozen.
+
+   * Ovidiu Predescu for his work on the Objective-C front end and
+     runtime libraries.
+
+   * Jerry Quinn for major performance improvements in C++ formatted
+     I/O.
+
+   * Ken Raeburn for various improvements to checker, MIPS ports and
+     various cleanups in the compiler.
+
+   * Rolf W. Rasmussen for hacking on AWT.
+
+   * David Reese of Sun Microsystems contributed to the Solaris on
+     PowerPC port.
+
+   * Volker Reichelt for keeping up with the problem reports.
+
+   * Joern Rennecke for maintaining the sh port, loop, regmove & reload
+     hacking and developing and maintaining the Epiphany port.
+
+   * Loren J. Rittle for improvements to libstdc++-v3 including the
+     FreeBSD port, threading fixes, thread-related configury changes,
+     critical threading documentation, and solutions to really tricky
+     I/O problems, as well as keeping GCC properly working on FreeBSD
+     and continuous testing.
+
+   * Craig Rodrigues for processing tons of bug reports.
+
+   * Ola Ro"nnerup for work on mt_alloc.
+
+   * Gavin Romig-Koch for lots of behind the scenes MIPS work.
+
+   * David Ronis inspired and encouraged Craig to rewrite the G77
+     documentation in texinfo format by contributing a first pass at a
+     translation of the old 'g77-0.5.16/f/DOC' file.
+
+   * Ken Rose for fixes to GCC's delay slot filling code.
+
+   * Paul Rubin wrote most of the preprocessor.
+
+   * Pe'tur Runo'lfsson for major performance improvements in C++
+     formatted I/O and large file support in C++ filebuf.
+
+   * Chip Salzenberg for libstdc++ patches and improvements to locales,
+     traits, Makefiles, libio, libtool hackery, and "long long" support.
+
+   * Juha Sarlin for improvements to the H8 code generator.
+
+   * Greg Satz assisted in making GCC work on HP-UX for the 9000 series
+     300.
+
+   * Roger Sayle for improvements to constant folding and GCC's RTL
+     optimizers as well as for fixing numerous bugs.
+
+   * Bradley Schatz for his work on the GCJ FAQ.
+
+   * Peter Schauer wrote the code to allow debugging to work on the
+     Alpha.
+
+   * William Schelter did most of the work on the Intel 80386 support.
+
+   * Tobias Schlu"ter for work on GNU Fortran.
+
+   * Bernd Schmidt for various code generation improvements and major
+     work in the reload pass, serving as release manager for GCC 2.95.3,
+     and work on the Blackfin and C6X ports.
+
+   * Peter Schmid for constant testing of libstdc++--especially
+     application testing, going above and beyond what was requested for
+     the release criteria--and libstdc++ header file tweaks.
+
+   * Jason Schroeder for jcf-dump patches.
+
+   * Andreas Schwab for his work on the m68k port.
+
+   * Lars Segerlund for work on GNU Fortran.
+
+   * Dodji Seketeli for numerous C++ bug fixes and debug info
+     improvements.
+
+   * Tim Shen for major work on '<regex>'.
+
+   * Joel Sherrill for his direction via the steering committee, RTEMS
+     contributions and RTEMS testing.
+
+   * Nathan Sidwell for many C++ fixes/improvements.
+
+   * Jeffrey Siegal for helping RMS with the original design of GCC,
+     some code which handles the parse tree and RTL data structures,
+     constant folding and help with the original VAX & m68k ports.
+
+   * Kenny Simpson for prompting libstdc++ fixes due to defect reports
+     from the LWG (thereby keeping GCC in line with updates from the
+     ISO).
+
+   * Franz Sirl for his ongoing work with making the PPC port stable for
+     GNU/Linux.
+
+   * Andrey Slepuhin for assorted AIX hacking.
+
+   * Trevor Smigiel for contributing the SPU port.
+
+   * Christopher Smith did the port for Convex machines.
+
+   * Danny Smith for his major efforts on the Mingw (and Cygwin) ports.
+
+   * Randy Smith finished the Sun FPA support.
+
+   * Ed Smith-Rowland for his continuous work on libstdc++-v3, special
+     functions, '<random>', and various improvements to C++11 features.
+
+   * Scott Snyder for queue, iterator, istream, and string fixes and
+     libstdc++ testsuite entries.  Also for providing the patch to G77
+     to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and
+     'LOGICAL*1'.
+
+   * Zdenek Sojka for running automated regression testing of GCC and
+     reporting numerous bugs.
+
+   * Jayant Sonar for contributing the CR16 port.
+
+   * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
+
+   * Richard Stallman, for writing the original GCC and launching the
+     GNU project.
+
+   * Jan Stein of the Chalmers Computer Society provided support for
+     Genix, as well as part of the 32000 machine description.
+
+   * Nigel Stephens for various mips16 related fixes/improvements.
+
+   * Jonathan Stone wrote the machine description for the Pyramid
+     computer.
+
+   * Graham Stott for various infrastructure improvements.
+
+   * John Stracke for his Java HTTP protocol fixes.
+
+   * Mike Stump for his Elxsi port, G++ contributions over the years and
+     more recently his vxworks contributions
+
+   * Jeff Sturm for Java porting help, bug fixes, and encouragement.
+
+   * Shigeya Suzuki for this fixes for the bsdi platforms.
+
+   * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64
+     support, general configury hacking, fixincludes, etc.
+
+   * Holger Teutsch provided the support for the Clipper CPU.
+
+   * Gary Thomas for his ongoing work to make the PPC work for
+     GNU/Linux.
+
+   * Philipp Thomas for random bug fixes throughout the compiler
+
+   * Jason Thorpe for thread support in libstdc++ on NetBSD.
+
+   * Kresten Krab Thorup wrote the run time support for the Objective-C
+     language and the fantastic Java bytecode interpreter.
+
+   * Michael Tiemann for random bug fixes, the first instruction
+     scheduler, initial C++ support, function integration, NS32k, SPARC
+     and M88k machine description work, delay slot scheduling.
+
+   * Andreas Tobler for his work porting libgcj to Darwin.
+
+   * Teemu Torma for thread safe exception handling support.
+
+   * Leonard Tower wrote parts of the parser, RTL generator, and RTL
+     definitions, and of the VAX machine description.
+
+   * Daniel Towner and Hariharan Sandanagobalane contributed and
+     maintain the picoChip port.
+
+   * Tom Tromey for internationalization support and for his many Java
+     contributions and libgcj maintainership.
+
+   * Lassi Tuura for improvements to config.guess to determine HP
+     processor types.
+
+   * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes.
+
+   * Andy Vaught for the design and initial implementation of the GNU
+     Fortran front end.
+
+   * Brent Verner for work with the libstdc++ cshadow files and their
+     associated configure steps.
+
+   * Todd Vierling for contributions for NetBSD ports.
+
+   * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
+     guidance.
+
+   * Dean Wakerley for converting the install documentation from HTML to
+     texinfo in time for GCC 3.0.
+
+   * Krister Walfridsson for random bug fixes.
+
+   * Feng Wang for contributions to GNU Fortran.
+
+   * Stephen M. Webb for time and effort on making libstdc++ shadow
+     files work with the tricky Solaris 8+ headers, and for pushing the
+     build-time header tree.  Also, for starting and driving the
+     '<regex>' effort.
+
+   * John Wehle for various improvements for the x86 code generator,
+     related infrastructure improvements to help x86 code generation,
+     value range propagation and other work, WE32k port.
+
+   * Ulrich Weigand for work on the s390 port.
+
+   * Zack Weinberg for major work on cpplib and various other bug fixes.
+
+   * Matt Welsh for help with Linux Threads support in GCJ.
+
+   * Urban Widmark for help fixing java.io.
+
+   * Mark Wielaard for new Java library code and his work integrating
+     with Classpath.
+
+   * Dale Wiles helped port GCC to the Tahoe.
+
+   * Bob Wilson from Tensilica, Inc. for the Xtensa port.
+
+   * Jim Wilson for his direction via the steering committee, tackling
+     hard problems in various places that nobody else wanted to work on,
+     strength reduction and other loop optimizations.
+
+   * Paul Woegerer and Tal Agmon for the CRX port.
+
+   * Carlo Wood for various fixes.
+
+   * Tom Wood for work on the m88k port.
+
+   * Chung-Ju Wu for his work on the Andes NDS32 port.
+
+   * Canqun Yang for work on GNU Fortran.
+
+   * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
+     description for the Tron architecture (specifically, the Gmicro).
+
+   * Kevin Zachmann helped port GCC to the Tahoe.
+
+   * Ayal Zaks for Swing Modulo Scheduling (SMS).
+
+   * Xiaoqiang Zhang for work on GNU Fortran.
+
+   * Gilles Zunino for help porting Java to Irix.
+
+ The following people are recognized for their contributions to GNAT,
+the Ada front end of GCC:
+   * Bernard Banner
+
+   * Romain Berrendonner
+
+   * Geert Bosch
+
+   * Emmanuel Briot
+
+   * Joel Brobecker
+
+   * Ben Brosgol
+
+   * Vincent Celier
+
+   * Arnaud Charlet
+
+   * Chien Chieng
+
+   * Cyrille Comar
+
+   * Cyrille Crozes
+
+   * Robert Dewar
+
+   * Gary Dismukes
+
+   * Robert Duff
+
+   * Ed Falis
+
+   * Ramon Fernandez
+
+   * Sam Figueroa
+
+   * Vasiliy Fofanov
+
+   * Michael Friess
+
+   * Franco Gasperoni
+
+   * Ted Giering
+
+   * Matthew Gingell
+
+   * Laurent Guerby
+
+   * Jerome Guitton
+
+   * Olivier Hainque
+
+   * Jerome Hugues
+
+   * Hristian Kirtchev
+
+   * Jerome Lambourg
+
+   * Bruno Leclerc
+
+   * Albert Lee
+
+   * Sean McNeil
+
+   * Javier Miranda
+
+   * Laurent Nana
+
+   * Pascal Obry
+
+   * Dong-Ik Oh
+
+   * Laurent Pautet
+
+   * Brett Porter
+
+   * Thomas Quinot
+
+   * Nicolas Roche
+
+   * Pat Rogers
+
+   * Jose Ruiz
+
+   * Douglas Rupp
+
+   * Sergey Rybin
+
+   * Gail Schenker
+
+   * Ed Schonberg
+
+   * Nicolas Setton
+
+   * Samuel Tardieu
+
+ The following people are recognized for their contributions of new
+features, bug reports, testing and integration of classpath/libgcj for
+GCC version 4.1:
+   * Lillian Angel for 'JTree' implementation and lots Free Swing
+     additions and bug fixes.
+
+   * Wolfgang Baer for 'GapContent' bug fixes.
+
+   * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse
+     event fixes, lots of Free Swing work including 'JTable' editing.
+
+   * Stuart Ballard for RMI constant fixes.
+
+   * Goffredo Baroncelli for 'HTTPURLConnection' fixes.
+
+   * Gary Benson for 'MessageFormat' fixes.
+
+   * Daniel Bonniot for 'Serialization' fixes.
+
+   * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX'
+     and 'DOM xml:id' support.
+
+   * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes.
+
+   * Archie Cobbs for build fixes, VM interface updates,
+     'URLClassLoader' updates.
+
+   * Kelley Cook for build fixes.
+
+   * Martin Cordova for Suggestions for better 'SocketTimeoutException'.
+
+   * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and
+     improvements.
+
+   * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo
+     2D support.  Lots of imageio framework additions, lots of AWT and
+     Free Swing bug fixes.
+
+   * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization
+     fixes, better 'Proxy' support, bug fixes and IKVM integration.
+
+   * Santiago Gala for 'AccessControlContext' fixes.
+
+   * Nicolas Geoffray for 'VMClassLoader' and 'AccessController'
+     improvements.
+
+   * David Gilbert for 'basic' and 'metal' icon and plaf support and
+     lots of documenting, Lots of Free Swing and metal theme additions.
+     'MetalIconFactory' implementation.
+
+   * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers.
+
+   * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj
+     build speedups.
+
+   * Kim Ho for 'JFileChooser' implementation.
+
+   * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates,
+     'Serialization' fixes, 'Properties' XML support and generic branch
+     work, VMIntegration guide update.
+
+   * Bastiaan Huisman for 'TimeZone' bug fixing.
+
+   * Andreas Jaeger for mprec updates.
+
+   * Paul Jenner for better '-Werror' support.
+
+   * Ito Kazumitsu for 'NetworkInterface' implementation and updates.
+
+   * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus
+     bug fixes all over.  Lots of Free Swing work including styled text.
+
+   * Simon Kitching for 'String' cleanups and optimization suggestions.
+
+   * Michael Koch for configuration fixes, 'Locale' updates, bug and
+     build fixes.
+
+   * Guilhem Lavaux for configuration, thread and channel fixes and
+     Kaffe integration.  JCL native 'Pointer' updates.  Logger bug
+     fixes.
+
+   * David Lichteblau for JCL support library global/local reference
+     cleanups.
+
+   * Aaron Luchko for JDWP updates and documentation fixes.
+
+   * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex
+     features.
+
+   * Sven de Marothy for BMP imageio support, CSS and 'TextLayout'
+     fixes.  'GtkImage' rewrite, 2D, awt, free swing and date/time fixes
+     and implementing the Qt4 peers.
+
+   * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock,
+     'SystemLogger' and 'FileHandler' rotate implementations, NIO
+     'FileChannel.map' support, security and policy updates.
+
+   * Bryce McKinlay for RMI work.
+
+   * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus
+     testing and documenting.
+
+   * Kalle Olavi Niemitalo for build fixes.
+
+   * Rainer Orth for build fixes.
+
+   * Andrew Overholt for 'File' locking fixes.
+
+   * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates.
+
+   * Olga Rodimina for 'MenuSelectionManager' implementation.
+
+   * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes.
+
+   * Julian Scheid for documentation updates and gjdoc support.
+
+   * Christian Schlichtherle for zip fixes and cleanups.
+
+   * Robert Schuster for documentation updates and beans fixes,
+     'TreeNode' enumerations and 'ActionCommand' and various fixes, XML
+     and URL, AWT and Free Swing bug fixes.
+
+   * Keith Seitz for lots of JDWP work.
+
+   * Christian Thalinger for 64-bit cleanups, Configuration and VM
+     interface fixes and 'CACAO' integration, 'fdlibm' updates.
+
+   * Gael Thomas for 'VMClassLoader' boot packages support suggestions.
+
+   * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4'
+     support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates.
+
+   * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe
+     integration.  'Qt4' build infrastructure, 'SHA1PRNG' and
+     'GdkPixbugDecoder' updates.
+
+   * Tom Tromey for Eclipse integration, generics work, lots of bug
+     fixes and gcj integration including coordinating The Big Merge.
+
+   * Mark Wielaard for bug fixes, packaging and release management,
+     'Clipboard' implementation, system call interrupts and network
+     timeouts and 'GdkPixpufDecoder' fixes.
+
+ In addition to the above, all of which also contributed time and energy
+in testing GCC, we would like to thank the following for their
+contributions to testing:
+
+   * Michael Abd-El-Malek
+
+   * Thomas Arend
+
+   * Bonzo Armstrong
+
+   * Steven Ashe
+
+   * Chris Baldwin
+
+   * David Billinghurst
+
+   * Jim Blandy
+
+   * Stephane Bortzmeyer
+
+   * Horst von Brand
+
+   * Frank Braun
+
+   * Rodney Brown
+
+   * Sidney Cadot
+
+   * Bradford Castalia
+
+   * Robert Clark
+
+   * Jonathan Corbet
+
+   * Ralph Doncaster
+
+   * Richard Emberson
+
+   * Levente Farkas
+
+   * Graham Fawcett
+
+   * Mark Fernyhough
+
+   * Robert A. French
+
+   * Jo"rgen Freyh
+
+   * Mark K. Gardner
+
+   * Charles-Antoine Gauthier
+
+   * Yung Shing Gene
+
+   * David Gilbert
+
+   * Simon Gornall
+
+   * Fred Gray
+
+   * John Griffin
+
+   * Patrik Hagglund
+
+   * Phil Hargett
+
+   * Amancio Hasty
+
+   * Takafumi Hayashi
+
+   * Bryan W. Headley
+
+   * Kevin B. Hendricks
+
+   * Joep Jansen
+
+   * Christian Joensson
+
+   * Michel Kern
+
+   * David Kidd
+
+   * Tobias Kuipers
+
+   * Anand Krishnaswamy
+
+   * A. O. V. Le Blanc
+
+   * llewelly
+
+   * Damon Love
+
+   * Brad Lucier
+
+   * Matthias Klose
+
+   * Martin Knoblauch
+
+   * Rick Lutowski
+
+   * Jesse Macnish
+
+   * Stefan Morrell
+
+   * Anon A. Mous
+
+   * Matthias Mueller
+
+   * Pekka Nikander
+
+   * Rick Niles
+
+   * Jon Olson
+
+   * Magnus Persson
+
+   * Chris Pollard
+
+   * Richard Polton
+
+   * Derk Reefman
+
+   * David Rees
+
+   * Paul Reilly
+
+   * Tom Reilly
+
+   * Torsten Rueger
+
+   * Danny Sadinoff
+
+   * Marc Schifer
+
+   * Erik Schnetter
+
+   * Wayne K. Schroll
+
+   * David Schuler
+
+   * Vin Shelton
+
+   * Tim Souder
+
+   * Adam Sulmicki
+
+   * Bill Thorson
+
+   * George Talbot
+
+   * Pedro A. M. Vazquez
+
+   * Gregory Warnes
+
+   * Ian Watson
+
+   * David E. Young
+
+   * And many others
+
+ And finally we'd like to thank everyone who uses the compiler, provides
+feedback and generally reminds us why we're doing this work in the first
+place.
+
+
+File: gcc.info,  Node: Option Index,  Next: Keyword Index,  Prev: Contributors,  Up: Top
+
+Option Index
+************
+
+GCC's command line options are indexed here without any initial '-' or
+'--'.  Where an option has both positive and negative forms (such as
+'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are
+indexed under the most appropriate form; it may sometimes be useful to
+look up both forms.
+
+
+* Menu:
+
+* ###:                                   Overall Options.    (line  209)
+* (fvtv-debug):                          C++ Dialect Options.
+                                                             (line  362)
+* -fno-keep-inline-dllexport:            Optimize Options.   (line  309)
+* -mcpu:                                 RX Options.         (line   30)
+* -mcpu=:                                MSP430 Options.     (line   35)
+* -mpointer-size=SIZE:                   VMS Options.        (line   20)
+* 8bit-idiv:                             i386 and x86-64 Options.
+                                                             (line  917)
+* A:                                     Preprocessor Options.
+                                                             (line  596)
+* allowable_client:                      Darwin Options.     (line  196)
+* all_load:                              Darwin Options.     (line  110)
+* ansi:                                  Standards.          (line   16)
+* ansi <1>:                              C Dialect Options.  (line   11)
+* ansi <2>:                              Preprocessor Options.
+                                                             (line  340)
+* ansi <3>:                              Other Builtins.     (line   21)
+* ansi <4>:                              Non-bugs.           (line  107)
+* arch_errors_fatal:                     Darwin Options.     (line  114)
+* aux-info:                              C Dialect Options.  (line  173)
+* avx256-split-unaligned-load:           i386 and x86-64 Options.
+                                                             (line  925)
+* avx256-split-unaligned-store:          i386 and x86-64 Options.
+                                                             (line  925)
+* B:                                     Directory Options.  (line   44)
+* Bdynamic:                              VxWorks Options.    (line   22)
+* bind_at_load:                          Darwin Options.     (line  118)
+* Bstatic:                               VxWorks Options.    (line   22)
+* bundle:                                Darwin Options.     (line  123)
+* bundle_loader:                         Darwin Options.     (line  127)
+* c:                                     Overall Options.    (line  164)
+* C:                                     Preprocessor Options.
+                                                             (line  653)
+* c <1>:                                 Link Options.       (line   20)
+* client_name:                           Darwin Options.     (line  196)
+* compatibility_version:                 Darwin Options.     (line  196)
+* coverage:                              Debugging Options.  (line  491)
+* current_version:                       Darwin Options.     (line  196)
+* d:                                     Debugging Options.  (line  622)
+* D:                                     Preprocessor Options.
+                                                             (line   46)
+* da:                                    Debugging Options.  (line  825)
+* dA:                                    Debugging Options.  (line  828)
+* dD:                                    Debugging Options.  (line  832)
+* dD <1>:                                Preprocessor Options.
+                                                             (line  627)
+* dead_strip:                            Darwin Options.     (line  196)
+* dependency-file:                       Darwin Options.     (line  196)
+* dH:                                    Debugging Options.  (line  836)
+* dI:                                    Preprocessor Options.
+                                                             (line  636)
+* dM:                                    Preprocessor Options.
+                                                             (line  612)
+* dN:                                    Preprocessor Options.
+                                                             (line  633)
+* dp:                                    Debugging Options.  (line  839)
+* dP:                                    Debugging Options.  (line  844)
+* dU:                                    Preprocessor Options.
+                                                             (line  640)
+* dumpmachine:                           Debugging Options.  (line 1410)
+* dumpspecs:                             Debugging Options.  (line 1418)
+* dumpversion:                           Debugging Options.  (line 1414)
+* dx:                                    Debugging Options.  (line  848)
+* dylib_file:                            Darwin Options.     (line  196)
+* dylinker_install_name:                 Darwin Options.     (line  196)
+* dynamic:                               Darwin Options.     (line  196)
+* dynamiclib:                            Darwin Options.     (line  131)
+* E:                                     Overall Options.    (line  185)
+* E <1>:                                 Link Options.       (line   20)
+* EB:                                    ARC Options.        (line  345)
+* EB <1>:                                MIPS Options.       (line    7)
+* EL:                                    ARC Options.        (line  354)
+* EL <1>:                                MIPS Options.       (line   10)
+* exported_symbols_list:                 Darwin Options.     (line  196)
+* F:                                     Darwin Options.     (line   31)
+* fabi-version:                          C++ Dialect Options.
+                                                             (line   19)
+* fada-spec-parent:                      Overall Options.    (line  367)
+* faggressive-loop-optimizations:        Optimize Options.   (line  478)
+* falign-functions:                      Optimize Options.   (line 1472)
+* falign-jumps:                          Optimize Options.   (line 1521)
+* falign-labels:                         Optimize Options.   (line 1490)
+* falign-loops:                          Optimize Options.   (line 1508)
+* fallow-parameterless-variadic-functions: C Dialect Options.
+                                                             (line  189)
+* fassociative-math:                     Optimize Options.   (line 2000)
+* fasynchronous-unwind-tables:           Code Gen Options.   (line  145)
+* fauto-inc-dec:                         Optimize Options.   (line  502)
+* fbounds-check:                         Code Gen Options.   (line   15)
+* fbranch-probabilities:                 Optimize Options.   (line 2128)
+* fbranch-target-load-optimize:          Optimize Options.   (line 2243)
+* fbranch-target-load-optimize2:         Optimize Options.   (line 2249)
+* fbtr-bb-exclusive:                     Optimize Options.   (line 2253)
+* fcall-saved:                           Code Gen Options.   (line  355)
+* fcall-used:                            Code Gen Options.   (line  341)
+* fcaller-saves:                         Optimize Options.   (line  810)
+* fcheck-data-deps:                      Optimize Options.   (line 1089)
+* fcheck-new:                            C++ Dialect Options.
+                                                             (line   54)
+* fcilkplus:                             C Dialect Options.  (line  276)
+* fcombine-stack-adjustments:            Optimize Options.   (line  822)
+* fcommon:                               Variable Attributes.
+                                                             (line  104)
+* fcompare-debug:                        Debugging Options.  (line  282)
+* fcompare-debug-second:                 Debugging Options.  (line  308)
+* fcompare-elim:                         Optimize Options.   (line 1836)
+* fcond-mismatch:                        C Dialect Options.  (line  339)
+* fconserve-stack:                       Optimize Options.   (line  828)
+* fconstant-string-class:                Objective-C and Objective-C++ Dialect Options.
+                                                             (line   30)
+* fconstexpr-depth:                      C++ Dialect Options.
+                                                             (line   64)
+* fcprop-registers:                      Optimize Options.   (line 1854)
+* fcrossjumping:                         Optimize Options.   (line  495)
+* fcse-follow-jumps:                     Optimize Options.   (line  414)
+* fcse-skip-blocks:                      Optimize Options.   (line  423)
+* fcx-fortran-rules:                     Optimize Options.   (line 2115)
+* fcx-limited-range:                     Optimize Options.   (line 2103)
+* fdata-sections:                        Optimize Options.   (line 2224)
+* fdbg-cnt:                              Debugging Options.  (line  543)
+* fdbg-cnt-list:                         Debugging Options.  (line  540)
+* fdce:                                  Optimize Options.   (line  508)
+* fdebug-cpp:                            Preprocessor Options.
+                                                             (line  527)
+* fdebug-prefix-map:                     Debugging Options.  (line  402)
+* fdebug-types-section:                  Debugging Options.  (line   79)
+* fdeclone-ctor-dtor:                    Optimize Options.   (line  531)
+* fdeduce-init-list:                     C++ Dialect Options.
+                                                             (line   70)
+* fdelayed-branch:                       Optimize Options.   (line  657)
+* fdelete-dead-exceptions:               Code Gen Options.   (line  130)
+* fdelete-null-pointer-checks:           Optimize Options.   (line  542)
+* fdevirtualize:                         Optimize Options.   (line  560)
+* fdevirtualize-speculatively:           Optimize Options.   (line  567)
+* fdiagnostics-color:                    Language Independent Options.
+                                                             (line   35)
+* fdiagnostics-show-caret:               Language Independent Options.
+                                                             (line   92)
+* fdiagnostics-show-location:            Language Independent Options.
+                                                             (line   20)
+* fdiagnostics-show-option:              Language Independent Options.
+                                                             (line   86)
+* fdirectives-only:                      Preprocessor Options.
+                                                             (line  475)
+* fdisable-:                             Debugging Options.  (line  553)
+* fdollars-in-identifiers:               Preprocessor Options.
+                                                             (line  496)
+* fdollars-in-identifiers <1>:           Interoperation.     (line  141)
+* fdse:                                  Optimize Options.   (line  512)
+* fdump-ada-spec:                        Overall Options.    (line  362)
+* fdump-class-hierarchy:                 Debugging Options.  (line  879)
+* fdump-final-insns:                     Debugging Options.  (line  276)
+* fdump-go-spec:                         Overall Options.    (line  371)
+* fdump-ipa:                             Debugging Options.  (line  887)
+* fdump-noaddr:                          Debugging Options.  (line  852)
+* fdump-passes:                          Debugging Options.  (line  904)
+* fdump-rtl-alignments:                  Debugging Options.  (line  643)
+* fdump-rtl-all:                         Debugging Options.  (line  825)
+* fdump-rtl-asmcons:                     Debugging Options.  (line  646)
+* fdump-rtl-auto_inc_dec:                Debugging Options.  (line  650)
+* fdump-rtl-barriers:                    Debugging Options.  (line  654)
+* fdump-rtl-bbpart:                      Debugging Options.  (line  657)
+* fdump-rtl-bbro:                        Debugging Options.  (line  660)
+* fdump-rtl-btl2:                        Debugging Options.  (line  664)
+* fdump-rtl-btl2 <1>:                    Debugging Options.  (line  664)
+* fdump-rtl-bypass:                      Debugging Options.  (line  668)
+* fdump-rtl-ce1:                         Debugging Options.  (line  679)
+* fdump-rtl-ce2:                         Debugging Options.  (line  679)
+* fdump-rtl-ce3:                         Debugging Options.  (line  679)
+* fdump-rtl-combine:                     Debugging Options.  (line  671)
+* fdump-rtl-compgotos:                   Debugging Options.  (line  674)
+* fdump-rtl-cprop_hardreg:               Debugging Options.  (line  683)
+* fdump-rtl-csa:                         Debugging Options.  (line  686)
+* fdump-rtl-cse1:                        Debugging Options.  (line  690)
+* fdump-rtl-cse2:                        Debugging Options.  (line  690)
+* fdump-rtl-dbr:                         Debugging Options.  (line  697)
+* fdump-rtl-dce:                         Debugging Options.  (line  694)
+* fdump-rtl-dce1:                        Debugging Options.  (line  701)
+* fdump-rtl-dce2:                        Debugging Options.  (line  701)
+* fdump-rtl-dfinish:                     Debugging Options.  (line  821)
+* fdump-rtl-dfinit:                      Debugging Options.  (line  821)
+* fdump-rtl-eh:                          Debugging Options.  (line  705)
+* fdump-rtl-eh_ranges:                   Debugging Options.  (line  708)
+* fdump-rtl-expand:                      Debugging Options.  (line  711)
+* fdump-rtl-fwprop1:                     Debugging Options.  (line  715)
+* fdump-rtl-fwprop2:                     Debugging Options.  (line  715)
+* fdump-rtl-gcse1:                       Debugging Options.  (line  720)
+* fdump-rtl-gcse2:                       Debugging Options.  (line  720)
+* fdump-rtl-init-regs:                   Debugging Options.  (line  724)
+* fdump-rtl-initvals:                    Debugging Options.  (line  727)
+* fdump-rtl-into_cfglayout:              Debugging Options.  (line  730)
+* fdump-rtl-ira:                         Debugging Options.  (line  733)
+* fdump-rtl-jump:                        Debugging Options.  (line  736)
+* fdump-rtl-loop2:                       Debugging Options.  (line  739)
+* fdump-rtl-mach:                        Debugging Options.  (line  743)
+* fdump-rtl-mode_sw:                     Debugging Options.  (line  747)
+* fdump-rtl-outof_cfglayout:             Debugging Options.  (line  753)
+* fdump-rtl-PASS:                        Debugging Options.  (line  622)
+* fdump-rtl-peephole2:                   Debugging Options.  (line  756)
+* fdump-rtl-postreload:                  Debugging Options.  (line  759)
+* fdump-rtl-pro_and_epilogue:            Debugging Options.  (line  762)
+* fdump-rtl-ree:                         Debugging Options.  (line  770)
+* fdump-rtl-regclass:                    Debugging Options.  (line  821)
+* fdump-rtl-rnreg:                       Debugging Options.  (line  750)
+* fdump-rtl-sched1:                      Debugging Options.  (line  766)
+* fdump-rtl-sched2:                      Debugging Options.  (line  766)
+* fdump-rtl-seqabstr:                    Debugging Options.  (line  773)
+* fdump-rtl-shorten:                     Debugging Options.  (line  776)
+* fdump-rtl-sibling:                     Debugging Options.  (line  779)
+* fdump-rtl-sms:                         Debugging Options.  (line  791)
+* fdump-rtl-split1:                      Debugging Options.  (line  786)
+* fdump-rtl-split2:                      Debugging Options.  (line  786)
+* fdump-rtl-split3:                      Debugging Options.  (line  786)
+* fdump-rtl-split4:                      Debugging Options.  (line  786)
+* fdump-rtl-split5:                      Debugging Options.  (line  786)
+* fdump-rtl-stack:                       Debugging Options.  (line  795)
+* fdump-rtl-subreg1:                     Debugging Options.  (line  801)
+* fdump-rtl-subreg2:                     Debugging Options.  (line  801)
+* fdump-rtl-subregs_of_mode_finish:      Debugging Options.  (line  821)
+* fdump-rtl-subregs_of_mode_init:        Debugging Options.  (line  821)
+* fdump-rtl-unshare:                     Debugging Options.  (line  805)
+* fdump-rtl-vartrack:                    Debugging Options.  (line  808)
+* fdump-rtl-vregs:                       Debugging Options.  (line  811)
+* fdump-rtl-web:                         Debugging Options.  (line  814)
+* fdump-statistics:                      Debugging Options.  (line  908)
+* fdump-translation-unit:                Debugging Options.  (line  870)
+* fdump-tree:                            Debugging Options.  (line  920)
+* fdump-tree-alias:                      Debugging Options.  (line 1042)
+* fdump-tree-all:                        Debugging Options.  (line 1126)
+* fdump-tree-ccp:                        Debugging Options.  (line 1046)
+* fdump-tree-cfg:                        Debugging Options.  (line 1030)
+* fdump-tree-ch:                         Debugging Options.  (line 1034)
+* fdump-tree-copyprop:                   Debugging Options.  (line 1062)
+* fdump-tree-copyrename:                 Debugging Options.  (line 1102)
+* fdump-tree-dce:                        Debugging Options.  (line 1070)
+* fdump-tree-dom:                        Debugging Options.  (line 1083)
+* fdump-tree-dse:                        Debugging Options.  (line 1088)
+* fdump-tree-forwprop:                   Debugging Options.  (line 1097)
+* fdump-tree-fre:                        Debugging Options.  (line 1058)
+* fdump-tree-gimple:                     Debugging Options.  (line 1025)
+* fdump-tree-nrv:                        Debugging Options.  (line 1107)
+* fdump-tree-optimized:                  Debugging Options.  (line 1022)
+* fdump-tree-original:                   Debugging Options.  (line 1019)
+* fdump-tree-phiopt:                     Debugging Options.  (line 1092)
+* fdump-tree-pre:                        Debugging Options.  (line 1054)
+* fdump-tree-sink:                       Debugging Options.  (line 1079)
+* fdump-tree-slp:                        Debugging Options.  (line 1117)
+* fdump-tree-sra:                        Debugging Options.  (line 1074)
+* fdump-tree-ssa:                        Debugging Options.  (line 1038)
+* fdump-tree-storeccp:                   Debugging Options.  (line 1050)
+* fdump-tree-store_copyprop:             Debugging Options.  (line 1066)
+* fdump-tree-vect:                       Debugging Options.  (line 1112)
+* fdump-tree-vrp:                        Debugging Options.  (line 1122)
+* fdump-unnumbered:                      Debugging Options.  (line  858)
+* fdump-unnumbered-links:                Debugging Options.  (line  864)
+* fdwarf2-cfi-asm:                       Debugging Options.  (line  406)
+* fearly-inlining:                       Optimize Options.   (line  268)
+* feliminate-dwarf2-dups:                Debugging Options.  (line  321)
+* feliminate-unused-debug-symbols:       Debugging Options.  (line   67)
+* feliminate-unused-debug-types:         Debugging Options.  (line 1422)
+* femit-struct-debug-baseonly:           Debugging Options.  (line  326)
+* femit-struct-debug-reduced:            Debugging Options.  (line  339)
+* fenable-:                              Debugging Options.  (line  553)
+* fexceptions:                           Code Gen Options.   (line  108)
+* fexcess-precision:                     Optimize Options.   (line 1927)
+* fexec-charset:                         Preprocessor Options.
+                                                             (line  554)
+* fexpensive-optimizations:              Optimize Options.   (line  576)
+* fext-numeric-literals:                 C++ Dialect Options.
+                                                             (line  587)
+* fextended-identifiers:                 Preprocessor Options.
+                                                             (line  499)
+* fextern-tls-init:                      C++ Dialect Options.
+                                                             (line  120)
+* ffast-math:                            Optimize Options.   (line 1950)
+* ffat-lto-objects:                      Optimize Options.   (line 1818)
+* ffinite-math-only:                     Optimize Options.   (line 2027)
+* ffix-and-continue:                     Darwin Options.     (line  104)
+* ffixed:                                Code Gen Options.   (line  329)
+* ffloat-store:                          Optimize Options.   (line 1913)
+* ffloat-store <1>:                      Disappointments.    (line   77)
+* ffor-scope:                            C++ Dialect Options.
+                                                             (line  141)
+* fforward-propagate:                    Optimize Options.   (line  178)
+* ffp-contract:                          Optimize Options.   (line  187)
+* ffreestanding:                         Standards.          (line   92)
+* ffreestanding <1>:                     C Dialect Options.  (line  252)
+* ffreestanding <2>:                     Warning Options.    (line  252)
+* ffreestanding <3>:                     Function Attributes.
+                                                             (line  493)
+* ffriend-injection:                     C++ Dialect Options.
+                                                             (line   91)
+* ffunction-sections:                    Optimize Options.   (line 2224)
+* fgcse:                                 Optimize Options.   (line  437)
+* fgcse-after-reload:                    Optimize Options.   (line  473)
+* fgcse-las:                             Optimize Options.   (line  466)
+* fgcse-lm:                              Optimize Options.   (line  448)
+* fgcse-sm:                              Optimize Options.   (line  457)
+* fgnu-runtime:                          Objective-C and Objective-C++ Dialect Options.
+                                                             (line   39)
+* fgnu-tm:                               C Dialect Options.  (line  286)
+* fgnu89-inline:                         C Dialect Options.  (line  152)
+* fgraphite-identity:                    Optimize Options.   (line 1069)
+* fhosted:                               C Dialect Options.  (line  244)
+* fif-conversion:                        Optimize Options.   (line  516)
+* fif-conversion2:                       Optimize Options.   (line  525)
+* filelist:                              Darwin Options.     (line  196)
+* findirect-data:                        Darwin Options.     (line  104)
+* findirect-inlining:                    Optimize Options.   (line  241)
+* finhibit-size-directive:               Code Gen Options.   (line  250)
+* finline-functions:                     Optimize Options.   (line  249)
+* finline-functions-called-once:         Optimize Options.   (line  260)
+* finline-limit:                         Optimize Options.   (line  284)
+* finline-small-functions:               Optimize Options.   (line  232)
+* finput-charset:                        Preprocessor Options.
+                                                             (line  567)
+* finstrument-functions:                 Code Gen Options.   (line  385)
+* finstrument-functions <1>:             Function Attributes.
+                                                             (line 1085)
+* finstrument-functions-exclude-file-list: Code Gen Options. (line  420)
+* finstrument-functions-exclude-function-list: Code Gen Options.
+                                                             (line  441)
+* fipa-cp:                               Optimize Options.   (line  894)
+* fipa-cp-clone:                         Optimize Options.   (line  902)
+* fipa-profile:                          Optimize Options.   (line  886)
+* fipa-pta:                              Optimize Options.   (line  880)
+* fipa-pure-const:                       Optimize Options.   (line  872)
+* fipa-reference:                        Optimize Options.   (line  876)
+* fipa-sra:                              Optimize Options.   (line  277)
+* fira-hoist-pressure:                   Optimize Options.   (line  624)
+* fira-loop-pressure:                    Optimize Options.   (line  631)
+* fira-verbose:                          Optimize Options.   (line  651)
+* fivopts:                               Optimize Options.   (line 1165)
+* fkeep-inline-functions:                Optimize Options.   (line  315)
+* fkeep-inline-functions <1>:            Inline.             (line   51)
+* fkeep-static-consts:                   Optimize Options.   (line  322)
+* flat_namespace:                        Darwin Options.     (line  196)
+* flax-vector-conversions:               C Dialect Options.  (line  344)
+* fleading-underscore:                   Code Gen Options.   (line  523)
+* flive-range-shrinkage:                 Optimize Options.   (line  590)
+* floop-block:                           Optimize Options.   (line 1040)
+* floop-interchange:                     Optimize Options.   (line  995)
+* floop-nest-optimize:                   Optimize Options.   (line 1077)
+* floop-parallelize-all:                 Optimize Options.   (line 1083)
+* floop-strip-mine:                      Optimize Options.   (line 1019)
+* flto:                                  Optimize Options.   (line 1575)
+* flto-partition:                        Optimize Options.   (line 1769)
+* fmax-errors:                           Warning Options.    (line   18)
+* fmem-report:                           Debugging Options.  (line  430)
+* fmem-report-wpa:                       Debugging Options.  (line  434)
+* fmerge-all-constants:                  Optimize Options.   (line  341)
+* fmerge-constants:                      Optimize Options.   (line  331)
+* fmerge-debug-strings:                  Debugging Options.  (line  395)
+* fmessage-length:                       Language Independent Options.
+                                                             (line   14)
+* fmodulo-sched:                         Optimize Options.   (line  352)
+* fmodulo-sched-allow-regmoves:          Optimize Options.   (line  357)
+* fmove-loop-invariants:                 Optimize Options.   (line 2214)
+* fms-extensions:                        C Dialect Options.  (line  301)
+* fms-extensions <1>:                    C++ Dialect Options.
+                                                             (line  175)
+* fms-extensions <2>:                    Unnamed Fields.     (line   36)
+* fnext-runtime:                         Objective-C and Objective-C++ Dialect Options.
+                                                             (line   43)
+* fno-access-control:                    C++ Dialect Options.
+                                                             (line   50)
+* fno-asm:                               C Dialect Options.  (line  196)
+* fno-branch-count-reg:                  Optimize Options.   (line  364)
+* fno-builtin:                           C Dialect Options.  (line  210)
+* fno-builtin <1>:                       Warning Options.    (line  252)
+* fno-builtin <2>:                       Function Attributes.
+                                                             (line  493)
+* fno-builtin <3>:                       Other Builtins.     (line   14)
+* fno-canonical-system-headers:          Preprocessor Options.
+                                                             (line  504)
+* fno-common:                            Code Gen Options.   (line  228)
+* fno-common <1>:                        Variable Attributes.
+                                                             (line  104)
+* fno-compare-debug:                     Debugging Options.  (line  282)
+* fno-debug-types-section:               Debugging Options.  (line   79)
+* fno-default-inline:                    Inline.             (line   71)
+* fno-defer-pop:                         Optimize Options.   (line  170)
+* fno-diagnostics-show-caret:            Language Independent Options.
+                                                             (line   92)
+* fno-diagnostics-show-option:           Language Independent Options.
+                                                             (line   86)
+* fno-dwarf2-cfi-asm:                    Debugging Options.  (line  406)
+* fno-elide-constructors:                C++ Dialect Options.
+                                                             (line  104)
+* fno-eliminate-unused-debug-types:      Debugging Options.  (line 1422)
+* fno-enforce-eh-specs:                  C++ Dialect Options.
+                                                             (line  110)
+* fno-ext-numeric-literals:              C++ Dialect Options.
+                                                             (line  587)
+* fno-extern-tls-init:                   C++ Dialect Options.
+                                                             (line  120)
+* fno-for-scope:                         C++ Dialect Options.
+                                                             (line  141)
+* fno-function-cse:                      Optimize Options.   (line  374)
+* fno-gnu-keywords:                      C++ Dialect Options.
+                                                             (line  153)
+* fno-gnu-unique:                        Code Gen Options.   (line  151)
+* fno-guess-branch-probability:          Optimize Options.   (line 1342)
+* fno-ident:                             Code Gen Options.   (line  247)
+* fno-implement-inlines:                 C++ Dialect Options.
+                                                             (line  170)
+* fno-implement-inlines <1>:             C++ Interface.      (line   75)
+* fno-implicit-inline-templates:         C++ Dialect Options.
+                                                             (line  164)
+* fno-implicit-templates:                C++ Dialect Options.
+                                                             (line  158)
+* fno-implicit-templates <1>:            Template Instantiation.
+                                                             (line   78)
+* fno-inline:                            Optimize Options.   (line  224)
+* fno-ira-share-save-slots:              Optimize Options.   (line  639)
+* fno-ira-share-spill-slots:             Optimize Options.   (line  645)
+* fno-jump-tables:                       Code Gen Options.   (line  321)
+* fno-math-errno:                        Optimize Options.   (line 1964)
+* fno-merge-debug-strings:               Debugging Options.  (line  395)
+* fno-nil-receivers:                     Objective-C and Objective-C++ Dialect Options.
+                                                             (line   49)
+* fno-nonansi-builtins:                  C++ Dialect Options.
+                                                             (line  180)
+* fno-operator-names:                    C++ Dialect Options.
+                                                             (line  196)
+* fno-optional-diags:                    C++ Dialect Options.
+                                                             (line  200)
+* fno-peephole:                          Optimize Options.   (line 1333)
+* fno-peephole2:                         Optimize Options.   (line 1333)
+* fno-pretty-templates:                  C++ Dialect Options.
+                                                             (line  210)
+* fno-rtti:                              C++ Dialect Options.
+                                                             (line  227)
+* fno-sched-interblock:                  Optimize Options.   (line  683)
+* fno-sched-spec:                        Optimize Options.   (line  688)
+* fno-set-stack-executable:              i386 and x86-64 Windows Options.
+                                                             (line   46)
+* fno-show-column:                       Preprocessor Options.
+                                                             (line  591)
+* fno-signed-bitfields:                  C Dialect Options.  (line  377)
+* fno-signed-zeros:                      Optimize Options.   (line 2039)
+* fno-stack-limit:                       Code Gen Options.   (line  491)
+* fno-threadsafe-statics:                C++ Dialect Options.
+                                                             (line  264)
+* fno-toplevel-reorder:                  Optimize Options.   (line 1541)
+* fno-trapping-math:                     Optimize Options.   (line 2049)
+* fno-unsigned-bitfields:                C Dialect Options.  (line  377)
+* fno-use-cxa-get-exception-ptr:         C++ Dialect Options.
+                                                             (line  277)
+* fno-var-tracking-assignments:          Debugging Options.  (line 1330)
+* fno-var-tracking-assignments-toggle:   Debugging Options.  (line 1339)
+* fno-weak:                              C++ Dialect Options.
+                                                             (line  389)
+* fno-working-directory:                 Preprocessor Options.
+                                                             (line  577)
+* fno-writable-relocated-rdata:          i386 and x86-64 Windows Options.
+                                                             (line   53)
+* fno-zero-initialized-in-bss:           Optimize Options.   (line  385)
+* fnon-call-exceptions:                  Code Gen Options.   (line  122)
+* fnothrow-opt:                          C++ Dialect Options.
+                                                             (line  185)
+* fobjc-abi-version:                     Objective-C and Objective-C++ Dialect Options.
+                                                             (line   56)
+* fobjc-call-cxx-cdtors:                 Objective-C and Objective-C++ Dialect Options.
+                                                             (line   67)
+* fobjc-direct-dispatch:                 Objective-C and Objective-C++ Dialect Options.
+                                                             (line   92)
+* fobjc-exceptions:                      Objective-C and Objective-C++ Dialect Options.
+                                                             (line   96)
+* fobjc-gc:                              Objective-C and Objective-C++ Dialect Options.
+                                                             (line  105)
+* fobjc-nilcheck:                        Objective-C and Objective-C++ Dialect Options.
+                                                             (line  111)
+* fobjc-std:                             Objective-C and Objective-C++ Dialect Options.
+                                                             (line  120)
+* fomit-frame-pointer:                   Optimize Options.   (line  198)
+* fopenmp:                               C Dialect Options.  (line  263)
+* fopenmp-simd:                          C Dialect Options.  (line  272)
+* fopt-info:                             Debugging Options.  (line 1132)
+* foptimize-sibling-calls:               Optimize Options.   (line  219)
+* force_cpusubtype_ALL:                  Darwin Options.     (line  135)
+* force_flat_namespace:                  Darwin Options.     (line  196)
+* fpack-struct:                          Code Gen Options.   (line  372)
+* fpartial-inlining:                     Optimize Options.   (line 1308)
+* fpcc-struct-return:                    Code Gen Options.   (line  164)
+* fpcc-struct-return <1>:                Incompatibilities.  (line  170)
+* fpch-deps:                             Preprocessor Options.
+                                                             (line  296)
+* fpch-preprocess:                       Preprocessor Options.
+                                                             (line  304)
+* fpeel-loops:                           Optimize Options.   (line 2206)
+* fpermissive:                           C++ Dialect Options.
+                                                             (line  205)
+* fpic:                                  Code Gen Options.   (line  278)
+* fPIC:                                  Code Gen Options.   (line  299)
+* fpie:                                  Code Gen Options.   (line  312)
+* fPIE:                                  Code Gen Options.   (line  312)
+* fplan9-extensions:                     Unnamed Fields.     (line   43)
+* fplugin:                               Overall Options.    (line  351)
+* fplugin-arg:                           Overall Options.    (line  358)
+* fpost-ipa-mem-report:                  Debugging Options.  (line  439)
+* fpre-ipa-mem-report:                   Debugging Options.  (line  438)
+* fpredictive-commoning:                 Optimize Options.   (line 1315)
+* fprefetch-loop-arrays:                 Optimize Options.   (line 1322)
+* fpreprocessed:                         Preprocessor Options.
+                                                             (line  508)
+* fprofile-arcs:                         Debugging Options.  (line  476)
+* fprofile-arcs <1>:                     Other Builtins.     (line  253)
+* fprofile-correction:                   Optimize Options.   (line 1861)
+* fprofile-dir:                          Optimize Options.   (line 1868)
+* fprofile-generate:                     Optimize Options.   (line 1879)
+* fprofile-reorder-functions:            Optimize Options.   (line 2156)
+* fprofile-report:                       Debugging Options.  (line  443)
+* fprofile-use:                          Optimize Options.   (line 1893)
+* fprofile-values:                       Optimize Options.   (line 2147)
+* fpu:                                   RX Options.         (line   17)
+* frandom-seed:                          Debugging Options.  (line 1224)
+* freciprocal-math:                      Optimize Options.   (line 2017)
+* frecord-gcc-switches:                  Code Gen Options.   (line  266)
+* free:                                  Optimize Options.   (line  582)
+* freg-struct-return:                    Code Gen Options.   (line  182)
+* frename-registers:                     Optimize Options.   (line 2173)
+* freorder-blocks:                       Optimize Options.   (line 1359)
+* freorder-blocks-and-partition:         Optimize Options.   (line 1365)
+* freorder-functions:                    Optimize Options.   (line 1378)
+* freplace-objc-classes:                 Objective-C and Objective-C++ Dialect Options.
+                                                             (line  131)
+* frepo:                                 C++ Dialect Options.
+                                                             (line  222)
+* frepo <1>:                             Template Instantiation.
+                                                             (line   54)
+* frerun-cse-after-loop:                 Optimize Options.   (line  431)
+* freschedule-modulo-scheduled-loops:    Optimize Options.   (line  782)
+* frounding-math:                        Optimize Options.   (line 2064)
+* fsanitize=address:                     Debugging Options.  (line  187)
+* fsanitize=integer-divide-by-zero:      Debugging Options.  (line  228)
+* fsanitize=leak:                        Debugging Options.  (line  206)
+* fsanitize=null:                        Debugging Options.  (line  247)
+* fsanitize=return:                      Debugging Options.  (line  255)
+* fsanitize=shift:                       Debugging Options.  (line  221)
+* fsanitize=signed-integer-overflow:     Debugging Options.  (line  262)
+* fsanitize=thread:                      Debugging Options.  (line  197)
+* fsanitize=undefined:                   Debugging Options.  (line  216)
+* fsanitize=unreachable:                 Debugging Options.  (line  233)
+* fsanitize=vla-bound:                   Debugging Options.  (line  240)
+* fsched-critical-path-heuristic:        Optimize Options.   (line  748)
+* fsched-dep-count-heuristic:            Optimize Options.   (line  775)
+* fsched-group-heuristic:                Optimize Options.   (line  742)
+* fsched-last-insn-heuristic:            Optimize Options.   (line  768)
+* fsched-pressure:                       Optimize Options.   (line  693)
+* fsched-rank-heuristic:                 Optimize Options.   (line  761)
+* fsched-spec-insn-heuristic:            Optimize Options.   (line  754)
+* fsched-spec-load:                      Optimize Options.   (line  702)
+* fsched-spec-load-dangerous:            Optimize Options.   (line  707)
+* fsched-stalled-insns:                  Optimize Options.   (line  713)
+* fsched-stalled-insns-dep:              Optimize Options.   (line  723)
+* fsched-verbose:                        Debugging Options.  (line 1234)
+* fsched2-use-superblocks:               Optimize Options.   (line  732)
+* fschedule-insns:                       Optimize Options.   (line  664)
+* fschedule-insns2:                      Optimize Options.   (line  674)
+* fsection-anchors:                      Optimize Options.   (line 2274)
+* fsel-sched-pipelining:                 Optimize Options.   (line  795)
+* fsel-sched-pipelining-outer-loops:     Optimize Options.   (line  800)
+* fselective-scheduling:                 Optimize Options.   (line  787)
+* fselective-scheduling2:                Optimize Options.   (line  791)
+* fshort-double:                         Code Gen Options.   (line  210)
+* fshort-enums:                          Code Gen Options.   (line  200)
+* fshort-enums <1>:                      Structures unions enumerations and bit-fields implementation.
+                                                             (line   48)
+* fshort-enums <2>:                      Type Attributes.    (line  113)
+* fshort-enums <3>:                      Non-bugs.           (line   42)
+* fshort-wchar:                          Code Gen Options.   (line  218)
+* fshrink-wrap:                          Optimize Options.   (line  805)
+* fsignaling-nans:                       Optimize Options.   (line 2084)
+* fsigned-bitfields:                     C Dialect Options.  (line  377)
+* fsigned-bitfields <1>:                 Non-bugs.           (line   57)
+* fsigned-char:                          C Dialect Options.  (line  367)
+* fsigned-char <1>:                      Characters implementation.
+                                                             (line   31)
+* fsimd-cost-model:                      Optimize Options.   (line 1256)
+* fsingle-precision-constant:            Optimize Options.   (line 2099)
+* fsplit-ivs-in-unroller:                Optimize Options.   (line 1289)
+* fsplit-stack:                          Code Gen Options.   (line  505)
+* fsplit-stack <1>:                      Function Attributes.
+                                                             (line 1090)
+* fsplit-wide-types:                     Optimize Options.   (line  406)
+* fstack-check:                          Code Gen Options.   (line  453)
+* fstack-limit-register:                 Code Gen Options.   (line  491)
+* fstack-limit-symbol:                   Code Gen Options.   (line  491)
+* fstack-protector:                      Optimize Options.   (line 2257)
+* fstack-protector-all:                  Optimize Options.   (line 2266)
+* fstack-protector-strong:               Optimize Options.   (line 2269)
+* fstack-usage:                          Debugging Options.  (line  447)
+* fstack_reuse:                          Code Gen Options.   (line   21)
+* fstats:                                C++ Dialect Options.
+                                                             (line  237)
+* fstrict-aliasing:                      Optimize Options.   (line 1391)
+* fstrict-enums:                         C++ Dialect Options.
+                                                             (line  242)
+* fstrict-overflow:                      Optimize Options.   (line 1437)
+* fstrict-volatile-bitfields:            Code Gen Options.   (line  611)
+* fsync-libcalls:                        Code Gen Options.   (line  643)
+* fsyntax-only:                          Warning Options.    (line   14)
+* ftabstop:                              Preprocessor Options.
+                                                             (line  521)
+* ftemplate-backtrace-limit:             C++ Dialect Options.
+                                                             (line  251)
+* ftemplate-depth:                       C++ Dialect Options.
+                                                             (line  255)
+* ftest-coverage:                        Debugging Options.  (line  531)
+* fthread-jumps:                         Optimize Options.   (line  397)
+* ftime-report:                          Debugging Options.  (line  426)
+* ftls-model:                            Code Gen Options.   (line  534)
+* ftracer:                               Optimize Options.   (line 1272)
+* ftracer <1>:                           Optimize Options.   (line 2183)
+* ftrack-macro-expansion:                Preprocessor Options.
+                                                             (line  536)
+* ftrapv:                                Code Gen Options.   (line   96)
+* ftree-bit-ccp:                         Optimize Options.   (line  930)
+* ftree-builtin-call-dce:                Optimize Options.   (line  958)
+* ftree-ccp:                             Optimize Options.   (line  936)
+* ftree-ch:                              Optimize Options.   (line  978)
+* ftree-coalesce-inlined-vars:           Optimize Options.   (line 1196)
+* ftree-coalesce-vars:                   Optimize Options.   (line 1206)
+* ftree-copy-prop:                       Optimize Options.   (line  867)
+* ftree-copyrename:                      Optimize Options.   (line 1189)
+* ftree-dce:                             Optimize Options.   (line  954)
+* ftree-dominator-opts:                  Optimize Options.   (line  964)
+* ftree-dse:                             Optimize Options.   (line  971)
+* ftree-forwprop:                        Optimize Options.   (line  846)
+* ftree-fre:                             Optimize Options.   (line  850)
+* ftree-loop-im:                         Optimize Options.   (line 1150)
+* ftree-loop-ivcanon:                    Optimize Options.   (line 1159)
+* ftree-loop-linear:                     Optimize Options.   (line  989)
+* ftree-loop-optimize:                   Optimize Options.   (line  985)
+* ftree-loop-vectorize:                  Optimize Options.   (line 1234)
+* ftree-parallelize-loops:               Optimize Options.   (line 1170)
+* ftree-partial-pre:                     Optimize Options.   (line  842)
+* ftree-phiprop:                         Optimize Options.   (line  857)
+* ftree-pre:                             Optimize Options.   (line  838)
+* ftree-pta:                             Optimize Options.   (line 1179)
+* ftree-reassoc:                         Optimize Options.   (line  834)
+* ftree-sink:                            Optimize Options.   (line  926)
+* ftree-slp-vectorize:                   Optimize Options.   (line 1238)
+* ftree-slsr:                            Optimize Options.   (line 1223)
+* ftree-sra:                             Optimize Options.   (line 1183)
+* ftree-ter:                             Optimize Options.   (line 1215)
+* ftree-vectorize:                       Optimize Options.   (line 1229)
+* ftree-vrp:                             Optimize Options.   (line 1263)
+* funit-at-a-time:                       Optimize Options.   (line 1534)
+* funroll-all-loops:                     Optimize Options.   (line 1283)
+* funroll-all-loops <1>:                 Optimize Options.   (line 2200)
+* funroll-loops:                         Optimize Options.   (line 1277)
+* funroll-loops <1>:                     Optimize Options.   (line 2190)
+* funsafe-loop-optimizations:            Optimize Options.   (line  487)
+* funsafe-math-optimizations:            Optimize Options.   (line 1982)
+* funsigned-bitfields:                   C Dialect Options.  (line  377)
+* funsigned-bitfields <1>:               Structures unions enumerations and bit-fields implementation.
+                                                             (line   17)
+* funsigned-bitfields <2>:               Non-bugs.           (line   57)
+* funsigned-char:                        C Dialect Options.  (line  349)
+* funsigned-char <1>:                    Characters implementation.
+                                                             (line   31)
+* funswitch-loops:                       Optimize Options.   (line 2218)
+* funwind-tables:                        Code Gen Options.   (line  138)
+* fuse-cxa-atexit:                       C++ Dialect Options.
+                                                             (line  270)
+* fuse-ld=bfd:                           Optimize Options.   (line 1848)
+* fuse-ld=gold:                          Optimize Options.   (line 1851)
+* fvar-tracking:                         Debugging Options.  (line 1320)
+* fvar-tracking-assignments:             Debugging Options.  (line 1330)
+* fvar-tracking-assignments-toggle:      Debugging Options.  (line 1339)
+* fvariable-expansion-in-unroller:       Optimize Options.   (line 1303)
+* fvect-cost-model:                      Optimize Options.   (line 1242)
+* fverbose-asm:                          Code Gen Options.   (line  257)
+* fvisibility:                           Code Gen Options.   (line  545)
+* fvisibility-inlines-hidden:            C++ Dialect Options.
+                                                             (line  282)
+* fvisibility-ms-compat:                 C++ Dialect Options.
+                                                             (line  310)
+* fvpt:                                  Optimize Options.   (line 2163)
+* fvtable-verify:                        C++ Dialect Options.
+                                                             (line  339)
+* fvtv-counts:                           C++ Dialect Options.
+                                                             (line  374)
+* fweb:                                  Optimize Options.   (line 1553)
+* fwhole-program:                        Optimize Options.   (line 1564)
+* fwide-exec-charset:                    Preprocessor Options.
+                                                             (line  559)
+* fworking-directory:                    Preprocessor Options.
+                                                             (line  577)
+* fwrapv:                                Code Gen Options.   (line  100)
+* fzero-link:                            Objective-C and Objective-C++ Dialect Options.
+                                                             (line  141)
+* g:                                     Debugging Options.  (line   10)
+* G:                                     M32R/D Options.     (line   57)
+* G <1>:                                 MIPS Options.       (line  393)
+* G <2>:                                 Nios II Options.    (line    9)
+* G <3>:                                 RS/6000 and PowerPC Options.
+                                                             (line  739)
+* G <4>:                                 System V Options.   (line   10)
+* gcoff:                                 Debugging Options.  (line   94)
+* gdwarf-VERSION:                        Debugging Options.  (line  112)
+* gen-decls:                             Objective-C and Objective-C++ Dialect Options.
+                                                             (line  153)
+* gfull:                                 Darwin Options.     (line   69)
+* ggdb:                                  Debugging Options.  (line   45)
+* ggnu-pubnames:                         Debugging Options.  (line   54)
+* gno-record-gcc-switches:               Debugging Options.  (line  132)
+* gno-strict-dwarf:                      Debugging Options.  (line  142)
+* gpubnames:                             Debugging Options.  (line   51)
+* grecord-gcc-switches:                  Debugging Options.  (line  123)
+* gsplit-dwarf:                          Debugging Options.  (line   38)
+* gstabs:                                Debugging Options.  (line   59)
+* gstabs+:                               Debugging Options.  (line   88)
+* gstrict-dwarf:                         Debugging Options.  (line  136)
+* gtoggle:                               Debugging Options.  (line  179)
+* gused:                                 Darwin Options.     (line   64)
+* gvms:                                  Debugging Options.  (line  146)
+* gxcoff:                                Debugging Options.  (line   99)
+* gxcoff+:                               Debugging Options.  (line  104)
+* H:                                     Preprocessor Options.
+                                                             (line  707)
+* headerpad_max_install_names:           Darwin Options.     (line  196)
+* help:                                  Overall Options.    (line  221)
+* help <1>:                              Preprocessor Options.
+                                                             (line  699)
+* hoist-adjacent-loads:                  Optimize Options.   (line  861)
+* I:                                     Preprocessor Options.
+                                                             (line   77)
+* I <1>:                                 Directory Options.  (line   10)
+* I-:                                    Preprocessor Options.
+                                                             (line  389)
+* I- <1>:                                Directory Options.  (line  116)
+* idirafter:                             Preprocessor Options.
+                                                             (line  431)
+* iframework:                            Darwin Options.     (line   57)
+* imacros:                               Preprocessor Options.
+                                                             (line  422)
+* image_base:                            Darwin Options.     (line  196)
+* imultilib:                             Preprocessor Options.
+                                                             (line  456)
+* include:                               Preprocessor Options.
+                                                             (line  411)
+* init:                                  Darwin Options.     (line  196)
+* install_name:                          Darwin Options.     (line  196)
+* iplugindir=:                           Directory Options.  (line   29)
+* iprefix:                               Preprocessor Options.
+                                                             (line  438)
+* iquote:                                Preprocessor Options.
+                                                             (line  468)
+* iquote <1>:                            Directory Options.  (line   34)
+* isysroot:                              Preprocessor Options.
+                                                             (line  450)
+* isystem:                               Preprocessor Options.
+                                                             (line  460)
+* iwithprefix:                           Preprocessor Options.
+                                                             (line  444)
+* iwithprefixbefore:                     Preprocessor Options.
+                                                             (line  444)
+* keep_private_externs:                  Darwin Options.     (line  196)
+* l:                                     Link Options.       (line   26)
+* L:                                     Directory Options.  (line   40)
+* lobjc:                                 Link Options.       (line   53)
+* M:                                     Preprocessor Options.
+                                                             (line  185)
+* m:                                     RS/6000 and PowerPC Options.
+                                                             (line  581)
+* m1:                                    SH Options.         (line    9)
+* m10:                                   PDP-11 Options.     (line   29)
+* m128bit-long-double:                   i386 and x86-64 Options.
+                                                             (line  381)
+* m16:                                   i386 and x86-64 Options.
+                                                             (line  940)
+* m16-bit:                               CRIS Options.       (line   64)
+* m16-bit <1>:                           NDS32 Options.      (line   39)
+* m1reg-:                                Adapteva Epiphany Options.
+                                                             (line  131)
+* m2:                                    SH Options.         (line   12)
+* m210:                                  MCore Options.      (line   43)
+* m2a:                                   SH Options.         (line   30)
+* m2a-nofpu:                             SH Options.         (line   18)
+* m2a-single:                            SH Options.         (line   26)
+* m2a-single-only:                       SH Options.         (line   22)
+* m3:                                    SH Options.         (line   34)
+* m31:                                   S/390 and zSeries Options.
+                                                             (line   86)
+* m32:                                   i386 and x86-64 Options.
+                                                             (line  940)
+* m32 <1>:                               RS/6000 and PowerPC Options.
+                                                             (line  274)
+* m32 <2>:                               SPARC Options.      (line  250)
+* m32 <3>:                               TILE-Gx Options.    (line   23)
+* m32 <4>:                               TILEPro Options.    (line   13)
+* m32-bit:                               CRIS Options.       (line   64)
+* m32bit-doubles:                        RX Options.         (line   10)
+* m32r:                                  M32R/D Options.     (line   15)
+* m32r2:                                 M32R/D Options.     (line    9)
+* m32rx:                                 M32R/D Options.     (line   12)
+* m340:                                  MCore Options.      (line   43)
+* m3dnow:                                i386 and x86-64 Options.
+                                                             (line  629)
+* m3e:                                   SH Options.         (line   37)
+* m4:                                    SH Options.         (line   51)
+* m4-nofpu:                              SH Options.         (line   40)
+* m4-single:                             SH Options.         (line   47)
+* m4-single-only:                        SH Options.         (line   43)
+* m40:                                   PDP-11 Options.     (line   23)
+* m45:                                   PDP-11 Options.     (line   26)
+* m4a:                                   SH Options.         (line   66)
+* m4a-nofpu:                             SH Options.         (line   54)
+* m4a-single:                            SH Options.         (line   62)
+* m4a-single-only:                       SH Options.         (line   58)
+* m4al:                                  SH Options.         (line   69)
+* m4byte-functions:                      MCore Options.      (line   27)
+* m5200:                                 M680x0 Options.     (line  144)
+* m5206e:                                M680x0 Options.     (line  153)
+* m528x:                                 M680x0 Options.     (line  157)
+* m5307:                                 M680x0 Options.     (line  161)
+* m5407:                                 M680x0 Options.     (line  165)
+* m64:                                   i386 and x86-64 Options.
+                                                             (line  940)
+* m64 <1>:                               RS/6000 and PowerPC Options.
+                                                             (line  274)
+* m64 <2>:                               S/390 and zSeries Options.
+                                                             (line   86)
+* m64 <3>:                               SPARC Options.      (line  250)
+* m64 <4>:                               TILE-Gx Options.    (line   23)
+* m64bit-doubles:                        RX Options.         (line   10)
+* m68000:                                M680x0 Options.     (line   93)
+* m68010:                                M680x0 Options.     (line  101)
+* m68020:                                M680x0 Options.     (line  107)
+* m68020-40:                             M680x0 Options.     (line  175)
+* m68020-60:                             M680x0 Options.     (line  184)
+* m68030:                                M680x0 Options.     (line  112)
+* m68040:                                M680x0 Options.     (line  117)
+* m68060:                                M680x0 Options.     (line  126)
+* m68881:                                M680x0 Options.     (line  194)
+* m8-bit:                                CRIS Options.       (line   64)
+* m8byte-align:                          V850 Options.       (line  170)
+* m96bit-long-double:                    i386 and x86-64 Options.
+                                                             (line  381)
+* mA6:                                   ARC Options.        (line   19)
+* mA7:                                   ARC Options.        (line   26)
+* mabi:                                  AArch64 Options.    (line    9)
+* mabi <1>:                              ARM Options.        (line   10)
+* mabi <2>:                              i386 and x86-64 Options.
+                                                             (line  799)
+* mabi <3>:                              RS/6000 and PowerPC Options.
+                                                             (line  608)
+* mabi=32:                               MIPS Options.       (line  138)
+* mabi=64:                               MIPS Options.       (line  138)
+* mabi=eabi:                             MIPS Options.       (line  138)
+* mabi=elfv1:                            RS/6000 and PowerPC Options.
+                                                             (line  629)
+* mabi=elfv2:                            RS/6000 and PowerPC Options.
+                                                             (line  635)
+* mabi=gnu:                              MMIX Options.       (line   20)
+* mabi=ibmlongdouble:                    RS/6000 and PowerPC Options.
+                                                             (line  621)
+* mabi=ieeelongdouble:                   RS/6000 and PowerPC Options.
+                                                             (line  625)
+* mabi=mmixware:                         MMIX Options.       (line   20)
+* mabi=n32:                              MIPS Options.       (line  138)
+* mabi=no-spe:                           RS/6000 and PowerPC Options.
+                                                             (line  618)
+* mabi=o64:                              MIPS Options.       (line  138)
+* mabi=spe:                              RS/6000 and PowerPC Options.
+                                                             (line  613)
+* mabicalls:                             MIPS Options.       (line  162)
+* mabort-on-noreturn:                    ARM Options.        (line  196)
+* mabs=2008:                             MIPS Options.       (line  260)
+* mabs=legacy:                           MIPS Options.       (line  260)
+* mabsdiff:                              MeP Options.        (line    7)
+* mabshi:                                PDP-11 Options.     (line   55)
+* mac0:                                  PDP-11 Options.     (line   16)
+* macc-4:                                FRV Options.        (line  139)
+* macc-8:                                FRV Options.        (line  143)
+* maccumulate-args:                      AVR Options.        (line  137)
+* maccumulate-outgoing-args:             i386 and x86-64 Options.
+                                                             (line  822)
+* maccumulate-outgoing-args <1>:         SH Options.         (line  325)
+* maddress-mode=long:                    i386 and x86-64 Options.
+                                                             (line  987)
+* maddress-mode=short:                   i386 and x86-64 Options.
+                                                             (line  992)
+* maddress-space-conversion:             SPU Options.        (line   68)
+* mads:                                  RS/6000 and PowerPC Options.
+                                                             (line  663)
+* maix-struct-return:                    RS/6000 and PowerPC Options.
+                                                             (line  601)
+* maix32:                                RS/6000 and PowerPC Options.
+                                                             (line  312)
+* maix64:                                RS/6000 and PowerPC Options.
+                                                             (line  312)
+* malign-300:                            H8/300 Options.     (line   41)
+* malign-call:                           ARC Options.        (line  192)
+* malign-double:                         i386 and x86-64 Options.
+                                                             (line  366)
+* malign-int:                            M680x0 Options.     (line  263)
+* malign-labels:                         FRV Options.        (line  128)
+* malign-loops:                          M32R/D Options.     (line   73)
+* malign-natural:                        RS/6000 and PowerPC Options.
+                                                             (line  350)
+* malign-power:                          RS/6000 and PowerPC Options.
+                                                             (line  350)
+* mall-opts:                             MeP Options.        (line   11)
+* malloc-cc:                             FRV Options.        (line   31)
+* maltivec:                              RS/6000 and PowerPC Options.
+                                                             (line  132)
+* maltivec=be:                           RS/6000 and PowerPC Options.
+                                                             (line  148)
+* maltivec=le:                           RS/6000 and PowerPC Options.
+                                                             (line  158)
+* mam33:                                 MN10300 Options.    (line   17)
+* mam33-2:                               MN10300 Options.    (line   24)
+* mam34:                                 MN10300 Options.    (line   27)
+* mandroid:                              GNU/Linux Options.  (line   21)
+* mannotate-align:                       ARC Options.        (line  133)
+* mapcs:                                 ARM Options.        (line   22)
+* mapcs-frame:                           ARM Options.        (line   14)
+* mapp-regs:                             SPARC Options.      (line   10)
+* mapp-regs <1>:                         V850 Options.       (line  181)
+* mARC600:                               ARC Options.        (line   19)
+* mARC601:                               ARC Options.        (line   23)
+* mARC700:                               ARC Options.        (line   26)
+* march:                                 AArch64 Options.    (line   66)
+* march <1>:                             ARM Options.        (line   75)
+* march <2>:                             C6X Options.        (line    7)
+* march <3>:                             CRIS Options.       (line   10)
+* march <4>:                             HPPA Options.       (line    9)
+* march <5>:                             HPPA Options.       (line  156)
+* march <6>:                             i386 and x86-64 Options.
+                                                             (line   10)
+* march <7>:                             M680x0 Options.     (line   12)
+* march <8>:                             MIPS Options.       (line   14)
+* march <9>:                             NDS32 Options.      (line   58)
+* march <10>:                            S/390 and zSeries Options.
+                                                             (line  114)
+* marclinux:                             ARC Options.        (line  139)
+* marclinux_prof:                        ARC Options.        (line  146)
+* margonaut:                             ARC Options.        (line  341)
+* marm:                                  ARM Options.        (line  266)
+* mas100-syntax:                         RX Options.         (line   76)
+* masm-hex:                              MSP430 Options.     (line    9)
+* masm=DIALECT:                          i386 and x86-64 Options.
+                                                             (line  322)
+* matomic-model=MODEL:                   SH Options.         (line  144)
+* matomic-updates:                       SPU Options.        (line   83)
+* mauto-modify-reg:                      ARC Options.        (line  195)
+* mauto-pic:                             IA-64 Options.      (line   50)
+* maverage:                              MeP Options.        (line   16)
+* mavoid-indexed-addresses:              RS/6000 and PowerPC Options.
+                                                             (line  420)
+* max-vect-align:                        Adapteva Epiphany Options.
+                                                             (line  119)
+* mb:                                    SH Options.         (line   74)
+* mbackchain:                            S/390 and zSeries Options.
+                                                             (line   35)
+* mbarrel-shift-enabled:                 LM32 Options.       (line    9)
+* mbarrel-shifter:                       ARC Options.        (line   10)
+* mbarrel_shifter:                       ARC Options.        (line  361)
+* mbase-addresses:                       MMIX Options.       (line   53)
+* mbased=:                               MeP Options.        (line   20)
+* mbbit-peephole:                        ARC Options.        (line  198)
+* mbcopy:                                PDP-11 Options.     (line   36)
+* mbcopy-builtin:                        PDP-11 Options.     (line   32)
+* mbig:                                  RS/6000 and PowerPC Options.
+                                                             (line  500)
+* mbig-endian:                           AArch64 Options.    (line   20)
+* mbig-endian <1>:                       ARC Options.        (line  344)
+* mbig-endian <2>:                       ARM Options.        (line   62)
+* mbig-endian <3>:                       C6X Options.        (line   13)
+* mbig-endian <4>:                       IA-64 Options.      (line    9)
+* mbig-endian <5>:                       MCore Options.      (line   39)
+* mbig-endian <6>:                       MicroBlaze Options. (line   57)
+* mbig-endian <7>:                       NDS32 Options.      (line    9)
+* mbig-endian <8>:                       RS/6000 and PowerPC Options.
+                                                             (line  500)
+* mbig-endian <9>:                       TILE-Gx Options.    (line   29)
+* mbig-endian-data:                      RX Options.         (line   42)
+* mbig-switch:                           V850 Options.       (line  176)
+* mbigtable:                             SH Options.         (line   89)
+* mbionic:                               GNU/Linux Options.  (line   17)
+* mbit-align:                            RS/6000 and PowerPC Options.
+                                                             (line  452)
+* mbit-ops:                              CR16 Options.       (line   25)
+* mbitfield:                             M680x0 Options.     (line  231)
+* mbitops:                               MeP Options.        (line   26)
+* mbitops <1>:                           SH Options.         (line   93)
+* mblock-move-inline-limit:              RS/6000 and PowerPC Options.
+                                                             (line  733)
+* mbranch-cheap:                         PDP-11 Options.     (line   65)
+* mbranch-cost:                          Adapteva Epiphany Options.
+                                                             (line   18)
+* mbranch-cost <1>:                      AVR Options.        (line  152)
+* mbranch-cost <2>:                      MIPS Options.       (line  701)
+* mbranch-cost=NUM:                      SH Options.         (line  389)
+* mbranch-cost=NUMBER:                   M32R/D Options.     (line   82)
+* mbranch-expensive:                     PDP-11 Options.     (line   61)
+* mbranch-hints:                         SPU Options.        (line   29)
+* mbranch-likely:                        MIPS Options.       (line  708)
+* mbranch-predict:                       MMIX Options.       (line   48)
+* mbss-plt:                              RS/6000 and PowerPC Options.
+                                                             (line  185)
+* mbuild-constants:                      DEC Alpha Options.  (line  141)
+* mbwx:                                  DEC Alpha Options.  (line  163)
+* mbypass-cache:                         Nios II Options.    (line   34)
+* mc68000:                               M680x0 Options.     (line   93)
+* mc68020:                               M680x0 Options.     (line  107)
+* mc=:                                   MeP Options.        (line   31)
+* mcache-block-size:                     NDS32 Options.      (line   54)
+* mcache-size:                           SPU Options.        (line   75)
+* mcache-volatile:                       Nios II Options.    (line   40)
+* mcall-eabi:                            RS/6000 and PowerPC Options.
+                                                             (line  575)
+* mcall-freebsd:                         RS/6000 and PowerPC Options.
+                                                             (line  589)
+* mcall-linux:                           RS/6000 and PowerPC Options.
+                                                             (line  585)
+* mcall-netbsd:                          RS/6000 and PowerPC Options.
+                                                             (line  593)
+* mcall-netbsd <1>:                      RS/6000 and PowerPC Options.
+                                                             (line  597)
+* mcall-prologues:                       AVR Options.        (line  157)
+* mcall-sysv:                            RS/6000 and PowerPC Options.
+                                                             (line  567)
+* mcall-sysv-eabi:                       RS/6000 and PowerPC Options.
+                                                             (line  575)
+* mcall-sysv-noeabi:                     RS/6000 and PowerPC Options.
+                                                             (line  578)
+* mcallee-super-interworking:            ARM Options.        (line  285)
+* mcaller-super-interworking:            ARM Options.        (line  292)
+* mcallgraph-data:                       MCore Options.      (line   31)
+* mcase-vector-pcrel:                    ARC Options.        (line  206)
+* mcbcond:                               SPARC Options.      (line  217)
+* mcc-init:                              CRIS Options.       (line   42)
+* mcfv4e:                                M680x0 Options.     (line  169)
+* mcheck-zero-division:                  MIPS Options.       (line  503)
+* mcix:                                  DEC Alpha Options.  (line  163)
+* mcld:                                  i386 and x86-64 Options.
+                                                             (line  672)
+* mclip:                                 MeP Options.        (line   35)
+* mcmodel:                               SPARC Options.      (line  255)
+* mcmodel=kernel:                        i386 and x86-64 Options.
+                                                             (line  971)
+* mcmodel=large:                         AArch64 Options.    (line   44)
+* mcmodel=large <1>:                     i386 and x86-64 Options.
+                                                             (line  983)
+* mcmodel=large <2>:                     RS/6000 and PowerPC Options.
+                                                             (line  126)
+* mcmodel=large <3>:                     TILE-Gx Options.    (line   14)
+* mcmodel=medium:                        i386 and x86-64 Options.
+                                                             (line  976)
+* mcmodel=medium <1>:                    RS/6000 and PowerPC Options.
+                                                             (line  122)
+* mcmodel=small:                         AArch64 Options.    (line   38)
+* mcmodel=small <1>:                     i386 and x86-64 Options.
+                                                             (line  965)
+* mcmodel=small <2>:                     RS/6000 and PowerPC Options.
+                                                             (line  118)
+* mcmodel=small <3>:                     TILE-Gx Options.    (line    9)
+* mcmodel=tiny:                          AArch64 Options.    (line   31)
+* mcmov:                                 NDS32 Options.      (line   21)
+* mcmove:                                Adapteva Epiphany Options.
+                                                             (line   23)
+* mcmpb:                                 RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mcode-readable:                        MIPS Options.       (line  463)
+* mcompact-casesi:                       ARC Options.        (line  210)
+* mcompat-align-parm:                    RS/6000 and PowerPC Options.
+                                                             (line  889)
+* mcond-exec:                            FRV Options.        (line  187)
+* mcond-move:                            FRV Options.        (line  159)
+* mconfig=:                              MeP Options.        (line   39)
+* mconsole:                              i386 and x86-64 Windows Options.
+                                                             (line    9)
+* mconst-align:                          CRIS Options.       (line   55)
+* mconst16:                              Xtensa Options.     (line   10)
+* mconstant-gp:                          IA-64 Options.      (line   46)
+* mcop:                                  MeP Options.        (line   48)
+* mcop32:                                MeP Options.        (line   53)
+* mcop64:                                MeP Options.        (line   56)
+* mcorea:                                Blackfin Options.   (line  156)
+* mcoreb:                                Blackfin Options.   (line  163)
+* mcpu:                                  AArch64 Options.    (line   98)
+* mcpu <1>:                              ARC Options.        (line   14)
+* mcpu <2>:                              ARM Options.        (line  136)
+* mcpu <3>:                              CRIS Options.       (line   10)
+* mcpu <4>:                              DEC Alpha Options.  (line  215)
+* mcpu <5>:                              FRV Options.        (line  258)
+* mcpu <6>:                              i386 and x86-64 Options.
+                                                             (line  270)
+* mcpu <7>:                              M680x0 Options.     (line   28)
+* mcpu <8>:                              picoChip Options.   (line    9)
+* mcpu <9>:                              RS/6000 and PowerPC Options.
+                                                             (line   68)
+* mcpu <10>:                             SPARC Options.      (line   95)
+* mcpu <11>:                             TILE-Gx Options.    (line   18)
+* mcpu <12>:                             TILEPro Options.    (line    9)
+* mcpu32:                                M680x0 Options.     (line  135)
+* mcpu=:                                 Blackfin Options.   (line    7)
+* mcpu= <1>:                             M32C Options.       (line    7)
+* mcpu= <2>:                             MicroBlaze Options. (line   20)
+* mcr16c:                                CR16 Options.       (line   14)
+* mcr16cplus:                            CR16 Options.       (line   14)
+* mcrc32:                                i386 and x86-64 Options.
+                                                             (line  719)
+* mcrypto:                               RS/6000 and PowerPC Options.
+                                                             (line  220)
+* mcsync-anomaly:                        Blackfin Options.   (line   59)
+* mctor-dtor:                            NDS32 Options.      (line   73)
+* mcustom-fpu-cfg:                       Nios II Options.    (line  175)
+* mcustom-INSN:                          Nios II Options.    (line   61)
+* mcx16:                                 i386 and x86-64 Options.
+                                                             (line  696)
+* MD:                                    Preprocessor Options.
+                                                             (line  276)
+* mdalign:                               SH Options.         (line   80)
+* mdata-align:                           CRIS Options.       (line   55)
+* mdata-model:                           CR16 Options.       (line   28)
+* mdc:                                   MeP Options.        (line   62)
+* mdebug:                                M32R/D Options.     (line   69)
+* mdebug <1>:                            S/390 and zSeries Options.
+                                                             (line  110)
+* mdebug-main=PREFIX:                    VMS Options.        (line   13)
+* mdec-asm:                              PDP-11 Options.     (line   72)
+* mdirect-move:                          RS/6000 and PowerPC Options.
+                                                             (line  226)
+* mdisable-callt:                        V850 Options.       (line   92)
+* mdisable-fpregs:                       HPPA Options.       (line   28)
+* mdisable-indexing:                     HPPA Options.       (line   34)
+* mdiv:                                  M680x0 Options.     (line  206)
+* mdiv <1>:                              MCore Options.      (line   15)
+* mdiv <2>:                              MeP Options.        (line   65)
+* mdiv=STRATEGY:                         SH Options.         (line  236)
+* mdivide-breaks:                        MIPS Options.       (line  509)
+* mdivide-enabled:                       LM32 Options.       (line   12)
+* mdivide-traps:                         MIPS Options.       (line  509)
+* mdivsi3_libfunc=NAME:                  SH Options.         (line  331)
+* mdll:                                  i386 and x86-64 Windows Options.
+                                                             (line   16)
+* mdlmzb:                                RS/6000 and PowerPC Options.
+                                                             (line  445)
+* mdmx:                                  MIPS Options.       (line  336)
+* mdouble:                               FRV Options.        (line   48)
+* mdouble-float:                         MIPS Options.       (line  255)
+* mdouble-float <1>:                     RS/6000 and PowerPC Options.
+                                                             (line  368)
+* mdpfp:                                 ARC Options.        (line   30)
+* mdpfp-compact:                         ARC Options.        (line   31)
+* mdpfp-fast:                            ARC Options.        (line   35)
+* mdpfp_compact:                         ARC Options.        (line  364)
+* mdpfp_fast:                            ARC Options.        (line  367)
+* mdsp:                                  MIPS Options.       (line  313)
+* mdsp-packa:                            ARC Options.        (line   88)
+* mdspr2:                                MIPS Options.       (line  319)
+* mdsp_packa:                            ARC Options.        (line  370)
+* mdual-nops:                            SPU Options.        (line   95)
+* mdump-tune-features:                   i386 and x86-64 Options.
+                                                             (line  653)
+* mdvbf:                                 ARC Options.        (line   92)
+* mdwarf2-asm:                           IA-64 Options.      (line   94)
+* mdword:                                FRV Options.        (line   40)
+* mdynamic-no-pic:                       RS/6000 and PowerPC Options.
+                                                             (line  505)
+* mea:                                   ARC Options.        (line   43)
+* mEA:                                   ARC Options.        (line  373)
+* mea32:                                 SPU Options.        (line   60)
+* mea64:                                 SPU Options.        (line   60)
+* meabi:                                 RS/6000 and PowerPC Options.
+                                                             (line  682)
+* mearly-cbranchsi:                      ARC Options.        (line  229)
+* mearly-stop-bits:                      IA-64 Options.      (line  100)
+* meb:                                   MeP Options.        (line   68)
+* meb <1>:                               Moxie Options.      (line    7)
+* meb <2>:                               Nios II Options.    (line   29)
+* meb <3>:                               Score Options.      (line    9)
+* mel:                                   MeP Options.        (line   71)
+* mel <1>:                               Moxie Options.      (line   11)
+* mel <2>:                               Nios II Options.    (line   29)
+* mel <3>:                               Score Options.      (line   12)
+* melf:                                  CRIS Options.       (line   87)
+* melf <1>:                              MMIX Options.       (line   43)
+* memb:                                  RS/6000 and PowerPC Options.
+                                                             (line  677)
+* membedded-data:                        MIPS Options.       (line  450)
+* memregs=:                              M32C Options.       (line   21)
+* mep:                                   V850 Options.       (line   16)
+* mepilogue-cfi:                         ARC Options.        (line  155)
+* mepsilon:                              MMIX Options.       (line   15)
+* merror-reloc:                          SPU Options.        (line   10)
+* mesa:                                  S/390 and zSeries Options.
+                                                             (line   94)
+* metrax100:                             CRIS Options.       (line   27)
+* metrax4:                               CRIS Options.       (line   27)
+* meva:                                  MIPS Options.       (line  363)
+* mex9:                                  NDS32 Options.      (line   70)
+* mexpand-adddi:                         ARC Options.        (line  232)
+* mexplicit-relocs:                      DEC Alpha Options.  (line  176)
+* mexplicit-relocs <1>:                  MIPS Options.       (line  494)
+* mexr:                                  H8/300 Options.     (line   28)
+* mextern-sdata:                         MIPS Options.       (line  413)
+* MF:                                    Preprocessor Options.
+                                                             (line  220)
+* mfast-fp:                              Blackfin Options.   (line  132)
+* mfast-indirect-calls:                  HPPA Options.       (line   46)
+* mfast-sw-div:                          Nios II Options.    (line   46)
+* mfaster-structs:                       SPARC Options.      (line   85)
+* mfdpic:                                FRV Options.        (line   72)
+* mfentry:                               i386 and x86-64 Options.
+                                                             (line  910)
+* mfix:                                  DEC Alpha Options.  (line  163)
+* mfix-24k:                              MIPS Options.       (line  567)
+* mfix-and-continue:                     Darwin Options.     (line  104)
+* mfix-at697f:                           SPARC Options.      (line  237)
+* mfix-cortex-m3-ldrd:                   ARM Options.        (line  325)
+* mfix-r10000:                           MIPS Options.       (line  589)
+* mfix-r4000:                            MIPS Options.       (line  573)
+* mfix-r4400:                            MIPS Options.       (line  583)
+* mfix-rm7000:                           MIPS Options.       (line  600)
+* mfix-sb1:                              MIPS Options.       (line  625)
+* mfix-ut699:                            SPARC Options.      (line  242)
+* mfix-vr4120:                           MIPS Options.       (line  605)
+* mfix-vr4130:                           MIPS Options.       (line  618)
+* mfixed-cc:                             FRV Options.        (line   35)
+* mfixed-range:                          HPPA Options.       (line   53)
+* mfixed-range <1>:                      IA-64 Options.      (line  105)
+* mfixed-range <2>:                      SH Options.         (line  338)
+* mfixed-range <3>:                      SPU Options.        (line   52)
+* mflat:                                 SPARC Options.      (line   22)
+* mflip-mips16:                          MIPS Options.       (line  110)
+* mfloat-abi:                            ARM Options.        (line   42)
+* mfloat-gprs:                           RS/6000 and PowerPC Options.
+                                                             (line  257)
+* mfloat-ieee:                           DEC Alpha Options.  (line  171)
+* mfloat-vax:                            DEC Alpha Options.  (line  171)
+* mfloat32:                              PDP-11 Options.     (line   52)
+* mfloat64:                              PDP-11 Options.     (line   48)
+* mflush-func:                           MIPS Options.       (line  692)
+* mflush-func=NAME:                      M32R/D Options.     (line   93)
+* mflush-trap=NUMBER:                    M32R/D Options.     (line   86)
+* mfmaf:                                 SPARC Options.      (line  231)
+* mfmovd:                                SH Options.         (line   96)
+* mforbid-fp-as-gp:                      NDS32 Options.      (line   65)
+* mforce-fp-as-gp:                       NDS32 Options.      (line   61)
+* mforce-no-pic:                         Xtensa Options.     (line   41)
+* mfp-exceptions:                        MIPS Options.       (line  719)
+* mfp-mode:                              Adapteva Epiphany Options.
+                                                             (line   71)
+* mfp-reg:                               DEC Alpha Options.  (line   25)
+* mfp-rounding-mode:                     DEC Alpha Options.  (line   85)
+* mfp-trap-mode:                         DEC Alpha Options.  (line   63)
+* mfp16-format:                          ARM Options.        (line  176)
+* mfp32:                                 MIPS Options.       (line  228)
+* mfp64:                                 MIPS Options.       (line  231)
+* mfpmath:                               Optimize Options.   (line 1942)
+* mfpmath <1>:                           i386 and x86-64 Options.
+                                                             (line  273)
+* mfpr-32:                               FRV Options.        (line   15)
+* mfpr-64:                               FRV Options.        (line   19)
+* mfprnd:                                RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mfpu:                                  ARM Options.        (line  156)
+* mfpu <1>:                              PDP-11 Options.     (line    9)
+* mfpu <2>:                              RS/6000 and PowerPC Options.
+                                                             (line  376)
+* mfpu <3>:                              SPARC Options.      (line   34)
+* mfriz:                                 RS/6000 and PowerPC Options.
+                                                             (line  860)
+* mfsca:                                 SH Options.         (line  414)
+* mfsrra:                                SH Options.         (line  423)
+* mfull-regs:                            NDS32 Options.      (line   18)
+* mfull-toc:                             RS/6000 and PowerPC Options.
+                                                             (line  285)
+* mfused-madd:                           IA-64 Options.      (line   88)
+* mfused-madd <1>:                       MIPS Options.       (line  550)
+* mfused-madd <2>:                       RS/6000 and PowerPC Options.
+                                                             (line  429)
+* mfused-madd <3>:                       S/390 and zSeries Options.
+                                                             (line  135)
+* mfused-madd <4>:                       SH Options.         (line  405)
+* mfused-madd <5>:                       Xtensa Options.     (line   19)
+* MG:                                    Preprocessor Options.
+                                                             (line  229)
+* mg:                                    VAX Options.        (line   17)
+* mgas:                                  HPPA Options.       (line   69)
+* mgcc-abi:                              V850 Options.       (line  148)
+* mgen-cell-microcode:                   RS/6000 and PowerPC Options.
+                                                             (line  173)
+* mgeneral-regs-only:                    AArch64 Options.    (line   24)
+* mgettrcost=NUMBER:                     SH Options.         (line  355)
+* mghs:                                  V850 Options.       (line  127)
+* mglibc:                                GNU/Linux Options.  (line    9)
+* mgnu:                                  VAX Options.        (line   13)
+* mgnu-as:                               IA-64 Options.      (line   18)
+* mgnu-ld:                               HPPA Options.       (line  105)
+* mgnu-ld <1>:                           IA-64 Options.      (line   23)
+* mgotplt:                               CRIS Options.       (line   81)
+* mgp-direct:                            NDS32 Options.      (line   45)
+* mgp32:                                 MIPS Options.       (line  222)
+* mgp64:                                 MIPS Options.       (line  225)
+* mgpopt:                                MIPS Options.       (line  435)
+* mgpopt <1>:                            Nios II Options.    (line   15)
+* mgpr-32:                               FRV Options.        (line    7)
+* mgpr-64:                               FRV Options.        (line   11)
+* mgprel-ro:                             FRV Options.        (line   99)
+* mh:                                    H8/300 Options.     (line   14)
+* mhal:                                  Nios II Options.    (line  220)
+* mhalf-reg-file:                        Adapteva Epiphany Options.
+                                                             (line    9)
+* mhard-dfp:                             RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mhard-dfp <1>:                         S/390 and zSeries Options.
+                                                             (line   20)
+* mhard-float:                           FRV Options.        (line   23)
+* mhard-float <1>:                       M680x0 Options.     (line  194)
+* mhard-float <2>:                       MicroBlaze Options. (line   10)
+* mhard-float <3>:                       MIPS Options.       (line  234)
+* mhard-float <4>:                       RS/6000 and PowerPC Options.
+                                                             (line  362)
+* mhard-float <5>:                       S/390 and zSeries Options.
+                                                             (line   11)
+* mhard-float <6>:                       SPARC Options.      (line   34)
+* mhard-float <7>:                       V850 Options.       (line  113)
+* mhard-quad-float:                      SPARC Options.      (line   55)
+* mhardlit:                              MCore Options.      (line   10)
+* mhint-max-distance:                    SPU Options.        (line  107)
+* mhint-max-nops:                        SPU Options.        (line  101)
+* mhitachi:                              SH Options.         (line  100)
+* mhitachi <1>:                          SH Options.         (line  103)
+* mhitachi <2>:                          SH Options.         (line  106)
+* mhotpatch:                             S/390 and zSeries Options.
+                                                             (line  171)
+* mhp-ld:                                HPPA Options.       (line  117)
+* mhw-div:                               Nios II Options.    (line   55)
+* mhw-mul:                               Nios II Options.    (line   55)
+* mhw-mulx:                              Nios II Options.    (line   55)
+* micplb:                                Blackfin Options.   (line  177)
+* mid-shared-library:                    Blackfin Options.   (line   80)
+* mieee:                                 DEC Alpha Options.  (line   39)
+* mieee <1>:                             SH Options.         (line  116)
+* mieee-conformant:                      DEC Alpha Options.  (line  134)
+* mieee-fp:                              i386 and x86-64 Options.
+                                                             (line  328)
+* mieee-with-inexact:                    DEC Alpha Options.  (line   52)
+* milp32:                                IA-64 Options.      (line  121)
+* mimadd:                                MIPS Options.       (line  543)
+* mimpure-text:                          Solaris 2 Options.  (line    9)
+* mincoming-stack-boundary:              i386 and x86-64 Options.
+                                                             (line  535)
+* mindexed-addressing:                   SH Options.         (line  345)
+* mindexed-loads:                        ARC Options.        (line  236)
+* minline-all-stringops:                 i386 and x86-64 Options.
+                                                             (line  842)
+* minline-float-divide-max-throughput:   IA-64 Options.      (line   58)
+* minline-float-divide-min-latency:      IA-64 Options.      (line   54)
+* minline-ic_invalidate:                 SH Options.         (line  125)
+* minline-int-divide-max-throughput:     IA-64 Options.      (line   69)
+* minline-int-divide-min-latency:        IA-64 Options.      (line   65)
+* minline-plt:                           Blackfin Options.   (line  137)
+* minline-plt <1>:                       FRV Options.        (line   81)
+* minline-sqrt-max-throughput:           IA-64 Options.      (line   80)
+* minline-sqrt-min-latency:              IA-64 Options.      (line   76)
+* minline-stringops-dynamically:         i386 and x86-64 Options.
+                                                             (line  849)
+* minsert-sched-nops:                    RS/6000 and PowerPC Options.
+                                                             (line  545)
+* mint-register:                         RX Options.         (line  100)
+* mint16:                                PDP-11 Options.     (line   40)
+* mint32:                                CR16 Options.       (line   22)
+* mint32 <1>:                            H8/300 Options.     (line   38)
+* mint32 <2>:                            PDP-11 Options.     (line   44)
+* mint8:                                 AVR Options.        (line  161)
+* minterlink-compressed:                 MIPS Options.       (line  117)
+* minterlink-mips16:                     MIPS Options.       (line  129)
+* minvalid-symbols:                      SH Options.         (line  379)
+* mio-volatile:                          MeP Options.        (line   74)
+* mips1:                                 MIPS Options.       (line   77)
+* mips16:                                MIPS Options.       (line  102)
+* mips2:                                 MIPS Options.       (line   80)
+* mips3:                                 MIPS Options.       (line   83)
+* mips32:                                MIPS Options.       (line   89)
+* mips32r2:                              MIPS Options.       (line   92)
+* mips3d:                                MIPS Options.       (line  342)
+* mips4:                                 MIPS Options.       (line   86)
+* mips64:                                MIPS Options.       (line   95)
+* mips64r2:                              MIPS Options.       (line   98)
+* misel:                                 RS/6000 and PowerPC Options.
+                                                             (line  191)
+* misize:                                ARC Options.        (line  130)
+* misize <1>:                            SH Options.         (line  137)
+* misr-vector-size:                      NDS32 Options.      (line   51)
+* missue-rate=NUMBER:                    M32R/D Options.     (line   79)
+* mivc2:                                 MeP Options.        (line   59)
+* mjump-in-delay:                        HPPA Options.       (line   23)
+* mkernel:                               Darwin Options.     (line   82)
+* mknuthdiv:                             MMIX Options.       (line   32)
+* ml:                                    MeP Options.        (line   78)
+* ml <1>:                                SH Options.         (line   77)
+* mlarge:                                MSP430 Options.     (line   45)
+* mlarge-data:                           DEC Alpha Options.  (line  187)
+* mlarge-data-threshold:                 i386 and x86-64 Options.
+                                                             (line  421)
+* mlarge-mem:                            SPU Options.        (line   38)
+* mlarge-text:                           DEC Alpha Options.  (line  205)
+* mleadz:                                MeP Options.        (line   81)
+* mleaf-id-shared-library:               Blackfin Options.   (line   91)
+* mlibfuncs:                             MMIX Options.       (line   10)
+* mlibrary-pic:                          FRV Options.        (line  135)
+* mlinked-fp:                            FRV Options.        (line  116)
+* mlinker-opt:                           HPPA Options.       (line   79)
+* mlinux:                                CRIS Options.       (line   91)
+* mlittle:                               RS/6000 and PowerPC Options.
+                                                             (line  494)
+* mlittle-endian:                        AArch64 Options.    (line   27)
+* mlittle-endian <1>:                    ARC Options.        (line  353)
+* mlittle-endian <2>:                    ARM Options.        (line   58)
+* mlittle-endian <3>:                    C6X Options.        (line   16)
+* mlittle-endian <4>:                    IA-64 Options.      (line   13)
+* mlittle-endian <5>:                    MCore Options.      (line   39)
+* mlittle-endian <6>:                    MicroBlaze Options. (line   60)
+* mlittle-endian <7>:                    NDS32 Options.      (line   12)
+* mlittle-endian <8>:                    RS/6000 and PowerPC Options.
+                                                             (line  494)
+* mlittle-endian <9>:                    TILE-Gx Options.    (line   29)
+* mlittle-endian-data:                   RX Options.         (line   42)
+* mliw:                                  MN10300 Options.    (line   54)
+* mllsc:                                 MIPS Options.       (line  299)
+* mlocal-sdata:                          MIPS Options.       (line  401)
+* mlock:                                 ARC Options.        (line   96)
+* mlong-calls:                           Adapteva Epiphany Options.
+                                                             (line   55)
+* mlong-calls <1>:                       ARC Options.        (line  161)
+* mlong-calls <2>:                       ARM Options.        (line  201)
+* mlong-calls <3>:                       Blackfin Options.   (line  120)
+* mlong-calls <4>:                       FRV Options.        (line  122)
+* mlong-calls <5>:                       MIPS Options.       (line  529)
+* mlong-calls <6>:                       V850 Options.       (line   10)
+* mlong-double-128:                      i386 and x86-64 Options.
+                                                             (line  407)
+* mlong-double-128 <1>:                  S/390 and zSeries Options.
+                                                             (line   29)
+* mlong-double-64:                       i386 and x86-64 Options.
+                                                             (line  407)
+* mlong-double-64 <1>:                   S/390 and zSeries Options.
+                                                             (line   29)
+* mlong-double-80:                       i386 and x86-64 Options.
+                                                             (line  407)
+* mlong-jumps:                           V850 Options.       (line  108)
+* mlong-load-store:                      HPPA Options.       (line   60)
+* mlong32:                               MIPS Options.       (line  376)
+* mlong64:                               MIPS Options.       (line  371)
+* mlongcall:                             RS/6000 and PowerPC Options.
+                                                             (line  753)
+* mlongcalls:                            Xtensa Options.     (line   72)
+* mloop:                                 V850 Options.       (line  121)
+* mlow-64k:                              Blackfin Options.   (line   69)
+* mlp64:                                 IA-64 Options.      (line  121)
+* mlra:                                  ARC Options.        (line  241)
+* mlra-priority-compact:                 ARC Options.        (line  249)
+* mlra-priority-noncompact:              ARC Options.        (line  252)
+* mlra-priority-none:                    ARC Options.        (line  246)
+* MM:                                    Preprocessor Options.
+                                                             (line  210)
+* mm:                                    MeP Options.        (line   84)
+* mmac:                                  CR16 Options.       (line    9)
+* mmac <1>:                              Score Options.      (line   21)
+* mmac-24:                               ARC Options.        (line  105)
+* mmac-d16:                              ARC Options.        (line  101)
+* mmac_24:                               ARC Options.        (line  376)
+* mmac_d16:                              ARC Options.        (line  379)
+* mmad:                                  MIPS Options.       (line  538)
+* mmalloc64:                             VMS Options.        (line   17)
+* mmax:                                  DEC Alpha Options.  (line  163)
+* mmax-constant-size:                    RX Options.         (line   82)
+* mmax-stack-frame:                      CRIS Options.       (line   23)
+* mmcount-ra-address:                    MIPS Options.       (line  768)
+* mmcu:                                  AVR Options.        (line    9)
+* mmcu <1>:                              MIPS Options.       (line  359)
+* mmcu=:                                 MSP430 Options.     (line   14)
+* MMD:                                   Preprocessor Options.
+                                                             (line  292)
+* mmedia:                                FRV Options.        (line   56)
+* mmedium-calls:                         ARC Options.        (line  165)
+* mmemcpy:                               MicroBlaze Options. (line   13)
+* mmemcpy <1>:                           MIPS Options.       (line  523)
+* mmemcpy-strategy=STRATEGY:             i386 and x86-64 Options.
+                                                             (line  871)
+* mmemory-latency:                       DEC Alpha Options.  (line  268)
+* mmemory-model:                         SPARC Options.      (line  283)
+* mmemset-strategy=STRATEGY:             i386 and x86-64 Options.
+                                                             (line  883)
+* mmfcrf:                                RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mmfpgpr:                               RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mmicromips:                            MIPS Options.       (line  347)
+* mminimal-toc:                          RS/6000 and PowerPC Options.
+                                                             (line  285)
+* mminmax:                               MeP Options.        (line   87)
+* mmixed-code:                           ARC Options.        (line  264)
+* mmmx:                                  i386 and x86-64 Options.
+                                                             (line  629)
+* mmodel=large:                          M32R/D Options.     (line   33)
+* mmodel=medium:                         M32R/D Options.     (line   27)
+* mmodel=small:                          M32R/D Options.     (line   18)
+* mmovbe:                                i386 and x86-64 Options.
+                                                             (line  715)
+* mmt:                                   MIPS Options.       (line  355)
+* mmul:                                  RL78 Options.       (line   13)
+* mmul-bug-workaround:                   CRIS Options.       (line   32)
+* mmul32x16:                             ARC Options.        (line   51)
+* mmul64:                                ARC Options.        (line   54)
+* mmuladd:                               FRV Options.        (line   64)
+* mmulhw:                                RS/6000 and PowerPC Options.
+                                                             (line  438)
+* mmult:                                 MeP Options.        (line   90)
+* mmult-bug:                             MN10300 Options.    (line    9)
+* mmultcost:                             ARC Options.        (line  326)
+* mmulti-cond-exec:                      FRV Options.        (line  215)
+* mmulticore:                            Blackfin Options.   (line  141)
+* mmultiple:                             RS/6000 and PowerPC Options.
+                                                             (line  388)
+* mmvcle:                                S/390 and zSeries Options.
+                                                             (line  104)
+* mmvme:                                 RS/6000 and PowerPC Options.
+                                                             (line  658)
+* mn:                                    H8/300 Options.     (line   20)
+* mnan=2008:                             MIPS Options.       (line  280)
+* mnan=legacy:                           MIPS Options.       (line  280)
+* mneon-for-64bits:                      ARM Options.        (line  345)
+* mnested-cond-exec:                     FRV Options.        (line  230)
+* mnhwloop:                              Score Options.      (line   15)
+* mno-16-bit:                            NDS32 Options.      (line   42)
+* mno-3dnow:                             i386 and x86-64 Options.
+                                                             (line  629)
+* mno-4byte-functions:                   MCore Options.      (line   27)
+* mno-8byte-align:                       V850 Options.       (line  170)
+* mno-abicalls:                          MIPS Options.       (line  162)
+* mno-abshi:                             PDP-11 Options.     (line   58)
+* mno-ac0:                               PDP-11 Options.     (line   20)
+* mno-address-space-conversion:          SPU Options.        (line   68)
+* mno-align-double:                      i386 and x86-64 Options.
+                                                             (line  366)
+* mno-align-int:                         M680x0 Options.     (line  263)
+* mno-align-loops:                       M32R/D Options.     (line   76)
+* mno-align-stringops:                   i386 and x86-64 Options.
+                                                             (line  837)
+* mno-altivec:                           RS/6000 and PowerPC Options.
+                                                             (line  132)
+* mno-am33:                              MN10300 Options.    (line   20)
+* mno-app-regs:                          SPARC Options.      (line   10)
+* mno-app-regs <1>:                      V850 Options.       (line  185)
+* mno-as100-syntax:                      RX Options.         (line   76)
+* mno-atomic-updates:                    SPU Options.        (line   83)
+* mno-avoid-indexed-addresses:           RS/6000 and PowerPC Options.
+                                                             (line  420)
+* mno-backchain:                         S/390 and zSeries Options.
+                                                             (line   35)
+* mno-base-addresses:                    MMIX Options.       (line   53)
+* mno-bit-align:                         RS/6000 and PowerPC Options.
+                                                             (line  452)
+* mno-bitfield:                          M680x0 Options.     (line  227)
+* mno-branch-likely:                     MIPS Options.       (line  708)
+* mno-branch-predict:                    MMIX Options.       (line   48)
+* mno-brcc:                              ARC Options.        (line  201)
+* mno-bwx:                               DEC Alpha Options.  (line  163)
+* mno-bypass-cache:                      Nios II Options.    (line   34)
+* mno-cache-volatile:                    Nios II Options.    (line   40)
+* mno-callgraph-data:                    MCore Options.      (line   31)
+* mno-cbcond:                            SPARC Options.      (line  217)
+* mno-check-zero-division:               MIPS Options.       (line  503)
+* mno-cix:                               DEC Alpha Options.  (line  163)
+* mno-clearbss:                          MicroBlaze Options. (line   16)
+* mno-cmov:                              NDS32 Options.      (line   24)
+* mno-cmpb:                              RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-cond-exec:                         ARC Options.        (line  213)
+* mno-cond-exec <1>:                     FRV Options.        (line  194)
+* mno-cond-move:                         FRV Options.        (line  166)
+* mno-const-align:                       CRIS Options.       (line   55)
+* mno-const16:                           Xtensa Options.     (line   10)
+* mno-crt0:                              MN10300 Options.    (line   43)
+* mno-crt0 <1>:                          Moxie Options.      (line   14)
+* mno-crypto:                            RS/6000 and PowerPC Options.
+                                                             (line  220)
+* mno-csync-anomaly:                     Blackfin Options.   (line   65)
+* mno-custom-INSN:                       Nios II Options.    (line   61)
+* mno-data-align:                        CRIS Options.       (line   55)
+* mno-debug:                             S/390 and zSeries Options.
+                                                             (line  110)
+* mno-default:                           i386 and x86-64 Options.
+                                                             (line  668)
+* mno-direct-move:                       RS/6000 and PowerPC Options.
+                                                             (line  226)
+* mno-disable-callt:                     V850 Options.       (line   92)
+* mno-div:                               M680x0 Options.     (line  206)
+* mno-div <1>:                           MCore Options.      (line   15)
+* mno-dlmzb:                             RS/6000 and PowerPC Options.
+                                                             (line  445)
+* mno-double:                            FRV Options.        (line   52)
+* mno-dpfp-lrsr:                         ARC Options.        (line   39)
+* mno-dsp:                               MIPS Options.       (line  313)
+* mno-dspr2:                             MIPS Options.       (line  319)
+* mno-dwarf2-asm:                        IA-64 Options.      (line   94)
+* mno-dword:                             FRV Options.        (line   44)
+* mno-eabi:                              RS/6000 and PowerPC Options.
+                                                             (line  682)
+* mno-early-stop-bits:                   IA-64 Options.      (line  100)
+* mno-eflags:                            FRV Options.        (line  155)
+* mno-embedded-data:                     MIPS Options.       (line  450)
+* mno-ep:                                V850 Options.       (line   16)
+* mno-epilogue-cfi:                      ARC Options.        (line  158)
+* mno-epsilon:                           MMIX Options.       (line   15)
+* mno-eva:                               MIPS Options.       (line  363)
+* mno-explicit-relocs:                   DEC Alpha Options.  (line  176)
+* mno-explicit-relocs <1>:               MIPS Options.       (line  494)
+* mno-exr:                               H8/300 Options.     (line   33)
+* mno-extern-sdata:                      MIPS Options.       (line  413)
+* mno-fancy-math-387:                    i386 and x86-64 Options.
+                                                             (line  356)
+* mno-fast-sw-div:                       Nios II Options.    (line   46)
+* mno-faster-structs:                    SPARC Options.      (line   85)
+* mno-fix:                               DEC Alpha Options.  (line  163)
+* mno-fix-24k:                           MIPS Options.       (line  567)
+* mno-fix-r10000:                        MIPS Options.       (line  589)
+* mno-fix-r4000:                         MIPS Options.       (line  573)
+* mno-fix-r4400:                         MIPS Options.       (line  583)
+* mno-flat:                              SPARC Options.      (line   22)
+* mno-float:                             MIPS Options.       (line  241)
+* mno-float32:                           PDP-11 Options.     (line   48)
+* mno-float64:                           PDP-11 Options.     (line   52)
+* mno-flush-func:                        M32R/D Options.     (line   98)
+* mno-flush-trap:                        M32R/D Options.     (line   90)
+* mno-fmaf:                              SPARC Options.      (line  231)
+* mno-fp-in-toc:                         RS/6000 and PowerPC Options.
+                                                             (line  285)
+* mno-fp-regs:                           DEC Alpha Options.  (line   25)
+* mno-fp-ret-in-387:                     i386 and x86-64 Options.
+                                                             (line  346)
+* mno-fprnd:                             RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-fpu:                               SPARC Options.      (line   39)
+* mno-fsca:                              SH Options.         (line  414)
+* mno-fsrra:                             SH Options.         (line  423)
+* mno-fused-madd:                        IA-64 Options.      (line   88)
+* mno-fused-madd <1>:                    MIPS Options.       (line  550)
+* mno-fused-madd <2>:                    RS/6000 and PowerPC Options.
+                                                             (line  429)
+* mno-fused-madd <3>:                    S/390 and zSeries Options.
+                                                             (line  135)
+* mno-fused-madd <4>:                    SH Options.         (line  405)
+* mno-fused-madd <5>:                    Xtensa Options.     (line   19)
+* mno-gnu-as:                            IA-64 Options.      (line   18)
+* mno-gnu-ld:                            IA-64 Options.      (line   23)
+* mno-gotplt:                            CRIS Options.       (line   81)
+* mno-gp-direct:                         NDS32 Options.      (line   48)
+* mno-gpopt:                             MIPS Options.       (line  435)
+* mno-gpopt <1>:                         Nios II Options.    (line   15)
+* mno-hard-dfp:                          RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-hard-dfp <1>:                      S/390 and zSeries Options.
+                                                             (line   20)
+* mno-hardlit:                           MCore Options.      (line   10)
+* mno-hw-div:                            Nios II Options.    (line   55)
+* mno-hw-mul:                            Nios II Options.    (line   55)
+* mno-hw-mulx:                           Nios II Options.    (line   55)
+* mno-id-shared-library:                 Blackfin Options.   (line   87)
+* mno-ieee-fp:                           i386 and x86-64 Options.
+                                                             (line  328)
+* mno-imadd:                             MIPS Options.       (line  543)
+* mno-inline-float-divide:               IA-64 Options.      (line   62)
+* mno-inline-int-divide:                 IA-64 Options.      (line   73)
+* mno-inline-sqrt:                       IA-64 Options.      (line   84)
+* mno-int16:                             PDP-11 Options.     (line   44)
+* mno-int32:                             PDP-11 Options.     (line   40)
+* mno-interlink-compressed:              MIPS Options.       (line  117)
+* mno-interlink-mips16:                  MIPS Options.       (line  129)
+* mno-interrupts:                        AVR Options.        (line  167)
+* mno-isel:                              RS/6000 and PowerPC Options.
+                                                             (line  191)
+* mno-knuthdiv:                          MMIX Options.       (line   32)
+* mno-leaf-id-shared-library:            Blackfin Options.   (line   97)
+* mno-libfuncs:                          MMIX Options.       (line   10)
+* mno-llsc:                              MIPS Options.       (line  299)
+* mno-local-sdata:                       MIPS Options.       (line  401)
+* mno-long-calls:                        ARM Options.        (line  201)
+* mno-long-calls <1>:                    Blackfin Options.   (line  120)
+* mno-long-calls <2>:                    HPPA Options.       (line  130)
+* mno-long-calls <3>:                    MIPS Options.       (line  529)
+* mno-long-calls <4>:                    V850 Options.       (line   10)
+* mno-long-jumps:                        V850 Options.       (line  108)
+* mno-longcall:                          RS/6000 and PowerPC Options.
+                                                             (line  753)
+* mno-longcalls:                         Xtensa Options.     (line   72)
+* mno-low-64k:                           Blackfin Options.   (line   73)
+* mno-lsim:                              FR30 Options.       (line   14)
+* mno-lsim <1>:                          MCore Options.      (line   46)
+* mno-mad:                               MIPS Options.       (line  538)
+* mno-max:                               DEC Alpha Options.  (line  163)
+* mno-mcount-ra-address:                 MIPS Options.       (line  768)
+* mno-mcu:                               MIPS Options.       (line  359)
+* mno-mdmx:                              MIPS Options.       (line  336)
+* mno-media:                             FRV Options.        (line   60)
+* mno-memcpy:                            MIPS Options.       (line  523)
+* mno-mfcrf:                             RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-mfpgpr:                            RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-millicode:                         ARC Options.        (line  255)
+* mno-mips16:                            MIPS Options.       (line  102)
+* mno-mips3d:                            MIPS Options.       (line  342)
+* mno-mmicromips:                        MIPS Options.       (line  347)
+* mno-mmx:                               i386 and x86-64 Options.
+                                                             (line  629)
+* mno-mpy:                               ARC Options.        (line   48)
+* mno-mt:                                MIPS Options.       (line  355)
+* mno-mul-bug-workaround:                CRIS Options.       (line   32)
+* mno-muladd:                            FRV Options.        (line   68)
+* mno-mulhw:                             RS/6000 and PowerPC Options.
+                                                             (line  438)
+* mno-mult-bug:                          MN10300 Options.    (line   13)
+* mno-multi-cond-exec:                   FRV Options.        (line  223)
+* mno-multiple:                          RS/6000 and PowerPC Options.
+                                                             (line  388)
+* mno-mvcle:                             S/390 and zSeries Options.
+                                                             (line  104)
+* mno-nested-cond-exec:                  FRV Options.        (line  237)
+* mno-omit-leaf-frame-pointer:           AArch64 Options.    (line   54)
+* mno-optimize-membar:                   FRV Options.        (line  249)
+* mno-opts:                              MeP Options.        (line   93)
+* mno-pack:                              FRV Options.        (line  151)
+* mno-packed-stack:                      S/390 and zSeries Options.
+                                                             (line   54)
+* mno-paired:                            RS/6000 and PowerPC Options.
+                                                             (line  205)
+* mno-paired-single:                     MIPS Options.       (line  330)
+* mno-perf-ext:                          NDS32 Options.      (line   30)
+* mno-pic:                               IA-64 Options.      (line   26)
+* mno-pid:                               RX Options.         (line  117)
+* mno-plt:                               MIPS Options.       (line  189)
+* mno-popc:                              SPARC Options.      (line  224)
+* mno-popcntb:                           RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-popcntd:                           RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-postinc:                           Adapteva Epiphany Options.
+                                                             (line  109)
+* mno-postmodify:                        Adapteva Epiphany Options.
+                                                             (line  109)
+* mno-power8-fusion:                     RS/6000 and PowerPC Options.
+                                                             (line  232)
+* mno-power8-vector:                     RS/6000 and PowerPC Options.
+                                                             (line  238)
+* mno-powerpc-gfxopt:                    RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-powerpc-gpopt:                     RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-powerpc64:                         RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mno-prolog-function:                   V850 Options.       (line   23)
+* mno-prologue-epilogue:                 CRIS Options.       (line   71)
+* mno-prototype:                         RS/6000 and PowerPC Options.
+                                                             (line  642)
+* mno-push-args:                         i386 and x86-64 Options.
+                                                             (line  815)
+* mno-quad-memory:                       RS/6000 and PowerPC Options.
+                                                             (line  245)
+* mno-quad-memory-atomic:                RS/6000 and PowerPC Options.
+                                                             (line  251)
+* mno-red-zone:                          i386 and x86-64 Options.
+                                                             (line  957)
+* mno-register-names:                    IA-64 Options.      (line   37)
+* mno-regnames:                          RS/6000 and PowerPC Options.
+                                                             (line  747)
+* mno-relax:                             V850 Options.       (line  103)
+* mno-relax-immediate:                   MCore Options.      (line   19)
+* mno-relocatable:                       RS/6000 and PowerPC Options.
+                                                             (line  468)
+* mno-relocatable-lib:                   RS/6000 and PowerPC Options.
+                                                             (line  479)
+* mno-round-nearest:                     Adapteva Epiphany Options.
+                                                             (line   51)
+* mno-rtd:                               M680x0 Options.     (line  258)
+* mno-scc:                               FRV Options.        (line  180)
+* mno-sched-ar-data-spec:                IA-64 Options.      (line  134)
+* mno-sched-ar-in-data-spec:             IA-64 Options.      (line  155)
+* mno-sched-br-data-spec:                IA-64 Options.      (line  128)
+* mno-sched-br-in-data-spec:             IA-64 Options.      (line  148)
+* mno-sched-control-spec:                IA-64 Options.      (line  140)
+* mno-sched-count-spec-in-critical-path: IA-64 Options.      (line  182)
+* mno-sched-in-control-spec:             IA-64 Options.      (line  162)
+* mno-sched-prefer-non-control-spec-insns: IA-64 Options.    (line  175)
+* mno-sched-prefer-non-data-spec-insns:  IA-64 Options.      (line  168)
+* mno-sched-prolog:                      ARM Options.        (line   33)
+* mno-sdata:                             ARC Options.        (line  174)
+* mno-sdata <1>:                         IA-64 Options.      (line   42)
+* mno-sdata <2>:                         RS/6000 and PowerPC Options.
+                                                             (line  728)
+* mno-sep-data:                          Blackfin Options.   (line  115)
+* mno-serialize-volatile:                Xtensa Options.     (line   35)
+* mno-short:                             M680x0 Options.     (line  222)
+* mno-side-effects:                      CRIS Options.       (line   46)
+* mno-sim:                               RX Options.         (line   71)
+* mno-single-exit:                       MMIX Options.       (line   65)
+* mno-slow-bytes:                        MCore Options.      (line   35)
+* mno-small-exec:                        S/390 and zSeries Options.
+                                                             (line   79)
+* mno-smartmips:                         MIPS Options.       (line  326)
+* mno-soft-cmpsf:                        Adapteva Epiphany Options.
+                                                             (line   29)
+* mno-soft-float:                        DEC Alpha Options.  (line   10)
+* mno-space-regs:                        HPPA Options.       (line   39)
+* mno-spe:                               RS/6000 and PowerPC Options.
+                                                             (line  200)
+* mno-specld-anomaly:                    Blackfin Options.   (line   55)
+* mno-split-addresses:                   MIPS Options.       (line  488)
+* mno-sse:                               i386 and x86-64 Options.
+                                                             (line  629)
+* mno-stack-align:                       CRIS Options.       (line   55)
+* mno-stack-bias:                        SPARC Options.      (line  307)
+* mno-strict-align:                      M680x0 Options.     (line  283)
+* mno-strict-align <1>:                  RS/6000 and PowerPC Options.
+                                                             (line  463)
+* mno-string:                            RS/6000 and PowerPC Options.
+                                                             (line  399)
+* mno-sum-in-toc:                        RS/6000 and PowerPC Options.
+                                                             (line  285)
+* mno-sym32:                             MIPS Options.       (line  386)
+* mno-target-align:                      Xtensa Options.     (line   59)
+* mno-text-section-literals:             Xtensa Options.     (line   47)
+* mno-tls-markers:                       RS/6000 and PowerPC Options.
+                                                             (line  785)
+* mno-toc:                               RS/6000 and PowerPC Options.
+                                                             (line  488)
+* mno-toplevel-symbols:                  MMIX Options.       (line   39)
+* mno-tpf-trace:                         S/390 and zSeries Options.
+                                                             (line  129)
+* mno-unaligned-access:                  ARM Options.        (line  332)
+* mno-unaligned-doubles:                 SPARC Options.      (line   73)
+* mno-uninit-const-in-rodata:            MIPS Options.       (line  458)
+* mno-update:                            RS/6000 and PowerPC Options.
+                                                             (line  410)
+* mno-v3push:                            NDS32 Options.      (line   36)
+* mno-v8plus:                            SPARC Options.      (line  188)
+* mno-vect-double:                       Adapteva Epiphany Options.
+                                                             (line  115)
+* mno-virt:                              MIPS Options.       (line  367)
+* mno-vis:                               SPARC Options.      (line  195)
+* mno-vis2:                              SPARC Options.      (line  201)
+* mno-vis3:                              SPARC Options.      (line  209)
+* mno-vliw-branch:                       FRV Options.        (line  208)
+* mno-volatile-asm-stop:                 IA-64 Options.      (line   32)
+* mno-volatile-cache:                    ARC Options.        (line  188)
+* mno-vrsave:                            RS/6000 and PowerPC Options.
+                                                             (line  170)
+* mno-vsx:                               RS/6000 and PowerPC Options.
+                                                             (line  214)
+* mno-warn-multiple-fast-interrupts:     RX Options.         (line  143)
+* mno-wide-bitfields:                    MCore Options.      (line   23)
+* mno-xgot:                              M680x0 Options.     (line  315)
+* mno-xgot <1>:                          MIPS Options.       (line  199)
+* mno-xl-compat:                         RS/6000 and PowerPC Options.
+                                                             (line  320)
+* mno-zdcbranch:                         SH Options.         (line  396)
+* mno-zero-extend:                       MMIX Options.       (line   26)
+* mnobitfield:                           M680x0 Options.     (line  227)
+* mnoieee:                               SH Options.         (line  116)
+* mnoliw:                                MN10300 Options.    (line   59)
+* mnomacsave:                            SH Options.         (line  111)
+* mnop-fun-dllimport:                    i386 and x86-64 Windows Options.
+                                                             (line   22)
+* mnops:                                 Adapteva Epiphany Options.
+                                                             (line   26)
+* mnorm:                                 ARC Options.        (line   58)
+* mnosetlb:                              MN10300 Options.    (line   69)
+* mnosplit-lohi:                         Adapteva Epiphany Options.
+                                                             (line  109)
+* momit-leaf-frame-pointer:              AArch64 Options.    (line   54)
+* momit-leaf-frame-pointer <1>:          Blackfin Options.   (line   43)
+* momit-leaf-frame-pointer <2>:          i386 and x86-64 Options.
+                                                             (line  887)
+* mone-byte-bool:                        Darwin Options.     (line   90)
+* moptimize-membar:                      FRV Options.        (line  244)
+* MP:                                    Preprocessor Options.
+                                                             (line  239)
+* mpa-risc-1-0:                          HPPA Options.       (line   19)
+* mpa-risc-1-1:                          HPPA Options.       (line   19)
+* mpa-risc-2-0:                          HPPA Options.       (line   19)
+* mpack:                                 FRV Options.        (line  147)
+* mpacked-stack:                         S/390 and zSeries Options.
+                                                             (line   54)
+* mpadstruct:                            SH Options.         (line  140)
+* mpaired:                               RS/6000 and PowerPC Options.
+                                                             (line  205)
+* mpaired-single:                        MIPS Options.       (line  330)
+* mpc32:                                 i386 and x86-64 Options.
+                                                             (line  484)
+* mpc64:                                 i386 and x86-64 Options.
+                                                             (line  484)
+* mpc80:                                 i386 and x86-64 Options.
+                                                             (line  484)
+* mpcrel:                                M680x0 Options.     (line  275)
+* mpdebug:                               CRIS Options.       (line   36)
+* mpe:                                   RS/6000 and PowerPC Options.
+                                                             (line  339)
+* mpe-aligned-commons:                   i386 and x86-64 Windows Options.
+                                                             (line   59)
+* mperf-ext:                             NDS32 Options.      (line   27)
+* mpic-data-is-text-relative:            ARM Options.        (line  238)
+* mpic-register:                         ARM Options.        (line  231)
+* mpid:                                  RX Options.         (line  117)
+* mplt:                                  MIPS Options.       (line  189)
+* mpointers-to-nested-functions:         RS/6000 and PowerPC Options.
+                                                             (line  868)
+* mpoke-function-name:                   ARM Options.        (line  244)
+* mpopc:                                 SPARC Options.      (line  224)
+* mpopcntb:                              RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mpopcntd:                              RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mportable-runtime:                     HPPA Options.       (line   65)
+* mpower8-fusion:                        RS/6000 and PowerPC Options.
+                                                             (line  232)
+* mpower8-vector:                        RS/6000 and PowerPC Options.
+                                                             (line  238)
+* mpowerpc-gfxopt:                       RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mpowerpc-gpopt:                        RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mpowerpc64:                            RS/6000 and PowerPC Options.
+                                                             (line   27)
+* mprefer-avx128:                        i386 and x86-64 Options.
+                                                             (line  692)
+* mprefer-short-insn-regs:               Adapteva Epiphany Options.
+                                                             (line   13)
+* mprefergot:                            SH Options.         (line  223)
+* mpreferred-stack-boundary:             i386 and x86-64 Options.
+                                                             (line  514)
+* mpretend-cmove:                        SH Options.         (line  432)
+* mprioritize-restricted-insns:          RS/6000 and PowerPC Options.
+                                                             (line  517)
+* mprolog-function:                      V850 Options.       (line   23)
+* mprologue-epilogue:                    CRIS Options.       (line   71)
+* mprototype:                            RS/6000 and PowerPC Options.
+                                                             (line  642)
+* mpt-fixed:                             SH Options.         (line  359)
+* mpush-args:                            i386 and x86-64 Options.
+                                                             (line  815)
+* MQ:                                    Preprocessor Options.
+                                                             (line  266)
+* mq-class:                              ARC Options.        (line  269)
+* mquad-memory:                          RS/6000 and PowerPC Options.
+                                                             (line  245)
+* mquad-memory-atomic:                   RS/6000 and PowerPC Options.
+                                                             (line  251)
+* mr10k-cache-barrier:                   MIPS Options.       (line  630)
+* mRcq:                                  ARC Options.        (line  273)
+* mRcw:                                  ARC Options.        (line  277)
+* mrecip:                                i386 and x86-64 Options.
+                                                             (line  725)
+* mrecip <1>:                            RS/6000 and PowerPC Options.
+                                                             (line  797)
+* mrecip-precision:                      RS/6000 and PowerPC Options.
+                                                             (line  832)
+* mrecip=opt:                            i386 and x86-64 Options.
+                                                             (line  747)
+* mrecip=opt <1>:                        RS/6000 and PowerPC Options.
+                                                             (line  810)
+* mreduced-regs:                         NDS32 Options.      (line   15)
+* mregister-names:                       IA-64 Options.      (line   37)
+* mregnames:                             RS/6000 and PowerPC Options.
+                                                             (line  747)
+* mregparm:                              i386 and x86-64 Options.
+                                                             (line  451)
+* mrelax:                                AVR Options.        (line  171)
+* mrelax <1>:                            H8/300 Options.     (line    9)
+* mrelax <2>:                            MN10300 Options.    (line   46)
+* mrelax <3>:                            MSP430 Options.     (line   51)
+* mrelax <4>:                            NDS32 Options.      (line   76)
+* mrelax <5>:                            RX Options.         (line   95)
+* mrelax <6>:                            SH Options.         (line   85)
+* mrelax <7>:                            V850 Options.       (line  103)
+* mrelax-immediate:                      MCore Options.      (line   19)
+* mrelax-pic-calls:                      MIPS Options.       (line  755)
+* mrelocatable:                          RS/6000 and PowerPC Options.
+                                                             (line  468)
+* mrelocatable-lib:                      RS/6000 and PowerPC Options.
+                                                             (line  479)
+* mrepeat:                               MeP Options.        (line   96)
+* mrestrict-it:                          ARM Options.        (line  356)
+* mreturn-pointer-on-d0:                 MN10300 Options.    (line   36)
+* mrh850-abi:                            V850 Options.       (line  127)
+* mrtd:                                  i386 and x86-64 Options.
+                                                             (line  427)
+* mrtd <1>:                              M680x0 Options.     (line  236)
+* mrtd <2>:                              Function Attributes.
+                                                             (line  209)
+* mrtp:                                  VxWorks Options.    (line   11)
+* mrtsc:                                 ARC Options.        (line  109)
+* ms:                                    H8/300 Options.     (line   17)
+* ms <1>:                                MeP Options.        (line  100)
+* ms2600:                                H8/300 Options.     (line   24)
+* msafe-dma:                             SPU Options.        (line   18)
+* msafe-hints:                           SPU Options.        (line  112)
+* msahf:                                 i386 and x86-64 Options.
+                                                             (line  705)
+* msatur:                                MeP Options.        (line  105)
+* msave-acc-in-interrupts:               RX Options.         (line  109)
+* msave-toc-indirect:                    RS/6000 and PowerPC Options.
+                                                             (line  880)
+* mscc:                                  FRV Options.        (line  173)
+* msched-ar-data-spec:                   IA-64 Options.      (line  134)
+* msched-ar-in-data-spec:                IA-64 Options.      (line  155)
+* msched-br-data-spec:                   IA-64 Options.      (line  128)
+* msched-br-in-data-spec:                IA-64 Options.      (line  148)
+* msched-control-spec:                   IA-64 Options.      (line  140)
+* msched-costly-dep:                     RS/6000 and PowerPC Options.
+                                                             (line  524)
+* msched-count-spec-in-critical-path:    IA-64 Options.      (line  182)
+* msched-fp-mem-deps-zero-cost:          IA-64 Options.      (line  198)
+* msched-in-control-spec:                IA-64 Options.      (line  162)
+* msched-max-memory-insns:               IA-64 Options.      (line  207)
+* msched-max-memory-insns-hard-limit:    IA-64 Options.      (line  213)
+* msched-prefer-non-control-spec-insns:  IA-64 Options.      (line  175)
+* msched-prefer-non-data-spec-insns:     IA-64 Options.      (line  168)
+* msched-spec-ldc:                       IA-64 Options.      (line  187)
+* msched-spec-ldc <1>:                   IA-64 Options.      (line  190)
+* msched-stop-bits-after-every-cycle:    IA-64 Options.      (line  194)
+* mschedule:                             HPPA Options.       (line   72)
+* mscore5:                               Score Options.      (line   25)
+* mscore5u:                              Score Options.      (line   28)
+* mscore7:                               Score Options.      (line   31)
+* mscore7d:                              Score Options.      (line   35)
+* msda:                                  V850 Options.       (line   40)
+* msdata:                                IA-64 Options.      (line   42)
+* msdata <1>:                            RS/6000 and PowerPC Options.
+                                                             (line  715)
+* msdata=all:                            C6X Options.        (line   30)
+* msdata=data:                           RS/6000 and PowerPC Options.
+                                                             (line  720)
+* msdata=default:                        C6X Options.        (line   22)
+* msdata=default <1>:                    RS/6000 and PowerPC Options.
+                                                             (line  715)
+* msdata=eabi:                           RS/6000 and PowerPC Options.
+                                                             (line  696)
+* msdata=none:                           C6X Options.        (line   35)
+* msdata=none <1>:                       M32R/D Options.     (line   40)
+* msdata=none <2>:                       RS/6000 and PowerPC Options.
+                                                             (line  728)
+* msdata=sdata:                          M32R/D Options.     (line   49)
+* msdata=sysv:                           RS/6000 and PowerPC Options.
+                                                             (line  706)
+* msdata=use:                            M32R/D Options.     (line   53)
+* msdram:                                Blackfin Options.   (line  171)
+* msdram <1>:                            MeP Options.        (line  110)
+* msecure-plt:                           RS/6000 and PowerPC Options.
+                                                             (line  180)
+* msel-sched-dont-check-control-spec:    IA-64 Options.      (line  203)
+* msep-data:                             Blackfin Options.   (line  109)
+* mserialize-volatile:                   Xtensa Options.     (line   35)
+* msetlb:                                MN10300 Options.    (line   64)
+* mshared-library-id:                    Blackfin Options.   (line  102)
+* mshort:                                M680x0 Options.     (line  216)
+* msign-extend-enabled:                  LM32 Options.       (line   18)
+* msim:                                  Blackfin Options.   (line   36)
+* msim <1>:                              C6X Options.        (line   19)
+* msim <2>:                              CR16 Options.       (line   18)
+* msim <3>:                              M32C Options.       (line   13)
+* msim <4>:                              MeP Options.        (line  114)
+* msim <5>:                              MSP430 Options.     (line   40)
+* msim <6>:                              RL78 Options.       (line    7)
+* msim <7>:                              RS/6000 and PowerPC Options.
+                                                             (line  652)
+* msim <8>:                              RX Options.         (line   71)
+* msim <9>:                              Xstormy16 Options.  (line    9)
+* msimd:                                 ARC Options.        (line   71)
+* msimnovec:                             MeP Options.        (line  117)
+* msimple-fpu:                           RS/6000 and PowerPC Options.
+                                                             (line  372)
+* msingle-exit:                          MMIX Options.       (line   65)
+* msingle-float:                         MIPS Options.       (line  251)
+* msingle-float <1>:                     RS/6000 and PowerPC Options.
+                                                             (line  368)
+* msingle-pic-base:                      ARM Options.        (line  225)
+* msingle-pic-base <1>:                  RS/6000 and PowerPC Options.
+                                                             (line  511)
+* msio:                                  HPPA Options.       (line   99)
+* msize-level:                           ARC Options.        (line  281)
+* mslow-bytes:                           MCore Options.      (line   35)
+* mslow-flash-data:                      ARM Options.        (line  350)
+* msmall:                                MSP430 Options.     (line   48)
+* msmall-data:                           DEC Alpha Options.  (line  187)
+* msmall-data-limit:                     RX Options.         (line   47)
+* msmall-divides:                        MicroBlaze Options. (line   39)
+* msmall-exec:                           S/390 and zSeries Options.
+                                                             (line   79)
+* msmall-mem:                            SPU Options.        (line   38)
+* msmall-model:                          FR30 Options.       (line    9)
+* msmall-text:                           DEC Alpha Options.  (line  205)
+* msmall16:                              Adapteva Epiphany Options.
+                                                             (line   66)
+* msmallc:                               Nios II Options.    (line  226)
+* msmartmips:                            MIPS Options.       (line  326)
+* msoft-float:                           ARC Options.        (line   75)
+* msoft-float <1>:                       DEC Alpha Options.  (line   10)
+* msoft-float <2>:                       FRV Options.        (line   27)
+* msoft-float <3>:                       HPPA Options.       (line   85)
+* msoft-float <4>:                       i386 and x86-64 Options.
+                                                             (line  333)
+* msoft-float <5>:                       M680x0 Options.     (line  200)
+* msoft-float <6>:                       MicroBlaze Options. (line    7)
+* msoft-float <7>:                       MIPS Options.       (line  237)
+* msoft-float <8>:                       PDP-11 Options.     (line   13)
+* msoft-float <9>:                       RS/6000 and PowerPC Options.
+                                                             (line  362)
+* msoft-float <10>:                      S/390 and zSeries Options.
+                                                             (line   11)
+* msoft-float <11>:                      SPARC Options.      (line   39)
+* msoft-float <12>:                      V850 Options.       (line  113)
+* msoft-quad-float:                      SPARC Options.      (line   59)
+* msp8:                                  AVR Options.        (line  185)
+* mspace:                                SH Options.         (line  220)
+* mspace <1>:                            V850 Options.       (line   30)
+* mspe:                                  RS/6000 and PowerPC Options.
+                                                             (line  200)
+* mspecld-anomaly:                       Blackfin Options.   (line   50)
+* mspfp:                                 ARC Options.        (line   62)
+* mspfp-compact:                         ARC Options.        (line   63)
+* mspfp-fast:                            ARC Options.        (line   67)
+* mspfp_compact:                         ARC Options.        (line  382)
+* mspfp_fast:                            ARC Options.        (line  385)
+* msplit-addresses:                      MIPS Options.       (line  488)
+* msplit-vecmove-early:                  Adapteva Epiphany Options.
+                                                             (line  126)
+* msse:                                  i386 and x86-64 Options.
+                                                             (line  629)
+* msse2avx:                              i386 and x86-64 Options.
+                                                             (line  905)
+* msseregparm:                           i386 and x86-64 Options.
+                                                             (line  462)
+* mstack-align:                          CRIS Options.       (line   55)
+* mstack-bias:                           SPARC Options.      (line  307)
+* mstack-check-l1:                       Blackfin Options.   (line   76)
+* mstack-guard:                          S/390 and zSeries Options.
+                                                             (line  154)
+* mstack-increment:                      MCore Options.      (line   50)
+* mstack-offset:                         Adapteva Epiphany Options.
+                                                             (line   37)
+* mstack-protector-guard=GUARD:          i386 and x86-64 Options.
+                                                             (line  928)
+* mstack-size:                           S/390 and zSeries Options.
+                                                             (line  154)
+* mstackrealign:                         i386 and x86-64 Options.
+                                                             (line  505)
+* mstdmain:                              SPU Options.        (line   44)
+* mstrict-align:                         AArch64 Options.    (line   49)
+* mstrict-align <1>:                     M680x0 Options.     (line  283)
+* mstrict-align <2>:                     RS/6000 and PowerPC Options.
+                                                             (line  463)
+* mstrict-X:                             AVR Options.        (line  198)
+* mstring:                               RS/6000 and PowerPC Options.
+                                                             (line  399)
+* mstringop-strategy=ALG:                i386 and x86-64 Options.
+                                                             (line  853)
+* mstructure-size-boundary:              ARM Options.        (line  182)
+* msvr4-struct-return:                   RS/6000 and PowerPC Options.
+                                                             (line  604)
+* mswap:                                 ARC Options.        (line   82)
+* mswape:                                ARC Options.        (line  114)
+* msym32:                                MIPS Options.       (line  386)
+* msynci:                                MIPS Options.       (line  740)
+* msys-crt0:                             Nios II Options.    (line  230)
+* msys-lib:                              Nios II Options.    (line  234)
+* MT:                                    Preprocessor Options.
+                                                             (line  251)
+* mtarget-align:                         Xtensa Options.     (line   59)
+* mtas:                                  SH Options.         (line  211)
+* mtda:                                  V850 Options.       (line   34)
+* mtelephony:                            ARC Options.        (line  119)
+* mtext-section-literals:                Xtensa Options.     (line   47)
+* mtf:                                   MeP Options.        (line  121)
+* mthread:                               i386 and x86-64 Windows Options.
+                                                             (line   26)
+* mthreads:                              i386 and x86-64 Options.
+                                                             (line  830)
+* mthumb:                                ARM Options.        (line  266)
+* mthumb-interwork:                      ARM Options.        (line   25)
+* mtiny-stack:                           AVR Options.        (line  212)
+* mtiny=:                                MeP Options.        (line  125)
+* mTLS:                                  FRV Options.        (line   90)
+* mtls:                                  FRV Options.        (line   94)
+* mtls-dialect:                          ARM Options.        (line  308)
+* mtls-dialect <1>:                      i386 and x86-64 Options.
+                                                             (line  808)
+* mtls-dialect=desc:                     AArch64 Options.    (line   58)
+* mtls-dialect=traditional:              AArch64 Options.    (line   62)
+* mtls-direct-seg-refs:                  i386 and x86-64 Options.
+                                                             (line  895)
+* mtls-markers:                          RS/6000 and PowerPC Options.
+                                                             (line  785)
+* mtls-size:                             IA-64 Options.      (line  112)
+* mtoc:                                  RS/6000 and PowerPC Options.
+                                                             (line  488)
+* mtomcat-stats:                         FRV Options.        (line  254)
+* mtoplevel-symbols:                     MMIX Options.       (line   39)
+* mtp:                                   ARM Options.        (line  300)
+* mtpcs-frame:                           ARM Options.        (line  273)
+* mtpcs-leaf-frame:                      ARM Options.        (line  279)
+* mtpf-trace:                            S/390 and zSeries Options.
+                                                             (line  129)
+* mtrap-precision:                       DEC Alpha Options.  (line  109)
+* mtune:                                 AArch64 Options.    (line   83)
+* mtune <1>:                             ARC Options.        (line  302)
+* mtune <2>:                             ARC Options.        (line  388)
+* mtune <3>:                             ARM Options.        (line   97)
+* mtune <4>:                             CRIS Options.       (line   17)
+* mtune <5>:                             DEC Alpha Options.  (line  259)
+* mtune <6>:                             i386 and x86-64 Options.
+                                                             (line  216)
+* mtune <7>:                             IA-64 Options.      (line  116)
+* mtune <8>:                             M680x0 Options.     (line   68)
+* mtune <9>:                             MIPS Options.       (line   63)
+* mtune <10>:                            MN10300 Options.    (line   30)
+* mtune <11>:                            RS/6000 and PowerPC Options.
+                                                             (line  110)
+* mtune <12>:                            S/390 and zSeries Options.
+                                                             (line  122)
+* mtune <13>:                            SPARC Options.      (line  174)
+* mtune-ctrl=FEATURE-LIST:               i386 and x86-64 Options.
+                                                             (line  658)
+* mucb-mcount:                           ARC Options.        (line  179)
+* muclibc:                               GNU/Linux Options.  (line   13)
+* muls:                                  Score Options.      (line   18)
+* multcost:                              ARC Options.        (line  393)
+* multcost=NUMBER:                       SH Options.         (line  233)
+* multilib-library-pic:                  FRV Options.        (line  110)
+* multiply-enabled:                      LM32 Options.       (line   15)
+* multiply_defined:                      Darwin Options.     (line  196)
+* multiply_defined_unused:               Darwin Options.     (line  196)
+* multi_module:                          Darwin Options.     (line  196)
+* munalign-prob-threshold:               ARC Options.        (line  330)
+* munaligned-access:                     ARM Options.        (line  332)
+* munaligned-doubles:                    SPARC Options.      (line   73)
+* municode:                              i386 and x86-64 Windows Options.
+                                                             (line   30)
+* muninit-const-in-rodata:               MIPS Options.       (line  458)
+* munix:                                 VAX Options.        (line    9)
+* munix-asm:                             PDP-11 Options.     (line   68)
+* munsafe-dma:                           SPU Options.        (line   18)
+* mupdate:                               RS/6000 and PowerPC Options.
+                                                             (line  410)
+* muser-enabled:                         LM32 Options.       (line   21)
+* musermode:                             SH Options.         (line  228)
+* mv3push:                               NDS32 Options.      (line   33)
+* mv850:                                 V850 Options.       (line   49)
+* mv850e:                                V850 Options.       (line   79)
+* mv850e1:                               V850 Options.       (line   70)
+* mv850e2:                               V850 Options.       (line   66)
+* mv850e2v3:                             V850 Options.       (line   61)
+* mv850e2v4:                             V850 Options.       (line   57)
+* mv850e3v5:                             V850 Options.       (line   52)
+* mv850es:                               V850 Options.       (line   75)
+* mv8plus:                               SPARC Options.      (line  188)
+* mveclibabi:                            i386 and x86-64 Options.
+                                                             (line  776)
+* mveclibabi <1>:                        RS/6000 and PowerPC Options.
+                                                             (line  841)
+* mvect8-ret-in-mem:                     i386 and x86-64 Options.
+                                                             (line  472)
+* mvirt:                                 MIPS Options.       (line  367)
+* mvis:                                  SPARC Options.      (line  195)
+* mvis2:                                 SPARC Options.      (line  201)
+* mvis3:                                 SPARC Options.      (line  209)
+* mvliw-branch:                          FRV Options.        (line  201)
+* mvms-return-codes:                     VMS Options.        (line    9)
+* mvolatile-asm-stop:                    IA-64 Options.      (line   32)
+* mvolatile-cache:                       ARC Options.        (line  184)
+* mvr4130-align:                         MIPS Options.       (line  729)
+* mvrsave:                               RS/6000 and PowerPC Options.
+                                                             (line  170)
+* mvsx:                                  RS/6000 and PowerPC Options.
+                                                             (line  214)
+* mvxworks:                              RS/6000 and PowerPC Options.
+                                                             (line  673)
+* mvzeroupper:                           i386 and x86-64 Options.
+                                                             (line  686)
+* mwarn-cell-microcode:                  RS/6000 and PowerPC Options.
+                                                             (line  176)
+* mwarn-dynamicstack:                    S/390 and zSeries Options.
+                                                             (line  148)
+* mwarn-framesize:                       S/390 and zSeries Options.
+                                                             (line  140)
+* mwarn-multiple-fast-interrupts:        RX Options.         (line  143)
+* mwarn-reloc:                           SPU Options.        (line   10)
+* mwide-bitfields:                       MCore Options.      (line   23)
+* mwin32:                                i386 and x86-64 Windows Options.
+                                                             (line   35)
+* mwindows:                              i386 and x86-64 Windows Options.
+                                                             (line   41)
+* mword-relocations:                     ARM Options.        (line  319)
+* mwords-little-endian:                  ARM Options.        (line   66)
+* mx32:                                  i386 and x86-64 Options.
+                                                             (line  940)
+* mxgot:                                 M680x0 Options.     (line  315)
+* mxgot <1>:                             MIPS Options.       (line  199)
+* mxilinx-fpu:                           RS/6000 and PowerPC Options.
+                                                             (line  383)
+* mxl-barrel-shift:                      MicroBlaze Options. (line   33)
+* mxl-compat:                            RS/6000 and PowerPC Options.
+                                                             (line  320)
+* mxl-float-convert:                     MicroBlaze Options. (line   51)
+* mxl-float-sqrt:                        MicroBlaze Options. (line   54)
+* mxl-gp-opt:                            MicroBlaze Options. (line   45)
+* mxl-multiply-high:                     MicroBlaze Options. (line   48)
+* mxl-pattern-compare:                   MicroBlaze Options. (line   36)
+* mxl-reorder:                           MicroBlaze Options. (line   63)
+* mxl-soft-div:                          MicroBlaze Options. (line   30)
+* mxl-soft-mul:                          MicroBlaze Options. (line   27)
+* mxl-stack-check:                       MicroBlaze Options. (line   42)
+* mxy:                                   ARC Options.        (line  124)
+* myellowknife:                          RS/6000 and PowerPC Options.
+                                                             (line  668)
+* mzarch:                                S/390 and zSeries Options.
+                                                             (line   94)
+* mzda:                                  V850 Options.       (line   45)
+* mzdcbranch:                            SH Options.         (line  396)
+* mzero-extend:                          MMIX Options.       (line   26)
+* no-canonical-prefixes:                 Overall Options.    (line  334)
+* no-integrated-cpp:                     Preprocessor Options.
+                                                             (line   34)
+* no-sysroot-suffix:                     Directory Options.  (line  109)
+* noall_load:                            Darwin Options.     (line  196)
+* nocpp:                                 MIPS Options.       (line  562)
+* nodefaultlibs:                         Link Options.       (line   62)
+* nofixprebinding:                       Darwin Options.     (line  196)
+* nofpu:                                 RX Options.         (line   17)
+* nolibdld:                              HPPA Options.       (line  182)
+* nomultidefs:                           Darwin Options.     (line  196)
+* non-static:                            VxWorks Options.    (line   16)
+* noprebind:                             Darwin Options.     (line  196)
+* noseglinkedit:                         Darwin Options.     (line  196)
+* nostartfiles:                          Link Options.       (line   57)
+* nostdinc:                              Preprocessor Options.
+                                                             (line  401)
+* nostdinc++:                            C++ Dialect Options.
+                                                             (line  396)
+* nostdinc++ <1>:                        Preprocessor Options.
+                                                             (line  406)
+* nostdlib:                              Link Options.       (line   74)
+* no_dead_strip_inits_and_terms:         Darwin Options.     (line  196)
+* o:                                     Overall Options.    (line  192)
+* O:                                     Optimize Options.   (line   39)
+* o <1>:                                 Preprocessor Options.
+                                                             (line   87)
+* O0:                                    Optimize Options.   (line  129)
+* O1:                                    Optimize Options.   (line   39)
+* O2:                                    Optimize Options.   (line   83)
+* O3:                                    Optimize Options.   (line  121)
+* Ofast:                                 Optimize Options.   (line  143)
+* Og:                                    Optimize Options.   (line  149)
+* Os:                                    Optimize Options.   (line  133)
+* p:                                     Debugging Options.  (line  410)
+* P:                                     Preprocessor Options.
+                                                             (line  647)
+* pagezero_size:                         Darwin Options.     (line  196)
+* param:                                 Optimize Options.   (line 2298)
+* pass-exit-codes:                       Overall Options.    (line  150)
+* pedantic:                              Standards.          (line   16)
+* pedantic <1>:                          Warning Options.    (line   71)
+* pedantic <2>:                          Preprocessor Options.
+                                                             (line  175)
+* pedantic <3>:                          C Extensions.       (line    6)
+* pedantic <4>:                          Alternate Keywords. (line   30)
+* pedantic <5>:                          Warnings and Errors.
+                                                             (line   25)
+* pedantic-errors:                       Standards.          (line   16)
+* pedantic-errors <1>:                   Warning Options.    (line  112)
+* pedantic-errors <2>:                   Preprocessor Options.
+                                                             (line  180)
+* pedantic-errors <3>:                   Non-bugs.           (line  216)
+* pedantic-errors <4>:                   Warnings and Errors.
+                                                             (line   25)
+* pg:                                    Debugging Options.  (line  416)
+* pie:                                   Link Options.       (line   99)
+* pipe:                                  Overall Options.    (line  215)
+* prebind:                               Darwin Options.     (line  196)
+* prebind_all_twolevel_modules:          Darwin Options.     (line  196)
+* print-file-name:                       Debugging Options.  (line 1343)
+* print-libgcc-file-name:                Debugging Options.  (line 1377)
+* print-multi-directory:                 Debugging Options.  (line 1349)
+* print-multi-lib:                       Debugging Options.  (line 1354)
+* print-multi-os-directory:              Debugging Options.  (line 1361)
+* print-multiarch:                       Debugging Options.  (line 1370)
+* print-objc-runtime-info:               Objective-C and Objective-C++ Dialect Options.
+                                                             (line  203)
+* print-prog-name:                       Debugging Options.  (line 1374)
+* print-search-dirs:                     Debugging Options.  (line 1385)
+* print-sysroot:                         Debugging Options.  (line 1398)
+* print-sysroot-headers-suffix:          Debugging Options.  (line 1405)
+* private_bundle:                        Darwin Options.     (line  196)
+* pthread:                               RS/6000 and PowerPC Options.
+                                                             (line  792)
+* pthread <1>:                           Solaris 2 Options.  (line   30)
+* pthreads:                              Solaris 2 Options.  (line   24)
+* Q:                                     Debugging Options.  (line  422)
+* Qn:                                    System V Options.   (line   18)
+* Qy:                                    System V Options.   (line   14)
+* rdynamic:                              Link Options.       (line  105)
+* read_only_relocs:                      Darwin Options.     (line  196)
+* remap:                                 Preprocessor Options.
+                                                             (line  694)
+* S:                                     Overall Options.    (line  175)
+* S <1>:                                 Link Options.       (line   20)
+* s:                                     Link Options.       (line  112)
+* save-temps:                            Debugging Options.  (line 1252)
+* save-temps=obj:                        Debugging Options.  (line 1278)
+* sectalign:                             Darwin Options.     (line  196)
+* sectcreate:                            Darwin Options.     (line  196)
+* sectobjectsymbols:                     Darwin Options.     (line  196)
+* sectobjectsymbols <1>:                 Darwin Options.     (line  196)
+* sectorder:                             Darwin Options.     (line  196)
+* seg1addr:                              Darwin Options.     (line  196)
+* segaddr:                               Darwin Options.     (line  196)
+* seglinkedit:                           Darwin Options.     (line  196)
+* segprot:                               Darwin Options.     (line  196)
+* segs_read_only_addr:                   Darwin Options.     (line  196)
+* segs_read_only_addr <1>:               Darwin Options.     (line  196)
+* segs_read_write_addr:                  Darwin Options.     (line  196)
+* segs_read_write_addr <1>:              Darwin Options.     (line  196)
+* seg_addr_table:                        Darwin Options.     (line  196)
+* seg_addr_table_filename:               Darwin Options.     (line  196)
+* shared:                                Link Options.       (line  120)
+* shared-libgcc:                         Link Options.       (line  128)
+* short-calls:                           Adapteva Epiphany Options.
+                                                             (line   61)
+* sim:                                   CRIS Options.       (line   95)
+* sim2:                                  CRIS Options.       (line  101)
+* single_module:                         Darwin Options.     (line  196)
+* specs:                                 Directory Options.  (line   86)
+* static:                                Link Options.       (line  116)
+* static <1>:                            Darwin Options.     (line  196)
+* static <2>:                            HPPA Options.       (line  186)
+* static-libasan:                        Link Options.       (line  163)
+* static-libgcc:                         Link Options.       (line  128)
+* static-liblsan:                        Link Options.       (line  179)
+* static-libstdc++:                      Link Options.       (line  196)
+* static-libtsan:                        Link Options.       (line  171)
+* static-libubsan:                       Link Options.       (line  187)
+* std:                                   Standards.          (line   16)
+* std <1>:                               C Dialect Options.  (line   46)
+* std <2>:                               Other Builtins.     (line   21)
+* std <3>:                               Non-bugs.           (line  107)
+* std=:                                  Preprocessor Options.
+                                                             (line  340)
+* sub_library:                           Darwin Options.     (line  196)
+* sub_umbrella:                          Darwin Options.     (line  196)
+* symbolic:                              Link Options.       (line  207)
+* sysroot:                               Directory Options.  (line   94)
+* T:                                     Link Options.       (line  213)
+* target-help:                           Overall Options.    (line  230)
+* target-help <1>:                       Preprocessor Options.
+                                                             (line  699)
+* threads:                               HPPA Options.       (line  199)
+* time:                                  Debugging Options.  (line 1293)
+* tno-android-cc:                        GNU/Linux Options.  (line   31)
+* tno-android-ld:                        GNU/Linux Options.  (line   35)
+* traditional:                           C Dialect Options.  (line  333)
+* traditional <1>:                       Incompatibilities.  (line    6)
+* traditional-cpp:                       C Dialect Options.  (line  333)
+* traditional-cpp <1>:                   Preprocessor Options.
+                                                             (line  677)
+* trigraphs:                             C Dialect Options.  (line  328)
+* trigraphs <1>:                         Preprocessor Options.
+                                                             (line  681)
+* twolevel_namespace:                    Darwin Options.     (line  196)
+* U:                                     Preprocessor Options.
+                                                             (line   69)
+* u:                                     Link Options.       (line  245)
+* umbrella:                              Darwin Options.     (line  196)
+* undef:                                 Preprocessor Options.
+                                                             (line   73)
+* undefined:                             Darwin Options.     (line  196)
+* unexported_symbols_list:               Darwin Options.     (line  196)
+* v:                                     Overall Options.    (line  203)
+* v <1>:                                 Preprocessor Options.
+                                                             (line  703)
+* version:                               Overall Options.    (line  338)
+* version <1>:                           Preprocessor Options.
+                                                             (line  715)
+* w:                                     Warning Options.    (line   25)
+* W:                                     Warning Options.    (line  166)
+* W <1>:                                 Warning Options.    (line 1265)
+* W <2>:                                 Warning Options.    (line 1349)
+* w <1>:                                 Preprocessor Options.
+                                                             (line  171)
+* W <3>:                                 Incompatibilities.  (line   64)
+* Wa:                                    Assembler Options.  (line    9)
+* Wabi:                                  C++ Dialect Options.
+                                                             (line  404)
+* Waddr-space-convert:                   AVR Options.        (line  215)
+* Waddress:                              Warning Options.    (line 1182)
+* Waggregate-return:                     Warning Options.    (line 1200)
+* Waggressive-loop-optimizations:        Warning Options.    (line 1205)
+* Wall:                                  Warning Options.    (line  116)
+* Wall <1>:                              Preprocessor Options.
+                                                             (line   93)
+* Wall <2>:                              Standard Libraries. (line    6)
+* Warray-bounds:                         Warning Options.    (line  824)
+* Wassign-intercept:                     Objective-C and Objective-C++ Dialect Options.
+                                                             (line  157)
+* Wattributes:                           Warning Options.    (line 1210)
+* Wbad-function-cast:                    Warning Options.    (line 1039)
+* Wbuiltin-macro-redefined:              Warning Options.    (line 1216)
+* Wcast-align:                           Warning Options.    (line 1070)
+* Wcast-qual:                            Warning Options.    (line 1054)
+* Wchar-subscripts:                      Warning Options.    (line  204)
+* Wclobbered:                            Warning Options.    (line 1089)
+* Wcomment:                              Warning Options.    (line  209)
+* Wcomment <1>:                          Preprocessor Options.
+                                                             (line  101)
+* Wcomments:                             Preprocessor Options.
+                                                             (line  101)
+* Wconditionally-supported:              Warning Options.    (line 1093)
+* Wconversion:                           Warning Options.    (line 1096)
+* Wconversion-null:                      Warning Options.    (line 1114)
+* Wctor-dtor-privacy:                    C++ Dialect Options.
+                                                             (line  511)
+* Wdate-time:                            Warning Options.    (line 1122)
+* Wdeclaration-after-statement:          Warning Options.    (line  956)
+* Wdelete-incomplete:                    Warning Options.    (line 1127)
+* Wdelete-non-virtual-dtor:              C++ Dialect Options.
+                                                             (line  518)
+* Wdeprecated:                           Warning Options.    (line 1331)
+* Wdeprecated-declarations:              Warning Options.    (line 1335)
+* Wdisabled-optimization:                Warning Options.    (line 1495)
+* Wdiv-by-zero:                          Warning Options.    (line  829)
+* Wdouble-promotion:                     Warning Options.    (line  233)
+* weak_reference_mismatches:             Darwin Options.     (line  196)
+* Weffc++:                               C++ Dialect Options.
+                                                             (line  598)
+* Wempty-body:                           Warning Options.    (line 1134)
+* Wendif-labels:                         Warning Options.    (line  966)
+* Wendif-labels <1>:                     Preprocessor Options.
+                                                             (line  148)
+* Wenum-compare:                         Warning Options.    (line 1138)
+* Werror:                                Warning Options.    (line   28)
+* Werror <1>:                            Preprocessor Options.
+                                                             (line  161)
+* Werror=:                               Warning Options.    (line   31)
+* Wextra:                                Warning Options.    (line  166)
+* Wextra <1>:                            Warning Options.    (line 1265)
+* Wextra <2>:                            Warning Options.    (line 1349)
+* Wfatal-errors:                         Warning Options.    (line   48)
+* Wfloat-conversion:                     Warning Options.    (line 1168)
+* Wfloat-equal:                          Warning Options.    (line  856)
+* Wformat:                               Warning Options.    (line  252)
+* Wformat <1>:                           Warning Options.    (line  277)
+* Wformat <2>:                           Warning Options.    (line  803)
+* Wformat <3>:                           Function Attributes.
+                                                             (line  453)
+* Wformat-contains-nul:                  Warning Options.    (line  286)
+* Wformat-extra-args:                    Warning Options.    (line  290)
+* Wformat-nonliteral:                    Warning Options.    (line  314)
+* Wformat-nonliteral <1>:                Function Attributes.
+                                                             (line  518)
+* Wformat-security:                      Warning Options.    (line  319)
+* Wformat-y2k:                           Warning Options.    (line  331)
+* Wformat-zero-length:                   Warning Options.    (line  304)
+* Wformat=:                              Warning Options.    (line  252)
+* Wformat=1:                             Warning Options.    (line  277)
+* Wformat=2:                             Warning Options.    (line  309)
+* Wframe-larger-than:                    Warning Options.    (line  980)
+* Wfree-nonheap-object:                  Warning Options.    (line  989)
+* whatsloaded:                           Darwin Options.     (line  196)
+* whyload:                               Darwin Options.     (line  196)
+* Wignored-qualifiers:                   Warning Options.    (line  371)
+* Wimplicit:                             Warning Options.    (line  367)
+* Wimplicit-function-declaration:        Warning Options.    (line  361)
+* Wimplicit-int:                         Warning Options.    (line  357)
+* Winherited-variadic-ctor:              Warning Options.    (line 1405)
+* Winit-self:                            Warning Options.    (line  342)
+* Winline:                               Warning Options.    (line 1410)
+* Winline <1>:                           Inline.             (line   63)
+* Wint-to-pointer-cast:                  Warning Options.    (line 1437)
+* Winvalid-offsetof:                     Warning Options.    (line 1423)
+* Winvalid-pch:                          Warning Options.    (line 1446)
+* Wjump-misses-init:                     Warning Options.    (line 1144)
+* Wl:                                    Link Options.       (line  237)
+* Wlarger-than-LEN:                      Warning Options.    (line  977)
+* Wlarger-than=LEN:                      Warning Options.    (line  977)
+* Wliteral-suffix:                       C++ Dialect Options.
+                                                             (line  525)
+* Wlogical-op:                           Warning Options.    (line 1195)
+* Wlong-long:                            Warning Options.    (line 1450)
+* Wmain:                                 Warning Options.    (line  382)
+* Wmaybe-uninitialized:                  Warning Options.    (line  640)
+* Wmissing-braces:                       Warning Options.    (line  389)
+* Wmissing-declarations:                 Warning Options.    (line 1255)
+* Wmissing-field-initializers:           Warning Options.    (line 1265)
+* Wmissing-format-attribute:             Warning Options.    (line  803)
+* Wmissing-include-dirs:                 Warning Options.    (line  400)
+* Wmissing-parameter-type:               Warning Options.    (line 1237)
+* Wmissing-prototypes:                   Warning Options.    (line 1245)
+* Wmultichar:                            Warning Options.    (line 1283)
+* Wnarrowing:                            C++ Dialect Options.
+                                                             (line  546)
+* Wnested-externs:                       Warning Options.    (line 1402)
+* Wno-abi:                               C++ Dialect Options.
+                                                             (line  404)
+* Wno-address:                           Warning Options.    (line 1182)
+* Wno-aggregate-return:                  Warning Options.    (line 1200)
+* Wno-aggressive-loop-optimizations:     Warning Options.    (line 1205)
+* Wno-all:                               Warning Options.    (line  116)
+* Wno-array-bounds:                      Warning Options.    (line  824)
+* Wno-assign-intercept:                  Objective-C and Objective-C++ Dialect Options.
+                                                             (line  157)
+* Wno-attributes:                        Warning Options.    (line 1210)
+* Wno-bad-function-cast:                 Warning Options.    (line 1039)
+* Wno-builtin-macro-redefined:           Warning Options.    (line 1216)
+* Wno-cast-align:                        Warning Options.    (line 1070)
+* Wno-cast-qual:                         Warning Options.    (line 1054)
+* Wno-char-subscripts:                   Warning Options.    (line  204)
+* Wno-clobbered:                         Warning Options.    (line 1089)
+* Wno-comment:                           Warning Options.    (line  209)
+* Wno-conditionally-supported:           Warning Options.    (line 1093)
+* Wno-conversion:                        Warning Options.    (line 1096)
+* Wno-conversion-null:                   Warning Options.    (line 1114)
+* Wno-coverage-mismatch:                 Warning Options.    (line  214)
+* Wno-ctor-dtor-privacy:                 C++ Dialect Options.
+                                                             (line  511)
+* Wno-date-time:                         Warning Options.    (line 1122)
+* Wno-declaration-after-statement:       Warning Options.    (line  956)
+* Wno-delete-incomplete:                 Warning Options.    (line 1127)
+* Wno-delete-non-virtual-dtor:           C++ Dialect Options.
+                                                             (line  518)
+* Wno-deprecated:                        Warning Options.    (line 1331)
+* Wno-deprecated-declarations:           Warning Options.    (line 1335)
+* Wno-disabled-optimization:             Warning Options.    (line 1495)
+* Wno-div-by-zero:                       Warning Options.    (line  829)
+* Wno-double-promotion:                  Warning Options.    (line  233)
+* Wno-effc++:                            C++ Dialect Options.
+                                                             (line  598)
+* Wno-empty-body:                        Warning Options.    (line 1134)
+* Wno-endif-labels:                      Warning Options.    (line  966)
+* Wno-enum-compare:                      Warning Options.    (line 1138)
+* Wno-error:                             Warning Options.    (line   28)
+* Wno-error=:                            Warning Options.    (line   31)
+* Wno-extra:                             Warning Options.    (line  166)
+* Wno-extra <1>:                         Warning Options.    (line 1265)
+* Wno-extra <2>:                         Warning Options.    (line 1349)
+* Wno-fatal-errors:                      Warning Options.    (line   48)
+* Wno-float-conversion:                  Warning Options.    (line 1168)
+* Wno-float-equal:                       Warning Options.    (line  856)
+* Wno-format:                            Warning Options.    (line  252)
+* Wno-format <1>:                        Warning Options.    (line  803)
+* Wno-format-contains-nul:               Warning Options.    (line  286)
+* Wno-format-extra-args:                 Warning Options.    (line  290)
+* Wno-format-nonliteral:                 Warning Options.    (line  314)
+* Wno-format-security:                   Warning Options.    (line  319)
+* Wno-format-y2k:                        Warning Options.    (line  331)
+* Wno-format-zero-length:                Warning Options.    (line  304)
+* Wno-free-nonheap-object:               Warning Options.    (line  989)
+* Wno-ignored-qualifiers:                Warning Options.    (line  371)
+* Wno-implicit:                          Warning Options.    (line  367)
+* Wno-implicit-function-declaration:     Warning Options.    (line  361)
+* Wno-implicit-int:                      Warning Options.    (line  357)
+* Wno-inherited-variadic-ctor:           Warning Options.    (line 1405)
+* Wno-init-self:                         Warning Options.    (line  342)
+* Wno-inline:                            Warning Options.    (line 1410)
+* Wno-int-to-pointer-cast:               Warning Options.    (line 1437)
+* Wno-invalid-offsetof:                  Warning Options.    (line 1423)
+* Wno-invalid-pch:                       Warning Options.    (line 1446)
+* Wno-jump-misses-init:                  Warning Options.    (line 1144)
+* Wno-literal-suffix:                    C++ Dialect Options.
+                                                             (line  525)
+* Wno-logical-op:                        Warning Options.    (line 1195)
+* Wno-long-long:                         Warning Options.    (line 1450)
+* Wno-main:                              Warning Options.    (line  382)
+* Wno-maybe-uninitialized:               Warning Options.    (line  640)
+* Wno-missing-braces:                    Warning Options.    (line  389)
+* Wno-missing-declarations:              Warning Options.    (line 1255)
+* Wno-missing-field-initializers:        Warning Options.    (line 1265)
+* Wno-missing-format-attribute:          Warning Options.    (line  803)
+* Wno-missing-include-dirs:              Warning Options.    (line  400)
+* Wno-missing-parameter-type:            Warning Options.    (line 1237)
+* Wno-missing-prototypes:                Warning Options.    (line 1245)
+* Wno-multichar:                         Warning Options.    (line 1283)
+* Wno-narrowing:                         C++ Dialect Options.
+                                                             (line  546)
+* Wno-nested-externs:                    Warning Options.    (line 1402)
+* Wno-noexcept:                          C++ Dialect Options.
+                                                             (line  559)
+* Wno-non-template-friend:               C++ Dialect Options.
+                                                             (line  633)
+* Wno-non-virtual-dtor:                  C++ Dialect Options.
+                                                             (line  565)
+* Wno-nonnull:                           Warning Options.    (line  335)
+* Wno-old-style-cast:                    C++ Dialect Options.
+                                                             (line  649)
+* Wno-old-style-declaration:             Warning Options.    (line 1227)
+* Wno-old-style-definition:              Warning Options.    (line 1233)
+* Wno-overflow:                          Warning Options.    (line 1341)
+* Wno-overlength-strings:                Warning Options.    (line 1515)
+* Wno-overloaded-virtual:                C++ Dialect Options.
+                                                             (line  655)
+* Wno-override-init:                     Warning Options.    (line 1349)
+* Wno-packed:                            Warning Options.    (line 1357)
+* Wno-packed-bitfield-compat:            Warning Options.    (line 1374)
+* Wno-padded:                            Warning Options.    (line 1391)
+* Wno-parentheses:                       Warning Options.    (line  403)
+* Wno-pedantic-ms-format:                Warning Options.    (line 1019)
+* Wno-pmf-conversions:                   C++ Dialect Options.
+                                                             (line  674)
+* Wno-pmf-conversions <1>:               Bound member functions.
+                                                             (line   35)
+* Wno-pointer-arith:                     Warning Options.    (line 1025)
+* Wno-pointer-sign:                      Warning Options.    (line 1504)
+* Wno-pointer-to-int-cast:               Warning Options.    (line 1442)
+* Wno-pragmas:                           Warning Options.    (line  690)
+* Wno-protocol:                          Objective-C and Objective-C++ Dialect Options.
+                                                             (line  161)
+* Wno-redundant-decls:                   Warning Options.    (line 1398)
+* Wno-reorder:                           C++ Dialect Options.
+                                                             (line  573)
+* Wno-return-local-addr:                 Warning Options.    (line  498)
+* Wno-return-type:                       Warning Options.    (line  502)
+* Wno-selector:                          Objective-C and Objective-C++ Dialect Options.
+                                                             (line  171)
+* Wno-sequence-point:                    Warning Options.    (line  452)
+* Wno-shadow:                            Warning Options.    (line  970)
+* Wno-sign-compare:                      Warning Options.    (line 1155)
+* Wno-sign-conversion:                   Warning Options.    (line 1162)
+* Wno-sign-promo:                        C++ Dialect Options.
+                                                             (line  678)
+* Wno-sizeof-pointer-memaccess:          Warning Options.    (line 1174)
+* Wno-stack-protector:                   Warning Options.    (line 1510)
+* Wno-strict-aliasing:                   Warning Options.    (line  695)
+* Wno-strict-null-sentinel:              C++ Dialect Options.
+                                                             (line  626)
+* Wno-strict-overflow:                   Warning Options.    (line  734)
+* Wno-strict-prototypes:                 Warning Options.    (line 1221)
+* Wno-strict-selector-match:             Objective-C and Objective-C++ Dialect Options.
+                                                             (line  183)
+* Wno-suggest-attribute=:                Warning Options.    (line  783)
+* Wno-suggest-attribute=const:           Warning Options.    (line  789)
+* Wno-suggest-attribute=format:          Warning Options.    (line  803)
+* Wno-suggest-attribute=noreturn:        Warning Options.    (line  789)
+* Wno-suggest-attribute=pure:            Warning Options.    (line  789)
+* Wno-switch:                            Warning Options.    (line  516)
+* Wno-switch-default:                    Warning Options.    (line  524)
+* Wno-switch-enum:                       Warning Options.    (line  527)
+* Wno-sync-nand:                         Warning Options.    (line  536)
+* Wno-system-headers:                    Warning Options.    (line  834)
+* Wno-traditional:                       Warning Options.    (line  871)
+* Wno-traditional-conversion:            Warning Options.    (line  948)
+* Wno-trampolines:                       Warning Options.    (line  845)
+* Wno-trigraphs:                         Warning Options.    (line  541)
+* Wno-type-limits:                       Warning Options.    (line 1032)
+* Wno-undeclared-selector:               Objective-C and Objective-C++ Dialect Options.
+                                                             (line  191)
+* Wno-undef:                             Warning Options.    (line  963)
+* Wno-uninitialized:                     Warning Options.    (line  618)
+* Wno-unknown-pragmas:                   Warning Options.    (line  683)
+* Wno-unsafe-loop-optimizations:         Warning Options.    (line 1013)
+* Wno-unused:                            Warning Options.    (line  611)
+* Wno-unused-but-set-parameter:          Warning Options.    (line  546)
+* Wno-unused-but-set-variable:           Warning Options.    (line  555)
+* Wno-unused-function:                   Warning Options.    (line  565)
+* Wno-unused-label:                      Warning Options.    (line  570)
+* Wno-unused-parameter:                  Warning Options.    (line  581)
+* Wno-unused-result:                     Warning Options.    (line  588)
+* Wno-unused-value:                      Warning Options.    (line  601)
+* Wno-unused-variable:                   Warning Options.    (line  593)
+* Wno-useless-cast:                      Warning Options.    (line 1131)
+* Wno-varargs:                           Warning Options.    (line 1461)
+* Wno-variadic-macros:                   Warning Options.    (line 1455)
+* Wno-vector-operation-performance:      Warning Options.    (line 1466)
+* Wno-virtual-move-assign:               Warning Options.    (line 1476)
+* Wno-vla:                               Warning Options.    (line 1485)
+* Wno-volatile-register-var:             Warning Options.    (line 1489)
+* Wno-write-strings:                     Warning Options.    (line 1076)
+* Wno-zero-as-null-pointer-constant:     Warning Options.    (line 1118)
+* Wnoexcept:                             C++ Dialect Options.
+                                                             (line  559)
+* Wnon-template-friend:                  C++ Dialect Options.
+                                                             (line  633)
+* Wnon-virtual-dtor:                     C++ Dialect Options.
+                                                             (line  565)
+* Wnonnull:                              Warning Options.    (line  335)
+* Wnormalized=:                          Warning Options.    (line 1289)
+* Wold-style-cast:                       C++ Dialect Options.
+                                                             (line  649)
+* Wold-style-declaration:                Warning Options.    (line 1227)
+* Wold-style-definition:                 Warning Options.    (line 1233)
+* Wopenm-simd:                           Warning Options.    (line 1344)
+* Woverflow:                             Warning Options.    (line 1341)
+* Woverlength-strings:                   Warning Options.    (line 1515)
+* Woverloaded-virtual:                   C++ Dialect Options.
+                                                             (line  655)
+* Woverride-init:                        Warning Options.    (line 1349)
+* Wp:                                    Preprocessor Options.
+                                                             (line   14)
+* Wpacked:                               Warning Options.    (line 1357)
+* Wpacked-bitfield-compat:               Warning Options.    (line 1374)
+* Wpadded:                               Warning Options.    (line 1391)
+* Wparentheses:                          Warning Options.    (line  403)
+* Wpedantic:                             Warning Options.    (line   71)
+* Wpedantic-ms-format:                   Warning Options.    (line 1019)
+* Wpmf-conversions:                      C++ Dialect Options.
+                                                             (line  674)
+* Wpointer-arith:                        Warning Options.    (line 1025)
+* Wpointer-arith <1>:                    Pointer Arith.      (line   13)
+* Wpointer-sign:                         Warning Options.    (line 1504)
+* Wpointer-to-int-cast:                  Warning Options.    (line 1442)
+* Wpragmas:                              Warning Options.    (line  690)
+* Wprotocol:                             Objective-C and Objective-C++ Dialect Options.
+                                                             (line  161)
+* wrapper:                               Overall Options.    (line  341)
+* Wredundant-decls:                      Warning Options.    (line 1398)
+* Wreorder:                              C++ Dialect Options.
+                                                             (line  573)
+* Wreturn-local-addr:                    Warning Options.    (line  498)
+* Wreturn-type:                          Warning Options.    (line  502)
+* Wselector:                             Objective-C and Objective-C++ Dialect Options.
+                                                             (line  171)
+* Wsequence-point:                       Warning Options.    (line  452)
+* Wshadow:                               Warning Options.    (line  970)
+* Wsign-compare:                         Warning Options.    (line 1155)
+* Wsign-conversion:                      Warning Options.    (line 1162)
+* Wsign-promo:                           C++ Dialect Options.
+                                                             (line  678)
+* Wsizeof-pointer-memaccess:             Warning Options.    (line 1174)
+* Wstack-protector:                      Warning Options.    (line 1510)
+* Wstack-usage:                          Warning Options.    (line  993)
+* Wstrict-aliasing:                      Warning Options.    (line  695)
+* Wstrict-aliasing=n:                    Warning Options.    (line  702)
+* Wstrict-null-sentinel:                 C++ Dialect Options.
+                                                             (line  626)
+* Wstrict-overflow:                      Warning Options.    (line  734)
+* Wstrict-prototypes:                    Warning Options.    (line 1221)
+* Wstrict-selector-match:                Objective-C and Objective-C++ Dialect Options.
+                                                             (line  183)
+* Wsuggest-attribute=:                   Warning Options.    (line  783)
+* Wsuggest-attribute=const:              Warning Options.    (line  789)
+* Wsuggest-attribute=format:             Warning Options.    (line  803)
+* Wsuggest-attribute=noreturn:           Warning Options.    (line  789)
+* Wsuggest-attribute=pure:               Warning Options.    (line  789)
+* Wswitch:                               Warning Options.    (line  516)
+* Wswitch-default:                       Warning Options.    (line  524)
+* Wswitch-enum:                          Warning Options.    (line  527)
+* Wsync-nand:                            Warning Options.    (line  536)
+* Wsystem-headers:                       Warning Options.    (line  834)
+* Wsystem-headers <1>:                   Preprocessor Options.
+                                                             (line  165)
+* Wtraditional:                          Warning Options.    (line  871)
+* Wtraditional <1>:                      Preprocessor Options.
+                                                             (line  118)
+* Wtraditional-conversion:               Warning Options.    (line  948)
+* Wtrampolines:                          Warning Options.    (line  845)
+* Wtrigraphs:                            Warning Options.    (line  541)
+* Wtrigraphs <1>:                        Preprocessor Options.
+                                                             (line  106)
+* Wtype-limits:                          Warning Options.    (line 1032)
+* Wundeclared-selector:                  Objective-C and Objective-C++ Dialect Options.
+                                                             (line  191)
+* Wundef:                                Warning Options.    (line  963)
+* Wundef <1>:                            Preprocessor Options.
+                                                             (line  124)
+* Wuninitialized:                        Warning Options.    (line  618)
+* Wunknown-pragmas:                      Warning Options.    (line  683)
+* Wunsafe-loop-optimizations:            Warning Options.    (line 1013)
+* Wunsuffixed-float-constants:           Warning Options.    (line 1530)
+* Wunused:                               Warning Options.    (line  611)
+* Wunused-but-set-parameter:             Warning Options.    (line  546)
+* Wunused-but-set-variable:              Warning Options.    (line  555)
+* Wunused-function:                      Warning Options.    (line  565)
+* Wunused-label:                         Warning Options.    (line  570)
+* Wunused-local-typedefs:                Warning Options.    (line  577)
+* Wunused-macros:                        Preprocessor Options.
+                                                             (line  129)
+* Wunused-parameter:                     Warning Options.    (line  581)
+* Wunused-result:                        Warning Options.    (line  588)
+* Wunused-value:                         Warning Options.    (line  601)
+* Wunused-variable:                      Warning Options.    (line  593)
+* Wuseless-cast:                         Warning Options.    (line 1131)
+* Wvarargs:                              Warning Options.    (line 1461)
+* Wvariadic-macros:                      Warning Options.    (line 1455)
+* Wvector-operation-performance:         Warning Options.    (line 1466)
+* Wvirtual-move-assign:                  Warning Options.    (line 1476)
+* Wvla:                                  Warning Options.    (line 1485)
+* Wvolatile-register-var:                Warning Options.    (line 1489)
+* Wwrite-strings:                        Warning Options.    (line 1076)
+* Wzero-as-null-pointer-constant:        Warning Options.    (line 1118)
+* x:                                     Overall Options.    (line  126)
+* x <1>:                                 Preprocessor Options.
+                                                             (line  324)
+* Xassembler:                            Assembler Options.  (line   13)
+* Xbind-lazy:                            VxWorks Options.    (line   26)
+* Xbind-now:                             VxWorks Options.    (line   30)
+* Xlinker:                               Link Options.       (line  219)
+* Xpreprocessor:                         Preprocessor Options.
+                                                             (line   25)
+* Ym:                                    System V Options.   (line   26)
+* YP:                                    System V Options.   (line   22)
+
+
+File: gcc.info,  Node: Keyword Index,  Prev: Option Index,  Up: Top
+
+Keyword Index
+*************
+
+
+* Menu:
+
+* '!' in constraint:                     Multi-Alternative.  (line   33)
+* '#' in constraint:                     Modifiers.          (line   57)
+* '#pragma':                             Pragmas.            (line    6)
+* #pragma implementation:                C++ Interface.      (line   39)
+* '#pragma implementation', implied:     C++ Interface.      (line   46)
+* #pragma interface:                     C++ Interface.      (line   20)
+* '#pragma', reason for not using:       Function Attributes.
+                                                             (line 2055)
+* $:                                     Dollar Signs.       (line    6)
+* '%' in constraint:                     Modifiers.          (line   45)
+* '%include':                            Spec Files.         (line   26)
+* '%include_noerr':                      Spec Files.         (line   30)
+* '%rename':                             Spec Files.         (line   34)
+* '&' in constraint:                     Modifiers.          (line   25)
+* ''':                                   Incompatibilities.  (line  116)
+* '*' in constraint:                     Modifiers.          (line   62)
+* *__builtin_assume_aligned:             Other Builtins.     (line  332)
+* '+' in constraint:                     Modifiers.          (line   12)
+* '-lgcc', use with '-nodefaultlibs':    Link Options.       (line   85)
+* '-lgcc', use with '-nostdlib':         Link Options.       (line   85)
+* '-march' feature modifiers:            AArch64 Options.    (line  119)
+* '-mcpu' feature modifiers:             AArch64 Options.    (line  119)
+* '-nodefaultlibs' and unresolved references: Link Options.  (line   85)
+* '-nostdlib' and unresolved references: Link Options.       (line   85)
+* .sdata/.sdata2 references (PowerPC):   RS/6000 and PowerPC Options.
+                                                             (line  739)
+* '//':                                  C++ Comments.       (line    6)
+* '0' in constraint:                     Simple Constraints. (line  125)
+* '<' in constraint:                     Simple Constraints. (line   47)
+* '=' in constraint:                     Modifiers.          (line    8)
+* '>' in constraint:                     Simple Constraints. (line   59)
+* '?' in constraint:                     Multi-Alternative.  (line   27)
+* '?:' extensions:                       Conditionals.       (line    6)
+* '?:' side effect:                      Conditionals.       (line   20)
+* '_' in variables in macros:            Typeof.             (line   46)
+* '_Accum' data type:                    Fixed-Point.        (line    6)
+* '_Complex' keyword:                    Complex.            (line    6)
+* '_Decimal128' data type:               Decimal Float.      (line    6)
+* '_Decimal32' data type:                Decimal Float.      (line    6)
+* '_Decimal64' data type:                Decimal Float.      (line    6)
+* _Exit:                                 Other Builtins.     (line    6)
+* _exit:                                 Other Builtins.     (line    6)
+* '_Fract' data type:                    Fixed-Point.        (line    6)
+* _HTM_FIRST_USER_ABORT_CODE:            S/390 System z Built-in Functions.
+                                                             (line   44)
+* '_Sat' data type:                      Fixed-Point.        (line    6)
+* _xabort:                               X86 transactional memory intrinsics.
+                                                             (line   61)
+* _xbegin:                               X86 transactional memory intrinsics.
+                                                             (line   19)
+* _xend:                                 X86 transactional memory intrinsics.
+                                                             (line   52)
+* _xtest:                                X86 transactional memory intrinsics.
+                                                             (line   57)
+* __atomic_add_fetch:                    __atomic Builtins.  (line  153)
+* __atomic_always_lock_free:             __atomic Builtins.  (line  230)
+* __atomic_and_fetch:                    __atomic Builtins.  (line  157)
+* __atomic_clear:                        __atomic Builtins.  (line  204)
+* __atomic_compare_exchange:             __atomic Builtins.  (line  145)
+* __atomic_compare_exchange_n:           __atomic Builtins.  (line  124)
+* __atomic_exchange:                     __atomic Builtins.  (line  118)
+* __atomic_exchange_n:                   __atomic Builtins.  (line  108)
+* __atomic_fetch_add:                    __atomic Builtins.  (line  172)
+* __atomic_fetch_and:                    __atomic Builtins.  (line  176)
+* __atomic_fetch_nand:                   __atomic Builtins.  (line  182)
+* __atomic_fetch_or:                     __atomic Builtins.  (line  180)
+* __atomic_fetch_sub:                    __atomic Builtins.  (line  174)
+* __atomic_fetch_xor:                    __atomic Builtins.  (line  178)
+* __atomic_is_lock_free:                 __atomic Builtins.  (line  244)
+* __atomic_load:                         __atomic Builtins.  (line   90)
+* __atomic_load_n:                       __atomic Builtins.  (line   83)
+* __atomic_nand_fetch:                   __atomic Builtins.  (line  163)
+* __atomic_or_fetch:                     __atomic Builtins.  (line  161)
+* __atomic_signal_fence:                 __atomic Builtins.  (line  223)
+* __atomic_store:                        __atomic Builtins.  (line  103)
+* __atomic_store_n:                      __atomic Builtins.  (line   95)
+* __atomic_sub_fetch:                    __atomic Builtins.  (line  155)
+* __atomic_test_and_set:                 __atomic Builtins.  (line  192)
+* __atomic_thread_fence:                 __atomic Builtins.  (line  216)
+* __atomic_xor_fetch:                    __atomic Builtins.  (line  159)
+* __builtin_apply:                       Constructing Calls. (line   29)
+* __builtin_apply_args:                  Constructing Calls. (line   19)
+* __builtin_arc_aligned:                 ARC Built-in Functions.
+                                                             (line   18)
+* __builtin_arc_brk:                     ARC Built-in Functions.
+                                                             (line   28)
+* __builtin_arc_core_read:               ARC Built-in Functions.
+                                                             (line   32)
+* __builtin_arc_core_write:              ARC Built-in Functions.
+                                                             (line   39)
+* __builtin_arc_divaw:                   ARC Built-in Functions.
+                                                             (line   46)
+* __builtin_arc_flag:                    ARC Built-in Functions.
+                                                             (line   53)
+* __builtin_arc_lr:                      ARC Built-in Functions.
+                                                             (line   57)
+* __builtin_arc_mul64:                   ARC Built-in Functions.
+                                                             (line   64)
+* __builtin_arc_mulu64:                  ARC Built-in Functions.
+                                                             (line   68)
+* __builtin_arc_nop:                     ARC Built-in Functions.
+                                                             (line   73)
+* __builtin_arc_norm:                    ARC Built-in Functions.
+                                                             (line   77)
+* __builtin_arc_normw:                   ARC Built-in Functions.
+                                                             (line   84)
+* __builtin_arc_rtie:                    ARC Built-in Functions.
+                                                             (line   91)
+* __builtin_arc_sleep:                   ARC Built-in Functions.
+                                                             (line   95)
+* __builtin_arc_sr:                      ARC Built-in Functions.
+                                                             (line   99)
+* __builtin_arc_swap:                    ARC Built-in Functions.
+                                                             (line  106)
+* __builtin_arc_swi:                     ARC Built-in Functions.
+                                                             (line  112)
+* __builtin_arc_sync:                    ARC Built-in Functions.
+                                                             (line  116)
+* __builtin_arc_trap_s:                  ARC Built-in Functions.
+                                                             (line  120)
+* __builtin_arc_unimp_s:                 ARC Built-in Functions.
+                                                             (line  124)
+* __builtin_bswap16:                     Other Builtins.     (line  599)
+* __builtin_bswap32:                     Other Builtins.     (line  603)
+* __builtin_bswap64:                     Other Builtins.     (line  607)
+* __builtin_choose_expr:                 Other Builtins.     (line  154)
+* __builtin_clrsb:                       Other Builtins.     (line  529)
+* __builtin_clrsbl:                      Other Builtins.     (line  551)
+* __builtin_clrsbll:                     Other Builtins.     (line  574)
+* __builtin_clz:                         Other Builtins.     (line  521)
+* __builtin_clzl:                        Other Builtins.     (line  543)
+* __builtin_clzll:                       Other Builtins.     (line  566)
+* __builtin_complex:                     Other Builtins.     (line  194)
+* __builtin_constant_p:                  Other Builtins.     (line  203)
+* __builtin_cpu_init:                    X86 Built-in Functions.
+                                                             (line   62)
+* __builtin_cpu_is:                      X86 Built-in Functions.
+                                                             (line   90)
+* __builtin_cpu_supports:                X86 Built-in Functions.
+                                                             (line  162)
+* __builtin_ctz:                         Other Builtins.     (line  525)
+* __builtin_ctzl:                        Other Builtins.     (line  547)
+* __builtin_ctzll:                       Other Builtins.     (line  570)
+* __builtin_expect:                      Other Builtins.     (line  252)
+* __builtin_extract_return_addr:         Return Address.     (line   35)
+* __builtin_ffs:                         Other Builtins.     (line  517)
+* __builtin_ffsl:                        Other Builtins.     (line  540)
+* __builtin_ffsll:                       Other Builtins.     (line  562)
+* __builtin_FILE:                        Other Builtins.     (line  361)
+* __builtin_fpclassify:                  Other Builtins.     (line    6)
+* __builtin_fpclassify <1>:              Other Builtins.     (line  431)
+* __builtin_frame_address:               Return Address.     (line   47)
+* __builtin_frob_return_address:         Return Address.     (line   44)
+* __builtin_FUNCTION:                    Other Builtins.     (line  356)
+* __builtin_huge_val:                    Other Builtins.     (line  419)
+* __builtin_huge_valf:                   Other Builtins.     (line  424)
+* __builtin_huge_vall:                   Other Builtins.     (line  427)
+* __builtin_huge_valq:                   X86 Built-in Functions.
+                                                             (line   57)
+* __builtin_inf:                         Other Builtins.     (line  442)
+* __builtin_infd128:                     Other Builtins.     (line  452)
+* __builtin_infd32:                      Other Builtins.     (line  446)
+* __builtin_infd64:                      Other Builtins.     (line  449)
+* __builtin_inff:                        Other Builtins.     (line  456)
+* __builtin_infl:                        Other Builtins.     (line  461)
+* __builtin_infq:                        X86 Built-in Functions.
+                                                             (line   54)
+* __builtin_isfinite:                    Other Builtins.     (line    6)
+* __builtin_isgreater:                   Other Builtins.     (line    6)
+* __builtin_isgreaterequal:              Other Builtins.     (line    6)
+* __builtin_isinf_sign:                  Other Builtins.     (line    6)
+* __builtin_isinf_sign <1>:              Other Builtins.     (line  465)
+* __builtin_isless:                      Other Builtins.     (line    6)
+* __builtin_islessequal:                 Other Builtins.     (line    6)
+* __builtin_islessgreater:               Other Builtins.     (line    6)
+* __builtin_isnormal:                    Other Builtins.     (line    6)
+* __builtin_isunordered:                 Other Builtins.     (line    6)
+* __builtin_LINE:                        Other Builtins.     (line  350)
+* __builtin_nan:                         Other Builtins.     (line  473)
+* __builtin_nand128:                     Other Builtins.     (line  495)
+* __builtin_nand32:                      Other Builtins.     (line  489)
+* __builtin_nand64:                      Other Builtins.     (line  492)
+* __builtin_nanf:                        Other Builtins.     (line  499)
+* __builtin_nanl:                        Other Builtins.     (line  502)
+* __builtin_nans:                        Other Builtins.     (line  506)
+* __builtin_nansf:                       Other Builtins.     (line  510)
+* __builtin_nansl:                       Other Builtins.     (line  513)
+* __builtin_nds32_isb:                   NDS32 Built-in Functions.
+                                                             (line   12)
+* __builtin_nds32_isync:                 NDS32 Built-in Functions.
+                                                             (line    8)
+* __builtin_nds32_mfsr:                  NDS32 Built-in Functions.
+                                                             (line   15)
+* __builtin_nds32_mfusr:                 NDS32 Built-in Functions.
+                                                             (line   18)
+* __builtin_nds32_mtsr:                  NDS32 Built-in Functions.
+                                                             (line   21)
+* __builtin_nds32_mtusr:                 NDS32 Built-in Functions.
+                                                             (line   24)
+* __builtin_nds32_setgie_dis:            NDS32 Built-in Functions.
+                                                             (line   30)
+* __builtin_nds32_setgie_en:             NDS32 Built-in Functions.
+                                                             (line   27)
+* __builtin_non_tx_store:                S/390 System z Built-in Functions.
+                                                             (line   98)
+* __builtin_object_size:                 Object Size Checking.
+                                                             (line    6)
+* __builtin_object_size <1>:             Object Size Checking.
+                                                             (line    9)
+* __builtin_offsetof:                    Offsetof.           (line    6)
+* __builtin_parity:                      Other Builtins.     (line  537)
+* __builtin_parityl:                     Other Builtins.     (line  558)
+* __builtin_parityll:                    Other Builtins.     (line  582)
+* __builtin_popcount:                    Other Builtins.     (line  534)
+* __builtin_popcountl:                   Other Builtins.     (line  554)
+* __builtin_popcountll:                  Other Builtins.     (line  578)
+* __builtin_powi:                        Other Builtins.     (line    6)
+* __builtin_powi <1>:                    Other Builtins.     (line  586)
+* __builtin_powif:                       Other Builtins.     (line    6)
+* __builtin_powif <1>:                   Other Builtins.     (line  591)
+* __builtin_powil:                       Other Builtins.     (line    6)
+* __builtin_powil <1>:                   Other Builtins.     (line  595)
+* __builtin_prefetch:                    Other Builtins.     (line  380)
+* __builtin_return:                      Constructing Calls. (line   47)
+* __builtin_return_address:              Return Address.     (line    9)
+* __builtin_rx_brk:                      RX Built-in Functions.
+                                                             (line   10)
+* __builtin_rx_clrpsw:                   RX Built-in Functions.
+                                                             (line   13)
+* __builtin_rx_int:                      RX Built-in Functions.
+                                                             (line   17)
+* __builtin_rx_machi:                    RX Built-in Functions.
+                                                             (line   21)
+* __builtin_rx_maclo:                    RX Built-in Functions.
+                                                             (line   26)
+* __builtin_rx_mulhi:                    RX Built-in Functions.
+                                                             (line   31)
+* __builtin_rx_mullo:                    RX Built-in Functions.
+                                                             (line   36)
+* __builtin_rx_mvfachi:                  RX Built-in Functions.
+                                                             (line   41)
+* __builtin_rx_mvfacmi:                  RX Built-in Functions.
+                                                             (line   45)
+* __builtin_rx_mvfc:                     RX Built-in Functions.
+                                                             (line   49)
+* __builtin_rx_mvtachi:                  RX Built-in Functions.
+                                                             (line   53)
+* __builtin_rx_mvtaclo:                  RX Built-in Functions.
+                                                             (line   57)
+* __builtin_rx_mvtc:                     RX Built-in Functions.
+                                                             (line   61)
+* __builtin_rx_mvtipl:                   RX Built-in Functions.
+                                                             (line   65)
+* __builtin_rx_racw:                     RX Built-in Functions.
+                                                             (line   69)
+* __builtin_rx_revw:                     RX Built-in Functions.
+                                                             (line   73)
+* __builtin_rx_rmpa:                     RX Built-in Functions.
+                                                             (line   78)
+* __builtin_rx_round:                    RX Built-in Functions.
+                                                             (line   82)
+* __builtin_rx_sat:                      RX Built-in Functions.
+                                                             (line   87)
+* __builtin_rx_setpsw:                   RX Built-in Functions.
+                                                             (line   91)
+* __builtin_rx_wait:                     RX Built-in Functions.
+                                                             (line   95)
+* __builtin_set_thread_pointer:          SH Built-in Functions.
+                                                             (line    9)
+* __builtin_tabort:                      S/390 System z Built-in Functions.
+                                                             (line   82)
+* __builtin_tbegin:                      S/390 System z Built-in Functions.
+                                                             (line    6)
+* __builtin_tbeginc:                     S/390 System z Built-in Functions.
+                                                             (line   73)
+* __builtin_tbegin_nofloat:              S/390 System z Built-in Functions.
+                                                             (line   54)
+* __builtin_tbegin_retry:                S/390 System z Built-in Functions.
+                                                             (line   60)
+* __builtin_tbegin_retry_nofloat:        S/390 System z Built-in Functions.
+                                                             (line   67)
+* __builtin_tend:                        S/390 System z Built-in Functions.
+                                                             (line   77)
+* __builtin_thread_pointer:              SH Built-in Functions.
+                                                             (line   18)
+* __builtin_trap:                        Other Builtins.     (line  276)
+* __builtin_tx_assist:                   S/390 System z Built-in Functions.
+                                                             (line   87)
+* __builtin_tx_nesting_depth:            S/390 System z Built-in Functions.
+                                                             (line   93)
+* __builtin_types_compatible_p:          Other Builtins.     (line  109)
+* __builtin_unreachable:                 Other Builtins.     (line  283)
+* __builtin_va_arg_pack:                 Constructing Calls. (line   52)
+* __builtin_va_arg_pack_len:             Constructing Calls. (line   75)
+* __builtin___clear_cache:               Other Builtins.     (line  367)
+* __builtin___fprintf_chk:               Object Size Checking.
+                                                             (line    6)
+* __builtin___memcpy_chk:                Object Size Checking.
+                                                             (line    6)
+* __builtin___memmove_chk:               Object Size Checking.
+                                                             (line    6)
+* __builtin___mempcpy_chk:               Object Size Checking.
+                                                             (line    6)
+* __builtin___memset_chk:                Object Size Checking.
+                                                             (line    6)
+* __builtin___printf_chk:                Object Size Checking.
+                                                             (line    6)
+* __builtin___snprintf_chk:              Object Size Checking.
+                                                             (line    6)
+* __builtin___sprintf_chk:               Object Size Checking.
+                                                             (line    6)
+* __builtin___stpcpy_chk:                Object Size Checking.
+                                                             (line    6)
+* __builtin___strcat_chk:                Object Size Checking.
+                                                             (line    6)
+* __builtin___strcpy_chk:                Object Size Checking.
+                                                             (line    6)
+* __builtin___strncat_chk:               Object Size Checking.
+                                                             (line    6)
+* __builtin___strncpy_chk:               Object Size Checking.
+                                                             (line    6)
+* __builtin___vfprintf_chk:              Object Size Checking.
+                                                             (line    6)
+* __builtin___vprintf_chk:               Object Size Checking.
+                                                             (line    6)
+* __builtin___vsnprintf_chk:             Object Size Checking.
+                                                             (line    6)
+* __builtin___vsprintf_chk:              Object Size Checking.
+                                                             (line    6)
+* '__complex__' keyword:                 Complex.            (line    6)
+* '__declspec(dllexport)':               Function Attributes.
+                                                             (line  290)
+* '__declspec(dllimport)':               Function Attributes.
+                                                             (line  323)
+* '__ea' SPU Named Address Spaces:       Named Address Spaces.
+                                                             (line  155)
+* __extension__:                         Alternate Keywords. (line   30)
+* '__far' M32C Named Address Spaces:     Named Address Spaces.
+                                                             (line  138)
+* '__far' RL78 Named Address Spaces:     Named Address Spaces.
+                                                             (line  147)
+* '__flash' AVR Named Address Spaces:    Named Address Spaces.
+                                                             (line   31)
+* '__flash1' AVR Named Address Spaces:   Named Address Spaces.
+                                                             (line   40)
+* '__flash2' AVR Named Address Spaces:   Named Address Spaces.
+                                                             (line   40)
+* '__flash3' AVR Named Address Spaces:   Named Address Spaces.
+                                                             (line   40)
+* '__flash4' AVR Named Address Spaces:   Named Address Spaces.
+                                                             (line   40)
+* '__flash5' AVR Named Address Spaces:   Named Address Spaces.
+                                                             (line   40)
+* '__float128' data type:                Floating Types.     (line    6)
+* '__float80' data type:                 Floating Types.     (line    6)
+* '__fp16' data type:                    Half-Precision.     (line    6)
+* '__FUNCTION__' identifier:             Function Names.     (line    6)
+* '__func__' identifier:                 Function Names.     (line    6)
+* '__imag__' keyword:                    Complex.            (line   27)
+* '__int128' data types:                 __int128.           (line    6)
+* '__memx' AVR Named Address Spaces:     Named Address Spaces.
+                                                             (line   46)
+* '__PRETTY_FUNCTION__' identifier:      Function Names.     (line    6)
+* '__real__' keyword:                    Complex.            (line   27)
+* __STDC_HOSTED__:                       Standards.          (line   13)
+* __sync_add_and_fetch:                  __sync Builtins.    (line   60)
+* __sync_and_and_fetch:                  __sync Builtins.    (line   60)
+* __sync_bool_compare_and_swap:          __sync Builtins.    (line   71)
+* __sync_fetch_and_add:                  __sync Builtins.    (line   44)
+* __sync_fetch_and_and:                  __sync Builtins.    (line   44)
+* __sync_fetch_and_nand:                 __sync Builtins.    (line   44)
+* __sync_fetch_and_or:                   __sync Builtins.    (line   44)
+* __sync_fetch_and_sub:                  __sync Builtins.    (line   44)
+* __sync_fetch_and_xor:                  __sync Builtins.    (line   44)
+* __sync_lock_release:                   __sync Builtins.    (line  101)
+* __sync_lock_test_and_set:              __sync Builtins.    (line   83)
+* __sync_nand_and_fetch:                 __sync Builtins.    (line   60)
+* __sync_or_and_fetch:                   __sync Builtins.    (line   60)
+* __sync_sub_and_fetch:                  __sync Builtins.    (line   60)
+* __sync_synchronize:                    __sync Builtins.    (line   80)
+* __sync_val_compare_and_swap:           __sync Builtins.    (line   71)
+* __sync_xor_and_fetch:                  __sync Builtins.    (line   60)
+* '__thread':                            Thread-Local.       (line    6)
+* AArch64 Options:                       AArch64 Options.    (line    6)
+* ABI:                                   Compatibility.      (line    6)
+* 'abi_tag' attribute:                   C++ Attributes.     (line    9)
+* abort:                                 Other Builtins.     (line    6)
+* abs:                                   Other Builtins.     (line    6)
+* accessing volatiles:                   Volatiles.          (line    6)
+* accessing volatiles <1>:               C++ Volatiles.      (line    6)
+* acos:                                  Other Builtins.     (line    6)
+* acosf:                                 Other Builtins.     (line    6)
+* acosh:                                 Other Builtins.     (line    6)
+* acoshf:                                Other Builtins.     (line    6)
+* acoshl:                                Other Builtins.     (line    6)
+* acosl:                                 Other Builtins.     (line    6)
+* Ada:                                   G++ and GCC.        (line    6)
+* Ada <1>:                               G++ and GCC.        (line   30)
+* additional floating types:             Floating Types.     (line    6)
+* address constraints:                   Simple Constraints. (line  152)
+* address of a label:                    Labels as Values.   (line    6)
+* address_operand:                       Simple Constraints. (line  156)
+* 'alias' attribute:                     Function Attributes.
+                                                             (line   39)
+* 'aligned' attribute:                   Function Attributes.
+                                                             (line   52)
+* 'aligned' attribute <1>:               Variable Attributes.
+                                                             (line   23)
+* 'aligned' attribute <2>:               Type Attributes.    (line   31)
+* alignment:                             Alignment.          (line    6)
+* alloca:                                Other Builtins.     (line    6)
+* 'alloca' vs variable-length arrays:    Variable Length.    (line   35)
+* 'alloc_align' attribute:               Function Attributes.
+                                                             (line   93)
+* 'alloc_size' attribute:                Function Attributes.
+                                                             (line   72)
+* Allow nesting in an interrupt handler on the Blackfin processor.: Function Attributes.
+                                                             (line 1068)
+* Altera Nios II options:                Nios II Options.    (line    6)
+* alternate keywords:                    Alternate Keywords. (line    6)
+* 'always_inline' function attribute:    Function Attributes.
+                                                             (line  125)
+* AMD x86-64 Options:                    i386 and x86-64 Options.
+                                                             (line    6)
+* AMD1:                                  Standards.          (line   13)
+* ANSI C:                                Standards.          (line   13)
+* ANSI C standard:                       Standards.          (line   13)
+* ANSI C89:                              Standards.          (line   13)
+* ANSI support:                          C Dialect Options.  (line   10)
+* ANSI X3.159-1989:                      Standards.          (line   13)
+* apostrophes:                           Incompatibilities.  (line  116)
+* application binary interface:          Compatibility.      (line    6)
+* ARC options:                           ARC Options.        (line    6)
+* ARM options:                           ARM Options.        (line    6)
+* ARM [Annotated C++ Reference Manual]:  Backwards Compatibility.
+                                                             (line    6)
+* arrays of length zero:                 Zero Length.        (line    6)
+* arrays of variable length:             Variable Length.    (line    6)
+* arrays, non-lvalue:                    Subscripting.       (line    6)
+* 'artificial' function attribute:       Function Attributes.
+                                                             (line  166)
+* asin:                                  Other Builtins.     (line    6)
+* asinf:                                 Other Builtins.     (line    6)
+* asinh:                                 Other Builtins.     (line    6)
+* asinhf:                                Other Builtins.     (line    6)
+* asinhl:                                Other Builtins.     (line    6)
+* asinl:                                 Other Builtins.     (line    6)
+* 'asm' constraints:                     Constraints.        (line    6)
+* 'asm' expressions:                     Extended Asm.       (line    6)
+* assembler instructions:                Extended Asm.       (line    6)
+* assembler names for identifiers:       Asm Labels.         (line    6)
+* assembly code, invalid:                Bug Criteria.       (line   12)
+* 'assume_aligned' attribute:            Function Attributes.
+                                                             (line  110)
+* atan:                                  Other Builtins.     (line    6)
+* atan2:                                 Other Builtins.     (line    6)
+* atan2f:                                Other Builtins.     (line    6)
+* atan2l:                                Other Builtins.     (line    6)
+* atanf:                                 Other Builtins.     (line    6)
+* atanh:                                 Other Builtins.     (line    6)
+* atanhf:                                Other Builtins.     (line    6)
+* atanhl:                                Other Builtins.     (line    6)
+* atanl:                                 Other Builtins.     (line    6)
+* attribute of types:                    Type Attributes.    (line    6)
+* attribute of variables:                Variable Attributes.
+                                                             (line    6)
+* attribute syntax:                      Attribute Syntax.   (line    6)
+* autoincrement/decrement addressing:    Simple Constraints. (line   30)
+* automatic 'inline' for C++ member fns: Inline.             (line   71)
+* AVR Options:                           AVR Options.        (line    6)
+* Backwards Compatibility:               Backwards Compatibility.
+                                                             (line    6)
+* base class members:                    Name lookup.        (line    6)
+* bcmp:                                  Other Builtins.     (line    6)
+* 'below100' attribute:                  Variable Attributes.
+                                                             (line  578)
+* binary compatibility:                  Compatibility.      (line    6)
+* Binary constants using the '0b' prefix: Binary constants.  (line    6)
+* Blackfin Options:                      Blackfin Options.   (line    6)
+* bound pointer to member function:      Bound member functions.
+                                                             (line    6)
+* bug criteria:                          Bug Criteria.       (line    6)
+* bugs:                                  Bugs.               (line    6)
+* bugs, known:                           Trouble.            (line    6)
+* built-in functions:                    C Dialect Options.  (line  210)
+* built-in functions <1>:                Other Builtins.     (line    6)
+* bzero:                                 Other Builtins.     (line    6)
+* C compilation options:                 Invoking GCC.       (line   17)
+* C intermediate output, nonexistent:    G++ and GCC.        (line   35)
+* C language extensions:                 C Extensions.       (line    6)
+* C language, traditional:               C Dialect Options.  (line  331)
+* C standard:                            Standards.          (line   13)
+* C standards:                           Standards.          (line   13)
+* c++:                                   Invoking G++.       (line   14)
+* C++:                                   G++ and GCC.        (line   30)
+* C++ comments:                          C++ Comments.       (line    6)
+* C++ compilation options:               Invoking GCC.       (line   23)
+* C++ interface and implementation headers: C++ Interface.   (line    6)
+* C++ language extensions:               C++ Extensions.     (line    6)
+* C++ member fns, automatically 'inline': Inline.            (line   71)
+* C++ misunderstandings:                 C++ Misunderstandings.
+                                                             (line    6)
+* C++ options, command-line:             C++ Dialect Options.
+                                                             (line    6)
+* C++ pragmas, effect on inlining:       C++ Interface.      (line   66)
+* C++ source file suffixes:              Invoking G++.       (line    6)
+* C++ static data, declaring and defining: Static Definitions.
+                                                             (line    6)
+* C11:                                   Standards.          (line   13)
+* C1X:                                   Standards.          (line   13)
+* C6X Options:                           C6X Options.        (line    6)
+* C89:                                   Standards.          (line   13)
+* C90:                                   Standards.          (line   13)
+* C94:                                   Standards.          (line   13)
+* C95:                                   Standards.          (line   13)
+* C99:                                   Standards.          (line   13)
+* C9X:                                   Standards.          (line   13)
+* cabs:                                  Other Builtins.     (line    6)
+* cabsf:                                 Other Builtins.     (line    6)
+* cabsl:                                 Other Builtins.     (line    6)
+* cacos:                                 Other Builtins.     (line    6)
+* cacosf:                                Other Builtins.     (line    6)
+* cacosh:                                Other Builtins.     (line    6)
+* cacoshf:                               Other Builtins.     (line    6)
+* cacoshl:                               Other Builtins.     (line    6)
+* cacosl:                                Other Builtins.     (line    6)
+* 'callee_pop_aggregate_return' attribute: Function Attributes.
+                                                             (line 1016)
+* calling functions through the function vector on H8/300, M16C, M32C and SH2A processors: Function Attributes.
+                                                             (line  564)
+* calloc:                                Other Builtins.     (line    6)
+* caret GCC_COLORS capability:           Language Independent Options.
+                                                             (line   76)
+* carg:                                  Other Builtins.     (line    6)
+* cargf:                                 Other Builtins.     (line    6)
+* cargl:                                 Other Builtins.     (line    6)
+* case labels in initializers:           Designated Inits.   (line    6)
+* case ranges:                           Case Ranges.        (line    6)
+* casin:                                 Other Builtins.     (line    6)
+* casinf:                                Other Builtins.     (line    6)
+* casinh:                                Other Builtins.     (line    6)
+* casinhf:                               Other Builtins.     (line    6)
+* casinhl:                               Other Builtins.     (line    6)
+* casinl:                                Other Builtins.     (line    6)
+* cast to a union:                       Cast to Union.      (line    6)
+* catan:                                 Other Builtins.     (line    6)
+* catanf:                                Other Builtins.     (line    6)
+* catanh:                                Other Builtins.     (line    6)
+* catanhf:                               Other Builtins.     (line    6)
+* catanhl:                               Other Builtins.     (line    6)
+* catanl:                                Other Builtins.     (line    6)
+* cbrt:                                  Other Builtins.     (line    6)
+* cbrtf:                                 Other Builtins.     (line    6)
+* cbrtl:                                 Other Builtins.     (line    6)
+* ccos:                                  Other Builtins.     (line    6)
+* ccosf:                                 Other Builtins.     (line    6)
+* ccosh:                                 Other Builtins.     (line    6)
+* ccoshf:                                Other Builtins.     (line    6)
+* ccoshl:                                Other Builtins.     (line    6)
+* ccosl:                                 Other Builtins.     (line    6)
+* ceil:                                  Other Builtins.     (line    6)
+* ceilf:                                 Other Builtins.     (line    6)
+* ceill:                                 Other Builtins.     (line    6)
+* cexp:                                  Other Builtins.     (line    6)
+* cexpf:                                 Other Builtins.     (line    6)
+* cexpl:                                 Other Builtins.     (line    6)
+* character set, execution:              Preprocessor Options.
+                                                             (line  554)
+* character set, input:                  Preprocessor Options.
+                                                             (line  567)
+* character set, input normalization:    Warning Options.    (line 1289)
+* character set, wide execution:         Preprocessor Options.
+                                                             (line  559)
+* cimag:                                 Other Builtins.     (line    6)
+* cimagf:                                Other Builtins.     (line    6)
+* cimagl:                                Other Builtins.     (line    6)
+* 'cleanup' attribute:                   Variable Attributes.
+                                                             (line   89)
+* clog:                                  Other Builtins.     (line    6)
+* clogf:                                 Other Builtins.     (line    6)
+* clogl:                                 Other Builtins.     (line    6)
+* COBOL:                                 G++ and GCC.        (line   23)
+* code generation conventions:           Code Gen Options.   (line    6)
+* code, mixed with declarations:         Mixed Declarations. (line    6)
+* 'cold' function attribute:             Function Attributes.
+                                                             (line 1307)
+* 'cold' label attribute:                Function Attributes.
+                                                             (line 1325)
+* command options:                       Invoking GCC.       (line    6)
+* comments, C++ style:                   C++ Comments.       (line    6)
+* 'common' attribute:                    Variable Attributes.
+                                                             (line  104)
+* comparison of signed and unsigned values, warning: Warning Options.
+                                                             (line 1155)
+* compiler bugs, reporting:              Bug Reporting.      (line    6)
+* compiler compared to C++ preprocessor: G++ and GCC.        (line   35)
+* compiler options, C++:                 C++ Dialect Options.
+                                                             (line    6)
+* compiler options, Objective-C and Objective-C++: Objective-C and Objective-C++ Dialect Options.
+                                                             (line    6)
+* compiler version, specifying:          Target Options.     (line    6)
+* COMPILER_PATH:                         Environment Variables.
+                                                             (line   91)
+* complex conjugation:                   Complex.            (line   34)
+* complex numbers:                       Complex.            (line    6)
+* compound literals:                     Compound Literals.  (line    6)
+* computed gotos:                        Labels as Values.   (line    6)
+* conditional expressions, extensions:   Conditionals.       (line    6)
+* conflicting types:                     Disappointments.    (line   21)
+* conj:                                  Other Builtins.     (line    6)
+* conjf:                                 Other Builtins.     (line    6)
+* conjl:                                 Other Builtins.     (line    6)
+* 'const' applied to function:           Function Attributes.
+                                                             (line    6)
+* 'const' function attribute:            Function Attributes.
+                                                             (line  215)
+* constants in constraints:              Simple Constraints. (line   68)
+* constraint modifier characters:        Modifiers.          (line    6)
+* constraint, matching:                  Simple Constraints. (line  137)
+* constraints, 'asm':                    Constraints.        (line    6)
+* constraints, machine specific:         Machine Constraints.
+                                                             (line    6)
+* constructing calls:                    Constructing Calls. (line    6)
+* constructor expressions:               Compound Literals.  (line    6)
+* 'constructor' function attribute:      Function Attributes.
+                                                             (line  243)
+* contributors:                          Contributors.       (line    6)
+* copysign:                              Other Builtins.     (line    6)
+* copysignf:                             Other Builtins.     (line    6)
+* copysignl:                             Other Builtins.     (line    6)
+* core dump:                             Bug Criteria.       (line    9)
+* cos:                                   Other Builtins.     (line    6)
+* cosf:                                  Other Builtins.     (line    6)
+* cosh:                                  Other Builtins.     (line    6)
+* coshf:                                 Other Builtins.     (line    6)
+* coshl:                                 Other Builtins.     (line    6)
+* cosl:                                  Other Builtins.     (line    6)
+* CPATH:                                 Environment Variables.
+                                                             (line  127)
+* CPLUS_INCLUDE_PATH:                    Environment Variables.
+                                                             (line  129)
+* cpow:                                  Other Builtins.     (line    6)
+* cpowf:                                 Other Builtins.     (line    6)
+* cpowl:                                 Other Builtins.     (line    6)
+* cproj:                                 Other Builtins.     (line    6)
+* cprojf:                                Other Builtins.     (line    6)
+* cprojl:                                Other Builtins.     (line    6)
+* CR16 Options:                          CR16 Options.       (line    6)
+* creal:                                 Other Builtins.     (line    6)
+* crealf:                                Other Builtins.     (line    6)
+* creall:                                Other Builtins.     (line    6)
+* CRIS Options:                          CRIS Options.       (line    6)
+* 'critical' attribute:                  Function Attributes.
+                                                             (line  717)
+* cross compiling:                       Target Options.     (line    6)
+* csin:                                  Other Builtins.     (line    6)
+* csinf:                                 Other Builtins.     (line    6)
+* csinh:                                 Other Builtins.     (line    6)
+* csinhf:                                Other Builtins.     (line    6)
+* csinhl:                                Other Builtins.     (line    6)
+* csinl:                                 Other Builtins.     (line    6)
+* csqrt:                                 Other Builtins.     (line    6)
+* csqrtf:                                Other Builtins.     (line    6)
+* csqrtl:                                Other Builtins.     (line    6)
+* ctan:                                  Other Builtins.     (line    6)
+* ctanf:                                 Other Builtins.     (line    6)
+* ctanh:                                 Other Builtins.     (line    6)
+* ctanhf:                                Other Builtins.     (line    6)
+* ctanhl:                                Other Builtins.     (line    6)
+* ctanl:                                 Other Builtins.     (line    6)
+* C_INCLUDE_PATH:                        Environment Variables.
+                                                             (line  128)
+* Darwin options:                        Darwin Options.     (line    6)
+* dcgettext:                             Other Builtins.     (line    6)
+* 'dd' integer suffix:                   Decimal Float.      (line    6)
+* 'DD' integer suffix:                   Decimal Float.      (line    6)
+* deallocating variable length arrays:   Variable Length.    (line   22)
+* debugging information options:         Debugging Options.  (line    6)
+* decimal floating types:                Decimal Float.      (line    6)
+* declaration scope:                     Incompatibilities.  (line   80)
+* declarations inside expressions:       Statement Exprs.    (line    6)
+* declarations, mixed with code:         Mixed Declarations. (line    6)
+* declaring attributes of functions:     Function Attributes.
+                                                             (line    6)
+* declaring static data in C++:          Static Definitions. (line    6)
+* defining static data in C++:           Static Definitions. (line    6)
+* dependencies for make as output:       Environment Variables.
+                                                             (line  155)
+* dependencies for make as output <1>:   Environment Variables.
+                                                             (line  171)
+* dependencies, 'make':                  Preprocessor Options.
+                                                             (line  185)
+* DEPENDENCIES_OUTPUT:                   Environment Variables.
+                                                             (line  154)
+* dependent name lookup:                 Name lookup.        (line    6)
+* 'deprecated' attribute:                Variable Attributes.
+                                                             (line  113)
+* 'deprecated' attribute.:               Function Attributes.
+                                                             (line  265)
+* designated initializers:               Designated Inits.   (line    6)
+* designator lists:                      Designated Inits.   (line   96)
+* designators:                           Designated Inits.   (line   64)
+* 'destructor' function attribute:       Function Attributes.
+                                                             (line  243)
+* 'df' integer suffix:                   Decimal Float.      (line    6)
+* 'DF' integer suffix:                   Decimal Float.      (line    6)
+* dgettext:                              Other Builtins.     (line    6)
+* diagnostic messages:                   Language Independent Options.
+                                                             (line    6)
+* dialect options:                       C Dialect Options.  (line    6)
+* digits in constraint:                  Simple Constraints. (line  125)
+* directory options:                     Directory Options.  (line    6)
+* 'disinterrupt' attribute:              Function Attributes.
+                                                             (line  285)
+* 'dl' integer suffix:                   Decimal Float.      (line    6)
+* 'DL' integer suffix:                   Decimal Float.      (line    6)
+* dollar signs in identifier names:      Dollar Signs.       (line    6)
+* double-word arithmetic:                Long Long.          (line    6)
+* downward funargs:                      Nested Functions.   (line    6)
+* drem:                                  Other Builtins.     (line    6)
+* dremf:                                 Other Builtins.     (line    6)
+* dreml:                                 Other Builtins.     (line    6)
+* 'E' in constraint:                     Simple Constraints. (line   87)
+* earlyclobber operand:                  Modifiers.          (line   25)
+* eight-bit data on the H8/300, H8/300H, and H8S: Function Attributes.
+                                                             (line  375)
+* 'EIND':                                AVR Options.        (line  222)
+* empty structures:                      Empty Structures.   (line    6)
+* Enable Cilk Plus:                      C Dialect Options.  (line  276)
+* environment variables:                 Environment Variables.
+                                                             (line    6)
+* erf:                                   Other Builtins.     (line    6)
+* erfc:                                  Other Builtins.     (line    6)
+* erfcf:                                 Other Builtins.     (line    6)
+* erfcl:                                 Other Builtins.     (line    6)
+* erff:                                  Other Builtins.     (line    6)
+* erfl:                                  Other Builtins.     (line    6)
+* 'error' function attribute:            Function Attributes.
+                                                             (line  185)
+* error GCC_COLORS capability:           Language Independent Options.
+                                                             (line   67)
+* error messages:                        Warnings and Errors.
+                                                             (line    6)
+* escaped newlines:                      Escaped Newlines.   (line    6)
+* exception handler functions:           Function Attributes.
+                                                             (line  385)
+* exception handler functions on the Blackfin processor: Function Attributes.
+                                                             (line  390)
+* exclamation point:                     Multi-Alternative.  (line   33)
+* exit:                                  Other Builtins.     (line    6)
+* exp:                                   Other Builtins.     (line    6)
+* exp10:                                 Other Builtins.     (line    6)
+* exp10f:                                Other Builtins.     (line    6)
+* exp10l:                                Other Builtins.     (line    6)
+* exp2:                                  Other Builtins.     (line    6)
+* exp2f:                                 Other Builtins.     (line    6)
+* exp2l:                                 Other Builtins.     (line    6)
+* expf:                                  Other Builtins.     (line    6)
+* expl:                                  Other Builtins.     (line    6)
+* explicit register variables:           Explicit Reg Vars.  (line    6)
+* expm1:                                 Other Builtins.     (line    6)
+* expm1f:                                Other Builtins.     (line    6)
+* expm1l:                                Other Builtins.     (line    6)
+* expressions containing statements:     Statement Exprs.    (line    6)
+* expressions, constructor:              Compound Literals.  (line    6)
+* extended 'asm':                        Extended Asm.       (line    6)
+* extensible constraints:                Simple Constraints. (line  161)
+* extensions, '?:':                      Conditionals.       (line    6)
+* extensions, C language:                C Extensions.       (line    6)
+* extensions, C++ language:              C++ Extensions.     (line    6)
+* external declaration scope:            Incompatibilities.  (line   80)
+* 'externally_visible' attribute.:       Function Attributes.
+                                                             (line  396)
+* 'F' in constraint:                     Simple Constraints. (line   92)
+* fabs:                                  Other Builtins.     (line    6)
+* fabsf:                                 Other Builtins.     (line    6)
+* fabsl:                                 Other Builtins.     (line    6)
+* fatal signal:                          Bug Criteria.       (line    9)
+* fdim:                                  Other Builtins.     (line    6)
+* fdimf:                                 Other Builtins.     (line    6)
+* fdiml:                                 Other Builtins.     (line    6)
+* FDL, GNU Free Documentation License:   GNU Free Documentation License.
+                                                             (line    6)
+* ffs:                                   Other Builtins.     (line    6)
+* file name suffix:                      Overall Options.    (line   14)
+* file names:                            Link Options.       (line   10)
+* fixed-point types:                     Fixed-Point.        (line    6)
+* 'flatten' function attribute:          Function Attributes.
+                                                             (line  178)
+* flexible array members:                Zero Length.        (line    6)
+* 'float' as function value type:        Incompatibilities.  (line  141)
+* floating point precision:              Disappointments.    (line   68)
+* floating-point precision:              Optimize Options.   (line 1917)
+* floor:                                 Other Builtins.     (line    6)
+* floorf:                                Other Builtins.     (line    6)
+* floorl:                                Other Builtins.     (line    6)
+* fma:                                   Other Builtins.     (line    6)
+* fmaf:                                  Other Builtins.     (line    6)
+* fmal:                                  Other Builtins.     (line    6)
+* fmax:                                  Other Builtins.     (line    6)
+* fmaxf:                                 Other Builtins.     (line    6)
+* fmaxl:                                 Other Builtins.     (line    6)
+* fmin:                                  Other Builtins.     (line    6)
+* fminf:                                 Other Builtins.     (line    6)
+* fminl:                                 Other Builtins.     (line    6)
+* fmod:                                  Other Builtins.     (line    6)
+* fmodf:                                 Other Builtins.     (line    6)
+* fmodl:                                 Other Builtins.     (line    6)
+* 'force_align_arg_pointer' attribute:   Function Attributes.
+                                                             (line 1384)
+* 'format' function attribute:           Function Attributes.
+                                                             (line  453)
+* 'format_arg' function attribute:       Function Attributes.
+                                                             (line  518)
+* Fortran:                               G++ and GCC.        (line    6)
+* 'forwarder_section' attribute:         Function Attributes.
+                                                             (line  756)
+* forwarding calls:                      Constructing Calls. (line    6)
+* fprintf:                               Other Builtins.     (line    6)
+* fprintf_unlocked:                      Other Builtins.     (line    6)
+* fputs:                                 Other Builtins.     (line    6)
+* fputs_unlocked:                        Other Builtins.     (line    6)
+* FR30 Options:                          FR30 Options.       (line    6)
+* freestanding environment:              Standards.          (line   13)
+* freestanding implementation:           Standards.          (line   13)
+* frexp:                                 Other Builtins.     (line    6)
+* frexpf:                                Other Builtins.     (line    6)
+* frexpl:                                Other Builtins.     (line    6)
+* FRV Options:                           FRV Options.        (line    6)
+* fscanf:                                Other Builtins.     (line    6)
+* 'fscanf', and constant strings:        Incompatibilities.  (line   17)
+* function addressability on the M32R/D: Function Attributes.
+                                                             (line  974)
+* function attributes:                   Function Attributes.
+                                                             (line    6)
+* function pointers, arithmetic:         Pointer Arith.      (line    6)
+* function prototype declarations:       Function Prototypes.
+                                                             (line    6)
+* function versions:                     Function Multiversioning.
+                                                             (line    6)
+* function without a prologue/epilogue code: Function Attributes.
+                                                             (line 1046)
+* function, size of pointer to:          Pointer Arith.      (line    6)
+* functions called via pointer on the RS/6000 and PowerPC: Function Attributes.
+                                                             (line  911)
+* functions in arbitrary sections:       Function Attributes.
+                                                             (line    6)
+* functions that are dynamically resolved: Function Attributes.
+                                                             (line    6)
+* functions that are passed arguments in registers on the 386: Function Attributes.
+                                                             (line    6)
+* functions that are passed arguments in registers on the 386 <1>: Function Attributes.
+                                                             (line 1349)
+* functions that behave like malloc:     Function Attributes.
+                                                             (line    6)
+* functions that do not handle memory bank switching on 68HC11/68HC12: Function Attributes.
+                                                             (line 1058)
+* functions that do not pop the argument stack on the 386: Function Attributes.
+                                                             (line    6)
+* functions that do pop the argument stack on the 386: Function Attributes.
+                                                             (line  209)
+* functions that handle memory bank switching: Function Attributes.
+                                                             (line  409)
+* functions that have different compilation options on the 386: Function Attributes.
+                                                             (line    6)
+* functions that have different optimization options: Function Attributes.
+                                                             (line    6)
+* functions that have no side effects:   Function Attributes.
+                                                             (line    6)
+* functions that never return:           Function Attributes.
+                                                             (line    6)
+* functions that pop the argument stack on the 386: Function Attributes.
+                                                             (line    6)
+* functions that pop the argument stack on the 386 <1>: Function Attributes.
+                                                             (line  435)
+* functions that pop the argument stack on the 386 <2>: Function Attributes.
+                                                             (line  443)
+* functions that pop the argument stack on the 386 <3>: Function Attributes.
+                                                             (line 1507)
+* functions that return more than once:  Function Attributes.
+                                                             (line    6)
+* functions with non-null pointer arguments: Function Attributes.
+                                                             (line    6)
+* functions with 'printf', 'scanf', 'strftime' or 'strfmon' style arguments: Function Attributes.
+                                                             (line    6)
+* 'G' in constraint:                     Simple Constraints. (line   96)
+* 'g' in constraint:                     Simple Constraints. (line  118)
+* g++:                                   Invoking G++.       (line   14)
+* G++:                                   G++ and GCC.        (line   30)
+* gamma:                                 Other Builtins.     (line    6)
+* gammaf:                                Other Builtins.     (line    6)
+* gammaf_r:                              Other Builtins.     (line    6)
+* gammal:                                Other Builtins.     (line    6)
+* gammal_r:                              Other Builtins.     (line    6)
+* gamma_r:                               Other Builtins.     (line    6)
+* GCC:                                   G++ and GCC.        (line    6)
+* GCC command options:                   Invoking GCC.       (line    6)
+* GCC_COLORS environment variable:       Language Independent Options.
+                                                             (line   35)
+* GCC_COMPARE_DEBUG:                     Environment Variables.
+                                                             (line   52)
+* GCC_EXEC_PREFIX:                       Environment Variables.
+                                                             (line   57)
+* 'gcc_struct':                          Type Attributes.    (line  323)
+* 'gcc_struct' attribute:                Variable Attributes.
+                                                             (line  438)
+* 'gcov':                                Debugging Options.  (line  490)
+* gettext:                               Other Builtins.     (line    6)
+* global offset table:                   Code Gen Options.   (line  278)
+* global register after 'longjmp':       Global Reg Vars.    (line   65)
+* global register variables:             Global Reg Vars.    (line    6)
+* GNAT:                                  G++ and GCC.        (line   30)
+* GNU C Compiler:                        G++ and GCC.        (line    6)
+* GNU Compiler Collection:               G++ and GCC.        (line    6)
+* 'gnu_inline' function attribute:       Function Attributes.
+                                                             (line  130)
+* Go:                                    G++ and GCC.        (line    6)
+* goto with computed label:              Labels as Values.   (line    6)
+* 'gprof':                               Debugging Options.  (line  415)
+* grouping options:                      Invoking GCC.       (line   26)
+* 'H' in constraint:                     Simple Constraints. (line   96)
+* half-precision floating point:         Half-Precision.     (line    6)
+* hardware models and configurations, specifying: Submodel Options.
+                                                             (line    6)
+* hex floats:                            Hex Floats.         (line    6)
+* highlight, color, colour:              Language Independent Options.
+                                                             (line   35)
+* 'hk' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'HK' fixed-suffix:                     Fixed-Point.        (line    6)
+* hosted environment:                    Standards.          (line   13)
+* hosted environment <1>:                C Dialect Options.  (line  244)
+* hosted environment <2>:                C Dialect Options.  (line  252)
+* hosted implementation:                 Standards.          (line   13)
+* 'hot' function attribute:              Function Attributes.
+                                                             (line 1285)
+* 'hot' label attribute:                 Function Attributes.
+                                                             (line 1297)
+* 'hotpatch' attribute:                  Function Attributes.
+                                                             (line 1037)
+* HPPA Options:                          HPPA Options.       (line    6)
+* 'hr' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'HR' fixed-suffix:                     Fixed-Point.        (line    6)
+* hypot:                                 Other Builtins.     (line    6)
+* hypotf:                                Other Builtins.     (line    6)
+* hypotl:                                Other Builtins.     (line    6)
+* 'i' in constraint:                     Simple Constraints. (line   68)
+* 'I' in constraint:                     Simple Constraints. (line   79)
+* i386 and x86-64 Windows Options:       i386 and x86-64 Windows Options.
+                                                             (line    6)
+* i386 Options:                          i386 and x86-64 Options.
+                                                             (line    6)
+* IA-64 Options:                         IA-64 Options.      (line    6)
+* IBM RS/6000 and PowerPC Options:       RS/6000 and PowerPC Options.
+                                                             (line    6)
+* identifier names, dollar signs in:     Dollar Signs.       (line    6)
+* identifiers, names in assembler code:  Asm Labels.         (line    6)
+* 'ifunc' attribute:                     Function Attributes.
+                                                             (line  625)
+* ilogb:                                 Other Builtins.     (line    6)
+* ilogbf:                                Other Builtins.     (line    6)
+* ilogbl:                                Other Builtins.     (line    6)
+* imaxabs:                               Other Builtins.     (line    6)
+* implementation-defined behavior, C language: C Implementation.
+                                                             (line    6)
+* implementation-defined behavior, C++ language: C++ Implementation.
+                                                             (line    6)
+* implied '#pragma implementation':      C++ Interface.      (line   46)
+* incompatibilities of GCC:              Incompatibilities.  (line    6)
+* increment operators:                   Bug Criteria.       (line   17)
+* index:                                 Other Builtins.     (line    6)
+* indirect calls on ARC:                 Function Attributes.
+                                                             (line  888)
+* indirect calls on ARM:                 Function Attributes.
+                                                             (line  888)
+* indirect calls on Epiphany:            Function Attributes.
+                                                             (line  888)
+* indirect calls on MIPS:                Function Attributes.
+                                                             (line  923)
+* initializations in expressions:        Compound Literals.  (line    6)
+* initializers with labeled elements:    Designated Inits.   (line    6)
+* initializers, non-constant:            Initializers.       (line    6)
+* 'init_priority' attribute:             C++ Attributes.     (line   35)
+* 'inline' automatic for C++ member fns: Inline.             (line   71)
+* inline functions:                      Inline.             (line    6)
+* inline functions, omission of:         Inline.             (line   51)
+* inlining and C++ pragmas:              C++ Interface.      (line   66)
+* installation trouble:                  Trouble.            (line    6)
+* integrating function code:             Inline.             (line    6)
+* Intel 386 Options:                     i386 and x86-64 Options.
+                                                             (line    6)
+* interface and implementation headers, C++: C++ Interface.  (line    6)
+* intermediate C version, nonexistent:   G++ and GCC.        (line   35)
+* interrupt handler functions:           Function Attributes.
+                                                             (line  173)
+* interrupt handler functions <1>:       Function Attributes.
+                                                             (line  429)
+* interrupt handler functions <2>:       Function Attributes.
+                                                             (line  665)
+* interrupt handler functions on the AVR processors: Function Attributes.
+                                                             (line 1479)
+* interrupt handler functions on the Blackfin, m68k, H8/300 and SH processors: Function Attributes.
+                                                             (line  826)
+* interrupt service routines on ARM:     Function Attributes.
+                                                             (line  840)
+* interrupt thread functions on fido:    Function Attributes.
+                                                             (line  832)
+* introduction:                          Top.                (line    6)
+* invalid assembly code:                 Bug Criteria.       (line   12)
+* invalid input:                         Bug Criteria.       (line   42)
+* invoking 'g++':                        Invoking G++.       (line   22)
+* isalnum:                               Other Builtins.     (line    6)
+* isalpha:                               Other Builtins.     (line    6)
+* isascii:                               Other Builtins.     (line    6)
+* isblank:                               Other Builtins.     (line    6)
+* iscntrl:                               Other Builtins.     (line    6)
+* isdigit:                               Other Builtins.     (line    6)
+* isgraph:                               Other Builtins.     (line    6)
+* islower:                               Other Builtins.     (line    6)
+* ISO 9899:                              Standards.          (line   13)
+* ISO C:                                 Standards.          (line   13)
+* ISO C standard:                        Standards.          (line   13)
+* ISO C11:                               Standards.          (line   13)
+* ISO C1X:                               Standards.          (line   13)
+* ISO C90:                               Standards.          (line   13)
+* ISO C94:                               Standards.          (line   13)
+* ISO C95:                               Standards.          (line   13)
+* ISO C99:                               Standards.          (line   13)
+* ISO C9X:                               Standards.          (line   13)
+* ISO support:                           C Dialect Options.  (line   10)
+* ISO/IEC 9899:                          Standards.          (line   13)
+* isprint:                               Other Builtins.     (line    6)
+* ispunct:                               Other Builtins.     (line    6)
+* isspace:                               Other Builtins.     (line    6)
+* isupper:                               Other Builtins.     (line    6)
+* iswalnum:                              Other Builtins.     (line    6)
+* iswalpha:                              Other Builtins.     (line    6)
+* iswblank:                              Other Builtins.     (line    6)
+* iswcntrl:                              Other Builtins.     (line    6)
+* iswdigit:                              Other Builtins.     (line    6)
+* iswgraph:                              Other Builtins.     (line    6)
+* iswlower:                              Other Builtins.     (line    6)
+* iswprint:                              Other Builtins.     (line    6)
+* iswpunct:                              Other Builtins.     (line    6)
+* iswspace:                              Other Builtins.     (line    6)
+* iswupper:                              Other Builtins.     (line    6)
+* iswxdigit:                             Other Builtins.     (line    6)
+* isxdigit:                              Other Builtins.     (line    6)
+* j0:                                    Other Builtins.     (line    6)
+* j0f:                                   Other Builtins.     (line    6)
+* j0l:                                   Other Builtins.     (line    6)
+* j1:                                    Other Builtins.     (line    6)
+* j1f:                                   Other Builtins.     (line    6)
+* j1l:                                   Other Builtins.     (line    6)
+* Java:                                  G++ and GCC.        (line    6)
+* 'java_interface' attribute:            C++ Attributes.     (line   56)
+* jn:                                    Other Builtins.     (line    6)
+* jnf:                                   Other Builtins.     (line    6)
+* jnl:                                   Other Builtins.     (line    6)
+* 'k' fixed-suffix:                      Fixed-Point.        (line    6)
+* 'K' fixed-suffix:                      Fixed-Point.        (line    6)
+* 'keep_interrupts_masked' attribute:    Function Attributes.
+                                                             (line  778)
+* keywords, alternate:                   Alternate Keywords. (line    6)
+* known causes of trouble:               Trouble.            (line    6)
+* 'l1_data' variable attribute:          Variable Attributes.
+                                                             (line  352)
+* 'l1_data_A' variable attribute:        Variable Attributes.
+                                                             (line  352)
+* 'l1_data_B' variable attribute:        Variable Attributes.
+                                                             (line  352)
+* 'l1_text' function attribute:          Function Attributes.
+                                                             (line  849)
+* 'l2' function attribute:               Function Attributes.
+                                                             (line  855)
+* 'l2' variable attribute:               Variable Attributes.
+                                                             (line  360)
+* labeled elements in initializers:      Designated Inits.   (line    6)
+* labels as values:                      Labels as Values.   (line    6)
+* labs:                                  Other Builtins.     (line    6)
+* LANG:                                  Environment Variables.
+                                                             (line   21)
+* LANG <1>:                              Environment Variables.
+                                                             (line  106)
+* language dialect options:              C Dialect Options.  (line    6)
+* LC_ALL:                                Environment Variables.
+                                                             (line   21)
+* LC_CTYPE:                              Environment Variables.
+                                                             (line   21)
+* LC_MESSAGES:                           Environment Variables.
+                                                             (line   21)
+* ldexp:                                 Other Builtins.     (line    6)
+* ldexpf:                                Other Builtins.     (line    6)
+* ldexpl:                                Other Builtins.     (line    6)
+* 'leaf' function attribute:             Function Attributes.
+                                                             (line  861)
+* length-zero arrays:                    Zero Length.        (line    6)
+* lgamma:                                Other Builtins.     (line    6)
+* lgammaf:                               Other Builtins.     (line    6)
+* lgammaf_r:                             Other Builtins.     (line    6)
+* lgammal:                               Other Builtins.     (line    6)
+* lgammal_r:                             Other Builtins.     (line    6)
+* lgamma_r:                              Other Builtins.     (line    6)
+* Libraries:                             Link Options.       (line   24)
+* LIBRARY_PATH:                          Environment Variables.
+                                                             (line   97)
+* link options:                          Link Options.       (line    6)
+* linker script:                         Link Options.       (line  213)
+* 'lk' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'LK' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'LL' integer suffix:                   Long Long.          (line    6)
+* llabs:                                 Other Builtins.     (line    6)
+* 'llk' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'LLK' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'llr' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'LLR' fixed-suffix:                    Fixed-Point.        (line    6)
+* llrint:                                Other Builtins.     (line    6)
+* llrintf:                               Other Builtins.     (line    6)
+* llrintl:                               Other Builtins.     (line    6)
+* llround:                               Other Builtins.     (line    6)
+* llroundf:                              Other Builtins.     (line    6)
+* llroundl:                              Other Builtins.     (line    6)
+* LM32 options:                          LM32 Options.       (line    6)
+* load address instruction:              Simple Constraints. (line  152)
+* local labels:                          Local Labels.       (line    6)
+* local variables in macros:             Typeof.             (line   46)
+* local variables, specifying registers: Local Reg Vars.     (line    6)
+* locale:                                Environment Variables.
+                                                             (line   21)
+* locale definition:                     Environment Variables.
+                                                             (line  106)
+* locus GCC_COLORS capability:           Language Independent Options.
+                                                             (line   79)
+* log:                                   Other Builtins.     (line    6)
+* log10:                                 Other Builtins.     (line    6)
+* log10f:                                Other Builtins.     (line    6)
+* log10l:                                Other Builtins.     (line    6)
+* log1p:                                 Other Builtins.     (line    6)
+* log1pf:                                Other Builtins.     (line    6)
+* log1pl:                                Other Builtins.     (line    6)
+* log2:                                  Other Builtins.     (line    6)
+* log2f:                                 Other Builtins.     (line    6)
+* log2l:                                 Other Builtins.     (line    6)
+* logb:                                  Other Builtins.     (line    6)
+* logbf:                                 Other Builtins.     (line    6)
+* logbl:                                 Other Builtins.     (line    6)
+* logf:                                  Other Builtins.     (line    6)
+* logl:                                  Other Builtins.     (line    6)
+* 'long long' data types:                Long Long.          (line    6)
+* longjmp:                               Global Reg Vars.    (line   65)
+* 'longjmp' incompatibilities:           Incompatibilities.  (line   39)
+* 'longjmp' warnings:                    Warning Options.    (line  666)
+* 'lr' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'LR' fixed-suffix:                     Fixed-Point.        (line    6)
+* lrint:                                 Other Builtins.     (line    6)
+* lrintf:                                Other Builtins.     (line    6)
+* lrintl:                                Other Builtins.     (line    6)
+* lround:                                Other Builtins.     (line    6)
+* lroundf:                               Other Builtins.     (line    6)
+* lroundl:                               Other Builtins.     (line    6)
+* 'm' in constraint:                     Simple Constraints. (line   17)
+* M32C options:                          M32C Options.       (line    6)
+* M32R/D options:                        M32R/D Options.     (line    6)
+* M680x0 options:                        M680x0 Options.     (line    6)
+* machine dependent options:             Submodel Options.   (line    6)
+* machine specific constraints:          Machine Constraints.
+                                                             (line    6)
+* macro with variable arguments:         Variadic Macros.    (line    6)
+* macros containing 'asm':               Extended Asm.       (line  237)
+* macros, inline alternative:            Inline.             (line    6)
+* macros, local labels:                  Local Labels.       (line    6)
+* macros, local variables in:            Typeof.             (line   46)
+* macros, statements in expressions:     Statement Exprs.    (line    6)
+* macros, types of arguments:            Typeof.             (line    6)
+* 'make':                                Preprocessor Options.
+                                                             (line  185)
+* malloc:                                Other Builtins.     (line    6)
+* 'malloc' attribute:                    Function Attributes.
+                                                             (line  933)
+* matching constraint:                   Simple Constraints. (line  137)
+* MCore options:                         MCore Options.      (line    6)
+* member fns, automatically 'inline':    Inline.             (line   71)
+* memchr:                                Other Builtins.     (line    6)
+* memcmp:                                Other Builtins.     (line    6)
+* memcpy:                                Other Builtins.     (line    6)
+* memory references in constraints:      Simple Constraints. (line   17)
+* mempcpy:                               Other Builtins.     (line    6)
+* memset:                                Other Builtins.     (line    6)
+* MeP options:                           MeP Options.        (line    6)
+* Mercury:                               G++ and GCC.        (line   23)
+* message formatting:                    Language Independent Options.
+                                                             (line    6)
+* messages, warning:                     Warning Options.    (line    6)
+* messages, warning and error:           Warnings and Errors.
+                                                             (line    6)
+* MicroBlaze Options:                    MicroBlaze Options. (line    6)
+* 'micromips' attribute:                 Function Attributes.
+                                                             (line  957)
+* middle-operands, omitted:              Conditionals.       (line    6)
+* MIPS options:                          MIPS Options.       (line    6)
+* 'mips16' attribute:                    Function Attributes.
+                                                             (line  942)
+* misunderstandings in C++:              C++ Misunderstandings.
+                                                             (line    6)
+* mixed declarations and code:           Mixed Declarations. (line    6)
+* 'mktemp', and constant strings:        Incompatibilities.  (line   13)
+* MMIX Options:                          MMIX Options.       (line    6)
+* MN10300 options:                       MN10300 Options.    (line    6)
+* 'mode' attribute:                      Variable Attributes.
+                                                             (line  133)
+* modf:                                  Other Builtins.     (line    6)
+* modff:                                 Other Builtins.     (line    6)
+* modfl:                                 Other Builtins.     (line    6)
+* modifiers in constraints:              Modifiers.          (line    6)
+* Moxie Options:                         Moxie Options.      (line    6)
+* MSP430 Options:                        MSP430 Options.     (line    6)
+* 'ms_abi' attribute:                    Function Attributes.
+                                                             (line 1003)
+* 'ms_hook_prologue' attribute:          Function Attributes.
+                                                             (line 1030)
+* 'ms_struct':                           Type Attributes.    (line  323)
+* 'ms_struct' attribute:                 Variable Attributes.
+                                                             (line  438)
+* multiple alternative constraints:      Multi-Alternative.  (line    6)
+* multiprecision arithmetic:             Long Long.          (line    6)
+* 'n' in constraint:                     Simple Constraints. (line   73)
+* Named Address Spaces:                  Named Address Spaces.
+                                                             (line    6)
+* names used in assembler code:          Asm Labels.         (line    6)
+* naming convention, implementation headers: C++ Interface.  (line   46)
+* NDS32 Options:                         NDS32 Options.      (line    6)
+* nearbyint:                             Other Builtins.     (line    6)
+* nearbyintf:                            Other Builtins.     (line    6)
+* nearbyintl:                            Other Builtins.     (line    6)
+* 'nested' attribute:                    Function Attributes.
+                                                             (line  806)
+* nested functions:                      Nested Functions.   (line    6)
+* 'nested_ready' attribute:              Function Attributes.
+                                                             (line  810)
+* newlines (escaped):                    Escaped Newlines.   (line    6)
+* nextafter:                             Other Builtins.     (line    6)
+* nextafterf:                            Other Builtins.     (line    6)
+* nextafterl:                            Other Builtins.     (line    6)
+* nexttoward:                            Other Builtins.     (line    6)
+* nexttowardf:                           Other Builtins.     (line    6)
+* nexttowardl:                           Other Builtins.     (line    6)
+* NFC:                                   Warning Options.    (line 1289)
+* NFKC:                                  Warning Options.    (line 1289)
+* Nios II options:                       Nios II Options.    (line    6)
+* 'nmi' attribute:                       Function Attributes.
+                                                             (line 1371)
+* NMI handler functions on the Blackfin processor: Function Attributes.
+                                                             (line 1073)
+* 'noclone' function attribute:          Function Attributes.
+                                                             (line 1107)
+* 'nocommon' attribute:                  Variable Attributes.
+                                                             (line  104)
+* 'nocompression' attribute:             Function Attributes.
+                                                             (line 1079)
+* 'noinline' function attribute:         Function Attributes.
+                                                             (line 1096)
+* 'nomicromips' attribute:               Function Attributes.
+                                                             (line  957)
+* 'nomips16' attribute:                  Function Attributes.
+                                                             (line  942)
+* non-constant initializers:             Initializers.       (line    6)
+* non-static inline function:            Inline.             (line   85)
+* 'nonnull' function attribute:          Function Attributes.
+                                                             (line 1113)
+* 'noreturn' function attribute:         Function Attributes.
+                                                             (line 1147)
+* 'nosave_low_regs' attribute:           Function Attributes.
+                                                             (line 1197)
+* note GCC_COLORS capability:            Language Independent Options.
+                                                             (line   73)
+* 'nothrow' function attribute:          Function Attributes.
+                                                             (line 1189)
+* 'not_nested' attribute:                Function Attributes.
+                                                             (line  808)
+* 'no_instrument_function' function attribute: Function Attributes.
+                                                             (line 1085)
+* 'no_sanitize_address' function attribute: Function Attributes.
+                                                             (line 1335)
+* 'no_sanitize_undefined' function attribute: Function Attributes.
+                                                             (line 1343)
+* 'no_split_stack' function attribute:   Function Attributes.
+                                                             (line 1090)
+* 'o' in constraint:                     Simple Constraints. (line   23)
+* OBJC_INCLUDE_PATH:                     Environment Variables.
+                                                             (line  130)
+* Objective-C:                           G++ and GCC.        (line    6)
+* Objective-C <1>:                       Standards.          (line  162)
+* Objective-C and Objective-C++ options, command-line: Objective-C and Objective-C++ Dialect Options.
+                                                             (line    6)
+* Objective-C++:                         G++ and GCC.        (line    6)
+* Objective-C++ <1>:                     Standards.          (line  162)
+* offsettable address:                   Simple Constraints. (line   23)
+* old-style function definitions:        Function Prototypes.
+                                                             (line    6)
+* omitted middle-operands:               Conditionals.       (line    6)
+* open coding:                           Inline.             (line    6)
+* OpenMP parallel:                       C Dialect Options.  (line  263)
+* OpenMP SIMD:                           C Dialect Options.  (line  272)
+* operand constraints, 'asm':            Constraints.        (line    6)
+* 'optimize' function attribute:         Function Attributes.
+                                                             (line 1203)
+* optimize options:                      Optimize Options.   (line    6)
+* options to control diagnostics formatting: Language Independent Options.
+                                                             (line    6)
+* options to control warnings:           Warning Options.    (line    6)
+* options, C++:                          C++ Dialect Options.
+                                                             (line    6)
+* options, code generation:              Code Gen Options.   (line    6)
+* options, debugging:                    Debugging Options.  (line    6)
+* options, dialect:                      C Dialect Options.  (line    6)
+* options, directory search:             Directory Options.  (line    6)
+* options, GCC command:                  Invoking GCC.       (line    6)
+* options, grouping:                     Invoking GCC.       (line   26)
+* options, linking:                      Link Options.       (line    6)
+* options, Objective-C and Objective-C++: Objective-C and Objective-C++ Dialect Options.
+                                                             (line    6)
+* options, optimization:                 Optimize Options.   (line    6)
+* options, order:                        Invoking GCC.       (line   30)
+* options, preprocessor:                 Preprocessor Options.
+                                                             (line    6)
+* order of evaluation, side effects:     Non-bugs.           (line  196)
+* order of options:                      Invoking GCC.       (line   30)
+* 'OS_main' AVR function attribute:      Function Attributes.
+                                                             (line 1220)
+* 'OS_task' AVR function attribute:      Function Attributes.
+                                                             (line 1220)
+* other register constraints:            Simple Constraints. (line  161)
+* output file option:                    Overall Options.    (line  191)
+* overloaded virtual function, warning:  C++ Dialect Options.
+                                                             (line  655)
+* 'p' in constraint:                     Simple Constraints. (line  152)
+* 'packed' attribute:                    Variable Attributes.
+                                                             (line  144)
+* parameter forward declaration:         Variable Length.    (line   68)
+* 'partial_save' attribute:              Function Attributes.
+                                                             (line  818)
+* Pascal:                                G++ and GCC.        (line   23)
+* 'pcs' function attribute:              Function Attributes.
+                                                             (line 1244)
+* PDP-11 Options:                        PDP-11 Options.     (line    6)
+* PIC:                                   Code Gen Options.   (line  278)
+* picoChip options:                      picoChip Options.   (line    6)
+* pmf:                                   Bound member functions.
+                                                             (line    6)
+* pointer arguments:                     Function Attributes.
+                                                             (line  220)
+* pointer to member function:            Bound member functions.
+                                                             (line    6)
+* portions of temporary objects, pointers to: Temporaries.   (line    6)
+* pow:                                   Other Builtins.     (line    6)
+* pow10:                                 Other Builtins.     (line    6)
+* pow10f:                                Other Builtins.     (line    6)
+* pow10l:                                Other Builtins.     (line    6)
+* PowerPC options:                       PowerPC Options.    (line    6)
+* powf:                                  Other Builtins.     (line    6)
+* powl:                                  Other Builtins.     (line    6)
+* pragma GCC ivdep:                      Loop-Specific Pragmas.
+                                                             (line    7)
+* pragma GCC optimize:                   Function Specific Option Pragmas.
+                                                             (line   20)
+* pragma GCC pop_options:                Function Specific Option Pragmas.
+                                                             (line   34)
+* pragma GCC push_options:               Function Specific Option Pragmas.
+                                                             (line   34)
+* pragma GCC reset_options:              Function Specific Option Pragmas.
+                                                             (line   45)
+* pragma GCC target:                     Function Specific Option Pragmas.
+                                                             (line    7)
+* pragma, address:                       M32C Pragmas.       (line   15)
+* pragma, align:                         Solaris Pragmas.    (line   11)
+* pragma, call:                          MeP Pragmas.        (line   48)
+* pragma, coprocessor available:         MeP Pragmas.        (line   13)
+* pragma, coprocessor call_saved:        MeP Pragmas.        (line   20)
+* pragma, coprocessor subclass:          MeP Pragmas.        (line   28)
+* pragma, custom io_volatile:            MeP Pragmas.        (line    7)
+* pragma, diagnostic:                    Diagnostic Pragmas. (line   14)
+* pragma, diagnostic <1>:                Diagnostic Pragmas. (line   57)
+* pragma, disinterrupt:                  MeP Pragmas.        (line   38)
+* pragma, fini:                          Solaris Pragmas.    (line   20)
+* pragma, init:                          Solaris Pragmas.    (line   26)
+* pragma, longcall:                      RS/6000 and PowerPC Pragmas.
+                                                             (line   14)
+* pragma, long_calls:                    ARM Pragmas.        (line   11)
+* pragma, long_calls_off:                ARM Pragmas.        (line   17)
+* pragma, mark:                          Darwin Pragmas.     (line   11)
+* pragma, memregs:                       M32C Pragmas.       (line    7)
+* pragma, no_long_calls:                 ARM Pragmas.        (line   14)
+* pragma, options align:                 Darwin Pragmas.     (line   14)
+* pragma, pop_macro:                     Push/Pop Macro Pragmas.
+                                                             (line   15)
+* pragma, push_macro:                    Push/Pop Macro Pragmas.
+                                                             (line   11)
+* pragma, reason for not using:          Function Attributes.
+                                                             (line 2055)
+* pragma, redefine_extname:              Symbol-Renaming Pragmas.
+                                                             (line   12)
+* pragma, segment:                       Darwin Pragmas.     (line   21)
+* pragma, unused:                        Darwin Pragmas.     (line   24)
+* pragma, visibility:                    Visibility Pragmas. (line    8)
+* pragma, weak:                          Weak Pragmas.       (line   10)
+* pragmas:                               Pragmas.            (line    6)
+* pragmas in C++, effect on inlining:    C++ Interface.      (line   66)
+* pragmas, interface and implementation: C++ Interface.      (line    6)
+* pragmas, warning of unknown:           Warning Options.    (line  683)
+* precompiled headers:                   Precompiled Headers.
+                                                             (line    6)
+* preprocessing numbers:                 Incompatibilities.  (line  173)
+* preprocessing tokens:                  Incompatibilities.  (line  173)
+* preprocessor options:                  Preprocessor Options.
+                                                             (line    6)
+* printf:                                Other Builtins.     (line    6)
+* printf_unlocked:                       Other Builtins.     (line    6)
+* 'prof':                                Debugging Options.  (line  409)
+* 'progmem' AVR variable attribute:      Variable Attributes.
+                                                             (line  314)
+* promotion of formal parameters:        Function Prototypes.
+                                                             (line    6)
+* 'pure' function attribute:             Function Attributes.
+                                                             (line 1263)
+* push address instruction:              Simple Constraints. (line  152)
+* putchar:                               Other Builtins.     (line    6)
+* puts:                                  Other Builtins.     (line    6)
+* 'q' floating point suffix:             Floating Types.     (line    6)
+* 'Q' floating point suffix:             Floating Types.     (line    6)
+* 'qsort', and global register variables: Global Reg Vars.   (line   41)
+* question mark:                         Multi-Alternative.  (line   27)
+* quote GCC_COLORS capability:           Language Independent Options.
+                                                             (line   83)
+* 'r' fixed-suffix:                      Fixed-Point.        (line    6)
+* 'R' fixed-suffix:                      Fixed-Point.        (line    6)
+* 'r' in constraint:                     Simple Constraints. (line   64)
+* 'RAMPD':                               AVR Options.        (line  333)
+* 'RAMPX':                               AVR Options.        (line  333)
+* 'RAMPY':                               AVR Options.        (line  333)
+* 'RAMPZ':                               AVR Options.        (line  333)
+* ranges in case statements:             Case Ranges.        (line    6)
+* read-only strings:                     Incompatibilities.  (line    9)
+* 'reentrant' attribute:                 Function Attributes.
+                                                             (line  723)
+* register variable after 'longjmp':     Global Reg Vars.    (line   65)
+* registers:                             Extended Asm.       (line    6)
+* registers for local variables:         Local Reg Vars.     (line    6)
+* registers in constraints:              Simple Constraints. (line   64)
+* registers, global allocation:          Explicit Reg Vars.  (line    6)
+* registers, global variables in:        Global Reg Vars.    (line    6)
+* 'regparm' attribute:                   Function Attributes.
+                                                             (line 1349)
+* relocation truncated to fit (ColdFire): M680x0 Options.    (line  325)
+* relocation truncated to fit (MIPS):    MIPS Options.       (line  207)
+* remainder:                             Other Builtins.     (line    6)
+* remainderf:                            Other Builtins.     (line    6)
+* remainderl:                            Other Builtins.     (line    6)
+* remquo:                                Other Builtins.     (line    6)
+* remquof:                               Other Builtins.     (line    6)
+* remquol:                               Other Builtins.     (line    6)
+* 'renesas' attribute:                   Function Attributes.
+                                                             (line 1392)
+* reordering, warning:                   C++ Dialect Options.
+                                                             (line  573)
+* reporting bugs:                        Bugs.               (line    6)
+* 'resbank' attribute:                   Function Attributes.
+                                                             (line 1396)
+* reset handler functions:               Function Attributes.
+                                                             (line 1366)
+* rest argument (in macro):              Variadic Macros.    (line    6)
+* restricted pointers:                   Restricted Pointers.
+                                                             (line    6)
+* restricted references:                 Restricted Pointers.
+                                                             (line    6)
+* restricted this pointer:               Restricted Pointers.
+                                                             (line    6)
+* 'returns_nonnull' function attribute:  Function Attributes.
+                                                             (line 1137)
+* 'returns_twice' attribute:             Function Attributes.
+                                                             (line 1410)
+* rindex:                                Other Builtins.     (line    6)
+* rint:                                  Other Builtins.     (line    6)
+* rintf:                                 Other Builtins.     (line    6)
+* rintl:                                 Other Builtins.     (line    6)
+* RL78 Options:                          RL78 Options.       (line    6)
+* round:                                 Other Builtins.     (line    6)
+* roundf:                                Other Builtins.     (line    6)
+* roundl:                                Other Builtins.     (line    6)
+* RS/6000 and PowerPC Options:           RS/6000 and PowerPC Options.
+                                                             (line    6)
+* RTTI:                                  Vague Linkage.      (line   42)
+* run-time options:                      Code Gen Options.   (line    6)
+* RX Options:                            RX Options.         (line    6)
+* 's' in constraint:                     Simple Constraints. (line  100)
+* S/390 and zSeries Options:             S/390 and zSeries Options.
+                                                             (line    6)
+* save all registers on the Blackfin, H8/300, H8/300H, and H8S: Function Attributes.
+                                                             (line 1419)
+* save volatile registers on the MicroBlaze: Function Attributes.
+                                                             (line 1424)
+* 'save_all' attribute:                  Function Attributes.
+                                                             (line  815)
+* scalb:                                 Other Builtins.     (line    6)
+* scalbf:                                Other Builtins.     (line    6)
+* scalbl:                                Other Builtins.     (line    6)
+* scalbln:                               Other Builtins.     (line    6)
+* scalblnf:                              Other Builtins.     (line    6)
+* scalblnf <1>:                          Other Builtins.     (line    6)
+* scalbn:                                Other Builtins.     (line    6)
+* scalbnf:                               Other Builtins.     (line    6)
+* 'scanf', and constant strings:         Incompatibilities.  (line   17)
+* scanfnl:                               Other Builtins.     (line    6)
+* scope of a variable length array:      Variable Length.    (line   22)
+* scope of declaration:                  Disappointments.    (line   21)
+* scope of external declarations:        Incompatibilities.  (line   80)
+* Score Options:                         Score Options.      (line    6)
+* search path:                           Directory Options.  (line    6)
+* 'section' function attribute:          Function Attributes.
+                                                             (line 1432)
+* 'section' variable attribute:          Variable Attributes.
+                                                             (line  165)
+* 'sentinel' function attribute:         Function Attributes.
+                                                             (line 1448)
+* setjmp:                                Global Reg Vars.    (line   65)
+* 'setjmp' incompatibilities:            Incompatibilities.  (line   39)
+* shared strings:                        Incompatibilities.  (line    9)
+* 'shared' variable attribute:           Variable Attributes.
+                                                             (line  210)
+* side effect in '?:':                   Conditionals.       (line   20)
+* side effects, macro argument:          Statement Exprs.    (line   35)
+* side effects, order of evaluation:     Non-bugs.           (line  196)
+* signbit:                               Other Builtins.     (line    6)
+* signbitd128:                           Other Builtins.     (line    6)
+* signbitd32:                            Other Builtins.     (line    6)
+* signbitd64:                            Other Builtins.     (line    6)
+* signbitf:                              Other Builtins.     (line    6)
+* signbitl:                              Other Builtins.     (line    6)
+* signed and unsigned values, comparison warning: Warning Options.
+                                                             (line 1155)
+* significand:                           Other Builtins.     (line    6)
+* significandf:                          Other Builtins.     (line    6)
+* significandl:                          Other Builtins.     (line    6)
+* SIMD:                                  C Dialect Options.  (line  272)
+* simple constraints:                    Simple Constraints. (line    6)
+* sin:                                   Other Builtins.     (line    6)
+* sincos:                                Other Builtins.     (line    6)
+* sincosf:                               Other Builtins.     (line    6)
+* sincosl:                               Other Builtins.     (line    6)
+* sinf:                                  Other Builtins.     (line    6)
+* sinh:                                  Other Builtins.     (line    6)
+* sinhf:                                 Other Builtins.     (line    6)
+* sinhl:                                 Other Builtins.     (line    6)
+* sinl:                                  Other Builtins.     (line    6)
+* sizeof:                                Typeof.             (line    6)
+* smaller data references:               M32R/D Options.     (line   57)
+* smaller data references <1>:           Nios II Options.    (line    9)
+* smaller data references (PowerPC):     RS/6000 and PowerPC Options.
+                                                             (line  739)
+* snprintf:                              Other Builtins.     (line    6)
+* Solaris 2 options:                     Solaris 2 Options.  (line    6)
+* SPARC options:                         SPARC Options.      (line    6)
+* Spec Files:                            Spec Files.         (line    6)
+* specified registers:                   Explicit Reg Vars.  (line    6)
+* specifying compiler version and target machine: Target Options.
+                                                             (line    6)
+* specifying hardware config:            Submodel Options.   (line    6)
+* specifying machine version:            Target Options.     (line    6)
+* specifying registers for local variables: Local Reg Vars.  (line    6)
+* speed of compilation:                  Precompiled Headers.
+                                                             (line    6)
+* sprintf:                               Other Builtins.     (line    6)
+* SPU options:                           SPU Options.        (line    6)
+* 'sp_switch' attribute:                 Function Attributes.
+                                                             (line 1497)
+* sqrt:                                  Other Builtins.     (line    6)
+* sqrtf:                                 Other Builtins.     (line    6)
+* sqrtl:                                 Other Builtins.     (line    6)
+* sscanf:                                Other Builtins.     (line    6)
+* 'sscanf', and constant strings:        Incompatibilities.  (line   17)
+* 'sseregparm' attribute:                Function Attributes.
+                                                             (line 1377)
+* statements inside expressions:         Statement Exprs.    (line    6)
+* static data in C++, declaring and defining: Static Definitions.
+                                                             (line    6)
+* stpcpy:                                Other Builtins.     (line    6)
+* stpncpy:                               Other Builtins.     (line    6)
+* strcasecmp:                            Other Builtins.     (line    6)
+* strcat:                                Other Builtins.     (line    6)
+* strchr:                                Other Builtins.     (line    6)
+* strcmp:                                Other Builtins.     (line    6)
+* strcpy:                                Other Builtins.     (line    6)
+* strcspn:                               Other Builtins.     (line    6)
+* strdup:                                Other Builtins.     (line    6)
+* strfmon:                               Other Builtins.     (line    6)
+* strftime:                              Other Builtins.     (line    6)
+* string constants:                      Incompatibilities.  (line    9)
+* strlen:                                Other Builtins.     (line    6)
+* strncasecmp:                           Other Builtins.     (line    6)
+* strncat:                               Other Builtins.     (line    6)
+* strncmp:                               Other Builtins.     (line    6)
+* strncpy:                               Other Builtins.     (line    6)
+* strndup:                               Other Builtins.     (line    6)
+* strpbrk:                               Other Builtins.     (line    6)
+* strrchr:                               Other Builtins.     (line    6)
+* strspn:                                Other Builtins.     (line    6)
+* strstr:                                Other Builtins.     (line    6)
+* 'struct':                              Unnamed Fields.     (line    6)
+* struct __htm_tdb:                      S/390 System z Built-in Functions.
+                                                             (line   49)
+* structures:                            Incompatibilities.  (line  146)
+* structures, constructor expression:    Compound Literals.  (line    6)
+* submodel options:                      Submodel Options.   (line    6)
+* subscripting:                          Subscripting.       (line    6)
+* subscripting and function values:      Subscripting.       (line    6)
+* suffixes for C++ source:               Invoking G++.       (line    6)
+* SUNPRO_DEPENDENCIES:                   Environment Variables.
+                                                             (line  170)
+* suppressing warnings:                  Warning Options.    (line    6)
+* surprises in C++:                      C++ Misunderstandings.
+                                                             (line    6)
+* syntax checking:                       Warning Options.    (line   13)
+* 'syscall_linkage' attribute:           Function Attributes.
+                                                             (line 1512)
+* system headers, warnings from:         Warning Options.    (line  834)
+* 'sysv_abi' attribute:                  Function Attributes.
+                                                             (line 1003)
+* tan:                                   Other Builtins.     (line    6)
+* tanf:                                  Other Builtins.     (line    6)
+* tanh:                                  Other Builtins.     (line    6)
+* tanhf:                                 Other Builtins.     (line    6)
+* tanhl:                                 Other Builtins.     (line    6)
+* tanl:                                  Other Builtins.     (line    6)
+* 'target' function attribute:           Function Attributes.
+                                                             (line 1519)
+* target machine, specifying:            Target Options.     (line    6)
+* target options:                        Target Options.     (line    6)
+* 'target("abm")' attribute:             Function Attributes.
+                                                             (line 1552)
+* 'target("aes")' attribute:             Function Attributes.
+                                                             (line 1557)
+* 'target("align-stringops")' attribute: Function Attributes.
+                                                             (line 1651)
+* 'target("altivec")' attribute:         Function Attributes.
+                                                             (line 1677)
+* 'target("arch=ARCH")' attribute:       Function Attributes.
+                                                             (line 1660)
+* 'target("avoid-indexed-addresses")' attribute: Function Attributes.
+                                                             (line 1798)
+* 'target("cld")' attribute:             Function Attributes.
+                                                             (line 1622)
+* 'target("cmpb")' attribute:            Function Attributes.
+                                                             (line 1683)
+* 'target("cpu=CPU")' attribute:         Function Attributes.
+                                                             (line 1813)
+* 'target("custom-fpu-cfg=NAME")' attribute: Function Attributes.
+                                                             (line 1839)
+* 'target("custom-INSN=N")' attribute:   Function Attributes.
+                                                             (line 1830)
+* 'target("default")' attribute:         Function Attributes.
+                                                             (line 1560)
+* 'target("dlmzb")' attribute:           Function Attributes.
+                                                             (line 1689)
+* 'target("fancy-math-387")' attribute:  Function Attributes.
+                                                             (line 1626)
+* 'target("fma4")' attribute:            Function Attributes.
+                                                             (line 1606)
+* 'target("fpmath=FPMATH")' attribute:   Function Attributes.
+                                                             (line 1668)
+* 'target("fprnd")' attribute:           Function Attributes.
+                                                             (line 1696)
+* 'target("friz")' attribute:            Function Attributes.
+                                                             (line 1789)
+* 'target("fused-madd")' attribute:      Function Attributes.
+                                                             (line 1631)
+* 'target("hard-dfp")' attribute:        Function Attributes.
+                                                             (line 1702)
+* 'target("ieee-fp")' attribute:         Function Attributes.
+                                                             (line 1636)
+* 'target("inline-all-stringops")' attribute: Function Attributes.
+                                                             (line 1641)
+* 'target("inline-stringops-dynamically")' attribute: Function Attributes.
+                                                             (line 1645)
+* 'target("isel")' attribute:            Function Attributes.
+                                                             (line 1708)
+* 'target("longcall")' attribute:        Function Attributes.
+                                                             (line 1808)
+* 'target("lwp")' attribute:             Function Attributes.
+                                                             (line 1614)
+* 'target("mfcrf")' attribute:           Function Attributes.
+                                                             (line 1712)
+* 'target("mfpgpr")' attribute:          Function Attributes.
+                                                             (line 1719)
+* 'target("mmx")' attribute:             Function Attributes.
+                                                             (line 1565)
+* 'target("mulhw")' attribute:           Function Attributes.
+                                                             (line 1726)
+* 'target("multiple")' attribute:        Function Attributes.
+                                                             (line 1733)
+* 'target("no-custom-INSN")' attribute:  Function Attributes.
+                                                             (line 1830)
+* 'target("paired")' attribute:          Function Attributes.
+                                                             (line 1803)
+* 'target("pclmul")' attribute:          Function Attributes.
+                                                             (line 1569)
+* 'target("popcnt")' attribute:          Function Attributes.
+                                                             (line 1573)
+* 'target("popcntb")' attribute:         Function Attributes.
+                                                             (line 1744)
+* 'target("popcntd")' attribute:         Function Attributes.
+                                                             (line 1751)
+* 'target("powerpc-gfxopt")' attribute:  Function Attributes.
+                                                             (line 1757)
+* 'target("powerpc-gpopt")' attribute:   Function Attributes.
+                                                             (line 1763)
+* 'target("recip")' attribute:           Function Attributes.
+                                                             (line 1655)
+* 'target("recip-precision")' attribute: Function Attributes.
+                                                             (line 1769)
+* 'target("sse")' attribute:             Function Attributes.
+                                                             (line 1577)
+* 'target("sse2")' attribute:            Function Attributes.
+                                                             (line 1581)
+* 'target("sse3")' attribute:            Function Attributes.
+                                                             (line 1585)
+* 'target("sse4")' attribute:            Function Attributes.
+                                                             (line 1589)
+* 'target("sse4.1")' attribute:          Function Attributes.
+                                                             (line 1594)
+* 'target("sse4.2")' attribute:          Function Attributes.
+                                                             (line 1598)
+* 'target("sse4a")' attribute:           Function Attributes.
+                                                             (line 1602)
+* 'target("ssse3")' attribute:           Function Attributes.
+                                                             (line 1618)
+* 'target("string")' attribute:          Function Attributes.
+                                                             (line 1775)
+* 'target("tune=TUNE")' attribute:       Function Attributes.
+                                                             (line 1664)
+* 'target("tune=TUNE")' attribute <1>:   Function Attributes.
+                                                             (line 1820)
+* 'target("update")' attribute:          Function Attributes.
+                                                             (line 1738)
+* 'target("vsx")' attribute:             Function Attributes.
+                                                             (line 1781)
+* 'target("xop")' attribute:             Function Attributes.
+                                                             (line 1610)
+* TC1:                                   Standards.          (line   13)
+* TC2:                                   Standards.          (line   13)
+* TC3:                                   Standards.          (line   13)
+* Technical Corrigenda:                  Standards.          (line   13)
+* Technical Corrigendum 1:               Standards.          (line   13)
+* Technical Corrigendum 2:               Standards.          (line   13)
+* Technical Corrigendum 3:               Standards.          (line   13)
+* template instantiation:                Template Instantiation.
+                                                             (line    6)
+* temporaries, lifetime of:              Temporaries.        (line    6)
+* tgamma:                                Other Builtins.     (line    6)
+* tgammaf:                               Other Builtins.     (line    6)
+* tgammal:                               Other Builtins.     (line    6)
+* Thread-Local Storage:                  Thread-Local.       (line    6)
+* thunks:                                Nested Functions.   (line    6)
+* TILE-Gx options:                       TILE-Gx Options.    (line    6)
+* TILEPro options:                       TILEPro Options.    (line    6)
+* tiny data section on the H8/300H and H8S: Function Attributes.
+                                                             (line 1852)
+* TLS:                                   Thread-Local.       (line    6)
+* 'tls_model' attribute:                 Variable Attributes.
+                                                             (line  233)
+* TMPDIR:                                Environment Variables.
+                                                             (line   45)
+* toascii:                               Other Builtins.     (line    6)
+* tolower:                               Other Builtins.     (line    6)
+* toupper:                               Other Builtins.     (line    6)
+* towlower:                              Other Builtins.     (line    6)
+* towupper:                              Other Builtins.     (line    6)
+* traditional C language:                C Dialect Options.  (line  331)
+* 'trapa_handler' attribute:             Function Attributes.
+                                                             (line 1864)
+* 'trap_exit' attribute:                 Function Attributes.
+                                                             (line 1859)
+* trunc:                                 Other Builtins.     (line    6)
+* truncf:                                Other Builtins.     (line    6)
+* truncl:                                Other Builtins.     (line    6)
+* two-stage name lookup:                 Name lookup.        (line    6)
+* type alignment:                        Alignment.          (line    6)
+* type attributes:                       Type Attributes.    (line    6)
+* typedef names as function parameters:  Incompatibilities.  (line   97)
+* typeof:                                Typeof.             (line    6)
+* 'type_info':                           Vague Linkage.      (line   42)
+* 'uhk' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'UHK' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'uhr' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'UHR' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'uk' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'UK' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'ulk' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'ULK' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'ULL' integer suffix:                  Long Long.          (line    6)
+* 'ullk' fixed-suffix:                   Fixed-Point.        (line    6)
+* 'ULLK' fixed-suffix:                   Fixed-Point.        (line    6)
+* 'ullr' fixed-suffix:                   Fixed-Point.        (line    6)
+* 'ULLR' fixed-suffix:                   Fixed-Point.        (line    6)
+* 'ulr' fixed-suffix:                    Fixed-Point.        (line    6)
+* 'ULR' fixed-suffix:                    Fixed-Point.        (line    6)
+* undefined behavior:                    Bug Criteria.       (line   17)
+* undefined function value:              Bug Criteria.       (line   17)
+* underscores in variables in macros:    Typeof.             (line   46)
+* 'union':                               Unnamed Fields.     (line    6)
+* union, casting to a:                   Cast to Union.      (line    6)
+* unions:                                Incompatibilities.  (line  146)
+* unknown pragmas, warning:              Warning Options.    (line  683)
+* unresolved references and '-nodefaultlibs': Link Options.  (line   85)
+* unresolved references and '-nostdlib': Link Options.       (line   85)
+* 'unused' attribute.:                   Function Attributes.
+                                                             (line 1868)
+* 'ur' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'UR' fixed-suffix:                     Fixed-Point.        (line    6)
+* 'used' attribute.:                     Function Attributes.
+                                                             (line 1873)
+* User stack pointer in interrupts on the Blackfin: Function Attributes.
+                                                             (line  844)
+* 'use_debug_exception_return' attribute: Function Attributes.
+                                                             (line  783)
+* 'use_shadow_register_set' attribute:   Function Attributes.
+                                                             (line  774)
+* 'V' in constraint:                     Simple Constraints. (line   43)
+* V850 Options:                          V850 Options.       (line    6)
+* vague linkage:                         Vague Linkage.      (line    6)
+* value after 'longjmp':                 Global Reg Vars.    (line   65)
+* variable addressability on the IA-64:  Function Attributes.
+                                                             (line  974)
+* variable addressability on the M32R/D: Variable Attributes.
+                                                             (line  370)
+* variable alignment:                    Alignment.          (line    6)
+* variable attributes:                   Variable Attributes.
+                                                             (line    6)
+* variable number of arguments:          Variadic Macros.    (line    6)
+* variable-length array in a structure:  Variable Length.    (line   26)
+* variable-length array scope:           Variable Length.    (line   22)
+* variable-length arrays:                Variable Length.    (line    6)
+* variables in specified registers:      Explicit Reg Vars.  (line    6)
+* variables, local, in macros:           Typeof.             (line   46)
+* variadic macros:                       Variadic Macros.    (line    6)
+* VAX options:                           VAX Options.        (line    6)
+* 'version_id' attribute:                Function Attributes.
+                                                             (line 1883)
+* vfprintf:                              Other Builtins.     (line    6)
+* vfscanf:                               Other Builtins.     (line    6)
+* 'visibility' attribute:                Function Attributes.
+                                                             (line 1893)
+* VLAs:                                  Variable Length.    (line    6)
+* 'vliw' attribute:                      Function Attributes.
+                                                             (line 1989)
+* void pointers, arithmetic:             Pointer Arith.      (line    6)
+* void, size of pointer to:              Pointer Arith.      (line    6)
+* volatile access:                       Volatiles.          (line    6)
+* volatile access <1>:                   C++ Volatiles.      (line    6)
+* 'volatile' applied to function:        Function Attributes.
+                                                             (line    6)
+* volatile read:                         Volatiles.          (line    6)
+* volatile read <1>:                     C++ Volatiles.      (line    6)
+* volatile write:                        Volatiles.          (line    6)
+* volatile write <1>:                    C++ Volatiles.      (line    6)
+* vprintf:                               Other Builtins.     (line    6)
+* vscanf:                                Other Builtins.     (line    6)
+* vsnprintf:                             Other Builtins.     (line    6)
+* vsprintf:                              Other Builtins.     (line    6)
+* vsscanf:                               Other Builtins.     (line    6)
+* vtable:                                Vague Linkage.      (line   27)
+* VxWorks Options:                       VxWorks Options.    (line    6)
+* 'w' floating point suffix:             Floating Types.     (line    6)
+* 'W' floating point suffix:             Floating Types.     (line    6)
+* 'wakeup' attribute:                    Function Attributes.
+                                                             (line  729)
+* 'warm' attribute:                      Function Attributes.
+                                                             (line 1373)
+* warning for comparison of signed and unsigned values: Warning Options.
+                                                             (line 1155)
+* warning for overloaded virtual function: C++ Dialect Options.
+                                                             (line  655)
+* warning for reordering of member initializers: C++ Dialect Options.
+                                                             (line  573)
+* warning for unknown pragmas:           Warning Options.    (line  683)
+* 'warning' function attribute:          Function Attributes.
+                                                             (line  198)
+* warning GCC_COLORS capability:         Language Independent Options.
+                                                             (line   70)
+* warning messages:                      Warning Options.    (line    6)
+* warnings from system headers:          Warning Options.    (line  834)
+* warnings vs errors:                    Warnings and Errors.
+                                                             (line    6)
+* 'warn_unused' attribute:               C++ Attributes.     (line   64)
+* 'warn_unused_result' attribute:        Function Attributes.
+                                                             (line 1995)
+* 'weak' attribute:                      Function Attributes.
+                                                             (line 2012)
+* 'weakref' attribute:                   Function Attributes.
+                                                             (line 2021)
+* whitespace:                            Incompatibilities.  (line  112)
+* 'X' in constraint:                     Simple Constraints. (line  122)
+* X3.159-1989:                           Standards.          (line   13)
+* x86-64 Options:                        i386 and x86-64 Options.
+                                                             (line    6)
+* x86-64 options:                        x86-64 Options.     (line    6)
+* Xstormy16 Options:                     Xstormy16 Options.  (line    6)
+* Xtensa Options:                        Xtensa Options.     (line    6)
+* y0:                                    Other Builtins.     (line    6)
+* y0f:                                   Other Builtins.     (line    6)
+* y0l:                                   Other Builtins.     (line    6)
+* y1:                                    Other Builtins.     (line    6)
+* y1f:                                   Other Builtins.     (line    6)
+* y1l:                                   Other Builtins.     (line    6)
+* yn:                                    Other Builtins.     (line    6)
+* ynf:                                   Other Builtins.     (line    6)
+* ynl:                                   Other Builtins.     (line    6)
+* zero-length arrays:                    Zero Length.        (line    6)
+* zero-size structures:                  Empty Structures.   (line    6)
+* zSeries options:                       zSeries Options.    (line    6)
+
+
+
+Tag Table:
+Node: Top1881
+Node: G++ and GCC3629
+Node: Standards5686
+Node: Invoking GCC17845
+Node: Option Summary21590
+Node: Overall Options63276
+Node: Invoking G++77463
+Node: C Dialect Options78986
+Node: C++ Dialect Options95984
+Node: Objective-C and Objective-C++ Dialect Options126529
+Node: Language Independent Options137036
+Node: Warning Options141536
+Node: Debugging Options211575
+Node: Optimize Options271636
+Ref: Type-punning331182
+Node: Preprocessor Options413934
+Ref: Wtrigraphs418717
+Ref: dashMF423467
+Ref: fdollars-in-identifiers434348
+Node: Assembler Options444573
+Node: Link Options445264
+Ref: Link Options-Footnote-1457404
+Node: Directory Options457740
+Node: Spec Files464284
+Node: Target Options486113
+Node: Submodel Options486512
+Node: AArch64 Options488278
+Node: Adapteva Epiphany Options493403
+Node: ARC Options499351
+Node: ARM Options511795
+Node: AVR Options529093
+Node: Blackfin Options549318
+Node: C6X Options557336
+Node: CRIS Options558879
+Node: CR16 Options562618
+Node: Darwin Options563529
+Node: DEC Alpha Options570963
+Node: FR30 Options582579
+Node: FRV Options583143
+Node: GNU/Linux Options589907
+Node: H8/300 Options591167
+Node: HPPA Options592619
+Node: i386 and x86-64 Options601921
+Node: i386 and x86-64 Windows Options643992
+Node: IA-64 Options646845
+Node: LM32 Options654911
+Node: M32C Options655434
+Node: M32R/D Options656707
+Node: M680x0 Options660252
+Node: MCore Options674287
+Node: MeP Options675789
+Node: MicroBlaze Options679749
+Node: MIPS Options682551
+Node: MMIX Options714436
+Node: MN10300 Options716913
+Node: Moxie Options719454
+Node: MSP430 Options719824
+Node: NDS32 Options721913
+Node: Nios II Options723793
+Node: PDP-11 Options732258
+Node: picoChip Options733952
+Node: PowerPC Options736090
+Node: RL78 Options736311
+Node: RS/6000 and PowerPC Options736972
+Node: RX Options775902
+Node: S/390 and zSeries Options783234
+Node: Score Options791781
+Node: SH Options792630
+Node: Solaris 2 Options811301
+Node: SPARC Options812531
+Node: SPU Options825566
+Node: System V Options830505
+Node: TILE-Gx Options831331
+Node: TILEPro Options832349
+Node: V850 Options832853
+Node: VAX Options839561
+Node: VMS Options840096
+Node: VxWorks Options840909
+Node: x86-64 Options842064
+Node: Xstormy16 Options842282
+Node: Xtensa Options842571
+Node: zSeries Options846882
+Node: Code Gen Options847078
+Node: Environment Variables877946
+Node: Precompiled Headers885949
+Node: C Implementation891952
+Node: Translation implementation893642
+Node: Environment implementation894233
+Node: Identifiers implementation894787
+Node: Characters implementation895873
+Node: Integers implementation899523
+Node: Floating point implementation901408
+Node: Arrays and pointers implementation904471
+Ref: Arrays and pointers implementation-Footnote-1905931
+Node: Hints implementation906057
+Node: Structures unions enumerations and bit-fields implementation907542
+Node: Qualifiers implementation909766
+Node: Declarators implementation911546
+Node: Statements implementation911887
+Node: Preprocessing directives implementation912213
+Node: Library functions implementation914534
+Node: Architecture implementation915183
+Node: Locale-specific behavior implementation916828
+Node: C++ Implementation917133
+Node: Conditionally-supported behavior918416
+Node: Exception handling918925
+Node: C Extensions919333
+Node: Statement Exprs924403
+Node: Local Labels928880
+Node: Labels as Values931853
+Ref: Labels as Values-Footnote-1934254
+Node: Nested Functions934439
+Node: Constructing Calls938397
+Node: Typeof943114
+Node: Conditionals947496
+Node: __int128948385
+Node: Long Long948910
+Node: Complex950386
+Node: Floating Types952974
+Node: Half-Precision954102
+Node: Decimal Float956287
+Node: Hex Floats958143
+Node: Fixed-Point959180
+Node: Named Address Spaces962440
+Ref: AVR Named Address Spaces963121
+Node: Zero Length968329
+Node: Empty Structures971616
+Node: Variable Length972022
+Node: Variadic Macros974878
+Node: Escaped Newlines977256
+Node: Subscripting978095
+Node: Pointer Arith978820
+Node: Initializers979388
+Node: Compound Literals979884
+Node: Designated Inits983245
+Node: Case Ranges986983
+Node: Cast to Union987664
+Node: Mixed Declarations988754
+Node: Function Attributes989264
+Node: Attribute Syntax1083847
+Node: Function Prototypes1094237
+Node: C++ Comments1096017
+Node: Dollar Signs1096536
+Node: Character Escapes1097001
+Node: Variable Attributes1097295
+Ref: AVR Variable Attributes1110970
+Ref: MeP Variable Attributes1113632
+Ref: i386 Variable Attributes1115568
+Node: Type Attributes1121229
+Ref: MeP Type Attributes1135117
+Ref: i386 Type Attributes1135391
+Ref: PowerPC Type Attributes1136083
+Ref: SPU Type Attributes1136945
+Node: Alignment1137236
+Node: Inline1138606
+Node: Volatiles1143582
+Node: Extended Asm1146463
+Ref: Example of asm with clobbered asm reg1152367
+Ref: Extended asm with goto1162080
+Node: Constraints1169930
+Node: Simple Constraints1171014
+Node: Multi-Alternative1178324
+Node: Modifiers1180041
+Node: Machine Constraints1183054
+Node: Asm Labels1240008
+Node: Explicit Reg Vars1241684
+Node: Global Reg Vars1243282
+Node: Local Reg Vars1247778
+Node: Alternate Keywords1250194
+Node: Incomplete Enums1251680
+Node: Function Names1252436
+Node: Return Address1254597
+Node: Vector Extensions1258104
+Node: Offsetof1265033
+Node: __sync Builtins1265838
+Node: __atomic Builtins1271307
+Node: x86 specific memory model extensions for transactional memory1282941
+Node: Object Size Checking1284203
+Node: Cilk Plus Builtins1289696
+Node: Other Builtins1290565
+Node: Target Builtins1319872
+Node: Alpha Built-in Functions1321291
+Node: Altera Nios II Built-in Functions1324304
+Node: ARC Built-in Functions1328291
+Node: ARC SIMD Built-in Functions1333503
+Node: ARM iWMMXt Built-in Functions1342399
+Node: ARM NEON Intrinsics1349382
+Node: ARM ACLE Intrinsics1566876
+Node: AVR Built-in Functions1568257
+Node: Blackfin Built-in Functions1571335
+Node: FR-V Built-in Functions1571952
+Node: Argument Types1572815
+Node: Directly-mapped Integer Functions1574569
+Node: Directly-mapped Media Functions1575653
+Node: Raw read/write Functions1583859
+Node: Other Built-in Functions1584767
+Node: X86 Built-in Functions1585953
+Node: X86 transactional memory intrinsics1645162
+Node: MIPS DSP Built-in Functions1647838
+Node: MIPS Paired-Single Support1660347
+Node: MIPS Loongson Built-in Functions1661846
+Node: Paired-Single Arithmetic1668361
+Node: Paired-Single Built-in Functions1669309
+Node: MIPS-3D Built-in Functions1671976
+Node: Other MIPS Built-in Functions1677354
+Node: MSP430 Built-in Functions1678359
+Node: NDS32 Built-in Functions1679263
+Node: picoChip Built-in Functions1680556
+Node: PowerPC Built-in Functions1681899
+Node: PowerPC AltiVec/VSX Built-in Functions1683314
+Node: PowerPC Hardware Transactional Memory Built-in Functions1815519
+Node: RX Built-in Functions1822060
+Node: S/390 System z Built-in Functions1826093
+Node: SH Built-in Functions1831322
+Node: SPARC VIS Built-in Functions1832714
+Node: SPU Built-in Functions1838317
+Node: TI C6X Built-in Functions1840134
+Node: TILE-Gx Built-in Functions1841158
+Node: TILEPro Built-in Functions1842275
+Node: Target Format Checks1843342
+Node: Solaris Format Checks1843774
+Node: Darwin Format Checks1844200
+Node: Pragmas1845018
+Node: ARM Pragmas1845754
+Node: M32C Pragmas1846357
+Node: MeP Pragmas1847429
+Node: RS/6000 and PowerPC Pragmas1849497
+Node: Darwin Pragmas1850238
+Node: Solaris Pragmas1851305
+Node: Symbol-Renaming Pragmas1852469
+Node: Structure-Packing Pragmas1854025
+Node: Weak Pragmas1855670
+Node: Diagnostic Pragmas1856404
+Node: Visibility Pragmas1859513
+Node: Push/Pop Macro Pragmas1860265
+Node: Function Specific Option Pragmas1861238
+Node: Loop-Specific Pragmas1863429
+Node: Unnamed Fields1864528
+Node: Thread-Local1866755
+Node: C99 Thread-Local Edits1868860
+Node: C++98 Thread-Local Edits1870858
+Node: Binary constants1874303
+Node: C++ Extensions1874974
+Node: C++ Volatiles1876685
+Node: Restricted Pointers1879033
+Node: Vague Linkage1880624
+Node: C++ Interface1884247
+Ref: C++ Interface-Footnote-11888535
+Node: Template Instantiation1888673
+Node: Bound member functions1895259
+Node: C++ Attributes1896791
+Node: Function Multiversioning1900370
+Node: Namespace Association1902187
+Node: Type Traits1903567
+Node: Java Exceptions1910050
+Node: Deprecated Features1911440
+Node: Backwards Compatibility1914407
+Node: Objective-C1915754
+Node: GNU Objective-C runtime API1916361
+Node: Modern GNU Objective-C runtime API1917368
+Node: Traditional GNU Objective-C runtime API1919804
+Node: Executing code before main1920531
+Node: What you can and what you cannot do in +load1923269
+Node: Type encoding1925657
+Node: Legacy type encoding1930684
+Node: @encode1931774
+Node: Method signatures1932315
+Node: Garbage Collection1934307
+Node: Constant string objects1936996
+Node: compatibility_alias1939504
+Node: Exceptions1940225
+Node: Synchronization1942935
+Node: Fast enumeration1944119
+Node: Using fast enumeration1944431
+Node: c99-like fast enumeration syntax1945642
+Node: Fast enumeration details1946345
+Node: Fast enumeration protocol1948685
+Node: Messaging with the GNU Objective-C runtime1951837
+Node: Dynamically registering methods1953209
+Node: Forwarding hook1954900
+Node: Compatibility1957940
+Node: Gcov1964496
+Node: Gcov Intro1965029
+Node: Invoking Gcov1967747
+Node: Gcov and Optimization1981987
+Node: Gcov Data Files1984989
+Node: Cross-profiling1986384
+Node: Trouble1988238
+Node: Actual Bugs1989650
+Node: Interoperation1990097
+Node: Incompatibilities1996988
+Node: Fixed Headers2005140
+Node: Standard Libraries2006798
+Node: Disappointments2008170
+Node: C++ Misunderstandings2012529
+Node: Static Definitions2013340
+Node: Name lookup2014393
+Ref: Name lookup-Footnote-12019173
+Node: Temporaries2019362
+Node: Copy Assignment2021338
+Node: Non-bugs2023145
+Node: Warnings and Errors2033651
+Node: Bugs2035413
+Node: Bug Criteria2035880
+Node: Bug Reporting2038090
+Node: Service2038311
+Node: Contributing2039130
+Node: Funding2039870
+Node: GNU Project2042360
+Node: Copying2043006
+Node: GNU Free Documentation License2080514
+Node: Contributors2105631
+Node: Option Index2143500
+Node: Keyword Index2353567
+
+End Tag Table
diff --git a/gcc-4.9/gcc/doc/gcc.texi b/gcc-4.9/gcc/doc/gcc.texi
index 1e0fc46d0..c1f385774 100644
--- a/gcc-4.9/gcc/doc/gcc.texi
+++ b/gcc-4.9/gcc/doc/gcc.texi
@@ -140,7 +140,7 @@ Introduction, gccint, GNU Compiler Collection (GCC) Internals}.
 * Gcov::            @command{gcov}---a test coverage program.
 * Trouble::         If you have trouble using GCC.
 * Bugs::            How, why and where to report bugs.
-* Service::         How to find suppliers of support for GCC.
+* Service::         How To Get Help with GCC
 * Contributing::    How to contribute to testing and developing GCC.
 
 * Funding::         How to help assure funding for free software.
diff --git a/gcc-4.9/gcc/doc/gccinstall.info b/gcc-4.9/gcc/doc/gccinstall.info
new file mode 100644
index 000000000..5c8cb8c62
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gccinstall.info
@@ -0,0 +1,4679 @@
+This is gccinstall.info, produced by makeinfo version 5.1 from
+install.texi.
+
+Copyright (C) 1988-2014 Free Software Foundation, Inc.
+
+   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 "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.
+INFO-DIR-SECTION Software development
+START-INFO-DIR-ENTRY
+* gccinstall: (gccinstall).    Installing the GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+
+   Copyright (C) 1988-2014 Free Software Foundation, Inc.
+
+   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 "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.
+
+
+File: gccinstall.info,  Node: Top,  Up: (dir)
+
+* 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.
+
+
+File: gccinstall.info,  Node: Installing GCC,  Next: Binaries,  Up: Top
+
+1 Installing GCC
+****************
+
+The latest version of this document is always available at
+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.
+
+   _Before_ starting the build/install procedure please check the *note
+host/target specific installation notes: Specific.  We recommend you
+browse the entire generic installation instructions before you proceed.
+
+   Lists of successful builds for released versions of GCC are available
+at <http://gcc.gnu.org/buildstat.html>.  These lists are updated as new
+information becomes available.
+
+   The installation procedure itself is broken into five steps.
+
+* Menu:
+
+* Prerequisites::
+* Downloading the source::
+* Configuration::
+* Building::
+* Testing:: (optional)
+* Final install::
+
+   Please note that GCC does not support '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.
+
+
+File: gccinstall.info,  Node: Prerequisites,  Next: Downloading the source,  Up: Installing GCC
+
+2 Prerequisites
+***************
+
+GCC requires that various tools and packages be available for use in the
+build procedure.  Modifying GCC sources requires additional tools
+described below.
+
+Tools/packages necessary for building GCC
+=========================================
+
+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 '--disable-stage1-checking', though
+     bootstrapping the compiler with such earlier compilers is strongly
+     discouraged.
+
+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 'x86_64-unknown-linux-gnu' platform (among
+     other multilib targets), for which 64-bit ('x86_64') and 32-bit
+     ('i386') libc headers are usually packaged separately.  If you do a
+     build of a native compiler on '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 '--disable-multilib'.  Otherwise, you may encounter an
+     error such as 'fatal error: gnu/stubs-32.h: No such file'
+
+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.
+
+A "working" POSIX compatible shell, or GNU bash
+
+     Necessary when running 'configure' because some '/bin/sh' shells
+     have bugs and may crash when configuring the target libraries.  In
+     other cases, '/bin/sh' or 'ksh' have disastrous corner-case
+     performance problems.  This can cause target 'configure' runs to
+     literally take days to complete in some cases.
+
+     So on some platforms '/bin/ksh' is sufficient, on others it isn't.
+     See the host/target specific instructions for your platform, or use
+     'bash' to be sure.  Then set 'CONFIG_SHELL' in your environment to
+     your "good" shell prior to running 'configure'/'make'.
+
+     'zsh' is not a fully compliant POSIX shell and will not work when
+     configuring GCC.
+
+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.
+
+GNU binutils
+
+     Necessary in some circumstances, optional in others.  See the
+     host/target specific instructions for your platform for the exact
+     requirements.
+
+gzip version 1.2.4 (or later) or
+bzip2 version 1.0.2 (or later)
+
+     Necessary to uncompress GCC 'tar' files when source code is
+     obtained via FTP mirror sites.
+
+GNU make version 3.80 (or later)
+
+     You must have GNU make installed to build GCC.
+
+GNU tar version 1.14 (or later)
+
+     Necessary (only on some platforms) to untar the source code.  Many
+     systems' 'tar' programs will also work, only try GNU 'tar' if you
+     have problems.
+
+Perl version 5.6.1 (or later)
+
+     Necessary when targeting Darwin, building 'libstdc++', and not
+     using '--disable-symvers'.  Necessary when targeting Solaris 2 with
+     Sun 'ld' and not using '--disable-symvers'.  The bundled 'perl' in
+     Solaris 8 and up works.
+
+     Necessary when regenerating 'Makefile' dependencies in libiberty.
+     Necessary when regenerating '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.
+
+'jar', or InfoZIP ('zip' and 'unzip')
+
+     Necessary to build libgcj, the GCJ runtime.
+
+   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.
+
+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 '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 '--with-gmp' configure option.  See also '--with-gmp-lib'
+     and '--with-gmp-include'.
+
+MPFR Library version 2.4.2 (or later)
+
+     Necessary to build GCC.  It can be downloaded from
+     <http://www.mpfr.org/>.  If an MPFR source distribution is found in
+     a subdirectory of your GCC sources named '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 '--with-mpfr'
+     configure option should be used.  See also '--with-mpfr-lib' and
+     '--with-mpfr-include'.
+
+MPC Library version 0.8.1 (or later)
+
+     Necessary to build GCC.  It can be downloaded from
+     <http://www.multiprecision.org/>.  If an MPC source distribution is
+     found in a subdirectory of your GCC sources named '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 '--with-mpc'
+     configure option should be used.  See also '--with-mpc-lib' and
+     '--with-mpc-include'.
+
+ISL Library version 0.12.2
+
+     Necessary to build GCC with the Graphite loop optimizations.  It
+     can be downloaded from <ftp://gcc.gnu.org/pub/gcc/infrastructure/>
+     as 'isl-0.12.2.tar.bz2'.  If an ISL source distribution is found in
+     a subdirectory of your GCC sources named 'isl', it will be built
+     together with GCC. Alternatively, the '--with-isl' configure option
+     should be used if ISL is not installed in your default library
+     search path.
+
+CLooG 0.18.1
+
+     Necessary to build GCC with the Graphite loop optimizations.  It
+     can be downloaded from <ftp://gcc.gnu.org/pub/gcc/infrastructure/>
+     as 'cloog-0.18.1.tar.gz'.  If a CLooG source distribution is found
+     in a subdirectory of your GCC sources named 'cloog', it will be
+     built together with GCC. Alternatively, the '--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 '--with-isl=system' to direct CLooG
+     to pick up an already installed ISL. Using the ISL library as
+     bundled with CLooG is not supported.
+
+Tools/packages necessary for modifying GCC
+==========================================
+
+autoconf version 2.64
+GNU m4 version 1.4.6 (or later)
+
+     Necessary when modifying 'configure.ac', 'aclocal.m4', etc. to
+     regenerate 'configure' and 'config.in' files.
+
+automake version 1.11.1
+
+     Necessary when modifying a 'Makefile.am' file to regenerate its
+     associated 'Makefile.in'.
+
+     Much of GCC does not use automake, so directly edit the
+     'Makefile.in' file.  Specifically this applies to the 'gcc',
+     'intl', 'libcpp', 'libiberty', '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.
+
+gettext version 0.14.5 (or later)
+
+     Needed to regenerate 'gcc.pot'.
+
+gperf version 2.7.2 (or later)
+
+     Necessary when modifying 'gperf' input files, e.g.
+     'gcc/cp/cfns.gperf' to regenerate its associated header file, e.g.
+     'gcc/cp/cfns.h'.
+
+DejaGnu 1.4.4
+Expect
+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
+     <http://core.tcl.tk/tcl/tktview/267b7e2334ee2e9de34c4b00d6e72e2f1997085f>
+     for more information.
+
+autogen version 5.5.4 (or later) and
+guile version 1.4.1 (or later)
+
+     Necessary to regenerate 'fixinc/fixincl.x' from
+     'fixinc/inclhack.def' and 'fixinc/*.tpl'.
+
+     Necessary to run 'make check' for 'fixinc'.
+
+     Necessary to regenerate the top level 'Makefile.in' file from
+     'Makefile.tpl' and 'Makefile.def'.
+
+Flex version 2.5.4 (or later)
+
+     Necessary when modifying '*.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.
+
+Texinfo version 4.7 (or later)
+
+     Necessary for running 'makeinfo' when modifying '*.texi' files to
+     test your changes.
+
+     Necessary for running 'make dvi' or 'make pdf' to create printable
+     documentation in DVI or PDF format.  Texinfo version 4.8 or later
+     is required for '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.
+
+TeX (any working version)
+
+     Necessary for running 'texi2dvi' and 'texi2pdf', which are used
+     when running 'make dvi' or 'make pdf' to create DVI or PDF files,
+     respectively.
+
+SVN (any version)
+SSH (any version)
+
+     Necessary to access the SVN repository.  Public releases and weekly
+     snapshots of the development sources are also available via FTP.
+
+GNU diffutils version 2.7 (or later)
+
+     Useful when submitting patches for the GCC source code.
+
+patch version 2.5.4 (or later)
+
+     Necessary when applying patches, created with 'diff', to one's own
+     sources.
+
+ecj1
+gjavah
+
+     If you wish to modify '.java' files in libjava, you will need to
+     configure with '--enable-java-maintainer-mode', and you will need
+     to have executables named 'ecj1' and 'gjavah' in your path.  The
+     'ecj1' executable should run the Eclipse Java compiler via the
+     GCC-specific entry point.  You can download a suitable jar from
+     <ftp://sourceware.org/pub/java/>, or by running the script
+     'contrib/download_ecj'.
+
+antlr.jar version 2.7.1 (or later)
+antlr binary
+
+     If you wish to build the 'gjdoc' binary in libjava, you will need
+     to have an 'antlr.jar' library available.  The library is searched
+     for in system locations but can be specified with
+     '--with-antlr-jar=' instead.  When configuring with
+     '--enable-java-maintainer-mode', you will need to have one of the
+     executables named 'cantlr', 'runantlr' or 'antlr' in your path.
+
+
+File: gccinstall.info,  Node: Downloading the source,  Next: Configuration,  Prev: Prerequisites,  Up: Installing GCC
+
+3 Downloading GCC
+*****************
+
+GCC is distributed via SVN and FTP tarballs compressed with 'gzip' or
+'bzip2'.
+
+   Please refer to the 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 ('bfd',
+'binutils', 'gas', 'gprof', 'ld', 'opcodes', ...) 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 'gmp', 'mpfr' and 'mpc', respectively (or use symbolic links with the
+same name).
+
+
+File: gccinstall.info,  Node: Configuration,  Next: Building,  Prev: Downloading the source,  Up: Installing GCC
+
+4 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 SRCDIR to refer to the toplevel source directory for GCC; we
+use OBJDIR to refer to the toplevel build/object directory.
+
+   If you obtained the sources via SVN, SRCDIR must refer to the top
+'gcc' directory, the one where the 'MAINTAINERS' file can be found, and
+not its 'gcc' subdirectory, otherwise the build will fail.
+
+   If either SRCDIR or OBJDIR is located on an automounted NFS file
+system, the shell's built-in 'pwd' command will return temporary
+pathnames.  Using these can lead to various sorts of build problems.  To
+avoid this issue, set the 'PWDCMD' environment variable to an
+automounter-aware 'pwd' command, e.g., 'pawd' or 'amq -w', during the
+configuration and build phases.
+
+   First, we *highly* recommend that GCC be built into a separate
+directory from the sources which does *not* reside within the source
+tree.  This is how we generally build GCC; building where SRCDIR ==
+OBJDIR should still work, but doesn't get extensive testing; building
+where OBJDIR is a subdirectory of SRCDIR is unsupported.
+
+   If you have previously built GCC in the same directory for a
+different target machine, do 'make distclean' to delete all files that
+might be invalid.  One of the files this deletes is 'Makefile'; if 'make
+distclean' complains that '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 OBJDIR, you should simply use a
+different OBJDIR for each target.
+
+   Second, when configuring a native system, either 'cc' or 'gcc' must
+be in your path or you must set 'CC' in your environment before running
+configure.  Otherwise the configuration scripts may fail.
+
+   To configure GCC:
+
+     % mkdir OBJDIR
+     % cd OBJDIR
+     % SRCDIR/configure [OPTIONS] [TARGET]
+
+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.
+
+'--with-pkgversion=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 'gcc --version'.  This suffix does not
+     replace the default version string, only the 'GCC' part.
+
+     The default value is 'GCC'.
+
+'--with-bugurl=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.
+
+Target specification
+====================
+
+   * GCC has code to correctly determine the correct value for TARGET
+     for nearly all native systems.  Therefore, we highly recommend you
+     do not provide a configure target when configuring a native
+     compiler.
+
+   * TARGET must be specified as '--target=TARGET' when configuring a
+     cross compiler; examples of valid targets would be m68k-elf,
+     sh-elf, etc.
+
+   * Specifying just TARGET instead of '--target=TARGET' implies that
+     the host defaults to TARGET.
+
+Options specification
+=====================
+
+Use OPTIONS to override several configure time options for GCC.  A list
+of supported OPTIONS follows; 'configure --help' may list other options,
+but those not listed below may not work and should not normally be used.
+
+   Note that each '--enable' option has a corresponding '--disable'
+option and that each '--with' option has a corresponding '--without'
+option.
+
+'--prefix=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
+     '/usr/local'.
+
+     We *highly* recommend against DIRNAME being the same or a
+     subdirectory of OBJDIR or vice versa.  If specifying a directory
+     beneath a user's home directory tree, some shells will not expand
+     DIRNAME correctly if it contains the '~' metacharacter; use '$HOME'
+     instead.
+
+     The following standard 'autoconf' options are supported.  Normally
+     you should not need to use these options.
+     '--exec-prefix=DIRNAME'
+          Specify the toplevel installation directory for
+          architecture-dependent files.  The default is 'PREFIX'.
+
+     '--bindir=DIRNAME'
+          Specify the installation directory for the executables called
+          by users (such as 'gcc' and 'g++').  The default is
+          'EXEC-PREFIX/bin'.
+
+     '--libdir=DIRNAME'
+          Specify the installation directory for object code libraries
+          and internal data files of GCC.  The default is
+          'EXEC-PREFIX/lib'.
+
+     '--libexecdir=DIRNAME'
+          Specify the installation directory for internal executables of
+          GCC.  The default is 'EXEC-PREFIX/libexec'.
+
+     '--with-slibdir=DIRNAME'
+          Specify the installation directory for the shared libgcc
+          library.  The default is 'LIBDIR'.
+
+     '--datarootdir=DIRNAME'
+          Specify the root of the directory tree for read-only
+          architecture-independent data files referenced by GCC.  The
+          default is 'PREFIX/share'.
+
+     '--infodir=DIRNAME'
+          Specify the installation directory for documentation in info
+          format.  The default is 'DATAROOTDIR/info'.
+
+     '--datadir=DIRNAME'
+          Specify the installation directory for some
+          architecture-independent data files referenced by GCC.  The
+          default is 'DATAROOTDIR'.
+
+     '--docdir=DIRNAME'
+          Specify the installation directory for documentation files
+          (other than Info) for GCC.  The default is 'DATAROOTDIR/doc'.
+
+     '--htmldir=DIRNAME'
+          Specify the installation directory for HTML documentation
+          files.  The default is 'DOCDIR'.
+
+     '--pdfdir=DIRNAME'
+          Specify the installation directory for PDF documentation
+          files.  The default is 'DOCDIR'.
+
+     '--mandir=DIRNAME'
+          Specify the installation directory for manual pages.  The
+          default is '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.)
+
+     '--with-gxx-include-dir=DIRNAME'
+          Specify the installation directory for G++ header files.  The
+          default depends on other configuration options, and differs
+          between cross and native configurations.
+
+     '--with-specs=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
+          '--with-specs=%{!fcommon:%{!fno-common:-fno-common}}'.  *Note
+          Specifying subprocesses and the switches to pass to them:
+          (gcc)Spec Files,
+
+'--program-prefix=PREFIX'
+     GCC supports some transformations of the names of its programs when
+     installing them.  This option prepends PREFIX to the names of
+     programs to install in BINDIR (see above).  For example, specifying
+     '--program-prefix=foo-' would result in 'gcc' being installed as
+     '/usr/local/bin/foo-gcc'.
+
+'--program-suffix=SUFFIX'
+     Appends SUFFIX to the names of programs to install in BINDIR (see
+     above).  For example, specifying '--program-suffix=-3.1' would
+     result in 'gcc' being installed as '/usr/local/bin/gcc-3.1'.
+
+'--program-transform-name=PATTERN'
+     Applies the 'sed' script PATTERN to be applied to the names of
+     programs to install in BINDIR (see above).  PATTERN has to consist
+     of one or more basic 'sed' editing commands, separated by
+     semicolons.  For example, if you want the 'gcc' program name to be
+     transformed to the installed program '/usr/local/bin/myowngcc' and
+     the 'g++' program name to be transformed to
+     '/usr/local/bin/gspecial++' without changing other program names,
+     you could use the pattern
+     '--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, PREFIX (and
+     SUFFIX) are prepended (appended) before further transformations can
+     happen with a special transformation script 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
+     'i686-pc-linux-gnu-gcc'.  All of the above transformations happen
+     before the target alias is prepended to the name--so, specifying
+     '--program-prefix=foo-' and 'program-suffix=-3.1', the resulting
+     binary would be installed as
+     '/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.
+
+'--with-local-prefix=DIRNAME'
+     Specify the installation directory for local include files.  The
+     default is '/usr/local'.  Specify this option if you want the
+     compiler to search directory 'DIRNAME/include' for locally
+     installed header files _instead_ of '/usr/local/include'.
+
+     You should specify '--with-local-prefix' *only* if your site has a
+     different convention (not '/usr/local') for where to put
+     site-specific files.
+
+     The default value for '--with-local-prefix' is '/usr/local'
+     regardless of the value of '--prefix'.  Specifying '--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 '--prefix' is to specify where to _install GCC_. The
+     local header files in '/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 '--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 '-I DIRECTORY' options to the compiler
+     command line, to ensure that directories containing installed
+     packages' headers are searched.  When 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
+     '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 '/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
+     '--program-prefix', '--program-suffix' and
+     '--program-transform-name' options to install multiple versions
+     into a single directory, but it may be simpler to use different
+     prefixes and the '--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 'LIBRARY_PATH').
+
+     The same value can be used for both '--with-local-prefix' and
+     '--prefix' provided it is not '/usr'.  This can be used to avoid
+     the default search of '/usr/local/include'.
+
+     *Do not* specify '/usr' as the '--with-local-prefix'!  The
+     directory you use for '--with-local-prefix' *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 '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.
+
+'--with-native-system-header-dir=DIRNAME'
+     Specifies that DIRNAME is the directory that contains native system
+     header files, rather than '/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
+     '--with-sysroot' option and will cause GCC to search DIRNAME inside
+     the system root specified by that option.
+
+'--enable-shared[=PACKAGE[,...]]'
+     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 'libgcc' (also known as 'gcc'), 'libstdc++'
+     (not 'libstdc++-v3'), 'libffi', 'zlib', 'boehm-gc', 'ada',
+     'libada', 'libjava', 'libgo', and 'libobjc'.  Note 'libiberty' does
+     not support shared libraries at all.
+
+     Use '--disable-shared' to build only static libraries.  Note that
+     '--disable-shared' does not accept a list of package names as
+     argument, only '--enable-shared' does.
+
+     Contrast with '--enable-host-shared', which affects _host_ code.
+
+'--enable-host-shared'
+     Specify that the _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 '--enable-shared', which affects _target_ libraries.
+
+'--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 '--with-gnu-as'.)  If you have more than one
+     assembler installed on your system, you may want to use this option
+     in connection with '--with-as=PATHNAME' or
+     '--with-build-time-tools=PATHNAME'.
+
+     The following systems are the only ones where it makes a difference
+     whether you use the GNU assembler.  On any other system,
+     '--with-gnu-as' has no effect.
+
+        * 'hppa1.0-ANY-ANY'
+        * 'hppa1.1-ANY-ANY'
+        * 'sparc-sun-solaris2.ANY'
+        * 'sparc64-ANY-solaris2.ANY'
+
+'--with-as=PATHNAME'
+     Specify that the compiler should use the assembler pointed to by
+     PATHNAME, rather than the one found by the standard rules to find
+     an assembler, which are:
+        * Unless GCC is being built with a cross compiler, check the
+          'LIBEXEC/gcc/TARGET/VERSION' directory.  LIBEXEC defaults to
+          'EXEC-PREFIX/libexec'; EXEC-PREFIX defaults to PREFIX, which
+          defaults to '/usr/local' unless overridden by the
+          '--prefix=PATHNAME' switch described above.  TARGET is the
+          target system triple, such as 'sparc-sun-solaris2.7', and
+          VERSION denotes the GCC version, such as 3.0.
+
+        * If the target system is the same that you are building on,
+          check operating system specific directories (e.g.
+          '/usr/ccs/bin' on Sun Solaris 2).
+
+        * Check in the 'PATH' for a tool whose name is prefixed by the
+          target system triple.
+
+        * Check in the '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).
+
+     You may want to use '--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.
+
+'--with-gnu-ld'
+     Same as '--with-gnu-as' but for the linker.
+
+'--with-ld=PATHNAME'
+     Same as '--with-as' but for the linker.
+
+'--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 '--with-stabs' when you configure GCC.
+
+     No matter which default you choose when you configure GCC, the user
+     can use the '-gcoff' and '-gstabs+' options to specify explicitly
+     the debug format for a particular compilation.
+
+     '--with-stabs' is meaningful on the ISC system on the 386, also, if
+     '--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.
+
+     '--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.
+
+'--with-tls=DIALECT'
+     Specify the default TLS dialect, for systems were there is a
+     choice.  For ARM targets, possible values for DIALECT are 'gnu' or
+     'gnu2', which select between the original GNU dialect and the GNU
+     TLS descriptor-based dialect.
+
+'--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
+     '--with-sysroot', and without '--with-native-system-header-dir'.
+     More documentation about multiarch can be found at
+     <http://wiki.debian.org/Multiarch>.
+
+'--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 '--disable-libvtv' to turn off
+     building libvtv).  '--disable-vtable-verify' is the default.
+
+'--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., '--disable-softfloat'):
+     'arm-*-*'
+          fpu, 26bit, underscore, interwork, biendian, nofmult.
+
+     'm68*-*-*'
+          softfloat, m68881, m68000, m68020.
+
+     'mips*-*-*'
+          single-float, biendian, softfloat.
+
+     'powerpc*-*-*, rs6000*-*-*'
+          aix64, pthread, softfloat, powercpu, powerpccpu, powerpcos,
+          biendian, sysv, aix.
+
+'--with-multilib-list=LIST'
+'--without-multilib-list'
+     Specify what multilibs to build.  Currently only implemented for
+     sh*-*-* and x86-64-*-linux*.
+
+     'sh*-*-*'
+          LIST is a comma separated list of CPU names.  These must be of
+          the form 'sh*' or 'm*' (in which case they match the compiler
+          option for that processor).  The list should not contain any
+          endian options - these are handled by '--with-endian'.
+
+          If 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 '!'
+          (exclamation point), then it is added to the list of excluded
+          multilibs.  Entries of this sort should be compatible with
+          'MULTILIB_EXCLUDES' (once the leading '!' has been stripped).
+
+          If '--with-multilib-list' is not given, then a default set of
+          multilibs is selected based on the value of '--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:
+               --with-cpu=sh4a --with-endian=little,big --with-multilib-list=
+
+          Example 2: to configure a compiler for both SH4A and
+          SH4AL-DSP, but with only little endian SH4AL:
+               --with-cpu=sh4a --with-endian=little,big \
+               --with-multilib-list=sh4al,!mb/m4al
+
+     'x86-64-*-linux*'
+          LIST is a comma separated list of 'm32', 'm64' and 'mx32' to
+          enable 32-bit, 64-bit and x32 run-time libraries,
+          respectively.  If LIST is empty, then there will be no
+          multilibs and only the default run-time library will be
+          enabled.
+
+          If '--with-multilib-list' is not given, then only 32-bit and
+          64-bit run-time libraries will be enabled.
+
+'--with-endian=ENDIANS'
+     Specify what endians to use.  Currently only implemented for
+     sh*-*-*.
+
+     ENDIANS may be one of the following:
+     'big'
+          Use big endian exclusively.
+     'little'
+          Use little endian exclusively.
+     'big,little'
+          Use big endian by default.  Provide a multilib for little
+          endian.
+     'little,big'
+          Use little endian by default.  Provide a multilib for big
+          endian.
+
+'--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,
+     '--enable-threads' is an alias for '--enable-threads=single'.
+
+'--disable-threads'
+     Specify that threading support should be disabled for the system.
+     This is an alias for '--enable-threads=single'.
+
+'--enable-threads=LIB'
+     Specify that 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 LIB
+     are:
+
+     'aix'
+          AIX thread support.
+     'dce'
+          DCE thread support.
+     'lynx'
+          LynxOS thread support.
+     'mipssde'
+          MIPS SDE thread support.
+     'no'
+          This is an alias for 'single'.
+     'posix'
+          Generic POSIX/Unix98 thread support.
+     'rtems'
+          RTEMS thread support.
+     'single'
+          Disable thread support, should work for all platforms.
+     'tpf'
+          TPF thread support.
+     'vxworks'
+          VxWorks thread support.
+     'win32'
+          Microsoft Win32 API thread support.
+
+'--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 '--enable-tls' or '--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.
+
+'--disable-tls'
+     Specify that the target does not support TLS. This is an alias for
+     '--enable-tls=no'.
+
+'--with-cpu=CPU'
+'--with-cpu-32=CPU'
+'--with-cpu-64=CPU'
+     Specify which cpu variant the compiler should generate code for by
+     default.  CPU will be used as the default value of the '-mcpu='
+     switch.  This option is only supported on some targets, including
+     ARC, ARM, i386, M68k, PowerPC, and SPARC.  It is mandatory for ARC.
+     The '--with-cpu-32' and '--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.
+
+'--with-schedule=CPU'
+'--with-arch=CPU'
+'--with-arch-32=CPU'
+'--with-arch-64=CPU'
+'--with-tune=CPU'
+'--with-tune-32=CPU'
+'--with-tune-64=CPU'
+'--with-abi=ABI'
+'--with-fpu=TYPE'
+'--with-float=TYPE'
+     These configure options provide default values for the
+     '-mschedule=', '-march=', '-mtune=', '-mabi=', and '-mfpu=' options
+     and for '-mhard-float' or '-msoft-float'.  As with '--with-cpu',
+     which switches will be accepted and acceptable values of the
+     arguments depend on the target.
+
+'--with-mode=MODE'
+     Specify if the compiler should default to '-marm' or '-mthumb'.
+     This option is only supported on ARM targets.
+
+'--with-stack-offset=NUM'
+     This option sets the default for the -mstack-offset=NUM option, and
+     will thus generally also control the setting of this option for
+     libraries.  This option is only supported on Epiphany targets.
+
+'--with-fpmath=ISA'
+     This options sets '-mfpmath=sse' by default and specifies the
+     default ISA for floating-point arithmetics.  You can select either
+     'sse' which enables '-msse2' or 'avx' which enables '-mavx' by
+     default.  This option is only supported on i386 and x86-64 targets.
+
+'--with-nan=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 ENCODING are:
+     'legacy'
+          Use the legacy encoding, as with the '-mnan=legacy'
+          command-line option.
+     '2008'
+          Use the 754-2008 encoding, as with the '-mnan=2008'
+          command-line option.
+     To use this configuration option you must have an assembler version
+     installed that supports the '-mnan=' command-line option too.  In
+     the absence of this configuration option the default convention is
+     the legacy encoding, as when neither of the '-mnan=2008' and
+     '-mnan=legacy' command-line options has been used.
+
+'--with-divide=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 TYPE are:
+     'traps'
+          Division by zero checks use conditional traps (this is the
+          default on systems that support conditional traps).
+     'breaks'
+          Division by zero checks use the break instruction.
+
+'--with-llsc'
+     On MIPS targets, make '-mllsc' the default when no '-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.
+
+'--without-llsc'
+     On MIPS targets, make '-mno-llsc' the default when no '-mllsc'
+     option is passed.
+
+'--with-synci'
+     On MIPS targets, make '-msynci' the default when no '-mno-synci'
+     option is passed.
+
+'--without-synci'
+     On MIPS targets, make '-mno-synci' the default when no '-msynci'
+     option is passed.  This is the default.
+
+'--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.
+
+'--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 '-fuse-cxa-atexit' to be passed by default.
+
+'--enable-gnu-indirect-function'
+     Define if you want to enable the 'ifunc' attribute.  This option is
+     currently only available on systems with GNU libc on certain
+     targets.
+
+'--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.
+
+'--with-cpp-install-dir=DIRNAME'
+     Specify that the user visible 'cpp' program should be installed in
+     'PREFIX/DIRNAME/cpp', in addition to BINDIR.
+
+'--enable-comdat'
+     Enable COMDAT group support.  This is primarily used to override
+     the automatically detected value.
+
+'--enable-initfini-array'
+     Force the use of sections '.init_array' and '.fini_array' (instead
+     of '.init' and '.fini') for constructors and destructors.  Option
+     '--disable-initfini-array' has the opposite effect.  If neither
+     option is specified, the configure script will try to guess whether
+     the '.init_array' and '.fini_array' sections are supported and, if
+     they are, use them.
+
+'--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.
+
+'--enable-maintainer-mode'
+     The build rules that regenerate the Autoconf and Automake output
+     files as well as the GCC master message catalog '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
+     '--enable-maintainer-mode' will enable this.  Note that you need a
+     recent version of the 'gettext' tools to do so.
+
+'--disable-bootstrap'
+     For a native build, the default configuration is to perform a
+     3-stage bootstrap of the compiler when 'make' is invoked, testing
+     that GCC can compile itself correctly.  If you want to disable this
+     process, you can configure with '--disable-bootstrap'.
+
+'--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 '--enable-bootstrap'.
+
+'--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 '--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.
+
+'--enable-version-specific-runtime-libs'
+     Specify that runtime libraries should be installed in the compiler
+     specific subdirectory ('LIBDIR/gcc') rather than the usual places.
+     In addition, 'libstdc++''s include files will be installed into
+     'LIBDIR' unless you overruled it by using
+     '--with-gxx-include-dir=DIRNAME'.  Using this option is
+     particularly useful if you intend to use several versions of GCC in
+     parallel.  This is currently supported by 'libgfortran', 'libjava',
+     'libstdc++', and 'libobjc'.
+
+'--enable-languages=LANG1,LANG2,...'
+     Specify that only a particular subset of compilers and their
+     runtime libraries should be built.  For a list of valid values for
+     LANGN you can issue the following command in the 'gcc' directory of
+     your GCC source tree:
+          grep language= */config-lang.in
+     Currently, you can use any of the following: 'all', 'ada', 'c',
+     'c++', 'fortran', 'go', 'java', 'objc', 'obj-c++'.  Building the
+     Ada compiler has special requirements, see below.  If you do not
+     pass this flag, or specify the option 'all', then all default
+     languages available in the 'gcc' sub-tree will be configured.  Ada,
+     Go and Objective-C++ are not default languages; the rest are.
+
+'--enable-stage1-languages=LANG1,LANG2,...'
+     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 '--enable-languages', and the option 'all' will select all of
+     the languages enabled by '--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 'make stage1-bubble all-target', or run the testsuite on the
+     stage-1 compiler for the specified languages using 'make
+     stage1-start check-gcc'.
+
+'--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 'make -C gcc gnatlib_and_tools'.
+
+'--disable-libssp'
+     Specify that the run-time libraries for stack smashing protection
+     should not be built.
+
+'--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
+     '--disable-libquadmath-support' is used.
+
+'--disable-libquadmath-support'
+     Specify that the Fortran front end and 'libgfortran' do not add
+     support for 'libquadmath' on systems supporting it.
+
+'--disable-libgomp'
+     Specify that the run-time libraries used by GOMP should not be
+     built.
+
+'--disable-libvtv'
+     Specify that the run-time libraries used by vtable verification
+     should not be built.
+
+'--with-dwarf2'
+     Specify that the compiler should use DWARF 2 debugging information
+     as the default.
+
+'--enable-targets=all'
+'--enable-targets=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.
+
+'--enable-secureplt'
+     This option enables '-msecure-plt' by default for powerpc-linux.
+     *Note RS/6000 and PowerPC Options: (gcc)RS/6000 and PowerPC
+     Options,
+
+'--enable-cld'
+     This option enables '-mcld' by default for 32-bit x86 targets.
+     *Note i386 and x86-64 Options: (gcc)i386 and x86-64 Options,
+
+'--enable-win32-registry'
+'--enable-win32-registry=KEY'
+'--disable-win32-registry'
+     The '--enable-win32-registry' option enables Microsoft
+     Windows-hosted GCC to look up installations paths in the registry
+     using the following key:
+
+          HKEY_LOCAL_MACHINE\SOFTWARE\Free Software Foundation\KEY
+
+     KEY defaults to GCC version number, and can be overridden by the
+     '--enable-win32-registry=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
+     '--disable-win32-registry' option.  This option has no effect on
+     the other hosts.
+
+'--nfp'
+     Specify that the machine does not have a floating point unit.  This
+     option only applies to 'm68k-sun-sunosN'.  On any other system,
+     '--nfp' has no effect.
+
+'--enable-werror'
+'--disable-werror'
+'--enable-werror=yes'
+'--enable-werror=no'
+     When you specify this option, it controls whether certain files in
+     the compiler are built with '-Werror' in bootstrap stage2 and
+     later.  If you don't specify it, '-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
+     '-Werror' are controlled by the Makefiles.
+
+'--enable-checking'
+'--enable-checking=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 'yes'
+     by default when building from SVN or snapshots, but 'release' for
+     releases.  The default for building the stage1 compiler is 'yes'.
+     More control over the checks may be had by specifying LIST.  The
+     categories of checks available are 'yes' (most common checks
+     'assert,misc,tree,gc,rtlflag,runtime'), 'no' (no checks at all),
+     'all' (all but 'valgrind'), 'release' (cheapest checks
+     'assert,runtime') or 'none' (same as 'no').  Individual checks can
+     be enabled with these flags 'assert', 'df', 'fold', 'gc', 'gcac'
+     'misc', 'rtl', 'rtlflag', 'runtime', 'tree', and 'valgrind'.
+
+     The 'valgrind' check requires the external 'valgrind' simulator,
+     available from <http://valgrind.org/>.  The 'df', 'rtl', 'gcac' and
+     'valgrind' checks are very expensive.  To disable all checking,
+     '--disable-checking' or '--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.
+
+'--disable-stage1-checking'
+'--enable-stage1-checking'
+'--enable-stage1-checking=LIST'
+     If no '--enable-checking' option is specified the stage1 compiler
+     will be built with 'yes' checking enabled, otherwise the stage1
+     checking flags are the same as specified by '--enable-checking'.
+     To build the stage1 compiler with different checking options use
+     '--enable-stage1-checking'.  The list of checking options is the
+     same as for '--enable-checking'.  If your system is too slow or too
+     small to bootstrap a released compiler with checking for stage1
+     enabled, you can use '--disable-stage1-checking' to disable
+     checking for the stage1 compiler.
+
+'--enable-coverage'
+'--enable-coverage=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 LEVEL argument controls whether the compiler
+     is built optimized or not, values are 'opt' and '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.
+
+'--enable-gather-detailed-mem-stats'
+     When this option is specified more detailed information on memory
+     allocation is gathered.  This information is printed when using
+     '-fmem-report'.
+
+'--enable-nls'
+'--disable-nls'
+     The '--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 '--disable-nls' option disables
+     NLS.
+
+'--with-included-gettext'
+     If NLS is enabled, the '--with-included-gettext' option causes the
+     build procedure to prefer its copy of GNU 'gettext'.
+
+'--with-catgets'
+     If NLS is enabled, and if the host lacks 'gettext' but has the
+     inferior 'catgets' interface, the GCC build procedure normally
+     ignores 'catgets' and instead uses GCC's copy of the GNU 'gettext'
+     library.  The '--with-catgets' option causes the build procedure to
+     use the host's 'catgets' in this situation.
+
+'--with-libiconv-prefix=DIR'
+     Search for libiconv header files in 'DIR/include' and libiconv
+     library files in 'DIR/lib'.
+
+'--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.
+
+'--enable-decimal-float'
+'--enable-decimal-float=yes'
+'--enable-decimal-float=no'
+'--enable-decimal-float=bid'
+'--enable-decimal-float=dpd'
+'--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 'bid' or 'dpd').  The 'bid'
+     (binary integer decimal) format is default on i386 and x86_64
+     systems, and the 'dpd' (densely packed decimal) format is default
+     on PowerPC systems.
+
+'--enable-fixed-point'
+'--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.
+
+'--with-long-double-128'
+     Specify if 'long double' type should be 128-bit by default on
+     selected GNU/Linux architectures.  If using
+     '--without-long-double-128', 'long double' will be by default
+     64-bit, the same as 'double' type.  When neither of these configure
+     options are used, the default will be 128-bit 'long double' when
+     built against GNU C Library 2.4 and later, 64-bit 'long double'
+     otherwise.
+
+'--with-gmp=PATHNAME'
+'--with-gmp-include=PATHNAME'
+'--with-gmp-lib=PATHNAME'
+'--with-mpfr=PATHNAME'
+'--with-mpfr-include=PATHNAME'
+'--with-mpfr-lib=PATHNAME'
+'--with-mpc=PATHNAME'
+'--with-mpc-include=PATHNAME'
+'--with-mpc-lib=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
+     ('--with-gmp=GMPINSTALLDIR', '--with-mpfr=MPFRINSTALLDIR',
+     '--with-mpc=MPCINSTALLDIR').  The '--with-gmp=GMPINSTALLDIR' option
+     is shorthand for '--with-gmp-lib=GMPINSTALLDIR/lib' and
+     '--with-gmp-include=GMPINSTALLDIR/include'.  Likewise the
+     '--with-mpfr=MPFRINSTALLDIR' option is shorthand for
+     '--with-mpfr-lib=MPFRINSTALLDIR/lib' and
+     '--with-mpfr-include=MPFRINSTALLDIR/include', also the
+     '--with-mpc=MPCINSTALLDIR' option is shorthand for
+     '--with-mpc-lib=MPCINSTALLDIR/lib' and
+     '--with-mpc-include=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 ('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.
+
+'--with-isl=PATHNAME'
+'--with-isl-include=PATHNAME'
+'--with-isl-lib=PATHNAME'
+'--with-cloog=PATHNAME'
+'--with-cloog-include=PATHNAME'
+'--with-cloog-lib=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
+     ('--with-isl=ISLINSTALLDIR', '--with-cloog=CLOOGINSTALLDIR').  The
+     '--with-isl=ISLINSTALLDIR' option is shorthand for
+     '--with-isl-lib=ISLINSTALLDIR/lib' and
+     '--with-isl-include=ISLINSTALLDIR/include'.  Likewise the
+     '--with-cloog=CLOOGINSTALLDIR' option is shorthand for
+     '--with-cloog-lib=CLOOGINSTALLDIR/lib' and
+     '--with-cloog-include=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.
+
+'--with-host-libstdcxx=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 LINKER-ARGS might
+     be '-lstdc++' or '-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.
+
+'--with-stage1-ldflags=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 '--disable-bootstrap'.  By default no special flags are used.
+
+'--with-stage1-libs=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 '--disable-bootstrap'.  The default is the argument to
+     '--with-host-libstdcxx', if specified.
+
+'--with-boot-ldflags=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 '-static-libstdc++ -static-libgcc'.
+
+'--with-boot-libs=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 '--with-host-libstdcxx', if specified.
+
+'--with-debug-prefix-map=MAP'
+     Convert source directory names using '-fdebug-prefix-map' when
+     building runtime libraries.  'MAP' is a space-separated list of
+     maps of the form 'OLD=NEW'.
+
+'--enable-linker-build-id'
+     Tells GCC to pass '--build-id' option to the linker for all final
+     links (links performed without the '-r' or '--relocatable' option),
+     if the linker supports it.  If you specify
+     '--enable-linker-build-id', but your linker does not support
+     '--build-id' option, a warning is issued and the
+     '--enable-linker-build-id' option is ignored.  The default is off.
+
+'--with-linker-hash-style=CHOICE'
+     Tells GCC to pass '--hash-style=CHOICE' option to the linker for
+     all final links.  CHOICE can be one of 'sysv', 'gnu', and 'both'
+     where 'sysv' is the default.
+
+'--enable-gnu-unique-object'
+'--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.
+
+'--enable-lto'
+'--disable-lto'
+     Enable support for link-time optimization (LTO). This is enabled by
+     default, and may be disabled using '--disable-lto'.
+
+'--with-plugin-ld=PATHNAME'
+     Enable an alternate linker to be used at link-time optimization
+     (LTO) link time when '-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 '-fuse-linker-plugin'
+     for details.
+
+'--enable-canonical-system-headers'
+'--disable-canonical-system-headers'
+     Enable system header path canonicalization for '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 '--disable-canonical-system-headers'.
+
+'--with-glibc-version=MAJOR.MINOR'
+     Tell GCC that when the GNU C Library (glibc) is used on the target
+     it will be version MAJOR.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.
+
+Cross-Compiler-Specific Options
+-------------------------------
+
+The following options only apply to building cross compilers.
+
+'--with-sysroot'
+'--with-sysroot=DIR'
+     Tells GCC to consider 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
+     '--sysroot=DIR' was added to the default options of the built
+     compiler.  The specified directory is not copied into the install
+     tree, unlike the options '--with-headers' and '--with-libs' that
+     this option obsoletes.  The default value, in case '--with-sysroot'
+     is not given an argument, is '${gcc_tooldir}/sys-root'.  If the
+     specified directory is a subdirectory of '${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 'make install'; it does not affect the
+     compiler which is used to build GCC itself.
+
+     If you specify the '--with-native-system-header-dir=DIRNAME' option
+     then the compiler will search that directory within DIRNAME for
+     native system headers rather than the default '/usr/include'.
+
+'--with-build-sysroot'
+'--with-build-sysroot=DIR'
+     Tells GCC to consider DIR as the system root (see '--with-sysroot')
+     while building target libraries, instead of the directory specified
+     with '--with-sysroot'.  This option is only useful when you are
+     already using '--with-sysroot'.  You can use '--with-build-sysroot'
+     when you are configuring with '--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 '--with-native-system-header-dir=DIRNAME' option
+     then the compiler will search that directory within DIRNAME for
+     native system headers rather than the default '/usr/include'.
+
+'--with-headers'
+'--with-headers=DIR'
+     Deprecated in favor of '--with-sysroot'.  Specifies that target
+     headers are available when building a cross compiler.  The DIR
+     argument specifies a directory which has the target include files.
+     These include files will be copied into the 'gcc' install
+     directory.  _This option with the DIR argument is required_ when
+     building a cross compiler, if 'PREFIX/TARGET/sys-include' doesn't
+     pre-exist.  If 'PREFIX/TARGET/sys-include' does pre-exist, the DIR
+     argument may be omitted.  'fixincludes' will be run on these files
+     to make them compatible with GCC.
+
+'--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.
+
+'--with-libs'
+'--with-libs="DIR1 DIR2 ... DIRN"'
+     Deprecated in favor of '--with-sysroot'.  Specifies a list of
+     directories which contain the target runtime libraries.  These
+     libraries will be copied into the 'gcc' install directory.  If the
+     directory list is omitted, this option has no effect.
+
+'--with-newlib'
+     Specifies that 'newlib' is being used as the target C library.
+     This causes '__eprintf' to be omitted from 'libgcc.a' on the
+     assumption that it will be provided by 'newlib'.
+
+'--with-avrlibc'
+     Specifies that 'AVR-Libc' is being used as the target C library.
+     This causes float support functions like '__addsf3' to be omitted
+     from 'libgcc.a' on the assumption that it will be provided by
+     'libm.a'.  For more technical details, cf.  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.
+
+'--with-nds32-lib=LIBRARY'
+     Specifies that LIBRARY setting is used for building 'libgcc.a'.
+     Currently, the valid LIBRARY is 'newlib' or 'mculib'.  This option
+     is only supported for the NDS32 target.
+
+'--with-build-time-tools=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 'ia64-hp-hpux' system, you may have the GNU
+     assembler and linker in '/usr/bin', and the native tools in a
+     different path, and build a toolchain that expects to find the
+     native tools in '/usr/bin'.
+
+     When you use this option, you should ensure that DIR includes 'ar',
+     'as', 'ld', 'nm', 'ranlib' and 'strip' if necessary, and possibly
+     'objdump'.  Otherwise, GCC may use an inconsistent set of tools.
+
+Java-Specific Options
+---------------------
+
+The following option applies to the build of the Java front end.
+
+'--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 'libgcj' isn't built, you may need to port it;
+     in this case, before modifying the top-level 'configure.in' so that
+     'libgcj' is enabled by default on this platform, you may use
+     '--enable-libgcj' to override the default.
+
+   The following options apply to building 'libgcj'.
+
+General Options
+...............
+
+'--enable-java-maintainer-mode'
+     By default the 'libjava' build will not attempt to compile the
+     '.java' source files to '.class'.  Instead, it will use the
+     '.class' files from the source tree.  If you use this option you
+     must have executables named 'ecj1' and 'gjavah' in your path for
+     use by the build.  You must use this option if you intend to modify
+     any '.java' files in 'libjava'.
+
+'--with-java-home=DIRNAME'
+     This 'libjava' option overrides the default value of the
+     'java.home' system property.  It is also used to set
+     'sun.boot.class.path' to 'DIRNAME/lib/rt.jar'.  By default
+     'java.home' is set to 'PREFIX' and 'sun.boot.class.path' to
+     'DATADIR/java/libgcj-VERSION.jar'.
+
+'--with-ecj-jar=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 'gcj' to parse '.java' source
+     files.  If this option is given, the 'libjava' build will create
+     and install an 'ecj1' executable which uses this jar file at
+     runtime.
+
+     If this option is not given, but an 'ecj.jar' file is found in the
+     topmost source tree at configure time, then the 'libgcj' build will
+     create and install 'ecj1', and will also install the discovered
+     'ecj.jar' into a suitable place in the install tree.
+
+     If 'ecj1' is not installed, then the user will have to supply one
+     on his path in order for 'gcj' to properly parse '.java' source
+     files.  A suitable jar is available from
+     <ftp://sourceware.org/pub/java/>.
+
+'--disable-getenv-properties'
+     Don't set system properties from 'GCJ_PROPERTIES'.
+
+'--enable-hash-synchronization'
+     Use a global hash table for monitor locks.  Ordinarily, 'libgcj''s
+     '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.
+
+'--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
+     '--disable-interpreter').
+
+'--disable-java-net'
+     Disable java.net.  This disables the native part of java.net only,
+     using non-functional stubs for native method implementations.
+
+'--disable-jvmpi'
+     Disable JVMPI support.
+
+'--disable-libgcj-bc'
+     Disable BC ABI compilation of certain parts of libgcj.  By default,
+     some portions of libgcj are compiled with '-findirect-dispatch' and
+     '-fno-indirect-classes', allowing them to be overridden at
+     run-time.
+
+     If '--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.
+
+'--enable-reduced-reflection'
+     Build most of libgcj with '-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).
+
+'--with-ecos'
+     Enable runtime eCos target support.
+
+'--without-libffi'
+     Don't use 'libffi'.  This will disable the interpreter and JNI
+     support as well, as these require 'libffi' to work.
+
+'--enable-libgcj-debug'
+     Enable runtime debugging code.
+
+'--enable-libgcj-multifile'
+     If specified, causes all '.java' source files to be compiled into
+     '.class' files in one invocation of 'gcj'.  This can speed up build
+     time, but is more resource-intensive.  If this option is
+     unspecified or disabled, 'gcj' is invoked once for each '.java'
+     file to compile into a '.class' file.
+
+'--with-libiconv-prefix=DIR'
+     Search for libiconv in 'DIR/include' and 'DIR/lib'.
+
+'--enable-sjlj-exceptions'
+     Force use of the 'setjmp'/'longjmp'-based scheme for exceptions.
+     'configure' ordinarily picks the correct value based on the
+     platform.  Only use this option if you are sure you need a
+     different setting.
+
+'--with-system-zlib'
+     Use installed 'zlib' rather than that included with GCC.
+
+'--with-win32-nlsapi=ansi, unicows or unicode'
+     Indicates how MinGW 'libgcj' translates between UNICODE characters
+     and the Win32 API.
+
+'--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.
+
+'--with-arch-directory=ARCH'
+     Specifies the name to use for the '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.
+
+'--with-os-directory=DIR'
+     Specifies the OS directory for the SDK include directory.  This is
+     set to auto detect, and is typically 'linux'.
+
+'--with-origin-name=NAME'
+     Specifies the JPackage origin name.  This defaults to the 'gcj' in
+     java-1.5.0-gcj.
+
+'--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'.
+
+'--with-jvm-root-dir=DIR'
+     Specifies where to install the SDK. Default is $(prefix)/lib/jvm.
+
+'--with-jvm-jar-dir=DIR'
+     Specifies where to install jars.  Default is
+     $(prefix)/lib/jvm-exports.
+
+'--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.
+
+'--enable-aot-compile-rpm'
+     Adds aot-compile-rpm to the list of installed scripts.
+
+'--enable-browser-plugin'
+     Build the gcjwebplugin web browser plugin.
+
+'--enable-static-libjava'
+     Build static libraries in libjava.  The default is to only build
+     shared libraries.
+
+     'ansi'
+          Use the single-byte 'char' and the Win32 A functions natively,
+          translating to and from UNICODE when using these functions.
+          If unspecified, this is the default.
+
+     'unicows'
+          Use the 'WCHAR' and Win32 W functions natively.  Adds
+          '-lunicows' to 'libgcj.spec' to link with 'libunicows'.
+          'unicows.dll' needs to be deployed on Microsoft Windows 9X
+          machines running built executables.  'libunicows.a', an
+          open-source import library around Microsoft's 'unicows.dll',
+          is obtained from <http://libunicows.sourceforge.net/>, which
+          also gives details on getting 'unicows.dll' from Microsoft.
+
+     'unicode'
+          Use the 'WCHAR' and Win32 W functions natively.  Does _not_
+          add '-lunicows' to 'libgcj.spec'.  The built executables will
+          only run on Microsoft Windows NT and above.
+
+AWT-Specific Options
+....................
+
+'--with-x'
+     Use the X Window System.
+
+'--enable-java-awt=PEER(S)'
+     Specifies the AWT peer library or libraries to build alongside
+     'libgcj'.  If this option is unspecified or disabled, AWT will be
+     non-functional.  Current valid values are 'gtk' and 'xlib'.
+     Multiple libraries should be separated by a comma (i.e.
+     '--enable-java-awt=gtk,xlib').
+
+'--enable-gtk-cairo'
+     Build the cairo Graphics2D implementation on GTK.
+
+'--enable-java-gc=TYPE'
+     Choose garbage collector.  Defaults to 'boehm' if unspecified.
+
+'--disable-gtktest'
+     Do not try to compile and run a test GTK+ program.
+
+'--disable-glibtest'
+     Do not try to compile and run a test GLIB program.
+
+'--with-libart-prefix=PFX'
+     Prefix where libart is installed (optional).
+
+'--with-libart-exec-prefix=PFX'
+     Exec prefix where libart is installed (optional).
+
+'--disable-libarttest'
+     Do not try to compile and run a test libart program.
+
+Overriding 'configure' test results
+...................................
+
+Sometimes, it might be necessary to override the result of some
+'configure' test, for example in order to ease porting to a new system
+or work around a bug in a test.  The toplevel 'configure' script
+provides three variables for this:
+
+'build_configargs'
+     The contents of this variable is passed to all build 'configure'
+     scripts.
+
+'host_configargs'
+     The contents of this variable is passed to all host 'configure'
+     scripts.
+
+'target_configargs'
+     The contents of this variable is passed to all target 'configure'
+     scripts.
+
+   In order to avoid shell and 'make' quoting issues for complex
+overrides, you can pass a setting for 'CONFIG_SITE' and set variables in
+the site file.
+
+
+File: gccinstall.info,  Node: Building,  Next: Testing,  Prev: Configuration,  Up: Installing GCC
+
+5 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 '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 '--disable-werror'.
+
+   On certain old systems, defining certain environment variables such
+as 'CC' can interfere with the functioning of '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 'fixincludes' if the
+System V file system doesn't support symbolic links.  These problems
+result in a failure to fix the declaration of 'size_t' in 'sys/types.h'.
+If you find that '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
+'*.l' files, you need the Flex lexical analyzer generator installed.  If
+you do not modify '*.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.
+
+5.1 Building a native compiler
+==============================
+
+For a native build, the default configuration is to perform a 3-stage
+bootstrap of the compiler when 'make' is invoked.  This will build the
+entire GCC system and ensure that it compiles itself correctly.  It can
+be disabled with the '--disable-bootstrap' parameter to '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:
+
+   * Build tools necessary to build the compiler.
+
+   * 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.
+
+   * Perform a comparison test of the stage2 and stage3 compilers.
+
+   * Build runtime libraries using the stage3 compiler from the previous
+     step.
+
+   If you are short on disk space you might consider '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 'BOOT_CFLAGS' on the command line when doing
+'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.)
+
+     make BOOT_CFLAGS='-O' bootstrap
+
+   You can place non-default optimization flags into 'BOOT_CFLAGS'; they
+are less well tested here than the default of '-g -O2', but should still
+work.  In a few cases, you may find that you need to specify special
+flags such as '-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 'BOOT_CFLAGS' to avoid the parts of the stage1
+compiler that were miscompiled, or by using 'make bootstrap4' to
+increase the number of stages of bootstrap.
+
+   'BOOT_CFLAGS' does not apply to bootstrapped target libraries.  Since
+these are always compiled with the compiler currently being
+bootstrapped, you can use '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 'STAGE1_TFLAGS' to this end.
+
+   If you used the flag '--enable-languages=...' 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
+'LANGUAGES' when calling 'make' *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 'Makefile'.)
+
+   If you do not want to bootstrap your compiler, you can configure with
+'--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
+'powerpc-unknown-linux-gnu' toolchain on a 'powerpc64-unknown-linux-gnu'
+host.  In this case, pass '--enable-bootstrap' to the configure script.
+
+   '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 'NAME', top-level 'config/NAME.mk' will be included by the
+top-level 'Makefile', bringing in any settings it contains.  The default
+'BUILD_CONFIG' can be set using the configure option
+'--with-build-config=NAME...'.  Some examples of supported build
+configurations are:
+
+'bootstrap-O1'
+     Removes any '-O'-started option from 'BOOT_CFLAGS', and adds '-O1'
+     to it.  'BUILD_CONFIG=bootstrap-O1' is equivalent to
+     'BOOT_CFLAGS='-g -O1''.
+
+'bootstrap-O3'
+     Analogous to 'bootstrap-O1'.
+
+'bootstrap-lto'
+     Enables Link-Time Optimization for host tools during bootstrapping.
+     'BUILD_CONFIG=bootstrap-lto' is equivalent to adding '-flto' to
+     'BOOT_CFLAGS'.
+
+'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 'contrib/compare-debug' to compare them with the stripped
+     stage3 object files.  If '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 '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.
+
+'bootstrap-debug-big'
+     Rather than comparing stripped object files, as in
+     '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 'bootstrap-debug'.
+
+'bootstrap-debug-lean'
+     This option saves disk space compared with '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
+     '-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.
+
+'bootstrap-debug-lib'
+     This option tests executable code invariance over debug information
+     generation on target libraries, just like 'bootstrap-debug-lean'
+     tests it on host programs.  It builds stage3 libraries with
+     '-fcompare-debug', and it can be used along with any of the
+     'bootstrap-debug' options above.
+
+     There aren't '-lean' or '-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.
+
+'bootstrap-debug-ckovw'
+     Arranges for error messages to be issued if the compiler built on
+     any stage is run without the option '-fcompare-debug'.  This is
+     useful to verify the full '-fcompare-debug' testing coverage.  It
+     must be used along with 'bootstrap-debug-lean' and
+     'bootstrap-debug-lib'.
+
+'bootstrap-time'
+     Arranges for the run time of each program started by the GCC
+     driver, built in any stage, to be logged to 'time.log', in the top
+     level of the build tree.
+
+5.2 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 '--with-ecj-jar=...'.
+
+   Assuming you have already installed a native copy of GCC and
+configured your cross compiler, issue the command 'make', which performs
+the following steps:
+
+   * Build host tools necessary to build the compiler.
+
+   * 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.
+
+   * Build the compiler (single stage only).
+
+   * Build runtime libraries using the compiler from the previous step.
+
+   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 'PREFIX/TARGET/bin'.  Here
+is a table of the tools you should put in this directory:
+
+'as'
+     This should be the cross-assembler.
+
+'ld'
+     This should be the cross-linker.
+
+'ar'
+     This should be the cross-archiver: a program which can manipulate
+     archive files (linker libraries) in the target machine's format.
+
+'ranlib'
+     This should be a program to construct a symbol table in an archive
+     file.
+
+   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 '--host' and '--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 '--with-sysroot' or
+'--with-headers' and '--with-libs'.  Many targets also require "start
+files" such as 'crt0.o' and 'crtn.o' which are linked into each
+executable.  There may be several alternatives for 'crt0.o', for use
+with profiling or other compilation options.  Check your target's
+definition of 'STARTFILE_SPEC' to find out what start files it uses.
+
+5.3 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 'make -j 2' instead
+of '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.
+
+5.4 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
+'gnatmake' and '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.
+
+   '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 '--enable-languages' is used to disable
+building the Ada front end.
+
+   'ADA_INCLUDE_PATH' and '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 'gnatls -v' lists only one explicit path in each
+section.
+
+5.5 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 'make
+profiledbootstrap'.
+
+   When 'make profiledbootstrap' is run, it will first build a 'stage1'
+compiler.  This compiler is used to build a 'stageprofile' compiler
+instrumented to collect execution counts of instruction and branch
+probabilities.  Then runtime libraries are compiled with profile
+collected.  Finally a 'stagefeedback' compiler is built using the
+information collected.
+
+   Unlike standard bootstrap, several additional restrictions apply.
+The compiler used to build '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.
+
+
+File: gccinstall.info,  Node: Testing,  Next: Final install,  Prev: Building,  Up: Installing GCC
+
+6 Installing GCC: Testing
+*************************
+
+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 gcc-testresults mailing list.  Some of these
+archived results are linked from the build status lists at
+<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 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
+DejaGnu, Tcl, and Expect; the DejaGnu site has links to these.
+
+   If the directories where 'runtest' and 'expect' were installed are
+not in the 'PATH', you may need to set the following environment
+variables appropriately, as in the following example (which assumes that
+DejaGnu has been installed under '/usr/local'):
+
+     TCL_LIBRARY = /usr/local/share/tcl8.0
+     DEJAGNULIBS = /usr/local/share/dejagnu
+
+   (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):
+     cd OBJDIR; make -k check
+
+   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 'WARNING: Couldn't find the global
+config file.' or '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
+<http://gcc.gnu.org/simtest-howto.html>.
+
+6.1 How can you run the testsuite on selected tests?
+====================================================
+
+In order to run sets of tests selectively, there are targets 'make
+check-gcc' and language specific 'make check-c', 'make check-c++', 'make
+check-fortran', 'make check-java', 'make check-ada', 'make check-objc',
+'make check-obj-c++', 'make check-lto' in the 'gcc' subdirectory of the
+object directory.  You can also just run 'make check' in a subdirectory
+of the object directory.
+
+   A more selective way to just run all 'gcc' execute tests in the
+testsuite is to use
+
+     make check-gcc RUNTESTFLAGS="execute.exp OTHER-OPTIONS"
+
+   Likewise, in order to run only the 'g++' "old-deja" tests in the
+testsuite with filenames matching '9805*', you would use
+
+     make check-g++ RUNTESTFLAGS="old-deja.exp=9805* OTHER-OPTIONS"
+
+   The '*.exp' files are located in the testsuite directories of the GCC
+source, the most important ones being 'compile.exp', 'execute.exp',
+'dg.exp' and 'old-deja.exp'.  To get a list of the possible '*.exp'
+files, pipe the output of 'make check' into a file and look at the
+'Running ... .exp' lines.
+
+6.2 Passing options and running multiple testsuites
+===================================================
+
+You can pass multiple options to the testsuite using the
+'--target_board' option of DejaGNU, either passed as part of
+'RUNTESTFLAGS', or directly to 'runtest' if you prefer to work outside
+the makefiles.  For example,
+
+     make check-g++ RUNTESTFLAGS="--target_board=unix/-O3/-fmerge-constants"
+
+   will run the standard 'g++' testsuites ("unix" is the target name for
+a standard native testsuite situation), passing '-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:
+
+     ..."--target_board=arm-sim\{-mhard-float,-msoft-float\}\{-O1,-O2,-O3,\}"
+
+   (Note the empty option caused by the trailing comma in the final
+group.)  The following will run each testsuite eight times using the
+'arm-sim' target, as if you had specified all possible combinations
+yourself:
+
+     --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'
+
+   They can be combined as many times as you wish, in arbitrary ways.
+This list:
+
+     ..."--target_board=unix/-Wextra\{-O3,-fno-strength\}\{-fomit-frame,\}"
+
+   will generate four combinations, all involving '-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
+'make' do the parallel runs.  Instead of using '--target_board', use a
+special makefile target:
+
+     make -jN check-TESTSUITE//TEST-TARGET/OPTION1/OPTION2/...
+
+   For example,
+
+     make -j3 check-gcc//sh-hms-sim/{-m1,-m2,-m3,-m3e,-m4}/{,-nofpu}
+
+   will run three concurrent "make-gcc" testsuites, eventually testing
+all ten combinations as described above.  Note that this is currently
+only supported in the 'gcc' subdirectory.  (To see how this works, try
+typing 'echo' before the example given here.)
+
+6.3 Additional testing for Java Class Libraries
+===============================================
+
+The Java runtime tests can be executed via 'make check' in the
+'TARGET/libjava/testsuite' directory in the build tree.
+
+   The 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
+'libjava/testsuite/libjava.mauve/mauve', or by specifying the location
+of that tree when invoking 'make', as in 'make MAUVEDIR=~/mauve check'.
+
+6.4 How to interpret test results
+=================================
+
+The result of running the testsuite are various '*.sum' and '*.log'
+files in the testsuite subdirectories.  The '*.log' files contain a
+detailed log of the compiler invocations and the corresponding results,
+the '*.sum' files summarize the results.  These summaries contain status
+codes for all tests:
+
+   * PASS: the test passed as expected
+   * XPASS: the test unexpectedly passed
+   * FAIL: the test unexpectedly failed
+   * XFAIL: the test failed as expected
+   * UNSUPPORTED: the test is not supported on this platform
+   * ERROR: the testsuite detected an error
+   * WARNING: the testsuite detected a possible problem
+
+   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.
+
+6.5 Submitting test results
+===========================
+
+If you want to report the results to the GCC project, use the
+'contrib/test_summary' shell script.  Start it in the OBJDIR with
+
+     SRCDIR/contrib/test_summary -p your_commentary.txt \
+         -m gcc-testresults@gcc.gnu.org |sh
+
+   This script uses the 'Mail' program to send the results, so make sure
+it is in your 'PATH'.  The 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.
+
+
+File: gccinstall.info,  Node: Final install,  Prev: Testing,  Up: Installing GCC
+
+7 Installing GCC: Final installation
+************************************
+
+Now that GCC has been built (and optionally tested), you can install it
+with
+     cd OBJDIR && make install
+
+   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 'PREFIX/bin' where PREFIX is the value you specified with
+the '--prefix' to configure (or '/usr/local' by default).  (If you
+specified '--bindir', that directory will be used instead; otherwise, if
+you specified '--exec-prefix', 'EXEC-PREFIX/bin' will be used.)  Headers
+for the C++ and Java libraries are installed in 'PREFIX/include';
+libraries in 'LIBDIR' (normally 'PREFIX/lib'); internal parts of the
+compiler in 'LIBDIR/gcc' and 'LIBEXECDIR/gcc'; documentation in info
+format in 'INFODIR' (normally 'PREFIX/info').
+
+   When installing cross-compilers, GCC's executables are not only
+installed into 'BINDIR', that is, 'EXEC-PREFIX/bin', but additionally
+into 'EXEC-PREFIX/TARGET-ALIAS/bin', if that directory exists.
+Typically, such "tooldirs" hold target-specific binutils, including
+assembler and linker.
+
+   Installation into a temporary staging area or into a 'chroot' jail
+can be achieved with the command
+
+     make DESTDIR=PATH-TO-ROOTDIR install
+
+where 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 'DESTDIR' need not exist yet; it will be created
+if necessary.
+
+   There is a subtle point with tooldirs and 'DESTDIR': If you relocate
+a cross-compiler installation with e.g. 'DESTDIR=ROOTDIR', then the
+directory 'ROOTDIR/EXEC-PREFIX/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 'DESTDIR'
+feature.
+
+   You can install stripped programs and libraries with
+
+     make install-strip
+
+   If you are bootstrapping a released version of GCC then please
+quickly review the build status page for your release, available from
+<http://gcc.gnu.org/buildstat.html>.  If your system is not listed for
+the version of GCC that you built, send a note to <gcc@gcc.gnu.org>
+indicating that you successfully built and installed GCC.  Include the
+following information:
+
+   * Output from running 'SRCDIR/config.guess'.  Do not send that file
+     itself, just the one-line output from running it.
+
+   * The output of 'gcc -v' for your newly installed 'gcc'.  This tells
+     us which version of GCC you built and the options you passed to
+     configure.
+
+   * 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 '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.
+
+   * If the build was for GNU/Linux, also include:
+        * The distribution name and version (e.g., Red Hat 7.1 or Debian
+          2.2.3); this information should be available from
+          '/etc/issue'.
+
+        * The version of the Linux kernel, available from 'uname
+          --version' or 'uname -a'.
+
+        * The version of glibc you used; for RPM-based systems like Red
+          Hat, Mandrake, and SuSE type 'rpm -q glibc' to get the glibc
+          version, and on systems like Debian and Progeny use 'dpkg -l
+          libc6'.
+     For other systems, you can include similar information if you think
+     it is relevant.
+
+   * 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.
+
+   We'd also like to know if the *note host/target specific installation
+notes: Specific. didn't include your host/target information or if that
+information is incomplete or out of date.  Send a note to
+<gcc@gcc.gnu.org> detailing how the information should be changed.
+
+   If you find a bug, please report it following the bug reporting
+guidelines.
+
+   If you want to print the GCC manuals, do 'cd OBJDIR; make dvi'.  You
+will need to have 'texi2dvi' (version at least 4.7) and TeX installed.
+This creates a number of '.dvi' files in subdirectories of 'OBJDIR';
+these may be converted for printing with programs such as 'dvips'.
+Alternately, by using 'make pdf' in place of 'make dvi', you can create
+documentation in the form of '.pdf' files; this requires 'texi2pdf',
+which is included with Texinfo version 4.8 and later.  You can also 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 'cd
+OBJDIR; make html' and HTML will be generated for the gcc manuals in
+'OBJDIR/gcc/HTML'.
+
+
+File: gccinstall.info,  Node: Binaries,  Next: Specific,  Prev: Installing GCC,  Up: Top
+
+8 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.
+
+   * AIX:
+        * Bull's Freeware and Shareware Archive for AIX;
+
+        * Hudson Valley Community College Open Source Software for IBM
+          System p;
+
+        * AIX 5L and 6 Open Source Packages.
+
+   * DOS--DJGPP.
+
+   * Renesas H8/300[HS]--GNU Development Tools for the Renesas
+     H8/300[HS] Series.
+
+   * HP-UX:
+        * HP-UX Porting Center;
+
+        * Binaries for HP-UX 11.00 at Aachen University of Technology.
+
+   * SCO OpenServer/Unixware.
+
+   * Solaris 2 (SPARC, Intel):
+        * Sunfreeware
+
+        * Blastwave
+
+        * OpenCSW
+
+        * TGCware
+
+   * Microsoft Windows:
+        * The Cygwin project;
+        * The MinGW project.
+
+   * 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.
+
+   * OpenPKG offers binaries for quite a number of platforms.
+
+   * The GFortran Wiki has links to GNU Fortran binaries for several
+     platforms.
+
+
+File: gccinstall.info,  Node: Specific,  Next: Old,  Prev: Binaries,  Up: Top
+
+9 Host/target specific installation notes for GCC
+*************************************************
+
+Please read this document carefully _before_ installing the GNU Compiler
+Collection on your machine.
+
+   Note that this list of install notes is _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.
+
+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.
+
+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 'alpha*-dec-osf4' are no longer supported.  (These
+are the versions which identify themselves as DEC OSF/1.)
+
+amd64-*-solaris2.1[0-9]*
+========================
+
+This is a synonym for 'x86_64-*-solaris2.1[0-9]*'.
+
+arc-*-elf32
+===========
+
+Use 'configure --target=arc-elf32 --with-cpu=CPU
+--enable-languages="c,c++"' to configure GCC, with CPU being one of
+'arc600', 'arc601', or 'arc700'.
+
+arc-linux-uclibc
+================
+
+Use 'configure --target=arc-linux-uclibc --with-cpu=arc700
+--enable-languages="c,c++"' to configure GCC.
+
+arm-*-eabi
+==========
+
+ARM-family processors.  Subtargets that use the ELF object format
+require GNU binutils 2.13 or newer.  Such subtargets include:
+'arm-*-netbsdelf', 'arm-*-*linux-*' and 'arm-*-rtemseabi'.
+
+avr
+===
+
+ATMEL AVR-family micro controllers.  These are used in embedded
+applications.  There are no standard Unix configurations.  *Note AVR
+Options: (gcc)AVR Options, for the list of supported MCU types.
+
+   Use 'configure --target=avr --enable-languages="c"' to configure GCC.
+
+   Further installation notes and other useful information about AVR
+tools can also be obtained from:
+
+   * http://www.nongnu.org/avr/
+   * http://www.amelek.gda.pl/avr/
+
+   We _strongly_ recommend using binutils 2.13 or newer.
+
+   The following error:
+     Error: register required
+
+   indicates that you should upgrade to a newer version of the binutils.
+
+Blackfin
+========
+
+The Blackfin processor, an Analog Devices DSP. *Note Blackfin Options:
+(gcc)Blackfin Options,
+
+   More information, and a version of binutils with support for this
+processor, is available at <http://blackfin.uclinux.org>
+
+CR16
+====
+
+The CR16 CompactRISC architecture is a 16-bit architecture.  This
+architecture is used in embedded applications.
+
+   *Note CR16 Options: (gcc)CR16 Options,
+
+   Use 'configure --target=cr16-elf --enable-languages=c,c++' to
+configure GCC for building a CR16 elf cross-compiler.
+
+   Use 'configure --target=cr16-uclinux --enable-languages=c,c++' to
+configure GCC for building a CR16 uclinux cross-compiler.
+
+CRIS
+====
+
+CRIS is the CPU architecture in Axis Communications ETRAX
+system-on-a-chip series.  These are used in embedded applications.
+
+   *Note CRIS Options: (gcc)CRIS Options, for a list of CRIS-specific
+options.
+
+   There are a few different CRIS targets:
+'cris-axis-elf'
+     Mainly for monolithic embedded systems.  Includes a multilib for
+     the 'v10' core used in 'ETRAX 100 LX'.
+'cris-axis-linux-gnu'
+     A GNU/Linux port for the CRIS architecture, currently targeting
+     'ETRAX 100 LX' by default.
+
+   For 'cris-axis-elf' you need binutils 2.11 or newer.  For
+'cris-axis-linux-gnu' you need binutils 2.12 or newer.
+
+   Pre-packaged tools can be obtained from
+<ftp://ftp.axis.com/pub/axis/tools/cris/compiler-kit/>.  More
+information about this platform is available at
+<http://developer.axis.com/>.
+
+DOS
+===
+
+Please have a look at the 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.
+
+epiphany-*-elf
+==============
+
+Adapteva Epiphany.  This configuration is intended for embedded systems.
+
+*-*-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 '__cxa_atexit' by default
+(on FreeBSD 6 or later).  The use of 'dl_iterate_phdr' inside
+'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 '-gstabs' instead of '-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, '--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 '/usr/bin' probably works with
+this release of GCC.  Bootstrapping against the latest GNU binutils
+and/or the version found in '/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.
+
+h8300-hms
+=========
+
+Renesas H8/300 series of processors.
+
+   Please have a look at the 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.
+
+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 '--with-gnu-as' and
+'--with-as=...' 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, '-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 'make
+all-host all-target' after getting the failure from '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 '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, 'UNIX_STD' can be set to '95' or '98'.  Another
+way is to add an appropriate set of predefines to 'CC'.  The description
+for the 'munix=' option contains a list of the predefines used with each
+standard.
+
+   More specific information to 'hppa*-hp-hpux*' targets follows.
+
+hppa*-hp-hpux10
+===============
+
+For hpux10.20, we _highly_ recommend you pick up the latest sed patch
+'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.
+
+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 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
+'--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 'hppa[1-2]*-hp-hpux11*' target generates code for the
+32-bit PA-RISC runtime architecture and uses the HP linker.  The
+'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 'PATH' or 'CC'
+so that configure finds an appropriate compiler for the initial
+bootstrap.  When 'CC' is used, the definition should contain the options
+that are needed whenever 'CC' is used.
+
+   Specifically, options that determine the runtime architecture must be
+in 'CC' to correctly select the target for the build.  It is also
+convenient to place many other compiler options in 'CC'.  For example,
+'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 '+DA2.0W' option will result in the automatic
+selection of the '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 '-Ac' option.
+These defines aren't necessary with '-Ae'.
+
+   It is best to explicitly configure the 'hppa64-hp-hpux11*' target
+with the '--with-ld=...' 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.  'PHSS_26559' and 'PHSS_24304' are the oldest linker
+patches that are known to work.  They are for HP-UX 11.00 and 11.11,
+respectively.  'PHSS_24303', the companion to '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 '+init' and '+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
+'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
+'-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 '--disable-symvers' when using GNU ld.
+
+   POSIX threads are the default.  The optional DCE thread library is
+not supported, so '--enable-threads=dce' does not work.
+
+*-*-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.
+
+i?86-*-linux*
+=============
+
+As of GCC 3.3, binutils 2.13.1 or later is required for this platform.
+See 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 www.bitwizard.nl.
+
+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
+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 2/x86 doesn't support the execution of SSE/SSE2 instructions
+before Solaris 9 4/04, even if the CPU supports them.  Programs will
+receive 'SIGILL' if they try.  The fix is available both in Solaris 9
+Update 6 and kernel patch 112234-12 or newer.  To avoid this problem,
+'-march' defaults to 'pentiumpro' on Solaris 9.  If you have the patch
+installed, you can configure GCC with an appropriate '--with-arch'
+option, but need GNU 'as' for SSE2 support.
+
+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 'amd64-*-solaris2.1[0-9]*' or
+'x86_64-*-solaris2.1[0-9]*' configuration that corresponds to
+'sparcv9-sun-solaris2*'.
+
+   It is recommended that you configure GCC to use the GNU assembler, in
+'/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 '/usr/ccs/bin/as' work
+almost as well, though.
+
+   For linking, the Sun linker, is preferred.  If you want to use the
+GNU linker instead, which is available in '/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 'as', configure with the options '--with-gnu-as
+--with-as=/usr/sfw/bin/gas'.  It may be necessary to configure with
+'--without-gnu-ld --with-ld=/usr/ccs/bin/ld' to guarantee use of Sun
+'ld'.
+
+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
+'--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.
+
+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 '--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, '--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, '--enable-libunwind-exceptions' is removed and
+the system libunwind library will always be used.
+
+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.
+
+*-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
+'/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
+LDR_CNTRL environment variable, e.g.,
+
+     % LDR_CNTRL=MAXDATA=0x50000000
+     % export LDR_CNTRL
+
+   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 '/bin/sh', e.g.,
+
+     % CONFIG_SHELL=/opt/freeware/bin/bash
+     % export CONFIG_SHELL
+
+   and then proceed as described in the build instructions, where we
+strongly recommend specifying an absolute path to invoke
+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 'alloca' when building GCC generally are due to an
+incorrect definition of '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 *must* be invoked as 'cc' (not 'xlc').
+Once 'configure' has been informed of 'xlc', one needs to use 'make
+distclean' to remove the configure cache files and ensure that 'CC'
+environment variable does not provide a definition that will confuse
+'configure'.  If this error occurs during stage2 or later, then the
+problem most likely is the version of Make (see above).
+
+   The native 'as' and '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 '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)
+
+   'libstdc++' in GCC 3.4 increments the major version number of the
+shared object and GCC installation places the '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 'libstdc++' shared object needs to be available to the AIX runtime
+loader.  The GCC 3.1 'libstdc++.so.4', if present, and GCC 3.3
+'libstdc++.so.5' shared objects can be installed for runtime dynamic
+loading using the following steps to set the 'F_LOADONLY' flag in the
+shared object for _each_ multilib 'libstdc++.a' installed:
+
+   Extract the shared objects from the currently installed 'libstdc++.a'
+archive:
+     % ar -x libstdc++.a libstdc++.so.4 libstdc++.so.5
+
+   Enable the 'F_LOADONLY' flag so that the shared object will be
+available for runtime dynamic loading, but not linking:
+     % strip -e libstdc++.so.4 libstdc++.so.5
+
+   Archive the runtime-only shared object in the GCC 3.4 'libstdc++.a'
+archive:
+     % ar -q libstdc++.a libstdc++.so.4 libstdc++.so.5
+
+   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 '-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 '-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
+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
+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 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., '.' vs ',' 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 'LANG' environment
+variable to 'C' or 'En_US'.
+
+   A default can be specified with the '-mcpu=CPU_TYPE' switch and using
+the configure option '--with-cpu-CPU_TYPE'.
+
+iq2000-*-elf
+============
+
+Vitesse IQ2000 processors.  These are used in embedded applications.
+There are no standard Unix configurations.
+
+lm32-*-elf
+==========
+
+Lattice Mico32 processor.  This configuration is intended for embedded
+systems.
+
+lm32-*-uclinux
+==============
+
+Lattice Mico32 processor.  This configuration is intended for embedded
+systems running uClinux.
+
+m32c-*-elf
+==========
+
+Renesas M32C processor.  This configuration is intended for embedded
+systems.
+
+m32r-*-elf
+==========
+
+Renesas M32R processor.  This configuration is intended for embedded
+systems.
+
+m68k-*-*
+========
+
+By default, 'm68k-*-elf*', 'm68k-*-rtems', 'm68k-*-uclinux' and
+'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 '--with-arch=m68k' to 'configure'.  Alternatively, you can omit
+the M680x0 libraries by passing '--with-arch=cf' to 'configure'.  These
+targets default to 5206 or 5475 code as appropriate for the target
+system when configured with '--with-arch=cf' and 68020 code otherwise.
+
+   The 'm68k-*-netbsd' and 'm68k-*-openbsd' targets also support the
+'--with-arch' option.  They will generate ColdFire CFV4e code when
+configured with '--with-arch=cf' and 68020 code otherwise.
+
+   You can override the default processors listed above by configuring
+with '--with-cpu=TARGET'.  This TARGET can either be a '-mcpu' argument
+or one of the following values: 'm68000', 'm68010', 'm68020', 'm68030',
+'m68040', 'm68060', 'm68020-40' and 'm68020-60'.
+
+   GCC requires at least binutils version 2.17 on these targets.
+
+m68k-*-uclinux
+==============
+
+GCC 4.3 changed the uClinux configuration so that it uses the
+'m68k-linux-gnu' ABI rather than the 'm68k-elf' ABI. It also added
+improved support for C++ and flat shared libraries, both of which were
+ABI changes.
+
+mep-*-elf
+=========
+
+Toshiba Media embedded Processor.  This configuration is intended for
+embedded systems.
+
+microblaze-*-elf
+================
+
+Xilinx MicroBlaze processor.  This configuration is intended for
+embedded systems.
+
+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
+'mips*-*-*' use the generic implementation instead.  You can also
+configure for 'mipsel-elf' as a workaround.  The 'mips*-*-linux*' target
+continues to use the MIPS II routines.  More work on this is expected in
+future releases.
+
+   The built-in '__sync_*' functions are available on MIPS II and later
+systems and others that support the 'll', 'sc' and 'sync' instructions.
+This can be overridden by passing '--with-llsc' or '--without-llsc' when
+configuring GCC. Since the Linux kernel emulates these instructions if
+they are missing, the default for 'mips*-*-linux*' targets is
+'--with-llsc'.  The '--with-llsc' and '--without-llsc' configure options
+may be overridden at compile time by passing the '-mllsc' or '-mno-llsc'
+options to the compiler.
+
+   MIPS systems check for division by zero (unless
+'-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 ('SIGFPE').  To enable the use of break,
+use the '--with-divide=breaks' '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 '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.
+
+mips-sgi-irix5
+==============
+
+Support for IRIX 5 has been removed in GCC 4.6.
+
+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.
+
+moxie-*-elf
+===========
+
+The moxie processor.
+
+msp430-*-elf
+============
+
+TI MSP430 processor.  This configuration is intended for embedded
+systems.
+
+nds32le-*-elf
+=============
+
+Andes NDS32 target in little endian mode.
+
+nds32be-*-elf
+=============
+
+Andes NDS32 target in big endian mode.
+
+powerpc-*-*
+===========
+
+You can specify a default version for the '-mcpu=CPU_TYPE' switch by
+using the configure option '--with-cpu-CPU_TYPE'.
+
+   You will need binutils 2.15 or newer for a working GCC.
+
+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 <http://opensource.apple.com/>.
+
+   This version of GCC requires at least cctools-590.36.  The
+cctools-590.36 package referenced from
+<http://gcc.gnu.org/ml/gcc/2006-03/msg00507.html> will not work on
+systems older than 10.3.9 (aka darwin7.9.0).
+
+powerpc-*-elf
+=============
+
+PowerPC system in big endian mode, running System V.4.
+
+powerpc*-*-linux-gnu*
+=====================
+
+PowerPC system in big endian mode running Linux.
+
+powerpc-*-netbsd*
+=================
+
+PowerPC system in big endian mode running NetBSD.
+
+powerpc-*-eabisim
+=================
+
+Embedded PowerPC system in big endian mode for use in running under the
+PSIM simulator.
+
+powerpc-*-eabi
+==============
+
+Embedded PowerPC system in big endian mode.
+
+powerpcle-*-elf
+===============
+
+PowerPC system in little endian mode, running System V.4.
+
+powerpcle-*-eabisim
+===================
+
+Embedded PowerPC system in little endian mode for use in running under
+the PSIM simulator.
+
+powerpcle-*-eabi
+================
+
+Embedded PowerPC system in little endian mode.
+
+rl78-*-elf
+==========
+
+The Renesas RL78 processor.  This configuration is intended for embedded
+systems.
+
+rx-*-elf
+========
+
+The Renesas RX processor.  See
+<http://eu.renesas.com/fmwk.jsp?cnt=rx600_series_landing.jsp&fp=/products/mpumcu/rx_family/rx600_series>
+for more information about this processor.
+
+s390-*-linux*
+=============
+
+S/390 system running GNU/Linux for S/390.
+
+s390x-*-linux*
+==============
+
+zSeries system (64-bit) running GNU/Linux for zSeries.
+
+s390x-ibm-tpf*
+==============
+
+zSeries system (64-bit) running TPF.  This platform is supported as
+cross-compilation target only.
+
+*-*-solaris2*
+=============
+
+Support for Solaris 9 has been obsoleted in GCC 4.9, but can still be
+enabled by configuring with '--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 '/usr/sfw/bin/gcc'.  Solaris 11
+also provides GCC 4.5.2 as '/usr/gcc/4.5/bin/gcc'.  Alternatively, you
+can install a pre-built GCC to bootstrap and install GCC. See the
+binaries page for details.
+
+   The Solaris 2 '/bin/sh' will often fail to configure 'libstdc++-v3',
+'boehm-gc' or 'libjava'.  We therefore recommend using the following
+initial sequence of commands
+
+     % CONFIG_SHELL=/bin/ksh
+     % export CONFIG_SHELL
+
+and proceed as described in the configure instructions.  In addition we
+strongly recommend specifying an absolute path to invoke
+'SRCDIR/configure'.
+
+   Solaris 2 comes with a number of optional OS packages.  Some of these
+are needed to use GCC fully, namely 'SUNWarc', 'SUNWbtool', 'SUNWesu',
+'SUNWhea', 'SUNWlibm', 'SUNWsprot', and '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 'pkginfo'
+command.  To add an optional package, use the 'pkgadd' command.  For
+further details, see the Solaris 2 documentation.
+
+   Trying to use the linker and other tools in '/usr/ucb' to install GCC
+has been observed to cause trouble.  For example, the linker may hang
+indefinitely.  The fix is to remove '/usr/ucb' from your 'PATH'.
+
+   The build process works more smoothly with the legacy Sun tools so,
+if you have '/usr/xpg4/bin' in your 'PATH', we recommend that you place
+'/usr/bin' before '/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 '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 '/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 'as' + Sun 'ld' should
+reasonably work, the reverse combination Sun 'as' + GNU 'ld' may fail to
+build or cause memory corruption at runtime in some cases for C++
+programs.  GNU '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 'ld'.  To use the LTO linker plugin
+('-fuse-linker-plugin') with GNU 'ld', GNU binutils _must_ be configured
+with '--enable-largefile'.
+
+   To enable symbol versioning in 'libstdc++' with Sun 'ld', you need to
+have any version of GNU 'c++filt', which is part of GNU binutils.
+'libstdc++' symbol versioning will be disabled if no appropriate version
+is found.  Sun 'c++filt' from the Sun Studio compilers does _not_ work.
+
+   Sun bug 4296832 turns up when compiling X11 headers with GCC 2.95 or
+newer: 'g++' will complain that types are missing.  These headers assume
+that omitting the type means '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 'expect' program
+which is used only by the GCC testsuite driver.  When the bug causes the
+'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 9, but requires
+some patches.  The 'libthread' patches provide the '__tls_get_addr'
+(SPARC, 64-bit x86) resp. '___tls_get_addr' (32-bit x86) functions.  On
+Solaris 9, the necessary support on SPARC is present since FCS, while
+114432-05 or newer is required on Intel.  Additionally, on
+Solaris 9/x86, patch 113986-02 or newer is required for the Sun 'ld' and
+runtime linker ('ld.so.1') support, while Solaris 9/SPARC works since
+FCS. The linker patches must be installed even if GNU 'ld' is used.  Sun
+'as' in Solaris 9 doesn't support the necessary relocations, so GNU 'as'
+must be used.  The '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.
+
+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 the
+prerequisites.
+
+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
+'-m64' option enables 64-bit code generation.  However, if all you want
+is code tuned for the UltraSPARC CPU, you should try the
+'-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
+'--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 'groff' 1.19.1 without getting messages similar to the
+following:
+
+     ld: warning: relocation error: R_SPARC_UA32: ...
+       external symbolic relocation against non-allocatable section
+       .debug_info cannot be processed at runtime: relocation ignored.
+
+To work around this problem, compile with '-gstabs+' instead of plain
+'-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 'build' parameter on the
+configure line.  This target triplet can be obtained by invoking
+'./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:
+
+     % ./configure --build=sparc-sun-solaris2.9 --prefix=xxx
+
+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
+
+     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
+
+This bug is fixed in Sun patch 118683-03 or later.
+
+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 'sparc-*-*' targets.
+
+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 'build' parameter on the configure line.  For example
+on a Solaris 9 system:
+
+     % ./configure --build=sparc64-sun-solaris2.9 --prefix=xxx
+
+   The following compiler flags must be specified in the configure step
+in order to bootstrap this target with the Sun compiler:
+
+     % CC="cc -xarch=v9 -xildoff" SRCDIR/configure [OPTIONS] [TARGET]
+
+'-xarch=v9' specifies the SPARC-V9 architecture to the Sun toolchain and
+'-xildoff' turns off the incremental linker.
+
+sparcv9-*-solaris2*
+===================
+
+This is a synonym for 'sparc64-*-solaris2*'.
+
+c6x-*-*
+=======
+
+The C6X family of processors.  This port requires binutils-2.22 or
+newer.
+
+tilegx-*-linux*
+===============
+
+The TILE-Gx processor in little endian mode, running GNU/Linux.  This
+port requires binutils-2.22 or newer.
+
+tilegxbe-*-linux*
+=================
+
+The TILE-Gx processor in big endian mode, running GNU/Linux.  This port
+requires binutils-2.23 or newer.
+
+tilepro-*-linux*
+================
+
+The TILEPro processor running GNU/Linux.  This port requires
+binutils-2.22 or newer.
+
+*-*-vxworks*
+============
+
+Support for VxWorks is in flux.  At present GCC supports _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
+'$WIND_BASE/host'; we recommend you do not overwrite it.  Choose an
+installation PREFIX entirely outside $WIND_BASE.  Before running
+'configure', create the directories 'PREFIX' and 'PREFIX/bin'.  Link or
+copy the appropriate assembler, linker, etc. into 'PREFIX/bin', and set
+your PATH to include that directory while running both 'configure' and
+'make'.
+
+   You must give 'configure' the '--with-headers=$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
+'--target=TARGET'.  'configure' will attempt to create the directory
+'PREFIX/TARGET/sys-include' and copy files into it; make sure the user
+running 'configure' has sufficient privilege to do so.
+
+   GCC's exception handling runtime requires a special "configlette"
+module, '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.)
+
+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 '-m32' switch).
+
+x86_64-*-solaris2.1[0-9]*
+=========================
+
+GCC also supports the x86-64 architecture implemented by the AMD64
+processor ('amd64-*-*' is an alias for '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 '-m64' switch.  Since GCC 4.7, there is also
+configuration that defaults to 64-bit code, but can generate 32-bit code
+with '-m32'.  To configure and build this way, you have to provide all
+support libraries like 'libgmp' as 64-bit code, configure with
+'--target=x86_64-pc-solaris2.1x' and 'CC=gcc -m64'.
+
+xtensa*-*-elf
+=============
+
+This target is intended for embedded Xtensa systems using the '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 '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.
+
+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 '-fpic' or
+'-fPIC' options are used.  In other respects, this target is the same as
+the 'xtensa*-*-elf' target.
+
+Microsoft Windows
+=================
+
+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.
+
+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.
+
+   * Cygwin *-*-cygwin: Cygwin provides a user-space Linux API emulation
+     layer in the Win32 subsystem.
+   * Interix *-*-interix: The Interix subsystem provides native support
+     for POSIX.
+   * MinGW *-*-mingw32: MinGW is a native GCC port for the Win32
+     subsystem that provides a subset of POSIX.
+   * MKS i386-pc-mks: NuTCracker from MKS. See
+     <http://www.mkssoftware.com/> for more information.
+
+Intel 64-bit versions
+---------------------
+
+GCC contains support for x86-64 using the mingw-w64 runtime library,
+available from <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.
+
+Windows CE
+----------
+
+Windows CE is supported as a target only on Hitachi SuperH
+(sh-wince-pe), and MIPS (mips-wince-pe).
+
+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 <http://pw32.sourceforge.net/> for more
+information.
+
+   UWIN support has been removed due to a lack of maintenance.
+
+*-*-cygwin
+==========
+
+Ports of GCC are included with the 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.
+
+*-*-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.
+
+*-*-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 'extern inline' in '-std=c99' and '-std=gnu99' modes.
+
+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 'configure' will fail unless the '--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
+'old-releases' directory on the GCC mirror sites.  Header bugs may
+generally be avoided using '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 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 'pub/binutils/old-releases' on 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.
+
+all ELF targets (SVR4, Solaris 2, etc.)
+=======================================
+
+C++ support is significantly better on ELF targets if you use the GNU
+linker; duplicate copies of inlines, vtables and template instantiations
+will be discarded automatically.
+
+
+File: gccinstall.info,  Node: Old,  Next: GNU Free Documentation License,  Prev: Specific,  Up: Top
+
+10 Old installation documentation
+*********************************
+
+Note most of this information is out of date and superseded by the
+previous chapters of this manual.  It is provided for historical
+reference only, because of a lack of volunteers to merge it into the
+main manual.
+
+* Menu:
+
+* Configurations::    Configurations Supported by GCC.
+
+   Here is the procedure for installing GCC on a GNU or Unix system.
+
+  1. If you have chosen a configuration for GCC which requires other GNU
+     tools (such as GAS or the GNU linker) instead of the standard
+     system tools, install the required tools in the build directory
+     under the names 'as', 'ld' or whatever is appropriate.
+
+     Alternatively, you can do subsequent compilation using a value of
+     the 'PATH' environment variable such that the necessary GNU tools
+     come before the standard system tools.
+
+  2. Specify the host, build and target machine configurations.  You do
+     this when you run the 'configure' script.
+
+     The "build" machine is the system which you are using, the "host"
+     machine is the system where you want to run the resulting compiler
+     (normally the build machine), and the "target" machine is the
+     system for which you want the compiler to generate code.
+
+     If you are building a compiler to produce code for the machine it
+     runs on (a native compiler), you normally do not need to specify
+     any operands to 'configure'; it will try to guess the type of
+     machine you are on and use that as the build, host and target
+     machines.  So you don't need to specify a configuration when
+     building a native compiler unless 'configure' cannot figure out
+     what your configuration is or guesses wrong.
+
+     In those cases, specify the build machine's "configuration name"
+     with the '--host' option; the host and target will default to be
+     the same as the host machine.
+
+     Here is an example:
+
+          ./configure --host=sparc-sun-sunos4.1
+
+     A configuration name may be canonical or it may be more or less
+     abbreviated.
+
+     A canonical configuration name has three parts, separated by
+     dashes.  It looks like this: 'CPU-COMPANY-SYSTEM'.  (The three
+     parts may themselves contain dashes; 'configure' can figure out
+     which dashes serve which purpose.)  For example,
+     'm68k-sun-sunos4.1' specifies a Sun 3.
+
+     You can also replace parts of the configuration by nicknames or
+     aliases.  For example, 'sun3' stands for 'm68k-sun', so
+     'sun3-sunos4.1' is another way to specify a Sun 3.
+
+     You can specify a version number after any of the system types, and
+     some of the CPU types.  In most cases, the version is irrelevant,
+     and will be ignored.  So you might as well specify the version if
+     you know it.
+
+     See *note Configurations::, for a list of supported configuration
+     names and notes on many of the configurations.  You should check
+     the notes in that section before proceeding any further with the
+     installation of GCC.
+
+
+File: gccinstall.info,  Node: Configurations,  Up: Old
+
+10.1 Configurations Supported by GCC
+====================================
+
+Here are the possible CPU types:
+
+     1750a, a29k, alpha, arm, avr, cN, clipper, dsp16xx, elxsi, fr30,
+     h8300, hppa1.0, hppa1.1, i370, i386, i486, i586, i686, i786, i860,
+     i960, ip2k, m32r, m68000, m68k, m88k, mcore, mips, mipsel, mips64,
+     mips64el, mn10200, mn10300, ns32k, pdp11, powerpc, powerpcle, romp,
+     rs6000, sh, sparc, sparclite, sparc64, v850, vax, we32k.
+
+   Here are the recognized company names.  As you can see, customary
+abbreviations are used rather than the longer official names.
+
+     acorn, alliant, altos, apollo, apple, att, bull, cbm, convergent,
+     convex, crds, dec, dg, dolphin, elxsi, encore, harris, hitachi, hp,
+     ibm, intergraph, isi, mips, motorola, ncr, next, ns, omron, plexus,
+     sequent, sgi, sony, sun, tti, unicom, wrs.
+
+   The company name is meaningful only to disambiguate when the rest of
+the information supplied is insufficient.  You can omit it, writing just
+'CPU-SYSTEM', if it is not needed.  For example, 'vax-ultrix4.2' is
+equivalent to 'vax-dec-ultrix4.2'.
+
+   Here is a list of system types:
+
+     386bsd, aix, acis, amigaos, aos, aout, aux, bosx, bsd, clix, coff,
+     ctix, cxux, dgux, dynix, ebmon, ecoff, elf, esix, freebsd, hms,
+     genix, gnu, linux, linux-gnu, hiux, hpux, iris, irix, isc, luna,
+     lynxos, mach, minix, msdos, mvs, netbsd, newsos, nindy, ns, osf,
+     osfrose, ptx, riscix, riscos, rtu, sco, sim, solaris, sunos, sym,
+     sysv, udi, ultrix, unicos, uniplus, unos, vms, vsta, vxworks,
+     winnt, xenix.
+
+You can omit the system type; then 'configure' guesses the operating
+system from the CPU and company.
+
+   You can add a version number to the system type; this may or may not
+make a difference.  For example, you can write 'bsd4.3' or 'bsd4.4' to
+distinguish versions of BSD.  In practice, the version number is most
+needed for 'sysv3' and 'sysv4', which are often treated differently.
+
+   'linux-gnu' is the canonical name for the GNU/Linux target; however
+GCC will also accept 'linux'.  The version of the kernel in use is not
+relevant on these systems.  A suffix such as 'libc1' or 'aout'
+distinguishes major versions of the C library; all of the suffixed
+versions are obsolete.
+
+   If you specify an impossible combination such as 'i860-dg-vms', then
+you may get an error message from 'configure', or it may ignore part of
+the information and do the best it can with the rest.  'configure'
+always prints the canonical name for the alternative that it used.  GCC
+does not support all possible alternatives.
+
+   Often a particular model of machine has a name.  Many machine names
+are recognized as aliases for CPU/company combinations.  Thus, the
+machine name 'sun3', mentioned above, is an alias for 'm68k-sun'.
+Sometimes we accept a company name as a machine name, when the name is
+popularly used for a particular machine.  Here is a table of the known
+machine names:
+
+     3300, 3b1, 3bN, 7300, altos3068, altos, apollo68, att-7300,
+     balance, convex-cN, crds, decstation-3100, decstation, delta,
+     encore, fx2800, gmicro, hp7NN, hp8NN, hp9k2NN, hp9k3NN, hp9k7NN,
+     hp9k8NN, iris4d, iris, isi68, m3230, magnum, merlin, miniframe,
+     mmax, news-3600, news800, news, next, pbd, pc532, pmax, powerpc,
+     powerpcle, ps2, risc-news, rtpc, sun2, sun386i, sun386, sun3, sun4,
+     symmetry, tower-32, tower.
+
+Remember that a machine name specifies both the cpu type and the company
+name.
+
+
+File: gccinstall.info,  Node: GNU Free Documentation License,  Next: Concept Index,  Prev: Old,  Up: Top
+
+GNU Free Documentation License
+******************************
+
+                     Version 1.3, 3 November 2008
+
+     Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
+     <http://fsf.org/>
+
+     Everyone is permitted to copy and distribute verbatim copies
+     of this license document, but changing it is not allowed.
+
+  0. PREAMBLE
+
+     The purpose of this License is to make a manual, textbook, or other
+     functional and useful document "free" in the sense of freedom: to
+     assure everyone the effective freedom to copy and redistribute it,
+     with or without modifying it, either commercially or
+     noncommercially.  Secondarily, this License preserves for the
+     author and publisher a way to get credit for their work, while not
+     being considered responsible for modifications made by others.
+
+     This License is a kind of "copyleft", which means that derivative
+     works of the document must themselves be free in the same sense.
+     It complements the GNU General Public License, which is a copyleft
+     license designed for free software.
+
+     We have designed this License in order to use it for manuals for
+     free software, because free software needs free documentation: a
+     free program should come with manuals providing the same freedoms
+     that the software does.  But this License is not limited to
+     software manuals; it can be used for any textual work, regardless
+     of subject matter or whether it is published as a printed book.  We
+     recommend this License principally for works whose purpose is
+     instruction or reference.
+
+  1. APPLICABILITY AND DEFINITIONS
+
+     This License applies to any manual or other work, in any medium,
+     that contains a notice placed by the copyright holder saying it can
+     be distributed under the terms of this License.  Such a notice
+     grants a world-wide, royalty-free license, unlimited in duration,
+     to use that work under the conditions stated herein.  The
+     "Document", below, refers to any such manual or work.  Any member
+     of the public is a licensee, and is addressed as "you".  You accept
+     the license if you copy, modify or distribute the work in a way
+     requiring permission under copyright law.
+
+     A "Modified Version" of the Document means any work containing the
+     Document or a portion of it, either copied verbatim, or with
+     modifications and/or translated into another language.
+
+     A "Secondary Section" is a named appendix or a front-matter section
+     of the Document that deals exclusively with the relationship of the
+     publishers or authors of the Document to the Document's overall
+     subject (or to related matters) and contains nothing that could
+     fall directly within that overall subject.  (Thus, if the Document
+     is in part a textbook of mathematics, a Secondary Section may not
+     explain any mathematics.)  The relationship could be a matter of
+     historical connection with the subject or with related matters, or
+     of legal, commercial, philosophical, ethical or political position
+     regarding them.
+
+     The "Invariant Sections" are certain Secondary Sections whose
+     titles are designated, as being those of Invariant Sections, in the
+     notice that says that the Document is released under this License.
+     If a section does not fit the above definition of Secondary then it
+     is not allowed to be designated as Invariant.  The Document may
+     contain zero Invariant Sections.  If the Document does not identify
+     any Invariant Sections then there are none.
+
+     The "Cover Texts" are certain short passages of text that are
+     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
+     that says that the Document is released under this License.  A
+     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
+     be at most 25 words.
+
+     A "Transparent" copy of the Document means a machine-readable copy,
+     represented in a format whose specification is available to the
+     general public, that is suitable for revising the document
+     straightforwardly with generic text editors or (for images composed
+     of pixels) generic paint programs or (for drawings) some widely
+     available drawing editor, and that is suitable for input to text
+     formatters or for automatic translation to a variety of formats
+     suitable for input to text formatters.  A copy made in an otherwise
+     Transparent file format whose markup, or absence of markup, has
+     been arranged to thwart or discourage subsequent modification by
+     readers is not Transparent.  An image format is not Transparent if
+     used for any substantial amount of text.  A copy that is not
+     "Transparent" is called "Opaque".
+
+     Examples of suitable formats for Transparent copies include plain
+     ASCII without markup, Texinfo input format, LaTeX input format,
+     SGML or XML using a publicly available DTD, and standard-conforming
+     simple HTML, PostScript or PDF designed for human modification.
+     Examples of transparent image formats include PNG, XCF and JPG.
+     Opaque formats include proprietary formats that can be read and
+     edited only by proprietary word processors, SGML or XML for which
+     the DTD and/or processing tools are not generally available, and
+     the machine-generated HTML, PostScript or PDF produced by some word
+     processors for output purposes only.
+
+     The "Title Page" means, for a printed book, the title page itself,
+     plus such following pages as are needed to hold, legibly, the
+     material this License requires to appear in the title page.  For
+     works in formats which do not have any title page as such, "Title
+     Page" means the text near the most prominent appearance of the
+     work's title, preceding the beginning of the body of the text.
+
+     The "publisher" means any person or entity that distributes copies
+     of the Document to the public.
+
+     A section "Entitled XYZ" means a named subunit of the Document
+     whose title either is precisely XYZ or contains XYZ in parentheses
+     following text that translates XYZ in another language.  (Here XYZ
+     stands for a specific section name mentioned below, such as
+     "Acknowledgements", "Dedications", "Endorsements", or "History".)
+     To "Preserve the Title" of such a section when you modify the
+     Document means that it remains a section "Entitled XYZ" according
+     to this definition.
+
+     The Document may include Warranty Disclaimers next to the notice
+     which states that this License applies to the Document.  These
+     Warranty Disclaimers are considered to be included by reference in
+     this License, but only as regards disclaiming warranties: any other
+     implication that these Warranty Disclaimers may have is void and
+     has no effect on the meaning of this License.
+
+  2. VERBATIM COPYING
+
+     You may copy and distribute the Document in any medium, either
+     commercially or noncommercially, provided that this License, the
+     copyright notices, and the license notice saying this License
+     applies to the Document are reproduced in all copies, and that you
+     add no other conditions whatsoever to those of this License.  You
+     may not use technical measures to obstruct or control the reading
+     or further copying of the copies you make or distribute.  However,
+     you may accept compensation in exchange for copies.  If you
+     distribute a large enough number of copies you must also follow the
+     conditions in section 3.
+
+     You may also lend copies, under the same conditions stated above,
+     and you may publicly display copies.
+
+  3. COPYING IN QUANTITY
+
+     If you publish printed copies (or copies in media that commonly
+     have printed covers) of the Document, numbering more than 100, and
+     the Document's license notice requires Cover Texts, you must
+     enclose the copies in covers that carry, clearly and legibly, all
+     these Cover Texts: Front-Cover Texts on the front cover, and
+     Back-Cover Texts on the back cover.  Both covers must also clearly
+     and legibly identify you as the publisher of these copies.  The
+     front cover must present the full title with all words of the title
+     equally prominent and visible.  You may add other material on the
+     covers in addition.  Copying with changes limited to the covers, as
+     long as they preserve the title of the Document and satisfy these
+     conditions, can be treated as verbatim copying in other respects.
+
+     If the required texts for either cover are too voluminous to fit
+     legibly, you should put the first ones listed (as many as fit
+     reasonably) on the actual cover, and continue the rest onto
+     adjacent pages.
+
+     If you publish or distribute Opaque copies of the Document
+     numbering more than 100, you must either include a machine-readable
+     Transparent copy along with each Opaque copy, or state in or with
+     each Opaque copy a computer-network location from which the general
+     network-using public has access to download using public-standard
+     network protocols a complete Transparent copy of the Document, free
+     of added material.  If you use the latter option, you must take
+     reasonably prudent steps, when you begin distribution of Opaque
+     copies in quantity, to ensure that this Transparent copy will
+     remain thus accessible at the stated location until at least one
+     year after the last time you distribute an Opaque copy (directly or
+     through your agents or retailers) of that edition to the public.
+
+     It is requested, but not required, that you contact the authors of
+     the Document well before redistributing any large number of copies,
+     to give them a chance to provide you with an updated version of the
+     Document.
+
+  4. MODIFICATIONS
+
+     You may copy and distribute a Modified Version of the Document
+     under the conditions of sections 2 and 3 above, provided that you
+     release the Modified Version under precisely this License, with the
+     Modified Version filling the role of the Document, thus licensing
+     distribution and modification of the Modified Version to whoever
+     possesses a copy of it.  In addition, you must do these things in
+     the Modified Version:
+
+       A. Use in the Title Page (and on the covers, if any) a title
+          distinct from that of the Document, and from those of previous
+          versions (which should, if there were any, be listed in the
+          History section of the Document).  You may use the same title
+          as a previous version if the original publisher of that
+          version gives permission.
+
+       B. List on the Title Page, as authors, one or more persons or
+          entities responsible for authorship of the modifications in
+          the Modified Version, together with at least five of the
+          principal authors of the Document (all of its principal
+          authors, if it has fewer than five), unless they release you
+          from this requirement.
+
+       C. State on the Title page the name of the publisher of the
+          Modified Version, as the publisher.
+
+       D. Preserve all the copyright notices of the Document.
+
+       E. Add an appropriate copyright notice for your modifications
+          adjacent to the other copyright notices.
+
+       F. Include, immediately after the copyright notices, a license
+          notice giving the public permission to use the Modified
+          Version under the terms of this License, in the form shown in
+          the Addendum below.
+
+       G. Preserve in that license notice the full lists of Invariant
+          Sections and required Cover Texts given in the Document's
+          license notice.
+
+       H. Include an unaltered copy of this License.
+
+       I. Preserve the section Entitled "History", Preserve its Title,
+          and add to it an item stating at least the title, year, new
+          authors, and publisher of the Modified Version as given on the
+          Title Page.  If there is no section Entitled "History" in the
+          Document, create one stating the title, year, authors, and
+          publisher of the Document as given on its Title Page, then add
+          an item describing the Modified Version as stated in the
+          previous sentence.
+
+       J. Preserve the network location, if any, given in the Document
+          for public access to a Transparent copy of the Document, and
+          likewise the network locations given in the Document for
+          previous versions it was based on.  These may be placed in the
+          "History" section.  You may omit a network location for a work
+          that was published at least four years before the Document
+          itself, or if the original publisher of the version it refers
+          to gives permission.
+
+       K. For any section Entitled "Acknowledgements" or "Dedications",
+          Preserve the Title of the section, and preserve in the section
+          all the substance and tone of each of the contributor
+          acknowledgements and/or dedications given therein.
+
+       L. Preserve all the Invariant Sections of the Document, unaltered
+          in their text and in their titles.  Section numbers or the
+          equivalent are not considered part of the section titles.
+
+       M. Delete any section Entitled "Endorsements".  Such a section
+          may not be included in the Modified Version.
+
+       N. Do not retitle any existing section to be Entitled
+          "Endorsements" or to conflict in title with any Invariant
+          Section.
+
+       O. Preserve any Warranty Disclaimers.
+
+     If the Modified Version includes new front-matter sections or
+     appendices that qualify as Secondary Sections and contain no
+     material copied from the Document, you may at your option designate
+     some or all of these sections as invariant.  To do this, add their
+     titles to the list of Invariant Sections in the Modified Version's
+     license notice.  These titles must be distinct from any other
+     section titles.
+
+     You may add a section Entitled "Endorsements", provided it contains
+     nothing but endorsements of your Modified Version by various
+     parties--for example, statements of peer review or that the text
+     has been approved by an organization as the authoritative
+     definition of a standard.
+
+     You may add a passage of up to five words as a Front-Cover Text,
+     and a passage of up to 25 words as a Back-Cover Text, to the end of
+     the list of Cover Texts in the Modified Version.  Only one passage
+     of Front-Cover Text and one of Back-Cover Text may be added by (or
+     through arrangements made by) any one entity.  If the Document
+     already includes a cover text for the same cover, previously added
+     by you or by arrangement made by the same entity you are acting on
+     behalf of, you may not add another; but you may replace the old
+     one, on explicit permission from the previous publisher that added
+     the old one.
+
+     The author(s) and publisher(s) of the Document do not by this
+     License give permission to use their names for publicity for or to
+     assert or imply endorsement of any Modified Version.
+
+  5. COMBINING DOCUMENTS
+
+     You may combine the Document with other documents released under
+     this License, under the terms defined in section 4 above for
+     modified versions, provided that you include in the combination all
+     of the Invariant Sections of all of the original documents,
+     unmodified, and list them all as Invariant Sections of your
+     combined work in its license notice, and that you preserve all
+     their Warranty Disclaimers.
+
+     The combined work need only contain one copy of this License, and
+     multiple identical Invariant Sections may be replaced with a single
+     copy.  If there are multiple Invariant Sections with the same name
+     but different contents, make the title of each such section unique
+     by adding at the end of it, in parentheses, the name of the
+     original author or publisher of that section if known, or else a
+     unique number.  Make the same adjustment to the section titles in
+     the list of Invariant Sections in the license notice of the
+     combined work.
+
+     In the combination, you must combine any sections Entitled
+     "History" in the various original documents, forming one section
+     Entitled "History"; likewise combine any sections Entitled
+     "Acknowledgements", and any sections Entitled "Dedications".  You
+     must delete all sections Entitled "Endorsements."
+
+  6. COLLECTIONS OF DOCUMENTS
+
+     You may make a collection consisting of the Document and other
+     documents released under this License, and replace the individual
+     copies of this License in the various documents with a single copy
+     that is included in the collection, provided that you follow the
+     rules of this License for verbatim copying of each of the documents
+     in all other respects.
+
+     You may extract a single document from such a collection, and
+     distribute it individually under this License, provided you insert
+     a copy of this License into the extracted document, and follow this
+     License in all other respects regarding verbatim copying of that
+     document.
+
+  7. AGGREGATION WITH INDEPENDENT WORKS
+
+     A compilation of the Document or its derivatives with other
+     separate and independent documents or works, in or on a volume of a
+     storage or distribution medium, is called an "aggregate" if the
+     copyright resulting from the compilation is not used to limit the
+     legal rights of the compilation's users beyond what the individual
+     works permit.  When the Document is included in an aggregate, this
+     License does not apply to the other works in the aggregate which
+     are not themselves derivative works of the Document.
+
+     If the Cover Text requirement of section 3 is applicable to these
+     copies of the Document, then if the Document is less than one half
+     of the entire aggregate, the Document's Cover Texts may be placed
+     on covers that bracket the Document within the aggregate, or the
+     electronic equivalent of covers if the Document is in electronic
+     form.  Otherwise they must appear on printed covers that bracket
+     the whole aggregate.
+
+  8. TRANSLATION
+
+     Translation is considered a kind of modification, so you may
+     distribute translations of the Document under the terms of section
+     4.  Replacing Invariant Sections with translations requires special
+     permission from their copyright holders, but you may include
+     translations of some or all Invariant Sections in addition to the
+     original versions of these Invariant Sections.  You may include a
+     translation of this License, and all the license notices in the
+     Document, and any Warranty Disclaimers, provided that you also
+     include the original English version of this License and the
+     original versions of those notices and disclaimers.  In case of a
+     disagreement between the translation and the original version of
+     this License or a notice or disclaimer, the original version will
+     prevail.
+
+     If a section in the Document is Entitled "Acknowledgements",
+     "Dedications", or "History", the requirement (section 4) to
+     Preserve its Title (section 1) will typically require changing the
+     actual title.
+
+  9. TERMINATION
+
+     You may not copy, modify, sublicense, or distribute the Document
+     except as expressly provided under this License.  Any attempt
+     otherwise to copy, modify, sublicense, or distribute it is void,
+     and will automatically terminate your rights under this License.
+
+     However, if you cease all violation of this License, then your
+     license from a particular copyright holder is reinstated (a)
+     provisionally, unless and until the copyright holder explicitly and
+     finally terminates your license, and (b) permanently, if the
+     copyright holder fails to notify you of the violation by some
+     reasonable means prior to 60 days after the cessation.
+
+     Moreover, your license from a particular copyright holder is
+     reinstated permanently if the copyright holder notifies you of the
+     violation by some reasonable means, this is the first time you have
+     received notice of violation of this License (for any work) from
+     that copyright holder, and you cure the violation prior to 30 days
+     after your receipt of the notice.
+
+     Termination of your rights under this section does not terminate
+     the licenses of parties who have received copies or rights from you
+     under this License.  If your rights have been terminated and not
+     permanently reinstated, receipt of a copy of some or all of the
+     same material does not give you any rights to use it.
+
+  10. FUTURE REVISIONS OF THIS LICENSE
+
+     The Free Software Foundation may publish new, revised versions of
+     the GNU Free Documentation License from time to time.  Such new
+     versions will be similar in spirit to the present version, but may
+     differ in detail to address new problems or concerns.  See
+     <http://www.gnu.org/copyleft/>.
+
+     Each version of the License is given a distinguishing version
+     number.  If the Document specifies that a particular numbered
+     version of this License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that specified version or of any later version that has been
+     published (not as a draft) by the Free Software Foundation.  If the
+     Document does not specify a version number of this License, you may
+     choose any version ever published (not as a draft) by the Free
+     Software Foundation.  If the Document specifies that a proxy can
+     decide which future versions of this License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Document.
+
+  11. RELICENSING
+
+     "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
+     World Wide Web server that publishes copyrightable works and also
+     provides prominent facilities for anybody to edit those works.  A
+     public wiki that anybody can edit is an example of such a server.
+     A "Massive Multiauthor Collaboration" (or "MMC") contained in the
+     site means any set of copyrightable works thus published on the MMC
+     site.
+
+     "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
+     license published by Creative Commons Corporation, a not-for-profit
+     corporation with a principal place of business in San Francisco,
+     California, as well as future copyleft versions of that license
+     published by that same organization.
+
+     "Incorporate" means to publish or republish a Document, in whole or
+     in part, as part of another Document.
+
+     An MMC is "eligible for relicensing" if it is licensed under this
+     License, and if all works that were first published under this
+     License somewhere other than this MMC, and subsequently
+     incorporated in whole or in part into the MMC, (1) had no cover
+     texts or invariant sections, and (2) were thus incorporated prior
+     to November 1, 2008.
+
+     The operator of an MMC Site may republish an MMC contained in the
+     site under CC-BY-SA on the same site at any time before August 1,
+     2009, provided the MMC is eligible for relicensing.
+
+ADDENDUM: How to use this License for your documents
+====================================================
+
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and license
+notices just after the title page:
+
+       Copyright (C)  YEAR  YOUR NAME.
+       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, no Front-Cover Texts, and no Back-Cover
+       Texts.  A copy of the license is included in the section entitled ``GNU
+       Free Documentation License''.
+
+   If you have Invariant Sections, Front-Cover Texts and Back-Cover
+Texts, replace the "with...Texts."  line with this:
+
+         with the Invariant Sections being LIST THEIR TITLES, with
+         the Front-Cover Texts being LIST, and with the Back-Cover Texts
+         being LIST.
+
+   If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+
+   If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of free
+software license, such as the GNU General Public License, to permit
+their use in free software.
+
+
+File: gccinstall.info,  Node: Concept Index,  Prev: GNU Free Documentation License,  Up: Top
+
+Concept Index
+*************
+
+
+* Menu:
+
+* Binaries:                              Binaries.           (line    6)
+* 'build_configargs':                    Configuration.      (line 1492)
+* Configuration:                         Configuration.      (line    6)
+* configurations supported by GCC:       Configurations.     (line    6)
+* Downloading GCC:                       Downloading the source.
+                                                             (line    6)
+* Downloading the Source:                Downloading the source.
+                                                             (line    6)
+* FDL, GNU Free Documentation License:   GNU Free Documentation License.
+                                                             (line    6)
+* Host specific installation:            Specific.           (line    6)
+* 'host_configargs':                     Configuration.      (line 1496)
+* Installing GCC: Binaries:              Binaries.           (line    6)
+* Installing GCC: Building:              Building.           (line    6)
+* Installing GCC: Configuration:         Configuration.      (line    6)
+* Installing GCC: Testing:               Testing.            (line    6)
+* Prerequisites:                         Prerequisites.      (line    6)
+* Specific:                              Specific.           (line    6)
+* Specific installation notes:           Specific.           (line    6)
+* Target specific installation:          Specific.           (line    6)
+* Target specific installation notes:    Specific.           (line    6)
+* 'target_configargs':                   Configuration.      (line 1500)
+* Testing:                               Testing.            (line    6)
+* Testsuite:                             Testing.            (line    6)
+
+
+
+Tag Table:
+Node: Top1696
+Node: Installing GCC2254
+Node: Prerequisites3888
+Node: Downloading the source15564
+Node: Configuration17114
+Ref: with-gnu-as32585
+Ref: with-as33480
+Ref: with-gnu-ld34893
+Node: Building84585
+Node: Testing100052
+Node: Final install107914
+Node: Binaries113225
+Node: Specific114733
+Ref: alpha-x-x115240
+Ref: alpha-dec-osf51115729
+Ref: amd64-x-solaris210116254
+Ref: arc-x-elf32116357
+Ref: arc-linux-uclibc116533
+Ref: arm-x-eabi116674
+Ref: avr116885
+Ref: bfin117524
+Ref: cr16117765
+Ref: cris118181
+Ref: dos118996
+Ref: epiphany-x-elf119319
+Ref: x-x-freebsd119424
+Ref: h8300-hms121260
+Ref: hppa-hp-hpux121612
+Ref: hppa-hp-hpux10123984
+Ref: hppa-hp-hpux11124397
+Ref: x-x-linux-gnu130056
+Ref: ix86-x-linux130249
+Ref: ix86-x-solaris29130562
+Ref: ix86-x-solaris210131341
+Ref: ia64-x-linux132532
+Ref: ia64-x-hpux133302
+Ref: aarch64-x-x133857
+Ref: x-ibm-aix134059
+Ref: iq2000-x-elf140922
+Ref: lm32-x-elf141062
+Ref: lm32-x-uclinux141166
+Ref: m32c-x-elf141294
+Ref: m32r-x-elf141396
+Ref: m68k-x-x141498
+Ref: m68k-x-uclinux142536
+Ref: mep-x-elf142781
+Ref: microblaze-x-elf142891
+Ref: mips-x-x143010
+Ref: mips-sgi-irix5145404
+Ref: mips-sgi-irix6145484
+Ref: moxie-x-elf145671
+Ref: msp430-x-elf145718
+Ref: nds32le-x-elf145821
+Ref: nds32be-x-elf145893
+Ref: powerpc-x-x145962
+Ref: powerpc-x-darwin146167
+Ref: powerpc-x-elf146661
+Ref: powerpc-x-linux-gnu146746
+Ref: powerpc-x-netbsd146841
+Ref: powerpc-x-eabisim146929
+Ref: powerpc-x-eabi147055
+Ref: powerpcle-x-elf147131
+Ref: powerpcle-x-eabisim147223
+Ref: powerpcle-x-eabi147356
+Ref: rl78-x-elf147439
+Ref: rx-x-elf147545
+Ref: s390-x-linux147744
+Ref: s390x-x-linux147816
+Ref: s390x-ibm-tpf147903
+Ref: x-x-solaris2148034
+Ref: sparc-x-x152955
+Ref: sparc-sun-solaris2153457
+Ref: sparc-sun-solaris210156210
+Ref: sparc-x-linux156585
+Ref: sparc64-x-solaris2156810
+Ref: sparcv9-x-solaris2157463
+Ref: c6x-x-x157550
+Ref: tilegx-*-linux157642
+Ref: tilegxbe-*-linux157784
+Ref: tilepro-*-linux157927
+Ref: x-x-vxworks158048
+Ref: x86-64-x-x159571
+Ref: x86-64-x-solaris210159899
+Ref: xtensa-x-elf160561
+Ref: xtensa-x-linux161232
+Ref: windows161573
+Ref: x-x-cygwin163506
+Ref: x-x-interix164059
+Ref: x-x-mingw32164367
+Ref: older164593
+Ref: elf166710
+Node: Old166968
+Node: Configurations170101
+Node: GNU Free Documentation License173639
+Node: Concept Index198766
+
+End Tag Table
diff --git a/gcc-4.9/gcc/doc/gccint.info b/gcc-4.9/gcc/doc/gccint.info
new file mode 100644
index 000000000..c4b7319c9
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gccint.info
@@ -0,0 +1,50307 @@
+This is gccint.info, produced by makeinfo version 5.1 from gccint.texi.
+
+Copyright (C) 1988-2014 Free Software Foundation, Inc.
+
+ 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 the
+Invariant Sections being "Funding Free Software", 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 "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.
+INFO-DIR-SECTION Software development
+START-INFO-DIR-ENTRY
+* gccint: (gccint).            Internals of the GNU Compiler Collection.
+END-INFO-DIR-ENTRY
+
+ This file documents the internals of the GNU compilers.
+
+ Copyright (C) 1988-2014 Free Software Foundation, Inc.
+
+ 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 the
+Invariant Sections being "Funding Free Software", 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 "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.
+
+
+File: gccint.info,  Node: Top,  Next: Contributing,  Up: (DIR)
+
+Introduction
+************
+
+This manual documents the internals of the GNU compilers, including how
+to port them to new targets and some information about how to write
+front ends for new languages.  It corresponds to the compilers (GCC)
+version 4.9.0.  The use of the GNU compilers is documented in a separate
+manual.  *Note Introduction: (gcc)Top.
+
+ This manual is mainly a reference manual rather than a tutorial.  It
+discusses how to contribute to GCC (*note Contributing::), the
+characteristics of the machines supported by GCC as hosts and targets
+(*note Portability::), how GCC relates to the ABIs on such systems
+(*note Interface::), and the characteristics of the languages for which
+GCC front ends are written (*note Languages::).  It then describes the
+GCC source tree structure and build system, some of the interfaces to
+GCC front ends, and how support for a target system is implemented in
+GCC.
+
+ Additional tutorial information is linked to from
+<http://gcc.gnu.org/readings.html>.
+
+* Menu:
+
+* Contributing::    How to contribute to testing and developing GCC.
+* Portability::     Goals of GCC's portability features.
+* Interface::       Function-call interface of GCC output.
+* Libgcc::          Low-level runtime library used by GCC.
+* Languages::       Languages for which GCC front ends are written.
+* Source Tree::     GCC source tree structure and build system.
+* Testsuites::      GCC testsuites.
+* Options::         Option specification files.
+* Passes::          Order of passes, what they do, and what each file is for.
+* GENERIC::         Language-independent representation generated by Front Ends
+* GIMPLE::          Tuple representation used by Tree SSA optimizers
+* Tree SSA::        Analysis and optimization of GIMPLE
+* RTL::             Machine-dependent low-level intermediate representation.
+* Control Flow::    Maintaining and manipulating the control flow graph.
+* Loop Analysis and Representation:: Analysis and representation of loops
+* Machine Desc::    How to write machine description instruction patterns.
+* Target Macros::   How to write the machine description C macros and functions.
+* Host Config::     Writing the 'xm-MACHINE.h' file.
+* Fragments::       Writing the 't-TARGET' and 'x-HOST' files.
+* Collect2::        How 'collect2' works; how it finds 'ld'.
+* Header Dirs::     Understanding the standard header file directories.
+* Type Information:: GCC's memory management; generating type information.
+* Plugins::         Extending the compiler with plugins.
+* LTO::             Using Link-Time Optimization.
+
+* Funding::         How to help assure funding for free software.
+* GNU Project::     The GNU Project and GNU/Linux.
+
+* Copying::         GNU General Public License says
+                    how you can copy and share GCC.
+* GNU Free Documentation License:: How you can copy and share this manual.
+* Contributors::    People who have contributed to GCC.
+
+* Option Index::    Index to command line options.
+* Concept Index::   Index of concepts and symbol names.
+
+
+File: gccint.info,  Node: Contributing,  Next: Portability,  Up: Top
+
+1 Contributing to GCC Development
+*********************************
+
+If you would like to help pretest GCC releases to assure they work well,
+current development sources are available by SVN (see
+<http://gcc.gnu.org/svn.html>).  Source and binary snapshots are also
+available for FTP; see <http://gcc.gnu.org/snapshots.html>.
+
+ If you would like to work on improvements to GCC, please read the
+advice at these URLs:
+
+     <http://gcc.gnu.org/contribute.html>
+     <http://gcc.gnu.org/contributewhy.html>
+
+for information on how to make useful contributions and avoid
+duplication of effort.  Suggested projects are listed at
+<http://gcc.gnu.org/projects/>.
+
+
+File: gccint.info,  Node: Portability,  Next: Interface,  Prev: Contributing,  Up: Top
+
+2 GCC and Portability
+*********************
+
+GCC itself aims to be portable to any machine where 'int' is at least a
+32-bit type.  It aims to target machines with a flat (non-segmented)
+byte addressed data address space (the code address space can be
+separate).  Target ABIs may have 8, 16, 32 or 64-bit 'int' type.  'char'
+can be wider than 8 bits.
+
+ GCC gets most of the information about the target machine from a
+machine description which gives an algebraic formula for each of the
+machine's instructions.  This is a very clean way to describe the
+target.  But when the compiler needs information that is difficult to
+express in this fashion, ad-hoc parameters have been defined for machine
+descriptions.  The purpose of portability is to reduce the total work
+needed on the compiler; it was not of interest for its own sake.
+
+ GCC does not contain machine dependent code, but it does contain code
+that depends on machine parameters such as endianness (whether the most
+significant byte has the highest or lowest address of the bytes in a
+word) and the availability of autoincrement addressing.  In the
+RTL-generation pass, it is often necessary to have multiple strategies
+for generating code for a particular kind of syntax tree, strategies
+that are usable for different combinations of parameters.  Often, not
+all possible cases have been addressed, but only the common ones or only
+the ones that have been encountered.  As a result, a new target may
+require additional strategies.  You will know if this happens because
+the compiler will call 'abort'.  Fortunately, the new strategies can be
+added in a machine-independent fashion, and will affect only the target
+machines that need them.
+
+
+File: gccint.info,  Node: Interface,  Next: Libgcc,  Prev: Portability,  Up: Top
+
+3 Interfacing to GCC Output
+***************************
+
+GCC is normally configured to use the same function calling convention
+normally in use on the target system.  This is done with the
+machine-description macros described (*note Target Macros::).
+
+ However, returning of structure and union values is done differently on
+some target machines.  As a result, functions compiled with PCC
+returning such types cannot be called from code compiled with GCC, and
+vice versa.  This does not cause trouble often because few Unix library
+routines return structures or unions.
+
+ GCC code returns structures and unions that are 1, 2, 4 or 8 bytes long
+in the same registers used for 'int' or 'double' return values.  (GCC
+typically allocates variables of such types in registers also.)
+Structures and unions of other sizes are returned by storing them into
+an address passed by the caller (usually in a register).  The target
+hook 'TARGET_STRUCT_VALUE_RTX' tells GCC where to pass this address.
+
+ By contrast, PCC on most target machines returns structures and unions
+of any size by copying the data into an area of static storage, and then
+returning the address of that storage as if it were a pointer value.
+The caller must copy the data from that memory area to the place where
+the value is wanted.  This is slower than the method used by GCC, and
+fails to be reentrant.
+
+ On some target machines, such as RISC machines and the 80386, the
+standard system convention is to pass to the subroutine the address of
+where to return the value.  On these machines, GCC has been configured
+to be compatible with the standard compiler, when this method is used.
+It may not be compatible for structures of 1, 2, 4 or 8 bytes.
+
+ GCC uses the system's standard convention for passing arguments.  On
+some machines, the first few arguments are passed in registers; in
+others, all are passed on the stack.  It would be possible to use
+registers for argument passing on any machine, and this would probably
+result in a significant speedup.  But the result would be complete
+incompatibility with code that follows the standard convention.  So this
+change is practical only if you are switching to GCC as the sole C
+compiler for the system.  We may implement register argument passing on
+certain machines once we have a complete GNU system so that we can
+compile the libraries with GCC.
+
+ On some machines (particularly the SPARC), certain types of arguments
+are passed "by invisible reference".  This means that the value is
+stored in memory, and the address of the memory location is passed to
+the subroutine.
+
+ If you use 'longjmp', beware of automatic variables.  ISO C says that
+automatic variables that are not declared 'volatile' have undefined
+values after a 'longjmp'.  And this is all GCC promises to do, because
+it is very difficult to restore register variables correctly, and one of
+GCC's features is that it can put variables in registers without your
+asking it to.
+
+
+File: gccint.info,  Node: Libgcc,  Next: Languages,  Prev: Interface,  Up: Top
+
+4 The GCC low-level runtime library
+***********************************
+
+GCC provides a low-level runtime library, 'libgcc.a' or 'libgcc_s.so.1'
+on some platforms.  GCC generates calls to routines in this library
+automatically, whenever it needs to perform some operation that is too
+complicated to emit inline code for.
+
+ Most of the routines in 'libgcc' handle arithmetic operations that the
+target processor cannot perform directly.  This includes integer
+multiply and divide on some machines, and all floating-point and
+fixed-point operations on other machines.  'libgcc' also includes
+routines for exception handling, and a handful of miscellaneous
+operations.
+
+ Some of these routines can be defined in mostly machine-independent C.
+Others must be hand-written in assembly language for each processor that
+needs them.
+
+ GCC will also generate calls to C library routines, such as 'memcpy'
+and 'memset', in some cases.  The set of routines that GCC may possibly
+use is documented in *note (gcc)Other Builtins::.
+
+ These routines take arguments and return values of a specific machine
+mode, not a specific C type.  *Note Machine Modes::, for an explanation
+of this concept.  For illustrative purposes, in this chapter the
+floating point type 'float' is assumed to correspond to 'SFmode';
+'double' to 'DFmode'; and 'long double' to both 'TFmode' and 'XFmode'.
+Similarly, the integer types 'int' and 'unsigned int' correspond to
+'SImode'; 'long' and 'unsigned long' to 'DImode'; and 'long long' and
+'unsigned long long' to 'TImode'.
+
+* Menu:
+
+* Integer library routines::
+* Soft float library routines::
+* Decimal float library routines::
+* Fixed-point fractional library routines::
+* Exception handling routines::
+* Miscellaneous routines::
+
+
+File: gccint.info,  Node: Integer library routines,  Next: Soft float library routines,  Up: Libgcc
+
+4.1 Routines for integer arithmetic
+===================================
+
+The integer arithmetic routines are used on platforms that don't provide
+hardware support for arithmetic operations on some modes.
+
+4.1.1 Arithmetic functions
+--------------------------
+
+ -- Runtime Function: int __ashlsi3 (int A, int B)
+ -- Runtime Function: long __ashldi3 (long A, int B)
+ -- Runtime Function: long long __ashlti3 (long long A, int B)
+     These functions return the result of shifting A left by B bits.
+
+ -- Runtime Function: int __ashrsi3 (int A, int B)
+ -- Runtime Function: long __ashrdi3 (long A, int B)
+ -- Runtime Function: long long __ashrti3 (long long A, int B)
+     These functions return the result of arithmetically shifting A
+     right by B bits.
+
+ -- Runtime Function: int __divsi3 (int A, int B)
+ -- Runtime Function: long __divdi3 (long A, long B)
+ -- Runtime Function: long long __divti3 (long long A, long long B)
+     These functions return the quotient of the signed division of A and
+     B.
+
+ -- Runtime Function: int __lshrsi3 (int A, int B)
+ -- Runtime Function: long __lshrdi3 (long A, int B)
+ -- Runtime Function: long long __lshrti3 (long long A, int B)
+     These functions return the result of logically shifting A right by
+     B bits.
+
+ -- Runtime Function: int __modsi3 (int A, int B)
+ -- Runtime Function: long __moddi3 (long A, long B)
+ -- Runtime Function: long long __modti3 (long long A, long long B)
+     These functions return the remainder of the signed division of A
+     and B.
+
+ -- Runtime Function: int __mulsi3 (int A, int B)
+ -- Runtime Function: long __muldi3 (long A, long B)
+ -- Runtime Function: long long __multi3 (long long A, long long B)
+     These functions return the product of A and B.
+
+ -- Runtime Function: long __negdi2 (long A)
+ -- Runtime Function: long long __negti2 (long long A)
+     These functions return the negation of A.
+
+ -- Runtime Function: unsigned int __udivsi3 (unsigned int A, unsigned
+          int B)
+ -- Runtime Function: unsigned long __udivdi3 (unsigned long A, unsigned
+          long B)
+ -- Runtime Function: unsigned long long __udivti3 (unsigned long long
+          A, unsigned long long B)
+     These functions return the quotient of the unsigned division of A
+     and B.
+
+ -- Runtime Function: unsigned long __udivmoddi4 (unsigned long A,
+          unsigned long B, unsigned long *C)
+ -- Runtime Function: unsigned long long __udivmodti4 (unsigned long
+          long A, unsigned long long B, unsigned long long *C)
+     These functions calculate both the quotient and remainder of the
+     unsigned division of A and B.  The return value is the quotient,
+     and the remainder is placed in variable pointed to by C.
+
+ -- Runtime Function: unsigned int __umodsi3 (unsigned int A, unsigned
+          int B)
+ -- Runtime Function: unsigned long __umoddi3 (unsigned long A, unsigned
+          long B)
+ -- Runtime Function: unsigned long long __umodti3 (unsigned long long
+          A, unsigned long long B)
+     These functions return the remainder of the unsigned division of A
+     and B.
+
+4.1.2 Comparison functions
+--------------------------
+
+The following functions implement integral comparisons.  These functions
+implement a low-level compare, upon which the higher level comparison
+operators (such as less than and greater than or equal to) can be
+constructed.  The returned values lie in the range zero to two, to allow
+the high-level operators to be implemented by testing the returned
+result using either signed or unsigned comparison.
+
+ -- Runtime Function: int __cmpdi2 (long A, long B)
+ -- Runtime Function: int __cmpti2 (long long A, long long B)
+     These functions perform a signed comparison of A and B.  If A is
+     less than B, they return 0; if A is greater than B, they return 2;
+     and if A and B are equal they return 1.
+
+ -- Runtime Function: int __ucmpdi2 (unsigned long A, unsigned long B)
+ -- Runtime Function: int __ucmpti2 (unsigned long long A, unsigned long
+          long B)
+     These functions perform an unsigned comparison of A and B.  If A is
+     less than B, they return 0; if A is greater than B, they return 2;
+     and if A and B are equal they return 1.
+
+4.1.3 Trapping arithmetic functions
+-----------------------------------
+
+The following functions implement trapping arithmetic.  These functions
+call the libc function 'abort' upon signed arithmetic overflow.
+
+ -- Runtime Function: int __absvsi2 (int A)
+ -- Runtime Function: long __absvdi2 (long A)
+     These functions return the absolute value of A.
+
+ -- Runtime Function: int __addvsi3 (int A, int B)
+ -- Runtime Function: long __addvdi3 (long A, long B)
+     These functions return the sum of A and B; that is 'A + B'.
+
+ -- Runtime Function: int __mulvsi3 (int A, int B)
+ -- Runtime Function: long __mulvdi3 (long A, long B)
+     The functions return the product of A and B; that is 'A * B'.
+
+ -- Runtime Function: int __negvsi2 (int A)
+ -- Runtime Function: long __negvdi2 (long A)
+     These functions return the negation of A; that is '-A'.
+
+ -- Runtime Function: int __subvsi3 (int A, int B)
+ -- Runtime Function: long __subvdi3 (long A, long B)
+     These functions return the difference between B and A; that is 'A -
+     B'.
+
+4.1.4 Bit operations
+--------------------
+
+ -- Runtime Function: int __clzsi2 (int A)
+ -- Runtime Function: int __clzdi2 (long A)
+ -- Runtime Function: int __clzti2 (long long A)
+     These functions return the number of leading 0-bits in A, starting
+     at the most significant bit position.  If A is zero, the result is
+     undefined.
+
+ -- Runtime Function: int __ctzsi2 (int A)
+ -- Runtime Function: int __ctzdi2 (long A)
+ -- Runtime Function: int __ctzti2 (long long A)
+     These functions return the number of trailing 0-bits in A, starting
+     at the least significant bit position.  If A is zero, the result is
+     undefined.
+
+ -- Runtime Function: int __ffsdi2 (long A)
+ -- Runtime Function: int __ffsti2 (long long A)
+     These functions return the index of the least significant 1-bit in
+     A, or the value zero if A is zero.  The least significant bit is
+     index one.
+
+ -- Runtime Function: int __paritysi2 (int A)
+ -- Runtime Function: int __paritydi2 (long A)
+ -- Runtime Function: int __parityti2 (long long A)
+     These functions return the value zero if the number of bits set in
+     A is even, and the value one otherwise.
+
+ -- Runtime Function: int __popcountsi2 (int A)
+ -- Runtime Function: int __popcountdi2 (long A)
+ -- Runtime Function: int __popcountti2 (long long A)
+     These functions return the number of bits set in A.
+
+ -- Runtime Function: int32_t __bswapsi2 (int32_t A)
+ -- Runtime Function: int64_t __bswapdi2 (int64_t A)
+     These functions return the A byteswapped.
+
+
+File: gccint.info,  Node: Soft float library routines,  Next: Decimal float library routines,  Prev: Integer library routines,  Up: Libgcc
+
+4.2 Routines for floating point emulation
+=========================================
+
+The software floating point library is used on machines which do not
+have hardware support for floating point.  It is also used whenever
+'-msoft-float' is used to disable generation of floating point
+instructions.  (Not all targets support this switch.)
+
+ For compatibility with other compilers, the floating point emulation
+routines can be renamed with the 'DECLARE_LIBRARY_RENAMES' macro (*note
+Library Calls::).  In this section, the default names are used.
+
+ Presently the library does not support 'XFmode', which is used for
+'long double' on some architectures.
+
+4.2.1 Arithmetic functions
+--------------------------
+
+ -- Runtime Function: float __addsf3 (float A, float B)
+ -- Runtime Function: double __adddf3 (double A, double B)
+ -- Runtime Function: long double __addtf3 (long double A, long double
+          B)
+ -- Runtime Function: long double __addxf3 (long double A, long double
+          B)
+     These functions return the sum of A and B.
+
+ -- Runtime Function: float __subsf3 (float A, float B)
+ -- Runtime Function: double __subdf3 (double A, double B)
+ -- Runtime Function: long double __subtf3 (long double A, long double
+          B)
+ -- Runtime Function: long double __subxf3 (long double A, long double
+          B)
+     These functions return the difference between B and A; that is,
+     A - B.
+
+ -- Runtime Function: float __mulsf3 (float A, float B)
+ -- Runtime Function: double __muldf3 (double A, double B)
+ -- Runtime Function: long double __multf3 (long double A, long double
+          B)
+ -- Runtime Function: long double __mulxf3 (long double A, long double
+          B)
+     These functions return the product of A and B.
+
+ -- Runtime Function: float __divsf3 (float A, float B)
+ -- Runtime Function: double __divdf3 (double A, double B)
+ -- Runtime Function: long double __divtf3 (long double A, long double
+          B)
+ -- Runtime Function: long double __divxf3 (long double A, long double
+          B)
+     These functions return the quotient of A and B; that is, A / B.
+
+ -- Runtime Function: float __negsf2 (float A)
+ -- Runtime Function: double __negdf2 (double A)
+ -- Runtime Function: long double __negtf2 (long double A)
+ -- Runtime Function: long double __negxf2 (long double A)
+     These functions return the negation of A.  They simply flip the
+     sign bit, so they can produce negative zero and negative NaN.
+
+4.2.2 Conversion functions
+--------------------------
+
+ -- Runtime Function: double __extendsfdf2 (float A)
+ -- Runtime Function: long double __extendsftf2 (float A)
+ -- Runtime Function: long double __extendsfxf2 (float A)
+ -- Runtime Function: long double __extenddftf2 (double A)
+ -- Runtime Function: long double __extenddfxf2 (double A)
+     These functions extend A to the wider mode of their return type.
+
+ -- Runtime Function: double __truncxfdf2 (long double A)
+ -- Runtime Function: double __trunctfdf2 (long double A)
+ -- Runtime Function: float __truncxfsf2 (long double A)
+ -- Runtime Function: float __trunctfsf2 (long double A)
+ -- Runtime Function: float __truncdfsf2 (double A)
+     These functions truncate A to the narrower mode of their return
+     type, rounding toward zero.
+
+ -- Runtime Function: int __fixsfsi (float A)
+ -- Runtime Function: int __fixdfsi (double A)
+ -- Runtime Function: int __fixtfsi (long double A)
+ -- Runtime Function: int __fixxfsi (long double A)
+     These functions convert A to a signed integer, rounding toward
+     zero.
+
+ -- Runtime Function: long __fixsfdi (float A)
+ -- Runtime Function: long __fixdfdi (double A)
+ -- Runtime Function: long __fixtfdi (long double A)
+ -- Runtime Function: long __fixxfdi (long double A)
+     These functions convert A to a signed long, rounding toward zero.
+
+ -- Runtime Function: long long __fixsfti (float A)
+ -- Runtime Function: long long __fixdfti (double A)
+ -- Runtime Function: long long __fixtfti (long double A)
+ -- Runtime Function: long long __fixxfti (long double A)
+     These functions convert A to a signed long long, rounding toward
+     zero.
+
+ -- Runtime Function: unsigned int __fixunssfsi (float A)
+ -- Runtime Function: unsigned int __fixunsdfsi (double A)
+ -- Runtime Function: unsigned int __fixunstfsi (long double A)
+ -- Runtime Function: unsigned int __fixunsxfsi (long double A)
+     These functions convert A to an unsigned integer, rounding toward
+     zero.  Negative values all become zero.
+
+ -- Runtime Function: unsigned long __fixunssfdi (float A)
+ -- Runtime Function: unsigned long __fixunsdfdi (double A)
+ -- Runtime Function: unsigned long __fixunstfdi (long double A)
+ -- Runtime Function: unsigned long __fixunsxfdi (long double A)
+     These functions convert A to an unsigned long, rounding toward
+     zero.  Negative values all become zero.
+
+ -- Runtime Function: unsigned long long __fixunssfti (float A)
+ -- Runtime Function: unsigned long long __fixunsdfti (double A)
+ -- Runtime Function: unsigned long long __fixunstfti (long double A)
+ -- Runtime Function: unsigned long long __fixunsxfti (long double A)
+     These functions convert A to an unsigned long long, rounding toward
+     zero.  Negative values all become zero.
+
+ -- Runtime Function: float __floatsisf (int I)
+ -- Runtime Function: double __floatsidf (int I)
+ -- Runtime Function: long double __floatsitf (int I)
+ -- Runtime Function: long double __floatsixf (int I)
+     These functions convert I, a signed integer, to floating point.
+
+ -- Runtime Function: float __floatdisf (long I)
+ -- Runtime Function: double __floatdidf (long I)
+ -- Runtime Function: long double __floatditf (long I)
+ -- Runtime Function: long double __floatdixf (long I)
+     These functions convert I, a signed long, to floating point.
+
+ -- Runtime Function: float __floattisf (long long I)
+ -- Runtime Function: double __floattidf (long long I)
+ -- Runtime Function: long double __floattitf (long long I)
+ -- Runtime Function: long double __floattixf (long long I)
+     These functions convert I, a signed long long, to floating point.
+
+ -- Runtime Function: float __floatunsisf (unsigned int I)
+ -- Runtime Function: double __floatunsidf (unsigned int I)
+ -- Runtime Function: long double __floatunsitf (unsigned int I)
+ -- Runtime Function: long double __floatunsixf (unsigned int I)
+     These functions convert I, an unsigned integer, to floating point.
+
+ -- Runtime Function: float __floatundisf (unsigned long I)
+ -- Runtime Function: double __floatundidf (unsigned long I)
+ -- Runtime Function: long double __floatunditf (unsigned long I)
+ -- Runtime Function: long double __floatundixf (unsigned long I)
+     These functions convert I, an unsigned long, to floating point.
+
+ -- Runtime Function: float __floatuntisf (unsigned long long I)
+ -- Runtime Function: double __floatuntidf (unsigned long long I)
+ -- Runtime Function: long double __floatuntitf (unsigned long long I)
+ -- Runtime Function: long double __floatuntixf (unsigned long long I)
+     These functions convert I, an unsigned long long, to floating
+     point.
+
+4.2.3 Comparison functions
+--------------------------
+
+There are two sets of basic comparison functions.
+
+ -- Runtime Function: int __cmpsf2 (float A, float B)
+ -- Runtime Function: int __cmpdf2 (double A, double B)
+ -- Runtime Function: int __cmptf2 (long double A, long double B)
+     These functions calculate a <=> b.  That is, if A is less than B,
+     they return -1; if A is greater than B, they return 1; and if A and
+     B are equal they return 0.  If either argument is NaN they return
+     1, but you should not rely on this; if NaN is a possibility, use
+     one of the higher-level comparison functions.
+
+ -- Runtime Function: int __unordsf2 (float A, float B)
+ -- Runtime Function: int __unorddf2 (double A, double B)
+ -- Runtime Function: int __unordtf2 (long double A, long double B)
+     These functions return a nonzero value if either argument is NaN,
+     otherwise 0.
+
+ There is also a complete group of higher level functions which
+correspond directly to comparison operators.  They implement the ISO C
+semantics for floating-point comparisons, taking NaN into account.  Pay
+careful attention to the return values defined for each set.  Under the
+hood, all of these routines are implemented as
+
+       if (__unordXf2 (a, b))
+         return E;
+       return __cmpXf2 (a, b);
+
+where E is a constant chosen to give the proper behavior for NaN.  Thus,
+the meaning of the return value is different for each set.  Do not rely
+on this implementation; only the semantics documented below are
+guaranteed.
+
+ -- Runtime Function: int __eqsf2 (float A, float B)
+ -- Runtime Function: int __eqdf2 (double A, double B)
+ -- Runtime Function: int __eqtf2 (long double A, long double B)
+     These functions return zero if neither argument is NaN, and A and B
+     are equal.
+
+ -- Runtime Function: int __nesf2 (float A, float B)
+ -- Runtime Function: int __nedf2 (double A, double B)
+ -- Runtime Function: int __netf2 (long double A, long double B)
+     These functions return a nonzero value if either argument is NaN,
+     or if A and B are unequal.
+
+ -- Runtime Function: int __gesf2 (float A, float B)
+ -- Runtime Function: int __gedf2 (double A, double B)
+ -- Runtime Function: int __getf2 (long double A, long double B)
+     These functions return a value greater than or equal to zero if
+     neither argument is NaN, and A is greater than or equal to B.
+
+ -- Runtime Function: int __ltsf2 (float A, float B)
+ -- Runtime Function: int __ltdf2 (double A, double B)
+ -- Runtime Function: int __lttf2 (long double A, long double B)
+     These functions return a value less than zero if neither argument
+     is NaN, and A is strictly less than B.
+
+ -- Runtime Function: int __lesf2 (float A, float B)
+ -- Runtime Function: int __ledf2 (double A, double B)
+ -- Runtime Function: int __letf2 (long double A, long double B)
+     These functions return a value less than or equal to zero if
+     neither argument is NaN, and A is less than or equal to B.
+
+ -- Runtime Function: int __gtsf2 (float A, float B)
+ -- Runtime Function: int __gtdf2 (double A, double B)
+ -- Runtime Function: int __gttf2 (long double A, long double B)
+     These functions return a value greater than zero if neither
+     argument is NaN, and A is strictly greater than B.
+
+4.2.4 Other floating-point functions
+------------------------------------
+
+ -- Runtime Function: float __powisf2 (float A, int B)
+ -- Runtime Function: double __powidf2 (double A, int B)
+ -- Runtime Function: long double __powitf2 (long double A, int B)
+ -- Runtime Function: long double __powixf2 (long double A, int B)
+     These functions convert raise A to the power B.
+
+ -- Runtime Function: complex float __mulsc3 (float A, float B, float C,
+          float D)
+ -- Runtime Function: complex double __muldc3 (double A, double B,
+          double C, double D)
+ -- Runtime Function: complex long double __multc3 (long double A, long
+          double B, long double C, long double D)
+ -- Runtime Function: complex long double __mulxc3 (long double A, long
+          double B, long double C, long double D)
+     These functions return the product of A + iB and C + iD, following
+     the rules of C99 Annex G.
+
+ -- Runtime Function: complex float __divsc3 (float A, float B, float C,
+          float D)
+ -- Runtime Function: complex double __divdc3 (double A, double B,
+          double C, double D)
+ -- Runtime Function: complex long double __divtc3 (long double A, long
+          double B, long double C, long double D)
+ -- Runtime Function: complex long double __divxc3 (long double A, long
+          double B, long double C, long double D)
+     These functions return the quotient of A + iB and C + iD (i.e., (A
+     + iB) / (C + iD)), following the rules of C99 Annex G.
+
+
+File: gccint.info,  Node: Decimal float library routines,  Next: Fixed-point fractional library routines,  Prev: Soft float library routines,  Up: Libgcc
+
+4.3 Routines for decimal floating point emulation
+=================================================
+
+The software decimal floating point library implements IEEE 754-2008
+decimal floating point arithmetic and is only activated on selected
+targets.
+
+ The software decimal floating point library supports either DPD
+(Densely Packed Decimal) or BID (Binary Integer Decimal) encoding as
+selected at configure time.
+
+4.3.1 Arithmetic functions
+--------------------------
+
+ -- Runtime Function: _Decimal32 __dpd_addsd3 (_Decimal32 A, _Decimal32
+          B)
+ -- Runtime Function: _Decimal32 __bid_addsd3 (_Decimal32 A, _Decimal32
+          B)
+ -- Runtime Function: _Decimal64 __dpd_adddd3 (_Decimal64 A, _Decimal64
+          B)
+ -- Runtime Function: _Decimal64 __bid_adddd3 (_Decimal64 A, _Decimal64
+          B)
+ -- Runtime Function: _Decimal128 __dpd_addtd3 (_Decimal128 A,
+          _Decimal128 B)
+ -- Runtime Function: _Decimal128 __bid_addtd3 (_Decimal128 A,
+          _Decimal128 B)
+     These functions return the sum of A and B.
+
+ -- Runtime Function: _Decimal32 __dpd_subsd3 (_Decimal32 A, _Decimal32
+          B)
+ -- Runtime Function: _Decimal32 __bid_subsd3 (_Decimal32 A, _Decimal32
+          B)
+ -- Runtime Function: _Decimal64 __dpd_subdd3 (_Decimal64 A, _Decimal64
+          B)
+ -- Runtime Function: _Decimal64 __bid_subdd3 (_Decimal64 A, _Decimal64
+          B)
+ -- Runtime Function: _Decimal128 __dpd_subtd3 (_Decimal128 A,
+          _Decimal128 B)
+ -- Runtime Function: _Decimal128 __bid_subtd3 (_Decimal128 A,
+          _Decimal128 B)
+     These functions return the difference between B and A; that is,
+     A - B.
+
+ -- Runtime Function: _Decimal32 __dpd_mulsd3 (_Decimal32 A, _Decimal32
+          B)
+ -- Runtime Function: _Decimal32 __bid_mulsd3 (_Decimal32 A, _Decimal32
+          B)
+ -- Runtime Function: _Decimal64 __dpd_muldd3 (_Decimal64 A, _Decimal64
+          B)
+ -- Runtime Function: _Decimal64 __bid_muldd3 (_Decimal64 A, _Decimal64
+          B)
+ -- Runtime Function: _Decimal128 __dpd_multd3 (_Decimal128 A,
+          _Decimal128 B)
+ -- Runtime Function: _Decimal128 __bid_multd3 (_Decimal128 A,
+          _Decimal128 B)
+     These functions return the product of A and B.
+
+ -- Runtime Function: _Decimal32 __dpd_divsd3 (_Decimal32 A, _Decimal32
+          B)
+ -- Runtime Function: _Decimal32 __bid_divsd3 (_Decimal32 A, _Decimal32
+          B)
+ -- Runtime Function: _Decimal64 __dpd_divdd3 (_Decimal64 A, _Decimal64
+          B)
+ -- Runtime Function: _Decimal64 __bid_divdd3 (_Decimal64 A, _Decimal64
+          B)
+ -- Runtime Function: _Decimal128 __dpd_divtd3 (_Decimal128 A,
+          _Decimal128 B)
+ -- Runtime Function: _Decimal128 __bid_divtd3 (_Decimal128 A,
+          _Decimal128 B)
+     These functions return the quotient of A and B; that is, A / B.
+
+ -- Runtime Function: _Decimal32 __dpd_negsd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal32 __bid_negsd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal64 __dpd_negdd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal64 __bid_negdd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal128 __dpd_negtd2 (_Decimal128 A)
+ -- Runtime Function: _Decimal128 __bid_negtd2 (_Decimal128 A)
+     These functions return the negation of A.  They simply flip the
+     sign bit, so they can produce negative zero and negative NaN.
+
+4.3.2 Conversion functions
+--------------------------
+
+ -- Runtime Function: _Decimal64 __dpd_extendsddd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal64 __bid_extendsddd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal128 __dpd_extendsdtd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal128 __bid_extendsdtd2 (_Decimal32 A)
+ -- Runtime Function: _Decimal128 __dpd_extendddtd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal128 __bid_extendddtd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal32 __dpd_truncddsd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal32 __bid_truncddsd2 (_Decimal64 A)
+ -- Runtime Function: _Decimal32 __dpd_trunctdsd2 (_Decimal128 A)
+ -- Runtime Function: _Decimal32 __bid_trunctdsd2 (_Decimal128 A)
+ -- Runtime Function: _Decimal64 __dpd_trunctddd2 (_Decimal128 A)
+ -- Runtime Function: _Decimal64 __bid_trunctddd2 (_Decimal128 A)
+     These functions convert the value A from one decimal floating type
+     to another.
+
+ -- Runtime Function: _Decimal64 __dpd_extendsfdd (float A)
+ -- Runtime Function: _Decimal64 __bid_extendsfdd (float A)
+ -- Runtime Function: _Decimal128 __dpd_extendsftd (float A)
+ -- Runtime Function: _Decimal128 __bid_extendsftd (float A)
+ -- Runtime Function: _Decimal128 __dpd_extenddftd (double A)
+ -- Runtime Function: _Decimal128 __bid_extenddftd (double A)
+ -- Runtime Function: _Decimal128 __dpd_extendxftd (long double A)
+ -- Runtime Function: _Decimal128 __bid_extendxftd (long double A)
+ -- Runtime Function: _Decimal32 __dpd_truncdfsd (double A)
+ -- Runtime Function: _Decimal32 __bid_truncdfsd (double A)
+ -- Runtime Function: _Decimal32 __dpd_truncxfsd (long double A)
+ -- Runtime Function: _Decimal32 __bid_truncxfsd (long double A)
+ -- Runtime Function: _Decimal32 __dpd_trunctfsd (long double A)
+ -- Runtime Function: _Decimal32 __bid_trunctfsd (long double A)
+ -- Runtime Function: _Decimal64 __dpd_truncxfdd (long double A)
+ -- Runtime Function: _Decimal64 __bid_truncxfdd (long double A)
+ -- Runtime Function: _Decimal64 __dpd_trunctfdd (long double A)
+ -- Runtime Function: _Decimal64 __bid_trunctfdd (long double A)
+     These functions convert the value of A from a binary floating type
+     to a decimal floating type of a different size.
+
+ -- Runtime Function: float __dpd_truncddsf (_Decimal64 A)
+ -- Runtime Function: float __bid_truncddsf (_Decimal64 A)
+ -- Runtime Function: float __dpd_trunctdsf (_Decimal128 A)
+ -- Runtime Function: float __bid_trunctdsf (_Decimal128 A)
+ -- Runtime Function: double __dpd_extendsddf (_Decimal32 A)
+ -- Runtime Function: double __bid_extendsddf (_Decimal32 A)
+ -- Runtime Function: double __dpd_trunctddf (_Decimal128 A)
+ -- Runtime Function: double __bid_trunctddf (_Decimal128 A)
+ -- Runtime Function: long double __dpd_extendsdxf (_Decimal32 A)
+ -- Runtime Function: long double __bid_extendsdxf (_Decimal32 A)
+ -- Runtime Function: long double __dpd_extendddxf (_Decimal64 A)
+ -- Runtime Function: long double __bid_extendddxf (_Decimal64 A)
+ -- Runtime Function: long double __dpd_trunctdxf (_Decimal128 A)
+ -- Runtime Function: long double __bid_trunctdxf (_Decimal128 A)
+ -- Runtime Function: long double __dpd_extendsdtf (_Decimal32 A)
+ -- Runtime Function: long double __bid_extendsdtf (_Decimal32 A)
+ -- Runtime Function: long double __dpd_extendddtf (_Decimal64 A)
+ -- Runtime Function: long double __bid_extendddtf (_Decimal64 A)
+     These functions convert the value of A from a decimal floating type
+     to a binary floating type of a different size.
+
+ -- Runtime Function: _Decimal32 __dpd_extendsfsd (float A)
+ -- Runtime Function: _Decimal32 __bid_extendsfsd (float A)
+ -- Runtime Function: _Decimal64 __dpd_extenddfdd (double A)
+ -- Runtime Function: _Decimal64 __bid_extenddfdd (double A)
+ -- Runtime Function: _Decimal128 __dpd_extendtftd (long double A)
+ -- Runtime Function: _Decimal128 __bid_extendtftd (long double A)
+ -- Runtime Function: float __dpd_truncsdsf (_Decimal32 A)
+ -- Runtime Function: float __bid_truncsdsf (_Decimal32 A)
+ -- Runtime Function: double __dpd_truncdddf (_Decimal64 A)
+ -- Runtime Function: double __bid_truncdddf (_Decimal64 A)
+ -- Runtime Function: long double __dpd_trunctdtf (_Decimal128 A)
+ -- Runtime Function: long double __bid_trunctdtf (_Decimal128 A)
+     These functions convert the value of A between decimal and binary
+     floating types of the same size.
+
+ -- Runtime Function: int __dpd_fixsdsi (_Decimal32 A)
+ -- Runtime Function: int __bid_fixsdsi (_Decimal32 A)
+ -- Runtime Function: int __dpd_fixddsi (_Decimal64 A)
+ -- Runtime Function: int __bid_fixddsi (_Decimal64 A)
+ -- Runtime Function: int __dpd_fixtdsi (_Decimal128 A)
+ -- Runtime Function: int __bid_fixtdsi (_Decimal128 A)
+     These functions convert A to a signed integer.
+
+ -- Runtime Function: long __dpd_fixsddi (_Decimal32 A)
+ -- Runtime Function: long __bid_fixsddi (_Decimal32 A)
+ -- Runtime Function: long __dpd_fixdddi (_Decimal64 A)
+ -- Runtime Function: long __bid_fixdddi (_Decimal64 A)
+ -- Runtime Function: long __dpd_fixtddi (_Decimal128 A)
+ -- Runtime Function: long __bid_fixtddi (_Decimal128 A)
+     These functions convert A to a signed long.
+
+ -- Runtime Function: unsigned int __dpd_fixunssdsi (_Decimal32 A)
+ -- Runtime Function: unsigned int __bid_fixunssdsi (_Decimal32 A)
+ -- Runtime Function: unsigned int __dpd_fixunsddsi (_Decimal64 A)
+ -- Runtime Function: unsigned int __bid_fixunsddsi (_Decimal64 A)
+ -- Runtime Function: unsigned int __dpd_fixunstdsi (_Decimal128 A)
+ -- Runtime Function: unsigned int __bid_fixunstdsi (_Decimal128 A)
+     These functions convert A to an unsigned integer.  Negative values
+     all become zero.
+
+ -- Runtime Function: unsigned long __dpd_fixunssddi (_Decimal32 A)
+ -- Runtime Function: unsigned long __bid_fixunssddi (_Decimal32 A)
+ -- Runtime Function: unsigned long __dpd_fixunsdddi (_Decimal64 A)
+ -- Runtime Function: unsigned long __bid_fixunsdddi (_Decimal64 A)
+ -- Runtime Function: unsigned long __dpd_fixunstddi (_Decimal128 A)
+ -- Runtime Function: unsigned long __bid_fixunstddi (_Decimal128 A)
+     These functions convert A to an unsigned long.  Negative values all
+     become zero.
+
+ -- Runtime Function: _Decimal32 __dpd_floatsisd (int I)
+ -- Runtime Function: _Decimal32 __bid_floatsisd (int I)
+ -- Runtime Function: _Decimal64 __dpd_floatsidd (int I)
+ -- Runtime Function: _Decimal64 __bid_floatsidd (int I)
+ -- Runtime Function: _Decimal128 __dpd_floatsitd (int I)
+ -- Runtime Function: _Decimal128 __bid_floatsitd (int I)
+     These functions convert I, a signed integer, to decimal floating
+     point.
+
+ -- Runtime Function: _Decimal32 __dpd_floatdisd (long I)
+ -- Runtime Function: _Decimal32 __bid_floatdisd (long I)
+ -- Runtime Function: _Decimal64 __dpd_floatdidd (long I)
+ -- Runtime Function: _Decimal64 __bid_floatdidd (long I)
+ -- Runtime Function: _Decimal128 __dpd_floatditd (long I)
+ -- Runtime Function: _Decimal128 __bid_floatditd (long I)
+     These functions convert I, a signed long, to decimal floating
+     point.
+
+ -- Runtime Function: _Decimal32 __dpd_floatunssisd (unsigned int I)
+ -- Runtime Function: _Decimal32 __bid_floatunssisd (unsigned int I)
+ -- Runtime Function: _Decimal64 __dpd_floatunssidd (unsigned int I)
+ -- Runtime Function: _Decimal64 __bid_floatunssidd (unsigned int I)
+ -- Runtime Function: _Decimal128 __dpd_floatunssitd (unsigned int I)
+ -- Runtime Function: _Decimal128 __bid_floatunssitd (unsigned int I)
+     These functions convert I, an unsigned integer, to decimal floating
+     point.
+
+ -- Runtime Function: _Decimal32 __dpd_floatunsdisd (unsigned long I)
+ -- Runtime Function: _Decimal32 __bid_floatunsdisd (unsigned long I)
+ -- Runtime Function: _Decimal64 __dpd_floatunsdidd (unsigned long I)
+ -- Runtime Function: _Decimal64 __bid_floatunsdidd (unsigned long I)
+ -- Runtime Function: _Decimal128 __dpd_floatunsditd (unsigned long I)
+ -- Runtime Function: _Decimal128 __bid_floatunsditd (unsigned long I)
+     These functions convert I, an unsigned long, to decimal floating
+     point.
+
+4.3.3 Comparison functions
+--------------------------
+
+ -- Runtime Function: int __dpd_unordsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_unordsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_unorddd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_unorddd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_unordtd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_unordtd2 (_Decimal128 A, _Decimal128 B)
+     These functions return a nonzero value if either argument is NaN,
+     otherwise 0.
+
+ There is also a complete group of higher level functions which
+correspond directly to comparison operators.  They implement the ISO C
+semantics for floating-point comparisons, taking NaN into account.  Pay
+careful attention to the return values defined for each set.  Under the
+hood, all of these routines are implemented as
+
+       if (__bid_unordXd2 (a, b))
+         return E;
+       return __bid_cmpXd2 (a, b);
+
+where E is a constant chosen to give the proper behavior for NaN.  Thus,
+the meaning of the return value is different for each set.  Do not rely
+on this implementation; only the semantics documented below are
+guaranteed.
+
+ -- Runtime Function: int __dpd_eqsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_eqsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_eqdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_eqdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_eqtd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_eqtd2 (_Decimal128 A, _Decimal128 B)
+     These functions return zero if neither argument is NaN, and A and B
+     are equal.
+
+ -- Runtime Function: int __dpd_nesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_nesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_nedd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_nedd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_netd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_netd2 (_Decimal128 A, _Decimal128 B)
+     These functions return a nonzero value if either argument is NaN,
+     or if A and B are unequal.
+
+ -- Runtime Function: int __dpd_gesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_gesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_gedd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_gedd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_getd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_getd2 (_Decimal128 A, _Decimal128 B)
+     These functions return a value greater than or equal to zero if
+     neither argument is NaN, and A is greater than or equal to B.
+
+ -- Runtime Function: int __dpd_ltsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_ltsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_ltdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_ltdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_lttd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_lttd2 (_Decimal128 A, _Decimal128 B)
+     These functions return a value less than zero if neither argument
+     is NaN, and A is strictly less than B.
+
+ -- Runtime Function: int __dpd_lesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_lesd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_ledd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_ledd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_letd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_letd2 (_Decimal128 A, _Decimal128 B)
+     These functions return a value less than or equal to zero if
+     neither argument is NaN, and A is less than or equal to B.
+
+ -- Runtime Function: int __dpd_gtsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __bid_gtsd2 (_Decimal32 A, _Decimal32 B)
+ -- Runtime Function: int __dpd_gtdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __bid_gtdd2 (_Decimal64 A, _Decimal64 B)
+ -- Runtime Function: int __dpd_gttd2 (_Decimal128 A, _Decimal128 B)
+ -- Runtime Function: int __bid_gttd2 (_Decimal128 A, _Decimal128 B)
+     These functions return a value greater than zero if neither
+     argument is NaN, and A is strictly greater than B.
+
+
+File: gccint.info,  Node: Fixed-point fractional library routines,  Next: Exception handling routines,  Prev: Decimal float library routines,  Up: Libgcc
+
+4.4 Routines for fixed-point fractional emulation
+=================================================
+
+The software fixed-point library implements fixed-point fractional
+arithmetic, and is only activated on selected targets.
+
+ For ease of comprehension 'fract' is an alias for the '_Fract' type,
+'accum' an alias for '_Accum', and 'sat' an alias for '_Sat'.
+
+ For illustrative purposes, in this section the fixed-point fractional
+type 'short fract' is assumed to correspond to machine mode 'QQmode';
+'unsigned short fract' to 'UQQmode'; 'fract' to 'HQmode';
+'unsigned fract' to 'UHQmode'; 'long fract' to 'SQmode';
+'unsigned long fract' to 'USQmode'; 'long long fract' to 'DQmode'; and
+'unsigned long long fract' to 'UDQmode'.  Similarly the fixed-point
+accumulator type 'short accum' corresponds to 'HAmode';
+'unsigned short accum' to 'UHAmode'; 'accum' to 'SAmode';
+'unsigned accum' to 'USAmode'; 'long accum' to 'DAmode';
+'unsigned long accum' to 'UDAmode'; 'long long accum' to 'TAmode'; and
+'unsigned long long accum' to 'UTAmode'.
+
+4.4.1 Arithmetic functions
+--------------------------
+
+ -- Runtime Function: short fract __addqq3 (short fract A, short fract
+          B)
+ -- Runtime Function: fract __addhq3 (fract A, fract B)
+ -- Runtime Function: long fract __addsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __adddq3 (long long fract A, long
+          long fract B)
+ -- Runtime Function: unsigned short fract __adduqq3 (unsigned short
+          fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __adduhq3 (unsigned fract A,
+          unsigned fract B)
+ -- Runtime Function: unsigned long fract __addusq3 (unsigned long fract
+          A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __addudq3 (unsigned long
+          long fract A, unsigned long long fract B)
+ -- Runtime Function: short accum __addha3 (short accum A, short accum
+          B)
+ -- Runtime Function: accum __addsa3 (accum A, accum B)
+ -- Runtime Function: long accum __addda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __addta3 (long long accum A, long
+          long accum B)
+ -- Runtime Function: unsigned short accum __adduha3 (unsigned short
+          accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __addusa3 (unsigned accum A,
+          unsigned accum B)
+ -- Runtime Function: unsigned long accum __adduda3 (unsigned long accum
+          A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __adduta3 (unsigned long
+          long accum A, unsigned long long accum B)
+     These functions return the sum of A and B.
+
+ -- Runtime Function: short fract __ssaddqq3 (short fract A, short fract
+          B)
+ -- Runtime Function: fract __ssaddhq3 (fract A, fract B)
+ -- Runtime Function: long fract __ssaddsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __ssadddq3 (long long fract A,
+          long long fract B)
+ -- Runtime Function: short accum __ssaddha3 (short accum A, short accum
+          B)
+ -- Runtime Function: accum __ssaddsa3 (accum A, accum B)
+ -- Runtime Function: long accum __ssaddda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __ssaddta3 (long long accum A,
+          long long accum B)
+     These functions return the sum of A and B with signed saturation.
+
+ -- Runtime Function: unsigned short fract __usadduqq3 (unsigned short
+          fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __usadduhq3 (unsigned fract A,
+          unsigned fract B)
+ -- Runtime Function: unsigned long fract __usaddusq3 (unsigned long
+          fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __usaddudq3 (unsigned
+          long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __usadduha3 (unsigned short
+          accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __usaddusa3 (unsigned accum A,
+          unsigned accum B)
+ -- Runtime Function: unsigned long accum __usadduda3 (unsigned long
+          accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __usadduta3 (unsigned
+          long long accum A, unsigned long long accum B)
+     These functions return the sum of A and B with unsigned saturation.
+
+ -- Runtime Function: short fract __subqq3 (short fract A, short fract
+          B)
+ -- Runtime Function: fract __subhq3 (fract A, fract B)
+ -- Runtime Function: long fract __subsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __subdq3 (long long fract A, long
+          long fract B)
+ -- Runtime Function: unsigned short fract __subuqq3 (unsigned short
+          fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __subuhq3 (unsigned fract A,
+          unsigned fract B)
+ -- Runtime Function: unsigned long fract __subusq3 (unsigned long fract
+          A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __subudq3 (unsigned long
+          long fract A, unsigned long long fract B)
+ -- Runtime Function: short accum __subha3 (short accum A, short accum
+          B)
+ -- Runtime Function: accum __subsa3 (accum A, accum B)
+ -- Runtime Function: long accum __subda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __subta3 (long long accum A, long
+          long accum B)
+ -- Runtime Function: unsigned short accum __subuha3 (unsigned short
+          accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __subusa3 (unsigned accum A,
+          unsigned accum B)
+ -- Runtime Function: unsigned long accum __subuda3 (unsigned long accum
+          A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __subuta3 (unsigned long
+          long accum A, unsigned long long accum B)
+     These functions return the difference of A and B; that is, 'A - B'.
+
+ -- Runtime Function: short fract __sssubqq3 (short fract A, short fract
+          B)
+ -- Runtime Function: fract __sssubhq3 (fract A, fract B)
+ -- Runtime Function: long fract __sssubsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __sssubdq3 (long long fract A,
+          long long fract B)
+ -- Runtime Function: short accum __sssubha3 (short accum A, short accum
+          B)
+ -- Runtime Function: accum __sssubsa3 (accum A, accum B)
+ -- Runtime Function: long accum __sssubda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __sssubta3 (long long accum A,
+          long long accum B)
+     These functions return the difference of A and B with signed
+     saturation; that is, 'A - B'.
+
+ -- Runtime Function: unsigned short fract __ussubuqq3 (unsigned short
+          fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __ussubuhq3 (unsigned fract A,
+          unsigned fract B)
+ -- Runtime Function: unsigned long fract __ussubusq3 (unsigned long
+          fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __ussubudq3 (unsigned
+          long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __ussubuha3 (unsigned short
+          accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __ussubusa3 (unsigned accum A,
+          unsigned accum B)
+ -- Runtime Function: unsigned long accum __ussubuda3 (unsigned long
+          accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __ussubuta3 (unsigned
+          long long accum A, unsigned long long accum B)
+     These functions return the difference of A and B with unsigned
+     saturation; that is, 'A - B'.
+
+ -- Runtime Function: short fract __mulqq3 (short fract A, short fract
+          B)
+ -- Runtime Function: fract __mulhq3 (fract A, fract B)
+ -- Runtime Function: long fract __mulsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __muldq3 (long long fract A, long
+          long fract B)
+ -- Runtime Function: unsigned short fract __muluqq3 (unsigned short
+          fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __muluhq3 (unsigned fract A,
+          unsigned fract B)
+ -- Runtime Function: unsigned long fract __mulusq3 (unsigned long fract
+          A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __muludq3 (unsigned long
+          long fract A, unsigned long long fract B)
+ -- Runtime Function: short accum __mulha3 (short accum A, short accum
+          B)
+ -- Runtime Function: accum __mulsa3 (accum A, accum B)
+ -- Runtime Function: long accum __mulda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __multa3 (long long accum A, long
+          long accum B)
+ -- Runtime Function: unsigned short accum __muluha3 (unsigned short
+          accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __mulusa3 (unsigned accum A,
+          unsigned accum B)
+ -- Runtime Function: unsigned long accum __muluda3 (unsigned long accum
+          A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __muluta3 (unsigned long
+          long accum A, unsigned long long accum B)
+     These functions return the product of A and B.
+
+ -- Runtime Function: short fract __ssmulqq3 (short fract A, short fract
+          B)
+ -- Runtime Function: fract __ssmulhq3 (fract A, fract B)
+ -- Runtime Function: long fract __ssmulsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __ssmuldq3 (long long fract A,
+          long long fract B)
+ -- Runtime Function: short accum __ssmulha3 (short accum A, short accum
+          B)
+ -- Runtime Function: accum __ssmulsa3 (accum A, accum B)
+ -- Runtime Function: long accum __ssmulda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __ssmulta3 (long long accum A,
+          long long accum B)
+     These functions return the product of A and B with signed
+     saturation.
+
+ -- Runtime Function: unsigned short fract __usmuluqq3 (unsigned short
+          fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __usmuluhq3 (unsigned fract A,
+          unsigned fract B)
+ -- Runtime Function: unsigned long fract __usmulusq3 (unsigned long
+          fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __usmuludq3 (unsigned
+          long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __usmuluha3 (unsigned short
+          accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __usmulusa3 (unsigned accum A,
+          unsigned accum B)
+ -- Runtime Function: unsigned long accum __usmuluda3 (unsigned long
+          accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __usmuluta3 (unsigned
+          long long accum A, unsigned long long accum B)
+     These functions return the product of A and B with unsigned
+     saturation.
+
+ -- Runtime Function: short fract __divqq3 (short fract A, short fract
+          B)
+ -- Runtime Function: fract __divhq3 (fract A, fract B)
+ -- Runtime Function: long fract __divsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __divdq3 (long long fract A, long
+          long fract B)
+ -- Runtime Function: short accum __divha3 (short accum A, short accum
+          B)
+ -- Runtime Function: accum __divsa3 (accum A, accum B)
+ -- Runtime Function: long accum __divda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __divta3 (long long accum A, long
+          long accum B)
+     These functions return the quotient of the signed division of A and
+     B.
+
+ -- Runtime Function: unsigned short fract __udivuqq3 (unsigned short
+          fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __udivuhq3 (unsigned fract A,
+          unsigned fract B)
+ -- Runtime Function: unsigned long fract __udivusq3 (unsigned long
+          fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __udivudq3 (unsigned long
+          long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __udivuha3 (unsigned short
+          accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __udivusa3 (unsigned accum A,
+          unsigned accum B)
+ -- Runtime Function: unsigned long accum __udivuda3 (unsigned long
+          accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __udivuta3 (unsigned long
+          long accum A, unsigned long long accum B)
+     These functions return the quotient of the unsigned division of A
+     and B.
+
+ -- Runtime Function: short fract __ssdivqq3 (short fract A, short fract
+          B)
+ -- Runtime Function: fract __ssdivhq3 (fract A, fract B)
+ -- Runtime Function: long fract __ssdivsq3 (long fract A, long fract B)
+ -- Runtime Function: long long fract __ssdivdq3 (long long fract A,
+          long long fract B)
+ -- Runtime Function: short accum __ssdivha3 (short accum A, short accum
+          B)
+ -- Runtime Function: accum __ssdivsa3 (accum A, accum B)
+ -- Runtime Function: long accum __ssdivda3 (long accum A, long accum B)
+ -- Runtime Function: long long accum __ssdivta3 (long long accum A,
+          long long accum B)
+     These functions return the quotient of the signed division of A and
+     B with signed saturation.
+
+ -- Runtime Function: unsigned short fract __usdivuqq3 (unsigned short
+          fract A, unsigned short fract B)
+ -- Runtime Function: unsigned fract __usdivuhq3 (unsigned fract A,
+          unsigned fract B)
+ -- Runtime Function: unsigned long fract __usdivusq3 (unsigned long
+          fract A, unsigned long fract B)
+ -- Runtime Function: unsigned long long fract __usdivudq3 (unsigned
+          long long fract A, unsigned long long fract B)
+ -- Runtime Function: unsigned short accum __usdivuha3 (unsigned short
+          accum A, unsigned short accum B)
+ -- Runtime Function: unsigned accum __usdivusa3 (unsigned accum A,
+          unsigned accum B)
+ -- Runtime Function: unsigned long accum __usdivuda3 (unsigned long
+          accum A, unsigned long accum B)
+ -- Runtime Function: unsigned long long accum __usdivuta3 (unsigned
+          long long accum A, unsigned long long accum B)
+     These functions return the quotient of the unsigned division of A
+     and B with unsigned saturation.
+
+ -- Runtime Function: short fract __negqq2 (short fract A)
+ -- Runtime Function: fract __neghq2 (fract A)
+ -- Runtime Function: long fract __negsq2 (long fract A)
+ -- Runtime Function: long long fract __negdq2 (long long fract A)
+ -- Runtime Function: unsigned short fract __neguqq2 (unsigned short
+          fract A)
+ -- Runtime Function: unsigned fract __neguhq2 (unsigned fract A)
+ -- Runtime Function: unsigned long fract __negusq2 (unsigned long fract
+          A)
+ -- Runtime Function: unsigned long long fract __negudq2 (unsigned long
+          long fract A)
+ -- Runtime Function: short accum __negha2 (short accum A)
+ -- Runtime Function: accum __negsa2 (accum A)
+ -- Runtime Function: long accum __negda2 (long accum A)
+ -- Runtime Function: long long accum __negta2 (long long accum A)
+ -- Runtime Function: unsigned short accum __neguha2 (unsigned short
+          accum A)
+ -- Runtime Function: unsigned accum __negusa2 (unsigned accum A)
+ -- Runtime Function: unsigned long accum __neguda2 (unsigned long accum
+          A)
+ -- Runtime Function: unsigned long long accum __neguta2 (unsigned long
+          long accum A)
+     These functions return the negation of A.
+
+ -- Runtime Function: short fract __ssnegqq2 (short fract A)
+ -- Runtime Function: fract __ssneghq2 (fract A)
+ -- Runtime Function: long fract __ssnegsq2 (long fract A)
+ -- Runtime Function: long long fract __ssnegdq2 (long long fract A)
+ -- Runtime Function: short accum __ssnegha2 (short accum A)
+ -- Runtime Function: accum __ssnegsa2 (accum A)
+ -- Runtime Function: long accum __ssnegda2 (long accum A)
+ -- Runtime Function: long long accum __ssnegta2 (long long accum A)
+     These functions return the negation of A with signed saturation.
+
+ -- Runtime Function: unsigned short fract __usneguqq2 (unsigned short
+          fract A)
+ -- Runtime Function: unsigned fract __usneguhq2 (unsigned fract A)
+ -- Runtime Function: unsigned long fract __usnegusq2 (unsigned long
+          fract A)
+ -- Runtime Function: unsigned long long fract __usnegudq2 (unsigned
+          long long fract A)
+ -- Runtime Function: unsigned short accum __usneguha2 (unsigned short
+          accum A)
+ -- Runtime Function: unsigned accum __usnegusa2 (unsigned accum A)
+ -- Runtime Function: unsigned long accum __usneguda2 (unsigned long
+          accum A)
+ -- Runtime Function: unsigned long long accum __usneguta2 (unsigned
+          long long accum A)
+     These functions return the negation of A with unsigned saturation.
+
+ -- Runtime Function: short fract __ashlqq3 (short fract A, int B)
+ -- Runtime Function: fract __ashlhq3 (fract A, int B)
+ -- Runtime Function: long fract __ashlsq3 (long fract A, int B)
+ -- Runtime Function: long long fract __ashldq3 (long long fract A, int
+          B)
+ -- Runtime Function: unsigned short fract __ashluqq3 (unsigned short
+          fract A, int B)
+ -- Runtime Function: unsigned fract __ashluhq3 (unsigned fract A, int
+          B)
+ -- Runtime Function: unsigned long fract __ashlusq3 (unsigned long
+          fract A, int B)
+ -- Runtime Function: unsigned long long fract __ashludq3 (unsigned long
+          long fract A, int B)
+ -- Runtime Function: short accum __ashlha3 (short accum A, int B)
+ -- Runtime Function: accum __ashlsa3 (accum A, int B)
+ -- Runtime Function: long accum __ashlda3 (long accum A, int B)
+ -- Runtime Function: long long accum __ashlta3 (long long accum A, int
+          B)
+ -- Runtime Function: unsigned short accum __ashluha3 (unsigned short
+          accum A, int B)
+ -- Runtime Function: unsigned accum __ashlusa3 (unsigned accum A, int
+          B)
+ -- Runtime Function: unsigned long accum __ashluda3 (unsigned long
+          accum A, int B)
+ -- Runtime Function: unsigned long long accum __ashluta3 (unsigned long
+          long accum A, int B)
+     These functions return the result of shifting A left by B bits.
+
+ -- Runtime Function: short fract __ashrqq3 (short fract A, int B)
+ -- Runtime Function: fract __ashrhq3 (fract A, int B)
+ -- Runtime Function: long fract __ashrsq3 (long fract A, int B)
+ -- Runtime Function: long long fract __ashrdq3 (long long fract A, int
+          B)
+ -- Runtime Function: short accum __ashrha3 (short accum A, int B)
+ -- Runtime Function: accum __ashrsa3 (accum A, int B)
+ -- Runtime Function: long accum __ashrda3 (long accum A, int B)
+ -- Runtime Function: long long accum __ashrta3 (long long accum A, int
+          B)
+     These functions return the result of arithmetically shifting A
+     right by B bits.
+
+ -- Runtime Function: unsigned short fract __lshruqq3 (unsigned short
+          fract A, int B)
+ -- Runtime Function: unsigned fract __lshruhq3 (unsigned fract A, int
+          B)
+ -- Runtime Function: unsigned long fract __lshrusq3 (unsigned long
+          fract A, int B)
+ -- Runtime Function: unsigned long long fract __lshrudq3 (unsigned long
+          long fract A, int B)
+ -- Runtime Function: unsigned short accum __lshruha3 (unsigned short
+          accum A, int B)
+ -- Runtime Function: unsigned accum __lshrusa3 (unsigned accum A, int
+          B)
+ -- Runtime Function: unsigned long accum __lshruda3 (unsigned long
+          accum A, int B)
+ -- Runtime Function: unsigned long long accum __lshruta3 (unsigned long
+          long accum A, int B)
+     These functions return the result of logically shifting A right by
+     B bits.
+
+ -- Runtime Function: fract __ssashlhq3 (fract A, int B)
+ -- Runtime Function: long fract __ssashlsq3 (long fract A, int B)
+ -- Runtime Function: long long fract __ssashldq3 (long long fract A,
+          int B)
+ -- Runtime Function: short accum __ssashlha3 (short accum A, int B)
+ -- Runtime Function: accum __ssashlsa3 (accum A, int B)
+ -- Runtime Function: long accum __ssashlda3 (long accum A, int B)
+ -- Runtime Function: long long accum __ssashlta3 (long long accum A,
+          int B)
+     These functions return the result of shifting A left by B bits with
+     signed saturation.
+
+ -- Runtime Function: unsigned short fract __usashluqq3 (unsigned short
+          fract A, int B)
+ -- Runtime Function: unsigned fract __usashluhq3 (unsigned fract A, int
+          B)
+ -- Runtime Function: unsigned long fract __usashlusq3 (unsigned long
+          fract A, int B)
+ -- Runtime Function: unsigned long long fract __usashludq3 (unsigned
+          long long fract A, int B)
+ -- Runtime Function: unsigned short accum __usashluha3 (unsigned short
+          accum A, int B)
+ -- Runtime Function: unsigned accum __usashlusa3 (unsigned accum A, int
+          B)
+ -- Runtime Function: unsigned long accum __usashluda3 (unsigned long
+          accum A, int B)
+ -- Runtime Function: unsigned long long accum __usashluta3 (unsigned
+          long long accum A, int B)
+     These functions return the result of shifting A left by B bits with
+     unsigned saturation.
+
+4.4.2 Comparison functions
+--------------------------
+
+The following functions implement fixed-point comparisons.  These
+functions implement a low-level compare, upon which the higher level
+comparison operators (such as less than and greater than or equal to)
+can be constructed.  The returned values lie in the range zero to two,
+to allow the high-level operators to be implemented by testing the
+returned result using either signed or unsigned comparison.
+
+ -- Runtime Function: int __cmpqq2 (short fract A, short fract B)
+ -- Runtime Function: int __cmphq2 (fract A, fract B)
+ -- Runtime Function: int __cmpsq2 (long fract A, long fract B)
+ -- Runtime Function: int __cmpdq2 (long long fract A, long long fract
+          B)
+ -- Runtime Function: int __cmpuqq2 (unsigned short fract A, unsigned
+          short fract B)
+ -- Runtime Function: int __cmpuhq2 (unsigned fract A, unsigned fract B)
+ -- Runtime Function: int __cmpusq2 (unsigned long fract A, unsigned
+          long fract B)
+ -- Runtime Function: int __cmpudq2 (unsigned long long fract A,
+          unsigned long long fract B)
+ -- Runtime Function: int __cmpha2 (short accum A, short accum B)
+ -- Runtime Function: int __cmpsa2 (accum A, accum B)
+ -- Runtime Function: int __cmpda2 (long accum A, long accum B)
+ -- Runtime Function: int __cmpta2 (long long accum A, long long accum
+          B)
+ -- Runtime Function: int __cmpuha2 (unsigned short accum A, unsigned
+          short accum B)
+ -- Runtime Function: int __cmpusa2 (unsigned accum A, unsigned accum B)
+ -- Runtime Function: int __cmpuda2 (unsigned long accum A, unsigned
+          long accum B)
+ -- Runtime Function: int __cmputa2 (unsigned long long accum A,
+          unsigned long long accum B)
+     These functions perform a signed or unsigned comparison of A and B
+     (depending on the selected machine mode).  If A is less than B,
+     they return 0; if A is greater than B, they return 2; and if A and
+     B are equal they return 1.
+
+4.4.3 Conversion functions
+--------------------------
+
+ -- Runtime Function: fract __fractqqhq2 (short fract A)
+ -- Runtime Function: long fract __fractqqsq2 (short fract A)
+ -- Runtime Function: long long fract __fractqqdq2 (short fract A)
+ -- Runtime Function: short accum __fractqqha (short fract A)
+ -- Runtime Function: accum __fractqqsa (short fract A)
+ -- Runtime Function: long accum __fractqqda (short fract A)
+ -- Runtime Function: long long accum __fractqqta (short fract A)
+ -- Runtime Function: unsigned short fract __fractqquqq (short fract A)
+ -- Runtime Function: unsigned fract __fractqquhq (short fract A)
+ -- Runtime Function: unsigned long fract __fractqqusq (short fract A)
+ -- Runtime Function: unsigned long long fract __fractqqudq (short fract
+          A)
+ -- Runtime Function: unsigned short accum __fractqquha (short fract A)
+ -- Runtime Function: unsigned accum __fractqqusa (short fract A)
+ -- Runtime Function: unsigned long accum __fractqquda (short fract A)
+ -- Runtime Function: unsigned long long accum __fractqquta (short fract
+          A)
+ -- Runtime Function: signed char __fractqqqi (short fract A)
+ -- Runtime Function: short __fractqqhi (short fract A)
+ -- Runtime Function: int __fractqqsi (short fract A)
+ -- Runtime Function: long __fractqqdi (short fract A)
+ -- Runtime Function: long long __fractqqti (short fract A)
+ -- Runtime Function: float __fractqqsf (short fract A)
+ -- Runtime Function: double __fractqqdf (short fract A)
+ -- Runtime Function: short fract __fracthqqq2 (fract A)
+ -- Runtime Function: long fract __fracthqsq2 (fract A)
+ -- Runtime Function: long long fract __fracthqdq2 (fract A)
+ -- Runtime Function: short accum __fracthqha (fract A)
+ -- Runtime Function: accum __fracthqsa (fract A)
+ -- Runtime Function: long accum __fracthqda (fract A)
+ -- Runtime Function: long long accum __fracthqta (fract A)
+ -- Runtime Function: unsigned short fract __fracthquqq (fract A)
+ -- Runtime Function: unsigned fract __fracthquhq (fract A)
+ -- Runtime Function: unsigned long fract __fracthqusq (fract A)
+ -- Runtime Function: unsigned long long fract __fracthqudq (fract A)
+ -- Runtime Function: unsigned short accum __fracthquha (fract A)
+ -- Runtime Function: unsigned accum __fracthqusa (fract A)
+ -- Runtime Function: unsigned long accum __fracthquda (fract A)
+ -- Runtime Function: unsigned long long accum __fracthquta (fract A)
+ -- Runtime Function: signed char __fracthqqi (fract A)
+ -- Runtime Function: short __fracthqhi (fract A)
+ -- Runtime Function: int __fracthqsi (fract A)
+ -- Runtime Function: long __fracthqdi (fract A)
+ -- Runtime Function: long long __fracthqti (fract A)
+ -- Runtime Function: float __fracthqsf (fract A)
+ -- Runtime Function: double __fracthqdf (fract A)
+ -- Runtime Function: short fract __fractsqqq2 (long fract A)
+ -- Runtime Function: fract __fractsqhq2 (long fract A)
+ -- Runtime Function: long long fract __fractsqdq2 (long fract A)
+ -- Runtime Function: short accum __fractsqha (long fract A)
+ -- Runtime Function: accum __fractsqsa (long fract A)
+ -- Runtime Function: long accum __fractsqda (long fract A)
+ -- Runtime Function: long long accum __fractsqta (long fract A)
+ -- Runtime Function: unsigned short fract __fractsquqq (long fract A)
+ -- Runtime Function: unsigned fract __fractsquhq (long fract A)
+ -- Runtime Function: unsigned long fract __fractsqusq (long fract A)
+ -- Runtime Function: unsigned long long fract __fractsqudq (long fract
+          A)
+ -- Runtime Function: unsigned short accum __fractsquha (long fract A)
+ -- Runtime Function: unsigned accum __fractsqusa (long fract A)
+ -- Runtime Function: unsigned long accum __fractsquda (long fract A)
+ -- Runtime Function: unsigned long long accum __fractsquta (long fract
+          A)
+ -- Runtime Function: signed char __fractsqqi (long fract A)
+ -- Runtime Function: short __fractsqhi (long fract A)
+ -- Runtime Function: int __fractsqsi (long fract A)
+ -- Runtime Function: long __fractsqdi (long fract A)
+ -- Runtime Function: long long __fractsqti (long fract A)
+ -- Runtime Function: float __fractsqsf (long fract A)
+ -- Runtime Function: double __fractsqdf (long fract A)
+ -- Runtime Function: short fract __fractdqqq2 (long long fract A)
+ -- Runtime Function: fract __fractdqhq2 (long long fract A)
+ -- Runtime Function: long fract __fractdqsq2 (long long fract A)
+ -- Runtime Function: short accum __fractdqha (long long fract A)
+ -- Runtime Function: accum __fractdqsa (long long fract A)
+ -- Runtime Function: long accum __fractdqda (long long fract A)
+ -- Runtime Function: long long accum __fractdqta (long long fract A)
+ -- Runtime Function: unsigned short fract __fractdquqq (long long fract
+          A)
+ -- Runtime Function: unsigned fract __fractdquhq (long long fract A)
+ -- Runtime Function: unsigned long fract __fractdqusq (long long fract
+          A)
+ -- Runtime Function: unsigned long long fract __fractdqudq (long long
+          fract A)
+ -- Runtime Function: unsigned short accum __fractdquha (long long fract
+          A)
+ -- Runtime Function: unsigned accum __fractdqusa (long long fract A)
+ -- Runtime Function: unsigned long accum __fractdquda (long long fract
+          A)
+ -- Runtime Function: unsigned long long accum __fractdquta (long long
+          fract A)
+ -- Runtime Function: signed char __fractdqqi (long long fract A)
+ -- Runtime Function: short __fractdqhi (long long fract A)
+ -- Runtime Function: int __fractdqsi (long long fract A)
+ -- Runtime Function: long __fractdqdi (long long fract A)
+ -- Runtime Function: long long __fractdqti (long long fract A)
+ -- Runtime Function: float __fractdqsf (long long fract A)
+ -- Runtime Function: double __fractdqdf (long long fract A)
+ -- Runtime Function: short fract __fracthaqq (short accum A)
+ -- Runtime Function: fract __fracthahq (short accum A)
+ -- Runtime Function: long fract __fracthasq (short accum A)
+ -- Runtime Function: long long fract __fracthadq (short accum A)
+ -- Runtime Function: accum __fracthasa2 (short accum A)
+ -- Runtime Function: long accum __fracthada2 (short accum A)
+ -- Runtime Function: long long accum __fracthata2 (short accum A)
+ -- Runtime Function: unsigned short fract __fracthauqq (short accum A)
+ -- Runtime Function: unsigned fract __fracthauhq (short accum A)
+ -- Runtime Function: unsigned long fract __fracthausq (short accum A)
+ -- Runtime Function: unsigned long long fract __fracthaudq (short accum
+          A)
+ -- Runtime Function: unsigned short accum __fracthauha (short accum A)
+ -- Runtime Function: unsigned accum __fracthausa (short accum A)
+ -- Runtime Function: unsigned long accum __fracthauda (short accum A)
+ -- Runtime Function: unsigned long long accum __fracthauta (short accum
+          A)
+ -- Runtime Function: signed char __fracthaqi (short accum A)
+ -- Runtime Function: short __fracthahi (short accum A)
+ -- Runtime Function: int __fracthasi (short accum A)
+ -- Runtime Function: long __fracthadi (short accum A)
+ -- Runtime Function: long long __fracthati (short accum A)
+ -- Runtime Function: float __fracthasf (short accum A)
+ -- Runtime Function: double __fracthadf (short accum A)
+ -- Runtime Function: short fract __fractsaqq (accum A)
+ -- Runtime Function: fract __fractsahq (accum A)
+ -- Runtime Function: long fract __fractsasq (accum A)
+ -- Runtime Function: long long fract __fractsadq (accum A)
+ -- Runtime Function: short accum __fractsaha2 (accum A)
+ -- Runtime Function: long accum __fractsada2 (accum A)
+ -- Runtime Function: long long accum __fractsata2 (accum A)
+ -- Runtime Function: unsigned short fract __fractsauqq (accum A)
+ -- Runtime Function: unsigned fract __fractsauhq (accum A)
+ -- Runtime Function: unsigned long fract __fractsausq (accum A)
+ -- Runtime Function: unsigned long long fract __fractsaudq (accum A)
+ -- Runtime Function: unsigned short accum __fractsauha (accum A)
+ -- Runtime Function: unsigned accum __fractsausa (accum A)
+ -- Runtime Function: unsigned long accum __fractsauda (accum A)
+ -- Runtime Function: unsigned long long accum __fractsauta (accum A)
+ -- Runtime Function: signed char __fractsaqi (accum A)
+ -- Runtime Function: short __fractsahi (accum A)
+ -- Runtime Function: int __fractsasi (accum A)
+ -- Runtime Function: long __fractsadi (accum A)
+ -- Runtime Function: long long __fractsati (accum A)
+ -- Runtime Function: float __fractsasf (accum A)
+ -- Runtime Function: double __fractsadf (accum A)
+ -- Runtime Function: short fract __fractdaqq (long accum A)
+ -- Runtime Function: fract __fractdahq (long accum A)
+ -- Runtime Function: long fract __fractdasq (long accum A)
+ -- Runtime Function: long long fract __fractdadq (long accum A)
+ -- Runtime Function: short accum __fractdaha2 (long accum A)
+ -- Runtime Function: accum __fractdasa2 (long accum A)
+ -- Runtime Function: long long accum __fractdata2 (long accum A)
+ -- Runtime Function: unsigned short fract __fractdauqq (long accum A)
+ -- Runtime Function: unsigned fract __fractdauhq (long accum A)
+ -- Runtime Function: unsigned long fract __fractdausq (long accum A)
+ -- Runtime Function: unsigned long long fract __fractdaudq (long accum
+          A)
+ -- Runtime Function: unsigned short accum __fractdauha (long accum A)
+ -- Runtime Function: unsigned accum __fractdausa (long accum A)
+ -- Runtime Function: unsigned long accum __fractdauda (long accum A)
+ -- Runtime Function: unsigned long long accum __fractdauta (long accum
+          A)
+ -- Runtime Function: signed char __fractdaqi (long accum A)
+ -- Runtime Function: short __fractdahi (long accum A)
+ -- Runtime Function: int __fractdasi (long accum A)
+ -- Runtime Function: long __fractdadi (long accum A)
+ -- Runtime Function: long long __fractdati (long accum A)
+ -- Runtime Function: float __fractdasf (long accum A)
+ -- Runtime Function: double __fractdadf (long accum A)
+ -- Runtime Function: short fract __fracttaqq (long long accum A)
+ -- Runtime Function: fract __fracttahq (long long accum A)
+ -- Runtime Function: long fract __fracttasq (long long accum A)
+ -- Runtime Function: long long fract __fracttadq (long long accum A)
+ -- Runtime Function: short accum __fracttaha2 (long long accum A)
+ -- Runtime Function: accum __fracttasa2 (long long accum A)
+ -- Runtime Function: long accum __fracttada2 (long long accum A)
+ -- Runtime Function: unsigned short fract __fracttauqq (long long accum
+          A)
+ -- Runtime Function: unsigned fract __fracttauhq (long long accum A)
+ -- Runtime Function: unsigned long fract __fracttausq (long long accum
+          A)
+ -- Runtime Function: unsigned long long fract __fracttaudq (long long
+          accum A)
+ -- Runtime Function: unsigned short accum __fracttauha (long long accum
+          A)
+ -- Runtime Function: unsigned accum __fracttausa (long long accum A)
+ -- Runtime Function: unsigned long accum __fracttauda (long long accum
+          A)
+ -- Runtime Function: unsigned long long accum __fracttauta (long long
+          accum A)
+ -- Runtime Function: signed char __fracttaqi (long long accum A)
+ -- Runtime Function: short __fracttahi (long long accum A)
+ -- Runtime Function: int __fracttasi (long long accum A)
+ -- Runtime Function: long __fracttadi (long long accum A)
+ -- Runtime Function: long long __fracttati (long long accum A)
+ -- Runtime Function: float __fracttasf (long long accum A)
+ -- Runtime Function: double __fracttadf (long long accum A)
+ -- Runtime Function: short fract __fractuqqqq (unsigned short fract A)
+ -- Runtime Function: fract __fractuqqhq (unsigned short fract A)
+ -- Runtime Function: long fract __fractuqqsq (unsigned short fract A)
+ -- Runtime Function: long long fract __fractuqqdq (unsigned short fract
+          A)
+ -- Runtime Function: short accum __fractuqqha (unsigned short fract A)
+ -- Runtime Function: accum __fractuqqsa (unsigned short fract A)
+ -- Runtime Function: long accum __fractuqqda (unsigned short fract A)
+ -- Runtime Function: long long accum __fractuqqta (unsigned short fract
+          A)
+ -- Runtime Function: unsigned fract __fractuqquhq2 (unsigned short
+          fract A)
+ -- Runtime Function: unsigned long fract __fractuqqusq2 (unsigned short
+          fract A)
+ -- Runtime Function: unsigned long long fract __fractuqqudq2 (unsigned
+          short fract A)
+ -- Runtime Function: unsigned short accum __fractuqquha (unsigned short
+          fract A)
+ -- Runtime Function: unsigned accum __fractuqqusa (unsigned short fract
+          A)
+ -- Runtime Function: unsigned long accum __fractuqquda (unsigned short
+          fract A)
+ -- Runtime Function: unsigned long long accum __fractuqquta (unsigned
+          short fract A)
+ -- Runtime Function: signed char __fractuqqqi (unsigned short fract A)
+ -- Runtime Function: short __fractuqqhi (unsigned short fract A)
+ -- Runtime Function: int __fractuqqsi (unsigned short fract A)
+ -- Runtime Function: long __fractuqqdi (unsigned short fract A)
+ -- Runtime Function: long long __fractuqqti (unsigned short fract A)
+ -- Runtime Function: float __fractuqqsf (unsigned short fract A)
+ -- Runtime Function: double __fractuqqdf (unsigned short fract A)
+ -- Runtime Function: short fract __fractuhqqq (unsigned fract A)
+ -- Runtime Function: fract __fractuhqhq (unsigned fract A)
+ -- Runtime Function: long fract __fractuhqsq (unsigned fract A)
+ -- Runtime Function: long long fract __fractuhqdq (unsigned fract A)
+ -- Runtime Function: short accum __fractuhqha (unsigned fract A)
+ -- Runtime Function: accum __fractuhqsa (unsigned fract A)
+ -- Runtime Function: long accum __fractuhqda (unsigned fract A)
+ -- Runtime Function: long long accum __fractuhqta (unsigned fract A)
+ -- Runtime Function: unsigned short fract __fractuhquqq2 (unsigned
+          fract A)
+ -- Runtime Function: unsigned long fract __fractuhqusq2 (unsigned fract
+          A)
+ -- Runtime Function: unsigned long long fract __fractuhqudq2 (unsigned
+          fract A)
+ -- Runtime Function: unsigned short accum __fractuhquha (unsigned fract
+          A)
+ -- Runtime Function: unsigned accum __fractuhqusa (unsigned fract A)
+ -- Runtime Function: unsigned long accum __fractuhquda (unsigned fract
+          A)
+ -- Runtime Function: unsigned long long accum __fractuhquta (unsigned
+          fract A)
+ -- Runtime Function: signed char __fractuhqqi (unsigned fract A)
+ -- Runtime Function: short __fractuhqhi (unsigned fract A)
+ -- Runtime Function: int __fractuhqsi (unsigned fract A)
+ -- Runtime Function: long __fractuhqdi (unsigned fract A)
+ -- Runtime Function: long long __fractuhqti (unsigned fract A)
+ -- Runtime Function: float __fractuhqsf (unsigned fract A)
+ -- Runtime Function: double __fractuhqdf (unsigned fract A)
+ -- Runtime Function: short fract __fractusqqq (unsigned long fract A)
+ -- Runtime Function: fract __fractusqhq (unsigned long fract A)
+ -- Runtime Function: long fract __fractusqsq (unsigned long fract A)
+ -- Runtime Function: long long fract __fractusqdq (unsigned long fract
+          A)
+ -- Runtime Function: short accum __fractusqha (unsigned long fract A)
+ -- Runtime Function: accum __fractusqsa (unsigned long fract A)
+ -- Runtime Function: long accum __fractusqda (unsigned long fract A)
+ -- Runtime Function: long long accum __fractusqta (unsigned long fract
+          A)
+ -- Runtime Function: unsigned short fract __fractusquqq2 (unsigned long
+          fract A)
+ -- Runtime Function: unsigned fract __fractusquhq2 (unsigned long fract
+          A)
+ -- Runtime Function: unsigned long long fract __fractusqudq2 (unsigned
+          long fract A)
+ -- Runtime Function: unsigned short accum __fractusquha (unsigned long
+          fract A)
+ -- Runtime Function: unsigned accum __fractusqusa (unsigned long fract
+          A)
+ -- Runtime Function: unsigned long accum __fractusquda (unsigned long
+          fract A)
+ -- Runtime Function: unsigned long long accum __fractusquta (unsigned
+          long fract A)
+ -- Runtime Function: signed char __fractusqqi (unsigned long fract A)
+ -- Runtime Function: short __fractusqhi (unsigned long fract A)
+ -- Runtime Function: int __fractusqsi (unsigned long fract A)
+ -- Runtime Function: long __fractusqdi (unsigned long fract A)
+ -- Runtime Function: long long __fractusqti (unsigned long fract A)
+ -- Runtime Function: float __fractusqsf (unsigned long fract A)
+ -- Runtime Function: double __fractusqdf (unsigned long fract A)
+ -- Runtime Function: short fract __fractudqqq (unsigned long long fract
+          A)
+ -- Runtime Function: fract __fractudqhq (unsigned long long fract A)
+ -- Runtime Function: long fract __fractudqsq (unsigned long long fract
+          A)
+ -- Runtime Function: long long fract __fractudqdq (unsigned long long
+          fract A)
+ -- Runtime Function: short accum __fractudqha (unsigned long long fract
+          A)
+ -- Runtime Function: accum __fractudqsa (unsigned long long fract A)
+ -- Runtime Function: long accum __fractudqda (unsigned long long fract
+          A)
+ -- Runtime Function: long long accum __fractudqta (unsigned long long
+          fract A)
+ -- Runtime Function: unsigned short fract __fractudquqq2 (unsigned long
+          long fract A)
+ -- Runtime Function: unsigned fract __fractudquhq2 (unsigned long long
+          fract A)
+ -- Runtime Function: unsigned long fract __fractudqusq2 (unsigned long
+          long fract A)
+ -- Runtime Function: unsigned short accum __fractudquha (unsigned long
+          long fract A)
+ -- Runtime Function: unsigned accum __fractudqusa (unsigned long long
+          fract A)
+ -- Runtime Function: unsigned long accum __fractudquda (unsigned long
+          long fract A)
+ -- Runtime Function: unsigned long long accum __fractudquta (unsigned
+          long long fract A)
+ -- Runtime Function: signed char __fractudqqi (unsigned long long fract
+          A)
+ -- Runtime Function: short __fractudqhi (unsigned long long fract A)
+ -- Runtime Function: int __fractudqsi (unsigned long long fract A)
+ -- Runtime Function: long __fractudqdi (unsigned long long fract A)
+ -- Runtime Function: long long __fractudqti (unsigned long long fract
+          A)
+ -- Runtime Function: float __fractudqsf (unsigned long long fract A)
+ -- Runtime Function: double __fractudqdf (unsigned long long fract A)
+ -- Runtime Function: short fract __fractuhaqq (unsigned short accum A)
+ -- Runtime Function: fract __fractuhahq (unsigned short accum A)
+ -- Runtime Function: long fract __fractuhasq (unsigned short accum A)
+ -- Runtime Function: long long fract __fractuhadq (unsigned short accum
+          A)
+ -- Runtime Function: short accum __fractuhaha (unsigned short accum A)
+ -- Runtime Function: accum __fractuhasa (unsigned short accum A)
+ -- Runtime Function: long accum __fractuhada (unsigned short accum A)
+ -- Runtime Function: long long accum __fractuhata (unsigned short accum
+          A)
+ -- Runtime Function: unsigned short fract __fractuhauqq (unsigned short
+          accum A)
+ -- Runtime Function: unsigned fract __fractuhauhq (unsigned short accum
+          A)
+ -- Runtime Function: unsigned long fract __fractuhausq (unsigned short
+          accum A)
+ -- Runtime Function: unsigned long long fract __fractuhaudq (unsigned
+          short accum A)
+ -- Runtime Function: unsigned accum __fractuhausa2 (unsigned short
+          accum A)
+ -- Runtime Function: unsigned long accum __fractuhauda2 (unsigned short
+          accum A)
+ -- Runtime Function: unsigned long long accum __fractuhauta2 (unsigned
+          short accum A)
+ -- Runtime Function: signed char __fractuhaqi (unsigned short accum A)
+ -- Runtime Function: short __fractuhahi (unsigned short accum A)
+ -- Runtime Function: int __fractuhasi (unsigned short accum A)
+ -- Runtime Function: long __fractuhadi (unsigned short accum A)
+ -- Runtime Function: long long __fractuhati (unsigned short accum A)
+ -- Runtime Function: float __fractuhasf (unsigned short accum A)
+ -- Runtime Function: double __fractuhadf (unsigned short accum A)
+ -- Runtime Function: short fract __fractusaqq (unsigned accum A)
+ -- Runtime Function: fract __fractusahq (unsigned accum A)
+ -- Runtime Function: long fract __fractusasq (unsigned accum A)
+ -- Runtime Function: long long fract __fractusadq (unsigned accum A)
+ -- Runtime Function: short accum __fractusaha (unsigned accum A)
+ -- Runtime Function: accum __fractusasa (unsigned accum A)
+ -- Runtime Function: long accum __fractusada (unsigned accum A)
+ -- Runtime Function: long long accum __fractusata (unsigned accum A)
+ -- Runtime Function: unsigned short fract __fractusauqq (unsigned accum
+          A)
+ -- Runtime Function: unsigned fract __fractusauhq (unsigned accum A)
+ -- Runtime Function: unsigned long fract __fractusausq (unsigned accum
+          A)
+ -- Runtime Function: unsigned long long fract __fractusaudq (unsigned
+          accum A)
+ -- Runtime Function: unsigned short accum __fractusauha2 (unsigned
+          accum A)
+ -- Runtime Function: unsigned long accum __fractusauda2 (unsigned accum
+          A)
+ -- Runtime Function: unsigned long long accum __fractusauta2 (unsigned
+          accum A)
+ -- Runtime Function: signed char __fractusaqi (unsigned accum A)
+ -- Runtime Function: short __fractusahi (unsigned accum A)
+ -- Runtime Function: int __fractusasi (unsigned accum A)
+ -- Runtime Function: long __fractusadi (unsigned accum A)
+ -- Runtime Function: long long __fractusati (unsigned accum A)
+ -- Runtime Function: float __fractusasf (unsigned accum A)
+ -- Runtime Function: double __fractusadf (unsigned accum A)
+ -- Runtime Function: short fract __fractudaqq (unsigned long accum A)
+ -- Runtime Function: fract __fractudahq (unsigned long accum A)
+ -- Runtime Function: long fract __fractudasq (unsigned long accum A)
+ -- Runtime Function: long long fract __fractudadq (unsigned long accum
+          A)
+ -- Runtime Function: short accum __fractudaha (unsigned long accum A)
+ -- Runtime Function: accum __fractudasa (unsigned long accum A)
+ -- Runtime Function: long accum __fractudada (unsigned long accum A)
+ -- Runtime Function: long long accum __fractudata (unsigned long accum
+          A)
+ -- Runtime Function: unsigned short fract __fractudauqq (unsigned long
+          accum A)
+ -- Runtime Function: unsigned fract __fractudauhq (unsigned long accum
+          A)
+ -- Runtime Function: unsigned long fract __fractudausq (unsigned long
+          accum A)
+ -- Runtime Function: unsigned long long fract __fractudaudq (unsigned
+          long accum A)
+ -- Runtime Function: unsigned short accum __fractudauha2 (unsigned long
+          accum A)
+ -- Runtime Function: unsigned accum __fractudausa2 (unsigned long accum
+          A)
+ -- Runtime Function: unsigned long long accum __fractudauta2 (unsigned
+          long accum A)
+ -- Runtime Function: signed char __fractudaqi (unsigned long accum A)
+ -- Runtime Function: short __fractudahi (unsigned long accum A)
+ -- Runtime Function: int __fractudasi (unsigned long accum A)
+ -- Runtime Function: long __fractudadi (unsigned long accum A)
+ -- Runtime Function: long long __fractudati (unsigned long accum A)
+ -- Runtime Function: float __fractudasf (unsigned long accum A)
+ -- Runtime Function: double __fractudadf (unsigned long accum A)
+ -- Runtime Function: short fract __fractutaqq (unsigned long long accum
+          A)
+ -- Runtime Function: fract __fractutahq (unsigned long long accum A)
+ -- Runtime Function: long fract __fractutasq (unsigned long long accum
+          A)
+ -- Runtime Function: long long fract __fractutadq (unsigned long long
+          accum A)
+ -- Runtime Function: short accum __fractutaha (unsigned long long accum
+          A)
+ -- Runtime Function: accum __fractutasa (unsigned long long accum A)
+ -- Runtime Function: long accum __fractutada (unsigned long long accum
+          A)
+ -- Runtime Function: long long accum __fractutata (unsigned long long
+          accum A)
+ -- Runtime Function: unsigned short fract __fractutauqq (unsigned long
+          long accum A)
+ -- Runtime Function: unsigned fract __fractutauhq (unsigned long long
+          accum A)
+ -- Runtime Function: unsigned long fract __fractutausq (unsigned long
+          long accum A)
+ -- Runtime Function: unsigned long long fract __fractutaudq (unsigned
+          long long accum A)
+ -- Runtime Function: unsigned short accum __fractutauha2 (unsigned long
+          long accum A)
+ -- Runtime Function: unsigned accum __fractutausa2 (unsigned long long
+          accum A)
+ -- Runtime Function: unsigned long accum __fractutauda2 (unsigned long
+          long accum A)
+ -- Runtime Function: signed char __fractutaqi (unsigned long long accum
+          A)
+ -- Runtime Function: short __fractutahi (unsigned long long accum A)
+ -- Runtime Function: int __fractutasi (unsigned long long accum A)
+ -- Runtime Function: long __fractutadi (unsigned long long accum A)
+ -- Runtime Function: long long __fractutati (unsigned long long accum
+          A)
+ -- Runtime Function: float __fractutasf (unsigned long long accum A)
+ -- Runtime Function: double __fractutadf (unsigned long long accum A)
+ -- Runtime Function: short fract __fractqiqq (signed char A)
+ -- Runtime Function: fract __fractqihq (signed char A)
+ -- Runtime Function: long fract __fractqisq (signed char A)
+ -- Runtime Function: long long fract __fractqidq (signed char A)
+ -- Runtime Function: short accum __fractqiha (signed char A)
+ -- Runtime Function: accum __fractqisa (signed char A)
+ -- Runtime Function: long accum __fractqida (signed char A)
+ -- Runtime Function: long long accum __fractqita (signed char A)
+ -- Runtime Function: unsigned short fract __fractqiuqq (signed char A)
+ -- Runtime Function: unsigned fract __fractqiuhq (signed char A)
+ -- Runtime Function: unsigned long fract __fractqiusq (signed char A)
+ -- Runtime Function: unsigned long long fract __fractqiudq (signed char
+          A)
+ -- Runtime Function: unsigned short accum __fractqiuha (signed char A)
+ -- Runtime Function: unsigned accum __fractqiusa (signed char A)
+ -- Runtime Function: unsigned long accum __fractqiuda (signed char A)
+ -- Runtime Function: unsigned long long accum __fractqiuta (signed char
+          A)
+ -- Runtime Function: short fract __fracthiqq (short A)
+ -- Runtime Function: fract __fracthihq (short A)
+ -- Runtime Function: long fract __fracthisq (short A)
+ -- Runtime Function: long long fract __fracthidq (short A)
+ -- Runtime Function: short accum __fracthiha (short A)
+ -- Runtime Function: accum __fracthisa (short A)
+ -- Runtime Function: long accum __fracthida (short A)
+ -- Runtime Function: long long accum __fracthita (short A)
+ -- Runtime Function: unsigned short fract __fracthiuqq (short A)
+ -- Runtime Function: unsigned fract __fracthiuhq (short A)
+ -- Runtime Function: unsigned long fract __fracthiusq (short A)
+ -- Runtime Function: unsigned long long fract __fracthiudq (short A)
+ -- Runtime Function: unsigned short accum __fracthiuha (short A)
+ -- Runtime Function: unsigned accum __fracthiusa (short A)
+ -- Runtime Function: unsigned long accum __fracthiuda (short A)
+ -- Runtime Function: unsigned long long accum __fracthiuta (short A)
+ -- Runtime Function: short fract __fractsiqq (int A)
+ -- Runtime Function: fract __fractsihq (int A)
+ -- Runtime Function: long fract __fractsisq (int A)
+ -- Runtime Function: long long fract __fractsidq (int A)
+ -- Runtime Function: short accum __fractsiha (int A)
+ -- Runtime Function: accum __fractsisa (int A)
+ -- Runtime Function: long accum __fractsida (int A)
+ -- Runtime Function: long long accum __fractsita (int A)
+ -- Runtime Function: unsigned short fract __fractsiuqq (int A)
+ -- Runtime Function: unsigned fract __fractsiuhq (int A)
+ -- Runtime Function: unsigned long fract __fractsiusq (int A)
+ -- Runtime Function: unsigned long long fract __fractsiudq (int A)
+ -- Runtime Function: unsigned short accum __fractsiuha (int A)
+ -- Runtime Function: unsigned accum __fractsiusa (int A)
+ -- Runtime Function: unsigned long accum __fractsiuda (int A)
+ -- Runtime Function: unsigned long long accum __fractsiuta (int A)
+ -- Runtime Function: short fract __fractdiqq (long A)
+ -- Runtime Function: fract __fractdihq (long A)
+ -- Runtime Function: long fract __fractdisq (long A)
+ -- Runtime Function: long long fract __fractdidq (long A)
+ -- Runtime Function: short accum __fractdiha (long A)
+ -- Runtime Function: accum __fractdisa (long A)
+ -- Runtime Function: long accum __fractdida (long A)
+ -- Runtime Function: long long accum __fractdita (long A)
+ -- Runtime Function: unsigned short fract __fractdiuqq (long A)
+ -- Runtime Function: unsigned fract __fractdiuhq (long A)
+ -- Runtime Function: unsigned long fract __fractdiusq (long A)
+ -- Runtime Function: unsigned long long fract __fractdiudq (long A)
+ -- Runtime Function: unsigned short accum __fractdiuha (long A)
+ -- Runtime Function: unsigned accum __fractdiusa (long A)
+ -- Runtime Function: unsigned long accum __fractdiuda (long A)
+ -- Runtime Function: unsigned long long accum __fractdiuta (long A)
+ -- Runtime Function: short fract __fracttiqq (long long A)
+ -- Runtime Function: fract __fracttihq (long long A)
+ -- Runtime Function: long fract __fracttisq (long long A)
+ -- Runtime Function: long long fract __fracttidq (long long A)
+ -- Runtime Function: short accum __fracttiha (long long A)
+ -- Runtime Function: accum __fracttisa (long long A)
+ -- Runtime Function: long accum __fracttida (long long A)
+ -- Runtime Function: long long accum __fracttita (long long A)
+ -- Runtime Function: unsigned short fract __fracttiuqq (long long A)
+ -- Runtime Function: unsigned fract __fracttiuhq (long long A)
+ -- Runtime Function: unsigned long fract __fracttiusq (long long A)
+ -- Runtime Function: unsigned long long fract __fracttiudq (long long
+          A)
+ -- Runtime Function: unsigned short accum __fracttiuha (long long A)
+ -- Runtime Function: unsigned accum __fracttiusa (long long A)
+ -- Runtime Function: unsigned long accum __fracttiuda (long long A)
+ -- Runtime Function: unsigned long long accum __fracttiuta (long long
+          A)
+ -- Runtime Function: short fract __fractsfqq (float A)
+ -- Runtime Function: fract __fractsfhq (float A)
+ -- Runtime Function: long fract __fractsfsq (float A)
+ -- Runtime Function: long long fract __fractsfdq (float A)
+ -- Runtime Function: short accum __fractsfha (float A)
+ -- Runtime Function: accum __fractsfsa (float A)
+ -- Runtime Function: long accum __fractsfda (float A)
+ -- Runtime Function: long long accum __fractsfta (float A)
+ -- Runtime Function: unsigned short fract __fractsfuqq (float A)
+ -- Runtime Function: unsigned fract __fractsfuhq (float A)
+ -- Runtime Function: unsigned long fract __fractsfusq (float A)
+ -- Runtime Function: unsigned long long fract __fractsfudq (float A)
+ -- Runtime Function: unsigned short accum __fractsfuha (float A)
+ -- Runtime Function: unsigned accum __fractsfusa (float A)
+ -- Runtime Function: unsigned long accum __fractsfuda (float A)
+ -- Runtime Function: unsigned long long accum __fractsfuta (float A)
+ -- Runtime Function: short fract __fractdfqq (double A)
+ -- Runtime Function: fract __fractdfhq (double A)
+ -- Runtime Function: long fract __fractdfsq (double A)
+ -- Runtime Function: long long fract __fractdfdq (double A)
+ -- Runtime Function: short accum __fractdfha (double A)
+ -- Runtime Function: accum __fractdfsa (double A)
+ -- Runtime Function: long accum __fractdfda (double A)
+ -- Runtime Function: long long accum __fractdfta (double A)
+ -- Runtime Function: unsigned short fract __fractdfuqq (double A)
+ -- Runtime Function: unsigned fract __fractdfuhq (double A)
+ -- Runtime Function: unsigned long fract __fractdfusq (double A)
+ -- Runtime Function: unsigned long long fract __fractdfudq (double A)
+ -- Runtime Function: unsigned short accum __fractdfuha (double A)
+ -- Runtime Function: unsigned accum __fractdfusa (double A)
+ -- Runtime Function: unsigned long accum __fractdfuda (double A)
+ -- Runtime Function: unsigned long long accum __fractdfuta (double A)
+     These functions convert from fractional and signed non-fractionals
+     to fractionals and signed non-fractionals, without saturation.
+
+ -- Runtime Function: fract __satfractqqhq2 (short fract A)
+ -- Runtime Function: long fract __satfractqqsq2 (short fract A)
+ -- Runtime Function: long long fract __satfractqqdq2 (short fract A)
+ -- Runtime Function: short accum __satfractqqha (short fract A)
+ -- Runtime Function: accum __satfractqqsa (short fract A)
+ -- Runtime Function: long accum __satfractqqda (short fract A)
+ -- Runtime Function: long long accum __satfractqqta (short fract A)
+ -- Runtime Function: unsigned short fract __satfractqquqq (short fract
+          A)
+ -- Runtime Function: unsigned fract __satfractqquhq (short fract A)
+ -- Runtime Function: unsigned long fract __satfractqqusq (short fract
+          A)
+ -- Runtime Function: unsigned long long fract __satfractqqudq (short
+          fract A)
+ -- Runtime Function: unsigned short accum __satfractqquha (short fract
+          A)
+ -- Runtime Function: unsigned accum __satfractqqusa (short fract A)
+ -- Runtime Function: unsigned long accum __satfractqquda (short fract
+          A)
+ -- Runtime Function: unsigned long long accum __satfractqquta (short
+          fract A)
+ -- Runtime Function: short fract __satfracthqqq2 (fract A)
+ -- Runtime Function: long fract __satfracthqsq2 (fract A)
+ -- Runtime Function: long long fract __satfracthqdq2 (fract A)
+ -- Runtime Function: short accum __satfracthqha (fract A)
+ -- Runtime Function: accum __satfracthqsa (fract A)
+ -- Runtime Function: long accum __satfracthqda (fract A)
+ -- Runtime Function: long long accum __satfracthqta (fract A)
+ -- Runtime Function: unsigned short fract __satfracthquqq (fract A)
+ -- Runtime Function: unsigned fract __satfracthquhq (fract A)
+ -- Runtime Function: unsigned long fract __satfracthqusq (fract A)
+ -- Runtime Function: unsigned long long fract __satfracthqudq (fract A)
+ -- Runtime Function: unsigned short accum __satfracthquha (fract A)
+ -- Runtime Function: unsigned accum __satfracthqusa (fract A)
+ -- Runtime Function: unsigned long accum __satfracthquda (fract A)
+ -- Runtime Function: unsigned long long accum __satfracthquta (fract A)
+ -- Runtime Function: short fract __satfractsqqq2 (long fract A)
+ -- Runtime Function: fract __satfractsqhq2 (long fract A)
+ -- Runtime Function: long long fract __satfractsqdq2 (long fract A)
+ -- Runtime Function: short accum __satfractsqha (long fract A)
+ -- Runtime Function: accum __satfractsqsa (long fract A)
+ -- Runtime Function: long accum __satfractsqda (long fract A)
+ -- Runtime Function: long long accum __satfractsqta (long fract A)
+ -- Runtime Function: unsigned short fract __satfractsquqq (long fract
+          A)
+ -- Runtime Function: unsigned fract __satfractsquhq (long fract A)
+ -- Runtime Function: unsigned long fract __satfractsqusq (long fract A)
+ -- Runtime Function: unsigned long long fract __satfractsqudq (long
+          fract A)
+ -- Runtime Function: unsigned short accum __satfractsquha (long fract
+          A)
+ -- Runtime Function: unsigned accum __satfractsqusa (long fract A)
+ -- Runtime Function: unsigned long accum __satfractsquda (long fract A)
+ -- Runtime Function: unsigned long long accum __satfractsquta (long
+          fract A)
+ -- Runtime Function: short fract __satfractdqqq2 (long long fract A)
+ -- Runtime Function: fract __satfractdqhq2 (long long fract A)
+ -- Runtime Function: long fract __satfractdqsq2 (long long fract A)
+ -- Runtime Function: short accum __satfractdqha (long long fract A)
+ -- Runtime Function: accum __satfractdqsa (long long fract A)
+ -- Runtime Function: long accum __satfractdqda (long long fract A)
+ -- Runtime Function: long long accum __satfractdqta (long long fract A)
+ -- Runtime Function: unsigned short fract __satfractdquqq (long long
+          fract A)
+ -- Runtime Function: unsigned fract __satfractdquhq (long long fract A)
+ -- Runtime Function: unsigned long fract __satfractdqusq (long long
+          fract A)
+ -- Runtime Function: unsigned long long fract __satfractdqudq (long
+          long fract A)
+ -- Runtime Function: unsigned short accum __satfractdquha (long long
+          fract A)
+ -- Runtime Function: unsigned accum __satfractdqusa (long long fract A)
+ -- Runtime Function: unsigned long accum __satfractdquda (long long
+          fract A)
+ -- Runtime Function: unsigned long long accum __satfractdquta (long
+          long fract A)
+ -- Runtime Function: short fract __satfracthaqq (short accum A)
+ -- Runtime Function: fract __satfracthahq (short accum A)
+ -- Runtime Function: long fract __satfracthasq (short accum A)
+ -- Runtime Function: long long fract __satfracthadq (short accum A)
+ -- Runtime Function: accum __satfracthasa2 (short accum A)
+ -- Runtime Function: long accum __satfracthada2 (short accum A)
+ -- Runtime Function: long long accum __satfracthata2 (short accum A)
+ -- Runtime Function: unsigned short fract __satfracthauqq (short accum
+          A)
+ -- Runtime Function: unsigned fract __satfracthauhq (short accum A)
+ -- Runtime Function: unsigned long fract __satfracthausq (short accum
+          A)
+ -- Runtime Function: unsigned long long fract __satfracthaudq (short
+          accum A)
+ -- Runtime Function: unsigned short accum __satfracthauha (short accum
+          A)
+ -- Runtime Function: unsigned accum __satfracthausa (short accum A)
+ -- Runtime Function: unsigned long accum __satfracthauda (short accum
+          A)
+ -- Runtime Function: unsigned long long accum __satfracthauta (short
+          accum A)
+ -- Runtime Function: short fract __satfractsaqq (accum A)
+ -- Runtime Function: fract __satfractsahq (accum A)
+ -- Runtime Function: long fract __satfractsasq (accum A)
+ -- Runtime Function: long long fract __satfractsadq (accum A)
+ -- Runtime Function: short accum __satfractsaha2 (accum A)
+ -- Runtime Function: long accum __satfractsada2 (accum A)
+ -- Runtime Function: long long accum __satfractsata2 (accum A)
+ -- Runtime Function: unsigned short fract __satfractsauqq (accum A)
+ -- Runtime Function: unsigned fract __satfractsauhq (accum A)
+ -- Runtime Function: unsigned long fract __satfractsausq (accum A)
+ -- Runtime Function: unsigned long long fract __satfractsaudq (accum A)
+ -- Runtime Function: unsigned short accum __satfractsauha (accum A)
+ -- Runtime Function: unsigned accum __satfractsausa (accum A)
+ -- Runtime Function: unsigned long accum __satfractsauda (accum A)
+ -- Runtime Function: unsigned long long accum __satfractsauta (accum A)
+ -- Runtime Function: short fract __satfractdaqq (long accum A)
+ -- Runtime Function: fract __satfractdahq (long accum A)
+ -- Runtime Function: long fract __satfractdasq (long accum A)
+ -- Runtime Function: long long fract __satfractdadq (long accum A)
+ -- Runtime Function: short accum __satfractdaha2 (long accum A)
+ -- Runtime Function: accum __satfractdasa2 (long accum A)
+ -- Runtime Function: long long accum __satfractdata2 (long accum A)
+ -- Runtime Function: unsigned short fract __satfractdauqq (long accum
+          A)
+ -- Runtime Function: unsigned fract __satfractdauhq (long accum A)
+ -- Runtime Function: unsigned long fract __satfractdausq (long accum A)
+ -- Runtime Function: unsigned long long fract __satfractdaudq (long
+          accum A)
+ -- Runtime Function: unsigned short accum __satfractdauha (long accum
+          A)
+ -- Runtime Function: unsigned accum __satfractdausa (long accum A)
+ -- Runtime Function: unsigned long accum __satfractdauda (long accum A)
+ -- Runtime Function: unsigned long long accum __satfractdauta (long
+          accum A)
+ -- Runtime Function: short fract __satfracttaqq (long long accum A)
+ -- Runtime Function: fract __satfracttahq (long long accum A)
+ -- Runtime Function: long fract __satfracttasq (long long accum A)
+ -- Runtime Function: long long fract __satfracttadq (long long accum A)
+ -- Runtime Function: short accum __satfracttaha2 (long long accum A)
+ -- Runtime Function: accum __satfracttasa2 (long long accum A)
+ -- Runtime Function: long accum __satfracttada2 (long long accum A)
+ -- Runtime Function: unsigned short fract __satfracttauqq (long long
+          accum A)
+ -- Runtime Function: unsigned fract __satfracttauhq (long long accum A)
+ -- Runtime Function: unsigned long fract __satfracttausq (long long
+          accum A)
+ -- Runtime Function: unsigned long long fract __satfracttaudq (long
+          long accum A)
+ -- Runtime Function: unsigned short accum __satfracttauha (long long
+          accum A)
+ -- Runtime Function: unsigned accum __satfracttausa (long long accum A)
+ -- Runtime Function: unsigned long accum __satfracttauda (long long
+          accum A)
+ -- Runtime Function: unsigned long long accum __satfracttauta (long
+          long accum A)
+ -- Runtime Function: short fract __satfractuqqqq (unsigned short fract
+          A)
+ -- Runtime Function: fract __satfractuqqhq (unsigned short fract A)
+ -- Runtime Function: long fract __satfractuqqsq (unsigned short fract
+          A)
+ -- Runtime Function: long long fract __satfractuqqdq (unsigned short
+          fract A)
+ -- Runtime Function: short accum __satfractuqqha (unsigned short fract
+          A)
+ -- Runtime Function: accum __satfractuqqsa (unsigned short fract A)
+ -- Runtime Function: long accum __satfractuqqda (unsigned short fract
+          A)
+ -- Runtime Function: long long accum __satfractuqqta (unsigned short
+          fract A)
+ -- Runtime Function: unsigned fract __satfractuqquhq2 (unsigned short
+          fract A)
+ -- Runtime Function: unsigned long fract __satfractuqqusq2 (unsigned
+          short fract A)
+ -- Runtime Function: unsigned long long fract __satfractuqqudq2
+          (unsigned short fract A)
+ -- Runtime Function: unsigned short accum __satfractuqquha (unsigned
+          short fract A)
+ -- Runtime Function: unsigned accum __satfractuqqusa (unsigned short
+          fract A)
+ -- Runtime Function: unsigned long accum __satfractuqquda (unsigned
+          short fract A)
+ -- Runtime Function: unsigned long long accum __satfractuqquta
+          (unsigned short fract A)
+ -- Runtime Function: short fract __satfractuhqqq (unsigned fract A)
+ -- Runtime Function: fract __satfractuhqhq (unsigned fract A)
+ -- Runtime Function: long fract __satfractuhqsq (unsigned fract A)
+ -- Runtime Function: long long fract __satfractuhqdq (unsigned fract A)
+ -- Runtime Function: short accum __satfractuhqha (unsigned fract A)
+ -- Runtime Function: accum __satfractuhqsa (unsigned fract A)
+ -- Runtime Function: long accum __satfractuhqda (unsigned fract A)
+ -- Runtime Function: long long accum __satfractuhqta (unsigned fract A)
+ -- Runtime Function: unsigned short fract __satfractuhquqq2 (unsigned
+          fract A)
+ -- Runtime Function: unsigned long fract __satfractuhqusq2 (unsigned
+          fract A)
+ -- Runtime Function: unsigned long long fract __satfractuhqudq2
+          (unsigned fract A)
+ -- Runtime Function: unsigned short accum __satfractuhquha (unsigned
+          fract A)
+ -- Runtime Function: unsigned accum __satfractuhqusa (unsigned fract A)
+ -- Runtime Function: unsigned long accum __satfractuhquda (unsigned
+          fract A)
+ -- Runtime Function: unsigned long long accum __satfractuhquta
+          (unsigned fract A)
+ -- Runtime Function: short fract __satfractusqqq (unsigned long fract
+          A)
+ -- Runtime Function: fract __satfractusqhq (unsigned long fract A)
+ -- Runtime Function: long fract __satfractusqsq (unsigned long fract A)
+ -- Runtime Function: long long fract __satfractusqdq (unsigned long
+          fract A)
+ -- Runtime Function: short accum __satfractusqha (unsigned long fract
+          A)
+ -- Runtime Function: accum __satfractusqsa (unsigned long fract A)
+ -- Runtime Function: long accum __satfractusqda (unsigned long fract A)
+ -- Runtime Function: long long accum __satfractusqta (unsigned long
+          fract A)
+ -- Runtime Function: unsigned short fract __satfractusquqq2 (unsigned
+          long fract A)
+ -- Runtime Function: unsigned fract __satfractusquhq2 (unsigned long
+          fract A)
+ -- Runtime Function: unsigned long long fract __satfractusqudq2
+          (unsigned long fract A)
+ -- Runtime Function: unsigned short accum __satfractusquha (unsigned
+          long fract A)
+ -- Runtime Function: unsigned accum __satfractusqusa (unsigned long
+          fract A)
+ -- Runtime Function: unsigned long accum __satfractusquda (unsigned
+          long fract A)
+ -- Runtime Function: unsigned long long accum __satfractusquta
+          (unsigned long fract A)
+ -- Runtime Function: short fract __satfractudqqq (unsigned long long
+          fract A)
+ -- Runtime Function: fract __satfractudqhq (unsigned long long fract A)
+ -- Runtime Function: long fract __satfractudqsq (unsigned long long
+          fract A)
+ -- Runtime Function: long long fract __satfractudqdq (unsigned long
+          long fract A)
+ -- Runtime Function: short accum __satfractudqha (unsigned long long
+          fract A)
+ -- Runtime Function: accum __satfractudqsa (unsigned long long fract A)
+ -- Runtime Function: long accum __satfractudqda (unsigned long long
+          fract A)
+ -- Runtime Function: long long accum __satfractudqta (unsigned long
+          long fract A)
+ -- Runtime Function: unsigned short fract __satfractudquqq2 (unsigned
+          long long fract A)
+ -- Runtime Function: unsigned fract __satfractudquhq2 (unsigned long
+          long fract A)
+ -- Runtime Function: unsigned long fract __satfractudqusq2 (unsigned
+          long long fract A)
+ -- Runtime Function: unsigned short accum __satfractudquha (unsigned
+          long long fract A)
+ -- Runtime Function: unsigned accum __satfractudqusa (unsigned long
+          long fract A)
+ -- Runtime Function: unsigned long accum __satfractudquda (unsigned
+          long long fract A)
+ -- Runtime Function: unsigned long long accum __satfractudquta
+          (unsigned long long fract A)
+ -- Runtime Function: short fract __satfractuhaqq (unsigned short accum
+          A)
+ -- Runtime Function: fract __satfractuhahq (unsigned short accum A)
+ -- Runtime Function: long fract __satfractuhasq (unsigned short accum
+          A)
+ -- Runtime Function: long long fract __satfractuhadq (unsigned short
+          accum A)
+ -- Runtime Function: short accum __satfractuhaha (unsigned short accum
+          A)
+ -- Runtime Function: accum __satfractuhasa (unsigned short accum A)
+ -- Runtime Function: long accum __satfractuhada (unsigned short accum
+          A)
+ -- Runtime Function: long long accum __satfractuhata (unsigned short
+          accum A)
+ -- Runtime Function: unsigned short fract __satfractuhauqq (unsigned
+          short accum A)
+ -- Runtime Function: unsigned fract __satfractuhauhq (unsigned short
+          accum A)
+ -- Runtime Function: unsigned long fract __satfractuhausq (unsigned
+          short accum A)
+ -- Runtime Function: unsigned long long fract __satfractuhaudq
+          (unsigned short accum A)
+ -- Runtime Function: unsigned accum __satfractuhausa2 (unsigned short
+          accum A)
+ -- Runtime Function: unsigned long accum __satfractuhauda2 (unsigned
+          short accum A)
+ -- Runtime Function: unsigned long long accum __satfractuhauta2
+          (unsigned short accum A)
+ -- Runtime Function: short fract __satfractusaqq (unsigned accum A)
+ -- Runtime Function: fract __satfractusahq (unsigned accum A)
+ -- Runtime Function: long fract __satfractusasq (unsigned accum A)
+ -- Runtime Function: long long fract __satfractusadq (unsigned accum A)
+ -- Runtime Function: short accum __satfractusaha (unsigned accum A)
+ -- Runtime Function: accum __satfractusasa (unsigned accum A)
+ -- Runtime Function: long accum __satfractusada (unsigned accum A)
+ -- Runtime Function: long long accum __satfractusata (unsigned accum A)
+ -- Runtime Function: unsigned short fract __satfractusauqq (unsigned
+          accum A)
+ -- Runtime Function: unsigned fract __satfractusauhq (unsigned accum A)
+ -- Runtime Function: unsigned long fract __satfractusausq (unsigned
+          accum A)
+ -- Runtime Function: unsigned long long fract __satfractusaudq
+          (unsigned accum A)
+ -- Runtime Function: unsigned short accum __satfractusauha2 (unsigned
+          accum A)
+ -- Runtime Function: unsigned long accum __satfractusauda2 (unsigned
+          accum A)
+ -- Runtime Function: unsigned long long accum __satfractusauta2
+          (unsigned accum A)
+ -- Runtime Function: short fract __satfractudaqq (unsigned long accum
+          A)
+ -- Runtime Function: fract __satfractudahq (unsigned long accum A)
+ -- Runtime Function: long fract __satfractudasq (unsigned long accum A)
+ -- Runtime Function: long long fract __satfractudadq (unsigned long
+          accum A)
+ -- Runtime Function: short accum __satfractudaha (unsigned long accum
+          A)
+ -- Runtime Function: accum __satfractudasa (unsigned long accum A)
+ -- Runtime Function: long accum __satfractudada (unsigned long accum A)
+ -- Runtime Function: long long accum __satfractudata (unsigned long
+          accum A)
+ -- Runtime Function: unsigned short fract __satfractudauqq (unsigned
+          long accum A)
+ -- Runtime Function: unsigned fract __satfractudauhq (unsigned long
+          accum A)
+ -- Runtime Function: unsigned long fract __satfractudausq (unsigned
+          long accum A)
+ -- Runtime Function: unsigned long long fract __satfractudaudq
+          (unsigned long accum A)
+ -- Runtime Function: unsigned short accum __satfractudauha2 (unsigned
+          long accum A)
+ -- Runtime Function: unsigned accum __satfractudausa2 (unsigned long
+          accum A)
+ -- Runtime Function: unsigned long long accum __satfractudauta2
+          (unsigned long accum A)
+ -- Runtime Function: short fract __satfractutaqq (unsigned long long
+          accum A)
+ -- Runtime Function: fract __satfractutahq (unsigned long long accum A)
+ -- Runtime Function: long fract __satfractutasq (unsigned long long
+          accum A)
+ -- Runtime Function: long long fract __satfractutadq (unsigned long
+          long accum A)
+ -- Runtime Function: short accum __satfractutaha (unsigned long long
+          accum A)
+ -- Runtime Function: accum __satfractutasa (unsigned long long accum A)
+ -- Runtime Function: long accum __satfractutada (unsigned long long
+          accum A)
+ -- Runtime Function: long long accum __satfractutata (unsigned long
+          long accum A)
+ -- Runtime Function: unsigned short fract __satfractutauqq (unsigned
+          long long accum A)
+ -- Runtime Function: unsigned fract __satfractutauhq (unsigned long
+          long accum A)
+ -- Runtime Function: unsigned long fract __satfractutausq (unsigned
+          long long accum A)
+ -- Runtime Function: unsigned long long fract __satfractutaudq
+          (unsigned long long accum A)
+ -- Runtime Function: unsigned short accum __satfractutauha2 (unsigned
+          long long accum A)
+ -- Runtime Function: unsigned accum __satfractutausa2 (unsigned long
+          long accum A)
+ -- Runtime Function: unsigned long accum __satfractutauda2 (unsigned
+          long long accum A)
+ -- Runtime Function: short fract __satfractqiqq (signed char A)
+ -- Runtime Function: fract __satfractqihq (signed char A)
+ -- Runtime Function: long fract __satfractqisq (signed char A)
+ -- Runtime Function: long long fract __satfractqidq (signed char A)
+ -- Runtime Function: short accum __satfractqiha (signed char A)
+ -- Runtime Function: accum __satfractqisa (signed char A)
+ -- Runtime Function: long accum __satfractqida (signed char A)
+ -- Runtime Function: long long accum __satfractqita (signed char A)
+ -- Runtime Function: unsigned short fract __satfractqiuqq (signed char
+          A)
+ -- Runtime Function: unsigned fract __satfractqiuhq (signed char A)
+ -- Runtime Function: unsigned long fract __satfractqiusq (signed char
+          A)
+ -- Runtime Function: unsigned long long fract __satfractqiudq (signed
+          char A)
+ -- Runtime Function: unsigned short accum __satfractqiuha (signed char
+          A)
+ -- Runtime Function: unsigned accum __satfractqiusa (signed char A)
+ -- Runtime Function: unsigned long accum __satfractqiuda (signed char
+          A)
+ -- Runtime Function: unsigned long long accum __satfractqiuta (signed
+          char A)
+ -- Runtime Function: short fract __satfracthiqq (short A)
+ -- Runtime Function: fract __satfracthihq (short A)
+ -- Runtime Function: long fract __satfracthisq (short A)
+ -- Runtime Function: long long fract __satfracthidq (short A)
+ -- Runtime Function: short accum __satfracthiha (short A)
+ -- Runtime Function: accum __satfracthisa (short A)
+ -- Runtime Function: long accum __satfracthida (short A)
+ -- Runtime Function: long long accum __satfracthita (short A)
+ -- Runtime Function: unsigned short fract __satfracthiuqq (short A)
+ -- Runtime Function: unsigned fract __satfracthiuhq (short A)
+ -- Runtime Function: unsigned long fract __satfracthiusq (short A)
+ -- Runtime Function: unsigned long long fract __satfracthiudq (short A)
+ -- Runtime Function: unsigned short accum __satfracthiuha (short A)
+ -- Runtime Function: unsigned accum __satfracthiusa (short A)
+ -- Runtime Function: unsigned long accum __satfracthiuda (short A)
+ -- Runtime Function: unsigned long long accum __satfracthiuta (short A)
+ -- Runtime Function: short fract __satfractsiqq (int A)
+ -- Runtime Function: fract __satfractsihq (int A)
+ -- Runtime Function: long fract __satfractsisq (int A)
+ -- Runtime Function: long long fract __satfractsidq (int A)
+ -- Runtime Function: short accum __satfractsiha (int A)
+ -- Runtime Function: accum __satfractsisa (int A)
+ -- Runtime Function: long accum __satfractsida (int A)
+ -- Runtime Function: long long accum __satfractsita (int A)
+ -- Runtime Function: unsigned short fract __satfractsiuqq (int A)
+ -- Runtime Function: unsigned fract __satfractsiuhq (int A)
+ -- Runtime Function: unsigned long fract __satfractsiusq (int A)
+ -- Runtime Function: unsigned long long fract __satfractsiudq (int A)
+ -- Runtime Function: unsigned short accum __satfractsiuha (int A)
+ -- Runtime Function: unsigned accum __satfractsiusa (int A)
+ -- Runtime Function: unsigned long accum __satfractsiuda (int A)
+ -- Runtime Function: unsigned long long accum __satfractsiuta (int A)
+ -- Runtime Function: short fract __satfractdiqq (long A)
+ -- Runtime Function: fract __satfractdihq (long A)
+ -- Runtime Function: long fract __satfractdisq (long A)
+ -- Runtime Function: long long fract __satfractdidq (long A)
+ -- Runtime Function: short accum __satfractdiha (long A)
+ -- Runtime Function: accum __satfractdisa (long A)
+ -- Runtime Function: long accum __satfractdida (long A)
+ -- Runtime Function: long long accum __satfractdita (long A)
+ -- Runtime Function: unsigned short fract __satfractdiuqq (long A)
+ -- Runtime Function: unsigned fract __satfractdiuhq (long A)
+ -- Runtime Function: unsigned long fract __satfractdiusq (long A)
+ -- Runtime Function: unsigned long long fract __satfractdiudq (long A)
+ -- Runtime Function: unsigned short accum __satfractdiuha (long A)
+ -- Runtime Function: unsigned accum __satfractdiusa (long A)
+ -- Runtime Function: unsigned long accum __satfractdiuda (long A)
+ -- Runtime Function: unsigned long long accum __satfractdiuta (long A)
+ -- Runtime Function: short fract __satfracttiqq (long long A)
+ -- Runtime Function: fract __satfracttihq (long long A)
+ -- Runtime Function: long fract __satfracttisq (long long A)
+ -- Runtime Function: long long fract __satfracttidq (long long A)
+ -- Runtime Function: short accum __satfracttiha (long long A)
+ -- Runtime Function: accum __satfracttisa (long long A)
+ -- Runtime Function: long accum __satfracttida (long long A)
+ -- Runtime Function: long long accum __satfracttita (long long A)
+ -- Runtime Function: unsigned short fract __satfracttiuqq (long long A)
+ -- Runtime Function: unsigned fract __satfracttiuhq (long long A)
+ -- Runtime Function: unsigned long fract __satfracttiusq (long long A)
+ -- Runtime Function: unsigned long long fract __satfracttiudq (long
+          long A)
+ -- Runtime Function: unsigned short accum __satfracttiuha (long long A)
+ -- Runtime Function: unsigned accum __satfracttiusa (long long A)
+ -- Runtime Function: unsigned long accum __satfracttiuda (long long A)
+ -- Runtime Function: unsigned long long accum __satfracttiuta (long
+          long A)
+ -- Runtime Function: short fract __satfractsfqq (float A)
+ -- Runtime Function: fract __satfractsfhq (float A)
+ -- Runtime Function: long fract __satfractsfsq (float A)
+ -- Runtime Function: long long fract __satfractsfdq (float A)
+ -- Runtime Function: short accum __satfractsfha (float A)
+ -- Runtime Function: accum __satfractsfsa (float A)
+ -- Runtime Function: long accum __satfractsfda (float A)
+ -- Runtime Function: long long accum __satfractsfta (float A)
+ -- Runtime Function: unsigned short fract __satfractsfuqq (float A)
+ -- Runtime Function: unsigned fract __satfractsfuhq (float A)
+ -- Runtime Function: unsigned long fract __satfractsfusq (float A)
+ -- Runtime Function: unsigned long long fract __satfractsfudq (float A)
+ -- Runtime Function: unsigned short accum __satfractsfuha (float A)
+ -- Runtime Function: unsigned accum __satfractsfusa (float A)
+ -- Runtime Function: unsigned long accum __satfractsfuda (float A)
+ -- Runtime Function: unsigned long long accum __satfractsfuta (float A)
+ -- Runtime Function: short fract __satfractdfqq (double A)
+ -- Runtime Function: fract __satfractdfhq (double A)
+ -- Runtime Function: long fract __satfractdfsq (double A)
+ -- Runtime Function: long long fract __satfractdfdq (double A)
+ -- Runtime Function: short accum __satfractdfha (double A)
+ -- Runtime Function: accum __satfractdfsa (double A)
+ -- Runtime Function: long accum __satfractdfda (double A)
+ -- Runtime Function: long long accum __satfractdfta (double A)
+ -- Runtime Function: unsigned short fract __satfractdfuqq (double A)
+ -- Runtime Function: unsigned fract __satfractdfuhq (double A)
+ -- Runtime Function: unsigned long fract __satfractdfusq (double A)
+ -- Runtime Function: unsigned long long fract __satfractdfudq (double
+          A)
+ -- Runtime Function: unsigned short accum __satfractdfuha (double A)
+ -- Runtime Function: unsigned accum __satfractdfusa (double A)
+ -- Runtime Function: unsigned long accum __satfractdfuda (double A)
+ -- Runtime Function: unsigned long long accum __satfractdfuta (double
+          A)
+     The functions convert from fractional and signed non-fractionals to
+     fractionals, with saturation.
+
+ -- Runtime Function: unsigned char __fractunsqqqi (short fract A)
+ -- Runtime Function: unsigned short __fractunsqqhi (short fract A)
+ -- Runtime Function: unsigned int __fractunsqqsi (short fract A)
+ -- Runtime Function: unsigned long __fractunsqqdi (short fract A)
+ -- Runtime Function: unsigned long long __fractunsqqti (short fract A)
+ -- Runtime Function: unsigned char __fractunshqqi (fract A)
+ -- Runtime Function: unsigned short __fractunshqhi (fract A)
+ -- Runtime Function: unsigned int __fractunshqsi (fract A)
+ -- Runtime Function: unsigned long __fractunshqdi (fract A)
+ -- Runtime Function: unsigned long long __fractunshqti (fract A)
+ -- Runtime Function: unsigned char __fractunssqqi (long fract A)
+ -- Runtime Function: unsigned short __fractunssqhi (long fract A)
+ -- Runtime Function: unsigned int __fractunssqsi (long fract A)
+ -- Runtime Function: unsigned long __fractunssqdi (long fract A)
+ -- Runtime Function: unsigned long long __fractunssqti (long fract A)
+ -- Runtime Function: unsigned char __fractunsdqqi (long long fract A)
+ -- Runtime Function: unsigned short __fractunsdqhi (long long fract A)
+ -- Runtime Function: unsigned int __fractunsdqsi (long long fract A)
+ -- Runtime Function: unsigned long __fractunsdqdi (long long fract A)
+ -- Runtime Function: unsigned long long __fractunsdqti (long long fract
+          A)
+ -- Runtime Function: unsigned char __fractunshaqi (short accum A)
+ -- Runtime Function: unsigned short __fractunshahi (short accum A)
+ -- Runtime Function: unsigned int __fractunshasi (short accum A)
+ -- Runtime Function: unsigned long __fractunshadi (short accum A)
+ -- Runtime Function: unsigned long long __fractunshati (short accum A)
+ -- Runtime Function: unsigned char __fractunssaqi (accum A)
+ -- Runtime Function: unsigned short __fractunssahi (accum A)
+ -- Runtime Function: unsigned int __fractunssasi (accum A)
+ -- Runtime Function: unsigned long __fractunssadi (accum A)
+ -- Runtime Function: unsigned long long __fractunssati (accum A)
+ -- Runtime Function: unsigned char __fractunsdaqi (long accum A)
+ -- Runtime Function: unsigned short __fractunsdahi (long accum A)
+ -- Runtime Function: unsigned int __fractunsdasi (long accum A)
+ -- Runtime Function: unsigned long __fractunsdadi (long accum A)
+ -- Runtime Function: unsigned long long __fractunsdati (long accum A)
+ -- Runtime Function: unsigned char __fractunstaqi (long long accum A)
+ -- Runtime Function: unsigned short __fractunstahi (long long accum A)
+ -- Runtime Function: unsigned int __fractunstasi (long long accum A)
+ -- Runtime Function: unsigned long __fractunstadi (long long accum A)
+ -- Runtime Function: unsigned long long __fractunstati (long long accum
+          A)
+ -- Runtime Function: unsigned char __fractunsuqqqi (unsigned short
+          fract A)
+ -- Runtime Function: unsigned short __fractunsuqqhi (unsigned short
+          fract A)
+ -- Runtime Function: unsigned int __fractunsuqqsi (unsigned short fract
+          A)
+ -- Runtime Function: unsigned long __fractunsuqqdi (unsigned short
+          fract A)
+ -- Runtime Function: unsigned long long __fractunsuqqti (unsigned short
+          fract A)
+ -- Runtime Function: unsigned char __fractunsuhqqi (unsigned fract A)
+ -- Runtime Function: unsigned short __fractunsuhqhi (unsigned fract A)
+ -- Runtime Function: unsigned int __fractunsuhqsi (unsigned fract A)
+ -- Runtime Function: unsigned long __fractunsuhqdi (unsigned fract A)
+ -- Runtime Function: unsigned long long __fractunsuhqti (unsigned fract
+          A)
+ -- Runtime Function: unsigned char __fractunsusqqi (unsigned long fract
+          A)
+ -- Runtime Function: unsigned short __fractunsusqhi (unsigned long
+          fract A)
+ -- Runtime Function: unsigned int __fractunsusqsi (unsigned long fract
+          A)
+ -- Runtime Function: unsigned long __fractunsusqdi (unsigned long fract
+          A)
+ -- Runtime Function: unsigned long long __fractunsusqti (unsigned long
+          fract A)
+ -- Runtime Function: unsigned char __fractunsudqqi (unsigned long long
+          fract A)
+ -- Runtime Function: unsigned short __fractunsudqhi (unsigned long long
+          fract A)
+ -- Runtime Function: unsigned int __fractunsudqsi (unsigned long long
+          fract A)
+ -- Runtime Function: unsigned long __fractunsudqdi (unsigned long long
+          fract A)
+ -- Runtime Function: unsigned long long __fractunsudqti (unsigned long
+          long fract A)
+ -- Runtime Function: unsigned char __fractunsuhaqi (unsigned short
+          accum A)
+ -- Runtime Function: unsigned short __fractunsuhahi (unsigned short
+          accum A)
+ -- Runtime Function: unsigned int __fractunsuhasi (unsigned short accum
+          A)
+ -- Runtime Function: unsigned long __fractunsuhadi (unsigned short
+          accum A)
+ -- Runtime Function: unsigned long long __fractunsuhati (unsigned short
+          accum A)
+ -- Runtime Function: unsigned char __fractunsusaqi (unsigned accum A)
+ -- Runtime Function: unsigned short __fractunsusahi (unsigned accum A)
+ -- Runtime Function: unsigned int __fractunsusasi (unsigned accum A)
+ -- Runtime Function: unsigned long __fractunsusadi (unsigned accum A)
+ -- Runtime Function: unsigned long long __fractunsusati (unsigned accum
+          A)
+ -- Runtime Function: unsigned char __fractunsudaqi (unsigned long accum
+          A)
+ -- Runtime Function: unsigned short __fractunsudahi (unsigned long
+          accum A)
+ -- Runtime Function: unsigned int __fractunsudasi (unsigned long accum
+          A)
+ -- Runtime Function: unsigned long __fractunsudadi (unsigned long accum
+          A)
+ -- Runtime Function: unsigned long long __fractunsudati (unsigned long
+          accum A)
+ -- Runtime Function: unsigned char __fractunsutaqi (unsigned long long
+          accum A)
+ -- Runtime Function: unsigned short __fractunsutahi (unsigned long long
+          accum A)
+ -- Runtime Function: unsigned int __fractunsutasi (unsigned long long
+          accum A)
+ -- Runtime Function: unsigned long __fractunsutadi (unsigned long long
+          accum A)
+ -- Runtime Function: unsigned long long __fractunsutati (unsigned long
+          long accum A)
+ -- Runtime Function: short fract __fractunsqiqq (unsigned char A)
+ -- Runtime Function: fract __fractunsqihq (unsigned char A)
+ -- Runtime Function: long fract __fractunsqisq (unsigned char A)
+ -- Runtime Function: long long fract __fractunsqidq (unsigned char A)
+ -- Runtime Function: short accum __fractunsqiha (unsigned char A)
+ -- Runtime Function: accum __fractunsqisa (unsigned char A)
+ -- Runtime Function: long accum __fractunsqida (unsigned char A)
+ -- Runtime Function: long long accum __fractunsqita (unsigned char A)
+ -- Runtime Function: unsigned short fract __fractunsqiuqq (unsigned
+          char A)
+ -- Runtime Function: unsigned fract __fractunsqiuhq (unsigned char A)
+ -- Runtime Function: unsigned long fract __fractunsqiusq (unsigned char
+          A)
+ -- Runtime Function: unsigned long long fract __fractunsqiudq (unsigned
+          char A)
+ -- Runtime Function: unsigned short accum __fractunsqiuha (unsigned
+          char A)
+ -- Runtime Function: unsigned accum __fractunsqiusa (unsigned char A)
+ -- Runtime Function: unsigned long accum __fractunsqiuda (unsigned char
+          A)
+ -- Runtime Function: unsigned long long accum __fractunsqiuta (unsigned
+          char A)
+ -- Runtime Function: short fract __fractunshiqq (unsigned short A)
+ -- Runtime Function: fract __fractunshihq (unsigned short A)
+ -- Runtime Function: long fract __fractunshisq (unsigned short A)
+ -- Runtime Function: long long fract __fractunshidq (unsigned short A)
+ -- Runtime Function: short accum __fractunshiha (unsigned short A)
+ -- Runtime Function: accum __fractunshisa (unsigned short A)
+ -- Runtime Function: long accum __fractunshida (unsigned short A)
+ -- Runtime Function: long long accum __fractunshita (unsigned short A)
+ -- Runtime Function: unsigned short fract __fractunshiuqq (unsigned
+          short A)
+ -- Runtime Function: unsigned fract __fractunshiuhq (unsigned short A)
+ -- Runtime Function: unsigned long fract __fractunshiusq (unsigned
+          short A)
+ -- Runtime Function: unsigned long long fract __fractunshiudq (unsigned
+          short A)
+ -- Runtime Function: unsigned short accum __fractunshiuha (unsigned
+          short A)
+ -- Runtime Function: unsigned accum __fractunshiusa (unsigned short A)
+ -- Runtime Function: unsigned long accum __fractunshiuda (unsigned
+          short A)
+ -- Runtime Function: unsigned long long accum __fractunshiuta (unsigned
+          short A)
+ -- Runtime Function: short fract __fractunssiqq (unsigned int A)
+ -- Runtime Function: fract __fractunssihq (unsigned int A)
+ -- Runtime Function: long fract __fractunssisq (unsigned int A)
+ -- Runtime Function: long long fract __fractunssidq (unsigned int A)
+ -- Runtime Function: short accum __fractunssiha (unsigned int A)
+ -- Runtime Function: accum __fractunssisa (unsigned int A)
+ -- Runtime Function: long accum __fractunssida (unsigned int A)
+ -- Runtime Function: long long accum __fractunssita (unsigned int A)
+ -- Runtime Function: unsigned short fract __fractunssiuqq (unsigned int
+          A)
+ -- Runtime Function: unsigned fract __fractunssiuhq (unsigned int A)
+ -- Runtime Function: unsigned long fract __fractunssiusq (unsigned int
+          A)
+ -- Runtime Function: unsigned long long fract __fractunssiudq (unsigned
+          int A)
+ -- Runtime Function: unsigned short accum __fractunssiuha (unsigned int
+          A)
+ -- Runtime Function: unsigned accum __fractunssiusa (unsigned int A)
+ -- Runtime Function: unsigned long accum __fractunssiuda (unsigned int
+          A)
+ -- Runtime Function: unsigned long long accum __fractunssiuta (unsigned
+          int A)
+ -- Runtime Function: short fract __fractunsdiqq (unsigned long A)
+ -- Runtime Function: fract __fractunsdihq (unsigned long A)
+ -- Runtime Function: long fract __fractunsdisq (unsigned long A)
+ -- Runtime Function: long long fract __fractunsdidq (unsigned long A)
+ -- Runtime Function: short accum __fractunsdiha (unsigned long A)
+ -- Runtime Function: accum __fractunsdisa (unsigned long A)
+ -- Runtime Function: long accum __fractunsdida (unsigned long A)
+ -- Runtime Function: long long accum __fractunsdita (unsigned long A)
+ -- Runtime Function: unsigned short fract __fractunsdiuqq (unsigned
+          long A)
+ -- Runtime Function: unsigned fract __fractunsdiuhq (unsigned long A)
+ -- Runtime Function: unsigned long fract __fractunsdiusq (unsigned long
+          A)
+ -- Runtime Function: unsigned long long fract __fractunsdiudq (unsigned
+          long A)
+ -- Runtime Function: unsigned short accum __fractunsdiuha (unsigned
+          long A)
+ -- Runtime Function: unsigned accum __fractunsdiusa (unsigned long A)
+ -- Runtime Function: unsigned long accum __fractunsdiuda (unsigned long
+          A)
+ -- Runtime Function: unsigned long long accum __fractunsdiuta (unsigned
+          long A)
+ -- Runtime Function: short fract __fractunstiqq (unsigned long long A)
+ -- Runtime Function: fract __fractunstihq (unsigned long long A)
+ -- Runtime Function: long fract __fractunstisq (unsigned long long A)
+ -- Runtime Function: long long fract __fractunstidq (unsigned long long
+          A)
+ -- Runtime Function: short accum __fractunstiha (unsigned long long A)
+ -- Runtime Function: accum __fractunstisa (unsigned long long A)
+ -- Runtime Function: long accum __fractunstida (unsigned long long A)
+ -- Runtime Function: long long accum __fractunstita (unsigned long long
+          A)
+ -- Runtime Function: unsigned short fract __fractunstiuqq (unsigned
+          long long A)
+ -- Runtime Function: unsigned fract __fractunstiuhq (unsigned long long
+          A)
+ -- Runtime Function: unsigned long fract __fractunstiusq (unsigned long
+          long A)
+ -- Runtime Function: unsigned long long fract __fractunstiudq (unsigned
+          long long A)
+ -- Runtime Function: unsigned short accum __fractunstiuha (unsigned
+          long long A)
+ -- Runtime Function: unsigned accum __fractunstiusa (unsigned long long
+          A)
+ -- Runtime Function: unsigned long accum __fractunstiuda (unsigned long
+          long A)
+ -- Runtime Function: unsigned long long accum __fractunstiuta (unsigned
+          long long A)
+     These functions convert from fractionals to unsigned
+     non-fractionals; and from unsigned non-fractionals to fractionals,
+     without saturation.
+
+ -- Runtime Function: short fract __satfractunsqiqq (unsigned char A)
+ -- Runtime Function: fract __satfractunsqihq (unsigned char A)
+ -- Runtime Function: long fract __satfractunsqisq (unsigned char A)
+ -- Runtime Function: long long fract __satfractunsqidq (unsigned char
+          A)
+ -- Runtime Function: short accum __satfractunsqiha (unsigned char A)
+ -- Runtime Function: accum __satfractunsqisa (unsigned char A)
+ -- Runtime Function: long accum __satfractunsqida (unsigned char A)
+ -- Runtime Function: long long accum __satfractunsqita (unsigned char
+          A)
+ -- Runtime Function: unsigned short fract __satfractunsqiuqq (unsigned
+          char A)
+ -- Runtime Function: unsigned fract __satfractunsqiuhq (unsigned char
+          A)
+ -- Runtime Function: unsigned long fract __satfractunsqiusq (unsigned
+          char A)
+ -- Runtime Function: unsigned long long fract __satfractunsqiudq
+          (unsigned char A)
+ -- Runtime Function: unsigned short accum __satfractunsqiuha (unsigned
+          char A)
+ -- Runtime Function: unsigned accum __satfractunsqiusa (unsigned char
+          A)
+ -- Runtime Function: unsigned long accum __satfractunsqiuda (unsigned
+          char A)
+ -- Runtime Function: unsigned long long accum __satfractunsqiuta
+          (unsigned char A)
+ -- Runtime Function: short fract __satfractunshiqq (unsigned short A)
+ -- Runtime Function: fract __satfractunshihq (unsigned short A)
+ -- Runtime Function: long fract __satfractunshisq (unsigned short A)
+ -- Runtime Function: long long fract __satfractunshidq (unsigned short
+          A)
+ -- Runtime Function: short accum __satfractunshiha (unsigned short A)
+ -- Runtime Function: accum __satfractunshisa (unsigned short A)
+ -- Runtime Function: long accum __satfractunshida (unsigned short A)
+ -- Runtime Function: long long accum __satfractunshita (unsigned short
+          A)
+ -- Runtime Function: unsigned short fract __satfractunshiuqq (unsigned
+          short A)
+ -- Runtime Function: unsigned fract __satfractunshiuhq (unsigned short
+          A)
+ -- Runtime Function: unsigned long fract __satfractunshiusq (unsigned
+          short A)
+ -- Runtime Function: unsigned long long fract __satfractunshiudq
+          (unsigned short A)
+ -- Runtime Function: unsigned short accum __satfractunshiuha (unsigned
+          short A)
+ -- Runtime Function: unsigned accum __satfractunshiusa (unsigned short
+          A)
+ -- Runtime Function: unsigned long accum __satfractunshiuda (unsigned
+          short A)
+ -- Runtime Function: unsigned long long accum __satfractunshiuta
+          (unsigned short A)
+ -- Runtime Function: short fract __satfractunssiqq (unsigned int A)
+ -- Runtime Function: fract __satfractunssihq (unsigned int A)
+ -- Runtime Function: long fract __satfractunssisq (unsigned int A)
+ -- Runtime Function: long long fract __satfractunssidq (unsigned int A)
+ -- Runtime Function: short accum __satfractunssiha (unsigned int A)
+ -- Runtime Function: accum __satfractunssisa (unsigned int A)
+ -- Runtime Function: long accum __satfractunssida (unsigned int A)
+ -- Runtime Function: long long accum __satfractunssita (unsigned int A)
+ -- Runtime Function: unsigned short fract __satfractunssiuqq (unsigned
+          int A)
+ -- Runtime Function: unsigned fract __satfractunssiuhq (unsigned int A)
+ -- Runtime Function: unsigned long fract __satfractunssiusq (unsigned
+          int A)
+ -- Runtime Function: unsigned long long fract __satfractunssiudq
+          (unsigned int A)
+ -- Runtime Function: unsigned short accum __satfractunssiuha (unsigned
+          int A)
+ -- Runtime Function: unsigned accum __satfractunssiusa (unsigned int A)
+ -- Runtime Function: unsigned long accum __satfractunssiuda (unsigned
+          int A)
+ -- Runtime Function: unsigned long long accum __satfractunssiuta
+          (unsigned int A)
+ -- Runtime Function: short fract __satfractunsdiqq (unsigned long A)
+ -- Runtime Function: fract __satfractunsdihq (unsigned long A)
+ -- Runtime Function: long fract __satfractunsdisq (unsigned long A)
+ -- Runtime Function: long long fract __satfractunsdidq (unsigned long
+          A)
+ -- Runtime Function: short accum __satfractunsdiha (unsigned long A)
+ -- Runtime Function: accum __satfractunsdisa (unsigned long A)
+ -- Runtime Function: long accum __satfractunsdida (unsigned long A)
+ -- Runtime Function: long long accum __satfractunsdita (unsigned long
+          A)
+ -- Runtime Function: unsigned short fract __satfractunsdiuqq (unsigned
+          long A)
+ -- Runtime Function: unsigned fract __satfractunsdiuhq (unsigned long
+          A)
+ -- Runtime Function: unsigned long fract __satfractunsdiusq (unsigned
+          long A)
+ -- Runtime Function: unsigned long long fract __satfractunsdiudq
+          (unsigned long A)
+ -- Runtime Function: unsigned short accum __satfractunsdiuha (unsigned
+          long A)
+ -- Runtime Function: unsigned accum __satfractunsdiusa (unsigned long
+          A)
+ -- Runtime Function: unsigned long accum __satfractunsdiuda (unsigned
+          long A)
+ -- Runtime Function: unsigned long long accum __satfractunsdiuta
+          (unsigned long A)
+ -- Runtime Function: short fract __satfractunstiqq (unsigned long long
+          A)
+ -- Runtime Function: fract __satfractunstihq (unsigned long long A)
+ -- Runtime Function: long fract __satfractunstisq (unsigned long long
+          A)
+ -- Runtime Function: long long fract __satfractunstidq (unsigned long
+          long A)
+ -- Runtime Function: short accum __satfractunstiha (unsigned long long
+          A)
+ -- Runtime Function: accum __satfractunstisa (unsigned long long A)
+ -- Runtime Function: long accum __satfractunstida (unsigned long long
+          A)
+ -- Runtime Function: long long accum __satfractunstita (unsigned long
+          long A)
+ -- Runtime Function: unsigned short fract __satfractunstiuqq (unsigned
+          long long A)
+ -- Runtime Function: unsigned fract __satfractunstiuhq (unsigned long
+          long A)
+ -- Runtime Function: unsigned long fract __satfractunstiusq (unsigned
+          long long A)
+ -- Runtime Function: unsigned long long fract __satfractunstiudq
+          (unsigned long long A)
+ -- Runtime Function: unsigned short accum __satfractunstiuha (unsigned
+          long long A)
+ -- Runtime Function: unsigned accum __satfractunstiusa (unsigned long
+          long A)
+ -- Runtime Function: unsigned long accum __satfractunstiuda (unsigned
+          long long A)
+ -- Runtime Function: unsigned long long accum __satfractunstiuta
+          (unsigned long long A)
+     These functions convert from unsigned non-fractionals to
+     fractionals, with saturation.
+
+
+File: gccint.info,  Node: Exception handling routines,  Next: Miscellaneous routines,  Prev: Fixed-point fractional library routines,  Up: Libgcc
+
+4.5 Language-independent routines for exception handling
+========================================================
+
+document me!
+
+       _Unwind_DeleteException
+       _Unwind_Find_FDE
+       _Unwind_ForcedUnwind
+       _Unwind_GetGR
+       _Unwind_GetIP
+       _Unwind_GetLanguageSpecificData
+       _Unwind_GetRegionStart
+       _Unwind_GetTextRelBase
+       _Unwind_GetDataRelBase
+       _Unwind_RaiseException
+       _Unwind_Resume
+       _Unwind_SetGR
+       _Unwind_SetIP
+       _Unwind_FindEnclosingFunction
+       _Unwind_SjLj_Register
+       _Unwind_SjLj_Unregister
+       _Unwind_SjLj_RaiseException
+       _Unwind_SjLj_ForcedUnwind
+       _Unwind_SjLj_Resume
+       __deregister_frame
+       __deregister_frame_info
+       __deregister_frame_info_bases
+       __register_frame
+       __register_frame_info
+       __register_frame_info_bases
+       __register_frame_info_table
+       __register_frame_info_table_bases
+       __register_frame_table
+
+
+File: gccint.info,  Node: Miscellaneous routines,  Prev: Exception handling routines,  Up: Libgcc
+
+4.6 Miscellaneous runtime library routines
+==========================================
+
+4.6.1 Cache control functions
+-----------------------------
+
+ -- Runtime Function: void __clear_cache (char *BEG, char *END)
+     This function clears the instruction cache between BEG and END.
+
+4.6.2 Split stack functions and variables
+-----------------------------------------
+
+ -- Runtime Function: void * __splitstack_find (void *SEGMENT_ARG, void
+          *SP, size_t LEN, void **NEXT_SEGMENT, void **NEXT_SP, void
+          **INITIAL_SP)
+     When using '-fsplit-stack', this call may be used to iterate over
+     the stack segments.  It may be called like this:
+            void *next_segment = NULL;
+            void *next_sp = NULL;
+            void *initial_sp = NULL;
+            void *stack;
+            size_t stack_size;
+            while ((stack = __splitstack_find (next_segment, next_sp,
+                                               &stack_size, &next_segment,
+                                               &next_sp, &initial_sp))
+                   != NULL)
+              {
+                /* Stack segment starts at stack and is
+                   stack_size bytes long.  */
+              }
+
+     There is no way to iterate over the stack segments of a different
+     thread.  However, what is permitted is for one thread to call this
+     with the SEGMENT_ARG and SP arguments NULL, to pass NEXT_SEGMENT,
+     NEXT_SP, and INITIAL_SP to a different thread, and then to suspend
+     one way or another.  A different thread may run the subsequent
+     '__splitstack_find' iterations.  Of course, this will only work if
+     the first thread is suspended while the second thread is calling
+     '__splitstack_find'.  If not, the second thread could be looking at
+     the stack while it is changing, and anything could happen.
+
+ -- Variable: __morestack_segments
+ -- Variable: __morestack_current_segment
+ -- Variable: __morestack_initial_sp
+     Internal variables used by the '-fsplit-stack' implementation.
+
+
+File: gccint.info,  Node: Languages,  Next: Source Tree,  Prev: Libgcc,  Up: Top
+
+5 Language Front Ends in GCC
+****************************
+
+The interface to front ends for languages in GCC, and in particular the
+'tree' structure (*note GENERIC::), was initially designed for C, and
+many aspects of it are still somewhat biased towards C and C-like
+languages.  It is, however, reasonably well suited to other procedural
+languages, and front ends for many such languages have been written for
+GCC.
+
+ Writing a compiler as a front end for GCC, rather than compiling
+directly to assembler or generating C code which is then compiled by
+GCC, has several advantages:
+
+   * GCC front ends benefit from the support for many different target
+     machines already present in GCC.
+   * GCC front ends benefit from all the optimizations in GCC.  Some of
+     these, such as alias analysis, may work better when GCC is
+     compiling directly from source code then when it is compiling from
+     generated C code.
+   * Better debugging information is generated when compiling directly
+     from source code than when going via intermediate generated C code.
+
+ Because of the advantages of writing a compiler as a GCC front end, GCC
+front ends have also been created for languages very different from
+those for which GCC was designed, such as the declarative
+logic/functional language Mercury.  For these reasons, it may also be
+useful to implement compilers created for specialized purposes (for
+example, as part of a research project) as GCC front ends.
+
+
+File: gccint.info,  Node: Source Tree,  Next: Testsuites,  Prev: Languages,  Up: Top
+
+6 Source Tree Structure and Build System
+****************************************
+
+This chapter describes the structure of the GCC source tree, and how GCC
+is built.  The user documentation for building and installing GCC is in
+a separate manual (<http://gcc.gnu.org/install/>), with which it is
+presumed that you are familiar.
+
+* Menu:
+
+* Configure Terms:: Configuration terminology and history.
+* Top Level::       The top level source directory.
+* gcc Directory::   The 'gcc' subdirectory.
+
+
+File: gccint.info,  Node: Configure Terms,  Next: Top Level,  Up: Source Tree
+
+6.1 Configure Terms and History
+===============================
+
+The configure and build process has a long and colorful history, and can
+be confusing to anyone who doesn't know why things are the way they are.
+While there are other documents which describe the configuration process
+in detail, here are a few things that everyone working on GCC should
+know.
+
+ There are three system names that the build knows about: the machine
+you are building on ("build"), the machine that you are building for
+("host"), and the machine that GCC will produce code for ("target").
+When you configure GCC, you specify these with '--build=', '--host=',
+and '--target='.
+
+ Specifying the host without specifying the build should be avoided, as
+'configure' may (and once did) assume that the host you specify is also
+the build, which may not be true.
+
+ If build, host, and target are all the same, this is called a "native".
+If build and host are the same but target is different, this is called a
+"cross".  If build, host, and target are all different this is called a
+"canadian" (for obscure reasons dealing with Canada's political party
+and the background of the person working on the build at that time).  If
+host and target are the same, but build is different, you are using a
+cross-compiler to build a native for a different system.  Some people
+call this a "host-x-host", "crossed native", or "cross-built native".
+If build and target are the same, but host is different, you are using a
+cross compiler to build a cross compiler that produces code for the
+machine you're building on.  This is rare, so there is no common way of
+describing it.  There is a proposal to call this a "crossback".
+
+ If build and host are the same, the GCC you are building will also be
+used to build the target libraries (like 'libstdc++').  If build and
+host are different, you must have already built and installed a cross
+compiler that will be used to build the target libraries (if you
+configured with '--target=foo-bar', this compiler will be called
+'foo-bar-gcc').
+
+ In the case of target libraries, the machine you're building for is the
+machine you specified with '--target'.  So, build is the machine you're
+building on (no change there), host is the machine you're building for
+(the target libraries are built for the target, so host is the target
+you specified), and target doesn't apply (because you're not building a
+compiler, you're building libraries).  The configure/make process will
+adjust these variables as needed.  It also sets '$with_cross_host' to
+the original '--host' value in case you need it.
+
+ The 'libiberty' support library is built up to three times: once for
+the host, once for the target (even if they are the same), and once for
+the build if build and host are different.  This allows it to be used by
+all programs which are generated in the course of the build process.
+
+
+File: gccint.info,  Node: Top Level,  Next: gcc Directory,  Prev: Configure Terms,  Up: Source Tree
+
+6.2 Top Level Source Directory
+==============================
+
+The top level source directory in a GCC distribution contains several
+files and directories that are shared with other software distributions
+such as that of GNU Binutils.  It also contains several subdirectories
+that contain parts of GCC and its runtime libraries:
+
+'boehm-gc'
+     The Boehm conservative garbage collector, used as part of the Java
+     runtime library.
+
+'config'
+     Autoconf macros and Makefile fragments used throughout the tree.
+
+'contrib'
+     Contributed scripts that may be found useful in conjunction with
+     GCC.  One of these, 'contrib/texi2pod.pl', is used to generate man
+     pages from Texinfo manuals as part of the GCC build process.
+
+'fixincludes'
+     The support for fixing system headers to work with GCC.  See
+     'fixincludes/README' for more information.  The headers fixed by
+     this mechanism are installed in 'LIBSUBDIR/include-fixed'.  Along
+     with those headers, 'README-fixinc' is also installed, as
+     'LIBSUBDIR/include-fixed/README'.
+
+'gcc'
+     The main sources of GCC itself (except for runtime libraries),
+     including optimizers, support for different target architectures,
+     language front ends, and testsuites.  *Note The 'gcc' Subdirectory:
+     gcc Directory, for details.
+
+'gnattools'
+     Support tools for GNAT.
+
+'include'
+     Headers for the 'libiberty' library.
+
+'intl'
+     GNU 'libintl', from GNU 'gettext', for systems which do not include
+     it in 'libc'.
+
+'libada'
+     The Ada runtime library.
+
+'libatomic'
+     The runtime support library for atomic operations (e.g.  for
+     '__sync' and '__atomic').
+
+'libcpp'
+     The C preprocessor library.
+
+'libdecnumber'
+     The Decimal Float support library.
+
+'libffi'
+     The 'libffi' library, used as part of the Java runtime library.
+
+'libgcc'
+     The GCC runtime library.
+
+'libgfortran'
+     The Fortran runtime library.
+
+'libgo'
+     The Go runtime library.  The bulk of this library is mirrored from
+     the master Go repository (http://code.google.com/p/go/).
+
+'libgomp'
+     The GNU OpenMP runtime library.
+
+'libiberty'
+     The 'libiberty' library, used for portability and for some
+     generally useful data structures and algorithms.  *Note
+     Introduction: (libiberty)Top, for more information about this
+     library.
+
+'libitm'
+     The runtime support library for transactional memory.
+
+'libjava'
+     The Java runtime library.
+
+'libobjc'
+     The Objective-C and Objective-C++ runtime library.
+
+'libquadmath'
+     The runtime support library for quad-precision math operations.
+
+'libssp'
+     The Stack protector runtime library.
+
+'libstdc++-v3'
+     The C++ runtime library.
+
+'lto-plugin'
+     Plugin used by the linker if link-time optimizations are enabled.
+
+'maintainer-scripts'
+     Scripts used by the 'gccadmin' account on 'gcc.gnu.org'.
+
+'zlib'
+     The 'zlib' compression library, used by the Java front end, as part
+     of the Java runtime library, and for compressing and uncompressing
+     GCC's intermediate language in LTO object files.
+
+ The build system in the top level directory, including how recursion
+into subdirectories works and how building runtime libraries for
+multilibs is handled, is documented in a separate manual, included with
+GNU Binutils.  *Note GNU configure and build system: (configure)Top, for
+details.
+
+
+File: gccint.info,  Node: gcc Directory,  Prev: Top Level,  Up: Source Tree
+
+6.3 The 'gcc' Subdirectory
+==========================
+
+The 'gcc' directory contains many files that are part of the C sources
+of GCC, other files used as part of the configuration and build process,
+and subdirectories including documentation and a testsuite.  The files
+that are sources of GCC are documented in a separate chapter.  *Note
+Passes and Files of the Compiler: Passes.
+
+* Menu:
+
+* Subdirectories:: Subdirectories of 'gcc'.
+* Configuration::  The configuration process, and the files it uses.
+* Build::          The build system in the 'gcc' directory.
+* Makefile::       Targets in 'gcc/Makefile'.
+* Library Files::  Library source files and headers under 'gcc/'.
+* Headers::        Headers installed by GCC.
+* Documentation::  Building documentation in GCC.
+* Front End::      Anatomy of a language front end.
+* Back End::       Anatomy of a target back end.
+
+
+File: gccint.info,  Node: Subdirectories,  Next: Configuration,  Up: gcc Directory
+
+6.3.1 Subdirectories of 'gcc'
+-----------------------------
+
+The 'gcc' directory contains the following subdirectories:
+
+'LANGUAGE'
+     Subdirectories for various languages.  Directories containing a
+     file 'config-lang.in' are language subdirectories.  The contents of
+     the subdirectories 'c' (for C), 'cp' (for C++), 'objc' (for
+     Objective-C), 'objcp' (for Objective-C++), and 'lto' (for LTO) are
+     documented in this manual (*note Passes and Files of the Compiler:
+     Passes.); those for other languages are not.  *Note Anatomy of a
+     Language Front End: Front End, for details of the files in these
+     directories.
+
+'common'
+     Source files shared between the compiler drivers (such as 'gcc')
+     and the compilers proper (such as 'cc1').  If an architecture
+     defines target hooks shared between those places, it also has a
+     subdirectory in 'common/config'.  *Note Target Structure::.
+
+'config'
+     Configuration files for supported architectures and operating
+     systems.  *Note Anatomy of a Target Back End: Back End, for details
+     of the files in this directory.
+
+'doc'
+     Texinfo documentation for GCC, together with automatically
+     generated man pages and support for converting the installation
+     manual to HTML.  *Note Documentation::.
+
+'ginclude'
+     System headers installed by GCC, mainly those required by the C
+     standard of freestanding implementations.  *Note Headers Installed
+     by GCC: Headers, for details of when these and other headers are
+     installed.
+
+'po'
+     Message catalogs with translations of messages produced by GCC into
+     various languages, 'LANGUAGE.po'.  This directory also contains
+     'gcc.pot', the template for these message catalogues, 'exgettext',
+     a wrapper around 'gettext' to extract the messages from the GCC
+     sources and create 'gcc.pot', which is run by 'make gcc.pot', and
+     'EXCLUDES', a list of files from which messages should not be
+     extracted.
+
+'testsuite'
+     The GCC testsuites (except for those for runtime libraries).  *Note
+     Testsuites::.
+
+
+File: gccint.info,  Node: Configuration,  Next: Build,  Prev: Subdirectories,  Up: gcc Directory
+
+6.3.2 Configuration in the 'gcc' Directory
+------------------------------------------
+
+The 'gcc' directory is configured with an Autoconf-generated script
+'configure'.  The 'configure' script is generated from 'configure.ac'
+and 'aclocal.m4'.  From the files 'configure.ac' and 'acconfig.h',
+Autoheader generates the file 'config.in'.  The file 'cstamp-h.in' is
+used as a timestamp.
+
+* Menu:
+
+* Config Fragments::     Scripts used by 'configure'.
+* System Config::        The 'config.build', 'config.host', and
+                         'config.gcc' files.
+* Configuration Files::  Files created by running 'configure'.
+
+
+File: gccint.info,  Node: Config Fragments,  Next: System Config,  Up: Configuration
+
+6.3.2.1 Scripts Used by 'configure'
+...................................
+
+'configure' uses some other scripts to help in its work:
+
+   * The standard GNU 'config.sub' and 'config.guess' files, kept in the
+     top level directory, are used.
+
+   * The file 'config.gcc' is used to handle configuration specific to
+     the particular target machine.  The file 'config.build' is used to
+     handle configuration specific to the particular build machine.  The
+     file 'config.host' is used to handle configuration specific to the
+     particular host machine.  (In general, these should only be used
+     for features that cannot reasonably be tested in Autoconf feature
+     tests.)  *Note The 'config.build'; 'config.host'; and 'config.gcc'
+     Files: System Config, for details of the contents of these files.
+
+   * Each language subdirectory has a file 'LANGUAGE/config-lang.in'
+     that is used for front-end-specific configuration.  *Note The Front
+     End 'config-lang.in' File: Front End Config, for details of this
+     file.
+
+   * A helper script 'configure.frag' is used as part of creating the
+     output of 'configure'.
+
+
+File: gccint.info,  Node: System Config,  Next: Configuration Files,  Prev: Config Fragments,  Up: Configuration
+
+6.3.2.2 The 'config.build'; 'config.host'; and 'config.gcc' Files
+.................................................................
+
+The 'config.build' file contains specific rules for particular systems
+which GCC is built on.  This should be used as rarely as possible, as
+the behavior of the build system can always be detected by autoconf.
+
+ The 'config.host' file contains specific rules for particular systems
+which GCC will run on.  This is rarely needed.
+
+ The 'config.gcc' file contains specific rules for particular systems
+which GCC will generate code for.  This is usually needed.
+
+ Each file has a list of the shell variables it sets, with descriptions,
+at the top of the file.
+
+ FIXME: document the contents of these files, and what variables should
+be set to control build, host and target configuration.
+
+
+File: gccint.info,  Node: Configuration Files,  Prev: System Config,  Up: Configuration
+
+6.3.2.3 Files Created by 'configure'
+....................................
+
+Here we spell out what files will be set up by 'configure' in the 'gcc'
+directory.  Some other files are created as temporary files in the
+configuration process, and are not used in the subsequent build; these
+are not documented.
+
+   * 'Makefile' is constructed from 'Makefile.in', together with the
+     host and target fragments (*note Makefile Fragments: Fragments.)
+     't-TARGET' and 'x-HOST' from 'config', if any, and language
+     Makefile fragments 'LANGUAGE/Make-lang.in'.
+   * 'auto-host.h' contains information about the host machine
+     determined by 'configure'.  If the host machine is different from
+     the build machine, then 'auto-build.h' is also created, containing
+     such information about the build machine.
+   * 'config.status' is a script that may be run to recreate the current
+     configuration.
+   * 'configargs.h' is a header containing details of the arguments
+     passed to 'configure' to configure GCC, and of the thread model
+     used.
+   * 'cstamp-h' is used as a timestamp.
+   * If a language 'config-lang.in' file (*note The Front End
+     'config-lang.in' File: Front End Config.) sets 'outputs', then the
+     files listed in 'outputs' there are also generated.
+
+ The following configuration headers are created from the Makefile,
+using 'mkconfig.sh', rather than directly by 'configure'.  'config.h',
+'bconfig.h' and 'tconfig.h' all contain the 'xm-MACHINE.h' header, if
+any, appropriate to the host, build and target machines respectively,
+the configuration headers for the target, and some definitions; for the
+host and build machines, these include the autoconfigured headers
+generated by 'configure'.  The other configuration headers are
+determined by 'config.gcc'.  They also contain the typedefs for 'rtx',
+'rtvec' and 'tree'.
+
+   * 'config.h', for use in programs that run on the host machine.
+   * 'bconfig.h', for use in programs that run on the build machine.
+   * 'tconfig.h', for use in programs and libraries for the target
+     machine.
+   * 'tm_p.h', which includes the header 'MACHINE-protos.h' that
+     contains prototypes for functions in the target 'MACHINE.c' file.
+     The header 'MACHINE-protos.h' can include prototypes of functions
+     that use rtl and tree data structures inside appropriate '#ifdef
+     RTX_CODE' and '#ifdef TREE_CODE' conditional code segements.  The
+     'MACHINE-protos.h' is included after the 'rtl.h' and/or 'tree.h'
+     would have been included.  The 'tm_p.h' also includes the header
+     'tm-preds.h' which is generated by 'genpreds' program during the
+     build to define the declarations and inline functions for the
+     predicate functions.
+
+
+File: gccint.info,  Node: Build,  Next: Makefile,  Prev: Configuration,  Up: gcc Directory
+
+6.3.3 Build System in the 'gcc' Directory
+-----------------------------------------
+
+FIXME: describe the build system, including what is built in what
+stages.  Also list the various source files that are used in the build
+process but aren't source files of GCC itself and so aren't documented
+below (*note Passes::).
+
+
+File: gccint.info,  Node: Makefile,  Next: Library Files,  Prev: Build,  Up: gcc Directory
+
+6.3.4 Makefile Targets
+----------------------
+
+These targets are available from the 'gcc' directory:
+
+'all'
+     This is the default target.  Depending on what your
+     build/host/target configuration is, it coordinates all the things
+     that need to be built.
+
+'doc'
+     Produce info-formatted documentation and man pages.  Essentially it
+     calls 'make man' and 'make info'.
+
+'dvi'
+     Produce DVI-formatted documentation.
+
+'pdf'
+     Produce PDF-formatted documentation.
+
+'html'
+     Produce HTML-formatted documentation.
+
+'man'
+     Generate man pages.
+
+'info'
+     Generate info-formatted pages.
+
+'mostlyclean'
+     Delete the files made while building the compiler.
+
+'clean'
+     That, and all the other files built by 'make all'.
+
+'distclean'
+     That, and all the files created by 'configure'.
+
+'maintainer-clean'
+     Distclean plus any file that can be generated from other files.
+     Note that additional tools may be required beyond what is normally
+     needed to build GCC.
+
+'srcextra'
+     Generates files in the source directory that are not
+     version-controlled but should go into a release tarball.
+
+'srcinfo'
+'srcman'
+     Copies the info-formatted and manpage documentation into the source
+     directory usually for the purpose of generating a release tarball.
+
+'install'
+     Installs GCC.
+
+'uninstall'
+     Deletes installed files, though this is not supported.
+
+'check'
+     Run the testsuite.  This creates a 'testsuite' subdirectory that
+     has various '.sum' and '.log' files containing the results of the
+     testing.  You can run subsets with, for example, 'make check-gcc'.
+     You can specify specific tests by setting 'RUNTESTFLAGS' to be the
+     name of the '.exp' file, optionally followed by (for some tests) an
+     equals and a file wildcard, like:
+
+          make check-gcc RUNTESTFLAGS="execute.exp=19980413-*"
+
+     Note that running the testsuite may require additional tools be
+     installed, such as Tcl or DejaGnu.
+
+ The toplevel tree from which you start GCC compilation is not the GCC
+directory, but rather a complex Makefile that coordinates the various
+steps of the build, including bootstrapping the compiler and using the
+new compiler to build target libraries.
+
+ When GCC is configured for a native configuration, the default action
+for 'make' is to do a full three-stage bootstrap.  This means that GCC
+is built three times--once with the native compiler, once with the
+native-built compiler it just built, and once with the compiler it built
+the second time.  In theory, the last two should produce the same
+results, which 'make compare' can check.  Each stage is configured
+separately and compiled into a separate directory, to minimize problems
+due to ABI incompatibilities between the native compiler and GCC.
+
+ If you do a change, rebuilding will also start from the first stage and
+"bubble" up the change through the three stages.  Each stage is taken
+from its build directory (if it had been built previously), rebuilt, and
+copied to its subdirectory.  This will allow you to, for example,
+continue a bootstrap after fixing a bug which causes the stage2 build to
+crash.  It does not provide as good coverage of the compiler as
+bootstrapping from scratch, but it ensures that the new code is
+syntactically correct (e.g., that you did not use GCC extensions by
+mistake), and avoids spurious bootstrap comparison failures(1).
+
+ Other targets available from the top level include:
+
+'bootstrap-lean'
+     Like 'bootstrap', except that the various stages are removed once
+     they're no longer needed.  This saves disk space.
+
+'bootstrap2'
+'bootstrap2-lean'
+     Performs only the first two stages of bootstrap.  Unlike a
+     three-stage bootstrap, this does not perform a comparison to test
+     that the compiler is running properly.  Note that the disk space
+     required by a "lean" bootstrap is approximately independent of the
+     number of stages.
+
+'stageN-bubble (N = 1...4, profile, feedback)'
+     Rebuild all the stages up to N, with the appropriate flags,
+     "bubbling" the changes as described above.
+
+'all-stageN (N = 1...4, profile, feedback)'
+     Assuming that stage N has already been built, rebuild it with the
+     appropriate flags.  This is rarely needed.
+
+'cleanstrap'
+     Remove everything ('make clean') and rebuilds ('make bootstrap').
+
+'compare'
+     Compares the results of stages 2 and 3.  This ensures that the
+     compiler is running properly, since it should produce the same
+     object files regardless of how it itself was compiled.
+
+'profiledbootstrap'
+     Builds a compiler with profiling feedback information.  In this
+     case, the second and third stages are named 'profile' and
+     'feedback', respectively.  For more information, see *note Building
+     with profile feedback: (gccinstall)Building.
+
+'restrap'
+     Restart a bootstrap, so that everything that was not built with the
+     system compiler is rebuilt.
+
+'stageN-start (N = 1...4, profile, feedback)'
+     For each package that is bootstrapped, rename directories so that,
+     for example, 'gcc' points to the stageN GCC, compiled with the
+     stageN-1 GCC(2).
+
+     You will invoke this target if you need to test or debug the stageN
+     GCC.  If you only need to execute GCC (but you need not run 'make'
+     either to rebuild it or to run test suites), you should be able to
+     work directly in the 'stageN-gcc' directory.  This makes it easier
+     to debug multiple stages in parallel.
+
+'stage'
+     For each package that is bootstrapped, relocate its build directory
+     to indicate its stage.  For example, if the 'gcc' directory points
+     to the stage2 GCC, after invoking this target it will be renamed to
+     'stage2-gcc'.
+
+ If you wish to use non-default GCC flags when compiling the stage2 and
+stage3 compilers, set 'BOOT_CFLAGS' on the command line when doing
+'make'.
+
+ Usually, the first stage only builds the languages that the compiler is
+written in: typically, C and maybe Ada.  If you are debugging a
+miscompilation of a different stage2 front-end (for example, of the
+Fortran front-end), you may want to have front-ends for other languages
+in the first stage as well.  To do so, set 'STAGE1_LANGUAGES' on the
+command line when doing 'make'.
+
+ For example, in the aforementioned scenario of debugging a Fortran
+front-end miscompilation caused by the stage1 compiler, you may need a
+command like
+
+     make stage2-bubble STAGE1_LANGUAGES=c,fortran
+
+ Alternatively, you can use per-language targets to build and test
+languages that are not enabled by default in stage1.  For example, 'make
+f951' will build a Fortran compiler even in the stage1 build directory.
+
+   ---------- Footnotes ----------
+
+   (1) Except if the compiler was buggy and miscompiled some of the
+files that were not modified.  In this case, it's best to use 'make
+restrap'.
+
+   (2) Customarily, the system compiler is also termed the 'stage0' GCC.
+
+
+File: gccint.info,  Node: Library Files,  Next: Headers,  Prev: Makefile,  Up: gcc Directory
+
+6.3.5 Library Source Files and Headers under the 'gcc' Directory
+----------------------------------------------------------------
+
+FIXME: list here, with explanation, all the C source files and headers
+under the 'gcc' directory that aren't built into the GCC executable but
+rather are part of runtime libraries and object files, such as
+'crtstuff.c' and 'unwind-dw2.c'.  *Note Headers Installed by GCC:
+Headers, for more information about the 'ginclude' directory.
+
+
+File: gccint.info,  Node: Headers,  Next: Documentation,  Prev: Library Files,  Up: gcc Directory
+
+6.3.6 Headers Installed by GCC
+------------------------------
+
+In general, GCC expects the system C library to provide most of the
+headers to be used with it.  However, GCC will fix those headers if
+necessary to make them work with GCC, and will install some headers
+required of freestanding implementations.  These headers are installed
+in 'LIBSUBDIR/include'.  Headers for non-C runtime libraries are also
+installed by GCC; these are not documented here.  (FIXME: document them
+somewhere.)
+
+ Several of the headers GCC installs are in the 'ginclude' directory.
+These headers, 'iso646.h', 'stdarg.h', 'stdbool.h', and 'stddef.h', are
+installed in 'LIBSUBDIR/include', unless the target Makefile fragment
+(*note Target Fragment::) overrides this by setting 'USER_H'.
+
+ In addition to these headers and those generated by fixing system
+headers to work with GCC, some other headers may also be installed in
+'LIBSUBDIR/include'.  'config.gcc' may set 'extra_headers'; this
+specifies additional headers under 'config' to be installed on some
+systems.
+
+ GCC installs its own version of '<float.h>', from 'ginclude/float.h'.
+This is done to cope with command-line options that change the
+representation of floating point numbers.
+
+ GCC also installs its own version of '<limits.h>'; this is generated
+from 'glimits.h', together with 'limitx.h' and 'limity.h' if the system
+also has its own version of '<limits.h>'.  (GCC provides its own header
+because it is required of ISO C freestanding implementations, but needs
+to include the system header from its own header as well because other
+standards such as POSIX specify additional values to be defined in
+'<limits.h>'.)  The system's '<limits.h>' header is used via
+'LIBSUBDIR/include/syslimits.h', which is copied from 'gsyslimits.h' if
+it does not need fixing to work with GCC; if it needs fixing,
+'syslimits.h' is the fixed copy.
+
+ GCC can also install '<tgmath.h>'.  It will do this when 'config.gcc'
+sets 'use_gcc_tgmath' to 'yes'.
+
+
+File: gccint.info,  Node: Documentation,  Next: Front End,  Prev: Headers,  Up: gcc Directory
+
+6.3.7 Building Documentation
+----------------------------
+
+The main GCC documentation is in the form of manuals in Texinfo format.
+These are installed in Info format; DVI versions may be generated by
+'make dvi', PDF versions by 'make pdf', and HTML versions by 'make
+html'.  In addition, some man pages are generated from the Texinfo
+manuals, there are some other text files with miscellaneous
+documentation, and runtime libraries have their own documentation
+outside the 'gcc' directory.  FIXME: document the documentation for
+runtime libraries somewhere.
+
+* Menu:
+
+* Texinfo Manuals::      GCC manuals in Texinfo format.
+* Man Page Generation::  Generating man pages from Texinfo manuals.
+* Miscellaneous Docs::   Miscellaneous text files with documentation.
+
+
+File: gccint.info,  Node: Texinfo Manuals,  Next: Man Page Generation,  Up: Documentation
+
+6.3.7.1 Texinfo Manuals
+.......................
+
+The manuals for GCC as a whole, and the C and C++ front ends, are in
+files 'doc/*.texi'.  Other front ends have their own manuals in files
+'LANGUAGE/*.texi'.  Common files 'doc/include/*.texi' are provided which
+may be included in multiple manuals; the following files are in
+'doc/include':
+
+'fdl.texi'
+     The GNU Free Documentation License.
+'funding.texi'
+     The section "Funding Free Software".
+'gcc-common.texi'
+     Common definitions for manuals.
+'gpl_v3.texi'
+     The GNU General Public License.
+'texinfo.tex'
+     A copy of 'texinfo.tex' known to work with the GCC manuals.
+
+ DVI-formatted manuals are generated by 'make dvi', which uses
+'texi2dvi' (via the Makefile macro '$(TEXI2DVI)').  PDF-formatted
+manuals are generated by 'make pdf', which uses 'texi2pdf' (via the
+Makefile macro '$(TEXI2PDF)').  HTML formatted manuals are generated by
+'make html'.  Info manuals are generated by 'make info' (which is run as
+part of a bootstrap); this generates the manuals in the source
+directory, using 'makeinfo' via the Makefile macro '$(MAKEINFO)', and
+they are included in release distributions.
+
+ Manuals are also provided on the GCC web site, in both HTML and
+PostScript forms.  This is done via the script
+'maintainer-scripts/update_web_docs_svn'.  Each manual to be provided
+online must be listed in the definition of 'MANUALS' in that file; a
+file 'NAME.texi' must only appear once in the source tree, and the
+output manual must have the same name as the source file.  (However,
+other Texinfo files, included in manuals but not themselves the root
+files of manuals, may have names that appear more than once in the
+source tree.)  The manual file 'NAME.texi' should only include other
+files in its own directory or in 'doc/include'.  HTML manuals will be
+generated by 'makeinfo --html', PostScript manuals by 'texi2dvi' and
+'dvips', and PDF manuals by 'texi2pdf'.  All Texinfo files that are
+parts of manuals must be version-controlled, even if they are generated
+files, for the generation of online manuals to work.
+
+ The installation manual, 'doc/install.texi', is also provided on the
+GCC web site.  The HTML version is generated by the script
+'doc/install.texi2html'.
+
+
+File: gccint.info,  Node: Man Page Generation,  Next: Miscellaneous Docs,  Prev: Texinfo Manuals,  Up: Documentation
+
+6.3.7.2 Man Page Generation
+...........................
+
+Because of user demand, in addition to full Texinfo manuals, man pages
+are provided which contain extracts from those manuals.  These man pages
+are generated from the Texinfo manuals using 'contrib/texi2pod.pl' and
+'pod2man'.  (The man page for 'g++', 'cp/g++.1', just contains a '.so'
+reference to 'gcc.1', but all the other man pages are generated from
+Texinfo manuals.)
+
+ Because many systems may not have the necessary tools installed to
+generate the man pages, they are only generated if the 'configure'
+script detects that recent enough tools are installed, and the Makefiles
+allow generating man pages to fail without aborting the build.  Man
+pages are also included in release distributions.  They are generated in
+the source directory.
+
+ Magic comments in Texinfo files starting '@c man' control what parts of
+a Texinfo file go into a man page.  Only a subset of Texinfo is
+supported by 'texi2pod.pl', and it may be necessary to add support for
+more Texinfo features to this script when generating new man pages.  To
+improve the man page output, some special Texinfo macros are provided in
+'doc/include/gcc-common.texi' which 'texi2pod.pl' understands:
+
+'@gcctabopt'
+     Use in the form '@table @gcctabopt' for tables of options, where
+     for printed output the effect of '@code' is better than that of
+     '@option' but for man page output a different effect is wanted.
+'@gccoptlist'
+     Use for summary lists of options in manuals.
+'@gol'
+     Use at the end of each line inside '@gccoptlist'.  This is
+     necessary to avoid problems with differences in how the
+     '@gccoptlist' macro is handled by different Texinfo formatters.
+
+ FIXME: describe the 'texi2pod.pl' input language and magic comments in
+more detail.
+
+
+File: gccint.info,  Node: Miscellaneous Docs,  Prev: Man Page Generation,  Up: Documentation
+
+6.3.7.3 Miscellaneous Documentation
+...................................
+
+In addition to the formal documentation that is installed by GCC, there
+are several other text files in the 'gcc' subdirectory with
+miscellaneous documentation:
+
+'ABOUT-GCC-NLS'
+     Notes on GCC's Native Language Support.  FIXME: this should be part
+     of this manual rather than a separate file.
+'ABOUT-NLS'
+     Notes on the Free Translation Project.
+'COPYING'
+'COPYING3'
+     The GNU General Public License, Versions 2 and 3.
+'COPYING.LIB'
+'COPYING3.LIB'
+     The GNU Lesser General Public License, Versions 2.1 and 3.
+'*ChangeLog*'
+'*/ChangeLog*'
+     Change log files for various parts of GCC.
+'LANGUAGES'
+     Details of a few changes to the GCC front-end interface.  FIXME:
+     the information in this file should be part of general
+     documentation of the front-end interface in this manual.
+'ONEWS'
+     Information about new features in old versions of GCC.  (For recent
+     versions, the information is on the GCC web site.)
+'README.Portability'
+     Information about portability issues when writing code in GCC.
+     FIXME: why isn't this part of this manual or of the GCC Coding
+     Conventions?
+
+ FIXME: document such files in subdirectories, at least 'config', 'c',
+'cp', 'objc', 'testsuite'.
+
+
+File: gccint.info,  Node: Front End,  Next: Back End,  Prev: Documentation,  Up: gcc Directory
+
+6.3.8 Anatomy of a Language Front End
+-------------------------------------
+
+A front end for a language in GCC has the following parts:
+
+   * A directory 'LANGUAGE' under 'gcc' containing source files for that
+     front end.  *Note The Front End 'LANGUAGE' Directory: Front End
+     Directory, for details.
+   * A mention of the language in the list of supported languages in
+     'gcc/doc/install.texi'.
+   * A mention of the name under which the language's runtime library is
+     recognized by '--enable-shared=PACKAGE' in the documentation of
+     that option in 'gcc/doc/install.texi'.
+   * A mention of any special prerequisites for building the front end
+     in the documentation of prerequisites in 'gcc/doc/install.texi'.
+   * Details of contributors to that front end in
+     'gcc/doc/contrib.texi'.  If the details are in that front end's own
+     manual then there should be a link to that manual's list in
+     'contrib.texi'.
+   * Information about support for that language in
+     'gcc/doc/frontends.texi'.
+   * Information about standards for that language, and the front end's
+     support for them, in 'gcc/doc/standards.texi'.  This may be a link
+     to such information in the front end's own manual.
+   * Details of source file suffixes for that language and '-x LANG'
+     options supported, in 'gcc/doc/invoke.texi'.
+   * Entries in 'default_compilers' in 'gcc.c' for source file suffixes
+     for that language.
+   * Preferably testsuites, which may be under 'gcc/testsuite' or
+     runtime library directories.  FIXME: document somewhere how to
+     write testsuite harnesses.
+   * Probably a runtime library for the language, outside the 'gcc'
+     directory.  FIXME: document this further.
+   * Details of the directories of any runtime libraries in
+     'gcc/doc/sourcebuild.texi'.
+   * Check targets in 'Makefile.def' for the top-level 'Makefile' to
+     check just the compiler or the compiler and runtime library for the
+     language.
+
+ If the front end is added to the official GCC source repository, the
+following are also necessary:
+
+   * At least one Bugzilla component for bugs in that front end and
+     runtime libraries.  This category needs to be added to the Bugzilla
+     database.
+   * Normally, one or more maintainers of that front end listed in
+     'MAINTAINERS'.
+   * Mentions on the GCC web site in 'index.html' and 'frontends.html',
+     with any relevant links on 'readings.html'.  (Front ends that are
+     not an official part of GCC may also be listed on 'frontends.html',
+     with relevant links.)
+   * A news item on 'index.html', and possibly an announcement on the
+     <gcc-announce@gcc.gnu.org> mailing list.
+   * The front end's manuals should be mentioned in
+     'maintainer-scripts/update_web_docs_svn' (*note Texinfo Manuals::)
+     and the online manuals should be linked to from
+     'onlinedocs/index.html'.
+   * Any old releases or CVS repositories of the front end, before its
+     inclusion in GCC, should be made available on the GCC FTP site
+     <ftp://gcc.gnu.org/pub/gcc/old-releases/>.
+   * The release and snapshot script 'maintainer-scripts/gcc_release'
+     should be updated to generate appropriate tarballs for this front
+     end.
+   * If this front end includes its own version files that include the
+     current date, 'maintainer-scripts/update_version' should be updated
+     accordingly.
+
+* Menu:
+
+* Front End Directory::  The front end 'LANGUAGE' directory.
+* Front End Config::     The front end 'config-lang.in' file.
+* Front End Makefile::   The front end 'Make-lang.in' file.
+
+
+File: gccint.info,  Node: Front End Directory,  Next: Front End Config,  Up: Front End
+
+6.3.8.1 The Front End 'LANGUAGE' Directory
+..........................................
+
+A front end 'LANGUAGE' directory contains the source files of that front
+end (but not of any runtime libraries, which should be outside the 'gcc'
+directory).  This includes documentation, and possibly some subsidiary
+programs built alongside the front end.  Certain files are special and
+other parts of the compiler depend on their names:
+
+'config-lang.in'
+     This file is required in all language subdirectories.  *Note The
+     Front End 'config-lang.in' File: Front End Config, for details of
+     its contents
+'Make-lang.in'
+     This file is required in all language subdirectories.  *Note The
+     Front End 'Make-lang.in' File: Front End Makefile, for details of
+     its contents.
+'lang.opt'
+     This file registers the set of switches that the front end accepts
+     on the command line, and their '--help' text.  *Note Options::.
+'lang-specs.h'
+     This file provides entries for 'default_compilers' in 'gcc.c' which
+     override the default of giving an error that a compiler for that
+     language is not installed.
+'LANGUAGE-tree.def'
+     This file, which need not exist, defines any language-specific tree
+     codes.
+
+
+File: gccint.info,  Node: Front End Config,  Next: Front End Makefile,  Prev: Front End Directory,  Up: Front End
+
+6.3.8.2 The Front End 'config-lang.in' File
+...........................................
+
+Each language subdirectory contains a 'config-lang.in' file.  This file
+is a shell script that may define some variables describing the
+language:
+
+'language'
+     This definition must be present, and gives the name of the language
+     for some purposes such as arguments to '--enable-languages'.
+'lang_requires'
+     If defined, this variable lists (space-separated) language front
+     ends other than C that this front end requires to be enabled (with
+     the names given being their 'language' settings).  For example, the
+     Java front end depends on the C++ front end, so sets
+     'lang_requires=c++'.
+'subdir_requires'
+     If defined, this variable lists (space-separated) front end
+     directories other than C that this front end requires to be
+     present.  For example, the Objective-C++ front end uses source
+     files from the C++ and Objective-C front ends, so sets
+     'subdir_requires="cp objc"'.
+'target_libs'
+     If defined, this variable lists (space-separated) targets in the
+     top level 'Makefile' to build the runtime libraries for this
+     language, such as 'target-libobjc'.
+'lang_dirs'
+     If defined, this variable lists (space-separated) top level
+     directories (parallel to 'gcc'), apart from the runtime libraries,
+     that should not be configured if this front end is not built.
+'build_by_default'
+     If defined to 'no', this language front end is not built unless
+     enabled in a '--enable-languages' argument.  Otherwise, front ends
+     are built by default, subject to any special logic in
+     'configure.ac' (as is present to disable the Ada front end if the
+     Ada compiler is not already installed).
+'boot_language'
+     If defined to 'yes', this front end is built in stage1 of the
+     bootstrap.  This is only relevant to front ends written in their
+     own languages.
+'compilers'
+     If defined, a space-separated list of compiler executables that
+     will be run by the driver.  The names here will each end with
+     '\$(exeext)'.
+'outputs'
+     If defined, a space-separated list of files that should be
+     generated by 'configure' substituting values in them.  This
+     mechanism can be used to create a file 'LANGUAGE/Makefile' from
+     'LANGUAGE/Makefile.in', but this is deprecated, building everything
+     from the single 'gcc/Makefile' is preferred.
+'gtfiles'
+     If defined, a space-separated list of files that should be scanned
+     by 'gengtype.c' to generate the garbage collection tables and
+     routines for this language.  This excludes the files that are
+     common to all front ends.  *Note Type Information::.
+
+
+File: gccint.info,  Node: Front End Makefile,  Prev: Front End Config,  Up: Front End
+
+6.3.8.3 The Front End 'Make-lang.in' File
+.........................................
+
+Each language subdirectory contains a 'Make-lang.in' file.  It contains
+targets 'LANG.HOOK' (where 'LANG' is the setting of 'language' in
+'config-lang.in') for the following values of 'HOOK', and any other
+Makefile rules required to build those targets (which may if necessary
+use other Makefiles specified in 'outputs' in 'config-lang.in', although
+this is deprecated).  It also adds any testsuite targets that can use
+the standard rule in 'gcc/Makefile.in' to the variable 'lang_checks'.
+
+'all.cross'
+'start.encap'
+'rest.encap'
+     FIXME: exactly what goes in each of these targets?
+'tags'
+     Build an 'etags' 'TAGS' file in the language subdirectory in the
+     source tree.
+'info'
+     Build info documentation for the front end, in the build directory.
+     This target is only called by 'make bootstrap' if a suitable
+     version of 'makeinfo' is available, so does not need to check for
+     this, and should fail if an error occurs.
+'dvi'
+     Build DVI documentation for the front end, in the build directory.
+     This should be done using '$(TEXI2DVI)', with appropriate '-I'
+     arguments pointing to directories of included files.
+'pdf'
+     Build PDF documentation for the front end, in the build directory.
+     This should be done using '$(TEXI2PDF)', with appropriate '-I'
+     arguments pointing to directories of included files.
+'html'
+     Build HTML documentation for the front end, in the build directory.
+'man'
+     Build generated man pages for the front end from Texinfo manuals
+     (*note Man Page Generation::), in the build directory.  This target
+     is only called if the necessary tools are available, but should
+     ignore errors so as not to stop the build if errors occur; man
+     pages are optional and the tools involved may be installed in a
+     broken way.
+'install-common'
+     Install everything that is part of the front end, apart from the
+     compiler executables listed in 'compilers' in 'config-lang.in'.
+'install-info'
+     Install info documentation for the front end, if it is present in
+     the source directory.  This target should have dependencies on info
+     files that should be installed.
+'install-man'
+     Install man pages for the front end.  This target should ignore
+     errors.
+'install-plugin'
+     Install headers needed for plugins.
+'srcextra'
+     Copies its dependencies into the source directory.  This generally
+     should be used for generated files such as Bison output files which
+     are not version-controlled, but should be included in any release
+     tarballs.  This target will be executed during a bootstrap if
+     '--enable-generated-files-in-srcdir' was specified as a 'configure'
+     option.
+'srcinfo'
+'srcman'
+     Copies its dependencies into the source directory.  These targets
+     will be executed during a bootstrap if
+     '--enable-generated-files-in-srcdir' was specified as a 'configure'
+     option.
+'uninstall'
+     Uninstall files installed by installing the compiler.  This is
+     currently documented not to be supported, so the hook need not do
+     anything.
+'mostlyclean'
+'clean'
+'distclean'
+'maintainer-clean'
+     The language parts of the standard GNU '*clean' targets.  *Note
+     Standard Targets for Users: (standards)Standard Targets, for
+     details of the standard targets.  For GCC, 'maintainer-clean'
+     should delete all generated files in the source directory that are
+     not version-controlled, but should not delete anything that is.
+
+ 'Make-lang.in' must also define a variable 'LANG_OBJS' to a list of
+host object files that are used by that language.
+
+
+File: gccint.info,  Node: Back End,  Prev: Front End,  Up: gcc Directory
+
+6.3.9 Anatomy of a Target Back End
+----------------------------------
+
+A back end for a target architecture in GCC has the following parts:
+
+   * A directory 'MACHINE' under 'gcc/config', containing a machine
+     description 'MACHINE.md' file (*note Machine Descriptions: Machine
+     Desc.), header files 'MACHINE.h' and 'MACHINE-protos.h' and a
+     source file 'MACHINE.c' (*note Target Description Macros and
+     Functions: Target Macros.), possibly a target Makefile fragment
+     't-MACHINE' (*note The Target Makefile Fragment: Target Fragment.),
+     and maybe some other files.  The names of these files may be
+     changed from the defaults given by explicit specifications in
+     'config.gcc'.
+   * If necessary, a file 'MACHINE-modes.def' in the 'MACHINE'
+     directory, containing additional machine modes to represent
+     condition codes.  *Note Condition Code::, for further details.
+   * An optional 'MACHINE.opt' file in the 'MACHINE' directory,
+     containing a list of target-specific options.  You can also add
+     other option files using the 'extra_options' variable in
+     'config.gcc'.  *Note Options::.
+   * Entries in 'config.gcc' (*note The 'config.gcc' File: System
+     Config.) for the systems with this target architecture.
+   * Documentation in 'gcc/doc/invoke.texi' for any command-line options
+     supported by this target (*note Run-time Target Specification:
+     Run-time Target.).  This means both entries in the summary table of
+     options and details of the individual options.
+   * Documentation in 'gcc/doc/extend.texi' for any target-specific
+     attributes supported (*note Defining target-specific uses of
+     '__attribute__': Target Attributes.), including where the same
+     attribute is already supported on some targets, which are
+     enumerated in the manual.
+   * Documentation in 'gcc/doc/extend.texi' for any target-specific
+     pragmas supported.
+   * Documentation in 'gcc/doc/extend.texi' of any target-specific
+     built-in functions supported.
+   * Documentation in 'gcc/doc/extend.texi' of any target-specific
+     format checking styles supported.
+   * Documentation in 'gcc/doc/md.texi' of any target-specific
+     constraint letters (*note Constraints for Particular Machines:
+     Machine Constraints.).
+   * A note in 'gcc/doc/contrib.texi' under the person or people who
+     contributed the target support.
+   * Entries in 'gcc/doc/install.texi' for all target triplets supported
+     with this target architecture, giving details of any special notes
+     about installation for this target, or saying that there are no
+     special notes if there are none.
+   * Possibly other support outside the 'gcc' directory for runtime
+     libraries.  FIXME: reference docs for this.  The 'libstdc++'
+     porting manual needs to be installed as info for this to work, or
+     to be a chapter of this manual.
+
+ If the back end is added to the official GCC source repository, the
+following are also necessary:
+
+   * An entry for the target architecture in 'readings.html' on the GCC
+     web site, with any relevant links.
+   * Details of the properties of the back end and target architecture
+     in 'backends.html' on the GCC web site.
+   * A news item about the contribution of support for that target
+     architecture, in 'index.html' on the GCC web site.
+   * Normally, one or more maintainers of that target listed in
+     'MAINTAINERS'.  Some existing architectures may be unmaintained,
+     but it would be unusual to add support for a target that does not
+     have a maintainer when support is added.
+   * Target triplets covering all 'config.gcc' stanzas for the target,
+     in the list in 'contrib/config-list.mk'.
+
+
+File: gccint.info,  Node: Testsuites,  Next: Options,  Prev: Source Tree,  Up: Top
+
+7 Testsuites
+************
+
+GCC contains several testsuites to help maintain compiler quality.  Most
+of the runtime libraries and language front ends in GCC have testsuites.
+Currently only the C language testsuites are documented here; FIXME:
+document the others.
+
+* Menu:
+
+* Test Idioms::     Idioms used in testsuite code.
+* Test Directives:: Directives used within DejaGnu tests.
+* Ada Tests::       The Ada language testsuites.
+* C Tests::         The C language testsuites.
+* libgcj Tests::    The Java library testsuites.
+* LTO Testing::     Support for testing link-time optimizations.
+* gcov Testing::    Support for testing gcov.
+* profopt Testing:: Support for testing profile-directed optimizations.
+* compat Testing::  Support for testing binary compatibility.
+* Torture Tests::   Support for torture testing using multiple options.
+
+
+File: gccint.info,  Node: Test Idioms,  Next: Test Directives,  Up: Testsuites
+
+7.1 Idioms Used in Testsuite Code
+=================================
+
+In general, C testcases have a trailing '-N.c', starting with '-1.c', in
+case other testcases with similar names are added later.  If the test is
+a test of some well-defined feature, it should have a name referring to
+that feature such as 'FEATURE-1.c'.  If it does not test a well-defined
+feature but just happens to exercise a bug somewhere in the compiler,
+and a bug report has been filed for this bug in the GCC bug database,
+'prBUG-NUMBER-1.c' is the appropriate form of name.  Otherwise (for
+miscellaneous bugs not filed in the GCC bug database), and previously
+more generally, test cases are named after the date on which they were
+added.  This allows people to tell at a glance whether a test failure is
+because of a recently found bug that has not yet been fixed, or whether
+it may be a regression, but does not give any other information about
+the bug or where discussion of it may be found.  Some other language
+testsuites follow similar conventions.
+
+ In the 'gcc.dg' testsuite, it is often necessary to test that an error
+is indeed a hard error and not just a warning--for example, where it is
+a constraint violation in the C standard, which must become an error
+with '-pedantic-errors'.  The following idiom, where the first line
+shown is line LINE of the file and the line that generates the error, is
+used for this:
+
+     /* { dg-bogus "warning" "warning in place of error" } */
+     /* { dg-error "REGEXP" "MESSAGE" { target *-*-* } LINE } */
+
+ It may be necessary to check that an expression is an integer constant
+expression and has a certain value.  To check that 'E' has value 'V', an
+idiom similar to the following is used:
+
+     char x[((E) == (V) ? 1 : -1)];
+
+ In 'gcc.dg' tests, '__typeof__' is sometimes used to make assertions
+about the types of expressions.  See, for example,
+'gcc.dg/c99-condexpr-1.c'.  The more subtle uses depend on the exact
+rules for the types of conditional expressions in the C standard; see,
+for example, 'gcc.dg/c99-intconst-1.c'.
+
+ It is useful to be able to test that optimizations are being made
+properly.  This cannot be done in all cases, but it can be done where
+the optimization will lead to code being optimized away (for example,
+where flow analysis or alias analysis should show that certain code
+cannot be called) or to functions not being called because they have
+been expanded as built-in functions.  Such tests go in
+'gcc.c-torture/execute'.  Where code should be optimized away, a call to
+a nonexistent function such as 'link_failure ()' may be inserted; a
+definition
+
+     #ifndef __OPTIMIZE__
+     void
+     link_failure (void)
+     {
+       abort ();
+     }
+     #endif
+
+will also be needed so that linking still succeeds when the test is run
+without optimization.  When all calls to a built-in function should have
+been optimized and no calls to the non-built-in version of the function
+should remain, that function may be defined as 'static' to call 'abort
+()' (although redeclaring a function as static may not work on all
+targets).
+
+ All testcases must be portable.  Target-specific testcases must have
+appropriate code to avoid causing failures on unsupported systems;
+unfortunately, the mechanisms for this differ by directory.
+
+ FIXME: discuss non-C testsuites here.
+
+
+File: gccint.info,  Node: Test Directives,  Next: Ada Tests,  Prev: Test Idioms,  Up: Testsuites
+
+7.2 Directives used within DejaGnu tests
+========================================
+
+* Menu:
+
+* Directives::  Syntax and descriptions of test directives.
+* Selectors:: Selecting targets to which a test applies.
+* Effective-Target Keywords:: Keywords describing target attributes.
+* Add Options:: Features for 'dg-add-options'
+* Require Support:: Variants of 'dg-require-SUPPORT'
+* Final Actions:: Commands for use in 'dg-final'
+
+
+File: gccint.info,  Node: Directives,  Next: Selectors,  Up: Test Directives
+
+7.2.1 Syntax and Descriptions of test directives
+------------------------------------------------
+
+Test directives appear within comments in a test source file and begin
+with 'dg-'.  Some of these are defined within DejaGnu and others are
+local to the GCC testsuite.
+
+ The order in which test directives appear in a test can be important:
+directives local to GCC sometimes override information used by the
+DejaGnu directives, which know nothing about the GCC directives, so the
+DejaGnu directives must precede GCC directives.
+
+ Several test directives include selectors (*note Selectors::) which are
+usually preceded by the keyword 'target' or 'xfail'.
+
+7.2.1.1 Specify how to build the test
+.....................................
+
+'{ dg-do DO-WHAT-KEYWORD [{ target/xfail SELECTOR }] }'
+     DO-WHAT-KEYWORD specifies how the test is compiled and whether it
+     is executed.  It is one of:
+
+     'preprocess'
+          Compile with '-E' to run only the preprocessor.
+     'compile'
+          Compile with '-S' to produce an assembly code file.
+     'assemble'
+          Compile with '-c' to produce a relocatable object file.
+     'link'
+          Compile, assemble, and link to produce an executable file.
+     'run'
+          Produce and run an executable file, which is expected to
+          return an exit code of 0.
+
+     The default is 'compile'.  That can be overridden for a set of
+     tests by redefining 'dg-do-what-default' within the '.exp' file for
+     those tests.
+
+     If the directive includes the optional '{ target SELECTOR }' then
+     the test is skipped unless the target system matches the SELECTOR.
+
+     If DO-WHAT-KEYWORD is 'run' and the directive includes the optional
+     '{ xfail SELECTOR }' and the selector is met then the test is
+     expected to fail.  The 'xfail' clause is ignored for other values
+     of DO-WHAT-KEYWORD; those tests can use directive 'dg-xfail-if'.
+
+7.2.1.2 Specify additional compiler options
+...........................................
+
+'{ dg-options OPTIONS [{ target SELECTOR }] }'
+     This DejaGnu directive provides a list of compiler options, to be
+     used if the target system matches SELECTOR, that replace the
+     default options used for this set of tests.
+
+'{ dg-add-options FEATURE ... }'
+     Add any compiler options that are needed to access certain
+     features.  This directive does nothing on targets that enable the
+     features by default, or that don't provide them at all.  It must
+     come after all 'dg-options' directives.  For supported values of
+     FEATURE see *note Add Options::.
+
+'{ dg-additional-options OPTIONS [{ target SELECTOR }] }'
+     This directive provides a list of compiler options, to be used if
+     the target system matches SELECTOR, that are added to the default
+     options used for this set of tests.
+
+7.2.1.3 Modify the test timeout value
+.....................................
+
+The normal timeout limit, in seconds, is found by searching the
+following in order:
+
+   * the value defined by an earlier 'dg-timeout' directive in the test
+
+   * variable TOOL_TIMEOUT defined by the set of tests
+
+   * GCC,TIMEOUT set in the target board
+
+   * 300
+
+'{ dg-timeout N [{target SELECTOR }] }'
+     Set the time limit for the compilation and for the execution of the
+     test to the specified number of seconds.
+
+'{ dg-timeout-factor X [{ target SELECTOR }] }'
+     Multiply the normal time limit for compilation and execution of the
+     test by the specified floating-point factor.
+
+7.2.1.4 Skip a test for some targets
+....................................
+
+'{ dg-skip-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
+     Arguments INCLUDE-OPTS and EXCLUDE-OPTS are lists in which each
+     element is a string of zero or more GCC options.  Skip the test if
+     all of the following conditions are met:
+        * the test system is included in SELECTOR
+
+        * for at least one of the option strings in INCLUDE-OPTS, every
+          option from that string is in the set of options with which
+          the test would be compiled; use '"*"' for an INCLUDE-OPTS list
+          that matches any options; that is the default if INCLUDE-OPTS
+          is not specified
+
+        * for each of the option strings in EXCLUDE-OPTS, at least one
+          option from that string is not in the set of options with
+          which the test would be compiled; use '""' for an empty
+          EXCLUDE-OPTS list; that is the default if EXCLUDE-OPTS is not
+          specified
+
+     For example, to skip a test if option '-Os' is present:
+
+          /* { dg-skip-if "" { *-*-* }  { "-Os" } { "" } } */
+
+     To skip a test if both options '-O2' and '-g' are present:
+
+          /* { dg-skip-if "" { *-*-* }  { "-O2 -g" } { "" } } */
+
+     To skip a test if either '-O2' or '-O3' is present:
+
+          /* { dg-skip-if "" { *-*-* }  { "-O2" "-O3" } { "" } } */
+
+     To skip a test unless option '-Os' is present:
+
+          /* { dg-skip-if "" { *-*-* }  { "*" } { "-Os" } } */
+
+     To skip a test if either '-O2' or '-O3' is used with '-g' but not
+     if '-fpic' is also present:
+
+          /* { dg-skip-if "" { *-*-* }  { "-O2 -g" "-O3 -g" } { "-fpic" } } */
+
+'{ dg-require-effective-target KEYWORD [{ SELECTOR }] }'
+     Skip the test if the test target, including current multilib flags,
+     is not covered by the effective-target keyword.  If the directive
+     includes the optional '{ SELECTOR }' then the effective-target test
+     is only performed if the target system matches the SELECTOR.  This
+     directive must appear after any 'dg-do' directive in the test and
+     before any 'dg-additional-sources' directive.  *Note
+     Effective-Target Keywords::.
+
+'{ dg-require-SUPPORT args }'
+     Skip the test if the target does not provide the required support.
+     These directives must appear after any 'dg-do' directive in the
+     test and before any 'dg-additional-sources' directive.  They
+     require at least one argument, which can be an empty string if the
+     specific procedure does not examine the argument.  *Note Require
+     Support::, for a complete list of these directives.
+
+7.2.1.5 Expect a test to fail for some targets
+..............................................
+
+'{ dg-xfail-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
+     Expect the test to fail if the conditions (which are the same as
+     for 'dg-skip-if') are met.  This does not affect the execute step.
+
+'{ dg-xfail-run-if COMMENT { SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]] }'
+     Expect the execute step of a test to fail if the conditions (which
+     are the same as for 'dg-skip-if') are met.
+
+7.2.1.6 Expect the test executable to fail
+..........................................
+
+'{ dg-shouldfail COMMENT [{ SELECTOR } [{ INCLUDE-OPTS } [{ EXCLUDE-OPTS }]]] }'
+     Expect the test executable to return a nonzero exit status if the
+     conditions (which are the same as for 'dg-skip-if') are met.
+
+7.2.1.7 Verify compiler messages
+................................
+
+'{ dg-error REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
+     This DejaGnu directive appears on a source line that is expected to
+     get an error message, or else specifies the source line associated
+     with the message.  If there is no message for that line or if the
+     text of that message is not matched by REGEXP then the check fails
+     and COMMENT is included in the 'FAIL' message.  The check does not
+     look for the string 'error' unless it is part of REGEXP.
+
+'{ dg-warning REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
+     This DejaGnu directive appears on a source line that is expected to
+     get a warning message, or else specifies the source line associated
+     with the message.  If there is no message for that line or if the
+     text of that message is not matched by REGEXP then the check fails
+     and COMMENT is included in the 'FAIL' message.  The check does not
+     look for the string 'warning' unless it is part of REGEXP.
+
+'{ dg-message REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
+     The line is expected to get a message other than an error or
+     warning.  If there is no message for that line or if the text of
+     that message is not matched by REGEXP then the check fails and
+     COMMENT is included in the 'FAIL' message.
+
+'{ dg-bogus REGEXP [COMMENT [{ target/xfail SELECTOR } [LINE] }]] }'
+     This DejaGnu directive appears on a source line that should not get
+     a message matching REGEXP, or else specifies the source line
+     associated with the bogus message.  It is usually used with 'xfail'
+     to indicate that the message is a known problem for a particular
+     set of targets.
+
+'{ dg-excess-errors COMMENT [{ target/xfail SELECTOR }] }'
+     This DejaGnu directive indicates that the test is expected to fail
+     due to compiler messages that are not handled by 'dg-error',
+     'dg-warning' or 'dg-bogus'.  For this directive 'xfail' has the
+     same effect as 'target'.
+
+'{ dg-prune-output REGEXP }'
+     Prune messages matching REGEXP from the test output.
+
+7.2.1.8 Verify output of the test executable
+............................................
+
+'{ dg-output REGEXP [{ target/xfail SELECTOR }] }'
+     This DejaGnu directive compares REGEXP to the combined output that
+     the test executable writes to 'stdout' and 'stderr'.
+
+7.2.1.9 Specify additional files for a test
+...........................................
+
+'{ dg-additional-files "FILELIST" }'
+     Specify additional files, other than source files, that must be
+     copied to the system where the compiler runs.
+
+'{ dg-additional-sources "FILELIST" }'
+     Specify additional source files to appear in the compile line
+     following the main test file.
+
+7.2.1.10 Add checks at the end of a test
+........................................
+
+'{ dg-final { LOCAL-DIRECTIVE } }'
+     This DejaGnu directive is placed within a comment anywhere in the
+     source file and is processed after the test has been compiled and
+     run.  Multiple 'dg-final' commands are processed in the order in
+     which they appear in the source file.  *Note Final Actions::, for a
+     list of directives that can be used within 'dg-final'.
+
+
+File: gccint.info,  Node: Selectors,  Next: Effective-Target Keywords,  Prev: Directives,  Up: Test Directives
+
+7.2.2 Selecting targets to which a test applies
+-----------------------------------------------
+
+Several test directives include SELECTORs to limit the targets for which
+a test is run or to declare that a test is expected to fail on
+particular targets.
+
+ A selector is:
+   * one or more target triplets, possibly including wildcard
+     characters; use '*-*-*' to match any target
+   * a single effective-target keyword (*note Effective-Target
+     Keywords::)
+   * a logical expression
+
+ Depending on the context, the selector specifies whether a test is
+skipped and reported as unsupported or is expected to fail.  A context
+that allows either 'target' or 'xfail' also allows '{ target SELECTOR1
+xfail SELECTOR2 }' to skip the test for targets that don't match
+SELECTOR1 and the test to fail for targets that match SELECTOR2.
+
+ A selector expression appears within curly braces and uses a single
+logical operator: one of '!', '&&', or '||'.  An operand is another
+selector expression, an effective-target keyword, a single target
+triplet, or a list of target triplets within quotes or curly braces.
+For example:
+
+     { target { ! "hppa*-*-* ia64*-*-*" } }
+     { target { powerpc*-*-* && lp64 } }
+     { xfail { lp64 || vect_no_align } }
+
+
+File: gccint.info,  Node: Effective-Target Keywords,  Next: Add Options,  Prev: Selectors,  Up: Test Directives
+
+7.2.3 Keywords describing target attributes
+-------------------------------------------
+
+Effective-target keywords identify sets of targets that support
+particular functionality.  They are used to limit tests to be run only
+for particular targets, or to specify that particular sets of targets
+are expected to fail some tests.
+
+ Effective-target keywords are defined in 'lib/target-supports.exp' in
+the GCC testsuite, with the exception of those that are documented as
+being local to a particular test directory.
+
+ The 'effective target' takes into account all of the compiler options
+with which the test will be compiled, including the multilib options.
+By convention, keywords ending in '_nocache' can also include options
+specified for the particular test in an earlier 'dg-options' or
+'dg-add-options' directive.
+
+7.2.3.1 Data type sizes
+.......................
+
+'ilp32'
+     Target has 32-bit 'int', 'long', and pointers.
+
+'lp64'
+     Target has 32-bit 'int', 64-bit 'long' and pointers.
+
+'llp64'
+     Target has 32-bit 'int' and 'long', 64-bit 'long long' and
+     pointers.
+
+'double64'
+     Target has 64-bit 'double'.
+
+'double64plus'
+     Target has 'double' that is 64 bits or longer.
+
+'int32plus'
+     Target has 'int' that is at 32 bits or longer.
+
+'int16'
+     Target has 'int' that is 16 bits or shorter.
+
+'long_neq_int'
+     Target has 'int' and 'long' with different sizes.
+
+'large_double'
+     Target supports 'double' that is longer than 'float'.
+
+'large_long_double'
+     Target supports 'long double' that is longer than 'double'.
+
+'ptr32plus'
+     Target has pointers that are 32 bits or longer.
+
+'size32plus'
+     Target supports array and structure sizes that are 32 bits or
+     longer.
+
+'4byte_wchar_t'
+     Target has 'wchar_t' that is at least 4 bytes.
+
+7.2.3.2 Fortran-specific attributes
+...................................
+
+'fortran_integer_16'
+     Target supports Fortran 'integer' that is 16 bytes or longer.
+
+'fortran_large_int'
+     Target supports Fortran 'integer' kinds larger than 'integer(8)'.
+
+'fortran_large_real'
+     Target supports Fortran 'real' kinds larger than 'real(8)'.
+
+7.2.3.3 Vector-specific attributes
+..................................
+
+'vect_condition'
+     Target supports vector conditional operations.
+
+'vect_double'
+     Target supports hardware vectors of 'double'.
+
+'vect_float'
+     Target supports hardware vectors of 'float'.
+
+'vect_int'
+     Target supports hardware vectors of 'int'.
+
+'vect_long'
+     Target supports hardware vectors of 'long'.
+
+'vect_long_long'
+     Target supports hardware vectors of 'long long'.
+
+'vect_aligned_arrays'
+     Target aligns arrays to vector alignment boundary.
+
+'vect_hw_misalign'
+     Target supports a vector misalign access.
+
+'vect_no_align'
+     Target does not support a vector alignment mechanism.
+
+'vect_no_int_max'
+     Target does not support a vector max instruction on 'int'.
+
+'vect_no_int_add'
+     Target does not support a vector add instruction on 'int'.
+
+'vect_no_bitwise'
+     Target does not support vector bitwise instructions.
+
+'vect_char_mult'
+     Target supports 'vector char' multiplication.
+
+'vect_short_mult'
+     Target supports 'vector short' multiplication.
+
+'vect_int_mult'
+     Target supports 'vector int' multiplication.
+
+'vect_extract_even_odd'
+     Target supports vector even/odd element extraction.
+
+'vect_extract_even_odd_wide'
+     Target supports vector even/odd element extraction of vectors with
+     elements 'SImode' or larger.
+
+'vect_interleave'
+     Target supports vector interleaving.
+
+'vect_strided'
+     Target supports vector interleaving and extract even/odd.
+
+'vect_strided_wide'
+     Target supports vector interleaving and extract even/odd for wide
+     element types.
+
+'vect_perm'
+     Target supports vector permutation.
+
+'vect_shift'
+     Target supports a hardware vector shift operation.
+
+'vect_widen_sum_hi_to_si'
+     Target supports a vector widening summation of 'short' operands
+     into 'int' results, or can promote (unpack) from 'short' to 'int'.
+
+'vect_widen_sum_qi_to_hi'
+     Target supports a vector widening summation of 'char' operands into
+     'short' results, or can promote (unpack) from 'char' to 'short'.
+
+'vect_widen_sum_qi_to_si'
+     Target supports a vector widening summation of 'char' operands into
+     'int' results.
+
+'vect_widen_mult_qi_to_hi'
+     Target supports a vector widening multiplication of 'char' operands
+     into 'short' results, or can promote (unpack) from 'char' to
+     'short' and perform non-widening multiplication of 'short'.
+
+'vect_widen_mult_hi_to_si'
+     Target supports a vector widening multiplication of 'short'
+     operands into 'int' results, or can promote (unpack) from 'short'
+     to 'int' and perform non-widening multiplication of 'int'.
+
+'vect_widen_mult_si_to_di_pattern'
+     Target supports a vector widening multiplication of 'int' operands
+     into 'long' results.
+
+'vect_sdot_qi'
+     Target supports a vector dot-product of 'signed char'.
+
+'vect_udot_qi'
+     Target supports a vector dot-product of 'unsigned char'.
+
+'vect_sdot_hi'
+     Target supports a vector dot-product of 'signed short'.
+
+'vect_udot_hi'
+     Target supports a vector dot-product of 'unsigned short'.
+
+'vect_pack_trunc'
+     Target supports a vector demotion (packing) of 'short' to 'char'
+     and from 'int' to 'short' using modulo arithmetic.
+
+'vect_unpack'
+     Target supports a vector promotion (unpacking) of 'char' to 'short'
+     and from 'char' to 'int'.
+
+'vect_intfloat_cvt'
+     Target supports conversion from 'signed int' to 'float'.
+
+'vect_uintfloat_cvt'
+     Target supports conversion from 'unsigned int' to 'float'.
+
+'vect_floatint_cvt'
+     Target supports conversion from 'float' to 'signed int'.
+
+'vect_floatuint_cvt'
+     Target supports conversion from 'float' to 'unsigned int'.
+
+7.2.3.4 Thread Local Storage attributes
+.......................................
+
+'tls'
+     Target supports thread-local storage.
+
+'tls_native'
+     Target supports native (rather than emulated) thread-local storage.
+
+'tls_runtime'
+     Test system supports executing TLS executables.
+
+7.2.3.5 Decimal floating point attributes
+.........................................
+
+'dfp'
+     Targets supports compiling decimal floating point extension to C.
+
+'dfp_nocache'
+     Including the options used to compile this particular test, the
+     target supports compiling decimal floating point extension to C.
+
+'dfprt'
+     Test system can execute decimal floating point tests.
+
+'dfprt_nocache'
+     Including the options used to compile this particular test, the
+     test system can execute decimal floating point tests.
+
+'hard_dfp'
+     Target generates decimal floating point instructions with current
+     options.
+
+7.2.3.6 ARM-specific attributes
+...............................
+
+'arm32'
+     ARM target generates 32-bit code.
+
+'arm_eabi'
+     ARM target adheres to the ABI for the ARM Architecture.
+
+'arm_hf_eabi'
+     ARM target adheres to the VFP and Advanced SIMD Register Arguments
+     variant of the ABI for the ARM Architecture (as selected with
+     '-mfloat-abi=hard').
+
+'arm_hard_vfp_ok'
+     ARM target supports '-mfpu=vfp -mfloat-abi=hard'.  Some multilibs
+     may be incompatible with these options.
+
+'arm_iwmmxt_ok'
+     ARM target supports '-mcpu=iwmmxt'.  Some multilibs may be
+     incompatible with this option.
+
+'arm_neon'
+     ARM target supports generating NEON instructions.
+
+'arm_neon_hw'
+     Test system supports executing NEON instructions.
+
+'arm_neonv2_hw'
+     Test system supports executing NEON v2 instructions.
+
+'arm_neon_ok'
+     ARM Target supports '-mfpu=neon -mfloat-abi=softfp' or compatible
+     options.  Some multilibs may be incompatible with these options.
+
+'arm_neonv2_ok'
+     ARM Target supports '-mfpu=neon-vfpv4 -mfloat-abi=softfp' or
+     compatible options.  Some multilibs may be incompatible with these
+     options.
+
+'arm_neon_fp16_ok'
+     ARM Target supports '-mfpu=neon-fp16 -mfloat-abi=softfp' or
+     compatible options.  Some multilibs may be incompatible with these
+     options.
+
+'arm_thumb1_ok'
+     ARM target generates Thumb-1 code for '-mthumb'.
+
+'arm_thumb2_ok'
+     ARM target generates Thumb-2 code for '-mthumb'.
+
+'arm_vfp_ok'
+     ARM target supports '-mfpu=vfp -mfloat-abi=softfp'.  Some multilibs
+     may be incompatible with these options.
+
+'arm_vfp3_ok'
+     ARM target supports '-mfpu=vfp3 -mfloat-abi=softfp'.  Some
+     multilibs may be incompatible with these options.
+
+'arm_v8_vfp_ok'
+     ARM target supports '-mfpu=fp-armv8 -mfloat-abi=softfp'.  Some
+     multilibs may be incompatible with these options.
+
+'arm_v8_neon_ok'
+     ARM target supports '-mfpu=neon-fp-armv8 -mfloat-abi=softfp'.  Some
+     multilibs may be incompatible with these options.
+
+'arm_prefer_ldrd_strd'
+     ARM target prefers 'LDRD' and 'STRD' instructions over 'LDM' and
+     'STM' instructions.
+
+7.2.3.7 MIPS-specific attributes
+................................
+
+'mips64'
+     MIPS target supports 64-bit instructions.
+
+'nomips16'
+     MIPS target does not produce MIPS16 code.
+
+'mips16_attribute'
+     MIPS target can generate MIPS16 code.
+
+'mips_loongson'
+     MIPS target is a Loongson-2E or -2F target using an ABI that
+     supports the Loongson vector modes.
+
+'mips_newabi_large_long_double'
+     MIPS target supports 'long double' larger than 'double' when using
+     the new ABI.
+
+'mpaired_single'
+     MIPS target supports '-mpaired-single'.
+
+7.2.3.8 PowerPC-specific attributes
+...................................
+
+'powerpc64'
+     Test system supports executing 64-bit instructions.
+
+'powerpc_altivec'
+     PowerPC target supports AltiVec.
+
+'powerpc_altivec_ok'
+     PowerPC target supports '-maltivec'.
+
+'powerpc_fprs'
+     PowerPC target supports floating-point registers.
+
+'powerpc_hard_double'
+     PowerPC target supports hardware double-precision floating-point.
+
+'powerpc_ppu_ok'
+     PowerPC target supports '-mcpu=cell'.
+
+'powerpc_spe'
+     PowerPC target supports PowerPC SPE.
+
+'powerpc_spe_nocache'
+     Including the options used to compile this particular test, the
+     PowerPC target supports PowerPC SPE.
+
+'powerpc_spu'
+     PowerPC target supports PowerPC SPU.
+
+'spu_auto_overlay'
+     SPU target has toolchain that supports automatic overlay
+     generation.
+
+'powerpc_vsx_ok'
+     PowerPC target supports '-mvsx'.
+
+'powerpc_405_nocache'
+     Including the options used to compile this particular test, the
+     PowerPC target supports PowerPC 405.
+
+'vmx_hw'
+     PowerPC target supports executing AltiVec instructions.
+
+7.2.3.9 Other hardware attributes
+.................................
+
+'avx'
+     Target supports compiling 'avx' instructions.
+
+'avx_runtime'
+     Target supports the execution of 'avx' instructions.
+
+'cell_hw'
+     Test system can execute AltiVec and Cell PPU instructions.
+
+'coldfire_fpu'
+     Target uses a ColdFire FPU.
+
+'hard_float'
+     Target supports FPU instructions.
+
+'sse'
+     Target supports compiling 'sse' instructions.
+
+'sse_runtime'
+     Target supports the execution of 'sse' instructions.
+
+'sse2'
+     Target supports compiling 'sse2' instructions.
+
+'sse2_runtime'
+     Target supports the execution of 'sse2' instructions.
+
+'sync_char_short'
+     Target supports atomic operations on 'char' and 'short'.
+
+'sync_int_long'
+     Target supports atomic operations on 'int' and 'long'.
+
+'ultrasparc_hw'
+     Test environment appears to run executables on a simulator that
+     accepts only 'EM_SPARC' executables and chokes on 'EM_SPARC32PLUS'
+     or 'EM_SPARCV9' executables.
+
+'vect_cmdline_needed'
+     Target requires a command line argument to enable a SIMD
+     instruction set.
+
+7.2.3.10 Environment attributes
+...............................
+
+'c'
+     The language for the compiler under test is C.
+
+'c++'
+     The language for the compiler under test is C++.
+
+'c99_runtime'
+     Target provides a full C99 runtime.
+
+'correct_iso_cpp_string_wchar_protos'
+     Target 'string.h' and 'wchar.h' headers provide C++ required
+     overloads for 'strchr' etc.  functions.
+
+'dummy_wcsftime'
+     Target uses a dummy 'wcsftime' function that always returns zero.
+
+'fd_truncate'
+     Target can truncate a file from a file descriptor, as used by
+     'libgfortran/io/unix.c:fd_truncate'; i.e.  'ftruncate' or 'chsize'.
+
+'freestanding'
+     Target is 'freestanding' as defined in section 4 of the C99
+     standard.  Effectively, it is a target which supports no extra
+     headers or libraries other than what is considered essential.
+
+'init_priority'
+     Target supports constructors with initialization priority
+     arguments.
+
+'inttypes_types'
+     Target has the basic signed and unsigned types in 'inttypes.h'.
+     This is for tests that GCC's notions of these types agree with
+     those in the header, as some systems have only 'inttypes.h'.
+
+'lax_strtofp'
+     Target might have errors of a few ULP in string to floating-point
+     conversion functions and overflow is not always detected correctly
+     by those functions.
+
+'mmap'
+     Target supports 'mmap'.
+
+'newlib'
+     Target supports Newlib.
+
+'pow10'
+     Target provides 'pow10' function.
+
+'pthread'
+     Target can compile using 'pthread.h' with no errors or warnings.
+
+'pthread_h'
+     Target has 'pthread.h'.
+
+'run_expensive_tests'
+     Expensive testcases (usually those that consume excessive amounts
+     of CPU time) should be run on this target.  This can be enabled by
+     setting the 'GCC_TEST_RUN_EXPENSIVE' environment variable to a
+     non-empty string.
+
+'simulator'
+     Test system runs executables on a simulator (i.e.  slowly) rather
+     than hardware (i.e.  fast).
+
+'stdint_types'
+     Target has the basic signed and unsigned C types in 'stdint.h'.
+     This will be obsolete when GCC ensures a working 'stdint.h' for all
+     targets.
+
+'trampolines'
+     Target supports trampolines.
+
+'uclibc'
+     Target supports uClibc.
+
+'unwrapped'
+     Target does not use a status wrapper.
+
+'vxworks_kernel'
+     Target is a VxWorks kernel.
+
+'vxworks_rtp'
+     Target is a VxWorks RTP.
+
+'wchar'
+     Target supports wide characters.
+
+7.2.3.11 Other attributes
+.........................
+
+'automatic_stack_alignment'
+     Target supports automatic stack alignment.
+
+'cxa_atexit'
+     Target uses '__cxa_atexit'.
+
+'default_packed'
+     Target has packed layout of structure members by default.
+
+'fgraphite'
+     Target supports Graphite optimizations.
+
+'fixed_point'
+     Target supports fixed-point extension to C.
+
+'fopenmp'
+     Target supports OpenMP via '-fopenmp'.
+
+'fpic'
+     Target supports '-fpic' and '-fPIC'.
+
+'freorder'
+     Target supports '-freorder-blocks-and-partition'.
+
+'fstack_protector'
+     Target supports '-fstack-protector'.
+
+'gas'
+     Target uses GNU 'as'.
+
+'gc_sections'
+     Target supports '--gc-sections'.
+
+'gld'
+     Target uses GNU 'ld'.
+
+'keeps_null_pointer_checks'
+     Target keeps null pointer checks, either due to the use of
+     '-fno-delete-null-pointer-checks' or hardwired into the target.
+
+'lto'
+     Compiler has been configured to support link-time optimization
+     (LTO).
+
+'naked_functions'
+     Target supports the 'naked' function attribute.
+
+'named_sections'
+     Target supports named sections.
+
+'natural_alignment_32'
+     Target uses natural alignment (aligned to type size) for types of
+     32 bits or less.
+
+'target_natural_alignment_64'
+     Target uses natural alignment (aligned to type size) for types of
+     64 bits or less.
+
+'nonpic'
+     Target does not generate PIC by default.
+
+'pcc_bitfield_type_matters'
+     Target defines 'PCC_BITFIELD_TYPE_MATTERS'.
+
+'pe_aligned_commons'
+     Target supports '-mpe-aligned-commons'.
+
+'pie'
+     Target supports '-pie', '-fpie' and '-fPIE'.
+
+'section_anchors'
+     Target supports section anchors.
+
+'short_enums'
+     Target defaults to short enums.
+
+'static'
+     Target supports '-static'.
+
+'static_libgfortran'
+     Target supports statically linking 'libgfortran'.
+
+'string_merging'
+     Target supports merging string constants at link time.
+
+'ucn'
+     Target supports compiling and assembling UCN.
+
+'ucn_nocache'
+     Including the options used to compile this particular test, the
+     target supports compiling and assembling UCN.
+
+'unaligned_stack'
+     Target does not guarantee that its 'STACK_BOUNDARY' is greater than
+     or equal to the required vector alignment.
+
+'vector_alignment_reachable'
+     Vector alignment is reachable for types of 32 bits or less.
+
+'vector_alignment_reachable_for_64bit'
+     Vector alignment is reachable for types of 64 bits or less.
+
+'wchar_t_char16_t_compatible'
+     Target supports 'wchar_t' that is compatible with 'char16_t'.
+
+'wchar_t_char32_t_compatible'
+     Target supports 'wchar_t' that is compatible with 'char32_t'.
+
+7.2.3.12 Local to tests in 'gcc.target/i386'
+............................................
+
+'3dnow'
+     Target supports compiling '3dnow' instructions.
+
+'aes'
+     Target supports compiling 'aes' instructions.
+
+'fma4'
+     Target supports compiling 'fma4' instructions.
+
+'ms_hook_prologue'
+     Target supports attribute 'ms_hook_prologue'.
+
+'pclmul'
+     Target supports compiling 'pclmul' instructions.
+
+'sse3'
+     Target supports compiling 'sse3' instructions.
+
+'sse4'
+     Target supports compiling 'sse4' instructions.
+
+'sse4a'
+     Target supports compiling 'sse4a' instructions.
+
+'ssse3'
+     Target supports compiling 'ssse3' instructions.
+
+'vaes'
+     Target supports compiling 'vaes' instructions.
+
+'vpclmul'
+     Target supports compiling 'vpclmul' instructions.
+
+'xop'
+     Target supports compiling 'xop' instructions.
+
+7.2.3.13 Local to tests in 'gcc.target/spu/ea'
+..............................................
+
+'ealib'
+     Target '__ea' library functions are available.
+
+7.2.3.14 Local to tests in 'gcc.test-framework'
+...............................................
+
+'no'
+     Always returns 0.
+
+'yes'
+     Always returns 1.
+
+
+File: gccint.info,  Node: Add Options,  Next: Require Support,  Prev: Effective-Target Keywords,  Up: Test Directives
+
+7.2.4 Features for 'dg-add-options'
+-----------------------------------
+
+The supported values of FEATURE for directive 'dg-add-options' are:
+
+'arm_neon'
+     NEON support.  Only ARM targets support this feature, and only then
+     in certain modes; see the *note arm_neon_ok effective target
+     keyword: arm_neon_ok.
+
+'arm_neon_fp16'
+     NEON and half-precision floating point support.  Only ARM targets
+     support this feature, and only then in certain modes; see the *note
+     arm_neon_fp16_ok effective target keyword: arm_neon_ok.
+
+'arm_vfp3'
+     arm vfp3 floating point support; see the *note arm_vfp3_ok
+     effective target keyword: arm_vfp3_ok.
+
+'bind_pic_locally'
+     Add the target-specific flags needed to enable functions to bind
+     locally when using pic/PIC passes in the testsuite.
+
+'c99_runtime'
+     Add the target-specific flags needed to access the C99 runtime.
+
+'ieee'
+     Add the target-specific flags needed to enable full IEEE compliance
+     mode.
+
+'mips16_attribute'
+     'mips16' function attributes.  Only MIPS targets support this
+     feature, and only then in certain modes.
+
+'tls'
+     Add the target-specific flags needed to use thread-local storage.
+
+
+File: gccint.info,  Node: Require Support,  Next: Final Actions,  Prev: Add Options,  Up: Test Directives
+
+7.2.5 Variants of 'dg-require-SUPPORT'
+--------------------------------------
+
+A few of the 'dg-require' directives take arguments.
+
+'dg-require-iconv CODESET'
+     Skip the test if the target does not support iconv.  CODESET is the
+     codeset to convert to.
+
+'dg-require-profiling PROFOPT'
+     Skip the test if the target does not support profiling with option
+     PROFOPT.
+
+'dg-require-visibility VIS'
+     Skip the test if the target does not support the 'visibility'
+     attribute.  If VIS is '""', support for 'visibility("hidden")' is
+     checked, for 'visibility("VIS")' otherwise.
+
+ The original 'dg-require' directives were defined before there was
+support for effective-target keywords.  The directives that do not take
+arguments could be replaced with effective-target keywords.
+
+'dg-require-alias ""'
+     Skip the test if the target does not support the 'alias' attribute.
+
+'dg-require-ascii-locale ""'
+     Skip the test if the host does not support an ASCII locale.
+
+'dg-require-compat-dfp ""'
+     Skip this test unless both compilers in a 'compat' testsuite
+     support decimal floating point.
+
+'dg-require-cxa-atexit ""'
+     Skip the test if the target does not support '__cxa_atexit'.  This
+     is equivalent to 'dg-require-effective-target cxa_atexit'.
+
+'dg-require-dll ""'
+     Skip the test if the target does not support DLL attributes.
+
+'dg-require-fork ""'
+     Skip the test if the target does not support 'fork'.
+
+'dg-require-gc-sections ""'
+     Skip the test if the target's linker does not support the
+     '--gc-sections' flags.  This is equivalent to
+     'dg-require-effective-target gc-sections'.
+
+'dg-require-host-local ""'
+     Skip the test if the host is remote, rather than the same as the
+     build system.  Some tests are incompatible with DejaGnu's handling
+     of remote hosts, which involves copying the source file to the host
+     and compiling it with a relative path and "'-o a.out'".
+
+'dg-require-mkfifo ""'
+     Skip the test if the target does not support 'mkfifo'.
+
+'dg-require-named-sections ""'
+     Skip the test is the target does not support named sections.  This
+     is equivalent to 'dg-require-effective-target named_sections'.
+
+'dg-require-weak ""'
+     Skip the test if the target does not support weak symbols.
+
+'dg-require-weak-override ""'
+     Skip the test if the target does not support overriding weak
+     symbols.
+
+
+File: gccint.info,  Node: Final Actions,  Prev: Require Support,  Up: Test Directives
+
+7.2.6 Commands for use in 'dg-final'
+------------------------------------
+
+The GCC testsuite defines the following directives to be used within
+'dg-final'.
+
+7.2.6.1 Scan a particular file
+..............................
+
+'scan-file FILENAME REGEXP [{ target/xfail SELECTOR }]'
+     Passes if REGEXP matches text in FILENAME.
+'scan-file-not FILENAME REGEXP [{ target/xfail SELECTOR }]'
+     Passes if REGEXP does not match text in FILENAME.
+'scan-module MODULE REGEXP [{ target/xfail SELECTOR }]'
+     Passes if REGEXP matches in Fortran module MODULE.
+
+7.2.6.2 Scan the assembly output
+................................
+
+'scan-assembler REGEX [{ target/xfail SELECTOR }]'
+     Passes if REGEX matches text in the test's assembler output.
+
+'scan-assembler-not REGEX [{ target/xfail SELECTOR }]'
+     Passes if REGEX does not match text in the test's assembler output.
+
+'scan-assembler-times REGEX NUM [{ target/xfail SELECTOR }]'
+     Passes if REGEX is matched exactly NUM times in the test's
+     assembler output.
+
+'scan-assembler-dem REGEX [{ target/xfail SELECTOR }]'
+     Passes if REGEX matches text in the test's demangled assembler
+     output.
+
+'scan-assembler-dem-not REGEX [{ target/xfail SELECTOR }]'
+     Passes if REGEX does not match text in the test's demangled
+     assembler output.
+
+'scan-hidden SYMBOL [{ target/xfail SELECTOR }]'
+     Passes if SYMBOL is defined as a hidden symbol in the test's
+     assembly output.
+
+'scan-not-hidden SYMBOL [{ target/xfail SELECTOR }]'
+     Passes if SYMBOL is not defined as a hidden symbol in the test's
+     assembly output.
+
+7.2.6.3 Scan optimization dump files
+....................................
+
+These commands are available for KIND of 'tree', 'rtl', and 'ipa'.
+
+'scan-KIND-dump REGEX SUFFIX [{ target/xfail SELECTOR }]'
+     Passes if REGEX matches text in the dump file with suffix SUFFIX.
+
+'scan-KIND-dump-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
+     Passes if REGEX does not match text in the dump file with suffix
+     SUFFIX.
+
+'scan-KIND-dump-times REGEX NUM SUFFIX [{ target/xfail SELECTOR }]'
+     Passes if REGEX is found exactly NUM times in the dump file with
+     suffix SUFFIX.
+
+'scan-KIND-dump-dem REGEX SUFFIX [{ target/xfail SELECTOR }]'
+     Passes if REGEX matches demangled text in the dump file with suffix
+     SUFFIX.
+
+'scan-KIND-dump-dem-not REGEX SUFFIX [{ target/xfail SELECTOR }]'
+     Passes if REGEX does not match demangled text in the dump file with
+     suffix SUFFIX.
+
+7.2.6.4 Verify that an output files exists or not
+.................................................
+
+'output-exists [{ target/xfail SELECTOR }]'
+     Passes if compiler output file exists.
+
+'output-exists-not [{ target/xfail SELECTOR }]'
+     Passes if compiler output file does not exist.
+
+7.2.6.5 Check for LTO tests
+...........................
+
+'scan-symbol REGEXP [{ target/xfail SELECTOR }]'
+     Passes if the pattern is present in the final executable.
+
+7.2.6.6 Checks for 'gcov' tests
+...............................
+
+'run-gcov SOURCEFILE'
+     Check line counts in 'gcov' tests.
+
+'run-gcov [branches] [calls] { OPTS SOURCEFILE }'
+     Check branch and/or call counts, in addition to line counts, in
+     'gcov' tests.
+
+7.2.6.7 Clean up generated test files
+.....................................
+
+'cleanup-coverage-files'
+     Removes coverage data files generated for this test.
+
+'cleanup-ipa-dump SUFFIX'
+     Removes IPA dump files generated for this test.
+
+'cleanup-modules "LIST-OF-EXTRA-MODULES"'
+     Removes Fortran module files generated for this test, excluding the
+     module names listed in keep-modules.  Cleaning up module files is
+     usually done automatically by the testsuite by looking at the
+     source files and removing the modules after the test has been
+     executed.
+          module MoD1
+          end module MoD1
+          module Mod2
+          end module Mod2
+          module moD3
+          end module moD3
+          module mod4
+          end module mod4
+          ! { dg-final { cleanup-modules "mod1 mod2" } } ! redundant
+          ! { dg-final { keep-modules "mod3 mod4" } }
+
+'keep-modules "LIST-OF-MODULES-NOT-TO-DELETE"'
+     Whitespace separated list of module names that should not be
+     deleted by cleanup-modules.  If the list of modules is empty, all
+     modules defined in this file are kept.
+          module maybe_unneeded
+          end module maybe_unneeded
+          module keep1
+          end module keep1
+          module keep2
+          end module keep2
+          ! { dg-final { keep-modules "keep1 keep2" } } ! just keep these two
+          ! { dg-final { keep-modules "" } } ! keep all
+
+'cleanup-profile-file'
+     Removes profiling files generated for this test.
+
+'cleanup-repo-files'
+     Removes files generated for this test for '-frepo'.
+
+'cleanup-rtl-dump SUFFIX'
+     Removes RTL dump files generated for this test.
+
+'cleanup-saved-temps'
+     Removes files for the current test which were kept for
+     '-save-temps'.
+
+'cleanup-tree-dump SUFFIX'
+     Removes tree dump files matching SUFFIX which were generated for
+     this test.
+
+
+File: gccint.info,  Node: Ada Tests,  Next: C Tests,  Prev: Test Directives,  Up: Testsuites
+
+7.3 Ada Language Testsuites
+===========================
+
+The Ada testsuite includes executable tests from the ACATS testsuite,
+publicly available at <http://www.ada-auth.org/acats.html>.
+
+ These tests are integrated in the GCC testsuite in the 'ada/acats'
+directory, and enabled automatically when running 'make check', assuming
+the Ada language has been enabled when configuring GCC.
+
+ You can also run the Ada testsuite independently, using 'make
+check-ada', or run a subset of the tests by specifying which chapter to
+run, e.g.:
+
+     $ make check-ada CHAPTERS="c3 c9"
+
+ The tests are organized by directory, each directory corresponding to a
+chapter of the Ada Reference Manual.  So for example, 'c9' corresponds
+to chapter 9, which deals with tasking features of the language.
+
+ There is also an extra chapter called 'gcc' containing a template for
+creating new executable tests, although this is deprecated in favor of
+the 'gnat.dg' testsuite.
+
+ The tests are run using two 'sh' scripts: 'run_acats' and 'run_all.sh'.
+To run the tests using a simulator or a cross target, see the small
+customization section at the top of 'run_all.sh'.
+
+ These tests are run using the build tree: they can be run without doing
+a 'make install'.
+
+
+File: gccint.info,  Node: C Tests,  Next: libgcj Tests,  Prev: Ada Tests,  Up: Testsuites
+
+7.4 C Language Testsuites
+=========================
+
+GCC contains the following C language testsuites, in the 'gcc/testsuite'
+directory:
+
+'gcc.dg'
+     This contains tests of particular features of the C compiler, using
+     the more modern 'dg' harness.  Correctness tests for various
+     compiler features should go here if possible.
+
+     Magic comments determine whether the file is preprocessed,
+     compiled, linked or run.  In these tests, error and warning message
+     texts are compared against expected texts or regular expressions
+     given in comments.  These tests are run with the options '-ansi
+     -pedantic' unless other options are given in the test.  Except as
+     noted below they are not run with multiple optimization options.
+'gcc.dg/compat'
+     This subdirectory contains tests for binary compatibility using
+     'lib/compat.exp', which in turn uses the language-independent
+     support (*note Support for testing binary compatibility: compat
+     Testing.).
+'gcc.dg/cpp'
+     This subdirectory contains tests of the preprocessor.
+'gcc.dg/debug'
+     This subdirectory contains tests for debug formats.  Tests in this
+     subdirectory are run for each debug format that the compiler
+     supports.
+'gcc.dg/format'
+     This subdirectory contains tests of the '-Wformat' format checking.
+     Tests in this directory are run with and without '-DWIDE'.
+'gcc.dg/noncompile'
+     This subdirectory contains tests of code that should not compile
+     and does not need any special compilation options.  They are run
+     with multiple optimization options, since sometimes invalid code
+     crashes the compiler with optimization.
+'gcc.dg/special'
+     FIXME: describe this.
+
+'gcc.c-torture'
+     This contains particular code fragments which have historically
+     broken easily.  These tests are run with multiple optimization
+     options, so tests for features which only break at some
+     optimization levels belong here.  This also contains tests to check
+     that certain optimizations occur.  It might be worthwhile to
+     separate the correctness tests cleanly from the code quality tests,
+     but it hasn't been done yet.
+
+'gcc.c-torture/compat'
+     FIXME: describe this.
+
+     This directory should probably not be used for new tests.
+'gcc.c-torture/compile'
+     This testsuite contains test cases that should compile, but do not
+     need to link or run.  These test cases are compiled with several
+     different combinations of optimization options.  All warnings are
+     disabled for these test cases, so this directory is not suitable if
+     you wish to test for the presence or absence of compiler warnings.
+     While special options can be set, and tests disabled on specific
+     platforms, by the use of '.x' files, mostly these test cases should
+     not contain platform dependencies.  FIXME: discuss how defines such
+     as 'NO_LABEL_VALUES' and 'STACK_SIZE' are used.
+'gcc.c-torture/execute'
+     This testsuite contains test cases that should compile, link and
+     run; otherwise the same comments as for 'gcc.c-torture/compile'
+     apply.
+'gcc.c-torture/execute/ieee'
+     This contains tests which are specific to IEEE floating point.
+'gcc.c-torture/unsorted'
+     FIXME: describe this.
+
+     This directory should probably not be used for new tests.
+'gcc.misc-tests'
+     This directory contains C tests that require special handling.
+     Some of these tests have individual expect files, and others share
+     special-purpose expect files:
+
+     'bprob*.c'
+          Test '-fbranch-probabilities' using
+          'gcc.misc-tests/bprob.exp', which in turn uses the generic,
+          language-independent framework (*note Support for testing
+          profile-directed optimizations: profopt Testing.).
+
+     'gcov*.c'
+          Test 'gcov' output using 'gcov.exp', which in turn uses the
+          language-independent support (*note Support for testing gcov:
+          gcov Testing.).
+
+     'i386-pf-*.c'
+          Test i386-specific support for data prefetch using
+          'i386-prefetch.exp'.
+
+'gcc.test-framework'
+     'dg-*.c'
+          Test the testsuite itself using
+          'gcc.test-framework/test-framework.exp'.
+
+ FIXME: merge in 'testsuite/README.gcc' and discuss the format of test
+cases and magic comments more.
+
+
+File: gccint.info,  Node: libgcj Tests,  Next: LTO Testing,  Prev: C Tests,  Up: Testsuites
+
+7.5 The Java library testsuites.
+================================
+
+Runtime tests are executed via 'make check' in the
+'TARGET/libjava/testsuite' directory in the build tree.  Additional
+runtime tests can be checked into this testsuite.
+
+ Regression testing of the core packages in libgcj is also covered by
+the Mauve testsuite.  The Mauve Project develops tests for the Java
+Class Libraries.  These tests are run as part of libgcj testing by
+placing the Mauve tree within the libjava testsuite sources at
+'libjava/testsuite/libjava.mauve/mauve', or by specifying the location
+of that tree when invoking 'make', as in 'make MAUVEDIR=~/mauve check'.
+
+ To detect regressions, a mechanism in 'mauve.exp' compares the failures
+for a test run against the list of expected failures in
+'libjava/testsuite/libjava.mauve/xfails' from the source hierarchy.
+Update this file when adding new failing tests to Mauve, or when fixing
+bugs in libgcj that had caused Mauve test failures.
+
+ We encourage developers to contribute test cases to Mauve.
+
+
+File: gccint.info,  Node: LTO Testing,  Next: gcov Testing,  Prev: libgcj Tests,  Up: Testsuites
+
+7.6 Support for testing link-time optimizations
+===============================================
+
+Tests for link-time optimizations usually require multiple source files
+that are compiled separately, perhaps with different sets of options.
+There are several special-purpose test directives used for these tests.
+
+'{ dg-lto-do DO-WHAT-KEYWORD }'
+     DO-WHAT-KEYWORD specifies how the test is compiled and whether it
+     is executed.  It is one of:
+
+     'assemble'
+          Compile with '-c' to produce a relocatable object file.
+     'link'
+          Compile, assemble, and link to produce an executable file.
+     'run'
+          Produce and run an executable file, which is expected to
+          return an exit code of 0.
+
+     The default is 'assemble'.  That can be overridden for a set of
+     tests by redefining 'dg-do-what-default' within the '.exp' file for
+     those tests.
+
+     Unlike 'dg-do', 'dg-lto-do' does not support an optional 'target'
+     or 'xfail' list.  Use 'dg-skip-if', 'dg-xfail-if', or
+     'dg-xfail-run-if'.
+
+'{ dg-lto-options { { OPTIONS } [{ OPTIONS }] } [{ target SELECTOR }]}'
+     This directive provides a list of one or more sets of compiler
+     options to override LTO_OPTIONS.  Each test will be compiled and
+     run with each of these sets of options.
+
+'{ dg-extra-ld-options OPTIONS [{ target SELECTOR }]}'
+     This directive adds OPTIONS to the linker options used.
+
+'{ dg-suppress-ld-options OPTIONS [{ target SELECTOR }]}'
+     This directive removes OPTIONS from the set of linker options used.
+
+
+File: gccint.info,  Node: gcov Testing,  Next: profopt Testing,  Prev: LTO Testing,  Up: Testsuites
+
+7.7 Support for testing 'gcov'
+==============================
+
+Language-independent support for testing 'gcov', and for checking that
+branch profiling produces expected values, is provided by the expect
+file 'lib/gcov.exp'.  'gcov' tests also rely on procedures in
+'lib/gcc-dg.exp' to compile and run the test program.  A typical 'gcov'
+test contains the following DejaGnu commands within comments:
+
+     { dg-options "-fprofile-arcs -ftest-coverage" }
+     { dg-do run { target native } }
+     { dg-final { run-gcov sourcefile } }
+
+ Checks of 'gcov' output can include line counts, branch percentages,
+and call return percentages.  All of these checks are requested via
+commands that appear in comments in the test's source file.  Commands to
+check line counts are processed by default.  Commands to check branch
+percentages and call return percentages are processed if the 'run-gcov'
+command has arguments 'branches' or 'calls', respectively.  For example,
+the following specifies checking both, as well as passing '-b' to
+'gcov':
+
+     { dg-final { run-gcov branches calls { -b sourcefile } } }
+
+ A line count command appears within a comment on the source line that
+is expected to get the specified count and has the form 'count(CNT)'.  A
+test should only check line counts for lines that will get the same
+count for any architecture.
+
+ Commands to check branch percentages ('branch') and call return
+percentages ('returns') are very similar to each other.  A beginning
+command appears on or before the first of a range of lines that will
+report the percentage, and the ending command follows that range of
+lines.  The beginning command can include a list of percentages, all of
+which are expected to be found within the range.  A range is terminated
+by the next command of the same kind.  A command 'branch(end)' or
+'returns(end)' marks the end of a range without starting a new one.  For
+example:
+
+     if (i > 10 && j > i && j < 20)  /* branch(27 50 75) */
+                                     /* branch(end) */
+       foo (i, j);
+
+ For a call return percentage, the value specified is the percentage of
+calls reported to return.  For a branch percentage, the value is either
+the expected percentage or 100 minus that value, since the direction of
+a branch can differ depending on the target or the optimization level.
+
+ Not all branches and calls need to be checked.  A test should not check
+for branches that might be optimized away or replaced with predicated
+instructions.  Don't check for calls inserted by the compiler or ones
+that might be inlined or optimized away.
+
+ A single test can check for combinations of line counts, branch
+percentages, and call return percentages.  The command to check a line
+count must appear on the line that will report that count, but commands
+to check branch percentages and call return percentages can bracket the
+lines that report them.
+
+
+File: gccint.info,  Node: profopt Testing,  Next: compat Testing,  Prev: gcov Testing,  Up: Testsuites
+
+7.8 Support for testing profile-directed optimizations
+======================================================
+
+The file 'profopt.exp' provides language-independent support for
+checking correct execution of a test built with profile-directed
+optimization.  This testing requires that a test program be built and
+executed twice.  The first time it is compiled to generate profile data,
+and the second time it is compiled to use the data that was generated
+during the first execution.  The second execution is to verify that the
+test produces the expected results.
+
+ To check that the optimization actually generated better code, a test
+can be built and run a third time with normal optimizations to verify
+that the performance is better with the profile-directed optimizations.
+'profopt.exp' has the beginnings of this kind of support.
+
+ 'profopt.exp' provides generic support for profile-directed
+optimizations.  Each set of tests that uses it provides information
+about a specific optimization:
+
+'tool'
+     tool being tested, e.g., 'gcc'
+
+'profile_option'
+     options used to generate profile data
+
+'feedback_option'
+     options used to optimize using that profile data
+
+'prof_ext'
+     suffix of profile data files
+
+'PROFOPT_OPTIONS'
+     list of options with which to run each test, similar to the lists
+     for torture tests
+
+'{ dg-final-generate { LOCAL-DIRECTIVE } }'
+     This directive is similar to 'dg-final', but the LOCAL-DIRECTIVE is
+     run after the generation of profile data.
+
+'{ dg-final-use { LOCAL-DIRECTIVE } }'
+     The LOCAL-DIRECTIVE is run after the profile data have been used.
+
+
+File: gccint.info,  Node: compat Testing,  Next: Torture Tests,  Prev: profopt Testing,  Up: Testsuites
+
+7.9 Support for testing binary compatibility
+============================================
+
+The file 'compat.exp' provides language-independent support for binary
+compatibility testing.  It supports testing interoperability of two
+compilers that follow the same ABI, or of multiple sets of compiler
+options that should not affect binary compatibility.  It is intended to
+be used for testsuites that complement ABI testsuites.
+
+ A test supported by this framework has three parts, each in a separate
+source file: a main program and two pieces that interact with each other
+to split up the functionality being tested.
+
+'TESTNAME_main.SUFFIX'
+     Contains the main program, which calls a function in file
+     'TESTNAME_x.SUFFIX'.
+
+'TESTNAME_x.SUFFIX'
+     Contains at least one call to a function in 'TESTNAME_y.SUFFIX'.
+
+'TESTNAME_y.SUFFIX'
+     Shares data with, or gets arguments from, 'TESTNAME_x.SUFFIX'.
+
+ Within each test, the main program and one functional piece are
+compiled by the GCC under test.  The other piece can be compiled by an
+alternate compiler.  If no alternate compiler is specified, then all
+three source files are all compiled by the GCC under test.  You can
+specify pairs of sets of compiler options.  The first element of such a
+pair specifies options used with the GCC under test, and the second
+element of the pair specifies options used with the alternate compiler.
+Each test is compiled with each pair of options.
+
+ 'compat.exp' defines default pairs of compiler options.  These can be
+overridden by defining the environment variable 'COMPAT_OPTIONS' as:
+
+     COMPAT_OPTIONS="[list [list {TST1} {ALT1}]
+       ...[list {TSTN} {ALTN}]]"
+
+ where TSTI and ALTI are lists of options, with TSTI used by the
+compiler under test and ALTI used by the alternate compiler.  For
+example, with '[list [list {-g -O0} {-O3}] [list {-fpic} {-fPIC -O2}]]',
+the test is first built with '-g -O0' by the compiler under test and
+with '-O3' by the alternate compiler.  The test is built a second time
+using '-fpic' by the compiler under test and '-fPIC -O2' by the
+alternate compiler.
+
+ An alternate compiler is specified by defining an environment variable
+to be the full pathname of an installed compiler; for C define
+'ALT_CC_UNDER_TEST', and for C++ define 'ALT_CXX_UNDER_TEST'.  These
+will be written to the 'site.exp' file used by DejaGnu.  The default is
+to build each test with the compiler under test using the first of each
+pair of compiler options from 'COMPAT_OPTIONS'.  When
+'ALT_CC_UNDER_TEST' or 'ALT_CXX_UNDER_TEST' is 'same', each test is
+built using the compiler under test but with combinations of the options
+from 'COMPAT_OPTIONS'.
+
+ To run only the C++ compatibility suite using the compiler under test
+and another version of GCC using specific compiler options, do the
+following from 'OBJDIR/gcc':
+
+     rm site.exp
+     make -k \
+       ALT_CXX_UNDER_TEST=${alt_prefix}/bin/g++ \
+       COMPAT_OPTIONS="LISTS AS SHOWN ABOVE" \
+       check-c++ \
+       RUNTESTFLAGS="compat.exp"
+
+ A test that fails when the source files are compiled with different
+compilers, but passes when the files are compiled with the same
+compiler, demonstrates incompatibility of the generated code or runtime
+support.  A test that fails for the alternate compiler but passes for
+the compiler under test probably tests for a bug that was fixed in the
+compiler under test but is present in the alternate compiler.
+
+ The binary compatibility tests support a small number of test framework
+commands that appear within comments in a test file.
+
+'dg-require-*'
+     These commands can be used in 'TESTNAME_main.SUFFIX' to skip the
+     test if specific support is not available on the target.
+
+'dg-options'
+     The specified options are used for compiling this particular source
+     file, appended to the options from 'COMPAT_OPTIONS'.  When this
+     command appears in 'TESTNAME_main.SUFFIX' the options are also used
+     to link the test program.
+
+'dg-xfail-if'
+     This command can be used in a secondary source file to specify that
+     compilation is expected to fail for particular options on
+     particular targets.
+
+
+File: gccint.info,  Node: Torture Tests,  Prev: compat Testing,  Up: Testsuites
+
+7.10 Support for torture testing using multiple options
+=======================================================
+
+Throughout the compiler testsuite there are several directories whose
+tests are run multiple times, each with a different set of options.
+These are known as torture tests.  'lib/torture-options.exp' defines
+procedures to set up these lists:
+
+'torture-init'
+     Initialize use of torture lists.
+'set-torture-options'
+     Set lists of torture options to use for tests with and without
+     loops.  Optionally combine a set of torture options with a set of
+     other options, as is done with Objective-C runtime options.
+'torture-finish'
+     Finalize use of torture lists.
+
+ The '.exp' file for a set of tests that use torture options must
+include calls to these three procedures if:
+
+   * It calls 'gcc-dg-runtest' and overrides DG_TORTURE_OPTIONS.
+
+   * It calls ${TOOL}'-torture' or ${TOOL}'-torture-execute', where TOOL
+     is 'c', 'fortran', or 'objc'.
+
+   * It calls 'dg-pch'.
+
+ It is not necessary for a '.exp' file that calls 'gcc-dg-runtest' to
+call the torture procedures if the tests should use the list in
+DG_TORTURE_OPTIONS defined in 'gcc-dg.exp'.
+
+ Most uses of torture options can override the default lists by defining
+TORTURE_OPTIONS or add to the default list by defining
+ADDITIONAL_TORTURE_OPTIONS.  Define these in a '.dejagnurc' file or add
+them to the 'site.exp' file; for example
+
+     set ADDITIONAL_TORTURE_OPTIONS  [list \
+       { -O2 -ftree-loop-linear } \
+       { -O2 -fpeel-loops } ]
+
+
+File: gccint.info,  Node: Options,  Next: Passes,  Prev: Testsuites,  Up: Top
+
+8 Option specification files
+****************************
+
+Most GCC command-line options are described by special option definition
+files, the names of which conventionally end in '.opt'.  This chapter
+describes the format of these files.
+
+* Menu:
+
+* Option file format::   The general layout of the files
+* Option properties::    Supported option properties
+
+
+File: gccint.info,  Node: Option file format,  Next: Option properties,  Up: Options
+
+8.1 Option file format
+======================
+
+Option files are a simple list of records in which each field occupies
+its own line and in which the records themselves are separated by blank
+lines.  Comments may appear on their own line anywhere within the file
+and are preceded by semicolons.  Whitespace is allowed before the
+semicolon.
+
+ The files can contain the following types of record:
+
+   * A language definition record.  These records have two fields: the
+     string 'Language' and the name of the language.  Once a language
+     has been declared in this way, it can be used as an option
+     property.  *Note Option properties::.
+
+   * A target specific save record to save additional information.
+     These records have two fields: the string 'TargetSave', and a
+     declaration type to go in the 'cl_target_option' structure.
+
+   * A variable record to define a variable used to store option
+     information.  These records have two fields: the string 'Variable',
+     and a declaration of the type and name of the variable, optionally
+     with an initializer (but without any trailing ';').  These records
+     may be used for variables used for many options where declaring the
+     initializer in a single option definition record, or duplicating it
+     in many records, would be inappropriate, or for variables set in
+     option handlers rather than referenced by 'Var' properties.
+
+   * A variable record to define a variable used to store option
+     information.  These records have two fields: the string
+     'TargetVariable', and a declaration of the type and name of the
+     variable, optionally with an initializer (but without any trailing
+     ';').  'TargetVariable' is a combination of 'Variable' and
+     'TargetSave' records in that the variable is defined in the
+     'gcc_options' structure, but these variables are also stored in the
+     'cl_target_option' structure.  The variables are saved in the
+     target save code and restored in the target restore code.
+
+   * A variable record to record any additional files that the
+     'options.h' file should include.  This is useful to provide
+     enumeration or structure definitions needed for target variables.
+     These records have two fields: the string 'HeaderInclude' and the
+     name of the include file.
+
+   * A variable record to record any additional files that the
+     'options.c' or 'options-save.c' file should include.  This is
+     useful to provide inline functions needed for target variables
+     and/or '#ifdef' sequences to properly set up the initialization.
+     These records have two fields: the string 'SourceInclude' and the
+     name of the include file.
+
+   * An enumeration record to define a set of strings that may be used
+     as arguments to an option or options.  These records have three
+     fields: the string 'Enum', a space-separated list of properties and
+     help text used to describe the set of strings in '--help' output.
+     Properties use the same format as option properties; the following
+     are valid:
+     'Name(NAME)'
+          This property is required; NAME must be a name (suitable for
+          use in C identifiers) used to identify the set of strings in
+          'Enum' option properties.
+
+     'Type(TYPE)'
+          This property is required; TYPE is the C type for variables
+          set by options using this enumeration together with 'Var'.
+
+     'UnknownError(MESSAGE)'
+          The message MESSAGE will be used as an error message if the
+          argument is invalid; for enumerations without 'UnknownError',
+          a generic error message is used.  MESSAGE should contain a
+          single '%qs' format, which will be used to format the invalid
+          argument.
+
+   * An enumeration value record to define one of the strings in a set
+     given in an 'Enum' record.  These records have two fields: the
+     string 'EnumValue' and a space-separated list of properties.
+     Properties use the same format as option properties; the following
+     are valid:
+     'Enum(NAME)'
+          This property is required; NAME says which 'Enum' record this
+          'EnumValue' record corresponds to.
+
+     'String(STRING)'
+          This property is required; STRING is the string option
+          argument being described by this record.
+
+     'Value(VALUE)'
+          This property is required; it says what value (representable
+          as 'int') should be used for the given string.
+
+     'Canonical'
+          This property is optional.  If present, it says the present
+          string is the canonical one among all those with the given
+          value.  Other strings yielding that value will be mapped to
+          this one so specs do not need to handle them.
+
+     'DriverOnly'
+          This property is optional.  If present, the present string
+          will only be accepted by the driver.  This is used for cases
+          such as '-march=native' that are processed by the driver so
+          that 'gcc -v' shows how the options chosen depended on the
+          system on which the compiler was run.
+
+   * An option definition record.  These records have the following
+     fields:
+       1. the name of the option, with the leading "-" removed
+       2. a space-separated list of option properties (*note Option
+          properties::)
+       3. the help text to use for '--help' (omitted if the second field
+          contains the 'Undocumented' property).
+
+     By default, all options beginning with "f", "W" or "m" are
+     implicitly assumed to take a "no-" form.  This form should not be
+     listed separately.  If an option beginning with one of these
+     letters does not have a "no-" form, you can use the
+     'RejectNegative' property to reject it.
+
+     The help text is automatically line-wrapped before being displayed.
+     Normally the name of the option is printed on the left-hand side of
+     the output and the help text is printed on the right.  However, if
+     the help text contains a tab character, the text to the left of the
+     tab is used instead of the option's name and the text to the right
+     of the tab forms the help text.  This allows you to elaborate on
+     what type of argument the option takes.
+
+   * A target mask record.  These records have one field of the form
+     'Mask(X)'.  The options-processing script will automatically
+     allocate a bit in 'target_flags' (*note Run-time Target::) for each
+     mask name X and set the macro 'MASK_X' to the appropriate bitmask.
+     It will also declare a 'TARGET_X' macro that has the value 1 when
+     bit 'MASK_X' is set and 0 otherwise.
+
+     They are primarily intended to declare target masks that are not
+     associated with user options, either because these masks represent
+     internal switches or because the options are not available on all
+     configurations and yet the masks always need to be defined.
+
+
+File: gccint.info,  Node: Option properties,  Prev: Option file format,  Up: Options
+
+8.2 Option properties
+=====================
+
+The second field of an option record can specify any of the following
+properties.  When an option takes an argument, it is enclosed in
+parentheses following the option property name.  The parser that handles
+option files is quite simplistic, and will be tricked by any nested
+parentheses within the argument text itself; in this case, the entire
+option argument can be wrapped in curly braces within the parentheses to
+demarcate it, e.g.:
+
+     Condition({defined (USE_CYGWIN_LIBSTDCXX_WRAPPERS)})
+
+'Common'
+     The option is available for all languages and targets.
+
+'Target'
+     The option is available for all languages but is target-specific.
+
+'Driver'
+     The option is handled by the compiler driver using code not shared
+     with the compilers proper ('cc1' etc.).
+
+'LANGUAGE'
+     The option is available when compiling for the given language.
+
+     It is possible to specify several different languages for the same
+     option.  Each LANGUAGE must have been declared by an earlier
+     'Language' record.  *Note Option file format::.
+
+'RejectDriver'
+     The option is only handled by the compilers proper ('cc1' etc.) and
+     should not be accepted by the driver.
+
+'RejectNegative'
+     The option does not have a "no-" form.  All options beginning with
+     "f", "W" or "m" are assumed to have a "no-" form unless this
+     property is used.
+
+'Negative(OTHERNAME)'
+     The option will turn off another option OTHERNAME, which is the
+     option name with the leading "-" removed.  This chain action will
+     propagate through the 'Negative' property of the option to be
+     turned off.
+
+     As a consequence, if you have a group of mutually-exclusive
+     options, their 'Negative' properties should form a circular chain.
+     For example, if options '-A', '-B' and '-C' are mutually exclusive,
+     their respective 'Negative' properties should be 'Negative(B)',
+     'Negative(C)' and 'Negative(A)'.
+
+'Joined'
+'Separate'
+     The option takes a mandatory argument.  'Joined' indicates that the
+     option and argument can be included in the same 'argv' entry (as
+     with '-mflush-func=NAME', for example).  'Separate' indicates that
+     the option and argument can be separate 'argv' entries (as with
+     '-o').  An option is allowed to have both of these properties.
+
+'JoinedOrMissing'
+     The option takes an optional argument.  If the argument is given,
+     it will be part of the same 'argv' entry as the option itself.
+
+     This property cannot be used alongside 'Joined' or 'Separate'.
+
+'MissingArgError(MESSAGE)'
+     For an option marked 'Joined' or 'Separate', the message MESSAGE
+     will be used as an error message if the mandatory argument is
+     missing; for options without 'MissingArgError', a generic error
+     message is used.  MESSAGE should contain a single '%qs' format,
+     which will be used to format the name of the option passed.
+
+'Args(N)'
+     For an option marked 'Separate', indicate that it takes N
+     arguments.  The default is 1.
+
+'UInteger'
+     The option's argument is a non-negative integer.  The option parser
+     will check and convert the argument before passing it to the
+     relevant option handler.  'UInteger' should also be used on options
+     like '-falign-loops' where both '-falign-loops' and
+     '-falign-loops'=N are supported to make sure the saved options are
+     given a full integer.
+
+'ToLower'
+     The option's argument should be converted to lowercase as part of
+     putting it in canonical form, and before comparing with the strings
+     indicated by any 'Enum' property.
+
+'NoDriverArg'
+     For an option marked 'Separate', the option only takes an argument
+     in the compiler proper, not in the driver.  This is for
+     compatibility with existing options that are used both directly and
+     via '-Wp,'; new options should not have this property.
+
+'Var(VAR)'
+     The state of this option should be stored in variable VAR (actually
+     a macro for 'global_options.x_VAR').  The way that the state is
+     stored depends on the type of option:
+
+        * If the option uses the 'Mask' or 'InverseMask' properties, VAR
+          is the integer variable that contains the mask.
+
+        * If the option is a normal on/off switch, VAR is an integer
+          variable that is nonzero when the option is enabled.  The
+          options parser will set the variable to 1 when the positive
+          form of the option is used and 0 when the "no-" form is used.
+
+        * If the option takes an argument and has the 'UInteger'
+          property, VAR is an integer variable that stores the value of
+          the argument.
+
+        * If the option takes an argument and has the 'Enum' property,
+          VAR is a variable (type given in the 'Type' property of the
+          'Enum' record whose 'Name' property has the same argument as
+          the 'Enum' property of this option) that stores the value of
+          the argument.
+
+        * If the option has the 'Defer' property, VAR is a pointer to a
+          'VEC(cl_deferred_option,heap)' that stores the option for
+          later processing.  (VAR is declared with type 'void *' and
+          needs to be cast to 'VEC(cl_deferred_option,heap)' before
+          use.)
+
+        * Otherwise, if the option takes an argument, VAR is a pointer
+          to the argument string.  The pointer will be null if the
+          argument is optional and wasn't given.
+
+     The option-processing script will usually zero-initialize VAR.  You
+     can modify this behavior using 'Init'.
+
+'Var(VAR, SET)'
+     The option controls an integer variable VAR and is active when VAR
+     equals SET.  The option parser will set VAR to SET when the
+     positive form of the option is used and '!SET' when the "no-" form
+     is used.
+
+     VAR is declared in the same way as for the single-argument form
+     described above.
+
+'Init(VALUE)'
+     The variable specified by the 'Var' property should be statically
+     initialized to VALUE.  If more than one option using the same
+     variable specifies 'Init', all must specify the same initializer.
+
+'Mask(NAME)'
+     The option is associated with a bit in the 'target_flags' variable
+     (*note Run-time Target::) and is active when that bit is set.  You
+     may also specify 'Var' to select a variable other than
+     'target_flags'.
+
+     The options-processing script will automatically allocate a unique
+     bit for the option.  If the option is attached to 'target_flags',
+     the script will set the macro 'MASK_NAME' to the appropriate
+     bitmask.  It will also declare a 'TARGET_NAME' macro that has the
+     value 1 when the option is active and 0 otherwise.  If you use
+     'Var' to attach the option to a different variable, the bitmask
+     macro with be called 'OPTION_MASK_NAME'.
+
+'InverseMask(OTHERNAME)'
+'InverseMask(OTHERNAME, THISNAME)'
+     The option is the inverse of another option that has the
+     'Mask(OTHERNAME)' property.  If THISNAME is given, the
+     options-processing script will declare a 'TARGET_THISNAME' macro
+     that is 1 when the option is active and 0 otherwise.
+
+'Enum(NAME)'
+     The option's argument is a string from the set of strings
+     associated with the corresponding 'Enum' record.  The string is
+     checked and converted to the integer specified in the corresponding
+     'EnumValue' record before being passed to option handlers.
+
+'Defer'
+     The option should be stored in a vector, specified with 'Var', for
+     later processing.
+
+'Alias(OPT)'
+'Alias(OPT, ARG)'
+'Alias(OPT, POSARG, NEGARG)'
+     The option is an alias for '-OPT' (or the negative form of that
+     option, depending on 'NegativeAlias').  In the first form, any
+     argument passed to the alias is considered to be passed to '-OPT',
+     and '-OPT' is considered to be negated if the alias is used in
+     negated form.  In the second form, the alias may not be negated or
+     have an argument, and POSARG is considered to be passed as an
+     argument to '-OPT'.  In the third form, the alias may not have an
+     argument, if the alias is used in the positive form then POSARG is
+     considered to be passed to '-OPT', and if the alias is used in the
+     negative form then NEGARG is considered to be passed to '-OPT'.
+
+     Aliases should not specify 'Var' or 'Mask' or 'UInteger'.  Aliases
+     should normally specify the same languages as the target of the
+     alias; the flags on the target will be used to determine any
+     diagnostic for use of an option for the wrong language, while those
+     on the alias will be used to identify what command-line text is the
+     option and what text is any argument to that option.
+
+     When an 'Alias' definition is used for an option, driver specs do
+     not need to handle it and no 'OPT_' enumeration value is defined
+     for it; only the canonical form of the option will be seen in those
+     places.
+
+'NegativeAlias'
+     For an option marked with 'Alias(OPT)', the option is considered to
+     be an alias for the positive form of '-OPT' if negated and for the
+     negative form of '-OPT' if not negated.  'NegativeAlias' may not be
+     used with the forms of 'Alias' taking more than one argument.
+
+'Ignore'
+     This option is ignored apart from printing any warning specified
+     using 'Warn'.  The option will not be seen by specs and no 'OPT_'
+     enumeration value is defined for it.
+
+'SeparateAlias'
+     For an option marked with 'Joined', 'Separate' and 'Alias', the
+     option only acts as an alias when passed a separate argument; with
+     a joined argument it acts as a normal option, with an 'OPT_'
+     enumeration value.  This is for compatibility with the Java '-d'
+     option and should not be used for new options.
+
+'Warn(MESSAGE)'
+     If this option is used, output the warning MESSAGE.  MESSAGE is a
+     format string, either taking a single operand with a '%qs' format
+     which is the option name, or not taking any operands, which is
+     passed to the 'warning' function.  If an alias is marked 'Warn',
+     the target of the alias must not also be marked 'Warn'.
+
+'Report'
+     The state of the option should be printed by '-fverbose-asm'.
+
+'Warning'
+     This is a warning option and should be shown as such in '--help'
+     output.  This flag does not currently affect anything other than
+     '--help'.
+
+'Optimization'
+     This is an optimization option.  It should be shown as such in
+     '--help' output, and any associated variable named using 'Var'
+     should be saved and restored when the optimization level is changed
+     with 'optimize' attributes.
+
+'Undocumented'
+     The option is deliberately missing documentation and should not be
+     included in the '--help' output.
+
+'Condition(COND)'
+     The option should only be accepted if preprocessor condition COND
+     is true.  Note that any C declarations associated with the option
+     will be present even if COND is false; COND simply controls whether
+     the option is accepted and whether it is printed in the '--help'
+     output.
+
+'Save'
+     Build the 'cl_target_option' structure to hold a copy of the
+     option, add the functions 'cl_target_option_save' and
+     'cl_target_option_restore' to save and restore the options.
+
+'SetByCombined'
+     The option may also be set by a combined option such as
+     '-ffast-math'.  This causes the 'gcc_options' struct to have a
+     field 'frontend_set_NAME', where 'NAME' is the name of the field
+     holding the value of this option (without the leading 'x_').  This
+     gives the front end a way to indicate that the value has been set
+     explicitly and should not be changed by the combined option.  For
+     example, some front ends use this to prevent '-ffast-math' and
+     '-fno-fast-math' from changing the value of '-fmath-errno' for
+     languages that do not use 'errno'.
+
+'EnabledBy(OPT)'
+'EnabledBy(OPT && OPT2)'
+     If not explicitly set, the option is set to the value of '-OPT'.
+     The second form specifies that the option is only set if both OPT
+     and OPT2 are set.
+
+'LangEnabledBy(LANGUAGE, OPT)'
+'LangEnabledBy(LANGUAGE, OPT, POSARG, NEGARG)'
+     When compiling for the given language, the option is set to the
+     value of '-OPT', if not explicitly set.  In the second form, if OPT
+     is used in the positive form then POSARG is considered to be passed
+     to the option, and if OPT is used in the negative form then NEGARG
+     is considered to be passed to the option.  It is possible to
+     specify several different languages.  Each LANGUAGE must have been
+     declared by an earlier 'Language' record.  *Note Option file
+     format::.
+
+'NoDWARFRecord'
+     The option is omitted from the producer string written by
+     '-grecord-gcc-switches'.
+
+'PchIgnore'
+     Even if this is a target option, this option will not be recorded /
+     compared to determine if a precompiled header file matches.
+
+
+File: gccint.info,  Node: Passes,  Next: GENERIC,  Prev: Options,  Up: Top
+
+9 Passes and Files of the Compiler
+**********************************
+
+This chapter is dedicated to giving an overview of the optimization and
+code generation passes of the compiler.  In the process, it describes
+some of the language front end interface, though this description is no
+where near complete.
+
+* Menu:
+
+* Parsing pass::         The language front end turns text into bits.
+* Cilk Plus Transformation:: Transform Cilk Plus Code to equivalent C/C++.
+* Gimplification pass::  The bits are turned into something we can optimize.
+* Pass manager::         Sequencing the optimization passes.
+* Tree SSA passes::      Optimizations on a high-level representation.
+* RTL passes::           Optimizations on a low-level representation.
+* Optimization info::    Dumping optimization information from passes.
+
+
+File: gccint.info,  Node: Parsing pass,  Next: Cilk Plus Transformation,  Up: Passes
+
+9.1 Parsing pass
+================
+
+The language front end is invoked only once, via
+'lang_hooks.parse_file', to parse the entire input.  The language front
+end may use any intermediate language representation deemed appropriate.
+The C front end uses GENERIC trees (*note GENERIC::), plus a double
+handful of language specific tree codes defined in 'c-common.def'.  The
+Fortran front end uses a completely different private representation.
+
+ At some point the front end must translate the representation used in
+the front end to a representation understood by the language-independent
+portions of the compiler.  Current practice takes one of two forms.  The
+C front end manually invokes the gimplifier (*note GIMPLE::) on each
+function, and uses the gimplifier callbacks to convert the
+language-specific tree nodes directly to GIMPLE before passing the
+function off to be compiled.  The Fortran front end converts from a
+private representation to GENERIC, which is later lowered to GIMPLE when
+the function is compiled.  Which route to choose probably depends on how
+well GENERIC (plus extensions) can be made to match up with the source
+language and necessary parsing data structures.
+
+ BUG: Gimplification must occur before nested function lowering, and
+nested function lowering must be done by the front end before passing
+the data off to cgraph.
+
+ TODO: Cgraph should control nested function lowering.  It would only be
+invoked when it is certain that the outer-most function is used.
+
+ TODO: Cgraph needs a gimplify_function callback.  It should be invoked
+when (1) it is certain that the function is used, (2) warning flags
+specified by the user require some amount of compilation in order to
+honor, (3) the language indicates that semantic analysis is not complete
+until gimplification occurs.  Hum... this sounds overly complicated.
+Perhaps we should just have the front end gimplify always; in most cases
+it's only one function call.
+
+ The front end needs to pass all function definitions and top level
+declarations off to the middle-end so that they can be compiled and
+emitted to the object file.  For a simple procedural language, it is
+usually most convenient to do this as each top level declaration or
+definition is seen.  There is also a distinction to be made between
+generating functional code and generating complete debug information.
+The only thing that is absolutely required for functional code is that
+function and data _definitions_ be passed to the middle-end.  For
+complete debug information, function, data and type declarations should
+all be passed as well.
+
+ In any case, the front end needs each complete top-level function or
+data declaration, and each data definition should be passed to
+'rest_of_decl_compilation'.  Each complete type definition should be
+passed to 'rest_of_type_compilation'.  Each function definition should
+be passed to 'cgraph_finalize_function'.
+
+ TODO: I know rest_of_compilation currently has all sorts of RTL
+generation semantics.  I plan to move all code generation bits (both
+Tree and RTL) to compile_function.  Should we hide cgraph from the front
+ends and move back to rest_of_compilation as the official interface?
+Possibly we should rename all three interfaces such that the names match
+in some meaningful way and that is more descriptive than "rest_of".
+
+ The middle-end will, at its option, emit the function and data
+definitions immediately or queue them for later processing.
+
+
+File: gccint.info,  Node: Cilk Plus Transformation,  Next: Gimplification pass,  Prev: Parsing pass,  Up: Passes
+
+9.2 Cilk Plus Transformation
+============================
+
+If Cilk Plus generation (flag '-fcilkplus') is enabled, all the Cilk
+Plus code is transformed into equivalent C and C++ functions.  Majority
+of this transformation occurs toward the end of the parsing and right
+before the gimplification pass.
+
+ These are the major components to the Cilk Plus language extension:
+   * Array Notations: During parsing phase, all the array notation
+     specific information is stored in 'ARRAY_NOTATION_REF' tree using
+     the function 'c_parser_array_notation'.  During the end of parsing,
+     we check the entire function to see if there are any array notation
+     specific code (using the function 'contains_array_notation_expr').
+     If this function returns true, then we expand them using either
+     'expand_array_notation_exprs' or 'build_array_notation_expr'.  For
+     the cases where array notations are inside conditions, they are
+     transformed using the function 'fix_conditional_array_notations'.
+     The C language-specific routines are located in
+     'c/c-array-notation.c' and the equivalent C++ routines are in the
+     file 'cp/cp-array-notation.c'.  Common routines such as functions
+     to initialize built-in functions are stored in
+     'array-notation-common.c'.
+
+   * Cilk keywords:
+        * '_Cilk_spawn': The '_Cilk_spawn' keyword is parsed and the
+          function it contains is marked as a spawning function.  The
+          spawning function is called the spawner.  At the end of the
+          parsing phase, appropriate built-in functions are added to the
+          spawner that are defined in the Cilk runtime.  The appropriate
+          locations of these functions, and the internal structures are
+          detailed in 'cilk_init_builtins' in the file 'cilk-common.c'.
+          The pointers to Cilk functions and fields of internal
+          structures are described in 'cilk.h'.  The built-in functions
+          are described in 'cilk-builtins.def'.
+
+          During gimplification, a new "spawn-helper" function is
+          created.  The spawned function is replaced with a spawn helper
+          function in the spawner.  The spawned function-call is moved
+          into the spawn helper.  The main function that does these
+          transformations is 'gimplify_cilk_spawn' in 'c-family/cilk.c'.
+          In the spawn-helper, the gimplification function
+          'gimplify_call_expr', inserts a function call
+          '__cilkrts_detach'.  This function is expanded by
+          'builtin_expand_cilk_detach' located in 'c-family/cilk.c'.
+
+        * '_Cilk_sync': '_Cilk_sync' is parsed like a keyword.  During
+          gimplification, the function 'gimplify_cilk_sync' in
+          'c-family/cilk.c', will replace this keyword with a set of
+          functions that are stored in the Cilk runtime.  One of the
+          internal functions inserted during gimplification,
+          '__cilkrts_pop_frame' must be expanded by the compiler and is
+          done by 'builtin_expand_cilk_pop_frame' in 'cilk-common.c'.
+
+ Documentation about Cilk Plus and language specification is provided
+under the "Learn" section in <http://www.cilkplus.org/>.  It is worth
+mentioning that the current implementation follows ABI 1.1.
+
+
+File: gccint.info,  Node: Gimplification pass,  Next: Pass manager,  Prev: Cilk Plus Transformation,  Up: Passes
+
+9.3 Gimplification pass
+=======================
+
+"Gimplification" is a whimsical term for the process of converting the
+intermediate representation of a function into the GIMPLE language
+(*note GIMPLE::).  The term stuck, and so words like "gimplification",
+"gimplify", "gimplifier" and the like are sprinkled throughout this
+section of code.
+
+ While a front end may certainly choose to generate GIMPLE directly if
+it chooses, this can be a moderately complex process unless the
+intermediate language used by the front end is already fairly simple.
+Usually it is easier to generate GENERIC trees plus extensions and let
+the language-independent gimplifier do most of the work.
+
+ The main entry point to this pass is 'gimplify_function_tree' located
+in 'gimplify.c'.  From here we process the entire function gimplifying
+each statement in turn.  The main workhorse for this pass is
+'gimplify_expr'.  Approximately everything passes through here at least
+once, and it is from here that we invoke the 'lang_hooks.gimplify_expr'
+callback.
+
+ The callback should examine the expression in question and return
+'GS_UNHANDLED' if the expression is not a language specific construct
+that requires attention.  Otherwise it should alter the expression in
+some way to such that forward progress is made toward producing valid
+GIMPLE.  If the callback is certain that the transformation is complete
+and the expression is valid GIMPLE, it should return 'GS_ALL_DONE'.
+Otherwise it should return 'GS_OK', which will cause the expression to
+be processed again.  If the callback encounters an error during the
+transformation (because the front end is relying on the gimplification
+process to finish semantic checks), it should return 'GS_ERROR'.
+
+
+File: gccint.info,  Node: Pass manager,  Next: Tree SSA passes,  Prev: Gimplification pass,  Up: Passes
+
+9.4 Pass manager
+================
+
+The pass manager is located in 'passes.c', 'tree-optimize.c' and
+'tree-pass.h'.  It processes passes as described in 'passes.def'.  Its
+job is to run all of the individual passes in the correct order, and
+take care of standard bookkeeping that applies to every pass.
+
+ The theory of operation is that each pass defines a structure that
+represents everything we need to know about that pass--when it should be
+run, how it should be run, what intermediate language form or
+on-the-side data structures it needs.  We register the pass to be run in
+some particular order, and the pass manager arranges for everything to
+happen in the correct order.
+
+ The actuality doesn't completely live up to the theory at present.
+Command-line switches and 'timevar_id_t' enumerations must still be
+defined elsewhere.  The pass manager validates constraints but does not
+attempt to (re-)generate data structures or lower intermediate language
+form based on the requirements of the next pass.  Nevertheless, what is
+present is useful, and a far sight better than nothing at all.
+
+ Each pass should have a unique name.  Each pass may have its own dump
+file (for GCC debugging purposes).  Passes with a name starting with a
+star do not dump anything.  Sometimes passes are supposed to share a
+dump file / option name.  To still give these unique names, you can use
+a prefix that is delimited by a space from the part that is used for the
+dump file / option name.  E.g.  When the pass name is "ud dce", the name
+used for dump file/options is "dce".
+
+ TODO: describe the global variables set up by the pass manager, and a
+brief description of how a new pass should use it.  I need to look at
+what info RTL passes use first...
+
+
+File: gccint.info,  Node: Tree SSA passes,  Next: RTL passes,  Prev: Pass manager,  Up: Passes
+
+9.5 Tree SSA passes
+===================
+
+The following briefly describes the Tree optimization passes that are
+run after gimplification and what source files they are located in.
+
+   * Remove useless statements
+
+     This pass is an extremely simple sweep across the gimple code in
+     which we identify obviously dead code and remove it.  Here we do
+     things like simplify 'if' statements with constant conditions,
+     remove exception handling constructs surrounding code that
+     obviously cannot throw, remove lexical bindings that contain no
+     variables, and other assorted simplistic cleanups.  The idea is to
+     get rid of the obvious stuff quickly rather than wait until later
+     when it's more work to get rid of it.  This pass is located in
+     'tree-cfg.c' and described by 'pass_remove_useless_stmts'.
+
+   * OpenMP lowering
+
+     If OpenMP generation ('-fopenmp') is enabled, this pass lowers
+     OpenMP constructs into GIMPLE.
+
+     Lowering of OpenMP constructs involves creating replacement
+     expressions for local variables that have been mapped using data
+     sharing clauses, exposing the control flow of most synchronization
+     directives and adding region markers to facilitate the creation of
+     the control flow graph.  The pass is located in 'omp-low.c' and is
+     described by 'pass_lower_omp'.
+
+   * OpenMP expansion
+
+     If OpenMP generation ('-fopenmp') is enabled, this pass expands
+     parallel regions into their own functions to be invoked by the
+     thread library.  The pass is located in 'omp-low.c' and is
+     described by 'pass_expand_omp'.
+
+   * Lower control flow
+
+     This pass flattens 'if' statements ('COND_EXPR') and moves lexical
+     bindings ('BIND_EXPR') out of line.  After this pass, all 'if'
+     statements will have exactly two 'goto' statements in its 'then'
+     and 'else' arms.  Lexical binding information for each statement
+     will be found in 'TREE_BLOCK' rather than being inferred from its
+     position under a 'BIND_EXPR'.  This pass is found in 'gimple-low.c'
+     and is described by 'pass_lower_cf'.
+
+   * Lower exception handling control flow
+
+     This pass decomposes high-level exception handling constructs
+     ('TRY_FINALLY_EXPR' and 'TRY_CATCH_EXPR') into a form that
+     explicitly represents the control flow involved.  After this pass,
+     'lookup_stmt_eh_region' will return a non-negative number for any
+     statement that may have EH control flow semantics; examine
+     'tree_can_throw_internal' or 'tree_can_throw_external' for exact
+     semantics.  Exact control flow may be extracted from
+     'foreach_reachable_handler'.  The EH region nesting tree is defined
+     in 'except.h' and built in 'except.c'.  The lowering pass itself is
+     in 'tree-eh.c' and is described by 'pass_lower_eh'.
+
+   * Build the control flow graph
+
+     This pass decomposes a function into basic blocks and creates all
+     of the edges that connect them.  It is located in 'tree-cfg.c' and
+     is described by 'pass_build_cfg'.
+
+   * Find all referenced variables
+
+     This pass walks the entire function and collects an array of all
+     variables referenced in the function, 'referenced_vars'.  The index
+     at which a variable is found in the array is used as a UID for the
+     variable within this function.  This data is needed by the SSA
+     rewriting routines.  The pass is located in 'tree-dfa.c' and is
+     described by 'pass_referenced_vars'.
+
+   * Enter static single assignment form
+
+     This pass rewrites the function such that it is in SSA form.  After
+     this pass, all 'is_gimple_reg' variables will be referenced by
+     'SSA_NAME', and all occurrences of other variables will be
+     annotated with 'VDEFS' and 'VUSES'; PHI nodes will have been
+     inserted as necessary for each basic block.  This pass is located
+     in 'tree-ssa.c' and is described by 'pass_build_ssa'.
+
+   * Warn for uninitialized variables
+
+     This pass scans the function for uses of 'SSA_NAME's that are fed
+     by default definition.  For non-parameter variables, such uses are
+     uninitialized.  The pass is run twice, before and after
+     optimization (if turned on).  In the first pass we only warn for
+     uses that are positively uninitialized; in the second pass we warn
+     for uses that are possibly uninitialized.  The pass is located in
+     'tree-ssa.c' and is defined by 'pass_early_warn_uninitialized' and
+     'pass_late_warn_uninitialized'.
+
+   * Dead code elimination
+
+     This pass scans the function for statements without side effects
+     whose result is unused.  It does not do memory life analysis, so
+     any value that is stored in memory is considered used.  The pass is
+     run multiple times throughout the optimization process.  It is
+     located in 'tree-ssa-dce.c' and is described by 'pass_dce'.
+
+   * Dominator optimizations
+
+     This pass performs trivial dominator-based copy and constant
+     propagation, expression simplification, and jump threading.  It is
+     run multiple times throughout the optimization process.  It is
+     located in 'tree-ssa-dom.c' and is described by 'pass_dominator'.
+
+   * Forward propagation of single-use variables
+
+     This pass attempts to remove redundant computation by substituting
+     variables that are used once into the expression that uses them and
+     seeing if the result can be simplified.  It is located in
+     'tree-ssa-forwprop.c' and is described by 'pass_forwprop'.
+
+   * Copy Renaming
+
+     This pass attempts to change the name of compiler temporaries
+     involved in copy operations such that SSA->normal can coalesce the
+     copy away.  When compiler temporaries are copies of user variables,
+     it also renames the compiler temporary to the user variable
+     resulting in better use of user symbols.  It is located in
+     'tree-ssa-copyrename.c' and is described by 'pass_copyrename'.
+
+   * PHI node optimizations
+
+     This pass recognizes forms of PHI inputs that can be represented as
+     conditional expressions and rewrites them into straight line code.
+     It is located in 'tree-ssa-phiopt.c' and is described by
+     'pass_phiopt'.
+
+   * May-alias optimization
+
+     This pass performs a flow sensitive SSA-based points-to analysis.
+     The resulting may-alias, must-alias, and escape analysis
+     information is used to promote variables from in-memory addressable
+     objects to non-aliased variables that can be renamed into SSA form.
+     We also update the 'VDEF'/'VUSE' memory tags for non-renameable
+     aggregates so that we get fewer false kills.  The pass is located
+     in 'tree-ssa-alias.c' and is described by 'pass_may_alias'.
+
+     Interprocedural points-to information is located in
+     'tree-ssa-structalias.c' and described by 'pass_ipa_pta'.
+
+   * Profiling
+
+     This pass rewrites the function in order to collect runtime block
+     and value profiling data.  Such data may be fed back into the
+     compiler on a subsequent run so as to allow optimization based on
+     expected execution frequencies.  The pass is located in 'predict.c'
+     and is described by 'pass_profile'.
+
+   * Lower complex arithmetic
+
+     This pass rewrites complex arithmetic operations into their
+     component scalar arithmetic operations.  The pass is located in
+     'tree-complex.c' and is described by 'pass_lower_complex'.
+
+   * Scalar replacement of aggregates
+
+     This pass rewrites suitable non-aliased local aggregate variables
+     into a set of scalar variables.  The resulting scalar variables are
+     rewritten into SSA form, which allows subsequent optimization
+     passes to do a significantly better job with them.  The pass is
+     located in 'tree-sra.c' and is described by 'pass_sra'.
+
+   * Dead store elimination
+
+     This pass eliminates stores to memory that are subsequently
+     overwritten by another store, without any intervening loads.  The
+     pass is located in 'tree-ssa-dse.c' and is described by 'pass_dse'.
+
+   * Tail recursion elimination
+
+     This pass transforms tail recursion into a loop.  It is located in
+     'tree-tailcall.c' and is described by 'pass_tail_recursion'.
+
+   * Forward store motion
+
+     This pass sinks stores and assignments down the flowgraph closer to
+     their use point.  The pass is located in 'tree-ssa-sink.c' and is
+     described by 'pass_sink_code'.
+
+   * Partial redundancy elimination
+
+     This pass eliminates partially redundant computations, as well as
+     performing load motion.  The pass is located in 'tree-ssa-pre.c'
+     and is described by 'pass_pre'.
+
+     Just before partial redundancy elimination, if
+     '-funsafe-math-optimizations' is on, GCC tries to convert divisions
+     to multiplications by the reciprocal.  The pass is located in
+     'tree-ssa-math-opts.c' and is described by 'pass_cse_reciprocal'.
+
+   * Full redundancy elimination
+
+     This is a simpler form of PRE that only eliminates redundancies
+     that occur on all paths.  It is located in 'tree-ssa-pre.c' and
+     described by 'pass_fre'.
+
+   * Loop optimization
+
+     The main driver of the pass is placed in 'tree-ssa-loop.c' and
+     described by 'pass_loop'.
+
+     The optimizations performed by this pass are:
+
+     Loop invariant motion.  This pass moves only invariants that would
+     be hard to handle on RTL level (function calls, operations that
+     expand to nontrivial sequences of insns).  With '-funswitch-loops'
+     it also moves operands of conditions that are invariant out of the
+     loop, so that we can use just trivial invariantness analysis in
+     loop unswitching.  The pass also includes store motion.  The pass
+     is implemented in 'tree-ssa-loop-im.c'.
+
+     Canonical induction variable creation.  This pass creates a simple
+     counter for number of iterations of the loop and replaces the exit
+     condition of the loop using it, in case when a complicated analysis
+     is necessary to determine the number of iterations.  Later
+     optimizations then may determine the number easily.  The pass is
+     implemented in 'tree-ssa-loop-ivcanon.c'.
+
+     Induction variable optimizations.  This pass performs standard
+     induction variable optimizations, including strength reduction,
+     induction variable merging and induction variable elimination.  The
+     pass is implemented in 'tree-ssa-loop-ivopts.c'.
+
+     Loop unswitching.  This pass moves the conditional jumps that are
+     invariant out of the loops.  To achieve this, a duplicate of the
+     loop is created for each possible outcome of conditional jump(s).
+     The pass is implemented in 'tree-ssa-loop-unswitch.c'.  This pass
+     should eventually replace the RTL level loop unswitching in
+     'loop-unswitch.c', but currently the RTL level pass is not
+     completely redundant yet due to deficiencies in tree level alias
+     analysis.
+
+     The optimizations also use various utility functions contained in
+     'tree-ssa-loop-manip.c', 'cfgloop.c', 'cfgloopanal.c' and
+     'cfgloopmanip.c'.
+
+     Vectorization.  This pass transforms loops to operate on vector
+     types instead of scalar types.  Data parallelism across loop
+     iterations is exploited to group data elements from consecutive
+     iterations into a vector and operate on them in parallel.
+     Depending on available target support the loop is conceptually
+     unrolled by a factor 'VF' (vectorization factor), which is the
+     number of elements operated upon in parallel in each iteration, and
+     the 'VF' copies of each scalar operation are fused to form a vector
+     operation.  Additional loop transformations such as peeling and
+     versioning may take place to align the number of iterations, and to
+     align the memory accesses in the loop.  The pass is implemented in
+     'tree-vectorizer.c' (the main driver), 'tree-vect-loop.c' and
+     'tree-vect-loop-manip.c' (loop specific parts and general loop
+     utilities), 'tree-vect-slp' (loop-aware SLP functionality),
+     'tree-vect-stmts.c' and 'tree-vect-data-refs.c'.  Analysis of data
+     references is in 'tree-data-ref.c'.
+
+     SLP Vectorization.  This pass performs vectorization of
+     straight-line code.  The pass is implemented in 'tree-vectorizer.c'
+     (the main driver), 'tree-vect-slp.c', 'tree-vect-stmts.c' and
+     'tree-vect-data-refs.c'.
+
+     Autoparallelization.  This pass splits the loop iteration space to
+     run into several threads.  The pass is implemented in
+     'tree-parloops.c'.
+
+     Graphite is a loop transformation framework based on the polyhedral
+     model.  Graphite stands for Gimple Represented as Polyhedra.  The
+     internals of this infrastructure are documented in
+     <http://gcc.gnu.org/wiki/Graphite>.  The passes working on this
+     representation are implemented in the various 'graphite-*' files.
+
+   * Tree level if-conversion for vectorizer
+
+     This pass applies if-conversion to simple loops to help vectorizer.
+     We identify if convertible loops, if-convert statements and merge
+     basic blocks in one big block.  The idea is to present loop in such
+     form so that vectorizer can have one to one mapping between
+     statements and available vector operations.  This pass is located
+     in 'tree-if-conv.c' and is described by 'pass_if_conversion'.
+
+   * Conditional constant propagation
+
+     This pass relaxes a lattice of values in order to identify those
+     that must be constant even in the presence of conditional branches.
+     The pass is located in 'tree-ssa-ccp.c' and is described by
+     'pass_ccp'.
+
+     A related pass that works on memory loads and stores, and not just
+     register values, is located in 'tree-ssa-ccp.c' and described by
+     'pass_store_ccp'.
+
+   * Conditional copy propagation
+
+     This is similar to constant propagation but the lattice of values
+     is the "copy-of" relation.  It eliminates redundant copies from the
+     code.  The pass is located in 'tree-ssa-copy.c' and described by
+     'pass_copy_prop'.
+
+     A related pass that works on memory copies, and not just register
+     copies, is located in 'tree-ssa-copy.c' and described by
+     'pass_store_copy_prop'.
+
+   * Value range propagation
+
+     This transformation is similar to constant propagation but instead
+     of propagating single constant values, it propagates known value
+     ranges.  The implementation is based on Patterson's range
+     propagation algorithm (Accurate Static Branch Prediction by Value
+     Range Propagation, J. R. C. Patterson, PLDI '95).  In contrast to
+     Patterson's algorithm, this implementation does not propagate
+     branch probabilities nor it uses more than a single range per SSA
+     name.  This means that the current implementation cannot be used
+     for branch prediction (though adapting it would not be difficult).
+     The pass is located in 'tree-vrp.c' and is described by 'pass_vrp'.
+
+   * Folding built-in functions
+
+     This pass simplifies built-in functions, as applicable, with
+     constant arguments or with inferable string lengths.  It is located
+     in 'tree-ssa-ccp.c' and is described by 'pass_fold_builtins'.
+
+   * Split critical edges
+
+     This pass identifies critical edges and inserts empty basic blocks
+     such that the edge is no longer critical.  The pass is located in
+     'tree-cfg.c' and is described by 'pass_split_crit_edges'.
+
+   * Control dependence dead code elimination
+
+     This pass is a stronger form of dead code elimination that can
+     eliminate unnecessary control flow statements.  It is located in
+     'tree-ssa-dce.c' and is described by 'pass_cd_dce'.
+
+   * Tail call elimination
+
+     This pass identifies function calls that may be rewritten into
+     jumps.  No code transformation is actually applied here, but the
+     data and control flow problem is solved.  The code transformation
+     requires target support, and so is delayed until RTL.  In the
+     meantime 'CALL_EXPR_TAILCALL' is set indicating the possibility.
+     The pass is located in 'tree-tailcall.c' and is described by
+     'pass_tail_calls'.  The RTL transformation is handled by
+     'fixup_tail_calls' in 'calls.c'.
+
+   * Warn for function return without value
+
+     For non-void functions, this pass locates return statements that do
+     not specify a value and issues a warning.  Such a statement may
+     have been injected by falling off the end of the function.  This
+     pass is run last so that we have as much time as possible to prove
+     that the statement is not reachable.  It is located in 'tree-cfg.c'
+     and is described by 'pass_warn_function_return'.
+
+   * Leave static single assignment form
+
+     This pass rewrites the function such that it is in normal form.  At
+     the same time, we eliminate as many single-use temporaries as
+     possible, so the intermediate language is no longer GIMPLE, but
+     GENERIC.  The pass is located in 'tree-outof-ssa.c' and is
+     described by 'pass_del_ssa'.
+
+   * Merge PHI nodes that feed into one another
+
+     This is part of the CFG cleanup passes.  It attempts to join PHI
+     nodes from a forwarder CFG block into another block with PHI nodes.
+     The pass is located in 'tree-cfgcleanup.c' and is described by
+     'pass_merge_phi'.
+
+   * Return value optimization
+
+     If a function always returns the same local variable, and that
+     local variable is an aggregate type, then the variable is replaced
+     with the return value for the function (i.e., the function's
+     DECL_RESULT). This is equivalent to the C++ named return value
+     optimization applied to GIMPLE.  The pass is located in
+     'tree-nrv.c' and is described by 'pass_nrv'.
+
+   * Return slot optimization
+
+     If a function returns a memory object and is called as 'var =
+     foo()', this pass tries to change the call so that the address of
+     'var' is sent to the caller to avoid an extra memory copy.  This
+     pass is located in 'tree-nrv.c' and is described by
+     'pass_return_slot'.
+
+   * Optimize calls to '__builtin_object_size'
+
+     This is a propagation pass similar to CCP that tries to remove
+     calls to '__builtin_object_size' when the size of the object can be
+     computed at compile-time.  This pass is located in
+     'tree-object-size.c' and is described by 'pass_object_sizes'.
+
+   * Loop invariant motion
+
+     This pass removes expensive loop-invariant computations out of
+     loops.  The pass is located in 'tree-ssa-loop.c' and described by
+     'pass_lim'.
+
+   * Loop nest optimizations
+
+     This is a family of loop transformations that works on loop nests.
+     It includes loop interchange, scaling, skewing and reversal and
+     they are all geared to the optimization of data locality in array
+     traversals and the removal of dependencies that hamper
+     optimizations such as loop parallelization and vectorization.  The
+     pass is located in 'tree-loop-linear.c' and described by
+     'pass_linear_transform'.
+
+   * Removal of empty loops
+
+     This pass removes loops with no code in them.  The pass is located
+     in 'tree-ssa-loop-ivcanon.c' and described by 'pass_empty_loop'.
+
+   * Unrolling of small loops
+
+     This pass completely unrolls loops with few iterations.  The pass
+     is located in 'tree-ssa-loop-ivcanon.c' and described by
+     'pass_complete_unroll'.
+
+   * Predictive commoning
+
+     This pass makes the code reuse the computations from the previous
+     iterations of the loops, especially loads and stores to memory.  It
+     does so by storing the values of these computations to a bank of
+     temporary variables that are rotated at the end of loop.  To avoid
+     the need for this rotation, the loop is then unrolled and the
+     copies of the loop body are rewritten to use the appropriate
+     version of the temporary variable.  This pass is located in
+     'tree-predcom.c' and described by 'pass_predcom'.
+
+   * Array prefetching
+
+     This pass issues prefetch instructions for array references inside
+     loops.  The pass is located in 'tree-ssa-loop-prefetch.c' and
+     described by 'pass_loop_prefetch'.
+
+   * Reassociation
+
+     This pass rewrites arithmetic expressions to enable optimizations
+     that operate on them, like redundancy elimination and
+     vectorization.  The pass is located in 'tree-ssa-reassoc.c' and
+     described by 'pass_reassoc'.
+
+   * Optimization of 'stdarg' functions
+
+     This pass tries to avoid the saving of register arguments into the
+     stack on entry to 'stdarg' functions.  If the function doesn't use
+     any 'va_start' macros, no registers need to be saved.  If
+     'va_start' macros are used, the 'va_list' variables don't escape
+     the function, it is only necessary to save registers that will be
+     used in 'va_arg' macros.  For instance, if 'va_arg' is only used
+     with integral types in the function, floating point registers don't
+     need to be saved.  This pass is located in 'tree-stdarg.c' and
+     described by 'pass_stdarg'.
+
+
+File: gccint.info,  Node: RTL passes,  Next: Optimization info,  Prev: Tree SSA passes,  Up: Passes
+
+9.6 RTL passes
+==============
+
+The following briefly describes the RTL generation and optimization
+passes that are run after the Tree optimization passes.
+
+   * RTL generation
+
+     The source files for RTL generation include 'stmt.c', 'calls.c',
+     'expr.c', 'explow.c', 'expmed.c', 'function.c', 'optabs.c' and
+     'emit-rtl.c'.  Also, the file 'insn-emit.c', generated from the
+     machine description by the program 'genemit', is used in this pass.
+     The header file 'expr.h' is used for communication within this
+     pass.
+
+     The header files 'insn-flags.h' and 'insn-codes.h', generated from
+     the machine description by the programs 'genflags' and 'gencodes',
+     tell this pass which standard names are available for use and which
+     patterns correspond to them.
+
+   * Generation of exception landing pads
+
+     This pass generates the glue that handles communication between the
+     exception handling library routines and the exception handlers
+     within the function.  Entry points in the function that are invoked
+     by the exception handling library are called "landing pads".  The
+     code for this pass is located in 'except.c'.
+
+   * Control flow graph cleanup
+
+     This pass removes unreachable code, simplifies jumps to next, jumps
+     to jump, jumps across jumps, etc.  The pass is run multiple times.
+     For historical reasons, it is occasionally referred to as the "jump
+     optimization pass".  The bulk of the code for this pass is in
+     'cfgcleanup.c', and there are support routines in 'cfgrtl.c' and
+     'jump.c'.
+
+   * Forward propagation of single-def values
+
+     This pass attempts to remove redundant computation by substituting
+     variables that come from a single definition, and seeing if the
+     result can be simplified.  It performs copy propagation and
+     addressing mode selection.  The pass is run twice, with values
+     being propagated into loops only on the second run.  The code is
+     located in 'fwprop.c'.
+
+   * Common subexpression elimination
+
+     This pass removes redundant computation within basic blocks, and
+     optimizes addressing modes based on cost.  The pass is run twice.
+     The code for this pass is located in 'cse.c'.
+
+   * Global common subexpression elimination
+
+     This pass performs two different types of GCSE depending on whether
+     you are optimizing for size or not (LCM based GCSE tends to
+     increase code size for a gain in speed, while Morel-Renvoise based
+     GCSE does not).  When optimizing for size, GCSE is done using
+     Morel-Renvoise Partial Redundancy Elimination, with the exception
+     that it does not try to move invariants out of loops--that is left
+     to the loop optimization pass.  If MR PRE GCSE is done, code
+     hoisting (aka unification) is also done, as well as load motion.
+     If you are optimizing for speed, LCM (lazy code motion) based GCSE
+     is done.  LCM is based on the work of Knoop, Ruthing, and Steffen.
+     LCM based GCSE also does loop invariant code motion.  We also
+     perform load and store motion when optimizing for speed.
+     Regardless of which type of GCSE is used, the GCSE pass also
+     performs global constant and copy propagation.  The source file for
+     this pass is 'gcse.c', and the LCM routines are in 'lcm.c'.
+
+   * Loop optimization
+
+     This pass performs several loop related optimizations.  The source
+     files 'cfgloopanal.c' and 'cfgloopmanip.c' contain generic loop
+     analysis and manipulation code.  Initialization and finalization of
+     loop structures is handled by 'loop-init.c'.  A loop invariant
+     motion pass is implemented in 'loop-invariant.c'.  Basic block
+     level optimizations--unrolling, peeling and unswitching loops-- are
+     implemented in 'loop-unswitch.c' and 'loop-unroll.c'.  Replacing of
+     the exit condition of loops by special machine-dependent
+     instructions is handled by 'loop-doloop.c'.
+
+   * Jump bypassing
+
+     This pass is an aggressive form of GCSE that transforms the control
+     flow graph of a function by propagating constants into conditional
+     branch instructions.  The source file for this pass is 'gcse.c'.
+
+   * If conversion
+
+     This pass attempts to replace conditional branches and surrounding
+     assignments with arithmetic, boolean value producing comparison
+     instructions, and conditional move instructions.  In the very last
+     invocation after reload/LRA, it will generate predicated
+     instructions when supported by the target.  The code is located in
+     'ifcvt.c'.
+
+   * Web construction
+
+     This pass splits independent uses of each pseudo-register.  This
+     can improve effect of the other transformation, such as CSE or
+     register allocation.  The code for this pass is located in 'web.c'.
+
+   * Instruction combination
+
+     This pass attempts to combine groups of two or three instructions
+     that are related by data flow into single instructions.  It
+     combines the RTL expressions for the instructions by substitution,
+     simplifies the result using algebra, and then attempts to match the
+     result against the machine description.  The code is located in
+     'combine.c'.
+
+   * Mode switching optimization
+
+     This pass looks for instructions that require the processor to be
+     in a specific "mode" and minimizes the number of mode changes
+     required to satisfy all users.  What these modes are, and what they
+     apply to are completely target-specific.  The code for this pass is
+     located in 'mode-switching.c'.
+
+   * Modulo scheduling
+
+     This pass looks at innermost loops and reorders their instructions
+     by overlapping different iterations.  Modulo scheduling is
+     performed immediately before instruction scheduling.  The code for
+     this pass is located in 'modulo-sched.c'.
+
+   * Instruction scheduling
+
+     This pass looks for instructions whose output will not be available
+     by the time that it is used in subsequent instructions.  Memory
+     loads and floating point instructions often have this behavior on
+     RISC machines.  It re-orders instructions within a basic block to
+     try to separate the definition and use of items that otherwise
+     would cause pipeline stalls.  This pass is performed twice, before
+     and after register allocation.  The code for this pass is located
+     in 'haifa-sched.c', 'sched-deps.c', 'sched-ebb.c', 'sched-rgn.c'
+     and 'sched-vis.c'.
+
+   * Register allocation
+
+     These passes make sure that all occurrences of pseudo registers are
+     eliminated, either by allocating them to a hard register, replacing
+     them by an equivalent expression (e.g. a constant) or by placing
+     them on the stack.  This is done in several subpasses:
+
+        * The integrated register allocator (IRA).  It is called
+          integrated because coalescing, register live range splitting,
+          and hard register preferencing are done on-the-fly during
+          coloring.  It also has better integration with the reload/LRA
+          pass.  Pseudo-registers spilled by the allocator or the
+          reload/LRA have still a chance to get hard-registers if the
+          reload/LRA evicts some pseudo-registers from hard-registers.
+          The allocator helps to choose better pseudos for spilling
+          based on their live ranges and to coalesce stack slots
+          allocated for the spilled pseudo-registers.  IRA is a regional
+          register allocator which is transformed into Chaitin-Briggs
+          allocator if there is one region.  By default, IRA chooses
+          regions using register pressure but the user can force it to
+          use one region or regions corresponding to all loops.
+
+          Source files of the allocator are 'ira.c', 'ira-build.c',
+          'ira-costs.c', 'ira-conflicts.c', 'ira-color.c', 'ira-emit.c',
+          'ira-lives', plus header files 'ira.h' and 'ira-int.h' used
+          for the communication between the allocator and the rest of
+          the compiler and between the IRA files.
+
+        * Reloading.  This pass renumbers pseudo registers with the
+          hardware registers numbers they were allocated.  Pseudo
+          registers that did not get hard registers are replaced with
+          stack slots.  Then it finds instructions that are invalid
+          because a value has failed to end up in a register, or has
+          ended up in a register of the wrong kind.  It fixes up these
+          instructions by reloading the problematical values temporarily
+          into registers.  Additional instructions are generated to do
+          the copying.
+
+          The reload pass also optionally eliminates the frame pointer
+          and inserts instructions to save and restore call-clobbered
+          registers around calls.
+
+          Source files are 'reload.c' and 'reload1.c', plus the header
+          'reload.h' used for communication between them.
+
+        * This pass is a modern replacement of the reload pass.  Source
+          files are 'lra.c', 'lra-assign.c', 'lra-coalesce.c',
+          'lra-constraints.c', 'lra-eliminations.c', 'lra-equivs.c',
+          'lra-lives.c', 'lra-saves.c', 'lra-spills.c', the header
+          'lra-int.h' used for communication between them, and the
+          header 'lra.h' used for communication between LRA and the rest
+          of compiler.
+
+          Unlike the reload pass, intermediate LRA decisions are
+          reflected in RTL as much as possible.  This reduces the number
+          of target-dependent macros and hooks, leaving instruction
+          constraints as the primary source of control.
+
+          LRA is run on targets for which TARGET_LRA_P returns true.
+
+   * Basic block reordering
+
+     This pass implements profile guided code positioning.  If profile
+     information is not available, various types of static analysis are
+     performed to make the predictions normally coming from the profile
+     feedback (IE execution frequency, branch probability, etc).  It is
+     implemented in the file 'bb-reorder.c', and the various prediction
+     routines are in 'predict.c'.
+
+   * Variable tracking
+
+     This pass computes where the variables are stored at each position
+     in code and generates notes describing the variable locations to
+     RTL code.  The location lists are then generated according to these
+     notes to debug information if the debugging information format
+     supports location lists.  The code is located in 'var-tracking.c'.
+
+   * Delayed branch scheduling
+
+     This optional pass attempts to find instructions that can go into
+     the delay slots of other instructions, usually jumps and calls.
+     The code for this pass is located in 'reorg.c'.
+
+   * Branch shortening
+
+     On many RISC machines, branch instructions have a limited range.
+     Thus, longer sequences of instructions must be used for long
+     branches.  In this pass, the compiler figures out what how far each
+     instruction will be from each other instruction, and therefore
+     whether the usual instructions, or the longer sequences, must be
+     used for each branch.  The code for this pass is located in
+     'final.c'.
+
+   * Register-to-stack conversion
+
+     Conversion from usage of some hard registers to usage of a register
+     stack may be done at this point.  Currently, this is supported only
+     for the floating-point registers of the Intel 80387 coprocessor.
+     The code for this pass is located in 'reg-stack.c'.
+
+   * Final
+
+     This pass outputs the assembler code for the function.  The source
+     files are 'final.c' plus 'insn-output.c'; the latter is generated
+     automatically from the machine description by the tool 'genoutput'.
+     The header file 'conditions.h' is used for communication between
+     these files.
+
+   * Debugging information output
+
+     This is run after final because it must output the stack slot
+     offsets for pseudo registers that did not get hard registers.
+     Source files are 'dbxout.c' for DBX symbol table format, 'sdbout.c'
+     for SDB symbol table format, 'dwarfout.c' for DWARF symbol table
+     format, files 'dwarf2out.c' and 'dwarf2asm.c' for DWARF2 symbol
+     table format, and 'vmsdbgout.c' for VMS debug symbol table format.
+
+
+File: gccint.info,  Node: Optimization info,  Prev: RTL passes,  Up: Passes
+
+9.7 Optimization info
+=====================
+
+This section is describes dump infrastructure which is common to both
+pass dumps as well as optimization dumps.  The goal for this
+infrastructure is to provide both gcc developers and users detailed
+information about various compiler transformations and optimizations.
+
+* Menu:
+
+* Dump setup::                         Setup of optimization dumps.
+* Optimization groups::                Groups made up of optimization passes.
+* Dump files and streams::             Dump output file names and streams.
+* Dump output verbosity::              How much information to dump.
+* Dump types::                         Various types of dump functions.
+* Dump examples::                      Sample usage.
+
+
+File: gccint.info,  Node: Dump setup,  Next: Optimization groups,  Up: Optimization info
+
+9.7.1 Dump setup
+----------------
+
+A dump_manager class is defined in 'dumpfile.h'.  Various passes
+register dumping pass-specific information via 'dump_register' in
+'passes.c'.  During the registration, an optimization pass can select
+its optimization group (*note Optimization groups::).  After that
+optimization information corresponding to the entire group (presumably
+from multiple passes) can be output via command-line switches.  Note
+that if a pass does not fit into any of the pre-defined groups, it can
+select 'OPTGROUP_NONE'.
+
+ Note that in general, a pass need not know its dump output file name,
+whether certain flags are enabled, etc.  However, for legacy reasons,
+passes could also call 'dump_begin' which returns a stream in case the
+particular pass has optimization dumps enabled.  A pass could call
+'dump_end' when the dump has ended.  These methods should go away once
+all the passes are converted to use the new dump infrastructure.
+
+ The recommended way to setup the dump output is via 'dump_start' and
+'dump_end'.
+
+
+File: gccint.info,  Node: Optimization groups,  Next: Dump files and streams,  Prev: Dump setup,  Up: Optimization info
+
+9.7.2 Optimization groups
+-------------------------
+
+The optimization passes are grouped into several categories.  Currently
+defined categories in 'dumpfile.h' are
+
+'OPTGROUP_IPA'
+     IPA optimization passes.  Enabled by '-ipa'
+
+'OPTGROUP_LOOP'
+     Loop optimization passes.  Enabled by '-loop'.
+
+'OPTGROUP_INLINE'
+     Inlining passes.  Enabled by '-inline'.
+
+'OPTGROUP_VEC'
+     Vectorization passes.  Enabled by '-vec'.
+
+'OPTGROUP_OTHER'
+     All other optimization passes which do not fall into one of the
+     above.
+
+'OPTGROUP_ALL'
+     All optimization passes.  Enabled by '-all'.
+
+ By using groups a user could selectively enable optimization
+information only for a group of passes.  By default, the optimization
+information for all the passes is dumped.
+
+
+File: gccint.info,  Node: Dump files and streams,  Next: Dump output verbosity,  Prev: Optimization groups,  Up: Optimization info
+
+9.7.3 Dump files and streams
+----------------------------
+
+There are two separate output streams available for outputting
+optimization information from passes.  Note that both these streams
+accept 'stderr' and 'stdout' as valid streams and thus it is possible to
+dump output to standard output or error.  This is specially handy for
+outputting all available information in a single file by redirecting
+'stderr'.
+
+'pstream'
+     This stream is for pass-specific dump output.  For example,
+     '-fdump-tree-vect=foo.v' dumps tree vectorization pass output into
+     the given file name 'foo.v'.  If the file name is not provided, the
+     default file name is based on the source file and pass number.
+     Note that one could also use special file names 'stdout' and
+     'stderr' for dumping to standard output and standard error
+     respectively.
+
+'alt_stream'
+     This steam is used for printing optimization specific output in
+     response to the '-fopt-info'.  Again a file name can be given.  If
+     the file name is not given, it defaults to 'stderr'.
+
+
+File: gccint.info,  Node: Dump output verbosity,  Next: Dump types,  Prev: Dump files and streams,  Up: Optimization info
+
+9.7.4 Dump output verbosity
+---------------------------
+
+The dump verbosity has the following options
+
+'optimized'
+     Print information when an optimization is successfully applied.  It
+     is up to a pass to decide which information is relevant.  For
+     example, the vectorizer passes print the source location of loops
+     which got successfully vectorized.
+
+'missed'
+     Print information about missed optimizations.  Individual passes
+     control which information to include in the output.  For example,
+
+          gcc -O2 -ftree-vectorize -fopt-info-vec-missed
+
+     will print information about missed optimization opportunities from
+     vectorization passes on stderr.
+
+'note'
+     Print verbose information about optimizations, such as certain
+     transformations, more detailed messages about decisions etc.
+
+'all'
+     Print detailed optimization information.  This includes OPTIMIZED,
+     MISSED, and NOTE.
+
+
+File: gccint.info,  Node: Dump types,  Next: Dump examples,  Prev: Dump output verbosity,  Up: Optimization info
+
+9.7.5 Dump types
+----------------
+
+'dump_printf'
+
+     This is a generic method for doing formatted output.  It takes an
+     additional argument 'dump_kind' which signifies the type of dump.
+     This method outputs information only when the dumps are enabled for
+     this particular 'dump_kind'.  Note that the caller doesn't need to
+     know if the particular dump is enabled or not, or even the file
+     name.  The caller only needs to decide which dump output
+     information is relevant, and under what conditions.  This
+     determines the associated flags.
+
+     Consider the following example from 'loop-unroll.c' where an
+     informative message about a loop (along with its location) is
+     printed when any of the following flags is enabled
+
+        - optimization messages
+        - RTL dumps
+        - detailed dumps
+
+          int report_flags = MSG_OPTIMIZED_LOCATIONS | TDF_RTL | TDF_DETAILS;
+          dump_printf_loc (report_flags, locus,
+                           "loop turned into non-loop; it never loops.\n");
+
+'dump_basic_block'
+     Output basic block.
+'dump_generic_expr'
+     Output generic expression.
+'dump_gimple_stmt'
+     Output gimple statement.
+
+     Note that the above methods also have variants prefixed with
+     '_loc', such as 'dump_printf_loc', which are similar except they
+     also output the source location information.
+
+
+File: gccint.info,  Node: Dump examples,  Prev: Dump types,  Up: Optimization info
+
+9.7.6 Dump examples
+-------------------
+
+     gcc -O3 -fopt-info-missed=missed.all
+
+ outputs missed optimization report from all the passes into
+'missed.all'.
+
+ As another example,
+     gcc -O3 -fopt-info-inline-optimized-missed=inline.txt
+
+ will output information about missed optimizations as well as optimized
+locations from all the inlining passes into 'inline.txt'.
+
+ If the FILENAME is provided, then the dumps from all the applicable
+optimizations are concatenated into the 'filename'.  Otherwise the dump
+is output onto 'stderr'.  If OPTIONS is omitted, it defaults to
+'all-all', which means dump all available optimization info from all the
+passes.  In the following example, all optimization info is output on to
+'stderr'.
+
+     gcc -O3 -fopt-info
+
+ Note that '-fopt-info-vec-missed' behaves the same as
+'-fopt-info-missed-vec'.
+
+ As another example, consider
+
+     gcc -fopt-info-vec-missed=vec.miss -fopt-info-loop-optimized=loop.opt
+
+ Here the two output file names 'vec.miss' and 'loop.opt' are in
+conflict since only one output file is allowed.  In this case, only the
+first option takes effect and the subsequent options are ignored.  Thus
+only the 'vec.miss' is produced which containts dumps from the
+vectorizer about missed opportunities.
+
+
+File: gccint.info,  Node: GENERIC,  Next: GIMPLE,  Prev: Passes,  Up: Top
+
+10 GENERIC
+**********
+
+The purpose of GENERIC is simply to provide a language-independent way
+of representing an entire function in trees.  To this end, it was
+necessary to add a few new tree codes to the back end, but almost
+everything was already there.  If you can express it with the codes in
+'gcc/tree.def', it's GENERIC.
+
+ Early on, there was a great deal of debate about how to think about
+statements in a tree IL.  In GENERIC, a statement is defined as any
+expression whose value, if any, is ignored.  A statement will always
+have 'TREE_SIDE_EFFECTS' set (or it will be discarded), but a
+non-statement expression may also have side effects.  A 'CALL_EXPR', for
+instance.
+
+ It would be possible for some local optimizations to work on the
+GENERIC form of a function; indeed, the adapted tree inliner works fine
+on GENERIC, but the current compiler performs inlining after lowering to
+GIMPLE (a restricted form described in the next section).  Indeed,
+currently the frontends perform this lowering before handing off to
+'tree_rest_of_compilation', but this seems inelegant.
+
+* Menu:
+
+* Deficiencies::                Topics net yet covered in this document.
+* Tree overview::               All about 'tree's.
+* Types::                       Fundamental and aggregate types.
+* Declarations::                Type declarations and variables.
+* Attributes::                  Declaration and type attributes.
+* Expressions: Expression trees.            Operating on data.
+* Statements::                  Control flow and related trees.
+* Functions::           	Function bodies, linkage, and other aspects.
+* Language-dependent trees::    Topics and trees specific to language front ends.
+* C and C++ Trees::     	Trees specific to C and C++.
+* Java Trees:: 	                Trees specific to Java.
+
+
+File: gccint.info,  Node: Deficiencies,  Next: Tree overview,  Up: GENERIC
+
+10.1 Deficiencies
+=================
+
+There are many places in which this document is incomplet and incorrekt.
+It is, as of yet, only _preliminary_ documentation.
+
+
+File: gccint.info,  Node: Tree overview,  Next: Types,  Prev: Deficiencies,  Up: GENERIC
+
+10.2 Overview
+=============
+
+The central data structure used by the internal representation is the
+'tree'.  These nodes, while all of the C type 'tree', are of many
+varieties.  A 'tree' is a pointer type, but the object to which it
+points may be of a variety of types.  From this point forward, we will
+refer to trees in ordinary type, rather than in 'this font', except when
+talking about the actual C type 'tree'.
+
+ You can tell what kind of node a particular tree is by using the
+'TREE_CODE' macro.  Many, many macros take trees as input and return
+trees as output.  However, most macros require a certain kind of tree
+node as input.  In other words, there is a type-system for trees, but it
+is not reflected in the C type-system.
+
+ For safety, it is useful to configure GCC with '--enable-checking'.
+Although this results in a significant performance penalty (since all
+tree types are checked at run-time), and is therefore inappropriate in a
+release version, it is extremely helpful during the development process.
+
+ Many macros behave as predicates.  Many, although not all, of these
+predicates end in '_P'.  Do not rely on the result type of these macros
+being of any particular type.  You may, however, rely on the fact that
+the type can be compared to '0', so that statements like
+     if (TEST_P (t) && !TEST_P (y))
+       x = 1;
+and
+     int i = (TEST_P (t) != 0);
+are legal.  Macros that return 'int' values now may be changed to return
+'tree' values, or other pointers in the future.  Even those that
+continue to return 'int' may return multiple nonzero codes where
+previously they returned only zero and one.  Therefore, you should not
+write code like
+     if (TEST_P (t) == 1)
+as this code is not guaranteed to work correctly in the future.
+
+ You should not take the address of values returned by the macros or
+functions described here.  In particular, no guarantee is given that the
+values are lvalues.
+
+ In general, the names of macros are all in uppercase, while the names
+of functions are entirely in lowercase.  There are rare exceptions to
+this rule.  You should assume that any macro or function whose name is
+made up entirely of uppercase letters may evaluate its arguments more
+than once.  You may assume that a macro or function whose name is made
+up entirely of lowercase letters will evaluate its arguments only once.
+
+ The 'error_mark_node' is a special tree.  Its tree code is
+'ERROR_MARK', but since there is only ever one node with that code, the
+usual practice is to compare the tree against 'error_mark_node'.  (This
+test is just a test for pointer equality.)  If an error has occurred
+during front-end processing the flag 'errorcount' will be set.  If the
+front end has encountered code it cannot handle, it will issue a message
+to the user and set 'sorrycount'.  When these flags are set, any macro
+or function which normally returns a tree of a particular kind may
+instead return the 'error_mark_node'.  Thus, if you intend to do any
+processing of erroneous code, you must be prepared to deal with the
+'error_mark_node'.
+
+ Occasionally, a particular tree slot (like an operand to an expression,
+or a particular field in a declaration) will be referred to as "reserved
+for the back end".  These slots are used to store RTL when the tree is
+converted to RTL for use by the GCC back end.  However, if that process
+is not taking place (e.g., if the front end is being hooked up to an
+intelligent editor), then those slots may be used by the back end
+presently in use.
+
+ If you encounter situations that do not match this documentation, such
+as tree nodes of types not mentioned here, or macros documented to
+return entities of a particular kind that instead return entities of
+some different kind, you have found a bug, either in the front end or in
+the documentation.  Please report these bugs as you would any other bug.
+
+* Menu:
+
+* Macros and Functions::Macros and functions that can be used with all trees.
+* Identifiers::         The names of things.
+* Containers::          Lists and vectors.
+
+
+File: gccint.info,  Node: Macros and Functions,  Next: Identifiers,  Up: Tree overview
+
+10.2.1 Trees
+------------
+
+All GENERIC trees have two fields in common.  First, 'TREE_CHAIN' is a
+pointer that can be used as a singly-linked list to other trees.  The
+other is 'TREE_TYPE'.  Many trees store the type of an expression or
+declaration in this field.
+
+ These are some other functions for handling trees:
+
+'tree_size'
+     Return the number of bytes a tree takes.
+
+'build0'
+'build1'
+'build2'
+'build3'
+'build4'
+'build5'
+'build6'
+
+     These functions build a tree and supply values to put in each
+     parameter.  The basic signature is 'code, type, [operands]'.
+     'code' is the 'TREE_CODE', and 'type' is a tree representing the
+     'TREE_TYPE'.  These are followed by the operands, each of which is
+     also a tree.
+
+
+File: gccint.info,  Node: Identifiers,  Next: Containers,  Prev: Macros and Functions,  Up: Tree overview
+
+10.2.2 Identifiers
+------------------
+
+An 'IDENTIFIER_NODE' represents a slightly more general concept than the
+standard C or C++ concept of identifier.  In particular, an
+'IDENTIFIER_NODE' may contain a '$', or other extraordinary characters.
+
+ There are never two distinct 'IDENTIFIER_NODE's representing the same
+identifier.  Therefore, you may use pointer equality to compare
+'IDENTIFIER_NODE's, rather than using a routine like 'strcmp'.  Use
+'get_identifier' to obtain the unique 'IDENTIFIER_NODE' for a supplied
+string.
+
+ You can use the following macros to access identifiers:
+'IDENTIFIER_POINTER'
+     The string represented by the identifier, represented as a 'char*'.
+     This string is always 'NUL'-terminated, and contains no embedded
+     'NUL' characters.
+
+'IDENTIFIER_LENGTH'
+     The length of the string returned by 'IDENTIFIER_POINTER', not
+     including the trailing 'NUL'.  This value of 'IDENTIFIER_LENGTH
+     (x)' is always the same as 'strlen (IDENTIFIER_POINTER (x))'.
+
+'IDENTIFIER_OPNAME_P'
+     This predicate holds if the identifier represents the name of an
+     overloaded operator.  In this case, you should not depend on the
+     contents of either the 'IDENTIFIER_POINTER' or the
+     'IDENTIFIER_LENGTH'.
+
+'IDENTIFIER_TYPENAME_P'
+     This predicate holds if the identifier represents the name of a
+     user-defined conversion operator.  In this case, the 'TREE_TYPE' of
+     the 'IDENTIFIER_NODE' holds the type to which the conversion
+     operator converts.
+
+
+File: gccint.info,  Node: Containers,  Prev: Identifiers,  Up: Tree overview
+
+10.2.3 Containers
+-----------------
+
+Two common container data structures can be represented directly with
+tree nodes.  A 'TREE_LIST' is a singly linked list containing two trees
+per node.  These are the 'TREE_PURPOSE' and 'TREE_VALUE' of each node.
+(Often, the 'TREE_PURPOSE' contains some kind of tag, or additional
+information, while the 'TREE_VALUE' contains the majority of the
+payload.  In other cases, the 'TREE_PURPOSE' is simply 'NULL_TREE',
+while in still others both the 'TREE_PURPOSE' and 'TREE_VALUE' are of
+equal stature.)  Given one 'TREE_LIST' node, the next node is found by
+following the 'TREE_CHAIN'.  If the 'TREE_CHAIN' is 'NULL_TREE', then
+you have reached the end of the list.
+
+ A 'TREE_VEC' is a simple vector.  The 'TREE_VEC_LENGTH' is an integer
+(not a tree) giving the number of nodes in the vector.  The nodes
+themselves are accessed using the 'TREE_VEC_ELT' macro, which takes two
+arguments.  The first is the 'TREE_VEC' in question; the second is an
+integer indicating which element in the vector is desired.  The elements
+are indexed from zero.
+
+
+File: gccint.info,  Node: Types,  Next: Declarations,  Prev: Tree overview,  Up: GENERIC
+
+10.3 Types
+==========
+
+All types have corresponding tree nodes.  However, you should not assume
+that there is exactly one tree node corresponding to each type.  There
+are often multiple nodes corresponding to the same type.
+
+ For the most part, different kinds of types have different tree codes.
+(For example, pointer types use a 'POINTER_TYPE' code while arrays use
+an 'ARRAY_TYPE' code.)  However, pointers to member functions use the
+'RECORD_TYPE' code.  Therefore, when writing a 'switch' statement that
+depends on the code associated with a particular type, you should take
+care to handle pointers to member functions under the 'RECORD_TYPE' case
+label.
+
+ The following functions and macros deal with cv-qualification of types:
+'TYPE_MAIN_VARIANT'
+     This macro returns the unqualified version of a type.  It may be
+     applied to an unqualified type, but it is not always the identity
+     function in that case.
+
+ A few other macros and functions are usable with all types:
+'TYPE_SIZE'
+     The number of bits required to represent the type, represented as
+     an 'INTEGER_CST'.  For an incomplete type, 'TYPE_SIZE' will be
+     'NULL_TREE'.
+
+'TYPE_ALIGN'
+     The alignment of the type, in bits, represented as an 'int'.
+
+'TYPE_NAME'
+     This macro returns a declaration (in the form of a 'TYPE_DECL') for
+     the type.  (Note this macro does _not_ return an 'IDENTIFIER_NODE',
+     as you might expect, given its name!)  You can look at the
+     'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the
+     type.  The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a
+     built-in type, the result of a typedef, or a named class type.
+
+'TYPE_CANONICAL'
+     This macro returns the "canonical" type for the given type node.
+     Canonical types are used to improve performance in the C++ and
+     Objective-C++ front ends by allowing efficient comparison between
+     two type nodes in 'same_type_p': if the 'TYPE_CANONICAL' values of
+     the types are equal, the types are equivalent; otherwise, the types
+     are not equivalent.  The notion of equivalence for canonical types
+     is the same as the notion of type equivalence in the language
+     itself.  For instance,
+
+     When 'TYPE_CANONICAL' is 'NULL_TREE', there is no canonical type
+     for the given type node.  In this case, comparison between this
+     type and any other type requires the compiler to perform a deep,
+     "structural" comparison to see if the two type nodes have the same
+     form and properties.
+
+     The canonical type for a node is always the most fundamental type
+     in the equivalence class of types.  For instance, 'int' is its own
+     canonical type.  A typedef 'I' of 'int' will have 'int' as its
+     canonical type.  Similarly, 'I*' and a typedef 'IP' (defined to
+     'I*') will has 'int*' as their canonical type.  When building a new
+     type node, be sure to set 'TYPE_CANONICAL' to the appropriate
+     canonical type.  If the new type is a compound type (built from
+     other types), and any of those other types require structural
+     equality, use 'SET_TYPE_STRUCTURAL_EQUALITY' to ensure that the new
+     type also requires structural equality.  Finally, if for some
+     reason you cannot guarantee that 'TYPE_CANONICAL' will point to the
+     canonical type, use 'SET_TYPE_STRUCTURAL_EQUALITY' to make sure
+     that the new type-and any type constructed based on it-requires
+     structural equality.  If you suspect that the canonical type system
+     is miscomparing types, pass '--param verify-canonical-types=1' to
+     the compiler or configure with '--enable-checking' to force the
+     compiler to verify its canonical-type comparisons against the
+     structural comparisons; the compiler will then print any warnings
+     if the canonical types miscompare.
+
+'TYPE_STRUCTURAL_EQUALITY_P'
+     This predicate holds when the node requires structural equality
+     checks, e.g., when 'TYPE_CANONICAL' is 'NULL_TREE'.
+
+'SET_TYPE_STRUCTURAL_EQUALITY'
+     This macro states that the type node it is given requires
+     structural equality checks, e.g., it sets 'TYPE_CANONICAL' to
+     'NULL_TREE'.
+
+'same_type_p'
+     This predicate takes two types as input, and holds if they are the
+     same type.  For example, if one type is a 'typedef' for the other,
+     or both are 'typedef's for the same type.  This predicate also
+     holds if the two trees given as input are simply copies of one
+     another; i.e., there is no difference between them at the source
+     level, but, for whatever reason, a duplicate has been made in the
+     representation.  You should never use '==' (pointer equality) to
+     compare types; always use 'same_type_p' instead.
+
+ Detailed below are the various kinds of types, and the macros that can
+be used to access them.  Although other kinds of types are used
+elsewhere in G++, the types described here are the only ones that you
+will encounter while examining the intermediate representation.
+
+'VOID_TYPE'
+     Used to represent the 'void' type.
+
+'INTEGER_TYPE'
+     Used to represent the various integral types, including 'char',
+     'short', 'int', 'long', and 'long long'.  This code is not used for
+     enumeration types, nor for the 'bool' type.  The 'TYPE_PRECISION'
+     is the number of bits used in the representation, represented as an
+     'unsigned int'.  (Note that in the general case this is not the
+     same value as 'TYPE_SIZE'; suppose that there were a 24-bit integer
+     type, but that alignment requirements for the ABI required 32-bit
+     alignment.  Then, 'TYPE_SIZE' would be an 'INTEGER_CST' for 32,
+     while 'TYPE_PRECISION' would be 24.)  The integer type is unsigned
+     if 'TYPE_UNSIGNED' holds; otherwise, it is signed.
+
+     The 'TYPE_MIN_VALUE' is an 'INTEGER_CST' for the smallest integer
+     that may be represented by this type.  Similarly, the
+     'TYPE_MAX_VALUE' is an 'INTEGER_CST' for the largest integer that
+     may be represented by this type.
+
+'REAL_TYPE'
+     Used to represent the 'float', 'double', and 'long double' types.
+     The number of bits in the floating-point representation is given by
+     'TYPE_PRECISION', as in the 'INTEGER_TYPE' case.
+
+'FIXED_POINT_TYPE'
+     Used to represent the 'short _Fract', '_Fract', 'long _Fract',
+     'long long _Fract', 'short _Accum', '_Accum', 'long _Accum', and
+     'long long _Accum' types.  The number of bits in the fixed-point
+     representation is given by 'TYPE_PRECISION', as in the
+     'INTEGER_TYPE' case.  There may be padding bits, fractional bits
+     and integral bits.  The number of fractional bits is given by
+     'TYPE_FBIT', and the number of integral bits is given by
+     'TYPE_IBIT'.  The fixed-point type is unsigned if 'TYPE_UNSIGNED'
+     holds; otherwise, it is signed.  The fixed-point type is saturating
+     if 'TYPE_SATURATING' holds; otherwise, it is not saturating.
+
+'COMPLEX_TYPE'
+     Used to represent GCC built-in '__complex__' data types.  The
+     'TREE_TYPE' is the type of the real and imaginary parts.
+
+'ENUMERAL_TYPE'
+     Used to represent an enumeration type.  The 'TYPE_PRECISION' gives
+     (as an 'int'), the number of bits used to represent the type.  If
+     there are no negative enumeration constants, 'TYPE_UNSIGNED' will
+     hold.  The minimum and maximum enumeration constants may be
+     obtained with 'TYPE_MIN_VALUE' and 'TYPE_MAX_VALUE', respectively;
+     each of these macros returns an 'INTEGER_CST'.
+
+     The actual enumeration constants themselves may be obtained by
+     looking at the 'TYPE_VALUES'.  This macro will return a
+     'TREE_LIST', containing the constants.  The 'TREE_PURPOSE' of each
+     node will be an 'IDENTIFIER_NODE' giving the name of the constant;
+     the 'TREE_VALUE' will be an 'INTEGER_CST' giving the value assigned
+     to that constant.  These constants will appear in the order in
+     which they were declared.  The 'TREE_TYPE' of each of these
+     constants will be the type of enumeration type itself.
+
+'BOOLEAN_TYPE'
+     Used to represent the 'bool' type.
+
+'POINTER_TYPE'
+     Used to represent pointer types, and pointer to data member types.
+     The 'TREE_TYPE' gives the type to which this type points.
+
+'REFERENCE_TYPE'
+     Used to represent reference types.  The 'TREE_TYPE' gives the type
+     to which this type refers.
+
+'FUNCTION_TYPE'
+     Used to represent the type of non-member functions and of static
+     member functions.  The 'TREE_TYPE' gives the return type of the
+     function.  The 'TYPE_ARG_TYPES' are a 'TREE_LIST' of the argument
+     types.  The 'TREE_VALUE' of each node in this list is the type of
+     the corresponding argument; the 'TREE_PURPOSE' is an expression for
+     the default argument value, if any.  If the last node in the list
+     is 'void_list_node' (a 'TREE_LIST' node whose 'TREE_VALUE' is the
+     'void_type_node'), then functions of this type do not take variable
+     arguments.  Otherwise, they do take a variable number of arguments.
+
+     Note that in C (but not in C++) a function declared like 'void f()'
+     is an unprototyped function taking a variable number of arguments;
+     the 'TYPE_ARG_TYPES' of such a function will be 'NULL'.
+
+'METHOD_TYPE'
+     Used to represent the type of a non-static member function.  Like a
+     'FUNCTION_TYPE', the return type is given by the 'TREE_TYPE'.  The
+     type of '*this', i.e., the class of which functions of this type
+     are a member, is given by the 'TYPE_METHOD_BASETYPE'.  The
+     'TYPE_ARG_TYPES' is the parameter list, as for a 'FUNCTION_TYPE',
+     and includes the 'this' argument.
+
+'ARRAY_TYPE'
+     Used to represent array types.  The 'TREE_TYPE' gives the type of
+     the elements in the array.  If the array-bound is present in the
+     type, the 'TYPE_DOMAIN' is an 'INTEGER_TYPE' whose 'TYPE_MIN_VALUE'
+     and 'TYPE_MAX_VALUE' will be the lower and upper bounds of the
+     array, respectively.  The 'TYPE_MIN_VALUE' will always be an
+     'INTEGER_CST' for zero, while the 'TYPE_MAX_VALUE' will be one less
+     than the number of elements in the array, i.e., the highest value
+     which may be used to index an element in the array.
+
+'RECORD_TYPE'
+     Used to represent 'struct' and 'class' types, as well as pointers
+     to member functions and similar constructs in other languages.
+     'TYPE_FIELDS' contains the items contained in this type, each of
+     which can be a 'FIELD_DECL', 'VAR_DECL', 'CONST_DECL', or
+     'TYPE_DECL'.  You may not make any assumptions about the ordering
+     of the fields in the type or whether one or more of them overlap.
+
+'UNION_TYPE'
+     Used to represent 'union' types.  Similar to 'RECORD_TYPE' except
+     that all 'FIELD_DECL' nodes in 'TYPE_FIELD' start at bit position
+     zero.
+
+'QUAL_UNION_TYPE'
+     Used to represent part of a variant record in Ada.  Similar to
+     'UNION_TYPE' except that each 'FIELD_DECL' has a 'DECL_QUALIFIER'
+     field, which contains a boolean expression that indicates whether
+     the field is present in the object.  The type will only have one
+     field, so each field's 'DECL_QUALIFIER' is only evaluated if none
+     of the expressions in the previous fields in 'TYPE_FIELDS' are
+     nonzero.  Normally these expressions will reference a field in the
+     outer object using a 'PLACEHOLDER_EXPR'.
+
+'LANG_TYPE'
+     This node is used to represent a language-specific type.  The front
+     end must handle it.
+
+'OFFSET_TYPE'
+     This node is used to represent a pointer-to-data member.  For a
+     data member 'X::m' the 'TYPE_OFFSET_BASETYPE' is 'X' and the
+     'TREE_TYPE' is the type of 'm'.
+
+ There are variables whose values represent some of the basic types.
+These include:
+'void_type_node'
+     A node for 'void'.
+
+'integer_type_node'
+     A node for 'int'.
+
+'unsigned_type_node.'
+     A node for 'unsigned int'.
+
+'char_type_node.'
+     A node for 'char'.
+It may sometimes be useful to compare one of these variables with a type
+in hand, using 'same_type_p'.
+
+
+File: gccint.info,  Node: Declarations,  Next: Attributes,  Prev: Types,  Up: GENERIC
+
+10.4 Declarations
+=================
+
+This section covers the various kinds of declarations that appear in the
+internal representation, except for declarations of functions
+(represented by 'FUNCTION_DECL' nodes), which are described in *note
+Functions::.
+
+* Menu:
+
+* Working with declarations::  Macros and functions that work on
+declarations.
+* Internal structure:: How declaration nodes are represented.
+
+
+File: gccint.info,  Node: Working with declarations,  Next: Internal structure,  Up: Declarations
+
+10.4.1 Working with declarations
+--------------------------------
+
+Some macros can be used with any kind of declaration.  These include:
+'DECL_NAME'
+     This macro returns an 'IDENTIFIER_NODE' giving the name of the
+     entity.
+
+'TREE_TYPE'
+     This macro returns the type of the entity declared.
+
+'EXPR_FILENAME'
+     This macro returns the name of the file in which the entity was
+     declared, as a 'char*'.  For an entity declared implicitly by the
+     compiler (like '__builtin_memcpy'), this will be the string
+     '"<internal>"'.
+
+'EXPR_LINENO'
+     This macro returns the line number at which the entity was
+     declared, as an 'int'.
+
+'DECL_ARTIFICIAL'
+     This predicate holds if the declaration was implicitly generated by
+     the compiler.  For example, this predicate will hold of an
+     implicitly declared member function, or of the 'TYPE_DECL'
+     implicitly generated for a class type.  Recall that in C++ code
+     like:
+          struct S {};
+     is roughly equivalent to C code like:
+          struct S {};
+          typedef struct S S;
+     The implicitly generated 'typedef' declaration is represented by a
+     'TYPE_DECL' for which 'DECL_ARTIFICIAL' holds.
+
+ The various kinds of declarations include:
+'LABEL_DECL'
+     These nodes are used to represent labels in function bodies.  For
+     more information, see *note Functions::.  These nodes only appear
+     in block scopes.
+
+'CONST_DECL'
+     These nodes are used to represent enumeration constants.  The value
+     of the constant is given by 'DECL_INITIAL' which will be an
+     'INTEGER_CST' with the same type as the 'TREE_TYPE' of the
+     'CONST_DECL', i.e., an 'ENUMERAL_TYPE'.
+
+'RESULT_DECL'
+     These nodes represent the value returned by a function.  When a
+     value is assigned to a 'RESULT_DECL', that indicates that the value
+     should be returned, via bitwise copy, by the function.  You can use
+     'DECL_SIZE' and 'DECL_ALIGN' on a 'RESULT_DECL', just as with a
+     'VAR_DECL'.
+
+'TYPE_DECL'
+     These nodes represent 'typedef' declarations.  The 'TREE_TYPE' is
+     the type declared to have the name given by 'DECL_NAME'.  In some
+     cases, there is no associated name.
+
+'VAR_DECL'
+     These nodes represent variables with namespace or block scope, as
+     well as static data members.  The 'DECL_SIZE' and 'DECL_ALIGN' are
+     analogous to 'TYPE_SIZE' and 'TYPE_ALIGN'.  For a declaration, you
+     should always use the 'DECL_SIZE' and 'DECL_ALIGN' rather than the
+     'TYPE_SIZE' and 'TYPE_ALIGN' given by the 'TREE_TYPE', since
+     special attributes may have been applied to the variable to give it
+     a particular size and alignment.  You may use the predicates
+     'DECL_THIS_STATIC' or 'DECL_THIS_EXTERN' to test whether the
+     storage class specifiers 'static' or 'extern' were used to declare
+     a variable.
+
+     If this variable is initialized (but does not require a
+     constructor), the 'DECL_INITIAL' will be an expression for the
+     initializer.  The initializer should be evaluated, and a bitwise
+     copy into the variable performed.  If the 'DECL_INITIAL' is the
+     'error_mark_node', there is an initializer, but it is given by an
+     explicit statement later in the code; no bitwise copy is required.
+
+     GCC provides an extension that allows either automatic variables,
+     or global variables, to be placed in particular registers.  This
+     extension is being used for a particular 'VAR_DECL' if
+     'DECL_REGISTER' holds for the 'VAR_DECL', and if
+     'DECL_ASSEMBLER_NAME' is not equal to 'DECL_NAME'.  In that case,
+     'DECL_ASSEMBLER_NAME' is the name of the register into which the
+     variable will be placed.
+
+'PARM_DECL'
+     Used to represent a parameter to a function.  Treat these nodes
+     similarly to 'VAR_DECL' nodes.  These nodes only appear in the
+     'DECL_ARGUMENTS' for a 'FUNCTION_DECL'.
+
+     The 'DECL_ARG_TYPE' for a 'PARM_DECL' is the type that will
+     actually be used when a value is passed to this function.  It may
+     be a wider type than the 'TREE_TYPE' of the parameter; for example,
+     the ordinary type might be 'short' while the 'DECL_ARG_TYPE' is
+     'int'.
+
+'DEBUG_EXPR_DECL'
+     Used to represent an anonymous debug-information temporary created
+     to hold an expression as it is optimized away, so that its value
+     can be referenced in debug bind statements.
+
+'FIELD_DECL'
+     These nodes represent non-static data members.  The 'DECL_SIZE' and
+     'DECL_ALIGN' behave as for 'VAR_DECL' nodes.  The position of the
+     field within the parent record is specified by a combination of
+     three attributes.  'DECL_FIELD_OFFSET' is the position, counting in
+     bytes, of the 'DECL_OFFSET_ALIGN'-bit sized word containing the bit
+     of the field closest to the beginning of the structure.
+     'DECL_FIELD_BIT_OFFSET' is the bit offset of the first bit of the
+     field within this word; this may be nonzero even for fields that
+     are not bit-fields, since 'DECL_OFFSET_ALIGN' may be greater than
+     the natural alignment of the field's type.
+
+     If 'DECL_C_BIT_FIELD' holds, this field is a bit-field.  In a
+     bit-field, 'DECL_BIT_FIELD_TYPE' also contains the type that was
+     originally specified for it, while DECL_TYPE may be a modified type
+     with lesser precision, according to the size of the bit field.
+
+'NAMESPACE_DECL'
+     Namespaces provide a name hierarchy for other declarations.  They
+     appear in the 'DECL_CONTEXT' of other '_DECL' nodes.
+
+
+File: gccint.info,  Node: Internal structure,  Prev: Working with declarations,  Up: Declarations
+
+10.4.2 Internal structure
+-------------------------
+
+'DECL' nodes are represented internally as a hierarchy of structures.
+
+* Menu:
+
+* Current structure hierarchy::  The current DECL node structure
+hierarchy.
+* Adding new DECL node types:: How to add a new DECL node to a
+frontend.
+
+
+File: gccint.info,  Node: Current structure hierarchy,  Next: Adding new DECL node types,  Up: Internal structure
+
+10.4.2.1 Current structure hierarchy
+....................................
+
+'struct tree_decl_minimal'
+     This is the minimal structure to inherit from in order for common
+     'DECL' macros to work.  The fields it contains are a unique ID,
+     source location, context, and name.
+
+'struct tree_decl_common'
+     This structure inherits from 'struct tree_decl_minimal'.  It
+     contains fields that most 'DECL' nodes need, such as a field to
+     store alignment, machine mode, size, and attributes.
+
+'struct tree_field_decl'
+     This structure inherits from 'struct tree_decl_common'.  It is used
+     to represent 'FIELD_DECL'.
+
+'struct tree_label_decl'
+     This structure inherits from 'struct tree_decl_common'.  It is used
+     to represent 'LABEL_DECL'.
+
+'struct tree_translation_unit_decl'
+     This structure inherits from 'struct tree_decl_common'.  It is used
+     to represent 'TRANSLATION_UNIT_DECL'.
+
+'struct tree_decl_with_rtl'
+     This structure inherits from 'struct tree_decl_common'.  It
+     contains a field to store the low-level RTL associated with a
+     'DECL' node.
+
+'struct tree_result_decl'
+     This structure inherits from 'struct tree_decl_with_rtl'.  It is
+     used to represent 'RESULT_DECL'.
+
+'struct tree_const_decl'
+     This structure inherits from 'struct tree_decl_with_rtl'.  It is
+     used to represent 'CONST_DECL'.
+
+'struct tree_parm_decl'
+     This structure inherits from 'struct tree_decl_with_rtl'.  It is
+     used to represent 'PARM_DECL'.
+
+'struct tree_decl_with_vis'
+     This structure inherits from 'struct tree_decl_with_rtl'.  It
+     contains fields necessary to store visibility information, as well
+     as a section name and assembler name.
+
+'struct tree_var_decl'
+     This structure inherits from 'struct tree_decl_with_vis'.  It is
+     used to represent 'VAR_DECL'.
+
+'struct tree_function_decl'
+     This structure inherits from 'struct tree_decl_with_vis'.  It is
+     used to represent 'FUNCTION_DECL'.
+
+
+File: gccint.info,  Node: Adding new DECL node types,  Prev: Current structure hierarchy,  Up: Internal structure
+
+10.4.2.2 Adding new DECL node types
+...................................
+
+Adding a new 'DECL' tree consists of the following steps
+
+Add a new tree code for the 'DECL' node
+     For language specific 'DECL' nodes, there is a '.def' file in each
+     frontend directory where the tree code should be added.  For 'DECL'
+     nodes that are part of the middle-end, the code should be added to
+     'tree.def'.
+
+Create a new structure type for the 'DECL' node
+     These structures should inherit from one of the existing structures
+     in the language hierarchy by using that structure as the first
+     member.
+
+          struct tree_foo_decl
+          {
+             struct tree_decl_with_vis common;
+          }
+
+     Would create a structure name 'tree_foo_decl' that inherits from
+     'struct tree_decl_with_vis'.
+
+     For language specific 'DECL' nodes, this new structure type should
+     go in the appropriate '.h' file.  For 'DECL' nodes that are part of
+     the middle-end, the structure type should go in 'tree.h'.
+
+Add a member to the tree structure enumerator for the node
+     For garbage collection and dynamic checking purposes, each 'DECL'
+     node structure type is required to have a unique enumerator value
+     specified with it.  For language specific 'DECL' nodes, this new
+     enumerator value should go in the appropriate '.def' file.  For
+     'DECL' nodes that are part of the middle-end, the enumerator values
+     are specified in 'treestruct.def'.
+
+Update 'union tree_node'
+     In order to make your new structure type usable, it must be added
+     to 'union tree_node'.  For language specific 'DECL' nodes, a new
+     entry should be added to the appropriate '.h' file of the form
+            struct tree_foo_decl GTY ((tag ("TS_VAR_DECL"))) foo_decl;
+     For 'DECL' nodes that are part of the middle-end, the additional
+     member goes directly into 'union tree_node' in 'tree.h'.
+
+Update dynamic checking info
+     In order to be able to check whether accessing a named portion of
+     'union tree_node' is legal, and whether a certain 'DECL' node
+     contains one of the enumerated 'DECL' node structures in the
+     hierarchy, a simple lookup table is used.  This lookup table needs
+     to be kept up to date with the tree structure hierarchy, or else
+     checking and containment macros will fail inappropriately.
+
+     For language specific 'DECL' nodes, their is an 'init_ts' function
+     in an appropriate '.c' file, which initializes the lookup table.
+     Code setting up the table for new 'DECL' nodes should be added
+     there.  For each 'DECL' tree code and enumerator value representing
+     a member of the inheritance hierarchy, the table should contain 1
+     if that tree code inherits (directly or indirectly) from that
+     member.  Thus, a 'FOO_DECL' node derived from 'struct
+     decl_with_rtl', and enumerator value 'TS_FOO_DECL', would be set up
+     as follows
+          tree_contains_struct[FOO_DECL][TS_FOO_DECL] = 1;
+          tree_contains_struct[FOO_DECL][TS_DECL_WRTL] = 1;
+          tree_contains_struct[FOO_DECL][TS_DECL_COMMON] = 1;
+          tree_contains_struct[FOO_DECL][TS_DECL_MINIMAL] = 1;
+
+     For 'DECL' nodes that are part of the middle-end, the setup code
+     goes into 'tree.c'.
+
+Add macros to access any new fields and flags
+
+     Each added field or flag should have a macro that is used to access
+     it, that performs appropriate checking to ensure only the right
+     type of 'DECL' nodes access the field.
+
+     These macros generally take the following form
+          #define FOO_DECL_FIELDNAME(NODE) FOO_DECL_CHECK(NODE)->foo_decl.fieldname
+     However, if the structure is simply a base class for further
+     structures, something like the following should be used
+          #define BASE_STRUCT_CHECK(T) CONTAINS_STRUCT_CHECK(T, TS_BASE_STRUCT)
+          #define BASE_STRUCT_FIELDNAME(NODE) \
+             (BASE_STRUCT_CHECK(NODE)->base_struct.fieldname
+
+     Reading them from the generated 'all-tree.def' file (which in turn
+     includes all the 'tree.def' files), 'gencheck.c' is used during
+     GCC's build to generate the '*_CHECK' macros for all tree codes.
+
+
+File: gccint.info,  Node: Attributes,  Next: Expression trees,  Prev: Declarations,  Up: GENERIC
+
+10.5 Attributes in trees
+========================
+
+Attributes, as specified using the '__attribute__' keyword, are
+represented internally as a 'TREE_LIST'.  The 'TREE_PURPOSE' is the name
+of the attribute, as an 'IDENTIFIER_NODE'.  The 'TREE_VALUE' is a
+'TREE_LIST' of the arguments of the attribute, if any, or 'NULL_TREE' if
+there are no arguments; the arguments are stored as the 'TREE_VALUE' of
+successive entries in the list, and may be identifiers or expressions.
+The 'TREE_CHAIN' of the attribute is the next attribute in a list of
+attributes applying to the same declaration or type, or 'NULL_TREE' if
+there are no further attributes in the list.
+
+ Attributes may be attached to declarations and to types; these
+attributes may be accessed with the following macros.  All attributes
+are stored in this way, and many also cause other changes to the
+declaration or type or to other internal compiler data structures.
+
+ -- Tree Macro: tree DECL_ATTRIBUTES (tree DECL)
+     This macro returns the attributes on the declaration DECL.
+
+ -- Tree Macro: tree TYPE_ATTRIBUTES (tree TYPE)
+     This macro returns the attributes on the type TYPE.
+
+
+File: gccint.info,  Node: Expression trees,  Next: Statements,  Prev: Attributes,  Up: GENERIC
+
+10.6 Expressions
+================
+
+The internal representation for expressions is for the most part quite
+straightforward.  However, there are a few facts that one must bear in
+mind.  In particular, the expression "tree" is actually a directed
+acyclic graph.  (For example there may be many references to the integer
+constant zero throughout the source program; many of these will be
+represented by the same expression node.)  You should not rely on
+certain kinds of node being shared, nor should you rely on certain kinds
+of nodes being unshared.
+
+ The following macros can be used with all expression nodes:
+
+'TREE_TYPE'
+     Returns the type of the expression.  This value may not be
+     precisely the same type that would be given the expression in the
+     original program.
+
+ In what follows, some nodes that one might expect to always have type
+'bool' are documented to have either integral or boolean type.  At some
+point in the future, the C front end may also make use of this same
+intermediate representation, and at this point these nodes will
+certainly have integral type.  The previous sentence is not meant to
+imply that the C++ front end does not or will not give these nodes
+integral type.
+
+ Below, we list the various kinds of expression nodes.  Except where
+noted otherwise, the operands to an expression are accessed using the
+'TREE_OPERAND' macro.  For example, to access the first operand to a
+binary plus expression 'expr', use:
+
+     TREE_OPERAND (expr, 0)
+
+ As this example indicates, the operands are zero-indexed.
+
+* Menu:
+
+* Constants: Constant expressions.
+* Storage References::
+* Unary and Binary Expressions::
+* Vectors::
+
+
+File: gccint.info,  Node: Constant expressions,  Next: Storage References,  Up: Expression trees
+
+10.6.1 Constant expressions
+---------------------------
+
+The table below begins with constants, moves on to unary expressions,
+then proceeds to binary expressions, and concludes with various other
+kinds of expressions:
+
+'INTEGER_CST'
+     These nodes represent integer constants.  Note that the type of
+     these constants is obtained with 'TREE_TYPE'; they are not always
+     of type 'int'.  In particular, 'char' constants are represented
+     with 'INTEGER_CST' nodes.  The value of the integer constant 'e' is
+     given by
+          ((TREE_INT_CST_HIGH (e) << HOST_BITS_PER_WIDE_INT)
+          + TREE_INST_CST_LOW (e))
+     HOST_BITS_PER_WIDE_INT is at least thirty-two on all platforms.
+     Both 'TREE_INT_CST_HIGH' and 'TREE_INT_CST_LOW' return a
+     'HOST_WIDE_INT'.  The value of an 'INTEGER_CST' is interpreted as a
+     signed or unsigned quantity depending on the type of the constant.
+     In general, the expression given above will overflow, so it should
+     not be used to calculate the value of the constant.
+
+     The variable 'integer_zero_node' is an integer constant with value
+     zero.  Similarly, 'integer_one_node' is an integer constant with
+     value one.  The 'size_zero_node' and 'size_one_node' variables are
+     analogous, but have type 'size_t' rather than 'int'.
+
+     The function 'tree_int_cst_lt' is a predicate which holds if its
+     first argument is less than its second.  Both constants are assumed
+     to have the same signedness (i.e., either both should be signed or
+     both should be unsigned.)  The full width of the constant is used
+     when doing the comparison; the usual rules about promotions and
+     conversions are ignored.  Similarly, 'tree_int_cst_equal' holds if
+     the two constants are equal.  The 'tree_int_cst_sgn' function
+     returns the sign of a constant.  The value is '1', '0', or '-1'
+     according on whether the constant is greater than, equal to, or
+     less than zero.  Again, the signedness of the constant's type is
+     taken into account; an unsigned constant is never less than zero,
+     no matter what its bit-pattern.
+
+'REAL_CST'
+
+     FIXME: Talk about how to obtain representations of this constant,
+     do comparisons, and so forth.
+
+'FIXED_CST'
+
+     These nodes represent fixed-point constants.  The type of these
+     constants is obtained with 'TREE_TYPE'.  'TREE_FIXED_CST_PTR'
+     points to a 'struct fixed_value'; 'TREE_FIXED_CST' returns the
+     structure itself.  'struct fixed_value' contains 'data' with the
+     size of two 'HOST_BITS_PER_WIDE_INT' and 'mode' as the associated
+     fixed-point machine mode for 'data'.
+
+'COMPLEX_CST'
+     These nodes are used to represent complex number constants, that is
+     a '__complex__' whose parts are constant nodes.  The
+     'TREE_REALPART' and 'TREE_IMAGPART' return the real and the
+     imaginary parts respectively.
+
+'VECTOR_CST'
+     These nodes are used to represent vector constants, whose parts are
+     constant nodes.  Each individual constant node is either an integer
+     or a double constant node.  The first operand is a 'TREE_LIST' of
+     the constant nodes and is accessed through 'TREE_VECTOR_CST_ELTS'.
+
+'STRING_CST'
+     These nodes represent string-constants.  The 'TREE_STRING_LENGTH'
+     returns the length of the string, as an 'int'.  The
+     'TREE_STRING_POINTER' is a 'char*' containing the string itself.
+     The string may not be 'NUL'-terminated, and it may contain embedded
+     'NUL' characters.  Therefore, the 'TREE_STRING_LENGTH' includes the
+     trailing 'NUL' if it is present.
+
+     For wide string constants, the 'TREE_STRING_LENGTH' is the number
+     of bytes in the string, and the 'TREE_STRING_POINTER' points to an
+     array of the bytes of the string, as represented on the target
+     system (that is, as integers in the target endianness).  Wide and
+     non-wide string constants are distinguished only by the 'TREE_TYPE'
+     of the 'STRING_CST'.
+
+     FIXME: The formats of string constants are not well-defined when
+     the target system bytes are not the same width as host system
+     bytes.
+
+
+File: gccint.info,  Node: Storage References,  Next: Unary and Binary Expressions,  Prev: Constant expressions,  Up: Expression trees
+
+10.6.2 References to storage
+----------------------------
+
+'ARRAY_REF'
+     These nodes represent array accesses.  The first operand is the
+     array; the second is the index.  To calculate the address of the
+     memory accessed, you must scale the index by the size of the type
+     of the array elements.  The type of these expressions must be the
+     type of a component of the array.  The third and fourth operands
+     are used after gimplification to represent the lower bound and
+     component size but should not be used directly; call
+     'array_ref_low_bound' and 'array_ref_element_size' instead.
+
+'ARRAY_RANGE_REF'
+     These nodes represent access to a range (or "slice") of an array.
+     The operands are the same as that for 'ARRAY_REF' and have the same
+     meanings.  The type of these expressions must be an array whose
+     component type is the same as that of the first operand.  The range
+     of that array type determines the amount of data these expressions
+     access.
+
+'TARGET_MEM_REF'
+     These nodes represent memory accesses whose address directly map to
+     an addressing mode of the target architecture.  The first argument
+     is 'TMR_SYMBOL' and must be a 'VAR_DECL' of an object with a fixed
+     address.  The second argument is 'TMR_BASE' and the third one is
+     'TMR_INDEX'.  The fourth argument is 'TMR_STEP' and must be an
+     'INTEGER_CST'.  The fifth argument is 'TMR_OFFSET' and must be an
+     'INTEGER_CST'.  Any of the arguments may be NULL if the appropriate
+     component does not appear in the address.  Address of the
+     'TARGET_MEM_REF' is determined in the following way.
+
+          &TMR_SYMBOL + TMR_BASE + TMR_INDEX * TMR_STEP + TMR_OFFSET
+
+     The sixth argument is the reference to the original memory access,
+     which is preserved for the purposes of the RTL alias analysis.  The
+     seventh argument is a tag representing the results of tree level
+     alias analysis.
+
+'ADDR_EXPR'
+     These nodes are used to represent the address of an object.  (These
+     expressions will always have pointer or reference type.)  The
+     operand may be another expression, or it may be a declaration.
+
+     As an extension, GCC allows users to take the address of a label.
+     In this case, the operand of the 'ADDR_EXPR' will be a
+     'LABEL_DECL'.  The type of such an expression is 'void*'.
+
+     If the object addressed is not an lvalue, a temporary is created,
+     and the address of the temporary is used.
+
+'INDIRECT_REF'
+     These nodes are used to represent the object pointed to by a
+     pointer.  The operand is the pointer being dereferenced; it will
+     always have pointer or reference type.
+
+'MEM_REF'
+     These nodes are used to represent the object pointed to by a
+     pointer offset by a constant.  The first operand is the pointer
+     being dereferenced; it will always have pointer or reference type.
+     The second operand is a pointer constant.  Its type is specifying
+     the type to be used for type-based alias analysis.
+
+'COMPONENT_REF'
+     These nodes represent non-static data member accesses.  The first
+     operand is the object (rather than a pointer to it); the second
+     operand is the 'FIELD_DECL' for the data member.  The third operand
+     represents the byte offset of the field, but should not be used
+     directly; call 'component_ref_field_offset' instead.
+
+
+File: gccint.info,  Node: Unary and Binary Expressions,  Next: Vectors,  Prev: Storage References,  Up: Expression trees
+
+10.6.3 Unary and Binary Expressions
+-----------------------------------
+
+'NEGATE_EXPR'
+     These nodes represent unary negation of the single operand, for
+     both integer and floating-point types.  The type of negation can be
+     determined by looking at the type of the expression.
+
+     The behavior of this operation on signed arithmetic overflow is
+     controlled by the 'flag_wrapv' and 'flag_trapv' variables.
+
+'ABS_EXPR'
+     These nodes represent the absolute value of the single operand, for
+     both integer and floating-point types.  This is typically used to
+     implement the 'abs', 'labs' and 'llabs' builtins for integer types,
+     and the 'fabs', 'fabsf' and 'fabsl' builtins for floating point
+     types.  The type of abs operation can be determined by looking at
+     the type of the expression.
+
+     This node is not used for complex types.  To represent the modulus
+     or complex abs of a complex value, use the 'BUILT_IN_CABS',
+     'BUILT_IN_CABSF' or 'BUILT_IN_CABSL' builtins, as used to implement
+     the C99 'cabs', 'cabsf' and 'cabsl' built-in functions.
+
+'BIT_NOT_EXPR'
+     These nodes represent bitwise complement, and will always have
+     integral type.  The only operand is the value to be complemented.
+
+'TRUTH_NOT_EXPR'
+     These nodes represent logical negation, and will always have
+     integral (or boolean) type.  The operand is the value being
+     negated.  The type of the operand and that of the result are always
+     of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'.
+
+'PREDECREMENT_EXPR'
+'PREINCREMENT_EXPR'
+'POSTDECREMENT_EXPR'
+'POSTINCREMENT_EXPR'
+     These nodes represent increment and decrement expressions.  The
+     value of the single operand is computed, and the operand
+     incremented or decremented.  In the case of 'PREDECREMENT_EXPR' and
+     'PREINCREMENT_EXPR', the value of the expression is the value
+     resulting after the increment or decrement; in the case of
+     'POSTDECREMENT_EXPR' and 'POSTINCREMENT_EXPR' is the value before
+     the increment or decrement occurs.  The type of the operand, like
+     that of the result, will be either integral, boolean, or
+     floating-point.
+
+'FIX_TRUNC_EXPR'
+     These nodes represent conversion of a floating-point value to an
+     integer.  The single operand will have a floating-point type, while
+     the complete expression will have an integral (or boolean) type.
+     The operand is rounded towards zero.
+
+'FLOAT_EXPR'
+     These nodes represent conversion of an integral (or boolean) value
+     to a floating-point value.  The single operand will have integral
+     type, while the complete expression will have a floating-point
+     type.
+
+     FIXME: How is the operand supposed to be rounded?  Is this
+     dependent on '-mieee'?
+
+'COMPLEX_EXPR'
+     These nodes are used to represent complex numbers constructed from
+     two expressions of the same (integer or real) type.  The first
+     operand is the real part and the second operand is the imaginary
+     part.
+
+'CONJ_EXPR'
+     These nodes represent the conjugate of their operand.
+
+'REALPART_EXPR'
+'IMAGPART_EXPR'
+     These nodes represent respectively the real and the imaginary parts
+     of complex numbers (their sole argument).
+
+'NON_LVALUE_EXPR'
+     These nodes indicate that their one and only operand is not an
+     lvalue.  A back end can treat these identically to the single
+     operand.
+
+'NOP_EXPR'
+     These nodes are used to represent conversions that do not require
+     any code-generation.  For example, conversion of a 'char*' to an
+     'int*' does not require any code be generated; such a conversion is
+     represented by a 'NOP_EXPR'.  The single operand is the expression
+     to be converted.  The conversion from a pointer to a reference is
+     also represented with a 'NOP_EXPR'.
+
+'CONVERT_EXPR'
+     These nodes are similar to 'NOP_EXPR's, but are used in those
+     situations where code may need to be generated.  For example, if an
+     'int*' is converted to an 'int' code may need to be generated on
+     some platforms.  These nodes are never used for C++-specific
+     conversions, like conversions between pointers to different classes
+     in an inheritance hierarchy.  Any adjustments that need to be made
+     in such cases are always indicated explicitly.  Similarly, a
+     user-defined conversion is never represented by a 'CONVERT_EXPR';
+     instead, the function calls are made explicit.
+
+'FIXED_CONVERT_EXPR'
+     These nodes are used to represent conversions that involve
+     fixed-point values.  For example, from a fixed-point value to
+     another fixed-point value, from an integer to a fixed-point value,
+     from a fixed-point value to an integer, from a floating-point value
+     to a fixed-point value, or from a fixed-point value to a
+     floating-point value.
+
+'LSHIFT_EXPR'
+'RSHIFT_EXPR'
+     These nodes represent left and right shifts, respectively.  The
+     first operand is the value to shift; it will always be of integral
+     type.  The second operand is an expression for the number of bits
+     by which to shift.  Right shift should be treated as arithmetic,
+     i.e., the high-order bits should be zero-filled when the expression
+     has unsigned type and filled with the sign bit when the expression
+     has signed type.  Note that the result is undefined if the second
+     operand is larger than or equal to the first operand's type size.
+     Unlike most nodes, these can have a vector as first operand and a
+     scalar as second operand.
+
+'BIT_IOR_EXPR'
+'BIT_XOR_EXPR'
+'BIT_AND_EXPR'
+     These nodes represent bitwise inclusive or, bitwise exclusive or,
+     and bitwise and, respectively.  Both operands will always have
+     integral type.
+
+'TRUTH_ANDIF_EXPR'
+'TRUTH_ORIF_EXPR'
+     These nodes represent logical "and" and logical "or", respectively.
+     These operators are not strict; i.e., the second operand is
+     evaluated only if the value of the expression is not determined by
+     evaluation of the first operand.  The type of the operands and that
+     of the result are always of 'BOOLEAN_TYPE' or 'INTEGER_TYPE'.
+
+'TRUTH_AND_EXPR'
+'TRUTH_OR_EXPR'
+'TRUTH_XOR_EXPR'
+     These nodes represent logical and, logical or, and logical
+     exclusive or.  They are strict; both arguments are always
+     evaluated.  There are no corresponding operators in C or C++, but
+     the front end will sometimes generate these expressions anyhow, if
+     it can tell that strictness does not matter.  The type of the
+     operands and that of the result are always of 'BOOLEAN_TYPE' or
+     'INTEGER_TYPE'.
+
+'POINTER_PLUS_EXPR'
+     This node represents pointer arithmetic.  The first operand is
+     always a pointer/reference type.  The second operand is always an
+     unsigned integer type compatible with sizetype.  This is the only
+     binary arithmetic operand that can operate on pointer types.
+
+'PLUS_EXPR'
+'MINUS_EXPR'
+'MULT_EXPR'
+     These nodes represent various binary arithmetic operations.
+     Respectively, these operations are addition, subtraction (of the
+     second operand from the first) and multiplication.  Their operands
+     may have either integral or floating type, but there will never be
+     case in which one operand is of floating type and the other is of
+     integral type.
+
+     The behavior of these operations on signed arithmetic overflow is
+     controlled by the 'flag_wrapv' and 'flag_trapv' variables.
+
+'MULT_HIGHPART_EXPR'
+     This node represents the "high-part" of a widening multiplication.
+     For an integral type with B bits of precision, the result is the
+     most significant B bits of the full 2B product.
+
+'RDIV_EXPR'
+     This node represents a floating point division operation.
+
+'TRUNC_DIV_EXPR'
+'FLOOR_DIV_EXPR'
+'CEIL_DIV_EXPR'
+'ROUND_DIV_EXPR'
+     These nodes represent integer division operations that return an
+     integer result.  'TRUNC_DIV_EXPR' rounds towards zero,
+     'FLOOR_DIV_EXPR' rounds towards negative infinity, 'CEIL_DIV_EXPR'
+     rounds towards positive infinity and 'ROUND_DIV_EXPR' rounds to the
+     closest integer.  Integer division in C and C++ is truncating, i.e.
+     'TRUNC_DIV_EXPR'.
+
+     The behavior of these operations on signed arithmetic overflow,
+     when dividing the minimum signed integer by minus one, is
+     controlled by the 'flag_wrapv' and 'flag_trapv' variables.
+
+'TRUNC_MOD_EXPR'
+'FLOOR_MOD_EXPR'
+'CEIL_MOD_EXPR'
+'ROUND_MOD_EXPR'
+     These nodes represent the integer remainder or modulus operation.
+     The integer modulus of two operands 'a' and 'b' is defined as 'a -
+     (a/b)*b' where the division calculated using the corresponding
+     division operator.  Hence for 'TRUNC_MOD_EXPR' this definition
+     assumes division using truncation towards zero, i.e.
+     'TRUNC_DIV_EXPR'.  Integer remainder in C and C++ uses truncating
+     division, i.e. 'TRUNC_MOD_EXPR'.
+
+'EXACT_DIV_EXPR'
+     The 'EXACT_DIV_EXPR' code is used to represent integer divisions
+     where the numerator is known to be an exact multiple of the
+     denominator.  This allows the backend to choose between the faster
+     of 'TRUNC_DIV_EXPR', 'CEIL_DIV_EXPR' and 'FLOOR_DIV_EXPR' for the
+     current target.
+
+'LT_EXPR'
+'LE_EXPR'
+'GT_EXPR'
+'GE_EXPR'
+'EQ_EXPR'
+'NE_EXPR'
+     These nodes represent the less than, less than or equal to, greater
+     than, greater than or equal to, equal, and not equal comparison
+     operators.  The first and second operands will either be both of
+     integral type, both of floating type or both of vector type.  The
+     result type of these expressions will always be of integral,
+     boolean or signed integral vector type.  These operations return
+     the result type's zero value for false, the result type's one value
+     for true, and a vector whose elements are zero (false) or minus one
+     (true) for vectors.
+
+     For floating point comparisons, if we honor IEEE NaNs and either
+     operand is NaN, then 'NE_EXPR' always returns true and the
+     remaining operators always return false.  On some targets,
+     comparisons against an IEEE NaN, other than equality and
+     inequality, may generate a floating point exception.
+
+'ORDERED_EXPR'
+'UNORDERED_EXPR'
+     These nodes represent non-trapping ordered and unordered comparison
+     operators.  These operations take two floating point operands and
+     determine whether they are ordered or unordered relative to each
+     other.  If either operand is an IEEE NaN, their comparison is
+     defined to be unordered, otherwise the comparison is defined to be
+     ordered.  The result type of these expressions will always be of
+     integral or boolean type.  These operations return the result
+     type's zero value for false, and the result type's one value for
+     true.
+
+'UNLT_EXPR'
+'UNLE_EXPR'
+'UNGT_EXPR'
+'UNGE_EXPR'
+'UNEQ_EXPR'
+'LTGT_EXPR'
+     These nodes represent the unordered comparison operators.  These
+     operations take two floating point operands and determine whether
+     the operands are unordered or are less than, less than or equal to,
+     greater than, greater than or equal to, or equal respectively.  For
+     example, 'UNLT_EXPR' returns true if either operand is an IEEE NaN
+     or the first operand is less than the second.  With the possible
+     exception of 'LTGT_EXPR', all of these operations are guaranteed
+     not to generate a floating point exception.  The result type of
+     these expressions will always be of integral or boolean type.
+     These operations return the result type's zero value for false, and
+     the result type's one value for true.
+
+'MODIFY_EXPR'
+     These nodes represent assignment.  The left-hand side is the first
+     operand; the right-hand side is the second operand.  The left-hand
+     side will be a 'VAR_DECL', 'INDIRECT_REF', 'COMPONENT_REF', or
+     other lvalue.
+
+     These nodes are used to represent not only assignment with '=' but
+     also compound assignments (like '+='), by reduction to '='
+     assignment.  In other words, the representation for 'i += 3' looks
+     just like that for 'i = i + 3'.
+
+'INIT_EXPR'
+     These nodes are just like 'MODIFY_EXPR', but are used only when a
+     variable is initialized, rather than assigned to subsequently.
+     This means that we can assume that the target of the initialization
+     is not used in computing its own value; any reference to the lhs in
+     computing the rhs is undefined.
+
+'COMPOUND_EXPR'
+     These nodes represent comma-expressions.  The first operand is an
+     expression whose value is computed and thrown away prior to the
+     evaluation of the second operand.  The value of the entire
+     expression is the value of the second operand.
+
+'COND_EXPR'
+     These nodes represent '?:' expressions.  The first operand is of
+     boolean or integral type.  If it evaluates to a nonzero value, the
+     second operand should be evaluated, and returned as the value of
+     the expression.  Otherwise, the third operand is evaluated, and
+     returned as the value of the expression.
+
+     The second operand must have the same type as the entire
+     expression, unless it unconditionally throws an exception or calls
+     a noreturn function, in which case it should have void type.  The
+     same constraints apply to the third operand.  This allows array
+     bounds checks to be represented conveniently as '(i >= 0 && i < 10)
+     ? i : abort()'.
+
+     As a GNU extension, the C language front-ends allow the second
+     operand of the '?:' operator may be omitted in the source.  For
+     example, 'x ? : 3' is equivalent to 'x ? x : 3', assuming that 'x'
+     is an expression without side-effects.  In the tree representation,
+     however, the second operand is always present, possibly protected
+     by 'SAVE_EXPR' if the first argument does cause side-effects.
+
+'CALL_EXPR'
+     These nodes are used to represent calls to functions, including
+     non-static member functions.  'CALL_EXPR's are implemented as
+     expression nodes with a variable number of operands.  Rather than
+     using 'TREE_OPERAND' to extract them, it is preferable to use the
+     specialized accessor macros and functions that operate specifically
+     on 'CALL_EXPR' nodes.
+
+     'CALL_EXPR_FN' returns a pointer to the function to call; it is
+     always an expression whose type is a 'POINTER_TYPE'.
+
+     The number of arguments to the call is returned by
+     'call_expr_nargs', while the arguments themselves can be accessed
+     with the 'CALL_EXPR_ARG' macro.  The arguments are zero-indexed and
+     numbered left-to-right.  You can iterate over the arguments using
+     'FOR_EACH_CALL_EXPR_ARG', as in:
+
+          tree call, arg;
+          call_expr_arg_iterator iter;
+          FOR_EACH_CALL_EXPR_ARG (arg, iter, call)
+            /* arg is bound to successive arguments of call.  */
+            ...;
+
+     For non-static member functions, there will be an operand
+     corresponding to the 'this' pointer.  There will always be
+     expressions corresponding to all of the arguments, even if the
+     function is declared with default arguments and some arguments are
+     not explicitly provided at the call sites.
+
+     'CALL_EXPR's also have a 'CALL_EXPR_STATIC_CHAIN' operand that is
+     used to implement nested functions.  This operand is otherwise
+     null.
+
+'CLEANUP_POINT_EXPR'
+     These nodes represent full-expressions.  The single operand is an
+     expression to evaluate.  Any destructor calls engendered by the
+     creation of temporaries during the evaluation of that expression
+     should be performed immediately after the expression is evaluated.
+
+'CONSTRUCTOR'
+     These nodes represent the brace-enclosed initializers for a
+     structure or an array.  They contain a sequence of component values
+     made out of a vector of constructor_elt, which is a ('INDEX',
+     'VALUE') pair.
+
+     If the 'TREE_TYPE' of the 'CONSTRUCTOR' is a 'RECORD_TYPE',
+     'UNION_TYPE' or 'QUAL_UNION_TYPE' then the 'INDEX' of each node in
+     the sequence will be a 'FIELD_DECL' and the 'VALUE' will be the
+     expression used to initialize that field.
+
+     If the 'TREE_TYPE' of the 'CONSTRUCTOR' is an 'ARRAY_TYPE', then
+     the 'INDEX' of each node in the sequence will be an 'INTEGER_CST'
+     or a 'RANGE_EXPR' of two 'INTEGER_CST's.  A single 'INTEGER_CST'
+     indicates which element of the array is being assigned to.  A
+     'RANGE_EXPR' indicates an inclusive range of elements to
+     initialize.  In both cases the 'VALUE' is the corresponding
+     initializer.  It is re-evaluated for each element of a
+     'RANGE_EXPR'.  If the 'INDEX' is 'NULL_TREE', then the initializer
+     is for the next available array element.
+
+     In the front end, you should not depend on the fields appearing in
+     any particular order.  However, in the middle end, fields must
+     appear in declaration order.  You should not assume that all fields
+     will be represented.  Unrepresented fields will be cleared
+     (zeroed), unless the CONSTRUCTOR_NO_CLEARING flag is set, in which
+     case their value becomes undefined.
+
+'COMPOUND_LITERAL_EXPR'
+     These nodes represent ISO C99 compound literals.  The
+     'COMPOUND_LITERAL_EXPR_DECL_EXPR' is a 'DECL_EXPR' containing an
+     anonymous 'VAR_DECL' for the unnamed object represented by the
+     compound literal; the 'DECL_INITIAL' of that 'VAR_DECL' is a
+     'CONSTRUCTOR' representing the brace-enclosed list of initializers
+     in the compound literal.  That anonymous 'VAR_DECL' can also be
+     accessed directly by the 'COMPOUND_LITERAL_EXPR_DECL' macro.
+
+'SAVE_EXPR'
+
+     A 'SAVE_EXPR' represents an expression (possibly involving
+     side-effects) that is used more than once.  The side-effects should
+     occur only the first time the expression is evaluated.  Subsequent
+     uses should just reuse the computed value.  The first operand to
+     the 'SAVE_EXPR' is the expression to evaluate.  The side-effects
+     should be executed where the 'SAVE_EXPR' is first encountered in a
+     depth-first preorder traversal of the expression tree.
+
+'TARGET_EXPR'
+     A 'TARGET_EXPR' represents a temporary object.  The first operand
+     is a 'VAR_DECL' for the temporary variable.  The second operand is
+     the initializer for the temporary.  The initializer is evaluated
+     and, if non-void, copied (bitwise) into the temporary.  If the
+     initializer is void, that means that it will perform the
+     initialization itself.
+
+     Often, a 'TARGET_EXPR' occurs on the right-hand side of an
+     assignment, or as the second operand to a comma-expression which is
+     itself the right-hand side of an assignment, etc.  In this case, we
+     say that the 'TARGET_EXPR' is "normal"; otherwise, we say it is
+     "orphaned".  For a normal 'TARGET_EXPR' the temporary variable
+     should be treated as an alias for the left-hand side of the
+     assignment, rather than as a new temporary variable.
+
+     The third operand to the 'TARGET_EXPR', if present, is a
+     cleanup-expression (i.e., destructor call) for the temporary.  If
+     this expression is orphaned, then this expression must be executed
+     when the statement containing this expression is complete.  These
+     cleanups must always be executed in the order opposite to that in
+     which they were encountered.  Note that if a temporary is created
+     on one branch of a conditional operator (i.e., in the second or
+     third operand to a 'COND_EXPR'), the cleanup must be run only if
+     that branch is actually executed.
+
+'VA_ARG_EXPR'
+     This node is used to implement support for the C/C++ variable
+     argument-list mechanism.  It represents expressions like 'va_arg
+     (ap, type)'.  Its 'TREE_TYPE' yields the tree representation for
+     'type' and its sole argument yields the representation for 'ap'.
+
+'ANNOTATE_EXPR'
+     This node is used to attach markers to an expression.  The first
+     operand is the annotated expression, the second is an 'INTEGER_CST'
+     with a value from 'enum annot_expr_kind'.
+
+
+File: gccint.info,  Node: Vectors,  Prev: Unary and Binary Expressions,  Up: Expression trees
+
+10.6.4 Vectors
+--------------
+
+'VEC_LSHIFT_EXPR'
+'VEC_RSHIFT_EXPR'
+     These nodes represent whole vector left and right shifts,
+     respectively.  The first operand is the vector to shift; it will
+     always be of vector type.  The second operand is an expression for
+     the number of bits by which to shift.  Note that the result is
+     undefined if the second operand is larger than or equal to the
+     first operand's type size.
+
+'VEC_WIDEN_MULT_HI_EXPR'
+'VEC_WIDEN_MULT_LO_EXPR'
+     These nodes represent widening vector multiplication of the high
+     and low parts of the two input vectors, respectively.  Their
+     operands are vectors that contain the same number of elements ('N')
+     of the same integral type.  The result is a vector that contains
+     half as many elements, of an integral type whose size is twice as
+     wide.  In the case of 'VEC_WIDEN_MULT_HI_EXPR' the high 'N/2'
+     elements of the two vector are multiplied to produce the vector of
+     'N/2' products.  In the case of 'VEC_WIDEN_MULT_LO_EXPR' the low
+     'N/2' elements of the two vector are multiplied to produce the
+     vector of 'N/2' products.
+
+'VEC_UNPACK_HI_EXPR'
+'VEC_UNPACK_LO_EXPR'
+     These nodes represent unpacking of the high and low parts of the
+     input vector, respectively.  The single operand is a vector that
+     contains 'N' elements of the same integral or floating point type.
+     The result is a vector that contains half as many elements, of an
+     integral or floating point type whose size is twice as wide.  In
+     the case of 'VEC_UNPACK_HI_EXPR' the high 'N/2' elements of the
+     vector are extracted and widened (promoted).  In the case of
+     'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the vector are
+     extracted and widened (promoted).
+
+'VEC_UNPACK_FLOAT_HI_EXPR'
+'VEC_UNPACK_FLOAT_LO_EXPR'
+     These nodes represent unpacking of the high and low parts of the
+     input vector, where the values are converted from fixed point to
+     floating point.  The single operand is a vector that contains 'N'
+     elements of the same integral type.  The result is a vector that
+     contains half as many elements of a floating point type whose size
+     is twice as wide.  In the case of 'VEC_UNPACK_HI_EXPR' the high
+     'N/2' elements of the vector are extracted, converted and widened.
+     In the case of 'VEC_UNPACK_LO_EXPR' the low 'N/2' elements of the
+     vector are extracted, converted and widened.
+
+'VEC_PACK_TRUNC_EXPR'
+     This node represents packing of truncated elements of the two input
+     vectors into the output vector.  Input operands are vectors that
+     contain the same number of elements of the same integral or
+     floating point type.  The result is a vector that contains twice as
+     many elements of an integral or floating point type whose size is
+     half as wide.  The elements of the two vectors are demoted and
+     merged (concatenated) to form the output vector.
+
+'VEC_PACK_SAT_EXPR'
+     This node represents packing of elements of the two input vectors
+     into the output vector using saturation.  Input operands are
+     vectors that contain the same number of elements of the same
+     integral type.  The result is a vector that contains twice as many
+     elements of an integral type whose size is half as wide.  The
+     elements of the two vectors are demoted and merged (concatenated)
+     to form the output vector.
+
+'VEC_PACK_FIX_TRUNC_EXPR'
+     This node represents packing of elements of the two input vectors
+     into the output vector, where the values are converted from
+     floating point to fixed point.  Input operands are vectors that
+     contain the same number of elements of a floating point type.  The
+     result is a vector that contains twice as many elements of an
+     integral type whose size is half as wide.  The elements of the two
+     vectors are merged (concatenated) to form the output vector.
+
+'VEC_COND_EXPR'
+     These nodes represent '?:' expressions.  The three operands must be
+     vectors of the same size and number of elements.  The second and
+     third operands must have the same type as the entire expression.
+     The first operand is of signed integral vector type.  If an element
+     of the first operand evaluates to a zero value, the corresponding
+     element of the result is taken from the third operand.  If it
+     evaluates to a minus one value, it is taken from the second
+     operand.  It should never evaluate to any other value currently,
+     but optimizations should not rely on that property.  In contrast
+     with a 'COND_EXPR', all operands are always evaluated.
+
+
+File: gccint.info,  Node: Statements,  Next: Functions,  Prev: Expression trees,  Up: GENERIC
+
+10.7 Statements
+===============
+
+Most statements in GIMPLE are assignment statements, represented by
+'GIMPLE_ASSIGN'.  No other C expressions can appear at statement level;
+a reference to a volatile object is converted into a 'GIMPLE_ASSIGN'.
+
+ There are also several varieties of complex statements.
+
+* Menu:
+
+* Basic Statements::
+* Blocks::
+* Statement Sequences::
+* Empty Statements::
+* Jumps::
+* Cleanups::
+* OpenMP::
+
+
+File: gccint.info,  Node: Basic Statements,  Next: Blocks,  Up: Statements
+
+10.7.1 Basic Statements
+-----------------------
+
+'ASM_EXPR'
+
+     Used to represent an inline assembly statement.  For an inline
+     assembly statement like:
+          asm ("mov x, y");
+     The 'ASM_STRING' macro will return a 'STRING_CST' node for '"mov x,
+     y"'.  If the original statement made use of the extended-assembly
+     syntax, then 'ASM_OUTPUTS', 'ASM_INPUTS', and 'ASM_CLOBBERS' will
+     be the outputs, inputs, and clobbers for the statement, represented
+     as 'STRING_CST' nodes.  The extended-assembly syntax looks like:
+          asm ("fsinx %1,%0" : "=f" (result) : "f" (angle));
+     The first string is the 'ASM_STRING', containing the instruction
+     template.  The next two strings are the output and inputs,
+     respectively; this statement has no clobbers.  As this example
+     indicates, "plain" assembly statements are merely a special case of
+     extended assembly statements; they have no cv-qualifiers, outputs,
+     inputs, or clobbers.  All of the strings will be 'NUL'-terminated,
+     and will contain no embedded 'NUL'-characters.
+
+     If the assembly statement is declared 'volatile', or if the
+     statement was not an extended assembly statement, and is therefore
+     implicitly volatile, then the predicate 'ASM_VOLATILE_P' will hold
+     of the 'ASM_EXPR'.
+
+'DECL_EXPR'
+
+     Used to represent a local declaration.  The 'DECL_EXPR_DECL' macro
+     can be used to obtain the entity declared.  This declaration may be
+     a 'LABEL_DECL', indicating that the label declared is a local
+     label.  (As an extension, GCC allows the declaration of labels with
+     scope.)  In C, this declaration may be a 'FUNCTION_DECL',
+     indicating the use of the GCC nested function extension.  For more
+     information, *note Functions::.
+
+'LABEL_EXPR'
+
+     Used to represent a label.  The 'LABEL_DECL' declared by this
+     statement can be obtained with the 'LABEL_EXPR_LABEL' macro.  The
+     'IDENTIFIER_NODE' giving the name of the label can be obtained from
+     the 'LABEL_DECL' with 'DECL_NAME'.
+
+'GOTO_EXPR'
+
+     Used to represent a 'goto' statement.  The 'GOTO_DESTINATION' will
+     usually be a 'LABEL_DECL'.  However, if the "computed goto"
+     extension has been used, the 'GOTO_DESTINATION' will be an
+     arbitrary expression indicating the destination.  This expression
+     will always have pointer type.
+
+'RETURN_EXPR'
+
+     Used to represent a 'return' statement.  Operand 0 represents the
+     value to return.  It should either be the 'RESULT_DECL' for the
+     containing function, or a 'MODIFY_EXPR' or 'INIT_EXPR' setting the
+     function's 'RESULT_DECL'.  It will be 'NULL_TREE' if the statement
+     was just
+          return;
+
+'LOOP_EXPR'
+     These nodes represent "infinite" loops.  The 'LOOP_EXPR_BODY'
+     represents the body of the loop.  It should be executed forever,
+     unless an 'EXIT_EXPR' is encountered.
+
+'EXIT_EXPR'
+     These nodes represent conditional exits from the nearest enclosing
+     'LOOP_EXPR'.  The single operand is the condition; if it is
+     nonzero, then the loop should be exited.  An 'EXIT_EXPR' will only
+     appear within a 'LOOP_EXPR'.
+
+'SWITCH_STMT'
+
+     Used to represent a 'switch' statement.  The 'SWITCH_STMT_COND' is
+     the expression on which the switch is occurring.  See the
+     documentation for an 'IF_STMT' for more information on the
+     representation used for the condition.  The 'SWITCH_STMT_BODY' is
+     the body of the switch statement.  The 'SWITCH_STMT_TYPE' is the
+     original type of switch expression as given in the source, before
+     any compiler conversions.
+
+'CASE_LABEL_EXPR'
+
+     Use to represent a 'case' label, range of 'case' labels, or a
+     'default' label.  If 'CASE_LOW' is 'NULL_TREE', then this is a
+     'default' label.  Otherwise, if 'CASE_HIGH' is 'NULL_TREE', then
+     this is an ordinary 'case' label.  In this case, 'CASE_LOW' is an
+     expression giving the value of the label.  Both 'CASE_LOW' and
+     'CASE_HIGH' are 'INTEGER_CST' nodes.  These values will have the
+     same type as the condition expression in the switch statement.
+
+     Otherwise, if both 'CASE_LOW' and 'CASE_HIGH' are defined, the
+     statement is a range of case labels.  Such statements originate
+     with the extension that allows users to write things of the form:
+          case 2 ... 5:
+     The first value will be 'CASE_LOW', while the second will be
+     'CASE_HIGH'.
+
+
+File: gccint.info,  Node: Blocks,  Next: Statement Sequences,  Prev: Basic Statements,  Up: Statements
+
+10.7.2 Blocks
+-------------
+
+Block scopes and the variables they declare in GENERIC are expressed
+using the 'BIND_EXPR' code, which in previous versions of GCC was
+primarily used for the C statement-expression extension.
+
+ Variables in a block are collected into 'BIND_EXPR_VARS' in declaration
+order through their 'TREE_CHAIN' field.  Any runtime initialization is
+moved out of 'DECL_INITIAL' and into a statement in the controlled
+block.  When gimplifying from C or C++, this initialization replaces the
+'DECL_STMT'.  These variables will never require cleanups.  The scope of
+these variables is just the body
+
+ Variable-length arrays (VLAs) complicate this process, as their size
+often refers to variables initialized earlier in the block.  To handle
+this, we currently split the block at that point, and move the VLA into
+a new, inner 'BIND_EXPR'.  This strategy may change in the future.
+
+ A C++ program will usually contain more 'BIND_EXPR's than there are
+syntactic blocks in the source code, since several C++ constructs have
+implicit scopes associated with them.  On the other hand, although the
+C++ front end uses pseudo-scopes to handle cleanups for objects with
+destructors, these don't translate into the GIMPLE form; multiple
+declarations at the same level use the same 'BIND_EXPR'.
+
+
+File: gccint.info,  Node: Statement Sequences,  Next: Empty Statements,  Prev: Blocks,  Up: Statements
+
+10.7.3 Statement Sequences
+--------------------------
+
+Multiple statements at the same nesting level are collected into a
+'STATEMENT_LIST'.  Statement lists are modified and traversed using the
+interface in 'tree-iterator.h'.
+
+
+File: gccint.info,  Node: Empty Statements,  Next: Jumps,  Prev: Statement Sequences,  Up: Statements
+
+10.7.4 Empty Statements
+-----------------------
+
+Whenever possible, statements with no effect are discarded.  But if they
+are nested within another construct which cannot be discarded for some
+reason, they are instead replaced with an empty statement, generated by
+'build_empty_stmt'.  Initially, all empty statements were shared, after
+the pattern of the Java front end, but this caused a lot of trouble in
+practice.
+
+ An empty statement is represented as '(void)0'.
+
+
+File: gccint.info,  Node: Jumps,  Next: Cleanups,  Prev: Empty Statements,  Up: Statements
+
+10.7.5 Jumps
+------------
+
+Other jumps are expressed by either 'GOTO_EXPR' or 'RETURN_EXPR'.
+
+ The operand of a 'GOTO_EXPR' must be either a label or a variable
+containing the address to jump to.
+
+ The operand of a 'RETURN_EXPR' is either 'NULL_TREE', 'RESULT_DECL', or
+a 'MODIFY_EXPR' which sets the return value.  It would be nice to move
+the 'MODIFY_EXPR' into a separate statement, but the special return
+semantics in 'expand_return' make that difficult.  It may still happen
+in the future, perhaps by moving most of that logic into
+'expand_assignment'.
+
+
+File: gccint.info,  Node: Cleanups,  Next: OpenMP,  Prev: Jumps,  Up: Statements
+
+10.7.6 Cleanups
+---------------
+
+Destructors for local C++ objects and similar dynamic cleanups are
+represented in GIMPLE by a 'TRY_FINALLY_EXPR'.  'TRY_FINALLY_EXPR' has
+two operands, both of which are a sequence of statements to execute.
+The first sequence is executed.  When it completes the second sequence
+is executed.
+
+ The first sequence may complete in the following ways:
+
+  1. Execute the last statement in the sequence and fall off the end.
+
+  2. Execute a goto statement ('GOTO_EXPR') to an ordinary label outside
+     the sequence.
+
+  3. Execute a return statement ('RETURN_EXPR').
+
+  4. Throw an exception.  This is currently not explicitly represented
+     in GIMPLE.
+
+ The second sequence is not executed if the first sequence completes by
+calling 'setjmp' or 'exit' or any other function that does not return.
+The second sequence is also not executed if the first sequence completes
+via a non-local goto or a computed goto (in general the compiler does
+not know whether such a goto statement exits the first sequence or not,
+so we assume that it doesn't).
+
+ After the second sequence is executed, if it completes normally by
+falling off the end, execution continues wherever the first sequence
+would have continued, by falling off the end, or doing a goto, etc.
+
+ 'TRY_FINALLY_EXPR' complicates the flow graph, since the cleanup needs
+to appear on every edge out of the controlled block; this reduces the
+freedom to move code across these edges.  Therefore, the EH lowering
+pass which runs before most of the optimization passes eliminates these
+expressions by explicitly adding the cleanup to each edge.  Rethrowing
+the exception is represented using 'RESX_EXPR'.
+
+
+File: gccint.info,  Node: OpenMP,  Prev: Cleanups,  Up: Statements
+
+10.7.7 OpenMP
+-------------
+
+All the statements starting with 'OMP_' represent directives and clauses
+used by the OpenMP API <http://www.openmp.org/>.
+
+'OMP_PARALLEL'
+
+     Represents '#pragma omp parallel [clause1 ... clauseN]'.  It has
+     four operands:
+
+     Operand 'OMP_PARALLEL_BODY' is valid while in GENERIC and High
+     GIMPLE forms.  It contains the body of code to be executed by all
+     the threads.  During GIMPLE lowering, this operand becomes 'NULL'
+     and the body is emitted linearly after 'OMP_PARALLEL'.
+
+     Operand 'OMP_PARALLEL_CLAUSES' is the list of clauses associated
+     with the directive.
+
+     Operand 'OMP_PARALLEL_FN' is created by 'pass_lower_omp', it
+     contains the 'FUNCTION_DECL' for the function that will contain the
+     body of the parallel region.
+
+     Operand 'OMP_PARALLEL_DATA_ARG' is also created by
+     'pass_lower_omp'.  If there are shared variables to be communicated
+     to the children threads, this operand will contain the 'VAR_DECL'
+     that contains all the shared values and variables.
+
+'OMP_FOR'
+
+     Represents '#pragma omp for [clause1 ... clauseN]'.  It has 5
+     operands:
+
+     Operand 'OMP_FOR_BODY' contains the loop body.
+
+     Operand 'OMP_FOR_CLAUSES' is the list of clauses associated with
+     the directive.
+
+     Operand 'OMP_FOR_INIT' is the loop initialization code of the form
+     'VAR = N1'.
+
+     Operand 'OMP_FOR_COND' is the loop conditional expression of the
+     form 'VAR {<,>,<=,>=} N2'.
+
+     Operand 'OMP_FOR_INCR' is the loop index increment of the form 'VAR
+     {+=,-=} INCR'.
+
+     Operand 'OMP_FOR_PRE_BODY' contains side-effect code from operands
+     'OMP_FOR_INIT', 'OMP_FOR_COND' and 'OMP_FOR_INC'.  These
+     side-effects are part of the 'OMP_FOR' block but must be evaluated
+     before the start of loop body.
+
+     The loop index variable 'VAR' must be a signed integer variable,
+     which is implicitly private to each thread.  Bounds 'N1' and 'N2'
+     and the increment expression 'INCR' are required to be loop
+     invariant integer expressions that are evaluated without any
+     synchronization.  The evaluation order, frequency of evaluation and
+     side-effects are unspecified by the standard.
+
+'OMP_SECTIONS'
+
+     Represents '#pragma omp sections [clause1 ... clauseN]'.
+
+     Operand 'OMP_SECTIONS_BODY' contains the sections body, which in
+     turn contains a set of 'OMP_SECTION' nodes for each of the
+     concurrent sections delimited by '#pragma omp section'.
+
+     Operand 'OMP_SECTIONS_CLAUSES' is the list of clauses associated
+     with the directive.
+
+'OMP_SECTION'
+
+     Section delimiter for 'OMP_SECTIONS'.
+
+'OMP_SINGLE'
+
+     Represents '#pragma omp single'.
+
+     Operand 'OMP_SINGLE_BODY' contains the body of code to be executed
+     by a single thread.
+
+     Operand 'OMP_SINGLE_CLAUSES' is the list of clauses associated with
+     the directive.
+
+'OMP_MASTER'
+
+     Represents '#pragma omp master'.
+
+     Operand 'OMP_MASTER_BODY' contains the body of code to be executed
+     by the master thread.
+
+'OMP_ORDERED'
+
+     Represents '#pragma omp ordered'.
+
+     Operand 'OMP_ORDERED_BODY' contains the body of code to be executed
+     in the sequential order dictated by the loop index variable.
+
+'OMP_CRITICAL'
+
+     Represents '#pragma omp critical [name]'.
+
+     Operand 'OMP_CRITICAL_BODY' is the critical section.
+
+     Operand 'OMP_CRITICAL_NAME' is an optional identifier to label the
+     critical section.
+
+'OMP_RETURN'
+
+     This does not represent any OpenMP directive, it is an artificial
+     marker to indicate the end of the body of an OpenMP.  It is used by
+     the flow graph ('tree-cfg.c') and OpenMP region building code
+     ('omp-low.c').
+
+'OMP_CONTINUE'
+
+     Similarly, this instruction does not represent an OpenMP directive,
+     it is used by 'OMP_FOR' and 'OMP_SECTIONS' to mark the place where
+     the code needs to loop to the next iteration (in the case of
+     'OMP_FOR') or the next section (in the case of 'OMP_SECTIONS').
+
+     In some cases, 'OMP_CONTINUE' is placed right before 'OMP_RETURN'.
+     But if there are cleanups that need to occur right after the
+     looping body, it will be emitted between 'OMP_CONTINUE' and
+     'OMP_RETURN'.
+
+'OMP_ATOMIC'
+
+     Represents '#pragma omp atomic'.
+
+     Operand 0 is the address at which the atomic operation is to be
+     performed.
+
+     Operand 1 is the expression to evaluate.  The gimplifier tries
+     three alternative code generation strategies.  Whenever possible,
+     an atomic update built-in is used.  If that fails, a
+     compare-and-swap loop is attempted.  If that also fails, a regular
+     critical section around the expression is used.
+
+'OMP_CLAUSE'
+
+     Represents clauses associated with one of the 'OMP_' directives.
+     Clauses are represented by separate subcodes defined in 'tree.h'.
+     Clauses codes can be one of: 'OMP_CLAUSE_PRIVATE',
+     'OMP_CLAUSE_SHARED', 'OMP_CLAUSE_FIRSTPRIVATE',
+     'OMP_CLAUSE_LASTPRIVATE', 'OMP_CLAUSE_COPYIN',
+     'OMP_CLAUSE_COPYPRIVATE', 'OMP_CLAUSE_IF',
+     'OMP_CLAUSE_NUM_THREADS', 'OMP_CLAUSE_SCHEDULE',
+     'OMP_CLAUSE_NOWAIT', 'OMP_CLAUSE_ORDERED', 'OMP_CLAUSE_DEFAULT',
+     'OMP_CLAUSE_REDUCTION', 'OMP_CLAUSE_COLLAPSE', 'OMP_CLAUSE_UNTIED',
+     'OMP_CLAUSE_FINAL', and 'OMP_CLAUSE_MERGEABLE'.  Each code
+     represents the corresponding OpenMP clause.
+
+     Clauses associated with the same directive are chained together via
+     'OMP_CLAUSE_CHAIN'.  Those clauses that accept a list of variables
+     are restricted to exactly one, accessed with 'OMP_CLAUSE_VAR'.
+     Therefore, multiple variables under the same clause 'C' need to be
+     represented as multiple 'C' clauses chained together.  This
+     facilitates adding new clauses during compilation.
+
+
+File: gccint.info,  Node: Functions,  Next: Language-dependent trees,  Prev: Statements,  Up: GENERIC
+
+10.8 Functions
+==============
+
+A function is represented by a 'FUNCTION_DECL' node.  It stores the
+basic pieces of the function such as body, parameters, and return type
+as well as information on the surrounding context, visibility, and
+linkage.
+
+* Menu:
+
+* Function Basics::     Function names, body, and parameters.
+* Function Properties:: Context, linkage, etc.
+
+
+File: gccint.info,  Node: Function Basics,  Next: Function Properties,  Up: Functions
+
+10.8.1 Function Basics
+----------------------
+
+A function has four core parts: the name, the parameters, the result,
+and the body.  The following macros and functions access these parts of
+a 'FUNCTION_DECL' as well as other basic features:
+'DECL_NAME'
+     This macro returns the unqualified name of the function, as an
+     'IDENTIFIER_NODE'.  For an instantiation of a function template,
+     the 'DECL_NAME' is the unqualified name of the template, not
+     something like 'f<int>'.  The value of 'DECL_NAME' is undefined
+     when used on a constructor, destructor, overloaded operator, or
+     type-conversion operator, or any function that is implicitly
+     generated by the compiler.  See below for macros that can be used
+     to distinguish these cases.
+
+'DECL_ASSEMBLER_NAME'
+     This macro returns the mangled name of the function, also an
+     'IDENTIFIER_NODE'.  This name does not contain leading underscores
+     on systems that prefix all identifiers with underscores.  The
+     mangled name is computed in the same way on all platforms; if
+     special processing is required to deal with the object file format
+     used on a particular platform, it is the responsibility of the back
+     end to perform those modifications.  (Of course, the back end
+     should not modify 'DECL_ASSEMBLER_NAME' itself.)
+
+     Using 'DECL_ASSEMBLER_NAME' will cause additional memory to be
+     allocated (for the mangled name of the entity) so it should be used
+     only when emitting assembly code.  It should not be used within the
+     optimizers to determine whether or not two declarations are the
+     same, even though some of the existing optimizers do use it in that
+     way.  These uses will be removed over time.
+
+'DECL_ARGUMENTS'
+     This macro returns the 'PARM_DECL' for the first argument to the
+     function.  Subsequent 'PARM_DECL' nodes can be obtained by
+     following the 'TREE_CHAIN' links.
+
+'DECL_RESULT'
+     This macro returns the 'RESULT_DECL' for the function.
+
+'DECL_SAVED_TREE'
+     This macro returns the complete body of the function.
+
+'TREE_TYPE'
+     This macro returns the 'FUNCTION_TYPE' or 'METHOD_TYPE' for the
+     function.
+
+'DECL_INITIAL'
+     A function that has a definition in the current translation unit
+     will have a non-'NULL' 'DECL_INITIAL'.  However, back ends should
+     not make use of the particular value given by 'DECL_INITIAL'.
+
+     It should contain a tree of 'BLOCK' nodes that mirrors the scopes
+     that variables are bound in the function.  Each block contains a
+     list of decls declared in a basic block, a pointer to a chain of
+     blocks at the next lower scope level, then a pointer to the next
+     block at the same level and a backpointer to the parent 'BLOCK' or
+     'FUNCTION_DECL'.  So given a function as follows:
+
+          void foo()
+          {
+            int a;
+            {
+              int b;
+            }
+            int c;
+          }
+
+     you would get the following:
+
+          tree foo = FUNCTION_DECL;
+          tree decl_a = VAR_DECL;
+          tree decl_b = VAR_DECL;
+          tree decl_c = VAR_DECL;
+          tree block_a = BLOCK;
+          tree block_b = BLOCK;
+          tree block_c = BLOCK;
+          BLOCK_VARS(block_a) = decl_a;
+          BLOCK_SUBBLOCKS(block_a) = block_b;
+          BLOCK_CHAIN(block_a) = block_c;
+          BLOCK_SUPERCONTEXT(block_a) = foo;
+          BLOCK_VARS(block_b) = decl_b;
+          BLOCK_SUPERCONTEXT(block_b) = block_a;
+          BLOCK_VARS(block_c) = decl_c;
+          BLOCK_SUPERCONTEXT(block_c) = foo;
+          DECL_INITIAL(foo) = block_a;
+
+
+File: gccint.info,  Node: Function Properties,  Prev: Function Basics,  Up: Functions
+
+10.8.2 Function Properties
+--------------------------
+
+To determine the scope of a function, you can use the 'DECL_CONTEXT'
+macro.  This macro will return the class (either a 'RECORD_TYPE' or a
+'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is
+a member.  For a virtual function, this macro returns the class in which
+the function was actually defined, not the base class in which the
+virtual declaration occurred.
+
+ In C, the 'DECL_CONTEXT' for a function maybe another function.  This
+representation indicates that the GNU nested function extension is in
+use.  For details on the semantics of nested functions, see the GCC
+Manual.  The nested function can refer to local variables in its
+containing function.  Such references are not explicitly marked in the
+tree structure; back ends must look at the 'DECL_CONTEXT' for the
+referenced 'VAR_DECL'.  If the 'DECL_CONTEXT' for the referenced
+'VAR_DECL' is not the same as the function currently being processed,
+and neither 'DECL_EXTERNAL' nor 'TREE_STATIC' hold, then the reference
+is to a local variable in a containing function, and the back end must
+take appropriate action.
+
+'DECL_EXTERNAL'
+     This predicate holds if the function is undefined.
+
+'TREE_PUBLIC'
+     This predicate holds if the function has external linkage.
+
+'TREE_STATIC'
+     This predicate holds if the function has been defined.
+
+'TREE_THIS_VOLATILE'
+     This predicate holds if the function does not return normally.
+
+'TREE_READONLY'
+     This predicate holds if the function can only read its arguments.
+
+'DECL_PURE_P'
+     This predicate holds if the function can only read its arguments,
+     but may also read global memory.
+
+'DECL_VIRTUAL_P'
+     This predicate holds if the function is virtual.
+
+'DECL_ARTIFICIAL'
+     This macro holds if the function was implicitly generated by the
+     compiler, rather than explicitly declared.  In addition to
+     implicitly generated class member functions, this macro holds for
+     the special functions created to implement static initialization
+     and destruction, to compute run-time type information, and so
+     forth.
+
+'DECL_FUNCTION_SPECIFIC_TARGET'
+     This macro returns a tree node that holds the target options that
+     are to be used to compile this particular function or 'NULL_TREE'
+     if the function is to be compiled with the target options specified
+     on the command line.
+
+'DECL_FUNCTION_SPECIFIC_OPTIMIZATION'
+     This macro returns a tree node that holds the optimization options
+     that are to be used to compile this particular function or
+     'NULL_TREE' if the function is to be compiled with the optimization
+     options specified on the command line.
+
+
+File: gccint.info,  Node: Language-dependent trees,  Next: C and C++ Trees,  Prev: Functions,  Up: GENERIC
+
+10.9 Language-dependent trees
+=============================
+
+Front ends may wish to keep some state associated with various GENERIC
+trees while parsing.  To support this, trees provide a set of flags that
+may be used by the front end.  They are accessed using
+'TREE_LANG_FLAG_n' where 'n' is currently 0 through 6.
+
+ If necessary, a front end can use some language-dependent tree codes in
+its GENERIC representation, so long as it provides a hook for converting
+them to GIMPLE and doesn't expect them to work with any (hypothetical)
+optimizers that run before the conversion to GIMPLE.  The intermediate
+representation used while parsing C and C++ looks very little like
+GENERIC, but the C and C++ gimplifier hooks are perfectly happy to take
+it as input and spit out GIMPLE.
+
+
+File: gccint.info,  Node: C and C++ Trees,  Next: Java Trees,  Prev: Language-dependent trees,  Up: GENERIC
+
+10.10 C and C++ Trees
+=====================
+
+This section documents the internal representation used by GCC to
+represent C and C++ source programs.  When presented with a C or C++
+source program, GCC parses the program, performs semantic analysis
+(including the generation of error messages), and then produces the
+internal representation described here.  This representation contains a
+complete representation for the entire translation unit provided as
+input to the front end.  This representation is then typically processed
+by a code-generator in order to produce machine code, but could also be
+used in the creation of source browsers, intelligent editors, automatic
+documentation generators, interpreters, and any other programs needing
+the ability to process C or C++ code.
+
+ This section explains the internal representation.  In particular, it
+documents the internal representation for C and C++ source constructs,
+and the macros, functions, and variables that can be used to access
+these constructs.  The C++ representation is largely a superset of the
+representation used in the C front end.  There is only one construct
+used in C that does not appear in the C++ front end and that is the GNU
+"nested function" extension.  Many of the macros documented here do not
+apply in C because the corresponding language constructs do not appear
+in C.
+
+ The C and C++ front ends generate a mix of GENERIC trees and ones
+specific to C and C++.  These language-specific trees are higher-level
+constructs than the ones in GENERIC to make the parser's job easier.
+This section describes those trees that aren't part of GENERIC as well
+as aspects of GENERIC trees that are treated in a language-specific
+manner.
+
+ If you are developing a "back end", be it is a code-generator or some
+other tool, that uses this representation, you may occasionally find
+that you need to ask questions not easily answered by the functions and
+macros available here.  If that situation occurs, it is quite likely
+that GCC already supports the functionality you desire, but that the
+interface is simply not documented here.  In that case, you should ask
+the GCC maintainers (via mail to <gcc@gcc.gnu.org>) about documenting
+the functionality you require.  Similarly, if you find yourself writing
+functions that do not deal directly with your back end, but instead
+might be useful to other people using the GCC front end, you should
+submit your patches for inclusion in GCC.
+
+* Menu:
+
+* Types for C++::               Fundamental and aggregate types.
+* Namespaces::                  Namespaces.
+* Classes::                     Classes.
+* Functions for C++::           Overloading and accessors for C++.
+* Statements for C++::          Statements specific to C and C++.
+* C++ Expressions::    From 'typeid' to 'throw'.
+
+
+File: gccint.info,  Node: Types for C++,  Next: Namespaces,  Up: C and C++ Trees
+
+10.10.1 Types for C++
+---------------------
+
+In C++, an array type is not qualified; rather the type of the array
+elements is qualified.  This situation is reflected in the intermediate
+representation.  The macros described here will always examine the
+qualification of the underlying element type when applied to an array
+type.  (If the element type is itself an array, then the recursion
+continues until a non-array type is found, and the qualification of this
+type is examined.)  So, for example, 'CP_TYPE_CONST_P' will hold of the
+type 'const int ()[7]', denoting an array of seven 'int's.
+
+ The following functions and macros deal with cv-qualification of types:
+'cp_type_quals'
+     This function returns the set of type qualifiers applied to this
+     type.  This value is 'TYPE_UNQUALIFIED' if no qualifiers have been
+     applied.  The 'TYPE_QUAL_CONST' bit is set if the type is
+     'const'-qualified.  The 'TYPE_QUAL_VOLATILE' bit is set if the type
+     is 'volatile'-qualified.  The 'TYPE_QUAL_RESTRICT' bit is set if
+     the type is 'restrict'-qualified.
+
+'CP_TYPE_CONST_P'
+     This macro holds if the type is 'const'-qualified.
+
+'CP_TYPE_VOLATILE_P'
+     This macro holds if the type is 'volatile'-qualified.
+
+'CP_TYPE_RESTRICT_P'
+     This macro holds if the type is 'restrict'-qualified.
+
+'CP_TYPE_CONST_NON_VOLATILE_P'
+     This predicate holds for a type that is 'const'-qualified, but
+     _not_ 'volatile'-qualified; other cv-qualifiers are ignored as
+     well: only the 'const'-ness is tested.
+
+ A few other macros and functions are usable with all types:
+'TYPE_SIZE'
+     The number of bits required to represent the type, represented as
+     an 'INTEGER_CST'.  For an incomplete type, 'TYPE_SIZE' will be
+     'NULL_TREE'.
+
+'TYPE_ALIGN'
+     The alignment of the type, in bits, represented as an 'int'.
+
+'TYPE_NAME'
+     This macro returns a declaration (in the form of a 'TYPE_DECL') for
+     the type.  (Note this macro does _not_ return an 'IDENTIFIER_NODE',
+     as you might expect, given its name!)  You can look at the
+     'DECL_NAME' of the 'TYPE_DECL' to obtain the actual name of the
+     type.  The 'TYPE_NAME' will be 'NULL_TREE' for a type that is not a
+     built-in type, the result of a typedef, or a named class type.
+
+'CP_INTEGRAL_TYPE'
+     This predicate holds if the type is an integral type.  Notice that
+     in C++, enumerations are _not_ integral types.
+
+'ARITHMETIC_TYPE_P'
+     This predicate holds if the type is an integral type (in the C++
+     sense) or a floating point type.
+
+'CLASS_TYPE_P'
+     This predicate holds for a class-type.
+
+'TYPE_BUILT_IN'
+     This predicate holds for a built-in type.
+
+'TYPE_PTRDATAMEM_P'
+     This predicate holds if the type is a pointer to data member.
+
+'TYPE_PTR_P'
+     This predicate holds if the type is a pointer type, and the pointee
+     is not a data member.
+
+'TYPE_PTRFN_P'
+     This predicate holds for a pointer to function type.
+
+'TYPE_PTROB_P'
+     This predicate holds for a pointer to object type.  Note however
+     that it does not hold for the generic pointer to object type 'void
+     *'.  You may use 'TYPE_PTROBV_P' to test for a pointer to object
+     type as well as 'void *'.
+
+ The table below describes types specific to C and C++ as well as
+language-dependent info about GENERIC types.
+
+'POINTER_TYPE'
+     Used to represent pointer types, and pointer to data member types.
+     If 'TREE_TYPE' is a pointer to data member type, then
+     'TYPE_PTRDATAMEM_P' will hold.  For a pointer to data member type
+     of the form 'T X::*', 'TYPE_PTRMEM_CLASS_TYPE' will be the type
+     'X', while 'TYPE_PTRMEM_POINTED_TO_TYPE' will be the type 'T'.
+
+'RECORD_TYPE'
+     Used to represent 'struct' and 'class' types in C and C++.  If
+     'TYPE_PTRMEMFUNC_P' holds, then this type is a pointer-to-member
+     type.  In that case, the 'TYPE_PTRMEMFUNC_FN_TYPE' is a
+     'POINTER_TYPE' pointing to a 'METHOD_TYPE'.  The 'METHOD_TYPE' is
+     the type of a function pointed to by the pointer-to-member
+     function.  If 'TYPE_PTRMEMFUNC_P' does not hold, this type is a
+     class type.  For more information, *note Classes::.
+
+'UNKNOWN_TYPE'
+     This node is used to represent a type the knowledge of which is
+     insufficient for a sound processing.
+
+'TYPENAME_TYPE'
+     Used to represent a construct of the form 'typename T::A'.  The
+     'TYPE_CONTEXT' is 'T'; the 'TYPE_NAME' is an 'IDENTIFIER_NODE' for
+     'A'.  If the type is specified via a template-id, then
+     'TYPENAME_TYPE_FULLNAME' yields a 'TEMPLATE_ID_EXPR'.  The
+     'TREE_TYPE' is non-'NULL' if the node is implicitly generated in
+     support for the implicit typename extension; in which case the
+     'TREE_TYPE' is a type node for the base-class.
+
+'TYPEOF_TYPE'
+     Used to represent the '__typeof__' extension.  The 'TYPE_FIELDS' is
+     the expression the type of which is being represented.
+
+
+File: gccint.info,  Node: Namespaces,  Next: Classes,  Prev: Types for C++,  Up: C and C++ Trees
+
+10.10.2 Namespaces
+------------------
+
+The root of the entire intermediate representation is the variable
+'global_namespace'.  This is the namespace specified with '::' in C++
+source code.  All other namespaces, types, variables, functions, and so
+forth can be found starting with this namespace.
+
+ However, except for the fact that it is distinguished as the root of
+the representation, the global namespace is no different from any other
+namespace.  Thus, in what follows, we describe namespaces generally,
+rather than the global namespace in particular.
+
+ A namespace is represented by a 'NAMESPACE_DECL' node.
+
+ The following macros and functions can be used on a 'NAMESPACE_DECL':
+
+'DECL_NAME'
+     This macro is used to obtain the 'IDENTIFIER_NODE' corresponding to
+     the unqualified name of the name of the namespace (*note
+     Identifiers::).  The name of the global namespace is '::', even
+     though in C++ the global namespace is unnamed.  However, you should
+     use comparison with 'global_namespace', rather than 'DECL_NAME' to
+     determine whether or not a namespace is the global one.  An unnamed
+     namespace will have a 'DECL_NAME' equal to
+     'anonymous_namespace_name'.  Within a single translation unit, all
+     unnamed namespaces will have the same name.
+
+'DECL_CONTEXT'
+     This macro returns the enclosing namespace.  The 'DECL_CONTEXT' for
+     the 'global_namespace' is 'NULL_TREE'.
+
+'DECL_NAMESPACE_ALIAS'
+     If this declaration is for a namespace alias, then
+     'DECL_NAMESPACE_ALIAS' is the namespace for which this one is an
+     alias.
+
+     Do not attempt to use 'cp_namespace_decls' for a namespace which is
+     an alias.  Instead, follow 'DECL_NAMESPACE_ALIAS' links until you
+     reach an ordinary, non-alias, namespace, and call
+     'cp_namespace_decls' there.
+
+'DECL_NAMESPACE_STD_P'
+     This predicate holds if the namespace is the special '::std'
+     namespace.
+
+'cp_namespace_decls'
+     This function will return the declarations contained in the
+     namespace, including types, overloaded functions, other namespaces,
+     and so forth.  If there are no declarations, this function will
+     return 'NULL_TREE'.  The declarations are connected through their
+     'TREE_CHAIN' fields.
+
+     Although most entries on this list will be declarations,
+     'TREE_LIST' nodes may also appear.  In this case, the 'TREE_VALUE'
+     will be an 'OVERLOAD'.  The value of the 'TREE_PURPOSE' is
+     unspecified; back ends should ignore this value.  As with the other
+     kinds of declarations returned by 'cp_namespace_decls', the
+     'TREE_CHAIN' will point to the next declaration in this list.
+
+     For more information on the kinds of declarations that can occur on
+     this list, *Note Declarations::.  Some declarations will not appear
+     on this list.  In particular, no 'FIELD_DECL', 'LABEL_DECL', or
+     'PARM_DECL' nodes will appear here.
+
+     This function cannot be used with namespaces that have
+     'DECL_NAMESPACE_ALIAS' set.
+
+
+File: gccint.info,  Node: Classes,  Next: Functions for C++,  Prev: Namespaces,  Up: C and C++ Trees
+
+10.10.3 Classes
+---------------
+
+Besides namespaces, the other high-level scoping construct in C++ is the
+class.  (Throughout this manual the term "class" is used to mean the
+types referred to in the ANSI/ISO C++ Standard as classes; these include
+types defined with the 'class', 'struct', and 'union' keywords.)
+
+ A class type is represented by either a 'RECORD_TYPE' or a
+'UNION_TYPE'.  A class declared with the 'union' tag is represented by a
+'UNION_TYPE', while classes declared with either the 'struct' or the
+'class' tag are represented by 'RECORD_TYPE's.  You can use the
+'CLASSTYPE_DECLARED_CLASS' macro to discern whether or not a particular
+type is a 'class' as opposed to a 'struct'.  This macro will be true
+only for classes declared with the 'class' tag.
+
+ Almost all non-function members are available on the 'TYPE_FIELDS'
+list.  Given one member, the next can be found by following the
+'TREE_CHAIN'.  You should not depend in any way on the order in which
+fields appear on this list.  All nodes on this list will be 'DECL'
+nodes.  A 'FIELD_DECL' is used to represent a non-static data member, a
+'VAR_DECL' is used to represent a static data member, and a 'TYPE_DECL'
+is used to represent a type.  Note that the 'CONST_DECL' for an
+enumeration constant will appear on this list, if the enumeration type
+was declared in the class.  (Of course, the 'TYPE_DECL' for the
+enumeration type will appear here as well.)  There are no entries for
+base classes on this list.  In particular, there is no 'FIELD_DECL' for
+the "base-class portion" of an object.
+
+ The 'TYPE_VFIELD' is a compiler-generated field used to point to
+virtual function tables.  It may or may not appear on the 'TYPE_FIELDS'
+list.  However, back ends should handle the 'TYPE_VFIELD' just like all
+the entries on the 'TYPE_FIELDS' list.
+
+ The function members are available on the 'TYPE_METHODS' list.  Again,
+subsequent members are found by following the 'TREE_CHAIN' field.  If a
+function is overloaded, each of the overloaded functions appears; no
+'OVERLOAD' nodes appear on the 'TYPE_METHODS' list.  Implicitly declared
+functions (including default constructors, copy constructors, assignment
+operators, and destructors) will appear on this list as well.
+
+ Every class has an associated "binfo", which can be obtained with
+'TYPE_BINFO'.  Binfos are used to represent base-classes.  The binfo
+given by 'TYPE_BINFO' is the degenerate case, whereby every class is
+considered to be its own base-class.  The base binfos for a particular
+binfo are held in a vector, whose length is obtained with
+'BINFO_N_BASE_BINFOS'.  The base binfos themselves are obtained with
+'BINFO_BASE_BINFO' and 'BINFO_BASE_ITERATE'.  To add a new binfo, use
+'BINFO_BASE_APPEND'.  The vector of base binfos can be obtained with
+'BINFO_BASE_BINFOS', but normally you do not need to use that.  The
+class type associated with a binfo is given by 'BINFO_TYPE'.  It is not
+always the case that 'BINFO_TYPE (TYPE_BINFO (x))', because of typedefs
+and qualified types.  Neither is it the case that 'TYPE_BINFO
+(BINFO_TYPE (y))' is the same binfo as 'y'.  The reason is that if 'y'
+is a binfo representing a base-class 'B' of a derived class 'D', then
+'BINFO_TYPE (y)' will be 'B', and 'TYPE_BINFO (BINFO_TYPE (y))' will be
+'B' as its own base-class, rather than as a base-class of 'D'.
+
+ The access to a base type can be found with 'BINFO_BASE_ACCESS'.  This
+will produce 'access_public_node', 'access_private_node' or
+'access_protected_node'.  If bases are always public,
+'BINFO_BASE_ACCESSES' may be 'NULL'.
+
+ 'BINFO_VIRTUAL_P' is used to specify whether the binfo is inherited
+virtually or not.  The other flags, 'BINFO_MARKED_P' and 'BINFO_FLAG_1'
+to 'BINFO_FLAG_6' can be used for language specific use.
+
+ The following macros can be used on a tree node representing a
+class-type.
+
+'LOCAL_CLASS_P'
+     This predicate holds if the class is local class _i.e._ declared
+     inside a function body.
+
+'TYPE_POLYMORPHIC_P'
+     This predicate holds if the class has at least one virtual function
+     (declared or inherited).
+
+'TYPE_HAS_DEFAULT_CONSTRUCTOR'
+     This predicate holds whenever its argument represents a class-type
+     with default constructor.
+
+'CLASSTYPE_HAS_MUTABLE'
+'TYPE_HAS_MUTABLE_P'
+     These predicates hold for a class-type having a mutable data
+     member.
+
+'CLASSTYPE_NON_POD_P'
+     This predicate holds only for class-types that are not PODs.
+
+'TYPE_HAS_NEW_OPERATOR'
+     This predicate holds for a class-type that defines 'operator new'.
+
+'TYPE_HAS_ARRAY_NEW_OPERATOR'
+     This predicate holds for a class-type for which 'operator new[]' is
+     defined.
+
+'TYPE_OVERLOADS_CALL_EXPR'
+     This predicate holds for class-type for which the function call
+     'operator()' is overloaded.
+
+'TYPE_OVERLOADS_ARRAY_REF'
+     This predicate holds for a class-type that overloads 'operator[]'
+
+'TYPE_OVERLOADS_ARROW'
+     This predicate holds for a class-type for which 'operator->' is
+     overloaded.
+
+
+File: gccint.info,  Node: Functions for C++,  Next: Statements for C++,  Prev: Classes,  Up: C and C++ Trees
+
+10.10.4 Functions for C++
+-------------------------
+
+A function is represented by a 'FUNCTION_DECL' node.  A set of
+overloaded functions is sometimes represented by an 'OVERLOAD' node.
+
+ An 'OVERLOAD' node is not a declaration, so none of the 'DECL_' macros
+should be used on an 'OVERLOAD'.  An 'OVERLOAD' node is similar to a
+'TREE_LIST'.  Use 'OVL_CURRENT' to get the function associated with an
+'OVERLOAD' node; use 'OVL_NEXT' to get the next 'OVERLOAD' node in the
+list of overloaded functions.  The macros 'OVL_CURRENT' and 'OVL_NEXT'
+are actually polymorphic; you can use them to work with 'FUNCTION_DECL'
+nodes as well as with overloads.  In the case of a 'FUNCTION_DECL',
+'OVL_CURRENT' will always return the function itself, and 'OVL_NEXT'
+will always be 'NULL_TREE'.
+
+ To determine the scope of a function, you can use the 'DECL_CONTEXT'
+macro.  This macro will return the class (either a 'RECORD_TYPE' or a
+'UNION_TYPE') or namespace (a 'NAMESPACE_DECL') of which the function is
+a member.  For a virtual function, this macro returns the class in which
+the function was actually defined, not the base class in which the
+virtual declaration occurred.
+
+ If a friend function is defined in a class scope, the
+'DECL_FRIEND_CONTEXT' macro can be used to determine the class in which
+it was defined.  For example, in
+     class C { friend void f() {} };
+the 'DECL_CONTEXT' for 'f' will be the 'global_namespace', but the
+'DECL_FRIEND_CONTEXT' will be the 'RECORD_TYPE' for 'C'.
+
+ The following macros and functions can be used on a 'FUNCTION_DECL':
+'DECL_MAIN_P'
+     This predicate holds for a function that is the program entry point
+     '::code'.
+
+'DECL_LOCAL_FUNCTION_P'
+     This predicate holds if the function was declared at block scope,
+     even though it has a global scope.
+
+'DECL_ANTICIPATED'
+     This predicate holds if the function is a built-in function but its
+     prototype is not yet explicitly declared.
+
+'DECL_EXTERN_C_FUNCTION_P'
+     This predicate holds if the function is declared as an ''extern
+     "C"'' function.
+
+'DECL_LINKONCE_P'
+     This macro holds if multiple copies of this function may be emitted
+     in various translation units.  It is the responsibility of the
+     linker to merge the various copies.  Template instantiations are
+     the most common example of functions for which 'DECL_LINKONCE_P'
+     holds; G++ instantiates needed templates in all translation units
+     which require them, and then relies on the linker to remove
+     duplicate instantiations.
+
+     FIXME: This macro is not yet implemented.
+
+'DECL_FUNCTION_MEMBER_P'
+     This macro holds if the function is a member of a class, rather
+     than a member of a namespace.
+
+'DECL_STATIC_FUNCTION_P'
+     This predicate holds if the function a static member function.
+
+'DECL_NONSTATIC_MEMBER_FUNCTION_P'
+     This macro holds for a non-static member function.
+
+'DECL_CONST_MEMFUNC_P'
+     This predicate holds for a 'const'-member function.
+
+'DECL_VOLATILE_MEMFUNC_P'
+     This predicate holds for a 'volatile'-member function.
+
+'DECL_CONSTRUCTOR_P'
+     This macro holds if the function is a constructor.
+
+'DECL_NONCONVERTING_P'
+     This predicate holds if the constructor is a non-converting
+     constructor.
+
+'DECL_COMPLETE_CONSTRUCTOR_P'
+     This predicate holds for a function which is a constructor for an
+     object of a complete type.
+
+'DECL_BASE_CONSTRUCTOR_P'
+     This predicate holds for a function which is a constructor for a
+     base class sub-object.
+
+'DECL_COPY_CONSTRUCTOR_P'
+     This predicate holds for a function which is a copy-constructor.
+
+'DECL_DESTRUCTOR_P'
+     This macro holds if the function is a destructor.
+
+'DECL_COMPLETE_DESTRUCTOR_P'
+     This predicate holds if the function is the destructor for an
+     object a complete type.
+
+'DECL_OVERLOADED_OPERATOR_P'
+     This macro holds if the function is an overloaded operator.
+
+'DECL_CONV_FN_P'
+     This macro holds if the function is a type-conversion operator.
+
+'DECL_GLOBAL_CTOR_P'
+     This predicate holds if the function is a file-scope initialization
+     function.
+
+'DECL_GLOBAL_DTOR_P'
+     This predicate holds if the function is a file-scope finalization
+     function.
+
+'DECL_THUNK_P'
+     This predicate holds if the function is a thunk.
+
+     These functions represent stub code that adjusts the 'this' pointer
+     and then jumps to another function.  When the jumped-to function
+     returns, control is transferred directly to the caller, without
+     returning to the thunk.  The first parameter to the thunk is always
+     the 'this' pointer; the thunk should add 'THUNK_DELTA' to this
+     value.  (The 'THUNK_DELTA' is an 'int', not an 'INTEGER_CST'.)
+
+     Then, if 'THUNK_VCALL_OFFSET' (an 'INTEGER_CST') is nonzero the
+     adjusted 'this' pointer must be adjusted again.  The complete
+     calculation is given by the following pseudo-code:
+
+          this += THUNK_DELTA
+          if (THUNK_VCALL_OFFSET)
+            this += (*((ptrdiff_t **) this))[THUNK_VCALL_OFFSET]
+
+     Finally, the thunk should jump to the location given by
+     'DECL_INITIAL'; this will always be an expression for the address
+     of a function.
+
+'DECL_NON_THUNK_FUNCTION_P'
+     This predicate holds if the function is _not_ a thunk function.
+
+'GLOBAL_INIT_PRIORITY'
+     If either 'DECL_GLOBAL_CTOR_P' or 'DECL_GLOBAL_DTOR_P' holds, then
+     this gives the initialization priority for the function.  The
+     linker will arrange that all functions for which
+     'DECL_GLOBAL_CTOR_P' holds are run in increasing order of priority
+     before 'main' is called.  When the program exits, all functions for
+     which 'DECL_GLOBAL_DTOR_P' holds are run in the reverse order.
+
+'TYPE_RAISES_EXCEPTIONS'
+     This macro returns the list of exceptions that a (member-)function
+     can raise.  The returned list, if non 'NULL', is comprised of nodes
+     whose 'TREE_VALUE' represents a type.
+
+'TYPE_NOTHROW_P'
+     This predicate holds when the exception-specification of its
+     arguments is of the form ''()''.
+
+'DECL_ARRAY_DELETE_OPERATOR_P'
+     This predicate holds if the function an overloaded 'operator
+     delete[]'.
+
+
+File: gccint.info,  Node: Statements for C++,  Next: C++ Expressions,  Prev: Functions for C++,  Up: C and C++ Trees
+
+10.10.5 Statements for C++
+--------------------------
+
+A function that has a definition in the current translation unit will
+have a non-'NULL' 'DECL_INITIAL'.  However, back ends should not make
+use of the particular value given by 'DECL_INITIAL'.
+
+ The 'DECL_SAVED_TREE' macro will give the complete body of the
+function.
+
+10.10.5.1 Statements
+....................
+
+There are tree nodes corresponding to all of the source-level statement
+constructs, used within the C and C++ frontends.  These are enumerated
+here, together with a list of the various macros that can be used to
+obtain information about them.  There are a few macros that can be used
+with all statements:
+
+'STMT_IS_FULL_EXPR_P'
+     In C++, statements normally constitute "full expressions";
+     temporaries created during a statement are destroyed when the
+     statement is complete.  However, G++ sometimes represents
+     expressions by statements; these statements will not have
+     'STMT_IS_FULL_EXPR_P' set.  Temporaries created during such
+     statements should be destroyed when the innermost enclosing
+     statement with 'STMT_IS_FULL_EXPR_P' set is exited.
+
+ Here is the list of the various statement nodes, and the macros used to
+access them.  This documentation describes the use of these nodes in
+non-template functions (including instantiations of template functions).
+In template functions, the same nodes are used, but sometimes in
+slightly different ways.
+
+ Many of the statements have substatements.  For example, a 'while' loop
+will have a body, which is itself a statement.  If the substatement is
+'NULL_TREE', it is considered equivalent to a statement consisting of a
+single ';', i.e., an expression statement in which the expression has
+been omitted.  A substatement may in fact be a list of statements,
+connected via their 'TREE_CHAIN's.  So, you should always process the
+statement tree by looping over substatements, like this:
+     void process_stmt (stmt)
+          tree stmt;
+     {
+       while (stmt)
+         {
+           switch (TREE_CODE (stmt))
+             {
+             case IF_STMT:
+               process_stmt (THEN_CLAUSE (stmt));
+               /* More processing here.  */
+               break;
+
+             ...
+             }
+
+           stmt = TREE_CHAIN (stmt);
+         }
+     }
+ In other words, while the 'then' clause of an 'if' statement in C++ can
+be only one statement (although that one statement may be a compound
+statement), the intermediate representation will sometimes use several
+statements chained together.
+
+'BREAK_STMT'
+
+     Used to represent a 'break' statement.  There are no additional
+     fields.
+
+'CILK_SPAWN_STMT'
+
+     Used to represent a spawning function in the Cilk Plus language
+     extension.  This tree has one field that holds the name of the
+     spawning function.  '_Cilk_spawn' can be written in C in the
+     following way:
+
+          _Cilk_spawn <function_name> (<parameters>);
+
+     Detailed description for usage and functionality of '_Cilk_spawn'
+     can be found at http://www.cilkplus.org
+
+'CILK_SYNC_STMT'
+
+     This statement is part of the Cilk Plus language extension.  It
+     indicates that the current function cannot continue in parallel
+     with its spawned children.  There are no additional fields.
+     '_Cilk_sync' can be written in C in the following way:
+
+          _Cilk_sync;
+
+'CLEANUP_STMT'
+
+     Used to represent an action that should take place upon exit from
+     the enclosing scope.  Typically, these actions are calls to
+     destructors for local objects, but back ends cannot rely on this
+     fact.  If these nodes are in fact representing such destructors,
+     'CLEANUP_DECL' will be the 'VAR_DECL' destroyed.  Otherwise,
+     'CLEANUP_DECL' will be 'NULL_TREE'.  In any case, the
+     'CLEANUP_EXPR' is the expression to execute.  The cleanups executed
+     on exit from a scope should be run in the reverse order of the
+     order in which the associated 'CLEANUP_STMT's were encountered.
+
+'CONTINUE_STMT'
+
+     Used to represent a 'continue' statement.  There are no additional
+     fields.
+
+'CTOR_STMT'
+
+     Used to mark the beginning (if 'CTOR_BEGIN_P' holds) or end (if
+     'CTOR_END_P' holds of the main body of a constructor.  See also
+     'SUBOBJECT' for more information on how to use these nodes.
+
+'DO_STMT'
+
+     Used to represent a 'do' loop.  The body of the loop is given by
+     'DO_BODY' while the termination condition for the loop is given by
+     'DO_COND'.  The condition for a 'do'-statement is always an
+     expression.
+
+'EMPTY_CLASS_EXPR'
+
+     Used to represent a temporary object of a class with no data whose
+     address is never taken.  (All such objects are interchangeable.)
+     The 'TREE_TYPE' represents the type of the object.
+
+'EXPR_STMT'
+
+     Used to represent an expression statement.  Use 'EXPR_STMT_EXPR' to
+     obtain the expression.
+
+'FOR_STMT'
+
+     Used to represent a 'for' statement.  The 'FOR_INIT_STMT' is the
+     initialization statement for the loop.  The 'FOR_COND' is the
+     termination condition.  The 'FOR_EXPR' is the expression executed
+     right before the 'FOR_COND' on each loop iteration; often, this
+     expression increments a counter.  The body of the loop is given by
+     'FOR_BODY'.  Note that 'FOR_INIT_STMT' and 'FOR_BODY' return
+     statements, while 'FOR_COND' and 'FOR_EXPR' return expressions.
+
+'HANDLER'
+
+     Used to represent a C++ 'catch' block.  The 'HANDLER_TYPE' is the
+     type of exception that will be caught by this handler; it is equal
+     (by pointer equality) to 'NULL' if this handler is for all types.
+     'HANDLER_PARMS' is the 'DECL_STMT' for the catch parameter, and
+     'HANDLER_BODY' is the code for the block itself.
+
+'IF_STMT'
+
+     Used to represent an 'if' statement.  The 'IF_COND' is the
+     expression.
+
+     If the condition is a 'TREE_LIST', then the 'TREE_PURPOSE' is a
+     statement (usually a 'DECL_STMT').  Each time the condition is
+     evaluated, the statement should be executed.  Then, the
+     'TREE_VALUE' should be used as the conditional expression itself.
+     This representation is used to handle C++ code like this:
+
+     C++ distinguishes between this and 'COND_EXPR' for handling
+     templates.
+
+          if (int i = 7) ...
+
+     where there is a new local variable (or variables) declared within
+     the condition.
+
+     The 'THEN_CLAUSE' represents the statement given by the 'then'
+     condition, while the 'ELSE_CLAUSE' represents the statement given
+     by the 'else' condition.
+
+'SUBOBJECT'
+
+     In a constructor, these nodes are used to mark the point at which a
+     subobject of 'this' is fully constructed.  If, after this point, an
+     exception is thrown before a 'CTOR_STMT' with 'CTOR_END_P' set is
+     encountered, the 'SUBOBJECT_CLEANUP' must be executed.  The
+     cleanups must be executed in the reverse order in which they
+     appear.
+
+'SWITCH_STMT'
+
+     Used to represent a 'switch' statement.  The 'SWITCH_STMT_COND' is
+     the expression on which the switch is occurring.  See the
+     documentation for an 'IF_STMT' for more information on the
+     representation used for the condition.  The 'SWITCH_STMT_BODY' is
+     the body of the switch statement.  The 'SWITCH_STMT_TYPE' is the
+     original type of switch expression as given in the source, before
+     any compiler conversions.
+
+'TRY_BLOCK'
+     Used to represent a 'try' block.  The body of the try block is
+     given by 'TRY_STMTS'.  Each of the catch blocks is a 'HANDLER'
+     node.  The first handler is given by 'TRY_HANDLERS'.  Subsequent
+     handlers are obtained by following the 'TREE_CHAIN' link from one
+     handler to the next.  The body of the handler is given by
+     'HANDLER_BODY'.
+
+     If 'CLEANUP_P' holds of the 'TRY_BLOCK', then the 'TRY_HANDLERS'
+     will not be a 'HANDLER' node.  Instead, it will be an expression
+     that should be executed if an exception is thrown in the try block.
+     It must rethrow the exception after executing that code.  And, if
+     an exception is thrown while the expression is executing,
+     'terminate' must be called.
+
+'USING_STMT'
+     Used to represent a 'using' directive.  The namespace is given by
+     'USING_STMT_NAMESPACE', which will be a NAMESPACE_DECL.  This node
+     is needed inside template functions, to implement using directives
+     during instantiation.
+
+'WHILE_STMT'
+
+     Used to represent a 'while' loop.  The 'WHILE_COND' is the
+     termination condition for the loop.  See the documentation for an
+     'IF_STMT' for more information on the representation used for the
+     condition.
+
+     The 'WHILE_BODY' is the body of the loop.
+
+
+File: gccint.info,  Node: C++ Expressions,  Prev: Statements for C++,  Up: C and C++ Trees
+
+10.10.6 C++ Expressions
+-----------------------
+
+This section describes expressions specific to the C and C++ front ends.
+
+'TYPEID_EXPR'
+
+     Used to represent a 'typeid' expression.
+
+'NEW_EXPR'
+'VEC_NEW_EXPR'
+
+     Used to represent a call to 'new' and 'new[]' respectively.
+
+'DELETE_EXPR'
+'VEC_DELETE_EXPR'
+
+     Used to represent a call to 'delete' and 'delete[]' respectively.
+
+'MEMBER_REF'
+
+     Represents a reference to a member of a class.
+
+'THROW_EXPR'
+
+     Represents an instance of 'throw' in the program.  Operand 0, which
+     is the expression to throw, may be 'NULL_TREE'.
+
+'AGGR_INIT_EXPR'
+     An 'AGGR_INIT_EXPR' represents the initialization as the return
+     value of a function call, or as the result of a constructor.  An
+     'AGGR_INIT_EXPR' will only appear as a full-expression, or as the
+     second operand of a 'TARGET_EXPR'.  'AGGR_INIT_EXPR's have a
+     representation similar to that of 'CALL_EXPR's.  You can use the
+     'AGGR_INIT_EXPR_FN' and 'AGGR_INIT_EXPR_ARG' macros to access the
+     function to call and the arguments to pass.
+
+     If 'AGGR_INIT_VIA_CTOR_P' holds of the 'AGGR_INIT_EXPR', then the
+     initialization is via a constructor call.  The address of the
+     'AGGR_INIT_EXPR_SLOT' operand, which is always a 'VAR_DECL', is
+     taken, and this value replaces the first argument in the argument
+     list.
+
+     In either case, the expression is void.
+
+
+File: gccint.info,  Node: Java Trees,  Prev: C and C++ Trees,  Up: GENERIC
+
+10.11 Java Trees
+================
+
+
+File: gccint.info,  Node: GIMPLE,  Next: Tree SSA,  Prev: GENERIC,  Up: Top
+
+11 GIMPLE
+*********
+
+GIMPLE is a three-address representation derived from GENERIC by
+breaking down GENERIC expressions into tuples of no more than 3 operands
+(with some exceptions like function calls).  GIMPLE was heavily
+influenced by the SIMPLE IL used by the McCAT compiler project at McGill
+University, though we have made some different choices.  For one thing,
+SIMPLE doesn't support 'goto'.
+
+ Temporaries are introduced to hold intermediate values needed to
+compute complex expressions.  Additionally, all the control structures
+used in GENERIC are lowered into conditional jumps, lexical scopes are
+removed and exception regions are converted into an on the side
+exception region tree.
+
+ The compiler pass which converts GENERIC into GIMPLE is referred to as
+the 'gimplifier'.  The gimplifier works recursively, generating GIMPLE
+tuples out of the original GENERIC expressions.
+
+ One of the early implementation strategies used for the GIMPLE
+representation was to use the same internal data structures used by
+front ends to represent parse trees.  This simplified implementation
+because we could leverage existing functionality and interfaces.
+However, GIMPLE is a much more restrictive representation than abstract
+syntax trees (AST), therefore it does not require the full structural
+complexity provided by the main tree data structure.
+
+ The GENERIC representation of a function is stored in the
+'DECL_SAVED_TREE' field of the associated 'FUNCTION_DECL' tree node.  It
+is converted to GIMPLE by a call to 'gimplify_function_tree'.
+
+ If a front end wants to include language-specific tree codes in the
+tree representation which it provides to the back end, it must provide a
+definition of 'LANG_HOOKS_GIMPLIFY_EXPR' which knows how to convert the
+front end trees to GIMPLE.  Usually such a hook will involve much of the
+same code for expanding front end trees to RTL.  This function can
+return fully lowered GIMPLE, or it can return GENERIC trees and let the
+main gimplifier lower them the rest of the way; this is often simpler.
+GIMPLE that is not fully lowered is known as "High GIMPLE" and consists
+of the IL before the pass 'pass_lower_cf'.  High GIMPLE contains some
+container statements like lexical scopes (represented by 'GIMPLE_BIND')
+and nested expressions (e.g., 'GIMPLE_TRY'), while "Low GIMPLE" exposes
+all of the implicit jumps for control and exception expressions directly
+in the IL and EH region trees.
+
+ The C and C++ front ends currently convert directly from front end
+trees to GIMPLE, and hand that off to the back end rather than first
+converting to GENERIC.  Their gimplifier hooks know about all the
+'_STMT' nodes and how to convert them to GENERIC forms.  There was some
+work done on a genericization pass which would run first, but the
+existence of 'STMT_EXPR' meant that in order to convert all of the C
+statements into GENERIC equivalents would involve walking the entire
+tree anyway, so it was simpler to lower all the way.  This might change
+in the future if someone writes an optimization pass which would work
+better with higher-level trees, but currently the optimizers all expect
+GIMPLE.
+
+ You can request to dump a C-like representation of the GIMPLE form with
+the flag '-fdump-tree-gimple'.
+
+* Menu:
+
+* Tuple representation::
+* GIMPLE instruction set::
+* GIMPLE Exception Handling::
+* Temporaries::
+* Operands::
+* Manipulating GIMPLE statements::
+* Tuple specific accessors::
+* GIMPLE sequences::
+* Sequence iterators::
+* Adding a new GIMPLE statement code::
+* Statement and operand traversals::
+
+
+File: gccint.info,  Node: Tuple representation,  Next: GIMPLE instruction set,  Up: GIMPLE
+
+11.1 Tuple representation
+=========================
+
+GIMPLE instructions are tuples of variable size divided in two groups: a
+header describing the instruction and its locations, and a variable
+length body with all the operands.  Tuples are organized into a
+hierarchy with 3 main classes of tuples.
+
+11.1.1 'gimple_statement_base' (gsbase)
+---------------------------------------
+
+This is the root of the hierarchy, it holds basic information needed by
+most GIMPLE statements.  There are some fields that may not be relevant
+to every GIMPLE statement, but those were moved into the base structure
+to take advantage of holes left by other fields (thus making the
+structure more compact).  The structure takes 4 words (32 bytes) on 64
+bit hosts:
+
+Field                   Size (bits)
+'code'                  8
+'subcode'               16
+'no_warning'            1
+'visited'               1
+'nontemporal_move'      1
+'plf'                   2
+'modified'              1
+'has_volatile_ops'      1
+'references_memory_p'   1
+'uid'                   32
+'location'              32
+'num_ops'               32
+'bb'                    64
+'block'                 63
+Total size              32 bytes
+
+   * 'code' Main identifier for a GIMPLE instruction.
+
+   * 'subcode' Used to distinguish different variants of the same basic
+     instruction or provide flags applicable to a given code.  The
+     'subcode' flags field has different uses depending on the code of
+     the instruction, but mostly it distinguishes instructions of the
+     same family.  The most prominent use of this field is in
+     assignments, where subcode indicates the operation done on the RHS
+     of the assignment.  For example, a = b + c is encoded as
+     'GIMPLE_ASSIGN <PLUS_EXPR, a, b, c>'.
+
+   * 'no_warning' Bitflag to indicate whether a warning has already been
+     issued on this statement.
+
+   * 'visited' General purpose "visited" marker.  Set and cleared by
+     each pass when needed.
+
+   * 'nontemporal_move' Bitflag used in assignments that represent
+     non-temporal moves.  Although this bitflag is only used in
+     assignments, it was moved into the base to take advantage of the
+     bit holes left by the previous fields.
+
+   * 'plf' Pass Local Flags.  This 2-bit mask can be used as general
+     purpose markers by any pass.  Passes are responsible for clearing
+     and setting these two flags accordingly.
+
+   * 'modified' Bitflag to indicate whether the statement has been
+     modified.  Used mainly by the operand scanner to determine when to
+     re-scan a statement for operands.
+
+   * 'has_volatile_ops' Bitflag to indicate whether this statement
+     contains operands that have been marked volatile.
+
+   * 'references_memory_p' Bitflag to indicate whether this statement
+     contains memory references (i.e., its operands are either global
+     variables, or pointer dereferences or anything that must reside in
+     memory).
+
+   * 'uid' This is an unsigned integer used by passes that want to
+     assign IDs to every statement.  These IDs must be assigned and used
+     by each pass.
+
+   * 'location' This is a 'location_t' identifier to specify source code
+     location for this statement.  It is inherited from the front end.
+
+   * 'num_ops' Number of operands that this statement has.  This
+     specifies the size of the operand vector embedded in the tuple.
+     Only used in some tuples, but it is declared in the base tuple to
+     take advantage of the 32-bit hole left by the previous fields.
+
+   * 'bb' Basic block holding the instruction.
+
+   * 'block' Lexical block holding this statement.  Also used for debug
+     information generation.
+
+11.1.2 'gimple_statement_with_ops'
+----------------------------------
+
+This tuple is actually split in two: 'gimple_statement_with_ops_base'
+and 'gimple_statement_with_ops'.  This is needed to accommodate the way
+the operand vector is allocated.  The operand vector is defined to be an
+array of 1 element.  So, to allocate a dynamic number of operands, the
+memory allocator ('gimple_alloc') simply allocates enough memory to hold
+the structure itself plus 'N - 1' operands which run "off the end" of
+the structure.  For example, to allocate space for a tuple with 3
+operands, 'gimple_alloc' reserves 'sizeof (struct
+gimple_statement_with_ops) + 2 * sizeof (tree)' bytes.
+
+ On the other hand, several fields in this tuple need to be shared with
+the 'gimple_statement_with_memory_ops' tuple.  So, these common fields
+are placed in 'gimple_statement_with_ops_base' which is then inherited
+from the other two tuples.
+
+'gsbase'    256
+'def_ops'   64
+'use_ops'   64
+'op'        'num_ops' * 64
+Total       48 + 8 * 'num_ops' bytes
+size
+
+   * 'gsbase' Inherited from 'struct gimple_statement_base'.
+
+   * 'def_ops' Array of pointers into the operand array indicating all
+     the slots that contain a variable written-to by the statement.
+     This array is also used for immediate use chaining.  Note that it
+     would be possible to not rely on this array, but the changes
+     required to implement this are pretty invasive.
+
+   * 'use_ops' Similar to 'def_ops' but for variables read by the
+     statement.
+
+   * 'op' Array of trees with 'num_ops' slots.
+
+11.1.3 'gimple_statement_with_memory_ops'
+-----------------------------------------
+
+This tuple is essentially identical to 'gimple_statement_with_ops',
+except that it contains 4 additional fields to hold vectors related
+memory stores and loads.  Similar to the previous case, the structure is
+split in two to accommodate for the operand vector
+('gimple_statement_with_memory_ops_base' and
+'gimple_statement_with_memory_ops').
+
+Field        Size (bits)
+'gsbase'     256
+'def_ops'    64
+'use_ops'    64
+'vdef_ops'   64
+'vuse_ops'   64
+'stores'     64
+'loads'      64
+'op'         'num_ops' * 64
+Total size   80 + 8 * 'num_ops' bytes
+
+   * 'vdef_ops' Similar to 'def_ops' but for 'VDEF' operators.  There is
+     one entry per memory symbol written by this statement.  This is
+     used to maintain the memory SSA use-def and def-def chains.
+
+   * 'vuse_ops' Similar to 'use_ops' but for 'VUSE' operators.  There is
+     one entry per memory symbol loaded by this statement.  This is used
+     to maintain the memory SSA use-def chains.
+
+   * 'stores' Bitset with all the UIDs for the symbols written-to by the
+     statement.  This is different than 'vdef_ops' in that all the
+     affected symbols are mentioned in this set.  If memory partitioning
+     is enabled, the 'vdef_ops' vector will refer to memory partitions.
+     Furthermore, no SSA information is stored in this set.
+
+   * 'loads' Similar to 'stores', but for memory loads.  (Note that
+     there is some amount of redundancy here, it should be possible to
+     reduce memory utilization further by removing these sets).
+
+ All the other tuples are defined in terms of these three basic ones.
+Each tuple will add some fields.  The main gimple type is defined to be
+the union of all these structures ('GTY' markers elided for clarity):
+
+     union gimple_statement_d
+     {
+       struct gimple_statement_base gsbase;
+       struct gimple_statement_with_ops gsops;
+       struct gimple_statement_with_memory_ops gsmem;
+       struct gimple_statement_omp omp;
+       struct gimple_statement_bind gimple_bind;
+       struct gimple_statement_catch gimple_catch;
+       struct gimple_statement_eh_filter gimple_eh_filter;
+       struct gimple_statement_phi gimple_phi;
+       struct gimple_statement_resx gimple_resx;
+       struct gimple_statement_try gimple_try;
+       struct gimple_statement_wce gimple_wce;
+       struct gimple_statement_asm gimple_asm;
+       struct gimple_statement_omp_critical gimple_omp_critical;
+       struct gimple_statement_omp_for gimple_omp_for;
+       struct gimple_statement_omp_parallel gimple_omp_parallel;
+       struct gimple_statement_omp_task gimple_omp_task;
+       struct gimple_statement_omp_sections gimple_omp_sections;
+       struct gimple_statement_omp_single gimple_omp_single;
+       struct gimple_statement_omp_continue gimple_omp_continue;
+       struct gimple_statement_omp_atomic_load gimple_omp_atomic_load;
+       struct gimple_statement_omp_atomic_store gimple_omp_atomic_store;
+     };
+
+
+File: gccint.info,  Node: GIMPLE instruction set,  Next: GIMPLE Exception Handling,  Prev: Tuple representation,  Up: GIMPLE
+
+11.2 GIMPLE instruction set
+===========================
+
+The following table briefly describes the GIMPLE instruction set.
+
+Instruction                    High GIMPLE   Low GIMPLE
+'GIMPLE_ASM'                   x             x
+'GIMPLE_ASSIGN'                x             x
+'GIMPLE_BIND'                  x
+'GIMPLE_CALL'                  x             x
+'GIMPLE_CATCH'                 x
+'GIMPLE_COND'                  x             x
+'GIMPLE_DEBUG'                 x             x
+'GIMPLE_EH_FILTER'             x
+'GIMPLE_GOTO'                  x             x
+'GIMPLE_LABEL'                 x             x
+'GIMPLE_NOP'                   x             x
+'GIMPLE_OMP_ATOMIC_LOAD'       x             x
+'GIMPLE_OMP_ATOMIC_STORE'      x             x
+'GIMPLE_OMP_CONTINUE'          x             x
+'GIMPLE_OMP_CRITICAL'          x             x
+'GIMPLE_OMP_FOR'               x             x
+'GIMPLE_OMP_MASTER'            x             x
+'GIMPLE_OMP_ORDERED'           x             x
+'GIMPLE_OMP_PARALLEL'          x             x
+'GIMPLE_OMP_RETURN'            x             x
+'GIMPLE_OMP_SECTION'           x             x
+'GIMPLE_OMP_SECTIONS'          x             x
+'GIMPLE_OMP_SECTIONS_SWITCH'   x             x
+'GIMPLE_OMP_SINGLE'            x             x
+'GIMPLE_PHI'                                 x
+'GIMPLE_RESX'                                x
+'GIMPLE_RETURN'                x             x
+'GIMPLE_SWITCH'                x             x
+'GIMPLE_TRY'                   x
+
+
+File: gccint.info,  Node: GIMPLE Exception Handling,  Next: Temporaries,  Prev: GIMPLE instruction set,  Up: GIMPLE
+
+11.3 Exception Handling
+=======================
+
+Other exception handling constructs are represented using
+'GIMPLE_TRY_CATCH'.  'GIMPLE_TRY_CATCH' has two operands.  The first
+operand is a sequence of statements to execute.  If executing these
+statements does not throw an exception, then the second operand is
+ignored.  Otherwise, if an exception is thrown, then the second operand
+of the 'GIMPLE_TRY_CATCH' is checked.  The second operand may have the
+following forms:
+
+  1. A sequence of statements to execute.  When an exception occurs,
+     these statements are executed, and then the exception is rethrown.
+
+  2. A sequence of 'GIMPLE_CATCH' statements.  Each 'GIMPLE_CATCH' has a
+     list of applicable exception types and handler code.  If the thrown
+     exception matches one of the caught types, the associated handler
+     code is executed.  If the handler code falls off the bottom,
+     execution continues after the original 'GIMPLE_TRY_CATCH'.
+
+  3. A 'GIMPLE_EH_FILTER' statement.  This has a list of permitted
+     exception types, and code to handle a match failure.  If the thrown
+     exception does not match one of the allowed types, the associated
+     match failure code is executed.  If the thrown exception does
+     match, it continues unwinding the stack looking for the next
+     handler.
+
+ Currently throwing an exception is not directly represented in GIMPLE,
+since it is implemented by calling a function.  At some point in the
+future we will want to add some way to express that the call will throw
+an exception of a known type.
+
+ Just before running the optimizers, the compiler lowers the high-level
+EH constructs above into a set of 'goto's, magic labels, and EH regions.
+Continuing to unwind at the end of a cleanup is represented with a
+'GIMPLE_RESX'.
+
+
+File: gccint.info,  Node: Temporaries,  Next: Operands,  Prev: GIMPLE Exception Handling,  Up: GIMPLE
+
+11.4 Temporaries
+================
+
+When gimplification encounters a subexpression that is too complex, it
+creates a new temporary variable to hold the value of the subexpression,
+and adds a new statement to initialize it before the current statement.
+These special temporaries are known as 'expression temporaries', and are
+allocated using 'get_formal_tmp_var'.  The compiler tries to always
+evaluate identical expressions into the same temporary, to simplify
+elimination of redundant calculations.
+
+ We can only use expression temporaries when we know that it will not be
+reevaluated before its value is used, and that it will not be otherwise
+modified(1).  Other temporaries can be allocated using
+'get_initialized_tmp_var' or 'create_tmp_var'.
+
+ Currently, an expression like 'a = b + 5' is not reduced any further.
+We tried converting it to something like
+     T1 = b + 5;
+     a = T1;
+ but this bloated the representation for minimal benefit.  However, a
+variable which must live in memory cannot appear in an expression; its
+value is explicitly loaded into a temporary first.  Similarly, storing
+the value of an expression to a memory variable goes through a
+temporary.
+
+   ---------- Footnotes ----------
+
+   (1) These restrictions are derived from those in Morgan 4.8.
+
+
+File: gccint.info,  Node: Operands,  Next: Manipulating GIMPLE statements,  Prev: Temporaries,  Up: GIMPLE
+
+11.5 Operands
+=============
+
+In general, expressions in GIMPLE consist of an operation and the
+appropriate number of simple operands; these operands must either be a
+GIMPLE rvalue ('is_gimple_val'), i.e. a constant or a register variable.
+More complex operands are factored out into temporaries, so that
+     a = b + c + d
+ becomes
+     T1 = b + c;
+     a = T1 + d;
+
+ The same rule holds for arguments to a 'GIMPLE_CALL'.
+
+ The target of an assignment is usually a variable, but can also be a
+'MEM_REF' or a compound lvalue as described below.
+
+* Menu:
+
+* Compound Expressions::
+* Compound Lvalues::
+* Conditional Expressions::
+* Logical Operators::
+
+
+File: gccint.info,  Node: Compound Expressions,  Next: Compound Lvalues,  Up: Operands
+
+11.5.1 Compound Expressions
+---------------------------
+
+The left-hand side of a C comma expression is simply moved into a
+separate statement.
+
+
+File: gccint.info,  Node: Compound Lvalues,  Next: Conditional Expressions,  Prev: Compound Expressions,  Up: Operands
+
+11.5.2 Compound Lvalues
+-----------------------
+
+Currently compound lvalues involving array and structure field
+references are not broken down; an expression like 'a.b[2] = 42' is not
+reduced any further (though complex array subscripts are).  This
+restriction is a workaround for limitations in later optimizers; if we
+were to convert this to
+
+     T1 = &a.b;
+     T1[2] = 42;
+
+ alias analysis would not remember that the reference to 'T1[2]' came by
+way of 'a.b', so it would think that the assignment could alias another
+member of 'a'; this broke 'struct-alias-1.c'.  Future optimizer
+improvements may make this limitation unnecessary.
+
+
+File: gccint.info,  Node: Conditional Expressions,  Next: Logical Operators,  Prev: Compound Lvalues,  Up: Operands
+
+11.5.3 Conditional Expressions
+------------------------------
+
+A C '?:' expression is converted into an 'if' statement with each branch
+assigning to the same temporary.  So,
+
+     a = b ? c : d;
+ becomes
+     if (b == 1)
+       T1 = c;
+     else
+       T1 = d;
+     a = T1;
+
+ The GIMPLE level if-conversion pass re-introduces '?:' expression, if
+appropriate.  It is used to vectorize loops with conditions using vector
+conditional operations.
+
+ Note that in GIMPLE, 'if' statements are represented using
+'GIMPLE_COND', as described below.
+
+
+File: gccint.info,  Node: Logical Operators,  Prev: Conditional Expressions,  Up: Operands
+
+11.5.4 Logical Operators
+------------------------
+
+Except when they appear in the condition operand of a 'GIMPLE_COND',
+logical 'and' and 'or' operators are simplified as follows: 'a = b && c'
+becomes
+
+     T1 = (bool)b;
+     if (T1 == true)
+       T1 = (bool)c;
+     a = T1;
+
+ Note that 'T1' in this example cannot be an expression temporary,
+because it has two different assignments.
+
+11.5.5 Manipulating operands
+----------------------------
+
+All gimple operands are of type 'tree'.  But only certain types of trees
+are allowed to be used as operand tuples.  Basic validation is
+controlled by the function 'get_gimple_rhs_class', which given a tree
+code, returns an 'enum' with the following values of type 'enum
+gimple_rhs_class'
+
+   * 'GIMPLE_INVALID_RHS' The tree cannot be used as a GIMPLE operand.
+
+   * 'GIMPLE_TERNARY_RHS' The tree is a valid GIMPLE ternary operation.
+
+   * 'GIMPLE_BINARY_RHS' The tree is a valid GIMPLE binary operation.
+
+   * 'GIMPLE_UNARY_RHS' The tree is a valid GIMPLE unary operation.
+
+   * 'GIMPLE_SINGLE_RHS' The tree is a single object, that cannot be
+     split into simpler operands (for instance, 'SSA_NAME', 'VAR_DECL',
+     'COMPONENT_REF', etc).
+
+     This operand class also acts as an escape hatch for tree nodes that
+     may be flattened out into the operand vector, but would need more
+     than two slots on the RHS. For instance, a 'COND_EXPR' expression
+     of the form '(a op b) ? x : y' could be flattened out on the
+     operand vector using 4 slots, but it would also require additional
+     processing to distinguish 'c = a op b' from 'c = a op b ? x : y'.
+     Something similar occurs with 'ASSERT_EXPR'.  In time, these
+     special case tree expressions should be flattened into the operand
+     vector.
+
+ For tree nodes in the categories 'GIMPLE_TERNARY_RHS',
+'GIMPLE_BINARY_RHS' and 'GIMPLE_UNARY_RHS', they cannot be stored inside
+tuples directly.  They first need to be flattened and separated into
+individual components.  For instance, given the GENERIC expression
+
+     a = b + c
+
+ its tree representation is:
+
+     MODIFY_EXPR <VAR_DECL  <a>, PLUS_EXPR <VAR_DECL <b>, VAR_DECL <c>>>
+
+ In this case, the GIMPLE form for this statement is logically identical
+to its GENERIC form but in GIMPLE, the 'PLUS_EXPR' on the RHS of the
+assignment is not represented as a tree, instead the two operands are
+taken out of the 'PLUS_EXPR' sub-tree and flattened into the GIMPLE
+tuple as follows:
+
+     GIMPLE_ASSIGN <PLUS_EXPR, VAR_DECL <a>, VAR_DECL <b>, VAR_DECL <c>>
+
+11.5.6 Operand vector allocation
+--------------------------------
+
+The operand vector is stored at the bottom of the three tuple structures
+that accept operands.  This means, that depending on the code of a given
+statement, its operand vector will be at different offsets from the base
+of the structure.  To access tuple operands use the following accessors
+
+ -- GIMPLE function: unsigned gimple_num_ops (gimple g)
+     Returns the number of operands in statement G.
+
+ -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
+     Returns operand 'I' from statement 'G'.
+
+ -- GIMPLE function: tree * gimple_ops (gimple g)
+     Returns a pointer into the operand vector for statement 'G'.  This
+     is computed using an internal table called 'gimple_ops_offset_'[].
+     This table is indexed by the gimple code of 'G'.
+
+     When the compiler is built, this table is filled-in using the sizes
+     of the structures used by each statement code defined in
+     gimple.def.  Since the operand vector is at the bottom of the
+     structure, for a gimple code 'C' the offset is computed as sizeof
+     (struct-of 'C') - sizeof (tree).
+
+     This mechanism adds one memory indirection to every access when
+     using 'gimple_op'(), if this becomes a bottleneck, a pass can
+     choose to memoize the result from 'gimple_ops'() and use that to
+     access the operands.
+
+11.5.7 Operand validation
+-------------------------
+
+When adding a new operand to a gimple statement, the operand will be
+validated according to what each tuple accepts in its operand vector.
+These predicates are called by the 'gimple_NAME_set_...()'.  Each tuple
+will use one of the following predicates (Note, this list is not
+exhaustive):
+
+ -- GIMPLE function: bool is_gimple_val (tree t)
+     Returns true if t is a "GIMPLE value", which are all the
+     non-addressable stack variables (variables for which
+     'is_gimple_reg' returns true) and constants (expressions for which
+     'is_gimple_min_invariant' returns true).
+
+ -- GIMPLE function: bool is_gimple_addressable (tree t)
+     Returns true if t is a symbol or memory reference whose address can
+     be taken.
+
+ -- GIMPLE function: bool is_gimple_asm_val (tree t)
+     Similar to 'is_gimple_val' but it also accepts hard registers.
+
+ -- GIMPLE function: bool is_gimple_call_addr (tree t)
+     Return true if t is a valid expression to use as the function
+     called by a 'GIMPLE_CALL'.
+
+ -- GIMPLE function: bool is_gimple_mem_ref_addr (tree t)
+     Return true if t is a valid expression to use as first operand of a
+     'MEM_REF' expression.
+
+ -- GIMPLE function: bool is_gimple_constant (tree t)
+     Return true if t is a valid gimple constant.
+
+ -- GIMPLE function: bool is_gimple_min_invariant (tree t)
+     Return true if t is a valid minimal invariant.  This is different
+     from constants, in that the specific value of t may not be known at
+     compile time, but it is known that it doesn't change (e.g., the
+     address of a function local variable).
+
+ -- GIMPLE function: bool is_gimple_ip_invariant (tree t)
+     Return true if t is an interprocedural invariant.  This means that
+     t is a valid invariant in all functions (e.g.  it can be an address
+     of a global variable but not of a local one).
+
+ -- GIMPLE function: bool is_gimple_ip_invariant_address (tree t)
+     Return true if t is an 'ADDR_EXPR' that does not change once the
+     program is running (and which is valid in all functions).
+
+11.5.8 Statement validation
+---------------------------
+
+ -- GIMPLE function: bool is_gimple_assign (gimple g)
+     Return true if the code of g is 'GIMPLE_ASSIGN'.
+
+ -- GIMPLE function: bool is_gimple_call (gimple g)
+     Return true if the code of g is 'GIMPLE_CALL'.
+
+ -- GIMPLE function: bool is_gimple_debug (gimple g)
+     Return true if the code of g is 'GIMPLE_DEBUG'.
+
+ -- GIMPLE function: bool gimple_assign_cast_p (gimple g)
+     Return true if g is a 'GIMPLE_ASSIGN' that performs a type cast
+     operation.
+
+ -- GIMPLE function: bool gimple_debug_bind_p (gimple g)
+     Return true if g is a 'GIMPLE_DEBUG' that binds the value of an
+     expression to a variable.
+
+ -- GIMPLE function: bool is_gimple_omp (gimple g)
+     Return true if g is any of the OpenMP codes.
+
+
+File: gccint.info,  Node: Manipulating GIMPLE statements,  Next: Tuple specific accessors,  Prev: Operands,  Up: GIMPLE
+
+11.6 Manipulating GIMPLE statements
+===================================
+
+This section documents all the functions available to handle each of the
+GIMPLE instructions.
+
+11.6.1 Common accessors
+-----------------------
+
+The following are common accessors for gimple statements.
+
+ -- GIMPLE function: enum gimple_code gimple_code (gimple g)
+     Return the code for statement 'G'.
+
+ -- GIMPLE function: basic_block gimple_bb (gimple g)
+     Return the basic block to which statement 'G' belongs to.
+
+ -- GIMPLE function: tree gimple_block (gimple g)
+     Return the lexical scope block holding statement 'G'.
+
+ -- GIMPLE function: tree gimple_expr_type (gimple stmt)
+     Return the type of the main expression computed by 'STMT'.  Return
+     'void_type_node' if 'STMT' computes nothing.  This will only return
+     something meaningful for 'GIMPLE_ASSIGN', 'GIMPLE_COND' and
+     'GIMPLE_CALL'.  For all other tuple codes, it will return
+     'void_type_node'.
+
+ -- GIMPLE function: enum tree_code gimple_expr_code (gimple stmt)
+     Return the tree code for the expression computed by 'STMT'.  This
+     is only meaningful for 'GIMPLE_CALL', 'GIMPLE_ASSIGN' and
+     'GIMPLE_COND'.  If 'STMT' is 'GIMPLE_CALL', it will return
+     'CALL_EXPR'.  For 'GIMPLE_COND', it returns the code of the
+     comparison predicate.  For 'GIMPLE_ASSIGN' it returns the code of
+     the operation performed by the 'RHS' of the assignment.
+
+ -- GIMPLE function: void gimple_set_block (gimple g, tree block)
+     Set the lexical scope block of 'G' to 'BLOCK'.
+
+ -- GIMPLE function: location_t gimple_locus (gimple g)
+     Return locus information for statement 'G'.
+
+ -- GIMPLE function: void gimple_set_locus (gimple g, location_t locus)
+     Set locus information for statement 'G'.
+
+ -- GIMPLE function: bool gimple_locus_empty_p (gimple g)
+     Return true if 'G' does not have locus information.
+
+ -- GIMPLE function: bool gimple_no_warning_p (gimple stmt)
+     Return true if no warnings should be emitted for statement 'STMT'.
+
+ -- GIMPLE function: void gimple_set_visited (gimple stmt, bool
+          visited_p)
+     Set the visited status on statement 'STMT' to 'VISITED_P'.
+
+ -- GIMPLE function: bool gimple_visited_p (gimple stmt)
+     Return the visited status on statement 'STMT'.
+
+ -- GIMPLE function: void gimple_set_plf (gimple stmt, enum plf_mask
+          plf, bool val_p)
+     Set pass local flag 'PLF' on statement 'STMT' to 'VAL_P'.
+
+ -- GIMPLE function: unsigned int gimple_plf (gimple stmt, enum plf_mask
+          plf)
+     Return the value of pass local flag 'PLF' on statement 'STMT'.
+
+ -- GIMPLE function: bool gimple_has_ops (gimple g)
+     Return true if statement 'G' has register or memory operands.
+
+ -- GIMPLE function: bool gimple_has_mem_ops (gimple g)
+     Return true if statement 'G' has memory operands.
+
+ -- GIMPLE function: unsigned gimple_num_ops (gimple g)
+     Return the number of operands for statement 'G'.
+
+ -- GIMPLE function: tree * gimple_ops (gimple g)
+     Return the array of operands for statement 'G'.
+
+ -- GIMPLE function: tree gimple_op (gimple g, unsigned i)
+     Return operand 'I' for statement 'G'.
+
+ -- GIMPLE function: tree * gimple_op_ptr (gimple g, unsigned i)
+     Return a pointer to operand 'I' for statement 'G'.
+
+ -- GIMPLE function: void gimple_set_op (gimple g, unsigned i, tree op)
+     Set operand 'I' of statement 'G' to 'OP'.
+
+ -- GIMPLE function: bitmap gimple_addresses_taken (gimple stmt)
+     Return the set of symbols that have had their address taken by
+     'STMT'.
+
+ -- GIMPLE function: struct def_optype_d * gimple_def_ops (gimple g)
+     Return the set of 'DEF' operands for statement 'G'.
+
+ -- GIMPLE function: void gimple_set_def_ops (gimple g, struct
+          def_optype_d *def)
+     Set 'DEF' to be the set of 'DEF' operands for statement 'G'.
+
+ -- GIMPLE function: struct use_optype_d * gimple_use_ops (gimple g)
+     Return the set of 'USE' operands for statement 'G'.
+
+ -- GIMPLE function: void gimple_set_use_ops (gimple g, struct
+          use_optype_d *use)
+     Set 'USE' to be the set of 'USE' operands for statement 'G'.
+
+ -- GIMPLE function: struct voptype_d * gimple_vuse_ops (gimple g)
+     Return the set of 'VUSE' operands for statement 'G'.
+
+ -- GIMPLE function: void gimple_set_vuse_ops (gimple g, struct
+          voptype_d *ops)
+     Set 'OPS' to be the set of 'VUSE' operands for statement 'G'.
+
+ -- GIMPLE function: struct voptype_d * gimple_vdef_ops (gimple g)
+     Return the set of 'VDEF' operands for statement 'G'.
+
+ -- GIMPLE function: void gimple_set_vdef_ops (gimple g, struct
+          voptype_d *ops)
+     Set 'OPS' to be the set of 'VDEF' operands for statement 'G'.
+
+ -- GIMPLE function: bitmap gimple_loaded_syms (gimple g)
+     Return the set of symbols loaded by statement 'G'.  Each element of
+     the set is the 'DECL_UID' of the corresponding symbol.
+
+ -- GIMPLE function: bitmap gimple_stored_syms (gimple g)
+     Return the set of symbols stored by statement 'G'.  Each element of
+     the set is the 'DECL_UID' of the corresponding symbol.
+
+ -- GIMPLE function: bool gimple_modified_p (gimple g)
+     Return true if statement 'G' has operands and the modified field
+     has been set.
+
+ -- GIMPLE function: bool gimple_has_volatile_ops (gimple stmt)
+     Return true if statement 'STMT' contains volatile operands.
+
+ -- GIMPLE function: void gimple_set_has_volatile_ops (gimple stmt, bool
+          volatilep)
+     Return true if statement 'STMT' contains volatile operands.
+
+ -- GIMPLE function: void update_stmt (gimple s)
+     Mark statement 'S' as modified, and update it.
+
+ -- GIMPLE function: void update_stmt_if_modified (gimple s)
+     Update statement 'S' if it has been marked modified.
+
+ -- GIMPLE function: gimple gimple_copy (gimple stmt)
+     Return a deep copy of statement 'STMT'.
+
+
+File: gccint.info,  Node: Tuple specific accessors,  Next: GIMPLE sequences,  Prev: Manipulating GIMPLE statements,  Up: GIMPLE
+
+11.7 Tuple specific accessors
+=============================
+
+* Menu:
+
+* 'GIMPLE_ASM'::
+* 'GIMPLE_ASSIGN'::
+* 'GIMPLE_BIND'::
+* 'GIMPLE_CALL'::
+* 'GIMPLE_CATCH'::
+* 'GIMPLE_COND'::
+* 'GIMPLE_DEBUG'::
+* 'GIMPLE_EH_FILTER'::
+* 'GIMPLE_LABEL'::
+* 'GIMPLE_NOP'::
+* 'GIMPLE_OMP_ATOMIC_LOAD'::
+* 'GIMPLE_OMP_ATOMIC_STORE'::
+* 'GIMPLE_OMP_CONTINUE'::
+* 'GIMPLE_OMP_CRITICAL'::
+* 'GIMPLE_OMP_FOR'::
+* 'GIMPLE_OMP_MASTER'::
+* 'GIMPLE_OMP_ORDERED'::
+* 'GIMPLE_OMP_PARALLEL'::
+* 'GIMPLE_OMP_RETURN'::
+* 'GIMPLE_OMP_SECTION'::
+* 'GIMPLE_OMP_SECTIONS'::
+* 'GIMPLE_OMP_SINGLE'::
+* 'GIMPLE_PHI'::
+* 'GIMPLE_RESX'::
+* 'GIMPLE_RETURN'::
+* 'GIMPLE_SWITCH'::
+* 'GIMPLE_TRY'::
+* 'GIMPLE_WITH_CLEANUP_EXPR'::
+
+
+File: gccint.info,  Node: 'GIMPLE_ASM',  Next: 'GIMPLE_ASSIGN',  Up: Tuple specific accessors
+
+11.7.1 'GIMPLE_ASM'
+-------------------
+
+ -- GIMPLE function: gimple gimple_build_asm (const char *string,
+          ninputs, noutputs, nclobbers, ...)
+     Build a 'GIMPLE_ASM' statement.  This statement is used for
+     building in-line assembly constructs.  'STRING' is the assembly
+     code.  'NINPUT' is the number of register inputs.  'NOUTPUT' is the
+     number of register outputs.  'NCLOBBERS' is the number of clobbered
+     registers.  The rest of the arguments trees for each input, output,
+     and clobbered registers.
+
+ -- GIMPLE function: gimple gimple_build_asm_vec (const char *,
+          VEC(tree,gc) *, VEC(tree,gc) *, VEC(tree,gc) *)
+     Identical to gimple_build_asm, but the arguments are passed in
+     VECs.
+
+ -- GIMPLE function: unsigned gimple_asm_ninputs (gimple g)
+     Return the number of input operands for 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: unsigned gimple_asm_noutputs (gimple g)
+     Return the number of output operands for 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: unsigned gimple_asm_nclobbers (gimple g)
+     Return the number of clobber operands for 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: tree gimple_asm_input_op (gimple g, unsigned index)
+     Return input operand 'INDEX' of 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: void gimple_asm_set_input_op (gimple g, unsigned
+          index, tree in_op)
+     Set 'IN_OP' to be input operand 'INDEX' in 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: tree gimple_asm_output_op (gimple g, unsigned
+          index)
+     Return output operand 'INDEX' of 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: void gimple_asm_set_output_op (gimple g, unsigned
+          index, tree out_op)
+     Set 'OUT_OP' to be output operand 'INDEX' in 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: tree gimple_asm_clobber_op (gimple g, unsigned
+          index)
+     Return clobber operand 'INDEX' of 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: void gimple_asm_set_clobber_op (gimple g, unsigned
+          index, tree clobber_op)
+     Set 'CLOBBER_OP' to be clobber operand 'INDEX' in 'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: const char * gimple_asm_string (gimple g)
+     Return the string representing the assembly instruction in
+     'GIMPLE_ASM' 'G'.
+
+ -- GIMPLE function: bool gimple_asm_volatile_p (gimple g)
+     Return true if 'G' is an asm statement marked volatile.
+
+ -- GIMPLE function: void gimple_asm_set_volatile (gimple g)
+     Mark asm statement 'G' as volatile.
+
+
+File: gccint.info,  Node: 'GIMPLE_ASSIGN',  Next: 'GIMPLE_BIND',  Prev: 'GIMPLE_ASM',  Up: Tuple specific accessors
+
+11.7.2 'GIMPLE_ASSIGN'
+----------------------
+
+ -- GIMPLE function: gimple gimple_build_assign (tree lhs, tree rhs)
+     Build a 'GIMPLE_ASSIGN' statement.  The left-hand side is an lvalue
+     passed in lhs.  The right-hand side can be either a unary or binary
+     tree expression.  The expression tree rhs will be flattened and its
+     operands assigned to the corresponding operand slots in the new
+     statement.  This function is useful when you already have a tree
+     expression that you want to convert into a tuple.  However, try to
+     avoid building expression trees for the sole purpose of calling
+     this function.  If you already have the operands in separate trees,
+     it is better to use 'gimple_build_assign_with_ops'.
+
+ -- GIMPLE function: gimple gimplify_assign (tree dst, tree src,
+          gimple_seq *seq_p)
+     Build a new 'GIMPLE_ASSIGN' tuple and append it to the end of
+     '*SEQ_P'.
+
+ 'DST'/'SRC' are the destination and source respectively.  You can pass
+ungimplified trees in 'DST' or 'SRC', in which case they will be
+converted to a gimple operand if necessary.
+
+ This function returns the newly created 'GIMPLE_ASSIGN' tuple.
+
+ -- GIMPLE function: gimple gimple_build_assign_with_ops (enum tree_code
+          subcode, tree lhs, tree op1, tree op2)
+     This function is similar to 'gimple_build_assign', but is used to
+     build a 'GIMPLE_ASSIGN' statement when the operands of the
+     right-hand side of the assignment are already split into different
+     operands.
+
+     The left-hand side is an lvalue passed in lhs.  Subcode is the
+     'tree_code' for the right-hand side of the assignment.  Op1 and op2
+     are the operands.  If op2 is null, subcode must be a 'tree_code'
+     for a unary expression.
+
+ -- GIMPLE function: enum tree_code gimple_assign_rhs_code (gimple g)
+     Return the code of the expression computed on the 'RHS' of
+     assignment statement 'G'.
+
+ -- GIMPLE function: enum gimple_rhs_class gimple_assign_rhs_class
+          (gimple g)
+     Return the gimple rhs class of the code for the expression computed
+     on the rhs of assignment statement 'G'.  This will never return
+     'GIMPLE_INVALID_RHS'.
+
+ -- GIMPLE function: tree gimple_assign_lhs (gimple g)
+     Return the 'LHS' of assignment statement 'G'.
+
+ -- GIMPLE function: tree * gimple_assign_lhs_ptr (gimple g)
+     Return a pointer to the 'LHS' of assignment statement 'G'.
+
+ -- GIMPLE function: tree gimple_assign_rhs1 (gimple g)
+     Return the first operand on the 'RHS' of assignment statement 'G'.
+
+ -- GIMPLE function: tree * gimple_assign_rhs1_ptr (gimple g)
+     Return the address of the first operand on the 'RHS' of assignment
+     statement 'G'.
+
+ -- GIMPLE function: tree gimple_assign_rhs2 (gimple g)
+     Return the second operand on the 'RHS' of assignment statement 'G'.
+
+ -- GIMPLE function: tree * gimple_assign_rhs2_ptr (gimple g)
+     Return the address of the second operand on the 'RHS' of assignment
+     statement 'G'.
+
+ -- GIMPLE function: tree gimple_assign_rhs3 (gimple g)
+     Return the third operand on the 'RHS' of assignment statement 'G'.
+
+ -- GIMPLE function: tree * gimple_assign_rhs3_ptr (gimple g)
+     Return the address of the third operand on the 'RHS' of assignment
+     statement 'G'.
+
+ -- GIMPLE function: void gimple_assign_set_lhs (gimple g, tree lhs)
+     Set 'LHS' to be the 'LHS' operand of assignment statement 'G'.
+
+ -- GIMPLE function: void gimple_assign_set_rhs1 (gimple g, tree rhs)
+     Set 'RHS' to be the first operand on the 'RHS' of assignment
+     statement 'G'.
+
+ -- GIMPLE function: void gimple_assign_set_rhs2 (gimple g, tree rhs)
+     Set 'RHS' to be the second operand on the 'RHS' of assignment
+     statement 'G'.
+
+ -- GIMPLE function: void gimple_assign_set_rhs3 (gimple g, tree rhs)
+     Set 'RHS' to be the third operand on the 'RHS' of assignment
+     statement 'G'.
+
+ -- GIMPLE function: bool gimple_assign_cast_p (gimple s)
+     Return true if 'S' is a type-cast assignment.
+
+
+File: gccint.info,  Node: 'GIMPLE_BIND',  Next: 'GIMPLE_CALL',  Prev: 'GIMPLE_ASSIGN',  Up: Tuple specific accessors
+
+11.7.3 'GIMPLE_BIND'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_bind (tree vars, gimple_seq
+          body)
+     Build a 'GIMPLE_BIND' statement with a list of variables in 'VARS'
+     and a body of statements in sequence 'BODY'.
+
+ -- GIMPLE function: tree gimple_bind_vars (gimple g)
+     Return the variables declared in the 'GIMPLE_BIND' statement 'G'.
+
+ -- GIMPLE function: void gimple_bind_set_vars (gimple g, tree vars)
+     Set 'VARS' to be the set of variables declared in the 'GIMPLE_BIND'
+     statement 'G'.
+
+ -- GIMPLE function: void gimple_bind_append_vars (gimple g, tree vars)
+     Append 'VARS' to the set of variables declared in the 'GIMPLE_BIND'
+     statement 'G'.
+
+ -- GIMPLE function: gimple_seq gimple_bind_body (gimple g)
+     Return the GIMPLE sequence contained in the 'GIMPLE_BIND' statement
+     'G'.
+
+ -- GIMPLE function: void gimple_bind_set_body (gimple g, gimple_seq
+          seq)
+     Set 'SEQ' to be sequence contained in the 'GIMPLE_BIND' statement
+     'G'.
+
+ -- GIMPLE function: void gimple_bind_add_stmt (gimple gs, gimple stmt)
+     Append a statement to the end of a 'GIMPLE_BIND''s body.
+
+ -- GIMPLE function: void gimple_bind_add_seq (gimple gs, gimple_seq
+          seq)
+     Append a sequence of statements to the end of a 'GIMPLE_BIND''s
+     body.
+
+ -- GIMPLE function: tree gimple_bind_block (gimple g)
+     Return the 'TREE_BLOCK' node associated with 'GIMPLE_BIND'
+     statement 'G'.  This is analogous to the 'BIND_EXPR_BLOCK' field in
+     trees.
+
+ -- GIMPLE function: void gimple_bind_set_block (gimple g, tree block)
+     Set 'BLOCK' to be the 'TREE_BLOCK' node associated with
+     'GIMPLE_BIND' statement 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_CALL',  Next: 'GIMPLE_CATCH',  Prev: 'GIMPLE_BIND',  Up: Tuple specific accessors
+
+11.7.4 'GIMPLE_CALL'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_call (tree fn, unsigned nargs,
+          ...)
+     Build a 'GIMPLE_CALL' statement to function 'FN'.  The argument
+     'FN' must be either a 'FUNCTION_DECL' or a gimple call address as
+     determined by 'is_gimple_call_addr'.  'NARGS' are the number of
+     arguments.  The rest of the arguments follow the argument 'NARGS',
+     and must be trees that are valid as rvalues in gimple (i.e., each
+     operand is validated with 'is_gimple_operand').
+
+ -- GIMPLE function: gimple gimple_build_call_from_tree (tree call_expr)
+     Build a 'GIMPLE_CALL' from a 'CALL_EXPR' node.  The arguments and
+     the function are taken from the expression directly.  This routine
+     assumes that 'call_expr' is already in GIMPLE form.  That is, its
+     operands are GIMPLE values and the function call needs no further
+     simplification.  All the call flags in 'call_expr' are copied over
+     to the new 'GIMPLE_CALL'.
+
+ -- GIMPLE function: gimple gimple_build_call_vec (tree fn, 'VEC'(tree,
+          heap) *args)
+     Identical to 'gimple_build_call' but the arguments are stored in a
+     'VEC'().
+
+ -- GIMPLE function: tree gimple_call_lhs (gimple g)
+     Return the 'LHS' of call statement 'G'.
+
+ -- GIMPLE function: tree * gimple_call_lhs_ptr (gimple g)
+     Return a pointer to the 'LHS' of call statement 'G'.
+
+ -- GIMPLE function: void gimple_call_set_lhs (gimple g, tree lhs)
+     Set 'LHS' to be the 'LHS' operand of call statement 'G'.
+
+ -- GIMPLE function: tree gimple_call_fn (gimple g)
+     Return the tree node representing the function called by call
+     statement 'G'.
+
+ -- GIMPLE function: void gimple_call_set_fn (gimple g, tree fn)
+     Set 'FN' to be the function called by call statement 'G'.  This has
+     to be a gimple value specifying the address of the called function.
+
+ -- GIMPLE function: tree gimple_call_fndecl (gimple g)
+     If a given 'GIMPLE_CALL''s callee is a 'FUNCTION_DECL', return it.
+     Otherwise return 'NULL'.  This function is analogous to
+     'get_callee_fndecl' in 'GENERIC'.
+
+ -- GIMPLE function: tree gimple_call_set_fndecl (gimple g, tree fndecl)
+     Set the called function to 'FNDECL'.
+
+ -- GIMPLE function: tree gimple_call_return_type (gimple g)
+     Return the type returned by call statement 'G'.
+
+ -- GIMPLE function: tree gimple_call_chain (gimple g)
+     Return the static chain for call statement 'G'.
+
+ -- GIMPLE function: void gimple_call_set_chain (gimple g, tree chain)
+     Set 'CHAIN' to be the static chain for call statement 'G'.
+
+ -- GIMPLE function: unsigned gimple_call_num_args (gimple g)
+     Return the number of arguments used by call statement 'G'.
+
+ -- GIMPLE function: tree gimple_call_arg (gimple g, unsigned index)
+     Return the argument at position 'INDEX' for call statement 'G'.
+     The first argument is 0.
+
+ -- GIMPLE function: tree * gimple_call_arg_ptr (gimple g, unsigned
+          index)
+     Return a pointer to the argument at position 'INDEX' for call
+     statement 'G'.
+
+ -- GIMPLE function: void gimple_call_set_arg (gimple g, unsigned index,
+          tree arg)
+     Set 'ARG' to be the argument at position 'INDEX' for call statement
+     'G'.
+
+ -- GIMPLE function: void gimple_call_set_tail (gimple s)
+     Mark call statement 'S' as being a tail call (i.e., a call just
+     before the exit of a function).  These calls are candidate for tail
+     call optimization.
+
+ -- GIMPLE function: bool gimple_call_tail_p (gimple s)
+     Return true if 'GIMPLE_CALL' 'S' is marked as a tail call.
+
+ -- GIMPLE function: void gimple_call_mark_uninlinable (gimple s)
+     Mark 'GIMPLE_CALL' 'S' as being uninlinable.
+
+ -- GIMPLE function: bool gimple_call_cannot_inline_p (gimple s)
+     Return true if 'GIMPLE_CALL' 'S' cannot be inlined.
+
+ -- GIMPLE function: bool gimple_call_noreturn_p (gimple s)
+     Return true if 'S' is a noreturn call.
+
+ -- GIMPLE function: gimple gimple_call_copy_skip_args (gimple stmt,
+          bitmap args_to_skip)
+     Build a 'GIMPLE_CALL' identical to 'STMT' but skipping the
+     arguments in the positions marked by the set 'ARGS_TO_SKIP'.
+
+
+File: gccint.info,  Node: 'GIMPLE_CATCH',  Next: 'GIMPLE_COND',  Prev: 'GIMPLE_CALL',  Up: Tuple specific accessors
+
+11.7.5 'GIMPLE_CATCH'
+---------------------
+
+ -- GIMPLE function: gimple gimple_build_catch (tree types, gimple_seq
+          handler)
+     Build a 'GIMPLE_CATCH' statement.  'TYPES' are the tree types this
+     catch handles.  'HANDLER' is a sequence of statements with the code
+     for the handler.
+
+ -- GIMPLE function: tree gimple_catch_types (gimple g)
+     Return the types handled by 'GIMPLE_CATCH' statement 'G'.
+
+ -- GIMPLE function: tree * gimple_catch_types_ptr (gimple g)
+     Return a pointer to the types handled by 'GIMPLE_CATCH' statement
+     'G'.
+
+ -- GIMPLE function: gimple_seq gimple_catch_handler (gimple g)
+     Return the GIMPLE sequence representing the body of the handler of
+     'GIMPLE_CATCH' statement 'G'.
+
+ -- GIMPLE function: void gimple_catch_set_types (gimple g, tree t)
+     Set 'T' to be the set of types handled by 'GIMPLE_CATCH' 'G'.
+
+ -- GIMPLE function: void gimple_catch_set_handler (gimple g, gimple_seq
+          handler)
+     Set 'HANDLER' to be the body of 'GIMPLE_CATCH' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_COND',  Next: 'GIMPLE_DEBUG',  Prev: 'GIMPLE_CATCH',  Up: Tuple specific accessors
+
+11.7.6 'GIMPLE_COND'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_cond (enum tree_code pred_code,
+          tree lhs, tree rhs, tree t_label, tree f_label)
+     Build a 'GIMPLE_COND' statement.  'A' 'GIMPLE_COND' statement
+     compares 'LHS' and 'RHS' and if the condition in 'PRED_CODE' is
+     true, jump to the label in 't_label', otherwise jump to the label
+     in 'f_label'.  'PRED_CODE' are relational operator tree codes like
+     'EQ_EXPR', 'LT_EXPR', 'LE_EXPR', 'NE_EXPR', etc.
+
+ -- GIMPLE function: gimple gimple_build_cond_from_tree (tree cond, tree
+          t_label, tree f_label)
+     Build a 'GIMPLE_COND' statement from the conditional expression
+     tree 'COND'.  'T_LABEL' and 'F_LABEL' are as in
+     'gimple_build_cond'.
+
+ -- GIMPLE function: enum tree_code gimple_cond_code (gimple g)
+     Return the code of the predicate computed by conditional statement
+     'G'.
+
+ -- GIMPLE function: void gimple_cond_set_code (gimple g, enum tree_code
+          code)
+     Set 'CODE' to be the predicate code for the conditional statement
+     'G'.
+
+ -- GIMPLE function: tree gimple_cond_lhs (gimple g)
+     Return the 'LHS' of the predicate computed by conditional statement
+     'G'.
+
+ -- GIMPLE function: void gimple_cond_set_lhs (gimple g, tree lhs)
+     Set 'LHS' to be the 'LHS' operand of the predicate computed by
+     conditional statement 'G'.
+
+ -- GIMPLE function: tree gimple_cond_rhs (gimple g)
+     Return the 'RHS' operand of the predicate computed by conditional
+     'G'.
+
+ -- GIMPLE function: void gimple_cond_set_rhs (gimple g, tree rhs)
+     Set 'RHS' to be the 'RHS' operand of the predicate computed by
+     conditional statement 'G'.
+
+ -- GIMPLE function: tree gimple_cond_true_label (gimple g)
+     Return the label used by conditional statement 'G' when its
+     predicate evaluates to true.
+
+ -- GIMPLE function: void gimple_cond_set_true_label (gimple g, tree
+          label)
+     Set 'LABEL' to be the label used by conditional statement 'G' when
+     its predicate evaluates to true.
+
+ -- GIMPLE function: void gimple_cond_set_false_label (gimple g, tree
+          label)
+     Set 'LABEL' to be the label used by conditional statement 'G' when
+     its predicate evaluates to false.
+
+ -- GIMPLE function: tree gimple_cond_false_label (gimple g)
+     Return the label used by conditional statement 'G' when its
+     predicate evaluates to false.
+
+ -- GIMPLE function: void gimple_cond_make_false (gimple g)
+     Set the conditional 'COND_STMT' to be of the form 'if (1 == 0)'.
+
+ -- GIMPLE function: void gimple_cond_make_true (gimple g)
+     Set the conditional 'COND_STMT' to be of the form 'if (1 == 1)'.
+
+
+File: gccint.info,  Node: 'GIMPLE_DEBUG',  Next: 'GIMPLE_EH_FILTER',  Prev: 'GIMPLE_COND',  Up: Tuple specific accessors
+
+11.7.7 'GIMPLE_DEBUG'
+---------------------
+
+ -- GIMPLE function: gimple gimple_build_debug_bind (tree var, tree
+          value, gimple stmt)
+     Build a 'GIMPLE_DEBUG' statement with 'GIMPLE_DEBUG_BIND' of
+     'subcode'.  The effect of this statement is to tell debug
+     information generation machinery that the value of user variable
+     'var' is given by 'value' at that point, and to remain with that
+     value until 'var' runs out of scope, a dynamically-subsequent debug
+     bind statement overrides the binding, or conflicting values reach a
+     control flow merge point.  Even if components of the 'value'
+     expression change afterwards, the variable is supposed to retain
+     the same value, though not necessarily the same location.
+
+     It is expected that 'var' be most often a tree for automatic user
+     variables ('VAR_DECL' or 'PARM_DECL') that satisfy the requirements
+     for gimple registers, but it may also be a tree for a scalarized
+     component of a user variable ('ARRAY_REF', 'COMPONENT_REF'), or a
+     debug temporary ('DEBUG_EXPR_DECL').
+
+     As for 'value', it can be an arbitrary tree expression, but it is
+     recommended that it be in a suitable form for a gimple assignment
+     'RHS'.  It is not expected that user variables that could appear as
+     'var' ever appear in 'value', because in the latter we'd have their
+     'SSA_NAME's instead, but even if they were not in SSA form, user
+     variables appearing in 'value' are to be regarded as part of the
+     executable code space, whereas those in 'var' are to be regarded as
+     part of the source code space.  There is no way to refer to the
+     value bound to a user variable within a 'value' expression.
+
+     If 'value' is 'GIMPLE_DEBUG_BIND_NOVALUE', debug information
+     generation machinery is informed that the variable 'var' is
+     unbound, i.e., that its value is indeterminate, which sometimes
+     means it is really unavailable, and other times that the compiler
+     could not keep track of it.
+
+     Block and location information for the newly-created stmt are taken
+     from 'stmt', if given.
+
+ -- GIMPLE function: tree gimple_debug_bind_get_var (gimple stmt)
+     Return the user variable VAR that is bound at 'stmt'.
+
+ -- GIMPLE function: tree gimple_debug_bind_get_value (gimple stmt)
+     Return the value expression that is bound to a user variable at
+     'stmt'.
+
+ -- GIMPLE function: tree * gimple_debug_bind_get_value_ptr (gimple
+          stmt)
+     Return a pointer to the value expression that is bound to a user
+     variable at 'stmt'.
+
+ -- GIMPLE function: void gimple_debug_bind_set_var (gimple stmt, tree
+          var)
+     Modify the user variable bound at 'stmt' to VAR.
+
+ -- GIMPLE function: void gimple_debug_bind_set_value (gimple stmt, tree
+          var)
+     Modify the value bound to the user variable bound at 'stmt' to
+     VALUE.
+
+ -- GIMPLE function: void gimple_debug_bind_reset_value (gimple stmt)
+     Modify the value bound to the user variable bound at 'stmt' so that
+     the variable becomes unbound.
+
+ -- GIMPLE function: bool gimple_debug_bind_has_value_p (gimple stmt)
+     Return 'TRUE' if 'stmt' binds a user variable to a value, and
+     'FALSE' if it unbinds the variable.
+
+
+File: gccint.info,  Node: 'GIMPLE_EH_FILTER',  Next: 'GIMPLE_LABEL',  Prev: 'GIMPLE_DEBUG',  Up: Tuple specific accessors
+
+11.7.8 'GIMPLE_EH_FILTER'
+-------------------------
+
+ -- GIMPLE function: gimple gimple_build_eh_filter (tree types,
+          gimple_seq failure)
+     Build a 'GIMPLE_EH_FILTER' statement.  'TYPES' are the filter's
+     types.  'FAILURE' is a sequence with the filter's failure action.
+
+ -- GIMPLE function: tree gimple_eh_filter_types (gimple g)
+     Return the types handled by 'GIMPLE_EH_FILTER' statement 'G'.
+
+ -- GIMPLE function: tree * gimple_eh_filter_types_ptr (gimple g)
+     Return a pointer to the types handled by 'GIMPLE_EH_FILTER'
+     statement 'G'.
+
+ -- GIMPLE function: gimple_seq gimple_eh_filter_failure (gimple g)
+     Return the sequence of statement to execute when 'GIMPLE_EH_FILTER'
+     statement fails.
+
+ -- GIMPLE function: void gimple_eh_filter_set_types (gimple g, tree
+          types)
+     Set 'TYPES' to be the set of types handled by 'GIMPLE_EH_FILTER'
+     'G'.
+
+ -- GIMPLE function: void gimple_eh_filter_set_failure (gimple g,
+          gimple_seq failure)
+     Set 'FAILURE' to be the sequence of statements to execute on
+     failure for 'GIMPLE_EH_FILTER' 'G'.
+
+ -- GIMPLE function: bool gimple_eh_filter_must_not_throw (gimple g)
+     Return the 'EH_FILTER_MUST_NOT_THROW' flag.
+
+ -- GIMPLE function: void gimple_eh_filter_set_must_not_throw (gimple g,
+          bool mntp)
+     Set the 'EH_FILTER_MUST_NOT_THROW' flag.
+
+
+File: gccint.info,  Node: 'GIMPLE_LABEL',  Next: 'GIMPLE_NOP',  Prev: 'GIMPLE_EH_FILTER',  Up: Tuple specific accessors
+
+11.7.9 'GIMPLE_LABEL'
+---------------------
+
+ -- GIMPLE function: gimple gimple_build_label (tree label)
+     Build a 'GIMPLE_LABEL' statement with corresponding to the tree
+     label, 'LABEL'.
+
+ -- GIMPLE function: tree gimple_label_label (gimple g)
+     Return the 'LABEL_DECL' node used by 'GIMPLE_LABEL' statement 'G'.
+
+ -- GIMPLE function: void gimple_label_set_label (gimple g, tree label)
+     Set 'LABEL' to be the 'LABEL_DECL' node used by 'GIMPLE_LABEL'
+     statement 'G'.
+
+ -- GIMPLE function: gimple gimple_build_goto (tree dest)
+     Build a 'GIMPLE_GOTO' statement to label 'DEST'.
+
+ -- GIMPLE function: tree gimple_goto_dest (gimple g)
+     Return the destination of the unconditional jump 'G'.
+
+ -- GIMPLE function: void gimple_goto_set_dest (gimple g, tree dest)
+     Set 'DEST' to be the destination of the unconditional jump 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_NOP',  Next: 'GIMPLE_OMP_ATOMIC_LOAD',  Prev: 'GIMPLE_LABEL',  Up: Tuple specific accessors
+
+11.7.10 'GIMPLE_NOP'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_nop (void)
+     Build a 'GIMPLE_NOP' statement.
+
+ -- GIMPLE function: bool gimple_nop_p (gimple g)
+     Returns 'TRUE' if statement 'G' is a 'GIMPLE_NOP'.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_ATOMIC_LOAD',  Next: 'GIMPLE_OMP_ATOMIC_STORE',  Prev: 'GIMPLE_NOP',  Up: Tuple specific accessors
+
+11.7.11 'GIMPLE_OMP_ATOMIC_LOAD'
+--------------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_atomic_load (tree lhs, tree
+          rhs)
+     Build a 'GIMPLE_OMP_ATOMIC_LOAD' statement.  'LHS' is the left-hand
+     side of the assignment.  'RHS' is the right-hand side of the
+     assignment.
+
+ -- GIMPLE function: void gimple_omp_atomic_load_set_lhs (gimple g, tree
+          lhs)
+     Set the 'LHS' of an atomic load.
+
+ -- GIMPLE function: tree gimple_omp_atomic_load_lhs (gimple g)
+     Get the 'LHS' of an atomic load.
+
+ -- GIMPLE function: void gimple_omp_atomic_load_set_rhs (gimple g, tree
+          rhs)
+     Set the 'RHS' of an atomic set.
+
+ -- GIMPLE function: tree gimple_omp_atomic_load_rhs (gimple g)
+     Get the 'RHS' of an atomic set.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_ATOMIC_STORE',  Next: 'GIMPLE_OMP_CONTINUE',  Prev: 'GIMPLE_OMP_ATOMIC_LOAD',  Up: Tuple specific accessors
+
+11.7.12 'GIMPLE_OMP_ATOMIC_STORE'
+---------------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_atomic_store (tree val)
+     Build a 'GIMPLE_OMP_ATOMIC_STORE' statement.  'VAL' is the value to
+     be stored.
+
+ -- GIMPLE function: void gimple_omp_atomic_store_set_val (gimple g,
+          tree val)
+     Set the value being stored in an atomic store.
+
+ -- GIMPLE function: tree gimple_omp_atomic_store_val (gimple g)
+     Return the value being stored in an atomic store.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_CONTINUE',  Next: 'GIMPLE_OMP_CRITICAL',  Prev: 'GIMPLE_OMP_ATOMIC_STORE',  Up: Tuple specific accessors
+
+11.7.13 'GIMPLE_OMP_CONTINUE'
+-----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_continue (tree control_def,
+          tree control_use)
+     Build a 'GIMPLE_OMP_CONTINUE' statement.  'CONTROL_DEF' is the
+     definition of the control variable.  'CONTROL_USE' is the use of
+     the control variable.
+
+ -- GIMPLE function: tree gimple_omp_continue_control_def (gimple s)
+     Return the definition of the control variable on a
+     'GIMPLE_OMP_CONTINUE' in 'S'.
+
+ -- GIMPLE function: tree gimple_omp_continue_control_def_ptr (gimple s)
+     Same as above, but return the pointer.
+
+ -- GIMPLE function: tree gimple_omp_continue_set_control_def (gimple s)
+     Set the control variable definition for a 'GIMPLE_OMP_CONTINUE'
+     statement in 'S'.
+
+ -- GIMPLE function: tree gimple_omp_continue_control_use (gimple s)
+     Return the use of the control variable on a 'GIMPLE_OMP_CONTINUE'
+     in 'S'.
+
+ -- GIMPLE function: tree gimple_omp_continue_control_use_ptr (gimple s)
+     Same as above, but return the pointer.
+
+ -- GIMPLE function: tree gimple_omp_continue_set_control_use (gimple s)
+     Set the control variable use for a 'GIMPLE_OMP_CONTINUE' statement
+     in 'S'.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_CRITICAL',  Next: 'GIMPLE_OMP_FOR',  Prev: 'GIMPLE_OMP_CONTINUE',  Up: Tuple specific accessors
+
+11.7.14 'GIMPLE_OMP_CRITICAL'
+-----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_critical (gimple_seq body,
+          tree name)
+     Build a 'GIMPLE_OMP_CRITICAL' statement.  'BODY' is the sequence of
+     statements for which only one thread can execute.  'NAME' is an
+     optional identifier for this critical block.
+
+ -- GIMPLE function: tree gimple_omp_critical_name (gimple g)
+     Return the name associated with 'OMP_CRITICAL' statement 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_critical_name_ptr (gimple g)
+     Return a pointer to the name associated with 'OMP' critical
+     statement 'G'.
+
+ -- GIMPLE function: void gimple_omp_critical_set_name (gimple g, tree
+          name)
+     Set 'NAME' to be the name associated with 'OMP' critical statement
+     'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_FOR',  Next: 'GIMPLE_OMP_MASTER',  Prev: 'GIMPLE_OMP_CRITICAL',  Up: Tuple specific accessors
+
+11.7.15 'GIMPLE_OMP_FOR'
+------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_for (gimple_seq body, tree
+          clauses, tree index, tree initial, tree final, tree incr,
+          gimple_seq pre_body, enum tree_code omp_for_cond)
+     Build a 'GIMPLE_OMP_FOR' statement.  'BODY' is sequence of
+     statements inside the for loop.  'CLAUSES', are any of the 'OMP'
+     loop construct's clauses: private, firstprivate, lastprivate,
+     reductions, ordered, schedule, and nowait.  'PRE_BODY' is the
+     sequence of statements that are loop invariant.  'INDEX' is the
+     index variable.  'INITIAL' is the initial value of 'INDEX'.
+     'FINAL' is final value of 'INDEX'.  OMP_FOR_COND is the predicate
+     used to compare 'INDEX' and 'FINAL'.  'INCR' is the increment
+     expression.
+
+ -- GIMPLE function: tree gimple_omp_for_clauses (gimple g)
+     Return the clauses associated with 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_for_clauses_ptr (gimple g)
+     Return a pointer to the 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_clauses (gimple g, tree
+          clauses)
+     Set 'CLAUSES' to be the list of clauses associated with 'OMP_FOR'
+     'G'.
+
+ -- GIMPLE function: tree gimple_omp_for_index (gimple g)
+     Return the index variable for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_for_index_ptr (gimple g)
+     Return a pointer to the index variable for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_index (gimple g, tree
+          index)
+     Set 'INDEX' to be the index variable for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: tree gimple_omp_for_initial (gimple g)
+     Return the initial value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_for_initial_ptr (gimple g)
+     Return a pointer to the initial value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_initial (gimple g, tree
+          initial)
+     Set 'INITIAL' to be the initial value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: tree gimple_omp_for_final (gimple g)
+     Return the final value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_for_final_ptr (gimple g)
+     turn a pointer to the final value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_final (gimple g, tree
+          final)
+     Set 'FINAL' to be the final value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: tree gimple_omp_for_incr (gimple g)
+     Return the increment value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_for_incr_ptr (gimple g)
+     Return a pointer to the increment value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: void gimple_omp_for_set_incr (gimple g, tree incr)
+     Set 'INCR' to be the increment value for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: gimple_seq gimple_omp_for_pre_body (gimple g)
+     Return the sequence of statements to execute before the 'OMP_FOR'
+     statement 'G' starts.
+
+ -- GIMPLE function: void gimple_omp_for_set_pre_body (gimple g,
+          gimple_seq pre_body)
+     Set 'PRE_BODY' to be the sequence of statements to execute before
+     the 'OMP_FOR' statement 'G' starts.
+
+ -- GIMPLE function: void gimple_omp_for_set_cond (gimple g, enum
+          tree_code cond)
+     Set 'COND' to be the condition code for 'OMP_FOR' 'G'.
+
+ -- GIMPLE function: enum tree_code gimple_omp_for_cond (gimple g)
+     Return the condition code associated with 'OMP_FOR' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_MASTER',  Next: 'GIMPLE_OMP_ORDERED',  Prev: 'GIMPLE_OMP_FOR',  Up: Tuple specific accessors
+
+11.7.16 'GIMPLE_OMP_MASTER'
+---------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_master (gimple_seq body)
+     Build a 'GIMPLE_OMP_MASTER' statement.  'BODY' is the sequence of
+     statements to be executed by just the master.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_ORDERED',  Next: 'GIMPLE_OMP_PARALLEL',  Prev: 'GIMPLE_OMP_MASTER',  Up: Tuple specific accessors
+
+11.7.17 'GIMPLE_OMP_ORDERED'
+----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_ordered (gimple_seq body)
+     Build a 'GIMPLE_OMP_ORDERED' statement.
+
+ 'BODY' is the sequence of statements inside a loop that will executed
+in sequence.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_PARALLEL',  Next: 'GIMPLE_OMP_RETURN',  Prev: 'GIMPLE_OMP_ORDERED',  Up: Tuple specific accessors
+
+11.7.18 'GIMPLE_OMP_PARALLEL'
+-----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_parallel (gimple_seq body,
+          tree clauses, tree child_fn, tree data_arg)
+     Build a 'GIMPLE_OMP_PARALLEL' statement.
+
+ 'BODY' is sequence of statements which are executed in parallel.
+'CLAUSES', are the 'OMP' parallel construct's clauses.  'CHILD_FN' is
+the function created for the parallel threads to execute.  'DATA_ARG'
+are the shared data argument(s).
+
+ -- GIMPLE function: bool gimple_omp_parallel_combined_p (gimple g)
+     Return true if 'OMP' parallel statement 'G' has the
+     'GF_OMP_PARALLEL_COMBINED' flag set.
+
+ -- GIMPLE function: void gimple_omp_parallel_set_combined_p (gimple g)
+     Set the 'GF_OMP_PARALLEL_COMBINED' field in 'OMP' parallel
+     statement 'G'.
+
+ -- GIMPLE function: gimple_seq gimple_omp_body (gimple g)
+     Return the body for the 'OMP' statement 'G'.
+
+ -- GIMPLE function: void gimple_omp_set_body (gimple g, gimple_seq
+          body)
+     Set 'BODY' to be the body for the 'OMP' statement 'G'.
+
+ -- GIMPLE function: tree gimple_omp_parallel_clauses (gimple g)
+     Return the clauses associated with 'OMP_PARALLEL' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_parallel_clauses_ptr (gimple g)
+     Return a pointer to the clauses associated with 'OMP_PARALLEL' 'G'.
+
+ -- GIMPLE function: void gimple_omp_parallel_set_clauses (gimple g,
+          tree clauses)
+     Set 'CLAUSES' to be the list of clauses associated with
+     'OMP_PARALLEL' 'G'.
+
+ -- GIMPLE function: tree gimple_omp_parallel_child_fn (gimple g)
+     Return the child function used to hold the body of 'OMP_PARALLEL'
+     'G'.
+
+ -- GIMPLE function: tree * gimple_omp_parallel_child_fn_ptr (gimple g)
+     Return a pointer to the child function used to hold the body of
+     'OMP_PARALLEL' 'G'.
+
+ -- GIMPLE function: void gimple_omp_parallel_set_child_fn (gimple g,
+          tree child_fn)
+     Set 'CHILD_FN' to be the child function for 'OMP_PARALLEL' 'G'.
+
+ -- GIMPLE function: tree gimple_omp_parallel_data_arg (gimple g)
+     Return the artificial argument used to send variables and values
+     from the parent to the children threads in 'OMP_PARALLEL' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_parallel_data_arg_ptr (gimple g)
+     Return a pointer to the data argument for 'OMP_PARALLEL' 'G'.
+
+ -- GIMPLE function: void gimple_omp_parallel_set_data_arg (gimple g,
+          tree data_arg)
+     Set 'DATA_ARG' to be the data argument for 'OMP_PARALLEL' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_RETURN',  Next: 'GIMPLE_OMP_SECTION',  Prev: 'GIMPLE_OMP_PARALLEL',  Up: Tuple specific accessors
+
+11.7.19 'GIMPLE_OMP_RETURN'
+---------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_return (bool wait_p)
+     Build a 'GIMPLE_OMP_RETURN' statement.  'WAIT_P' is true if this is
+     a non-waiting return.
+
+ -- GIMPLE function: void gimple_omp_return_set_nowait (gimple s)
+     Set the nowait flag on 'GIMPLE_OMP_RETURN' statement 'S'.
+
+ -- GIMPLE function: bool gimple_omp_return_nowait_p (gimple g)
+     Return true if 'OMP' return statement 'G' has the
+     'GF_OMP_RETURN_NOWAIT' flag set.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_SECTION',  Next: 'GIMPLE_OMP_SECTIONS',  Prev: 'GIMPLE_OMP_RETURN',  Up: Tuple specific accessors
+
+11.7.20 'GIMPLE_OMP_SECTION'
+----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_section (gimple_seq body)
+     Build a 'GIMPLE_OMP_SECTION' statement for a sections statement.
+
+ 'BODY' is the sequence of statements in the section.
+
+ -- GIMPLE function: bool gimple_omp_section_last_p (gimple g)
+     Return true if 'OMP' section statement 'G' has the
+     'GF_OMP_SECTION_LAST' flag set.
+
+ -- GIMPLE function: void gimple_omp_section_set_last (gimple g)
+     Set the 'GF_OMP_SECTION_LAST' flag on 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_SECTIONS',  Next: 'GIMPLE_OMP_SINGLE',  Prev: 'GIMPLE_OMP_SECTION',  Up: Tuple specific accessors
+
+11.7.21 'GIMPLE_OMP_SECTIONS'
+-----------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_sections (gimple_seq body,
+          tree clauses)
+     Build a 'GIMPLE_OMP_SECTIONS' statement.  'BODY' is a sequence of
+     section statements.  'CLAUSES' are any of the 'OMP' sections
+     construct's clauses: private, firstprivate, lastprivate, reduction,
+     and nowait.
+
+ -- GIMPLE function: gimple gimple_build_omp_sections_switch (void)
+     Build a 'GIMPLE_OMP_SECTIONS_SWITCH' statement.
+
+ -- GIMPLE function: tree gimple_omp_sections_control (gimple g)
+     Return the control variable associated with the
+     'GIMPLE_OMP_SECTIONS' in 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_sections_control_ptr (gimple g)
+     Return a pointer to the clauses associated with the
+     'GIMPLE_OMP_SECTIONS' in 'G'.
+
+ -- GIMPLE function: void gimple_omp_sections_set_control (gimple g,
+          tree control)
+     Set 'CONTROL' to be the set of clauses associated with the
+     'GIMPLE_OMP_SECTIONS' in 'G'.
+
+ -- GIMPLE function: tree gimple_omp_sections_clauses (gimple g)
+     Return the clauses associated with 'OMP_SECTIONS' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_sections_clauses_ptr (gimple g)
+     Return a pointer to the clauses associated with 'OMP_SECTIONS' 'G'.
+
+ -- GIMPLE function: void gimple_omp_sections_set_clauses (gimple g,
+          tree clauses)
+     Set 'CLAUSES' to be the set of clauses associated with
+     'OMP_SECTIONS' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_OMP_SINGLE',  Next: 'GIMPLE_PHI',  Prev: 'GIMPLE_OMP_SECTIONS',  Up: Tuple specific accessors
+
+11.7.22 'GIMPLE_OMP_SINGLE'
+---------------------------
+
+ -- GIMPLE function: gimple gimple_build_omp_single (gimple_seq body,
+          tree clauses)
+     Build a 'GIMPLE_OMP_SINGLE' statement.  'BODY' is the sequence of
+     statements that will be executed once.  'CLAUSES' are any of the
+     'OMP' single construct's clauses: private, firstprivate,
+     copyprivate, nowait.
+
+ -- GIMPLE function: tree gimple_omp_single_clauses (gimple g)
+     Return the clauses associated with 'OMP_SINGLE' 'G'.
+
+ -- GIMPLE function: tree * gimple_omp_single_clauses_ptr (gimple g)
+     Return a pointer to the clauses associated with 'OMP_SINGLE' 'G'.
+
+ -- GIMPLE function: void gimple_omp_single_set_clauses (gimple g, tree
+          clauses)
+     Set 'CLAUSES' to be the clauses associated with 'OMP_SINGLE' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_PHI',  Next: 'GIMPLE_RESX',  Prev: 'GIMPLE_OMP_SINGLE',  Up: Tuple specific accessors
+
+11.7.23 'GIMPLE_PHI'
+--------------------
+
+ -- GIMPLE function: unsigned gimple_phi_capacity (gimple g)
+     Return the maximum number of arguments supported by 'GIMPLE_PHI'
+     'G'.
+
+ -- GIMPLE function: unsigned gimple_phi_num_args (gimple g)
+     Return the number of arguments in 'GIMPLE_PHI' 'G'.  This must
+     always be exactly the number of incoming edges for the basic block
+     holding 'G'.
+
+ -- GIMPLE function: tree gimple_phi_result (gimple g)
+     Return the 'SSA' name created by 'GIMPLE_PHI' 'G'.
+
+ -- GIMPLE function: tree * gimple_phi_result_ptr (gimple g)
+     Return a pointer to the 'SSA' name created by 'GIMPLE_PHI' 'G'.
+
+ -- GIMPLE function: void gimple_phi_set_result (gimple g, tree result)
+     Set 'RESULT' to be the 'SSA' name created by 'GIMPLE_PHI' 'G'.
+
+ -- GIMPLE function: struct phi_arg_d * gimple_phi_arg (gimple g, index)
+     Return the 'PHI' argument corresponding to incoming edge 'INDEX'
+     for 'GIMPLE_PHI' 'G'.
+
+ -- GIMPLE function: void gimple_phi_set_arg (gimple g, index, struct
+          phi_arg_d * phiarg)
+     Set 'PHIARG' to be the argument corresponding to incoming edge
+     'INDEX' for 'GIMPLE_PHI' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_RESX',  Next: 'GIMPLE_RETURN',  Prev: 'GIMPLE_PHI',  Up: Tuple specific accessors
+
+11.7.24 'GIMPLE_RESX'
+---------------------
+
+ -- GIMPLE function: gimple gimple_build_resx (int region)
+     Build a 'GIMPLE_RESX' statement which is a statement.  This
+     statement is a placeholder for _Unwind_Resume before we know if a
+     function call or a branch is needed.  'REGION' is the exception
+     region from which control is flowing.
+
+ -- GIMPLE function: int gimple_resx_region (gimple g)
+     Return the region number for 'GIMPLE_RESX' 'G'.
+
+ -- GIMPLE function: void gimple_resx_set_region (gimple g, int region)
+     Set 'REGION' to be the region number for 'GIMPLE_RESX' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_RETURN',  Next: 'GIMPLE_SWITCH',  Prev: 'GIMPLE_RESX',  Up: Tuple specific accessors
+
+11.7.25 'GIMPLE_RETURN'
+-----------------------
+
+ -- GIMPLE function: gimple gimple_build_return (tree retval)
+     Build a 'GIMPLE_RETURN' statement whose return value is retval.
+
+ -- GIMPLE function: tree gimple_return_retval (gimple g)
+     Return the return value for 'GIMPLE_RETURN' 'G'.
+
+ -- GIMPLE function: void gimple_return_set_retval (gimple g, tree
+          retval)
+     Set 'RETVAL' to be the return value for 'GIMPLE_RETURN' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_SWITCH',  Next: 'GIMPLE_TRY',  Prev: 'GIMPLE_RETURN',  Up: Tuple specific accessors
+
+11.7.26 'GIMPLE_SWITCH'
+-----------------------
+
+ -- GIMPLE function: gimple gimple_build_switch (tree index, tree
+          default_label, 'VEC'(tree,heap) *args)
+     Build a 'GIMPLE_SWITCH' statement.  'INDEX' is the index variable
+     to switch on, and 'DEFAULT_LABEL' represents the default label.
+     'ARGS' is a vector of 'CASE_LABEL_EXPR' trees that contain the
+     non-default case labels.  Each label is a tree of code
+     'CASE_LABEL_EXPR'.
+
+ -- GIMPLE function: unsigned gimple_switch_num_labels (gimple g)
+     Return the number of labels associated with the switch statement
+     'G'.
+
+ -- GIMPLE function: void gimple_switch_set_num_labels (gimple g,
+          unsigned nlabels)
+     Set 'NLABELS' to be the number of labels for the switch statement
+     'G'.
+
+ -- GIMPLE function: tree gimple_switch_index (gimple g)
+     Return the index variable used by the switch statement 'G'.
+
+ -- GIMPLE function: void gimple_switch_set_index (gimple g, tree index)
+     Set 'INDEX' to be the index variable for switch statement 'G'.
+
+ -- GIMPLE function: tree gimple_switch_label (gimple g, unsigned index)
+     Return the label numbered 'INDEX'.  The default label is 0,
+     followed by any labels in a switch statement.
+
+ -- GIMPLE function: void gimple_switch_set_label (gimple g, unsigned
+          index, tree label)
+     Set the label number 'INDEX' to 'LABEL'.  0 is always the default
+     label.
+
+ -- GIMPLE function: tree gimple_switch_default_label (gimple g)
+     Return the default label for a switch statement.
+
+ -- GIMPLE function: void gimple_switch_set_default_label (gimple g,
+          tree label)
+     Set the default label for a switch statement.
+
+
+File: gccint.info,  Node: 'GIMPLE_TRY',  Next: 'GIMPLE_WITH_CLEANUP_EXPR',  Prev: 'GIMPLE_SWITCH',  Up: Tuple specific accessors
+
+11.7.27 'GIMPLE_TRY'
+--------------------
+
+ -- GIMPLE function: gimple gimple_build_try (gimple_seq eval,
+          gimple_seq cleanup, unsigned int kind)
+     Build a 'GIMPLE_TRY' statement.  'EVAL' is a sequence with the
+     expression to evaluate.  'CLEANUP' is a sequence of statements to
+     run at clean-up time.  'KIND' is the enumeration value
+     'GIMPLE_TRY_CATCH' if this statement denotes a try/catch construct
+     or 'GIMPLE_TRY_FINALLY' if this statement denotes a try/finally
+     construct.
+
+ -- GIMPLE function: enum gimple_try_flags gimple_try_kind (gimple g)
+     Return the kind of try block represented by 'GIMPLE_TRY' 'G'.  This
+     is either 'GIMPLE_TRY_CATCH' or 'GIMPLE_TRY_FINALLY'.
+
+ -- GIMPLE function: bool gimple_try_catch_is_cleanup (gimple g)
+     Return the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag.
+
+ -- GIMPLE function: gimple_seq gimple_try_eval (gimple g)
+     Return the sequence of statements used as the body for 'GIMPLE_TRY'
+     'G'.
+
+ -- GIMPLE function: gimple_seq gimple_try_cleanup (gimple g)
+     Return the sequence of statements used as the cleanup body for
+     'GIMPLE_TRY' 'G'.
+
+ -- GIMPLE function: void gimple_try_set_catch_is_cleanup (gimple g,
+          bool catch_is_cleanup)
+     Set the 'GIMPLE_TRY_CATCH_IS_CLEANUP' flag.
+
+ -- GIMPLE function: void gimple_try_set_eval (gimple g, gimple_seq
+          eval)
+     Set 'EVAL' to be the sequence of statements to use as the body for
+     'GIMPLE_TRY' 'G'.
+
+ -- GIMPLE function: void gimple_try_set_cleanup (gimple g, gimple_seq
+          cleanup)
+     Set 'CLEANUP' to be the sequence of statements to use as the
+     cleanup body for 'GIMPLE_TRY' 'G'.
+
+
+File: gccint.info,  Node: 'GIMPLE_WITH_CLEANUP_EXPR',  Prev: 'GIMPLE_TRY',  Up: Tuple specific accessors
+
+11.7.28 'GIMPLE_WITH_CLEANUP_EXPR'
+----------------------------------
+
+ -- GIMPLE function: gimple gimple_build_wce (gimple_seq cleanup)
+     Build a 'GIMPLE_WITH_CLEANUP_EXPR' statement.  'CLEANUP' is the
+     clean-up expression.
+
+ -- GIMPLE function: gimple_seq gimple_wce_cleanup (gimple g)
+     Return the cleanup sequence for cleanup statement 'G'.
+
+ -- GIMPLE function: void gimple_wce_set_cleanup (gimple g, gimple_seq
+          cleanup)
+     Set 'CLEANUP' to be the cleanup sequence for 'G'.
+
+ -- GIMPLE function: bool gimple_wce_cleanup_eh_only (gimple g)
+     Return the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple.
+
+ -- GIMPLE function: void gimple_wce_set_cleanup_eh_only (gimple g, bool
+          eh_only_p)
+     Set the 'CLEANUP_EH_ONLY' flag for a 'WCE' tuple.
+
+
+File: gccint.info,  Node: GIMPLE sequences,  Next: Sequence iterators,  Prev: Tuple specific accessors,  Up: GIMPLE
+
+11.8 GIMPLE sequences
+=====================
+
+GIMPLE sequences are the tuple equivalent of 'STATEMENT_LIST''s used in
+'GENERIC'.  They are used to chain statements together, and when used in
+conjunction with sequence iterators, provide a framework for iterating
+through statements.
+
+ GIMPLE sequences are of type struct 'gimple_sequence', but are more
+commonly passed by reference to functions dealing with sequences.  The
+type for a sequence pointer is 'gimple_seq' which is the same as struct
+'gimple_sequence' *.  When declaring a local sequence, you can define a
+local variable of type struct 'gimple_sequence'.  When declaring a
+sequence allocated on the garbage collected heap, use the function
+'gimple_seq_alloc' documented below.
+
+ There are convenience functions for iterating through sequences in the
+section entitled Sequence Iterators.
+
+ Below is a list of functions to manipulate and query sequences.
+
+ -- GIMPLE function: void gimple_seq_add_stmt (gimple_seq *seq, gimple
+          g)
+     Link a gimple statement to the end of the sequence *'SEQ' if 'G' is
+     not 'NULL'.  If *'SEQ' is 'NULL', allocate a sequence before
+     linking.
+
+ -- GIMPLE function: void gimple_seq_add_seq (gimple_seq *dest,
+          gimple_seq src)
+     Append sequence 'SRC' to the end of sequence *'DEST' if 'SRC' is
+     not 'NULL'.  If *'DEST' is 'NULL', allocate a new sequence before
+     appending.
+
+ -- GIMPLE function: gimple_seq gimple_seq_deep_copy (gimple_seq src)
+     Perform a deep copy of sequence 'SRC' and return the result.
+
+ -- GIMPLE function: gimple_seq gimple_seq_reverse (gimple_seq seq)
+     Reverse the order of the statements in the sequence 'SEQ'.  Return
+     'SEQ'.
+
+ -- GIMPLE function: gimple gimple_seq_first (gimple_seq s)
+     Return the first statement in sequence 'S'.
+
+ -- GIMPLE function: gimple gimple_seq_last (gimple_seq s)
+     Return the last statement in sequence 'S'.
+
+ -- GIMPLE function: void gimple_seq_set_last (gimple_seq s, gimple
+          last)
+     Set the last statement in sequence 'S' to the statement in 'LAST'.
+
+ -- GIMPLE function: void gimple_seq_set_first (gimple_seq s, gimple
+          first)
+     Set the first statement in sequence 'S' to the statement in
+     'FIRST'.
+
+ -- GIMPLE function: void gimple_seq_init (gimple_seq s)
+     Initialize sequence 'S' to an empty sequence.
+
+ -- GIMPLE function: gimple_seq gimple_seq_alloc (void)
+     Allocate a new sequence in the garbage collected store and return
+     it.
+
+ -- GIMPLE function: void gimple_seq_copy (gimple_seq dest, gimple_seq
+          src)
+     Copy the sequence 'SRC' into the sequence 'DEST'.
+
+ -- GIMPLE function: bool gimple_seq_empty_p (gimple_seq s)
+     Return true if the sequence 'S' is empty.
+
+ -- GIMPLE function: gimple_seq bb_seq (basic_block bb)
+     Returns the sequence of statements in 'BB'.
+
+ -- GIMPLE function: void set_bb_seq (basic_block bb, gimple_seq seq)
+     Sets the sequence of statements in 'BB' to 'SEQ'.
+
+ -- GIMPLE function: bool gimple_seq_singleton_p (gimple_seq seq)
+     Determine whether 'SEQ' contains exactly one statement.
+
+
+File: gccint.info,  Node: Sequence iterators,  Next: Adding a new GIMPLE statement code,  Prev: GIMPLE sequences,  Up: GIMPLE
+
+11.9 Sequence iterators
+=======================
+
+Sequence iterators are convenience constructs for iterating through
+statements in a sequence.  Given a sequence 'SEQ', here is a typical use
+of gimple sequence iterators:
+
+     gimple_stmt_iterator gsi;
+
+     for (gsi = gsi_start (seq); !gsi_end_p (gsi); gsi_next (&gsi))
+       {
+         gimple g = gsi_stmt (gsi);
+         /* Do something with gimple statement G.  */
+       }
+
+ Backward iterations are possible:
+
+             for (gsi = gsi_last (seq); !gsi_end_p (gsi); gsi_prev (&gsi))
+
+ Forward and backward iterations on basic blocks are possible with
+'gsi_start_bb' and 'gsi_last_bb'.
+
+ In the documentation below we sometimes refer to enum
+'gsi_iterator_update'.  The valid options for this enumeration are:
+
+   * 'GSI_NEW_STMT' Only valid when a single statement is added.  Move
+     the iterator to it.
+
+   * 'GSI_SAME_STMT' Leave the iterator at the same statement.
+
+   * 'GSI_CONTINUE_LINKING' Move iterator to whatever position is
+     suitable for linking other statements in the same direction.
+
+ Below is a list of the functions used to manipulate and use statement
+iterators.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_start (gimple_seq seq)
+     Return a new iterator pointing to the sequence 'SEQ''s first
+     statement.  If 'SEQ' is empty, the iterator's basic block is
+     'NULL'.  Use 'gsi_start_bb' instead when the iterator needs to
+     always have the correct basic block set.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_start_bb (basic_block bb)
+     Return a new iterator pointing to the first statement in basic
+     block 'BB'.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_last (gimple_seq seq)
+     Return a new iterator initially pointing to the last statement of
+     sequence 'SEQ'.  If 'SEQ' is empty, the iterator's basic block is
+     'NULL'.  Use 'gsi_last_bb' instead when the iterator needs to
+     always have the correct basic block set.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_last_bb (basic_block bb)
+     Return a new iterator pointing to the last statement in basic block
+     'BB'.
+
+ -- GIMPLE function: bool gsi_end_p (gimple_stmt_iterator i)
+     Return 'TRUE' if at the end of 'I'.
+
+ -- GIMPLE function: bool gsi_one_before_end_p (gimple_stmt_iterator i)
+     Return 'TRUE' if we're one statement before the end of 'I'.
+
+ -- GIMPLE function: void gsi_next (gimple_stmt_iterator *i)
+     Advance the iterator to the next gimple statement.
+
+ -- GIMPLE function: void gsi_prev (gimple_stmt_iterator *i)
+     Advance the iterator to the previous gimple statement.
+
+ -- GIMPLE function: gimple gsi_stmt (gimple_stmt_iterator i)
+     Return the current stmt.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_after_labels (basic_block
+          bb)
+     Return a block statement iterator that points to the first
+     non-label statement in block 'BB'.
+
+ -- GIMPLE function: gimple * gsi_stmt_ptr (gimple_stmt_iterator *i)
+     Return a pointer to the current stmt.
+
+ -- GIMPLE function: basic_block gsi_bb (gimple_stmt_iterator i)
+     Return the basic block associated with this iterator.
+
+ -- GIMPLE function: gimple_seq gsi_seq (gimple_stmt_iterator i)
+     Return the sequence associated with this iterator.
+
+ -- GIMPLE function: void gsi_remove (gimple_stmt_iterator *i, bool
+          remove_eh_info)
+     Remove the current stmt from the sequence.  The iterator is updated
+     to point to the next statement.  When 'REMOVE_EH_INFO' is true we
+     remove the statement pointed to by iterator 'I' from the 'EH'
+     tables.  Otherwise we do not modify the 'EH' tables.  Generally,
+     'REMOVE_EH_INFO' should be true when the statement is going to be
+     removed from the 'IL' and not reinserted elsewhere.
+
+ -- GIMPLE function: void gsi_link_seq_before (gimple_stmt_iterator *i,
+          gimple_seq seq, enum gsi_iterator_update mode)
+     Links the sequence of statements 'SEQ' before the statement pointed
+     by iterator 'I'.  'MODE' indicates what to do with the iterator
+     after insertion (see 'enum gsi_iterator_update' above).
+
+ -- GIMPLE function: void gsi_link_before (gimple_stmt_iterator *i,
+          gimple g, enum gsi_iterator_update mode)
+     Links statement 'G' before the statement pointed-to by iterator
+     'I'.  Updates iterator 'I' according to 'MODE'.
+
+ -- GIMPLE function: void gsi_link_seq_after (gimple_stmt_iterator *i,
+          gimple_seq seq, enum gsi_iterator_update mode)
+     Links sequence 'SEQ' after the statement pointed-to by iterator
+     'I'.  'MODE' is as in 'gsi_insert_after'.
+
+ -- GIMPLE function: void gsi_link_after (gimple_stmt_iterator *i,
+          gimple g, enum gsi_iterator_update mode)
+     Links statement 'G' after the statement pointed-to by iterator 'I'.
+     'MODE' is as in 'gsi_insert_after'.
+
+ -- GIMPLE function: gimple_seq gsi_split_seq_after
+          (gimple_stmt_iterator i)
+     Move all statements in the sequence after 'I' to a new sequence.
+     Return this new sequence.
+
+ -- GIMPLE function: gimple_seq gsi_split_seq_before
+          (gimple_stmt_iterator *i)
+     Move all statements in the sequence before 'I' to a new sequence.
+     Return this new sequence.
+
+ -- GIMPLE function: void gsi_replace (gimple_stmt_iterator *i, gimple
+          stmt, bool update_eh_info)
+     Replace the statement pointed-to by 'I' to 'STMT'.  If
+     'UPDATE_EH_INFO' is true, the exception handling information of the
+     original statement is moved to the new statement.
+
+ -- GIMPLE function: void gsi_insert_before (gimple_stmt_iterator *i,
+          gimple stmt, enum gsi_iterator_update mode)
+     Insert statement 'STMT' before the statement pointed-to by iterator
+     'I', update 'STMT''s basic block and scan it for new operands.
+     'MODE' specifies how to update iterator 'I' after insertion (see
+     enum 'gsi_iterator_update').
+
+ -- GIMPLE function: void gsi_insert_seq_before (gimple_stmt_iterator
+          *i, gimple_seq seq, enum gsi_iterator_update mode)
+     Like 'gsi_insert_before', but for all the statements in 'SEQ'.
+
+ -- GIMPLE function: void gsi_insert_after (gimple_stmt_iterator *i,
+          gimple stmt, enum gsi_iterator_update mode)
+     Insert statement 'STMT' after the statement pointed-to by iterator
+     'I', update 'STMT''s basic block and scan it for new operands.
+     'MODE' specifies how to update iterator 'I' after insertion (see
+     enum 'gsi_iterator_update').
+
+ -- GIMPLE function: void gsi_insert_seq_after (gimple_stmt_iterator *i,
+          gimple_seq seq, enum gsi_iterator_update mode)
+     Like 'gsi_insert_after', but for all the statements in 'SEQ'.
+
+ -- GIMPLE function: gimple_stmt_iterator gsi_for_stmt (gimple stmt)
+     Finds iterator for 'STMT'.
+
+ -- GIMPLE function: void gsi_move_after (gimple_stmt_iterator *from,
+          gimple_stmt_iterator *to)
+     Move the statement at 'FROM' so it comes right after the statement
+     at 'TO'.
+
+ -- GIMPLE function: void gsi_move_before (gimple_stmt_iterator *from,
+          gimple_stmt_iterator *to)
+     Move the statement at 'FROM' so it comes right before the statement
+     at 'TO'.
+
+ -- GIMPLE function: void gsi_move_to_bb_end (gimple_stmt_iterator
+          *from, basic_block bb)
+     Move the statement at 'FROM' to the end of basic block 'BB'.
+
+ -- GIMPLE function: void gsi_insert_on_edge (edge e, gimple stmt)
+     Add 'STMT' to the pending list of edge 'E'.  No actual insertion is
+     made until a call to 'gsi_commit_edge_inserts'() is made.
+
+ -- GIMPLE function: void gsi_insert_seq_on_edge (edge e, gimple_seq
+          seq)
+     Add the sequence of statements in 'SEQ' to the pending list of edge
+     'E'.  No actual insertion is made until a call to
+     'gsi_commit_edge_inserts'() is made.
+
+ -- GIMPLE function: basic_block gsi_insert_on_edge_immediate (edge e,
+          gimple stmt)
+     Similar to 'gsi_insert_on_edge'+'gsi_commit_edge_inserts'.  If a
+     new block has to be created, it is returned.
+
+ -- GIMPLE function: void gsi_commit_one_edge_insert (edge e,
+          basic_block *new_bb)
+     Commit insertions pending at edge 'E'.  If a new block is created,
+     set 'NEW_BB' to this block, otherwise set it to 'NULL'.
+
+ -- GIMPLE function: void gsi_commit_edge_inserts (void)
+     This routine will commit all pending edge insertions, creating any
+     new basic blocks which are necessary.
+
+
+File: gccint.info,  Node: Adding a new GIMPLE statement code,  Next: Statement and operand traversals,  Prev: Sequence iterators,  Up: GIMPLE
+
+11.10 Adding a new GIMPLE statement code
+========================================
+
+The first step in adding a new GIMPLE statement code, is modifying the
+file 'gimple.def', which contains all the GIMPLE codes.  Then you must
+add a corresponding structure, and an entry in 'union
+gimple_statement_d', both of which are located in 'gimple.h'.  This in
+turn, will require you to add a corresponding 'GTY' tag in
+'gsstruct.def', and code to handle this tag in 'gss_for_code' which is
+located in 'gimple.c'.
+
+ In order for the garbage collector to know the size of the structure
+you created in 'gimple.h', you need to add a case to handle your new
+GIMPLE statement in 'gimple_size' which is located in 'gimple.c'.
+
+ You will probably want to create a function to build the new gimple
+statement in 'gimple.c'.  The function should be called
+'gimple_build_NEW-TUPLE-NAME', and should return the new tuple of type
+gimple.
+
+ If your new statement requires accessors for any members or operands it
+may have, put simple inline accessors in 'gimple.h' and any non-trivial
+accessors in 'gimple.c' with a corresponding prototype in 'gimple.h'.
+
+
+File: gccint.info,  Node: Statement and operand traversals,  Prev: Adding a new GIMPLE statement code,  Up: GIMPLE
+
+11.11 Statement and operand traversals
+======================================
+
+There are two functions available for walking statements and sequences:
+'walk_gimple_stmt' and 'walk_gimple_seq', accordingly, and a third
+function for walking the operands in a statement: 'walk_gimple_op'.
+
+ -- GIMPLE function: tree walk_gimple_stmt (gimple_stmt_iterator *gsi,
+          walk_stmt_fn callback_stmt, walk_tree_fn callback_op, struct
+          walk_stmt_info *wi)
+     This function is used to walk the current statement in 'GSI',
+     optionally using traversal state stored in 'WI'.  If 'WI' is
+     'NULL', no state is kept during the traversal.
+
+     The callback 'CALLBACK_STMT' is called.  If 'CALLBACK_STMT' returns
+     true, it means that the callback function has handled all the
+     operands of the statement and it is not necessary to walk its
+     operands.
+
+     If 'CALLBACK_STMT' is 'NULL' or it returns false, 'CALLBACK_OP' is
+     called on each operand of the statement via 'walk_gimple_op'.  If
+     'walk_gimple_op' returns non-'NULL' for any operand, the remaining
+     operands are not scanned.
+
+     The return value is that returned by the last call to
+     'walk_gimple_op', or 'NULL_TREE' if no 'CALLBACK_OP' is specified.
+
+ -- GIMPLE function: tree walk_gimple_op (gimple stmt, walk_tree_fn
+          callback_op, struct walk_stmt_info *wi)
+     Use this function to walk the operands of statement 'STMT'.  Every
+     operand is walked via 'walk_tree' with optional state information
+     in 'WI'.
+
+     'CALLBACK_OP' is called on each operand of 'STMT' via 'walk_tree'.
+     Additional parameters to 'walk_tree' must be stored in 'WI'.  For
+     each operand 'OP', 'walk_tree' is called as:
+
+          walk_tree (&OP, CALLBACK_OP, WI, PSET)
+
+     If 'CALLBACK_OP' returns non-'NULL' for an operand, the remaining
+     operands are not scanned.  The return value is that returned by the
+     last call to 'walk_tree', or 'NULL_TREE' if no 'CALLBACK_OP' is
+     specified.
+
+ -- GIMPLE function: tree walk_gimple_seq (gimple_seq seq, walk_stmt_fn
+          callback_stmt, walk_tree_fn callback_op, struct walk_stmt_info
+          *wi)
+     This function walks all the statements in the sequence 'SEQ'
+     calling 'walk_gimple_stmt' on each one.  'WI' is as in
+     'walk_gimple_stmt'.  If 'walk_gimple_stmt' returns non-'NULL', the
+     walk is stopped and the value returned.  Otherwise, all the
+     statements are walked and 'NULL_TREE' returned.
+
+
+File: gccint.info,  Node: Tree SSA,  Next: RTL,  Prev: GIMPLE,  Up: Top
+
+12 Analysis and Optimization of GIMPLE tuples
+*********************************************
+
+GCC uses three main intermediate languages to represent the program
+during compilation: GENERIC, GIMPLE and RTL.  GENERIC is a
+language-independent representation generated by each front end.  It is
+used to serve as an interface between the parser and optimizer.  GENERIC
+is a common representation that is able to represent programs written in
+all the languages supported by GCC.
+
+ GIMPLE and RTL are used to optimize the program.  GIMPLE is used for
+target and language independent optimizations (e.g., inlining, constant
+propagation, tail call elimination, redundancy elimination, etc).  Much
+like GENERIC, GIMPLE is a language independent, tree based
+representation.  However, it differs from GENERIC in that the GIMPLE
+grammar is more restrictive: expressions contain no more than 3 operands
+(except function calls), it has no control flow structures and
+expressions with side-effects are only allowed on the right hand side of
+assignments.  See the chapter describing GENERIC and GIMPLE for more
+details.
+
+ This chapter describes the data structures and functions used in the
+GIMPLE optimizers (also known as "tree optimizers" or "middle end").  In
+particular, it focuses on all the macros, data structures, functions and
+programming constructs needed to implement optimization passes for
+GIMPLE.
+
+* Menu:
+
+* Annotations::         Attributes for variables.
+* SSA Operands::        SSA names referenced by GIMPLE statements.
+* SSA::                 Static Single Assignment representation.
+* Alias analysis::      Representing aliased loads and stores.
+* Memory model::        Memory model used by the middle-end.
+
+
+File: gccint.info,  Node: Annotations,  Next: SSA Operands,  Up: Tree SSA
+
+12.1 Annotations
+================
+
+The optimizers need to associate attributes with variables during the
+optimization process.  For instance, we need to know whether a variable
+has aliases.  All these attributes are stored in data structures called
+annotations which are then linked to the field 'ann' in 'struct
+tree_common'.
+
+
+File: gccint.info,  Node: SSA Operands,  Next: SSA,  Prev: Annotations,  Up: Tree SSA
+
+12.2 SSA Operands
+=================
+
+Almost every GIMPLE statement will contain a reference to a variable or
+memory location.  Since statements come in different shapes and sizes,
+their operands are going to be located at various spots inside the
+statement's tree.  To facilitate access to the statement's operands,
+they are organized into lists associated inside each statement's
+annotation.  Each element in an operand list is a pointer to a
+'VAR_DECL', 'PARM_DECL' or 'SSA_NAME' tree node.  This provides a very
+convenient way of examining and replacing operands.
+
+ Data flow analysis and optimization is done on all tree nodes
+representing variables.  Any node for which 'SSA_VAR_P' returns nonzero
+is considered when scanning statement operands.  However, not all
+'SSA_VAR_P' variables are processed in the same way.  For the purposes
+of optimization, we need to distinguish between references to local
+scalar variables and references to globals, statics, structures, arrays,
+aliased variables, etc.  The reason is simple, the compiler can gather
+complete data flow information for a local scalar.  On the other hand, a
+global variable may be modified by a function call, it may not be
+possible to keep track of all the elements of an array or the fields of
+a structure, etc.
+
+ The operand scanner gathers two kinds of operands: "real" and
+"virtual".  An operand for which 'is_gimple_reg' returns true is
+considered real, otherwise it is a virtual operand.  We also distinguish
+between uses and definitions.  An operand is used if its value is loaded
+by the statement (e.g., the operand at the RHS of an assignment).  If
+the statement assigns a new value to the operand, the operand is
+considered a definition (e.g., the operand at the LHS of an assignment).
+
+ Virtual and real operands also have very different data flow
+properties.  Real operands are unambiguous references to the full object
+that they represent.  For instance, given
+
+     {
+       int a, b;
+       a = b
+     }
+
+ Since 'a' and 'b' are non-aliased locals, the statement 'a = b' will
+have one real definition and one real use because variable 'a' is
+completely modified with the contents of variable 'b'.  Real definition
+are also known as "killing definitions".  Similarly, the use of 'b'
+reads all its bits.
+
+ In contrast, virtual operands are used with variables that can have a
+partial or ambiguous reference.  This includes structures, arrays,
+globals, and aliased variables.  In these cases, we have two types of
+definitions.  For globals, structures, and arrays, we can determine from
+a statement whether a variable of these types has a killing definition.
+If the variable does, then the statement is marked as having a "must
+definition" of that variable.  However, if a statement is only defining
+a part of the variable (i.e. a field in a structure), or if we know that
+a statement might define the variable but we cannot say for sure, then
+we mark that statement as having a "may definition".  For instance,
+given
+
+     {
+       int a, b, *p;
+
+       if (...)
+         p = &a;
+       else
+         p = &b;
+       *p = 5;
+       return *p;
+     }
+
+ The assignment '*p = 5' may be a definition of 'a' or 'b'.  If we
+cannot determine statically where 'p' is pointing to at the time of the
+store operation, we create virtual definitions to mark that statement as
+a potential definition site for 'a' and 'b'.  Memory loads are similarly
+marked with virtual use operands.  Virtual operands are shown in tree
+dumps right before the statement that contains them.  To request a tree
+dump with virtual operands, use the '-vops' option to '-fdump-tree':
+
+     {
+       int a, b, *p;
+
+       if (...)
+         p = &a;
+       else
+         p = &b;
+       # a = VDEF <a>
+       # b = VDEF <b>
+       *p = 5;
+
+       # VUSE <a>
+       # VUSE <b>
+       return *p;
+     }
+
+ Notice that 'VDEF' operands have two copies of the referenced variable.
+This indicates that this is not a killing definition of that variable.
+In this case we refer to it as a "may definition" or "aliased store".
+The presence of the second copy of the variable in the 'VDEF' operand
+will become important when the function is converted into SSA form.
+This will be used to link all the non-killing definitions to prevent
+optimizations from making incorrect assumptions about them.
+
+ Operands are updated as soon as the statement is finished via a call to
+'update_stmt'.  If statement elements are changed via 'SET_USE' or
+'SET_DEF', then no further action is required (i.e., those macros take
+care of updating the statement).  If changes are made by manipulating
+the statement's tree directly, then a call must be made to 'update_stmt'
+when complete.  Calling one of the 'bsi_insert' routines or
+'bsi_replace' performs an implicit call to 'update_stmt'.
+
+12.2.1 Operand Iterators And Access Routines
+--------------------------------------------
+
+Operands are collected by 'tree-ssa-operands.c'.  They are stored inside
+each statement's annotation and can be accessed through either the
+operand iterators or an access routine.
+
+ The following access routines are available for examining operands:
+
+  1. 'SINGLE_SSA_{USE,DEF,TREE}_OPERAND': These accessors will return
+     NULL unless there is exactly one operand matching the specified
+     flags.  If there is exactly one operand, the operand is returned as
+     either a 'tree', 'def_operand_p', or 'use_operand_p'.
+
+          tree t = SINGLE_SSA_TREE_OPERAND (stmt, flags);
+          use_operand_p u = SINGLE_SSA_USE_OPERAND (stmt, SSA_ALL_VIRTUAL_USES);
+          def_operand_p d = SINGLE_SSA_DEF_OPERAND (stmt, SSA_OP_ALL_DEFS);
+
+  2. 'ZERO_SSA_OPERANDS': This macro returns true if there are no
+     operands matching the specified flags.
+
+          if (ZERO_SSA_OPERANDS (stmt, SSA_OP_ALL_VIRTUALS))
+            return;
+
+  3. 'NUM_SSA_OPERANDS': This macro Returns the number of operands
+     matching 'flags'.  This actually executes a loop to perform the
+     count, so only use this if it is really needed.
+
+          int count = NUM_SSA_OPERANDS (stmt, flags)
+
+ If you wish to iterate over some or all operands, use the
+'FOR_EACH_SSA_{USE,DEF,TREE}_OPERAND' iterator.  For example, to print
+all the operands for a statement:
+
+     void
+     print_ops (tree stmt)
+     {
+       ssa_op_iter;
+       tree var;
+
+       FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_ALL_OPERANDS)
+         print_generic_expr (stderr, var, TDF_SLIM);
+     }
+
+ How to choose the appropriate iterator:
+
+  1. Determine whether you are need to see the operand pointers, or just
+     the trees, and choose the appropriate macro:
+
+          Need            Macro:
+          ----            -------
+          use_operand_p   FOR_EACH_SSA_USE_OPERAND
+          def_operand_p   FOR_EACH_SSA_DEF_OPERAND
+          tree            FOR_EACH_SSA_TREE_OPERAND
+
+  2. You need to declare a variable of the type you are interested in,
+     and an ssa_op_iter structure which serves as the loop controlling
+     variable.
+
+  3. Determine which operands you wish to use, and specify the flags of
+     those you are interested in.  They are documented in
+     'tree-ssa-operands.h':
+
+          #define SSA_OP_USE              0x01    /* Real USE operands.  */
+          #define SSA_OP_DEF              0x02    /* Real DEF operands.  */
+          #define SSA_OP_VUSE             0x04    /* VUSE operands.  */
+          #define SSA_OP_VDEF             0x08    /* VDEF operands.  */
+
+          /* These are commonly grouped operand flags.  */
+          #define SSA_OP_VIRTUAL_USES	(SSA_OP_VUSE)
+          #define SSA_OP_VIRTUAL_DEFS	(SSA_OP_VDEF)
+          #define SSA_OP_ALL_VIRTUALS     (SSA_OP_VIRTUAL_USES | SSA_OP_VIRTUAL_DEFS)
+          #define SSA_OP_ALL_USES		(SSA_OP_VIRTUAL_USES | SSA_OP_USE)
+          #define SSA_OP_ALL_DEFS		(SSA_OP_VIRTUAL_DEFS | SSA_OP_DEF)
+          #define SSA_OP_ALL_OPERANDS	(SSA_OP_ALL_USES | SSA_OP_ALL_DEFS)
+
+ So if you want to look at the use pointers for all the 'USE' and 'VUSE'
+operands, you would do something like:
+
+       use_operand_p use_p;
+       ssa_op_iter iter;
+
+       FOR_EACH_SSA_USE_OPERAND (use_p, stmt, iter, (SSA_OP_USE | SSA_OP_VUSE))
+         {
+           process_use_ptr (use_p);
+         }
+
+ The 'TREE' macro is basically the same as the 'USE' and 'DEF' macros,
+only with the use or def dereferenced via 'USE_FROM_PTR (use_p)' and
+'DEF_FROM_PTR (def_p)'.  Since we aren't using operand pointers, use and
+defs flags can be mixed.
+
+       tree var;
+       ssa_op_iter iter;
+
+       FOR_EACH_SSA_TREE_OPERAND (var, stmt, iter, SSA_OP_VUSE)
+         {
+            print_generic_expr (stderr, var, TDF_SLIM);
+         }
+
+ 'VDEF's are broken into two flags, one for the 'DEF' portion
+('SSA_OP_VDEF') and one for the USE portion ('SSA_OP_VUSE').
+
+ There are many examples in the code, in addition to the documentation
+in 'tree-ssa-operands.h' and 'ssa-iterators.h'.
+
+ There are also a couple of variants on the stmt iterators regarding PHI
+nodes.
+
+ 'FOR_EACH_PHI_ARG' Works exactly like 'FOR_EACH_SSA_USE_OPERAND',
+except it works over 'PHI' arguments instead of statement operands.
+
+     /* Look at every virtual PHI use.  */
+     FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_VIRTUAL_USES)
+     {
+        my_code;
+     }
+
+     /* Look at every real PHI use.  */
+     FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_USES)
+       my_code;
+
+     /* Look at every PHI use.  */
+     FOR_EACH_PHI_ARG (use_p, phi_stmt, iter, SSA_OP_ALL_USES)
+       my_code;
+
+ 'FOR_EACH_PHI_OR_STMT_{USE,DEF}' works exactly like
+'FOR_EACH_SSA_{USE,DEF}_OPERAND', except it will function on either a
+statement or a 'PHI' node.  These should be used when it is appropriate
+but they are not quite as efficient as the individual 'FOR_EACH_PHI' and
+'FOR_EACH_SSA' routines.
+
+     FOR_EACH_PHI_OR_STMT_USE (use_operand_p, stmt, iter, flags)
+       {
+          my_code;
+       }
+
+     FOR_EACH_PHI_OR_STMT_DEF (def_operand_p, phi, iter, flags)
+       {
+          my_code;
+       }
+
+12.2.2 Immediate Uses
+---------------------
+
+Immediate use information is now always available.  Using the immediate
+use iterators, you may examine every use of any 'SSA_NAME'.  For
+instance, to change each use of 'ssa_var' to 'ssa_var2' and call
+fold_stmt on each stmt after that is done:
+
+       use_operand_p imm_use_p;
+       imm_use_iterator iterator;
+       tree ssa_var, stmt;
+
+
+       FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var)
+         {
+           FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator)
+             SET_USE (imm_use_p, ssa_var_2);
+           fold_stmt (stmt);
+         }
+
+ There are 2 iterators which can be used.  'FOR_EACH_IMM_USE_FAST' is
+used when the immediate uses are not changed, i.e., you are looking at
+the uses, but not setting them.
+
+ If they do get changed, then care must be taken that things are not
+changed under the iterators, so use the 'FOR_EACH_IMM_USE_STMT' and
+'FOR_EACH_IMM_USE_ON_STMT' iterators.  They attempt to preserve the
+sanity of the use list by moving all the uses for a statement into a
+controlled position, and then iterating over those uses.  Then the
+optimization can manipulate the stmt when all the uses have been
+processed.  This is a little slower than the FAST version since it adds
+a placeholder element and must sort through the list a bit for each
+statement.  This placeholder element must be also be removed if the loop
+is terminated early.  The macro 'BREAK_FROM_IMM_USE_SAFE' is provided to
+do this :
+
+       FOR_EACH_IMM_USE_STMT (stmt, iterator, ssa_var)
+         {
+           if (stmt == last_stmt)
+             BREAK_FROM_SAFE_IMM_USE (iter);
+
+           FOR_EACH_IMM_USE_ON_STMT (imm_use_p, iterator)
+             SET_USE (imm_use_p, ssa_var_2);
+           fold_stmt (stmt);
+         }
+
+ There are checks in 'verify_ssa' which verify that the immediate use
+list is up to date, as well as checking that an optimization didn't
+break from the loop without using this macro.  It is safe to simply
+'break'; from a 'FOR_EACH_IMM_USE_FAST' traverse.
+
+ Some useful functions and macros:
+  1. 'has_zero_uses (ssa_var)' : Returns true if there are no uses of
+     'ssa_var'.
+  2. 'has_single_use (ssa_var)' : Returns true if there is only a single
+     use of 'ssa_var'.
+  3. 'single_imm_use (ssa_var, use_operand_p *ptr, tree *stmt)' :
+     Returns true if there is only a single use of 'ssa_var', and also
+     returns the use pointer and statement it occurs in, in the second
+     and third parameters.
+  4. 'num_imm_uses (ssa_var)' : Returns the number of immediate uses of
+     'ssa_var'.  It is better not to use this if possible since it
+     simply utilizes a loop to count the uses.
+  5. 'PHI_ARG_INDEX_FROM_USE (use_p)' : Given a use within a 'PHI' node,
+     return the index number for the use.  An assert is triggered if the
+     use isn't located in a 'PHI' node.
+  6. 'USE_STMT (use_p)' : Return the statement a use occurs in.
+
+ Note that uses are not put into an immediate use list until their
+statement is actually inserted into the instruction stream via a 'bsi_*'
+routine.
+
+ It is also still possible to utilize lazy updating of statements, but
+this should be used only when absolutely required.  Both alias analysis
+and the dominator optimizations currently do this.
+
+ When lazy updating is being used, the immediate use information is out
+of date and cannot be used reliably.  Lazy updating is achieved by
+simply marking statements modified via calls to 'mark_stmt_modified'
+instead of 'update_stmt'.  When lazy updating is no longer required, all
+the modified statements must have 'update_stmt' called in order to bring
+them up to date.  This must be done before the optimization is finished,
+or 'verify_ssa' will trigger an abort.
+
+ This is done with a simple loop over the instruction stream:
+       block_stmt_iterator bsi;
+       basic_block bb;
+       FOR_EACH_BB (bb)
+         {
+           for (bsi = bsi_start (bb); !bsi_end_p (bsi); bsi_next (&bsi))
+             update_stmt_if_modified (bsi_stmt (bsi));
+         }
+
+
+File: gccint.info,  Node: SSA,  Next: Alias analysis,  Prev: SSA Operands,  Up: Tree SSA
+
+12.3 Static Single Assignment
+=============================
+
+Most of the tree optimizers rely on the data flow information provided
+by the Static Single Assignment (SSA) form.  We implement the SSA form
+as described in 'R. Cytron, J. Ferrante, B. Rosen, M. Wegman, and K.
+Zadeck. Efficiently Computing Static Single Assignment Form and the
+Control Dependence Graph. ACM Transactions on Programming Languages and
+Systems, 13(4):451-490, October 1991'.
+
+ The SSA form is based on the premise that program variables are
+assigned in exactly one location in the program.  Multiple assignments
+to the same variable create new versions of that variable.  Naturally,
+actual programs are seldom in SSA form initially because variables tend
+to be assigned multiple times.  The compiler modifies the program
+representation so that every time a variable is assigned in the code, a
+new version of the variable is created.  Different versions of the same
+variable are distinguished by subscripting the variable name with its
+version number.  Variables used in the right-hand side of expressions
+are renamed so that their version number matches that of the most recent
+assignment.
+
+ We represent variable versions using 'SSA_NAME' nodes.  The renaming
+process in 'tree-ssa.c' wraps every real and virtual operand with an
+'SSA_NAME' node which contains the version number and the statement that
+created the 'SSA_NAME'.  Only definitions and virtual definitions may
+create new 'SSA_NAME' nodes.
+
+ Sometimes, flow of control makes it impossible to determine the most
+recent version of a variable.  In these cases, the compiler inserts an
+artificial definition for that variable called "PHI function" or "PHI
+node".  This new definition merges all the incoming versions of the
+variable to create a new name for it.  For instance,
+
+     if (...)
+       a_1 = 5;
+     else if (...)
+       a_2 = 2;
+     else
+       a_3 = 13;
+
+     # a_4 = PHI <a_1, a_2, a_3>
+     return a_4;
+
+ Since it is not possible to determine which of the three branches will
+be taken at runtime, we don't know which of 'a_1', 'a_2' or 'a_3' to use
+at the return statement.  So, the SSA renamer creates a new version
+'a_4' which is assigned the result of "merging" 'a_1', 'a_2' and 'a_3'.
+Hence, PHI nodes mean "one of these operands.  I don't know which".
+
+ The following functions can be used to examine PHI nodes
+
+ -- Function: gimple_phi_result (PHI)
+     Returns the 'SSA_NAME' created by PHI node PHI (i.e., PHI's LHS).
+
+ -- Function: gimple_phi_num_args (PHI)
+     Returns the number of arguments in PHI.  This number is exactly the
+     number of incoming edges to the basic block holding PHI.
+
+ -- Function: gimple_phi_arg (PHI, I)
+     Returns Ith argument of PHI.
+
+ -- Function: gimple_phi_arg_edge (PHI, I)
+     Returns the incoming edge for the Ith argument of PHI.
+
+ -- Function: gimple_phi_arg_def (PHI, I)
+     Returns the 'SSA_NAME' for the Ith argument of PHI.
+
+12.3.1 Preserving the SSA form
+------------------------------
+
+Some optimization passes make changes to the function that invalidate
+the SSA property.  This can happen when a pass has added new symbols or
+changed the program so that variables that were previously aliased
+aren't anymore.  Whenever something like this happens, the affected
+symbols must be renamed into SSA form again.  Transformations that emit
+new code or replicate existing statements will also need to update the
+SSA form.
+
+ Since GCC implements two different SSA forms for register and virtual
+variables, keeping the SSA form up to date depends on whether you are
+updating register or virtual names.  In both cases, the general idea
+behind incremental SSA updates is similar: when new SSA names are
+created, they typically are meant to replace other existing names in the
+program.
+
+ For instance, given the following code:
+
+          1  L0:
+          2  x_1 = PHI (0, x_5)
+          3  if (x_1 < 10)
+          4    if (x_1 > 7)
+          5      y_2 = 0
+          6    else
+          7      y_3 = x_1 + x_7
+          8    endif
+          9    x_5 = x_1 + 1
+          10   goto L0;
+          11 endif
+
+ Suppose that we insert new names 'x_10' and 'x_11' (lines '4' and '8').
+
+          1  L0:
+          2  x_1 = PHI (0, x_5)
+          3  if (x_1 < 10)
+          4    x_10 = ...
+          5    if (x_1 > 7)
+          6      y_2 = 0
+          7    else
+          8      x_11 = ...
+          9      y_3 = x_1 + x_7
+          10   endif
+          11   x_5 = x_1 + 1
+          12   goto L0;
+          13 endif
+
+ We want to replace all the uses of 'x_1' with the new definitions of
+'x_10' and 'x_11'.  Note that the only uses that should be replaced are
+those at lines '5', '9' and '11'.  Also, the use of 'x_7' at line '9'
+should _not_ be replaced (this is why we cannot just mark symbol 'x' for
+renaming).
+
+ Additionally, we may need to insert a PHI node at line '11' because
+that is a merge point for 'x_10' and 'x_11'.  So the use of 'x_1' at
+line '11' will be replaced with the new PHI node.  The insertion of PHI
+nodes is optional.  They are not strictly necessary to preserve the SSA
+form, and depending on what the caller inserted, they may not even be
+useful for the optimizers.
+
+ Updating the SSA form is a two step process.  First, the pass has to
+identify which names need to be updated and/or which symbols need to be
+renamed into SSA form for the first time.  When new names are introduced
+to replace existing names in the program, the mapping between the old
+and the new names are registered by calling 'register_new_name_mapping'
+(note that if your pass creates new code by duplicating basic blocks,
+the call to 'tree_duplicate_bb' will set up the necessary mappings
+automatically).
+
+ After the replacement mappings have been registered and new symbols
+marked for renaming, a call to 'update_ssa' makes the registered
+changes.  This can be done with an explicit call or by creating 'TODO'
+flags in the 'tree_opt_pass' structure for your pass.  There are several
+'TODO' flags that control the behavior of 'update_ssa':
+
+   * 'TODO_update_ssa'.  Update the SSA form inserting PHI nodes for
+     newly exposed symbols and virtual names marked for updating.  When
+     updating real names, only insert PHI nodes for a real name 'O_j' in
+     blocks reached by all the new and old definitions for 'O_j'.  If
+     the iterated dominance frontier for 'O_j' is not pruned, we may end
+     up inserting PHI nodes in blocks that have one or more edges with
+     no incoming definition for 'O_j'.  This would lead to uninitialized
+     warnings for 'O_j''s symbol.
+
+   * 'TODO_update_ssa_no_phi'.  Update the SSA form without inserting
+     any new PHI nodes at all.  This is used by passes that have either
+     inserted all the PHI nodes themselves or passes that need only to
+     patch use-def and def-def chains for virtuals (e.g., DCE).
+
+   * 'TODO_update_ssa_full_phi'.  Insert PHI nodes everywhere they are
+     needed.  No pruning of the IDF is done.  This is used by passes
+     that need the PHI nodes for 'O_j' even if it means that some
+     arguments will come from the default definition of 'O_j''s symbol
+     (e.g., 'pass_linear_transform').
+
+     WARNING: If you need to use this flag, chances are that your pass
+     may be doing something wrong.  Inserting PHI nodes for an old name
+     where not all edges carry a new replacement may lead to silent
+     codegen errors or spurious uninitialized warnings.
+
+   * 'TODO_update_ssa_only_virtuals'.  Passes that update the SSA form
+     on their own may want to delegate the updating of virtual names to
+     the generic updater.  Since FUD chains are easier to maintain, this
+     simplifies the work they need to do.  NOTE: If this flag is used,
+     any OLD->NEW mappings for real names are explicitly destroyed and
+     only the symbols marked for renaming are processed.
+
+12.3.2 Preserving the virtual SSA form
+--------------------------------------
+
+The virtual SSA form is harder to preserve than the non-virtual SSA form
+mainly because the set of virtual operands for a statement may change at
+what some would consider unexpected times.  In general, statement
+modifications should be bracketed between calls to 'push_stmt_changes'
+and 'pop_stmt_changes'.  For example,
+
+         munge_stmt (tree stmt)
+         {
+            push_stmt_changes (&stmt);
+            ... rewrite STMT ...
+            pop_stmt_changes (&stmt);
+         }
+
+ The call to 'push_stmt_changes' saves the current state of the
+statement operands and the call to 'pop_stmt_changes' compares the saved
+state with the current one and does the appropriate symbol marking for
+the SSA renamer.
+
+ It is possible to modify several statements at a time, provided that
+'push_stmt_changes' and 'pop_stmt_changes' are called in LIFO order, as
+when processing a stack of statements.
+
+ Additionally, if the pass discovers that it did not need to make
+changes to the statement after calling 'push_stmt_changes', it can
+simply discard the topmost change buffer by calling
+'discard_stmt_changes'.  This will avoid the expensive operand re-scan
+operation and the buffer comparison that determines if symbols need to
+be marked for renaming.
+
+12.3.3 Examining 'SSA_NAME' nodes
+---------------------------------
+
+The following macros can be used to examine 'SSA_NAME' nodes
+
+ -- Macro: SSA_NAME_DEF_STMT (VAR)
+     Returns the statement S that creates the 'SSA_NAME' VAR.  If S is
+     an empty statement (i.e., 'IS_EMPTY_STMT (S)' returns 'true'), it
+     means that the first reference to this variable is a USE or a VUSE.
+
+ -- Macro: SSA_NAME_VERSION (VAR)
+     Returns the version number of the 'SSA_NAME' object VAR.
+
+12.3.4 Walking the dominator tree
+---------------------------------
+
+ -- Tree SSA function: void walk_dominator_tree (WALK_DATA, BB)
+
+     This function walks the dominator tree for the current CFG calling
+     a set of callback functions defined in STRUCT DOM_WALK_DATA in
+     'domwalk.h'.  The call back functions you need to define give you
+     hooks to execute custom code at various points during traversal:
+
+       1. Once to initialize any local data needed while processing BB
+          and its children.  This local data is pushed into an internal
+          stack which is automatically pushed and popped as the walker
+          traverses the dominator tree.
+
+       2. Once before traversing all the statements in the BB.
+
+       3. Once for every statement inside BB.
+
+       4. Once after traversing all the statements and before recursing
+          into BB's dominator children.
+
+       5. It then recurses into all the dominator children of BB.
+
+       6. After recursing into all the dominator children of BB it can,
+          optionally, traverse every statement in BB again (i.e.,
+          repeating steps 2 and 3).
+
+       7. Once after walking the statements in BB and BB's dominator
+          children.  At this stage, the block local data stack is
+          popped.
+
+
+File: gccint.info,  Node: Alias analysis,  Next: Memory model,  Prev: SSA,  Up: Tree SSA
+
+12.4 Alias analysis
+===================
+
+Alias analysis in GIMPLE SSA form consists of two pieces.  First the
+virtual SSA web ties conflicting memory accesses and provides a SSA
+use-def chain and SSA immediate-use chains for walking possibly
+dependent memory accesses.  Second an alias-oracle can be queried to
+disambiguate explicit and implicit memory references.
+
+  1. Memory SSA form.
+
+     All statements that may use memory have exactly one accompanied use
+     of a virtual SSA name that represents the state of memory at the
+     given point in the IL.
+
+     All statements that may define memory have exactly one accompanied
+     definition of a virtual SSA name using the previous state of memory
+     and defining the new state of memory after the given point in the
+     IL.
+
+          int i;
+          int foo (void)
+          {
+            # .MEM_3 = VDEF <.MEM_2(D)>
+            i = 1;
+            # VUSE <.MEM_3>
+            return i;
+          }
+
+     The virtual SSA names in this case are '.MEM_2(D)' and '.MEM_3'.
+     The store to the global variable 'i' defines '.MEM_3' invalidating
+     '.MEM_2(D)'.  The load from 'i' uses that new state '.MEM_3'.
+
+     The virtual SSA web serves as constraints to SSA optimizers
+     preventing illegitimate code-motion and optimization.  It also
+     provides a way to walk related memory statements.
+
+  2. Points-to and escape analysis.
+
+     Points-to analysis builds a set of constraints from the GIMPLE SSA
+     IL representing all pointer operations and facts we do or do not
+     know about pointers.  Solving this set of constraints yields a
+     conservatively correct solution for each pointer variable in the
+     program (though we are only interested in SSA name pointers) as to
+     what it may possibly point to.
+
+     This points-to solution for a given SSA name pointer is stored in
+     the 'pt_solution' sub-structure of the 'SSA_NAME_PTR_INFO' record.
+     The following accessor functions are available:
+
+        * 'pt_solution_includes'
+        * 'pt_solutions_intersect'
+
+     Points-to analysis also computes the solution for two special set
+     of pointers, 'ESCAPED' and 'CALLUSED'.  Those represent all memory
+     that has escaped the scope of analysis or that is used by pure or
+     nested const calls.
+
+  3. Type-based alias analysis
+
+     Type-based alias analysis is frontend dependent though generic
+     support is provided by the middle-end in 'alias.c'.  TBAA code is
+     used by both tree optimizers and RTL optimizers.
+
+     Every language that wishes to perform language-specific alias
+     analysis should define a function that computes, given a 'tree'
+     node, an alias set for the node.  Nodes in different alias sets are
+     not allowed to alias.  For an example, see the C front-end function
+     'c_get_alias_set'.
+
+  4. Tree alias-oracle
+
+     The tree alias-oracle provides means to disambiguate two memory
+     references and memory references against statements.  The following
+     queries are available:
+
+        * 'refs_may_alias_p'
+        * 'ref_maybe_used_by_stmt_p'
+        * 'stmt_may_clobber_ref_p'
+
+     In addition to those two kind of statement walkers are available
+     walking statements related to a reference ref.
+     'walk_non_aliased_vuses' walks over dominating memory defining
+     statements and calls back if the statement does not clobber ref
+     providing the non-aliased VUSE. The walk stops at the first
+     clobbering statement or if asked to.  'walk_aliased_vdefs' walks
+     over dominating memory defining statements and calls back on each
+     statement clobbering ref providing its aliasing VDEF. The walk
+     stops if asked to.
+
+
+File: gccint.info,  Node: Memory model,  Prev: Alias analysis,  Up: Tree SSA
+
+12.5 Memory model
+=================
+
+The memory model used by the middle-end models that of the C/C++
+languages.  The middle-end has the notion of an effective type of a
+memory region which is used for type-based alias analysis.
+
+ The following is a refinement of ISO C99 6.5/6, clarifying the block
+copy case to follow common sense and extending the concept of a dynamic
+effective type to objects with a declared type as required for C++.
+
+     The effective type of an object for an access to its stored value is
+     the declared type of the object or the effective type determined by
+     a previous store to it.  If a value is stored into an object through
+     an lvalue having a type that is not a character type, then the
+     type of the lvalue becomes the effective type of the object for that
+     access and for subsequent accesses that do not modify the stored value.
+     If a value is copied into an object using memcpy or memmove,
+     or is copied as an array of character type, then the effective type
+     of the modified object for that access and for subsequent accesses that
+     do not modify the value is undetermined.  For all other accesses to an
+     object, the effective type of the object is simply the type of the
+     lvalue used for the access.
+
+
+File: gccint.info,  Node: RTL,  Next: Control Flow,  Prev: Tree SSA,  Up: Top
+
+13 RTL Representation
+*********************
+
+The last part of the compiler work is done on a low-level intermediate
+representation called Register Transfer Language.  In this language, the
+instructions to be output are described, pretty much one by one, in an
+algebraic form that describes what the instruction does.
+
+ RTL is inspired by Lisp lists.  It has both an internal form, made up
+of structures that point at other structures, and a textual form that is
+used in the machine description and in printed debugging dumps.  The
+textual form uses nested parentheses to indicate the pointers in the
+internal form.
+
+* Menu:
+
+* RTL Objects::       Expressions vs vectors vs strings vs integers.
+* RTL Classes::       Categories of RTL expression objects, and their structure.
+* Accessors::         Macros to access expression operands or vector elts.
+* Special Accessors:: Macros to access specific annotations on RTL.
+* Flags::             Other flags in an RTL expression.
+* Machine Modes::     Describing the size and format of a datum.
+* Constants::         Expressions with constant values.
+* Regs and Memory::   Expressions representing register contents or memory.
+* Arithmetic::        Expressions representing arithmetic on other expressions.
+* Comparisons::       Expressions representing comparison of expressions.
+* Bit-Fields::        Expressions representing bit-fields in memory or reg.
+* Vector Operations:: Expressions involving vector datatypes.
+* Conversions::       Extending, truncating, floating or fixing.
+* RTL Declarations::  Declaring volatility, constancy, etc.
+* Side Effects::      Expressions for storing in registers, etc.
+* Incdec::            Embedded side-effects for autoincrement addressing.
+* Assembler::         Representing 'asm' with operands.
+* Debug Information:: Expressions representing debugging information.
+* Insns::             Expression types for entire insns.
+* Calls::             RTL representation of function call insns.
+* Sharing::           Some expressions are unique; others *must* be copied.
+* Reading RTL::       Reading textual RTL from a file.
+
+
+File: gccint.info,  Node: RTL Objects,  Next: RTL Classes,  Up: RTL
+
+13.1 RTL Object Types
+=====================
+
+RTL uses five kinds of objects: expressions, integers, wide integers,
+strings and vectors.  Expressions are the most important ones.  An RTL
+expression ("RTX", for short) is a C structure, but it is usually
+referred to with a pointer; a type that is given the typedef name 'rtx'.
+
+ An integer is simply an 'int'; their written form uses decimal digits.
+A wide integer is an integral object whose type is 'HOST_WIDE_INT';
+their written form uses decimal digits.
+
+ A string is a sequence of characters.  In core it is represented as a
+'char *' in usual C fashion, and it is written in C syntax as well.
+However, strings in RTL may never be null.  If you write an empty string
+in a machine description, it is represented in core as a null pointer
+rather than as a pointer to a null character.  In certain contexts,
+these null pointers instead of strings are valid.  Within RTL code,
+strings are most commonly found inside 'symbol_ref' expressions, but
+they appear in other contexts in the RTL expressions that make up
+machine descriptions.
+
+ In a machine description, strings are normally written with double
+quotes, as you would in C.  However, strings in machine descriptions may
+extend over many lines, which is invalid C, and adjacent string
+constants are not concatenated as they are in C.  Any string constant
+may be surrounded with a single set of parentheses.  Sometimes this
+makes the machine description easier to read.
+
+ There is also a special syntax for strings, which can be useful when C
+code is embedded in a machine description.  Wherever a string can
+appear, it is also valid to write a C-style brace block.  The entire
+brace block, including the outermost pair of braces, is considered to be
+the string constant.  Double quote characters inside the braces are not
+special.  Therefore, if you write string constants in the C code, you
+need not escape each quote character with a backslash.
+
+ A vector contains an arbitrary number of pointers to expressions.  The
+number of elements in the vector is explicitly present in the vector.
+The written form of a vector consists of square brackets ('[...]')
+surrounding the elements, in sequence and with whitespace separating
+them.  Vectors of length zero are not created; null pointers are used
+instead.
+
+ Expressions are classified by "expression codes" (also called RTX
+codes).  The expression code is a name defined in 'rtl.def', which is
+also (in uppercase) a C enumeration constant.  The possible expression
+codes and their meanings are machine-independent.  The code of an RTX
+can be extracted with the macro 'GET_CODE (X)' and altered with
+'PUT_CODE (X, NEWCODE)'.
+
+ The expression code determines how many operands the expression
+contains, and what kinds of objects they are.  In RTL, unlike Lisp, you
+cannot tell by looking at an operand what kind of object it is.
+Instead, you must know from its context--from the expression code of the
+containing expression.  For example, in an expression of code 'subreg',
+the first operand is to be regarded as an expression and the second
+operand as an integer.  In an expression of code 'plus', there are two
+operands, both of which are to be regarded as expressions.  In a
+'symbol_ref' expression, there is one operand, which is to be regarded
+as a string.
+
+ Expressions are written as parentheses containing the name of the
+expression type, its flags and machine mode if any, and then the
+operands of the expression (separated by spaces).
+
+ Expression code names in the 'md' file are written in lowercase, but
+when they appear in C code they are written in uppercase.  In this
+manual, they are shown as follows: 'const_int'.
+
+ In a few contexts a null pointer is valid where an expression is
+normally wanted.  The written form of this is '(nil)'.
+
+
+File: gccint.info,  Node: RTL Classes,  Next: Accessors,  Prev: RTL Objects,  Up: RTL
+
+13.2 RTL Classes and Formats
+============================
+
+The various expression codes are divided into several "classes", which
+are represented by single characters.  You can determine the class of an
+RTX code with the macro 'GET_RTX_CLASS (CODE)'.  Currently, 'rtl.def'
+defines these classes:
+
+'RTX_OBJ'
+     An RTX code that represents an actual object, such as a register
+     ('REG') or a memory location ('MEM', 'SYMBOL_REF').  'LO_SUM') is
+     also included; instead, 'SUBREG' and 'STRICT_LOW_PART' are not in
+     this class, but in class 'x'.
+
+'RTX_CONST_OBJ'
+     An RTX code that represents a constant object.  'HIGH' is also
+     included in this class.
+
+'RTX_COMPARE'
+     An RTX code for a non-symmetric comparison, such as 'GEU' or 'LT'.
+
+'RTX_COMM_COMPARE'
+     An RTX code for a symmetric (commutative) comparison, such as 'EQ'
+     or 'ORDERED'.
+
+'RTX_UNARY'
+     An RTX code for a unary arithmetic operation, such as 'NEG', 'NOT',
+     or 'ABS'.  This category also includes value extension (sign or
+     zero) and conversions between integer and floating point.
+
+'RTX_COMM_ARITH'
+     An RTX code for a commutative binary operation, such as 'PLUS' or
+     'AND'.  'NE' and 'EQ' are comparisons, so they have class '<'.
+
+'RTX_BIN_ARITH'
+     An RTX code for a non-commutative binary operation, such as
+     'MINUS', 'DIV', or 'ASHIFTRT'.
+
+'RTX_BITFIELD_OPS'
+     An RTX code for a bit-field operation.  Currently only
+     'ZERO_EXTRACT' and 'SIGN_EXTRACT'.  These have three inputs and are
+     lvalues (so they can be used for insertion as well).  *Note
+     Bit-Fields::.
+
+'RTX_TERNARY'
+     An RTX code for other three input operations.  Currently only
+     'IF_THEN_ELSE', 'VEC_MERGE', 'SIGN_EXTRACT', 'ZERO_EXTRACT', and
+     'FMA'.
+
+'RTX_INSN'
+     An RTX code for an entire instruction: 'INSN', 'JUMP_INSN', and
+     'CALL_INSN'.  *Note Insns::.
+
+'RTX_MATCH'
+     An RTX code for something that matches in insns, such as
+     'MATCH_DUP'.  These only occur in machine descriptions.
+
+'RTX_AUTOINC'
+     An RTX code for an auto-increment addressing mode, such as
+     'POST_INC'.
+
+'RTX_EXTRA'
+     All other RTX codes.  This category includes the remaining codes
+     used only in machine descriptions ('DEFINE_*', etc.).  It also
+     includes all the codes describing side effects ('SET', 'USE',
+     'CLOBBER', etc.)  and the non-insns that may appear on an insn
+     chain, such as 'NOTE', 'BARRIER', and 'CODE_LABEL'.  'SUBREG' is
+     also part of this class.
+
+ For each expression code, 'rtl.def' specifies the number of contained
+objects and their kinds using a sequence of characters called the
+"format" of the expression code.  For example, the format of 'subreg' is
+'ei'.
+
+ These are the most commonly used format characters:
+
+'e'
+     An expression (actually a pointer to an expression).
+
+'i'
+     An integer.
+
+'w'
+     A wide integer.
+
+'s'
+     A string.
+
+'E'
+     A vector of expressions.
+
+ A few other format characters are used occasionally:
+
+'u'
+     'u' is equivalent to 'e' except that it is printed differently in
+     debugging dumps.  It is used for pointers to insns.
+
+'n'
+     'n' is equivalent to 'i' except that it is printed differently in
+     debugging dumps.  It is used for the line number or code number of
+     a 'note' insn.
+
+'S'
+     'S' indicates a string which is optional.  In the RTL objects in
+     core, 'S' is equivalent to 's', but when the object is read, from
+     an 'md' file, the string value of this operand may be omitted.  An
+     omitted string is taken to be the null string.
+
+'V'
+     'V' indicates a vector which is optional.  In the RTL objects in
+     core, 'V' is equivalent to 'E', but when the object is read from an
+     'md' file, the vector value of this operand may be omitted.  An
+     omitted vector is effectively the same as a vector of no elements.
+
+'B'
+     'B' indicates a pointer to basic block structure.
+
+'0'
+     '0' means a slot whose contents do not fit any normal category.
+     '0' slots are not printed at all in dumps, and are often used in
+     special ways by small parts of the compiler.
+
+ There are macros to get the number of operands and the format of an
+expression code:
+
+'GET_RTX_LENGTH (CODE)'
+     Number of operands of an RTX of code CODE.
+
+'GET_RTX_FORMAT (CODE)'
+     The format of an RTX of code CODE, as a C string.
+
+ Some classes of RTX codes always have the same format.  For example, it
+is safe to assume that all comparison operations have format 'ee'.
+
+'1'
+     All codes of this class have format 'e'.
+
+'<'
+'c'
+'2'
+     All codes of these classes have format 'ee'.
+
+'b'
+'3'
+     All codes of these classes have format 'eee'.
+
+'i'
+     All codes of this class have formats that begin with 'iuueiee'.
+     *Note Insns::.  Note that not all RTL objects linked onto an insn
+     chain are of class 'i'.
+
+'o'
+'m'
+'x'
+     You can make no assumptions about the format of these codes.
+
+
+File: gccint.info,  Node: Accessors,  Next: Special Accessors,  Prev: RTL Classes,  Up: RTL
+
+13.3 Access to Operands
+=======================
+
+Operands of expressions are accessed using the macros 'XEXP', 'XINT',
+'XWINT' and 'XSTR'.  Each of these macros takes two arguments: an
+expression-pointer (RTX) and an operand number (counting from zero).
+Thus,
+
+     XEXP (X, 2)
+
+accesses operand 2 of expression X, as an expression.
+
+     XINT (X, 2)
+
+accesses the same operand as an integer.  'XSTR', used in the same
+fashion, would access it as a string.
+
+ Any operand can be accessed as an integer, as an expression or as a
+string.  You must choose the correct method of access for the kind of
+value actually stored in the operand.  You would do this based on the
+expression code of the containing expression.  That is also how you
+would know how many operands there are.
+
+ For example, if X is a 'subreg' expression, you know that it has two
+operands which can be correctly accessed as 'XEXP (X, 0)' and 'XINT (X,
+1)'.  If you did 'XINT (X, 0)', you would get the address of the
+expression operand but cast as an integer; that might occasionally be
+useful, but it would be cleaner to write '(int) XEXP (X, 0)'.  'XEXP (X,
+1)' would also compile without error, and would return the second,
+integer operand cast as an expression pointer, which would probably
+result in a crash when accessed.  Nothing stops you from writing 'XEXP
+(X, 28)' either, but this will access memory past the end of the
+expression with unpredictable results.
+
+ Access to operands which are vectors is more complicated.  You can use
+the macro 'XVEC' to get the vector-pointer itself, or the macros
+'XVECEXP' and 'XVECLEN' to access the elements and length of a vector.
+
+'XVEC (EXP, IDX)'
+     Access the vector-pointer which is operand number IDX in EXP.
+
+'XVECLEN (EXP, IDX)'
+     Access the length (number of elements) in the vector which is in
+     operand number IDX in EXP.  This value is an 'int'.
+
+'XVECEXP (EXP, IDX, ELTNUM)'
+     Access element number ELTNUM in the vector which is in operand
+     number IDX in EXP.  This value is an RTX.
+
+     It is up to you to make sure that ELTNUM is not negative and is
+     less than 'XVECLEN (EXP, IDX)'.
+
+ All the macros defined in this section expand into lvalues and
+therefore can be used to assign the operands, lengths and vector
+elements as well as to access them.
+
+
+File: gccint.info,  Node: Special Accessors,  Next: Flags,  Prev: Accessors,  Up: RTL
+
+13.4 Access to Special Operands
+===============================
+
+Some RTL nodes have special annotations associated with them.
+
+'MEM'
+     'MEM_ALIAS_SET (X)'
+          If 0, X is not in any alias set, and may alias anything.
+          Otherwise, X can only alias 'MEM's in a conflicting alias set.
+          This value is set in a language-dependent manner in the
+          front-end, and should not be altered in the back-end.  In some
+          front-ends, these numbers may correspond in some way to types,
+          or other language-level entities, but they need not, and the
+          back-end makes no such assumptions.  These set numbers are
+          tested with 'alias_sets_conflict_p'.
+
+     'MEM_EXPR (X)'
+          If this register is known to hold the value of some user-level
+          declaration, this is that tree node.  It may also be a
+          'COMPONENT_REF', in which case this is some field reference,
+          and 'TREE_OPERAND (X, 0)' contains the declaration, or another
+          'COMPONENT_REF', or null if there is no compile-time object
+          associated with the reference.
+
+     'MEM_OFFSET_KNOWN_P (X)'
+          True if the offset of the memory reference from 'MEM_EXPR' is
+          known.  'MEM_OFFSET (X)' provides the offset if so.
+
+     'MEM_OFFSET (X)'
+          The offset from the start of 'MEM_EXPR'.  The value is only
+          valid if 'MEM_OFFSET_KNOWN_P (X)' is true.
+
+     'MEM_SIZE_KNOWN_P (X)'
+          True if the size of the memory reference is known.  'MEM_SIZE
+          (X)' provides its size if so.
+
+     'MEM_SIZE (X)'
+          The size in bytes of the memory reference.  This is mostly
+          relevant for 'BLKmode' references as otherwise the size is
+          implied by the mode.  The value is only valid if
+          'MEM_SIZE_KNOWN_P (X)' is true.
+
+     'MEM_ALIGN (X)'
+          The known alignment in bits of the memory reference.
+
+     'MEM_ADDR_SPACE (X)'
+          The address space of the memory reference.  This will commonly
+          be zero for the generic address space.
+
+'REG'
+     'ORIGINAL_REGNO (X)'
+          This field holds the number the register "originally" had; for
+          a pseudo register turned into a hard reg this will hold the
+          old pseudo register number.
+
+     'REG_EXPR (X)'
+          If this register is known to hold the value of some user-level
+          declaration, this is that tree node.
+
+     'REG_OFFSET (X)'
+          If this register is known to hold the value of some user-level
+          declaration, this is the offset into that logical storage.
+
+'SYMBOL_REF'
+     'SYMBOL_REF_DECL (X)'
+          If the 'symbol_ref' X was created for a 'VAR_DECL' or a
+          'FUNCTION_DECL', that tree is recorded here.  If this value is
+          null, then X was created by back end code generation routines,
+          and there is no associated front end symbol table entry.
+
+          'SYMBOL_REF_DECL' may also point to a tree of class ''c'',
+          that is, some sort of constant.  In this case, the
+          'symbol_ref' is an entry in the per-file constant pool; again,
+          there is no associated front end symbol table entry.
+
+     'SYMBOL_REF_CONSTANT (X)'
+          If 'CONSTANT_POOL_ADDRESS_P (X)' is true, this is the constant
+          pool entry for X.  It is null otherwise.
+
+     'SYMBOL_REF_DATA (X)'
+          A field of opaque type used to store 'SYMBOL_REF_DECL' or
+          'SYMBOL_REF_CONSTANT'.
+
+     'SYMBOL_REF_FLAGS (X)'
+          In a 'symbol_ref', this is used to communicate various
+          predicates about the symbol.  Some of these are common enough
+          to be computed by common code, some are specific to the
+          target.  The common bits are:
+
+          'SYMBOL_FLAG_FUNCTION'
+               Set if the symbol refers to a function.
+
+          'SYMBOL_FLAG_LOCAL'
+               Set if the symbol is local to this "module".  See
+               'TARGET_BINDS_LOCAL_P'.
+
+          'SYMBOL_FLAG_EXTERNAL'
+               Set if this symbol is not defined in this translation
+               unit.  Note that this is not the inverse of
+               'SYMBOL_FLAG_LOCAL'.
+
+          'SYMBOL_FLAG_SMALL'
+               Set if the symbol is located in the small data section.
+               See 'TARGET_IN_SMALL_DATA_P'.
+
+          'SYMBOL_REF_TLS_MODEL (X)'
+               This is a multi-bit field accessor that returns the
+               'tls_model' to be used for a thread-local storage symbol.
+               It returns zero for non-thread-local symbols.
+
+          'SYMBOL_FLAG_HAS_BLOCK_INFO'
+               Set if the symbol has 'SYMBOL_REF_BLOCK' and
+               'SYMBOL_REF_BLOCK_OFFSET' fields.
+
+          'SYMBOL_FLAG_ANCHOR'
+               Set if the symbol is used as a section anchor.  "Section
+               anchors" are symbols that have a known position within an
+               'object_block' and that can be used to access nearby
+               members of that block.  They are used to implement
+               '-fsection-anchors'.
+
+               If this flag is set, then 'SYMBOL_FLAG_HAS_BLOCK_INFO'
+               will be too.
+
+          Bits beginning with 'SYMBOL_FLAG_MACH_DEP' are available for
+          the target's use.
+
+'SYMBOL_REF_BLOCK (X)'
+     If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the 'object_block'
+     structure to which the symbol belongs, or 'NULL' if it has not been
+     assigned a block.
+
+'SYMBOL_REF_BLOCK_OFFSET (X)'
+     If 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)', this is the offset of X from
+     the first object in 'SYMBOL_REF_BLOCK (X)'.  The value is negative
+     if X has not yet been assigned to a block, or it has not been given
+     an offset within that block.
+
+
+File: gccint.info,  Node: Flags,  Next: Machine Modes,  Prev: Special Accessors,  Up: RTL
+
+13.5 Flags in an RTL Expression
+===============================
+
+RTL expressions contain several flags (one-bit bit-fields) that are used
+in certain types of expression.  Most often they are accessed with the
+following macros, which expand into lvalues.
+
+'CONSTANT_POOL_ADDRESS_P (X)'
+     Nonzero in a 'symbol_ref' if it refers to part of the current
+     function's constant pool.  For most targets these addresses are in
+     a '.rodata' section entirely separate from the function, but for
+     some targets the addresses are close to the beginning of the
+     function.  In either case GCC assumes these addresses can be
+     addressed directly, perhaps with the help of base registers.
+     Stored in the 'unchanging' field and printed as '/u'.
+
+'RTL_CONST_CALL_P (X)'
+     In a 'call_insn' indicates that the insn represents a call to a
+     const function.  Stored in the 'unchanging' field and printed as
+     '/u'.
+
+'RTL_PURE_CALL_P (X)'
+     In a 'call_insn' indicates that the insn represents a call to a
+     pure function.  Stored in the 'return_val' field and printed as
+     '/i'.
+
+'RTL_CONST_OR_PURE_CALL_P (X)'
+     In a 'call_insn', true if 'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P'
+     is true.
+
+'RTL_LOOPING_CONST_OR_PURE_CALL_P (X)'
+     In a 'call_insn' indicates that the insn represents a possibly
+     infinite looping call to a const or pure function.  Stored in the
+     'call' field and printed as '/c'.  Only true if one of
+     'RTL_CONST_CALL_P' or 'RTL_PURE_CALL_P' is true.
+
+'INSN_ANNULLED_BRANCH_P (X)'
+     In a 'jump_insn', 'call_insn', or 'insn' indicates that the branch
+     is an annulling one.  See the discussion under 'sequence' below.
+     Stored in the 'unchanging' field and printed as '/u'.
+
+'INSN_DELETED_P (X)'
+     In an 'insn', 'call_insn', 'jump_insn', 'code_label',
+     'jump_table_data', 'barrier', or 'note', nonzero if the insn has
+     been deleted.  Stored in the 'volatil' field and printed as '/v'.
+
+'INSN_FROM_TARGET_P (X)'
+     In an 'insn' or 'jump_insn' or 'call_insn' in a delay slot of a
+     branch, indicates that the insn is from the target of the branch.
+     If the branch insn has 'INSN_ANNULLED_BRANCH_P' set, this insn will
+     only be executed if the branch is taken.  For annulled branches
+     with 'INSN_FROM_TARGET_P' clear, the insn will be executed only if
+     the branch is not taken.  When 'INSN_ANNULLED_BRANCH_P' is not set,
+     this insn will always be executed.  Stored in the 'in_struct' field
+     and printed as '/s'.
+
+'LABEL_PRESERVE_P (X)'
+     In a 'code_label' or 'note', indicates that the label is referenced
+     by code or data not visible to the RTL of a given function.  Labels
+     referenced by a non-local goto will have this bit set.  Stored in
+     the 'in_struct' field and printed as '/s'.
+
+'LABEL_REF_NONLOCAL_P (X)'
+     In 'label_ref' and 'reg_label' expressions, nonzero if this is a
+     reference to a non-local label.  Stored in the 'volatil' field and
+     printed as '/v'.
+
+'MEM_KEEP_ALIAS_SET_P (X)'
+     In 'mem' expressions, 1 if we should keep the alias set for this
+     mem unchanged when we access a component.  Set to 1, for example,
+     when we are already in a non-addressable component of an aggregate.
+     Stored in the 'jump' field and printed as '/j'.
+
+'MEM_VOLATILE_P (X)'
+     In 'mem', 'asm_operands', and 'asm_input' expressions, nonzero for
+     volatile memory references.  Stored in the 'volatil' field and
+     printed as '/v'.
+
+'MEM_NOTRAP_P (X)'
+     In 'mem', nonzero for memory references that will not trap.  Stored
+     in the 'call' field and printed as '/c'.
+
+'MEM_POINTER (X)'
+     Nonzero in a 'mem' if the memory reference holds a pointer.  Stored
+     in the 'frame_related' field and printed as '/f'.
+
+'REG_FUNCTION_VALUE_P (X)'
+     Nonzero in a 'reg' if it is the place in which this function's
+     value is going to be returned.  (This happens only in a hard
+     register.)  Stored in the 'return_val' field and printed as '/i'.
+
+'REG_POINTER (X)'
+     Nonzero in a 'reg' if the register holds a pointer.  Stored in the
+     'frame_related' field and printed as '/f'.
+
+'REG_USERVAR_P (X)'
+     In a 'reg', nonzero if it corresponds to a variable present in the
+     user's source code.  Zero for temporaries generated internally by
+     the compiler.  Stored in the 'volatil' field and printed as '/v'.
+
+     The same hard register may be used also for collecting the values
+     of functions called by this one, but 'REG_FUNCTION_VALUE_P' is zero
+     in this kind of use.
+
+'RTX_FRAME_RELATED_P (X)'
+     Nonzero in an 'insn', 'call_insn', 'jump_insn', 'barrier', or 'set'
+     which is part of a function prologue and sets the stack pointer,
+     sets the frame pointer, or saves a register.  This flag should also
+     be set on an instruction that sets up a temporary register to use
+     in place of the frame pointer.  Stored in the 'frame_related' field
+     and printed as '/f'.
+
+     In particular, on RISC targets where there are limits on the sizes
+     of immediate constants, it is sometimes impossible to reach the
+     register save area directly from the stack pointer.  In that case,
+     a temporary register is used that is near enough to the register
+     save area, and the Canonical Frame Address, i.e., DWARF2's logical
+     frame pointer, register must (temporarily) be changed to be this
+     temporary register.  So, the instruction that sets this temporary
+     register must be marked as 'RTX_FRAME_RELATED_P'.
+
+     If the marked instruction is overly complex (defined in terms of
+     what 'dwarf2out_frame_debug_expr' can handle), you will also have
+     to create a 'REG_FRAME_RELATED_EXPR' note and attach it to the
+     instruction.  This note should contain a simple expression of the
+     computation performed by this instruction, i.e., one that
+     'dwarf2out_frame_debug_expr' can handle.
+
+     This flag is required for exception handling support on targets
+     with RTL prologues.
+
+'MEM_READONLY_P (X)'
+     Nonzero in a 'mem', if the memory is statically allocated and
+     read-only.
+
+     Read-only in this context means never modified during the lifetime
+     of the program, not necessarily in ROM or in write-disabled pages.
+     A common example of the later is a shared library's global offset
+     table.  This table is initialized by the runtime loader, so the
+     memory is technically writable, but after control is transferred
+     from the runtime loader to the application, this memory will never
+     be subsequently modified.
+
+     Stored in the 'unchanging' field and printed as '/u'.
+
+'SCHED_GROUP_P (X)'
+     During instruction scheduling, in an 'insn', 'call_insn',
+     'jump_insn' or 'jump_table_data', indicates that the previous insn
+     must be scheduled together with this insn.  This is used to ensure
+     that certain groups of instructions will not be split up by the
+     instruction scheduling pass, for example, 'use' insns before a
+     'call_insn' may not be separated from the 'call_insn'.  Stored in
+     the 'in_struct' field and printed as '/s'.
+
+'SET_IS_RETURN_P (X)'
+     For a 'set', nonzero if it is for a return.  Stored in the 'jump'
+     field and printed as '/j'.
+
+'SIBLING_CALL_P (X)'
+     For a 'call_insn', nonzero if the insn is a sibling call.  Stored
+     in the 'jump' field and printed as '/j'.
+
+'STRING_POOL_ADDRESS_P (X)'
+     For a 'symbol_ref' expression, nonzero if it addresses this
+     function's string constant pool.  Stored in the 'frame_related'
+     field and printed as '/f'.
+
+'SUBREG_PROMOTED_UNSIGNED_P (X)'
+     Returns a value greater then zero for a 'subreg' that has
+     'SUBREG_PROMOTED_VAR_P' nonzero if the object being referenced is
+     kept zero-extended, zero if it is kept sign-extended, and less then
+     zero if it is extended some other way via the 'ptr_extend'
+     instruction.  Stored in the 'unchanging' field and 'volatil' field,
+     printed as '/u' and '/v'.  This macro may only be used to get the
+     value it may not be used to change the value.  Use
+     'SUBREG_PROMOTED_UNSIGNED_SET' to change the value.
+
+'SUBREG_PROMOTED_UNSIGNED_SET (X)'
+     Set the 'unchanging' and 'volatil' fields in a 'subreg' to reflect
+     zero, sign, or other extension.  If 'volatil' is zero, then
+     'unchanging' as nonzero means zero extension and as zero means sign
+     extension.  If 'volatil' is nonzero then some other type of
+     extension was done via the 'ptr_extend' instruction.
+
+'SUBREG_PROMOTED_VAR_P (X)'
+     Nonzero in a 'subreg' if it was made when accessing an object that
+     was promoted to a wider mode in accord with the 'PROMOTED_MODE'
+     machine description macro (*note Storage Layout::).  In this case,
+     the mode of the 'subreg' is the declared mode of the object and the
+     mode of 'SUBREG_REG' is the mode of the register that holds the
+     object.  Promoted variables are always either sign- or
+     zero-extended to the wider mode on every assignment.  Stored in the
+     'in_struct' field and printed as '/s'.
+
+'SYMBOL_REF_USED (X)'
+     In a 'symbol_ref', indicates that X has been used.  This is
+     normally only used to ensure that X is only declared external once.
+     Stored in the 'used' field.
+
+'SYMBOL_REF_WEAK (X)'
+     In a 'symbol_ref', indicates that X has been declared weak.  Stored
+     in the 'return_val' field and printed as '/i'.
+
+'SYMBOL_REF_FLAG (X)'
+     In a 'symbol_ref', this is used as a flag for machine-specific
+     purposes.  Stored in the 'volatil' field and printed as '/v'.
+
+     Most uses of 'SYMBOL_REF_FLAG' are historic and may be subsumed by
+     'SYMBOL_REF_FLAGS'.  Certainly use of 'SYMBOL_REF_FLAGS' is
+     mandatory if the target requires more than one bit of storage.
+
+'PREFETCH_SCHEDULE_BARRIER_P (X)'
+     In a 'prefetch', indicates that the prefetch is a scheduling
+     barrier.  No other INSNs will be moved over it.  Stored in the
+     'volatil' field and printed as '/v'.
+
+ These are the fields to which the above macros refer:
+
+'call'
+     In a 'mem', 1 means that the memory reference will not trap.
+
+     In a 'call', 1 means that this pure or const call may possibly
+     infinite loop.
+
+     In an RTL dump, this flag is represented as '/c'.
+
+'frame_related'
+     In an 'insn' or 'set' expression, 1 means that it is part of a
+     function prologue and sets the stack pointer, sets the frame
+     pointer, saves a register, or sets up a temporary register to use
+     in place of the frame pointer.
+
+     In 'reg' expressions, 1 means that the register holds a pointer.
+
+     In 'mem' expressions, 1 means that the memory reference holds a
+     pointer.
+
+     In 'symbol_ref' expressions, 1 means that the reference addresses
+     this function's string constant pool.
+
+     In an RTL dump, this flag is represented as '/f'.
+
+'in_struct'
+     In 'reg' expressions, it is 1 if the register has its entire life
+     contained within the test expression of some loop.
+
+     In 'subreg' expressions, 1 means that the 'subreg' is accessing an
+     object that has had its mode promoted from a wider mode.
+
+     In 'label_ref' expressions, 1 means that the referenced label is
+     outside the innermost loop containing the insn in which the
+     'label_ref' was found.
+
+     In 'code_label' expressions, it is 1 if the label may never be
+     deleted.  This is used for labels which are the target of non-local
+     gotos.  Such a label that would have been deleted is replaced with
+     a 'note' of type 'NOTE_INSN_DELETED_LABEL'.
+
+     In an 'insn' during dead-code elimination, 1 means that the insn is
+     dead code.
+
+     In an 'insn' or 'jump_insn' during reorg for an insn in the delay
+     slot of a branch, 1 means that this insn is from the target of the
+     branch.
+
+     In an 'insn' during instruction scheduling, 1 means that this insn
+     must be scheduled as part of a group together with the previous
+     insn.
+
+     In an RTL dump, this flag is represented as '/s'.
+
+'return_val'
+     In 'reg' expressions, 1 means the register contains the value to be
+     returned by the current function.  On machines that pass parameters
+     in registers, the same register number may be used for parameters
+     as well, but this flag is not set on such uses.
+
+     In 'symbol_ref' expressions, 1 means the referenced symbol is weak.
+
+     In 'call' expressions, 1 means the call is pure.
+
+     In an RTL dump, this flag is represented as '/i'.
+
+'jump'
+     In a 'mem' expression, 1 means we should keep the alias set for
+     this mem unchanged when we access a component.
+
+     In a 'set', 1 means it is for a return.
+
+     In a 'call_insn', 1 means it is a sibling call.
+
+     In an RTL dump, this flag is represented as '/j'.
+
+'unchanging'
+     In 'reg' and 'mem' expressions, 1 means that the value of the
+     expression never changes.
+
+     In 'subreg' expressions, it is 1 if the 'subreg' references an
+     unsigned object whose mode has been promoted to a wider mode.
+
+     In an 'insn' or 'jump_insn' in the delay slot of a branch
+     instruction, 1 means an annulling branch should be used.
+
+     In a 'symbol_ref' expression, 1 means that this symbol addresses
+     something in the per-function constant pool.
+
+     In a 'call_insn' 1 means that this instruction is a call to a const
+     function.
+
+     In an RTL dump, this flag is represented as '/u'.
+
+'used'
+     This flag is used directly (without an access macro) at the end of
+     RTL generation for a function, to count the number of times an
+     expression appears in insns.  Expressions that appear more than
+     once are copied, according to the rules for shared structure (*note
+     Sharing::).
+
+     For a 'reg', it is used directly (without an access macro) by the
+     leaf register renumbering code to ensure that each register is only
+     renumbered once.
+
+     In a 'symbol_ref', it indicates that an external declaration for
+     the symbol has already been written.
+
+'volatil'
+     In a 'mem', 'asm_operands', or 'asm_input' expression, it is 1 if
+     the memory reference is volatile.  Volatile memory references may
+     not be deleted, reordered or combined.
+
+     In a 'symbol_ref' expression, it is used for machine-specific
+     purposes.
+
+     In a 'reg' expression, it is 1 if the value is a user-level
+     variable.  0 indicates an internal compiler temporary.
+
+     In an 'insn', 1 means the insn has been deleted.
+
+     In 'label_ref' and 'reg_label' expressions, 1 means a reference to
+     a non-local label.
+
+     In 'prefetch' expressions, 1 means that the containing insn is a
+     scheduling barrier.
+
+     In an RTL dump, this flag is represented as '/v'.
+
+
+File: gccint.info,  Node: Machine Modes,  Next: Constants,  Prev: Flags,  Up: RTL
+
+13.6 Machine Modes
+==================
+
+A machine mode describes a size of data object and the representation
+used for it.  In the C code, machine modes are represented by an
+enumeration type, 'enum machine_mode', defined in 'machmode.def'.  Each
+RTL expression has room for a machine mode and so do certain kinds of
+tree expressions (declarations and types, to be precise).
+
+ In debugging dumps and machine descriptions, the machine mode of an RTL
+expression is written after the expression code with a colon to separate
+them.  The letters 'mode' which appear at the end of each machine mode
+name are omitted.  For example, '(reg:SI 38)' is a 'reg' expression with
+machine mode 'SImode'.  If the mode is 'VOIDmode', it is not written at
+all.
+
+ Here is a table of machine modes.  The term "byte" below refers to an
+object of 'BITS_PER_UNIT' bits (*note Storage Layout::).
+
+'BImode'
+     "Bit" mode represents a single bit, for predicate registers.
+
+'QImode'
+     "Quarter-Integer" mode represents a single byte treated as an
+     integer.
+
+'HImode'
+     "Half-Integer" mode represents a two-byte integer.
+
+'PSImode'
+     "Partial Single Integer" mode represents an integer which occupies
+     four bytes but which doesn't really use all four.  On some
+     machines, this is the right mode to use for pointers.
+
+'SImode'
+     "Single Integer" mode represents a four-byte integer.
+
+'PDImode'
+     "Partial Double Integer" mode represents an integer which occupies
+     eight bytes but which doesn't really use all eight.  On some
+     machines, this is the right mode to use for certain pointers.
+
+'DImode'
+     "Double Integer" mode represents an eight-byte integer.
+
+'TImode'
+     "Tetra Integer" (?)  mode represents a sixteen-byte integer.
+
+'OImode'
+     "Octa Integer" (?)  mode represents a thirty-two-byte integer.
+
+'XImode'
+     "Hexadeca Integer" (?)  mode represents a sixty-four-byte integer.
+
+'QFmode'
+     "Quarter-Floating" mode represents a quarter-precision (single
+     byte) floating point number.
+
+'HFmode'
+     "Half-Floating" mode represents a half-precision (two byte)
+     floating point number.
+
+'TQFmode'
+     "Three-Quarter-Floating" (?)  mode represents a
+     three-quarter-precision (three byte) floating point number.
+
+'SFmode'
+     "Single Floating" mode represents a four byte floating point
+     number.  In the common case, of a processor with IEEE arithmetic
+     and 8-bit bytes, this is a single-precision IEEE floating point
+     number; it can also be used for double-precision (on processors
+     with 16-bit bytes) and single-precision VAX and IBM types.
+
+'DFmode'
+     "Double Floating" mode represents an eight byte floating point
+     number.  In the common case, of a processor with IEEE arithmetic
+     and 8-bit bytes, this is a double-precision IEEE floating point
+     number.
+
+'XFmode'
+     "Extended Floating" mode represents an IEEE extended floating point
+     number.  This mode only has 80 meaningful bits (ten bytes).  Some
+     processors require such numbers to be padded to twelve bytes,
+     others to sixteen; this mode is used for either.
+
+'SDmode'
+     "Single Decimal Floating" mode represents a four byte decimal
+     floating point number (as distinct from conventional binary
+     floating point).
+
+'DDmode'
+     "Double Decimal Floating" mode represents an eight byte decimal
+     floating point number.
+
+'TDmode'
+     "Tetra Decimal Floating" mode represents a sixteen byte decimal
+     floating point number all 128 of whose bits are meaningful.
+
+'TFmode'
+     "Tetra Floating" mode represents a sixteen byte floating point
+     number all 128 of whose bits are meaningful.  One common use is the
+     IEEE quad-precision format.
+
+'QQmode'
+     "Quarter-Fractional" mode represents a single byte treated as a
+     signed fractional number.  The default format is "s.7".
+
+'HQmode'
+     "Half-Fractional" mode represents a two-byte signed fractional
+     number.  The default format is "s.15".
+
+'SQmode'
+     "Single Fractional" mode represents a four-byte signed fractional
+     number.  The default format is "s.31".
+
+'DQmode'
+     "Double Fractional" mode represents an eight-byte signed fractional
+     number.  The default format is "s.63".
+
+'TQmode'
+     "Tetra Fractional" mode represents a sixteen-byte signed fractional
+     number.  The default format is "s.127".
+
+'UQQmode'
+     "Unsigned Quarter-Fractional" mode represents a single byte treated
+     as an unsigned fractional number.  The default format is ".8".
+
+'UHQmode'
+     "Unsigned Half-Fractional" mode represents a two-byte unsigned
+     fractional number.  The default format is ".16".
+
+'USQmode'
+     "Unsigned Single Fractional" mode represents a four-byte unsigned
+     fractional number.  The default format is ".32".
+
+'UDQmode'
+     "Unsigned Double Fractional" mode represents an eight-byte unsigned
+     fractional number.  The default format is ".64".
+
+'UTQmode'
+     "Unsigned Tetra Fractional" mode represents a sixteen-byte unsigned
+     fractional number.  The default format is ".128".
+
+'HAmode'
+     "Half-Accumulator" mode represents a two-byte signed accumulator.
+     The default format is "s8.7".
+
+'SAmode'
+     "Single Accumulator" mode represents a four-byte signed
+     accumulator.  The default format is "s16.15".
+
+'DAmode'
+     "Double Accumulator" mode represents an eight-byte signed
+     accumulator.  The default format is "s32.31".
+
+'TAmode'
+     "Tetra Accumulator" mode represents a sixteen-byte signed
+     accumulator.  The default format is "s64.63".
+
+'UHAmode'
+     "Unsigned Half-Accumulator" mode represents a two-byte unsigned
+     accumulator.  The default format is "8.8".
+
+'USAmode'
+     "Unsigned Single Accumulator" mode represents a four-byte unsigned
+     accumulator.  The default format is "16.16".
+
+'UDAmode'
+     "Unsigned Double Accumulator" mode represents an eight-byte
+     unsigned accumulator.  The default format is "32.32".
+
+'UTAmode'
+     "Unsigned Tetra Accumulator" mode represents a sixteen-byte
+     unsigned accumulator.  The default format is "64.64".
+
+'CCmode'
+     "Condition Code" mode represents the value of a condition code,
+     which is a machine-specific set of bits used to represent the
+     result of a comparison operation.  Other machine-specific modes may
+     also be used for the condition code.  These modes are not used on
+     machines that use 'cc0' (*note Condition Code::).
+
+'BLKmode'
+     "Block" mode represents values that are aggregates to which none of
+     the other modes apply.  In RTL, only memory references can have
+     this mode, and only if they appear in string-move or vector
+     instructions.  On machines which have no such instructions,
+     'BLKmode' will not appear in RTL.
+
+'VOIDmode'
+     Void mode means the absence of a mode or an unspecified mode.  For
+     example, RTL expressions of code 'const_int' have mode 'VOIDmode'
+     because they can be taken to have whatever mode the context
+     requires.  In debugging dumps of RTL, 'VOIDmode' is expressed by
+     the absence of any mode.
+
+'QCmode, HCmode, SCmode, DCmode, XCmode, TCmode'
+     These modes stand for a complex number represented as a pair of
+     floating point values.  The floating point values are in 'QFmode',
+     'HFmode', 'SFmode', 'DFmode', 'XFmode', and 'TFmode', respectively.
+
+'CQImode, CHImode, CSImode, CDImode, CTImode, COImode'
+     These modes stand for a complex number represented as a pair of
+     integer values.  The integer values are in 'QImode', 'HImode',
+     'SImode', 'DImode', 'TImode', and 'OImode', respectively.
+
+ The machine description defines 'Pmode' as a C macro which expands into
+the machine mode used for addresses.  Normally this is the mode whose
+size is 'BITS_PER_WORD', 'SImode' on 32-bit machines.
+
+ The only modes which a machine description must support are 'QImode',
+and the modes corresponding to 'BITS_PER_WORD', 'FLOAT_TYPE_SIZE' and
+'DOUBLE_TYPE_SIZE'.  The compiler will attempt to use 'DImode' for
+8-byte structures and unions, but this can be prevented by overriding
+the definition of 'MAX_FIXED_MODE_SIZE'.  Alternatively, you can have
+the compiler use 'TImode' for 16-byte structures and unions.  Likewise,
+you can arrange for the C type 'short int' to avoid using 'HImode'.
+
+ Very few explicit references to machine modes remain in the compiler
+and these few references will soon be removed.  Instead, the machine
+modes are divided into mode classes.  These are represented by the
+enumeration type 'enum mode_class' defined in 'machmode.h'.  The
+possible mode classes are:
+
+'MODE_INT'
+     Integer modes.  By default these are 'BImode', 'QImode', 'HImode',
+     'SImode', 'DImode', 'TImode', and 'OImode'.
+
+'MODE_PARTIAL_INT'
+     The "partial integer" modes, 'PQImode', 'PHImode', 'PSImode' and
+     'PDImode'.
+
+'MODE_FLOAT'
+     Floating point modes.  By default these are 'QFmode', 'HFmode',
+     'TQFmode', 'SFmode', 'DFmode', 'XFmode' and 'TFmode'.
+
+'MODE_DECIMAL_FLOAT'
+     Decimal floating point modes.  By default these are 'SDmode',
+     'DDmode' and 'TDmode'.
+
+'MODE_FRACT'
+     Signed fractional modes.  By default these are 'QQmode', 'HQmode',
+     'SQmode', 'DQmode' and 'TQmode'.
+
+'MODE_UFRACT'
+     Unsigned fractional modes.  By default these are 'UQQmode',
+     'UHQmode', 'USQmode', 'UDQmode' and 'UTQmode'.
+
+'MODE_ACCUM'
+     Signed accumulator modes.  By default these are 'HAmode', 'SAmode',
+     'DAmode' and 'TAmode'.
+
+'MODE_UACCUM'
+     Unsigned accumulator modes.  By default these are 'UHAmode',
+     'USAmode', 'UDAmode' and 'UTAmode'.
+
+'MODE_COMPLEX_INT'
+     Complex integer modes.  (These are not currently implemented).
+
+'MODE_COMPLEX_FLOAT'
+     Complex floating point modes.  By default these are 'QCmode',
+     'HCmode', 'SCmode', 'DCmode', 'XCmode', and 'TCmode'.
+
+'MODE_FUNCTION'
+     Algol or Pascal function variables including a static chain.
+     (These are not currently implemented).
+
+'MODE_CC'
+     Modes representing condition code values.  These are 'CCmode' plus
+     any 'CC_MODE' modes listed in the 'MACHINE-modes.def'.  *Note Jump
+     Patterns::, also see *note Condition Code::.
+
+'MODE_RANDOM'
+     This is a catchall mode class for modes which don't fit into the
+     above classes.  Currently 'VOIDmode' and 'BLKmode' are in
+     'MODE_RANDOM'.
+
+ Here are some C macros that relate to machine modes:
+
+'GET_MODE (X)'
+     Returns the machine mode of the RTX X.
+
+'PUT_MODE (X, NEWMODE)'
+     Alters the machine mode of the RTX X to be NEWMODE.
+
+'NUM_MACHINE_MODES'
+     Stands for the number of machine modes available on the target
+     machine.  This is one greater than the largest numeric value of any
+     machine mode.
+
+'GET_MODE_NAME (M)'
+     Returns the name of mode M as a string.
+
+'GET_MODE_CLASS (M)'
+     Returns the mode class of mode M.
+
+'GET_MODE_WIDER_MODE (M)'
+     Returns the next wider natural mode.  For example, the expression
+     'GET_MODE_WIDER_MODE (QImode)' returns 'HImode'.
+
+'GET_MODE_SIZE (M)'
+     Returns the size in bytes of a datum of mode M.
+
+'GET_MODE_BITSIZE (M)'
+     Returns the size in bits of a datum of mode M.
+
+'GET_MODE_IBIT (M)'
+     Returns the number of integral bits of a datum of fixed-point mode
+     M.
+
+'GET_MODE_FBIT (M)'
+     Returns the number of fractional bits of a datum of fixed-point
+     mode M.
+
+'GET_MODE_MASK (M)'
+     Returns a bitmask containing 1 for all bits in a word that fit
+     within mode M.  This macro can only be used for modes whose bitsize
+     is less than or equal to 'HOST_BITS_PER_INT'.
+
+'GET_MODE_ALIGNMENT (M)'
+     Return the required alignment, in bits, for an object of mode M.
+
+'GET_MODE_UNIT_SIZE (M)'
+     Returns the size in bytes of the subunits of a datum of mode M.
+     This is the same as 'GET_MODE_SIZE' except in the case of complex
+     modes.  For them, the unit size is the size of the real or
+     imaginary part.
+
+'GET_MODE_NUNITS (M)'
+     Returns the number of units contained in a mode, i.e.,
+     'GET_MODE_SIZE' divided by 'GET_MODE_UNIT_SIZE'.
+
+'GET_CLASS_NARROWEST_MODE (C)'
+     Returns the narrowest mode in mode class C.
+
+ The following 3 variables are defined on every target.  They can be
+used to allocate buffers that are guaranteed to be large enough to hold
+any value that can be represented on the target.  The first two can be
+overridden by defining them in the target's mode.def file, however, the
+value must be a constant that can determined very early in the
+compilation process.  The third symbol cannot be overridden.
+
+'BITS_PER_UNIT'
+     The number of bits in an addressable storage unit (byte).  If you
+     do not define this, the default is 8.
+
+'MAX_BITSIZE_MODE_ANY_INT'
+     The maximum bitsize of any mode that is used in integer math.  This
+     should be overridden by the target if it uses large integers as
+     containers for larger vectors but otherwise never uses the contents
+     to compute integer values.
+
+'MAX_BITSIZE_MODE_ANY_MODE'
+     The bitsize of the largest mode on the target.
+
+ The global variables 'byte_mode' and 'word_mode' contain modes whose
+classes are 'MODE_INT' and whose bitsizes are either 'BITS_PER_UNIT' or
+'BITS_PER_WORD', respectively.  On 32-bit machines, these are 'QImode'
+and 'SImode', respectively.
+
+
+File: gccint.info,  Node: Constants,  Next: Regs and Memory,  Prev: Machine Modes,  Up: RTL
+
+13.7 Constant Expression Types
+==============================
+
+The simplest RTL expressions are those that represent constant values.
+
+'(const_int I)'
+     This type of expression represents the integer value I.  I is
+     customarily accessed with the macro 'INTVAL' as in 'INTVAL (EXP)',
+     which is equivalent to 'XWINT (EXP, 0)'.
+
+     Constants generated for modes with fewer bits than in
+     'HOST_WIDE_INT' must be sign extended to full width (e.g., with
+     'gen_int_mode').  For constants for modes with more bits than in
+     'HOST_WIDE_INT' the implied high order bits of that constant are
+     copies of the top bit.  Note however that values are neither
+     inherently signed nor inherently unsigned; where necessary,
+     signedness is determined by the rtl operation instead.
+
+     There is only one expression object for the integer value zero; it
+     is the value of the variable 'const0_rtx'.  Likewise, the only
+     expression for integer value one is found in 'const1_rtx', the only
+     expression for integer value two is found in 'const2_rtx', and the
+     only expression for integer value negative one is found in
+     'constm1_rtx'.  Any attempt to create an expression of code
+     'const_int' and value zero, one, two or negative one will return
+     'const0_rtx', 'const1_rtx', 'const2_rtx' or 'constm1_rtx' as
+     appropriate.
+
+     Similarly, there is only one object for the integer whose value is
+     'STORE_FLAG_VALUE'.  It is found in 'const_true_rtx'.  If
+     'STORE_FLAG_VALUE' is one, 'const_true_rtx' and 'const1_rtx' will
+     point to the same object.  If 'STORE_FLAG_VALUE' is -1,
+     'const_true_rtx' and 'constm1_rtx' will point to the same object.
+
+'(const_double:M I0 I1 ...)'
+     Represents either a floating-point constant of mode M or an integer
+     constant too large to fit into 'HOST_BITS_PER_WIDE_INT' bits but
+     small enough to fit within twice that number of bits (GCC does not
+     provide a mechanism to represent even larger constants).  In the
+     latter case, M will be 'VOIDmode'.  For integral values constants
+     for modes with more bits than twice the number in 'HOST_WIDE_INT'
+     the implied high order bits of that constant are copies of the top
+     bit of 'CONST_DOUBLE_HIGH'.  Note however that integral values are
+     neither inherently signed nor inherently unsigned; where necessary,
+     signedness is determined by the rtl operation instead.
+
+     If M is 'VOIDmode', the bits of the value are stored in I0 and I1.
+     I0 is customarily accessed with the macro 'CONST_DOUBLE_LOW' and I1
+     with 'CONST_DOUBLE_HIGH'.
+
+     If the constant is floating point (regardless of its precision),
+     then the number of integers used to store the value depends on the
+     size of 'REAL_VALUE_TYPE' (*note Floating Point::).  The integers
+     represent a floating point number, but not precisely in the target
+     machine's or host machine's floating point format.  To convert them
+     to the precise bit pattern used by the target machine, use the
+     macro 'REAL_VALUE_TO_TARGET_DOUBLE' and friends (*note Data
+     Output::).
+
+'(const_fixed:M ...)'
+     Represents a fixed-point constant of mode M.  The operand is a data
+     structure of type 'struct fixed_value' and is accessed with the
+     macro 'CONST_FIXED_VALUE'.  The high part of data is accessed with
+     'CONST_FIXED_VALUE_HIGH'; the low part is accessed with
+     'CONST_FIXED_VALUE_LOW'.
+
+'(const_vector:M [X0 X1 ...])'
+     Represents a vector constant.  The square brackets stand for the
+     vector containing the constant elements.  X0, X1 and so on are the
+     'const_int', 'const_double' or 'const_fixed' elements.
+
+     The number of units in a 'const_vector' is obtained with the macro
+     'CONST_VECTOR_NUNITS' as in 'CONST_VECTOR_NUNITS (V)'.
+
+     Individual elements in a vector constant are accessed with the
+     macro 'CONST_VECTOR_ELT' as in 'CONST_VECTOR_ELT (V, N)' where V is
+     the vector constant and N is the element desired.
+
+'(const_string STR)'
+     Represents a constant string with value STR.  Currently this is
+     used only for insn attributes (*note Insn Attributes::) since
+     constant strings in C are placed in memory.
+
+'(symbol_ref:MODE SYMBOL)'
+     Represents the value of an assembler label for data.  SYMBOL is a
+     string that describes the name of the assembler label.  If it
+     starts with a '*', the label is the rest of SYMBOL not including
+     the '*'.  Otherwise, the label is SYMBOL, usually prefixed with
+     '_'.
+
+     The 'symbol_ref' contains a mode, which is usually 'Pmode'.
+     Usually that is the only mode for which a symbol is directly valid.
+
+'(label_ref:MODE LABEL)'
+     Represents the value of an assembler label for code.  It contains
+     one operand, an expression, which must be a 'code_label' or a
+     'note' of type 'NOTE_INSN_DELETED_LABEL' that appears in the
+     instruction sequence to identify the place where the label should
+     go.
+
+     The reason for using a distinct expression type for code label
+     references is so that jump optimization can distinguish them.
+
+     The 'label_ref' contains a mode, which is usually 'Pmode'.  Usually
+     that is the only mode for which a label is directly valid.
+
+'(const:M EXP)'
+     Represents a constant that is the result of an assembly-time
+     arithmetic computation.  The operand, EXP, is an expression that
+     contains only constants ('const_int', 'symbol_ref' and 'label_ref'
+     expressions) combined with 'plus' and 'minus'.  However, not all
+     combinations are valid, since the assembler cannot do arbitrary
+     arithmetic on relocatable symbols.
+
+     M should be 'Pmode'.
+
+'(high:M EXP)'
+     Represents the high-order bits of EXP, usually a 'symbol_ref'.  The
+     number of bits is machine-dependent and is normally the number of
+     bits specified in an instruction that initializes the high order
+     bits of a register.  It is used with 'lo_sum' to represent the
+     typical two-instruction sequence used in RISC machines to reference
+     a global memory location.
+
+     M should be 'Pmode'.
+
+ The macro 'CONST0_RTX (MODE)' refers to an expression with value 0 in
+mode MODE.  If mode MODE is of mode class 'MODE_INT', it returns
+'const0_rtx'.  If mode MODE is of mode class 'MODE_FLOAT', it returns a
+'CONST_DOUBLE' expression in mode MODE.  Otherwise, it returns a
+'CONST_VECTOR' expression in mode MODE.  Similarly, the macro
+'CONST1_RTX (MODE)' refers to an expression with value 1 in mode MODE
+and similarly for 'CONST2_RTX'.  The 'CONST1_RTX' and 'CONST2_RTX'
+macros are undefined for vector modes.
+
+
+File: gccint.info,  Node: Regs and Memory,  Next: Arithmetic,  Prev: Constants,  Up: RTL
+
+13.8 Registers and Memory
+=========================
+
+Here are the RTL expression types for describing access to machine
+registers and to main memory.
+
+'(reg:M N)'
+     For small values of the integer N (those that are less than
+     'FIRST_PSEUDO_REGISTER'), this stands for a reference to machine
+     register number N: a "hard register".  For larger values of N, it
+     stands for a temporary value or "pseudo register".  The compiler's
+     strategy is to generate code assuming an unlimited number of such
+     pseudo registers, and later convert them into hard registers or
+     into memory references.
+
+     M is the machine mode of the reference.  It is necessary because
+     machines can generally refer to each register in more than one
+     mode.  For example, a register may contain a full word but there
+     may be instructions to refer to it as a half word or as a single
+     byte, as well as instructions to refer to it as a floating point
+     number of various precisions.
+
+     Even for a register that the machine can access in only one mode,
+     the mode must always be specified.
+
+     The symbol 'FIRST_PSEUDO_REGISTER' is defined by the machine
+     description, since the number of hard registers on the machine is
+     an invariant characteristic of the machine.  Note, however, that
+     not all of the machine registers must be general registers.  All
+     the machine registers that can be used for storage of data are
+     given hard register numbers, even those that can be used only in
+     certain instructions or can hold only certain types of data.
+
+     A hard register may be accessed in various modes throughout one
+     function, but each pseudo register is given a natural mode and is
+     accessed only in that mode.  When it is necessary to describe an
+     access to a pseudo register using a nonnatural mode, a 'subreg'
+     expression is used.
+
+     A 'reg' expression with a machine mode that specifies more than one
+     word of data may actually stand for several consecutive registers.
+     If in addition the register number specifies a hardware register,
+     then it actually represents several consecutive hardware registers
+     starting with the specified one.
+
+     Each pseudo register number used in a function's RTL code is
+     represented by a unique 'reg' expression.
+
+     Some pseudo register numbers, those within the range of
+     'FIRST_VIRTUAL_REGISTER' to 'LAST_VIRTUAL_REGISTER' only appear
+     during the RTL generation phase and are eliminated before the
+     optimization phases.  These represent locations in the stack frame
+     that cannot be determined until RTL generation for the function has
+     been completed.  The following virtual register numbers are
+     defined:
+
+     'VIRTUAL_INCOMING_ARGS_REGNUM'
+          This points to the first word of the incoming arguments passed
+          on the stack.  Normally these arguments are placed there by
+          the caller, but the callee may have pushed some arguments that
+          were previously passed in registers.
+
+          When RTL generation is complete, this virtual register is
+          replaced by the sum of the register given by
+          'ARG_POINTER_REGNUM' and the value of 'FIRST_PARM_OFFSET'.
+
+     'VIRTUAL_STACK_VARS_REGNUM'
+          If 'FRAME_GROWS_DOWNWARD' is defined to a nonzero value, this
+          points to immediately above the first variable on the stack.
+          Otherwise, it points to the first variable on the stack.
+
+          'VIRTUAL_STACK_VARS_REGNUM' is replaced with the sum of the
+          register given by 'FRAME_POINTER_REGNUM' and the value
+          'STARTING_FRAME_OFFSET'.
+
+     'VIRTUAL_STACK_DYNAMIC_REGNUM'
+          This points to the location of dynamically allocated memory on
+          the stack immediately after the stack pointer has been
+          adjusted by the amount of memory desired.
+
+          This virtual register is replaced by the sum of the register
+          given by 'STACK_POINTER_REGNUM' and the value
+          'STACK_DYNAMIC_OFFSET'.
+
+     'VIRTUAL_OUTGOING_ARGS_REGNUM'
+          This points to the location in the stack at which outgoing
+          arguments should be written when the stack is pre-pushed
+          (arguments pushed using push insns should always use
+          'STACK_POINTER_REGNUM').
+
+          This virtual register is replaced by the sum of the register
+          given by 'STACK_POINTER_REGNUM' and the value
+          'STACK_POINTER_OFFSET'.
+
+'(subreg:M1 REG:M2 BYTENUM)'
+
+     'subreg' expressions are used to refer to a register in a machine
+     mode other than its natural one, or to refer to one register of a
+     multi-part 'reg' that actually refers to several registers.
+
+     Each pseudo register has a natural mode.  If it is necessary to
+     operate on it in a different mode, the register must be enclosed in
+     a 'subreg'.
+
+     There are currently three supported types for the first operand of
+     a 'subreg':
+        * pseudo registers This is the most common case.  Most 'subreg's
+          have pseudo 'reg's as their first operand.
+
+        * mem 'subreg's of 'mem' were common in earlier versions of GCC
+          and are still supported.  During the reload pass these are
+          replaced by plain 'mem's.  On machines that do not do
+          instruction scheduling, use of 'subreg's of 'mem' are still
+          used, but this is no longer recommended.  Such 'subreg's are
+          considered to be 'register_operand's rather than
+          'memory_operand's before and during reload.  Because of this,
+          the scheduling passes cannot properly schedule instructions
+          with 'subreg's of 'mem', so for machines that do scheduling,
+          'subreg's of 'mem' should never be used.  To support this, the
+          combine and recog passes have explicit code to inhibit the
+          creation of 'subreg's of 'mem' when 'INSN_SCHEDULING' is
+          defined.
+
+          The use of 'subreg's of 'mem' after the reload pass is an area
+          that is not well understood and should be avoided.  There is
+          still some code in the compiler to support this, but this code
+          has possibly rotted.  This use of 'subreg's is discouraged and
+          will most likely not be supported in the future.
+
+        * hard registers It is seldom necessary to wrap hard registers
+          in 'subreg's; such registers would normally reduce to a single
+          'reg' rtx.  This use of 'subreg's is discouraged and may not
+          be supported in the future.
+
+     'subreg's of 'subreg's are not supported.  Using
+     'simplify_gen_subreg' is the recommended way to avoid this problem.
+
+     'subreg's come in two distinct flavors, each having its own usage
+     and rules:
+
+     Paradoxical subregs
+          When M1 is strictly wider than M2, the 'subreg' expression is
+          called "paradoxical".  The canonical test for this class of
+          'subreg' is:
+
+               GET_MODE_SIZE (M1) > GET_MODE_SIZE (M2)
+
+          Paradoxical 'subreg's can be used as both lvalues and rvalues.
+          When used as an lvalue, the low-order bits of the source value
+          are stored in REG and the high-order bits are discarded.  When
+          used as an rvalue, the low-order bits of the 'subreg' are
+          taken from REG while the high-order bits may or may not be
+          defined.
+
+          The high-order bits of rvalues are in the following
+          circumstances:
+
+             * 'subreg's of 'mem' When M2 is smaller than a word, the
+               macro 'LOAD_EXTEND_OP', can control how the high-order
+               bits are defined.
+
+             * 'subreg' of 'reg's The upper bits are defined when
+               'SUBREG_PROMOTED_VAR_P' is true.
+               'SUBREG_PROMOTED_UNSIGNED_P' describes what the upper
+               bits hold.  Such subregs usually represent local
+               variables, register variables and parameter pseudo
+               variables that have been promoted to a wider mode.
+
+          BYTENUM is always zero for a paradoxical 'subreg', even on
+          big-endian targets.
+
+          For example, the paradoxical 'subreg':
+
+               (set (subreg:SI (reg:HI X) 0) Y)
+
+          stores the lower 2 bytes of Y in X and discards the upper 2
+          bytes.  A subsequent:
+
+               (set Z (subreg:SI (reg:HI X) 0))
+
+          would set the lower two bytes of Z to Y and set the upper two
+          bytes to an unknown value assuming 'SUBREG_PROMOTED_VAR_P' is
+          false.
+
+     Normal subregs
+          When M1 is at least as narrow as M2 the 'subreg' expression is
+          called "normal".
+
+          Normal 'subreg's restrict consideration to certain bits of
+          REG.  There are two cases.  If M1 is smaller than a word, the
+          'subreg' refers to the least-significant part (or "lowpart")
+          of one word of REG.  If M1 is word-sized or greater, the
+          'subreg' refers to one or more complete words.
+
+          When used as an lvalue, 'subreg' is a word-based accessor.
+          Storing to a 'subreg' modifies all the words of REG that
+          overlap the 'subreg', but it leaves the other words of REG
+          alone.
+
+          When storing to a normal 'subreg' that is smaller than a word,
+          the other bits of the referenced word are usually left in an
+          undefined state.  This laxity makes it easier to generate
+          efficient code for such instructions.  To represent an
+          instruction that preserves all the bits outside of those in
+          the 'subreg', use 'strict_low_part' or 'zero_extract' around
+          the 'subreg'.
+
+          BYTENUM must identify the offset of the first byte of the
+          'subreg' from the start of REG, assuming that REG is laid out
+          in memory order.  The memory order of bytes is defined by two
+          target macros, 'WORDS_BIG_ENDIAN' and 'BYTES_BIG_ENDIAN':
+
+             * 'WORDS_BIG_ENDIAN', if set to 1, says that byte number
+               zero is part of the most significant word; otherwise, it
+               is part of the least significant word.
+
+             * 'BYTES_BIG_ENDIAN', if set to 1, says that byte number
+               zero is the most significant byte within a word;
+               otherwise, it is the least significant byte within a
+               word.
+
+          On a few targets, 'FLOAT_WORDS_BIG_ENDIAN' disagrees with
+          'WORDS_BIG_ENDIAN'.  However, most parts of the compiler treat
+          floating point values as if they had the same endianness as
+          integer values.  This works because they handle them solely as
+          a collection of integer values, with no particular numerical
+          value.  Only real.c and the runtime libraries care about
+          'FLOAT_WORDS_BIG_ENDIAN'.
+
+          Thus,
+
+               (subreg:HI (reg:SI X) 2)
+
+          on a 'BYTES_BIG_ENDIAN', 'UNITS_PER_WORD == 4' target is the
+          same as
+
+               (subreg:HI (reg:SI X) 0)
+
+          on a little-endian, 'UNITS_PER_WORD == 4' target.  Both
+          'subreg's access the lower two bytes of register X.
+
+     A 'MODE_PARTIAL_INT' mode behaves as if it were as wide as the
+     corresponding 'MODE_INT' mode, except that it has an unknown number
+     of undefined bits.  For example:
+
+          (subreg:PSI (reg:SI 0) 0)
+
+     accesses the whole of '(reg:SI 0)', but the exact relationship
+     between the 'PSImode' value and the 'SImode' value is not defined.
+     If we assume 'UNITS_PER_WORD <= 4', then the following two
+     'subreg's:
+
+          (subreg:PSI (reg:DI 0) 0)
+          (subreg:PSI (reg:DI 0) 4)
+
+     represent independent 4-byte accesses to the two halves of '(reg:DI
+     0)'.  Both 'subreg's have an unknown number of undefined bits.
+
+     If 'UNITS_PER_WORD <= 2' then these two 'subreg's:
+
+          (subreg:HI (reg:PSI 0) 0)
+          (subreg:HI (reg:PSI 0) 2)
+
+     represent independent 2-byte accesses that together span the whole
+     of '(reg:PSI 0)'.  Storing to the first 'subreg' does not affect
+     the value of the second, and vice versa.  '(reg:PSI 0)' has an
+     unknown number of undefined bits, so the assignment:
+
+          (set (subreg:HI (reg:PSI 0) 0) (reg:HI 4))
+
+     does not guarantee that '(subreg:HI (reg:PSI 0) 0)' has the value
+     '(reg:HI 4)'.
+
+     The rules above apply to both pseudo REGs and hard REGs.  If the
+     semantics are not correct for particular combinations of M1, M2 and
+     hard REG, the target-specific code must ensure that those
+     combinations are never used.  For example:
+
+          CANNOT_CHANGE_MODE_CLASS (M2, M1, CLASS)
+
+     must be true for every class CLASS that includes REG.
+
+     The first operand of a 'subreg' expression is customarily accessed
+     with the 'SUBREG_REG' macro and the second operand is customarily
+     accessed with the 'SUBREG_BYTE' macro.
+
+     It has been several years since a platform in which
+     'BYTES_BIG_ENDIAN' not equal to 'WORDS_BIG_ENDIAN' has been tested.
+     Anyone wishing to support such a platform in the future may be
+     confronted with code rot.
+
+'(scratch:M)'
+     This represents a scratch register that will be required for the
+     execution of a single instruction and not used subsequently.  It is
+     converted into a 'reg' by either the local register allocator or
+     the reload pass.
+
+     'scratch' is usually present inside a 'clobber' operation (*note
+     Side Effects::).
+
+'(cc0)'
+     This refers to the machine's condition code register.  It has no
+     operands and may not have a machine mode.  There are two ways to
+     use it:
+
+        * To stand for a complete set of condition code flags.  This is
+          best on most machines, where each comparison sets the entire
+          series of flags.
+
+          With this technique, '(cc0)' may be validly used in only two
+          contexts: as the destination of an assignment (in test and
+          compare instructions) and in comparison operators comparing
+          against zero ('const_int' with value zero; that is to say,
+          'const0_rtx').
+
+        * To stand for a single flag that is the result of a single
+          condition.  This is useful on machines that have only a single
+          flag bit, and in which comparison instructions must specify
+          the condition to test.
+
+          With this technique, '(cc0)' may be validly used in only two
+          contexts: as the destination of an assignment (in test and
+          compare instructions) where the source is a comparison
+          operator, and as the first operand of 'if_then_else' (in a
+          conditional branch).
+
+     There is only one expression object of code 'cc0'; it is the value
+     of the variable 'cc0_rtx'.  Any attempt to create an expression of
+     code 'cc0' will return 'cc0_rtx'.
+
+     Instructions can set the condition code implicitly.  On many
+     machines, nearly all instructions set the condition code based on
+     the value that they compute or store.  It is not necessary to
+     record these actions explicitly in the RTL because the machine
+     description includes a prescription for recognizing the
+     instructions that do so (by means of the macro 'NOTICE_UPDATE_CC').
+     *Note Condition Code::.  Only instructions whose sole purpose is to
+     set the condition code, and instructions that use the condition
+     code, need mention '(cc0)'.
+
+     On some machines, the condition code register is given a register
+     number and a 'reg' is used instead of '(cc0)'.  This is usually the
+     preferable approach if only a small subset of instructions modify
+     the condition code.  Other machines store condition codes in
+     general registers; in such cases a pseudo register should be used.
+
+     Some machines, such as the SPARC and RS/6000, have two sets of
+     arithmetic instructions, one that sets and one that does not set
+     the condition code.  This is best handled by normally generating
+     the instruction that does not set the condition code, and making a
+     pattern that both performs the arithmetic and sets the condition
+     code register (which would not be '(cc0)' in this case).  For
+     examples, search for 'addcc' and 'andcc' in 'sparc.md'.
+
+'(pc)'
+     This represents the machine's program counter.  It has no operands
+     and may not have a machine mode.  '(pc)' may be validly used only
+     in certain specific contexts in jump instructions.
+
+     There is only one expression object of code 'pc'; it is the value
+     of the variable 'pc_rtx'.  Any attempt to create an expression of
+     code 'pc' will return 'pc_rtx'.
+
+     All instructions that do not jump alter the program counter
+     implicitly by incrementing it, but there is no need to mention this
+     in the RTL.
+
+'(mem:M ADDR ALIAS)'
+     This RTX represents a reference to main memory at an address
+     represented by the expression ADDR.  M specifies how large a unit
+     of memory is accessed.  ALIAS specifies an alias set for the
+     reference.  In general two items are in different alias sets if
+     they cannot reference the same memory address.
+
+     The construct '(mem:BLK (scratch))' is considered to alias all
+     other memories.  Thus it may be used as a memory barrier in
+     epilogue stack deallocation patterns.
+
+'(concatM RTX RTX)'
+     This RTX represents the concatenation of two other RTXs.  This is
+     used for complex values.  It should only appear in the RTL attached
+     to declarations and during RTL generation.  It should not appear in
+     the ordinary insn chain.
+
+'(concatnM [RTX ...])'
+     This RTX represents the concatenation of all the RTX to make a
+     single value.  Like 'concat', this should only appear in
+     declarations, and not in the insn chain.
+
+
+File: gccint.info,  Node: Arithmetic,  Next: Comparisons,  Prev: Regs and Memory,  Up: RTL
+
+13.9 RTL Expressions for Arithmetic
+===================================
+
+Unless otherwise specified, all the operands of arithmetic expressions
+must be valid for mode M.  An operand is valid for mode M if it has mode
+M, or if it is a 'const_int' or 'const_double' and M is a mode of class
+'MODE_INT'.
+
+ For commutative binary operations, constants should be placed in the
+second operand.
+
+'(plus:M X Y)'
+'(ss_plus:M X Y)'
+'(us_plus:M X Y)'
+
+     These three expressions all represent the sum of the values
+     represented by X and Y carried out in machine mode M.  They differ
+     in their behavior on overflow of integer modes.  'plus' wraps round
+     modulo the width of M; 'ss_plus' saturates at the maximum signed
+     value representable in M; 'us_plus' saturates at the maximum
+     unsigned value.
+
+'(lo_sum:M X Y)'
+
+     This expression represents the sum of X and the low-order bits of
+     Y.  It is used with 'high' (*note Constants::) to represent the
+     typical two-instruction sequence used in RISC machines to reference
+     a global memory location.
+
+     The number of low order bits is machine-dependent but is normally
+     the number of bits in a 'Pmode' item minus the number of bits set
+     by 'high'.
+
+     M should be 'Pmode'.
+
+'(minus:M X Y)'
+'(ss_minus:M X Y)'
+'(us_minus:M X Y)'
+
+     These three expressions represent the result of subtracting Y from
+     X, carried out in mode M.  Behavior on overflow is the same as for
+     the three variants of 'plus' (see above).
+
+'(compare:M X Y)'
+     Represents the result of subtracting Y from X for purposes of
+     comparison.  The result is computed without overflow, as if with
+     infinite precision.
+
+     Of course, machines can't really subtract with infinite precision.
+     However, they can pretend to do so when only the sign of the result
+     will be used, which is the case when the result is stored in the
+     condition code.  And that is the _only_ way this kind of expression
+     may validly be used: as a value to be stored in the condition
+     codes, either '(cc0)' or a register.  *Note Comparisons::.
+
+     The mode M is not related to the modes of X and Y, but instead is
+     the mode of the condition code value.  If '(cc0)' is used, it is
+     'VOIDmode'.  Otherwise it is some mode in class 'MODE_CC', often
+     'CCmode'.  *Note Condition Code::.  If M is 'VOIDmode' or 'CCmode',
+     the operation returns sufficient information (in an unspecified
+     format) so that any comparison operator can be applied to the
+     result of the 'COMPARE' operation.  For other modes in class
+     'MODE_CC', the operation only returns a subset of this information.
+
+     Normally, X and Y must have the same mode.  Otherwise, 'compare' is
+     valid only if the mode of X is in class 'MODE_INT' and Y is a
+     'const_int' or 'const_double' with mode 'VOIDmode'.  The mode of X
+     determines what mode the comparison is to be done in; thus it must
+     not be 'VOIDmode'.
+
+     If one of the operands is a constant, it should be placed in the
+     second operand and the comparison code adjusted as appropriate.
+
+     A 'compare' specifying two 'VOIDmode' constants is not valid since
+     there is no way to know in what mode the comparison is to be
+     performed; the comparison must either be folded during the
+     compilation or the first operand must be loaded into a register
+     while its mode is still known.
+
+'(neg:M X)'
+'(ss_neg:M X)'
+'(us_neg:M X)'
+     These two expressions represent the negation (subtraction from
+     zero) of the value represented by X, carried out in mode M.  They
+     differ in the behavior on overflow of integer modes.  In the case
+     of 'neg', the negation of the operand may be a number not
+     representable in mode M, in which case it is truncated to M.
+     'ss_neg' and 'us_neg' ensure that an out-of-bounds result saturates
+     to the maximum or minimum signed or unsigned value.
+
+'(mult:M X Y)'
+'(ss_mult:M X Y)'
+'(us_mult:M X Y)'
+     Represents the signed product of the values represented by X and Y
+     carried out in machine mode M.  'ss_mult' and 'us_mult' ensure that
+     an out-of-bounds result saturates to the maximum or minimum signed
+     or unsigned value.
+
+     Some machines support a multiplication that generates a product
+     wider than the operands.  Write the pattern for this as
+
+          (mult:M (sign_extend:M X) (sign_extend:M Y))
+
+     where M is wider than the modes of X and Y, which need not be the
+     same.
+
+     For unsigned widening multiplication, use the same idiom, but with
+     'zero_extend' instead of 'sign_extend'.
+
+'(fma:M X Y Z)'
+     Represents the 'fma', 'fmaf', and 'fmal' builtin functions that do
+     a combined multiply of X and Y and then adding toZ without doing an
+     intermediate rounding step.
+
+'(div:M X Y)'
+'(ss_div:M X Y)'
+     Represents the quotient in signed division of X by Y, carried out
+     in machine mode M.  If M is a floating point mode, it represents
+     the exact quotient; otherwise, the integerized quotient.  'ss_div'
+     ensures that an out-of-bounds result saturates to the maximum or
+     minimum signed value.
+
+     Some machines have division instructions in which the operands and
+     quotient widths are not all the same; you should represent such
+     instructions using 'truncate' and 'sign_extend' as in,
+
+          (truncate:M1 (div:M2 X (sign_extend:M2 Y)))
+
+'(udiv:M X Y)'
+'(us_div:M X Y)'
+     Like 'div' but represents unsigned division.  'us_div' ensures that
+     an out-of-bounds result saturates to the maximum or minimum
+     unsigned value.
+
+'(mod:M X Y)'
+'(umod:M X Y)'
+     Like 'div' and 'udiv' but represent the remainder instead of the
+     quotient.
+
+'(smin:M X Y)'
+'(smax:M X Y)'
+     Represents the smaller (for 'smin') or larger (for 'smax') of X and
+     Y, interpreted as signed values in mode M.  When used with floating
+     point, if both operands are zeros, or if either operand is 'NaN',
+     then it is unspecified which of the two operands is returned as the
+     result.
+
+'(umin:M X Y)'
+'(umax:M X Y)'
+     Like 'smin' and 'smax', but the values are interpreted as unsigned
+     integers.
+
+'(not:M X)'
+     Represents the bitwise complement of the value represented by X,
+     carried out in mode M, which must be a fixed-point machine mode.
+
+'(and:M X Y)'
+     Represents the bitwise logical-and of the values represented by X
+     and Y, carried out in machine mode M, which must be a fixed-point
+     machine mode.
+
+'(ior:M X Y)'
+     Represents the bitwise inclusive-or of the values represented by X
+     and Y, carried out in machine mode M, which must be a fixed-point
+     mode.
+
+'(xor:M X Y)'
+     Represents the bitwise exclusive-or of the values represented by X
+     and Y, carried out in machine mode M, which must be a fixed-point
+     mode.
+
+'(ashift:M X C)'
+'(ss_ashift:M X C)'
+'(us_ashift:M X C)'
+     These three expressions represent the result of arithmetically
+     shifting X left by C places.  They differ in their behavior on
+     overflow of integer modes.  An 'ashift' operation is a plain shift
+     with no special behavior in case of a change in the sign bit;
+     'ss_ashift' and 'us_ashift' saturates to the minimum or maximum
+     representable value if any of the bits shifted out differs from the
+     final sign bit.
+
+     X have mode M, a fixed-point machine mode.  C be a fixed-point mode
+     or be a constant with mode 'VOIDmode'; which mode is determined by
+     the mode called for in the machine description entry for the
+     left-shift instruction.  For example, on the VAX, the mode of C is
+     'QImode' regardless of M.
+
+'(lshiftrt:M X C)'
+'(ashiftrt:M X C)'
+     Like 'ashift' but for right shift.  Unlike the case for left shift,
+     these two operations are distinct.
+
+'(rotate:M X C)'
+'(rotatert:M X C)'
+     Similar but represent left and right rotate.  If C is a constant,
+     use 'rotate'.
+
+'(abs:M X)'
+'(ss_abs:M X)'
+     Represents the absolute value of X, computed in mode M.  'ss_abs'
+     ensures that an out-of-bounds result saturates to the maximum
+     signed value.
+
+'(sqrt:M X)'
+     Represents the square root of X, computed in mode M.  Most often M
+     will be a floating point mode.
+
+'(ffs:M X)'
+     Represents one plus the index of the least significant 1-bit in X,
+     represented as an integer of mode M.  (The value is zero if X is
+     zero.)  The mode of X must be M or 'VOIDmode'.
+
+'(clrsb:M X)'
+     Represents the number of redundant leading sign bits in X,
+     represented as an integer of mode M, starting at the most
+     significant bit position.  This is one less than the number of
+     leading sign bits (either 0 or 1), with no special cases.  The mode
+     of X must be M or 'VOIDmode'.
+
+'(clz:M X)'
+     Represents the number of leading 0-bits in X, represented as an
+     integer of mode M, starting at the most significant bit position.
+     If X is zero, the value is determined by
+     'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::).  Note that this is one
+     of the few expressions that is not invariant under widening.  The
+     mode of X must be M or 'VOIDmode'.
+
+'(ctz:M X)'
+     Represents the number of trailing 0-bits in X, represented as an
+     integer of mode M, starting at the least significant bit position.
+     If X is zero, the value is determined by
+     'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::).  Except for this case,
+     'ctz(x)' is equivalent to 'ffs(X) - 1'.  The mode of X must be M or
+     'VOIDmode'.
+
+'(popcount:M X)'
+     Represents the number of 1-bits in X, represented as an integer of
+     mode M.  The mode of X must be M or 'VOIDmode'.
+
+'(parity:M X)'
+     Represents the number of 1-bits modulo 2 in X, represented as an
+     integer of mode M.  The mode of X must be M or 'VOIDmode'.
+
+'(bswap:M X)'
+     Represents the value X with the order of bytes reversed, carried
+     out in mode M, which must be a fixed-point machine mode.  The mode
+     of X must be M or 'VOIDmode'.
+
+
+File: gccint.info,  Node: Comparisons,  Next: Bit-Fields,  Prev: Arithmetic,  Up: RTL
+
+13.10 Comparison Operations
+===========================
+
+Comparison operators test a relation on two operands and are considered
+to represent a machine-dependent nonzero value described by, but not
+necessarily equal to, 'STORE_FLAG_VALUE' (*note Misc::) if the relation
+holds, or zero if it does not, for comparison operators whose results
+have a 'MODE_INT' mode, 'FLOAT_STORE_FLAG_VALUE' (*note Misc::) if the
+relation holds, or zero if it does not, for comparison operators that
+return floating-point values, and a vector of either
+'VECTOR_STORE_FLAG_VALUE' (*note Misc::) if the relation holds, or of
+zeros if it does not, for comparison operators that return vector
+results.  The mode of the comparison operation is independent of the
+mode of the data being compared.  If the comparison operation is being
+tested (e.g., the first operand of an 'if_then_else'), the mode must be
+'VOIDmode'.
+
+ There are two ways that comparison operations may be used.  The
+comparison operators may be used to compare the condition codes '(cc0)'
+against zero, as in '(eq (cc0) (const_int 0))'.  Such a construct
+actually refers to the result of the preceding instruction in which the
+condition codes were set.  The instruction setting the condition code
+must be adjacent to the instruction using the condition code; only
+'note' insns may separate them.
+
+ Alternatively, a comparison operation may directly compare two data
+objects.  The mode of the comparison is determined by the operands; they
+must both be valid for a common machine mode.  A comparison with both
+operands constant would be invalid as the machine mode could not be
+deduced from it, but such a comparison should never exist in RTL due to
+constant folding.
+
+ In the example above, if '(cc0)' were last set to '(compare X Y)', the
+comparison operation is identical to '(eq X Y)'.  Usually only one style
+of comparisons is supported on a particular machine, but the combine
+pass will try to merge the operations to produce the 'eq' shown in case
+it exists in the context of the particular insn involved.
+
+ Inequality comparisons come in two flavors, signed and unsigned.  Thus,
+there are distinct expression codes 'gt' and 'gtu' for signed and
+unsigned greater-than.  These can produce different results for the same
+pair of integer values: for example, 1 is signed greater-than -1 but not
+unsigned greater-than, because -1 when regarded as unsigned is actually
+'0xffffffff' which is greater than 1.
+
+ The signed comparisons are also used for floating point values.
+Floating point comparisons are distinguished by the machine modes of the
+operands.
+
+'(eq:M X Y)'
+     'STORE_FLAG_VALUE' if the values represented by X and Y are equal,
+     otherwise 0.
+
+'(ne:M X Y)'
+     'STORE_FLAG_VALUE' if the values represented by X and Y are not
+     equal, otherwise 0.
+
+'(gt:M X Y)'
+     'STORE_FLAG_VALUE' if the X is greater than Y.  If they are
+     fixed-point, the comparison is done in a signed sense.
+
+'(gtu:M X Y)'
+     Like 'gt' but does unsigned comparison, on fixed-point numbers
+     only.
+
+'(lt:M X Y)'
+'(ltu:M X Y)'
+     Like 'gt' and 'gtu' but test for "less than".
+
+'(ge:M X Y)'
+'(geu:M X Y)'
+     Like 'gt' and 'gtu' but test for "greater than or equal".
+
+'(le:M X Y)'
+'(leu:M X Y)'
+     Like 'gt' and 'gtu' but test for "less than or equal".
+
+'(if_then_else COND THEN ELSE)'
+     This is not a comparison operation but is listed here because it is
+     always used in conjunction with a comparison operation.  To be
+     precise, COND is a comparison expression.  This expression
+     represents a choice, according to COND, between the value
+     represented by THEN and the one represented by ELSE.
+
+     On most machines, 'if_then_else' expressions are valid only to
+     express conditional jumps.
+
+'(cond [TEST1 VALUE1 TEST2 VALUE2 ...] DEFAULT)'
+     Similar to 'if_then_else', but more general.  Each of TEST1, TEST2,
+     ... is performed in turn.  The result of this expression is the
+     VALUE corresponding to the first nonzero test, or DEFAULT if none
+     of the tests are nonzero expressions.
+
+     This is currently not valid for instruction patterns and is
+     supported only for insn attributes.  *Note Insn Attributes::.
+
+
+File: gccint.info,  Node: Bit-Fields,  Next: Vector Operations,  Prev: Comparisons,  Up: RTL
+
+13.11 Bit-Fields
+================
+
+Special expression codes exist to represent bit-field instructions.
+
+'(sign_extract:M LOC SIZE POS)'
+     This represents a reference to a sign-extended bit-field contained
+     or starting in LOC (a memory or register reference).  The bit-field
+     is SIZE bits wide and starts at bit POS.  The compilation option
+     'BITS_BIG_ENDIAN' says which end of the memory unit POS counts
+     from.
+
+     If LOC is in memory, its mode must be a single-byte integer mode.
+     If LOC is in a register, the mode to use is specified by the
+     operand of the 'insv' or 'extv' pattern (*note Standard Names::)
+     and is usually a full-word integer mode, which is the default if
+     none is specified.
+
+     The mode of POS is machine-specific and is also specified in the
+     'insv' or 'extv' pattern.
+
+     The mode M is the same as the mode that would be used for LOC if it
+     were a register.
+
+     A 'sign_extract' can not appear as an lvalue, or part thereof, in
+     RTL.
+
+'(zero_extract:M LOC SIZE POS)'
+     Like 'sign_extract' but refers to an unsigned or zero-extended
+     bit-field.  The same sequence of bits are extracted, but they are
+     filled to an entire word with zeros instead of by sign-extension.
+
+     Unlike 'sign_extract', this type of expressions can be lvalues in
+     RTL; they may appear on the left side of an assignment, indicating
+     insertion of a value into the specified bit-field.
+
+
+File: gccint.info,  Node: Vector Operations,  Next: Conversions,  Prev: Bit-Fields,  Up: RTL
+
+13.12 Vector Operations
+=======================
+
+All normal RTL expressions can be used with vector modes; they are
+interpreted as operating on each part of the vector independently.
+Additionally, there are a few new expressions to describe specific
+vector operations.
+
+'(vec_merge:M VEC1 VEC2 ITEMS)'
+     This describes a merge operation between two vectors.  The result
+     is a vector of mode M; its elements are selected from either VEC1
+     or VEC2.  Which elements are selected is described by ITEMS, which
+     is a bit mask represented by a 'const_int'; a zero bit indicates
+     the corresponding element in the result vector is taken from VEC2
+     while a set bit indicates it is taken from VEC1.
+
+'(vec_select:M VEC1 SELECTION)'
+     This describes an operation that selects parts of a vector.  VEC1
+     is the source vector, and SELECTION is a 'parallel' that contains a
+     'const_int' for each of the subparts of the result vector, giving
+     the number of the source subpart that should be stored into it.
+     The result mode M is either the submode for a single element of
+     VEC1 (if only one subpart is selected), or another vector mode with
+     that element submode (if multiple subparts are selected).
+
+'(vec_concat:M X1 X2)'
+     Describes a vector concat operation.  The result is a concatenation
+     of the vectors or scalars X1 and X2; its length is the sum of the
+     lengths of the two inputs.
+
+'(vec_duplicate:M X)'
+     This operation converts a scalar into a vector or a small vector
+     into a larger one by duplicating the input values.  The output
+     vector mode must have the same submodes as the input vector mode or
+     the scalar modes, and the number of output parts must be an integer
+     multiple of the number of input parts.
+
+
+File: gccint.info,  Node: Conversions,  Next: RTL Declarations,  Prev: Vector Operations,  Up: RTL
+
+13.13 Conversions
+=================
+
+All conversions between machine modes must be represented by explicit
+conversion operations.  For example, an expression which is the sum of a
+byte and a full word cannot be written as '(plus:SI (reg:QI 34) (reg:SI
+80))' because the 'plus' operation requires two operands of the same
+machine mode.  Therefore, the byte-sized operand is enclosed in a
+conversion operation, as in
+
+     (plus:SI (sign_extend:SI (reg:QI 34)) (reg:SI 80))
+
+ The conversion operation is not a mere placeholder, because there may
+be more than one way of converting from a given starting mode to the
+desired final mode.  The conversion operation code says how to do it.
+
+ For all conversion operations, X must not be 'VOIDmode' because the
+mode in which to do the conversion would not be known.  The conversion
+must either be done at compile-time or X must be placed into a register.
+
+'(sign_extend:M X)'
+     Represents the result of sign-extending the value X to machine mode
+     M.  M must be a fixed-point mode and X a fixed-point value of a
+     mode narrower than M.
+
+'(zero_extend:M X)'
+     Represents the result of zero-extending the value X to machine mode
+     M.  M must be a fixed-point mode and X a fixed-point value of a
+     mode narrower than M.
+
+'(float_extend:M X)'
+     Represents the result of extending the value X to machine mode M.
+     M must be a floating point mode and X a floating point value of a
+     mode narrower than M.
+
+'(truncate:M X)'
+     Represents the result of truncating the value X to machine mode M.
+     M must be a fixed-point mode and X a fixed-point value of a mode
+     wider than M.
+
+'(ss_truncate:M X)'
+     Represents the result of truncating the value X to machine mode M,
+     using signed saturation in the case of overflow.  Both M and the
+     mode of X must be fixed-point modes.
+
+'(us_truncate:M X)'
+     Represents the result of truncating the value X to machine mode M,
+     using unsigned saturation in the case of overflow.  Both M and the
+     mode of X must be fixed-point modes.
+
+'(float_truncate:M X)'
+     Represents the result of truncating the value X to machine mode M.
+     M must be a floating point mode and X a floating point value of a
+     mode wider than M.
+
+'(float:M X)'
+     Represents the result of converting fixed point value X, regarded
+     as signed, to floating point mode M.
+
+'(unsigned_float:M X)'
+     Represents the result of converting fixed point value X, regarded
+     as unsigned, to floating point mode M.
+
+'(fix:M X)'
+     When M is a floating-point mode, represents the result of
+     converting floating point value X (valid for mode M) to an integer,
+     still represented in floating point mode M, by rounding towards
+     zero.
+
+     When M is a fixed-point mode, represents the result of converting
+     floating point value X to mode M, regarded as signed.  How rounding
+     is done is not specified, so this operation may be used validly in
+     compiling C code only for integer-valued operands.
+
+'(unsigned_fix:M X)'
+     Represents the result of converting floating point value X to fixed
+     point mode M, regarded as unsigned.  How rounding is done is not
+     specified.
+
+'(fract_convert:M X)'
+     Represents the result of converting fixed-point value X to
+     fixed-point mode M, signed integer value X to fixed-point mode M,
+     floating-point value X to fixed-point mode M, fixed-point value X
+     to integer mode M regarded as signed, or fixed-point value X to
+     floating-point mode M.  When overflows or underflows happen, the
+     results are undefined.
+
+'(sat_fract:M X)'
+     Represents the result of converting fixed-point value X to
+     fixed-point mode M, signed integer value X to fixed-point mode M,
+     or floating-point value X to fixed-point mode M.  When overflows or
+     underflows happen, the results are saturated to the maximum or the
+     minimum.
+
+'(unsigned_fract_convert:M X)'
+     Represents the result of converting fixed-point value X to integer
+     mode M regarded as unsigned, or unsigned integer value X to
+     fixed-point mode M.  When overflows or underflows happen, the
+     results are undefined.
+
+'(unsigned_sat_fract:M X)'
+     Represents the result of converting unsigned integer value X to
+     fixed-point mode M.  When overflows or underflows happen, the
+     results are saturated to the maximum or the minimum.
+
+
+File: gccint.info,  Node: RTL Declarations,  Next: Side Effects,  Prev: Conversions,  Up: RTL
+
+13.14 Declarations
+==================
+
+Declaration expression codes do not represent arithmetic operations but
+rather state assertions about their operands.
+
+'(strict_low_part (subreg:M (reg:N R) 0))'
+     This expression code is used in only one context: as the
+     destination operand of a 'set' expression.  In addition, the
+     operand of this expression must be a non-paradoxical 'subreg'
+     expression.
+
+     The presence of 'strict_low_part' says that the part of the
+     register which is meaningful in mode N, but is not part of mode M,
+     is not to be altered.  Normally, an assignment to such a subreg is
+     allowed to have undefined effects on the rest of the register when
+     M is less than a word.
+
+
+File: gccint.info,  Node: Side Effects,  Next: Incdec,  Prev: RTL Declarations,  Up: RTL
+
+13.15 Side Effect Expressions
+=============================
+
+The expression codes described so far represent values, not actions.
+But machine instructions never produce values; they are meaningful only
+for their side effects on the state of the machine.  Special expression
+codes are used to represent side effects.
+
+ The body of an instruction is always one of these side effect codes;
+the codes described above, which represent values, appear only as the
+operands of these.
+
+'(set LVAL X)'
+     Represents the action of storing the value of X into the place
+     represented by LVAL.  LVAL must be an expression representing a
+     place that can be stored in: 'reg' (or 'subreg', 'strict_low_part'
+     or 'zero_extract'), 'mem', 'pc', 'parallel', or 'cc0'.
+
+     If LVAL is a 'reg', 'subreg' or 'mem', it has a machine mode; then
+     X must be valid for that mode.
+
+     If LVAL is a 'reg' whose machine mode is less than the full width
+     of the register, then it means that the part of the register
+     specified by the machine mode is given the specified value and the
+     rest of the register receives an undefined value.  Likewise, if
+     LVAL is a 'subreg' whose machine mode is narrower than the mode of
+     the register, the rest of the register can be changed in an
+     undefined way.
+
+     If LVAL is a 'strict_low_part' of a subreg, then the part of the
+     register specified by the machine mode of the 'subreg' is given the
+     value X and the rest of the register is not changed.
+
+     If LVAL is a 'zero_extract', then the referenced part of the
+     bit-field (a memory or register reference) specified by the
+     'zero_extract' is given the value X and the rest of the bit-field
+     is not changed.  Note that 'sign_extract' can not appear in LVAL.
+
+     If LVAL is '(cc0)', it has no machine mode, and X may be either a
+     'compare' expression or a value that may have any mode.  The latter
+     case represents a "test" instruction.  The expression '(set (cc0)
+     (reg:M N))' is equivalent to '(set (cc0) (compare (reg:M N)
+     (const_int 0)))'.  Use the former expression to save space during
+     the compilation.
+
+     If LVAL is a 'parallel', it is used to represent the case of a
+     function returning a structure in multiple registers.  Each element
+     of the 'parallel' is an 'expr_list' whose first operand is a 'reg'
+     and whose second operand is a 'const_int' representing the offset
+     (in bytes) into the structure at which the data in that register
+     corresponds.  The first element may be null to indicate that the
+     structure is also passed partly in memory.
+
+     If LVAL is '(pc)', we have a jump instruction, and the
+     possibilities for X are very limited.  It may be a 'label_ref'
+     expression (unconditional jump).  It may be an 'if_then_else'
+     (conditional jump), in which case either the second or the third
+     operand must be '(pc)' (for the case which does not jump) and the
+     other of the two must be a 'label_ref' (for the case which does
+     jump).  X may also be a 'mem' or '(plus:SI (pc) Y)', where Y may be
+     a 'reg' or a 'mem'; these unusual patterns are used to represent
+     jumps through branch tables.
+
+     If LVAL is neither '(cc0)' nor '(pc)', the mode of LVAL must not be
+     'VOIDmode' and the mode of X must be valid for the mode of LVAL.
+
+     LVAL is customarily accessed with the 'SET_DEST' macro and X with
+     the 'SET_SRC' macro.
+
+'(return)'
+     As the sole expression in a pattern, represents a return from the
+     current function, on machines where this can be done with one
+     instruction, such as VAXen.  On machines where a multi-instruction
+     "epilogue" must be executed in order to return from the function,
+     returning is done by jumping to a label which precedes the
+     epilogue, and the 'return' expression code is never used.
+
+     Inside an 'if_then_else' expression, represents the value to be
+     placed in 'pc' to return to the caller.
+
+     Note that an insn pattern of '(return)' is logically equivalent to
+     '(set (pc) (return))', but the latter form is never used.
+
+'(simple_return)'
+     Like '(return)', but truly represents only a function return, while
+     '(return)' may represent an insn that also performs other functions
+     of the function epilogue.  Like '(return)', this may also occur in
+     conditional jumps.
+
+'(call FUNCTION NARGS)'
+     Represents a function call.  FUNCTION is a 'mem' expression whose
+     address is the address of the function to be called.  NARGS is an
+     expression which can be used for two purposes: on some machines it
+     represents the number of bytes of stack argument; on others, it
+     represents the number of argument registers.
+
+     Each machine has a standard machine mode which FUNCTION must have.
+     The machine description defines macro 'FUNCTION_MODE' to expand
+     into the requisite mode name.  The purpose of this mode is to
+     specify what kind of addressing is allowed, on machines where the
+     allowed kinds of addressing depend on the machine mode being
+     addressed.
+
+'(clobber X)'
+     Represents the storing or possible storing of an unpredictable,
+     undescribed value into X, which must be a 'reg', 'scratch',
+     'parallel' or 'mem' expression.
+
+     One place this is used is in string instructions that store
+     standard values into particular hard registers.  It may not be
+     worth the trouble to describe the values that are stored, but it is
+     essential to inform the compiler that the registers will be
+     altered, lest it attempt to keep data in them across the string
+     instruction.
+
+     If X is '(mem:BLK (const_int 0))' or '(mem:BLK (scratch))', it
+     means that all memory locations must be presumed clobbered.  If X
+     is a 'parallel', it has the same meaning as a 'parallel' in a 'set'
+     expression.
+
+     Note that the machine description classifies certain hard registers
+     as "call-clobbered".  All function call instructions are assumed by
+     default to clobber these registers, so there is no need to use
+     'clobber' expressions to indicate this fact.  Also, each function
+     call is assumed to have the potential to alter any memory location,
+     unless the function is declared 'const'.
+
+     If the last group of expressions in a 'parallel' are each a
+     'clobber' expression whose arguments are 'reg' or 'match_scratch'
+     (*note RTL Template::) expressions, the combiner phase can add the
+     appropriate 'clobber' expressions to an insn it has constructed
+     when doing so will cause a pattern to be matched.
+
+     This feature can be used, for example, on a machine that whose
+     multiply and add instructions don't use an MQ register but which
+     has an add-accumulate instruction that does clobber the MQ
+     register.  Similarly, a combined instruction might require a
+     temporary register while the constituent instructions might not.
+
+     When a 'clobber' expression for a register appears inside a
+     'parallel' with other side effects, the register allocator
+     guarantees that the register is unoccupied both before and after
+     that insn if it is a hard register clobber.  For pseudo-register
+     clobber, the register allocator and the reload pass do not assign
+     the same hard register to the clobber and the input operands if
+     there is an insn alternative containing the '&' constraint (*note
+     Modifiers::) for the clobber and the hard register is in register
+     classes of the clobber in the alternative.  You can clobber either
+     a specific hard register, a pseudo register, or a 'scratch'
+     expression; in the latter two cases, GCC will allocate a hard
+     register that is available there for use as a temporary.
+
+     For instructions that require a temporary register, you should use
+     'scratch' instead of a pseudo-register because this will allow the
+     combiner phase to add the 'clobber' when required.  You do this by
+     coding ('clobber' ('match_scratch' ...)).  If you do clobber a
+     pseudo register, use one which appears nowhere else--generate a new
+     one each time.  Otherwise, you may confuse CSE.
+
+     There is one other known use for clobbering a pseudo register in a
+     'parallel': when one of the input operands of the insn is also
+     clobbered by the insn.  In this case, using the same pseudo
+     register in the clobber and elsewhere in the insn produces the
+     expected results.
+
+'(use X)'
+     Represents the use of the value of X.  It indicates that the value
+     in X at this point in the program is needed, even though it may not
+     be apparent why this is so.  Therefore, the compiler will not
+     attempt to delete previous instructions whose only effect is to
+     store a value in X.  X must be a 'reg' expression.
+
+     In some situations, it may be tempting to add a 'use' of a register
+     in a 'parallel' to describe a situation where the value of a
+     special register will modify the behavior of the instruction.  A
+     hypothetical example might be a pattern for an addition that can
+     either wrap around or use saturating addition depending on the
+     value of a special control register:
+
+          (parallel [(set (reg:SI 2) (unspec:SI [(reg:SI 3)
+                                                 (reg:SI 4)] 0))
+                     (use (reg:SI 1))])
+
+     This will not work, several of the optimizers only look at
+     expressions locally; it is very likely that if you have multiple
+     insns with identical inputs to the 'unspec', they will be optimized
+     away even if register 1 changes in between.
+
+     This means that 'use' can _only_ be used to describe that the
+     register is live.  You should think twice before adding 'use'
+     statements, more often you will want to use 'unspec' instead.  The
+     'use' RTX is most commonly useful to describe that a fixed register
+     is implicitly used in an insn.  It is also safe to use in patterns
+     where the compiler knows for other reasons that the result of the
+     whole pattern is variable, such as 'movmemM' or 'call' patterns.
+
+     During the reload phase, an insn that has a 'use' as pattern can
+     carry a reg_equal note.  These 'use' insns will be deleted before
+     the reload phase exits.
+
+     During the delayed branch scheduling phase, X may be an insn.  This
+     indicates that X previously was located at this place in the code
+     and its data dependencies need to be taken into account.  These
+     'use' insns will be deleted before the delayed branch scheduling
+     phase exits.
+
+'(parallel [X0 X1 ...])'
+     Represents several side effects performed in parallel.  The square
+     brackets stand for a vector; the operand of 'parallel' is a vector
+     of expressions.  X0, X1 and so on are individual side effect
+     expressions--expressions of code 'set', 'call', 'return',
+     'simple_return', 'clobber' or 'use'.
+
+     "In parallel" means that first all the values used in the
+     individual side-effects are computed, and second all the actual
+     side-effects are performed.  For example,
+
+          (parallel [(set (reg:SI 1) (mem:SI (reg:SI 1)))
+                     (set (mem:SI (reg:SI 1)) (reg:SI 1))])
+
+     says unambiguously that the values of hard register 1 and the
+     memory location addressed by it are interchanged.  In both places
+     where '(reg:SI 1)' appears as a memory address it refers to the
+     value in register 1 _before_ the execution of the insn.
+
+     It follows that it is _incorrect_ to use 'parallel' and expect the
+     result of one 'set' to be available for the next one.  For example,
+     people sometimes attempt to represent a jump-if-zero instruction
+     this way:
+
+          (parallel [(set (cc0) (reg:SI 34))
+                     (set (pc) (if_then_else
+                                  (eq (cc0) (const_int 0))
+                                  (label_ref ...)
+                                  (pc)))])
+
+     But this is incorrect, because it says that the jump condition
+     depends on the condition code value _before_ this instruction, not
+     on the new value that is set by this instruction.
+
+     Peephole optimization, which takes place together with final
+     assembly code output, can produce insns whose patterns consist of a
+     'parallel' whose elements are the operands needed to output the
+     resulting assembler code--often 'reg', 'mem' or constant
+     expressions.  This would not be well-formed RTL at any other stage
+     in compilation, but it is OK then because no further optimization
+     remains to be done.  However, the definition of the macro
+     'NOTICE_UPDATE_CC', if any, must deal with such insns if you define
+     any peephole optimizations.
+
+'(cond_exec [COND EXPR])'
+     Represents a conditionally executed expression.  The EXPR is
+     executed only if the COND is nonzero.  The COND expression must not
+     have side-effects, but the EXPR may very well have side-effects.
+
+'(sequence [INSNS ...])'
+     Represents a sequence of insns.  If a 'sequence' appears in the
+     chain of insns, then each of the INSNS that appears in the sequence
+     must be suitable for appearing in the chain of insns, i.e.  must
+     satisfy the 'INSN_P' predicate.
+
+     After delay-slot scheduling is completed, an insn and all the insns
+     that reside in its delay slots are grouped together into a
+     'sequence'.  The insn requiring the delay slot is the first insn in
+     the vector; subsequent insns are to be placed in the delay slot.
+
+     'INSN_ANNULLED_BRANCH_P' is set on an insn in a delay slot to
+     indicate that a branch insn should be used that will conditionally
+     annul the effect of the insns in the delay slots.  In such a case,
+     'INSN_FROM_TARGET_P' indicates that the insn is from the target of
+     the branch and should be executed only if the branch is taken;
+     otherwise the insn should be executed only if the branch is not
+     taken.  *Note Delay Slots::.
+
+     Some back ends also use 'sequence' objects for purposes other than
+     delay-slot groups.  This is not supported in the common parts of
+     the compiler, which treat such sequences as delay-slot groups.
+
+     DWARF2 Call Frame Address (CFA) adjustments are sometimes also
+     expressed using 'sequence' objects as the value of a
+     'RTX_FRAME_RELATED_P' note.  This only happens if the CFA
+     adjustments cannot be easily derived from the pattern of the
+     instruction to which the note is attached.  In such cases, the
+     value of the note is used instead of best-guesing the semantics of
+     the instruction.  The back end can attach notes containing a
+     'sequence' of 'set' patterns that express the effect of the parent
+     instruction.
+
+ These expression codes appear in place of a side effect, as the body of
+an insn, though strictly speaking they do not always describe side
+effects as such:
+
+'(asm_input S)'
+     Represents literal assembler code as described by the string S.
+
+'(unspec [OPERANDS ...] INDEX)'
+'(unspec_volatile [OPERANDS ...] INDEX)'
+     Represents a machine-specific operation on OPERANDS.  INDEX selects
+     between multiple machine-specific operations.  'unspec_volatile' is
+     used for volatile operations and operations that may trap; 'unspec'
+     is used for other operations.
+
+     These codes may appear inside a 'pattern' of an insn, inside a
+     'parallel', or inside an expression.
+
+'(addr_vec:M [LR0 LR1 ...])'
+     Represents a table of jump addresses.  The vector elements LR0,
+     etc., are 'label_ref' expressions.  The mode M specifies how much
+     space is given to each address; normally M would be 'Pmode'.
+
+'(addr_diff_vec:M BASE [LR0 LR1 ...] MIN MAX FLAGS)'
+     Represents a table of jump addresses expressed as offsets from
+     BASE.  The vector elements LR0, etc., are 'label_ref' expressions
+     and so is BASE.  The mode M specifies how much space is given to
+     each address-difference.  MIN and MAX are set up by branch
+     shortening and hold a label with a minimum and a maximum address,
+     respectively.  FLAGS indicates the relative position of BASE, MIN
+     and MAX to the containing insn and of MIN and MAX to BASE.  See
+     rtl.def for details.
+
+'(prefetch:M ADDR RW LOCALITY)'
+     Represents prefetch of memory at address ADDR.  Operand RW is 1 if
+     the prefetch is for data to be written, 0 otherwise; targets that
+     do not support write prefetches should treat this as a normal
+     prefetch.  Operand LOCALITY specifies the amount of temporal
+     locality; 0 if there is none or 1, 2, or 3 for increasing levels of
+     temporal locality; targets that do not support locality hints
+     should ignore this.
+
+     This insn is used to minimize cache-miss latency by moving data
+     into a cache before it is accessed.  It should use only
+     non-faulting data prefetch instructions.
+
+
+File: gccint.info,  Node: Incdec,  Next: Assembler,  Prev: Side Effects,  Up: RTL
+
+13.16 Embedded Side-Effects on Addresses
+========================================
+
+Six special side-effect expression codes appear as memory addresses.
+
+'(pre_dec:M X)'
+     Represents the side effect of decrementing X by a standard amount
+     and represents also the value that X has after being decremented.
+     X must be a 'reg' or 'mem', but most machines allow only a 'reg'.
+     M must be the machine mode for pointers on the machine in use.  The
+     amount X is decremented by is the length in bytes of the machine
+     mode of the containing memory reference of which this expression
+     serves as the address.  Here is an example of its use:
+
+          (mem:DF (pre_dec:SI (reg:SI 39)))
+
+     This says to decrement pseudo register 39 by the length of a
+     'DFmode' value and use the result to address a 'DFmode' value.
+
+'(pre_inc:M X)'
+     Similar, but specifies incrementing X instead of decrementing it.
+
+'(post_dec:M X)'
+     Represents the same side effect as 'pre_dec' but a different value.
+     The value represented here is the value X has before being
+     decremented.
+
+'(post_inc:M X)'
+     Similar, but specifies incrementing X instead of decrementing it.
+
+'(post_modify:M X Y)'
+
+     Represents the side effect of setting X to Y and represents X
+     before X is modified.  X must be a 'reg' or 'mem', but most
+     machines allow only a 'reg'.  M must be the machine mode for
+     pointers on the machine in use.
+
+     The expression Y must be one of three forms: '(plus:M X Z)',
+     '(minus:M X Z)', or '(plus:M X I)', where Z is an index register
+     and I is a constant.
+
+     Here is an example of its use:
+
+          (mem:SF (post_modify:SI (reg:SI 42) (plus (reg:SI 42)
+                                                    (reg:SI 48))))
+
+     This says to modify pseudo register 42 by adding the contents of
+     pseudo register 48 to it, after the use of what ever 42 points to.
+
+'(pre_modify:M X EXPR)'
+     Similar except side effects happen before the use.
+
+ These embedded side effect expressions must be used with care.
+Instruction patterns may not use them.  Until the 'flow' pass of the
+compiler, they may occur only to represent pushes onto the stack.  The
+'flow' pass finds cases where registers are incremented or decremented
+in one instruction and used as an address shortly before or after; these
+cases are then transformed to use pre- or post-increment or -decrement.
+
+ If a register used as the operand of these expressions is used in
+another address in an insn, the original value of the register is used.
+Uses of the register outside of an address are not permitted within the
+same insn as a use in an embedded side effect expression because such
+insns behave differently on different machines and hence must be treated
+as ambiguous and disallowed.
+
+ An instruction that can be represented with an embedded side effect
+could also be represented using 'parallel' containing an additional
+'set' to describe how the address register is altered.  This is not done
+because machines that allow these operations at all typically allow them
+wherever a memory address is called for.  Describing them as additional
+parallel stores would require doubling the number of entries in the
+machine description.
+
+
+File: gccint.info,  Node: Assembler,  Next: Debug Information,  Prev: Incdec,  Up: RTL
+
+13.17 Assembler Instructions as Expressions
+===========================================
+
+The RTX code 'asm_operands' represents a value produced by a
+user-specified assembler instruction.  It is used to represent an 'asm'
+statement with arguments.  An 'asm' statement with a single output
+operand, like this:
+
+     asm ("foo %1,%2,%0" : "=a" (outputvar) : "g" (x + y), "di" (*z));
+
+is represented using a single 'asm_operands' RTX which represents the
+value that is stored in 'outputvar':
+
+     (set RTX-FOR-OUTPUTVAR
+          (asm_operands "foo %1,%2,%0" "a" 0
+                        [RTX-FOR-ADDITION-RESULT RTX-FOR-*Z]
+                        [(asm_input:M1 "g")
+                         (asm_input:M2 "di")]))
+
+Here the operands of the 'asm_operands' RTX are the assembler template
+string, the output-operand's constraint, the index-number of the output
+operand among the output operands specified, a vector of input operand
+RTX's, and a vector of input-operand modes and constraints.  The mode M1
+is the mode of the sum 'x+y'; M2 is that of '*z'.
+
+ When an 'asm' statement has multiple output values, its insn has
+several such 'set' RTX's inside of a 'parallel'.  Each 'set' contains an
+'asm_operands'; all of these share the same assembler template and
+vectors, but each contains the constraint for the respective output
+operand.  They are also distinguished by the output-operand index
+number, which is 0, 1, ... for successive output operands.
+
+
+File: gccint.info,  Node: Debug Information,  Next: Insns,  Prev: Assembler,  Up: RTL
+
+13.18 Variable Location Debug Information in RTL
+================================================
+
+Variable tracking relies on 'MEM_EXPR' and 'REG_EXPR' annotations to
+determine what user variables memory and register references refer to.
+
+ Variable tracking at assignments uses these notes only when they refer
+to variables that live at fixed locations (e.g., addressable variables,
+global non-automatic variables).  For variables whose location may vary,
+it relies on the following types of notes.
+
+'(var_location:MODE VAR EXP STAT)'
+     Binds variable 'var', a tree, to value EXP, an RTL expression.  It
+     appears only in 'NOTE_INSN_VAR_LOCATION' and 'DEBUG_INSN's, with
+     slightly different meanings.  MODE, if present, represents the mode
+     of EXP, which is useful if it is a modeless expression.  STAT is
+     only meaningful in notes, indicating whether the variable is known
+     to be initialized or uninitialized.
+
+'(debug_expr:MODE DECL)'
+     Stands for the value bound to the 'DEBUG_EXPR_DECL' DECL, that
+     points back to it, within value expressions in 'VAR_LOCATION'
+     nodes.
+
+
+File: gccint.info,  Node: Insns,  Next: Calls,  Prev: Debug Information,  Up: RTL
+
+13.19 Insns
+===========
+
+The RTL representation of the code for a function is a doubly-linked
+chain of objects called "insns".  Insns are expressions with special
+codes that are used for no other purpose.  Some insns are actual
+instructions; others represent dispatch tables for 'switch' statements;
+others represent labels to jump to or various sorts of declarative
+information.
+
+ In addition to its own specific data, each insn must have a unique
+id-number that distinguishes it from all other insns in the current
+function (after delayed branch scheduling, copies of an insn with the
+same id-number may be present in multiple places in a function, but
+these copies will always be identical and will only appear inside a
+'sequence'), and chain pointers to the preceding and following insns.
+These three fields occupy the same position in every insn, independent
+of the expression code of the insn.  They could be accessed with 'XEXP'
+and 'XINT', but instead three special macros are always used:
+
+'INSN_UID (I)'
+     Accesses the unique id of insn I.
+
+'PREV_INSN (I)'
+     Accesses the chain pointer to the insn preceding I.  If I is the
+     first insn, this is a null pointer.
+
+'NEXT_INSN (I)'
+     Accesses the chain pointer to the insn following I.  If I is the
+     last insn, this is a null pointer.
+
+ The first insn in the chain is obtained by calling 'get_insns'; the
+last insn is the result of calling 'get_last_insn'.  Within the chain
+delimited by these insns, the 'NEXT_INSN' and 'PREV_INSN' pointers must
+always correspond: if INSN is not the first insn,
+
+     NEXT_INSN (PREV_INSN (INSN)) == INSN
+
+is always true and if INSN is not the last insn,
+
+     PREV_INSN (NEXT_INSN (INSN)) == INSN
+
+is always true.
+
+ After delay slot scheduling, some of the insns in the chain might be
+'sequence' expressions, which contain a vector of insns.  The value of
+'NEXT_INSN' in all but the last of these insns is the next insn in the
+vector; the value of 'NEXT_INSN' of the last insn in the vector is the
+same as the value of 'NEXT_INSN' for the 'sequence' in which it is
+contained.  Similar rules apply for 'PREV_INSN'.
+
+ This means that the above invariants are not necessarily true for insns
+inside 'sequence' expressions.  Specifically, if INSN is the first insn
+in a 'sequence', 'NEXT_INSN (PREV_INSN (INSN))' is the insn containing
+the 'sequence' expression, as is the value of 'PREV_INSN (NEXT_INSN
+(INSN))' if INSN is the last insn in the 'sequence' expression.  You can
+use these expressions to find the containing 'sequence' expression.
+
+ Every insn has one of the following expression codes:
+
+'insn'
+     The expression code 'insn' is used for instructions that do not
+     jump and do not do function calls.  'sequence' expressions are
+     always contained in insns with code 'insn' even if one of those
+     insns should jump or do function calls.
+
+     Insns with code 'insn' have four additional fields beyond the three
+     mandatory ones listed above.  These four are described in a table
+     below.
+
+'jump_insn'
+     The expression code 'jump_insn' is used for instructions that may
+     jump (or, more generally, may contain 'label_ref' expressions to
+     which 'pc' can be set in that instruction).  If there is an
+     instruction to return from the current function, it is recorded as
+     a 'jump_insn'.
+
+     'jump_insn' insns have the same extra fields as 'insn' insns,
+     accessed in the same way and in addition contain a field
+     'JUMP_LABEL' which is defined once jump optimization has completed.
+
+     For simple conditional and unconditional jumps, this field contains
+     the 'code_label' to which this insn will (possibly conditionally)
+     branch.  In a more complex jump, 'JUMP_LABEL' records one of the
+     labels that the insn refers to; other jump target labels are
+     recorded as 'REG_LABEL_TARGET' notes.  The exception is 'addr_vec'
+     and 'addr_diff_vec', where 'JUMP_LABEL' is 'NULL_RTX' and the only
+     way to find the labels is to scan the entire body of the insn.
+
+     Return insns count as jumps, but since they do not refer to any
+     labels, their 'JUMP_LABEL' is 'NULL_RTX'.
+
+'call_insn'
+     The expression code 'call_insn' is used for instructions that may
+     do function calls.  It is important to distinguish these
+     instructions because they imply that certain registers and memory
+     locations may be altered unpredictably.
+
+     'call_insn' insns have the same extra fields as 'insn' insns,
+     accessed in the same way and in addition contain a field
+     'CALL_INSN_FUNCTION_USAGE', which contains a list (chain of
+     'expr_list' expressions) containing 'use', 'clobber' and sometimes
+     'set' expressions that denote hard registers and 'mem's used or
+     clobbered by the called function.
+
+     A 'mem' generally points to a stack slot in which arguments passed
+     to the libcall by reference (*note TARGET_PASS_BY_REFERENCE:
+     Register Arguments.) are stored.  If the argument is caller-copied
+     (*note TARGET_CALLEE_COPIES: Register Arguments.), the stack slot
+     will be mentioned in 'clobber' and 'use' entries; if it's
+     callee-copied, only a 'use' will appear, and the 'mem' may point to
+     addresses that are not stack slots.
+
+     Registers occurring inside a 'clobber' in this list augment
+     registers specified in 'CALL_USED_REGISTERS' (*note Register
+     Basics::).
+
+     If the list contains a 'set' involving two registers, it indicates
+     that the function returns one of its arguments.  Such a 'set' may
+     look like a no-op if the same register holds the argument and the
+     return value.
+
+'code_label'
+     A 'code_label' insn represents a label that a jump insn can jump
+     to.  It contains two special fields of data in addition to the
+     three standard ones.  'CODE_LABEL_NUMBER' is used to hold the
+     "label number", a number that identifies this label uniquely among
+     all the labels in the compilation (not just in the current
+     function).  Ultimately, the label is represented in the assembler
+     output as an assembler label, usually of the form 'LN' where N is
+     the label number.
+
+     When a 'code_label' appears in an RTL expression, it normally
+     appears within a 'label_ref' which represents the address of the
+     label, as a number.
+
+     Besides as a 'code_label', a label can also be represented as a
+     'note' of type 'NOTE_INSN_DELETED_LABEL'.
+
+     The field 'LABEL_NUSES' is only defined once the jump optimization
+     phase is completed.  It contains the number of times this label is
+     referenced in the current function.
+
+     The field 'LABEL_KIND' differentiates four different types of
+     labels: 'LABEL_NORMAL', 'LABEL_STATIC_ENTRY', 'LABEL_GLOBAL_ENTRY',
+     and 'LABEL_WEAK_ENTRY'.  The only labels that do not have type
+     'LABEL_NORMAL' are "alternate entry points" to the current
+     function.  These may be static (visible only in the containing
+     translation unit), global (exposed to all translation units), or
+     weak (global, but can be overridden by another symbol with the same
+     name).
+
+     Much of the compiler treats all four kinds of label identically.
+     Some of it needs to know whether or not a label is an alternate
+     entry point; for this purpose, the macro 'LABEL_ALT_ENTRY_P' is
+     provided.  It is equivalent to testing whether 'LABEL_KIND (label)
+     == LABEL_NORMAL'.  The only place that cares about the distinction
+     between static, global, and weak alternate entry points, besides
+     the front-end code that creates them, is the function
+     'output_alternate_entry_point', in 'final.c'.
+
+     To set the kind of a label, use the 'SET_LABEL_KIND' macro.
+
+'jump_table_data'
+     A 'jump_table_data' insn is a placeholder for the jump-table data
+     of a 'casesi' or 'tablejump' insn.  They are placed after a
+     'tablejump_p' insn.  A 'jump_table_data' insn is not part o a basic
+     blockm but it is associated with the basic block that ends with the
+     'tablejump_p' insn.  The 'PATTERN' of a 'jump_table_data' is always
+     either an 'addr_vec' or an 'addr_diff_vec', and a 'jump_table_data'
+     insn is always preceded by a 'code_label'.  The 'tablejump_p' insn
+     refers to that 'code_label' via its 'JUMP_LABEL'.
+
+'barrier'
+     Barriers are placed in the instruction stream when control cannot
+     flow past them.  They are placed after unconditional jump
+     instructions to indicate that the jumps are unconditional and after
+     calls to 'volatile' functions, which do not return (e.g., 'exit').
+     They contain no information beyond the three standard fields.
+
+'note'
+     'note' insns are used to represent additional debugging and
+     declarative information.  They contain two nonstandard fields, an
+     integer which is accessed with the macro 'NOTE_LINE_NUMBER' and a
+     string accessed with 'NOTE_SOURCE_FILE'.
+
+     If 'NOTE_LINE_NUMBER' is positive, the note represents the position
+     of a source line and 'NOTE_SOURCE_FILE' is the source file name
+     that the line came from.  These notes control generation of line
+     number data in the assembler output.
+
+     Otherwise, 'NOTE_LINE_NUMBER' is not really a line number but a
+     code with one of the following values (and 'NOTE_SOURCE_FILE' must
+     contain a null pointer):
+
+     'NOTE_INSN_DELETED'
+          Such a note is completely ignorable.  Some passes of the
+          compiler delete insns by altering them into notes of this
+          kind.
+
+     'NOTE_INSN_DELETED_LABEL'
+          This marks what used to be a 'code_label', but was not used
+          for other purposes than taking its address and was transformed
+          to mark that no code jumps to it.
+
+     'NOTE_INSN_BLOCK_BEG'
+     'NOTE_INSN_BLOCK_END'
+          These types of notes indicate the position of the beginning
+          and end of a level of scoping of variable names.  They control
+          the output of debugging information.
+
+     'NOTE_INSN_EH_REGION_BEG'
+     'NOTE_INSN_EH_REGION_END'
+          These types of notes indicate the position of the beginning
+          and end of a level of scoping for exception handling.
+          'NOTE_EH_HANDLER' identifies which region is associated with
+          these notes.
+
+     'NOTE_INSN_FUNCTION_BEG'
+          Appears at the start of the function body, after the function
+          prologue.
+
+     'NOTE_INSN_VAR_LOCATION'
+          This note is used to generate variable location debugging
+          information.  It indicates that the user variable in its
+          'VAR_LOCATION' operand is at the location given in the RTL
+          expression, or holds a value that can be computed by
+          evaluating the RTL expression from that static point in the
+          program up to the next such note for the same user variable.
+
+     These codes are printed symbolically when they appear in debugging
+     dumps.
+
+'debug_insn'
+     The expression code 'debug_insn' is used for pseudo-instructions
+     that hold debugging information for variable tracking at
+     assignments (see '-fvar-tracking-assignments' option).  They are
+     the RTL representation of 'GIMPLE_DEBUG' statements (*note
+     'GIMPLE_DEBUG'::), with a 'VAR_LOCATION' operand that binds a user
+     variable tree to an RTL representation of the 'value' in the
+     corresponding statement.  A 'DEBUG_EXPR' in it stands for the value
+     bound to the corresponding 'DEBUG_EXPR_DECL'.
+
+     Throughout optimization passes, binding information is kept in
+     pseudo-instruction form, so that, unlike notes, it gets the same
+     treatment and adjustments that regular instructions would.  It is
+     the variable tracking pass that turns these pseudo-instructions
+     into var location notes, analyzing control flow, value equivalences
+     and changes to registers and memory referenced in value
+     expressions, propagating the values of debug temporaries and
+     determining expressions that can be used to compute the value of
+     each user variable at as many points (ranges, actually) in the
+     program as possible.
+
+     Unlike 'NOTE_INSN_VAR_LOCATION', the value expression in an
+     'INSN_VAR_LOCATION' denotes a value at that specific point in the
+     program, rather than an expression that can be evaluated at any
+     later point before an overriding 'VAR_LOCATION' is encountered.
+     E.g., if a user variable is bound to a 'REG' and then a subsequent
+     insn modifies the 'REG', the note location would keep mapping the
+     user variable to the register across the insn, whereas the insn
+     location would keep the variable bound to the value, so that the
+     variable tracking pass would emit another location note for the
+     variable at the point in which the register is modified.
+
+ The machine mode of an insn is normally 'VOIDmode', but some phases use
+the mode for various purposes.
+
+ The common subexpression elimination pass sets the mode of an insn to
+'QImode' when it is the first insn in a block that has already been
+processed.
+
+ The second Haifa scheduling pass, for targets that can multiple issue,
+sets the mode of an insn to 'TImode' when it is believed that the
+instruction begins an issue group.  That is, when the instruction cannot
+issue simultaneously with the previous.  This may be relied on by later
+passes, in particular machine-dependent reorg.
+
+ Here is a table of the extra fields of 'insn', 'jump_insn' and
+'call_insn' insns:
+
+'PATTERN (I)'
+     An expression for the side effect performed by this insn.  This
+     must be one of the following codes: 'set', 'call', 'use',
+     'clobber', 'return', 'simple_return', 'asm_input', 'asm_output',
+     'addr_vec', 'addr_diff_vec', 'trap_if', 'unspec',
+     'unspec_volatile', 'parallel', 'cond_exec', or 'sequence'.  If it
+     is a 'parallel', each element of the 'parallel' must be one these
+     codes, except that 'parallel' expressions cannot be nested and
+     'addr_vec' and 'addr_diff_vec' are not permitted inside a
+     'parallel' expression.
+
+'INSN_CODE (I)'
+     An integer that says which pattern in the machine description
+     matches this insn, or -1 if the matching has not yet been
+     attempted.
+
+     Such matching is never attempted and this field remains -1 on an
+     insn whose pattern consists of a single 'use', 'clobber',
+     'asm_input', 'addr_vec' or 'addr_diff_vec' expression.
+
+     Matching is also never attempted on insns that result from an 'asm'
+     statement.  These contain at least one 'asm_operands' expression.
+     The function 'asm_noperands' returns a non-negative value for such
+     insns.
+
+     In the debugging output, this field is printed as a number followed
+     by a symbolic representation that locates the pattern in the 'md'
+     file as some small positive or negative offset from a named
+     pattern.
+
+'LOG_LINKS (I)'
+     A list (chain of 'insn_list' expressions) giving information about
+     dependencies between instructions within a basic block.  Neither a
+     jump nor a label may come between the related insns.  These are
+     only used by the schedulers and by combine.  This is a deprecated
+     data structure.  Def-use and use-def chains are now preferred.
+
+'REG_NOTES (I)'
+     A list (chain of 'expr_list', 'insn_list' and 'int_list'
+     expressions) giving miscellaneous information about the insn.  It
+     is often information pertaining to the registers used in this insn.
+
+ The 'LOG_LINKS' field of an insn is a chain of 'insn_list' expressions.
+Each of these has two operands: the first is an insn, and the second is
+another 'insn_list' expression (the next one in the chain).  The last
+'insn_list' in the chain has a null pointer as second operand.  The
+significant thing about the chain is which insns appear in it (as first
+operands of 'insn_list' expressions).  Their order is not significant.
+
+ This list is originally set up by the flow analysis pass; it is a null
+pointer until then.  Flow only adds links for those data dependencies
+which can be used for instruction combination.  For each insn, the flow
+analysis pass adds a link to insns which store into registers values
+that are used for the first time in this insn.
+
+ The 'REG_NOTES' field of an insn is a chain similar to the 'LOG_LINKS'
+field but it includes 'expr_list' and 'int_list' expressions in addition
+to 'insn_list' expressions.  There are several kinds of register notes,
+which are distinguished by the machine mode, which in a register note is
+really understood as being an 'enum reg_note'.  The first operand OP of
+the note is data whose meaning depends on the kind of note.
+
+ The macro 'REG_NOTE_KIND (X)' returns the kind of register note.  Its
+counterpart, the macro 'PUT_REG_NOTE_KIND (X, NEWKIND)' sets the
+register note type of X to be NEWKIND.
+
+ Register notes are of three classes: They may say something about an
+input to an insn, they may say something about an output of an insn, or
+they may create a linkage between two insns.  There are also a set of
+values that are only used in 'LOG_LINKS'.
+
+ These register notes annotate inputs to an insn:
+
+'REG_DEAD'
+     The value in OP dies in this insn; that is to say, altering the
+     value immediately after this insn would not affect the future
+     behavior of the program.
+
+     It does not follow that the register OP has no useful value after
+     this insn since OP is not necessarily modified by this insn.
+     Rather, no subsequent instruction uses the contents of OP.
+
+'REG_UNUSED'
+     The register OP being set by this insn will not be used in a
+     subsequent insn.  This differs from a 'REG_DEAD' note, which
+     indicates that the value in an input will not be used subsequently.
+     These two notes are independent; both may be present for the same
+     register.
+
+'REG_INC'
+     The register OP is incremented (or decremented; at this level there
+     is no distinction) by an embedded side effect inside this insn.
+     This means it appears in a 'post_inc', 'pre_inc', 'post_dec' or
+     'pre_dec' expression.
+
+'REG_NONNEG'
+     The register OP is known to have a nonnegative value when this insn
+     is reached.  This is used so that decrement and branch until zero
+     instructions, such as the m68k dbra, can be matched.
+
+     The 'REG_NONNEG' note is added to insns only if the machine
+     description has a 'decrement_and_branch_until_zero' pattern.
+
+'REG_LABEL_OPERAND'
+     This insn uses OP, a 'code_label' or a 'note' of type
+     'NOTE_INSN_DELETED_LABEL', but is not a 'jump_insn', or it is a
+     'jump_insn' that refers to the operand as an ordinary operand.  The
+     label may still eventually be a jump target, but if so in an
+     indirect jump in a subsequent insn.  The presence of this note
+     allows jump optimization to be aware that OP is, in fact, being
+     used, and flow optimization to build an accurate flow graph.
+
+'REG_LABEL_TARGET'
+     This insn is a 'jump_insn' but not an 'addr_vec' or
+     'addr_diff_vec'.  It uses OP, a 'code_label' as a direct or
+     indirect jump target.  Its purpose is similar to that of
+     'REG_LABEL_OPERAND'.  This note is only present if the insn has
+     multiple targets; the last label in the insn (in the highest
+     numbered insn-field) goes into the 'JUMP_LABEL' field and does not
+     have a 'REG_LABEL_TARGET' note.  *Note JUMP_LABEL: Insns.
+
+'REG_CROSSING_JUMP'
+     This insn is a branching instruction (either an unconditional jump
+     or an indirect jump) which crosses between hot and cold sections,
+     which could potentially be very far apart in the executable.  The
+     presence of this note indicates to other optimizations that this
+     branching instruction should not be "collapsed" into a simpler
+     branching construct.  It is used when the optimization to partition
+     basic blocks into hot and cold sections is turned on.
+
+'REG_SETJMP'
+     Appears attached to each 'CALL_INSN' to 'setjmp' or a related
+     function.
+
+ The following notes describe attributes of outputs of an insn:
+
+'REG_EQUIV'
+'REG_EQUAL'
+     This note is only valid on an insn that sets only one register and
+     indicates that that register will be equal to OP at run time; the
+     scope of this equivalence differs between the two types of notes.
+     The value which the insn explicitly copies into the register may
+     look different from OP, but they will be equal at run time.  If the
+     output of the single 'set' is a 'strict_low_part' expression, the
+     note refers to the register that is contained in 'SUBREG_REG' of
+     the 'subreg' expression.
+
+     For 'REG_EQUIV', the register is equivalent to OP throughout the
+     entire function, and could validly be replaced in all its
+     occurrences by OP.  ("Validly" here refers to the data flow of the
+     program; simple replacement may make some insns invalid.)  For
+     example, when a constant is loaded into a register that is never
+     assigned any other value, this kind of note is used.
+
+     When a parameter is copied into a pseudo-register at entry to a
+     function, a note of this kind records that the register is
+     equivalent to the stack slot where the parameter was passed.
+     Although in this case the register may be set by other insns, it is
+     still valid to replace the register by the stack slot throughout
+     the function.
+
+     A 'REG_EQUIV' note is also used on an instruction which copies a
+     register parameter into a pseudo-register at entry to a function,
+     if there is a stack slot where that parameter could be stored.
+     Although other insns may set the pseudo-register, it is valid for
+     the compiler to replace the pseudo-register by stack slot
+     throughout the function, provided the compiler ensures that the
+     stack slot is properly initialized by making the replacement in the
+     initial copy instruction as well.  This is used on machines for
+     which the calling convention allocates stack space for register
+     parameters.  See 'REG_PARM_STACK_SPACE' in *note Stack Arguments::.
+
+     In the case of 'REG_EQUAL', the register that is set by this insn
+     will be equal to OP at run time at the end of this insn but not
+     necessarily elsewhere in the function.  In this case, OP is
+     typically an arithmetic expression.  For example, when a sequence
+     of insns such as a library call is used to perform an arithmetic
+     operation, this kind of note is attached to the insn that produces
+     or copies the final value.
+
+     These two notes are used in different ways by the compiler passes.
+     'REG_EQUAL' is used by passes prior to register allocation (such as
+     common subexpression elimination and loop optimization) to tell
+     them how to think of that value.  'REG_EQUIV' notes are used by
+     register allocation to indicate that there is an available
+     substitute expression (either a constant or a 'mem' expression for
+     the location of a parameter on the stack) that may be used in place
+     of a register if insufficient registers are available.
+
+     Except for stack homes for parameters, which are indicated by a
+     'REG_EQUIV' note and are not useful to the early optimization
+     passes and pseudo registers that are equivalent to a memory
+     location throughout their entire life, which is not detected until
+     later in the compilation, all equivalences are initially indicated
+     by an attached 'REG_EQUAL' note.  In the early stages of register
+     allocation, a 'REG_EQUAL' note is changed into a 'REG_EQUIV' note
+     if OP is a constant and the insn represents the only set of its
+     destination register.
+
+     Thus, compiler passes prior to register allocation need only check
+     for 'REG_EQUAL' notes and passes subsequent to register allocation
+     need only check for 'REG_EQUIV' notes.
+
+ These notes describe linkages between insns.  They occur in pairs: one
+insn has one of a pair of notes that points to a second insn, which has
+the inverse note pointing back to the first insn.
+
+'REG_CC_SETTER'
+'REG_CC_USER'
+     On machines that use 'cc0', the insns which set and use 'cc0' set
+     and use 'cc0' are adjacent.  However, when branch delay slot
+     filling is done, this may no longer be true.  In this case a
+     'REG_CC_USER' note will be placed on the insn setting 'cc0' to
+     point to the insn using 'cc0' and a 'REG_CC_SETTER' note will be
+     placed on the insn using 'cc0' to point to the insn setting 'cc0'.
+
+ These values are only used in the 'LOG_LINKS' field, and indicate the
+type of dependency that each link represents.  Links which indicate a
+data dependence (a read after write dependence) do not use any code,
+they simply have mode 'VOIDmode', and are printed without any
+descriptive text.
+
+'REG_DEP_TRUE'
+     This indicates a true dependence (a read after write dependence).
+
+'REG_DEP_OUTPUT'
+     This indicates an output dependence (a write after write
+     dependence).
+
+'REG_DEP_ANTI'
+     This indicates an anti dependence (a write after read dependence).
+
+ These notes describe information gathered from gcov profile data.  They
+are stored in the 'REG_NOTES' field of an insn.
+
+'REG_BR_PROB'
+     This is used to specify the ratio of branches to non-branches of a
+     branch insn according to the profile data.  The note is represented
+     as an 'int_list' expression whose integer value is between 0 and
+     REG_BR_PROB_BASE. Larger values indicate a higher probability that
+     the branch will be taken.
+
+'REG_BR_PRED'
+     These notes are found in JUMP insns after delayed branch scheduling
+     has taken place.  They indicate both the direction and the
+     likelihood of the JUMP.  The format is a bitmask of ATTR_FLAG_*
+     values.
+
+'REG_FRAME_RELATED_EXPR'
+     This is used on an RTX_FRAME_RELATED_P insn wherein the attached
+     expression is used in place of the actual insn pattern.  This is
+     done in cases where the pattern is either complex or misleading.
+
+ For convenience, the machine mode in an 'insn_list' or 'expr_list' is
+printed using these symbolic codes in debugging dumps.
+
+ The only difference between the expression codes 'insn_list' and
+'expr_list' is that the first operand of an 'insn_list' is assumed to be
+an insn and is printed in debugging dumps as the insn's unique id; the
+first operand of an 'expr_list' is printed in the ordinary way as an
+expression.
+
+
+File: gccint.info,  Node: Calls,  Next: Sharing,  Prev: Insns,  Up: RTL
+
+13.20 RTL Representation of Function-Call Insns
+===============================================
+
+Insns that call subroutines have the RTL expression code 'call_insn'.
+These insns must satisfy special rules, and their bodies must use a
+special RTL expression code, 'call'.
+
+ A 'call' expression has two operands, as follows:
+
+     (call (mem:FM ADDR) NBYTES)
+
+Here NBYTES is an operand that represents the number of bytes of
+argument data being passed to the subroutine, FM is a machine mode
+(which must equal as the definition of the 'FUNCTION_MODE' macro in the
+machine description) and ADDR represents the address of the subroutine.
+
+ For a subroutine that returns no value, the 'call' expression as shown
+above is the entire body of the insn, except that the insn might also
+contain 'use' or 'clobber' expressions.
+
+ For a subroutine that returns a value whose mode is not 'BLKmode', the
+value is returned in a hard register.  If this register's number is R,
+then the body of the call insn looks like this:
+
+     (set (reg:M R)
+          (call (mem:FM ADDR) NBYTES))
+
+This RTL expression makes it clear (to the optimizer passes) that the
+appropriate register receives a useful value in this insn.
+
+ When a subroutine returns a 'BLKmode' value, it is handled by passing
+to the subroutine the address of a place to store the value.  So the
+call insn itself does not "return" any value, and it has the same RTL
+form as a call that returns nothing.
+
+ On some machines, the call instruction itself clobbers some register,
+for example to contain the return address.  'call_insn' insns on these
+machines should have a body which is a 'parallel' that contains both the
+'call' expression and 'clobber' expressions that indicate which
+registers are destroyed.  Similarly, if the call instruction requires
+some register other than the stack pointer that is not explicitly
+mentioned in its RTL, a 'use' subexpression should mention that
+register.
+
+ Functions that are called are assumed to modify all registers listed in
+the configuration macro 'CALL_USED_REGISTERS' (*note Register Basics::)
+and, with the exception of 'const' functions and library calls, to
+modify all of memory.
+
+ Insns containing just 'use' expressions directly precede the
+'call_insn' insn to indicate which registers contain inputs to the
+function.  Similarly, if registers other than those in
+'CALL_USED_REGISTERS' are clobbered by the called function, insns
+containing a single 'clobber' follow immediately after the call to
+indicate which registers.
+
+
+File: gccint.info,  Node: Sharing,  Next: Reading RTL,  Prev: Calls,  Up: RTL
+
+13.21 Structure Sharing Assumptions
+===================================
+
+The compiler assumes that certain kinds of RTL expressions are unique;
+there do not exist two distinct objects representing the same value.  In
+other cases, it makes an opposite assumption: that no RTL expression
+object of a certain kind appears in more than one place in the
+containing structure.
+
+ These assumptions refer to a single function; except for the RTL
+objects that describe global variables and external functions, and a few
+standard objects such as small integer constants, no RTL objects are
+common to two functions.
+
+   * Each pseudo-register has only a single 'reg' object to represent
+     it, and therefore only a single machine mode.
+
+   * For any symbolic label, there is only one 'symbol_ref' object
+     referring to it.
+
+   * All 'const_int' expressions with equal values are shared.
+
+   * There is only one 'pc' expression.
+
+   * There is only one 'cc0' expression.
+
+   * There is only one 'const_double' expression with value 0 for each
+     floating point mode.  Likewise for values 1 and 2.
+
+   * There is only one 'const_vector' expression with value 0 for each
+     vector mode, be it an integer or a double constant vector.
+
+   * No 'label_ref' or 'scratch' appears in more than one place in the
+     RTL structure; in other words, it is safe to do a tree-walk of all
+     the insns in the function and assume that each time a 'label_ref'
+     or 'scratch' is seen it is distinct from all others that are seen.
+
+   * Only one 'mem' object is normally created for each static variable
+     or stack slot, so these objects are frequently shared in all the
+     places they appear.  However, separate but equal objects for these
+     variables are occasionally made.
+
+   * When a single 'asm' statement has multiple output operands, a
+     distinct 'asm_operands' expression is made for each output operand.
+     However, these all share the vector which contains the sequence of
+     input operands.  This sharing is used later on to test whether two
+     'asm_operands' expressions come from the same statement, so all
+     optimizations must carefully preserve the sharing if they copy the
+     vector at all.
+
+   * No RTL object appears in more than one place in the RTL structure
+     except as described above.  Many passes of the compiler rely on
+     this by assuming that they can modify RTL objects in place without
+     unwanted side-effects on other insns.
+
+   * During initial RTL generation, shared structure is freely
+     introduced.  After all the RTL for a function has been generated,
+     all shared structure is copied by 'unshare_all_rtl' in
+     'emit-rtl.c', after which the above rules are guaranteed to be
+     followed.
+
+   * During the combiner pass, shared structure within an insn can exist
+     temporarily.  However, the shared structure is copied before the
+     combiner is finished with the insn.  This is done by calling
+     'copy_rtx_if_shared', which is a subroutine of 'unshare_all_rtl'.
+
+
+File: gccint.info,  Node: Reading RTL,  Prev: Sharing,  Up: RTL
+
+13.22 Reading RTL
+=================
+
+To read an RTL object from a file, call 'read_rtx'.  It takes one
+argument, a stdio stream, and returns a single RTL object.  This routine
+is defined in 'read-rtl.c'.  It is not available in the compiler itself,
+only the various programs that generate the compiler back end from the
+machine description.
+
+ People frequently have the idea of using RTL stored as text in a file
+as an interface between a language front end and the bulk of GCC.  This
+idea is not feasible.
+
+ GCC was designed to use RTL internally only.  Correct RTL for a given
+program is very dependent on the particular target machine.  And the RTL
+does not contain all the information about the program.
+
+ The proper way to interface GCC to a new language front end is with the
+"tree" data structure, described in the files 'tree.h' and 'tree.def'.
+The documentation for this structure (*note GENERIC::) is incomplete.
+
+
+File: gccint.info,  Node: Control Flow,  Next: Loop Analysis and Representation,  Prev: RTL,  Up: Top
+
+14 Control Flow Graph
+*********************
+
+A control flow graph (CFG) is a data structure built on top of the
+intermediate code representation (the RTL or 'GIMPLE' instruction
+stream) abstracting the control flow behavior of a function that is
+being compiled.  The CFG is a directed graph where the vertices
+represent basic blocks and edges represent possible transfer of control
+flow from one basic block to another.  The data structures used to
+represent the control flow graph are defined in 'basic-block.h'.
+
+ In GCC, the representation of control flow is maintained throughout the
+compilation process, from constructing the CFG early in 'pass_build_cfg'
+to 'pass_free_cfg' (see 'passes.def').  The CFG takes various different
+modes and may undergo extensive manipulations, but the graph is always
+valid between its construction and its release.  This way, transfer of
+information such as data flow, a measured profile, or the loop tree, can
+be propagated through the passes pipeline, and even from 'GIMPLE' to
+'RTL'.
+
+ Often the CFG may be better viewed as integral part of instruction
+chain, than structure built on the top of it.  Updating the compiler's
+intermediate representation for instructions can not be easily done
+without proper maintenance of the CFG simultaneously.
+
+* Menu:
+
+* Basic Blocks::           The definition and representation of basic blocks.
+* Edges::                  Types of edges and their representation.
+* Profile information::    Representation of frequencies and probabilities.
+* Maintaining the CFG::    Keeping the control flow graph and up to date.
+* Liveness information::   Using and maintaining liveness information.
+
+
+File: gccint.info,  Node: Basic Blocks,  Next: Edges,  Up: Control Flow
+
+14.1 Basic Blocks
+=================
+
+A basic block is a straight-line sequence of code with only one entry
+point and only one exit.  In GCC, basic blocks are represented using the
+'basic_block' data type.
+
+ Special basic blocks represent possible entry and exit points of a
+function.  These blocks are called 'ENTRY_BLOCK_PTR' and
+'EXIT_BLOCK_PTR'.  These blocks do not contain any code.
+
+ The 'BASIC_BLOCK' array contains all basic blocks in an unspecified
+order.  Each 'basic_block' structure has a field that holds a unique
+integer identifier 'index' that is the index of the block in the
+'BASIC_BLOCK' array.  The total number of basic blocks in the function
+is 'n_basic_blocks'.  Both the basic block indices and the total number
+of basic blocks may vary during the compilation process, as passes
+reorder, create, duplicate, and destroy basic blocks.  The index for any
+block should never be greater than 'last_basic_block'.  The indices 0
+and 1 are special codes reserved for 'ENTRY_BLOCK' and 'EXIT_BLOCK', the
+indices of 'ENTRY_BLOCK_PTR' and 'EXIT_BLOCK_PTR'.
+
+ Two pointer members of the 'basic_block' structure are the pointers
+'next_bb' and 'prev_bb'.  These are used to keep doubly linked chain of
+basic blocks in the same order as the underlying instruction stream.
+The chain of basic blocks is updated transparently by the provided API
+for manipulating the CFG.  The macro 'FOR_EACH_BB' can be used to visit
+all the basic blocks in lexicographical order, except 'ENTRY_BLOCK' and
+'EXIT_BLOCK'.  The macro 'FOR_ALL_BB' also visits all basic blocks in
+lexicographical order, including 'ENTRY_BLOCK' and 'EXIT_BLOCK'.
+
+ The functions 'post_order_compute' and 'inverted_post_order_compute'
+can be used to compute topological orders of the CFG. The orders are
+stored as vectors of basic block indices.  The 'BASIC_BLOCK' array can
+be used to iterate each basic block by index.  Dominator traversals are
+also possible using 'walk_dominator_tree'.  Given two basic blocks A and
+B, block A dominates block B if A is _always_ executed before B.
+
+ Each 'basic_block' also contains pointers to the first instruction (the
+"head") and the last instruction (the "tail") or "end" of the
+instruction stream contained in a basic block.  In fact, since the
+'basic_block' data type is used to represent blocks in both major
+intermediate representations of GCC ('GIMPLE' and RTL), there are
+pointers to the head and end of a basic block for both representations,
+stored in intermediate representation specific data in the 'il' field of
+'struct basic_block_def'.
+
+ For RTL, these pointers are 'BB_HEAD' and 'BB_END'.
+
+ In the RTL representation of a function, the instruction stream
+contains not only the "real" instructions, but also "notes" or "insn
+notes" (to distinguish them from "reg notes").  Any function that moves
+or duplicates the basic blocks needs to take care of updating of these
+notes.  Many of these notes expect that the instruction stream consists
+of linear regions, so updating can sometimes be tedious.  All types of
+insn notes are defined in 'insn-notes.def'.
+
+ In the RTL function representation, the instructions contained in a
+basic block always follow a 'NOTE_INSN_BASIC_BLOCK', but zero or more
+'CODE_LABEL' nodes can precede the block note.  A basic block ends with
+a control flow instruction or with the last instruction before the next
+'CODE_LABEL' or 'NOTE_INSN_BASIC_BLOCK'.  By definition, a 'CODE_LABEL'
+cannot appear in the middle of the instruction stream of a basic block.
+
+ In addition to notes, the jump table vectors are also represented as
+"pseudo-instructions" inside the insn stream.  These vectors never
+appear in the basic block and should always be placed just after the
+table jump instructions referencing them.  After removing the table-jump
+it is often difficult to eliminate the code computing the address and
+referencing the vector, so cleaning up these vectors is postponed until
+after liveness analysis.  Thus the jump table vectors may appear in the
+insn stream unreferenced and without any purpose.  Before any edge is
+made "fall-thru", the existence of such construct in the way needs to be
+checked by calling 'can_fallthru' function.
+
+ For the 'GIMPLE' representation, the PHI nodes and statements contained
+in a basic block are in a 'gimple_seq' pointed to by the basic block
+intermediate language specific pointers.  Abstract containers and
+iterators are used to access the PHI nodes and statements in a basic
+blocks.  These iterators are called "GIMPLE statement iterators" (GSIs).
+Grep for '^gsi' in the various 'gimple-*' and 'tree-*' files.  The
+following snippet will pretty-print all PHI nodes the statements of the
+current function in the GIMPLE representation.
+
+     basic_block bb;
+
+     FOR_EACH_BB (bb)
+       {
+        gimple_stmt_iterator si;
+
+        for (si = gsi_start_phis (bb); !gsi_end_p (si); gsi_next (&si))
+          {
+            gimple phi = gsi_stmt (si);
+            print_gimple_stmt (dump_file, phi, 0, TDF_SLIM);
+          }
+        for (si = gsi_start_bb (bb); !gsi_end_p (si); gsi_next (&si))
+          {
+            gimple stmt = gsi_stmt (si);
+            print_gimple_stmt (dump_file, stmt, 0, TDF_SLIM);
+          }
+       }
+
+
+File: gccint.info,  Node: Edges,  Next: Profile information,  Prev: Basic Blocks,  Up: Control Flow
+
+14.2 Edges
+==========
+
+Edges represent possible control flow transfers from the end of some
+basic block A to the head of another basic block B.  We say that A is a
+predecessor of B, and B is a successor of A.  Edges are represented in
+GCC with the 'edge' data type.  Each 'edge' acts as a link between two
+basic blocks: The 'src' member of an edge points to the predecessor
+basic block of the 'dest' basic block.  The members 'preds' and 'succs'
+of the 'basic_block' data type point to type-safe vectors of edges to
+the predecessors and successors of the block.
+
+ When walking the edges in an edge vector, "edge iterators" should be
+used.  Edge iterators are constructed using the 'edge_iterator' data
+structure and several methods are available to operate on them:
+
+'ei_start'
+     This function initializes an 'edge_iterator' that points to the
+     first edge in a vector of edges.
+
+'ei_last'
+     This function initializes an 'edge_iterator' that points to the
+     last edge in a vector of edges.
+
+'ei_end_p'
+     This predicate is 'true' if an 'edge_iterator' represents the last
+     edge in an edge vector.
+
+'ei_one_before_end_p'
+     This predicate is 'true' if an 'edge_iterator' represents the
+     second last edge in an edge vector.
+
+'ei_next'
+     This function takes a pointer to an 'edge_iterator' and makes it
+     point to the next edge in the sequence.
+
+'ei_prev'
+     This function takes a pointer to an 'edge_iterator' and makes it
+     point to the previous edge in the sequence.
+
+'ei_edge'
+     This function returns the 'edge' currently pointed to by an
+     'edge_iterator'.
+
+'ei_safe_safe'
+     This function returns the 'edge' currently pointed to by an
+     'edge_iterator', but returns 'NULL' if the iterator is pointing at
+     the end of the sequence.  This function has been provided for
+     existing code makes the assumption that a 'NULL' edge indicates the
+     end of the sequence.
+
+ The convenience macro 'FOR_EACH_EDGE' can be used to visit all of the
+edges in a sequence of predecessor or successor edges.  It must not be
+used when an element might be removed during the traversal, otherwise
+elements will be missed.  Here is an example of how to use the macro:
+
+     edge e;
+     edge_iterator ei;
+
+     FOR_EACH_EDGE (e, ei, bb->succs)
+       {
+          if (e->flags & EDGE_FALLTHRU)
+            break;
+       }
+
+ There are various reasons why control flow may transfer from one block
+to another.  One possibility is that some instruction, for example a
+'CODE_LABEL', in a linearized instruction stream just always starts a
+new basic block.  In this case a "fall-thru" edge links the basic block
+to the first following basic block.  But there are several other reasons
+why edges may be created.  The 'flags' field of the 'edge' data type is
+used to store information about the type of edge we are dealing with.
+Each edge is of one of the following types:
+
+_jump_
+     No type flags are set for edges corresponding to jump instructions.
+     These edges are used for unconditional or conditional jumps and in
+     RTL also for table jumps.  They are the easiest to manipulate as
+     they may be freely redirected when the flow graph is not in SSA
+     form.
+
+_fall-thru_
+     Fall-thru edges are present in case where the basic block may
+     continue execution to the following one without branching.  These
+     edges have the 'EDGE_FALLTHRU' flag set.  Unlike other types of
+     edges, these edges must come into the basic block immediately
+     following in the instruction stream.  The function
+     'force_nonfallthru' is available to insert an unconditional jump in
+     the case that redirection is needed.  Note that this may require
+     creation of a new basic block.
+
+_exception handling_
+     Exception handling edges represent possible control transfers from
+     a trapping instruction to an exception handler.  The definition of
+     "trapping" varies.  In C++, only function calls can throw, but for
+     Java and Ada, exceptions like division by zero or segmentation
+     fault are defined and thus each instruction possibly throwing this
+     kind of exception needs to be handled as control flow instruction.
+     Exception edges have the 'EDGE_ABNORMAL' and 'EDGE_EH' flags set.
+
+     When updating the instruction stream it is easy to change possibly
+     trapping instruction to non-trapping, by simply removing the
+     exception edge.  The opposite conversion is difficult, but should
+     not happen anyway.  The edges can be eliminated via
+     'purge_dead_edges' call.
+
+     In the RTL representation, the destination of an exception edge is
+     specified by 'REG_EH_REGION' note attached to the insn.  In case of
+     a trapping call the 'EDGE_ABNORMAL_CALL' flag is set too.  In the
+     'GIMPLE' representation, this extra flag is not set.
+
+     In the RTL representation, the predicate 'may_trap_p' may be used
+     to check whether instruction still may trap or not.  For the tree
+     representation, the 'tree_could_trap_p' predicate is available, but
+     this predicate only checks for possible memory traps, as in
+     dereferencing an invalid pointer location.
+
+_sibling calls_
+     Sibling calls or tail calls terminate the function in a
+     non-standard way and thus an edge to the exit must be present.
+     'EDGE_SIBCALL' and 'EDGE_ABNORMAL' are set in such case.  These
+     edges only exist in the RTL representation.
+
+_computed jumps_
+     Computed jumps contain edges to all labels in the function
+     referenced from the code.  All those edges have 'EDGE_ABNORMAL'
+     flag set.  The edges used to represent computed jumps often cause
+     compile time performance problems, since functions consisting of
+     many taken labels and many computed jumps may have _very_ dense
+     flow graphs, so these edges need to be handled with special care.
+     During the earlier stages of the compilation process, GCC tries to
+     avoid such dense flow graphs by factoring computed jumps.  For
+     example, given the following series of jumps,
+
+            goto *x;
+            [ ... ]
+
+            goto *x;
+            [ ... ]
+
+            goto *x;
+            [ ... ]
+
+     factoring the computed jumps results in the following code sequence
+     which has a much simpler flow graph:
+
+            goto y;
+            [ ... ]
+
+            goto y;
+            [ ... ]
+
+            goto y;
+            [ ... ]
+
+          y:
+            goto *x;
+
+     However, the classic problem with this transformation is that it
+     has a runtime cost in there resulting code: An extra jump.
+     Therefore, the computed jumps are un-factored in the later passes
+     of the compiler (in the pass called
+     'pass_duplicate_computed_gotos').  Be aware of that when you work
+     on passes in that area.  There have been numerous examples already
+     where the compile time for code with unfactored computed jumps
+     caused some serious headaches.
+
+_nonlocal goto handlers_
+     GCC allows nested functions to return into caller using a 'goto' to
+     a label passed to as an argument to the callee.  The labels passed
+     to nested functions contain special code to cleanup after function
+     call.  Such sections of code are referred to as "nonlocal goto
+     receivers".  If a function contains such nonlocal goto receivers,
+     an edge from the call to the label is created with the
+     'EDGE_ABNORMAL' and 'EDGE_ABNORMAL_CALL' flags set.
+
+_function entry points_
+     By definition, execution of function starts at basic block 0, so
+     there is always an edge from the 'ENTRY_BLOCK_PTR' to basic block
+     0.  There is no 'GIMPLE' representation for alternate entry points
+     at this moment.  In RTL, alternate entry points are specified by
+     'CODE_LABEL' with 'LABEL_ALTERNATE_NAME' defined.  This feature is
+     currently used for multiple entry point prologues and is limited to
+     post-reload passes only.  This can be used by back-ends to emit
+     alternate prologues for functions called from different contexts.
+     In future full support for multiple entry functions defined by
+     Fortran 90 needs to be implemented.
+
+_function exits_
+     In the pre-reload representation a function terminates after the
+     last instruction in the insn chain and no explicit return
+     instructions are used.  This corresponds to the fall-thru edge into
+     exit block.  After reload, optimal RTL epilogues are used that use
+     explicit (conditional) return instructions that are represented by
+     edges with no flags set.
+
+
+File: gccint.info,  Node: Profile information,  Next: Maintaining the CFG,  Prev: Edges,  Up: Control Flow
+
+14.3 Profile information
+========================
+
+In many cases a compiler must make a choice whether to trade speed in
+one part of code for speed in another, or to trade code size for code
+speed.  In such cases it is useful to know information about how often
+some given block will be executed.  That is the purpose for maintaining
+profile within the flow graph.  GCC can handle profile information
+obtained through "profile feedback", but it can also estimate branch
+probabilities based on statics and heuristics.
+
+ The feedback based profile is produced by compiling the program with
+instrumentation, executing it on a train run and reading the numbers of
+executions of basic blocks and edges back to the compiler while
+re-compiling the program to produce the final executable.  This method
+provides very accurate information about where a program spends most of
+its time on the train run.  Whether it matches the average run of course
+depends on the choice of train data set, but several studies have shown
+that the behavior of a program usually changes just marginally over
+different data sets.
+
+ When profile feedback is not available, the compiler may be asked to
+attempt to predict the behavior of each branch in the program using a
+set of heuristics (see 'predict.def' for details) and compute estimated
+frequencies of each basic block by propagating the probabilities over
+the graph.
+
+ Each 'basic_block' contains two integer fields to represent profile
+information: 'frequency' and 'count'.  The 'frequency' is an estimation
+how often is basic block executed within a function.  It is represented
+as an integer scaled in the range from 0 to 'BB_FREQ_BASE'.  The most
+frequently executed basic block in function is initially set to
+'BB_FREQ_BASE' and the rest of frequencies are scaled accordingly.
+During optimization, the frequency of the most frequent basic block can
+both decrease (for instance by loop unrolling) or grow (for instance by
+cross-jumping optimization), so scaling sometimes has to be performed
+multiple times.
+
+ The 'count' contains hard-counted numbers of execution measured during
+training runs and is nonzero only when profile feedback is available.
+This value is represented as the host's widest integer (typically a 64
+bit integer) of the special type 'gcov_type'.
+
+ Most optimization passes can use only the frequency information of a
+basic block, but a few passes may want to know hard execution counts.
+The frequencies should always match the counts after scaling, however
+during updating of the profile information numerical error may
+accumulate into quite large errors.
+
+ Each edge also contains a branch probability field: an integer in the
+range from 0 to 'REG_BR_PROB_BASE'.  It represents probability of
+passing control from the end of the 'src' basic block to the 'dest'
+basic block, i.e. the probability that control will flow along this
+edge.  The 'EDGE_FREQUENCY' macro is available to compute how frequently
+a given edge is taken.  There is a 'count' field for each edge as well,
+representing same information as for a basic block.
+
+ The basic block frequencies are not represented in the instruction
+stream, but in the RTL representation the edge frequencies are
+represented for conditional jumps (via the 'REG_BR_PROB' macro) since
+they are used when instructions are output to the assembly file and the
+flow graph is no longer maintained.
+
+ The probability that control flow arrives via a given edge to its
+destination basic block is called "reverse probability" and is not
+directly represented, but it may be easily computed from frequencies of
+basic blocks.
+
+ Updating profile information is a delicate task that can unfortunately
+not be easily integrated with the CFG manipulation API.  Many of the
+functions and hooks to modify the CFG, such as
+'redirect_edge_and_branch', do not have enough information to easily
+update the profile, so updating it is in the majority of cases left up
+to the caller.  It is difficult to uncover bugs in the profile updating
+code, because they manifest themselves only by producing worse code, and
+checking profile consistency is not possible because of numeric error
+accumulation.  Hence special attention needs to be given to this issue
+in each pass that modifies the CFG.
+
+ It is important to point out that 'REG_BR_PROB_BASE' and 'BB_FREQ_BASE'
+are both set low enough to be possible to compute second power of any
+frequency or probability in the flow graph, it is not possible to even
+square the 'count' field, as modern CPUs are fast enough to execute
+$2^32$ operations quickly.
+
+
+File: gccint.info,  Node: Maintaining the CFG,  Next: Liveness information,  Prev: Profile information,  Up: Control Flow
+
+14.4 Maintaining the CFG
+========================
+
+An important task of each compiler pass is to keep both the control flow
+graph and all profile information up-to-date.  Reconstruction of the
+control flow graph after each pass is not an option, since it may be
+very expensive and lost profile information cannot be reconstructed at
+all.
+
+ GCC has two major intermediate representations, and both use the
+'basic_block' and 'edge' data types to represent control flow.  Both
+representations share as much of the CFG maintenance code as possible.
+For each representation, a set of "hooks" is defined so that each
+representation can provide its own implementation of CFG manipulation
+routines when necessary.  These hooks are defined in 'cfghooks.h'.
+There are hooks for almost all common CFG manipulations, including block
+splitting and merging, edge redirection and creating and deleting basic
+blocks.  These hooks should provide everything you need to maintain and
+manipulate the CFG in both the RTL and 'GIMPLE' representation.
+
+ At the moment, the basic block boundaries are maintained transparently
+when modifying instructions, so there rarely is a need to move them
+manually (such as in case someone wants to output instruction outside
+basic block explicitly).
+
+ In the RTL representation, each instruction has a 'BLOCK_FOR_INSN'
+value that represents pointer to the basic block that contains the
+instruction.  In the 'GIMPLE' representation, the function 'gimple_bb'
+returns a pointer to the basic block containing the queried statement.
+
+ When changes need to be applied to a function in its 'GIMPLE'
+representation, "GIMPLE statement iterators" should be used.  These
+iterators provide an integrated abstraction of the flow graph and the
+instruction stream.  Block statement iterators are constructed using the
+'gimple_stmt_iterator' data structure and several modifier are
+available, including the following:
+
+'gsi_start'
+     This function initializes a 'gimple_stmt_iterator' that points to
+     the first non-empty statement in a basic block.
+
+'gsi_last'
+     This function initializes a 'gimple_stmt_iterator' that points to
+     the last statement in a basic block.
+
+'gsi_end_p'
+     This predicate is 'true' if a 'gimple_stmt_iterator' represents the
+     end of a basic block.
+
+'gsi_next'
+     This function takes a 'gimple_stmt_iterator' and makes it point to
+     its successor.
+
+'gsi_prev'
+     This function takes a 'gimple_stmt_iterator' and makes it point to
+     its predecessor.
+
+'gsi_insert_after'
+     This function inserts a statement after the 'gimple_stmt_iterator'
+     passed in.  The final parameter determines whether the statement
+     iterator is updated to point to the newly inserted statement, or
+     left pointing to the original statement.
+
+'gsi_insert_before'
+     This function inserts a statement before the 'gimple_stmt_iterator'
+     passed in.  The final parameter determines whether the statement
+     iterator is updated to point to the newly inserted statement, or
+     left pointing to the original statement.
+
+'gsi_remove'
+     This function removes the 'gimple_stmt_iterator' passed in and
+     rechains the remaining statements in a basic block, if any.
+
+ In the RTL representation, the macros 'BB_HEAD' and 'BB_END' may be
+used to get the head and end 'rtx' of a basic block.  No abstract
+iterators are defined for traversing the insn chain, but you can just
+use 'NEXT_INSN' and 'PREV_INSN' instead.  *Note Insns::.
+
+ Usually a code manipulating pass simplifies the instruction stream and
+the flow of control, possibly eliminating some edges.  This may for
+example happen when a conditional jump is replaced with an unconditional
+jump, but also when simplifying possibly trapping instruction to
+non-trapping while compiling Java.  Updating of edges is not transparent
+and each optimization pass is required to do so manually.  However only
+few cases occur in practice.  The pass may call 'purge_dead_edges' on a
+given basic block to remove superfluous edges, if any.
+
+ Another common scenario is redirection of branch instructions, but this
+is best modeled as redirection of edges in the control flow graph and
+thus use of 'redirect_edge_and_branch' is preferred over more low level
+functions, such as 'redirect_jump' that operate on RTL chain only.  The
+CFG hooks defined in 'cfghooks.h' should provide the complete API
+required for manipulating and maintaining the CFG.
+
+ It is also possible that a pass has to insert control flow instruction
+into the middle of a basic block, thus creating an entry point in the
+middle of the basic block, which is impossible by definition: The block
+must be split to make sure it only has one entry point, i.e. the head of
+the basic block.  The CFG hook 'split_block' may be used when an
+instruction in the middle of a basic block has to become the target of a
+jump or branch instruction.
+
+ For a global optimizer, a common operation is to split edges in the
+flow graph and insert instructions on them.  In the RTL representation,
+this can be easily done using the 'insert_insn_on_edge' function that
+emits an instruction "on the edge", caching it for a later
+'commit_edge_insertions' call that will take care of moving the inserted
+instructions off the edge into the instruction stream contained in a
+basic block.  This includes the creation of new basic blocks where
+needed.  In the 'GIMPLE' representation, the equivalent functions are
+'gsi_insert_on_edge' which inserts a block statement iterator on an
+edge, and 'gsi_commit_edge_inserts' which flushes the instruction to
+actual instruction stream.
+
+ While debugging the optimization pass, the 'verify_flow_info' function
+may be useful to find bugs in the control flow graph updating code.
+
+
+File: gccint.info,  Node: Liveness information,  Prev: Maintaining the CFG,  Up: Control Flow
+
+14.5 Liveness information
+=========================
+
+Liveness information is useful to determine whether some register is
+"live" at given point of program, i.e. that it contains a value that may
+be used at a later point in the program.  This information is used, for
+instance, during register allocation, as the pseudo registers only need
+to be assigned to a unique hard register or to a stack slot if they are
+live.  The hard registers and stack slots may be freely reused for other
+values when a register is dead.
+
+ Liveness information is available in the back end starting with
+'pass_df_initialize' and ending with 'pass_df_finish'.  Three flavors of
+live analysis are available: With 'LR', it is possible to determine at
+any point 'P' in the function if the register may be used on some path
+from 'P' to the end of the function.  With 'UR', it is possible to
+determine if there is a path from the beginning of the function to 'P'
+that defines the variable.  'LIVE' is the intersection of the 'LR' and
+'UR' and a variable is live at 'P' if there is both an assignment that
+reaches it from the beginning of the function and a use that can be
+reached on some path from 'P' to the end of the function.
+
+ In general 'LIVE' is the most useful of the three.  The macros
+'DF_[LR,UR,LIVE]_[IN,OUT]' can be used to access this information.  The
+macros take a basic block number and return a bitmap that is indexed by
+the register number.  This information is only guaranteed to be up to
+date after calls are made to 'df_analyze'.  See the file 'df-core.c' for
+details on using the dataflow.
+
+ The liveness information is stored partly in the RTL instruction stream
+and partly in the flow graph.  Local information is stored in the
+instruction stream: Each instruction may contain 'REG_DEAD' notes
+representing that the value of a given register is no longer needed, or
+'REG_UNUSED' notes representing that the value computed by the
+instruction is never used.  The second is useful for instructions
+computing multiple values at once.
+
+
+File: gccint.info,  Node: Loop Analysis and Representation,  Next: Machine Desc,  Prev: Control Flow,  Up: Top
+
+15 Analysis and Representation of Loops
+***************************************
+
+GCC provides extensive infrastructure for work with natural loops, i.e.,
+strongly connected components of CFG with only one entry block.  This
+chapter describes representation of loops in GCC, both on GIMPLE and in
+RTL, as well as the interfaces to loop-related analyses (induction
+variable analysis and number of iterations analysis).
+
+* Menu:
+
+* Loop representation::         Representation and analysis of loops.
+* Loop querying::               Getting information about loops.
+* Loop manipulation::           Loop manipulation functions.
+* LCSSA::                       Loop-closed SSA form.
+* Scalar evolutions::           Induction variables on GIMPLE.
+* loop-iv::                     Induction variables on RTL.
+* Number of iterations::        Number of iterations analysis.
+* Dependency analysis::         Data dependency analysis.
+* Omega::                       A solver for linear programming problems.
+
+
+File: gccint.info,  Node: Loop representation,  Next: Loop querying,  Up: Loop Analysis and Representation
+
+15.1 Loop representation
+========================
+
+This chapter describes the representation of loops in GCC, and functions
+that can be used to build, modify and analyze this representation.  Most
+of the interfaces and data structures are declared in 'cfgloop.h'.  Loop
+structures are analyzed and this information disposed or updated at the
+discretion of individual passes.  Still most of the generic CFG
+manipulation routines are aware of loop structures and try to keep them
+up-to-date.  By this means an increasing part of the compilation
+pipeline is setup to maintain loop structure across passes to allow
+attaching meta information to individual loops for consumption by later
+passes.
+
+ In general, a natural loop has one entry block (header) and possibly
+several back edges (latches) leading to the header from the inside of
+the loop.  Loops with several latches may appear if several loops share
+a single header, or if there is a branching in the middle of the loop.
+The representation of loops in GCC however allows only loops with a
+single latch.  During loop analysis, headers of such loops are split and
+forwarder blocks are created in order to disambiguate their structures.
+Heuristic based on profile information and structure of the induction
+variables in the loops is used to determine whether the latches
+correspond to sub-loops or to control flow in a single loop.  This means
+that the analysis sometimes changes the CFG, and if you run it in the
+middle of an optimization pass, you must be able to deal with the new
+blocks.  You may avoid CFG changes by passing
+'LOOPS_MAY_HAVE_MULTIPLE_LATCHES' flag to the loop discovery, note
+however that most other loop manipulation functions will not work
+correctly for loops with multiple latch edges (the functions that only
+query membership of blocks to loops and subloop relationships, or
+enumerate and test loop exits, can be expected to work).
+
+ Body of the loop is the set of blocks that are dominated by its header,
+and reachable from its latch against the direction of edges in CFG.  The
+loops are organized in a containment hierarchy (tree) such that all the
+loops immediately contained inside loop L are the children of L in the
+tree.  This tree is represented by the 'struct loops' structure.  The
+root of this tree is a fake loop that contains all blocks in the
+function.  Each of the loops is represented in a 'struct loop'
+structure.  Each loop is assigned an index ('num' field of the 'struct
+loop' structure), and the pointer to the loop is stored in the
+corresponding field of the 'larray' vector in the loops structure.  The
+indices do not have to be continuous, there may be empty ('NULL')
+entries in the 'larray' created by deleting loops.  Also, there is no
+guarantee on the relative order of a loop and its subloops in the
+numbering.  The index of a loop never changes.
+
+ The entries of the 'larray' field should not be accessed directly.  The
+function 'get_loop' returns the loop description for a loop with the
+given index.  'number_of_loops' function returns number of loops in the
+function.  To traverse all loops, use 'FOR_EACH_LOOP' macro.  The
+'flags' argument of the macro is used to determine the direction of
+traversal and the set of loops visited.  Each loop is guaranteed to be
+visited exactly once, regardless of the changes to the loop tree, and
+the loops may be removed during the traversal.  The newly created loops
+are never traversed, if they need to be visited, this must be done
+separately after their creation.  The 'FOR_EACH_LOOP' macro allocates
+temporary variables.  If the 'FOR_EACH_LOOP' loop were ended using break
+or goto, they would not be released; 'FOR_EACH_LOOP_BREAK' macro must be
+used instead.
+
+ Each basic block contains the reference to the innermost loop it
+belongs to ('loop_father').  For this reason, it is only possible to
+have one 'struct loops' structure initialized at the same time for each
+CFG.  The global variable 'current_loops' contains the 'struct loops'
+structure.  Many of the loop manipulation functions assume that
+dominance information is up-to-date.
+
+ The loops are analyzed through 'loop_optimizer_init' function.  The
+argument of this function is a set of flags represented in an integer
+bitmask.  These flags specify what other properties of the loop
+structures should be calculated/enforced and preserved later:
+
+   * 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES': If this flag is set, no changes
+     to CFG will be performed in the loop analysis, in particular, loops
+     with multiple latch edges will not be disambiguated.  If a loop has
+     multiple latches, its latch block is set to NULL.  Most of the loop
+     manipulation functions will not work for loops in this shape.  No
+     other flags that require CFG changes can be passed to
+     loop_optimizer_init.
+   * 'LOOPS_HAVE_PREHEADERS': Forwarder blocks are created in such a way
+     that each loop has only one entry edge, and additionally, the
+     source block of this entry edge has only one successor.  This
+     creates a natural place where the code can be moved out of the
+     loop, and ensures that the entry edge of the loop leads from its
+     immediate super-loop.
+   * 'LOOPS_HAVE_SIMPLE_LATCHES': Forwarder blocks are created to force
+     the latch block of each loop to have only one successor.  This
+     ensures that the latch of the loop does not belong to any of its
+     sub-loops, and makes manipulation with the loops significantly
+     easier.  Most of the loop manipulation functions assume that the
+     loops are in this shape.  Note that with this flag, the "normal"
+     loop without any control flow inside and with one exit consists of
+     two basic blocks.
+   * 'LOOPS_HAVE_MARKED_IRREDUCIBLE_REGIONS': Basic blocks and edges in
+     the strongly connected components that are not natural loops (have
+     more than one entry block) are marked with 'BB_IRREDUCIBLE_LOOP'
+     and 'EDGE_IRREDUCIBLE_LOOP' flags.  The flag is not set for blocks
+     and edges that belong to natural loops that are in such an
+     irreducible region (but it is set for the entry and exit edges of
+     such a loop, if they lead to/from this region).
+   * 'LOOPS_HAVE_RECORDED_EXITS': The lists of exits are recorded and
+     updated for each loop.  This makes some functions (e.g.,
+     'get_loop_exit_edges') more efficient.  Some functions (e.g.,
+     'single_exit') can be used only if the lists of exits are recorded.
+
+ These properties may also be computed/enforced later, using functions
+'create_preheaders', 'force_single_succ_latches',
+'mark_irreducible_loops' and 'record_loop_exits'.  The properties can be
+queried using 'loops_state_satisfies_p'.
+
+ The memory occupied by the loops structures should be freed with
+'loop_optimizer_finalize' function.  When loop structures are setup to
+be preserved across passes this function reduces the information to be
+kept up-to-date to a minimum (only 'LOOPS_MAY_HAVE_MULTIPLE_LATCHES'
+set).
+
+ The CFG manipulation functions in general do not update loop
+structures.  Specialized versions that additionally do so are provided
+for the most common tasks.  On GIMPLE, 'cleanup_tree_cfg_loop' function
+can be used to cleanup CFG while updating the loops structures if
+'current_loops' is set.
+
+ At the moment loop structure is preserved from the start of GIMPLE loop
+optimizations until the end of RTL loop optimizations.  During this time
+a loop can be tracked by its 'struct loop' and number.
+
+
+File: gccint.info,  Node: Loop querying,  Next: Loop manipulation,  Prev: Loop representation,  Up: Loop Analysis and Representation
+
+15.2 Loop querying
+==================
+
+The functions to query the information about loops are declared in
+'cfgloop.h'.  Some of the information can be taken directly from the
+structures.  'loop_father' field of each basic block contains the
+innermost loop to that the block belongs.  The most useful fields of
+loop structure (that are kept up-to-date at all times) are:
+
+   * 'header', 'latch': Header and latch basic blocks of the loop.
+   * 'num_nodes': Number of basic blocks in the loop (including the
+     basic blocks of the sub-loops).
+   * 'depth': The depth of the loop in the loops tree, i.e., the number
+     of super-loops of the loop.
+   * 'outer', 'inner', 'next': The super-loop, the first sub-loop, and
+     the sibling of the loop in the loops tree.
+
+ There are other fields in the loop structures, many of them used only
+by some of the passes, or not updated during CFG changes; in general,
+they should not be accessed directly.
+
+ The most important functions to query loop structures are:
+
+   * 'flow_loops_dump': Dumps the information about loops to a file.
+   * 'verify_loop_structure': Checks consistency of the loop structures.
+   * 'loop_latch_edge': Returns the latch edge of a loop.
+   * 'loop_preheader_edge': If loops have preheaders, returns the
+     preheader edge of a loop.
+   * 'flow_loop_nested_p': Tests whether loop is a sub-loop of another
+     loop.
+   * 'flow_bb_inside_loop_p': Tests whether a basic block belongs to a
+     loop (including its sub-loops).
+   * 'find_common_loop': Finds the common super-loop of two loops.
+   * 'superloop_at_depth': Returns the super-loop of a loop with the
+     given depth.
+   * 'tree_num_loop_insns', 'num_loop_insns': Estimates the number of
+     insns in the loop, on GIMPLE and on RTL.
+   * 'loop_exit_edge_p': Tests whether edge is an exit from a loop.
+   * 'mark_loop_exit_edges': Marks all exit edges of all loops with
+     'EDGE_LOOP_EXIT' flag.
+   * 'get_loop_body', 'get_loop_body_in_dom_order',
+     'get_loop_body_in_bfs_order': Enumerates the basic blocks in the
+     loop in depth-first search order in reversed CFG, ordered by
+     dominance relation, and breath-first search order, respectively.
+   * 'single_exit': Returns the single exit edge of the loop, or 'NULL'
+     if the loop has more than one exit.  You can only use this function
+     if LOOPS_HAVE_MARKED_SINGLE_EXITS property is used.
+   * 'get_loop_exit_edges': Enumerates the exit edges of a loop.
+   * 'just_once_each_iteration_p': Returns true if the basic block is
+     executed exactly once during each iteration of a loop (that is, it
+     does not belong to a sub-loop, and it dominates the latch of the
+     loop).
+
+
+File: gccint.info,  Node: Loop manipulation,  Next: LCSSA,  Prev: Loop querying,  Up: Loop Analysis and Representation
+
+15.3 Loop manipulation
+======================
+
+The loops tree can be manipulated using the following functions:
+
+   * 'flow_loop_tree_node_add': Adds a node to the tree.
+   * 'flow_loop_tree_node_remove': Removes a node from the tree.
+   * 'add_bb_to_loop': Adds a basic block to a loop.
+   * 'remove_bb_from_loops': Removes a basic block from loops.
+
+ Most low-level CFG functions update loops automatically.  The following
+functions handle some more complicated cases of CFG manipulations:
+
+   * 'remove_path': Removes an edge and all blocks it dominates.
+   * 'split_loop_exit_edge': Splits exit edge of the loop, ensuring that
+     PHI node arguments remain in the loop (this ensures that
+     loop-closed SSA form is preserved).  Only useful on GIMPLE.
+
+ Finally, there are some higher-level loop transformations implemented.
+While some of them are written so that they should work on non-innermost
+loops, they are mostly untested in that case, and at the moment, they
+are only reliable for the innermost loops:
+
+   * 'create_iv': Creates a new induction variable.  Only works on
+     GIMPLE.  'standard_iv_increment_position' can be used to find a
+     suitable place for the iv increment.
+   * 'duplicate_loop_to_header_edge',
+     'tree_duplicate_loop_to_header_edge': These functions (on RTL and
+     on GIMPLE) duplicate the body of the loop prescribed number of
+     times on one of the edges entering loop header, thus performing
+     either loop unrolling or loop peeling.  'can_duplicate_loop_p'
+     ('can_unroll_loop_p' on GIMPLE) must be true for the duplicated
+     loop.
+   * 'loop_version', 'tree_ssa_loop_version': These function create a
+     copy of a loop, and a branch before them that selects one of them
+     depending on the prescribed condition.  This is useful for
+     optimizations that need to verify some assumptions in runtime (one
+     of the copies of the loop is usually left unchanged, while the
+     other one is transformed in some way).
+   * 'tree_unroll_loop': Unrolls the loop, including peeling the extra
+     iterations to make the number of iterations divisible by unroll
+     factor, updating the exit condition, and removing the exits that
+     now cannot be taken.  Works only on GIMPLE.
+
+
+File: gccint.info,  Node: LCSSA,  Next: Scalar evolutions,  Prev: Loop manipulation,  Up: Loop Analysis and Representation
+
+15.4 Loop-closed SSA form
+=========================
+
+Throughout the loop optimizations on tree level, one extra condition is
+enforced on the SSA form: No SSA name is used outside of the loop in
+that it is defined.  The SSA form satisfying this condition is called
+"loop-closed SSA form" - LCSSA.  To enforce LCSSA, PHI nodes must be
+created at the exits of the loops for the SSA names that are used
+outside of them.  Only the real operands (not virtual SSA names) are
+held in LCSSA, in order to save memory.
+
+ There are various benefits of LCSSA:
+
+   * Many optimizations (value range analysis, final value replacement)
+     are interested in the values that are defined in the loop and used
+     outside of it, i.e., exactly those for that we create new PHI
+     nodes.
+   * In induction variable analysis, it is not necessary to specify the
+     loop in that the analysis should be performed - the scalar
+     evolution analysis always returns the results with respect to the
+     loop in that the SSA name is defined.
+   * It makes updating of SSA form during loop transformations simpler.
+     Without LCSSA, operations like loop unrolling may force creation of
+     PHI nodes arbitrarily far from the loop, while in LCSSA, the SSA
+     form can be updated locally.  However, since we only keep real
+     operands in LCSSA, we cannot use this advantage (we could have
+     local updating of real operands, but it is not much more efficient
+     than to use generic SSA form updating for it as well; the amount of
+     changes to SSA is the same).
+
+ However, it also means LCSSA must be updated.  This is usually
+straightforward, unless you create a new value in loop and use it
+outside, or unless you manipulate loop exit edges (functions are
+provided to make these manipulations simple).
+'rewrite_into_loop_closed_ssa' is used to rewrite SSA form to LCSSA, and
+'verify_loop_closed_ssa' to check that the invariant of LCSSA is
+preserved.
+
+
+File: gccint.info,  Node: Scalar evolutions,  Next: loop-iv,  Prev: LCSSA,  Up: Loop Analysis and Representation
+
+15.5 Scalar evolutions
+======================
+
+Scalar evolutions (SCEV) are used to represent results of induction
+variable analysis on GIMPLE.  They enable us to represent variables with
+complicated behavior in a simple and consistent way (we only use it to
+express values of polynomial induction variables, but it is possible to
+extend it).  The interfaces to SCEV analysis are declared in
+'tree-scalar-evolution.h'.  To use scalar evolutions analysis,
+'scev_initialize' must be used.  To stop using SCEV, 'scev_finalize'
+should be used.  SCEV analysis caches results in order to save time and
+memory.  This cache however is made invalid by most of the loop
+transformations, including removal of code.  If such a transformation is
+performed, 'scev_reset' must be called to clean the caches.
+
+ Given an SSA name, its behavior in loops can be analyzed using the
+'analyze_scalar_evolution' function.  The returned SCEV however does not
+have to be fully analyzed and it may contain references to other SSA
+names defined in the loop.  To resolve these (potentially recursive)
+references, 'instantiate_parameters' or 'resolve_mixers' functions must
+be used.  'instantiate_parameters' is useful when you use the results of
+SCEV only for some analysis, and when you work with whole nest of loops
+at once.  It will try replacing all SSA names by their SCEV in all
+loops, including the super-loops of the current loop, thus providing a
+complete information about the behavior of the variable in the loop
+nest.  'resolve_mixers' is useful if you work with only one loop at a
+time, and if you possibly need to create code based on the value of the
+induction variable.  It will only resolve the SSA names defined in the
+current loop, leaving the SSA names defined outside unchanged, even if
+their evolution in the outer loops is known.
+
+ The SCEV is a normal tree expression, except for the fact that it may
+contain several special tree nodes.  One of them is 'SCEV_NOT_KNOWN',
+used for SSA names whose value cannot be expressed.  The other one is
+'POLYNOMIAL_CHREC'.  Polynomial chrec has three arguments - base, step
+and loop (both base and step may contain further polynomial chrecs).
+Type of the expression and of base and step must be the same.  A
+variable has evolution 'POLYNOMIAL_CHREC(base, step, loop)' if it is (in
+the specified loop) equivalent to 'x_1' in the following example
+
+     while (...)
+       {
+         x_1 = phi (base, x_2);
+         x_2 = x_1 + step;
+       }
+
+ Note that this includes the language restrictions on the operations.
+For example, if we compile C code and 'x' has signed type, then the
+overflow in addition would cause undefined behavior, and we may assume
+that this does not happen.  Hence, the value with this SCEV cannot
+overflow (which restricts the number of iterations of such a loop).
+
+ In many cases, one wants to restrict the attention just to affine
+induction variables.  In this case, the extra expressive power of SCEV
+is not useful, and may complicate the optimizations.  In this case,
+'simple_iv' function may be used to analyze a value - the result is a
+loop-invariant base and step.
+
+
+File: gccint.info,  Node: loop-iv,  Next: Number of iterations,  Prev: Scalar evolutions,  Up: Loop Analysis and Representation
+
+15.6 IV analysis on RTL
+=======================
+
+The induction variable on RTL is simple and only allows analysis of
+affine induction variables, and only in one loop at once.  The interface
+is declared in 'cfgloop.h'.  Before analyzing induction variables in a
+loop L, 'iv_analysis_loop_init' function must be called on L. After the
+analysis (possibly calling 'iv_analysis_loop_init' for several loops) is
+finished, 'iv_analysis_done' should be called.  The following functions
+can be used to access the results of the analysis:
+
+   * 'iv_analyze': Analyzes a single register used in the given insn.
+     If no use of the register in this insn is found, the following
+     insns are scanned, so that this function can be called on the insn
+     returned by get_condition.
+   * 'iv_analyze_result': Analyzes result of the assignment in the given
+     insn.
+   * 'iv_analyze_expr': Analyzes a more complicated expression.  All its
+     operands are analyzed by 'iv_analyze', and hence they must be used
+     in the specified insn or one of the following insns.
+
+ The description of the induction variable is provided in 'struct
+rtx_iv'.  In order to handle subregs, the representation is a bit
+complicated; if the value of the 'extend' field is not 'UNKNOWN', the
+value of the induction variable in the i-th iteration is
+
+     delta + mult * extend_{extend_mode} (subreg_{mode} (base + i * step)),
+
+ with the following exception: if 'first_special' is true, then the
+value in the first iteration (when 'i' is zero) is 'delta + mult *
+base'.  However, if 'extend' is equal to 'UNKNOWN', then 'first_special'
+must be false, 'delta' 0, 'mult' 1 and the value in the i-th iteration
+is
+
+     subreg_{mode} (base + i * step)
+
+ The function 'get_iv_value' can be used to perform these calculations.
+
+
+File: gccint.info,  Node: Number of iterations,  Next: Dependency analysis,  Prev: loop-iv,  Up: Loop Analysis and Representation
+
+15.7 Number of iterations analysis
+==================================
+
+Both on GIMPLE and on RTL, there are functions available to determine
+the number of iterations of a loop, with a similar interface.  The
+number of iterations of a loop in GCC is defined as the number of
+executions of the loop latch.  In many cases, it is not possible to
+determine the number of iterations unconditionally - the determined
+number is correct only if some assumptions are satisfied.  The analysis
+tries to verify these conditions using the information contained in the
+program; if it fails, the conditions are returned together with the
+result.  The following information and conditions are provided by the
+analysis:
+
+   * 'assumptions': If this condition is false, the rest of the
+     information is invalid.
+   * 'noloop_assumptions' on RTL, 'may_be_zero' on GIMPLE: If this
+     condition is true, the loop exits in the first iteration.
+   * 'infinite': If this condition is true, the loop is infinite.  This
+     condition is only available on RTL.  On GIMPLE, conditions for
+     finiteness of the loop are included in 'assumptions'.
+   * 'niter_expr' on RTL, 'niter' on GIMPLE: The expression that gives
+     number of iterations.  The number of iterations is defined as the
+     number of executions of the loop latch.
+
+ Both on GIMPLE and on RTL, it necessary for the induction variable
+analysis framework to be initialized (SCEV on GIMPLE, loop-iv on RTL).
+On GIMPLE, the results are stored to 'struct tree_niter_desc' structure.
+Number of iterations before the loop is exited through a given exit can
+be determined using 'number_of_iterations_exit' function.  On RTL, the
+results are returned in 'struct niter_desc' structure.  The
+corresponding function is named 'check_simple_exit'.  There are also
+functions that pass through all the exits of a loop and try to find one
+with easy to determine number of iterations - 'find_loop_niter' on
+GIMPLE and 'find_simple_exit' on RTL.  Finally, there are functions that
+provide the same information, but additionally cache it, so that
+repeated calls to number of iterations are not so costly -
+'number_of_latch_executions' on GIMPLE and 'get_simple_loop_desc' on
+RTL.
+
+ Note that some of these functions may behave slightly differently than
+others - some of them return only the expression for the number of
+iterations, and fail if there are some assumptions.  The function
+'number_of_latch_executions' works only for single-exit loops.  The
+function 'number_of_cond_exit_executions' can be used to determine
+number of executions of the exit condition of a single-exit loop (i.e.,
+the 'number_of_latch_executions' increased by one).
+
+
+File: gccint.info,  Node: Dependency analysis,  Next: Omega,  Prev: Number of iterations,  Up: Loop Analysis and Representation
+
+15.8 Data Dependency Analysis
+=============================
+
+The code for the data dependence analysis can be found in
+'tree-data-ref.c' and its interface and data structures are described in
+'tree-data-ref.h'.  The function that computes the data dependences for
+all the array and pointer references for a given loop is
+'compute_data_dependences_for_loop'.  This function is currently used by
+the linear loop transform and the vectorization passes.  Before calling
+this function, one has to allocate two vectors: a first vector will
+contain the set of data references that are contained in the analyzed
+loop body, and the second vector will contain the dependence relations
+between the data references.  Thus if the vector of data references is
+of size 'n', the vector containing the dependence relations will contain
+'n*n' elements.  However if the analyzed loop contains side effects,
+such as calls that potentially can interfere with the data references in
+the current analyzed loop, the analysis stops while scanning the loop
+body for data references, and inserts a single 'chrec_dont_know' in the
+dependence relation array.
+
+ The data references are discovered in a particular order during the
+scanning of the loop body: the loop body is analyzed in execution order,
+and the data references of each statement are pushed at the end of the
+data reference array.  Two data references syntactically occur in the
+program in the same order as in the array of data references.  This
+syntactic order is important in some classical data dependence tests,
+and mapping this order to the elements of this array avoids costly
+queries to the loop body representation.
+
+ Three types of data references are currently handled: ARRAY_REF,
+INDIRECT_REF and COMPONENT_REF.  The data structure for the data
+reference is 'data_reference', where 'data_reference_p' is a name of a
+pointer to the data reference structure.  The structure contains the
+following elements:
+
+   * 'base_object_info': Provides information about the base object of
+     the data reference and its access functions.  These access
+     functions represent the evolution of the data reference in the loop
+     relative to its base, in keeping with the classical meaning of the
+     data reference access function for the support of arrays.  For
+     example, for a reference 'a.b[i][j]', the base object is 'a.b' and
+     the access functions, one for each array subscript, are: '{i_init,
+     + i_step}_1, {j_init, +, j_step}_2'.
+
+   * 'first_location_in_loop': Provides information about the first
+     location accessed by the data reference in the loop and about the
+     access function used to represent evolution relative to this
+     location.  This data is used to support pointers, and is not used
+     for arrays (for which we have base objects).  Pointer accesses are
+     represented as a one-dimensional access that starts from the first
+     location accessed in the loop.  For example:
+
+                for1 i
+                   for2 j
+                    *((int *)p + i + j) = a[i][j];
+
+     The access function of the pointer access is '{0, + 4B}_for2'
+     relative to 'p + i'.  The access functions of the array are
+     '{i_init, + i_step}_for1' and '{j_init, +, j_step}_for2' relative
+     to 'a'.
+
+     Usually, the object the pointer refers to is either unknown, or we
+     can't prove that the access is confined to the boundaries of a
+     certain object.
+
+     Two data references can be compared only if at least one of these
+     two representations has all its fields filled for both data
+     references.
+
+     The current strategy for data dependence tests is as follows: If
+     both 'a' and 'b' are represented as arrays, compare 'a.base_object'
+     and 'b.base_object'; if they are equal, apply dependence tests (use
+     access functions based on base_objects).  Else if both 'a' and 'b'
+     are represented as pointers, compare 'a.first_location' and
+     'b.first_location'; if they are equal, apply dependence tests (use
+     access functions based on first location).  However, if 'a' and 'b'
+     are represented differently, only try to prove that the bases are
+     definitely different.
+
+   * Aliasing information.
+   * Alignment information.
+
+ The structure describing the relation between two data references is
+'data_dependence_relation' and the shorter name for a pointer to such a
+structure is 'ddr_p'.  This structure contains:
+
+   * a pointer to each data reference,
+   * a tree node 'are_dependent' that is set to 'chrec_known' if the
+     analysis has proved that there is no dependence between these two
+     data references, 'chrec_dont_know' if the analysis was not able to
+     determine any useful result and potentially there could exist a
+     dependence between these data references, and 'are_dependent' is
+     set to 'NULL_TREE' if there exist a dependence relation between the
+     data references, and the description of this dependence relation is
+     given in the 'subscripts', 'dir_vects', and 'dist_vects' arrays,
+   * a boolean that determines whether the dependence relation can be
+     represented by a classical distance vector,
+   * an array 'subscripts' that contains a description of each subscript
+     of the data references.  Given two array accesses a subscript is
+     the tuple composed of the access functions for a given dimension.
+     For example, given 'A[f1][f2][f3]' and 'B[g1][g2][g3]', there are
+     three subscripts: '(f1, g1), (f2, g2), (f3, g3)'.
+   * two arrays 'dir_vects' and 'dist_vects' that contain classical
+     representations of the data dependences under the form of direction
+     and distance dependence vectors,
+   * an array of loops 'loop_nest' that contains the loops to which the
+     distance and direction vectors refer to.
+
+ Several functions for pretty printing the information extracted by the
+data dependence analysis are available: 'dump_ddrs' prints with a
+maximum verbosity the details of a data dependence relations array,
+'dump_dist_dir_vectors' prints only the classical distance and direction
+vectors for a data dependence relations array, and
+'dump_data_references' prints the details of the data references
+contained in a data reference array.
+
+
+File: gccint.info,  Node: Omega,  Prev: Dependency analysis,  Up: Loop Analysis and Representation
+
+15.9 Omega a solver for linear programming problems
+===================================================
+
+The data dependence analysis contains several solvers triggered
+sequentially from the less complex ones to the more sophisticated.  For
+ensuring the consistency of the results of these solvers, a data
+dependence check pass has been implemented based on two different
+solvers.  The second method that has been integrated to GCC is based on
+the Omega dependence solver, written in the 1990's by William Pugh and
+David Wonnacott.  Data dependence tests can be formulated using a subset
+of the Presburger arithmetics that can be translated to linear
+constraint systems.  These linear constraint systems can then be solved
+using the Omega solver.
+
+ The Omega solver is using Fourier-Motzkin's algorithm for variable
+elimination: a linear constraint system containing 'n' variables is
+reduced to a linear constraint system with 'n-1' variables.  The Omega
+solver can also be used for solving other problems that can be expressed
+under the form of a system of linear equalities and inequalities.  The
+Omega solver is known to have an exponential worst case, also known
+under the name of "omega nightmare" in the literature, but in practice,
+the omega test is known to be efficient for the common data dependence
+tests.
+
+ The interface used by the Omega solver for describing the linear
+programming problems is described in 'omega.h', and the solver is
+'omega_solve_problem'.
+
+
+File: gccint.info,  Node: Machine Desc,  Next: Target Macros,  Prev: Loop Analysis and Representation,  Up: Top
+
+16 Machine Descriptions
+***********************
+
+A machine description has two parts: a file of instruction patterns
+('.md' file) and a C header file of macro definitions.
+
+ The '.md' file for a target machine contains a pattern for each
+instruction that the target machine supports (or at least each
+instruction that is worth telling the compiler about).  It may also
+contain comments.  A semicolon causes the rest of the line to be a
+comment, unless the semicolon is inside a quoted string.
+
+ See the next chapter for information on the C header file.
+
+* Menu:
+
+* Overview::            How the machine description is used.
+* Patterns::            How to write instruction patterns.
+* Example::             An explained example of a 'define_insn' pattern.
+* RTL Template::        The RTL template defines what insns match a pattern.
+* Output Template::     The output template says how to make assembler code
+                        from such an insn.
+* Output Statement::    For more generality, write C code to output
+                        the assembler code.
+* Predicates::          Controlling what kinds of operands can be used
+                        for an insn.
+* Constraints::         Fine-tuning operand selection.
+* Standard Names::      Names mark patterns to use for code generation.
+* Pattern Ordering::    When the order of patterns makes a difference.
+* Dependent Patterns::  Having one pattern may make you need another.
+* Jump Patterns::       Special considerations for patterns for jump insns.
+* Looping Patterns::    How to define patterns for special looping insns.
+* Insn Canonicalizations::Canonicalization of Instructions
+* Expander Definitions::Generating a sequence of several RTL insns
+                        for a standard operation.
+* Insn Splitting::      Splitting Instructions into Multiple Instructions.
+* Including Patterns::  Including Patterns in Machine Descriptions.
+* Peephole Definitions::Defining machine-specific peephole optimizations.
+* Insn Attributes::     Specifying the value of attributes for generated insns.
+* Conditional Execution::Generating 'define_insn' patterns for
+                         predication.
+* Define Subst::	Generating 'define_insn' and 'define_expand'
+			patterns from other patterns.
+* Constant Definitions::Defining symbolic constants that can be used in the
+                        md file.
+* Iterators::           Using iterators to generate patterns from a template.
+
+
+File: gccint.info,  Node: Overview,  Next: Patterns,  Up: Machine Desc
+
+16.1 Overview of How the Machine Description is Used
+====================================================
+
+There are three main conversions that happen in the compiler:
+
+  1. The front end reads the source code and builds a parse tree.
+
+  2. The parse tree is used to generate an RTL insn list based on named
+     instruction patterns.
+
+  3. The insn list is matched against the RTL templates to produce
+     assembler code.
+
+ For the generate pass, only the names of the insns matter, from either
+a named 'define_insn' or a 'define_expand'.  The compiler will choose
+the pattern with the right name and apply the operands according to the
+documentation later in this chapter, without regard for the RTL template
+or operand constraints.  Note that the names the compiler looks for are
+hard-coded in the compiler--it will ignore unnamed patterns and patterns
+with names it doesn't know about, but if you don't provide a named
+pattern it needs, it will abort.
+
+ If a 'define_insn' is used, the template given is inserted into the
+insn list.  If a 'define_expand' is used, one of three things happens,
+based on the condition logic.  The condition logic may manually create
+new insns for the insn list, say via 'emit_insn()', and invoke 'DONE'.
+For certain named patterns, it may invoke 'FAIL' to tell the compiler to
+use an alternate way of performing that task.  If it invokes neither
+'DONE' nor 'FAIL', the template given in the pattern is inserted, as if
+the 'define_expand' were a 'define_insn'.
+
+ Once the insn list is generated, various optimization passes convert,
+replace, and rearrange the insns in the insn list.  This is where the
+'define_split' and 'define_peephole' patterns get used, for example.
+
+ Finally, the insn list's RTL is matched up with the RTL templates in
+the 'define_insn' patterns, and those patterns are used to emit the
+final assembly code.  For this purpose, each named 'define_insn' acts
+like it's unnamed, since the names are ignored.
+
+
+File: gccint.info,  Node: Patterns,  Next: Example,  Prev: Overview,  Up: Machine Desc
+
+16.2 Everything about Instruction Patterns
+==========================================
+
+Each instruction pattern contains an incomplete RTL expression, with
+pieces to be filled in later, operand constraints that restrict how the
+pieces can be filled in, and an output pattern or C code to generate the
+assembler output, all wrapped up in a 'define_insn' expression.
+
+ A 'define_insn' is an RTL expression containing four or five operands:
+
+  1. An optional name.  The presence of a name indicate that this
+     instruction pattern can perform a certain standard job for the
+     RTL-generation pass of the compiler.  This pass knows certain names
+     and will use the instruction patterns with those names, if the
+     names are defined in the machine description.
+
+     The absence of a name is indicated by writing an empty string where
+     the name should go.  Nameless instruction patterns are never used
+     for generating RTL code, but they may permit several simpler insns
+     to be combined later on.
+
+     Names that are not thus known and used in RTL-generation have no
+     effect; they are equivalent to no name at all.
+
+     For the purpose of debugging the compiler, you may also specify a
+     name beginning with the '*' character.  Such a name is used only
+     for identifying the instruction in RTL dumps; it is entirely
+     equivalent to having a nameless pattern for all other purposes.
+
+  2. The "RTL template" (*note RTL Template::) is a vector of incomplete
+     RTL expressions which show what the instruction should look like.
+     It is incomplete because it may contain 'match_operand',
+     'match_operator', and 'match_dup' expressions that stand for
+     operands of the instruction.
+
+     If the vector has only one element, that element is the template
+     for the instruction pattern.  If the vector has multiple elements,
+     then the instruction pattern is a 'parallel' expression containing
+     the elements described.
+
+  3. A condition.  This is a string which contains a C expression that
+     is the final test to decide whether an insn body matches this
+     pattern.
+
+     For a named pattern, the condition (if present) may not depend on
+     the data in the insn being matched, but only the
+     target-machine-type flags.  The compiler needs to test these
+     conditions during initialization in order to learn exactly which
+     named instructions are available in a particular run.
+
+     For nameless patterns, the condition is applied only when matching
+     an individual insn, and only after the insn has matched the
+     pattern's recognition template.  The insn's operands may be found
+     in the vector 'operands'.  For an insn where the condition has once
+     matched, it can't be used to control register allocation, for
+     example by excluding certain hard registers or hard register
+     combinations.
+
+  4. The "output template": a string that says how to output matching
+     insns as assembler code.  '%' in this string specifies where to
+     substitute the value of an operand.  *Note Output Template::.
+
+     When simple substitution isn't general enough, you can specify a
+     piece of C code to compute the output.  *Note Output Statement::.
+
+  5. Optionally, a vector containing the values of attributes for insns
+     matching this pattern.  *Note Insn Attributes::.
+
+
+File: gccint.info,  Node: Example,  Next: RTL Template,  Prev: Patterns,  Up: Machine Desc
+
+16.3 Example of 'define_insn'
+=============================
+
+Here is an actual example of an instruction pattern, for the
+68000/68020.
+
+     (define_insn "tstsi"
+       [(set (cc0)
+             (match_operand:SI 0 "general_operand" "rm"))]
+       ""
+       "*
+     {
+       if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
+         return \"tstl %0\";
+       return \"cmpl #0,%0\";
+     }")
+
+This can also be written using braced strings:
+
+     (define_insn "tstsi"
+       [(set (cc0)
+             (match_operand:SI 0 "general_operand" "rm"))]
+       ""
+     {
+       if (TARGET_68020 || ! ADDRESS_REG_P (operands[0]))
+         return "tstl %0";
+       return "cmpl #0,%0";
+     })
+
+ This is an instruction that sets the condition codes based on the value
+of a general operand.  It has no condition, so any insn whose RTL
+description has the form shown may be handled according to this pattern.
+The name 'tstsi' means "test a 'SImode' value" and tells the RTL
+generation pass that, when it is necessary to test such a value, an insn
+to do so can be constructed using this pattern.
+
+ The output control string is a piece of C code which chooses which
+output template to return based on the kind of operand and the specific
+type of CPU for which code is being generated.
+
+ '"rm"' is an operand constraint.  Its meaning is explained below.
+
+
+File: gccint.info,  Node: RTL Template,  Next: Output Template,  Prev: Example,  Up: Machine Desc
+
+16.4 RTL Template
+=================
+
+The RTL template is used to define which insns match the particular
+pattern and how to find their operands.  For named patterns, the RTL
+template also says how to construct an insn from specified operands.
+
+ Construction involves substituting specified operands into a copy of
+the template.  Matching involves determining the values that serve as
+the operands in the insn being matched.  Both of these activities are
+controlled by special expression types that direct matching and
+substitution of the operands.
+
+'(match_operand:M N PREDICATE CONSTRAINT)'
+     This expression is a placeholder for operand number N of the insn.
+     When constructing an insn, operand number N will be substituted at
+     this point.  When matching an insn, whatever appears at this
+     position in the insn will be taken as operand number N; but it must
+     satisfy PREDICATE or this instruction pattern will not match at
+     all.
+
+     Operand numbers must be chosen consecutively counting from zero in
+     each instruction pattern.  There may be only one 'match_operand'
+     expression in the pattern for each operand number.  Usually
+     operands are numbered in the order of appearance in 'match_operand'
+     expressions.  In the case of a 'define_expand', any operand numbers
+     used only in 'match_dup' expressions have higher values than all
+     other operand numbers.
+
+     PREDICATE is a string that is the name of a function that accepts
+     two arguments, an expression and a machine mode.  *Note
+     Predicates::.  During matching, the function will be called with
+     the putative operand as the expression and M as the mode argument
+     (if M is not specified, 'VOIDmode' will be used, which normally
+     causes PREDICATE to accept any mode).  If it returns zero, this
+     instruction pattern fails to match.  PREDICATE may be an empty
+     string; then it means no test is to be done on the operand, so
+     anything which occurs in this position is valid.
+
+     Most of the time, PREDICATE will reject modes other than M--but not
+     always.  For example, the predicate 'address_operand' uses M as the
+     mode of memory ref that the address should be valid for.  Many
+     predicates accept 'const_int' nodes even though their mode is
+     'VOIDmode'.
+
+     CONSTRAINT controls reloading and the choice of the best register
+     class to use for a value, as explained later (*note Constraints::).
+     If the constraint would be an empty string, it can be omitted.
+
+     People are often unclear on the difference between the constraint
+     and the predicate.  The predicate helps decide whether a given insn
+     matches the pattern.  The constraint plays no role in this
+     decision; instead, it controls various decisions in the case of an
+     insn which does match.
+
+'(match_scratch:M N CONSTRAINT)'
+     This expression is also a placeholder for operand number N and
+     indicates that operand must be a 'scratch' or 'reg' expression.
+
+     When matching patterns, this is equivalent to
+
+          (match_operand:M N "scratch_operand" PRED)
+
+     but, when generating RTL, it produces a ('scratch':M) expression.
+
+     If the last few expressions in a 'parallel' are 'clobber'
+     expressions whose operands are either a hard register or
+     'match_scratch', the combiner can add or delete them when
+     necessary.  *Note Side Effects::.
+
+'(match_dup N)'
+     This expression is also a placeholder for operand number N.  It is
+     used when the operand needs to appear more than once in the insn.
+
+     In construction, 'match_dup' acts just like 'match_operand': the
+     operand is substituted into the insn being constructed.  But in
+     matching, 'match_dup' behaves differently.  It assumes that operand
+     number N has already been determined by a 'match_operand' appearing
+     earlier in the recognition template, and it matches only an
+     identical-looking expression.
+
+     Note that 'match_dup' should not be used to tell the compiler that
+     a particular register is being used for two operands (example:
+     'add' that adds one register to another; the second register is
+     both an input operand and the output operand).  Use a matching
+     constraint (*note Simple Constraints::) for those.  'match_dup' is
+     for the cases where one operand is used in two places in the
+     template, such as an instruction that computes both a quotient and
+     a remainder, where the opcode takes two input operands but the RTL
+     template has to refer to each of those twice; once for the quotient
+     pattern and once for the remainder pattern.
+
+'(match_operator:M N PREDICATE [OPERANDS...])'
+     This pattern is a kind of placeholder for a variable RTL expression
+     code.
+
+     When constructing an insn, it stands for an RTL expression whose
+     expression code is taken from that of operand N, and whose operands
+     are constructed from the patterns OPERANDS.
+
+     When matching an expression, it matches an expression if the
+     function PREDICATE returns nonzero on that expression _and_ the
+     patterns OPERANDS match the operands of the expression.
+
+     Suppose that the function 'commutative_operator' is defined as
+     follows, to match any expression whose operator is one of the
+     commutative arithmetic operators of RTL and whose mode is MODE:
+
+          int
+          commutative_integer_operator (x, mode)
+               rtx x;
+               enum machine_mode mode;
+          {
+            enum rtx_code code = GET_CODE (x);
+            if (GET_MODE (x) != mode)
+              return 0;
+            return (GET_RTX_CLASS (code) == RTX_COMM_ARITH
+                    || code == EQ || code == NE);
+          }
+
+     Then the following pattern will match any RTL expression consisting
+     of a commutative operator applied to two general operands:
+
+          (match_operator:SI 3 "commutative_operator"
+            [(match_operand:SI 1 "general_operand" "g")
+             (match_operand:SI 2 "general_operand" "g")])
+
+     Here the vector '[OPERANDS...]' contains two patterns because the
+     expressions to be matched all contain two operands.
+
+     When this pattern does match, the two operands of the commutative
+     operator are recorded as operands 1 and 2 of the insn.  (This is
+     done by the two instances of 'match_operand'.)  Operand 3 of the
+     insn will be the entire commutative expression: use 'GET_CODE
+     (operands[3])' to see which commutative operator was used.
+
+     The machine mode M of 'match_operator' works like that of
+     'match_operand': it is passed as the second argument to the
+     predicate function, and that function is solely responsible for
+     deciding whether the expression to be matched "has" that mode.
+
+     When constructing an insn, argument 3 of the gen-function will
+     specify the operation (i.e. the expression code) for the expression
+     to be made.  It should be an RTL expression, whose expression code
+     is copied into a new expression whose operands are arguments 1 and
+     2 of the gen-function.  The subexpressions of argument 3 are not
+     used; only its expression code matters.
+
+     When 'match_operator' is used in a pattern for matching an insn, it
+     usually best if the operand number of the 'match_operator' is
+     higher than that of the actual operands of the insn.  This improves
+     register allocation because the register allocator often looks at
+     operands 1 and 2 of insns to see if it can do register tying.
+
+     There is no way to specify constraints in 'match_operator'.  The
+     operand of the insn which corresponds to the 'match_operator' never
+     has any constraints because it is never reloaded as a whole.
+     However, if parts of its OPERANDS are matched by 'match_operand'
+     patterns, those parts may have constraints of their own.
+
+'(match_op_dup:M N[OPERANDS...])'
+     Like 'match_dup', except that it applies to operators instead of
+     operands.  When constructing an insn, operand number N will be
+     substituted at this point.  But in matching, 'match_op_dup' behaves
+     differently.  It assumes that operand number N has already been
+     determined by a 'match_operator' appearing earlier in the
+     recognition template, and it matches only an identical-looking
+     expression.
+
+'(match_parallel N PREDICATE [SUBPAT...])'
+     This pattern is a placeholder for an insn that consists of a
+     'parallel' expression with a variable number of elements.  This
+     expression should only appear at the top level of an insn pattern.
+
+     When constructing an insn, operand number N will be substituted at
+     this point.  When matching an insn, it matches if the body of the
+     insn is a 'parallel' expression with at least as many elements as
+     the vector of SUBPAT expressions in the 'match_parallel', if each
+     SUBPAT matches the corresponding element of the 'parallel', _and_
+     the function PREDICATE returns nonzero on the 'parallel' that is
+     the body of the insn.  It is the responsibility of the predicate to
+     validate elements of the 'parallel' beyond those listed in the
+     'match_parallel'.
+
+     A typical use of 'match_parallel' is to match load and store
+     multiple expressions, which can contain a variable number of
+     elements in a 'parallel'.  For example,
+
+          (define_insn ""
+            [(match_parallel 0 "load_multiple_operation"
+               [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
+                     (match_operand:SI 2 "memory_operand" "m"))
+                (use (reg:SI 179))
+                (clobber (reg:SI 179))])]
+            ""
+            "loadm 0,0,%1,%2")
+
+     This example comes from 'a29k.md'.  The function
+     'load_multiple_operation' is defined in 'a29k.c' and checks that
+     subsequent elements in the 'parallel' are the same as the 'set' in
+     the pattern, except that they are referencing subsequent registers
+     and memory locations.
+
+     An insn that matches this pattern might look like:
+
+          (parallel
+           [(set (reg:SI 20) (mem:SI (reg:SI 100)))
+            (use (reg:SI 179))
+            (clobber (reg:SI 179))
+            (set (reg:SI 21)
+                 (mem:SI (plus:SI (reg:SI 100)
+                                  (const_int 4))))
+            (set (reg:SI 22)
+                 (mem:SI (plus:SI (reg:SI 100)
+                                  (const_int 8))))])
+
+'(match_par_dup N [SUBPAT...])'
+     Like 'match_op_dup', but for 'match_parallel' instead of
+     'match_operator'.
+
+
+File: gccint.info,  Node: Output Template,  Next: Output Statement,  Prev: RTL Template,  Up: Machine Desc
+
+16.5 Output Templates and Operand Substitution
+==============================================
+
+The "output template" is a string which specifies how to output the
+assembler code for an instruction pattern.  Most of the template is a
+fixed string which is output literally.  The character '%' is used to
+specify where to substitute an operand; it can also be used to identify
+places where different variants of the assembler require different
+syntax.
+
+ In the simplest case, a '%' followed by a digit N says to output
+operand N at that point in the string.
+
+ '%' followed by a letter and a digit says to output an operand in an
+alternate fashion.  Four letters have standard, built-in meanings
+described below.  The machine description macro 'PRINT_OPERAND' can
+define additional letters with nonstandard meanings.
+
+ '%cDIGIT' can be used to substitute an operand that is a constant value
+without the syntax that normally indicates an immediate operand.
+
+ '%nDIGIT' is like '%cDIGIT' except that the value of the constant is
+negated before printing.
+
+ '%aDIGIT' can be used to substitute an operand as if it were a memory
+reference, with the actual operand treated as the address.  This may be
+useful when outputting a "load address" instruction, because often the
+assembler syntax for such an instruction requires you to write the
+operand as if it were a memory reference.
+
+ '%lDIGIT' is used to substitute a 'label_ref' into a jump instruction.
+
+ '%=' outputs a number which is unique to each instruction in the entire
+compilation.  This is useful for making local labels to be referred to
+more than once in a single template that generates multiple assembler
+instructions.
+
+ '%' followed by a punctuation character specifies a substitution that
+does not use an operand.  Only one case is standard: '%%' outputs a '%'
+into the assembler code.  Other nonstandard cases can be defined in the
+'PRINT_OPERAND' macro.  You must also define which punctuation
+characters are valid with the 'PRINT_OPERAND_PUNCT_VALID_P' macro.
+
+ The template may generate multiple assembler instructions.  Write the
+text for the instructions, with '\;' between them.
+
+ When the RTL contains two operands which are required by constraint to
+match each other, the output template must refer only to the
+lower-numbered operand.  Matching operands are not always identical, and
+the rest of the compiler arranges to put the proper RTL expression for
+printing into the lower-numbered operand.
+
+ One use of nonstandard letters or punctuation following '%' is to
+distinguish between different assembler languages for the same machine;
+for example, Motorola syntax versus MIT syntax for the 68000.  Motorola
+syntax requires periods in most opcode names, while MIT syntax does not.
+For example, the opcode 'movel' in MIT syntax is 'move.l' in Motorola
+syntax.  The same file of patterns is used for both kinds of output
+syntax, but the character sequence '%.' is used in each place where
+Motorola syntax wants a period.  The 'PRINT_OPERAND' macro for Motorola
+syntax defines the sequence to output a period; the macro for MIT syntax
+defines it to do nothing.
+
+ As a special case, a template consisting of the single character '#'
+instructs the compiler to first split the insn, and then output the
+resulting instructions separately.  This helps eliminate redundancy in
+the output templates.  If you have a 'define_insn' that needs to emit
+multiple assembler instructions, and there is a matching 'define_split'
+already defined, then you can simply use '#' as the output template
+instead of writing an output template that emits the multiple assembler
+instructions.
+
+ If the macro 'ASSEMBLER_DIALECT' is defined, you can use construct of
+the form '{option0|option1|option2}' in the templates.  These describe
+multiple variants of assembler language syntax.  *Note Instruction
+Output::.
+
+
+File: gccint.info,  Node: Output Statement,  Next: Predicates,  Prev: Output Template,  Up: Machine Desc
+
+16.6 C Statements for Assembler Output
+======================================
+
+Often a single fixed template string cannot produce correct and
+efficient assembler code for all the cases that are recognized by a
+single instruction pattern.  For example, the opcodes may depend on the
+kinds of operands; or some unfortunate combinations of operands may
+require extra machine instructions.
+
+ If the output control string starts with a '@', then it is actually a
+series of templates, each on a separate line.  (Blank lines and leading
+spaces and tabs are ignored.)  The templates correspond to the pattern's
+constraint alternatives (*note Multi-Alternative::).  For example, if a
+target machine has a two-address add instruction 'addr' to add into a
+register and another 'addm' to add a register to memory, you might write
+this pattern:
+
+     (define_insn "addsi3"
+       [(set (match_operand:SI 0 "general_operand" "=r,m")
+             (plus:SI (match_operand:SI 1 "general_operand" "0,0")
+                      (match_operand:SI 2 "general_operand" "g,r")))]
+       ""
+       "@
+        addr %2,%0
+        addm %2,%0")
+
+ If the output control string starts with a '*', then it is not an
+output template but rather a piece of C program that should compute a
+template.  It should execute a 'return' statement to return the
+template-string you want.  Most such templates use C string literals,
+which require doublequote characters to delimit them.  To include these
+doublequote characters in the string, prefix each one with '\'.
+
+ If the output control string is written as a brace block instead of a
+double-quoted string, it is automatically assumed to be C code.  In that
+case, it is not necessary to put in a leading asterisk, or to escape the
+doublequotes surrounding C string literals.
+
+ The operands may be found in the array 'operands', whose C data type is
+'rtx []'.
+
+ It is very common to select different ways of generating assembler code
+based on whether an immediate operand is within a certain range.  Be
+careful when doing this, because the result of 'INTVAL' is an integer on
+the host machine.  If the host machine has more bits in an 'int' than
+the target machine has in the mode in which the constant will be used,
+then some of the bits you get from 'INTVAL' will be superfluous.  For
+proper results, you must carefully disregard the values of those bits.
+
+ It is possible to output an assembler instruction and then go on to
+output or compute more of them, using the subroutine 'output_asm_insn'.
+This receives two arguments: a template-string and a vector of operands.
+The vector may be 'operands', or it may be another array of 'rtx' that
+you declare locally and initialize yourself.
+
+ When an insn pattern has multiple alternatives in its constraints,
+often the appearance of the assembler code is determined mostly by which
+alternative was matched.  When this is so, the C code can test the
+variable 'which_alternative', which is the ordinal number of the
+alternative that was actually satisfied (0 for the first, 1 for the
+second alternative, etc.).
+
+ For example, suppose there are two opcodes for storing zero, 'clrreg'
+for registers and 'clrmem' for memory locations.  Here is how a pattern
+could use 'which_alternative' to choose between them:
+
+     (define_insn ""
+       [(set (match_operand:SI 0 "general_operand" "=r,m")
+             (const_int 0))]
+       ""
+       {
+       return (which_alternative == 0
+               ? "clrreg %0" : "clrmem %0");
+       })
+
+ The example above, where the assembler code to generate was _solely_
+determined by the alternative, could also have been specified as
+follows, having the output control string start with a '@':
+
+     (define_insn ""
+       [(set (match_operand:SI 0 "general_operand" "=r,m")
+             (const_int 0))]
+       ""
+       "@
+        clrreg %0
+        clrmem %0")
+
+ If you just need a little bit of C code in one (or a few) alternatives,
+you can use '*' inside of a '@' multi-alternative template:
+
+     (define_insn ""
+       [(set (match_operand:SI 0 "general_operand" "=r,<,m")
+             (const_int 0))]
+       ""
+       "@
+        clrreg %0
+        * return stack_mem_p (operands[0]) ? \"push 0\" : \"clrmem %0\";
+        clrmem %0")
+
+
+File: gccint.info,  Node: Predicates,  Next: Constraints,  Prev: Output Statement,  Up: Machine Desc
+
+16.7 Predicates
+===============
+
+A predicate determines whether a 'match_operand' or 'match_operator'
+expression matches, and therefore whether the surrounding instruction
+pattern will be used for that combination of operands.  GCC has a number
+of machine-independent predicates, and you can define machine-specific
+predicates as needed.  By convention, predicates used with
+'match_operand' have names that end in '_operand', and those used with
+'match_operator' have names that end in '_operator'.
+
+ All predicates are Boolean functions (in the mathematical sense) of two
+arguments: the RTL expression that is being considered at that position
+in the instruction pattern, and the machine mode that the
+'match_operand' or 'match_operator' specifies.  In this section, the
+first argument is called OP and the second argument MODE.  Predicates
+can be called from C as ordinary two-argument functions; this can be
+useful in output templates or other machine-specific code.
+
+ Operand predicates can allow operands that are not actually acceptable
+to the hardware, as long as the constraints give reload the ability to
+fix them up (*note Constraints::).  However, GCC will usually generate
+better code if the predicates specify the requirements of the machine
+instructions as closely as possible.  Reload cannot fix up operands that
+must be constants ("immediate operands"); you must use a predicate that
+allows only constants, or else enforce the requirement in the extra
+condition.
+
+ Most predicates handle their MODE argument in a uniform manner.  If
+MODE is 'VOIDmode' (unspecified), then OP can have any mode.  If MODE is
+anything else, then OP must have the same mode, unless OP is a
+'CONST_INT' or integer 'CONST_DOUBLE'.  These RTL expressions always
+have 'VOIDmode', so it would be counterproductive to check that their
+mode matches.  Instead, predicates that accept 'CONST_INT' and/or
+integer 'CONST_DOUBLE' check that the value stored in the constant will
+fit in the requested mode.
+
+ Predicates with this behavior are called "normal".  'genrecog' can
+optimize the instruction recognizer based on knowledge of how normal
+predicates treat modes.  It can also diagnose certain kinds of common
+errors in the use of normal predicates; for instance, it is almost
+always an error to use a normal predicate without specifying a mode.
+
+ Predicates that do something different with their MODE argument are
+called "special".  The generic predicates 'address_operand' and
+'pmode_register_operand' are special predicates.  'genrecog' does not do
+any optimizations or diagnosis when special predicates are used.
+
+* Menu:
+
+* Machine-Independent Predicates::  Predicates available to all back ends.
+* Defining Predicates::             How to write machine-specific predicate
+                                    functions.
+
+
+File: gccint.info,  Node: Machine-Independent Predicates,  Next: Defining Predicates,  Up: Predicates
+
+16.7.1 Machine-Independent Predicates
+-------------------------------------
+
+These are the generic predicates available to all back ends.  They are
+defined in 'recog.c'.  The first category of predicates allow only
+constant, or "immediate", operands.
+
+ -- Function: immediate_operand
+     This predicate allows any sort of constant that fits in MODE.  It
+     is an appropriate choice for instructions that take operands that
+     must be constant.
+
+ -- Function: const_int_operand
+     This predicate allows any 'CONST_INT' expression that fits in MODE.
+     It is an appropriate choice for an immediate operand that does not
+     allow a symbol or label.
+
+ -- Function: const_double_operand
+     This predicate accepts any 'CONST_DOUBLE' expression that has
+     exactly MODE.  If MODE is 'VOIDmode', it will also accept
+     'CONST_INT'.  It is intended for immediate floating point
+     constants.
+
+The second category of predicates allow only some kind of machine
+register.
+
+ -- Function: register_operand
+     This predicate allows any 'REG' or 'SUBREG' expression that is
+     valid for MODE.  It is often suitable for arithmetic instruction
+     operands on a RISC machine.
+
+ -- Function: pmode_register_operand
+     This is a slight variant on 'register_operand' which works around a
+     limitation in the machine-description reader.
+
+          (match_operand N "pmode_register_operand" CONSTRAINT)
+
+     means exactly what
+
+          (match_operand:P N "register_operand" CONSTRAINT)
+
+     would mean, if the machine-description reader accepted ':P' mode
+     suffixes.  Unfortunately, it cannot, because 'Pmode' is an alias
+     for some other mode, and might vary with machine-specific options.
+     *Note Misc::.
+
+ -- Function: scratch_operand
+     This predicate allows hard registers and 'SCRATCH' expressions, but
+     not pseudo-registers.  It is used internally by 'match_scratch'; it
+     should not be used directly.
+
+The third category of predicates allow only some kind of memory
+reference.
+
+ -- Function: memory_operand
+     This predicate allows any valid reference to a quantity of mode
+     MODE in memory, as determined by the weak form of
+     'GO_IF_LEGITIMATE_ADDRESS' (*note Addressing Modes::).
+
+ -- Function: address_operand
+     This predicate is a little unusual; it allows any operand that is a
+     valid expression for the _address_ of a quantity of mode MODE,
+     again determined by the weak form of 'GO_IF_LEGITIMATE_ADDRESS'.
+     To first order, if '(mem:MODE (EXP))' is acceptable to
+     'memory_operand', then EXP is acceptable to 'address_operand'.
+     Note that EXP does not necessarily have the mode MODE.
+
+ -- Function: indirect_operand
+     This is a stricter form of 'memory_operand' which allows only
+     memory references with a 'general_operand' as the address
+     expression.  New uses of this predicate are discouraged, because
+     'general_operand' is very permissive, so it's hard to tell what an
+     'indirect_operand' does or does not allow.  If a target has
+     different requirements for memory operands for different
+     instructions, it is better to define target-specific predicates
+     which enforce the hardware's requirements explicitly.
+
+ -- Function: push_operand
+     This predicate allows a memory reference suitable for pushing a
+     value onto the stack.  This will be a 'MEM' which refers to
+     'stack_pointer_rtx', with a side-effect in its address expression
+     (*note Incdec::); which one is determined by the 'STACK_PUSH_CODE'
+     macro (*note Frame Layout::).
+
+ -- Function: pop_operand
+     This predicate allows a memory reference suitable for popping a
+     value off the stack.  Again, this will be a 'MEM' referring to
+     'stack_pointer_rtx', with a side-effect in its address expression.
+     However, this time 'STACK_POP_CODE' is expected.
+
+The fourth category of predicates allow some combination of the above
+operands.
+
+ -- Function: nonmemory_operand
+     This predicate allows any immediate or register operand valid for
+     MODE.
+
+ -- Function: nonimmediate_operand
+     This predicate allows any register or memory operand valid for
+     MODE.
+
+ -- Function: general_operand
+     This predicate allows any immediate, register, or memory operand
+     valid for MODE.
+
+Finally, there are two generic operator predicates.
+
+ -- Function: comparison_operator
+     This predicate matches any expression which performs an arithmetic
+     comparison in MODE; that is, 'COMPARISON_P' is true for the
+     expression code.
+
+ -- Function: ordered_comparison_operator
+     This predicate matches any expression which performs an arithmetic
+     comparison in MODE and whose expression code is valid for integer
+     modes; that is, the expression code will be one of 'eq', 'ne',
+     'lt', 'ltu', 'le', 'leu', 'gt', 'gtu', 'ge', 'geu'.
+
+
+File: gccint.info,  Node: Defining Predicates,  Prev: Machine-Independent Predicates,  Up: Predicates
+
+16.7.2 Defining Machine-Specific Predicates
+-------------------------------------------
+
+Many machines have requirements for their operands that cannot be
+expressed precisely using the generic predicates.  You can define
+additional predicates using 'define_predicate' and
+'define_special_predicate' expressions.  These expressions have three
+operands:
+
+   * The name of the predicate, as it will be referred to in
+     'match_operand' or 'match_operator' expressions.
+
+   * An RTL expression which evaluates to true if the predicate allows
+     the operand OP, false if it does not.  This expression can only use
+     the following RTL codes:
+
+     'MATCH_OPERAND'
+          When written inside a predicate expression, a 'MATCH_OPERAND'
+          expression evaluates to true if the predicate it names would
+          allow OP.  The operand number and constraint are ignored.  Due
+          to limitations in 'genrecog', you can only refer to generic
+          predicates and predicates that have already been defined.
+
+     'MATCH_CODE'
+          This expression evaluates to true if OP or a specified
+          subexpression of OP has one of a given list of RTX codes.
+
+          The first operand of this expression is a string constant
+          containing a comma-separated list of RTX code names (in lower
+          case).  These are the codes for which the 'MATCH_CODE' will be
+          true.
+
+          The second operand is a string constant which indicates what
+          subexpression of OP to examine.  If it is absent or the empty
+          string, OP itself is examined.  Otherwise, the string constant
+          must be a sequence of digits and/or lowercase letters.  Each
+          character indicates a subexpression to extract from the
+          current expression; for the first character this is OP, for
+          the second and subsequent characters it is the result of the
+          previous character.  A digit N extracts 'XEXP (E, N)'; a
+          letter L extracts 'XVECEXP (E, 0, N)' where N is the
+          alphabetic ordinal of L (0 for 'a', 1 for 'b', and so on).
+          The 'MATCH_CODE' then examines the RTX code of the
+          subexpression extracted by the complete string.  It is not
+          possible to extract components of an 'rtvec' that is not at
+          position 0 within its RTX object.
+
+     'MATCH_TEST'
+          This expression has one operand, a string constant containing
+          a C expression.  The predicate's arguments, OP and MODE, are
+          available with those names in the C expression.  The
+          'MATCH_TEST' evaluates to true if the C expression evaluates
+          to a nonzero value.  'MATCH_TEST' expressions must not have
+          side effects.
+
+     'AND'
+     'IOR'
+     'NOT'
+     'IF_THEN_ELSE'
+          The basic 'MATCH_' expressions can be combined using these
+          logical operators, which have the semantics of the C operators
+          '&&', '||', '!', and '? :' respectively.  As in Common Lisp,
+          you may give an 'AND' or 'IOR' expression an arbitrary number
+          of arguments; this has exactly the same effect as writing a
+          chain of two-argument 'AND' or 'IOR' expressions.
+
+   * An optional block of C code, which should execute 'return true' if
+     the predicate is found to match and 'return false' if it does not.
+     It must not have any side effects.  The predicate arguments, OP and
+     MODE, are available with those names.
+
+     If a code block is present in a predicate definition, then the RTL
+     expression must evaluate to true _and_ the code block must execute
+     'return true' for the predicate to allow the operand.  The RTL
+     expression is evaluated first; do not re-check anything in the code
+     block that was checked in the RTL expression.
+
+ The program 'genrecog' scans 'define_predicate' and
+'define_special_predicate' expressions to determine which RTX codes are
+possibly allowed.  You should always make this explicit in the RTL
+predicate expression, using 'MATCH_OPERAND' and 'MATCH_CODE'.
+
+ Here is an example of a simple predicate definition, from the IA64
+machine description:
+
+     ;; True if OP is a 'SYMBOL_REF' which refers to the sdata section.
+     (define_predicate "small_addr_symbolic_operand"
+       (and (match_code "symbol_ref")
+            (match_test "SYMBOL_REF_SMALL_ADDR_P (op)")))
+
+And here is another, showing the use of the C block.
+
+     ;; True if OP is a register operand that is (or could be) a GR reg.
+     (define_predicate "gr_register_operand"
+       (match_operand 0 "register_operand")
+     {
+       unsigned int regno;
+       if (GET_CODE (op) == SUBREG)
+         op = SUBREG_REG (op);
+
+       regno = REGNO (op);
+       return (regno >= FIRST_PSEUDO_REGISTER || GENERAL_REGNO_P (regno));
+     })
+
+ Predicates written with 'define_predicate' automatically include a test
+that MODE is 'VOIDmode', or OP has the same mode as MODE, or OP is a
+'CONST_INT' or 'CONST_DOUBLE'.  They do _not_ check specifically for
+integer 'CONST_DOUBLE', nor do they test that the value of either kind
+of constant fits in the requested mode.  This is because target-specific
+predicates that take constants usually have to do more stringent value
+checks anyway.  If you need the exact same treatment of 'CONST_INT' or
+'CONST_DOUBLE' that the generic predicates provide, use a
+'MATCH_OPERAND' subexpression to call 'const_int_operand',
+'const_double_operand', or 'immediate_operand'.
+
+ Predicates written with 'define_special_predicate' do not get any
+automatic mode checks, and are treated as having special mode handling
+by 'genrecog'.
+
+ The program 'genpreds' is responsible for generating code to test
+predicates.  It also writes a header file containing function
+declarations for all machine-specific predicates.  It is not necessary
+to declare these predicates in 'CPU-protos.h'.
+
+
+File: gccint.info,  Node: Constraints,  Next: Standard Names,  Prev: Predicates,  Up: Machine Desc
+
+16.8 Operand Constraints
+========================
+
+Each 'match_operand' in an instruction pattern can specify constraints
+for the operands allowed.  The constraints allow you to fine-tune
+matching within the set of operands allowed by the predicate.
+
+ Constraints can say whether an operand may be in a register, and which
+kinds of register; whether the operand can be a memory reference, and
+which kinds of address; whether the operand may be an immediate
+constant, and which possible values it may have.  Constraints can also
+require two operands to match.  Side-effects aren't allowed in operands
+of inline 'asm', unless '<' or '>' constraints are used, because there
+is no guarantee that the side-effects will happen exactly once in an
+instruction that can update the addressing register.
+
+* Menu:
+
+* Simple Constraints::  Basic use of constraints.
+* Multi-Alternative::   When an insn has two alternative constraint-patterns.
+* Class Preferences::   Constraints guide which hard register to put things in.
+* Modifiers::           More precise control over effects of constraints.
+* Machine Constraints:: Existing constraints for some particular machines.
+* Disable Insn Alternatives:: Disable insn alternatives using the 'enabled' attribute.
+* Define Constraints::  How to define machine-specific constraints.
+* C Constraint Interface:: How to test constraints from C code.
+
+
+File: gccint.info,  Node: Simple Constraints,  Next: Multi-Alternative,  Up: Constraints
+
+16.8.1 Simple Constraints
+-------------------------
+
+The simplest kind of constraint is a string full of letters, each of
+which describes one kind of operand that is permitted.  Here are the
+letters that are allowed:
+
+whitespace
+     Whitespace characters are ignored and can be inserted at any
+     position except the first.  This enables each alternative for
+     different operands to be visually aligned in the machine
+     description even if they have different number of constraints and
+     modifiers.
+
+'m'
+     A memory operand is allowed, with any kind of address that the
+     machine supports in general.  Note that the letter used for the
+     general memory constraint can be re-defined by a back end using the
+     'TARGET_MEM_CONSTRAINT' macro.
+
+'o'
+     A memory operand is allowed, but only if the address is
+     "offsettable".  This means that adding a small integer (actually,
+     the width in bytes of the operand, as determined by its machine
+     mode) may be added to the address and the result is also a valid
+     memory address.
+
+     For example, an address which is constant is offsettable; so is an
+     address that is the sum of a register and a constant (as long as a
+     slightly larger constant is also within the range of
+     address-offsets supported by the machine); but an autoincrement or
+     autodecrement address is not offsettable.  More complicated
+     indirect/indexed addresses may or may not be offsettable depending
+     on the other addressing modes that the machine supports.
+
+     Note that in an output operand which can be matched by another
+     operand, the constraint letter 'o' is valid only when accompanied
+     by both '<' (if the target machine has predecrement addressing) and
+     '>' (if the target machine has preincrement addressing).
+
+'V'
+     A memory operand that is not offsettable.  In other words, anything
+     that would fit the 'm' constraint but not the 'o' constraint.
+
+'<'
+     A memory operand with autodecrement addressing (either predecrement
+     or postdecrement) is allowed.  In inline 'asm' this constraint is
+     only allowed if the operand is used exactly once in an instruction
+     that can handle the side-effects.  Not using an operand with '<' in
+     constraint string in the inline 'asm' pattern at all or using it in
+     multiple instructions isn't valid, because the side-effects
+     wouldn't be performed or would be performed more than once.
+     Furthermore, on some targets the operand with '<' in constraint
+     string must be accompanied by special instruction suffixes like
+     '%U0' instruction suffix on PowerPC or '%P0' on IA-64.
+
+'>'
+     A memory operand with autoincrement addressing (either preincrement
+     or postincrement) is allowed.  In inline 'asm' the same
+     restrictions as for '<' apply.
+
+'r'
+     A register operand is allowed provided that it is in a general
+     register.
+
+'i'
+     An immediate integer operand (one with constant value) is allowed.
+     This includes symbolic constants whose values will be known only at
+     assembly time or later.
+
+'n'
+     An immediate integer operand with a known numeric value is allowed.
+     Many systems cannot support assembly-time constants for operands
+     less than a word wide.  Constraints for these operands should use
+     'n' rather than 'i'.
+
+'I', 'J', 'K', ... 'P'
+     Other letters in the range 'I' through 'P' may be defined in a
+     machine-dependent fashion to permit immediate integer operands with
+     explicit integer values in specified ranges.  For example, on the
+     68000, 'I' is defined to stand for the range of values 1 to 8.
+     This is the range permitted as a shift count in the shift
+     instructions.
+
+'E'
+     An immediate floating operand (expression code 'const_double') is
+     allowed, but only if the target floating point format is the same
+     as that of the host machine (on which the compiler is running).
+
+'F'
+     An immediate floating operand (expression code 'const_double' or
+     'const_vector') is allowed.
+
+'G', 'H'
+     'G' and 'H' may be defined in a machine-dependent fashion to permit
+     immediate floating operands in particular ranges of values.
+
+'s'
+     An immediate integer operand whose value is not an explicit integer
+     is allowed.
+
+     This might appear strange; if an insn allows a constant operand
+     with a value not known at compile time, it certainly must allow any
+     known value.  So why use 's' instead of 'i'?  Sometimes it allows
+     better code to be generated.
+
+     For example, on the 68000 in a fullword instruction it is possible
+     to use an immediate operand; but if the immediate value is between
+     -128 and 127, better code results from loading the value into a
+     register and using the register.  This is because the load into the
+     register can be done with a 'moveq' instruction.  We arrange for
+     this to happen by defining the letter 'K' to mean "any integer
+     outside the range -128 to 127", and then specifying 'Ks' in the
+     operand constraints.
+
+'g'
+     Any register, memory or immediate integer operand is allowed,
+     except for registers that are not general registers.
+
+'X'
+     Any operand whatsoever is allowed, even if it does not satisfy
+     'general_operand'.  This is normally used in the constraint of a
+     'match_scratch' when certain alternatives will not actually require
+     a scratch register.
+
+'0', '1', '2', ... '9'
+     An operand that matches the specified operand number is allowed.
+     If a digit is used together with letters within the same
+     alternative, the digit should come last.
+
+     This number is allowed to be more than a single digit.  If multiple
+     digits are encountered consecutively, they are interpreted as a
+     single decimal integer.  There is scant chance for ambiguity, since
+     to-date it has never been desirable that '10' be interpreted as
+     matching either operand 1 _or_ operand 0.  Should this be desired,
+     one can use multiple alternatives instead.
+
+     This is called a "matching constraint" and what it really means is
+     that the assembler has only a single operand that fills two roles
+     considered separate in the RTL insn.  For example, an add insn has
+     two input operands and one output operand in the RTL, but on most
+     CISC machines an add instruction really has only two operands, one
+     of them an input-output operand:
+
+          addl #35,r12
+
+     Matching constraints are used in these circumstances.  More
+     precisely, the two operands that match must include one input-only
+     operand and one output-only operand.  Moreover, the digit must be a
+     smaller number than the number of the operand that uses it in the
+     constraint.
+
+     For operands to match in a particular case usually means that they
+     are identical-looking RTL expressions.  But in a few special cases
+     specific kinds of dissimilarity are allowed.  For example, '*x' as
+     an input operand will match '*x++' as an output operand.  For
+     proper results in such cases, the output template should always use
+     the output-operand's number when printing the operand.
+
+'p'
+     An operand that is a valid memory address is allowed.  This is for
+     "load address" and "push address" instructions.
+
+     'p' in the constraint must be accompanied by 'address_operand' as
+     the predicate in the 'match_operand'.  This predicate interprets
+     the mode specified in the 'match_operand' as the mode of the memory
+     reference for which the address would be valid.
+
+OTHER-LETTERS
+     Other letters can be defined in machine-dependent fashion to stand
+     for particular classes of registers or other arbitrary operand
+     types.  'd', 'a' and 'f' are defined on the 68000/68020 to stand
+     for data, address and floating point registers.
+
+ In order to have valid assembler code, each operand must satisfy its
+constraint.  But a failure to do so does not prevent the pattern from
+applying to an insn.  Instead, it directs the compiler to modify the
+code so that the constraint will be satisfied.  Usually this is done by
+copying an operand into a register.
+
+ Contrast, therefore, the two instruction patterns that follow:
+
+     (define_insn ""
+       [(set (match_operand:SI 0 "general_operand" "=r")
+             (plus:SI (match_dup 0)
+                      (match_operand:SI 1 "general_operand" "r")))]
+       ""
+       "...")
+
+which has two operands, one of which must appear in two places, and
+
+     (define_insn ""
+       [(set (match_operand:SI 0 "general_operand" "=r")
+             (plus:SI (match_operand:SI 1 "general_operand" "0")
+                      (match_operand:SI 2 "general_operand" "r")))]
+       ""
+       "...")
+
+which has three operands, two of which are required by a constraint to
+be identical.  If we are considering an insn of the form
+
+     (insn N PREV NEXT
+       (set (reg:SI 3)
+            (plus:SI (reg:SI 6) (reg:SI 109)))
+       ...)
+
+the first pattern would not apply at all, because this insn does not
+contain two identical subexpressions in the right place.  The pattern
+would say, "That does not look like an add instruction; try other
+patterns".  The second pattern would say, "Yes, that's an add
+instruction, but there is something wrong with it".  It would direct the
+reload pass of the compiler to generate additional insns to make the
+constraint true.  The results might look like this:
+
+     (insn N2 PREV N
+       (set (reg:SI 3) (reg:SI 6))
+       ...)
+
+     (insn N N2 NEXT
+       (set (reg:SI 3)
+            (plus:SI (reg:SI 3) (reg:SI 109)))
+       ...)
+
+ It is up to you to make sure that each operand, in each pattern, has
+constraints that can handle any RTL expression that could be present for
+that operand.  (When multiple alternatives are in use, each pattern
+must, for each possible combination of operand expressions, have at
+least one alternative which can handle that combination of operands.)
+The constraints don't need to _allow_ any possible operand--when this is
+the case, they do not constrain--but they must at least point the way to
+reloading any possible operand so that it will fit.
+
+   * If the constraint accepts whatever operands the predicate permits,
+     there is no problem: reloading is never necessary for this operand.
+
+     For example, an operand whose constraints permit everything except
+     registers is safe provided its predicate rejects registers.
+
+     An operand whose predicate accepts only constant values is safe
+     provided its constraints include the letter 'i'.  If any possible
+     constant value is accepted, then nothing less than 'i' will do; if
+     the predicate is more selective, then the constraints may also be
+     more selective.
+
+   * Any operand expression can be reloaded by copying it into a
+     register.  So if an operand's constraints allow some kind of
+     register, it is certain to be safe.  It need not permit all classes
+     of registers; the compiler knows how to copy a register into
+     another register of the proper class in order to make an
+     instruction valid.
+
+   * A nonoffsettable memory reference can be reloaded by copying the
+     address into a register.  So if the constraint uses the letter 'o',
+     all memory references are taken care of.
+
+   * A constant operand can be reloaded by allocating space in memory to
+     hold it as preinitialized data.  Then the memory reference can be
+     used in place of the constant.  So if the constraint uses the
+     letters 'o' or 'm', constant operands are not a problem.
+
+   * If the constraint permits a constant and a pseudo register used in
+     an insn was not allocated to a hard register and is equivalent to a
+     constant, the register will be replaced with the constant.  If the
+     predicate does not permit a constant and the insn is re-recognized
+     for some reason, the compiler will crash.  Thus the predicate must
+     always recognize any objects allowed by the constraint.
+
+ If the operand's predicate can recognize registers, but the constraint
+does not permit them, it can make the compiler crash.  When this operand
+happens to be a register, the reload pass will be stymied, because it
+does not know how to copy a register temporarily into memory.
+
+ If the predicate accepts a unary operator, the constraint applies to
+the operand.  For example, the MIPS processor at ISA level 3 supports an
+instruction which adds two registers in 'SImode' to produce a 'DImode'
+result, but only if the registers are correctly sign extended.  This
+predicate for the input operands accepts a 'sign_extend' of an 'SImode'
+register.  Write the constraint to indicate the type of register that is
+required for the operand of the 'sign_extend'.
+
+
+File: gccint.info,  Node: Multi-Alternative,  Next: Class Preferences,  Prev: Simple Constraints,  Up: Constraints
+
+16.8.2 Multiple Alternative Constraints
+---------------------------------------
+
+Sometimes a single instruction has multiple alternative sets of possible
+operands.  For example, on the 68000, a logical-or instruction can
+combine register or an immediate value into memory, or it can combine
+any kind of operand into a register; but it cannot combine one memory
+location into another.
+
+ These constraints are represented as multiple alternatives.  An
+alternative can be described by a series of letters for each operand.
+The overall constraint for an operand is made from the letters for this
+operand from the first alternative, a comma, the letters for this
+operand from the second alternative, a comma, and so on until the last
+alternative.  Here is how it is done for fullword logical-or on the
+68000:
+
+     (define_insn "iorsi3"
+       [(set (match_operand:SI 0 "general_operand" "=m,d")
+             (ior:SI (match_operand:SI 1 "general_operand" "%0,0")
+                     (match_operand:SI 2 "general_operand" "dKs,dmKs")))]
+       ...)
+
+ The first alternative has 'm' (memory) for operand 0, '0' for operand 1
+(meaning it must match operand 0), and 'dKs' for operand 2.  The second
+alternative has 'd' (data register) for operand 0, '0' for operand 1,
+and 'dmKs' for operand 2.  The '=' and '%' in the constraints apply to
+all the alternatives; their meaning is explained in the next section
+(*note Class Preferences::).
+
+ If all the operands fit any one alternative, the instruction is valid.
+Otherwise, for each alternative, the compiler counts how many
+instructions must be added to copy the operands so that that alternative
+applies.  The alternative requiring the least copying is chosen.  If two
+alternatives need the same amount of copying, the one that comes first
+is chosen.  These choices can be altered with the '?' and '!'
+characters:
+
+'?'
+     Disparage slightly the alternative that the '?' appears in, as a
+     choice when no alternative applies exactly.  The compiler regards
+     this alternative as one unit more costly for each '?' that appears
+     in it.
+
+'!'
+     Disparage severely the alternative that the '!' appears in.  This
+     alternative can still be used if it fits without reloading, but if
+     reloading is needed, some other alternative will be used.
+
+ When an insn pattern has multiple alternatives in its constraints,
+often the appearance of the assembler code is determined mostly by which
+alternative was matched.  When this is so, the C code for writing the
+assembler code can use the variable 'which_alternative', which is the
+ordinal number of the alternative that was actually satisfied (0 for the
+first, 1 for the second alternative, etc.).  *Note Output Statement::.
+
+
+File: gccint.info,  Node: Class Preferences,  Next: Modifiers,  Prev: Multi-Alternative,  Up: Constraints
+
+16.8.3 Register Class Preferences
+---------------------------------
+
+The operand constraints have another function: they enable the compiler
+to decide which kind of hardware register a pseudo register is best
+allocated to.  The compiler examines the constraints that apply to the
+insns that use the pseudo register, looking for the machine-dependent
+letters such as 'd' and 'a' that specify classes of registers.  The
+pseudo register is put in whichever class gets the most "votes".  The
+constraint letters 'g' and 'r' also vote: they vote in favor of a
+general register.  The machine description says which registers are
+considered general.
+
+ Of course, on some machines all registers are equivalent, and no
+register classes are defined.  Then none of this complexity is relevant.
+
+
+File: gccint.info,  Node: Modifiers,  Next: Machine Constraints,  Prev: Class Preferences,  Up: Constraints
+
+16.8.4 Constraint Modifier Characters
+-------------------------------------
+
+Here are constraint modifier characters.
+
+'='
+     Means that this operand is write-only for this instruction: the
+     previous value is discarded and replaced by output data.
+
+'+'
+     Means that this operand is both read and written by the
+     instruction.
+
+     When the compiler fixes up the operands to satisfy the constraints,
+     it needs to know which operands are inputs to the instruction and
+     which are outputs from it.  '=' identifies an output; '+'
+     identifies an operand that is both input and output; all other
+     operands are assumed to be input only.
+
+     If you specify '=' or '+' in a constraint, you put it in the first
+     character of the constraint string.
+
+'&'
+     Means (in a particular alternative) that this operand is an
+     "earlyclobber" operand, which is modified before the instruction is
+     finished using the input operands.  Therefore, this operand may not
+     lie in a register that is used as an input operand or as part of
+     any memory address.
+
+     '&' applies only to the alternative in which it is written.  In
+     constraints with multiple alternatives, sometimes one alternative
+     requires '&' while others do not.  See, for example, the 'movdf'
+     insn of the 68000.
+
+     An input operand can be tied to an earlyclobber operand if its only
+     use as an input occurs before the early result is written.  Adding
+     alternatives of this form often allows GCC to produce better code
+     when only some of the inputs can be affected by the earlyclobber.
+     See, for example, the 'mulsi3' insn of the ARM.
+
+     '&' does not obviate the need to write '='.
+
+'%'
+     Declares the instruction to be commutative for this operand and the
+     following operand.  This means that the compiler may interchange
+     the two operands if that is the cheapest way to make all operands
+     fit the constraints.  This is often used in patterns for addition
+     instructions that really have only two operands: the result must go
+     in one of the arguments.  Here for example, is how the 68000
+     halfword-add instruction is defined:
+
+          (define_insn "addhi3"
+            [(set (match_operand:HI 0 "general_operand" "=m,r")
+               (plus:HI (match_operand:HI 1 "general_operand" "%0,0")
+                        (match_operand:HI 2 "general_operand" "di,g")))]
+            ...)
+     GCC can only handle one commutative pair in an asm; if you use
+     more, the compiler may fail.  Note that you need not use the
+     modifier if the two alternatives are strictly identical; this would
+     only waste time in the reload pass.  The modifier is not
+     operational after register allocation, so the result of
+     'define_peephole2' and 'define_split's performed after reload
+     cannot rely on '%' to make the intended insn match.
+
+'#'
+     Says that all following characters, up to the next comma, are to be
+     ignored as a constraint.  They are significant only for choosing
+     register preferences.
+
+'*'
+     Says that the following character should be ignored when choosing
+     register preferences.  '*' has no effect on the meaning of the
+     constraint as a constraint, and no effect on reloading.  For LRA
+     '*' additionally disparages slightly the alternative if the
+     following character matches the operand.
+
+     Here is an example: the 68000 has an instruction to sign-extend a
+     halfword in a data register, and can also sign-extend a value by
+     copying it into an address register.  While either kind of register
+     is acceptable, the constraints on an address-register destination
+     are less strict, so it is best if register allocation makes an
+     address register its goal.  Therefore, '*' is used so that the 'd'
+     constraint letter (for data register) is ignored when computing
+     register preferences.
+
+          (define_insn "extendhisi2"
+            [(set (match_operand:SI 0 "general_operand" "=*d,a")
+                  (sign_extend:SI
+                   (match_operand:HI 1 "general_operand" "0,g")))]
+            ...)
+
+
+File: gccint.info,  Node: Machine Constraints,  Next: Disable Insn Alternatives,  Prev: Modifiers,  Up: Constraints
+
+16.8.5 Constraints for Particular Machines
+------------------------------------------
+
+Whenever possible, you should use the general-purpose constraint letters
+in 'asm' arguments, since they will convey meaning more readily to
+people reading your code.  Failing that, use the constraint letters that
+usually have very similar meanings across architectures.  The most
+commonly used constraints are 'm' and 'r' (for memory and
+general-purpose registers respectively; *note Simple Constraints::), and
+'I', usually the letter indicating the most common immediate-constant
+format.
+
+ Each architecture defines additional constraints.  These constraints
+are used by the compiler itself for instruction generation, as well as
+for 'asm' statements; therefore, some of the constraints are not
+particularly useful for 'asm'.  Here is a summary of some of the
+machine-dependent constraints available on some particular machines; it
+includes both constraints that are useful for 'asm' and constraints that
+aren't.  The compiler source file mentioned in the table heading for
+each architecture is the definitive reference for the meanings of that
+architecture's constraints.
+
+_AArch64 family--'config/aarch64/constraints.md'_
+     'k'
+          The stack pointer register ('SP')
+
+     'w'
+          Floating point or SIMD vector register
+
+     'I'
+          Integer constant that is valid as an immediate operand in an
+          'ADD' instruction
+
+     'J'
+          Integer constant that is valid as an immediate operand in a
+          'SUB' instruction (once negated)
+
+     'K'
+          Integer constant that can be used with a 32-bit logical
+          instruction
+
+     'L'
+          Integer constant that can be used with a 64-bit logical
+          instruction
+
+     'M'
+          Integer constant that is valid as an immediate operand in a
+          32-bit 'MOV' pseudo instruction.  The 'MOV' may be assembled
+          to one of several different machine instructions depending on
+          the value
+
+     'N'
+          Integer constant that is valid as an immediate operand in a
+          64-bit 'MOV' pseudo instruction
+
+     'S'
+          An absolute symbolic address or a label reference
+
+     'Y'
+          Floating point constant zero
+
+     'Z'
+          Integer constant zero
+
+     'Ush'
+          The high part (bits 12 and upwards) of the pc-relative address
+          of a symbol within 4GB of the instruction
+
+     'Q'
+          A memory address which uses a single base register with no
+          offset
+
+     'Ump'
+          A memory address suitable for a load/store pair instruction in
+          SI, DI, SF and DF modes
+
+_ARC --'config/arc/constraints.md'_
+     'q'
+          Registers usable in ARCompact 16-bit instructions: 'r0'-'r3',
+          'r12'-'r15'.  This constraint can only match when the '-mq'
+          option is in effect.
+
+     'e'
+          Registers usable as base-regs of memory addresses in ARCompact
+          16-bit memory instructions: 'r0'-'r3', 'r12'-'r15', 'sp'.
+          This constraint can only match when the '-mq' option is in
+          effect.
+     'D'
+          ARC FPX (dpfp) 64-bit registers.  'D0', 'D1'.
+
+     'I'
+          A signed 12-bit integer constant.
+
+     'Cal'
+          constant for arithmetic/logical operations.  This might be any
+          constant that can be put into a long immediate by the assmbler
+          or linker without involving a PIC relocation.
+
+     'K'
+          A 3-bit unsigned integer constant.
+
+     'L'
+          A 6-bit unsigned integer constant.
+
+     'CnL'
+          One's complement of a 6-bit unsigned integer constant.
+
+     'CmL'
+          Two's complement of a 6-bit unsigned integer constant.
+
+     'M'
+          A 5-bit unsigned integer constant.
+
+     'O'
+          A 7-bit unsigned integer constant.
+
+     'P'
+          A 8-bit unsigned integer constant.
+
+     'H'
+          Any const_double value.
+
+_ARM family--'config/arm/constraints.md'_
+     'w'
+          VFP floating-point register
+
+     'G'
+          The floating-point constant 0.0
+
+     'I'
+          Integer that is valid as an immediate operand in a data
+          processing instruction.  That is, an integer in the range 0 to
+          255 rotated by a multiple of 2
+
+     'J'
+          Integer in the range -4095 to 4095
+
+     'K'
+          Integer that satisfies constraint 'I' when inverted (ones
+          complement)
+
+     'L'
+          Integer that satisfies constraint 'I' when negated (twos
+          complement)
+
+     'M'
+          Integer in the range 0 to 32
+
+     'Q'
+          A memory reference where the exact address is in a single
+          register (''m'' is preferable for 'asm' statements)
+
+     'R'
+          An item in the constant pool
+
+     'S'
+          A symbol in the text segment of the current file
+
+     'Uv'
+          A memory reference suitable for VFP load/store insns
+          (reg+constant offset)
+
+     'Uy'
+          A memory reference suitable for iWMMXt load/store
+          instructions.
+
+     'Uq'
+          A memory reference suitable for the ARMv4 ldrsb instruction.
+
+_AVR family--'config/avr/constraints.md'_
+     'l'
+          Registers from r0 to r15
+
+     'a'
+          Registers from r16 to r23
+
+     'd'
+          Registers from r16 to r31
+
+     'w'
+          Registers from r24 to r31.  These registers can be used in
+          'adiw' command
+
+     'e'
+          Pointer register (r26-r31)
+
+     'b'
+          Base pointer register (r28-r31)
+
+     'q'
+          Stack pointer register (SPH:SPL)
+
+     't'
+          Temporary register r0
+
+     'x'
+          Register pair X (r27:r26)
+
+     'y'
+          Register pair Y (r29:r28)
+
+     'z'
+          Register pair Z (r31:r30)
+
+     'I'
+          Constant greater than -1, less than 64
+
+     'J'
+          Constant greater than -64, less than 1
+
+     'K'
+          Constant integer 2
+
+     'L'
+          Constant integer 0
+
+     'M'
+          Constant that fits in 8 bits
+
+     'N'
+          Constant integer -1
+
+     'O'
+          Constant integer 8, 16, or 24
+
+     'P'
+          Constant integer 1
+
+     'G'
+          A floating point constant 0.0
+
+     'Q'
+          A memory address based on Y or Z pointer with displacement.
+
+_Epiphany--'config/epiphany/constraints.md'_
+     'U16'
+          An unsigned 16-bit constant.
+
+     'K'
+          An unsigned 5-bit constant.
+
+     'L'
+          A signed 11-bit constant.
+
+     'Cm1'
+          A signed 11-bit constant added to -1.  Can only match when the
+          '-m1reg-REG' option is active.
+
+     'Cl1'
+          Left-shift of -1, i.e., a bit mask with a block of leading
+          ones, the rest being a block of trailing zeroes.  Can only
+          match when the '-m1reg-REG' option is active.
+
+     'Cr1'
+          Right-shift of -1, i.e., a bit mask with a trailing block of
+          ones, the rest being zeroes.  Or to put it another way, one
+          less than a power of two.  Can only match when the
+          '-m1reg-REG' option is active.
+
+     'Cal'
+          Constant for arithmetic/logical operations.  This is like 'i',
+          except that for position independent code, no symbols /
+          expressions needing relocations are allowed.
+
+     'Csy'
+          Symbolic constant for call/jump instruction.
+
+     'Rcs'
+          The register class usable in short insns.  This is a register
+          class constraint, and can thus drive register allocation.
+          This constraint won't match unless '-mprefer-short-insn-regs'
+          is in effect.
+
+     'Rsc'
+          The the register class of registers that can be used to hold a
+          sibcall call address.  I.e., a caller-saved register.
+
+     'Rct'
+          Core control register class.
+
+     'Rgs'
+          The register group usable in short insns.  This constraint
+          does not use a register class, so that it only passively
+          matches suitable registers, and doesn't drive register
+          allocation.
+
+     'Car'
+          Constant suitable for the addsi3_r pattern.  This is a valid
+          offset For byte, halfword, or word addressing.
+
+     'Rra'
+          Matches the return address if it can be replaced with the link
+          register.
+
+     'Rcc'
+          Matches the integer condition code register.
+
+     'Sra'
+          Matches the return address if it is in a stack slot.
+
+     'Cfm'
+          Matches control register values to switch fp mode, which are
+          encapsulated in 'UNSPEC_FP_MODE'.
+
+_CR16 Architecture--'config/cr16/cr16.h'_
+
+     'b'
+          Registers from r0 to r14 (registers without stack pointer)
+
+     't'
+          Register from r0 to r11 (all 16-bit registers)
+
+     'p'
+          Register from r12 to r15 (all 32-bit registers)
+
+     'I'
+          Signed constant that fits in 4 bits
+
+     'J'
+          Signed constant that fits in 5 bits
+
+     'K'
+          Signed constant that fits in 6 bits
+
+     'L'
+          Unsigned constant that fits in 4 bits
+
+     'M'
+          Signed constant that fits in 32 bits
+
+     'N'
+          Check for 64 bits wide constants for add/sub instructions
+
+     'G'
+          Floating point constant that is legal for store immediate
+
+_Hewlett-Packard PA-RISC--'config/pa/pa.h'_
+     'a'
+          General register 1
+
+     'f'
+          Floating point register
+
+     'q'
+          Shift amount register
+
+     'x'
+          Floating point register (deprecated)
+
+     'y'
+          Upper floating point register (32-bit), floating point
+          register (64-bit)
+
+     'Z'
+          Any register
+
+     'I'
+          Signed 11-bit integer constant
+
+     'J'
+          Signed 14-bit integer constant
+
+     'K'
+          Integer constant that can be deposited with a 'zdepi'
+          instruction
+
+     'L'
+          Signed 5-bit integer constant
+
+     'M'
+          Integer constant 0
+
+     'N'
+          Integer constant that can be loaded with a 'ldil' instruction
+
+     'O'
+          Integer constant whose value plus one is a power of 2
+
+     'P'
+          Integer constant that can be used for 'and' operations in
+          'depi' and 'extru' instructions
+
+     'S'
+          Integer constant 31
+
+     'U'
+          Integer constant 63
+
+     'G'
+          Floating-point constant 0.0
+
+     'A'
+          A 'lo_sum' data-linkage-table memory operand
+
+     'Q'
+          A memory operand that can be used as the destination operand
+          of an integer store instruction
+
+     'R'
+          A scaled or unscaled indexed memory operand
+
+     'T'
+          A memory operand for floating-point loads and stores
+
+     'W'
+          A register indirect memory operand
+
+_picoChip family--'picochip.h'_
+     'k'
+          Stack register.
+
+     'f'
+          Pointer register.  A register which can be used to access
+          memory without supplying an offset.  Any other register can be
+          used to access memory, but will need a constant offset.  In
+          the case of the offset being zero, it is more efficient to use
+          a pointer register, since this reduces code size.
+
+     't'
+          A twin register.  A register which may be paired with an
+          adjacent register to create a 32-bit register.
+
+     'a'
+          Any absolute memory address (e.g., symbolic constant, symbolic
+          constant + offset).
+
+     'I'
+          4-bit signed integer.
+
+     'J'
+          4-bit unsigned integer.
+
+     'K'
+          8-bit signed integer.
+
+     'M'
+          Any constant whose absolute value is no greater than 4-bits.
+
+     'N'
+          10-bit signed integer
+
+     'O'
+          16-bit signed integer.
+
+_PowerPC and IBM RS6000--'config/rs6000/constraints.md'_
+     'b'
+          Address base register
+
+     'd'
+          Floating point register (containing 64-bit value)
+
+     'f'
+          Floating point register (containing 32-bit value)
+
+     'v'
+          Altivec vector register
+
+     'wa'
+          Any VSX register if the -mvsx option was used or NO_REGS.
+
+     'wd'
+          VSX vector register to hold vector double data or NO_REGS.
+
+     'wf'
+          VSX vector register to hold vector float data or NO_REGS.
+
+     'wg'
+          If '-mmfpgpr' was used, a floating point register or NO_REGS.
+
+     'wl'
+          Floating point register if the LFIWAX instruction is enabled
+          or NO_REGS.
+
+     'wm'
+          VSX register if direct move instructions are enabled, or
+          NO_REGS.
+
+     'wn'
+          No register (NO_REGS).
+
+     'wr'
+          General purpose register if 64-bit instructions are enabled or
+          NO_REGS.
+
+     'ws'
+          VSX vector register to hold scalar double values or NO_REGS.
+
+     'wt'
+          VSX vector register to hold 128 bit integer or NO_REGS.
+
+     'wu'
+          Altivec register to use for float/32-bit int loads/stores or
+          NO_REGS.
+
+     'wv'
+          Altivec register to use for double loads/stores or NO_REGS.
+
+     'ww'
+          FP or VSX register to perform float operations under '-mvsx'
+          or NO_REGS.
+
+     'wx'
+          Floating point register if the STFIWX instruction is enabled
+          or NO_REGS.
+
+     'wy'
+          VSX vector register to hold scalar float values or NO_REGS.
+
+     'wz'
+          Floating point register if the LFIWZX instruction is enabled
+          or NO_REGS.
+
+     'wD'
+          Int constant that is the element number of the 64-bit scalar
+          in a vector.
+
+     'wQ'
+          A memory address that will work with the 'lq' and 'stq'
+          instructions.
+
+     'h'
+          'MQ', 'CTR', or 'LINK' register
+
+     'q'
+          'MQ' register
+
+     'c'
+          'CTR' register
+
+     'l'
+          'LINK' register
+
+     'x'
+          'CR' register (condition register) number 0
+
+     'y'
+          'CR' register (condition register)
+
+     'z'
+          'XER[CA]' carry bit (part of the XER register)
+
+     'I'
+          Signed 16-bit constant
+
+     'J'
+          Unsigned 16-bit constant shifted left 16 bits (use 'L' instead
+          for 'SImode' constants)
+
+     'K'
+          Unsigned 16-bit constant
+
+     'L'
+          Signed 16-bit constant shifted left 16 bits
+
+     'M'
+          Constant larger than 31
+
+     'N'
+          Exact power of 2
+
+     'O'
+          Zero
+
+     'P'
+          Constant whose negation is a signed 16-bit constant
+
+     'G'
+          Floating point constant that can be loaded into a register
+          with one instruction per word
+
+     'H'
+          Integer/Floating point constant that can be loaded into a
+          register using three instructions
+
+     'm'
+          Memory operand.  Normally, 'm' does not allow addresses that
+          update the base register.  If '<' or '>' constraint is also
+          used, they are allowed and therefore on PowerPC targets in
+          that case it is only safe to use 'm<>' in an 'asm' statement
+          if that 'asm' statement accesses the operand exactly once.
+          The 'asm' statement must also use '%U<OPNO>' as a placeholder
+          for the "update" flag in the corresponding load or store
+          instruction.  For example:
+
+               asm ("st%U0 %1,%0" : "=m<>" (mem) : "r" (val));
+
+          is correct but:
+
+               asm ("st %1,%0" : "=m<>" (mem) : "r" (val));
+
+          is not.
+
+     'es'
+          A "stable" memory operand; that is, one which does not include
+          any automodification of the base register.  This used to be
+          useful when 'm' allowed automodification of the base register,
+          but as those are now only allowed when '<' or '>' is used,
+          'es' is basically the same as 'm' without '<' and '>'.
+
+     'Q'
+          Memory operand that is an offset from a register (it is
+          usually better to use 'm' or 'es' in 'asm' statements)
+
+     'Z'
+          Memory operand that is an indexed or indirect from a register
+          (it is usually better to use 'm' or 'es' in 'asm' statements)
+
+     'R'
+          AIX TOC entry
+
+     'a'
+          Address operand that is an indexed or indirect from a register
+          ('p' is preferable for 'asm' statements)
+
+     'S'
+          Constant suitable as a 64-bit mask operand
+
+     'T'
+          Constant suitable as a 32-bit mask operand
+
+     'U'
+          System V Release 4 small data area reference
+
+     't'
+          AND masks that can be performed by two rldic{l, r}
+          instructions
+
+     'W'
+          Vector constant that does not require memory
+
+     'j'
+          Vector constant that is all zeros.
+
+_Intel 386--'config/i386/constraints.md'_
+     'R'
+          Legacy register--the eight integer registers available on all
+          i386 processors ('a', 'b', 'c', 'd', 'si', 'di', 'bp', 'sp').
+
+     'q'
+          Any register accessible as 'Rl'.  In 32-bit mode, 'a', 'b',
+          'c', and 'd'; in 64-bit mode, any integer register.
+
+     'Q'
+          Any register accessible as 'Rh': 'a', 'b', 'c', and 'd'.
+
+     'l'
+          Any register that can be used as the index in a base+index
+          memory access: that is, any general register except the stack
+          pointer.
+
+     'a'
+          The 'a' register.
+
+     'b'
+          The 'b' register.
+
+     'c'
+          The 'c' register.
+
+     'd'
+          The 'd' register.
+
+     'S'
+          The 'si' register.
+
+     'D'
+          The 'di' register.
+
+     'A'
+          The 'a' and 'd' registers.  This class is used for
+          instructions that return double word results in the 'ax:dx'
+          register pair.  Single word values will be allocated either in
+          'ax' or 'dx'.  For example on i386 the following implements
+          'rdtsc':
+
+               unsigned long long rdtsc (void)
+               {
+                 unsigned long long tick;
+                 __asm__ __volatile__("rdtsc":"=A"(tick));
+                 return tick;
+               }
+
+          This is not correct on x86_64 as it would allocate tick in
+          either 'ax' or 'dx'.  You have to use the following variant
+          instead:
+
+               unsigned long long rdtsc (void)
+               {
+                 unsigned int tickl, tickh;
+                 __asm__ __volatile__("rdtsc":"=a"(tickl),"=d"(tickh));
+                 return ((unsigned long long)tickh << 32)|tickl;
+               }
+
+     'f'
+          Any 80387 floating-point (stack) register.
+
+     't'
+          Top of 80387 floating-point stack ('%st(0)').
+
+     'u'
+          Second from top of 80387 floating-point stack ('%st(1)').
+
+     'y'
+          Any MMX register.
+
+     'x'
+          Any SSE register.
+
+     'Yz'
+          First SSE register ('%xmm0').
+
+     'Y2'
+          Any SSE register, when SSE2 is enabled.
+
+     'Yi'
+          Any SSE register, when SSE2 and inter-unit moves are enabled.
+
+     'Ym'
+          Any MMX register, when inter-unit moves are enabled.
+
+     'I'
+          Integer constant in the range 0 ... 31, for 32-bit shifts.
+
+     'J'
+          Integer constant in the range 0 ... 63, for 64-bit shifts.
+
+     'K'
+          Signed 8-bit integer constant.
+
+     'L'
+          '0xFF' or '0xFFFF', for andsi as a zero-extending move.
+
+     'M'
+          0, 1, 2, or 3 (shifts for the 'lea' instruction).
+
+     'N'
+          Unsigned 8-bit integer constant (for 'in' and 'out'
+          instructions).
+
+     'O'
+          Integer constant in the range 0 ... 127, for 128-bit shifts.
+
+     'G'
+          Standard 80387 floating point constant.
+
+     'C'
+          Standard SSE floating point constant.
+
+     'e'
+          32-bit signed integer constant, or a symbolic reference known
+          to fit that range (for immediate operands in sign-extending
+          x86-64 instructions).
+
+     'Z'
+          32-bit unsigned integer constant, or a symbolic reference
+          known to fit that range (for immediate operands in
+          zero-extending x86-64 instructions).
+
+_Intel IA-64--'config/ia64/ia64.h'_
+     'a'
+          General register 'r0' to 'r3' for 'addl' instruction
+
+     'b'
+          Branch register
+
+     'c'
+          Predicate register ('c' as in "conditional")
+
+     'd'
+          Application register residing in M-unit
+
+     'e'
+          Application register residing in I-unit
+
+     'f'
+          Floating-point register
+
+     'm'
+          Memory operand.  If used together with '<' or '>', the operand
+          can have postincrement and postdecrement which require
+          printing with '%Pn' on IA-64.
+
+     'G'
+          Floating-point constant 0.0 or 1.0
+
+     'I'
+          14-bit signed integer constant
+
+     'J'
+          22-bit signed integer constant
+
+     'K'
+          8-bit signed integer constant for logical instructions
+
+     'L'
+          8-bit adjusted signed integer constant for compare pseudo-ops
+
+     'M'
+          6-bit unsigned integer constant for shift counts
+
+     'N'
+          9-bit signed integer constant for load and store
+          postincrements
+
+     'O'
+          The constant zero
+
+     'P'
+          0 or -1 for 'dep' instruction
+
+     'Q'
+          Non-volatile memory for floating-point loads and stores
+
+     'R'
+          Integer constant in the range 1 to 4 for 'shladd' instruction
+
+     'S'
+          Memory operand except postincrement and postdecrement.  This
+          is now roughly the same as 'm' when not used together with '<'
+          or '>'.
+
+_FRV--'config/frv/frv.h'_
+     'a'
+          Register in the class 'ACC_REGS' ('acc0' to 'acc7').
+
+     'b'
+          Register in the class 'EVEN_ACC_REGS' ('acc0' to 'acc7').
+
+     'c'
+          Register in the class 'CC_REGS' ('fcc0' to 'fcc3' and 'icc0'
+          to 'icc3').
+
+     'd'
+          Register in the class 'GPR_REGS' ('gr0' to 'gr63').
+
+     'e'
+          Register in the class 'EVEN_REGS' ('gr0' to 'gr63').  Odd
+          registers are excluded not in the class but through the use of
+          a machine mode larger than 4 bytes.
+
+     'f'
+          Register in the class 'FPR_REGS' ('fr0' to 'fr63').
+
+     'h'
+          Register in the class 'FEVEN_REGS' ('fr0' to 'fr63').  Odd
+          registers are excluded not in the class but through the use of
+          a machine mode larger than 4 bytes.
+
+     'l'
+          Register in the class 'LR_REG' (the 'lr' register).
+
+     'q'
+          Register in the class 'QUAD_REGS' ('gr2' to 'gr63').  Register
+          numbers not divisible by 4 are excluded not in the class but
+          through the use of a machine mode larger than 8 bytes.
+
+     't'
+          Register in the class 'ICC_REGS' ('icc0' to 'icc3').
+
+     'u'
+          Register in the class 'FCC_REGS' ('fcc0' to 'fcc3').
+
+     'v'
+          Register in the class 'ICR_REGS' ('cc4' to 'cc7').
+
+     'w'
+          Register in the class 'FCR_REGS' ('cc0' to 'cc3').
+
+     'x'
+          Register in the class 'QUAD_FPR_REGS' ('fr0' to 'fr63').
+          Register numbers not divisible by 4 are excluded not in the
+          class but through the use of a machine mode larger than 8
+          bytes.
+
+     'z'
+          Register in the class 'SPR_REGS' ('lcr' and 'lr').
+
+     'A'
+          Register in the class 'QUAD_ACC_REGS' ('acc0' to 'acc7').
+
+     'B'
+          Register in the class 'ACCG_REGS' ('accg0' to 'accg7').
+
+     'C'
+          Register in the class 'CR_REGS' ('cc0' to 'cc7').
+
+     'G'
+          Floating point constant zero
+
+     'I'
+          6-bit signed integer constant
+
+     'J'
+          10-bit signed integer constant
+
+     'L'
+          16-bit signed integer constant
+
+     'M'
+          16-bit unsigned integer constant
+
+     'N'
+          12-bit signed integer constant that is negative--i.e. in the
+          range of -2048 to -1
+
+     'O'
+          Constant zero
+
+     'P'
+          12-bit signed integer constant that is greater than zero--i.e.
+          in the range of 1 to 2047.
+
+_Blackfin family--'config/bfin/constraints.md'_
+     'a'
+          P register
+
+     'd'
+          D register
+
+     'z'
+          A call clobbered P register.
+
+     'qN'
+          A single register.  If N is in the range 0 to 7, the
+          corresponding D register.  If it is 'A', then the register P0.
+
+     'D'
+          Even-numbered D register
+
+     'W'
+          Odd-numbered D register
+
+     'e'
+          Accumulator register.
+
+     'A'
+          Even-numbered accumulator register.
+
+     'B'
+          Odd-numbered accumulator register.
+
+     'b'
+          I register
+
+     'v'
+          B register
+
+     'f'
+          M register
+
+     'c'
+          Registers used for circular buffering, i.e.  I, B, or L
+          registers.
+
+     'C'
+          The CC register.
+
+     't'
+          LT0 or LT1.
+
+     'k'
+          LC0 or LC1.
+
+     'u'
+          LB0 or LB1.
+
+     'x'
+          Any D, P, B, M, I or L register.
+
+     'y'
+          Additional registers typically used only in prologues and
+          epilogues: RETS, RETN, RETI, RETX, RETE, ASTAT, SEQSTAT and
+          USP.
+
+     'w'
+          Any register except accumulators or CC.
+
+     'Ksh'
+          Signed 16 bit integer (in the range -32768 to 32767)
+
+     'Kuh'
+          Unsigned 16 bit integer (in the range 0 to 65535)
+
+     'Ks7'
+          Signed 7 bit integer (in the range -64 to 63)
+
+     'Ku7'
+          Unsigned 7 bit integer (in the range 0 to 127)
+
+     'Ku5'
+          Unsigned 5 bit integer (in the range 0 to 31)
+
+     'Ks4'
+          Signed 4 bit integer (in the range -8 to 7)
+
+     'Ks3'
+          Signed 3 bit integer (in the range -3 to 4)
+
+     'Ku3'
+          Unsigned 3 bit integer (in the range 0 to 7)
+
+     'PN'
+          Constant N, where N is a single-digit constant in the range 0
+          to 4.
+
+     'PA'
+          An integer equal to one of the MACFLAG_XXX constants that is
+          suitable for use with either accumulator.
+
+     'PB'
+          An integer equal to one of the MACFLAG_XXX constants that is
+          suitable for use only with accumulator A1.
+
+     'M1'
+          Constant 255.
+
+     'M2'
+          Constant 65535.
+
+     'J'
+          An integer constant with exactly a single bit set.
+
+     'L'
+          An integer constant with all bits set except exactly one.
+
+     'H'
+
+     'Q'
+          Any SYMBOL_REF.
+
+_M32C--'config/m32c/m32c.c'_
+     'Rsp'
+     'Rfb'
+     'Rsb'
+          '$sp', '$fb', '$sb'.
+
+     'Rcr'
+          Any control register, when they're 16 bits wide (nothing if
+          control registers are 24 bits wide)
+
+     'Rcl'
+          Any control register, when they're 24 bits wide.
+
+     'R0w'
+     'R1w'
+     'R2w'
+     'R3w'
+          $r0, $r1, $r2, $r3.
+
+     'R02'
+          $r0 or $r2, or $r2r0 for 32 bit values.
+
+     'R13'
+          $r1 or $r3, or $r3r1 for 32 bit values.
+
+     'Rdi'
+          A register that can hold a 64 bit value.
+
+     'Rhl'
+          $r0 or $r1 (registers with addressable high/low bytes)
+
+     'R23'
+          $r2 or $r3
+
+     'Raa'
+          Address registers
+
+     'Raw'
+          Address registers when they're 16 bits wide.
+
+     'Ral'
+          Address registers when they're 24 bits wide.
+
+     'Rqi'
+          Registers that can hold QI values.
+
+     'Rad'
+          Registers that can be used with displacements ($a0, $a1, $sb).
+
+     'Rsi'
+          Registers that can hold 32 bit values.
+
+     'Rhi'
+          Registers that can hold 16 bit values.
+
+     'Rhc'
+          Registers chat can hold 16 bit values, including all control
+          registers.
+
+     'Rra'
+          $r0 through R1, plus $a0 and $a1.
+
+     'Rfl'
+          The flags register.
+
+     'Rmm'
+          The memory-based pseudo-registers $mem0 through $mem15.
+
+     'Rpi'
+          Registers that can hold pointers (16 bit registers for r8c,
+          m16c; 24 bit registers for m32cm, m32c).
+
+     'Rpa'
+          Matches multiple registers in a PARALLEL to form a larger
+          register.  Used to match function return values.
+
+     'Is3'
+          -8 ... 7
+
+     'IS1'
+          -128 ... 127
+
+     'IS2'
+          -32768 ... 32767
+
+     'IU2'
+          0 ... 65535
+
+     'In4'
+          -8 ... -1 or 1 ... 8
+
+     'In5'
+          -16 ... -1 or 1 ... 16
+
+     'In6'
+          -32 ... -1 or 1 ... 32
+
+     'IM2'
+          -65536 ... -1
+
+     'Ilb'
+          An 8 bit value with exactly one bit set.
+
+     'Ilw'
+          A 16 bit value with exactly one bit set.
+
+     'Sd'
+          The common src/dest memory addressing modes.
+
+     'Sa'
+          Memory addressed using $a0 or $a1.
+
+     'Si'
+          Memory addressed with immediate addresses.
+
+     'Ss'
+          Memory addressed using the stack pointer ($sp).
+
+     'Sf'
+          Memory addressed using the frame base register ($fb).
+
+     'Ss'
+          Memory addressed using the small base register ($sb).
+
+     'S1'
+          $r1h
+
+_MeP--'config/mep/constraints.md'_
+
+     'a'
+          The $sp register.
+
+     'b'
+          The $tp register.
+
+     'c'
+          Any control register.
+
+     'd'
+          Either the $hi or the $lo register.
+
+     'em'
+          Coprocessor registers that can be directly loaded ($c0-$c15).
+
+     'ex'
+          Coprocessor registers that can be moved to each other.
+
+     'er'
+          Coprocessor registers that can be moved to core registers.
+
+     'h'
+          The $hi register.
+
+     'j'
+          The $rpc register.
+
+     'l'
+          The $lo register.
+
+     't'
+          Registers which can be used in $tp-relative addressing.
+
+     'v'
+          The $gp register.
+
+     'x'
+          The coprocessor registers.
+
+     'y'
+          The coprocessor control registers.
+
+     'z'
+          The $0 register.
+
+     'A'
+          User-defined register set A.
+
+     'B'
+          User-defined register set B.
+
+     'C'
+          User-defined register set C.
+
+     'D'
+          User-defined register set D.
+
+     'I'
+          Offsets for $gp-rel addressing.
+
+     'J'
+          Constants that can be used directly with boolean insns.
+
+     'K'
+          Constants that can be moved directly to registers.
+
+     'L'
+          Small constants that can be added to registers.
+
+     'M'
+          Long shift counts.
+
+     'N'
+          Small constants that can be compared to registers.
+
+     'O'
+          Constants that can be loaded into the top half of registers.
+
+     'S'
+          Signed 8-bit immediates.
+
+     'T'
+          Symbols encoded for $tp-rel or $gp-rel addressing.
+
+     'U'
+          Non-constant addresses for loading/saving coprocessor
+          registers.
+
+     'W'
+          The top half of a symbol's value.
+
+     'Y'
+          A register indirect address without offset.
+
+     'Z'
+          Symbolic references to the control bus.
+
+_MicroBlaze--'config/microblaze/constraints.md'_
+     'd'
+          A general register ('r0' to 'r31').
+
+     'z'
+          A status register ('rmsr', '$fcc1' to '$fcc7').
+
+_MIPS--'config/mips/constraints.md'_
+     'd'
+          An address register.  This is equivalent to 'r' unless
+          generating MIPS16 code.
+
+     'f'
+          A floating-point register (if available).
+
+     'h'
+          Formerly the 'hi' register.  This constraint is no longer
+          supported.
+
+     'l'
+          The 'lo' register.  Use this register to store values that are
+          no bigger than a word.
+
+     'x'
+          The concatenated 'hi' and 'lo' registers.  Use this register
+          to store doubleword values.
+
+     'c'
+          A register suitable for use in an indirect jump.  This will
+          always be '$25' for '-mabicalls'.
+
+     'v'
+          Register '$3'.  Do not use this constraint in new code; it is
+          retained only for compatibility with glibc.
+
+     'y'
+          Equivalent to 'r'; retained for backwards compatibility.
+
+     'z'
+          A floating-point condition code register.
+
+     'I'
+          A signed 16-bit constant (for arithmetic instructions).
+
+     'J'
+          Integer zero.
+
+     'K'
+          An unsigned 16-bit constant (for logic instructions).
+
+     'L'
+          A signed 32-bit constant in which the lower 16 bits are zero.
+          Such constants can be loaded using 'lui'.
+
+     'M'
+          A constant that cannot be loaded using 'lui', 'addiu' or
+          'ori'.
+
+     'N'
+          A constant in the range -65535 to -1 (inclusive).
+
+     'O'
+          A signed 15-bit constant.
+
+     'P'
+          A constant in the range 1 to 65535 (inclusive).
+
+     'G'
+          Floating-point zero.
+
+     'R'
+          An address that can be used in a non-macro load or store.
+
+     'ZC'
+          When compiling microMIPS code, this constraint matches a
+          memory operand whose address is formed from a base register
+          and a 12-bit offset.  These operands can be used for microMIPS
+          instructions such as 'll' and 'sc'.  When not compiling for
+          microMIPS code, 'ZC' is equivalent to 'R'.
+
+     'ZD'
+          When compiling microMIPS code, this constraint matches an
+          address operand that is formed from a base register and a
+          12-bit offset.  These operands can be used for microMIPS
+          instructions such as 'prefetch'.  When not compiling for
+          microMIPS code, 'ZD' is equivalent to 'p'.
+
+_Motorola 680x0--'config/m68k/constraints.md'_
+     'a'
+          Address register
+
+     'd'
+          Data register
+
+     'f'
+          68881 floating-point register, if available
+
+     'I'
+          Integer in the range 1 to 8
+
+     'J'
+          16-bit signed number
+
+     'K'
+          Signed number whose magnitude is greater than 0x80
+
+     'L'
+          Integer in the range -8 to -1
+
+     'M'
+          Signed number whose magnitude is greater than 0x100
+
+     'N'
+          Range 24 to 31, rotatert:SI 8 to 1 expressed as rotate
+
+     'O'
+          16 (for rotate using swap)
+
+     'P'
+          Range 8 to 15, rotatert:HI 8 to 1 expressed as rotate
+
+     'R'
+          Numbers that mov3q can handle
+
+     'G'
+          Floating point constant that is not a 68881 constant
+
+     'S'
+          Operands that satisfy 'm' when -mpcrel is in effect
+
+     'T'
+          Operands that satisfy 's' when -mpcrel is not in effect
+
+     'Q'
+          Address register indirect addressing mode
+
+     'U'
+          Register offset addressing
+
+     'W'
+          const_call_operand
+
+     'Cs'
+          symbol_ref or const
+
+     'Ci'
+          const_int
+
+     'C0'
+          const_int 0
+
+     'Cj'
+          Range of signed numbers that don't fit in 16 bits
+
+     'Cmvq'
+          Integers valid for mvq
+
+     'Capsw'
+          Integers valid for a moveq followed by a swap
+
+     'Cmvz'
+          Integers valid for mvz
+
+     'Cmvs'
+          Integers valid for mvs
+
+     'Ap'
+          push_operand
+
+     'Ac'
+          Non-register operands allowed in clr
+
+_Moxie--'config/moxie/constraints.md'_
+     'A'
+          An absolute address
+
+     'B'
+          An offset address
+
+     'W'
+          A register indirect memory operand
+
+     'I'
+          A constant in the range of 0 to 255.
+
+     'N'
+          A constant in the range of 0 to -255.
+
+_MSP430-'config/msp430/constraints.md'_
+
+     'R12'
+          Register R12.
+
+     'R13'
+          Register R13.
+
+     'K'
+          Integer constant 1.
+
+     'L'
+          Integer constant -1^20..1^19.
+
+     'M'
+          Integer constant 1-4.
+
+     'Ya'
+          Memory references which do not require an extended MOVX
+          instruction.
+
+     'Yl'
+          Memory reference, labels only.
+
+     'Ys'
+          Memory reference, stack only.
+
+_NDS32--'config/nds32/constraints.md'_
+     'w'
+          LOW register class $r0 to $r7 constraint for V3/V3M ISA.
+     'l'
+          LOW register class $r0 to $r7.
+     'd'
+          MIDDLE register class $r0 to $r11, $r16 to $r19.
+     'h'
+          HIGH register class $r12 to $r14, $r20 to $r31.
+     't'
+          Temporary assist register $ta (i.e. $r15).
+     'k'
+          Stack register $sp.
+     'Iu03'
+          Unsigned immediate 3-bit value.
+     'In03'
+          Negative immediate 3-bit value in the range of -7-0.
+     'Iu04'
+          Unsigned immediate 4-bit value.
+     'Is05'
+          Signed immediate 5-bit value.
+     'Iu05'
+          Unsigned immediate 5-bit value.
+     'In05'
+          Negative immediate 5-bit value in the range of -31-0.
+     'Ip05'
+          Unsigned immediate 5-bit value for movpi45 instruction with
+          range 16-47.
+     'Iu06'
+          Unsigned immediate 6-bit value constraint for addri36.sp
+          instruction.
+     'Iu08'
+          Unsigned immediate 8-bit value.
+     'Iu09'
+          Unsigned immediate 9-bit value.
+     'Is10'
+          Signed immediate 10-bit value.
+     'Is11'
+          Signed immediate 11-bit value.
+     'Is15'
+          Signed immediate 15-bit value.
+     'Iu15'
+          Unsigned immediate 15-bit value.
+     'Ic15'
+          A constant which is not in the range of imm15u but ok for bclr
+          instruction.
+     'Ie15'
+          A constant which is not in the range of imm15u but ok for bset
+          instruction.
+     'It15'
+          A constant which is not in the range of imm15u but ok for btgl
+          instruction.
+     'Ii15'
+          A constant whose compliment value is in the range of imm15u
+          and ok for bitci instruction.
+     'Is16'
+          Signed immediate 16-bit value.
+     'Is17'
+          Signed immediate 17-bit value.
+     'Is19'
+          Signed immediate 19-bit value.
+     'Is20'
+          Signed immediate 20-bit value.
+     'Ihig'
+          The immediate value that can be simply set high 20-bit.
+     'Izeb'
+          The immediate value 0xff.
+     'Izeh'
+          The immediate value 0xffff.
+     'Ixls'
+          The immediate value 0x01.
+     'Ix11'
+          The immediate value 0x7ff.
+     'Ibms'
+          The immediate value with power of 2.
+     'Ifex'
+          The immediate value with power of 2 minus 1.
+     'U33'
+          Memory constraint for 333 format.
+     'U45'
+          Memory constraint for 45 format.
+     'U37'
+          Memory constraint for 37 format.
+
+_Nios II family--'config/nios2/constraints.md'_
+
+     'I'
+          Integer that is valid as an immediate operand in an
+          instruction taking a signed 16-bit number.  Range -32768 to
+          32767.
+
+     'J'
+          Integer that is valid as an immediate operand in an
+          instruction taking an unsigned 16-bit number.  Range 0 to
+          65535.
+
+     'K'
+          Integer that is valid as an immediate operand in an
+          instruction taking only the upper 16-bits of a 32-bit number.
+          Range 32-bit numbers with the lower 16-bits being 0.
+
+     'L'
+          Integer that is valid as an immediate operand for a shift
+          instruction.  Range 0 to 31.
+
+     'M'
+          Integer that is valid as an immediate operand for only the
+          value 0.  Can be used in conjunction with the format modifier
+          'z' to use 'r0' instead of '0' in the assembly output.
+
+     'N'
+          Integer that is valid as an immediate operand for a custom
+          instruction opcode.  Range 0 to 255.
+
+     'S'
+          Matches immediates which are addresses in the small data
+          section and therefore can be added to 'gp' as a 16-bit
+          immediate to re-create their 32-bit value.
+
+     'T'
+          A 'const' wrapped 'UNSPEC' expression, representing a
+          supported PIC or TLS relocation.
+
+_PDP-11--'config/pdp11/constraints.md'_
+     'a'
+          Floating point registers AC0 through AC3.  These can be loaded
+          from/to memory with a single instruction.
+
+     'd'
+          Odd numbered general registers (R1, R3, R5).  These are used
+          for 16-bit multiply operations.
+
+     'f'
+          Any of the floating point registers (AC0 through AC5).
+
+     'G'
+          Floating point constant 0.
+
+     'I'
+          An integer constant that fits in 16 bits.
+
+     'J'
+          An integer constant whose low order 16 bits are zero.
+
+     'K'
+          An integer constant that does not meet the constraints for
+          codes 'I' or 'J'.
+
+     'L'
+          The integer constant 1.
+
+     'M'
+          The integer constant -1.
+
+     'N'
+          The integer constant 0.
+
+     'O'
+          Integer constants -4 through -1 and 1 through 4; shifts by
+          these amounts are handled as multiple single-bit shifts rather
+          than a single variable-length shift.
+
+     'Q'
+          A memory reference which requires an additional word (address
+          or offset) after the opcode.
+
+     'R'
+          A memory reference that is encoded within the opcode.
+
+_RL78--'config/rl78/constraints.md'_
+
+     'Int3'
+          An integer constant in the range 1 ... 7.
+     'Int8'
+          An integer constant in the range 0 ... 255.
+     'J'
+          An integer constant in the range -255 ... 0
+     'K'
+          The integer constant 1.
+     'L'
+          The integer constant -1.
+     'M'
+          The integer constant 0.
+     'N'
+          The integer constant 2.
+     'O'
+          The integer constant -2.
+     'P'
+          An integer constant in the range 1 ... 15.
+     'Qbi'
+          The built-in compare types-eq, ne, gtu, ltu, geu, and leu.
+     'Qsc'
+          The synthetic compare types-gt, lt, ge, and le.
+     'Wab'
+          A memory reference with an absolute address.
+     'Wbc'
+          A memory reference using 'BC' as a base register, with an
+          optional offset.
+     'Wca'
+          A memory reference using 'AX', 'BC', 'DE', or 'HL' for the
+          address, for calls.
+     'Wcv'
+          A memory reference using any 16-bit register pair for the
+          address, for calls.
+     'Wd2'
+          A memory reference using 'DE' as a base register, with an
+          optional offset.
+     'Wde'
+          A memory reference using 'DE' as a base register, without any
+          offset.
+     'Wfr'
+          Any memory reference to an address in the far address space.
+     'Wh1'
+          A memory reference using 'HL' as a base register, with an
+          optional one-byte offset.
+     'Whb'
+          A memory reference using 'HL' as a base register, with 'B' or
+          'C' as the index register.
+     'Whl'
+          A memory reference using 'HL' as a base register, without any
+          offset.
+     'Ws1'
+          A memory reference using 'SP' as a base register, with an
+          optional one-byte offset.
+     'Y'
+          Any memory reference to an address in the near address space.
+     'A'
+          The 'AX' register.
+     'B'
+          The 'BC' register.
+     'D'
+          The 'DE' register.
+     'R'
+          'A' through 'L' registers.
+     'S'
+          The 'SP' register.
+     'T'
+          The 'HL' register.
+     'Z08W'
+          The 16-bit 'R8' register.
+     'Z10W'
+          The 16-bit 'R10' register.
+     'Zint'
+          The registers reserved for interrupts ('R24' to 'R31').
+     'a'
+          The 'A' register.
+     'b'
+          The 'B' register.
+     'c'
+          The 'C' register.
+     'd'
+          The 'D' register.
+     'e'
+          The 'E' register.
+     'h'
+          The 'H' register.
+     'l'
+          The 'L' register.
+     'v'
+          The virtual registers.
+     'w'
+          The 'PSW' register.
+     'x'
+          The 'X' register.
+
+_RX--'config/rx/constraints.md'_
+     'Q'
+          An address which does not involve register indirect addressing
+          or pre/post increment/decrement addressing.
+
+     'Symbol'
+          A symbol reference.
+
+     'Int08'
+          A constant in the range -256 to 255, inclusive.
+
+     'Sint08'
+          A constant in the range -128 to 127, inclusive.
+
+     'Sint16'
+          A constant in the range -32768 to 32767, inclusive.
+
+     'Sint24'
+          A constant in the range -8388608 to 8388607, inclusive.
+
+     'Uint04'
+          A constant in the range 0 to 15, inclusive.
+
+_SPARC--'config/sparc/sparc.h'_
+     'f'
+          Floating-point register on the SPARC-V8 architecture and lower
+          floating-point register on the SPARC-V9 architecture.
+
+     'e'
+          Floating-point register.  It is equivalent to 'f' on the
+          SPARC-V8 architecture and contains both lower and upper
+          floating-point registers on the SPARC-V9 architecture.
+
+     'c'
+          Floating-point condition code register.
+
+     'd'
+          Lower floating-point register.  It is only valid on the
+          SPARC-V9 architecture when the Visual Instruction Set is
+          available.
+
+     'b'
+          Floating-point register.  It is only valid on the SPARC-V9
+          architecture when the Visual Instruction Set is available.
+
+     'h'
+          64-bit global or out register for the SPARC-V8+ architecture.
+
+     'C'
+          The constant all-ones, for floating-point.
+
+     'A'
+          Signed 5-bit constant
+
+     'D'
+          A vector constant
+
+     'I'
+          Signed 13-bit constant
+
+     'J'
+          Zero
+
+     'K'
+          32-bit constant with the low 12 bits clear (a constant that
+          can be loaded with the 'sethi' instruction)
+
+     'L'
+          A constant in the range supported by 'movcc' instructions
+          (11-bit signed immediate)
+
+     'M'
+          A constant in the range supported by 'movrcc' instructions
+          (10-bit signed immediate)
+
+     'N'
+          Same as 'K', except that it verifies that bits that are not in
+          the lower 32-bit range are all zero.  Must be used instead of
+          'K' for modes wider than 'SImode'
+
+     'O'
+          The constant 4096
+
+     'G'
+          Floating-point zero
+
+     'H'
+          Signed 13-bit constant, sign-extended to 32 or 64 bits
+
+     'P'
+          The constant -1
+
+     'Q'
+          Floating-point constant whose integral representation can be
+          moved into an integer register using a single sethi
+          instruction
+
+     'R'
+          Floating-point constant whose integral representation can be
+          moved into an integer register using a single mov instruction
+
+     'S'
+          Floating-point constant whose integral representation can be
+          moved into an integer register using a high/lo_sum instruction
+          sequence
+
+     'T'
+          Memory address aligned to an 8-byte boundary
+
+     'U'
+          Even register
+
+     'W'
+          Memory address for 'e' constraint registers
+
+     'w'
+          Memory address with only a base register
+
+     'Y'
+          Vector zero
+
+_SPU--'config/spu/spu.h'_
+     'a'
+          An immediate which can be loaded with the il/ila/ilh/ilhu
+          instructions.  const_int is treated as a 64 bit value.
+
+     'c'
+          An immediate for and/xor/or instructions.  const_int is
+          treated as a 64 bit value.
+
+     'd'
+          An immediate for the 'iohl' instruction.  const_int is treated
+          as a 64 bit value.
+
+     'f'
+          An immediate which can be loaded with 'fsmbi'.
+
+     'A'
+          An immediate which can be loaded with the il/ila/ilh/ilhu
+          instructions.  const_int is treated as a 32 bit value.
+
+     'B'
+          An immediate for most arithmetic instructions.  const_int is
+          treated as a 32 bit value.
+
+     'C'
+          An immediate for and/xor/or instructions.  const_int is
+          treated as a 32 bit value.
+
+     'D'
+          An immediate for the 'iohl' instruction.  const_int is treated
+          as a 32 bit value.
+
+     'I'
+          A constant in the range [-64, 63] for shift/rotate
+          instructions.
+
+     'J'
+          An unsigned 7-bit constant for conversion/nop/channel
+          instructions.
+
+     'K'
+          A signed 10-bit constant for most arithmetic instructions.
+
+     'M'
+          A signed 16 bit immediate for 'stop'.
+
+     'N'
+          An unsigned 16-bit constant for 'iohl' and 'fsmbi'.
+
+     'O'
+          An unsigned 7-bit constant whose 3 least significant bits are
+          0.
+
+     'P'
+          An unsigned 3-bit constant for 16-byte rotates and shifts
+
+     'R'
+          Call operand, reg, for indirect calls
+
+     'S'
+          Call operand, symbol, for relative calls.
+
+     'T'
+          Call operand, const_int, for absolute calls.
+
+     'U'
+          An immediate which can be loaded with the il/ila/ilh/ilhu
+          instructions.  const_int is sign extended to 128 bit.
+
+     'W'
+          An immediate for shift and rotate instructions.  const_int is
+          treated as a 32 bit value.
+
+     'Y'
+          An immediate for and/xor/or instructions.  const_int is sign
+          extended as a 128 bit.
+
+     'Z'
+          An immediate for the 'iohl' instruction.  const_int is sign
+          extended to 128 bit.
+
+_S/390 and zSeries--'config/s390/s390.h'_
+     'a'
+          Address register (general purpose register except r0)
+
+     'c'
+          Condition code register
+
+     'd'
+          Data register (arbitrary general purpose register)
+
+     'f'
+          Floating-point register
+
+     'I'
+          Unsigned 8-bit constant (0-255)
+
+     'J'
+          Unsigned 12-bit constant (0-4095)
+
+     'K'
+          Signed 16-bit constant (-32768-32767)
+
+     'L'
+          Value appropriate as displacement.
+          '(0..4095)'
+               for short displacement
+          '(-524288..524287)'
+               for long displacement
+
+     'M'
+          Constant integer with a value of 0x7fffffff.
+
+     'N'
+          Multiple letter constraint followed by 4 parameter letters.
+          '0..9:'
+               number of the part counting from most to least
+               significant
+          'H,Q:'
+               mode of the part
+          'D,S,H:'
+               mode of the containing operand
+          '0,F:'
+               value of the other parts (F--all bits set)
+          The constraint matches if the specified part of a constant has
+          a value different from its other parts.
+
+     'Q'
+          Memory reference without index register and with short
+          displacement.
+
+     'R'
+          Memory reference with index register and short displacement.
+
+     'S'
+          Memory reference without index register but with long
+          displacement.
+
+     'T'
+          Memory reference with index register and long displacement.
+
+     'U'
+          Pointer with short displacement.
+
+     'W'
+          Pointer with long displacement.
+
+     'Y'
+          Shift count operand.
+
+_Score family--'config/score/score.h'_
+     'd'
+          Registers from r0 to r32.
+
+     'e'
+          Registers from r0 to r16.
+
+     't'
+          r8--r11 or r22--r27 registers.
+
+     'h'
+          hi register.
+
+     'l'
+          lo register.
+
+     'x'
+          hi + lo register.
+
+     'q'
+          cnt register.
+
+     'y'
+          lcb register.
+
+     'z'
+          scb register.
+
+     'a'
+          cnt + lcb + scb register.
+
+     'c'
+          cr0--cr15 register.
+
+     'b'
+          cp1 registers.
+
+     'f'
+          cp2 registers.
+
+     'i'
+          cp3 registers.
+
+     'j'
+          cp1 + cp2 + cp3 registers.
+
+     'I'
+          High 16-bit constant (32-bit constant with 16 LSBs zero).
+
+     'J'
+          Unsigned 5 bit integer (in the range 0 to 31).
+
+     'K'
+          Unsigned 16 bit integer (in the range 0 to 65535).
+
+     'L'
+          Signed 16 bit integer (in the range -32768 to 32767).
+
+     'M'
+          Unsigned 14 bit integer (in the range 0 to 16383).
+
+     'N'
+          Signed 14 bit integer (in the range -8192 to 8191).
+
+     'Z'
+          Any SYMBOL_REF.
+
+_Xstormy16--'config/stormy16/stormy16.h'_
+     'a'
+          Register r0.
+
+     'b'
+          Register r1.
+
+     'c'
+          Register r2.
+
+     'd'
+          Register r8.
+
+     'e'
+          Registers r0 through r7.
+
+     't'
+          Registers r0 and r1.
+
+     'y'
+          The carry register.
+
+     'z'
+          Registers r8 and r9.
+
+     'I'
+          A constant between 0 and 3 inclusive.
+
+     'J'
+          A constant that has exactly one bit set.
+
+     'K'
+          A constant that has exactly one bit clear.
+
+     'L'
+          A constant between 0 and 255 inclusive.
+
+     'M'
+          A constant between -255 and 0 inclusive.
+
+     'N'
+          A constant between -3 and 0 inclusive.
+
+     'O'
+          A constant between 1 and 4 inclusive.
+
+     'P'
+          A constant between -4 and -1 inclusive.
+
+     'Q'
+          A memory reference that is a stack push.
+
+     'R'
+          A memory reference that is a stack pop.
+
+     'S'
+          A memory reference that refers to a constant address of known
+          value.
+
+     'T'
+          The register indicated by Rx (not implemented yet).
+
+     'U'
+          A constant that is not between 2 and 15 inclusive.
+
+     'Z'
+          The constant 0.
+
+_TI C6X family--'config/c6x/constraints.md'_
+     'a'
+          Register file A (A0-A31).
+
+     'b'
+          Register file B (B0-B31).
+
+     'A'
+          Predicate registers in register file A (A0-A2 on C64X and
+          higher, A1 and A2 otherwise).
+
+     'B'
+          Predicate registers in register file B (B0-B2).
+
+     'C'
+          A call-used register in register file B (B0-B9, B16-B31).
+
+     'Da'
+          Register file A, excluding predicate registers (A3-A31, plus
+          A0 if not C64X or higher).
+
+     'Db'
+          Register file B, excluding predicate registers (B3-B31).
+
+     'Iu4'
+          Integer constant in the range 0 ... 15.
+
+     'Iu5'
+          Integer constant in the range 0 ... 31.
+
+     'In5'
+          Integer constant in the range -31 ... 0.
+
+     'Is5'
+          Integer constant in the range -16 ... 15.
+
+     'I5x'
+          Integer constant that can be the operand of an ADDA or a SUBA
+          insn.
+
+     'IuB'
+          Integer constant in the range 0 ... 65535.
+
+     'IsB'
+          Integer constant in the range -32768 ... 32767.
+
+     'IsC'
+          Integer constant in the range -2^{20} ... 2^{20} - 1.
+
+     'Jc'
+          Integer constant that is a valid mask for the clr instruction.
+
+     'Js'
+          Integer constant that is a valid mask for the set instruction.
+
+     'Q'
+          Memory location with A base register.
+
+     'R'
+          Memory location with B base register.
+
+     'S0'
+          On C64x+ targets, a GP-relative small data reference.
+
+     'S1'
+          Any kind of 'SYMBOL_REF', for use in a call address.
+
+     'Si'
+          Any kind of immediate operand, unless it matches the S0
+          constraint.
+
+     'T'
+          Memory location with B base register, but not using a long
+          offset.
+
+     'W'
+          A memory operand with an address that can't be used in an
+          unaligned access.
+
+     'Z'
+          Register B14 (aka DP).
+
+_TILE-Gx--'config/tilegx/constraints.md'_
+     'R00'
+     'R01'
+     'R02'
+     'R03'
+     'R04'
+     'R05'
+     'R06'
+     'R07'
+     'R08'
+     'R09'
+     'R10'
+          Each of these represents a register constraint for an
+          individual register, from r0 to r10.
+
+     'I'
+          Signed 8-bit integer constant.
+
+     'J'
+          Signed 16-bit integer constant.
+
+     'K'
+          Unsigned 16-bit integer constant.
+
+     'L'
+          Integer constant that fits in one signed byte when incremented
+          by one (-129 ... 126).
+
+     'm'
+          Memory operand.  If used together with '<' or '>', the operand
+          can have postincrement which requires printing with '%In' and
+          '%in' on TILE-Gx.  For example:
+
+               asm ("st_add %I0,%1,%i0" : "=m<>" (*mem) : "r" (val));
+
+     'M'
+          A bit mask suitable for the BFINS instruction.
+
+     'N'
+          Integer constant that is a byte tiled out eight times.
+
+     'O'
+          The integer zero constant.
+
+     'P'
+          Integer constant that is a sign-extended byte tiled out as
+          four shorts.
+
+     'Q'
+          Integer constant that fits in one signed byte when incremented
+          (-129 ... 126), but excluding -1.
+
+     'S'
+          Integer constant that has all 1 bits consecutive and starting
+          at bit 0.
+
+     'T'
+          A 16-bit fragment of a got, tls, or pc-relative reference.
+
+     'U'
+          Memory operand except postincrement.  This is roughly the same
+          as 'm' when not used together with '<' or '>'.
+
+     'W'
+          An 8-element vector constant with identical elements.
+
+     'Y'
+          A 4-element vector constant with identical elements.
+
+     'Z0'
+          The integer constant 0xffffffff.
+
+     'Z1'
+          The integer constant 0xffffffff00000000.
+
+_TILEPro--'config/tilepro/constraints.md'_
+     'R00'
+     'R01'
+     'R02'
+     'R03'
+     'R04'
+     'R05'
+     'R06'
+     'R07'
+     'R08'
+     'R09'
+     'R10'
+          Each of these represents a register constraint for an
+          individual register, from r0 to r10.
+
+     'I'
+          Signed 8-bit integer constant.
+
+     'J'
+          Signed 16-bit integer constant.
+
+     'K'
+          Nonzero integer constant with low 16 bits zero.
+
+     'L'
+          Integer constant that fits in one signed byte when incremented
+          by one (-129 ... 126).
+
+     'm'
+          Memory operand.  If used together with '<' or '>', the operand
+          can have postincrement which requires printing with '%In' and
+          '%in' on TILEPro.  For example:
+
+               asm ("swadd %I0,%1,%i0" : "=m<>" (mem) : "r" (val));
+
+     'M'
+          A bit mask suitable for the MM instruction.
+
+     'N'
+          Integer constant that is a byte tiled out four times.
+
+     'O'
+          The integer zero constant.
+
+     'P'
+          Integer constant that is a sign-extended byte tiled out as two
+          shorts.
+
+     'Q'
+          Integer constant that fits in one signed byte when incremented
+          (-129 ... 126), but excluding -1.
+
+     'T'
+          A symbolic operand, or a 16-bit fragment of a got, tls, or
+          pc-relative reference.
+
+     'U'
+          Memory operand except postincrement.  This is roughly the same
+          as 'm' when not used together with '<' or '>'.
+
+     'W'
+          A 4-element vector constant with identical elements.
+
+     'Y'
+          A 2-element vector constant with identical elements.
+
+_Xtensa--'config/xtensa/constraints.md'_
+     'a'
+          General-purpose 32-bit register
+
+     'b'
+          One-bit boolean register
+
+     'A'
+          MAC16 40-bit accumulator register
+
+     'I'
+          Signed 12-bit integer constant, for use in MOVI instructions
+
+     'J'
+          Signed 8-bit integer constant, for use in ADDI instructions
+
+     'K'
+          Integer constant valid for BccI instructions
+
+     'L'
+          Unsigned constant valid for BccUI instructions
+
+
+File: gccint.info,  Node: Disable Insn Alternatives,  Next: Define Constraints,  Prev: Machine Constraints,  Up: Constraints
+
+16.8.6 Disable insn alternatives using the 'enabled' attribute
+--------------------------------------------------------------
+
+The 'enabled' insn attribute may be used to disable certain insn
+alternatives for machine-specific reasons.  This is useful when adding
+new instructions to an existing pattern which are only available for
+certain cpu architecture levels as specified with the '-march=' option.
+
+ If an insn alternative is disabled, then it will never be used.  The
+compiler treats the constraints for the disabled alternative as
+unsatisfiable.
+
+ In order to make use of the 'enabled' attribute a back end has to add
+in the machine description files:
+
+  1. A definition of the 'enabled' insn attribute.  The attribute is
+     defined as usual using the 'define_attr' command.  This definition
+     should be based on other insn attributes and/or target flags.  The
+     'enabled' attribute is a numeric attribute and should evaluate to
+     '(const_int 1)' for an enabled alternative and to '(const_int 0)'
+     otherwise.
+  2. A definition of another insn attribute used to describe for what
+     reason an insn alternative might be available or not.  E.g.
+     'cpu_facility' as in the example below.
+  3. An assignment for the second attribute to each insn definition
+     combining instructions which are not all available under the same
+     circumstances.  (Note: It obviously only makes sense for
+     definitions with more than one alternative.  Otherwise the insn
+     pattern should be disabled or enabled using the insn condition.)
+
+ E.g.  the following two patterns could easily be merged using the
+'enabled' attribute:
+
+
+     (define_insn "*movdi_old"
+       [(set (match_operand:DI 0 "register_operand" "=d")
+             (match_operand:DI 1 "register_operand" " d"))]
+       "!TARGET_NEW"
+       "lgr %0,%1")
+
+     (define_insn "*movdi_new"
+       [(set (match_operand:DI 0 "register_operand" "=d,f,d")
+             (match_operand:DI 1 "register_operand" " d,d,f"))]
+       "TARGET_NEW"
+       "@
+        lgr  %0,%1
+        ldgr %0,%1
+        lgdr %0,%1")
+
+ to:
+
+
+     (define_insn "*movdi_combined"
+       [(set (match_operand:DI 0 "register_operand" "=d,f,d")
+             (match_operand:DI 1 "register_operand" " d,d,f"))]
+       ""
+       "@
+        lgr  %0,%1
+        ldgr %0,%1
+        lgdr %0,%1"
+       [(set_attr "cpu_facility" "*,new,new")])
+
+ with the 'enabled' attribute defined like this:
+
+
+     (define_attr "cpu_facility" "standard,new" (const_string "standard"))
+
+     (define_attr "enabled" ""
+       (cond [(eq_attr "cpu_facility" "standard") (const_int 1)
+              (and (eq_attr "cpu_facility" "new")
+                   (ne (symbol_ref "TARGET_NEW") (const_int 0)))
+              (const_int 1)]
+             (const_int 0)))
+
+
+File: gccint.info,  Node: Define Constraints,  Next: C Constraint Interface,  Prev: Disable Insn Alternatives,  Up: Constraints
+
+16.8.7 Defining Machine-Specific Constraints
+--------------------------------------------
+
+Machine-specific constraints fall into two categories: register and
+non-register constraints.  Within the latter category, constraints which
+allow subsets of all possible memory or address operands should be
+specially marked, to give 'reload' more information.
+
+ Machine-specific constraints can be given names of arbitrary length,
+but they must be entirely composed of letters, digits, underscores
+('_'), and angle brackets ('< >').  Like C identifiers, they must begin
+with a letter or underscore.
+
+ In order to avoid ambiguity in operand constraint strings, no
+constraint can have a name that begins with any other constraint's name.
+For example, if 'x' is defined as a constraint name, 'xy' may not be,
+and vice versa.  As a consequence of this rule, no constraint may begin
+with one of the generic constraint letters: 'E F V X g i m n o p r s'.
+
+ Register constraints correspond directly to register classes.  *Note
+Register Classes::.  There is thus not much flexibility in their
+definitions.
+
+ -- MD Expression: define_register_constraint name regclass docstring
+     All three arguments are string constants.  NAME is the name of the
+     constraint, as it will appear in 'match_operand' expressions.  If
+     NAME is a multi-letter constraint its length shall be the same for
+     all constraints starting with the same letter.  REGCLASS can be
+     either the name of the corresponding register class (*note Register
+     Classes::), or a C expression which evaluates to the appropriate
+     register class.  If it is an expression, it must have no side
+     effects, and it cannot look at the operand.  The usual use of
+     expressions is to map some register constraints to 'NO_REGS' when
+     the register class is not available on a given subarchitecture.
+
+     DOCSTRING is a sentence documenting the meaning of the constraint.
+     Docstrings are explained further below.
+
+ Non-register constraints are more like predicates: the constraint
+definition gives a Boolean expression which indicates whether the
+constraint matches.
+
+ -- MD Expression: define_constraint name docstring exp
+     The NAME and DOCSTRING arguments are the same as for
+     'define_register_constraint', but note that the docstring comes
+     immediately after the name for these expressions.  EXP is an RTL
+     expression, obeying the same rules as the RTL expressions in
+     predicate definitions.  *Note Defining Predicates::, for details.
+     If it evaluates true, the constraint matches; if it evaluates
+     false, it doesn't.  Constraint expressions should indicate which
+     RTL codes they might match, just like predicate expressions.
+
+     'match_test' C expressions have access to the following variables:
+
+     OP
+          The RTL object defining the operand.
+     MODE
+          The machine mode of OP.
+     IVAL
+          'INTVAL (OP)', if OP is a 'const_int'.
+     HVAL
+          'CONST_DOUBLE_HIGH (OP)', if OP is an integer 'const_double'.
+     LVAL
+          'CONST_DOUBLE_LOW (OP)', if OP is an integer 'const_double'.
+     RVAL
+          'CONST_DOUBLE_REAL_VALUE (OP)', if OP is a floating-point
+          'const_double'.
+
+     The *VAL variables should only be used once another piece of the
+     expression has verified that OP is the appropriate kind of RTL
+     object.
+
+ Most non-register constraints should be defined with
+'define_constraint'.  The remaining two definition expressions are only
+appropriate for constraints that should be handled specially by 'reload'
+if they fail to match.
+
+ -- MD Expression: define_memory_constraint name docstring exp
+     Use this expression for constraints that match a subset of all
+     memory operands: that is, 'reload' can make them match by
+     converting the operand to the form '(mem (reg X))', where X is a
+     base register (from the register class specified by
+     'BASE_REG_CLASS', *note Register Classes::).
+
+     For example, on the S/390, some instructions do not accept
+     arbitrary memory references, but only those that do not make use of
+     an index register.  The constraint letter 'Q' is defined to
+     represent a memory address of this type.  If 'Q' is defined with
+     'define_memory_constraint', a 'Q' constraint can handle any memory
+     operand, because 'reload' knows it can simply copy the memory
+     address into a base register if required.  This is analogous to the
+     way an 'o' constraint can handle any memory operand.
+
+     The syntax and semantics are otherwise identical to
+     'define_constraint'.
+
+ -- MD Expression: define_address_constraint name docstring exp
+     Use this expression for constraints that match a subset of all
+     address operands: that is, 'reload' can make the constraint match
+     by converting the operand to the form '(reg X)', again with X a
+     base register.
+
+     Constraints defined with 'define_address_constraint' can only be
+     used with the 'address_operand' predicate, or machine-specific
+     predicates that work the same way.  They are treated analogously to
+     the generic 'p' constraint.
+
+     The syntax and semantics are otherwise identical to
+     'define_constraint'.
+
+ For historical reasons, names beginning with the letters 'G H' are
+reserved for constraints that match only 'const_double's, and names
+beginning with the letters 'I J K L M N O P' are reserved for
+constraints that match only 'const_int's.  This may change in the
+future.  For the time being, constraints with these names must be
+written in a stylized form, so that 'genpreds' can tell you did it
+correctly:
+
+     (define_constraint "[GHIJKLMNOP]..."
+       "DOC..."
+       (and (match_code "const_int")  ; 'const_double' for G/H
+            CONDITION...))            ; usually a 'match_test'
+
+ It is fine to use names beginning with other letters for constraints
+that match 'const_double's or 'const_int's.
+
+ Each docstring in a constraint definition should be one or more
+complete sentences, marked up in Texinfo format.  _They are currently
+unused._  In the future they will be copied into the GCC manual, in
+*note Machine Constraints::, replacing the hand-maintained tables
+currently found in that section.  Also, in the future the compiler may
+use this to give more helpful diagnostics when poor choice of 'asm'
+constraints causes a reload failure.
+
+ If you put the pseudo-Texinfo directive '@internal' at the beginning of
+a docstring, then (in the future) it will appear only in the internals
+manual's version of the machine-specific constraint tables.  Use this
+for constraints that should not appear in 'asm' statements.
+
+
+File: gccint.info,  Node: C Constraint Interface,  Prev: Define Constraints,  Up: Constraints
+
+16.8.8 Testing constraints from C
+---------------------------------
+
+It is occasionally useful to test a constraint from C code rather than
+implicitly via the constraint string in a 'match_operand'.  The
+generated file 'tm_p.h' declares a few interfaces for working with
+machine-specific constraints.  None of these interfaces work with the
+generic constraints described in *note Simple Constraints::.  This may
+change in the future.
+
+ *Warning:* 'tm_p.h' may declare other functions that operate on
+constraints, besides the ones documented here.  Do not use those
+functions from machine-dependent code.  They exist to implement the old
+constraint interface that machine-independent components of the compiler
+still expect.  They will change or disappear in the future.
+
+ Some valid constraint names are not valid C identifiers, so there is a
+mangling scheme for referring to them from C.  Constraint names that do
+not contain angle brackets or underscores are left unchanged.
+Underscores are doubled, each '<' is replaced with '_l', and each '>'
+with '_g'.  Here are some examples:
+
+     *Original* *Mangled*  
+     x          x       
+     P42x       P42x    
+     P4_x       P4__x   
+     P4>x       P4_gx   
+     P4>>       P4_g_g  
+     P4_g>      P4__g_g 
+
+ Throughout this section, the variable C is either a constraint in the
+abstract sense, or a constant from 'enum constraint_num'; the variable M
+is a mangled constraint name (usually as part of a larger identifier).
+
+ -- Enum: constraint_num
+     For each machine-specific constraint, there is a corresponding
+     enumeration constant: 'CONSTRAINT_' plus the mangled name of the
+     constraint.  Functions that take an 'enum constraint_num' as an
+     argument expect one of these constants.
+
+     Machine-independent constraints do not have associated constants.
+     This may change in the future.
+
+ -- Function: inline bool satisfies_constraint_ M (rtx EXP)
+     For each machine-specific, non-register constraint M, there is one
+     of these functions; it returns 'true' if EXP satisfies the
+     constraint.  These functions are only visible if 'rtl.h' was
+     included before 'tm_p.h'.
+
+ -- Function: bool constraint_satisfied_p (rtx EXP, enum constraint_num
+          C)
+     Like the 'satisfies_constraint_M' functions, but the constraint to
+     test is given as an argument, C.  If C specifies a register
+     constraint, this function will always return 'false'.
+
+ -- Function: enum reg_class regclass_for_constraint (enum
+          constraint_num C)
+     Returns the register class associated with C.  If C is not a
+     register constraint, or those registers are not available for the
+     currently selected subtarget, returns 'NO_REGS'.
+
+ Here is an example use of 'satisfies_constraint_M'.  In peephole
+optimizations (*note Peephole Definitions::), operand constraint strings
+are ignored, so if there are relevant constraints, they must be tested
+in the C condition.  In the example, the optimization is applied if
+operand 2 does _not_ satisfy the 'K' constraint.  (This is a simplified
+version of a peephole definition from the i386 machine description.)
+
+     (define_peephole2
+       [(match_scratch:SI 3 "r")
+        (set (match_operand:SI 0 "register_operand" "")
+             (mult:SI (match_operand:SI 1 "memory_operand" "")
+                      (match_operand:SI 2 "immediate_operand" "")))]
+
+       "!satisfies_constraint_K (operands[2])"
+
+       [(set (match_dup 3) (match_dup 1))
+        (set (match_dup 0) (mult:SI (match_dup 3) (match_dup 2)))]
+
+       "")
+
+
+File: gccint.info,  Node: Standard Names,  Next: Pattern Ordering,  Prev: Constraints,  Up: Machine Desc
+
+16.9 Standard Pattern Names For Generation
+==========================================
+
+Here is a table of the instruction names that are meaningful in the RTL
+generation pass of the compiler.  Giving one of these names to an
+instruction pattern tells the RTL generation pass that it can use the
+pattern to accomplish a certain task.
+
+'movM'
+     Here M stands for a two-letter machine mode name, in lowercase.
+     This instruction pattern moves data with that machine mode from
+     operand 1 to operand 0.  For example, 'movsi' moves full-word data.
+
+     If operand 0 is a 'subreg' with mode M of a register whose own mode
+     is wider than M, the effect of this instruction is to store the
+     specified value in the part of the register that corresponds to
+     mode M.  Bits outside of M, but which are within the same target
+     word as the 'subreg' are undefined.  Bits which are outside the
+     target word are left unchanged.
+
+     This class of patterns is special in several ways.  First of all,
+     each of these names up to and including full word size _must_ be
+     defined, because there is no other way to copy a datum from one
+     place to another.  If there are patterns accepting operands in
+     larger modes, 'movM' must be defined for integer modes of those
+     sizes.
+
+     Second, these patterns are not used solely in the RTL generation
+     pass.  Even the reload pass can generate move insns to copy values
+     from stack slots into temporary registers.  When it does so, one of
+     the operands is a hard register and the other is an operand that
+     can need to be reloaded into a register.
+
+     Therefore, when given such a pair of operands, the pattern must
+     generate RTL which needs no reloading and needs no temporary
+     registers--no registers other than the operands.  For example, if
+     you support the pattern with a 'define_expand', then in such a case
+     the 'define_expand' mustn't call 'force_reg' or any other such
+     function which might generate new pseudo registers.
+
+     This requirement exists even for subword modes on a RISC machine
+     where fetching those modes from memory normally requires several
+     insns and some temporary registers.
+
+     During reload a memory reference with an invalid address may be
+     passed as an operand.  Such an address will be replaced with a
+     valid address later in the reload pass.  In this case, nothing may
+     be done with the address except to use it as it stands.  If it is
+     copied, it will not be replaced with a valid address.  No attempt
+     should be made to make such an address into a valid address and no
+     routine (such as 'change_address') that will do so may be called.
+     Note that 'general_operand' will fail when applied to such an
+     address.
+
+     The global variable 'reload_in_progress' (which must be explicitly
+     declared if required) can be used to determine whether such special
+     handling is required.
+
+     The variety of operands that have reloads depends on the rest of
+     the machine description, but typically on a RISC machine these can
+     only be pseudo registers that did not get hard registers, while on
+     other machines explicit memory references will get optional
+     reloads.
+
+     If a scratch register is required to move an object to or from
+     memory, it can be allocated using 'gen_reg_rtx' prior to life
+     analysis.
+
+     If there are cases which need scratch registers during or after
+     reload, you must provide an appropriate secondary_reload target
+     hook.
+
+     The macro 'can_create_pseudo_p' can be used to determine if it is
+     unsafe to create new pseudo registers.  If this variable is
+     nonzero, then it is unsafe to call 'gen_reg_rtx' to allocate a new
+     pseudo.
+
+     The constraints on a 'movM' must permit moving any hard register to
+     any other hard register provided that 'HARD_REGNO_MODE_OK' permits
+     mode M in both registers and 'TARGET_REGISTER_MOVE_COST' applied to
+     their classes returns a value of 2.
+
+     It is obligatory to support floating point 'movM' instructions into
+     and out of any registers that can hold fixed point values, because
+     unions and structures (which have modes 'SImode' or 'DImode') can
+     be in those registers and they may have floating point members.
+
+     There may also be a need to support fixed point 'movM' instructions
+     in and out of floating point registers.  Unfortunately, I have
+     forgotten why this was so, and I don't know whether it is still
+     true.  If 'HARD_REGNO_MODE_OK' rejects fixed point values in
+     floating point registers, then the constraints of the fixed point
+     'movM' instructions must be designed to avoid ever trying to reload
+     into a floating point register.
+
+'reload_inM'
+'reload_outM'
+     These named patterns have been obsoleted by the target hook
+     'secondary_reload'.
+
+     Like 'movM', but used when a scratch register is required to move
+     between operand 0 and operand 1.  Operand 2 describes the scratch
+     register.  See the discussion of the 'SECONDARY_RELOAD_CLASS' macro
+     in *note Register Classes::.
+
+     There are special restrictions on the form of the 'match_operand's
+     used in these patterns.  First, only the predicate for the reload
+     operand is examined, i.e., 'reload_in' examines operand 1, but not
+     the predicates for operand 0 or 2.  Second, there may be only one
+     alternative in the constraints.  Third, only a single register
+     class letter may be used for the constraint; subsequent constraint
+     letters are ignored.  As a special exception, an empty constraint
+     string matches the 'ALL_REGS' register class.  This may relieve
+     ports of the burden of defining an 'ALL_REGS' constraint letter
+     just for these patterns.
+
+'movstrictM'
+     Like 'movM' except that if operand 0 is a 'subreg' with mode M of a
+     register whose natural mode is wider, the 'movstrictM' instruction
+     is guaranteed not to alter any of the register except the part
+     which belongs to mode M.
+
+'movmisalignM'
+     This variant of a move pattern is designed to load or store a value
+     from a memory address that is not naturally aligned for its mode.
+     For a store, the memory will be in operand 0; for a load, the
+     memory will be in operand 1.  The other operand is guaranteed not
+     to be a memory, so that it's easy to tell whether this is a load or
+     store.
+
+     This pattern is used by the autovectorizer, and when expanding a
+     'MISALIGNED_INDIRECT_REF' expression.
+
+'load_multiple'
+     Load several consecutive memory locations into consecutive
+     registers.  Operand 0 is the first of the consecutive registers,
+     operand 1 is the first memory location, and operand 2 is a
+     constant: the number of consecutive registers.
+
+     Define this only if the target machine really has such an
+     instruction; do not define this if the most efficient way of
+     loading consecutive registers from memory is to do them one at a
+     time.
+
+     On some machines, there are restrictions as to which consecutive
+     registers can be stored into memory, such as particular starting or
+     ending register numbers or only a range of valid counts.  For those
+     machines, use a 'define_expand' (*note Expander Definitions::) and
+     make the pattern fail if the restrictions are not met.
+
+     Write the generated insn as a 'parallel' with elements being a
+     'set' of one register from the appropriate memory location (you may
+     also need 'use' or 'clobber' elements).  Use a 'match_parallel'
+     (*note RTL Template::) to recognize the insn.  See 'rs6000.md' for
+     examples of the use of this insn pattern.
+
+'store_multiple'
+     Similar to 'load_multiple', but store several consecutive registers
+     into consecutive memory locations.  Operand 0 is the first of the
+     consecutive memory locations, operand 1 is the first register, and
+     operand 2 is a constant: the number of consecutive registers.
+
+'vec_load_lanesMN'
+     Perform an interleaved load of several vectors from memory operand
+     1 into register operand 0.  Both operands have mode M.  The
+     register operand is viewed as holding consecutive vectors of mode
+     N, while the memory operand is a flat array that contains the same
+     number of elements.  The operation is equivalent to:
+
+          int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N);
+          for (j = 0; j < GET_MODE_NUNITS (N); j++)
+            for (i = 0; i < c; i++)
+              operand0[i][j] = operand1[j * c + i];
+
+     For example, 'vec_load_lanestiv4hi' loads 8 16-bit values from
+     memory into a register of mode 'TI'.  The register contains two
+     consecutive vectors of mode 'V4HI'.
+
+     This pattern can only be used if:
+          TARGET_ARRAY_MODE_SUPPORTED_P (N, C)
+     is true.  GCC assumes that, if a target supports this kind of
+     instruction for some mode N, it also supports unaligned loads for
+     vectors of mode N.
+
+'vec_store_lanesMN'
+     Equivalent to 'vec_load_lanesMN', with the memory and register
+     operands reversed.  That is, the instruction is equivalent to:
+
+          int c = GET_MODE_SIZE (M) / GET_MODE_SIZE (N);
+          for (j = 0; j < GET_MODE_NUNITS (N); j++)
+            for (i = 0; i < c; i++)
+              operand0[j * c + i] = operand1[i][j];
+
+     for a memory operand 0 and register operand 1.
+
+'vec_setM'
+     Set given field in the vector value.  Operand 0 is the vector to
+     modify, operand 1 is new value of field and operand 2 specify the
+     field index.
+
+'vec_extractM'
+     Extract given field from the vector value.  Operand 1 is the
+     vector, operand 2 specify field index and operand 0 place to store
+     value into.
+
+'vec_initM'
+     Initialize the vector to given values.  Operand 0 is the vector to
+     initialize and operand 1 is parallel containing values for
+     individual fields.
+
+'vcondMN'
+     Output a conditional vector move.  Operand 0 is the destination to
+     receive a combination of operand 1 and operand 2, which are of mode
+     M, dependent on the outcome of the predicate in operand 3 which is
+     a vector comparison with operands of mode N in operands 4 and 5.
+     The modes M and N should have the same size.  Operand 0 will be set
+     to the value OP1 & MSK | OP2 & ~MSK where MSK is computed by
+     element-wise evaluation of the vector comparison with a truth value
+     of all-ones and a false value of all-zeros.
+
+'vec_permM'
+     Output a (variable) vector permutation.  Operand 0 is the
+     destination to receive elements from operand 1 and operand 2, which
+     are of mode M.  Operand 3 is the "selector".  It is an integral
+     mode vector of the same width and number of elements as mode M.
+
+     The input elements are numbered from 0 in operand 1 through 2*N-1
+     in operand 2.  The elements of the selector must be computed modulo
+     2*N.  Note that if 'rtx_equal_p(operand1, operand2)', this can be
+     implemented with just operand 1 and selector elements modulo N.
+
+     In order to make things easy for a number of targets, if there is
+     no 'vec_perm' pattern for mode M, but there is for mode Q where Q
+     is a vector of 'QImode' of the same width as M, the middle-end will
+     lower the mode M 'VEC_PERM_EXPR' to mode Q.
+
+'vec_perm_constM'
+     Like 'vec_perm' except that the permutation is a compile-time
+     constant.  That is, operand 3, the "selector", is a 'CONST_VECTOR'.
+
+     Some targets cannot perform a permutation with a variable selector,
+     but can efficiently perform a constant permutation.  Further, the
+     target hook 'vec_perm_ok' is queried to determine if the specific
+     constant permutation is available efficiently; the named pattern is
+     never expanded without 'vec_perm_ok' returning true.
+
+     There is no need for a target to supply both 'vec_permM' and
+     'vec_perm_constM' if the former can trivially implement the
+     operation with, say, the vector constant loaded into a register.
+
+'pushM1'
+     Output a push instruction.  Operand 0 is value to push.  Used only
+     when 'PUSH_ROUNDING' is defined.  For historical reason, this
+     pattern may be missing and in such case an 'mov' expander is used
+     instead, with a 'MEM' expression forming the push operation.  The
+     'mov' expander method is deprecated.
+
+'addM3'
+     Add operand 2 and operand 1, storing the result in operand 0.  All
+     operands must have mode M.  This can be used even on two-address
+     machines, by means of constraints requiring operands 1 and 0 to be
+     the same location.
+
+'addptrM3'
+     Like 'addM3' but is guaranteed to only be used for address
+     calculations.  The expanded code is not allowed to clobber the
+     condition code.  It only needs to be defined if 'addM3' sets the
+     condition code.  If adds used for address calculations and normal
+     adds are not compatible it is required to expand a distinct pattern
+     (e.g.  using an unspec).  The pattern is used by LRA to emit
+     address calculations.  'addM3' is used if 'addptrM3' is not
+     defined.
+
+'ssaddM3', 'usaddM3'
+'subM3', 'sssubM3', 'ussubM3'
+'mulM3', 'ssmulM3', 'usmulM3'
+'divM3', 'ssdivM3'
+'udivM3', 'usdivM3'
+'modM3', 'umodM3'
+'uminM3', 'umaxM3'
+'andM3', 'iorM3', 'xorM3'
+     Similar, for other arithmetic operations.
+
+'fmaM4'
+     Multiply operand 2 and operand 1, then add operand 3, storing the
+     result in operand 0 without doing an intermediate rounding step.
+     All operands must have mode M.  This pattern is used to implement
+     the 'fma', 'fmaf', and 'fmal' builtin functions from the ISO C99
+     standard.
+
+'fmsM4'
+     Like 'fmaM4', except operand 3 subtracted from the product instead
+     of added to the product.  This is represented in the rtl as
+
+          (fma:M OP1 OP2 (neg:M OP3))
+
+'fnmaM4'
+     Like 'fmaM4' except that the intermediate product is negated before
+     being added to operand 3.  This is represented in the rtl as
+
+          (fma:M (neg:M OP1) OP2 OP3)
+
+'fnmsM4'
+     Like 'fmsM4' except that the intermediate product is negated before
+     subtracting operand 3.  This is represented in the rtl as
+
+          (fma:M (neg:M OP1) OP2 (neg:M OP3))
+
+'sminM3', 'smaxM3'
+     Signed minimum and maximum operations.  When used with floating
+     point, if both operands are zeros, or if either operand is 'NaN',
+     then it is unspecified which of the two operands is returned as the
+     result.
+
+'reduc_smin_M', 'reduc_smax_M'
+     Find the signed minimum/maximum of the elements of a vector.  The
+     vector is operand 1, and the scalar result is stored in the least
+     significant bits of operand 0 (also a vector).  The output and
+     input vector should have the same modes.
+
+'reduc_umin_M', 'reduc_umax_M'
+     Find the unsigned minimum/maximum of the elements of a vector.  The
+     vector is operand 1, and the scalar result is stored in the least
+     significant bits of operand 0 (also a vector).  The output and
+     input vector should have the same modes.
+
+'reduc_splus_M'
+     Compute the sum of the signed elements of a vector.  The vector is
+     operand 1, and the scalar result is stored in the least significant
+     bits of operand 0 (also a vector).  The output and input vector
+     should have the same modes.
+
+'reduc_uplus_M'
+     Compute the sum of the unsigned elements of a vector.  The vector
+     is operand 1, and the scalar result is stored in the least
+     significant bits of operand 0 (also a vector).  The output and
+     input vector should have the same modes.
+
+'sdot_prodM'
+'udot_prodM'
+     Compute the sum of the products of two signed/unsigned elements.
+     Operand 1 and operand 2 are of the same mode.  Their product, which
+     is of a wider mode, is computed and added to operand 3.  Operand 3
+     is of a mode equal or wider than the mode of the product.  The
+     result is placed in operand 0, which is of the same mode as operand
+     3.
+
+'ssum_widenM3'
+'usum_widenM3'
+     Operands 0 and 2 are of the same mode, which is wider than the mode
+     of operand 1.  Add operand 1 to operand 2 and place the widened
+     result in operand 0.  (This is used express accumulation of
+     elements into an accumulator of a wider mode.)
+
+'vec_shl_M', 'vec_shr_M'
+     Whole vector left/right shift in bits.  Operand 1 is a vector to be
+     shifted.  Operand 2 is an integer shift amount in bits.  Operand 0
+     is where the resulting shifted vector is stored.  The output and
+     input vectors should have the same modes.
+
+'vec_pack_trunc_M'
+     Narrow (demote) and merge the elements of two vectors.  Operands 1
+     and 2 are vectors of the same mode having N integral or floating
+     point elements of size S.  Operand 0 is the resulting vector in
+     which 2*N elements of size N/2 are concatenated after narrowing
+     them down using truncation.
+
+'vec_pack_ssat_M', 'vec_pack_usat_M'
+     Narrow (demote) and merge the elements of two vectors.  Operands 1
+     and 2 are vectors of the same mode having N integral elements of
+     size S. Operand 0 is the resulting vector in which the elements of
+     the two input vectors are concatenated after narrowing them down
+     using signed/unsigned saturating arithmetic.
+
+'vec_pack_sfix_trunc_M', 'vec_pack_ufix_trunc_M'
+     Narrow, convert to signed/unsigned integral type and merge the
+     elements of two vectors.  Operands 1 and 2 are vectors of the same
+     mode having N floating point elements of size S.  Operand 0 is the
+     resulting vector in which 2*N elements of size N/2 are
+     concatenated.
+
+'vec_unpacks_hi_M', 'vec_unpacks_lo_M'
+     Extract and widen (promote) the high/low part of a vector of signed
+     integral or floating point elements.  The input vector (operand 1)
+     has N elements of size S.  Widen (promote) the high/low elements of
+     the vector using signed or floating point extension and place the
+     resulting N/2 values of size 2*S in the output vector (operand 0).
+
+'vec_unpacku_hi_M', 'vec_unpacku_lo_M'
+     Extract and widen (promote) the high/low part of a vector of
+     unsigned integral elements.  The input vector (operand 1) has N
+     elements of size S. Widen (promote) the high/low elements of the
+     vector using zero extension and place the resulting N/2 values of
+     size 2*S in the output vector (operand 0).
+
+'vec_unpacks_float_hi_M', 'vec_unpacks_float_lo_M'
+'vec_unpacku_float_hi_M', 'vec_unpacku_float_lo_M'
+     Extract, convert to floating point type and widen the high/low part
+     of a vector of signed/unsigned integral elements.  The input vector
+     (operand 1) has N elements of size S.  Convert the high/low
+     elements of the vector using floating point conversion and place
+     the resulting N/2 values of size 2*S in the output vector (operand
+     0).
+
+'vec_widen_umult_hi_M', 'vec_widen_umult_lo_M'
+'vec_widen_smult_hi_M', 'vec_widen_smult_lo_M'
+'vec_widen_umult_even_M', 'vec_widen_umult_odd_M'
+'vec_widen_smult_even_M', 'vec_widen_smult_odd_M'
+     Signed/Unsigned widening multiplication.  The two inputs (operands
+     1 and 2) are vectors with N signed/unsigned elements of size S.
+     Multiply the high/low or even/odd elements of the two vectors, and
+     put the N/2 products of size 2*S in the output vector (operand 0).
+     A target shouldn't implement even/odd pattern pair if it is less
+     efficient than lo/hi one.
+
+'vec_widen_ushiftl_hi_M', 'vec_widen_ushiftl_lo_M'
+'vec_widen_sshiftl_hi_M', 'vec_widen_sshiftl_lo_M'
+     Signed/Unsigned widening shift left.  The first input (operand 1)
+     is a vector with N signed/unsigned elements of size S.  Operand 2
+     is a constant.  Shift the high/low elements of operand 1, and put
+     the N/2 results of size 2*S in the output vector (operand 0).
+
+'mulhisi3'
+     Multiply operands 1 and 2, which have mode 'HImode', and store a
+     'SImode' product in operand 0.
+
+'mulqihi3', 'mulsidi3'
+     Similar widening-multiplication instructions of other widths.
+
+'umulqihi3', 'umulhisi3', 'umulsidi3'
+     Similar widening-multiplication instructions that do unsigned
+     multiplication.
+
+'usmulqihi3', 'usmulhisi3', 'usmulsidi3'
+     Similar widening-multiplication instructions that interpret the
+     first operand as unsigned and the second operand as signed, then do
+     a signed multiplication.
+
+'smulM3_highpart'
+     Perform a signed multiplication of operands 1 and 2, which have
+     mode M, and store the most significant half of the product in
+     operand 0.  The least significant half of the product is discarded.
+
+'umulM3_highpart'
+     Similar, but the multiplication is unsigned.
+
+'maddMN4'
+     Multiply operands 1 and 2, sign-extend them to mode N, add operand
+     3, and store the result in operand 0.  Operands 1 and 2 have mode M
+     and operands 0 and 3 have mode N.  Both modes must be integer or
+     fixed-point modes and N must be twice the size of M.
+
+     In other words, 'maddMN4' is like 'mulMN3' except that it also adds
+     operand 3.
+
+     These instructions are not allowed to 'FAIL'.
+
+'umaddMN4'
+     Like 'maddMN4', but zero-extend the multiplication operands instead
+     of sign-extending them.
+
+'ssmaddMN4'
+     Like 'maddMN4', but all involved operations must be
+     signed-saturating.
+
+'usmaddMN4'
+     Like 'umaddMN4', but all involved operations must be
+     unsigned-saturating.
+
+'msubMN4'
+     Multiply operands 1 and 2, sign-extend them to mode N, subtract the
+     result from operand 3, and store the result in operand 0.  Operands
+     1 and 2 have mode M and operands 0 and 3 have mode N.  Both modes
+     must be integer or fixed-point modes and N must be twice the size
+     of M.
+
+     In other words, 'msubMN4' is like 'mulMN3' except that it also
+     subtracts the result from operand 3.
+
+     These instructions are not allowed to 'FAIL'.
+
+'umsubMN4'
+     Like 'msubMN4', but zero-extend the multiplication operands instead
+     of sign-extending them.
+
+'ssmsubMN4'
+     Like 'msubMN4', but all involved operations must be
+     signed-saturating.
+
+'usmsubMN4'
+     Like 'umsubMN4', but all involved operations must be
+     unsigned-saturating.
+
+'divmodM4'
+     Signed division that produces both a quotient and a remainder.
+     Operand 1 is divided by operand 2 to produce a quotient stored in
+     operand 0 and a remainder stored in operand 3.
+
+     For machines with an instruction that produces both a quotient and
+     a remainder, provide a pattern for 'divmodM4' but do not provide
+     patterns for 'divM3' and 'modM3'.  This allows optimization in the
+     relatively common case when both the quotient and remainder are
+     computed.
+
+     If an instruction that just produces a quotient or just a remainder
+     exists and is more efficient than the instruction that produces
+     both, write the output routine of 'divmodM4' to call
+     'find_reg_note' and look for a 'REG_UNUSED' note on the quotient or
+     remainder and generate the appropriate instruction.
+
+'udivmodM4'
+     Similar, but does unsigned division.
+
+'ashlM3', 'ssashlM3', 'usashlM3'
+     Arithmetic-shift operand 1 left by a number of bits specified by
+     operand 2, and store the result in operand 0.  Here M is the mode
+     of operand 0 and operand 1; operand 2's mode is specified by the
+     instruction pattern, and the compiler will convert the operand to
+     that mode before generating the instruction.  The meaning of
+     out-of-range shift counts can optionally be specified by
+     'TARGET_SHIFT_TRUNCATION_MASK'.  *Note
+     TARGET_SHIFT_TRUNCATION_MASK::.  Operand 2 is always a scalar type.
+
+'ashrM3', 'lshrM3', 'rotlM3', 'rotrM3'
+     Other shift and rotate instructions, analogous to the 'ashlM3'
+     instructions.  Operand 2 is always a scalar type.
+
+'vashlM3', 'vashrM3', 'vlshrM3', 'vrotlM3', 'vrotrM3'
+     Vector shift and rotate instructions that take vectors as operand 2
+     instead of a scalar type.
+
+'bswapM2'
+     Reverse the order of bytes of operand 1 and store the result in
+     operand 0.
+
+'negM2', 'ssnegM2', 'usnegM2'
+     Negate operand 1 and store the result in operand 0.
+
+'absM2'
+     Store the absolute value of operand 1 into operand 0.
+
+'sqrtM2'
+     Store the square root of operand 1 into operand 0.
+
+     The 'sqrt' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'sqrtf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'fmodM3'
+     Store the remainder of dividing operand 1 by operand 2 into operand
+     0, rounded towards zero to an integer.
+
+     The 'fmod' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'fmodf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'remainderM3'
+     Store the remainder of dividing operand 1 by operand 2 into operand
+     0, rounded to the nearest integer.
+
+     The 'remainder' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'remainderf'
+     built-in function uses the mode which corresponds to the C data
+     type 'float'.
+
+'cosM2'
+     Store the cosine of operand 1 into operand 0.
+
+     The 'cos' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'cosf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'sinM2'
+     Store the sine of operand 1 into operand 0.
+
+     The 'sin' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'sinf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'sincosM3'
+     Store the cosine of operand 2 into operand 0 and the sine of
+     operand 2 into operand 1.
+
+     The 'sin' and 'cos' built-in functions of C always use the mode
+     which corresponds to the C data type 'double' and the 'sinf' and
+     'cosf' built-in function use the mode which corresponds to the C
+     data type 'float'.  Targets that can calculate the sine and cosine
+     simultaneously can implement this pattern as opposed to
+     implementing individual 'sinM2' and 'cosM2' patterns.  The 'sin'
+     and 'cos' built-in functions will then be expanded to the
+     'sincosM3' pattern, with one of the output values left unused.
+
+'expM2'
+     Store the exponential of operand 1 into operand 0.
+
+     The 'exp' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'expf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'logM2'
+     Store the natural logarithm of operand 1 into operand 0.
+
+     The 'log' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'logf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'powM3'
+     Store the value of operand 1 raised to the exponent operand 2 into
+     operand 0.
+
+     The 'pow' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'powf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'atan2M3'
+     Store the arc tangent (inverse tangent) of operand 1 divided by
+     operand 2 into operand 0, using the signs of both arguments to
+     determine the quadrant of the result.
+
+     The 'atan2' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'atan2f' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'floorM2'
+     Store the largest integral value not greater than argument.
+
+     The 'floor' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'floorf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'btruncM2'
+     Store the argument rounded to integer towards zero.
+
+     The 'trunc' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'truncf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'roundM2'
+     Store the argument rounded to integer away from zero.
+
+     The 'round' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'roundf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'ceilM2'
+     Store the argument rounded to integer away from zero.
+
+     The 'ceil' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'ceilf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'nearbyintM2'
+     Store the argument rounded according to the default rounding mode
+
+     The 'nearbyint' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'nearbyintf'
+     built-in function uses the mode which corresponds to the C data
+     type 'float'.
+
+'rintM2'
+     Store the argument rounded according to the default rounding mode
+     and raise the inexact exception when the result differs in value
+     from the argument
+
+     The 'rint' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'rintf' built-in
+     function uses the mode which corresponds to the C data type
+     'float'.
+
+'lrintMN2'
+     Convert operand 1 (valid for floating point mode M) to fixed point
+     mode N as a signed number according to the current rounding mode
+     and store in operand 0 (which has mode N).
+
+'lroundMN2'
+     Convert operand 1 (valid for floating point mode M) to fixed point
+     mode N as a signed number rounding to nearest and away from zero
+     and store in operand 0 (which has mode N).
+
+'lfloorMN2'
+     Convert operand 1 (valid for floating point mode M) to fixed point
+     mode N as a signed number rounding down and store in operand 0
+     (which has mode N).
+
+'lceilMN2'
+     Convert operand 1 (valid for floating point mode M) to fixed point
+     mode N as a signed number rounding up and store in operand 0 (which
+     has mode N).
+
+'copysignM3'
+     Store a value with the magnitude of operand 1 and the sign of
+     operand 2 into operand 0.
+
+     The 'copysign' built-in function of C always uses the mode which
+     corresponds to the C data type 'double' and the 'copysignf'
+     built-in function uses the mode which corresponds to the C data
+     type 'float'.
+
+'ffsM2'
+     Store into operand 0 one plus the index of the least significant
+     1-bit of operand 1.  If operand 1 is zero, store zero.  M is the
+     mode of operand 0; operand 1's mode is specified by the instruction
+     pattern, and the compiler will convert the operand to that mode
+     before generating the instruction.
+
+     The 'ffs' built-in function of C always uses the mode which
+     corresponds to the C data type 'int'.
+
+'clzM2'
+     Store into operand 0 the number of leading 0-bits in X, starting at
+     the most significant bit position.  If X is 0, the
+     'CLZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the
+     result is undefined or has a useful value.  M is the mode of
+     operand 0; operand 1's mode is specified by the instruction
+     pattern, and the compiler will convert the operand to that mode
+     before generating the instruction.
+
+'ctzM2'
+     Store into operand 0 the number of trailing 0-bits in X, starting
+     at the least significant bit position.  If X is 0, the
+     'CTZ_DEFINED_VALUE_AT_ZERO' (*note Misc::) macro defines if the
+     result is undefined or has a useful value.  M is the mode of
+     operand 0; operand 1's mode is specified by the instruction
+     pattern, and the compiler will convert the operand to that mode
+     before generating the instruction.
+
+'popcountM2'
+     Store into operand 0 the number of 1-bits in X.  M is the mode of
+     operand 0; operand 1's mode is specified by the instruction
+     pattern, and the compiler will convert the operand to that mode
+     before generating the instruction.
+
+'parityM2'
+     Store into operand 0 the parity of X, i.e. the number of 1-bits in
+     X modulo 2.  M is the mode of operand 0; operand 1's mode is
+     specified by the instruction pattern, and the compiler will convert
+     the operand to that mode before generating the instruction.
+
+'one_cmplM2'
+     Store the bitwise-complement of operand 1 into operand 0.
+
+'movmemM'
+     Block move instruction.  The destination and source blocks of
+     memory are the first two operands, and both are 'mem:BLK's with an
+     address in mode 'Pmode'.
+
+     The number of bytes to move is the third operand, in mode M.
+     Usually, you specify 'Pmode' for M.  However, if you can generate
+     better code knowing the range of valid lengths is smaller than
+     those representable in a full Pmode pointer, you should provide a
+     pattern with a mode corresponding to the range of values you can
+     handle efficiently (e.g., 'QImode' for values in the range 0-127;
+     note we avoid numbers that appear negative) and also a pattern with
+     'Pmode'.
+
+     The fourth operand is the known shared alignment of the source and
+     destination, in the form of a 'const_int' rtx.  Thus, if the
+     compiler knows that both source and destination are word-aligned,
+     it may provide the value 4 for this operand.
+
+     Optional operands 5 and 6 specify expected alignment and size of
+     block respectively.  The expected alignment differs from alignment
+     in operand 4 in a way that the blocks are not required to be
+     aligned according to it in all cases.  This expected alignment is
+     also in bytes, just like operand 4.  Expected size, when unknown,
+     is set to '(const_int -1)'.
+
+     Descriptions of multiple 'movmemM' patterns can only be beneficial
+     if the patterns for smaller modes have fewer restrictions on their
+     first, second and fourth operands.  Note that the mode M in
+     'movmemM' does not impose any restriction on the mode of
+     individually moved data units in the block.
+
+     These patterns need not give special consideration to the
+     possibility that the source and destination strings might overlap.
+
+'movstr'
+     String copy instruction, with 'stpcpy' semantics.  Operand 0 is an
+     output operand in mode 'Pmode'.  The addresses of the destination
+     and source strings are operands 1 and 2, and both are 'mem:BLK's
+     with addresses in mode 'Pmode'.  The execution of the expansion of
+     this pattern should store in operand 0 the address in which the
+     'NUL' terminator was stored in the destination string.
+
+     This patern has also several optional operands that are same as in
+     'setmem'.
+
+'setmemM'
+     Block set instruction.  The destination string is the first
+     operand, given as a 'mem:BLK' whose address is in mode 'Pmode'.
+     The number of bytes to set is the second operand, in mode M.  The
+     value to initialize the memory with is the third operand.  Targets
+     that only support the clearing of memory should reject any value
+     that is not the constant 0.  See 'movmemM' for a discussion of the
+     choice of mode.
+
+     The fourth operand is the known alignment of the destination, in
+     the form of a 'const_int' rtx.  Thus, if the compiler knows that
+     the destination is word-aligned, it may provide the value 4 for
+     this operand.
+
+     Optional operands 5 and 6 specify expected alignment and size of
+     block respectively.  The expected alignment differs from alignment
+     in operand 4 in a way that the blocks are not required to be
+     aligned according to it in all cases.  This expected alignment is
+     also in bytes, just like operand 4.  Expected size, when unknown,
+     is set to '(const_int -1)'.  Operand 7 is the minimal size of the
+     block and operand 8 is the maximal size of the block (NULL if it
+     can not be represented as CONST_INT). Operand 9 is the probable
+     maximal size (i.e.  we can not rely on it for correctness, but it
+     can be used for choosing proper code sequence for a given size).
+
+     The use for multiple 'setmemM' is as for 'movmemM'.
+
+'cmpstrnM'
+     String compare instruction, with five operands.  Operand 0 is the
+     output; it has mode M.  The remaining four operands are like the
+     operands of 'movmemM'.  The two memory blocks specified are
+     compared byte by byte in lexicographic order starting at the
+     beginning of each string.  The instruction is not allowed to
+     prefetch more than one byte at a time since either string may end
+     in the first byte and reading past that may access an invalid page
+     or segment and cause a fault.  The comparison terminates early if
+     the fetched bytes are different or if they are equal to zero.  The
+     effect of the instruction is to store a value in operand 0 whose
+     sign indicates the result of the comparison.
+
+'cmpstrM'
+     String compare instruction, without known maximum length.  Operand
+     0 is the output; it has mode M.  The second and third operand are
+     the blocks of memory to be compared; both are 'mem:BLK' with an
+     address in mode 'Pmode'.
+
+     The fourth operand is the known shared alignment of the source and
+     destination, in the form of a 'const_int' rtx.  Thus, if the
+     compiler knows that both source and destination are word-aligned,
+     it may provide the value 4 for this operand.
+
+     The two memory blocks specified are compared byte by byte in
+     lexicographic order starting at the beginning of each string.  The
+     instruction is not allowed to prefetch more than one byte at a time
+     since either string may end in the first byte and reading past that
+     may access an invalid page or segment and cause a fault.  The
+     comparison will terminate when the fetched bytes are different or
+     if they are equal to zero.  The effect of the instruction is to
+     store a value in operand 0 whose sign indicates the result of the
+     comparison.
+
+'cmpmemM'
+     Block compare instruction, with five operands like the operands of
+     'cmpstrM'.  The two memory blocks specified are compared byte by
+     byte in lexicographic order starting at the beginning of each
+     block.  Unlike 'cmpstrM' the instruction can prefetch any bytes in
+     the two memory blocks.  Also unlike 'cmpstrM' the comparison will
+     not stop if both bytes are zero.  The effect of the instruction is
+     to store a value in operand 0 whose sign indicates the result of
+     the comparison.
+
+'strlenM'
+     Compute the length of a string, with three operands.  Operand 0 is
+     the result (of mode M), operand 1 is a 'mem' referring to the first
+     character of the string, operand 2 is the character to search for
+     (normally zero), and operand 3 is a constant describing the known
+     alignment of the beginning of the string.
+
+'floatMN2'
+     Convert signed integer operand 1 (valid for fixed point mode M) to
+     floating point mode N and store in operand 0 (which has mode N).
+
+'floatunsMN2'
+     Convert unsigned integer operand 1 (valid for fixed point mode M)
+     to floating point mode N and store in operand 0 (which has mode N).
+
+'fixMN2'
+     Convert operand 1 (valid for floating point mode M) to fixed point
+     mode N as a signed number and store in operand 0 (which has mode
+     N).  This instruction's result is defined only when the value of
+     operand 1 is an integer.
+
+     If the machine description defines this pattern, it also needs to
+     define the 'ftrunc' pattern.
+
+'fixunsMN2'
+     Convert operand 1 (valid for floating point mode M) to fixed point
+     mode N as an unsigned number and store in operand 0 (which has mode
+     N).  This instruction's result is defined only when the value of
+     operand 1 is an integer.
+
+'ftruncM2'
+     Convert operand 1 (valid for floating point mode M) to an integer
+     value, still represented in floating point mode M, and store it in
+     operand 0 (valid for floating point mode M).
+
+'fix_truncMN2'
+     Like 'fixMN2' but works for any floating point value of mode M by
+     converting the value to an integer.
+
+'fixuns_truncMN2'
+     Like 'fixunsMN2' but works for any floating point value of mode M
+     by converting the value to an integer.
+
+'truncMN2'
+     Truncate operand 1 (valid for mode M) to mode N and store in
+     operand 0 (which has mode N).  Both modes must be fixed point or
+     both floating point.
+
+'extendMN2'
+     Sign-extend operand 1 (valid for mode M) to mode N and store in
+     operand 0 (which has mode N).  Both modes must be fixed point or
+     both floating point.
+
+'zero_extendMN2'
+     Zero-extend operand 1 (valid for mode M) to mode N and store in
+     operand 0 (which has mode N).  Both modes must be fixed point.
+
+'fractMN2'
+     Convert operand 1 of mode M to mode N and store in operand 0 (which
+     has mode N).  Mode M and mode N could be fixed-point to
+     fixed-point, signed integer to fixed-point, fixed-point to signed
+     integer, floating-point to fixed-point, or fixed-point to
+     floating-point.  When overflows or underflows happen, the results
+     are undefined.
+
+'satfractMN2'
+     Convert operand 1 of mode M to mode N and store in operand 0 (which
+     has mode N).  Mode M and mode N could be fixed-point to
+     fixed-point, signed integer to fixed-point, or floating-point to
+     fixed-point.  When overflows or underflows happen, the instruction
+     saturates the results to the maximum or the minimum.
+
+'fractunsMN2'
+     Convert operand 1 of mode M to mode N and store in operand 0 (which
+     has mode N).  Mode M and mode N could be unsigned integer to
+     fixed-point, or fixed-point to unsigned integer.  When overflows or
+     underflows happen, the results are undefined.
+
+'satfractunsMN2'
+     Convert unsigned integer operand 1 of mode M to fixed-point mode N
+     and store in operand 0 (which has mode N).  When overflows or
+     underflows happen, the instruction saturates the results to the
+     maximum or the minimum.
+
+'extvM'
+     Extract a bit-field from register operand 1, sign-extend it, and
+     store it in operand 0.  Operand 2 specifies the width of the field
+     in bits and operand 3 the starting bit, which counts from the most
+     significant bit if 'BITS_BIG_ENDIAN' is true and from the least
+     significant bit otherwise.
+
+     Operands 0 and 1 both have mode M.  Operands 2 and 3 have a
+     target-specific mode.
+
+'extvmisalignM'
+     Extract a bit-field from memory operand 1, sign extend it, and
+     store it in operand 0.  Operand 2 specifies the width in bits and
+     operand 3 the starting bit.  The starting bit is always somewhere
+     in the first byte of operand 1; it counts from the most significant
+     bit if 'BITS_BIG_ENDIAN' is true and from the least significant bit
+     otherwise.
+
+     Operand 0 has mode M while operand 1 has 'BLK' mode.  Operands 2
+     and 3 have a target-specific mode.
+
+     The instruction must not read beyond the last byte of the
+     bit-field.
+
+'extzvM'
+     Like 'extvM' except that the bit-field value is zero-extended.
+
+'extzvmisalignM'
+     Like 'extvmisalignM' except that the bit-field value is
+     zero-extended.
+
+'insvM'
+     Insert operand 3 into a bit-field of register operand 0.  Operand 1
+     specifies the width of the field in bits and operand 2 the starting
+     bit, which counts from the most significant bit if
+     'BITS_BIG_ENDIAN' is true and from the least significant bit
+     otherwise.
+
+     Operands 0 and 3 both have mode M.  Operands 1 and 2 have a
+     target-specific mode.
+
+'insvmisalignM'
+     Insert operand 3 into a bit-field of memory operand 0.  Operand 1
+     specifies the width of the field in bits and operand 2 the starting
+     bit.  The starting bit is always somewhere in the first byte of
+     operand 0; it counts from the most significant bit if
+     'BITS_BIG_ENDIAN' is true and from the least significant bit
+     otherwise.
+
+     Operand 3 has mode M while operand 0 has 'BLK' mode.  Operands 1
+     and 2 have a target-specific mode.
+
+     The instruction must not read or write beyond the last byte of the
+     bit-field.
+
+'extv'
+     Extract a bit-field from operand 1 (a register or memory operand),
+     where operand 2 specifies the width in bits and operand 3 the
+     starting bit, and store it in operand 0.  Operand 0 must have mode
+     'word_mode'.  Operand 1 may have mode 'byte_mode' or 'word_mode';
+     often 'word_mode' is allowed only for registers.  Operands 2 and 3
+     must be valid for 'word_mode'.
+
+     The RTL generation pass generates this instruction only with
+     constants for operands 2 and 3 and the constant is never zero for
+     operand 2.
+
+     The bit-field value is sign-extended to a full word integer before
+     it is stored in operand 0.
+
+     This pattern is deprecated; please use 'extvM' and 'extvmisalignM'
+     instead.
+
+'extzv'
+     Like 'extv' except that the bit-field value is zero-extended.
+
+     This pattern is deprecated; please use 'extzvM' and
+     'extzvmisalignM' instead.
+
+'insv'
+     Store operand 3 (which must be valid for 'word_mode') into a
+     bit-field in operand 0, where operand 1 specifies the width in bits
+     and operand 2 the starting bit.  Operand 0 may have mode
+     'byte_mode' or 'word_mode'; often 'word_mode' is allowed only for
+     registers.  Operands 1 and 2 must be valid for 'word_mode'.
+
+     The RTL generation pass generates this instruction only with
+     constants for operands 1 and 2 and the constant is never zero for
+     operand 1.
+
+     This pattern is deprecated; please use 'insvM' and 'insvmisalignM'
+     instead.
+
+'movMODEcc'
+     Conditionally move operand 2 or operand 3 into operand 0 according
+     to the comparison in operand 1.  If the comparison is true, operand
+     2 is moved into operand 0, otherwise operand 3 is moved.
+
+     The mode of the operands being compared need not be the same as the
+     operands being moved.  Some machines, sparc64 for example, have
+     instructions that conditionally move an integer value based on the
+     floating point condition codes and vice versa.
+
+     If the machine does not have conditional move instructions, do not
+     define these patterns.
+
+'addMODEcc'
+     Similar to 'movMODEcc' but for conditional addition.  Conditionally
+     move operand 2 or (operands 2 + operand 3) into operand 0 according
+     to the comparison in operand 1.  If the comparison is false,
+     operand 2 is moved into operand 0, otherwise (operand 2 + operand
+     3) is moved.
+
+'cstoreMODE4'
+     Store zero or nonzero in operand 0 according to whether a
+     comparison is true.  Operand 1 is a comparison operator.  Operand 2
+     and operand 3 are the first and second operand of the comparison,
+     respectively.  You specify the mode that operand 0 must have when
+     you write the 'match_operand' expression.  The compiler
+     automatically sees which mode you have used and supplies an operand
+     of that mode.
+
+     The value stored for a true condition must have 1 as its low bit,
+     or else must be negative.  Otherwise the instruction is not
+     suitable and you should omit it from the machine description.  You
+     describe to the compiler exactly which value is stored by defining
+     the macro 'STORE_FLAG_VALUE' (*note Misc::).  If a description
+     cannot be found that can be used for all the possible comparison
+     operators, you should pick one and use a 'define_expand' to map all
+     results onto the one you chose.
+
+     These operations may 'FAIL', but should do so only in relatively
+     uncommon cases; if they would 'FAIL' for common cases involving
+     integer comparisons, it is best to restrict the predicates to not
+     allow these operands.  Likewise if a given comparison operator will
+     always fail, independent of the operands (for floating-point modes,
+     the 'ordered_comparison_operator' predicate is often useful in this
+     case).
+
+     If this pattern is omitted, the compiler will generate a
+     conditional branch--for example, it may copy a constant one to the
+     target and branching around an assignment of zero to the target--or
+     a libcall.  If the predicate for operand 1 only rejects some
+     operators, it will also try reordering the operands and/or
+     inverting the result value (e.g. by an exclusive OR). These
+     possibilities could be cheaper or equivalent to the instructions
+     used for the 'cstoreMODE4' pattern followed by those required to
+     convert a positive result from 'STORE_FLAG_VALUE' to 1; in this
+     case, you can and should make operand 1's predicate reject some
+     operators in the 'cstoreMODE4' pattern, or remove the pattern
+     altogether from the machine description.
+
+'cbranchMODE4'
+     Conditional branch instruction combined with a compare instruction.
+     Operand 0 is a comparison operator.  Operand 1 and operand 2 are
+     the first and second operands of the comparison, respectively.
+     Operand 3 is a 'label_ref' that refers to the label to jump to.
+
+'jump'
+     A jump inside a function; an unconditional branch.  Operand 0 is
+     the 'label_ref' of the label to jump to.  This pattern name is
+     mandatory on all machines.
+
+'call'
+     Subroutine call instruction returning no value.  Operand 0 is the
+     function to call; operand 1 is the number of bytes of arguments
+     pushed as a 'const_int'; operand 2 is the number of registers used
+     as operands.
+
+     On most machines, operand 2 is not actually stored into the RTL
+     pattern.  It is supplied for the sake of some RISC machines which
+     need to put this information into the assembler code; they can put
+     it in the RTL instead of operand 1.
+
+     Operand 0 should be a 'mem' RTX whose address is the address of the
+     function.  Note, however, that this address can be a 'symbol_ref'
+     expression even if it would not be a legitimate memory address on
+     the target machine.  If it is also not a valid argument for a call
+     instruction, the pattern for this operation should be a
+     'define_expand' (*note Expander Definitions::) that places the
+     address into a register and uses that register in the call
+     instruction.
+
+'call_value'
+     Subroutine call instruction returning a value.  Operand 0 is the
+     hard register in which the value is returned.  There are three more
+     operands, the same as the three operands of the 'call' instruction
+     (but with numbers increased by one).
+
+     Subroutines that return 'BLKmode' objects use the 'call' insn.
+
+'call_pop', 'call_value_pop'
+     Similar to 'call' and 'call_value', except used if defined and if
+     'RETURN_POPS_ARGS' is nonzero.  They should emit a 'parallel' that
+     contains both the function call and a 'set' to indicate the
+     adjustment made to the frame pointer.
+
+     For machines where 'RETURN_POPS_ARGS' can be nonzero, the use of
+     these patterns increases the number of functions for which the
+     frame pointer can be eliminated, if desired.
+
+'untyped_call'
+     Subroutine call instruction returning a value of any type.  Operand
+     0 is the function to call; operand 1 is a memory location where the
+     result of calling the function is to be stored; operand 2 is a
+     'parallel' expression where each element is a 'set' expression that
+     indicates the saving of a function return value into the result
+     block.
+
+     This instruction pattern should be defined to support
+     '__builtin_apply' on machines where special instructions are needed
+     to call a subroutine with arbitrary arguments or to save the value
+     returned.  This instruction pattern is required on machines that
+     have multiple registers that can hold a return value (i.e.
+     'FUNCTION_VALUE_REGNO_P' is true for more than one register).
+
+'return'
+     Subroutine return instruction.  This instruction pattern name
+     should be defined only if a single instruction can do all the work
+     of returning from a function.
+
+     Like the 'movM' patterns, this pattern is also used after the RTL
+     generation phase.  In this case it is to support machines where
+     multiple instructions are usually needed to return from a function,
+     but some class of functions only requires one instruction to
+     implement a return.  Normally, the applicable functions are those
+     which do not need to save any registers or allocate stack space.
+
+     It is valid for this pattern to expand to an instruction using
+     'simple_return' if no epilogue is required.
+
+'simple_return'
+     Subroutine return instruction.  This instruction pattern name
+     should be defined only if a single instruction can do all the work
+     of returning from a function on a path where no epilogue is
+     required.  This pattern is very similar to the 'return' instruction
+     pattern, but it is emitted only by the shrink-wrapping optimization
+     on paths where the function prologue has not been executed, and a
+     function return should occur without any of the effects of the
+     epilogue.  Additional uses may be introduced on paths where both
+     the prologue and the epilogue have executed.
+
+     For such machines, the condition specified in this pattern should
+     only be true when 'reload_completed' is nonzero and the function's
+     epilogue would only be a single instruction.  For machines with
+     register windows, the routine 'leaf_function_p' may be used to
+     determine if a register window push is required.
+
+     Machines that have conditional return instructions should define
+     patterns such as
+
+          (define_insn ""
+            [(set (pc)
+                  (if_then_else (match_operator
+                                   0 "comparison_operator"
+                                   [(cc0) (const_int 0)])
+                                (return)
+                                (pc)))]
+            "CONDITION"
+            "...")
+
+     where CONDITION would normally be the same condition specified on
+     the named 'return' pattern.
+
+'untyped_return'
+     Untyped subroutine return instruction.  This instruction pattern
+     should be defined to support '__builtin_return' on machines where
+     special instructions are needed to return a value of any type.
+
+     Operand 0 is a memory location where the result of calling a
+     function with '__builtin_apply' is stored; operand 1 is a
+     'parallel' expression where each element is a 'set' expression that
+     indicates the restoring of a function return value from the result
+     block.
+
+'nop'
+     No-op instruction.  This instruction pattern name should always be
+     defined to output a no-op in assembler code.  '(const_int 0)' will
+     do as an RTL pattern.
+
+'indirect_jump'
+     An instruction to jump to an address which is operand zero.  This
+     pattern name is mandatory on all machines.
+
+'casesi'
+     Instruction to jump through a dispatch table, including bounds
+     checking.  This instruction takes five operands:
+
+       1. The index to dispatch on, which has mode 'SImode'.
+
+       2. The lower bound for indices in the table, an integer constant.
+
+       3. The total range of indices in the table--the largest index
+          minus the smallest one (both inclusive).
+
+       4. A label that precedes the table itself.
+
+       5. A label to jump to if the index has a value outside the
+          bounds.
+
+     The table is an 'addr_vec' or 'addr_diff_vec' inside of a
+     'jump_table_data'.  The number of elements in the table is one plus
+     the difference between the upper bound and the lower bound.
+
+'tablejump'
+     Instruction to jump to a variable address.  This is a low-level
+     capability which can be used to implement a dispatch table when
+     there is no 'casesi' pattern.
+
+     This pattern requires two operands: the address or offset, and a
+     label which should immediately precede the jump table.  If the
+     macro 'CASE_VECTOR_PC_RELATIVE' evaluates to a nonzero value then
+     the first operand is an offset which counts from the address of the
+     table; otherwise, it is an absolute address to jump to.  In either
+     case, the first operand has mode 'Pmode'.
+
+     The 'tablejump' insn is always the last insn before the jump table
+     it uses.  Its assembler code normally has no need to use the second
+     operand, but you should incorporate it in the RTL pattern so that
+     the jump optimizer will not delete the table as unreachable code.
+
+'decrement_and_branch_until_zero'
+     Conditional branch instruction that decrements a register and jumps
+     if the register is nonzero.  Operand 0 is the register to decrement
+     and test; operand 1 is the label to jump to if the register is
+     nonzero.  *Note Looping Patterns::.
+
+     This optional instruction pattern is only used by the combiner,
+     typically for loops reversed by the loop optimizer when strength
+     reduction is enabled.
+
+'doloop_end'
+     Conditional branch instruction that decrements a register and jumps
+     if the register is nonzero.  Operand 0 is the register to decrement
+     and test; operand 1 is the label to jump to if the register is
+     nonzero.  *Note Looping Patterns::.
+
+     This optional instruction pattern should be defined for machines
+     with low-overhead looping instructions as the loop optimizer will
+     try to modify suitable loops to utilize it.  The target hook
+     'TARGET_CAN_USE_DOLOOP_P' controls the conditions under which
+     low-overhead loops can be used.
+
+'doloop_begin'
+     Companion instruction to 'doloop_end' required for machines that
+     need to perform some initialization, such as loading a special
+     counter register.  Operand 1 is the associated 'doloop_end' pattern
+     and operand 0 is the register that it decrements.
+
+     If initialization insns do not always need to be emitted, use a
+     'define_expand' (*note Expander Definitions::) and make it fail.
+
+'canonicalize_funcptr_for_compare'
+     Canonicalize the function pointer in operand 1 and store the result
+     into operand 0.
+
+     Operand 0 is always a 'reg' and has mode 'Pmode'; operand 1 may be
+     a 'reg', 'mem', 'symbol_ref', 'const_int', etc and also has mode
+     'Pmode'.
+
+     Canonicalization of a function pointer usually involves computing
+     the address of the function which would be called if the function
+     pointer were used in an indirect call.
+
+     Only define this pattern if function pointers on the target machine
+     can have different values but still call the same function when
+     used in an indirect call.
+
+'save_stack_block'
+'save_stack_function'
+'save_stack_nonlocal'
+'restore_stack_block'
+'restore_stack_function'
+'restore_stack_nonlocal'
+     Most machines save and restore the stack pointer by copying it to
+     or from an object of mode 'Pmode'.  Do not define these patterns on
+     such machines.
+
+     Some machines require special handling for stack pointer saves and
+     restores.  On those machines, define the patterns corresponding to
+     the non-standard cases by using a 'define_expand' (*note Expander
+     Definitions::) that produces the required insns.  The three types
+     of saves and restores are:
+
+       1. 'save_stack_block' saves the stack pointer at the start of a
+          block that allocates a variable-sized object, and
+          'restore_stack_block' restores the stack pointer when the
+          block is exited.
+
+       2. 'save_stack_function' and 'restore_stack_function' do a
+          similar job for the outermost block of a function and are used
+          when the function allocates variable-sized objects or calls
+          'alloca'.  Only the epilogue uses the restored stack pointer,
+          allowing a simpler save or restore sequence on some machines.
+
+       3. 'save_stack_nonlocal' is used in functions that contain labels
+          branched to by nested functions.  It saves the stack pointer
+          in such a way that the inner function can use
+          'restore_stack_nonlocal' to restore the stack pointer.  The
+          compiler generates code to restore the frame and argument
+          pointer registers, but some machines require saving and
+          restoring additional data such as register window information
+          or stack backchains.  Place insns in these patterns to save
+          and restore any such required data.
+
+     When saving the stack pointer, operand 0 is the save area and
+     operand 1 is the stack pointer.  The mode used to allocate the save
+     area defaults to 'Pmode' but you can override that choice by
+     defining the 'STACK_SAVEAREA_MODE' macro (*note Storage Layout::).
+     You must specify an integral mode, or 'VOIDmode' if no save area is
+     needed for a particular type of save (either because no save is
+     needed or because a machine-specific save area can be used).
+     Operand 0 is the stack pointer and operand 1 is the save area for
+     restore operations.  If 'save_stack_block' is defined, operand 0
+     must not be 'VOIDmode' since these saves can be arbitrarily nested.
+
+     A save area is a 'mem' that is at a constant offset from
+     'virtual_stack_vars_rtx' when the stack pointer is saved for use by
+     nonlocal gotos and a 'reg' in the other two cases.
+
+'allocate_stack'
+     Subtract (or add if 'STACK_GROWS_DOWNWARD' is undefined) operand 1
+     from the stack pointer to create space for dynamically allocated
+     data.
+
+     Store the resultant pointer to this space into operand 0.  If you
+     are allocating space from the main stack, do this by emitting a
+     move insn to copy 'virtual_stack_dynamic_rtx' to operand 0.  If you
+     are allocating the space elsewhere, generate code to copy the
+     location of the space to operand 0.  In the latter case, you must
+     ensure this space gets freed when the corresponding space on the
+     main stack is free.
+
+     Do not define this pattern if all that must be done is the
+     subtraction.  Some machines require other operations such as stack
+     probes or maintaining the back chain.  Define this pattern to emit
+     those operations in addition to updating the stack pointer.
+
+'check_stack'
+     If stack checking (*note Stack Checking::) cannot be done on your
+     system by probing the stack, define this pattern to perform the
+     needed check and signal an error if the stack has overflowed.  The
+     single operand is the address in the stack farthest from the
+     current stack pointer that you need to validate.  Normally, on
+     platforms where this pattern is needed, you would obtain the stack
+     limit from a global or thread-specific variable or register.
+
+'probe_stack_address'
+     If stack checking (*note Stack Checking::) can be done on your
+     system by probing the stack but without the need to actually access
+     it, define this pattern and signal an error if the stack has
+     overflowed.  The single operand is the memory address in the stack
+     that needs to be probed.
+
+'probe_stack'
+     If stack checking (*note Stack Checking::) can be done on your
+     system by probing the stack but doing it with a "store zero"
+     instruction is not valid or optimal, define this pattern to do the
+     probing differently and signal an error if the stack has
+     overflowed.  The single operand is the memory reference in the
+     stack that needs to be probed.
+
+'nonlocal_goto'
+     Emit code to generate a non-local goto, e.g., a jump from one
+     function to a label in an outer function.  This pattern has four
+     arguments, each representing a value to be used in the jump.  The
+     first argument is to be loaded into the frame pointer, the second
+     is the address to branch to (code to dispatch to the actual label),
+     the third is the address of a location where the stack is saved,
+     and the last is the address of the label, to be placed in the
+     location for the incoming static chain.
+
+     On most machines you need not define this pattern, since GCC will
+     already generate the correct code, which is to load the frame
+     pointer and static chain, restore the stack (using the
+     'restore_stack_nonlocal' pattern, if defined), and jump indirectly
+     to the dispatcher.  You need only define this pattern if this code
+     will not work on your machine.
+
+'nonlocal_goto_receiver'
+     This pattern, if defined, contains code needed at the target of a
+     nonlocal goto after the code already generated by GCC.  You will
+     not normally need to define this pattern.  A typical reason why you
+     might need this pattern is if some value, such as a pointer to a
+     global table, must be restored when the frame pointer is restored.
+     Note that a nonlocal goto only occurs within a unit-of-translation,
+     so a global table pointer that is shared by all functions of a
+     given module need not be restored.  There are no arguments.
+
+'exception_receiver'
+     This pattern, if defined, contains code needed at the site of an
+     exception handler that isn't needed at the site of a nonlocal goto.
+     You will not normally need to define this pattern.  A typical
+     reason why you might need this pattern is if some value, such as a
+     pointer to a global table, must be restored after control flow is
+     branched to the handler of an exception.  There are no arguments.
+
+'builtin_setjmp_setup'
+     This pattern, if defined, contains additional code needed to
+     initialize the 'jmp_buf'.  You will not normally need to define
+     this pattern.  A typical reason why you might need this pattern is
+     if some value, such as a pointer to a global table, must be
+     restored.  Though it is preferred that the pointer value be
+     recalculated if possible (given the address of a label for
+     instance).  The single argument is a pointer to the 'jmp_buf'.
+     Note that the buffer is five words long and that the first three
+     are normally used by the generic mechanism.
+
+'builtin_setjmp_receiver'
+     This pattern, if defined, contains code needed at the site of a
+     built-in setjmp that isn't needed at the site of a nonlocal goto.
+     You will not normally need to define this pattern.  A typical
+     reason why you might need this pattern is if some value, such as a
+     pointer to a global table, must be restored.  It takes one
+     argument, which is the label to which builtin_longjmp transferred
+     control; this pattern may be emitted at a small offset from that
+     label.
+
+'builtin_longjmp'
+     This pattern, if defined, performs the entire action of the
+     longjmp.  You will not normally need to define this pattern unless
+     you also define 'builtin_setjmp_setup'.  The single argument is a
+     pointer to the 'jmp_buf'.
+
+'eh_return'
+     This pattern, if defined, affects the way '__builtin_eh_return',
+     and thence the call frame exception handling library routines, are
+     built.  It is intended to handle non-trivial actions needed along
+     the abnormal return path.
+
+     The address of the exception handler to which the function should
+     return is passed as operand to this pattern.  It will normally need
+     to copied by the pattern to some special register or memory
+     location.  If the pattern needs to determine the location of the
+     target call frame in order to do so, it may use
+     'EH_RETURN_STACKADJ_RTX', if defined; it will have already been
+     assigned.
+
+     If this pattern is not defined, the default action will be to
+     simply copy the return address to 'EH_RETURN_HANDLER_RTX'.  Either
+     that macro or this pattern needs to be defined if call frame
+     exception handling is to be used.
+
+'prologue'
+     This pattern, if defined, emits RTL for entry to a function.  The
+     function entry is responsible for setting up the stack frame,
+     initializing the frame pointer register, saving callee saved
+     registers, etc.
+
+     Using a prologue pattern is generally preferred over defining
+     'TARGET_ASM_FUNCTION_PROLOGUE' to emit assembly code for the
+     prologue.
+
+     The 'prologue' pattern is particularly useful for targets which
+     perform instruction scheduling.
+
+'window_save'
+     This pattern, if defined, emits RTL for a register window save.  It
+     should be defined if the target machine has register windows but
+     the window events are decoupled from calls to subroutines.  The
+     canonical example is the SPARC architecture.
+
+'epilogue'
+     This pattern emits RTL for exit from a function.  The function exit
+     is responsible for deallocating the stack frame, restoring callee
+     saved registers and emitting the return instruction.
+
+     Using an epilogue pattern is generally preferred over defining
+     'TARGET_ASM_FUNCTION_EPILOGUE' to emit assembly code for the
+     epilogue.
+
+     The 'epilogue' pattern is particularly useful for targets which
+     perform instruction scheduling or which have delay slots for their
+     return instruction.
+
+'sibcall_epilogue'
+     This pattern, if defined, emits RTL for exit from a function
+     without the final branch back to the calling function.  This
+     pattern will be emitted before any sibling call (aka tail call)
+     sites.
+
+     The 'sibcall_epilogue' pattern must not clobber any arguments used
+     for parameter passing or any stack slots for arguments passed to
+     the current function.
+
+'trap'
+     This pattern, if defined, signals an error, typically by causing
+     some kind of signal to be raised.  Among other places, it is used
+     by the Java front end to signal 'invalid array index' exceptions.
+
+'ctrapMM4'
+     Conditional trap instruction.  Operand 0 is a piece of RTL which
+     performs a comparison, and operands 1 and 2 are the arms of the
+     comparison.  Operand 3 is the trap code, an integer.
+
+     A typical 'ctrap' pattern looks like
+
+          (define_insn "ctrapsi4"
+            [(trap_if (match_operator 0 "trap_operator"
+                       [(match_operand 1 "register_operand")
+                        (match_operand 2 "immediate_operand")])
+                      (match_operand 3 "const_int_operand" "i"))]
+            ""
+            "...")
+
+'prefetch'
+
+     This pattern, if defined, emits code for a non-faulting data
+     prefetch instruction.  Operand 0 is the address of the memory to
+     prefetch.  Operand 1 is a constant 1 if the prefetch is preparing
+     for a write to the memory address, or a constant 0 otherwise.
+     Operand 2 is the expected degree of temporal locality of the data
+     and is a value between 0 and 3, inclusive; 0 means that the data
+     has no temporal locality, so it need not be left in the cache after
+     the access; 3 means that the data has a high degree of temporal
+     locality and should be left in all levels of cache possible; 1 and
+     2 mean, respectively, a low or moderate degree of temporal
+     locality.
+
+     Targets that do not support write prefetches or locality hints can
+     ignore the values of operands 1 and 2.
+
+'blockage'
+
+     This pattern defines a pseudo insn that prevents the instruction
+     scheduler and other passes from moving instructions and using
+     register equivalences across the boundary defined by the blockage
+     insn.  This needs to be an UNSPEC_VOLATILE pattern or a volatile
+     ASM.
+
+'memory_barrier'
+
+     If the target memory model is not fully synchronous, then this
+     pattern should be defined to an instruction that orders both loads
+     and stores before the instruction with respect to loads and stores
+     after the instruction.  This pattern has no operands.
+
+'sync_compare_and_swapMODE'
+
+     This pattern, if defined, emits code for an atomic compare-and-swap
+     operation.  Operand 1 is the memory on which the atomic operation
+     is performed.  Operand 2 is the "old" value to be compared against
+     the current contents of the memory location.  Operand 3 is the
+     "new" value to store in the memory if the compare succeeds.
+     Operand 0 is the result of the operation; it should contain the
+     contents of the memory before the operation.  If the compare
+     succeeds, this should obviously be a copy of operand 2.
+
+     This pattern must show that both operand 0 and operand 1 are
+     modified.
+
+     This pattern must issue any memory barrier instructions such that
+     all memory operations before the atomic operation occur before the
+     atomic operation and all memory operations after the atomic
+     operation occur after the atomic operation.
+
+     For targets where the success or failure of the compare-and-swap
+     operation is available via the status flags, it is possible to
+     avoid a separate compare operation and issue the subsequent branch
+     or store-flag operation immediately after the compare-and-swap.  To
+     this end, GCC will look for a 'MODE_CC' set in the output of
+     'sync_compare_and_swapMODE'; if the machine description includes
+     such a set, the target should also define special 'cbranchcc4'
+     and/or 'cstorecc4' instructions.  GCC will then be able to take the
+     destination of the 'MODE_CC' set and pass it to the 'cbranchcc4' or
+     'cstorecc4' pattern as the first operand of the comparison (the
+     second will be '(const_int 0)').
+
+     For targets where the operating system may provide support for this
+     operation via library calls, the 'sync_compare_and_swap_optab' may
+     be initialized to a function with the same interface as the
+     '__sync_val_compare_and_swap_N' built-in.  If the entire set of
+     __SYNC builtins are supported via library calls, the target can
+     initialize all of the optabs at once with 'init_sync_libfuncs'.
+     For the purposes of C++11 'std::atomic::is_lock_free', it is
+     assumed that these library calls do _not_ use any kind of
+     interruptable locking.
+
+'sync_addMODE', 'sync_subMODE'
+'sync_iorMODE', 'sync_andMODE'
+'sync_xorMODE', 'sync_nandMODE'
+
+     These patterns emit code for an atomic operation on memory.
+     Operand 0 is the memory on which the atomic operation is performed.
+     Operand 1 is the second operand to the binary operator.
+
+     This pattern must issue any memory barrier instructions such that
+     all memory operations before the atomic operation occur before the
+     atomic operation and all memory operations after the atomic
+     operation occur after the atomic operation.
+
+     If these patterns are not defined, the operation will be
+     constructed from a compare-and-swap operation, if defined.
+
+'sync_old_addMODE', 'sync_old_subMODE'
+'sync_old_iorMODE', 'sync_old_andMODE'
+'sync_old_xorMODE', 'sync_old_nandMODE'
+
+     These patterns emit code for an atomic operation on memory, and
+     return the value that the memory contained before the operation.
+     Operand 0 is the result value, operand 1 is the memory on which the
+     atomic operation is performed, and operand 2 is the second operand
+     to the binary operator.
+
+     This pattern must issue any memory barrier instructions such that
+     all memory operations before the atomic operation occur before the
+     atomic operation and all memory operations after the atomic
+     operation occur after the atomic operation.
+
+     If these patterns are not defined, the operation will be
+     constructed from a compare-and-swap operation, if defined.
+
+'sync_new_addMODE', 'sync_new_subMODE'
+'sync_new_iorMODE', 'sync_new_andMODE'
+'sync_new_xorMODE', 'sync_new_nandMODE'
+
+     These patterns are like their 'sync_old_OP' counterparts, except
+     that they return the value that exists in the memory location after
+     the operation, rather than before the operation.
+
+'sync_lock_test_and_setMODE'
+
+     This pattern takes two forms, based on the capabilities of the
+     target.  In either case, operand 0 is the result of the operand,
+     operand 1 is the memory on which the atomic operation is performed,
+     and operand 2 is the value to set in the lock.
+
+     In the ideal case, this operation is an atomic exchange operation,
+     in which the previous value in memory operand is copied into the
+     result operand, and the value operand is stored in the memory
+     operand.
+
+     For less capable targets, any value operand that is not the
+     constant 1 should be rejected with 'FAIL'.  In this case the target
+     may use an atomic test-and-set bit operation.  The result operand
+     should contain 1 if the bit was previously set and 0 if the bit was
+     previously clear.  The true contents of the memory operand are
+     implementation defined.
+
+     This pattern must issue any memory barrier instructions such that
+     the pattern as a whole acts as an acquire barrier, that is all
+     memory operations after the pattern do not occur until the lock is
+     acquired.
+
+     If this pattern is not defined, the operation will be constructed
+     from a compare-and-swap operation, if defined.
+
+'sync_lock_releaseMODE'
+
+     This pattern, if defined, releases a lock set by
+     'sync_lock_test_and_setMODE'.  Operand 0 is the memory that
+     contains the lock; operand 1 is the value to store in the lock.
+
+     If the target doesn't implement full semantics for
+     'sync_lock_test_and_setMODE', any value operand which is not the
+     constant 0 should be rejected with 'FAIL', and the true contents of
+     the memory operand are implementation defined.
+
+     This pattern must issue any memory barrier instructions such that
+     the pattern as a whole acts as a release barrier, that is the lock
+     is released only after all previous memory operations have
+     completed.
+
+     If this pattern is not defined, then a 'memory_barrier' pattern
+     will be emitted, followed by a store of the value to the memory
+     operand.
+
+'atomic_compare_and_swapMODE'
+     This pattern, if defined, emits code for an atomic compare-and-swap
+     operation with memory model semantics.  Operand 2 is the memory on
+     which the atomic operation is performed.  Operand 0 is an output
+     operand which is set to true or false based on whether the
+     operation succeeded.  Operand 1 is an output operand which is set
+     to the contents of the memory before the operation was attempted.
+     Operand 3 is the value that is expected to be in memory.  Operand 4
+     is the value to put in memory if the expected value is found there.
+     Operand 5 is set to 1 if this compare and swap is to be treated as
+     a weak operation.  Operand 6 is the memory model to be used if the
+     operation is a success.  Operand 7 is the memory model to be used
+     if the operation fails.
+
+     If memory referred to in operand 2 contains the value in operand 3,
+     then operand 4 is stored in memory pointed to by operand 2 and
+     fencing based on the memory model in operand 6 is issued.
+
+     If memory referred to in operand 2 does not contain the value in
+     operand 3, then fencing based on the memory model in operand 7 is
+     issued.
+
+     If a target does not support weak compare-and-swap operations, or
+     the port elects not to implement weak operations, the argument in
+     operand 5 can be ignored.  Note a strong implementation must be
+     provided.
+
+     If this pattern is not provided, the '__atomic_compare_exchange'
+     built-in functions will utilize the legacy 'sync_compare_and_swap'
+     pattern with an '__ATOMIC_SEQ_CST' memory model.
+
+'atomic_loadMODE'
+     This pattern implements an atomic load operation with memory model
+     semantics.  Operand 1 is the memory address being loaded from.
+     Operand 0 is the result of the load.  Operand 2 is the memory model
+     to be used for the load operation.
+
+     If not present, the '__atomic_load' built-in function will either
+     resort to a normal load with memory barriers, or a compare-and-swap
+     operation if a normal load would not be atomic.
+
+'atomic_storeMODE'
+     This pattern implements an atomic store operation with memory model
+     semantics.  Operand 0 is the memory address being stored to.
+     Operand 1 is the value to be written.  Operand 2 is the memory
+     model to be used for the operation.
+
+     If not present, the '__atomic_store' built-in function will attempt
+     to perform a normal store and surround it with any required memory
+     fences.  If the store would not be atomic, then an
+     '__atomic_exchange' is attempted with the result being ignored.
+
+'atomic_exchangeMODE'
+     This pattern implements an atomic exchange operation with memory
+     model semantics.  Operand 1 is the memory location the operation is
+     performed on.  Operand 0 is an output operand which is set to the
+     original value contained in the memory pointed to by operand 1.
+     Operand 2 is the value to be stored.  Operand 3 is the memory model
+     to be used.
+
+     If this pattern is not present, the built-in function
+     '__atomic_exchange' will attempt to preform the operation with a
+     compare and swap loop.
+
+'atomic_addMODE', 'atomic_subMODE'
+'atomic_orMODE', 'atomic_andMODE'
+'atomic_xorMODE', 'atomic_nandMODE'
+
+     These patterns emit code for an atomic operation on memory with
+     memory model semantics.  Operand 0 is the memory on which the
+     atomic operation is performed.  Operand 1 is the second operand to
+     the binary operator.  Operand 2 is the memory model to be used by
+     the operation.
+
+     If these patterns are not defined, attempts will be made to use
+     legacy 'sync' patterns, or equivalent patterns which return a
+     result.  If none of these are available a compare-and-swap loop
+     will be used.
+
+'atomic_fetch_addMODE', 'atomic_fetch_subMODE'
+'atomic_fetch_orMODE', 'atomic_fetch_andMODE'
+'atomic_fetch_xorMODE', 'atomic_fetch_nandMODE'
+
+     These patterns emit code for an atomic operation on memory with
+     memory model semantics, and return the original value.  Operand 0
+     is an output operand which contains the value of the memory
+     location before the operation was performed.  Operand 1 is the
+     memory on which the atomic operation is performed.  Operand 2 is
+     the second operand to the binary operator.  Operand 3 is the memory
+     model to be used by the operation.
+
+     If these patterns are not defined, attempts will be made to use
+     legacy 'sync' patterns.  If none of these are available a
+     compare-and-swap loop will be used.
+
+'atomic_add_fetchMODE', 'atomic_sub_fetchMODE'
+'atomic_or_fetchMODE', 'atomic_and_fetchMODE'
+'atomic_xor_fetchMODE', 'atomic_nand_fetchMODE'
+
+     These patterns emit code for an atomic operation on memory with
+     memory model semantics and return the result after the operation is
+     performed.  Operand 0 is an output operand which contains the value
+     after the operation.  Operand 1 is the memory on which the atomic
+     operation is performed.  Operand 2 is the second operand to the
+     binary operator.  Operand 3 is the memory model to be used by the
+     operation.
+
+     If these patterns are not defined, attempts will be made to use
+     legacy 'sync' patterns, or equivalent patterns which return the
+     result before the operation followed by the arithmetic operation
+     required to produce the result.  If none of these are available a
+     compare-and-swap loop will be used.
+
+'atomic_test_and_set'
+
+     This pattern emits code for '__builtin_atomic_test_and_set'.
+     Operand 0 is an output operand which is set to true if the previous
+     previous contents of the byte was "set", and false otherwise.
+     Operand 1 is the 'QImode' memory to be modified.  Operand 2 is the
+     memory model to be used.
+
+     The specific value that defines "set" is implementation defined,
+     and is normally based on what is performed by the native atomic
+     test and set instruction.
+
+'mem_thread_fenceMODE'
+     This pattern emits code required to implement a thread fence with
+     memory model semantics.  Operand 0 is the memory model to be used.
+
+     If this pattern is not specified, all memory models except
+     '__ATOMIC_RELAXED' will result in issuing a 'sync_synchronize'
+     barrier pattern.
+
+'mem_signal_fenceMODE'
+     This pattern emits code required to implement a signal fence with
+     memory model semantics.  Operand 0 is the memory model to be used.
+
+     This pattern should impact the compiler optimizers the same way
+     that mem_signal_fence does, but it does not need to issue any
+     barrier instructions.
+
+     If this pattern is not specified, all memory models except
+     '__ATOMIC_RELAXED' will result in issuing a 'sync_synchronize'
+     barrier pattern.
+
+'get_thread_pointerMODE'
+'set_thread_pointerMODE'
+     These patterns emit code that reads/sets the TLS thread pointer.
+     Currently, these are only needed if the target needs to support the
+     '__builtin_thread_pointer' and '__builtin_set_thread_pointer'
+     builtins.
+
+     The get/set patterns have a single output/input operand
+     respectively, with MODE intended to be 'Pmode'.
+
+'stack_protect_set'
+
+     This pattern, if defined, moves a 'ptr_mode' value from the memory
+     in operand 1 to the memory in operand 0 without leaving the value
+     in a register afterward.  This is to avoid leaking the value some
+     place that an attacker might use to rewrite the stack guard slot
+     after having clobbered it.
+
+     If this pattern is not defined, then a plain move pattern is
+     generated.
+
+'stack_protect_test'
+
+     This pattern, if defined, compares a 'ptr_mode' value from the
+     memory in operand 1 with the memory in operand 0 without leaving
+     the value in a register afterward and branches to operand 2 if the
+     values were equal.
+
+     If this pattern is not defined, then a plain compare pattern and
+     conditional branch pattern is used.
+
+'clear_cache'
+
+     This pattern, if defined, flushes the instruction cache for a
+     region of memory.  The region is bounded to by the Pmode pointers
+     in operand 0 inclusive and operand 1 exclusive.
+
+     If this pattern is not defined, a call to the library function
+     '__clear_cache' is used.
+
+
+File: gccint.info,  Node: Pattern Ordering,  Next: Dependent Patterns,  Prev: Standard Names,  Up: Machine Desc
+
+16.10 When the Order of Patterns Matters
+========================================
+
+Sometimes an insn can match more than one instruction pattern.  Then the
+pattern that appears first in the machine description is the one used.
+Therefore, more specific patterns (patterns that will match fewer
+things) and faster instructions (those that will produce better code
+when they do match) should usually go first in the description.
+
+ In some cases the effect of ordering the patterns can be used to hide a
+pattern when it is not valid.  For example, the 68000 has an instruction
+for converting a fullword to floating point and another for converting a
+byte to floating point.  An instruction converting an integer to
+floating point could match either one.  We put the pattern to convert
+the fullword first to make sure that one will be used rather than the
+other.  (Otherwise a large integer might be generated as a single-byte
+immediate quantity, which would not work.)  Instead of using this
+pattern ordering it would be possible to make the pattern for
+convert-a-byte smart enough to deal properly with any constant value.
+
+
+File: gccint.info,  Node: Dependent Patterns,  Next: Jump Patterns,  Prev: Pattern Ordering,  Up: Machine Desc
+
+16.11 Interdependence of Patterns
+=================================
+
+In some cases machines support instructions identical except for the
+machine mode of one or more operands.  For example, there may be
+"sign-extend halfword" and "sign-extend byte" instructions whose
+patterns are
+
+     (set (match_operand:SI 0 ...)
+          (extend:SI (match_operand:HI 1 ...)))
+
+     (set (match_operand:SI 0 ...)
+          (extend:SI (match_operand:QI 1 ...)))
+
+Constant integers do not specify a machine mode, so an instruction to
+extend a constant value could match either pattern.  The pattern it
+actually will match is the one that appears first in the file.  For
+correct results, this must be the one for the widest possible mode
+('HImode', here).  If the pattern matches the 'QImode' instruction, the
+results will be incorrect if the constant value does not actually fit
+that mode.
+
+ Such instructions to extend constants are rarely generated because they
+are optimized away, but they do occasionally happen in nonoptimized
+compilations.
+
+ If a constraint in a pattern allows a constant, the reload pass may
+replace a register with a constant permitted by the constraint in some
+cases.  Similarly for memory references.  Because of this substitution,
+you should not provide separate patterns for increment and decrement
+instructions.  Instead, they should be generated from the same pattern
+that supports register-register add insns by examining the operands and
+generating the appropriate machine instruction.
+
+
+File: gccint.info,  Node: Jump Patterns,  Next: Looping Patterns,  Prev: Dependent Patterns,  Up: Machine Desc
+
+16.12 Defining Jump Instruction Patterns
+========================================
+
+GCC does not assume anything about how the machine realizes jumps.  The
+machine description should define a single pattern, usually a
+'define_expand', which expands to all the required insns.
+
+ Usually, this would be a comparison insn to set the condition code and
+a separate branch insn testing the condition code and branching or not
+according to its value.  For many machines, however, separating compares
+and branches is limiting, which is why the more flexible approach with
+one 'define_expand' is used in GCC. The machine description becomes
+clearer for architectures that have compare-and-branch instructions but
+no condition code.  It also works better when different sets of
+comparison operators are supported by different kinds of conditional
+branches (e.g.  integer vs.  floating-point), or by conditional branches
+with respect to conditional stores.
+
+ Two separate insns are always used if the machine description
+represents a condition code register using the legacy RTL expression
+'(cc0)', and on most machines that use a separate condition code
+register (*note Condition Code::).  For machines that use '(cc0)', in
+fact, the set and use of the condition code must be separate and
+adjacent(1), thus allowing flags in 'cc_status' to be used (*note
+Condition Code::) and so that the comparison and branch insns could be
+located from each other by using the functions 'prev_cc0_setter' and
+'next_cc0_user'.
+
+ Even in this case having a single entry point for conditional branches
+is advantageous, because it handles equally well the case where a single
+comparison instruction records the results of both signed and unsigned
+comparison of the given operands (with the branch insns coming in
+distinct signed and unsigned flavors) as in the x86 or SPARC, and the
+case where there are distinct signed and unsigned compare instructions
+and only one set of conditional branch instructions as in the PowerPC.
+
+   ---------- Footnotes ----------
+
+   (1) 'note' insns can separate them, though.
+
+
+File: gccint.info,  Node: Looping Patterns,  Next: Insn Canonicalizations,  Prev: Jump Patterns,  Up: Machine Desc
+
+16.13 Defining Looping Instruction Patterns
+===========================================
+
+Some machines have special jump instructions that can be utilized to
+make loops more efficient.  A common example is the 68000 'dbra'
+instruction which performs a decrement of a register and a branch if the
+result was greater than zero.  Other machines, in particular digital
+signal processors (DSPs), have special block repeat instructions to
+provide low-overhead loop support.  For example, the TI TMS320C3x/C4x
+DSPs have a block repeat instruction that loads special registers to
+mark the top and end of a loop and to count the number of loop
+iterations.  This avoids the need for fetching and executing a
+'dbra'-like instruction and avoids pipeline stalls associated with the
+jump.
+
+ GCC has three special named patterns to support low overhead looping.
+They are 'decrement_and_branch_until_zero', 'doloop_begin', and
+'doloop_end'.  The first pattern, 'decrement_and_branch_until_zero', is
+not emitted during RTL generation but may be emitted during the
+instruction combination phase.  This requires the assistance of the loop
+optimizer, using information collected during strength reduction, to
+reverse a loop to count down to zero.  Some targets also require the
+loop optimizer to add a 'REG_NONNEG' note to indicate that the iteration
+count is always positive.  This is needed if the target performs a
+signed loop termination test.  For example, the 68000 uses a pattern
+similar to the following for its 'dbra' instruction:
+
+     (define_insn "decrement_and_branch_until_zero"
+       [(set (pc)
+             (if_then_else
+               (ge (plus:SI (match_operand:SI 0 "general_operand" "+d*am")
+                            (const_int -1))
+                   (const_int 0))
+               (label_ref (match_operand 1 "" ""))
+               (pc)))
+        (set (match_dup 0)
+             (plus:SI (match_dup 0)
+                      (const_int -1)))]
+       "find_reg_note (insn, REG_NONNEG, 0)"
+       "...")
+
+ Note that since the insn is both a jump insn and has an output, it must
+deal with its own reloads, hence the 'm' constraints.  Also note that
+since this insn is generated by the instruction combination phase
+combining two sequential insns together into an implicit parallel insn,
+the iteration counter needs to be biased by the same amount as the
+decrement operation, in this case -1.  Note that the following similar
+pattern will not be matched by the combiner.
+
+     (define_insn "decrement_and_branch_until_zero"
+       [(set (pc)
+             (if_then_else
+               (ge (match_operand:SI 0 "general_operand" "+d*am")
+                   (const_int 1))
+               (label_ref (match_operand 1 "" ""))
+               (pc)))
+        (set (match_dup 0)
+             (plus:SI (match_dup 0)
+                      (const_int -1)))]
+       "find_reg_note (insn, REG_NONNEG, 0)"
+       "...")
+
+ The other two special looping patterns, 'doloop_begin' and
+'doloop_end', are emitted by the loop optimizer for certain well-behaved
+loops with a finite number of loop iterations using information
+collected during strength reduction.
+
+ The 'doloop_end' pattern describes the actual looping instruction (or
+the implicit looping operation) and the 'doloop_begin' pattern is an
+optional companion pattern that can be used for initialization needed
+for some low-overhead looping instructions.
+
+ Note that some machines require the actual looping instruction to be
+emitted at the top of the loop (e.g., the TMS320C3x/C4x DSPs).  Emitting
+the true RTL for a looping instruction at the top of the loop can cause
+problems with flow analysis.  So instead, a dummy 'doloop' insn is
+emitted at the end of the loop.  The machine dependent reorg pass checks
+for the presence of this 'doloop' insn and then searches back to the top
+of the loop, where it inserts the true looping insn (provided there are
+no instructions in the loop which would cause problems).  Any additional
+labels can be emitted at this point.  In addition, if the desired
+special iteration counter register was not allocated, this machine
+dependent reorg pass could emit a traditional compare and jump
+instruction pair.
+
+ The essential difference between the 'decrement_and_branch_until_zero'
+and the 'doloop_end' patterns is that the loop optimizer allocates an
+additional pseudo register for the latter as an iteration counter.  This
+pseudo register cannot be used within the loop (i.e., general induction
+variables cannot be derived from it), however, in many cases the loop
+induction variable may become redundant and removed by the flow pass.
+
+
+File: gccint.info,  Node: Insn Canonicalizations,  Next: Expander Definitions,  Prev: Looping Patterns,  Up: Machine Desc
+
+16.14 Canonicalization of Instructions
+======================================
+
+There are often cases where multiple RTL expressions could represent an
+operation performed by a single machine instruction.  This situation is
+most commonly encountered with logical, branch, and multiply-accumulate
+instructions.  In such cases, the compiler attempts to convert these
+multiple RTL expressions into a single canonical form to reduce the
+number of insn patterns required.
+
+ In addition to algebraic simplifications, following canonicalizations
+are performed:
+
+   * For commutative and comparison operators, a constant is always made
+     the second operand.  If a machine only supports a constant as the
+     second operand, only patterns that match a constant in the second
+     operand need be supplied.
+
+   * For associative operators, a sequence of operators will always
+     chain to the left; for instance, only the left operand of an
+     integer 'plus' can itself be a 'plus'.  'and', 'ior', 'xor',
+     'plus', 'mult', 'smin', 'smax', 'umin', and 'umax' are associative
+     when applied to integers, and sometimes to floating-point.
+
+   * For these operators, if only one operand is a 'neg', 'not', 'mult',
+     'plus', or 'minus' expression, it will be the first operand.
+
+   * In combinations of 'neg', 'mult', 'plus', and 'minus', the 'neg'
+     operations (if any) will be moved inside the operations as far as
+     possible.  For instance, '(neg (mult A B))' is canonicalized as
+     '(mult (neg A) B)', but '(plus (mult (neg B) C) A)' is
+     canonicalized as '(minus A (mult B C))'.
+
+   * For the 'compare' operator, a constant is always the second operand
+     if the first argument is a condition code register or '(cc0)'.
+
+   * An operand of 'neg', 'not', 'mult', 'plus', or 'minus' is made the
+     first operand under the same conditions as above.
+
+   * '(ltu (plus A B) B)' is converted to '(ltu (plus A B) A)'.
+     Likewise with 'geu' instead of 'ltu'.
+
+   * '(minus X (const_int N))' is converted to '(plus X (const_int
+     -N))'.
+
+   * Within address computations (i.e., inside 'mem'), a left shift is
+     converted into the appropriate multiplication by a power of two.
+
+   * De Morgan's Law is used to move bitwise negation inside a bitwise
+     logical-and or logical-or operation.  If this results in only one
+     operand being a 'not' expression, it will be the first one.
+
+     A machine that has an instruction that performs a bitwise
+     logical-and of one operand with the bitwise negation of the other
+     should specify the pattern for that instruction as
+
+          (define_insn ""
+            [(set (match_operand:M 0 ...)
+                  (and:M (not:M (match_operand:M 1 ...))
+                               (match_operand:M 2 ...)))]
+            "..."
+            "...")
+
+     Similarly, a pattern for a "NAND" instruction should be written
+
+          (define_insn ""
+            [(set (match_operand:M 0 ...)
+                  (ior:M (not:M (match_operand:M 1 ...))
+                               (not:M (match_operand:M 2 ...))))]
+            "..."
+            "...")
+
+     In both cases, it is not necessary to include patterns for the many
+     logically equivalent RTL expressions.
+
+   * The only possible RTL expressions involving both bitwise
+     exclusive-or and bitwise negation are '(xor:M X Y)' and '(not:M
+     (xor:M X Y))'.
+
+   * The sum of three items, one of which is a constant, will only
+     appear in the form
+
+          (plus:M (plus:M X Y) CONSTANT)
+
+   * Equality comparisons of a group of bits (usually a single bit) with
+     zero will be written using 'zero_extract' rather than the
+     equivalent 'and' or 'sign_extract' operations.
+
+   * '(sign_extend:M1 (mult:M2 (sign_extend:M2 X) (sign_extend:M2 Y)))'
+     is converted to '(mult:M1 (sign_extend:M1 X) (sign_extend:M1 Y))',
+     and likewise for 'zero_extend'.
+
+   * '(sign_extend:M1 (mult:M2 (ashiftrt:M2 X S) (sign_extend:M2 Y)))'
+     is converted to '(mult:M1 (sign_extend:M1 (ashiftrt:M2 X S))
+     (sign_extend:M1 Y))', and likewise for patterns using 'zero_extend'
+     and 'lshiftrt'.  If the second operand of 'mult' is also a shift,
+     then that is extended also.  This transformation is only applied
+     when it can be proven that the original operation had sufficient
+     precision to prevent overflow.
+
+ Further canonicalization rules are defined in the function
+'commutative_operand_precedence' in 'gcc/rtlanal.c'.
+
+
+File: gccint.info,  Node: Expander Definitions,  Next: Insn Splitting,  Prev: Insn Canonicalizations,  Up: Machine Desc
+
+16.15 Defining RTL Sequences for Code Generation
+================================================
+
+On some target machines, some standard pattern names for RTL generation
+cannot be handled with single insn, but a sequence of RTL insns can
+represent them.  For these target machines, you can write a
+'define_expand' to specify how to generate the sequence of RTL.
+
+ A 'define_expand' is an RTL expression that looks almost like a
+'define_insn'; but, unlike the latter, a 'define_expand' is used only
+for RTL generation and it can produce more than one RTL insn.
+
+ A 'define_expand' RTX has four operands:
+
+   * The name.  Each 'define_expand' must have a name, since the only
+     use for it is to refer to it by name.
+
+   * The RTL template.  This is a vector of RTL expressions representing
+     a sequence of separate instructions.  Unlike 'define_insn', there
+     is no implicit surrounding 'PARALLEL'.
+
+   * The condition, a string containing a C expression.  This expression
+     is used to express how the availability of this pattern depends on
+     subclasses of target machine, selected by command-line options when
+     GCC is run.  This is just like the condition of a 'define_insn'
+     that has a standard name.  Therefore, the condition (if present)
+     may not depend on the data in the insn being matched, but only the
+     target-machine-type flags.  The compiler needs to test these
+     conditions during initialization in order to learn exactly which
+     named instructions are available in a particular run.
+
+   * The preparation statements, a string containing zero or more C
+     statements which are to be executed before RTL code is generated
+     from the RTL template.
+
+     Usually these statements prepare temporary registers for use as
+     internal operands in the RTL template, but they can also generate
+     RTL insns directly by calling routines such as 'emit_insn', etc.
+     Any such insns precede the ones that come from the RTL template.
+
+   * Optionally, a vector containing the values of attributes.  *Note
+     Insn Attributes::.
+
+ Every RTL insn emitted by a 'define_expand' must match some
+'define_insn' in the machine description.  Otherwise, the compiler will
+crash when trying to generate code for the insn or trying to optimize
+it.
+
+ The RTL template, in addition to controlling generation of RTL insns,
+also describes the operands that need to be specified when this pattern
+is used.  In particular, it gives a predicate for each operand.
+
+ A true operand, which needs to be specified in order to generate RTL
+from the pattern, should be described with a 'match_operand' in its
+first occurrence in the RTL template.  This enters information on the
+operand's predicate into the tables that record such things.  GCC uses
+the information to preload the operand into a register if that is
+required for valid RTL code.  If the operand is referred to more than
+once, subsequent references should use 'match_dup'.
+
+ The RTL template may also refer to internal "operands" which are
+temporary registers or labels used only within the sequence made by the
+'define_expand'.  Internal operands are substituted into the RTL
+template with 'match_dup', never with 'match_operand'.  The values of
+the internal operands are not passed in as arguments by the compiler
+when it requests use of this pattern.  Instead, they are computed within
+the pattern, in the preparation statements.  These statements compute
+the values and store them into the appropriate elements of 'operands' so
+that 'match_dup' can find them.
+
+ There are two special macros defined for use in the preparation
+statements: 'DONE' and 'FAIL'.  Use them with a following semicolon, as
+a statement.
+
+'DONE'
+     Use the 'DONE' macro to end RTL generation for the pattern.  The
+     only RTL insns resulting from the pattern on this occasion will be
+     those already emitted by explicit calls to 'emit_insn' within the
+     preparation statements; the RTL template will not be generated.
+
+'FAIL'
+     Make the pattern fail on this occasion.  When a pattern fails, it
+     means that the pattern was not truly available.  The calling
+     routines in the compiler will try other strategies for code
+     generation using other patterns.
+
+     Failure is currently supported only for binary (addition,
+     multiplication, shifting, etc.)  and bit-field ('extv', 'extzv',
+     and 'insv') operations.
+
+ If the preparation falls through (invokes neither 'DONE' nor 'FAIL'),
+then the 'define_expand' acts like a 'define_insn' in that the RTL
+template is used to generate the insn.
+
+ The RTL template is not used for matching, only for generating the
+initial insn list.  If the preparation statement always invokes 'DONE'
+or 'FAIL', the RTL template may be reduced to a simple list of operands,
+such as this example:
+
+     (define_expand "addsi3"
+       [(match_operand:SI 0 "register_operand" "")
+        (match_operand:SI 1 "register_operand" "")
+        (match_operand:SI 2 "register_operand" "")]
+       ""
+       "
+     {
+       handle_add (operands[0], operands[1], operands[2]);
+       DONE;
+     }")
+
+ Here is an example, the definition of left-shift for the SPUR chip:
+
+     (define_expand "ashlsi3"
+       [(set (match_operand:SI 0 "register_operand" "")
+             (ashift:SI
+               (match_operand:SI 1 "register_operand" "")
+               (match_operand:SI 2 "nonmemory_operand" "")))]
+       ""
+       "
+
+     {
+       if (GET_CODE (operands[2]) != CONST_INT
+           || (unsigned) INTVAL (operands[2]) > 3)
+         FAIL;
+     }")
+
+This example uses 'define_expand' so that it can generate an RTL insn
+for shifting when the shift-count is in the supported range of 0 to 3
+but fail in other cases where machine insns aren't available.  When it
+fails, the compiler tries another strategy using different patterns
+(such as, a library call).
+
+ If the compiler were able to handle nontrivial condition-strings in
+patterns with names, then it would be possible to use a 'define_insn' in
+that case.  Here is another case (zero-extension on the 68000) which
+makes more use of the power of 'define_expand':
+
+     (define_expand "zero_extendhisi2"
+       [(set (match_operand:SI 0 "general_operand" "")
+             (const_int 0))
+        (set (strict_low_part
+               (subreg:HI
+                 (match_dup 0)
+                 0))
+             (match_operand:HI 1 "general_operand" ""))]
+       ""
+       "operands[1] = make_safe_from (operands[1], operands[0]);")
+
+Here two RTL insns are generated, one to clear the entire output operand
+and the other to copy the input operand into its low half.  This
+sequence is incorrect if the input operand refers to [the old value of]
+the output operand, so the preparation statement makes sure this isn't
+so.  The function 'make_safe_from' copies the 'operands[1]' into a
+temporary register if it refers to 'operands[0]'.  It does this by
+emitting another RTL insn.
+
+ Finally, a third example shows the use of an internal operand.
+Zero-extension on the SPUR chip is done by 'and'-ing the result against
+a halfword mask.  But this mask cannot be represented by a 'const_int'
+because the constant value is too large to be legitimate on this
+machine.  So it must be copied into a register with 'force_reg' and then
+the register used in the 'and'.
+
+     (define_expand "zero_extendhisi2"
+       [(set (match_operand:SI 0 "register_operand" "")
+             (and:SI (subreg:SI
+                       (match_operand:HI 1 "register_operand" "")
+                       0)
+                     (match_dup 2)))]
+       ""
+       "operands[2]
+          = force_reg (SImode, GEN_INT (65535)); ")
+
+ _Note:_ If the 'define_expand' is used to serve a standard binary or
+unary arithmetic operation or a bit-field operation, then the last insn
+it generates must not be a 'code_label', 'barrier' or 'note'.  It must
+be an 'insn', 'jump_insn' or 'call_insn'.  If you don't need a real insn
+at the end, emit an insn to copy the result of the operation into
+itself.  Such an insn will generate no code, but it can avoid problems
+in the compiler.
+
+
+File: gccint.info,  Node: Insn Splitting,  Next: Including Patterns,  Prev: Expander Definitions,  Up: Machine Desc
+
+16.16 Defining How to Split Instructions
+========================================
+
+There are two cases where you should specify how to split a pattern into
+multiple insns.  On machines that have instructions requiring delay
+slots (*note Delay Slots::) or that have instructions whose output is
+not available for multiple cycles (*note Processor pipeline
+description::), the compiler phases that optimize these cases need to be
+able to move insns into one-instruction delay slots.  However, some
+insns may generate more than one machine instruction.  These insns
+cannot be placed into a delay slot.
+
+ Often you can rewrite the single insn as a list of individual insns,
+each corresponding to one machine instruction.  The disadvantage of
+doing so is that it will cause the compilation to be slower and require
+more space.  If the resulting insns are too complex, it may also
+suppress some optimizations.  The compiler splits the insn if there is a
+reason to believe that it might improve instruction or delay slot
+scheduling.
+
+ The insn combiner phase also splits putative insns.  If three insns are
+merged into one insn with a complex expression that cannot be matched by
+some 'define_insn' pattern, the combiner phase attempts to split the
+complex pattern into two insns that are recognized.  Usually it can
+break the complex pattern into two patterns by splitting out some
+subexpression.  However, in some other cases, such as performing an
+addition of a large constant in two insns on a RISC machine, the way to
+split the addition into two insns is machine-dependent.
+
+ The 'define_split' definition tells the compiler how to split a complex
+insn into several simpler insns.  It looks like this:
+
+     (define_split
+       [INSN-PATTERN]
+       "CONDITION"
+       [NEW-INSN-PATTERN-1
+        NEW-INSN-PATTERN-2
+        ...]
+       "PREPARATION-STATEMENTS")
+
+ INSN-PATTERN is a pattern that needs to be split and CONDITION is the
+final condition to be tested, as in a 'define_insn'.  When an insn
+matching INSN-PATTERN and satisfying CONDITION is found, it is replaced
+in the insn list with the insns given by NEW-INSN-PATTERN-1,
+NEW-INSN-PATTERN-2, etc.
+
+ The PREPARATION-STATEMENTS are similar to those statements that are
+specified for 'define_expand' (*note Expander Definitions::) and are
+executed before the new RTL is generated to prepare for the generated
+code or emit some insns whose pattern is not fixed.  Unlike those in
+'define_expand', however, these statements must not generate any new
+pseudo-registers.  Once reload has completed, they also must not
+allocate any space in the stack frame.
+
+ Patterns are matched against INSN-PATTERN in two different
+circumstances.  If an insn needs to be split for delay slot scheduling
+or insn scheduling, the insn is already known to be valid, which means
+that it must have been matched by some 'define_insn' and, if
+'reload_completed' is nonzero, is known to satisfy the constraints of
+that 'define_insn'.  In that case, the new insn patterns must also be
+insns that are matched by some 'define_insn' and, if 'reload_completed'
+is nonzero, must also satisfy the constraints of those definitions.
+
+ As an example of this usage of 'define_split', consider the following
+example from 'a29k.md', which splits a 'sign_extend' from 'HImode' to
+'SImode' into a pair of shift insns:
+
+     (define_split
+       [(set (match_operand:SI 0 "gen_reg_operand" "")
+             (sign_extend:SI (match_operand:HI 1 "gen_reg_operand" "")))]
+       ""
+       [(set (match_dup 0)
+             (ashift:SI (match_dup 1)
+                        (const_int 16)))
+        (set (match_dup 0)
+             (ashiftrt:SI (match_dup 0)
+                          (const_int 16)))]
+       "
+     { operands[1] = gen_lowpart (SImode, operands[1]); }")
+
+ When the combiner phase tries to split an insn pattern, it is always
+the case that the pattern is _not_ matched by any 'define_insn'.  The
+combiner pass first tries to split a single 'set' expression and then
+the same 'set' expression inside a 'parallel', but followed by a
+'clobber' of a pseudo-reg to use as a scratch register.  In these cases,
+the combiner expects exactly two new insn patterns to be generated.  It
+will verify that these patterns match some 'define_insn' definitions, so
+you need not do this test in the 'define_split' (of course, there is no
+point in writing a 'define_split' that will never produce insns that
+match).
+
+ Here is an example of this use of 'define_split', taken from
+'rs6000.md':
+
+     (define_split
+       [(set (match_operand:SI 0 "gen_reg_operand" "")
+             (plus:SI (match_operand:SI 1 "gen_reg_operand" "")
+                      (match_operand:SI 2 "non_add_cint_operand" "")))]
+       ""
+       [(set (match_dup 0) (plus:SI (match_dup 1) (match_dup 3)))
+        (set (match_dup 0) (plus:SI (match_dup 0) (match_dup 4)))]
+     "
+     {
+       int low = INTVAL (operands[2]) & 0xffff;
+       int high = (unsigned) INTVAL (operands[2]) >> 16;
+
+       if (low & 0x8000)
+         high++, low |= 0xffff0000;
+
+       operands[3] = GEN_INT (high << 16);
+       operands[4] = GEN_INT (low);
+     }")
+
+ Here the predicate 'non_add_cint_operand' matches any 'const_int' that
+is _not_ a valid operand of a single add insn.  The add with the smaller
+displacement is written so that it can be substituted into the address
+of a subsequent operation.
+
+ An example that uses a scratch register, from the same file, generates
+an equality comparison of a register and a large constant:
+
+     (define_split
+       [(set (match_operand:CC 0 "cc_reg_operand" "")
+             (compare:CC (match_operand:SI 1 "gen_reg_operand" "")
+                         (match_operand:SI 2 "non_short_cint_operand" "")))
+        (clobber (match_operand:SI 3 "gen_reg_operand" ""))]
+       "find_single_use (operands[0], insn, 0)
+        && (GET_CODE (*find_single_use (operands[0], insn, 0)) == EQ
+            || GET_CODE (*find_single_use (operands[0], insn, 0)) == NE)"
+       [(set (match_dup 3) (xor:SI (match_dup 1) (match_dup 4)))
+        (set (match_dup 0) (compare:CC (match_dup 3) (match_dup 5)))]
+       "
+     {
+       /* Get the constant we are comparing against, C, and see what it
+          looks like sign-extended to 16 bits.  Then see what constant
+          could be XOR'ed with C to get the sign-extended value.  */
+
+       int c = INTVAL (operands[2]);
+       int sextc = (c << 16) >> 16;
+       int xorv = c ^ sextc;
+
+       operands[4] = GEN_INT (xorv);
+       operands[5] = GEN_INT (sextc);
+     }")
+
+ To avoid confusion, don't write a single 'define_split' that accepts
+some insns that match some 'define_insn' as well as some insns that
+don't.  Instead, write two separate 'define_split' definitions, one for
+the insns that are valid and one for the insns that are not valid.
+
+ The splitter is allowed to split jump instructions into sequence of
+jumps or create new jumps in while splitting non-jump instructions.  As
+the central flowgraph and branch prediction information needs to be
+updated, several restriction apply.
+
+ Splitting of jump instruction into sequence that over by another jump
+instruction is always valid, as compiler expect identical behavior of
+new jump.  When new sequence contains multiple jump instructions or new
+labels, more assistance is needed.  Splitter is required to create only
+unconditional jumps, or simple conditional jump instructions.
+Additionally it must attach a 'REG_BR_PROB' note to each conditional
+jump.  A global variable 'split_branch_probability' holds the
+probability of the original branch in case it was a simple conditional
+jump, -1 otherwise.  To simplify recomputing of edge frequencies, the
+new sequence is required to have only forward jumps to the newly created
+labels.
+
+ For the common case where the pattern of a define_split exactly matches
+the pattern of a define_insn, use 'define_insn_and_split'.  It looks
+like this:
+
+     (define_insn_and_split
+       [INSN-PATTERN]
+       "CONDITION"
+       "OUTPUT-TEMPLATE"
+       "SPLIT-CONDITION"
+       [NEW-INSN-PATTERN-1
+        NEW-INSN-PATTERN-2
+        ...]
+       "PREPARATION-STATEMENTS"
+       [INSN-ATTRIBUTES])
+
+ INSN-PATTERN, CONDITION, OUTPUT-TEMPLATE, and INSN-ATTRIBUTES are used
+as in 'define_insn'.  The NEW-INSN-PATTERN vector and the
+PREPARATION-STATEMENTS are used as in a 'define_split'.  The
+SPLIT-CONDITION is also used as in 'define_split', with the additional
+behavior that if the condition starts with '&&', the condition used for
+the split will be the constructed as a logical "and" of the split
+condition with the insn condition.  For example, from i386.md:
+
+     (define_insn_and_split "zero_extendhisi2_and"
+       [(set (match_operand:SI 0 "register_operand" "=r")
+          (zero_extend:SI (match_operand:HI 1 "register_operand" "0")))
+        (clobber (reg:CC 17))]
+       "TARGET_ZERO_EXTEND_WITH_AND && !optimize_size"
+       "#"
+       "&& reload_completed"
+       [(parallel [(set (match_dup 0)
+                        (and:SI (match_dup 0) (const_int 65535)))
+                   (clobber (reg:CC 17))])]
+       ""
+       [(set_attr "type" "alu1")])
+
+ In this case, the actual split condition will be
+'TARGET_ZERO_EXTEND_WITH_AND && !optimize_size && reload_completed'.
+
+ The 'define_insn_and_split' construction provides exactly the same
+functionality as two separate 'define_insn' and 'define_split' patterns.
+It exists for compactness, and as a maintenance tool to prevent having
+to ensure the two patterns' templates match.
+
+
+File: gccint.info,  Node: Including Patterns,  Next: Peephole Definitions,  Prev: Insn Splitting,  Up: Machine Desc
+
+16.17 Including Patterns in Machine Descriptions.
+=================================================
+
+The 'include' pattern tells the compiler tools where to look for
+patterns that are in files other than in the file '.md'.  This is used
+only at build time and there is no preprocessing allowed.
+
+ It looks like:
+
+
+     (include
+       PATHNAME)
+
+ For example:
+
+
+     (include "filestuff")
+
+ Where PATHNAME is a string that specifies the location of the file,
+specifies the include file to be in 'gcc/config/target/filestuff'.  The
+directory 'gcc/config/target' is regarded as the default directory.
+
+ Machine descriptions may be split up into smaller more manageable
+subsections and placed into subdirectories.
+
+ By specifying:
+
+
+     (include "BOGUS/filestuff")
+
+ the include file is specified to be in
+'gcc/config/TARGET/BOGUS/filestuff'.
+
+ Specifying an absolute path for the include file such as;
+
+     (include "/u2/BOGUS/filestuff")
+
+ is permitted but is not encouraged.
+
+16.17.1 RTL Generation Tool Options for Directory Search
+--------------------------------------------------------
+
+The '-IDIR' option specifies directories to search for machine
+descriptions.  For example:
+
+
+     genrecog -I/p1/abc/proc1 -I/p2/abcd/pro2 target.md
+
+ Add the directory DIR to the head of the list of directories to be
+searched for header files.  This can be used to override a system
+machine definition file, substituting your own version, since these
+directories are searched before the default machine description file
+directories.  If you use more than one '-I' option, the directories are
+scanned in left-to-right order; the standard default directory come
+after.
+
+
+File: gccint.info,  Node: Peephole Definitions,  Next: Insn Attributes,  Prev: Including Patterns,  Up: Machine Desc
+
+16.18 Machine-Specific Peephole Optimizers
+==========================================
+
+In addition to instruction patterns the 'md' file may contain
+definitions of machine-specific peephole optimizations.
+
+ The combiner does not notice certain peephole optimizations when the
+data flow in the program does not suggest that it should try them.  For
+example, sometimes two consecutive insns related in purpose can be
+combined even though the second one does not appear to use a register
+computed in the first one.  A machine-specific peephole optimizer can
+detect such opportunities.
+
+ There are two forms of peephole definitions that may be used.  The
+original 'define_peephole' is run at assembly output time to match insns
+and substitute assembly text.  Use of 'define_peephole' is deprecated.
+
+ A newer 'define_peephole2' matches insns and substitutes new insns.
+The 'peephole2' pass is run after register allocation but before
+scheduling, which may result in much better code for targets that do
+scheduling.
+
+* Menu:
+
+* define_peephole::     RTL to Text Peephole Optimizers
+* define_peephole2::    RTL to RTL Peephole Optimizers
+
+
+File: gccint.info,  Node: define_peephole,  Next: define_peephole2,  Up: Peephole Definitions
+
+16.18.1 RTL to Text Peephole Optimizers
+---------------------------------------
+
+A definition looks like this:
+
+     (define_peephole
+       [INSN-PATTERN-1
+        INSN-PATTERN-2
+        ...]
+       "CONDITION"
+       "TEMPLATE"
+       "OPTIONAL-INSN-ATTRIBUTES")
+
+The last string operand may be omitted if you are not using any
+machine-specific information in this machine description.  If present,
+it must obey the same rules as in a 'define_insn'.
+
+ In this skeleton, INSN-PATTERN-1 and so on are patterns to match
+consecutive insns.  The optimization applies to a sequence of insns when
+INSN-PATTERN-1 matches the first one, INSN-PATTERN-2 matches the next,
+and so on.
+
+ Each of the insns matched by a peephole must also match a
+'define_insn'.  Peepholes are checked only at the last stage just before
+code generation, and only optionally.  Therefore, any insn which would
+match a peephole but no 'define_insn' will cause a crash in code
+generation in an unoptimized compilation, or at various optimization
+stages.
+
+ The operands of the insns are matched with 'match_operands',
+'match_operator', and 'match_dup', as usual.  What is not usual is that
+the operand numbers apply to all the insn patterns in the definition.
+So, you can check for identical operands in two insns by using
+'match_operand' in one insn and 'match_dup' in the other.
+
+ The operand constraints used in 'match_operand' patterns do not have
+any direct effect on the applicability of the peephole, but they will be
+validated afterward, so make sure your constraints are general enough to
+apply whenever the peephole matches.  If the peephole matches but the
+constraints are not satisfied, the compiler will crash.
+
+ It is safe to omit constraints in all the operands of the peephole; or
+you can write constraints which serve as a double-check on the criteria
+previously tested.
+
+ Once a sequence of insns matches the patterns, the CONDITION is
+checked.  This is a C expression which makes the final decision whether
+to perform the optimization (we do so if the expression is nonzero).  If
+CONDITION is omitted (in other words, the string is empty) then the
+optimization is applied to every sequence of insns that matches the
+patterns.
+
+ The defined peephole optimizations are applied after register
+allocation is complete.  Therefore, the peephole definition can check
+which operands have ended up in which kinds of registers, just by
+looking at the operands.
+
+ The way to refer to the operands in CONDITION is to write 'operands[I]'
+for operand number I (as matched by '(match_operand I ...)').  Use the
+variable 'insn' to refer to the last of the insns being matched; use
+'prev_active_insn' to find the preceding insns.
+
+ When optimizing computations with intermediate results, you can use
+CONDITION to match only when the intermediate results are not used
+elsewhere.  Use the C expression 'dead_or_set_p (INSN, OP)', where INSN
+is the insn in which you expect the value to be used for the last time
+(from the value of 'insn', together with use of 'prev_nonnote_insn'),
+and OP is the intermediate value (from 'operands[I]').
+
+ Applying the optimization means replacing the sequence of insns with
+one new insn.  The TEMPLATE controls ultimate output of assembler code
+for this combined insn.  It works exactly like the template of a
+'define_insn'.  Operand numbers in this template are the same ones used
+in matching the original sequence of insns.
+
+ The result of a defined peephole optimizer does not need to match any
+of the insn patterns in the machine description; it does not even have
+an opportunity to match them.  The peephole optimizer definition itself
+serves as the insn pattern to control how the insn is output.
+
+ Defined peephole optimizers are run as assembler code is being output,
+so the insns they produce are never combined or rearranged in any way.
+
+ Here is an example, taken from the 68000 machine description:
+
+     (define_peephole
+       [(set (reg:SI 15) (plus:SI (reg:SI 15) (const_int 4)))
+        (set (match_operand:DF 0 "register_operand" "=f")
+             (match_operand:DF 1 "register_operand" "ad"))]
+       "FP_REG_P (operands[0]) && ! FP_REG_P (operands[1])"
+     {
+       rtx xoperands[2];
+       xoperands[1] = gen_rtx_REG (SImode, REGNO (operands[1]) + 1);
+     #ifdef MOTOROLA
+       output_asm_insn ("move.l %1,(sp)", xoperands);
+       output_asm_insn ("move.l %1,-(sp)", operands);
+       return "fmove.d (sp)+,%0";
+     #else
+       output_asm_insn ("movel %1,sp@", xoperands);
+       output_asm_insn ("movel %1,sp@-", operands);
+       return "fmoved sp@+,%0";
+     #endif
+     })
+
+ The effect of this optimization is to change
+
+     jbsr _foobar
+     addql #4,sp
+     movel d1,sp@-
+     movel d0,sp@-
+     fmoved sp@+,fp0
+
+into
+
+     jbsr _foobar
+     movel d1,sp@
+     movel d0,sp@-
+     fmoved sp@+,fp0
+
+ INSN-PATTERN-1 and so on look _almost_ like the second operand of
+'define_insn'.  There is one important difference: the second operand of
+'define_insn' consists of one or more RTX's enclosed in square brackets.
+Usually, there is only one: then the same action can be written as an
+element of a 'define_peephole'.  But when there are multiple actions in
+a 'define_insn', they are implicitly enclosed in a 'parallel'.  Then you
+must explicitly write the 'parallel', and the square brackets within it,
+in the 'define_peephole'.  Thus, if an insn pattern looks like this,
+
+     (define_insn "divmodsi4"
+       [(set (match_operand:SI 0 "general_operand" "=d")
+             (div:SI (match_operand:SI 1 "general_operand" "0")
+                     (match_operand:SI 2 "general_operand" "dmsK")))
+        (set (match_operand:SI 3 "general_operand" "=d")
+             (mod:SI (match_dup 1) (match_dup 2)))]
+       "TARGET_68020"
+       "divsl%.l %2,%3:%0")
+
+then the way to mention this insn in a peephole is as follows:
+
+     (define_peephole
+       [...
+        (parallel
+         [(set (match_operand:SI 0 "general_operand" "=d")
+               (div:SI (match_operand:SI 1 "general_operand" "0")
+                       (match_operand:SI 2 "general_operand" "dmsK")))
+          (set (match_operand:SI 3 "general_operand" "=d")
+               (mod:SI (match_dup 1) (match_dup 2)))])
+        ...]
+       ...)
+
+
+File: gccint.info,  Node: define_peephole2,  Prev: define_peephole,  Up: Peephole Definitions
+
+16.18.2 RTL to RTL Peephole Optimizers
+--------------------------------------
+
+The 'define_peephole2' definition tells the compiler how to substitute
+one sequence of instructions for another sequence, what additional
+scratch registers may be needed and what their lifetimes must be.
+
+     (define_peephole2
+       [INSN-PATTERN-1
+        INSN-PATTERN-2
+        ...]
+       "CONDITION"
+       [NEW-INSN-PATTERN-1
+        NEW-INSN-PATTERN-2
+        ...]
+       "PREPARATION-STATEMENTS")
+
+ The definition is almost identical to 'define_split' (*note Insn
+Splitting::) except that the pattern to match is not a single
+instruction, but a sequence of instructions.
+
+ It is possible to request additional scratch registers for use in the
+output template.  If appropriate registers are not free, the pattern
+will simply not match.
+
+ Scratch registers are requested with a 'match_scratch' pattern at the
+top level of the input pattern.  The allocated register (initially) will
+be dead at the point requested within the original sequence.  If the
+scratch is used at more than a single point, a 'match_dup' pattern at
+the top level of the input pattern marks the last position in the input
+sequence at which the register must be available.
+
+ Here is an example from the IA-32 machine description:
+
+     (define_peephole2
+       [(match_scratch:SI 2 "r")
+        (parallel [(set (match_operand:SI 0 "register_operand" "")
+                        (match_operator:SI 3 "arith_or_logical_operator"
+                          [(match_dup 0)
+                           (match_operand:SI 1 "memory_operand" "")]))
+                   (clobber (reg:CC 17))])]
+       "! optimize_size && ! TARGET_READ_MODIFY"
+       [(set (match_dup 2) (match_dup 1))
+        (parallel [(set (match_dup 0)
+                        (match_op_dup 3 [(match_dup 0) (match_dup 2)]))
+                   (clobber (reg:CC 17))])]
+       "")
+
+This pattern tries to split a load from its use in the hopes that we'll
+be able to schedule around the memory load latency.  It allocates a
+single 'SImode' register of class 'GENERAL_REGS' ('"r"') that needs to
+be live only at the point just before the arithmetic.
+
+ A real example requiring extended scratch lifetimes is harder to come
+by, so here's a silly made-up example:
+
+     (define_peephole2
+       [(match_scratch:SI 4 "r")
+        (set (match_operand:SI 0 "" "") (match_operand:SI 1 "" ""))
+        (set (match_operand:SI 2 "" "") (match_dup 1))
+        (match_dup 4)
+        (set (match_operand:SI 3 "" "") (match_dup 1))]
+       "/* determine 1 does not overlap 0 and 2 */"
+       [(set (match_dup 4) (match_dup 1))
+        (set (match_dup 0) (match_dup 4))
+        (set (match_dup 2) (match_dup 4))
+        (set (match_dup 3) (match_dup 4))]
+       "")
+
+If we had not added the '(match_dup 4)' in the middle of the input
+sequence, it might have been the case that the register we chose at the
+beginning of the sequence is killed by the first or second 'set'.
+
+
+File: gccint.info,  Node: Insn Attributes,  Next: Conditional Execution,  Prev: Peephole Definitions,  Up: Machine Desc
+
+16.19 Instruction Attributes
+============================
+
+In addition to describing the instruction supported by the target
+machine, the 'md' file also defines a group of "attributes" and a set of
+values for each.  Every generated insn is assigned a value for each
+attribute.  One possible attribute would be the effect that the insn has
+on the machine's condition code.  This attribute can then be used by
+'NOTICE_UPDATE_CC' to track the condition codes.
+
+* Menu:
+
+* Defining Attributes:: Specifying attributes and their values.
+* Expressions::         Valid expressions for attribute values.
+* Tagging Insns::       Assigning attribute values to insns.
+* Attr Example::        An example of assigning attributes.
+* Insn Lengths::        Computing the length of insns.
+* Constant Attributes:: Defining attributes that are constant.
+* Mnemonic Attribute::  Obtain the instruction mnemonic as attribute value.
+* Delay Slots::         Defining delay slots required for a machine.
+* Processor pipeline description:: Specifying information for insn scheduling.
+
+
+File: gccint.info,  Node: Defining Attributes,  Next: Expressions,  Up: Insn Attributes
+
+16.19.1 Defining Attributes and their Values
+--------------------------------------------
+
+The 'define_attr' expression is used to define each attribute required
+by the target machine.  It looks like:
+
+     (define_attr NAME LIST-OF-VALUES DEFAULT)
+
+ NAME is a string specifying the name of the attribute being defined.
+Some attributes are used in a special way by the rest of the compiler.
+The 'enabled' attribute can be used to conditionally enable or disable
+insn alternatives (*note Disable Insn Alternatives::).  The 'predicable'
+attribute, together with a suitable 'define_cond_exec' (*note
+Conditional Execution::), can be used to automatically generate
+conditional variants of instruction patterns.  The 'mnemonic' attribute
+can be used to check for the instruction mnemonic (*note Mnemonic
+Attribute::).  The compiler internally uses the names 'ce_enabled' and
+'nonce_enabled', so they should not be used elsewhere as alternative
+names.
+
+ LIST-OF-VALUES is either a string that specifies a comma-separated list
+of values that can be assigned to the attribute, or a null string to
+indicate that the attribute takes numeric values.
+
+ DEFAULT is an attribute expression that gives the value of this
+attribute for insns that match patterns whose definition does not
+include an explicit value for this attribute.  *Note Attr Example::, for
+more information on the handling of defaults.  *Note Constant
+Attributes::, for information on attributes that do not depend on any
+particular insn.
+
+ For each defined attribute, a number of definitions are written to the
+'insn-attr.h' file.  For cases where an explicit set of values is
+specified for an attribute, the following are defined:
+
+   * A '#define' is written for the symbol 'HAVE_ATTR_NAME'.
+
+   * An enumerated class is defined for 'attr_NAME' with elements of the
+     form 'UPPER-NAME_UPPER-VALUE' where the attribute name and value
+     are first converted to uppercase.
+
+   * A function 'get_attr_NAME' is defined that is passed an insn and
+     returns the attribute value for that insn.
+
+ For example, if the following is present in the 'md' file:
+
+     (define_attr "type" "branch,fp,load,store,arith" ...)
+
+the following lines will be written to the file 'insn-attr.h'.
+
+     #define HAVE_ATTR_type 1
+     enum attr_type {TYPE_BRANCH, TYPE_FP, TYPE_LOAD,
+                      TYPE_STORE, TYPE_ARITH};
+     extern enum attr_type get_attr_type ();
+
+ If the attribute takes numeric values, no 'enum' type will be defined
+and the function to obtain the attribute's value will return 'int'.
+
+ There are attributes which are tied to a specific meaning.  These
+attributes are not free to use for other purposes:
+
+'length'
+     The 'length' attribute is used to calculate the length of emitted
+     code chunks.  This is especially important when verifying branch
+     distances.  *Note Insn Lengths::.
+
+'enabled'
+     The 'enabled' attribute can be defined to prevent certain
+     alternatives of an insn definition from being used during code
+     generation.  *Note Disable Insn Alternatives::.
+
+'mnemonic'
+     The 'mnemonic' attribute can be defined to implement instruction
+     specific checks in e.g.  the pipeline description.  *Note Mnemonic
+     Attribute::.
+
+ For each of these special attributes, the corresponding
+'HAVE_ATTR_NAME' '#define' is also written when the attribute is not
+defined; in that case, it is defined as '0'.
+
+ Another way of defining an attribute is to use:
+
+     (define_enum_attr "ATTR" "ENUM" DEFAULT)
+
+ This works in just the same way as 'define_attr', except that the list
+of values is taken from a separate enumeration called ENUM (*note
+define_enum::).  This form allows you to use the same list of values for
+several attributes without having to repeat the list each time.  For
+example:
+
+     (define_enum "processor" [
+       model_a
+       model_b
+       ...
+     ])
+     (define_enum_attr "arch" "processor"
+       (const (symbol_ref "target_arch")))
+     (define_enum_attr "tune" "processor"
+       (const (symbol_ref "target_tune")))
+
+ defines the same attributes as:
+
+     (define_attr "arch" "model_a,model_b,..."
+       (const (symbol_ref "target_arch")))
+     (define_attr "tune" "model_a,model_b,..."
+       (const (symbol_ref "target_tune")))
+
+ but without duplicating the processor list.  The second example defines
+two separate C enums ('attr_arch' and 'attr_tune') whereas the first
+defines a single C enum ('processor').
+
+
+File: gccint.info,  Node: Expressions,  Next: Tagging Insns,  Prev: Defining Attributes,  Up: Insn Attributes
+
+16.19.2 Attribute Expressions
+-----------------------------
+
+RTL expressions used to define attributes use the codes described above
+plus a few specific to attribute definitions, to be discussed below.
+Attribute value expressions must have one of the following forms:
+
+'(const_int I)'
+     The integer I specifies the value of a numeric attribute.  I must
+     be non-negative.
+
+     The value of a numeric attribute can be specified either with a
+     'const_int', or as an integer represented as a string in
+     'const_string', 'eq_attr' (see below), 'attr', 'symbol_ref', simple
+     arithmetic expressions, and 'set_attr' overrides on specific
+     instructions (*note Tagging Insns::).
+
+'(const_string VALUE)'
+     The string VALUE specifies a constant attribute value.  If VALUE is
+     specified as '"*"', it means that the default value of the
+     attribute is to be used for the insn containing this expression.
+     '"*"' obviously cannot be used in the DEFAULT expression of a
+     'define_attr'.
+
+     If the attribute whose value is being specified is numeric, VALUE
+     must be a string containing a non-negative integer (normally
+     'const_int' would be used in this case).  Otherwise, it must
+     contain one of the valid values for the attribute.
+
+'(if_then_else TEST TRUE-VALUE FALSE-VALUE)'
+     TEST specifies an attribute test, whose format is defined below.
+     The value of this expression is TRUE-VALUE if TEST is true,
+     otherwise it is FALSE-VALUE.
+
+'(cond [TEST1 VALUE1 ...] DEFAULT)'
+     The first operand of this expression is a vector containing an even
+     number of expressions and consisting of pairs of TEST and VALUE
+     expressions.  The value of the 'cond' expression is that of the
+     VALUE corresponding to the first true TEST expression.  If none of
+     the TEST expressions are true, the value of the 'cond' expression
+     is that of the DEFAULT expression.
+
+ TEST expressions can have one of the following forms:
+
+'(const_int I)'
+     This test is true if I is nonzero and false otherwise.
+
+'(not TEST)'
+'(ior TEST1 TEST2)'
+'(and TEST1 TEST2)'
+     These tests are true if the indicated logical function is true.
+
+'(match_operand:M N PRED CONSTRAINTS)'
+     This test is true if operand N of the insn whose attribute value is
+     being determined has mode M (this part of the test is ignored if M
+     is 'VOIDmode') and the function specified by the string PRED
+     returns a nonzero value when passed operand N and mode M (this part
+     of the test is ignored if PRED is the null string).
+
+     The CONSTRAINTS operand is ignored and should be the null string.
+
+'(match_test C-EXPR)'
+     The test is true if C expression C-EXPR is true.  In non-constant
+     attributes, C-EXPR has access to the following variables:
+
+     INSN
+          The rtl instruction under test.
+     WHICH_ALTERNATIVE
+          The 'define_insn' alternative that INSN matches.  *Note Output
+          Statement::.
+     OPERANDS
+          An array of INSN's rtl operands.
+
+     C-EXPR behaves like the condition in a C 'if' statement, so there
+     is no need to explicitly convert the expression into a boolean 0 or
+     1 value.  For example, the following two tests are equivalent:
+
+          (match_test "x & 2")
+          (match_test "(x & 2) != 0")
+
+'(le ARITH1 ARITH2)'
+'(leu ARITH1 ARITH2)'
+'(lt ARITH1 ARITH2)'
+'(ltu ARITH1 ARITH2)'
+'(gt ARITH1 ARITH2)'
+'(gtu ARITH1 ARITH2)'
+'(ge ARITH1 ARITH2)'
+'(geu ARITH1 ARITH2)'
+'(ne ARITH1 ARITH2)'
+'(eq ARITH1 ARITH2)'
+     These tests are true if the indicated comparison of the two
+     arithmetic expressions is true.  Arithmetic expressions are formed
+     with 'plus', 'minus', 'mult', 'div', 'mod', 'abs', 'neg', 'and',
+     'ior', 'xor', 'not', 'ashift', 'lshiftrt', and 'ashiftrt'
+     expressions.
+
+     'const_int' and 'symbol_ref' are always valid terms (*note Insn
+     Lengths::,for additional forms).  'symbol_ref' is a string denoting
+     a C expression that yields an 'int' when evaluated by the
+     'get_attr_...' routine.  It should normally be a global variable.
+
+'(eq_attr NAME VALUE)'
+     NAME is a string specifying the name of an attribute.
+
+     VALUE is a string that is either a valid value for attribute NAME,
+     a comma-separated list of values, or '!' followed by a value or
+     list.  If VALUE does not begin with a '!', this test is true if the
+     value of the NAME attribute of the current insn is in the list
+     specified by VALUE.  If VALUE begins with a '!', this test is true
+     if the attribute's value is _not_ in the specified list.
+
+     For example,
+
+          (eq_attr "type" "load,store")
+
+     is equivalent to
+
+          (ior (eq_attr "type" "load") (eq_attr "type" "store"))
+
+     If NAME specifies an attribute of 'alternative', it refers to the
+     value of the compiler variable 'which_alternative' (*note Output
+     Statement::) and the values must be small integers.  For example,
+
+          (eq_attr "alternative" "2,3")
+
+     is equivalent to
+
+          (ior (eq (symbol_ref "which_alternative") (const_int 2))
+               (eq (symbol_ref "which_alternative") (const_int 3)))
+
+     Note that, for most attributes, an 'eq_attr' test is simplified in
+     cases where the value of the attribute being tested is known for
+     all insns matching a particular pattern.  This is by far the most
+     common case.
+
+'(attr_flag NAME)'
+     The value of an 'attr_flag' expression is true if the flag
+     specified by NAME is true for the 'insn' currently being scheduled.
+
+     NAME is a string specifying one of a fixed set of flags to test.
+     Test the flags 'forward' and 'backward' to determine the direction
+     of a conditional branch.
+
+     This example describes a conditional branch delay slot which can be
+     nullified for forward branches that are taken (annul-true) or for
+     backward branches which are not taken (annul-false).
+
+          (define_delay (eq_attr "type" "cbranch")
+            [(eq_attr "in_branch_delay" "true")
+             (and (eq_attr "in_branch_delay" "true")
+                  (attr_flag "forward"))
+             (and (eq_attr "in_branch_delay" "true")
+                  (attr_flag "backward"))])
+
+     The 'forward' and 'backward' flags are false if the current 'insn'
+     being scheduled is not a conditional branch.
+
+     'attr_flag' is only used during delay slot scheduling and has no
+     meaning to other passes of the compiler.
+
+'(attr NAME)'
+     The value of another attribute is returned.  This is most useful
+     for numeric attributes, as 'eq_attr' and 'attr_flag' produce more
+     efficient code for non-numeric attributes.
+
+
+File: gccint.info,  Node: Tagging Insns,  Next: Attr Example,  Prev: Expressions,  Up: Insn Attributes
+
+16.19.3 Assigning Attribute Values to Insns
+-------------------------------------------
+
+The value assigned to an attribute of an insn is primarily determined by
+which pattern is matched by that insn (or which 'define_peephole'
+generated it).  Every 'define_insn' and 'define_peephole' can have an
+optional last argument to specify the values of attributes for matching
+insns.  The value of any attribute not specified in a particular insn is
+set to the default value for that attribute, as specified in its
+'define_attr'.  Extensive use of default values for attributes permits
+the specification of the values for only one or two attributes in the
+definition of most insn patterns, as seen in the example in the next
+section.
+
+ The optional last argument of 'define_insn' and 'define_peephole' is a
+vector of expressions, each of which defines the value for a single
+attribute.  The most general way of assigning an attribute's value is to
+use a 'set' expression whose first operand is an 'attr' expression
+giving the name of the attribute being set.  The second operand of the
+'set' is an attribute expression (*note Expressions::) giving the value
+of the attribute.
+
+ When the attribute value depends on the 'alternative' attribute (i.e.,
+which is the applicable alternative in the constraint of the insn), the
+'set_attr_alternative' expression can be used.  It allows the
+specification of a vector of attribute expressions, one for each
+alternative.
+
+ When the generality of arbitrary attribute expressions is not required,
+the simpler 'set_attr' expression can be used, which allows specifying a
+string giving either a single attribute value or a list of attribute
+values, one for each alternative.
+
+ The form of each of the above specifications is shown below.  In each
+case, NAME is a string specifying the attribute to be set.
+
+'(set_attr NAME VALUE-STRING)'
+     VALUE-STRING is either a string giving the desired attribute value,
+     or a string containing a comma-separated list giving the values for
+     succeeding alternatives.  The number of elements must match the
+     number of alternatives in the constraint of the insn pattern.
+
+     Note that it may be useful to specify '*' for some alternative, in
+     which case the attribute will assume its default value for insns
+     matching that alternative.
+
+'(set_attr_alternative NAME [VALUE1 VALUE2 ...])'
+     Depending on the alternative of the insn, the value will be one of
+     the specified values.  This is a shorthand for using a 'cond' with
+     tests on the 'alternative' attribute.
+
+'(set (attr NAME) VALUE)'
+     The first operand of this 'set' must be the special RTL expression
+     'attr', whose sole operand is a string giving the name of the
+     attribute being set.  VALUE is the value of the attribute.
+
+ The following shows three different ways of representing the same
+attribute value specification:
+
+     (set_attr "type" "load,store,arith")
+
+     (set_attr_alternative "type"
+                           [(const_string "load") (const_string "store")
+                            (const_string "arith")])
+
+     (set (attr "type")
+          (cond [(eq_attr "alternative" "1") (const_string "load")
+                 (eq_attr "alternative" "2") (const_string "store")]
+                (const_string "arith")))
+
+ The 'define_asm_attributes' expression provides a mechanism to specify
+the attributes assigned to insns produced from an 'asm' statement.  It
+has the form:
+
+     (define_asm_attributes [ATTR-SETS])
+
+where ATTR-SETS is specified the same as for both the 'define_insn' and
+the 'define_peephole' expressions.
+
+ These values will typically be the "worst case" attribute values.  For
+example, they might indicate that the condition code will be clobbered.
+
+ A specification for a 'length' attribute is handled specially.  The way
+to compute the length of an 'asm' insn is to multiply the length
+specified in the expression 'define_asm_attributes' by the number of
+machine instructions specified in the 'asm' statement, determined by
+counting the number of semicolons and newlines in the string.
+Therefore, the value of the 'length' attribute specified in a
+'define_asm_attributes' should be the maximum possible length of a
+single machine instruction.
+
+
+File: gccint.info,  Node: Attr Example,  Next: Insn Lengths,  Prev: Tagging Insns,  Up: Insn Attributes
+
+16.19.4 Example of Attribute Specifications
+-------------------------------------------
+
+The judicious use of defaulting is important in the efficient use of
+insn attributes.  Typically, insns are divided into "types" and an
+attribute, customarily called 'type', is used to represent this value.
+This attribute is normally used only to define the default value for
+other attributes.  An example will clarify this usage.
+
+ Assume we have a RISC machine with a condition code and in which only
+full-word operations are performed in registers.  Let us assume that we
+can divide all insns into loads, stores, (integer) arithmetic
+operations, floating point operations, and branches.
+
+ Here we will concern ourselves with determining the effect of an insn
+on the condition code and will limit ourselves to the following possible
+effects: The condition code can be set unpredictably (clobbered), not be
+changed, be set to agree with the results of the operation, or only
+changed if the item previously set into the condition code has been
+modified.
+
+ Here is part of a sample 'md' file for such a machine:
+
+     (define_attr "type" "load,store,arith,fp,branch" (const_string "arith"))
+
+     (define_attr "cc" "clobber,unchanged,set,change0"
+                  (cond [(eq_attr "type" "load")
+                             (const_string "change0")
+                         (eq_attr "type" "store,branch")
+                             (const_string "unchanged")
+                         (eq_attr "type" "arith")
+                             (if_then_else (match_operand:SI 0 "" "")
+                                           (const_string "set")
+                                           (const_string "clobber"))]
+                        (const_string "clobber")))
+
+     (define_insn ""
+       [(set (match_operand:SI 0 "general_operand" "=r,r,m")
+             (match_operand:SI 1 "general_operand" "r,m,r"))]
+       ""
+       "@
+        move %0,%1
+        load %0,%1
+        store %0,%1"
+       [(set_attr "type" "arith,load,store")])
+
+ Note that we assume in the above example that arithmetic operations
+performed on quantities smaller than a machine word clobber the
+condition code since they will set the condition code to a value
+corresponding to the full-word result.
+
+
+File: gccint.info,  Node: Insn Lengths,  Next: Constant Attributes,  Prev: Attr Example,  Up: Insn Attributes
+
+16.19.5 Computing the Length of an Insn
+---------------------------------------
+
+For many machines, multiple types of branch instructions are provided,
+each for different length branch displacements.  In most cases, the
+assembler will choose the correct instruction to use.  However, when the
+assembler cannot do so, GCC can when a special attribute, the 'length'
+attribute, is defined.  This attribute must be defined to have numeric
+values by specifying a null string in its 'define_attr'.
+
+ In the case of the 'length' attribute, two additional forms of
+arithmetic terms are allowed in test expressions:
+
+'(match_dup N)'
+     This refers to the address of operand N of the current insn, which
+     must be a 'label_ref'.
+
+'(pc)'
+     This refers to the address of the _current_ insn.  It might have
+     been more consistent with other usage to make this the address of
+     the _next_ insn but this would be confusing because the length of
+     the current insn is to be computed.
+
+ For normal insns, the length will be determined by value of the
+'length' attribute.  In the case of 'addr_vec' and 'addr_diff_vec' insn
+patterns, the length is computed as the number of vectors multiplied by
+the size of each vector.
+
+ Lengths are measured in addressable storage units (bytes).
+
+ The following macros can be used to refine the length computation:
+
+'ADJUST_INSN_LENGTH (INSN, LENGTH)'
+     If defined, modifies the length assigned to instruction INSN as a
+     function of the context in which it is used.  LENGTH is an lvalue
+     that contains the initially computed length of the insn and should
+     be updated with the correct length of the insn.
+
+     This macro will normally not be required.  A case in which it is
+     required is the ROMP.  On this machine, the size of an 'addr_vec'
+     insn must be increased by two to compensate for the fact that
+     alignment may be required.
+
+ The routine that returns 'get_attr_length' (the value of the 'length'
+attribute) can be used by the output routine to determine the form of
+the branch instruction to be written, as the example below illustrates.
+
+ As an example of the specification of variable-length branches,
+consider the IBM 360.  If we adopt the convention that a register will
+be set to the starting address of a function, we can jump to labels
+within 4k of the start using a four-byte instruction.  Otherwise, we
+need a six-byte sequence to load the address from memory and then branch
+to it.
+
+ On such a machine, a pattern for a branch instruction might be
+specified as follows:
+
+     (define_insn "jump"
+       [(set (pc)
+             (label_ref (match_operand 0 "" "")))]
+       ""
+     {
+        return (get_attr_length (insn) == 4
+                ? "b %l0" : "l r15,=a(%l0); br r15");
+     }
+       [(set (attr "length")
+             (if_then_else (lt (match_dup 0) (const_int 4096))
+                           (const_int 4)
+                           (const_int 6)))])
+
+
+File: gccint.info,  Node: Constant Attributes,  Next: Mnemonic Attribute,  Prev: Insn Lengths,  Up: Insn Attributes
+
+16.19.6 Constant Attributes
+---------------------------
+
+A special form of 'define_attr', where the expression for the default
+value is a 'const' expression, indicates an attribute that is constant
+for a given run of the compiler.  Constant attributes may be used to
+specify which variety of processor is used.  For example,
+
+     (define_attr "cpu" "m88100,m88110,m88000"
+      (const
+       (cond [(symbol_ref "TARGET_88100") (const_string "m88100")
+              (symbol_ref "TARGET_88110") (const_string "m88110")]
+             (const_string "m88000"))))
+
+     (define_attr "memory" "fast,slow"
+      (const
+       (if_then_else (symbol_ref "TARGET_FAST_MEM")
+                     (const_string "fast")
+                     (const_string "slow"))))
+
+ The routine generated for constant attributes has no parameters as it
+does not depend on any particular insn.  RTL expressions used to define
+the value of a constant attribute may use the 'symbol_ref' form, but may
+not use either the 'match_operand' form or 'eq_attr' forms involving
+insn attributes.
+
+
+File: gccint.info,  Node: Mnemonic Attribute,  Next: Delay Slots,  Prev: Constant Attributes,  Up: Insn Attributes
+
+16.19.7 Mnemonic Attribute
+--------------------------
+
+The 'mnemonic' attribute is a string type attribute holding the
+instruction mnemonic for an insn alternative.  The attribute values will
+automatically be generated by the machine description parser if there is
+an attribute definition in the md file:
+
+     (define_attr "mnemonic" "unknown" (const_string "unknown"))
+
+ The default value can be freely chosen as long as it does not collide
+with any of the instruction mnemonics.  This value will be used whenever
+the machine description parser is not able to determine the mnemonic
+string.  This might be the case for output templates containing more
+than a single instruction as in '"mvcle\t%0,%1,0\;jo\t.-4"'.
+
+ The 'mnemonic' attribute set is not generated automatically if the
+instruction string is generated via C code.
+
+ An existing 'mnemonic' attribute set in an insn definition will not be
+overriden by the md file parser.  That way it is possible to manually
+set the instruction mnemonics for the cases where the md file parser
+fails to determine it automatically.
+
+ The 'mnemonic' attribute is useful for dealing with instruction
+specific properties in the pipeline description without defining
+additional insn attributes.
+
+     (define_attr "ooo_expanded" ""
+       (cond [(eq_attr "mnemonic" "dlr,dsgr,d,dsgf,stam,dsgfr,dlgr")
+              (const_int 1)]
+             (const_int 0)))
+
+
+File: gccint.info,  Node: Delay Slots,  Next: Processor pipeline description,  Prev: Mnemonic Attribute,  Up: Insn Attributes
+
+16.19.8 Delay Slot Scheduling
+-----------------------------
+
+The insn attribute mechanism can be used to specify the requirements for
+delay slots, if any, on a target machine.  An instruction is said to
+require a "delay slot" if some instructions that are physically after
+the instruction are executed as if they were located before it.  Classic
+examples are branch and call instructions, which often execute the
+following instruction before the branch or call is performed.
+
+ On some machines, conditional branch instructions can optionally
+"annul" instructions in the delay slot.  This means that the instruction
+will not be executed for certain branch outcomes.  Both instructions
+that annul if the branch is true and instructions that annul if the
+branch is false are supported.
+
+ Delay slot scheduling differs from instruction scheduling in that
+determining whether an instruction needs a delay slot is dependent only
+on the type of instruction being generated, not on data flow between the
+instructions.  See the next section for a discussion of data-dependent
+instruction scheduling.
+
+ The requirement of an insn needing one or more delay slots is indicated
+via the 'define_delay' expression.  It has the following form:
+
+     (define_delay TEST
+                   [DELAY-1 ANNUL-TRUE-1 ANNUL-FALSE-1
+                    DELAY-2 ANNUL-TRUE-2 ANNUL-FALSE-2
+                    ...])
+
+ TEST is an attribute test that indicates whether this 'define_delay'
+applies to a particular insn.  If so, the number of required delay slots
+is determined by the length of the vector specified as the second
+argument.  An insn placed in delay slot N must satisfy attribute test
+DELAY-N.  ANNUL-TRUE-N is an attribute test that specifies which insns
+may be annulled if the branch is true.  Similarly, ANNUL-FALSE-N
+specifies which insns in the delay slot may be annulled if the branch is
+false.  If annulling is not supported for that delay slot, '(nil)'
+should be coded.
+
+ For example, in the common case where branch and call insns require a
+single delay slot, which may contain any insn other than a branch or
+call, the following would be placed in the 'md' file:
+
+     (define_delay (eq_attr "type" "branch,call")
+                   [(eq_attr "type" "!branch,call") (nil) (nil)])
+
+ Multiple 'define_delay' expressions may be specified.  In this case,
+each such expression specifies different delay slot requirements and
+there must be no insn for which tests in two 'define_delay' expressions
+are both true.
+
+ For example, if we have a machine that requires one delay slot for
+branches but two for calls, no delay slot can contain a branch or call
+insn, and any valid insn in the delay slot for the branch can be
+annulled if the branch is true, we might represent this as follows:
+
+     (define_delay (eq_attr "type" "branch")
+        [(eq_attr "type" "!branch,call")
+         (eq_attr "type" "!branch,call")
+         (nil)])
+
+     (define_delay (eq_attr "type" "call")
+                   [(eq_attr "type" "!branch,call") (nil) (nil)
+                    (eq_attr "type" "!branch,call") (nil) (nil)])
+
+
+File: gccint.info,  Node: Processor pipeline description,  Prev: Delay Slots,  Up: Insn Attributes
+
+16.19.9 Specifying processor pipeline description
+-------------------------------------------------
+
+To achieve better performance, most modern processors (super-pipelined,
+superscalar RISC, and VLIW processors) have many "functional units" on
+which several instructions can be executed simultaneously.  An
+instruction starts execution if its issue conditions are satisfied.  If
+not, the instruction is stalled until its conditions are satisfied.
+Such "interlock (pipeline) delay" causes interruption of the fetching of
+successor instructions (or demands nop instructions, e.g. for some MIPS
+processors).
+
+ There are two major kinds of interlock delays in modern processors.
+The first one is a data dependence delay determining "instruction
+latency time".  The instruction execution is not started until all
+source data have been evaluated by prior instructions (there are more
+complex cases when the instruction execution starts even when the data
+are not available but will be ready in given time after the instruction
+execution start).  Taking the data dependence delays into account is
+simple.  The data dependence (true, output, and anti-dependence) delay
+between two instructions is given by a constant.  In most cases this
+approach is adequate.  The second kind of interlock delays is a
+reservation delay.  The reservation delay means that two instructions
+under execution will be in need of shared processors resources, i.e.
+buses, internal registers, and/or functional units, which are reserved
+for some time.  Taking this kind of delay into account is complex
+especially for modern RISC processors.
+
+ The task of exploiting more processor parallelism is solved by an
+instruction scheduler.  For a better solution to this problem, the
+instruction scheduler has to have an adequate description of the
+processor parallelism (or "pipeline description").  GCC machine
+descriptions describe processor parallelism and functional unit
+reservations for groups of instructions with the aid of "regular
+expressions".
+
+ The GCC instruction scheduler uses a "pipeline hazard recognizer" to
+figure out the possibility of the instruction issue by the processor on
+a given simulated processor cycle.  The pipeline hazard recognizer is
+automatically generated from the processor pipeline description.  The
+pipeline hazard recognizer generated from the machine description is
+based on a deterministic finite state automaton (DFA): the instruction
+issue is possible if there is a transition from one automaton state to
+another one.  This algorithm is very fast, and furthermore, its speed is
+not dependent on processor complexity(1).
+
+ The rest of this section describes the directives that constitute an
+automaton-based processor pipeline description.  The order of these
+constructions within the machine description file is not important.
+
+ The following optional construction describes names of automata
+generated and used for the pipeline hazards recognition.  Sometimes the
+generated finite state automaton used by the pipeline hazard recognizer
+is large.  If we use more than one automaton and bind functional units
+to the automata, the total size of the automata is usually less than the
+size of the single automaton.  If there is no one such construction,
+only one finite state automaton is generated.
+
+     (define_automaton AUTOMATA-NAMES)
+
+ AUTOMATA-NAMES is a string giving names of the automata.  The names are
+separated by commas.  All the automata should have unique names.  The
+automaton name is used in the constructions 'define_cpu_unit' and
+'define_query_cpu_unit'.
+
+ Each processor functional unit used in the description of instruction
+reservations should be described by the following construction.
+
+     (define_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
+
+ UNIT-NAMES is a string giving the names of the functional units
+separated by commas.  Don't use name 'nothing', it is reserved for other
+goals.
+
+ AUTOMATON-NAME is a string giving the name of the automaton with which
+the unit is bound.  The automaton should be described in construction
+'define_automaton'.  You should give "automaton-name", if there is a
+defined automaton.
+
+ The assignment of units to automata are constrained by the uses of the
+units in insn reservations.  The most important constraint is: if a unit
+reservation is present on a particular cycle of an alternative for an
+insn reservation, then some unit from the same automaton must be present
+on the same cycle for the other alternatives of the insn reservation.
+The rest of the constraints are mentioned in the description of the
+subsequent constructions.
+
+ The following construction describes CPU functional units analogously
+to 'define_cpu_unit'.  The reservation of such units can be queried for
+an automaton state.  The instruction scheduler never queries reservation
+of functional units for given automaton state.  So as a rule, you don't
+need this construction.  This construction could be used for future code
+generation goals (e.g. to generate VLIW insn templates).
+
+     (define_query_cpu_unit UNIT-NAMES [AUTOMATON-NAME])
+
+ UNIT-NAMES is a string giving names of the functional units separated
+by commas.
+
+ AUTOMATON-NAME is a string giving the name of the automaton with which
+the unit is bound.
+
+ The following construction is the major one to describe pipeline
+characteristics of an instruction.
+
+     (define_insn_reservation INSN-NAME DEFAULT_LATENCY
+                              CONDITION REGEXP)
+
+ DEFAULT_LATENCY is a number giving latency time of the instruction.
+There is an important difference between the old description and the
+automaton based pipeline description.  The latency time is used for all
+dependencies when we use the old description.  In the automaton based
+pipeline description, the given latency time is only used for true
+dependencies.  The cost of anti-dependencies is always zero and the cost
+of output dependencies is the difference between latency times of the
+producing and consuming insns (if the difference is negative, the cost
+is considered to be zero).  You can always change the default costs for
+any description by using the target hook 'TARGET_SCHED_ADJUST_COST'
+(*note Scheduling::).
+
+ INSN-NAME is a string giving the internal name of the insn.  The
+internal names are used in constructions 'define_bypass' and in the
+automaton description file generated for debugging.  The internal name
+has nothing in common with the names in 'define_insn'.  It is a good
+practice to use insn classes described in the processor manual.
+
+ CONDITION defines what RTL insns are described by this construction.
+You should remember that you will be in trouble if CONDITION for two or
+more different 'define_insn_reservation' constructions is TRUE for an
+insn.  In this case what reservation will be used for the insn is not
+defined.  Such cases are not checked during generation of the pipeline
+hazards recognizer because in general recognizing that two conditions
+may have the same value is quite difficult (especially if the conditions
+contain 'symbol_ref').  It is also not checked during the pipeline
+hazard recognizer work because it would slow down the recognizer
+considerably.
+
+ REGEXP is a string describing the reservation of the cpu's functional
+units by the instruction.  The reservations are described by a regular
+expression according to the following syntax:
+
+            regexp = regexp "," oneof
+                   | oneof
+
+            oneof = oneof "|" allof
+                  | allof
+
+            allof = allof "+" repeat
+                  | repeat
+
+            repeat = element "*" number
+                   | element
+
+            element = cpu_function_unit_name
+                    | reservation_name
+                    | result_name
+                    | "nothing"
+                    | "(" regexp ")"
+
+   * ',' is used for describing the start of the next cycle in the
+     reservation.
+
+   * '|' is used for describing a reservation described by the first
+     regular expression *or* a reservation described by the second
+     regular expression *or* etc.
+
+   * '+' is used for describing a reservation described by the first
+     regular expression *and* a reservation described by the second
+     regular expression *and* etc.
+
+   * '*' is used for convenience and simply means a sequence in which
+     the regular expression are repeated NUMBER times with cycle
+     advancing (see ',').
+
+   * 'cpu_function_unit_name' denotes reservation of the named
+     functional unit.
+
+   * 'reservation_name' -- see description of construction
+     'define_reservation'.
+
+   * 'nothing' denotes no unit reservations.
+
+ Sometimes unit reservations for different insns contain common parts.
+In such case, you can simplify the pipeline description by describing
+the common part by the following construction
+
+     (define_reservation RESERVATION-NAME REGEXP)
+
+ RESERVATION-NAME is a string giving name of REGEXP.  Functional unit
+names and reservation names are in the same name space.  So the
+reservation names should be different from the functional unit names and
+can not be the reserved name 'nothing'.
+
+ The following construction is used to describe exceptions in the
+latency time for given instruction pair.  This is so called bypasses.
+
+     (define_bypass NUMBER OUT_INSN_NAMES IN_INSN_NAMES
+                    [GUARD])
+
+ NUMBER defines when the result generated by the instructions given in
+string OUT_INSN_NAMES will be ready for the instructions given in string
+IN_INSN_NAMES.  Each of these strings is a comma-separated list of
+filename-style globs and they refer to the names of
+'define_insn_reservation's.  For example:
+     (define_bypass 1 "cpu1_load_*, cpu1_store_*" "cpu1_load_*")
+ defines a bypass between instructions that start with 'cpu1_load_' or
+'cpu1_store_' and those that start with 'cpu1_load_'.
+
+ GUARD is an optional string giving the name of a C function which
+defines an additional guard for the bypass.  The function will get the
+two insns as parameters.  If the function returns zero the bypass will
+be ignored for this case.  The additional guard is necessary to
+recognize complicated bypasses, e.g. when the consumer is only an
+address of insn 'store' (not a stored value).
+
+ If there are more one bypass with the same output and input insns, the
+chosen bypass is the first bypass with a guard in description whose
+guard function returns nonzero.  If there is no such bypass, then bypass
+without the guard function is chosen.
+
+ The following five constructions are usually used to describe VLIW
+processors, or more precisely, to describe a placement of small
+instructions into VLIW instruction slots.  They can be used for RISC
+processors, too.
+
+     (exclusion_set UNIT-NAMES UNIT-NAMES)
+     (presence_set UNIT-NAMES PATTERNS)
+     (final_presence_set UNIT-NAMES PATTERNS)
+     (absence_set UNIT-NAMES PATTERNS)
+     (final_absence_set UNIT-NAMES PATTERNS)
+
+ UNIT-NAMES is a string giving names of functional units separated by
+commas.
+
+ PATTERNS is a string giving patterns of functional units separated by
+comma.  Currently pattern is one unit or units separated by
+white-spaces.
+
+ The first construction ('exclusion_set') means that each functional
+unit in the first string can not be reserved simultaneously with a unit
+whose name is in the second string and vice versa.  For example, the
+construction is useful for describing processors (e.g. some SPARC
+processors) with a fully pipelined floating point functional unit which
+can execute simultaneously only single floating point insns or only
+double floating point insns.
+
+ The second construction ('presence_set') means that each functional
+unit in the first string can not be reserved unless at least one of
+pattern of units whose names are in the second string is reserved.  This
+is an asymmetric relation.  For example, it is useful for description
+that VLIW 'slot1' is reserved after 'slot0' reservation.  We could
+describe it by the following construction
+
+     (presence_set "slot1" "slot0")
+
+ Or 'slot1' is reserved only after 'slot0' and unit 'b0' reservation.
+In this case we could write
+
+     (presence_set "slot1" "slot0 b0")
+
+ The third construction ('final_presence_set') is analogous to
+'presence_set'.  The difference between them is when checking is done.
+When an instruction is issued in given automaton state reflecting all
+current and planned unit reservations, the automaton state is changed.
+The first state is a source state, the second one is a result state.
+Checking for 'presence_set' is done on the source state reservation,
+checking for 'final_presence_set' is done on the result reservation.
+This construction is useful to describe a reservation which is actually
+two subsequent reservations.  For example, if we use
+
+     (presence_set "slot1" "slot0")
+
+ the following insn will be never issued (because 'slot1' requires
+'slot0' which is absent in the source state).
+
+     (define_reservation "insn_and_nop" "slot0 + slot1")
+
+ but it can be issued if we use analogous 'final_presence_set'.
+
+ The forth construction ('absence_set') means that each functional unit
+in the first string can be reserved only if each pattern of units whose
+names are in the second string is not reserved.  This is an asymmetric
+relation (actually 'exclusion_set' is analogous to this one but it is
+symmetric).  For example it might be useful in a VLIW description to say
+that 'slot0' cannot be reserved after either 'slot1' or 'slot2' have
+been reserved.  This can be described as:
+
+     (absence_set "slot0" "slot1, slot2")
+
+ Or 'slot2' can not be reserved if 'slot0' and unit 'b0' are reserved or
+'slot1' and unit 'b1' are reserved.  In this case we could write
+
+     (absence_set "slot2" "slot0 b0, slot1 b1")
+
+ All functional units mentioned in a set should belong to the same
+automaton.
+
+ The last construction ('final_absence_set') is analogous to
+'absence_set' but checking is done on the result (state) reservation.
+See comments for 'final_presence_set'.
+
+ You can control the generator of the pipeline hazard recognizer with
+the following construction.
+
+     (automata_option OPTIONS)
+
+ OPTIONS is a string giving options which affect the generated code.
+Currently there are the following options:
+
+   * "no-minimization" makes no minimization of the automaton.  This is
+     only worth to do when we are debugging the description and need to
+     look more accurately at reservations of states.
+
+   * "time" means printing time statistics about the generation of
+     automata.
+
+   * "stats" means printing statistics about the generated automata such
+     as the number of DFA states, NDFA states and arcs.
+
+   * "v" means a generation of the file describing the result automata.
+     The file has suffix '.dfa' and can be used for the description
+     verification and debugging.
+
+   * "w" means a generation of warning instead of error for non-critical
+     errors.
+
+   * "no-comb-vect" prevents the automaton generator from generating two
+     data structures and comparing them for space efficiency.  Using a
+     comb vector to represent transitions may be better, but it can be
+     very expensive to construct.  This option is useful if the build
+     process spends an unacceptably long time in genautomata.
+
+   * "ndfa" makes nondeterministic finite state automata.  This affects
+     the treatment of operator '|' in the regular expressions.  The
+     usual treatment of the operator is to try the first alternative
+     and, if the reservation is not possible, the second alternative.
+     The nondeterministic treatment means trying all alternatives, some
+     of them may be rejected by reservations in the subsequent insns.
+
+   * "collapse-ndfa" modifies the behaviour of the generator when
+     producing an automaton.  An additional state transition to collapse
+     a nondeterministic NDFA state to a deterministic DFA state is
+     generated.  It can be triggered by passing 'const0_rtx' to
+     state_transition.  In such an automaton, cycle advance transitions
+     are available only for these collapsed states.  This option is
+     useful for ports that want to use the 'ndfa' option, but also want
+     to use 'define_query_cpu_unit' to assign units to insns issued in a
+     cycle.
+
+   * "progress" means output of a progress bar showing how many states
+     were generated so far for automaton being processed.  This is
+     useful during debugging a DFA description.  If you see too many
+     generated states, you could interrupt the generator of the pipeline
+     hazard recognizer and try to figure out a reason for generation of
+     the huge automaton.
+
+ As an example, consider a superscalar RISC machine which can issue
+three insns (two integer insns and one floating point insn) on the cycle
+but can finish only two insns.  To describe this, we define the
+following functional units.
+
+     (define_cpu_unit "i0_pipeline, i1_pipeline, f_pipeline")
+     (define_cpu_unit "port0, port1")
+
+ All simple integer insns can be executed in any integer pipeline and
+their result is ready in two cycles.  The simple integer insns are
+issued into the first pipeline unless it is reserved, otherwise they are
+issued into the second pipeline.  Integer division and multiplication
+insns can be executed only in the second integer pipeline and their
+results are ready correspondingly in 8 and 4 cycles.  The integer
+division is not pipelined, i.e. the subsequent integer division insn can
+not be issued until the current division insn finished.  Floating point
+insns are fully pipelined and their results are ready in 3 cycles.
+Where the result of a floating point insn is used by an integer insn, an
+additional delay of one cycle is incurred.  To describe all of this we
+could specify
+
+     (define_cpu_unit "div")
+
+     (define_insn_reservation "simple" 2 (eq_attr "type" "int")
+                              "(i0_pipeline | i1_pipeline), (port0 | port1)")
+
+     (define_insn_reservation "mult" 4 (eq_attr "type" "mult")
+                              "i1_pipeline, nothing*2, (port0 | port1)")
+
+     (define_insn_reservation "div" 8 (eq_attr "type" "div")
+                              "i1_pipeline, div*7, div + (port0 | port1)")
+
+     (define_insn_reservation "float" 3 (eq_attr "type" "float")
+                              "f_pipeline, nothing, (port0 | port1))
+
+     (define_bypass 4 "float" "simple,mult,div")
+
+ To simplify the description we could describe the following reservation
+
+     (define_reservation "finish" "port0|port1")
+
+ and use it in all 'define_insn_reservation' as in the following
+construction
+
+     (define_insn_reservation "simple" 2 (eq_attr "type" "int")
+                              "(i0_pipeline | i1_pipeline), finish")
+
+   ---------- Footnotes ----------
+
+   (1) However, the size of the automaton depends on processor
+complexity.  To limit this effect, machine descriptions can split
+orthogonal parts of the machine description among several automata: but
+then, since each of these must be stepped independently, this does cause
+a small decrease in the algorithm's performance.
+
+
+File: gccint.info,  Node: Conditional Execution,  Next: Define Subst,  Prev: Insn Attributes,  Up: Machine Desc
+
+16.20 Conditional Execution
+===========================
+
+A number of architectures provide for some form of conditional
+execution, or predication.  The hallmark of this feature is the ability
+to nullify most of the instructions in the instruction set.  When the
+instruction set is large and not entirely symmetric, it can be quite
+tedious to describe these forms directly in the '.md' file.  An
+alternative is the 'define_cond_exec' template.
+
+     (define_cond_exec
+       [PREDICATE-PATTERN]
+       "CONDITION"
+       "OUTPUT-TEMPLATE"
+       "OPTIONAL-INSN-ATTRIBUES")
+
+ PREDICATE-PATTERN is the condition that must be true for the insn to be
+executed at runtime and should match a relational operator.  One can use
+'match_operator' to match several relational operators at once.  Any
+'match_operand' operands must have no more than one alternative.
+
+ CONDITION is a C expression that must be true for the generated pattern
+to match.
+
+ OUTPUT-TEMPLATE is a string similar to the 'define_insn' output
+template (*note Output Template::), except that the '*' and '@' special
+cases do not apply.  This is only useful if the assembly text for the
+predicate is a simple prefix to the main insn.  In order to handle the
+general case, there is a global variable 'current_insn_predicate' that
+will contain the entire predicate if the current insn is predicated, and
+will otherwise be 'NULL'.
+
+ OPTIONAL-INSN-ATTRIBUTES is an optional vector of attributes that gets
+appended to the insn attributes of the produced cond_exec rtx.  It can
+be used to add some distinguishing attribute to cond_exec rtxs produced
+that way.  An example usage would be to use this attribute in
+conjunction with attributes on the main pattern to disable particular
+alternatives under certain conditions.
+
+ When 'define_cond_exec' is used, an implicit reference to the
+'predicable' instruction attribute is made.  *Note Insn Attributes::.
+This attribute must be a boolean (i.e. have exactly two elements in its
+LIST-OF-VALUES), with the possible values being 'no' and 'yes'.  The
+default and all uses in the insns must be a simple constant, not a
+complex expressions.  It may, however, depend on the alternative, by
+using a comma-separated list of values.  If that is the case, the port
+should also define an 'enabled' attribute (*note Disable Insn
+Alternatives::), which should also allow only 'no' and 'yes' as its
+values.
+
+ For each 'define_insn' for which the 'predicable' attribute is true, a
+new 'define_insn' pattern will be generated that matches a predicated
+version of the instruction.  For example,
+
+     (define_insn "addsi"
+       [(set (match_operand:SI 0 "register_operand" "r")
+             (plus:SI (match_operand:SI 1 "register_operand" "r")
+                      (match_operand:SI 2 "register_operand" "r")))]
+       "TEST1"
+       "add %2,%1,%0")
+
+     (define_cond_exec
+       [(ne (match_operand:CC 0 "register_operand" "c")
+            (const_int 0))]
+       "TEST2"
+       "(%0)")
+
+generates a new pattern
+
+     (define_insn ""
+       [(cond_exec
+          (ne (match_operand:CC 3 "register_operand" "c") (const_int 0))
+          (set (match_operand:SI 0 "register_operand" "r")
+               (plus:SI (match_operand:SI 1 "register_operand" "r")
+                        (match_operand:SI 2 "register_operand" "r"))))]
+       "(TEST2) && (TEST1)"
+       "(%3) add %2,%1,%0")
+
+
+File: gccint.info,  Node: Define Subst,  Next: Constant Definitions,  Prev: Conditional Execution,  Up: Machine Desc
+
+16.21 RTL Templates Transformations
+===================================
+
+For some hardware architectures there are common cases when the RTL
+templates for the instructions can be derived from the other RTL
+templates using simple transformations.  E.g., 'i386.md' contains an RTL
+template for the ordinary 'sub' instruction-- '*subsi_1', and for the
+'sub' instruction with subsequent zero-extension--'*subsi_1_zext'.  Such
+cases can be easily implemented by a single meta-template capable of
+generating a modified case based on the initial one:
+
+     (define_subst "NAME"
+       [INPUT-TEMPLATE]
+       "CONDITION"
+       [OUTPUT-TEMPLATE])
+ INPUT-TEMPLATE is a pattern describing the source RTL template, which
+will be transformed.
+
+ CONDITION is a C expression that is conjunct with the condition from
+the input-template to generate a condition to be used in the
+output-template.
+
+ OUTPUT-TEMPLATE is a pattern that will be used in the resulting
+template.
+
+ 'define_subst' mechanism is tightly coupled with the notion of the
+subst attribute (*note Subst Iterators::).  The use of 'define_subst' is
+triggered by a reference to a subst attribute in the transforming RTL
+template.  This reference initiates duplication of the source RTL
+template and substitution of the attributes with their values.  The
+source RTL template is left unchanged, while the copy is transformed by
+'define_subst'.  This transformation can fail in the case when the
+source RTL template is not matched against the input-template of the
+'define_subst'.  In such case the copy is deleted.
+
+ 'define_subst' can be used only in 'define_insn' and 'define_expand',
+it cannot be used in other expressions (e.g.  in
+'define_insn_and_split').
+
+* Menu:
+
+* Define Subst Example::	    Example of 'define_subst' work.
+* Define Subst Pattern Matching::   Process of template comparison.
+* Define Subst Output Template::    Generation of output template.
+
+
+File: gccint.info,  Node: Define Subst Example,  Next: Define Subst Pattern Matching,  Up: Define Subst
+
+16.21.1 'define_subst' Example
+------------------------------
+
+To illustrate how 'define_subst' works, let us examine a simple template
+transformation.
+
+ Suppose there are two kinds of instructions: one that touches flags and
+the other that does not.  The instructions of the second type could be
+generated with the following 'define_subst':
+
+     (define_subst "add_clobber_subst"
+       [(set (match_operand:SI 0 "" "")
+             (match_operand:SI 1 "" ""))]
+       ""
+       [(set (match_dup 0)
+             (match_dup 1))
+        (clobber (reg:CC FLAGS_REG))]
+
+ This 'define_subst' can be applied to any RTL pattern containing 'set'
+of mode SI and generates a copy with clobber when it is applied.
+
+ Assume there is an RTL template for a 'max' instruction to be used in
+'define_subst' mentioned above:
+
+     (define_insn "maxsi"
+       [(set (match_operand:SI 0 "register_operand" "=r")
+             (max:SI
+               (match_operand:SI 1 "register_operand" "r")
+               (match_operand:SI 2 "register_operand" "r")))]
+       ""
+       "max\t{%2, %1, %0|%0, %1, %2}"
+      [...])
+
+ To mark the RTL template for 'define_subst' application,
+subst-attributes are used.  They should be declared in advance:
+
+     (define_subst_attr "add_clobber_name" "add_clobber_subst" "_noclobber" "_clobber")
+
+ Here 'add_clobber_name' is the attribute name, 'add_clobber_subst' is
+the name of the corresponding 'define_subst', the third argument
+('_noclobber') is the attribute value that would be substituted into the
+unchanged version of the source RTL template, and the last argument
+('_clobber') is the value that would be substituted into the second,
+transformed, version of the RTL template.
+
+ Once the subst-attribute has been defined, it should be used in RTL
+templates which need to be processed by the 'define_subst'.  So, the
+original RTL template should be changed:
+
+     (define_insn "maxsi<add_clobber_name>"
+       [(set (match_operand:SI 0 "register_operand" "=r")
+             (max:SI
+               (match_operand:SI 1 "register_operand" "r")
+               (match_operand:SI 2 "register_operand" "r")))]
+       ""
+       "max\t{%2, %1, %0|%0, %1, %2}"
+      [...])
+
+ The result of the 'define_subst' usage would look like the following:
+
+     (define_insn "maxsi_noclobber"
+       [(set (match_operand:SI 0 "register_operand" "=r")
+             (max:SI
+               (match_operand:SI 1 "register_operand" "r")
+               (match_operand:SI 2 "register_operand" "r")))]
+       ""
+       "max\t{%2, %1, %0|%0, %1, %2}"
+      [...])
+     (define_insn "maxsi_clobber"
+       [(set (match_operand:SI 0 "register_operand" "=r")
+             (max:SI
+               (match_operand:SI 1 "register_operand" "r")
+               (match_operand:SI 2 "register_operand" "r")))
+        (clobber (reg:CC FLAGS_REG))]
+       ""
+       "max\t{%2, %1, %0|%0, %1, %2}"
+      [...])
+
+
+File: gccint.info,  Node: Define Subst Pattern Matching,  Next: Define Subst Output Template,  Prev: Define Subst Example,  Up: Define Subst
+
+16.21.2 Pattern Matching in 'define_subst'
+------------------------------------------
+
+All expressions, allowed in 'define_insn' or 'define_expand', are
+allowed in the input-template of 'define_subst', except 'match_par_dup',
+'match_scratch', 'match_parallel'.  The meanings of expressions in the
+input-template were changed:
+
+ 'match_operand' matches any expression (possibly, a subtree in
+RTL-template), if modes of the 'match_operand' and this expression are
+the same, or mode of the 'match_operand' is 'VOIDmode', or this
+expression is 'match_dup', 'match_op_dup'.  If the expression is
+'match_operand' too, and predicate of 'match_operand' from the input
+pattern is not empty, then the predicates are compared.  That can be
+used for more accurate filtering of accepted RTL-templates.
+
+ 'match_operator' matches common operators (like 'plus', 'minus'),
+'unspec', 'unspec_volatile' operators and 'match_operator's from the
+original pattern if the modes match and 'match_operator' from the input
+pattern has the same number of operands as the operator from the
+original pattern.
+
+
+File: gccint.info,  Node: Define Subst Output Template,  Prev: Define Subst Pattern Matching,  Up: Define Subst
+
+16.21.3 Generation of output template in 'define_subst'
+-------------------------------------------------------
+
+If all necessary checks for 'define_subst' application pass, a new
+RTL-pattern, based on the output-template, is created to replace the old
+template.  Like in input-patterns, meanings of some RTL expressions are
+changed when they are used in output-patterns of a 'define_subst'.
+Thus, 'match_dup' is used for copying the whole expression from the
+original pattern, which matched corresponding 'match_operand' from the
+input pattern.
+
+ 'match_dup N' is used in the output template to be replaced with the
+expression from the original pattern, which matched 'match_operand N'
+from the input pattern.  As a consequence, 'match_dup' cannot be used to
+point to 'match_operand's from the output pattern, it should always
+refer to a 'match_operand' from the input pattern.
+
+ In the output template one can refer to the expressions from the
+original pattern and create new ones.  For instance, some operands could
+be added by means of standard 'match_operand'.
+
+ After replacing 'match_dup' with some RTL-subtree from the original
+pattern, it could happen that several 'match_operand's in the output
+pattern have the same indexes.  It is unknown, how many and what indexes
+would be used in the expression which would replace 'match_dup', so such
+conflicts in indexes are inevitable.  To overcome this issue,
+'match_operands' and 'match_operators', which were introduced into the
+output pattern, are renumerated when all 'match_dup's are replaced.
+
+ Number of alternatives in 'match_operand's introduced into the output
+template 'M' could differ from the number of alternatives in the
+original pattern 'N', so in the resultant pattern there would be 'N*M'
+alternatives.  Thus, constraints from the original pattern would be
+duplicated 'N' times, constraints from the output pattern would be
+duplicated 'M' times, producing all possible combinations.
+
+
+File: gccint.info,  Node: Constant Definitions,  Next: Iterators,  Prev: Define Subst,  Up: Machine Desc
+
+16.22 Constant Definitions
+==========================
+
+Using literal constants inside instruction patterns reduces legibility
+and can be a maintenance problem.
+
+ To overcome this problem, you may use the 'define_constants'
+expression.  It contains a vector of name-value pairs.  From that point
+on, wherever any of the names appears in the MD file, it is as if the
+corresponding value had been written instead.  You may use
+'define_constants' multiple times; each appearance adds more constants
+to the table.  It is an error to redefine a constant with a different
+value.
+
+ To come back to the a29k load multiple example, instead of
+
+     (define_insn ""
+       [(match_parallel 0 "load_multiple_operation"
+          [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
+                (match_operand:SI 2 "memory_operand" "m"))
+           (use (reg:SI 179))
+           (clobber (reg:SI 179))])]
+       ""
+       "loadm 0,0,%1,%2")
+
+ You could write:
+
+     (define_constants [
+         (R_BP 177)
+         (R_FC 178)
+         (R_CR 179)
+         (R_Q  180)
+     ])
+
+     (define_insn ""
+       [(match_parallel 0 "load_multiple_operation"
+          [(set (match_operand:SI 1 "gpc_reg_operand" "=r")
+                (match_operand:SI 2 "memory_operand" "m"))
+           (use (reg:SI R_CR))
+           (clobber (reg:SI R_CR))])]
+       ""
+       "loadm 0,0,%1,%2")
+
+ The constants that are defined with a define_constant are also output
+in the insn-codes.h header file as #defines.
+
+ You can also use the machine description file to define enumerations.
+Like the constants defined by 'define_constant', these enumerations are
+visible to both the machine description file and the main C code.
+
+ The syntax is as follows:
+
+     (define_c_enum "NAME" [
+       VALUE0
+       VALUE1
+       ...
+       VALUEN
+     ])
+
+ This definition causes the equivalent of the following C code to appear
+in 'insn-constants.h':
+
+     enum NAME {
+       VALUE0 = 0,
+       VALUE1 = 1,
+       ...
+       VALUEN = N
+     };
+     #define NUM_CNAME_VALUES (N + 1)
+
+ where CNAME is the capitalized form of NAME.  It also makes each VALUEI
+available in the machine description file, just as if it had been
+declared with:
+
+     (define_constants [(VALUEI I)])
+
+ Each VALUEI is usually an upper-case identifier and usually begins with
+CNAME.
+
+ You can split the enumeration definition into as many statements as you
+like.  The above example is directly equivalent to:
+
+     (define_c_enum "NAME" [VALUE0])
+     (define_c_enum "NAME" [VALUE1])
+     ...
+     (define_c_enum "NAME" [VALUEN])
+
+ Splitting the enumeration helps to improve the modularity of each
+individual '.md' file.  For example, if a port defines its
+synchronization instructions in a separate 'sync.md' file, it is
+convenient to define all synchronization-specific enumeration values in
+'sync.md' rather than in the main '.md' file.
+
+ Some enumeration names have special significance to GCC:
+
+'unspecv'
+     If an enumeration called 'unspecv' is defined, GCC will use it when
+     printing out 'unspec_volatile' expressions.  For example:
+
+          (define_c_enum "unspecv" [
+            UNSPECV_BLOCKAGE
+          ])
+
+     causes GCC to print '(unspec_volatile ... 0)' as:
+
+          (unspec_volatile ... UNSPECV_BLOCKAGE)
+
+'unspec'
+     If an enumeration called 'unspec' is defined, GCC will use it when
+     printing out 'unspec' expressions.  GCC will also use it when
+     printing out 'unspec_volatile' expressions unless an 'unspecv'
+     enumeration is also defined.  You can therefore decide whether to
+     keep separate enumerations for volatile and non-volatile
+     expressions or whether to use the same enumeration for both.
+
+ Another way of defining an enumeration is to use 'define_enum':
+
+     (define_enum "NAME" [
+       VALUE0
+       VALUE1
+       ...
+       VALUEN
+     ])
+
+ This directive implies:
+
+     (define_c_enum "NAME" [
+       CNAME_CVALUE0
+       CNAME_CVALUE1
+       ...
+       CNAME_CVALUEN
+     ])
+
+ where CVALUEI is the capitalized form of VALUEI.  However, unlike
+'define_c_enum', the enumerations defined by 'define_enum' can be used
+in attribute specifications (*note define_enum_attr::).
+
+
+File: gccint.info,  Node: Iterators,  Prev: Constant Definitions,  Up: Machine Desc
+
+16.23 Iterators
+===============
+
+Ports often need to define similar patterns for more than one machine
+mode or for more than one rtx code.  GCC provides some simple iterator
+facilities to make this process easier.
+
+* Menu:
+
+* Mode Iterators::         Generating variations of patterns for different modes.
+* Code Iterators::         Doing the same for codes.
+* Int Iterators::          Doing the same for integers.
+* Subst Iterators::	   Generating variations of patterns for define_subst.
+
+
+File: gccint.info,  Node: Mode Iterators,  Next: Code Iterators,  Up: Iterators
+
+16.23.1 Mode Iterators
+----------------------
+
+Ports often need to define similar patterns for two or more different
+modes.  For example:
+
+   * If a processor has hardware support for both single and double
+     floating-point arithmetic, the 'SFmode' patterns tend to be very
+     similar to the 'DFmode' ones.
+
+   * If a port uses 'SImode' pointers in one configuration and 'DImode'
+     pointers in another, it will usually have very similar 'SImode' and
+     'DImode' patterns for manipulating pointers.
+
+ Mode iterators allow several patterns to be instantiated from one '.md'
+file template.  They can be used with any type of rtx-based construct,
+such as a 'define_insn', 'define_split', or 'define_peephole2'.
+
+* Menu:
+
+* Defining Mode Iterators:: Defining a new mode iterator.
+* Substitutions::           Combining mode iterators with substitutions
+* Examples::                Examples
+
+
+File: gccint.info,  Node: Defining Mode Iterators,  Next: Substitutions,  Up: Mode Iterators
+
+16.23.1.1 Defining Mode Iterators
+.................................
+
+The syntax for defining a mode iterator is:
+
+     (define_mode_iterator NAME [(MODE1 "COND1") ... (MODEN "CONDN")])
+
+ This allows subsequent '.md' file constructs to use the mode suffix
+':NAME'.  Every construct that does so will be expanded N times, once
+with every use of ':NAME' replaced by ':MODE1', once with every use
+replaced by ':MODE2', and so on.  In the expansion for a particular
+MODEI, every C condition will also require that CONDI be true.
+
+ For example:
+
+     (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
+
+ defines a new mode suffix ':P'.  Every construct that uses ':P' will be
+expanded twice, once with every ':P' replaced by ':SI' and once with
+every ':P' replaced by ':DI'.  The ':SI' version will only apply if
+'Pmode == SImode' and the ':DI' version will only apply if 'Pmode ==
+DImode'.
+
+ As with other '.md' conditions, an empty string is treated as "always
+true".  '(MODE "")' can also be abbreviated to 'MODE'.  For example:
+
+     (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
+
+ means that the ':DI' expansion only applies if 'TARGET_64BIT' but that
+the ':SI' expansion has no such constraint.
+
+ Iterators are applied in the order they are defined.  This can be
+significant if two iterators are used in a construct that requires
+substitutions.  *Note Substitutions::.
+
+
+File: gccint.info,  Node: Substitutions,  Next: Examples,  Prev: Defining Mode Iterators,  Up: Mode Iterators
+
+16.23.1.2 Substitution in Mode Iterators
+........................................
+
+If an '.md' file construct uses mode iterators, each version of the
+construct will often need slightly different strings or modes.  For
+example:
+
+   * When a 'define_expand' defines several 'addM3' patterns (*note
+     Standard Names::), each expander will need to use the appropriate
+     mode name for M.
+
+   * When a 'define_insn' defines several instruction patterns, each
+     instruction will often use a different assembler mnemonic.
+
+   * When a 'define_insn' requires operands with different modes, using
+     an iterator for one of the operand modes usually requires a
+     specific mode for the other operand(s).
+
+ GCC supports such variations through a system of "mode attributes".
+There are two standard attributes: 'mode', which is the name of the mode
+in lower case, and 'MODE', which is the same thing in upper case.  You
+can define other attributes using:
+
+     (define_mode_attr NAME [(MODE1 "VALUE1") ... (MODEN "VALUEN")])
+
+ where NAME is the name of the attribute and VALUEI is the value
+associated with MODEI.
+
+ When GCC replaces some :ITERATOR with :MODE, it will scan each string
+and mode in the pattern for sequences of the form '<ITERATOR:ATTR>',
+where ATTR is the name of a mode attribute.  If the attribute is defined
+for MODE, the whole '<...>' sequence will be replaced by the appropriate
+attribute value.
+
+ For example, suppose an '.md' file has:
+
+     (define_mode_iterator P [(SI "Pmode == SImode") (DI "Pmode == DImode")])
+     (define_mode_attr load [(SI "lw") (DI "ld")])
+
+ If one of the patterns that uses ':P' contains the string
+'"<P:load>\t%0,%1"', the 'SI' version of that pattern will use
+'"lw\t%0,%1"' and the 'DI' version will use '"ld\t%0,%1"'.
+
+ Here is an example of using an attribute for a mode:
+
+     (define_mode_iterator LONG [SI DI])
+     (define_mode_attr SHORT [(SI "HI") (DI "SI")])
+     (define_insn ...
+       (sign_extend:LONG (match_operand:<LONG:SHORT> ...)) ...)
+
+ The 'ITERATOR:' prefix may be omitted, in which case the substitution
+will be attempted for every iterator expansion.
+
+
+File: gccint.info,  Node: Examples,  Prev: Substitutions,  Up: Mode Iterators
+
+16.23.1.3 Mode Iterator Examples
+................................
+
+Here is an example from the MIPS port.  It defines the following modes
+and attributes (among others):
+
+     (define_mode_iterator GPR [SI (DI "TARGET_64BIT")])
+     (define_mode_attr d [(SI "") (DI "d")])
+
+ and uses the following template to define both 'subsi3' and 'subdi3':
+
+     (define_insn "sub<mode>3"
+       [(set (match_operand:GPR 0 "register_operand" "=d")
+             (minus:GPR (match_operand:GPR 1 "register_operand" "d")
+                        (match_operand:GPR 2 "register_operand" "d")))]
+       ""
+       "<d>subu\t%0,%1,%2"
+       [(set_attr "type" "arith")
+        (set_attr "mode" "<MODE>")])
+
+ This is exactly equivalent to:
+
+     (define_insn "subsi3"
+       [(set (match_operand:SI 0 "register_operand" "=d")
+             (minus:SI (match_operand:SI 1 "register_operand" "d")
+                       (match_operand:SI 2 "register_operand" "d")))]
+       ""
+       "subu\t%0,%1,%2"
+       [(set_attr "type" "arith")
+        (set_attr "mode" "SI")])
+
+     (define_insn "subdi3"
+       [(set (match_operand:DI 0 "register_operand" "=d")
+             (minus:DI (match_operand:DI 1 "register_operand" "d")
+                       (match_operand:DI 2 "register_operand" "d")))]
+       ""
+       "dsubu\t%0,%1,%2"
+       [(set_attr "type" "arith")
+        (set_attr "mode" "DI")])
+
+
+File: gccint.info,  Node: Code Iterators,  Next: Int Iterators,  Prev: Mode Iterators,  Up: Iterators
+
+16.23.2 Code Iterators
+----------------------
+
+Code iterators operate in a similar way to mode iterators.  *Note Mode
+Iterators::.
+
+ The construct:
+
+     (define_code_iterator NAME [(CODE1 "COND1") ... (CODEN "CONDN")])
+
+ defines a pseudo rtx code NAME that can be instantiated as CODEI if
+condition CONDI is true.  Each CODEI must have the same rtx format.
+*Note RTL Classes::.
+
+ As with mode iterators, each pattern that uses NAME will be expanded N
+times, once with all uses of NAME replaced by CODE1, once with all uses
+replaced by CODE2, and so on.  *Note Defining Mode Iterators::.
+
+ It is possible to define attributes for codes as well as for modes.
+There are two standard code attributes: 'code', the name of the code in
+lower case, and 'CODE', the name of the code in upper case.  Other
+attributes are defined using:
+
+     (define_code_attr NAME [(CODE1 "VALUE1") ... (CODEN "VALUEN")])
+
+ Here's an example of code iterators in action, taken from the MIPS
+port:
+
+     (define_code_iterator any_cond [unordered ordered unlt unge uneq ltgt unle ungt
+                                     eq ne gt ge lt le gtu geu ltu leu])
+
+     (define_expand "b<code>"
+       [(set (pc)
+             (if_then_else (any_cond:CC (cc0)
+                                        (const_int 0))
+                           (label_ref (match_operand 0 ""))
+                           (pc)))]
+       ""
+     {
+       gen_conditional_branch (operands, <CODE>);
+       DONE;
+     })
+
+ This is equivalent to:
+
+     (define_expand "bunordered"
+       [(set (pc)
+             (if_then_else (unordered:CC (cc0)
+                                         (const_int 0))
+                           (label_ref (match_operand 0 ""))
+                           (pc)))]
+       ""
+     {
+       gen_conditional_branch (operands, UNORDERED);
+       DONE;
+     })
+
+     (define_expand "bordered"
+       [(set (pc)
+             (if_then_else (ordered:CC (cc0)
+                                       (const_int 0))
+                           (label_ref (match_operand 0 ""))
+                           (pc)))]
+       ""
+     {
+       gen_conditional_branch (operands, ORDERED);
+       DONE;
+     })
+
+     ...
+
+
+File: gccint.info,  Node: Int Iterators,  Next: Subst Iterators,  Prev: Code Iterators,  Up: Iterators
+
+16.23.3 Int Iterators
+---------------------
+
+Int iterators operate in a similar way to code iterators.  *Note Code
+Iterators::.
+
+ The construct:
+
+     (define_int_iterator NAME [(INT1 "COND1") ... (INTN "CONDN")])
+
+ defines a pseudo integer constant NAME that can be instantiated as INTI
+if condition CONDI is true.  Each INT must have the same rtx format.
+*Note RTL Classes::.  Int iterators can appear in only those rtx fields
+that have 'i' as the specifier.  This means that each INT has to be a
+constant defined using define_constant or define_c_enum.
+
+ As with mode and code iterators, each pattern that uses NAME will be
+expanded N times, once with all uses of NAME replaced by INT1, once with
+all uses replaced by INT2, and so on.  *Note Defining Mode Iterators::.
+
+ It is possible to define attributes for ints as well as for codes and
+modes.  Attributes are defined using:
+
+     (define_int_attr NAME [(INT1 "VALUE1") ... (INTN "VALUEN")])
+
+ Here's an example of int iterators in action, taken from the ARM port:
+
+     (define_int_iterator QABSNEG [UNSPEC_VQABS UNSPEC_VQNEG])
+
+     (define_int_attr absneg [(UNSPEC_VQABS "abs") (UNSPEC_VQNEG "neg")])
+
+     (define_insn "neon_vq<absneg><mode>"
+       [(set (match_operand:VDQIW 0 "s_register_operand" "=w")
+     	(unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w")
+     		       (match_operand:SI 2 "immediate_operand" "i")]
+     		      QABSNEG))]
+       "TARGET_NEON"
+       "vq<absneg>.<V_s_elem>\t%<V_reg>0, %<V_reg>1"
+       [(set_attr "type" "neon_vqneg_vqabs")]
+     )
+
+ This is equivalent to:
+
+     (define_insn "neon_vqabs<mode>"
+       [(set (match_operand:VDQIW 0 "s_register_operand" "=w")
+     	(unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w")
+     		       (match_operand:SI 2 "immediate_operand" "i")]
+     		      UNSPEC_VQABS))]
+       "TARGET_NEON"
+       "vqabs.<V_s_elem>\t%<V_reg>0, %<V_reg>1"
+       [(set_attr "type" "neon_vqneg_vqabs")]
+     )
+
+     (define_insn "neon_vqneg<mode>"
+       [(set (match_operand:VDQIW 0 "s_register_operand" "=w")
+     	(unspec:VDQIW [(match_operand:VDQIW 1 "s_register_operand" "w")
+     		       (match_operand:SI 2 "immediate_operand" "i")]
+     		      UNSPEC_VQNEG))]
+       "TARGET_NEON"
+       "vqneg.<V_s_elem>\t%<V_reg>0, %<V_reg>1"
+       [(set_attr "type" "neon_vqneg_vqabs")]
+     )
+
+
+File: gccint.info,  Node: Subst Iterators,  Prev: Int Iterators,  Up: Iterators
+
+16.23.4 Subst Iterators
+-----------------------
+
+Subst iterators are special type of iterators with the following
+restrictions: they could not be declared explicitly, they always have
+only two values, and they do not have explicit dedicated name.
+Subst-iterators are triggered only when corresponding subst-attribute is
+used in RTL-pattern.
+
+ Subst iterators transform templates in the following way: the templates
+are duplicated, the subst-attributes in these templates are replaced
+with the corresponding values, and a new attribute is implicitly added
+to the given 'define_insn'/'define_expand'.  The name of the added
+attribute matches the name of 'define_subst'.  Such attributes are
+declared implicitly, and it is not allowed to have a 'define_attr' named
+as a 'define_subst'.
+
+ Each subst iterator is linked to a 'define_subst'.  It is declared
+implicitly by the first appearance of the corresponding
+'define_subst_attr', and it is not allowed to define it explicitly.
+
+ Declarations of subst-attributes have the following syntax:
+
+     (define_subst_attr "NAME"
+       "SUBST-NAME"
+       "NO-SUBST-VALUE"
+       "SUBST-APPLIED-VALUE")
+
+ NAME is a string with which the given subst-attribute could be referred
+to.
+
+ SUBST-NAME shows which 'define_subst' should be applied to an
+RTL-template if the given subst-attribute is present in the
+RTL-template.
+
+ NO-SUBST-VALUE is a value with which subst-attribute would be replaced
+in the first copy of the original RTL-template.
+
+ SUBST-APPLIED-VALUE is a value with which subst-attribute would be
+replaced in the second copy of the original RTL-template.
+
+
+File: gccint.info,  Node: Target Macros,  Next: Host Config,  Prev: Machine Desc,  Up: Top
+
+17 Target Description Macros and Functions
+******************************************
+
+In addition to the file 'MACHINE.md', a machine description includes a C
+header file conventionally given the name 'MACHINE.h' and a C source
+file named 'MACHINE.c'.  The header file defines numerous macros that
+convey the information about the target machine that does not fit into
+the scheme of the '.md' file.  The file 'tm.h' should be a link to
+'MACHINE.h'.  The header file 'config.h' includes 'tm.h' and most
+compiler source files include 'config.h'.  The source file defines a
+variable 'targetm', which is a structure containing pointers to
+functions and data relating to the target machine.  'MACHINE.c' should
+also contain their definitions, if they are not defined elsewhere in
+GCC, and other functions called through the macros defined in the '.h'
+file.
+
+* Menu:
+
+* Target Structure::    The 'targetm' variable.
+* Driver::              Controlling how the driver runs the compilation passes.
+* Run-time Target::     Defining '-m' options like '-m68000' and '-m68020'.
+* Per-Function Data::   Defining data structures for per-function information.
+* Storage Layout::      Defining sizes and alignments of data.
+* Type Layout::         Defining sizes and properties of basic user data types.
+* Registers::           Naming and describing the hardware registers.
+* Register Classes::    Defining the classes of hardware registers.
+* Old Constraints::     The old way to define machine-specific constraints.
+* Stack and Calling::   Defining which way the stack grows and by how much.
+* Varargs::             Defining the varargs macros.
+* Trampolines::         Code set up at run time to enter a nested function.
+* Library Calls::       Controlling how library routines are implicitly called.
+* Addressing Modes::    Defining addressing modes valid for memory operands.
+* Anchored Addresses::  Defining how '-fsection-anchors' should work.
+* Condition Code::      Defining how insns update the condition code.
+* Costs::               Defining relative costs of different operations.
+* Scheduling::          Adjusting the behavior of the instruction scheduler.
+* Sections::            Dividing storage into text, data, and other sections.
+* PIC::                 Macros for position independent code.
+* Assembler Format::    Defining how to write insns and pseudo-ops to output.
+* Debugging Info::      Defining the format of debugging output.
+* Floating Point::      Handling floating point for cross-compilers.
+* Mode Switching::      Insertion of mode-switching instructions.
+* Target Attributes::   Defining target-specific uses of '__attribute__'.
+* Emulated TLS::        Emulated TLS support.
+* MIPS Coprocessors::   MIPS coprocessor support and how to customize it.
+* PCH Target::          Validity checking for precompiled headers.
+* C++ ABI::             Controlling C++ ABI changes.
+* Named Address Spaces:: Adding support for named address spaces
+* Misc::                Everything else.
+
+
+File: gccint.info,  Node: Target Structure,  Next: Driver,  Up: Target Macros
+
+17.1 The Global 'targetm' Variable
+==================================
+
+ -- Variable: struct gcc_target targetm
+     The target '.c' file must define the global 'targetm' variable
+     which contains pointers to functions and data relating to the
+     target machine.  The variable is declared in 'target.h';
+     'target-def.h' defines the macro 'TARGET_INITIALIZER' which is used
+     to initialize the variable, and macros for the default initializers
+     for elements of the structure.  The '.c' file should override those
+     macros for which the default definition is inappropriate.  For
+     example:
+          #include "target.h"
+          #include "target-def.h"
+
+          /* Initialize the GCC target structure.  */
+
+          #undef TARGET_COMP_TYPE_ATTRIBUTES
+          #define TARGET_COMP_TYPE_ATTRIBUTES MACHINE_comp_type_attributes
+
+          struct gcc_target targetm = TARGET_INITIALIZER;
+
+ Where a macro should be defined in the '.c' file in this manner to form
+part of the 'targetm' structure, it is documented below as a "Target
+Hook" with a prototype.  Many macros will change in future from being
+defined in the '.h' file to being part of the 'targetm' structure.
+
+ Similarly, there is a 'targetcm' variable for hooks that are specific
+to front ends for C-family languages, documented as "C Target Hook".
+This is declared in 'c-family/c-target.h', the initializer
+'TARGETCM_INITIALIZER' in 'c-family/c-target-def.h'.  If targets
+initialize 'targetcm' themselves, they should set
+'target_has_targetcm=yes' in 'config.gcc'; otherwise a default
+definition is used.
+
+ Similarly, there is a 'targetm_common' variable for hooks that are
+shared between the compiler driver and the compilers proper, documented
+as "Common Target Hook".  This is declared in 'common/common-target.h',
+the initializer 'TARGETM_COMMON_INITIALIZER' in
+'common/common-target-def.h'.  If targets initialize 'targetm_common'
+themselves, they should set 'target_has_targetm_common=yes' in
+'config.gcc'; otherwise a default definition is used.
+
+
+File: gccint.info,  Node: Driver,  Next: Run-time Target,  Prev: Target Structure,  Up: Target Macros
+
+17.2 Controlling the Compilation Driver, 'gcc'
+==============================================
+
+You can control the compilation driver.
+
+ -- Macro: DRIVER_SELF_SPECS
+     A list of specs for the driver itself.  It should be a suitable
+     initializer for an array of strings, with no surrounding braces.
+
+     The driver applies these specs to its own command line between
+     loading default 'specs' files (but not command-line specified ones)
+     and choosing the multilib directory or running any subcommands.  It
+     applies them in the order given, so each spec can depend on the
+     options added by earlier ones.  It is also possible to remove
+     options using '%<OPTION' in the usual way.
+
+     This macro can be useful when a port has several interdependent
+     target options.  It provides a way of standardizing the command
+     line so that the other specs are easier to write.
+
+     Do not define this macro if it does not need to do anything.
+
+ -- Macro: OPTION_DEFAULT_SPECS
+     A list of specs used to support configure-time default options
+     (i.e. '--with' options) in the driver.  It should be a suitable
+     initializer for an array of structures, each containing two
+     strings, without the outermost pair of surrounding braces.
+
+     The first item in the pair is the name of the default.  This must
+     match the code in 'config.gcc' for the target.  The second item is
+     a spec to apply if a default with this name was specified.  The
+     string '%(VALUE)' in the spec will be replaced by the value of the
+     default everywhere it occurs.
+
+     The driver will apply these specs to its own command line between
+     loading default 'specs' files and processing 'DRIVER_SELF_SPECS',
+     using the same mechanism as 'DRIVER_SELF_SPECS'.
+
+     Do not define this macro if it does not need to do anything.
+
+ -- Macro: CPP_SPEC
+     A C string constant that tells the GCC driver program options to
+     pass to CPP.  It can also specify how to translate options you give
+     to GCC into options for GCC to pass to the CPP.
+
+     Do not define this macro if it does not need to do anything.
+
+ -- Macro: CPLUSPLUS_CPP_SPEC
+     This macro is just like 'CPP_SPEC', but is used for C++, rather
+     than C.  If you do not define this macro, then the value of
+     'CPP_SPEC' (if any) will be used instead.
+
+ -- Macro: CC1_SPEC
+     A C string constant that tells the GCC driver program options to
+     pass to 'cc1', 'cc1plus', 'f771', and the other language front
+     ends.  It can also specify how to translate options you give to GCC
+     into options for GCC to pass to front ends.
+
+     Do not define this macro if it does not need to do anything.
+
+ -- Macro: CC1PLUS_SPEC
+     A C string constant that tells the GCC driver program options to
+     pass to 'cc1plus'.  It can also specify how to translate options
+     you give to GCC into options for GCC to pass to the 'cc1plus'.
+
+     Do not define this macro if it does not need to do anything.  Note
+     that everything defined in CC1_SPEC is already passed to 'cc1plus'
+     so there is no need to duplicate the contents of CC1_SPEC in
+     CC1PLUS_SPEC.
+
+ -- Macro: ASM_SPEC
+     A C string constant that tells the GCC driver program options to
+     pass to the assembler.  It can also specify how to translate
+     options you give to GCC into options for GCC to pass to the
+     assembler.  See the file 'sun3.h' for an example of this.
+
+     Do not define this macro if it does not need to do anything.
+
+ -- Macro: ASM_FINAL_SPEC
+     A C string constant that tells the GCC driver program how to run
+     any programs which cleanup after the normal assembler.  Normally,
+     this is not needed.  See the file 'mips.h' for an example of this.
+
+     Do not define this macro if it does not need to do anything.
+
+ -- Macro: AS_NEEDS_DASH_FOR_PIPED_INPUT
+     Define this macro, with no value, if the driver should give the
+     assembler an argument consisting of a single dash, '-', to instruct
+     it to read from its standard input (which will be a pipe connected
+     to the output of the compiler proper).  This argument is given
+     after any '-o' option specifying the name of the output file.
+
+     If you do not define this macro, the assembler is assumed to read
+     its standard input if given no non-option arguments.  If your
+     assembler cannot read standard input at all, use a '%{pipe:%e}'
+     construct; see 'mips.h' for instance.
+
+ -- Macro: LINK_SPEC
+     A C string constant that tells the GCC driver program options to
+     pass to the linker.  It can also specify how to translate options
+     you give to GCC into options for GCC to pass to the linker.
+
+     Do not define this macro if it does not need to do anything.
+
+ -- Macro: LIB_SPEC
+     Another C string constant used much like 'LINK_SPEC'.  The
+     difference between the two is that 'LIB_SPEC' is used at the end of
+     the command given to the linker.
+
+     If this macro is not defined, a default is provided that loads the
+     standard C library from the usual place.  See 'gcc.c'.
+
+ -- Macro: LIBGCC_SPEC
+     Another C string constant that tells the GCC driver program how and
+     when to place a reference to 'libgcc.a' into the linker command
+     line.  This constant is placed both before and after the value of
+     'LIB_SPEC'.
+
+     If this macro is not defined, the GCC driver provides a default
+     that passes the string '-lgcc' to the linker.
+
+ -- Macro: REAL_LIBGCC_SPEC
+     By default, if 'ENABLE_SHARED_LIBGCC' is defined, the 'LIBGCC_SPEC'
+     is not directly used by the driver program but is instead modified
+     to refer to different versions of 'libgcc.a' depending on the
+     values of the command line flags '-static', '-shared',
+     '-static-libgcc', and '-shared-libgcc'.  On targets where these
+     modifications are inappropriate, define 'REAL_LIBGCC_SPEC' instead.
+     'REAL_LIBGCC_SPEC' tells the driver how to place a reference to
+     'libgcc' on the link command line, but, unlike 'LIBGCC_SPEC', it is
+     used unmodified.
+
+ -- Macro: USE_LD_AS_NEEDED
+     A macro that controls the modifications to 'LIBGCC_SPEC' mentioned
+     in 'REAL_LIBGCC_SPEC'.  If nonzero, a spec will be generated that
+     uses '--as-needed' or equivalent options and the shared 'libgcc' in
+     place of the static exception handler library, when linking without
+     any of '-static', '-static-libgcc', or '-shared-libgcc'.
+
+ -- Macro: LINK_EH_SPEC
+     If defined, this C string constant is added to 'LINK_SPEC'.  When
+     'USE_LD_AS_NEEDED' is zero or undefined, it also affects the
+     modifications to 'LIBGCC_SPEC' mentioned in 'REAL_LIBGCC_SPEC'.
+
+ -- Macro: STARTFILE_SPEC
+     Another C string constant used much like 'LINK_SPEC'.  The
+     difference between the two is that 'STARTFILE_SPEC' is used at the
+     very beginning of the command given to the linker.
+
+     If this macro is not defined, a default is provided that loads the
+     standard C startup file from the usual place.  See 'gcc.c'.
+
+ -- Macro: ENDFILE_SPEC
+     Another C string constant used much like 'LINK_SPEC'.  The
+     difference between the two is that 'ENDFILE_SPEC' is used at the
+     very end of the command given to the linker.
+
+     Do not define this macro if it does not need to do anything.
+
+ -- Macro: THREAD_MODEL_SPEC
+     GCC '-v' will print the thread model GCC was configured to use.
+     However, this doesn't work on platforms that are multilibbed on
+     thread models, such as AIX 4.3.  On such platforms, define
+     'THREAD_MODEL_SPEC' such that it evaluates to a string without
+     blanks that names one of the recognized thread models.  '%*', the
+     default value of this macro, will expand to the value of
+     'thread_file' set in 'config.gcc'.
+
+ -- Macro: SYSROOT_SUFFIX_SPEC
+     Define this macro to add a suffix to the target sysroot when GCC is
+     configured with a sysroot.  This will cause GCC to search for
+     usr/lib, et al, within sysroot+suffix.
+
+ -- Macro: SYSROOT_HEADERS_SUFFIX_SPEC
+     Define this macro to add a headers_suffix to the target sysroot
+     when GCC is configured with a sysroot.  This will cause GCC to pass
+     the updated sysroot+headers_suffix to CPP, causing it to search for
+     usr/include, et al, within sysroot+headers_suffix.
+
+ -- Macro: EXTRA_SPECS
+     Define this macro to provide additional specifications to put in
+     the 'specs' file that can be used in various specifications like
+     'CC1_SPEC'.
+
+     The definition should be an initializer for an array of structures,
+     containing a string constant, that defines the specification name,
+     and a string constant that provides the specification.
+
+     Do not define this macro if it does not need to do anything.
+
+     'EXTRA_SPECS' is useful when an architecture contains several
+     related targets, which have various '..._SPECS' which are similar
+     to each other, and the maintainer would like one central place to
+     keep these definitions.
+
+     For example, the PowerPC System V.4 targets use 'EXTRA_SPECS' to
+     define either '_CALL_SYSV' when the System V calling sequence is
+     used or '_CALL_AIX' when the older AIX-based calling sequence is
+     used.
+
+     The 'config/rs6000/rs6000.h' target file defines:
+
+          #define EXTRA_SPECS \
+            { "cpp_sysv_default", CPP_SYSV_DEFAULT },
+
+          #define CPP_SYS_DEFAULT ""
+
+     The 'config/rs6000/sysv.h' target file defines:
+          #undef CPP_SPEC
+          #define CPP_SPEC \
+          "%{posix: -D_POSIX_SOURCE } \
+          %{mcall-sysv: -D_CALL_SYSV } \
+          %{!mcall-sysv: %(cpp_sysv_default) } \
+          %{msoft-float: -D_SOFT_FLOAT} %{mcpu=403: -D_SOFT_FLOAT}"
+
+          #undef CPP_SYSV_DEFAULT
+          #define CPP_SYSV_DEFAULT "-D_CALL_SYSV"
+
+     while the 'config/rs6000/eabiaix.h' target file defines
+     'CPP_SYSV_DEFAULT' as:
+
+          #undef CPP_SYSV_DEFAULT
+          #define CPP_SYSV_DEFAULT "-D_CALL_AIX"
+
+ -- Macro: LINK_LIBGCC_SPECIAL_1
+     Define this macro if the driver program should find the library
+     'libgcc.a'.  If you do not define this macro, the driver program
+     will pass the argument '-lgcc' to tell the linker to do the search.
+
+ -- Macro: LINK_GCC_C_SEQUENCE_SPEC
+     The sequence in which libgcc and libc are specified to the linker.
+     By default this is '%G %L %G'.
+
+ -- Macro: LINK_COMMAND_SPEC
+     A C string constant giving the complete command line need to
+     execute the linker.  When you do this, you will need to update your
+     port each time a change is made to the link command line within
+     'gcc.c'.  Therefore, define this macro only if you need to
+     completely redefine the command line for invoking the linker and
+     there is no other way to accomplish the effect you need.
+     Overriding this macro may be avoidable by overriding
+     'LINK_GCC_C_SEQUENCE_SPEC' instead.
+
+ -- Common Target Hook: bool TARGET_ALWAYS_STRIP_DOTDOT
+     True if '..' components should always be removed from directory
+     names computed relative to GCC's internal directories, false
+     (default) if such components should be preserved and directory
+     names containing them passed to other tools such as the linker.
+
+ -- Macro: MULTILIB_DEFAULTS
+     Define this macro as a C expression for the initializer of an array
+     of string to tell the driver program which options are defaults for
+     this target and thus do not need to be handled specially when using
+     'MULTILIB_OPTIONS'.
+
+     Do not define this macro if 'MULTILIB_OPTIONS' is not defined in
+     the target makefile fragment or if none of the options listed in
+     'MULTILIB_OPTIONS' are set by default.  *Note Target Fragment::.
+
+ -- Macro: RELATIVE_PREFIX_NOT_LINKDIR
+     Define this macro to tell 'gcc' that it should only translate a
+     '-B' prefix into a '-L' linker option if the prefix indicates an
+     absolute file name.
+
+ -- Macro: MD_EXEC_PREFIX
+     If defined, this macro is an additional prefix to try after
+     'STANDARD_EXEC_PREFIX'.  'MD_EXEC_PREFIX' is not searched when the
+     compiler is built as a cross compiler.  If you define
+     'MD_EXEC_PREFIX', then be sure to add it to the list of directories
+     used to find the assembler in 'configure.in'.
+
+ -- Macro: STANDARD_STARTFILE_PREFIX
+     Define this macro as a C string constant if you wish to override
+     the standard choice of 'libdir' as the default prefix to try when
+     searching for startup files such as 'crt0.o'.
+     'STANDARD_STARTFILE_PREFIX' is not searched when the compiler is
+     built as a cross compiler.
+
+ -- Macro: STANDARD_STARTFILE_PREFIX_1
+     Define this macro as a C string constant if you wish to override
+     the standard choice of '/lib' as a prefix to try after the default
+     prefix when searching for startup files such as 'crt0.o'.
+     'STANDARD_STARTFILE_PREFIX_1' is not searched when the compiler is
+     built as a cross compiler.
+
+ -- Macro: STANDARD_STARTFILE_PREFIX_2
+     Define this macro as a C string constant if you wish to override
+     the standard choice of '/lib' as yet another prefix to try after
+     the default prefix when searching for startup files such as
+     'crt0.o'.  'STANDARD_STARTFILE_PREFIX_2' is not searched when the
+     compiler is built as a cross compiler.
+
+ -- Macro: MD_STARTFILE_PREFIX
+     If defined, this macro supplies an additional prefix to try after
+     the standard prefixes.  'MD_EXEC_PREFIX' is not searched when the
+     compiler is built as a cross compiler.
+
+ -- Macro: MD_STARTFILE_PREFIX_1
+     If defined, this macro supplies yet another prefix to try after the
+     standard prefixes.  It is not searched when the compiler is built
+     as a cross compiler.
+
+ -- Macro: INIT_ENVIRONMENT
+     Define this macro as a C string constant if you wish to set
+     environment variables for programs called by the driver, such as
+     the assembler and loader.  The driver passes the value of this
+     macro to 'putenv' to initialize the necessary environment
+     variables.
+
+ -- Macro: LOCAL_INCLUDE_DIR
+     Define this macro as a C string constant if you wish to override
+     the standard choice of '/usr/local/include' as the default prefix
+     to try when searching for local header files.  'LOCAL_INCLUDE_DIR'
+     comes before 'NATIVE_SYSTEM_HEADER_DIR' (set in 'config.gcc',
+     normally '/usr/include') in the search order.
+
+     Cross compilers do not search either '/usr/local/include' or its
+     replacement.
+
+ -- Macro: NATIVE_SYSTEM_HEADER_COMPONENT
+     The "component" corresponding to 'NATIVE_SYSTEM_HEADER_DIR'.  See
+     'INCLUDE_DEFAULTS', below, for the description of components.  If
+     you do not define this macro, no component is used.
+
+ -- Macro: INCLUDE_DEFAULTS
+     Define this macro if you wish to override the entire default search
+     path for include files.  For a native compiler, the default search
+     path usually consists of 'GCC_INCLUDE_DIR', 'LOCAL_INCLUDE_DIR',
+     'GPLUSPLUS_INCLUDE_DIR', and 'NATIVE_SYSTEM_HEADER_DIR'.  In
+     addition, 'GPLUSPLUS_INCLUDE_DIR' and 'GCC_INCLUDE_DIR' are defined
+     automatically by 'Makefile', and specify private search areas for
+     GCC.  The directory 'GPLUSPLUS_INCLUDE_DIR' is used only for C++
+     programs.
+
+     The definition should be an initializer for an array of structures.
+     Each array element should have four elements: the directory name (a
+     string constant), the component name (also a string constant), a
+     flag for C++-only directories, and a flag showing that the includes
+     in the directory don't need to be wrapped in 'extern 'C'' when
+     compiling C++.  Mark the end of the array with a null element.
+
+     The component name denotes what GNU package the include file is
+     part of, if any, in all uppercase letters.  For example, it might
+     be 'GCC' or 'BINUTILS'.  If the package is part of a
+     vendor-supplied operating system, code the component name as '0'.
+
+     For example, here is the definition used for VAX/VMS:
+
+          #define INCLUDE_DEFAULTS \
+          {                                       \
+            { "GNU_GXX_INCLUDE:", "G++", 1, 1},   \
+            { "GNU_CC_INCLUDE:", "GCC", 0, 0},    \
+            { "SYS$SYSROOT:[SYSLIB.]", 0, 0, 0},  \
+            { ".", 0, 0, 0},                      \
+            { 0, 0, 0, 0}                         \
+          }
+
+ Here is the order of prefixes tried for exec files:
+
+  1. Any prefixes specified by the user with '-B'.
+
+  2. The environment variable 'GCC_EXEC_PREFIX' or, if 'GCC_EXEC_PREFIX'
+     is not set and the compiler has not been installed in the
+     configure-time PREFIX, the location in which the compiler has
+     actually been installed.
+
+  3. The directories specified by the environment variable
+     'COMPILER_PATH'.
+
+  4. The macro 'STANDARD_EXEC_PREFIX', if the compiler has been
+     installed in the configured-time PREFIX.
+
+  5. The location '/usr/libexec/gcc/', but only if this is a native
+     compiler.
+
+  6. The location '/usr/lib/gcc/', but only if this is a native
+     compiler.
+
+  7. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a
+     native compiler.
+
+ Here is the order of prefixes tried for startfiles:
+
+  1. Any prefixes specified by the user with '-B'.
+
+  2. The environment variable 'GCC_EXEC_PREFIX' or its automatically
+     determined value based on the installed toolchain location.
+
+  3. The directories specified by the environment variable
+     'LIBRARY_PATH' (or port-specific name; native only, cross compilers
+     do not use this).
+
+  4. The macro 'STANDARD_EXEC_PREFIX', but only if the toolchain is
+     installed in the configured PREFIX or this is a native compiler.
+
+  5. The location '/usr/lib/gcc/', but only if this is a native
+     compiler.
+
+  6. The macro 'MD_EXEC_PREFIX', if defined, but only if this is a
+     native compiler.
+
+  7. The macro 'MD_STARTFILE_PREFIX', if defined, but only if this is a
+     native compiler, or we have a target system root.
+
+  8. The macro 'MD_STARTFILE_PREFIX_1', if defined, but only if this is
+     a native compiler, or we have a target system root.
+
+  9. The macro 'STANDARD_STARTFILE_PREFIX', with any sysroot
+     modifications.  If this path is relative it will be prefixed by
+     'GCC_EXEC_PREFIX' and the machine suffix or 'STANDARD_EXEC_PREFIX'
+     and the machine suffix.
+
+  10. The macro 'STANDARD_STARTFILE_PREFIX_1', but only if this is a
+     native compiler, or we have a target system root.  The default for
+     this macro is '/lib/'.
+
+  11. The macro 'STANDARD_STARTFILE_PREFIX_2', but only if this is a
+     native compiler, or we have a target system root.  The default for
+     this macro is '/usr/lib/'.
+
+
+File: gccint.info,  Node: Run-time Target,  Next: Per-Function Data,  Prev: Driver,  Up: Target Macros
+
+17.3 Run-time Target Specification
+==================================
+
+Here are run-time target specifications.
+
+ -- Macro: TARGET_CPU_CPP_BUILTINS ()
+     This function-like macro expands to a block of code that defines
+     built-in preprocessor macros and assertions for the target CPU,
+     using the functions 'builtin_define', 'builtin_define_std' and
+     'builtin_assert'.  When the front end calls this macro it provides
+     a trailing semicolon, and since it has finished command line option
+     processing your code can use those results freely.
+
+     'builtin_assert' takes a string in the form you pass to the
+     command-line option '-A', such as 'cpu=mips', and creates the
+     assertion.  'builtin_define' takes a string in the form accepted by
+     option '-D' and unconditionally defines the macro.
+
+     'builtin_define_std' takes a string representing the name of an
+     object-like macro.  If it doesn't lie in the user's namespace,
+     'builtin_define_std' defines it unconditionally.  Otherwise, it
+     defines a version with two leading underscores, and another version
+     with two leading and trailing underscores, and defines the original
+     only if an ISO standard was not requested on the command line.  For
+     example, passing 'unix' defines '__unix', '__unix__' and possibly
+     'unix'; passing '_mips' defines '__mips', '__mips__' and possibly
+     '_mips', and passing '_ABI64' defines only '_ABI64'.
+
+     You can also test for the C dialect being compiled.  The variable
+     'c_language' is set to one of 'clk_c', 'clk_cplusplus' or
+     'clk_objective_c'.  Note that if we are preprocessing assembler,
+     this variable will be 'clk_c' but the function-like macro
+     'preprocessing_asm_p()' will return true, so you might want to
+     check for that first.  If you need to check for strict ANSI, the
+     variable 'flag_iso' can be used.  The function-like macro
+     'preprocessing_trad_p()' can be used to check for traditional
+     preprocessing.
+
+ -- Macro: TARGET_OS_CPP_BUILTINS ()
+     Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional
+     and is used for the target operating system instead.
+
+ -- Macro: TARGET_OBJFMT_CPP_BUILTINS ()
+     Similarly to 'TARGET_CPU_CPP_BUILTINS' but this macro is optional
+     and is used for the target object format.  'elfos.h' uses this
+     macro to define '__ELF__', so you probably do not need to define it
+     yourself.
+
+ -- Variable: extern int target_flags
+     This variable is declared in 'options.h', which is included before
+     any target-specific headers.
+
+ -- Common Target Hook: int TARGET_DEFAULT_TARGET_FLAGS
+     This variable specifies the initial value of 'target_flags'.  Its
+     default setting is 0.
+
+ -- Common Target Hook: bool TARGET_HANDLE_OPTION (struct gcc_options
+          *OPTS, struct gcc_options *OPTS_SET, const struct
+          cl_decoded_option *DECODED, location_t LOC)
+     This hook is called whenever the user specifies one of the
+     target-specific options described by the '.opt' definition files
+     (*note Options::).  It has the opportunity to do some
+     option-specific processing and should return true if the option is
+     valid.  The default definition does nothing but return true.
+
+     DECODED specifies the option and its arguments.  OPTS and OPTS_SET
+     are the 'gcc_options' structures to be used for storing option
+     state, and LOC is the location at which the option was passed
+     ('UNKNOWN_LOCATION' except for options passed via attributes).
+
+ -- C Target Hook: bool TARGET_HANDLE_C_OPTION (size_t CODE, const char
+          *ARG, int VALUE)
+     This target hook is called whenever the user specifies one of the
+     target-specific C language family options described by the '.opt'
+     definition files(*note Options::).  It has the opportunity to do
+     some option-specific processing and should return true if the
+     option is valid.  The arguments are like for
+     'TARGET_HANDLE_OPTION'.  The default definition does nothing but
+     return false.
+
+     In general, you should use 'TARGET_HANDLE_OPTION' to handle
+     options.  However, if processing an option requires routines that
+     are only available in the C (and related language) front ends, then
+     you should use 'TARGET_HANDLE_C_OPTION' instead.
+
+ -- C Target Hook: tree TARGET_OBJC_CONSTRUCT_STRING_OBJECT (tree
+          STRING)
+     Targets may provide a string object type that can be used within
+     and between C, C++ and their respective Objective-C dialects.  A
+     string object might, for example, embed encoding and length
+     information.  These objects are considered opaque to the compiler
+     and handled as references.  An ideal implementation makes the
+     composition of the string object match that of the Objective-C
+     'NSString' ('NXString' for GNUStep), allowing efficient
+     interworking between C-only and Objective-C code.  If a target
+     implements string objects then this hook should return a reference
+     to such an object constructed from the normal 'C' string
+     representation provided in STRING.  At present, the hook is used by
+     Objective-C only, to obtain a common-format string object when the
+     target provides one.
+
+ -- C Target Hook: void TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE
+          (const char *CLASSNAME)
+     Declare that Objective C class CLASSNAME is referenced by the
+     current TU.
+
+ -- C Target Hook: void TARGET_OBJC_DECLARE_CLASS_DEFINITION (const char
+          *CLASSNAME)
+     Declare that Objective C class CLASSNAME is defined by the current
+     TU.
+
+ -- C Target Hook: bool TARGET_STRING_OBJECT_REF_TYPE_P (const_tree
+          STRINGREF)
+     If a target implements string objects then this hook should return
+     'true' if STRINGREF is a valid reference to such an object.
+
+ -- C Target Hook: void TARGET_CHECK_STRING_OBJECT_FORMAT_ARG (tree
+          FORMAT_ARG, tree ARGS_LIST)
+     If a target implements string objects then this hook should should
+     provide a facility to check the function arguments in ARGS_LIST
+     against the format specifiers in FORMAT_ARG where the type of
+     FORMAT_ARG is one recognized as a valid string reference type.
+
+ -- Target Hook: void TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE (void)
+     This target function is similar to the hook
+     'TARGET_OPTION_OVERRIDE' but is called when the optimize level is
+     changed via an attribute or pragma or when it is reset at the end
+     of the code affected by the attribute or pragma.  It is not called
+     at the beginning of compilation when 'TARGET_OPTION_OVERRIDE' is
+     called so if you want to perform these actions then, you should
+     have 'TARGET_OPTION_OVERRIDE' call
+     'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'.
+
+ -- Macro: C_COMMON_OVERRIDE_OPTIONS
+     This is similar to the 'TARGET_OPTION_OVERRIDE' hook but is only
+     used in the C language frontends (C, Objective-C, C++,
+     Objective-C++) and so can be used to alter option flag variables
+     which only exist in those frontends.
+
+ -- Common Target Hook: const struct default_options *
+          TARGET_OPTION_OPTIMIZATION_TABLE
+     Some machines may desire to change what optimizations are performed
+     for various optimization levels.  This variable, if defined,
+     describes options to enable at particular sets of optimization
+     levels.  These options are processed once just after the
+     optimization level is determined and before the remainder of the
+     command options have been parsed, so may be overridden by other
+     options passed explicitly.
+
+     This processing is run once at program startup and when the
+     optimization options are changed via '#pragma GCC optimize' or by
+     using the 'optimize' attribute.
+
+ -- Common Target Hook: void TARGET_OPTION_INIT_STRUCT (struct
+          gcc_options *OPTS)
+     Set target-dependent initial values of fields in OPTS.
+
+ -- Common Target Hook: void TARGET_OPTION_DEFAULT_PARAMS (void)
+     Set target-dependent default values for '--param' settings, using
+     calls to 'set_default_param_value'.
+
+ -- Macro: SWITCHABLE_TARGET
+     Some targets need to switch between substantially different
+     subtargets during compilation.  For example, the MIPS target has
+     one subtarget for the traditional MIPS architecture and another for
+     MIPS16.  Source code can switch between these two subarchitectures
+     using the 'mips16' and 'nomips16' attributes.
+
+     Such subtargets can differ in things like the set of available
+     registers, the set of available instructions, the costs of various
+     operations, and so on.  GCC caches a lot of this type of
+     information in global variables, and recomputing them for each
+     subtarget takes a significant amount of time.  The compiler
+     therefore provides a facility for maintaining several versions of
+     the global variables and quickly switching between them; see
+     'target-globals.h' for details.
+
+     Define this macro to 1 if your target needs this facility.  The
+     default is 0.
+
+ -- Target Hook: bool TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P
+          (void)
+     Returns true if the target supports IEEE 754 floating-point
+     exceptions and rounding modes, false otherwise.  This is intended
+     to relate to the 'float' and 'double' types, but not necessarily
+     'long double'.  By default, returns true if the 'adddf3'
+     instruction pattern is available and false otherwise, on the
+     assumption that hardware floating point supports exceptions and
+     rounding modes but software floating point does not.
+
+
+File: gccint.info,  Node: Per-Function Data,  Next: Storage Layout,  Prev: Run-time Target,  Up: Target Macros
+
+17.4 Defining data structures for per-function information.
+===========================================================
+
+If the target needs to store information on a per-function basis, GCC
+provides a macro and a couple of variables to allow this.  Note, just
+using statics to store the information is a bad idea, since GCC supports
+nested functions, so you can be halfway through encoding one function
+when another one comes along.
+
+ GCC defines a data structure called 'struct function' which contains
+all of the data specific to an individual function.  This structure
+contains a field called 'machine' whose type is 'struct machine_function
+*', which can be used by targets to point to their own specific data.
+
+ If a target needs per-function specific data it should define the type
+'struct machine_function' and also the macro 'INIT_EXPANDERS'.  This
+macro should be used to initialize the function pointer
+'init_machine_status'.  This pointer is explained below.
+
+ One typical use of per-function, target specific data is to create an
+RTX to hold the register containing the function's return address.  This
+RTX can then be used to implement the '__builtin_return_address'
+function, for level 0.
+
+ Note--earlier implementations of GCC used a single data area to hold
+all of the per-function information.  Thus when processing of a nested
+function began the old per-function data had to be pushed onto a stack,
+and when the processing was finished, it had to be popped off the stack.
+GCC used to provide function pointers called 'save_machine_status' and
+'restore_machine_status' to handle the saving and restoring of the
+target specific information.  Since the single data area approach is no
+longer used, these pointers are no longer supported.
+
+ -- Macro: INIT_EXPANDERS
+     Macro called to initialize any target specific information.  This
+     macro is called once per function, before generation of any RTL has
+     begun.  The intention of this macro is to allow the initialization
+     of the function pointer 'init_machine_status'.
+
+ -- Variable: void (*)(struct function *) init_machine_status
+     If this function pointer is non-'NULL' it will be called once per
+     function, before function compilation starts, in order to allow the
+     target to perform any target specific initialization of the 'struct
+     function' structure.  It is intended that this would be used to
+     initialize the 'machine' of that structure.
+
+     'struct machine_function' structures are expected to be freed by
+     GC.  Generally, any memory that they reference must be allocated by
+     using GC allocation, including the structure itself.
+
+
+File: gccint.info,  Node: Storage Layout,  Next: Type Layout,  Prev: Per-Function Data,  Up: Target Macros
+
+17.5 Storage Layout
+===================
+
+Note that the definitions of the macros in this table which are sizes or
+alignments measured in bits do not need to be constant.  They can be C
+expressions that refer to static variables, such as the 'target_flags'.
+*Note Run-time Target::.
+
+ -- Macro: BITS_BIG_ENDIAN
+     Define this macro to have the value 1 if the most significant bit
+     in a byte has the lowest number; otherwise define it to have the
+     value zero.  This means that bit-field instructions count from the
+     most significant bit.  If the machine has no bit-field
+     instructions, then this must still be defined, but it doesn't
+     matter which value it is defined to.  This macro need not be a
+     constant.
+
+     This macro does not affect the way structure fields are packed into
+     bytes or words; that is controlled by 'BYTES_BIG_ENDIAN'.
+
+ -- Macro: BYTES_BIG_ENDIAN
+     Define this macro to have the value 1 if the most significant byte
+     in a word has the lowest number.  This macro need not be a
+     constant.
+
+ -- Macro: WORDS_BIG_ENDIAN
+     Define this macro to have the value 1 if, in a multiword object,
+     the most significant word has the lowest number.  This applies to
+     both memory locations and registers; see 'REG_WORDS_BIG_ENDIAN' if
+     the order of words in memory is not the same as the order in
+     registers.  This macro need not be a constant.
+
+ -- Macro: REG_WORDS_BIG_ENDIAN
+     On some machines, the order of words in a multiword object differs
+     between registers in memory.  In such a situation, define this
+     macro to describe the order of words in a register.  The macro
+     'WORDS_BIG_ENDIAN' controls the order of words in memory.
+
+ -- Macro: FLOAT_WORDS_BIG_ENDIAN
+     Define this macro to have the value 1 if 'DFmode', 'XFmode' or
+     'TFmode' floating point numbers are stored in memory with the word
+     containing the sign bit at the lowest address; otherwise define it
+     to have the value 0.  This macro need not be a constant.
+
+     You need not define this macro if the ordering is the same as for
+     multi-word integers.
+
+ -- Macro: BITS_PER_WORD
+     Number of bits in a word.  If you do not define this macro, the
+     default is 'BITS_PER_UNIT * UNITS_PER_WORD'.
+
+ -- Macro: MAX_BITS_PER_WORD
+     Maximum number of bits in a word.  If this is undefined, the
+     default is 'BITS_PER_WORD'.  Otherwise, it is the constant value
+     that is the largest value that 'BITS_PER_WORD' can have at
+     run-time.
+
+ -- Macro: UNITS_PER_WORD
+     Number of storage units in a word; normally the size of a
+     general-purpose register, a power of two from 1 or 8.
+
+ -- Macro: MIN_UNITS_PER_WORD
+     Minimum number of units in a word.  If this is undefined, the
+     default is 'UNITS_PER_WORD'.  Otherwise, it is the constant value
+     that is the smallest value that 'UNITS_PER_WORD' can have at
+     run-time.
+
+ -- Macro: POINTER_SIZE
+     Width of a pointer, in bits.  You must specify a value no wider
+     than the width of 'Pmode'.  If it is not equal to the width of
+     'Pmode', you must define 'POINTERS_EXTEND_UNSIGNED'.  If you do not
+     specify a value the default is 'BITS_PER_WORD'.
+
+ -- Macro: POINTERS_EXTEND_UNSIGNED
+     A C expression that determines how pointers should be extended from
+     'ptr_mode' to either 'Pmode' or 'word_mode'.  It is greater than
+     zero if pointers should be zero-extended, zero if they should be
+     sign-extended, and negative if some other sort of conversion is
+     needed.  In the last case, the extension is done by the target's
+     'ptr_extend' instruction.
+
+     You need not define this macro if the 'ptr_mode', 'Pmode' and
+     'word_mode' are all the same width.
+
+ -- Macro: PROMOTE_MODE (M, UNSIGNEDP, TYPE)
+     A macro to update M and UNSIGNEDP when an object whose type is TYPE
+     and which has the specified mode and signedness is to be stored in
+     a register.  This macro is only called when TYPE is a scalar type.
+
+     On most RISC machines, which only have operations that operate on a
+     full register, define this macro to set M to 'word_mode' if M is an
+     integer mode narrower than 'BITS_PER_WORD'.  In most cases, only
+     integer modes should be widened because wider-precision
+     floating-point operations are usually more expensive than their
+     narrower counterparts.
+
+     For most machines, the macro definition does not change UNSIGNEDP.
+     However, some machines, have instructions that preferentially
+     handle either signed or unsigned quantities of certain modes.  For
+     example, on the DEC Alpha, 32-bit loads from memory and 32-bit add
+     instructions sign-extend the result to 64 bits.  On such machines,
+     set UNSIGNEDP according to which kind of extension is more
+     efficient.
+
+     Do not define this macro if it would never modify M.
+
+ -- Target Hook: enum machine_mode TARGET_PROMOTE_FUNCTION_MODE
+          (const_tree TYPE, enum machine_mode MODE, int *PUNSIGNEDP,
+          const_tree FUNTYPE, int FOR_RETURN)
+     Like 'PROMOTE_MODE', but it is applied to outgoing function
+     arguments or function return values.  The target hook should return
+     the new mode and possibly change '*PUNSIGNEDP' if the promotion
+     should change signedness.  This function is called only for scalar
+     _or pointer_ types.
+
+     FOR_RETURN allows to distinguish the promotion of arguments and
+     return values.  If it is '1', a return value is being promoted and
+     'TARGET_FUNCTION_VALUE' must perform the same promotions done here.
+     If it is '2', the returned mode should be that of the register in
+     which an incoming parameter is copied, or the outgoing result is
+     computed; then the hook should return the same mode as
+     'promote_mode', though the signedness may be different.
+
+     TYPE can be NULL when promoting function arguments of libcalls.
+
+     The default is to not promote arguments and return values.  You can
+     also define the hook to
+     'default_promote_function_mode_always_promote' if you would like to
+     apply the same rules given by 'PROMOTE_MODE'.
+
+ -- Macro: PARM_BOUNDARY
+     Normal alignment required for function parameters on the stack, in
+     bits.  All stack parameters receive at least this much alignment
+     regardless of data type.  On most machines, this is the same as the
+     size of an integer.
+
+ -- Macro: STACK_BOUNDARY
+     Define this macro to the minimum alignment enforced by hardware for
+     the stack pointer on this machine.  The definition is a C
+     expression for the desired alignment (measured in bits).  This
+     value is used as a default if 'PREFERRED_STACK_BOUNDARY' is not
+     defined.  On most machines, this should be the same as
+     'PARM_BOUNDARY'.
+
+ -- Macro: PREFERRED_STACK_BOUNDARY
+     Define this macro if you wish to preserve a certain alignment for
+     the stack pointer, greater than what the hardware enforces.  The
+     definition is a C expression for the desired alignment (measured in
+     bits).  This macro must evaluate to a value equal to or larger than
+     'STACK_BOUNDARY'.
+
+ -- Macro: INCOMING_STACK_BOUNDARY
+     Define this macro if the incoming stack boundary may be different
+     from 'PREFERRED_STACK_BOUNDARY'.  This macro must evaluate to a
+     value equal to or larger than 'STACK_BOUNDARY'.
+
+ -- Macro: FUNCTION_BOUNDARY
+     Alignment required for a function entry point, in bits.
+
+ -- Macro: BIGGEST_ALIGNMENT
+     Biggest alignment that any data type can require on this machine,
+     in bits.  Note that this is not the biggest alignment that is
+     supported, just the biggest alignment that, when violated, may
+     cause a fault.
+
+ -- Macro: MALLOC_ABI_ALIGNMENT
+     Alignment, in bits, a C conformant malloc implementation has to
+     provide.  If not defined, the default value is 'BITS_PER_WORD'.
+
+ -- Macro: ATTRIBUTE_ALIGNED_VALUE
+     Alignment used by the '__attribute__ ((aligned))' construct.  If
+     not defined, the default value is 'BIGGEST_ALIGNMENT'.
+
+ -- Macro: MINIMUM_ATOMIC_ALIGNMENT
+     If defined, the smallest alignment, in bits, that can be given to
+     an object that can be referenced in one operation, without
+     disturbing any nearby object.  Normally, this is 'BITS_PER_UNIT',
+     but may be larger on machines that don't have byte or half-word
+     store operations.
+
+ -- Macro: BIGGEST_FIELD_ALIGNMENT
+     Biggest alignment that any structure or union field can require on
+     this machine, in bits.  If defined, this overrides
+     'BIGGEST_ALIGNMENT' for structure and union fields only, unless the
+     field alignment has been set by the '__attribute__ ((aligned (N)))'
+     construct.
+
+ -- Macro: ADJUST_FIELD_ALIGN (FIELD, COMPUTED)
+     An expression for the alignment of a structure field FIELD if the
+     alignment computed in the usual way (including applying of
+     'BIGGEST_ALIGNMENT' and 'BIGGEST_FIELD_ALIGNMENT' to the alignment)
+     is COMPUTED.  It overrides alignment only if the field alignment
+     has not been set by the '__attribute__ ((aligned (N)))' construct.
+
+ -- Macro: MAX_STACK_ALIGNMENT
+     Biggest stack alignment guaranteed by the backend.  Use this macro
+     to specify the maximum alignment of a variable on stack.
+
+     If not defined, the default value is 'STACK_BOUNDARY'.
+
+ -- Macro: MAX_OFILE_ALIGNMENT
+     Biggest alignment supported by the object file format of this
+     machine.  Use this macro to limit the alignment which can be
+     specified using the '__attribute__ ((aligned (N)))' construct.  If
+     not defined, the default value is 'BIGGEST_ALIGNMENT'.
+
+     On systems that use ELF, the default (in 'config/elfos.h') is the
+     largest supported 32-bit ELF section alignment representable on a
+     32-bit host e.g.  '(((unsigned HOST_WIDEST_INT) 1 << 28) * 8)'.  On
+     32-bit ELF the largest supported section alignment in bits is
+     '(0x80000000 * 8)', but this is not representable on 32-bit hosts.
+
+ -- Macro: DATA_ALIGNMENT (TYPE, BASIC-ALIGN)
+     If defined, a C expression to compute the alignment for a variable
+     in the static store.  TYPE is the data type, and BASIC-ALIGN is the
+     alignment that the object would ordinarily have.  The value of this
+     macro is used instead of that alignment to align the object.
+
+     If this macro is not defined, then BASIC-ALIGN is used.
+
+     One use of this macro is to increase alignment of medium-size data
+     to make it all fit in fewer cache lines.  Another is to cause
+     character arrays to be word-aligned so that 'strcpy' calls that
+     copy constants to character arrays can be done inline.
+
+ -- Macro: DATA_ABI_ALIGNMENT (TYPE, BASIC-ALIGN)
+     Similar to 'DATA_ALIGNMENT', but for the cases where the ABI
+     mandates some alignment increase, instead of optimization only
+     purposes.  E.g. AMD x86-64 psABI says that variables with array
+     type larger than 15 bytes must be aligned to 16 byte boundaries.
+
+     If this macro is not defined, then BASIC-ALIGN is used.
+
+ -- Macro: CONSTANT_ALIGNMENT (CONSTANT, BASIC-ALIGN)
+     If defined, a C expression to compute the alignment given to a
+     constant that is being placed in memory.  CONSTANT is the constant
+     and BASIC-ALIGN is the alignment that the object would ordinarily
+     have.  The value of this macro is used instead of that alignment to
+     align the object.
+
+     If this macro is not defined, then BASIC-ALIGN is used.
+
+     The typical use of this macro is to increase alignment for string
+     constants to be word aligned so that 'strcpy' calls that copy
+     constants can be done inline.
+
+ -- Macro: LOCAL_ALIGNMENT (TYPE, BASIC-ALIGN)
+     If defined, a C expression to compute the alignment for a variable
+     in the local store.  TYPE is the data type, and BASIC-ALIGN is the
+     alignment that the object would ordinarily have.  The value of this
+     macro is used instead of that alignment to align the object.
+
+     If this macro is not defined, then BASIC-ALIGN is used.
+
+     One use of this macro is to increase alignment of medium-size data
+     to make it all fit in fewer cache lines.
+
+     If the value of this macro has a type, it should be an unsigned
+     type.
+
+ -- Target Hook: HOST_WIDE_INT TARGET_VECTOR_ALIGNMENT (const_tree TYPE)
+     This hook can be used to define the alignment for a vector of type
+     TYPE, in order to comply with a platform ABI. The default is to
+     require natural alignment for vector types.  The alignment returned
+     by this hook must be a power-of-two multiple of the default
+     alignment of the vector element type.
+
+ -- Macro: STACK_SLOT_ALIGNMENT (TYPE, MODE, BASIC-ALIGN)
+     If defined, a C expression to compute the alignment for stack slot.
+     TYPE is the data type, MODE is the widest mode available, and
+     BASIC-ALIGN is the alignment that the slot would ordinarily have.
+     The value of this macro is used instead of that alignment to align
+     the slot.
+
+     If this macro is not defined, then BASIC-ALIGN is used when TYPE is
+     'NULL'.  Otherwise, 'LOCAL_ALIGNMENT' will be used.
+
+     This macro is to set alignment of stack slot to the maximum
+     alignment of all possible modes which the slot may have.
+
+     If the value of this macro has a type, it should be an unsigned
+     type.
+
+ -- Macro: LOCAL_DECL_ALIGNMENT (DECL)
+     If defined, a C expression to compute the alignment for a local
+     variable DECL.
+
+     If this macro is not defined, then 'LOCAL_ALIGNMENT (TREE_TYPE
+     (DECL), DECL_ALIGN (DECL))' is used.
+
+     One use of this macro is to increase alignment of medium-size data
+     to make it all fit in fewer cache lines.
+
+     If the value of this macro has a type, it should be an unsigned
+     type.
+
+ -- Macro: MINIMUM_ALIGNMENT (EXP, MODE, ALIGN)
+     If defined, a C expression to compute the minimum required
+     alignment for dynamic stack realignment purposes for EXP (a type or
+     decl), MODE, assuming normal alignment ALIGN.
+
+     If this macro is not defined, then ALIGN will be used.
+
+ -- Macro: EMPTY_FIELD_BOUNDARY
+     Alignment in bits to be given to a structure bit-field that follows
+     an empty field such as 'int : 0;'.
+
+     If 'PCC_BITFIELD_TYPE_MATTERS' is true, it overrides this macro.
+
+ -- Macro: STRUCTURE_SIZE_BOUNDARY
+     Number of bits which any structure or union's size must be a
+     multiple of.  Each structure or union's size is rounded up to a
+     multiple of this.
+
+     If you do not define this macro, the default is the same as
+     'BITS_PER_UNIT'.
+
+ -- Macro: STRICT_ALIGNMENT
+     Define this macro to be the value 1 if instructions will fail to
+     work if given data not on the nominal alignment.  If instructions
+     will merely go slower in that case, define this macro as 0.
+
+ -- Macro: PCC_BITFIELD_TYPE_MATTERS
+     Define this if you wish to imitate the way many other C compilers
+     handle alignment of bit-fields and the structures that contain
+     them.
+
+     The behavior is that the type written for a named bit-field ('int',
+     'short', or other integer type) imposes an alignment for the entire
+     structure, as if the structure really did contain an ordinary field
+     of that type.  In addition, the bit-field is placed within the
+     structure so that it would fit within such a field, not crossing a
+     boundary for it.
+
+     Thus, on most machines, a named bit-field whose type is written as
+     'int' would not cross a four-byte boundary, and would force
+     four-byte alignment for the whole structure.  (The alignment used
+     may not be four bytes; it is controlled by the other alignment
+     parameters.)
+
+     An unnamed bit-field will not affect the alignment of the
+     containing structure.
+
+     If the macro is defined, its definition should be a C expression; a
+     nonzero value for the expression enables this behavior.
+
+     Note that if this macro is not defined, or its value is zero, some
+     bit-fields may cross more than one alignment boundary.  The
+     compiler can support such references if there are 'insv', 'extv',
+     and 'extzv' insns that can directly reference memory.
+
+     The other known way of making bit-fields work is to define
+     'STRUCTURE_SIZE_BOUNDARY' as large as 'BIGGEST_ALIGNMENT'.  Then
+     every structure can be accessed with fullwords.
+
+     Unless the machine has bit-field instructions or you define
+     'STRUCTURE_SIZE_BOUNDARY' that way, you must define
+     'PCC_BITFIELD_TYPE_MATTERS' to have a nonzero value.
+
+     If your aim is to make GCC use the same conventions for laying out
+     bit-fields as are used by another compiler, here is how to
+     investigate what the other compiler does.  Compile and run this
+     program:
+
+          struct foo1
+          {
+            char x;
+            char :0;
+            char y;
+          };
+
+          struct foo2
+          {
+            char x;
+            int :0;
+            char y;
+          };
+
+          main ()
+          {
+            printf ("Size of foo1 is %d\n",
+                    sizeof (struct foo1));
+            printf ("Size of foo2 is %d\n",
+                    sizeof (struct foo2));
+            exit (0);
+          }
+
+     If this prints 2 and 5, then the compiler's behavior is what you
+     would get from 'PCC_BITFIELD_TYPE_MATTERS'.
+
+ -- Macro: BITFIELD_NBYTES_LIMITED
+     Like 'PCC_BITFIELD_TYPE_MATTERS' except that its effect is limited
+     to aligning a bit-field within the structure.
+
+ -- Target Hook: bool TARGET_ALIGN_ANON_BITFIELD (void)
+     When 'PCC_BITFIELD_TYPE_MATTERS' is true this hook will determine
+     whether unnamed bitfields affect the alignment of the containing
+     structure.  The hook should return true if the structure should
+     inherit the alignment requirements of an unnamed bitfield's type.
+
+ -- Target Hook: bool TARGET_NARROW_VOLATILE_BITFIELD (void)
+     This target hook should return 'true' if accesses to volatile
+     bitfields should use the narrowest mode possible.  It should return
+     'false' if these accesses should use the bitfield container type.
+
+     The default is 'false'.
+
+ -- Target Hook: bool TARGET_MEMBER_TYPE_FORCES_BLK (const_tree FIELD,
+          enum machine_mode MODE)
+     Return true if a structure, union or array containing FIELD should
+     be accessed using 'BLKMODE'.
+
+     If FIELD is the only field in the structure, MODE is its mode,
+     otherwise MODE is VOIDmode.  MODE is provided in the case where
+     structures of one field would require the structure's mode to
+     retain the field's mode.
+
+     Normally, this is not needed.
+
+ -- Macro: ROUND_TYPE_ALIGN (TYPE, COMPUTED, SPECIFIED)
+     Define this macro as an expression for the alignment of a type
+     (given by TYPE as a tree node) if the alignment computed in the
+     usual way is COMPUTED and the alignment explicitly specified was
+     SPECIFIED.
+
+     The default is to use SPECIFIED if it is larger; otherwise, use the
+     smaller of COMPUTED and 'BIGGEST_ALIGNMENT'
+
+ -- Macro: MAX_FIXED_MODE_SIZE
+     An integer expression for the size in bits of the largest integer
+     machine mode that should actually be used.  All integer machine
+     modes of this size or smaller can be used for structures and unions
+     with the appropriate sizes.  If this macro is undefined,
+     'GET_MODE_BITSIZE (DImode)' is assumed.
+
+ -- Macro: STACK_SAVEAREA_MODE (SAVE_LEVEL)
+     If defined, an expression of type 'enum machine_mode' that
+     specifies the mode of the save area operand of a 'save_stack_LEVEL'
+     named pattern (*note Standard Names::).  SAVE_LEVEL is one of
+     'SAVE_BLOCK', 'SAVE_FUNCTION', or 'SAVE_NONLOCAL' and selects which
+     of the three named patterns is having its mode specified.
+
+     You need not define this macro if it always returns 'Pmode'.  You
+     would most commonly define this macro if the 'save_stack_LEVEL'
+     patterns need to support both a 32- and a 64-bit mode.
+
+ -- Macro: STACK_SIZE_MODE
+     If defined, an expression of type 'enum machine_mode' that
+     specifies the mode of the size increment operand of an
+     'allocate_stack' named pattern (*note Standard Names::).
+
+     You need not define this macro if it always returns 'word_mode'.
+     You would most commonly define this macro if the 'allocate_stack'
+     pattern needs to support both a 32- and a 64-bit mode.
+
+ -- Target Hook: enum machine_mode TARGET_LIBGCC_CMP_RETURN_MODE (void)
+     This target hook should return the mode to be used for the return
+     value of compare instructions expanded to libgcc calls.  If not
+     defined 'word_mode' is returned which is the right choice for a
+     majority of targets.
+
+ -- Target Hook: enum machine_mode TARGET_LIBGCC_SHIFT_COUNT_MODE (void)
+     This target hook should return the mode to be used for the shift
+     count operand of shift instructions expanded to libgcc calls.  If
+     not defined 'word_mode' is returned which is the right choice for a
+     majority of targets.
+
+ -- Target Hook: enum machine_mode TARGET_UNWIND_WORD_MODE (void)
+     Return machine mode to be used for '_Unwind_Word' type.  The
+     default is to use 'word_mode'.
+
+ -- Macro: ROUND_TOWARDS_ZERO
+     If defined, this macro should be true if the prevailing rounding
+     mode is towards zero.
+
+     Defining this macro only affects the way 'libgcc.a' emulates
+     floating-point arithmetic.
+
+     Not defining this macro is equivalent to returning zero.
+
+ -- Macro: LARGEST_EXPONENT_IS_NORMAL (SIZE)
+     This macro should return true if floats with SIZE bits do not have
+     a NaN or infinity representation, but use the largest exponent for
+     normal numbers instead.
+
+     Defining this macro only affects the way 'libgcc.a' emulates
+     floating-point arithmetic.
+
+     The default definition of this macro returns false for all sizes.
+
+ -- Target Hook: bool TARGET_MS_BITFIELD_LAYOUT_P (const_tree
+          RECORD_TYPE)
+     This target hook returns 'true' if bit-fields in the given
+     RECORD_TYPE are to be laid out following the rules of Microsoft
+     Visual C/C++, namely: (i) a bit-field won't share the same storage
+     unit with the previous bit-field if their underlying types have
+     different sizes, and the bit-field will be aligned to the highest
+     alignment of the underlying types of itself and of the previous
+     bit-field; (ii) a zero-sized bit-field will affect the alignment of
+     the whole enclosing structure, even if it is unnamed; except that
+     (iii) a zero-sized bit-field will be disregarded unless it follows
+     another bit-field of nonzero size.  If this hook returns 'true',
+     other macros that control bit-field layout are ignored.
+
+     When a bit-field is inserted into a packed record, the whole size
+     of the underlying type is used by one or more same-size adjacent
+     bit-fields (that is, if its long:3, 32 bits is used in the record,
+     and any additional adjacent long bit-fields are packed into the
+     same chunk of 32 bits.  However, if the size changes, a new field
+     of that size is allocated).  In an unpacked record, this is the
+     same as using alignment, but not equivalent when packing.
+
+     If both MS bit-fields and '__attribute__((packed))' are used, the
+     latter will take precedence.  If '__attribute__((packed))' is used
+     on a single field when MS bit-fields are in use, it will take
+     precedence for that field, but the alignment of the rest of the
+     structure may affect its placement.
+
+ -- Target Hook: bool TARGET_DECIMAL_FLOAT_SUPPORTED_P (void)
+     Returns true if the target supports decimal floating point.
+
+ -- Target Hook: bool TARGET_FIXED_POINT_SUPPORTED_P (void)
+     Returns true if the target supports fixed-point arithmetic.
+
+ -- Target Hook: void TARGET_EXPAND_TO_RTL_HOOK (void)
+     This hook is called just before expansion into rtl, allowing the
+     target to perform additional initializations or analysis before the
+     expansion.  For example, the rs6000 port uses it to allocate a
+     scratch stack slot for use in copying SDmode values between memory
+     and floating point registers whenever the function being expanded
+     has any SDmode usage.
+
+ -- Target Hook: void TARGET_INSTANTIATE_DECLS (void)
+     This hook allows the backend to perform additional instantiations
+     on rtl that are not actually in any insns yet, but will be later.
+
+ -- Target Hook: const char * TARGET_MANGLE_TYPE (const_tree TYPE)
+     If your target defines any fundamental types, or any types your
+     target uses should be mangled differently from the default, define
+     this hook to return the appropriate encoding for these types as
+     part of a C++ mangled name.  The TYPE argument is the tree
+     structure representing the type to be mangled.  The hook may be
+     applied to trees which are not target-specific fundamental types;
+     it should return 'NULL' for all such types, as well as arguments it
+     does not recognize.  If the return value is not 'NULL', it must
+     point to a statically-allocated string constant.
+
+     Target-specific fundamental types might be new fundamental types or
+     qualified versions of ordinary fundamental types.  Encode new
+     fundamental types as 'u N NAME', where NAME is the name used for
+     the type in source code, and N is the length of NAME in decimal.
+     Encode qualified versions of ordinary types as 'U N NAME CODE',
+     where NAME is the name used for the type qualifier in source code,
+     N is the length of NAME as above, and CODE is the code used to
+     represent the unqualified version of this type.  (See
+     'write_builtin_type' in 'cp/mangle.c' for the list of codes.)  In
+     both cases the spaces are for clarity; do not include any spaces in
+     your string.
+
+     This hook is applied to types prior to typedef resolution.  If the
+     mangled name for a particular type depends only on that type's main
+     variant, you can perform typedef resolution yourself using
+     'TYPE_MAIN_VARIANT' before mangling.
+
+     The default version of this hook always returns 'NULL', which is
+     appropriate for a target that does not define any new fundamental
+     types.
+
+
+File: gccint.info,  Node: Type Layout,  Next: Registers,  Prev: Storage Layout,  Up: Target Macros
+
+17.6 Layout of Source Language Data Types
+=========================================
+
+These macros define the sizes and other characteristics of the standard
+basic data types used in programs being compiled.  Unlike the macros in
+the previous section, these apply to specific features of C and related
+languages, rather than to fundamental aspects of storage layout.
+
+ -- Macro: INT_TYPE_SIZE
+     A C expression for the size in bits of the type 'int' on the target
+     machine.  If you don't define this, the default is one word.
+
+ -- Macro: SHORT_TYPE_SIZE
+     A C expression for the size in bits of the type 'short' on the
+     target machine.  If you don't define this, the default is half a
+     word.  (If this would be less than one storage unit, it is rounded
+     up to one unit.)
+
+ -- Macro: LONG_TYPE_SIZE
+     A C expression for the size in bits of the type 'long' on the
+     target machine.  If you don't define this, the default is one word.
+
+ -- Macro: ADA_LONG_TYPE_SIZE
+     On some machines, the size used for the Ada equivalent of the type
+     'long' by a native Ada compiler differs from that used by C.  In
+     that situation, define this macro to be a C expression to be used
+     for the size of that type.  If you don't define this, the default
+     is the value of 'LONG_TYPE_SIZE'.
+
+ -- Macro: LONG_LONG_TYPE_SIZE
+     A C expression for the size in bits of the type 'long long' on the
+     target machine.  If you don't define this, the default is two
+     words.  If you want to support GNU Ada on your machine, the value
+     of this macro must be at least 64.
+
+ -- Macro: CHAR_TYPE_SIZE
+     A C expression for the size in bits of the type 'char' on the
+     target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT'.
+
+ -- Macro: BOOL_TYPE_SIZE
+     A C expression for the size in bits of the C++ type 'bool' and C99
+     type '_Bool' on the target machine.  If you don't define this, and
+     you probably shouldn't, the default is 'CHAR_TYPE_SIZE'.
+
+ -- Macro: FLOAT_TYPE_SIZE
+     A C expression for the size in bits of the type 'float' on the
+     target machine.  If you don't define this, the default is one word.
+
+ -- Macro: DOUBLE_TYPE_SIZE
+     A C expression for the size in bits of the type 'double' on the
+     target machine.  If you don't define this, the default is two
+     words.
+
+ -- Macro: LONG_DOUBLE_TYPE_SIZE
+     A C expression for the size in bits of the type 'long double' on
+     the target machine.  If you don't define this, the default is two
+     words.
+
+ -- Macro: SHORT_FRACT_TYPE_SIZE
+     A C expression for the size in bits of the type 'short _Fract' on
+     the target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT'.
+
+ -- Macro: FRACT_TYPE_SIZE
+     A C expression for the size in bits of the type '_Fract' on the
+     target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT * 2'.
+
+ -- Macro: LONG_FRACT_TYPE_SIZE
+     A C expression for the size in bits of the type 'long _Fract' on
+     the target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT * 4'.
+
+ -- Macro: LONG_LONG_FRACT_TYPE_SIZE
+     A C expression for the size in bits of the type 'long long _Fract'
+     on the target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT * 8'.
+
+ -- Macro: SHORT_ACCUM_TYPE_SIZE
+     A C expression for the size in bits of the type 'short _Accum' on
+     the target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT * 2'.
+
+ -- Macro: ACCUM_TYPE_SIZE
+     A C expression for the size in bits of the type '_Accum' on the
+     target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT * 4'.
+
+ -- Macro: LONG_ACCUM_TYPE_SIZE
+     A C expression for the size in bits of the type 'long _Accum' on
+     the target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT * 8'.
+
+ -- Macro: LONG_LONG_ACCUM_TYPE_SIZE
+     A C expression for the size in bits of the type 'long long _Accum'
+     on the target machine.  If you don't define this, the default is
+     'BITS_PER_UNIT * 16'.
+
+ -- Macro: LIBGCC2_LONG_DOUBLE_TYPE_SIZE
+     Define this macro if 'LONG_DOUBLE_TYPE_SIZE' is not constant or if
+     you want routines in 'libgcc2.a' for a size other than
+     'LONG_DOUBLE_TYPE_SIZE'.  If you don't define this, the default is
+     'LONG_DOUBLE_TYPE_SIZE'.
+
+ -- Macro: LIBGCC2_HAS_DF_MODE
+     Define this macro if neither 'DOUBLE_TYPE_SIZE' nor
+     'LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 'DFmode' but you want 'DFmode'
+     routines in 'libgcc2.a' anyway.  If you don't define this and
+     either 'DOUBLE_TYPE_SIZE' or 'LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 64
+     then the default is 1, otherwise it is 0.
+
+ -- Macro: LIBGCC2_HAS_XF_MODE
+     Define this macro if 'LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
+     'XFmode' but you want 'XFmode' routines in 'libgcc2.a' anyway.  If
+     you don't define this and 'LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 80
+     then the default is 1, otherwise it is 0.
+
+ -- Macro: LIBGCC2_HAS_TF_MODE
+     Define this macro if 'LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is not
+     'TFmode' but you want 'TFmode' routines in 'libgcc2.a' anyway.  If
+     you don't define this and 'LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is 128
+     then the default is 1, otherwise it is 0.
+
+ -- Macro: LIBGCC2_GNU_PREFIX
+     This macro corresponds to the 'TARGET_LIBFUNC_GNU_PREFIX' target
+     hook and should be defined if that hook is overriden to be true.
+     It causes function names in libgcc to be changed to use a '__gnu_'
+     prefix for their name rather than the default '__'.  A port which
+     uses this macro should also arrange to use 't-gnu-prefix' in the
+     libgcc 'config.host'.
+
+ -- Macro: SF_SIZE
+ -- Macro: DF_SIZE
+ -- Macro: XF_SIZE
+ -- Macro: TF_SIZE
+     Define these macros to be the size in bits of the mantissa of
+     'SFmode', 'DFmode', 'XFmode' and 'TFmode' values, if the defaults
+     in 'libgcc2.h' are inappropriate.  By default, 'FLT_MANT_DIG' is
+     used for 'SF_SIZE', 'LDBL_MANT_DIG' for 'XF_SIZE' and 'TF_SIZE',
+     and 'DBL_MANT_DIG' or 'LDBL_MANT_DIG' for 'DF_SIZE' according to
+     whether 'DOUBLE_TYPE_SIZE' or 'LIBGCC2_LONG_DOUBLE_TYPE_SIZE' is
+     64.
+
+ -- Macro: TARGET_FLT_EVAL_METHOD
+     A C expression for the value for 'FLT_EVAL_METHOD' in 'float.h',
+     assuming, if applicable, that the floating-point control word is in
+     its default state.  If you do not define this macro the value of
+     'FLT_EVAL_METHOD' will be zero.
+
+ -- Macro: WIDEST_HARDWARE_FP_SIZE
+     A C expression for the size in bits of the widest floating-point
+     format supported by the hardware.  If you define this macro, you
+     must specify a value less than or equal to the value of
+     'LONG_DOUBLE_TYPE_SIZE'.  If you do not define this macro, the
+     value of 'LONG_DOUBLE_TYPE_SIZE' is the default.
+
+ -- Macro: DEFAULT_SIGNED_CHAR
+     An expression whose value is 1 or 0, according to whether the type
+     'char' should be signed or unsigned by default.  The user can
+     always override this default with the options '-fsigned-char' and
+     '-funsigned-char'.
+
+ -- Target Hook: bool TARGET_DEFAULT_SHORT_ENUMS (void)
+     This target hook should return true if the compiler should give an
+     'enum' type only as many bytes as it takes to represent the range
+     of possible values of that type.  It should return false if all
+     'enum' types should be allocated like 'int'.
+
+     The default is to return false.
+
+ -- Macro: SIZE_TYPE
+     A C expression for a string describing the name of the data type to
+     use for size values.  The typedef name 'size_t' is defined using
+     the contents of the string.
+
+     The string can contain more than one keyword.  If so, separate them
+     with spaces, and write first any length keyword, then 'unsigned' if
+     appropriate, and finally 'int'.  The string must exactly match one
+     of the data type names defined in the function
+     'c_common_nodes_and_builtins' in the file 'c-family/c-common.c'.
+     You may not omit 'int' or change the order--that would cause the
+     compiler to crash on startup.
+
+     If you don't define this macro, the default is '"long unsigned
+     int"'.
+
+ -- Macro: SIZETYPE
+     GCC defines internal types ('sizetype', 'ssizetype', 'bitsizetype'
+     and 'sbitsizetype') for expressions dealing with size.  This macro
+     is a C expression for a string describing the name of the data type
+     from which the precision of 'sizetype' is extracted.
+
+     The string has the same restrictions as 'SIZE_TYPE' string.
+
+     If you don't define this macro, the default is 'SIZE_TYPE'.
+
+ -- Macro: PTRDIFF_TYPE
+     A C expression for a string describing the name of the data type to
+     use for the result of subtracting two pointers.  The typedef name
+     'ptrdiff_t' is defined using the contents of the string.  See
+     'SIZE_TYPE' above for more information.
+
+     If you don't define this macro, the default is '"long int"'.
+
+ -- Macro: WCHAR_TYPE
+     A C expression for a string describing the name of the data type to
+     use for wide characters.  The typedef name 'wchar_t' is defined
+     using the contents of the string.  See 'SIZE_TYPE' above for more
+     information.
+
+     If you don't define this macro, the default is '"int"'.
+
+ -- Macro: WCHAR_TYPE_SIZE
+     A C expression for the size in bits of the data type for wide
+     characters.  This is used in 'cpp', which cannot make use of
+     'WCHAR_TYPE'.
+
+ -- Macro: WINT_TYPE
+     A C expression for a string describing the name of the data type to
+     use for wide characters passed to 'printf' and returned from
+     'getwc'.  The typedef name 'wint_t' is defined using the contents
+     of the string.  See 'SIZE_TYPE' above for more information.
+
+     If you don't define this macro, the default is '"unsigned int"'.
+
+ -- Macro: INTMAX_TYPE
+     A C expression for a string describing the name of the data type
+     that can represent any value of any standard or extended signed
+     integer type.  The typedef name 'intmax_t' is defined using the
+     contents of the string.  See 'SIZE_TYPE' above for more
+     information.
+
+     If you don't define this macro, the default is the first of
+     '"int"', '"long int"', or '"long long int"' that has as much
+     precision as 'long long int'.
+
+ -- Macro: UINTMAX_TYPE
+     A C expression for a string describing the name of the data type
+     that can represent any value of any standard or extended unsigned
+     integer type.  The typedef name 'uintmax_t' is defined using the
+     contents of the string.  See 'SIZE_TYPE' above for more
+     information.
+
+     If you don't define this macro, the default is the first of
+     '"unsigned int"', '"long unsigned int"', or '"long long unsigned
+     int"' that has as much precision as 'long long unsigned int'.
+
+ -- Macro: SIG_ATOMIC_TYPE
+ -- Macro: INT8_TYPE
+ -- Macro: INT16_TYPE
+ -- Macro: INT32_TYPE
+ -- Macro: INT64_TYPE
+ -- Macro: UINT8_TYPE
+ -- Macro: UINT16_TYPE
+ -- Macro: UINT32_TYPE
+ -- Macro: UINT64_TYPE
+ -- Macro: INT_LEAST8_TYPE
+ -- Macro: INT_LEAST16_TYPE
+ -- Macro: INT_LEAST32_TYPE
+ -- Macro: INT_LEAST64_TYPE
+ -- Macro: UINT_LEAST8_TYPE
+ -- Macro: UINT_LEAST16_TYPE
+ -- Macro: UINT_LEAST32_TYPE
+ -- Macro: UINT_LEAST64_TYPE
+ -- Macro: INT_FAST8_TYPE
+ -- Macro: INT_FAST16_TYPE
+ -- Macro: INT_FAST32_TYPE
+ -- Macro: INT_FAST64_TYPE
+ -- Macro: UINT_FAST8_TYPE
+ -- Macro: UINT_FAST16_TYPE
+ -- Macro: UINT_FAST32_TYPE
+ -- Macro: UINT_FAST64_TYPE
+ -- Macro: INTPTR_TYPE
+ -- Macro: UINTPTR_TYPE
+     C expressions for the standard types 'sig_atomic_t', 'int8_t',
+     'int16_t', 'int32_t', 'int64_t', 'uint8_t', 'uint16_t', 'uint32_t',
+     'uint64_t', 'int_least8_t', 'int_least16_t', 'int_least32_t',
+     'int_least64_t', 'uint_least8_t', 'uint_least16_t',
+     'uint_least32_t', 'uint_least64_t', 'int_fast8_t', 'int_fast16_t',
+     'int_fast32_t', 'int_fast64_t', 'uint_fast8_t', 'uint_fast16_t',
+     'uint_fast32_t', 'uint_fast64_t', 'intptr_t', and 'uintptr_t'.  See
+     'SIZE_TYPE' above for more information.
+
+     If any of these macros evaluates to a null pointer, the
+     corresponding type is not supported; if GCC is configured to
+     provide '<stdint.h>' in such a case, the header provided may not
+     conform to C99, depending on the type in question.  The defaults
+     for all of these macros are null pointers.
+
+ -- Macro: TARGET_PTRMEMFUNC_VBIT_LOCATION
+     The C++ compiler represents a pointer-to-member-function with a
+     struct that looks like:
+
+            struct {
+              union {
+                void (*fn)();
+                ptrdiff_t vtable_index;
+              };
+              ptrdiff_t delta;
+            };
+
+     The C++ compiler must use one bit to indicate whether the function
+     that will be called through a pointer-to-member-function is
+     virtual.  Normally, we assume that the low-order bit of a function
+     pointer must always be zero.  Then, by ensuring that the
+     vtable_index is odd, we can distinguish which variant of the union
+     is in use.  But, on some platforms function pointers can be odd,
+     and so this doesn't work.  In that case, we use the low-order bit
+     of the 'delta' field, and shift the remainder of the 'delta' field
+     to the left.
+
+     GCC will automatically make the right selection about where to
+     store this bit using the 'FUNCTION_BOUNDARY' setting for your
+     platform.  However, some platforms such as ARM/Thumb have
+     'FUNCTION_BOUNDARY' set such that functions always start at even
+     addresses, but the lowest bit of pointers to functions indicate
+     whether the function at that address is in ARM or Thumb mode.  If
+     this is the case of your architecture, you should define this macro
+     to 'ptrmemfunc_vbit_in_delta'.
+
+     In general, you should not have to define this macro.  On
+     architectures in which function addresses are always even,
+     according to 'FUNCTION_BOUNDARY', GCC will automatically define
+     this macro to 'ptrmemfunc_vbit_in_pfn'.
+
+ -- Macro: TARGET_VTABLE_USES_DESCRIPTORS
+     Normally, the C++ compiler uses function pointers in vtables.  This
+     macro allows the target to change to use "function descriptors"
+     instead.  Function descriptors are found on targets for whom a
+     function pointer is actually a small data structure.  Normally the
+     data structure consists of the actual code address plus a data
+     pointer to which the function's data is relative.
+
+     If vtables are used, the value of this macro should be the number
+     of words that the function descriptor occupies.
+
+ -- Macro: TARGET_VTABLE_ENTRY_ALIGN
+     By default, the vtable entries are void pointers, the so the
+     alignment is the same as pointer alignment.  The value of this
+     macro specifies the alignment of the vtable entry in bits.  It
+     should be defined only when special alignment is necessary.  */
+
+ -- Macro: TARGET_VTABLE_DATA_ENTRY_DISTANCE
+     There are a few non-descriptor entries in the vtable at offsets
+     below zero.  If these entries must be padded (say, to preserve the
+     alignment specified by 'TARGET_VTABLE_ENTRY_ALIGN'), set this to
+     the number of words in each data entry.
+
+
+File: gccint.info,  Node: Registers,  Next: Register Classes,  Prev: Type Layout,  Up: Target Macros
+
+17.7 Register Usage
+===================
+
+This section explains how to describe what registers the target machine
+has, and how (in general) they can be used.
+
+ The description of which registers a specific instruction can use is
+done with register classes; see *note Register Classes::.  For
+information on using registers to access a stack frame, see *note Frame
+Registers::.  For passing values in registers, see *note Register
+Arguments::.  For returning values in registers, see *note Scalar
+Return::.
+
+* Menu:
+
+* Register Basics::             Number and kinds of registers.
+* Allocation Order::            Order in which registers are allocated.
+* Values in Registers::         What kinds of values each reg can hold.
+* Leaf Functions::              Renumbering registers for leaf functions.
+* Stack Registers::             Handling a register stack such as 80387.
+
+
+File: gccint.info,  Node: Register Basics,  Next: Allocation Order,  Up: Registers
+
+17.7.1 Basic Characteristics of Registers
+-----------------------------------------
+
+Registers have various characteristics.
+
+ -- Macro: FIRST_PSEUDO_REGISTER
+     Number of hardware registers known to the compiler.  They receive
+     numbers 0 through 'FIRST_PSEUDO_REGISTER-1'; thus, the first pseudo
+     register's number really is assigned the number
+     'FIRST_PSEUDO_REGISTER'.
+
+ -- Macro: FIXED_REGISTERS
+     An initializer that says which registers are used for fixed
+     purposes all throughout the compiled code and are therefore not
+     available for general allocation.  These would include the stack
+     pointer, the frame pointer (except on machines where that can be
+     used as a general register when no frame pointer is needed), the
+     program counter on machines where that is considered one of the
+     addressable registers, and any other numbered register with a
+     standard use.
+
+     This information is expressed as a sequence of numbers, separated
+     by commas and surrounded by braces.  The Nth number is 1 if
+     register N is fixed, 0 otherwise.
+
+     The table initialized from this macro, and the table initialized by
+     the following one, may be overridden at run time either
+     automatically, by the actions of the macro
+     'CONDITIONAL_REGISTER_USAGE', or by the user with the command
+     options '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'.
+
+ -- Macro: CALL_USED_REGISTERS
+     Like 'FIXED_REGISTERS' but has 1 for each register that is
+     clobbered (in general) by function calls as well as for fixed
+     registers.  This macro therefore identifies the registers that are
+     not available for general allocation of values that must live
+     across function calls.
+
+     If a register has 0 in 'CALL_USED_REGISTERS', the compiler
+     automatically saves it on function entry and restores it on
+     function exit, if the register is used within the function.
+
+ -- Macro: CALL_REALLY_USED_REGISTERS
+     Like 'CALL_USED_REGISTERS' except this macro doesn't require that
+     the entire set of 'FIXED_REGISTERS' be included.
+     ('CALL_USED_REGISTERS' must be a superset of 'FIXED_REGISTERS').
+     This macro is optional.  If not specified, it defaults to the value
+     of 'CALL_USED_REGISTERS'.
+
+ -- Macro: HARD_REGNO_CALL_PART_CLOBBERED (REGNO, MODE)
+     A C expression that is nonzero if it is not permissible to store a
+     value of mode MODE in hard register number REGNO across a call
+     without some part of it being clobbered.  For most machines this
+     macro need not be defined.  It is only required for machines that
+     do not preserve the entire contents of a register across a call.
+
+ -- Target Hook: void TARGET_CONDITIONAL_REGISTER_USAGE (void)
+     This hook may conditionally modify five variables 'fixed_regs',
+     'call_used_regs', 'global_regs', 'reg_names', and
+     'reg_class_contents', to take into account any dependence of these
+     register sets on target flags.  The first three of these are of
+     type 'char []' (interpreted as Boolean vectors).  'global_regs' is
+     a 'const char *[]', and 'reg_class_contents' is a 'HARD_REG_SET'.
+     Before the macro is called, 'fixed_regs', 'call_used_regs',
+     'reg_class_contents', and 'reg_names' have been initialized from
+     'FIXED_REGISTERS', 'CALL_USED_REGISTERS', 'REG_CLASS_CONTENTS', and
+     'REGISTER_NAMES', respectively.  'global_regs' has been cleared,
+     and any '-ffixed-REG', '-fcall-used-REG' and '-fcall-saved-REG'
+     command options have been applied.
+
+     If the usage of an entire class of registers depends on the target
+     flags, you may indicate this to GCC by using this macro to modify
+     'fixed_regs' and 'call_used_regs' to 1 for each of the registers in
+     the classes which should not be used by GCC.  Also define the macro
+     'REG_CLASS_FROM_LETTER' / 'REG_CLASS_FROM_CONSTRAINT' to return
+     'NO_REGS' if it is called with a letter for a class that shouldn't
+     be used.
+
+     (However, if this class is not included in 'GENERAL_REGS' and all
+     of the insn patterns whose constraints permit this class are
+     controlled by target switches, then GCC will automatically avoid
+     using these registers when the target switches are opposed to
+     them.)
+
+ -- Macro: INCOMING_REGNO (OUT)
+     Define this macro if the target machine has register windows.  This
+     C expression returns the register number as seen by the called
+     function corresponding to the register number OUT as seen by the
+     calling function.  Return OUT if register number OUT is not an
+     outbound register.
+
+ -- Macro: OUTGOING_REGNO (IN)
+     Define this macro if the target machine has register windows.  This
+     C expression returns the register number as seen by the calling
+     function corresponding to the register number IN as seen by the
+     called function.  Return IN if register number IN is not an inbound
+     register.
+
+ -- Macro: LOCAL_REGNO (REGNO)
+     Define this macro if the target machine has register windows.  This
+     C expression returns true if the register is call-saved but is in
+     the register window.  Unlike most call-saved registers, such
+     registers need not be explicitly restored on function exit or
+     during non-local gotos.
+
+ -- Macro: PC_REGNUM
+     If the program counter has a register number, define this as that
+     register number.  Otherwise, do not define it.
+
+
+File: gccint.info,  Node: Allocation Order,  Next: Values in Registers,  Prev: Register Basics,  Up: Registers
+
+17.7.2 Order of Allocation of Registers
+---------------------------------------
+
+Registers are allocated in order.
+
+ -- Macro: REG_ALLOC_ORDER
+     If defined, an initializer for a vector of integers, containing the
+     numbers of hard registers in the order in which GCC should prefer
+     to use them (from most preferred to least).
+
+     If this macro is not defined, registers are used lowest numbered
+     first (all else being equal).
+
+     One use of this macro is on machines where the highest numbered
+     registers must always be saved and the save-multiple-registers
+     instruction supports only sequences of consecutive registers.  On
+     such machines, define 'REG_ALLOC_ORDER' to be an initializer that
+     lists the highest numbered allocable register first.
+
+ -- Macro: ADJUST_REG_ALLOC_ORDER
+     A C statement (sans semicolon) to choose the order in which to
+     allocate hard registers for pseudo-registers local to a basic
+     block.
+
+     Store the desired register order in the array 'reg_alloc_order'.
+     Element 0 should be the register to allocate first; element 1, the
+     next register; and so on.
+
+     The macro body should not assume anything about the contents of
+     'reg_alloc_order' before execution of the macro.
+
+     On most machines, it is not necessary to define this macro.
+
+ -- Macro: HONOR_REG_ALLOC_ORDER
+     Normally, IRA tries to estimate the costs for saving a register in
+     the prologue and restoring it in the epilogue.  This discourages it
+     from using call-saved registers.  If a machine wants to ensure that
+     IRA allocates registers in the order given by REG_ALLOC_ORDER even
+     if some call-saved registers appear earlier than call-used ones,
+     this macro should be defined.
+
+ -- Macro: IRA_HARD_REGNO_ADD_COST_MULTIPLIER (REGNO)
+     In some case register allocation order is not enough for the
+     Integrated Register Allocator (IRA) to generate a good code.  If
+     this macro is defined, it should return a floating point value
+     based on REGNO.  The cost of using REGNO for a pseudo will be
+     increased by approximately the pseudo's usage frequency times the
+     value returned by this macro.  Not defining this macro is
+     equivalent to having it always return '0.0'.
+
+     On most machines, it is not necessary to define this macro.
+
+
+File: gccint.info,  Node: Values in Registers,  Next: Leaf Functions,  Prev: Allocation Order,  Up: Registers
+
+17.7.3 How Values Fit in Registers
+----------------------------------
+
+This section discusses the macros that describe which kinds of values
+(specifically, which machine modes) each register can hold, and how many
+consecutive registers are needed for a given mode.
+
+ -- Macro: HARD_REGNO_NREGS (REGNO, MODE)
+     A C expression for the number of consecutive hard registers,
+     starting at register number REGNO, required to hold a value of mode
+     MODE.  This macro must never return zero, even if a register cannot
+     hold the requested mode - indicate that with HARD_REGNO_MODE_OK
+     and/or CANNOT_CHANGE_MODE_CLASS instead.
+
+     On a machine where all registers are exactly one word, a suitable
+     definition of this macro is
+
+          #define HARD_REGNO_NREGS(REGNO, MODE)            \
+             ((GET_MODE_SIZE (MODE) + UNITS_PER_WORD - 1)  \
+              / UNITS_PER_WORD)
+
+ -- Macro: HARD_REGNO_NREGS_HAS_PADDING (REGNO, MODE)
+     A C expression that is nonzero if a value of mode MODE, stored in
+     memory, ends with padding that causes it to take up more space than
+     in registers starting at register number REGNO (as determined by
+     multiplying GCC's notion of the size of the register when
+     containing this mode by the number of registers returned by
+     'HARD_REGNO_NREGS').  By default this is zero.
+
+     For example, if a floating-point value is stored in three 32-bit
+     registers but takes up 128 bits in memory, then this would be
+     nonzero.
+
+     This macros only needs to be defined if there are cases where
+     'subreg_get_info' would otherwise wrongly determine that a 'subreg'
+     can be represented by an offset to the register number, when in
+     fact such a 'subreg' would contain some of the padding not stored
+     in registers and so not be representable.
+
+ -- Macro: HARD_REGNO_NREGS_WITH_PADDING (REGNO, MODE)
+     For values of REGNO and MODE for which
+     'HARD_REGNO_NREGS_HAS_PADDING' returns nonzero, a C expression
+     returning the greater number of registers required to hold the
+     value including any padding.  In the example above, the value would
+     be four.
+
+ -- Macro: REGMODE_NATURAL_SIZE (MODE)
+     Define this macro if the natural size of registers that hold values
+     of mode MODE is not the word size.  It is a C expression that
+     should give the natural size in bytes for the specified mode.  It
+     is used by the register allocator to try to optimize its results.
+     This happens for example on SPARC 64-bit where the natural size of
+     floating-point registers is still 32-bit.
+
+ -- Macro: HARD_REGNO_MODE_OK (REGNO, MODE)
+     A C expression that is nonzero if it is permissible to store a
+     value of mode MODE in hard register number REGNO (or in several
+     registers starting with that one).  For a machine where all
+     registers are equivalent, a suitable definition is
+
+          #define HARD_REGNO_MODE_OK(REGNO, MODE) 1
+
+     You need not include code to check for the numbers of fixed
+     registers, because the allocation mechanism considers them to be
+     always occupied.
+
+     On some machines, double-precision values must be kept in even/odd
+     register pairs.  You can implement that by defining this macro to
+     reject odd register numbers for such modes.
+
+     The minimum requirement for a mode to be OK in a register is that
+     the 'movMODE' instruction pattern support moves between the
+     register and other hard register in the same class and that moving
+     a value into the register and back out not alter it.
+
+     Since the same instruction used to move 'word_mode' will work for
+     all narrower integer modes, it is not necessary on any machine for
+     'HARD_REGNO_MODE_OK' to distinguish between these modes, provided
+     you define patterns 'movhi', etc., to take advantage of this.  This
+     is useful because of the interaction between 'HARD_REGNO_MODE_OK'
+     and 'MODES_TIEABLE_P'; it is very desirable for all integer modes
+     to be tieable.
+
+     Many machines have special registers for floating point arithmetic.
+     Often people assume that floating point machine modes are allowed
+     only in floating point registers.  This is not true.  Any registers
+     that can hold integers can safely _hold_ a floating point machine
+     mode, whether or not floating arithmetic can be done on it in those
+     registers.  Integer move instructions can be used to move the
+     values.
+
+     On some machines, though, the converse is true: fixed-point machine
+     modes may not go in floating registers.  This is true if the
+     floating registers normalize any value stored in them, because
+     storing a non-floating value there would garble it.  In this case,
+     'HARD_REGNO_MODE_OK' should reject fixed-point machine modes in
+     floating registers.  But if the floating registers do not
+     automatically normalize, if you can store any bit pattern in one
+     and retrieve it unchanged without a trap, then any machine mode may
+     go in a floating register, so you can define this macro to say so.
+
+     The primary significance of special floating registers is rather
+     that they are the registers acceptable in floating point arithmetic
+     instructions.  However, this is of no concern to
+     'HARD_REGNO_MODE_OK'.  You handle it by writing the proper
+     constraints for those instructions.
+
+     On some machines, the floating registers are especially slow to
+     access, so that it is better to store a value in a stack frame than
+     in such a register if floating point arithmetic is not being done.
+     As long as the floating registers are not in class 'GENERAL_REGS',
+     they will not be used unless some pattern's constraint asks for
+     one.
+
+ -- Macro: HARD_REGNO_RENAME_OK (FROM, TO)
+     A C expression that is nonzero if it is OK to rename a hard
+     register FROM to another hard register TO.
+
+     One common use of this macro is to prevent renaming of a register
+     to another register that is not saved by a prologue in an interrupt
+     handler.
+
+     The default is always nonzero.
+
+ -- Macro: MODES_TIEABLE_P (MODE1, MODE2)
+     A C expression that is nonzero if a value of mode MODE1 is
+     accessible in mode MODE2 without copying.
+
+     If 'HARD_REGNO_MODE_OK (R, MODE1)' and 'HARD_REGNO_MODE_OK (R,
+     MODE2)' are always the same for any R, then 'MODES_TIEABLE_P
+     (MODE1, MODE2)' should be nonzero.  If they differ for any R, you
+     should define this macro to return zero unless some other mechanism
+     ensures the accessibility of the value in a narrower mode.
+
+     You should define this macro to return nonzero in as many cases as
+     possible since doing so will allow GCC to perform better register
+     allocation.
+
+ -- Target Hook: bool TARGET_HARD_REGNO_SCRATCH_OK (unsigned int REGNO)
+     This target hook should return 'true' if it is OK to use a hard
+     register REGNO as scratch reg in peephole2.
+
+     One common use of this macro is to prevent using of a register that
+     is not saved by a prologue in an interrupt handler.
+
+     The default version of this hook always returns 'true'.
+
+ -- Macro: AVOID_CCMODE_COPIES
+     Define this macro if the compiler should avoid copies to/from
+     'CCmode' registers.  You should only define this macro if support
+     for copying to/from 'CCmode' is incomplete.
+
+
+File: gccint.info,  Node: Leaf Functions,  Next: Stack Registers,  Prev: Values in Registers,  Up: Registers
+
+17.7.4 Handling Leaf Functions
+------------------------------
+
+On some machines, a leaf function (i.e., one which makes no calls) can
+run more efficiently if it does not make its own register window.  Often
+this means it is required to receive its arguments in the registers
+where they are passed by the caller, instead of the registers where they
+would normally arrive.
+
+ The special treatment for leaf functions generally applies only when
+other conditions are met; for example, often they may use only those
+registers for its own variables and temporaries.  We use the term "leaf
+function" to mean a function that is suitable for this special handling,
+so that functions with no calls are not necessarily "leaf functions".
+
+ GCC assigns register numbers before it knows whether the function is
+suitable for leaf function treatment.  So it needs to renumber the
+registers in order to output a leaf function.  The following macros
+accomplish this.
+
+ -- Macro: LEAF_REGISTERS
+     Name of a char vector, indexed by hard register number, which
+     contains 1 for a register that is allowable in a candidate for leaf
+     function treatment.
+
+     If leaf function treatment involves renumbering the registers, then
+     the registers marked here should be the ones before
+     renumbering--those that GCC would ordinarily allocate.  The
+     registers which will actually be used in the assembler code, after
+     renumbering, should not be marked with 1 in this vector.
+
+     Define this macro only if the target machine offers a way to
+     optimize the treatment of leaf functions.
+
+ -- Macro: LEAF_REG_REMAP (REGNO)
+     A C expression whose value is the register number to which REGNO
+     should be renumbered, when a function is treated as a leaf
+     function.
+
+     If REGNO is a register number which should not appear in a leaf
+     function before renumbering, then the expression should yield -1,
+     which will cause the compiler to abort.
+
+     Define this macro only if the target machine offers a way to
+     optimize the treatment of leaf functions, and registers need to be
+     renumbered to do this.
+
+ 'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE' must
+usually treat leaf functions specially.  They can test the C variable
+'current_function_is_leaf' which is nonzero for leaf functions.
+'current_function_is_leaf' is set prior to local register allocation and
+is valid for the remaining compiler passes.  They can also test the C
+variable 'current_function_uses_only_leaf_regs' which is nonzero for
+leaf functions which only use leaf registers.
+'current_function_uses_only_leaf_regs' is valid after all passes that
+modify the instructions have been run and is only useful if
+'LEAF_REGISTERS' is defined.
+
+
+File: gccint.info,  Node: Stack Registers,  Prev: Leaf Functions,  Up: Registers
+
+17.7.5 Registers That Form a Stack
+----------------------------------
+
+There are special features to handle computers where some of the
+"registers" form a stack.  Stack registers are normally written by
+pushing onto the stack, and are numbered relative to the top of the
+stack.
+
+ Currently, GCC can only handle one group of stack-like registers, and
+they must be consecutively numbered.  Furthermore, the existing support
+for stack-like registers is specific to the 80387 floating point
+coprocessor.  If you have a new architecture that uses stack-like
+registers, you will need to do substantial work on 'reg-stack.c' and
+write your machine description to cooperate with it, as well as defining
+these macros.
+
+ -- Macro: STACK_REGS
+     Define this if the machine has any stack-like registers.
+
+ -- Macro: STACK_REG_COVER_CLASS
+     This is a cover class containing the stack registers.  Define this
+     if the machine has any stack-like registers.
+
+ -- Macro: FIRST_STACK_REG
+     The number of the first stack-like register.  This one is the top
+     of the stack.
+
+ -- Macro: LAST_STACK_REG
+     The number of the last stack-like register.  This one is the bottom
+     of the stack.
+
+
+File: gccint.info,  Node: Register Classes,  Next: Old Constraints,  Prev: Registers,  Up: Target Macros
+
+17.8 Register Classes
+=====================
+
+On many machines, the numbered registers are not all equivalent.  For
+example, certain registers may not be allowed for indexed addressing;
+certain registers may not be allowed in some instructions.  These
+machine restrictions are described to the compiler using "register
+classes".
+
+ You define a number of register classes, giving each one a name and
+saying which of the registers belong to it.  Then you can specify
+register classes that are allowed as operands to particular instruction
+patterns.
+
+ In general, each register will belong to several classes.  In fact, one
+class must be named 'ALL_REGS' and contain all the registers.  Another
+class must be named 'NO_REGS' and contain no registers.  Often the union
+of two classes will be another class; however, this is not required.
+
+ One of the classes must be named 'GENERAL_REGS'.  There is nothing
+terribly special about the name, but the operand constraint letters 'r'
+and 'g' specify this class.  If 'GENERAL_REGS' is the same as
+'ALL_REGS', just define it as a macro which expands to 'ALL_REGS'.
+
+ Order the classes so that if class X is contained in class Y then X has
+a lower class number than Y.
+
+ The way classes other than 'GENERAL_REGS' are specified in operand
+constraints is through machine-dependent operand constraint letters.
+You can define such letters to correspond to various classes, then use
+them in operand constraints.
+
+ You must define the narrowest register classes for allocatable
+registers, so that each class either has no subclasses, or that for some
+mode, the move cost between registers within the class is cheaper than
+moving a register in the class to or from memory (*note Costs::).
+
+ You should define a class for the union of two classes whenever some
+instruction allows both classes.  For example, if an instruction allows
+either a floating point (coprocessor) register or a general register for
+a certain operand, you should define a class 'FLOAT_OR_GENERAL_REGS'
+which includes both of them.  Otherwise you will get suboptimal code, or
+even internal compiler errors when reload cannot find a register in the
+class computed via 'reg_class_subunion'.
+
+ You must also specify certain redundant information about the register
+classes: for each class, which classes contain it and which ones are
+contained in it; for each pair of classes, the largest class contained
+in their union.
+
+ When a value occupying several consecutive registers is expected in a
+certain class, all the registers used must belong to that class.
+Therefore, register classes cannot be used to enforce a requirement for
+a register pair to start with an even-numbered register.  The way to
+specify this requirement is with 'HARD_REGNO_MODE_OK'.
+
+ Register classes used for input-operands of bitwise-and or shift
+instructions have a special requirement: each such class must have, for
+each fixed-point machine mode, a subclass whose registers can transfer
+that mode to or from memory.  For example, on some machines, the
+operations for single-byte values ('QImode') are limited to certain
+registers.  When this is so, each register class that is used in a
+bitwise-and or shift instruction must have a subclass consisting of
+registers from which single-byte values can be loaded or stored.  This
+is so that 'PREFERRED_RELOAD_CLASS' can always have a possible value to
+return.
+
+ -- Data type: enum reg_class
+     An enumerated type that must be defined with all the register class
+     names as enumerated values.  'NO_REGS' must be first.  'ALL_REGS'
+     must be the last register class, followed by one more enumerated
+     value, 'LIM_REG_CLASSES', which is not a register class but rather
+     tells how many classes there are.
+
+     Each register class has a number, which is the value of casting the
+     class name to type 'int'.  The number serves as an index in many of
+     the tables described below.
+
+ -- Macro: N_REG_CLASSES
+     The number of distinct register classes, defined as follows:
+
+          #define N_REG_CLASSES (int) LIM_REG_CLASSES
+
+ -- Macro: REG_CLASS_NAMES
+     An initializer containing the names of the register classes as C
+     string constants.  These names are used in writing some of the
+     debugging dumps.
+
+ -- Macro: REG_CLASS_CONTENTS
+     An initializer containing the contents of the register classes, as
+     integers which are bit masks.  The Nth integer specifies the
+     contents of class N.  The way the integer MASK is interpreted is
+     that register R is in the class if 'MASK & (1 << R)' is 1.
+
+     When the machine has more than 32 registers, an integer does not
+     suffice.  Then the integers are replaced by sub-initializers,
+     braced groupings containing several integers.  Each sub-initializer
+     must be suitable as an initializer for the type 'HARD_REG_SET'
+     which is defined in 'hard-reg-set.h'.  In this situation, the first
+     integer in each sub-initializer corresponds to registers 0 through
+     31, the second integer to registers 32 through 63, and so on.
+
+ -- Macro: REGNO_REG_CLASS (REGNO)
+     A C expression whose value is a register class containing hard
+     register REGNO.  In general there is more than one such class;
+     choose a class which is "minimal", meaning that no smaller class
+     also contains the register.
+
+ -- Macro: BASE_REG_CLASS
+     A macro whose definition is the name of the class to which a valid
+     base register must belong.  A base register is one used in an
+     address which is the register value plus a displacement.
+
+ -- Macro: MODE_BASE_REG_CLASS (MODE)
+     This is a variation of the 'BASE_REG_CLASS' macro which allows the
+     selection of a base register in a mode dependent manner.  If MODE
+     is VOIDmode then it should return the same value as
+     'BASE_REG_CLASS'.
+
+ -- Macro: MODE_BASE_REG_REG_CLASS (MODE)
+     A C expression whose value is the register class to which a valid
+     base register must belong in order to be used in a base plus index
+     register address.  You should define this macro if base plus index
+     addresses have different requirements than other base register
+     uses.
+
+ -- Macro: MODE_CODE_BASE_REG_CLASS (MODE, ADDRESS_SPACE, OUTER_CODE,
+          INDEX_CODE)
+     A C expression whose value is the register class to which a valid
+     base register for a memory reference in mode MODE to address space
+     ADDRESS_SPACE must belong.  OUTER_CODE and INDEX_CODE define the
+     context in which the base register occurs.  OUTER_CODE is the code
+     of the immediately enclosing expression ('MEM' for the top level of
+     an address, 'ADDRESS' for something that occurs in an
+     'address_operand').  INDEX_CODE is the code of the corresponding
+     index expression if OUTER_CODE is 'PLUS'; 'SCRATCH' otherwise.
+
+ -- Macro: INDEX_REG_CLASS
+     A macro whose definition is the name of the class to which a valid
+     index register must belong.  An index register is one used in an
+     address where its value is either multiplied by a scale factor or
+     added to another register (as well as added to a displacement).
+
+ -- Macro: REGNO_OK_FOR_BASE_P (NUM)
+     A C expression which is nonzero if register number NUM is suitable
+     for use as a base register in operand addresses.
+
+ -- Macro: REGNO_MODE_OK_FOR_BASE_P (NUM, MODE)
+     A C expression that is just like 'REGNO_OK_FOR_BASE_P', except that
+     that expression may examine the mode of the memory reference in
+     MODE.  You should define this macro if the mode of the memory
+     reference affects whether a register may be used as a base
+     register.  If you define this macro, the compiler will use it
+     instead of 'REGNO_OK_FOR_BASE_P'.  The mode may be 'VOIDmode' for
+     addresses that appear outside a 'MEM', i.e., as an
+     'address_operand'.
+
+ -- Macro: REGNO_MODE_OK_FOR_REG_BASE_P (NUM, MODE)
+     A C expression which is nonzero if register number NUM is suitable
+     for use as a base register in base plus index operand addresses,
+     accessing memory in mode MODE.  It may be either a suitable hard
+     register or a pseudo register that has been allocated such a hard
+     register.  You should define this macro if base plus index
+     addresses have different requirements than other base register
+     uses.
+
+     Use of this macro is deprecated; please use the more general
+     'REGNO_MODE_CODE_OK_FOR_BASE_P'.
+
+ -- Macro: REGNO_MODE_CODE_OK_FOR_BASE_P (NUM, MODE, ADDRESS_SPACE,
+          OUTER_CODE, INDEX_CODE)
+     A C expression which is nonzero if register number NUM is suitable
+     for use as a base register in operand addresses, accessing memory
+     in mode MODE in address space ADDRESS_SPACE.  This is similar to
+     'REGNO_MODE_OK_FOR_BASE_P', except that that expression may examine
+     the context in which the register appears in the memory reference.
+     OUTER_CODE is the code of the immediately enclosing expression
+     ('MEM' if at the top level of the address, 'ADDRESS' for something
+     that occurs in an 'address_operand').  INDEX_CODE is the code of
+     the corresponding index expression if OUTER_CODE is 'PLUS';
+     'SCRATCH' otherwise.  The mode may be 'VOIDmode' for addresses that
+     appear outside a 'MEM', i.e., as an 'address_operand'.
+
+ -- Macro: REGNO_OK_FOR_INDEX_P (NUM)
+     A C expression which is nonzero if register number NUM is suitable
+     for use as an index register in operand addresses.  It may be
+     either a suitable hard register or a pseudo register that has been
+     allocated such a hard register.
+
+     The difference between an index register and a base register is
+     that the index register may be scaled.  If an address involves the
+     sum of two registers, neither one of them scaled, then either one
+     may be labeled the "base" and the other the "index"; but whichever
+     labeling is used must fit the machine's constraints of which
+     registers may serve in each capacity.  The compiler will try both
+     labelings, looking for one that is valid, and will reload one or
+     both registers only if neither labeling works.
+
+ -- Target Hook: reg_class_t TARGET_PREFERRED_RENAME_CLASS (reg_class_t
+          RCLASS)
+     A target hook that places additional preference on the register
+     class to use when it is necessary to rename a register in class
+     RCLASS to another class, or perhaps NO_REGS, if no preferred
+     register class is found or hook 'preferred_rename_class' is not
+     implemented.  Sometimes returning a more restrictive class makes
+     better code.  For example, on ARM, thumb-2 instructions using
+     'LO_REGS' may be smaller than instructions using 'GENERIC_REGS'.
+     By returning 'LO_REGS' from 'preferred_rename_class', code size can
+     be reduced.
+
+ -- Target Hook: reg_class_t TARGET_PREFERRED_RELOAD_CLASS (rtx X,
+          reg_class_t RCLASS)
+     A target hook that places additional restrictions on the register
+     class to use when it is necessary to copy value X into a register
+     in class RCLASS.  The value is a register class; perhaps RCLASS, or
+     perhaps another, smaller class.
+
+     The default version of this hook always returns value of 'rclass'
+     argument.
+
+     Sometimes returning a more restrictive class makes better code.
+     For example, on the 68000, when X is an integer constant that is in
+     range for a 'moveq' instruction, the value of this macro is always
+     'DATA_REGS' as long as RCLASS includes the data registers.
+     Requiring a data register guarantees that a 'moveq' will be used.
+
+     One case where 'TARGET_PREFERRED_RELOAD_CLASS' must not return
+     RCLASS is if X is a legitimate constant which cannot be loaded into
+     some register class.  By returning 'NO_REGS' you can force X into a
+     memory location.  For example, rs6000 can load immediate values
+     into general-purpose registers, but does not have an instruction
+     for loading an immediate value into a floating-point register, so
+     'TARGET_PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a
+     floating-point constant.  If the constant can't be loaded into any
+     kind of register, code generation will be better if
+     'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate
+     instead of using 'TARGET_PREFERRED_RELOAD_CLASS'.
+
+     If an insn has pseudos in it after register allocation, reload will
+     go through the alternatives and call repeatedly
+     'TARGET_PREFERRED_RELOAD_CLASS' to find the best one.  Returning
+     'NO_REGS', in this case, makes reload add a '!' in front of the
+     constraint: the x86 back-end uses this feature to discourage usage
+     of 387 registers when math is done in the SSE registers (and vice
+     versa).
+
+ -- Macro: PREFERRED_RELOAD_CLASS (X, CLASS)
+     A C expression that places additional restrictions on the register
+     class to use when it is necessary to copy value X into a register
+     in class CLASS.  The value is a register class; perhaps CLASS, or
+     perhaps another, smaller class.  On many machines, the following
+     definition is safe:
+
+          #define PREFERRED_RELOAD_CLASS(X,CLASS) CLASS
+
+     Sometimes returning a more restrictive class makes better code.
+     For example, on the 68000, when X is an integer constant that is in
+     range for a 'moveq' instruction, the value of this macro is always
+     'DATA_REGS' as long as CLASS includes the data registers.
+     Requiring a data register guarantees that a 'moveq' will be used.
+
+     One case where 'PREFERRED_RELOAD_CLASS' must not return CLASS is if
+     X is a legitimate constant which cannot be loaded into some
+     register class.  By returning 'NO_REGS' you can force X into a
+     memory location.  For example, rs6000 can load immediate values
+     into general-purpose registers, but does not have an instruction
+     for loading an immediate value into a floating-point register, so
+     'PREFERRED_RELOAD_CLASS' returns 'NO_REGS' when X is a
+     floating-point constant.  If the constant can't be loaded into any
+     kind of register, code generation will be better if
+     'TARGET_LEGITIMATE_CONSTANT_P' makes the constant illegitimate
+     instead of using 'TARGET_PREFERRED_RELOAD_CLASS'.
+
+     If an insn has pseudos in it after register allocation, reload will
+     go through the alternatives and call repeatedly
+     'PREFERRED_RELOAD_CLASS' to find the best one.  Returning
+     'NO_REGS', in this case, makes reload add a '!' in front of the
+     constraint: the x86 back-end uses this feature to discourage usage
+     of 387 registers when math is done in the SSE registers (and vice
+     versa).
+
+ -- Target Hook: reg_class_t TARGET_PREFERRED_OUTPUT_RELOAD_CLASS (rtx
+          X, reg_class_t RCLASS)
+     Like 'TARGET_PREFERRED_RELOAD_CLASS', but for output reloads
+     instead of input reloads.
+
+     The default version of this hook always returns value of 'rclass'
+     argument.
+
+     You can also use 'TARGET_PREFERRED_OUTPUT_RELOAD_CLASS' to
+     discourage reload from using some alternatives, like
+     'TARGET_PREFERRED_RELOAD_CLASS'.
+
+ -- Macro: LIMIT_RELOAD_CLASS (MODE, CLASS)
+     A C expression that places additional restrictions on the register
+     class to use when it is necessary to be able to hold a value of
+     mode MODE in a reload register for which class CLASS would
+     ordinarily be used.
+
+     Unlike 'PREFERRED_RELOAD_CLASS', this macro should be used when
+     there are certain modes that simply can't go in certain reload
+     classes.
+
+     The value is a register class; perhaps CLASS, or perhaps another,
+     smaller class.
+
+     Don't define this macro unless the target machine has limitations
+     which require the macro to do something nontrivial.
+
+ -- Target Hook: reg_class_t TARGET_SECONDARY_RELOAD (bool IN_P, rtx X,
+          reg_class_t RELOAD_CLASS, enum machine_mode RELOAD_MODE,
+          secondary_reload_info *SRI)
+     Many machines have some registers that cannot be copied directly to
+     or from memory or even from other types of registers.  An example
+     is the 'MQ' register, which on most machines, can only be copied to
+     or from general registers, but not memory.  Below, we shall be
+     using the term 'intermediate register' when a move operation cannot
+     be performed directly, but has to be done by copying the source
+     into the intermediate register first, and then copying the
+     intermediate register to the destination.  An intermediate register
+     always has the same mode as source and destination.  Since it holds
+     the actual value being copied, reload might apply optimizations to
+     re-use an intermediate register and eliding the copy from the
+     source when it can determine that the intermediate register still
+     holds the required value.
+
+     Another kind of secondary reload is required on some machines which
+     allow copying all registers to and from memory, but require a
+     scratch register for stores to some memory locations (e.g., those
+     with symbolic address on the RT, and those with certain symbolic
+     address on the SPARC when compiling PIC).  Scratch registers need
+     not have the same mode as the value being copied, and usually hold
+     a different value than that being copied.  Special patterns in the
+     md file are needed to describe how the copy is performed with the
+     help of the scratch register; these patterns also describe the
+     number, register class(es) and mode(s) of the scratch register(s).
+
+     In some cases, both an intermediate and a scratch register are
+     required.
+
+     For input reloads, this target hook is called with nonzero IN_P,
+     and X is an rtx that needs to be copied to a register of class
+     RELOAD_CLASS in RELOAD_MODE.  For output reloads, this target hook
+     is called with zero IN_P, and a register of class RELOAD_CLASS
+     needs to be copied to rtx X in RELOAD_MODE.
+
+     If copying a register of RELOAD_CLASS from/to X requires an
+     intermediate register, the hook 'secondary_reload' should return
+     the register class required for this intermediate register.  If no
+     intermediate register is required, it should return NO_REGS. If
+     more than one intermediate register is required, describe the one
+     that is closest in the copy chain to the reload register.
+
+     If scratch registers are needed, you also have to describe how to
+     perform the copy from/to the reload register to/from this closest
+     intermediate register.  Or if no intermediate register is required,
+     but still a scratch register is needed, describe the copy from/to
+     the reload register to/from the reload operand X.
+
+     You do this by setting 'sri->icode' to the instruction code of a
+     pattern in the md file which performs the move.  Operands 0 and 1
+     are the output and input of this copy, respectively.  Operands from
+     operand 2 onward are for scratch operands.  These scratch operands
+     must have a mode, and a single-register-class output constraint.
+
+     When an intermediate register is used, the 'secondary_reload' hook
+     will be called again to determine how to copy the intermediate
+     register to/from the reload operand X, so your hook must also have
+     code to handle the register class of the intermediate operand.
+
+     X might be a pseudo-register or a 'subreg' of a pseudo-register,
+     which could either be in a hard register or in memory.  Use
+     'true_regnum' to find out; it will return -1 if the pseudo is in
+     memory and the hard register number if it is in a register.
+
+     Scratch operands in memory (constraint '"=m"' / '"=&m"') are
+     currently not supported.  For the time being, you will have to
+     continue to use 'SECONDARY_MEMORY_NEEDED' for that purpose.
+
+     'copy_cost' also uses this target hook to find out how values are
+     copied.  If you want it to include some extra cost for the need to
+     allocate (a) scratch register(s), set 'sri->extra_cost' to the
+     additional cost.  Or if two dependent moves are supposed to have a
+     lower cost than the sum of the individual moves due to expected
+     fortuitous scheduling and/or special forwarding logic, you can set
+     'sri->extra_cost' to a negative amount.
+
+ -- Macro: SECONDARY_RELOAD_CLASS (CLASS, MODE, X)
+ -- Macro: SECONDARY_INPUT_RELOAD_CLASS (CLASS, MODE, X)
+ -- Macro: SECONDARY_OUTPUT_RELOAD_CLASS (CLASS, MODE, X)
+     These macros are obsolete, new ports should use the target hook
+     'TARGET_SECONDARY_RELOAD' instead.
+
+     These are obsolete macros, replaced by the
+     'TARGET_SECONDARY_RELOAD' target hook.  Older ports still define
+     these macros to indicate to the reload phase that it may need to
+     allocate at least one register for a reload in addition to the
+     register to contain the data.  Specifically, if copying X to a
+     register CLASS in MODE requires an intermediate register, you were
+     supposed to define 'SECONDARY_INPUT_RELOAD_CLASS' to return the
+     largest register class all of whose registers can be used as
+     intermediate registers or scratch registers.
+
+     If copying a register CLASS in MODE to X requires an intermediate
+     or scratch register, 'SECONDARY_OUTPUT_RELOAD_CLASS' was supposed
+     to be defined be defined to return the largest register class
+     required.  If the requirements for input and output reloads were
+     the same, the macro 'SECONDARY_RELOAD_CLASS' should have been used
+     instead of defining both macros identically.
+
+     The values returned by these macros are often 'GENERAL_REGS'.
+     Return 'NO_REGS' if no spare register is needed; i.e., if X can be
+     directly copied to or from a register of CLASS in MODE without
+     requiring a scratch register.  Do not define this macro if it would
+     always return 'NO_REGS'.
+
+     If a scratch register is required (either with or without an
+     intermediate register), you were supposed to define patterns for
+     'reload_inM' or 'reload_outM', as required (*note Standard Names::.
+     These patterns, which were normally implemented with a
+     'define_expand', should be similar to the 'movM' patterns, except
+     that operand 2 is the scratch register.
+
+     These patterns need constraints for the reload register and scratch
+     register that contain a single register class.  If the original
+     reload register (whose class is CLASS) can meet the constraint
+     given in the pattern, the value returned by these macros is used
+     for the class of the scratch register.  Otherwise, two additional
+     reload registers are required.  Their classes are obtained from the
+     constraints in the insn pattern.
+
+     X might be a pseudo-register or a 'subreg' of a pseudo-register,
+     which could either be in a hard register or in memory.  Use
+     'true_regnum' to find out; it will return -1 if the pseudo is in
+     memory and the hard register number if it is in a register.
+
+     These macros should not be used in the case where a particular
+     class of registers can only be copied to memory and not to another
+     class of registers.  In that case, secondary reload registers are
+     not needed and would not be helpful.  Instead, a stack location
+     must be used to perform the copy and the 'movM' pattern should use
+     memory as an intermediate storage.  This case often occurs between
+     floating-point and general registers.
+
+ -- Macro: SECONDARY_MEMORY_NEEDED (CLASS1, CLASS2, M)
+     Certain machines have the property that some registers cannot be
+     copied to some other registers without using memory.  Define this
+     macro on those machines to be a C expression that is nonzero if
+     objects of mode M in registers of CLASS1 can only be copied to
+     registers of class CLASS2 by storing a register of CLASS1 into
+     memory and loading that memory location into a register of CLASS2.
+
+     Do not define this macro if its value would always be zero.
+
+ -- Macro: SECONDARY_MEMORY_NEEDED_RTX (MODE)
+     Normally when 'SECONDARY_MEMORY_NEEDED' is defined, the compiler
+     allocates a stack slot for a memory location needed for register
+     copies.  If this macro is defined, the compiler instead uses the
+     memory location defined by this macro.
+
+     Do not define this macro if you do not define
+     'SECONDARY_MEMORY_NEEDED'.
+
+ -- Macro: SECONDARY_MEMORY_NEEDED_MODE (MODE)
+     When the compiler needs a secondary memory location to copy between
+     two registers of mode MODE, it normally allocates sufficient memory
+     to hold a quantity of 'BITS_PER_WORD' bits and performs the store
+     and load operations in a mode that many bits wide and whose class
+     is the same as that of MODE.
+
+     This is right thing to do on most machines because it ensures that
+     all bits of the register are copied and prevents accesses to the
+     registers in a narrower mode, which some machines prohibit for
+     floating-point registers.
+
+     However, this default behavior is not correct on some machines,
+     such as the DEC Alpha, that store short integers in floating-point
+     registers differently than in integer registers.  On those
+     machines, the default widening will not work correctly and you must
+     define this macro to suppress that widening in some cases.  See the
+     file 'alpha.h' for details.
+
+     Do not define this macro if you do not define
+     'SECONDARY_MEMORY_NEEDED' or if widening MODE to a mode that is
+     'BITS_PER_WORD' bits wide is correct for your machine.
+
+ -- Target Hook: bool TARGET_CLASS_LIKELY_SPILLED_P (reg_class_t RCLASS)
+     A target hook which returns 'true' if pseudos that have been
+     assigned to registers of class RCLASS would likely be spilled
+     because registers of RCLASS are needed for spill registers.
+
+     The default version of this target hook returns 'true' if RCLASS
+     has exactly one register and 'false' otherwise.  On most machines,
+     this default should be used.  For generally register-starved
+     machines, such as i386, or machines with right register
+     constraints, such as SH, this hook can be used to avoid excessive
+     spilling.
+
+     This hook is also used by some of the global intra-procedural code
+     transformations to throtle code motion, to avoid increasing
+     register pressure.
+
+ -- Target Hook: unsigned char TARGET_CLASS_MAX_NREGS (reg_class_t
+          RCLASS, enum machine_mode MODE)
+     A target hook returns the maximum number of consecutive registers
+     of class RCLASS needed to hold a value of mode MODE.
+
+     This is closely related to the macro 'HARD_REGNO_NREGS'.  In fact,
+     the value returned by 'TARGET_CLASS_MAX_NREGS (RCLASS, MODE)'
+     target hook should be the maximum value of 'HARD_REGNO_NREGS
+     (REGNO, MODE)' for all REGNO values in the class RCLASS.
+
+     This target hook helps control the handling of multiple-word values
+     in the reload pass.
+
+     The default version of this target hook returns the size of MODE in
+     words.
+
+ -- Macro: CLASS_MAX_NREGS (CLASS, MODE)
+     A C expression for the maximum number of consecutive registers of
+     class CLASS needed to hold a value of mode MODE.
+
+     This is closely related to the macro 'HARD_REGNO_NREGS'.  In fact,
+     the value of the macro 'CLASS_MAX_NREGS (CLASS, MODE)' should be
+     the maximum value of 'HARD_REGNO_NREGS (REGNO, MODE)' for all REGNO
+     values in the class CLASS.
+
+     This macro helps control the handling of multiple-word values in
+     the reload pass.
+
+ -- Macro: CANNOT_CHANGE_MODE_CLASS (FROM, TO, CLASS)
+     If defined, a C expression that returns nonzero for a CLASS for
+     which a change from mode FROM to mode TO is invalid.
+
+     For the example, loading 32-bit integer or floating-point objects
+     into floating-point registers on the Alpha extends them to 64 bits.
+     Therefore loading a 64-bit object and then storing it as a 32-bit
+     object does not store the low-order 32 bits, as would be the case
+     for a normal register.  Therefore, 'alpha.h' defines
+     'CANNOT_CHANGE_MODE_CLASS' as below:
+
+          #define CANNOT_CHANGE_MODE_CLASS(FROM, TO, CLASS) \
+            (GET_MODE_SIZE (FROM) != GET_MODE_SIZE (TO) \
+             ? reg_classes_intersect_p (FLOAT_REGS, (CLASS)) : 0)
+
+ -- Target Hook: bool TARGET_LRA_P (void)
+     A target hook which returns true if we use LRA instead of reload
+     pass.  It means that LRA was ported to the target.  The default
+     version of this target hook returns always false.
+
+ -- Target Hook: int TARGET_REGISTER_PRIORITY (int)
+     A target hook which returns the register priority number to which
+     the register HARD_REGNO belongs to.  The bigger the number, the
+     more preferable the hard register usage (when all other conditions
+     are the same).  This hook can be used to prefer some hard register
+     over others in LRA. For example, some x86-64 register usage needs
+     additional prefix which makes instructions longer.  The hook can
+     return lower priority number for such registers make them less
+     favorable and as result making the generated code smaller.  The
+     default version of this target hook returns always zero.
+
+ -- Target Hook: bool TARGET_REGISTER_USAGE_LEVELING_P (void)
+     A target hook which returns true if we need register usage
+     leveling.  That means if a few hard registers are equally good for
+     the assignment, we choose the least used hard register.  The
+     register usage leveling may be profitable for some targets.  Don't
+     use the usage leveling for targets with conditional execution or
+     targets with big register files as it hurts if-conversion and
+     cross-jumping optimizations.  The default version of this target
+     hook returns always false.
+
+ -- Target Hook: bool TARGET_DIFFERENT_ADDR_DISPLACEMENT_P (void)
+     A target hook which returns true if an address with the same
+     structure can have different maximal legitimate displacement.  For
+     example, the displacement can depend on memory mode or on operand
+     combinations in the insn.  The default version of this target hook
+     returns always false.
+
+ -- Target Hook: reg_class_t TARGET_SPILL_CLASS (reg_class_t, enum
+          MACHINE_MODE)
+     This hook defines a class of registers which could be used for
+     spilling pseudos of the given mode and class, or 'NO_REGS' if only
+     memory should be used.  Not defining this hook is equivalent to
+     returning 'NO_REGS' for all inputs.
+
+ -- Target Hook: enum machine_mode TARGET_CSTORE_MODE (enum insn_code
+          ICODE)
+     This hook defines the machine mode to use for the boolean result of
+     conditional store patterns.  The ICODE argument is the instruction
+     code for the cstore being performed.  Not definiting this hook is
+     the same as accepting the mode encoded into operand 0 of the cstore
+     expander patterns.
+
+
+File: gccint.info,  Node: Old Constraints,  Next: Stack and Calling,  Prev: Register Classes,  Up: Target Macros
+
+17.9 Obsolete Macros for Defining Constraints
+=============================================
+
+Machine-specific constraints can be defined with these macros instead of
+the machine description constructs described in *note Define
+Constraints::.  This mechanism is obsolete.  New ports should not use
+it; old ports should convert to the new mechanism.
+
+ -- Macro: CONSTRAINT_LEN (CHAR, STR)
+     For the constraint at the start of STR, which starts with the
+     letter C, return the length.  This allows you to have register
+     class / constant / extra constraints that are longer than a single
+     letter; you don't need to define this macro if you can do with
+     single-letter constraints only.  The definition of this macro
+     should use DEFAULT_CONSTRAINT_LEN for all the characters that you
+     don't want to handle specially.  There are some sanity checks in
+     genoutput.c that check the constraint lengths for the md file, so
+     you can also use this macro to help you while you are transitioning
+     from a byzantine single-letter-constraint scheme: when you return a
+     negative length for a constraint you want to re-use, genoutput will
+     complain about every instance where it is used in the md file.
+
+ -- Macro: REG_CLASS_FROM_LETTER (CHAR)
+     A C expression which defines the machine-dependent operand
+     constraint letters for register classes.  If CHAR is such a letter,
+     the value should be the register class corresponding to it.
+     Otherwise, the value should be 'NO_REGS'.  The register letter 'r',
+     corresponding to class 'GENERAL_REGS', will not be passed to this
+     macro; you do not need to handle it.
+
+ -- Macro: REG_CLASS_FROM_CONSTRAINT (CHAR, STR)
+     Like 'REG_CLASS_FROM_LETTER', but you also get the constraint
+     string passed in STR, so that you can use suffixes to distinguish
+     between different variants.
+
+ -- Macro: CONST_OK_FOR_LETTER_P (VALUE, C)
+     A C expression that defines the machine-dependent operand
+     constraint letters ('I', 'J', 'K', ... 'P') that specify particular
+     ranges of integer values.  If C is one of those letters, the
+     expression should check that VALUE, an integer, is in the
+     appropriate range and return 1 if so, 0 otherwise.  If C is not one
+     of those letters, the value should be 0 regardless of VALUE.
+
+ -- Macro: CONST_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
+     Like 'CONST_OK_FOR_LETTER_P', but you also get the constraint
+     string passed in STR, so that you can use suffixes to distinguish
+     between different variants.
+
+ -- Macro: CONST_DOUBLE_OK_FOR_LETTER_P (VALUE, C)
+     A C expression that defines the machine-dependent operand
+     constraint letters that specify particular ranges of 'const_double'
+     values ('G' or 'H').
+
+     If C is one of those letters, the expression should check that
+     VALUE, an RTX of code 'const_double', is in the appropriate range
+     and return 1 if so, 0 otherwise.  If C is not one of those letters,
+     the value should be 0 regardless of VALUE.
+
+     'const_double' is used for all floating-point constants and for
+     'DImode' fixed-point constants.  A given letter can accept either
+     or both kinds of values.  It can use 'GET_MODE' to distinguish
+     between these kinds.
+
+ -- Macro: CONST_DOUBLE_OK_FOR_CONSTRAINT_P (VALUE, C, STR)
+     Like 'CONST_DOUBLE_OK_FOR_LETTER_P', but you also get the
+     constraint string passed in STR, so that you can use suffixes to
+     distinguish between different variants.
+
+ -- Macro: EXTRA_CONSTRAINT (VALUE, C)
+     A C expression that defines the optional machine-dependent
+     constraint letters that can be used to segregate specific types of
+     operands, usually memory references, for the target machine.  Any
+     letter that is not elsewhere defined and not matched by
+     'REG_CLASS_FROM_LETTER' / 'REG_CLASS_FROM_CONSTRAINT' may be used.
+     Normally this macro will not be defined.
+
+     If it is required for a particular target machine, it should return
+     1 if VALUE corresponds to the operand type represented by the
+     constraint letter C.  If C is not defined as an extra constraint,
+     the value returned should be 0 regardless of VALUE.
+
+     For example, on the ROMP, load instructions cannot have their
+     output in r0 if the memory reference contains a symbolic address.
+     Constraint letter 'Q' is defined as representing a memory address
+     that does _not_ contain a symbolic address.  An alternative is
+     specified with a 'Q' constraint on the input and 'r' on the output.
+     The next alternative specifies 'm' on the input and a register
+     class that does not include r0 on the output.
+
+ -- Macro: EXTRA_CONSTRAINT_STR (VALUE, C, STR)
+     Like 'EXTRA_CONSTRAINT', but you also get the constraint string
+     passed in STR, so that you can use suffixes to distinguish between
+     different variants.
+
+ -- Macro: EXTRA_MEMORY_CONSTRAINT (C, STR)
+     A C expression that defines the optional machine-dependent
+     constraint letters, amongst those accepted by 'EXTRA_CONSTRAINT',
+     that should be treated like memory constraints by the reload pass.
+
+     It should return 1 if the operand type represented by the
+     constraint at the start of STR, the first letter of which is the
+     letter C, comprises a subset of all memory references including all
+     those whose address is simply a base register.  This allows the
+     reload pass to reload an operand, if it does not directly
+     correspond to the operand type of C, by copying its address into a
+     base register.
+
+     For example, on the S/390, some instructions do not accept
+     arbitrary memory references, but only those that do not make use of
+     an index register.  The constraint letter 'Q' is defined via
+     'EXTRA_CONSTRAINT' as representing a memory address of this type.
+     If the letter 'Q' is marked as 'EXTRA_MEMORY_CONSTRAINT', a 'Q'
+     constraint can handle any memory operand, because the reload pass
+     knows it can be reloaded by copying the memory address into a base
+     register if required.  This is analogous to the way an 'o'
+     constraint can handle any memory operand.
+
+ -- Macro: EXTRA_ADDRESS_CONSTRAINT (C, STR)
+     A C expression that defines the optional machine-dependent
+     constraint letters, amongst those accepted by 'EXTRA_CONSTRAINT' /
+     'EXTRA_CONSTRAINT_STR', that should be treated like address
+     constraints by the reload pass.
+
+     It should return 1 if the operand type represented by the
+     constraint at the start of STR, which starts with the letter C,
+     comprises a subset of all memory addresses including all those that
+     consist of just a base register.  This allows the reload pass to
+     reload an operand, if it does not directly correspond to the
+     operand type of STR, by copying it into a base register.
+
+     Any constraint marked as 'EXTRA_ADDRESS_CONSTRAINT' can only be
+     used with the 'address_operand' predicate.  It is treated
+     analogously to the 'p' constraint.
+
+
+File: gccint.info,  Node: Stack and Calling,  Next: Varargs,  Prev: Old Constraints,  Up: Target Macros
+
+17.10 Stack Layout and Calling Conventions
+==========================================
+
+This describes the stack layout and calling conventions.
+
+* Menu:
+
+* Frame Layout::
+* Exception Handling::
+* Stack Checking::
+* Frame Registers::
+* Elimination::
+* Stack Arguments::
+* Register Arguments::
+* Scalar Return::
+* Aggregate Return::
+* Caller Saves::
+* Function Entry::
+* Profiling::
+* Tail Calls::
+* Stack Smashing Protection::
+
+
+File: gccint.info,  Node: Frame Layout,  Next: Exception Handling,  Up: Stack and Calling
+
+17.10.1 Basic Stack Layout
+--------------------------
+
+Here is the basic stack layout.
+
+ -- Macro: STACK_GROWS_DOWNWARD
+     Define this macro if pushing a word onto the stack moves the stack
+     pointer to a smaller address.
+
+     When we say, "define this macro if ...", it means that the compiler
+     checks this macro only with '#ifdef' so the precise definition used
+     does not matter.
+
+ -- Macro: STACK_PUSH_CODE
+     This macro defines the operation used when something is pushed on
+     the stack.  In RTL, a push operation will be '(set (mem
+     (STACK_PUSH_CODE (reg sp))) ...)'
+
+     The choices are 'PRE_DEC', 'POST_DEC', 'PRE_INC', and 'POST_INC'.
+     Which of these is correct depends on the stack direction and on
+     whether the stack pointer points to the last item on the stack or
+     whether it points to the space for the next item on the stack.
+
+     The default is 'PRE_DEC' when 'STACK_GROWS_DOWNWARD' is defined,
+     which is almost always right, and 'PRE_INC' otherwise, which is
+     often wrong.
+
+ -- Macro: FRAME_GROWS_DOWNWARD
+     Define this macro to nonzero value if the addresses of local
+     variable slots are at negative offsets from the frame pointer.
+
+ -- Macro: ARGS_GROW_DOWNWARD
+     Define this macro if successive arguments to a function occupy
+     decreasing addresses on the stack.
+
+ -- Macro: STARTING_FRAME_OFFSET
+     Offset from the frame pointer to the first local variable slot to
+     be allocated.
+
+     If 'FRAME_GROWS_DOWNWARD', find the next slot's offset by
+     subtracting the first slot's length from 'STARTING_FRAME_OFFSET'.
+     Otherwise, it is found by adding the length of the first slot to
+     the value 'STARTING_FRAME_OFFSET'.
+
+ -- Macro: STACK_ALIGNMENT_NEEDED
+     Define to zero to disable final alignment of the stack during
+     reload.  The nonzero default for this macro is suitable for most
+     ports.
+
+     On ports where 'STARTING_FRAME_OFFSET' is nonzero or where there is
+     a register save block following the local block that doesn't
+     require alignment to 'STACK_BOUNDARY', it may be beneficial to
+     disable stack alignment and do it in the backend.
+
+ -- Macro: STACK_POINTER_OFFSET
+     Offset from the stack pointer register to the first location at
+     which outgoing arguments are placed.  If not specified, the default
+     value of zero is used.  This is the proper value for most machines.
+
+     If 'ARGS_GROW_DOWNWARD', this is the offset to the location above
+     the first location at which outgoing arguments are placed.
+
+ -- Macro: FIRST_PARM_OFFSET (FUNDECL)
+     Offset from the argument pointer register to the first argument's
+     address.  On some machines it may depend on the data type of the
+     function.
+
+     If 'ARGS_GROW_DOWNWARD', this is the offset to the location above
+     the first argument's address.
+
+ -- Macro: STACK_DYNAMIC_OFFSET (FUNDECL)
+     Offset from the stack pointer register to an item dynamically
+     allocated on the stack, e.g., by 'alloca'.
+
+     The default value for this macro is 'STACK_POINTER_OFFSET' plus the
+     length of the outgoing arguments.  The default is correct for most
+     machines.  See 'function.c' for details.
+
+ -- Macro: INITIAL_FRAME_ADDRESS_RTX
+     A C expression whose value is RTL representing the address of the
+     initial stack frame.  This address is passed to 'RETURN_ADDR_RTX'
+     and 'DYNAMIC_CHAIN_ADDRESS'.  If you don't define this macro, a
+     reasonable default value will be used.  Define this macro in order
+     to make frame pointer elimination work in the presence of
+     '__builtin_frame_address (count)' and '__builtin_return_address
+     (count)' for 'count' not equal to zero.
+
+ -- Macro: DYNAMIC_CHAIN_ADDRESS (FRAMEADDR)
+     A C expression whose value is RTL representing the address in a
+     stack frame where the pointer to the caller's frame is stored.
+     Assume that FRAMEADDR is an RTL expression for the address of the
+     stack frame itself.
+
+     If you don't define this macro, the default is to return the value
+     of FRAMEADDR--that is, the stack frame address is also the address
+     of the stack word that points to the previous frame.
+
+ -- Macro: SETUP_FRAME_ADDRESSES
+     If defined, a C expression that produces the machine-specific code
+     to setup the stack so that arbitrary frames can be accessed.  For
+     example, on the SPARC, we must flush all of the register windows to
+     the stack before we can access arbitrary stack frames.  You will
+     seldom need to define this macro.
+
+ -- Target Hook: rtx TARGET_BUILTIN_SETJMP_FRAME_VALUE (void)
+     This target hook should return an rtx that is used to store the
+     address of the current frame into the built in 'setjmp' buffer.
+     The default value, 'virtual_stack_vars_rtx', is correct for most
+     machines.  One reason you may need to define this target hook is if
+     'hard_frame_pointer_rtx' is the appropriate value on your machine.
+
+ -- Macro: FRAME_ADDR_RTX (FRAMEADDR)
+     A C expression whose value is RTL representing the value of the
+     frame address for the current frame.  FRAMEADDR is the frame
+     pointer of the current frame.  This is used for
+     __builtin_frame_address.  You need only define this macro if the
+     frame address is not the same as the frame pointer.  Most machines
+     do not need to define it.
+
+ -- Macro: RETURN_ADDR_RTX (COUNT, FRAMEADDR)
+     A C expression whose value is RTL representing the value of the
+     return address for the frame COUNT steps up from the current frame,
+     after the prologue.  FRAMEADDR is the frame pointer of the COUNT
+     frame, or the frame pointer of the COUNT - 1 frame if
+     'RETURN_ADDR_IN_PREVIOUS_FRAME' is defined.
+
+     The value of the expression must always be the correct address when
+     COUNT is zero, but may be 'NULL_RTX' if there is no way to
+     determine the return address of other frames.
+
+ -- Macro: RETURN_ADDR_IN_PREVIOUS_FRAME
+     Define this if the return address of a particular stack frame is
+     accessed from the frame pointer of the previous stack frame.
+
+ -- Macro: INCOMING_RETURN_ADDR_RTX
+     A C expression whose value is RTL representing the location of the
+     incoming return address at the beginning of any function, before
+     the prologue.  This RTL is either a 'REG', indicating that the
+     return value is saved in 'REG', or a 'MEM' representing a location
+     in the stack.
+
+     You only need to define this macro if you want to support call
+     frame debugging information like that provided by DWARF 2.
+
+     If this RTL is a 'REG', you should also define
+     'DWARF_FRAME_RETURN_COLUMN' to 'DWARF_FRAME_REGNUM (REGNO)'.
+
+ -- Macro: DWARF_ALT_FRAME_RETURN_COLUMN
+     A C expression whose value is an integer giving a DWARF 2 column
+     number that may be used as an alternative return column.  The
+     column must not correspond to any gcc hard register (that is, it
+     must not be in the range of 'DWARF_FRAME_REGNUM').
+
+     This macro can be useful if 'DWARF_FRAME_RETURN_COLUMN' is set to a
+     general register, but an alternative column needs to be used for
+     signal frames.  Some targets have also used different frame return
+     columns over time.
+
+ -- Macro: DWARF_ZERO_REG
+     A C expression whose value is an integer giving a DWARF 2 register
+     number that is considered to always have the value zero.  This
+     should only be defined if the target has an architected zero
+     register, and someone decided it was a good idea to use that
+     register number to terminate the stack backtrace.  New ports should
+     avoid this.
+
+ -- Target Hook: void TARGET_DWARF_HANDLE_FRAME_UNSPEC (const char
+          *LABEL, rtx PATTERN, int INDEX)
+     This target hook allows the backend to emit frame-related insns
+     that contain UNSPECs or UNSPEC_VOLATILEs.  The DWARF 2 call frame
+     debugging info engine will invoke it on insns of the form
+          (set (reg) (unspec [...] UNSPEC_INDEX))
+     and
+          (set (reg) (unspec_volatile [...] UNSPECV_INDEX)).
+     to let the backend emit the call frame instructions.  LABEL is the
+     CFI label attached to the insn, PATTERN is the pattern of the insn
+     and INDEX is 'UNSPEC_INDEX' or 'UNSPECV_INDEX'.
+
+ -- Macro: INCOMING_FRAME_SP_OFFSET
+     A C expression whose value is an integer giving the offset, in
+     bytes, from the value of the stack pointer register to the top of
+     the stack frame at the beginning of any function, before the
+     prologue.  The top of the frame is defined to be the value of the
+     stack pointer in the previous frame, just before the call
+     instruction.
+
+     You only need to define this macro if you want to support call
+     frame debugging information like that provided by DWARF 2.
+
+ -- Macro: ARG_POINTER_CFA_OFFSET (FUNDECL)
+     A C expression whose value is an integer giving the offset, in
+     bytes, from the argument pointer to the canonical frame address
+     (cfa).  The final value should coincide with that calculated by
+     'INCOMING_FRAME_SP_OFFSET'.  Which is unfortunately not usable
+     during virtual register instantiation.
+
+     The default value for this macro is 'FIRST_PARM_OFFSET (fundecl) +
+     crtl->args.pretend_args_size', which is correct for most machines;
+     in general, the arguments are found immediately before the stack
+     frame.  Note that this is not the case on some targets that save
+     registers into the caller's frame, such as SPARC and rs6000, and so
+     such targets need to define this macro.
+
+     You only need to define this macro if the default is incorrect, and
+     you want to support call frame debugging information like that
+     provided by DWARF 2.
+
+ -- Macro: FRAME_POINTER_CFA_OFFSET (FUNDECL)
+     If defined, a C expression whose value is an integer giving the
+     offset in bytes from the frame pointer to the canonical frame
+     address (cfa).  The final value should coincide with that
+     calculated by 'INCOMING_FRAME_SP_OFFSET'.
+
+     Normally the CFA is calculated as an offset from the argument
+     pointer, via 'ARG_POINTER_CFA_OFFSET', but if the argument pointer
+     is variable due to the ABI, this may not be possible.  If this
+     macro is defined, it implies that the virtual register
+     instantiation should be based on the frame pointer instead of the
+     argument pointer.  Only one of 'FRAME_POINTER_CFA_OFFSET' and
+     'ARG_POINTER_CFA_OFFSET' should be defined.
+
+ -- Macro: CFA_FRAME_BASE_OFFSET (FUNDECL)
+     If defined, a C expression whose value is an integer giving the
+     offset in bytes from the canonical frame address (cfa) to the frame
+     base used in DWARF 2 debug information.  The default is zero.  A
+     different value may reduce the size of debug information on some
+     ports.
+
+
+File: gccint.info,  Node: Exception Handling,  Next: Stack Checking,  Prev: Frame Layout,  Up: Stack and Calling
+
+17.10.2 Exception Handling Support
+----------------------------------
+
+ -- Macro: EH_RETURN_DATA_REGNO (N)
+     A C expression whose value is the Nth register number used for data
+     by exception handlers, or 'INVALID_REGNUM' if fewer than N
+     registers are usable.
+
+     The exception handling library routines communicate with the
+     exception handlers via a set of agreed upon registers.  Ideally
+     these registers should be call-clobbered; it is possible to use
+     call-saved registers, but may negatively impact code size.  The
+     target must support at least 2 data registers, but should define 4
+     if there are enough free registers.
+
+     You must define this macro if you want to support call frame
+     exception handling like that provided by DWARF 2.
+
+ -- Macro: EH_RETURN_STACKADJ_RTX
+     A C expression whose value is RTL representing a location in which
+     to store a stack adjustment to be applied before function return.
+     This is used to unwind the stack to an exception handler's call
+     frame.  It will be assigned zero on code paths that return
+     normally.
+
+     Typically this is a call-clobbered hard register that is otherwise
+     untouched by the epilogue, but could also be a stack slot.
+
+     Do not define this macro if the stack pointer is saved and restored
+     by the regular prolog and epilog code in the call frame itself; in
+     this case, the exception handling library routines will update the
+     stack location to be restored in place.  Otherwise, you must define
+     this macro if you want to support call frame exception handling
+     like that provided by DWARF 2.
+
+ -- Macro: EH_RETURN_HANDLER_RTX
+     A C expression whose value is RTL representing a location in which
+     to store the address of an exception handler to which we should
+     return.  It will not be assigned on code paths that return
+     normally.
+
+     Typically this is the location in the call frame at which the
+     normal return address is stored.  For targets that return by
+     popping an address off the stack, this might be a memory address
+     just below the _target_ call frame rather than inside the current
+     call frame.  If defined, 'EH_RETURN_STACKADJ_RTX' will have already
+     been assigned, so it may be used to calculate the location of the
+     target call frame.
+
+     Some targets have more complex requirements than storing to an
+     address calculable during initial code generation.  In that case
+     the 'eh_return' instruction pattern should be used instead.
+
+     If you want to support call frame exception handling, you must
+     define either this macro or the 'eh_return' instruction pattern.
+
+ -- Macro: RETURN_ADDR_OFFSET
+     If defined, an integer-valued C expression for which rtl will be
+     generated to add it to the exception handler address before it is
+     searched in the exception handling tables, and to subtract it again
+     from the address before using it to return to the exception
+     handler.
+
+ -- Macro: ASM_PREFERRED_EH_DATA_FORMAT (CODE, GLOBAL)
+     This macro chooses the encoding of pointers embedded in the
+     exception handling sections.  If at all possible, this should be
+     defined such that the exception handling section will not require
+     dynamic relocations, and so may be read-only.
+
+     CODE is 0 for data, 1 for code labels, 2 for function pointers.
+     GLOBAL is true if the symbol may be affected by dynamic
+     relocations.  The macro should return a combination of the
+     'DW_EH_PE_*' defines as found in 'dwarf2.h'.
+
+     If this macro is not defined, pointers will not be encoded but
+     represented directly.
+
+ -- Macro: ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX (FILE, ENCODING, SIZE,
+          ADDR, DONE)
+     This macro allows the target to emit whatever special magic is
+     required to represent the encoding chosen by
+     'ASM_PREFERRED_EH_DATA_FORMAT'.  Generic code takes care of
+     pc-relative and indirect encodings; this must be defined if the
+     target uses text-relative or data-relative encodings.
+
+     This is a C statement that branches to DONE if the format was
+     handled.  ENCODING is the format chosen, SIZE is the number of
+     bytes that the format occupies, ADDR is the 'SYMBOL_REF' to be
+     emitted.
+
+ -- Macro: MD_FALLBACK_FRAME_STATE_FOR (CONTEXT, FS)
+     This macro allows the target to add CPU and operating system
+     specific code to the call-frame unwinder for use when there is no
+     unwind data available.  The most common reason to implement this
+     macro is to unwind through signal frames.
+
+     This macro is called from 'uw_frame_state_for' in 'unwind-dw2.c',
+     'unwind-dw2-xtensa.c' and 'unwind-ia64.c'.  CONTEXT is an
+     '_Unwind_Context'; FS is an '_Unwind_FrameState'.  Examine
+     'context->ra' for the address of the code being executed and
+     'context->cfa' for the stack pointer value.  If the frame can be
+     decoded, the register save addresses should be updated in FS and
+     the macro should evaluate to '_URC_NO_REASON'.  If the frame cannot
+     be decoded, the macro should evaluate to '_URC_END_OF_STACK'.
+
+     For proper signal handling in Java this macro is accompanied by
+     'MAKE_THROW_FRAME', defined in 'libjava/include/*-signal.h'
+     headers.
+
+ -- Macro: MD_HANDLE_UNWABI (CONTEXT, FS)
+     This macro allows the target to add operating system specific code
+     to the call-frame unwinder to handle the IA-64 '.unwabi' unwinding
+     directive, usually used for signal or interrupt frames.
+
+     This macro is called from 'uw_update_context' in libgcc's
+     'unwind-ia64.c'.  CONTEXT is an '_Unwind_Context'; FS is an
+     '_Unwind_FrameState'.  Examine 'fs->unwabi' for the abi and context
+     in the '.unwabi' directive.  If the '.unwabi' directive can be
+     handled, the register save addresses should be updated in FS.
+
+ -- Macro: TARGET_USES_WEAK_UNWIND_INFO
+     A C expression that evaluates to true if the target requires unwind
+     info to be given comdat linkage.  Define it to be '1' if comdat
+     linkage is necessary.  The default is '0'.
+
+
+File: gccint.info,  Node: Stack Checking,  Next: Frame Registers,  Prev: Exception Handling,  Up: Stack and Calling
+
+17.10.3 Specifying How Stack Checking is Done
+---------------------------------------------
+
+GCC will check that stack references are within the boundaries of the
+stack, if the option '-fstack-check' is specified, in one of three ways:
+
+  1. If the value of the 'STACK_CHECK_BUILTIN' macro is nonzero, GCC
+     will assume that you have arranged for full stack checking to be
+     done at appropriate places in the configuration files.  GCC will
+     not do other special processing.
+
+  2. If 'STACK_CHECK_BUILTIN' is zero and the value of the
+     'STACK_CHECK_STATIC_BUILTIN' macro is nonzero, GCC will assume that
+     you have arranged for static stack checking (checking of the static
+     stack frame of functions) to be done at appropriate places in the
+     configuration files.  GCC will only emit code to do dynamic stack
+     checking (checking on dynamic stack allocations) using the third
+     approach below.
+
+  3. If neither of the above are true, GCC will generate code to
+     periodically "probe" the stack pointer using the values of the
+     macros defined below.
+
+ If neither STACK_CHECK_BUILTIN nor STACK_CHECK_STATIC_BUILTIN is
+defined, GCC will change its allocation strategy for large objects if
+the option '-fstack-check' is specified: they will always be allocated
+dynamically if their size exceeds 'STACK_CHECK_MAX_VAR_SIZE' bytes.
+
+ -- Macro: STACK_CHECK_BUILTIN
+     A nonzero value if stack checking is done by the configuration
+     files in a machine-dependent manner.  You should define this macro
+     if stack checking is required by the ABI of your machine or if you
+     would like to do stack checking in some more efficient way than the
+     generic approach.  The default value of this macro is zero.
+
+ -- Macro: STACK_CHECK_STATIC_BUILTIN
+     A nonzero value if static stack checking is done by the
+     configuration files in a machine-dependent manner.  You should
+     define this macro if you would like to do static stack checking in
+     some more efficient way than the generic approach.  The default
+     value of this macro is zero.
+
+ -- Macro: STACK_CHECK_PROBE_INTERVAL_EXP
+     An integer specifying the interval at which GCC must generate stack
+     probe instructions, defined as 2 raised to this integer.  You will
+     normally define this macro so that the interval be no larger than
+     the size of the "guard pages" at the end of a stack area.  The
+     default value of 12 (4096-byte interval) is suitable for most
+     systems.
+
+ -- Macro: STACK_CHECK_MOVING_SP
+     An integer which is nonzero if GCC should move the stack pointer
+     page by page when doing probes.  This can be necessary on systems
+     where the stack pointer contains the bottom address of the memory
+     area accessible to the executing thread at any point in time.  In
+     this situation an alternate signal stack is required in order to be
+     able to recover from a stack overflow.  The default value of this
+     macro is zero.
+
+ -- Macro: STACK_CHECK_PROTECT
+     The number of bytes of stack needed to recover from a stack
+     overflow, for languages where such a recovery is supported.  The
+     default value of 75 words with the 'setjmp'/'longjmp'-based
+     exception handling mechanism and 8192 bytes with other exception
+     handling mechanisms should be adequate for most machines.
+
+ The following macros are relevant only if neither STACK_CHECK_BUILTIN
+nor STACK_CHECK_STATIC_BUILTIN is defined; you can omit them altogether
+in the opposite case.
+
+ -- Macro: STACK_CHECK_MAX_FRAME_SIZE
+     The maximum size of a stack frame, in bytes.  GCC will generate
+     probe instructions in non-leaf functions to ensure at least this
+     many bytes of stack are available.  If a stack frame is larger than
+     this size, stack checking will not be reliable and GCC will issue a
+     warning.  The default is chosen so that GCC only generates one
+     instruction on most systems.  You should normally not change the
+     default value of this macro.
+
+ -- Macro: STACK_CHECK_FIXED_FRAME_SIZE
+     GCC uses this value to generate the above warning message.  It
+     represents the amount of fixed frame used by a function, not
+     including space for any callee-saved registers, temporaries and
+     user variables.  You need only specify an upper bound for this
+     amount and will normally use the default of four words.
+
+ -- Macro: STACK_CHECK_MAX_VAR_SIZE
+     The maximum size, in bytes, of an object that GCC will place in the
+     fixed area of the stack frame when the user specifies
+     '-fstack-check'.  GCC computed the default from the values of the
+     above macros and you will normally not need to override that
+     default.
+
+
+File: gccint.info,  Node: Frame Registers,  Next: Elimination,  Prev: Stack Checking,  Up: Stack and Calling
+
+17.10.4 Registers That Address the Stack Frame
+----------------------------------------------
+
+This discusses registers that address the stack frame.
+
+ -- Macro: STACK_POINTER_REGNUM
+     The register number of the stack pointer register, which must also
+     be a fixed register according to 'FIXED_REGISTERS'.  On most
+     machines, the hardware determines which register this is.
+
+ -- Macro: FRAME_POINTER_REGNUM
+     The register number of the frame pointer register, which is used to
+     access automatic variables in the stack frame.  On some machines,
+     the hardware determines which register this is.  On other machines,
+     you can choose any register you wish for this purpose.
+
+ -- Macro: HARD_FRAME_POINTER_REGNUM
+     On some machines the offset between the frame pointer and starting
+     offset of the automatic variables is not known until after register
+     allocation has been done (for example, because the saved registers
+     are between these two locations).  On those machines, define
+     'FRAME_POINTER_REGNUM' the number of a special, fixed register to
+     be used internally until the offset is known, and define
+     'HARD_FRAME_POINTER_REGNUM' to be the actual hard register number
+     used for the frame pointer.
+
+     You should define this macro only in the very rare circumstances
+     when it is not possible to calculate the offset between the frame
+     pointer and the automatic variables until after register allocation
+     has been completed.  When this macro is defined, you must also
+     indicate in your definition of 'ELIMINABLE_REGS' how to eliminate
+     'FRAME_POINTER_REGNUM' into either 'HARD_FRAME_POINTER_REGNUM' or
+     'STACK_POINTER_REGNUM'.
+
+     Do not define this macro if it would be the same as
+     'FRAME_POINTER_REGNUM'.
+
+ -- Macro: ARG_POINTER_REGNUM
+     The register number of the arg pointer register, which is used to
+     access the function's argument list.  On some machines, this is the
+     same as the frame pointer register.  On some machines, the hardware
+     determines which register this is.  On other machines, you can
+     choose any register you wish for this purpose.  If this is not the
+     same register as the frame pointer register, then you must mark it
+     as a fixed register according to 'FIXED_REGISTERS', or arrange to
+     be able to eliminate it (*note Elimination::).
+
+ -- Macro: HARD_FRAME_POINTER_IS_FRAME_POINTER
+     Define this to a preprocessor constant that is nonzero if
+     'hard_frame_pointer_rtx' and 'frame_pointer_rtx' should be the
+     same.  The default definition is '(HARD_FRAME_POINTER_REGNUM ==
+     FRAME_POINTER_REGNUM)'; you only need to define this macro if that
+     definition is not suitable for use in preprocessor conditionals.
+
+ -- Macro: HARD_FRAME_POINTER_IS_ARG_POINTER
+     Define this to a preprocessor constant that is nonzero if
+     'hard_frame_pointer_rtx' and 'arg_pointer_rtx' should be the same.
+     The default definition is '(HARD_FRAME_POINTER_REGNUM ==
+     ARG_POINTER_REGNUM)'; you only need to define this macro if that
+     definition is not suitable for use in preprocessor conditionals.
+
+ -- Macro: RETURN_ADDRESS_POINTER_REGNUM
+     The register number of the return address pointer register, which
+     is used to access the current function's return address from the
+     stack.  On some machines, the return address is not at a fixed
+     offset from the frame pointer or stack pointer or argument pointer.
+     This register can be defined to point to the return address on the
+     stack, and then be converted by 'ELIMINABLE_REGS' into either the
+     frame pointer or stack pointer.
+
+     Do not define this macro unless there is no other way to get the
+     return address from the stack.
+
+ -- Macro: STATIC_CHAIN_REGNUM
+ -- Macro: STATIC_CHAIN_INCOMING_REGNUM
+     Register numbers used for passing a function's static chain
+     pointer.  If register windows are used, the register number as seen
+     by the called function is 'STATIC_CHAIN_INCOMING_REGNUM', while the
+     register number as seen by the calling function is
+     'STATIC_CHAIN_REGNUM'.  If these registers are the same,
+     'STATIC_CHAIN_INCOMING_REGNUM' need not be defined.
+
+     The static chain register need not be a fixed register.
+
+     If the static chain is passed in memory, these macros should not be
+     defined; instead, the 'TARGET_STATIC_CHAIN' hook should be used.
+
+ -- Target Hook: rtx TARGET_STATIC_CHAIN (const_tree FNDECL, bool
+          INCOMING_P)
+     This hook replaces the use of 'STATIC_CHAIN_REGNUM' et al for
+     targets that may use different static chain locations for different
+     nested functions.  This may be required if the target has function
+     attributes that affect the calling conventions of the function and
+     those calling conventions use different static chain locations.
+
+     The default version of this hook uses 'STATIC_CHAIN_REGNUM' et al.
+
+     If the static chain is passed in memory, this hook should be used
+     to provide rtx giving 'mem' expressions that denote where they are
+     stored.  Often the 'mem' expression as seen by the caller will be
+     at an offset from the stack pointer and the 'mem' expression as
+     seen by the callee will be at an offset from the frame pointer.
+     The variables 'stack_pointer_rtx', 'frame_pointer_rtx', and
+     'arg_pointer_rtx' will have been initialized and should be used to
+     refer to those items.
+
+ -- Macro: DWARF_FRAME_REGISTERS
+     This macro specifies the maximum number of hard registers that can
+     be saved in a call frame.  This is used to size data structures
+     used in DWARF2 exception handling.
+
+     Prior to GCC 3.0, this macro was needed in order to establish a
+     stable exception handling ABI in the face of adding new hard
+     registers for ISA extensions.  In GCC 3.0 and later, the EH ABI is
+     insulated from changes in the number of hard registers.
+     Nevertheless, this macro can still be used to reduce the runtime
+     memory requirements of the exception handling routines, which can
+     be substantial if the ISA contains a lot of registers that are not
+     call-saved.
+
+     If this macro is not defined, it defaults to
+     'FIRST_PSEUDO_REGISTER'.
+
+ -- Macro: PRE_GCC3_DWARF_FRAME_REGISTERS
+
+     This macro is similar to 'DWARF_FRAME_REGISTERS', but is provided
+     for backward compatibility in pre GCC 3.0 compiled code.
+
+     If this macro is not defined, it defaults to
+     'DWARF_FRAME_REGISTERS'.
+
+ -- Macro: DWARF_REG_TO_UNWIND_COLUMN (REGNO)
+
+     Define this macro if the target's representation for dwarf
+     registers is different than the internal representation for unwind
+     column.  Given a dwarf register, this macro should return the
+     internal unwind column number to use instead.
+
+     See the PowerPC's SPE target for an example.
+
+ -- Macro: DWARF_FRAME_REGNUM (REGNO)
+
+     Define this macro if the target's representation for dwarf
+     registers used in .eh_frame or .debug_frame is different from that
+     used in other debug info sections.  Given a GCC hard register
+     number, this macro should return the .eh_frame register number.
+     The default is 'DBX_REGISTER_NUMBER (REGNO)'.
+
+ -- Macro: DWARF2_FRAME_REG_OUT (REGNO, FOR_EH)
+
+     Define this macro to map register numbers held in the call frame
+     info that GCC has collected using 'DWARF_FRAME_REGNUM' to those
+     that should be output in .debug_frame ('FOR_EH' is zero) and
+     .eh_frame ('FOR_EH' is nonzero).  The default is to return 'REGNO'.
+
+ -- Macro: REG_VALUE_IN_UNWIND_CONTEXT
+
+     Define this macro if the target stores register values as
+     '_Unwind_Word' type in unwind context.  It should be defined if
+     target register size is larger than the size of 'void *'.  The
+     default is to store register values as 'void *' type.
+
+ -- Macro: ASSUME_EXTENDED_UNWIND_CONTEXT
+
+     Define this macro to be 1 if the target always uses extended unwind
+     context with version, args_size and by_value fields.  If it is
+     undefined, it will be defined to 1 when
+     'REG_VALUE_IN_UNWIND_CONTEXT' is defined and 0 otherwise.
+
+
+File: gccint.info,  Node: Elimination,  Next: Stack Arguments,  Prev: Frame Registers,  Up: Stack and Calling
+
+17.10.5 Eliminating Frame Pointer and Arg Pointer
+-------------------------------------------------
+
+This is about eliminating the frame pointer and arg pointer.
+
+ -- Target Hook: bool TARGET_FRAME_POINTER_REQUIRED (void)
+     This target hook should return 'true' if a function must have and
+     use a frame pointer.  This target hook is called in the reload
+     pass.  If its return value is 'true' the function will have a frame
+     pointer.
+
+     This target hook can in principle examine the current function and
+     decide according to the facts, but on most machines the constant
+     'false' or the constant 'true' suffices.  Use 'false' when the
+     machine allows code to be generated with no frame pointer, and
+     doing so saves some time or space.  Use 'true' when there is no
+     possible advantage to avoiding a frame pointer.
+
+     In certain cases, the compiler does not know how to produce valid
+     code without a frame pointer.  The compiler recognizes those cases
+     and automatically gives the function a frame pointer regardless of
+     what 'TARGET_FRAME_POINTER_REQUIRED' returns.  You don't need to
+     worry about them.
+
+     In a function that does not require a frame pointer, the frame
+     pointer register can be allocated for ordinary usage, unless you
+     mark it as a fixed register.  See 'FIXED_REGISTERS' for more
+     information.
+
+     Default return value is 'false'.
+
+ -- Macro: INITIAL_FRAME_POINTER_OFFSET (DEPTH-VAR)
+     A C statement to store in the variable DEPTH-VAR the difference
+     between the frame pointer and the stack pointer values immediately
+     after the function prologue.  The value would be computed from
+     information such as the result of 'get_frame_size ()' and the
+     tables of registers 'regs_ever_live' and 'call_used_regs'.
+
+     If 'ELIMINABLE_REGS' is defined, this macro will be not be used and
+     need not be defined.  Otherwise, it must be defined even if
+     'TARGET_FRAME_POINTER_REQUIRED' always returns true; in that case,
+     you may set DEPTH-VAR to anything.
+
+ -- Macro: ELIMINABLE_REGS
+     If defined, this macro specifies a table of register pairs used to
+     eliminate unneeded registers that point into the stack frame.  If
+     it is not defined, the only elimination attempted by the compiler
+     is to replace references to the frame pointer with references to
+     the stack pointer.
+
+     The definition of this macro is a list of structure
+     initializations, each of which specifies an original and
+     replacement register.
+
+     On some machines, the position of the argument pointer is not known
+     until the compilation is completed.  In such a case, a separate
+     hard register must be used for the argument pointer.  This register
+     can be eliminated by replacing it with either the frame pointer or
+     the argument pointer, depending on whether or not the frame pointer
+     has been eliminated.
+
+     In this case, you might specify:
+          #define ELIMINABLE_REGS  \
+          {{ARG_POINTER_REGNUM, STACK_POINTER_REGNUM}, \
+           {ARG_POINTER_REGNUM, FRAME_POINTER_REGNUM}, \
+           {FRAME_POINTER_REGNUM, STACK_POINTER_REGNUM}}
+
+     Note that the elimination of the argument pointer with the stack
+     pointer is specified first since that is the preferred elimination.
+
+ -- Target Hook: bool TARGET_CAN_ELIMINATE (const int FROM_REG, const
+          int TO_REG)
+     This target hook should returns 'true' if the compiler is allowed
+     to try to replace register number FROM_REG with register number
+     TO_REG.  This target hook need only be defined if 'ELIMINABLE_REGS'
+     is defined, and will usually be 'true', since most of the cases
+     preventing register elimination are things that the compiler
+     already knows about.
+
+     Default return value is 'true'.
+
+ -- Macro: INITIAL_ELIMINATION_OFFSET (FROM-REG, TO-REG, OFFSET-VAR)
+     This macro is similar to 'INITIAL_FRAME_POINTER_OFFSET'.  It
+     specifies the initial difference between the specified pair of
+     registers.  This macro must be defined if 'ELIMINABLE_REGS' is
+     defined.
+
+
+File: gccint.info,  Node: Stack Arguments,  Next: Register Arguments,  Prev: Elimination,  Up: Stack and Calling
+
+17.10.6 Passing Function Arguments on the Stack
+-----------------------------------------------
+
+The macros in this section control how arguments are passed on the
+stack.  See the following section for other macros that control passing
+certain arguments in registers.
+
+ -- Target Hook: bool TARGET_PROMOTE_PROTOTYPES (const_tree FNTYPE)
+     This target hook returns 'true' if an argument declared in a
+     prototype as an integral type smaller than 'int' should actually be
+     passed as an 'int'.  In addition to avoiding errors in certain
+     cases of mismatch, it also makes for better code on certain
+     machines.  The default is to not promote prototypes.
+
+ -- Macro: PUSH_ARGS
+     A C expression.  If nonzero, push insns will be used to pass
+     outgoing arguments.  If the target machine does not have a push
+     instruction, set it to zero.  That directs GCC to use an alternate
+     strategy: to allocate the entire argument block and then store the
+     arguments into it.  When 'PUSH_ARGS' is nonzero, 'PUSH_ROUNDING'
+     must be defined too.
+
+ -- Macro: PUSH_ARGS_REVERSED
+     A C expression.  If nonzero, function arguments will be evaluated
+     from last to first, rather than from first to last.  If this macro
+     is not defined, it defaults to 'PUSH_ARGS' on targets where the
+     stack and args grow in opposite directions, and 0 otherwise.
+
+ -- Macro: PUSH_ROUNDING (NPUSHED)
+     A C expression that is the number of bytes actually pushed onto the
+     stack when an instruction attempts to push NPUSHED bytes.
+
+     On some machines, the definition
+
+          #define PUSH_ROUNDING(BYTES) (BYTES)
+
+     will suffice.  But on other machines, instructions that appear to
+     push one byte actually push two bytes in an attempt to maintain
+     alignment.  Then the definition should be
+
+          #define PUSH_ROUNDING(BYTES) (((BYTES) + 1) & ~1)
+
+     If the value of this macro has a type, it should be an unsigned
+     type.
+
+ -- Macro: ACCUMULATE_OUTGOING_ARGS
+     A C expression.  If nonzero, the maximum amount of space required
+     for outgoing arguments will be computed and placed into
+     'crtl->outgoing_args_size'.  No space will be pushed onto the stack
+     for each call; instead, the function prologue should increase the
+     stack frame size by this amount.
+
+     Setting both 'PUSH_ARGS' and 'ACCUMULATE_OUTGOING_ARGS' is not
+     proper.
+
+ -- Macro: REG_PARM_STACK_SPACE (FNDECL)
+     Define this macro if functions should assume that stack space has
+     been allocated for arguments even when their values are passed in
+     registers.
+
+     The value of this macro is the size, in bytes, of the area reserved
+     for arguments passed in registers for the function represented by
+     FNDECL, which can be zero if GCC is calling a library function.
+     The argument FNDECL can be the FUNCTION_DECL, or the type itself of
+     the function.
+
+     This space can be allocated by the caller, or be a part of the
+     machine-dependent stack frame: 'OUTGOING_REG_PARM_STACK_SPACE' says
+     which.
+
+ -- Macro: OUTGOING_REG_PARM_STACK_SPACE (FNTYPE)
+     Define this to a nonzero value if it is the responsibility of the
+     caller to allocate the area reserved for arguments passed in
+     registers when calling a function of FNTYPE.  FNTYPE may be NULL if
+     the function called is a library function.
+
+     If 'ACCUMULATE_OUTGOING_ARGS' is defined, this macro controls
+     whether the space for these arguments counts in the value of
+     'crtl->outgoing_args_size'.
+
+ -- Macro: STACK_PARMS_IN_REG_PARM_AREA
+     Define this macro if 'REG_PARM_STACK_SPACE' is defined, but the
+     stack parameters don't skip the area specified by it.
+
+     Normally, when a parameter is not passed in registers, it is placed
+     on the stack beyond the 'REG_PARM_STACK_SPACE' area.  Defining this
+     macro suppresses this behavior and causes the parameter to be
+     passed on the stack in its natural location.
+
+ -- Target Hook: int TARGET_RETURN_POPS_ARGS (tree FUNDECL, tree
+          FUNTYPE, int SIZE)
+     This target hook returns the number of bytes of its own arguments
+     that a function pops on returning, or 0 if the function pops no
+     arguments and the caller must therefore pop them all after the
+     function returns.
+
+     FUNDECL is a C variable whose value is a tree node that describes
+     the function in question.  Normally it is a node of type
+     'FUNCTION_DECL' that describes the declaration of the function.
+     From this you can obtain the 'DECL_ATTRIBUTES' of the function.
+
+     FUNTYPE is a C variable whose value is a tree node that describes
+     the function in question.  Normally it is a node of type
+     'FUNCTION_TYPE' that describes the data type of the function.  From
+     this it is possible to obtain the data types of the value and
+     arguments (if known).
+
+     When a call to a library function is being considered, FUNDECL will
+     contain an identifier node for the library function.  Thus, if you
+     need to distinguish among various library functions, you can do so
+     by their names.  Note that "library function" in this context means
+     a function used to perform arithmetic, whose name is known
+     specially in the compiler and was not mentioned in the C code being
+     compiled.
+
+     SIZE is the number of bytes of arguments passed on the stack.  If a
+     variable number of bytes is passed, it is zero, and argument
+     popping will always be the responsibility of the calling function.
+
+     On the VAX, all functions always pop their arguments, so the
+     definition of this macro is SIZE.  On the 68000, using the standard
+     calling convention, no functions pop their arguments, so the value
+     of the macro is always 0 in this case.  But an alternative calling
+     convention is available in which functions that take a fixed number
+     of arguments pop them but other functions (such as 'printf') pop
+     nothing (the caller pops all).  When this convention is in use,
+     FUNTYPE is examined to determine whether a function takes a fixed
+     number of arguments.
+
+ -- Macro: CALL_POPS_ARGS (CUM)
+     A C expression that should indicate the number of bytes a call
+     sequence pops off the stack.  It is added to the value of
+     'RETURN_POPS_ARGS' when compiling a function call.
+
+     CUM is the variable in which all arguments to the called function
+     have been accumulated.
+
+     On certain architectures, such as the SH5, a call trampoline is
+     used that pops certain registers off the stack, depending on the
+     arguments that have been passed to the function.  Since this is a
+     property of the call site, not of the called function,
+     'RETURN_POPS_ARGS' is not appropriate.
+
+
+File: gccint.info,  Node: Register Arguments,  Next: Scalar Return,  Prev: Stack Arguments,  Up: Stack and Calling
+
+17.10.7 Passing Arguments in Registers
+--------------------------------------
+
+This section describes the macros which let you control how various
+types of arguments are passed in registers or how they are arranged in
+the stack.
+
+ -- Target Hook: rtx TARGET_FUNCTION_ARG (cumulative_args_t CA, enum
+          machine_mode MODE, const_tree TYPE, bool NAMED)
+     Return an RTX indicating whether a function argument is passed in a
+     register and if so, which register.
+
+     The arguments are CA, which summarizes all the previous arguments;
+     MODE, the machine mode of the argument; TYPE, the data type of the
+     argument as a tree node or 0 if that is not known (which happens
+     for C support library functions); and NAMED, which is 'true' for an
+     ordinary argument and 'false' for nameless arguments that
+     correspond to '...' in the called function's prototype.  TYPE can
+     be an incomplete type if a syntax error has previously occurred.
+
+     The return value is usually either a 'reg' RTX for the hard
+     register in which to pass the argument, or zero to pass the
+     argument on the stack.
+
+     The value of the expression can also be a 'parallel' RTX.  This is
+     used when an argument is passed in multiple locations.  The mode of
+     the 'parallel' should be the mode of the entire argument.  The
+     'parallel' holds any number of 'expr_list' pairs; each one
+     describes where part of the argument is passed.  In each
+     'expr_list' the first operand must be a 'reg' RTX for the hard
+     register in which to pass this part of the argument, and the mode
+     of the register RTX indicates how large this part of the argument
+     is.  The second operand of the 'expr_list' is a 'const_int' which
+     gives the offset in bytes into the entire argument of where this
+     part starts.  As a special exception the first 'expr_list' in the
+     'parallel' RTX may have a first operand of zero.  This indicates
+     that the entire argument is also stored on the stack.
+
+     The last time this hook is called, it is called with 'MODE ==
+     VOIDmode', and its result is passed to the 'call' or 'call_value'
+     pattern as operands 2 and 3 respectively.
+
+     The usual way to make the ISO library 'stdarg.h' work on a machine
+     where some arguments are usually passed in registers, is to cause
+     nameless arguments to be passed on the stack instead.  This is done
+     by making 'TARGET_FUNCTION_ARG' return 0 whenever NAMED is 'false'.
+
+     You may use the hook 'targetm.calls.must_pass_in_stack' in the
+     definition of this macro to determine if this argument is of a type
+     that must be passed in the stack.  If 'REG_PARM_STACK_SPACE' is not
+     defined and 'TARGET_FUNCTION_ARG' returns nonzero for such an
+     argument, the compiler will abort.  If 'REG_PARM_STACK_SPACE' is
+     defined, the argument will be computed in the stack and then loaded
+     into a register.
+
+ -- Target Hook: bool TARGET_MUST_PASS_IN_STACK (enum machine_mode MODE,
+          const_tree TYPE)
+     This target hook should return 'true' if we should not pass TYPE
+     solely in registers.  The file 'expr.h' defines a definition that
+     is usually appropriate, refer to 'expr.h' for additional
+     documentation.
+
+ -- Target Hook: rtx TARGET_FUNCTION_INCOMING_ARG (cumulative_args_t CA,
+          enum machine_mode MODE, const_tree TYPE, bool NAMED)
+     Define this hook if the target machine has "register windows", so
+     that the register in which a function sees an arguments is not
+     necessarily the same as the one in which the caller passed the
+     argument.
+
+     For such machines, 'TARGET_FUNCTION_ARG' computes the register in
+     which the caller passes the value, and
+     'TARGET_FUNCTION_INCOMING_ARG' should be defined in a similar
+     fashion to tell the function being called where the arguments will
+     arrive.
+
+     If 'TARGET_FUNCTION_INCOMING_ARG' is not defined,
+     'TARGET_FUNCTION_ARG' serves both purposes.
+
+ -- Target Hook: int TARGET_ARG_PARTIAL_BYTES (cumulative_args_t CUM,
+          enum machine_mode MODE, tree TYPE, bool NAMED)
+     This target hook returns the number of bytes at the beginning of an
+     argument that must be put in registers.  The value must be zero for
+     arguments that are passed entirely in registers or that are
+     entirely pushed on the stack.
+
+     On some machines, certain arguments must be passed partially in
+     registers and partially in memory.  On these machines, typically
+     the first few words of arguments are passed in registers, and the
+     rest on the stack.  If a multi-word argument (a 'double' or a
+     structure) crosses that boundary, its first few words must be
+     passed in registers and the rest must be pushed.  This macro tells
+     the compiler when this occurs, and how many bytes should go in
+     registers.
+
+     'TARGET_FUNCTION_ARG' for these arguments should return the first
+     register to be used by the caller for this argument; likewise
+     'TARGET_FUNCTION_INCOMING_ARG', for the called function.
+
+ -- Target Hook: bool TARGET_PASS_BY_REFERENCE (cumulative_args_t CUM,
+          enum machine_mode MODE, const_tree TYPE, bool NAMED)
+     This target hook should return 'true' if an argument at the
+     position indicated by CUM should be passed by reference.  This
+     predicate is queried after target independent reasons for being
+     passed by reference, such as 'TREE_ADDRESSABLE (type)'.
+
+     If the hook returns true, a copy of that argument is made in memory
+     and a pointer to the argument is passed instead of the argument
+     itself.  The pointer is passed in whatever way is appropriate for
+     passing a pointer to that type.
+
+ -- Target Hook: bool TARGET_CALLEE_COPIES (cumulative_args_t CUM, enum
+          machine_mode MODE, const_tree TYPE, bool NAMED)
+     The function argument described by the parameters to this hook is
+     known to be passed by reference.  The hook should return true if
+     the function argument should be copied by the callee instead of
+     copied by the caller.
+
+     For any argument for which the hook returns true, if it can be
+     determined that the argument is not modified, then a copy need not
+     be generated.
+
+     The default version of this hook always returns false.
+
+ -- Macro: CUMULATIVE_ARGS
+     A C type for declaring a variable that is used as the first
+     argument of 'TARGET_FUNCTION_ARG' and other related values.  For
+     some target machines, the type 'int' suffices and can hold the
+     number of bytes of argument so far.
+
+     There is no need to record in 'CUMULATIVE_ARGS' anything about the
+     arguments that have been passed on the stack.  The compiler has
+     other variables to keep track of that.  For target machines on
+     which all arguments are passed on the stack, there is no need to
+     store anything in 'CUMULATIVE_ARGS'; however, the data structure
+     must exist and should not be empty, so use 'int'.
+
+ -- Macro: OVERRIDE_ABI_FORMAT (FNDECL)
+     If defined, this macro is called before generating any code for a
+     function, but after the CFUN descriptor for the function has been
+     created.  The back end may use this macro to update CFUN to reflect
+     an ABI other than that which would normally be used by default.  If
+     the compiler is generating code for a compiler-generated function,
+     FNDECL may be 'NULL'.
+
+ -- Macro: INIT_CUMULATIVE_ARGS (CUM, FNTYPE, LIBNAME, FNDECL,
+          N_NAMED_ARGS)
+     A C statement (sans semicolon) for initializing the variable CUM
+     for the state at the beginning of the argument list.  The variable
+     has type 'CUMULATIVE_ARGS'.  The value of FNTYPE is the tree node
+     for the data type of the function which will receive the args, or 0
+     if the args are to a compiler support library function.  For direct
+     calls that are not libcalls, FNDECL contain the declaration node of
+     the function.  FNDECL is also set when 'INIT_CUMULATIVE_ARGS' is
+     used to find arguments for the function being compiled.
+     N_NAMED_ARGS is set to the number of named arguments, including a
+     structure return address if it is passed as a parameter, when
+     making a call.  When processing incoming arguments, N_NAMED_ARGS is
+     set to -1.
+
+     When processing a call to a compiler support library function,
+     LIBNAME identifies which one.  It is a 'symbol_ref' rtx which
+     contains the name of the function, as a string.  LIBNAME is 0 when
+     an ordinary C function call is being processed.  Thus, each time
+     this macro is called, either LIBNAME or FNTYPE is nonzero, but
+     never both of them at once.
+
+ -- Macro: INIT_CUMULATIVE_LIBCALL_ARGS (CUM, MODE, LIBNAME)
+     Like 'INIT_CUMULATIVE_ARGS' but only used for outgoing libcalls, it
+     gets a 'MODE' argument instead of FNTYPE, that would be 'NULL'.
+     INDIRECT would always be zero, too.  If this macro is not defined,
+     'INIT_CUMULATIVE_ARGS (cum, NULL_RTX, libname, 0)' is used instead.
+
+ -- Macro: INIT_CUMULATIVE_INCOMING_ARGS (CUM, FNTYPE, LIBNAME)
+     Like 'INIT_CUMULATIVE_ARGS' but overrides it for the purposes of
+     finding the arguments for the function being compiled.  If this
+     macro is undefined, 'INIT_CUMULATIVE_ARGS' is used instead.
+
+     The value passed for LIBNAME is always 0, since library routines
+     with special calling conventions are never compiled with GCC.  The
+     argument LIBNAME exists for symmetry with 'INIT_CUMULATIVE_ARGS'.
+
+ -- Target Hook: void TARGET_FUNCTION_ARG_ADVANCE (cumulative_args_t CA,
+          enum machine_mode MODE, const_tree TYPE, bool NAMED)
+     This hook updates the summarizer variable pointed to by CA to
+     advance past an argument in the argument list.  The values MODE,
+     TYPE and NAMED describe that argument.  Once this is done, the
+     variable CUM is suitable for analyzing the _following_ argument
+     with 'TARGET_FUNCTION_ARG', etc.
+
+     This hook need not do anything if the argument in question was
+     passed on the stack.  The compiler knows how to track the amount of
+     stack space used for arguments without any special help.
+
+ -- Macro: FUNCTION_ARG_OFFSET (MODE, TYPE)
+     If defined, a C expression that is the number of bytes to add to
+     the offset of the argument passed in memory.  This is needed for
+     the SPU, which passes 'char' and 'short' arguments in the preferred
+     slot that is in the middle of the quad word instead of starting at
+     the top.
+
+ -- Macro: FUNCTION_ARG_PADDING (MODE, TYPE)
+     If defined, a C expression which determines whether, and in which
+     direction, to pad out an argument with extra space.  The value
+     should be of type 'enum direction': either 'upward' to pad above
+     the argument, 'downward' to pad below, or 'none' to inhibit
+     padding.
+
+     The _amount_ of padding is not controlled by this macro, but by the
+     target hook 'TARGET_FUNCTION_ARG_ROUND_BOUNDARY'.  It is always
+     just enough to reach the next multiple of that boundary.
+
+     This macro has a default definition which is right for most
+     systems.  For little-endian machines, the default is to pad upward.
+     For big-endian machines, the default is to pad downward for an
+     argument of constant size shorter than an 'int', and upward
+     otherwise.
+
+ -- Macro: PAD_VARARGS_DOWN
+     If defined, a C expression which determines whether the default
+     implementation of va_arg will attempt to pad down before reading
+     the next argument, if that argument is smaller than its aligned
+     space as controlled by 'PARM_BOUNDARY'.  If this macro is not
+     defined, all such arguments are padded down if 'BYTES_BIG_ENDIAN'
+     is true.
+
+ -- Macro: BLOCK_REG_PADDING (MODE, TYPE, FIRST)
+     Specify padding for the last element of a block move between
+     registers and memory.  FIRST is nonzero if this is the only
+     element.  Defining this macro allows better control of register
+     function parameters on big-endian machines, without using
+     'PARALLEL' rtl.  In particular, 'MUST_PASS_IN_STACK' need not test
+     padding and mode of types in registers, as there is no longer a
+     "wrong" part of a register; For example, a three byte aggregate may
+     be passed in the high part of a register if so required.
+
+ -- Target Hook: unsigned int TARGET_FUNCTION_ARG_BOUNDARY (enum
+          machine_mode MODE, const_tree TYPE)
+     This hook returns the alignment boundary, in bits, of an argument
+     with the specified mode and type.  The default hook returns
+     'PARM_BOUNDARY' for all arguments.
+
+ -- Target Hook: unsigned int TARGET_FUNCTION_ARG_ROUND_BOUNDARY (enum
+          machine_mode MODE, const_tree TYPE)
+     Normally, the size of an argument is rounded up to 'PARM_BOUNDARY',
+     which is the default value for this hook.  You can define this hook
+     to return a different value if an argument size must be rounded to
+     a larger value.
+
+ -- Macro: FUNCTION_ARG_REGNO_P (REGNO)
+     A C expression that is nonzero if REGNO is the number of a hard
+     register in which function arguments are sometimes passed.  This
+     does _not_ include implicit arguments such as the static chain and
+     the structure-value address.  On many machines, no registers can be
+     used for this purpose since all function arguments are pushed on
+     the stack.
+
+ -- Target Hook: bool TARGET_SPLIT_COMPLEX_ARG (const_tree TYPE)
+     This hook should return true if parameter of type TYPE are passed
+     as two scalar parameters.  By default, GCC will attempt to pack
+     complex arguments into the target's word size.  Some ABIs require
+     complex arguments to be split and treated as their individual
+     components.  For example, on AIX64, complex floats should be passed
+     in a pair of floating point registers, even though a complex float
+     would fit in one 64-bit floating point register.
+
+     The default value of this hook is 'NULL', which is treated as
+     always false.
+
+ -- Target Hook: tree TARGET_BUILD_BUILTIN_VA_LIST (void)
+     This hook returns a type node for 'va_list' for the target.  The
+     default version of the hook returns 'void*'.
+
+ -- Target Hook: int TARGET_ENUM_VA_LIST_P (int IDX, const char **PNAME,
+          tree *PTREE)
+     This target hook is used in function 'c_common_nodes_and_builtins'
+     to iterate through the target specific builtin types for va_list.
+     The variable IDX is used as iterator.  PNAME has to be a pointer to
+     a 'const char *' and PTREE a pointer to a 'tree' typed variable.
+     The arguments PNAME and PTREE are used to store the result of this
+     macro and are set to the name of the va_list builtin type and its
+     internal type.  If the return value of this macro is zero, then
+     there is no more element.  Otherwise the IDX should be increased
+     for the next call of this macro to iterate through all types.
+
+ -- Target Hook: tree TARGET_FN_ABI_VA_LIST (tree FNDECL)
+     This hook returns the va_list type of the calling convention
+     specified by FNDECL.  The default version of this hook returns
+     'va_list_type_node'.
+
+ -- Target Hook: tree TARGET_CANONICAL_VA_LIST_TYPE (tree TYPE)
+     This hook returns the va_list type of the calling convention
+     specified by the type of TYPE.  If TYPE is not a valid va_list
+     type, it returns 'NULL_TREE'.
+
+ -- Target Hook: tree TARGET_GIMPLIFY_VA_ARG_EXPR (tree VALIST, tree
+          TYPE, gimple_seq *PRE_P, gimple_seq *POST_P)
+     This hook performs target-specific gimplification of 'VA_ARG_EXPR'.
+     The first two parameters correspond to the arguments to 'va_arg';
+     the latter two are as in 'gimplify.c:gimplify_expr'.
+
+ -- Target Hook: bool TARGET_VALID_POINTER_MODE (enum machine_mode MODE)
+     Define this to return nonzero if the port can handle pointers with
+     machine mode MODE.  The default version of this hook returns true
+     for both 'ptr_mode' and 'Pmode'.
+
+ -- Target Hook: bool TARGET_REF_MAY_ALIAS_ERRNO (struct ao_ref *REF)
+     Define this to return nonzero if the memory reference REF may alias
+     with the system C library errno location.  The default version of
+     this hook assumes the system C library errno location is either a
+     declaration of type int or accessed by dereferencing a pointer to
+     int.
+
+ -- Target Hook: bool TARGET_SCALAR_MODE_SUPPORTED_P (enum machine_mode
+          MODE)
+     Define this to return nonzero if the port is prepared to handle
+     insns involving scalar mode MODE.  For a scalar mode to be
+     considered supported, all the basic arithmetic and comparisons must
+     work.
+
+     The default version of this hook returns true for any mode required
+     to handle the basic C types (as defined by the port).  Included
+     here are the double-word arithmetic supported by the code in
+     'optabs.c'.
+
+ -- Target Hook: bool TARGET_VECTOR_MODE_SUPPORTED_P (enum machine_mode
+          MODE)
+     Define this to return nonzero if the port is prepared to handle
+     insns involving vector mode MODE.  At the very least, it must have
+     move patterns for this mode.
+
+ -- Target Hook: bool TARGET_ARRAY_MODE_SUPPORTED_P (enum machine_mode
+          MODE, unsigned HOST_WIDE_INT NELEMS)
+     Return true if GCC should try to use a scalar mode to store an
+     array of NELEMS elements, given that each element has mode MODE.
+     Returning true here overrides the usual 'MAX_FIXED_MODE' limit and
+     allows GCC to use any defined integer mode.
+
+     One use of this hook is to support vector load and store operations
+     that operate on several homogeneous vectors.  For example, ARM NEON
+     has operations like:
+
+          int8x8x3_t vld3_s8 (const int8_t *)
+
+     where the return type is defined as:
+
+          typedef struct int8x8x3_t
+          {
+            int8x8_t val[3];
+          } int8x8x3_t;
+
+     If this hook allows 'val' to have a scalar mode, then 'int8x8x3_t'
+     can have the same mode.  GCC can then store 'int8x8x3_t's in
+     registers rather than forcing them onto the stack.
+
+ -- Target Hook: bool TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P (enum
+          machine_mode MODE)
+     Define this to return nonzero for machine modes for which the port
+     has small register classes.  If this target hook returns nonzero
+     for a given MODE, the compiler will try to minimize the lifetime of
+     registers in MODE.  The hook may be called with 'VOIDmode' as
+     argument.  In this case, the hook is expected to return nonzero if
+     it returns nonzero for any mode.
+
+     On some machines, it is risky to let hard registers live across
+     arbitrary insns.  Typically, these machines have instructions that
+     require values to be in specific registers (like an accumulator),
+     and reload will fail if the required hard register is used for
+     another purpose across such an insn.
+
+     Passes before reload do not know which hard registers will be used
+     in an instruction, but the machine modes of the registers set or
+     used in the instruction are already known.  And for some machines,
+     register classes are small for, say, integer registers but not for
+     floating point registers.  For example, the AMD x86-64 architecture
+     requires specific registers for the legacy x86 integer
+     instructions, but there are many SSE registers for floating point
+     operations.  On such targets, a good strategy may be to return
+     nonzero from this hook for 'INTEGRAL_MODE_P' machine modes but zero
+     for the SSE register classes.
+
+     The default version of this hook returns false for any mode.  It is
+     always safe to redefine this hook to return with a nonzero value.
+     But if you unnecessarily define it, you will reduce the amount of
+     optimizations that can be performed in some cases.  If you do not
+     define this hook to return a nonzero value when it is required, the
+     compiler will run out of spill registers and print a fatal error
+     message.
+
+ -- Target Hook: unsigned int TARGET_FLAGS_REGNUM
+     If the target has a dedicated flags register, and it needs to use
+     the post-reload comparison elimination pass, then this value should
+     be set appropriately.
+
+
+File: gccint.info,  Node: Scalar Return,  Next: Aggregate Return,  Prev: Register Arguments,  Up: Stack and Calling
+
+17.10.8 How Scalar Function Values Are Returned
+-----------------------------------------------
+
+This section discusses the macros that control returning scalars as
+values--values that can fit in registers.
+
+ -- Target Hook: rtx TARGET_FUNCTION_VALUE (const_tree RET_TYPE,
+          const_tree FN_DECL_OR_TYPE, bool OUTGOING)
+
+     Define this to return an RTX representing the place where a
+     function returns or receives a value of data type RET_TYPE, a tree
+     node representing a data type.  FN_DECL_OR_TYPE is a tree node
+     representing 'FUNCTION_DECL' or 'FUNCTION_TYPE' of a function being
+     called.  If OUTGOING is false, the hook should compute the register
+     in which the caller will see the return value.  Otherwise, the hook
+     should return an RTX representing the place where a function
+     returns a value.
+
+     On many machines, only 'TYPE_MODE (RET_TYPE)' is relevant.
+     (Actually, on most machines, scalar values are returned in the same
+     place regardless of mode.)  The value of the expression is usually
+     a 'reg' RTX for the hard register where the return value is stored.
+     The value can also be a 'parallel' RTX, if the return value is in
+     multiple places.  See 'TARGET_FUNCTION_ARG' for an explanation of
+     the 'parallel' form.  Note that the callee will populate every
+     location specified in the 'parallel', but if the first element of
+     the 'parallel' contains the whole return value, callers will use
+     that element as the canonical location and ignore the others.  The
+     m68k port uses this type of 'parallel' to return pointers in both
+     '%a0' (the canonical location) and '%d0'.
+
+     If 'TARGET_PROMOTE_FUNCTION_RETURN' returns true, you must apply
+     the same promotion rules specified in 'PROMOTE_MODE' if VALTYPE is
+     a scalar type.
+
+     If the precise function being called is known, FUNC is a tree node
+     ('FUNCTION_DECL') for it; otherwise, FUNC is a null pointer.  This
+     makes it possible to use a different value-returning convention for
+     specific functions when all their calls are known.
+
+     Some target machines have "register windows" so that the register
+     in which a function returns its value is not the same as the one in
+     which the caller sees the value.  For such machines, you should
+     return different RTX depending on OUTGOING.
+
+     'TARGET_FUNCTION_VALUE' is not used for return values with
+     aggregate data types, because these are returned in another way.
+     See 'TARGET_STRUCT_VALUE_RTX' and related macros, below.
+
+ -- Macro: FUNCTION_VALUE (VALTYPE, FUNC)
+     This macro has been deprecated.  Use 'TARGET_FUNCTION_VALUE' for a
+     new target instead.
+
+ -- Macro: LIBCALL_VALUE (MODE)
+     A C expression to create an RTX representing the place where a
+     library function returns a value of mode MODE.
+
+     Note that "library function" in this context means a compiler
+     support routine, used to perform arithmetic, whose name is known
+     specially by the compiler and was not mentioned in the C code being
+     compiled.
+
+ -- Target Hook: rtx TARGET_LIBCALL_VALUE (enum machine_mode MODE,
+          const_rtx FUN)
+     Define this hook if the back-end needs to know the name of the
+     libcall function in order to determine where the result should be
+     returned.
+
+     The mode of the result is given by MODE and the name of the called
+     library function is given by FUN.  The hook should return an RTX
+     representing the place where the library function result will be
+     returned.
+
+     If this hook is not defined, then LIBCALL_VALUE will be used.
+
+ -- Macro: FUNCTION_VALUE_REGNO_P (REGNO)
+     A C expression that is nonzero if REGNO is the number of a hard
+     register in which the values of called function may come back.
+
+     A register whose use for returning values is limited to serving as
+     the second of a pair (for a value of type 'double', say) need not
+     be recognized by this macro.  So for most machines, this definition
+     suffices:
+
+          #define FUNCTION_VALUE_REGNO_P(N) ((N) == 0)
+
+     If the machine has register windows, so that the caller and the
+     called function use different registers for the return value, this
+     macro should recognize only the caller's register numbers.
+
+     This macro has been deprecated.  Use
+     'TARGET_FUNCTION_VALUE_REGNO_P' for a new target instead.
+
+ -- Target Hook: bool TARGET_FUNCTION_VALUE_REGNO_P (const unsigned int
+          REGNO)
+     A target hook that return 'true' if REGNO is the number of a hard
+     register in which the values of called function may come back.
+
+     A register whose use for returning values is limited to serving as
+     the second of a pair (for a value of type 'double', say) need not
+     be recognized by this target hook.
+
+     If the machine has register windows, so that the caller and the
+     called function use different registers for the return value, this
+     target hook should recognize only the caller's register numbers.
+
+     If this hook is not defined, then FUNCTION_VALUE_REGNO_P will be
+     used.
+
+ -- Macro: APPLY_RESULT_SIZE
+     Define this macro if 'untyped_call' and 'untyped_return' need more
+     space than is implied by 'FUNCTION_VALUE_REGNO_P' for saving and
+     restoring an arbitrary return value.
+
+ -- Target Hook: bool TARGET_RETURN_IN_MSB (const_tree TYPE)
+     This hook should return true if values of type TYPE are returned at
+     the most significant end of a register (in other words, if they are
+     padded at the least significant end).  You can assume that TYPE is
+     returned in a register; the caller is required to check this.
+
+     Note that the register provided by 'TARGET_FUNCTION_VALUE' must be
+     able to hold the complete return value.  For example, if a 1-, 2-
+     or 3-byte structure is returned at the most significant end of a
+     4-byte register, 'TARGET_FUNCTION_VALUE' should provide an 'SImode'
+     rtx.
+
+
+File: gccint.info,  Node: Aggregate Return,  Next: Caller Saves,  Prev: Scalar Return,  Up: Stack and Calling
+
+17.10.9 How Large Values Are Returned
+-------------------------------------
+
+When a function value's mode is 'BLKmode' (and in some other cases), the
+value is not returned according to 'TARGET_FUNCTION_VALUE' (*note Scalar
+Return::).  Instead, the caller passes the address of a block of memory
+in which the value should be stored.  This address is called the
+"structure value address".
+
+ This section describes how to control returning structure values in
+memory.
+
+ -- Target Hook: bool TARGET_RETURN_IN_MEMORY (const_tree TYPE,
+          const_tree FNTYPE)
+     This target hook should return a nonzero value to say to return the
+     function value in memory, just as large structures are always
+     returned.  Here TYPE will be the data type of the value, and FNTYPE
+     will be the type of the function doing the returning, or 'NULL' for
+     libcalls.
+
+     Note that values of mode 'BLKmode' must be explicitly handled by
+     this function.  Also, the option '-fpcc-struct-return' takes effect
+     regardless of this macro.  On most systems, it is possible to leave
+     the hook undefined; this causes a default definition to be used,
+     whose value is the constant 1 for 'BLKmode' values, and 0
+     otherwise.
+
+     Do not use this hook to indicate that structures and unions should
+     always be returned in memory.  You should instead use
+     'DEFAULT_PCC_STRUCT_RETURN' to indicate this.
+
+ -- Macro: DEFAULT_PCC_STRUCT_RETURN
+     Define this macro to be 1 if all structure and union return values
+     must be in memory.  Since this results in slower code, this should
+     be defined only if needed for compatibility with other compilers or
+     with an ABI.  If you define this macro to be 0, then the
+     conventions used for structure and union return values are decided
+     by the 'TARGET_RETURN_IN_MEMORY' target hook.
+
+     If not defined, this defaults to the value 1.
+
+ -- Target Hook: rtx TARGET_STRUCT_VALUE_RTX (tree FNDECL, int INCOMING)
+     This target hook should return the location of the structure value
+     address (normally a 'mem' or 'reg'), or 0 if the address is passed
+     as an "invisible" first argument.  Note that FNDECL may be 'NULL',
+     for libcalls.  You do not need to define this target hook if the
+     address is always passed as an "invisible" first argument.
+
+     On some architectures the place where the structure value address
+     is found by the called function is not the same place that the
+     caller put it.  This can be due to register windows, or it could be
+     because the function prologue moves it to a different place.
+     INCOMING is '1' or '2' when the location is needed in the context
+     of the called function, and '0' in the context of the caller.
+
+     If INCOMING is nonzero and the address is to be found on the stack,
+     return a 'mem' which refers to the frame pointer.  If INCOMING is
+     '2', the result is being used to fetch the structure value address
+     at the beginning of a function.  If you need to emit adjusting
+     code, you should do it at this point.
+
+ -- Macro: PCC_STATIC_STRUCT_RETURN
+     Define this macro if the usual system convention on the target
+     machine for returning structures and unions is for the called
+     function to return the address of a static variable containing the
+     value.
+
+     Do not define this if the usual system convention is for the caller
+     to pass an address to the subroutine.
+
+     This macro has effect in '-fpcc-struct-return' mode, but it does
+     nothing when you use '-freg-struct-return' mode.
+
+ -- Target Hook: enum machine_mode TARGET_GET_RAW_RESULT_MODE (int
+          REGNO)
+     This target hook returns the mode to be used when accessing raw
+     return registers in '__builtin_return'.  Define this macro if the
+     value in REG_RAW_MODE is not correct.
+
+ -- Target Hook: enum machine_mode TARGET_GET_RAW_ARG_MODE (int REGNO)
+     This target hook returns the mode to be used when accessing raw
+     argument registers in '__builtin_apply_args'.  Define this macro if
+     the value in REG_RAW_MODE is not correct.
+
+
+File: gccint.info,  Node: Caller Saves,  Next: Function Entry,  Prev: Aggregate Return,  Up: Stack and Calling
+
+17.10.10 Caller-Saves Register Allocation
+-----------------------------------------
+
+If you enable it, GCC can save registers around function calls.  This
+makes it possible to use call-clobbered registers to hold variables that
+must live across calls.
+
+ -- Macro: CALLER_SAVE_PROFITABLE (REFS, CALLS)
+     A C expression to determine whether it is worthwhile to consider
+     placing a pseudo-register in a call-clobbered hard register and
+     saving and restoring it around each function call.  The expression
+     should be 1 when this is worth doing, and 0 otherwise.
+
+     If you don't define this macro, a default is used which is good on
+     most machines: '4 * CALLS < REFS'.
+
+ -- Macro: HARD_REGNO_CALLER_SAVE_MODE (REGNO, NREGS)
+     A C expression specifying which mode is required for saving NREGS
+     of a pseudo-register in call-clobbered hard register REGNO.  If
+     REGNO is unsuitable for caller save, 'VOIDmode' should be returned.
+     For most machines this macro need not be defined since GCC will
+     select the smallest suitable mode.
+
+
+File: gccint.info,  Node: Function Entry,  Next: Profiling,  Prev: Caller Saves,  Up: Stack and Calling
+
+17.10.11 Function Entry and Exit
+--------------------------------
+
+This section describes the macros that output function entry
+("prologue") and exit ("epilogue") code.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_PROLOGUE (FILE *FILE,
+          HOST_WIDE_INT SIZE)
+     If defined, a function that outputs the assembler code for entry to
+     a function.  The prologue is responsible for setting up the stack
+     frame, initializing the frame pointer register, saving registers
+     that must be saved, and allocating SIZE additional bytes of storage
+     for the local variables.  SIZE is an integer.  FILE is a stdio
+     stream to which the assembler code should be output.
+
+     The label for the beginning of the function need not be output by
+     this macro.  That has already been done when the macro is run.
+
+     To determine which registers to save, the macro can refer to the
+     array 'regs_ever_live': element R is nonzero if hard register R is
+     used anywhere within the function.  This implies the function
+     prologue should save register R, provided it is not one of the
+     call-used registers.  ('TARGET_ASM_FUNCTION_EPILOGUE' must likewise
+     use 'regs_ever_live'.)
+
+     On machines that have "register windows", the function entry code
+     does not save on the stack the registers that are in the windows,
+     even if they are supposed to be preserved by function calls;
+     instead it takes appropriate steps to "push" the register stack, if
+     any non-call-used registers are used in the function.
+
+     On machines where functions may or may not have frame-pointers, the
+     function entry code must vary accordingly; it must set up the frame
+     pointer if one is wanted, and not otherwise.  To determine whether
+     a frame pointer is in wanted, the macro can refer to the variable
+     'frame_pointer_needed'.  The variable's value will be 1 at run time
+     in a function that needs a frame pointer.  *Note Elimination::.
+
+     The function entry code is responsible for allocating any stack
+     space required for the function.  This stack space consists of the
+     regions listed below.  In most cases, these regions are allocated
+     in the order listed, with the last listed region closest to the top
+     of the stack (the lowest address if 'STACK_GROWS_DOWNWARD' is
+     defined, and the highest address if it is not defined).  You can
+     use a different order for a machine if doing so is more convenient
+     or required for compatibility reasons.  Except in cases where
+     required by standard or by a debugger, there is no reason why the
+     stack layout used by GCC need agree with that used by other
+     compilers for a machine.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_END_PROLOGUE (FILE *FILE)
+     If defined, a function that outputs assembler code at the end of a
+     prologue.  This should be used when the function prologue is being
+     emitted as RTL, and you have some extra assembler that needs to be
+     emitted.  *Note prologue instruction pattern::.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_BEGIN_EPILOGUE (FILE *FILE)
+     If defined, a function that outputs assembler code at the start of
+     an epilogue.  This should be used when the function epilogue is
+     being emitted as RTL, and you have some extra assembler that needs
+     to be emitted.  *Note epilogue instruction pattern::.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_EPILOGUE (FILE *FILE,
+          HOST_WIDE_INT SIZE)
+     If defined, a function that outputs the assembler code for exit
+     from a function.  The epilogue is responsible for restoring the
+     saved registers and stack pointer to their values when the function
+     was called, and returning control to the caller.  This macro takes
+     the same arguments as the macro 'TARGET_ASM_FUNCTION_PROLOGUE', and
+     the registers to restore are determined from 'regs_ever_live' and
+     'CALL_USED_REGISTERS' in the same way.
+
+     On some machines, there is a single instruction that does all the
+     work of returning from the function.  On these machines, give that
+     instruction the name 'return' and do not define the macro
+     'TARGET_ASM_FUNCTION_EPILOGUE' at all.
+
+     Do not define a pattern named 'return' if you want the
+     'TARGET_ASM_FUNCTION_EPILOGUE' to be used.  If you want the target
+     switches to control whether return instructions or epilogues are
+     used, define a 'return' pattern with a validity condition that
+     tests the target switches appropriately.  If the 'return' pattern's
+     validity condition is false, epilogues will be used.
+
+     On machines where functions may or may not have frame-pointers, the
+     function exit code must vary accordingly.  Sometimes the code for
+     these two cases is completely different.  To determine whether a
+     frame pointer is wanted, the macro can refer to the variable
+     'frame_pointer_needed'.  The variable's value will be 1 when
+     compiling a function that needs a frame pointer.
+
+     Normally, 'TARGET_ASM_FUNCTION_PROLOGUE' and
+     'TARGET_ASM_FUNCTION_EPILOGUE' must treat leaf functions specially.
+     The C variable 'current_function_is_leaf' is nonzero for such a
+     function.  *Note Leaf Functions::.
+
+     On some machines, some functions pop their arguments on exit while
+     others leave that for the caller to do.  For example, the 68020
+     when given '-mrtd' pops arguments in functions that take a fixed
+     number of arguments.
+
+     Your definition of the macro 'RETURN_POPS_ARGS' decides which
+     functions pop their own arguments.  'TARGET_ASM_FUNCTION_EPILOGUE'
+     needs to know what was decided.  The number of bytes of the current
+     function's arguments that this function should pop is available in
+     'crtl->args.pops_args'.  *Note Scalar Return::.
+
+   * A region of 'crtl->args.pretend_args_size' bytes of uninitialized
+     space just underneath the first argument arriving on the stack.
+     (This may not be at the very start of the allocated stack region if
+     the calling sequence has pushed anything else since pushing the
+     stack arguments.  But usually, on such machines, nothing else has
+     been pushed yet, because the function prologue itself does all the
+     pushing.)  This region is used on machines where an argument may be
+     passed partly in registers and partly in memory, and, in some cases
+     to support the features in '<stdarg.h>'.
+
+   * An area of memory used to save certain registers used by the
+     function.  The size of this area, which may also include space for
+     such things as the return address and pointers to previous stack
+     frames, is machine-specific and usually depends on which registers
+     have been used in the function.  Machines with register windows
+     often do not require a save area.
+
+   * A region of at least SIZE bytes, possibly rounded up to an
+     allocation boundary, to contain the local variables of the
+     function.  On some machines, this region and the save area may
+     occur in the opposite order, with the save area closer to the top
+     of the stack.
+
+   * Optionally, when 'ACCUMULATE_OUTGOING_ARGS' is defined, a region of
+     'crtl->outgoing_args_size' bytes to be used for outgoing argument
+     lists of the function.  *Note Stack Arguments::.
+
+ -- Macro: EXIT_IGNORE_STACK
+     Define this macro as a C expression that is nonzero if the return
+     instruction or the function epilogue ignores the value of the stack
+     pointer; in other words, if it is safe to delete an instruction to
+     adjust the stack pointer before a return from the function.  The
+     default is 0.
+
+     Note that this macro's value is relevant only for functions for
+     which frame pointers are maintained.  It is never safe to delete a
+     final stack adjustment in a function that has no frame pointer, and
+     the compiler knows this regardless of 'EXIT_IGNORE_STACK'.
+
+ -- Macro: EPILOGUE_USES (REGNO)
+     Define this macro as a C expression that is nonzero for registers
+     that are used by the epilogue or the 'return' pattern.  The stack
+     and frame pointer registers are already assumed to be used as
+     needed.
+
+ -- Macro: EH_USES (REGNO)
+     Define this macro as a C expression that is nonzero for registers
+     that are used by the exception handling mechanism, and so should be
+     considered live on entry to an exception edge.
+
+ -- Target Hook: void TARGET_ASM_OUTPUT_MI_THUNK (FILE *FILE, tree
+          THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET,
+          tree FUNCTION)
+     A function that outputs the assembler code for a thunk function,
+     used to implement C++ virtual function calls with multiple
+     inheritance.  The thunk acts as a wrapper around a virtual
+     function, adjusting the implicit object parameter before handing
+     control off to the real function.
+
+     First, emit code to add the integer DELTA to the location that
+     contains the incoming first argument.  Assume that this argument
+     contains a pointer, and is the one used to pass the 'this' pointer
+     in C++.  This is the incoming argument _before_ the function
+     prologue, e.g. '%o0' on a sparc.  The addition must preserve the
+     values of all other incoming arguments.
+
+     Then, if VCALL_OFFSET is nonzero, an additional adjustment should
+     be made after adding 'delta'.  In particular, if P is the adjusted
+     pointer, the following adjustment should be made:
+
+          p += (*((ptrdiff_t **)p))[vcall_offset/sizeof(ptrdiff_t)]
+
+     After the additions, emit code to jump to FUNCTION, which is a
+     'FUNCTION_DECL'.  This is a direct pure jump, not a call, and does
+     not touch the return address.  Hence returning from FUNCTION will
+     return to whoever called the current 'thunk'.
+
+     The effect must be as if FUNCTION had been called directly with the
+     adjusted first argument.  This macro is responsible for emitting
+     all of the code for a thunk function;
+     'TARGET_ASM_FUNCTION_PROLOGUE' and 'TARGET_ASM_FUNCTION_EPILOGUE'
+     are not invoked.
+
+     The THUNK_FNDECL is redundant.  (DELTA and FUNCTION have already
+     been extracted from it.)  It might possibly be useful on some
+     targets, but probably not.
+
+     If you do not define this macro, the target-independent code in the
+     C++ front end will generate a less efficient heavyweight thunk that
+     calls FUNCTION instead of jumping to it.  The generic approach does
+     not support varargs.
+
+ -- Target Hook: bool TARGET_ASM_CAN_OUTPUT_MI_THUNK (const_tree
+          THUNK_FNDECL, HOST_WIDE_INT DELTA, HOST_WIDE_INT VCALL_OFFSET,
+          const_tree FUNCTION)
+     A function that returns true if TARGET_ASM_OUTPUT_MI_THUNK would be
+     able to output the assembler code for the thunk function specified
+     by the arguments it is passed, and false otherwise.  In the latter
+     case, the generic approach will be used by the C++ front end, with
+     the limitations previously exposed.
+
+
+File: gccint.info,  Node: Profiling,  Next: Tail Calls,  Prev: Function Entry,  Up: Stack and Calling
+
+17.10.12 Generating Code for Profiling
+--------------------------------------
+
+These macros will help you generate code for profiling.
+
+ -- Macro: FUNCTION_PROFILER (FILE, LABELNO)
+     A C statement or compound statement to output to FILE some
+     assembler code to call the profiling subroutine 'mcount'.
+
+     The details of how 'mcount' expects to be called are determined by
+     your operating system environment, not by GCC.  To figure them out,
+     compile a small program for profiling using the system's installed
+     C compiler and look at the assembler code that results.
+
+     Older implementations of 'mcount' expect the address of a counter
+     variable to be loaded into some register.  The name of this
+     variable is 'LP' followed by the number LABELNO, so you would
+     generate the name using 'LP%d' in a 'fprintf'.
+
+ -- Macro: PROFILE_HOOK
+     A C statement or compound statement to output to FILE some assembly
+     code to call the profiling subroutine 'mcount' even the target does
+     not support profiling.
+
+ -- Macro: NO_PROFILE_COUNTERS
+     Define this macro to be an expression with a nonzero value if the
+     'mcount' subroutine on your system does not need a counter variable
+     allocated for each function.  This is true for almost all modern
+     implementations.  If you define this macro, you must not use the
+     LABELNO argument to 'FUNCTION_PROFILER'.
+
+ -- Macro: PROFILE_BEFORE_PROLOGUE
+     Define this macro if the code for function profiling should come
+     before the function prologue.  Normally, the profiling code comes
+     after.
+
+
+File: gccint.info,  Node: Tail Calls,  Next: Stack Smashing Protection,  Prev: Profiling,  Up: Stack and Calling
+
+17.10.13 Permitting tail calls
+------------------------------
+
+ -- Target Hook: bool TARGET_FUNCTION_OK_FOR_SIBCALL (tree DECL, tree
+          EXP)
+     True if it is OK to do sibling call optimization for the specified
+     call expression EXP.  DECL will be the called function, or 'NULL'
+     if this is an indirect call.
+
+     It is not uncommon for limitations of calling conventions to
+     prevent tail calls to functions outside the current unit of
+     translation, or during PIC compilation.  The hook is used to
+     enforce these restrictions, as the 'sibcall' md pattern can not
+     fail, or fall over to a "normal" call.  The criteria for successful
+     sibling call optimization may vary greatly between different
+     architectures.
+
+ -- Target Hook: void TARGET_EXTRA_LIVE_ON_ENTRY (bitmap REGS)
+     Add any hard registers to REGS that are live on entry to the
+     function.  This hook only needs to be defined to provide registers
+     that cannot be found by examination of FUNCTION_ARG_REGNO_P, the
+     callee saved registers, STATIC_CHAIN_INCOMING_REGNUM,
+     STATIC_CHAIN_REGNUM, TARGET_STRUCT_VALUE_RTX, FRAME_POINTER_REGNUM,
+     EH_USES, FRAME_POINTER_REGNUM, ARG_POINTER_REGNUM, and the
+     PIC_OFFSET_TABLE_REGNUM.
+
+ -- Target Hook: void TARGET_SET_UP_BY_PROLOGUE (struct
+          hard_reg_set_container *)
+     This hook should add additional registers that are computed by the
+     prologue to the hard regset for shrink-wrapping optimization
+     purposes.
+
+ -- Target Hook: bool TARGET_WARN_FUNC_RETURN (tree)
+     True if a function's return statements should be checked for
+     matching the function's return type.  This includes checking for
+     falling off the end of a non-void function.  Return false if no
+     such check should be made.
+
+
+File: gccint.info,  Node: Stack Smashing Protection,  Prev: Tail Calls,  Up: Stack and Calling
+
+17.10.14 Stack smashing protection
+----------------------------------
+
+ -- Target Hook: tree TARGET_STACK_PROTECT_GUARD (void)
+     This hook returns a 'DECL' node for the external variable to use
+     for the stack protection guard.  This variable is initialized by
+     the runtime to some random value and is used to initialize the
+     guard value that is placed at the top of the local stack frame.
+     The type of this variable must be 'ptr_type_node'.
+
+     The default version of this hook creates a variable called
+     '__stack_chk_guard', which is normally defined in 'libgcc2.c'.
+
+ -- Target Hook: tree TARGET_STACK_PROTECT_FAIL (void)
+     This hook returns a 'CALL_EXPR' that alerts the runtime that the
+     stack protect guard variable has been modified.  This expression
+     should involve a call to a 'noreturn' function.
+
+     The default version of this hook invokes a function called
+     '__stack_chk_fail', taking no arguments.  This function is normally
+     defined in 'libgcc2.c'.
+
+ -- Common Target Hook: bool TARGET_SUPPORTS_SPLIT_STACK (bool REPORT,
+          struct gcc_options *OPTS)
+     Whether this target supports splitting the stack when the options
+     described in OPTS have been passed.  This is called after options
+     have been parsed, so the target may reject splitting the stack in
+     some configurations.  The default version of this hook returns
+     false.  If REPORT is true, this function may issue a warning or
+     error; if REPORT is false, it must simply return a value
+
+
+File: gccint.info,  Node: Varargs,  Next: Trampolines,  Prev: Stack and Calling,  Up: Target Macros
+
+17.11 Implementing the Varargs Macros
+=====================================
+
+GCC comes with an implementation of '<varargs.h>' and '<stdarg.h>' that
+work without change on machines that pass arguments on the stack.  Other
+machines require their own implementations of varargs, and the two
+machine independent header files must have conditionals to include it.
+
+ ISO '<stdarg.h>' differs from traditional '<varargs.h>' mainly in the
+calling convention for 'va_start'.  The traditional implementation takes
+just one argument, which is the variable in which to store the argument
+pointer.  The ISO implementation of 'va_start' takes an additional
+second argument.  The user is supposed to write the last named argument
+of the function here.
+
+ However, 'va_start' should not use this argument.  The way to find the
+end of the named arguments is with the built-in functions described
+below.
+
+ -- Macro: __builtin_saveregs ()
+     Use this built-in function to save the argument registers in memory
+     so that the varargs mechanism can access them.  Both ISO and
+     traditional versions of 'va_start' must use '__builtin_saveregs',
+     unless you use 'TARGET_SETUP_INCOMING_VARARGS' (see below) instead.
+
+     On some machines, '__builtin_saveregs' is open-coded under the
+     control of the target hook 'TARGET_EXPAND_BUILTIN_SAVEREGS'.  On
+     other machines, it calls a routine written in assembler language,
+     found in 'libgcc2.c'.
+
+     Code generated for the call to '__builtin_saveregs' appears at the
+     beginning of the function, as opposed to where the call to
+     '__builtin_saveregs' is written, regardless of what the code is.
+     This is because the registers must be saved before the function
+     starts to use them for its own purposes.
+
+ -- Macro: __builtin_next_arg (LASTARG)
+     This builtin returns the address of the first anonymous stack
+     argument, as type 'void *'.  If 'ARGS_GROW_DOWNWARD', it returns
+     the address of the location above the first anonymous stack
+     argument.  Use it in 'va_start' to initialize the pointer for
+     fetching arguments from the stack.  Also use it in 'va_start' to
+     verify that the second parameter LASTARG is the last named argument
+     of the current function.
+
+ -- Macro: __builtin_classify_type (OBJECT)
+     Since each machine has its own conventions for which data types are
+     passed in which kind of register, your implementation of 'va_arg'
+     has to embody these conventions.  The easiest way to categorize the
+     specified data type is to use '__builtin_classify_type' together
+     with 'sizeof' and '__alignof__'.
+
+     '__builtin_classify_type' ignores the value of OBJECT, considering
+     only its data type.  It returns an integer describing what kind of
+     type that is--integer, floating, pointer, structure, and so on.
+
+     The file 'typeclass.h' defines an enumeration that you can use to
+     interpret the values of '__builtin_classify_type'.
+
+ These machine description macros help implement varargs:
+
+ -- Target Hook: rtx TARGET_EXPAND_BUILTIN_SAVEREGS (void)
+     If defined, this hook produces the machine-specific code for a call
+     to '__builtin_saveregs'.  This code will be moved to the very
+     beginning of the function, before any parameter access are made.
+     The return value of this function should be an RTX that contains
+     the value to use as the return of '__builtin_saveregs'.
+
+ -- Target Hook: void TARGET_SETUP_INCOMING_VARARGS (cumulative_args_t
+          ARGS_SO_FAR, enum machine_mode MODE, tree TYPE, int
+          *PRETEND_ARGS_SIZE, int SECOND_TIME)
+     This target hook offers an alternative to using
+     '__builtin_saveregs' and defining the hook
+     'TARGET_EXPAND_BUILTIN_SAVEREGS'.  Use it to store the anonymous
+     register arguments into the stack so that all the arguments appear
+     to have been passed consecutively on the stack.  Once this is done,
+     you can use the standard implementation of varargs that works for
+     machines that pass all their arguments on the stack.
+
+     The argument ARGS_SO_FAR points to the 'CUMULATIVE_ARGS' data
+     structure, containing the values that are obtained after processing
+     the named arguments.  The arguments MODE and TYPE describe the last
+     named argument--its machine mode and its data type as a tree node.
+
+     The target hook should do two things: first, push onto the stack
+     all the argument registers _not_ used for the named arguments, and
+     second, store the size of the data thus pushed into the
+     'int'-valued variable pointed to by PRETEND_ARGS_SIZE.  The value
+     that you store here will serve as additional offset for setting up
+     the stack frame.
+
+     Because you must generate code to push the anonymous arguments at
+     compile time without knowing their data types,
+     'TARGET_SETUP_INCOMING_VARARGS' is only useful on machines that
+     have just a single category of argument register and use it
+     uniformly for all data types.
+
+     If the argument SECOND_TIME is nonzero, it means that the arguments
+     of the function are being analyzed for the second time.  This
+     happens for an inline function, which is not actually compiled
+     until the end of the source file.  The hook
+     'TARGET_SETUP_INCOMING_VARARGS' should not generate any
+     instructions in this case.
+
+ -- Target Hook: bool TARGET_STRICT_ARGUMENT_NAMING (cumulative_args_t
+          CA)
+     Define this hook to return 'true' if the location where a function
+     argument is passed depends on whether or not it is a named
+     argument.
+
+     This hook controls how the NAMED argument to 'TARGET_FUNCTION_ARG'
+     is set for varargs and stdarg functions.  If this hook returns
+     'true', the NAMED argument is always true for named arguments, and
+     false for unnamed arguments.  If it returns 'false', but
+     'TARGET_PRETEND_OUTGOING_VARARGS_NAMED' returns 'true', then all
+     arguments are treated as named.  Otherwise, all named arguments
+     except the last are treated as named.
+
+     You need not define this hook if it always returns 'false'.
+
+ -- Target Hook: bool TARGET_PRETEND_OUTGOING_VARARGS_NAMED
+          (cumulative_args_t CA)
+     If you need to conditionally change ABIs so that one works with
+     'TARGET_SETUP_INCOMING_VARARGS', but the other works like neither
+     'TARGET_SETUP_INCOMING_VARARGS' nor 'TARGET_STRICT_ARGUMENT_NAMING'
+     was defined, then define this hook to return 'true' if
+     'TARGET_SETUP_INCOMING_VARARGS' is used, 'false' otherwise.
+     Otherwise, you should not define this hook.
+
+
+File: gccint.info,  Node: Trampolines,  Next: Library Calls,  Prev: Varargs,  Up: Target Macros
+
+17.12 Trampolines for Nested Functions
+======================================
+
+A "trampoline" is a small piece of code that is created at run time when
+the address of a nested function is taken.  It normally resides on the
+stack, in the stack frame of the containing function.  These macros tell
+GCC how to generate code to allocate and initialize a trampoline.
+
+ The instructions in the trampoline must do two things: load a constant
+address into the static chain register, and jump to the real address of
+the nested function.  On CISC machines such as the m68k, this requires
+two instructions, a move immediate and a jump.  Then the two addresses
+exist in the trampoline as word-long immediate operands.  On RISC
+machines, it is often necessary to load each address into a register in
+two parts.  Then pieces of each address form separate immediate
+operands.
+
+ The code generated to initialize the trampoline must store the variable
+parts--the static chain value and the function address--into the
+immediate operands of the instructions.  On a CISC machine, this is
+simply a matter of copying each address to a memory reference at the
+proper offset from the start of the trampoline.  On a RISC machine, it
+may be necessary to take out pieces of the address and store them
+separately.
+
+ -- Target Hook: void TARGET_ASM_TRAMPOLINE_TEMPLATE (FILE *F)
+     This hook is called by 'assemble_trampoline_template' to output, on
+     the stream F, assembler code for a block of data that contains the
+     constant parts of a trampoline.  This code should not include a
+     label--the label is taken care of automatically.
+
+     If you do not define this hook, it means no template is needed for
+     the target.  Do not define this hook on systems where the block
+     move code to copy the trampoline into place would be larger than
+     the code to generate it on the spot.
+
+ -- Macro: TRAMPOLINE_SECTION
+     Return the section into which the trampoline template is to be
+     placed (*note Sections::).  The default value is
+     'readonly_data_section'.
+
+ -- Macro: TRAMPOLINE_SIZE
+     A C expression for the size in bytes of the trampoline, as an
+     integer.
+
+ -- Macro: TRAMPOLINE_ALIGNMENT
+     Alignment required for trampolines, in bits.
+
+     If you don't define this macro, the value of 'FUNCTION_ALIGNMENT'
+     is used for aligning trampolines.
+
+ -- Target Hook: void TARGET_TRAMPOLINE_INIT (rtx M_TRAMP, tree FNDECL,
+          rtx STATIC_CHAIN)
+     This hook is called to initialize a trampoline.  M_TRAMP is an RTX
+     for the memory block for the trampoline; FNDECL is the
+     'FUNCTION_DECL' for the nested function; STATIC_CHAIN is an RTX for
+     the static chain value that should be passed to the function when
+     it is called.
+
+     If the target defines 'TARGET_ASM_TRAMPOLINE_TEMPLATE', then the
+     first thing this hook should do is emit a block move into M_TRAMP
+     from the memory block returned by 'assemble_trampoline_template'.
+     Note that the block move need only cover the constant parts of the
+     trampoline.  If the target isolates the variable parts of the
+     trampoline to the end, not all 'TRAMPOLINE_SIZE' bytes need be
+     copied.
+
+     If the target requires any other actions, such as flushing caches
+     or enabling stack execution, these actions should be performed
+     after initializing the trampoline proper.
+
+ -- Target Hook: rtx TARGET_TRAMPOLINE_ADJUST_ADDRESS (rtx ADDR)
+     This hook should perform any machine-specific adjustment in the
+     address of the trampoline.  Its argument contains the address of
+     the memory block that was passed to 'TARGET_TRAMPOLINE_INIT'.  In
+     case the address to be used for a function call should be different
+     from the address at which the template was stored, the different
+     address should be returned; otherwise ADDR should be returned
+     unchanged.  If this hook is not defined, ADDR will be used for
+     function calls.
+
+ Implementing trampolines is difficult on many machines because they
+have separate instruction and data caches.  Writing into a stack
+location fails to clear the memory in the instruction cache, so when the
+program jumps to that location, it executes the old contents.
+
+ Here are two possible solutions.  One is to clear the relevant parts of
+the instruction cache whenever a trampoline is set up.  The other is to
+make all trampolines identical, by having them jump to a standard
+subroutine.  The former technique makes trampoline execution faster; the
+latter makes initialization faster.
+
+ To clear the instruction cache when a trampoline is initialized, define
+the following macro.
+
+ -- Macro: CLEAR_INSN_CACHE (BEG, END)
+     If defined, expands to a C expression clearing the _instruction
+     cache_ in the specified interval.  The definition of this macro
+     would typically be a series of 'asm' statements.  Both BEG and END
+     are both pointer expressions.
+
+ To use a standard subroutine, define the following macro.  In addition,
+you must make sure that the instructions in a trampoline fill an entire
+cache line with identical instructions, or else ensure that the
+beginning of the trampoline code is always aligned at the same point in
+its cache line.  Look in 'm68k.h' as a guide.
+
+ -- Macro: TRANSFER_FROM_TRAMPOLINE
+     Define this macro if trampolines need a special subroutine to do
+     their work.  The macro should expand to a series of 'asm'
+     statements which will be compiled with GCC.  They go in a library
+     function named '__transfer_from_trampoline'.
+
+     If you need to avoid executing the ordinary prologue code of a
+     compiled C function when you jump to the subroutine, you can do so
+     by placing a special label of your own in the assembler code.  Use
+     one 'asm' statement to generate an assembler label, and another to
+     make the label global.  Then trampolines can use that label to jump
+     directly to your special assembler code.
+
+
+File: gccint.info,  Node: Library Calls,  Next: Addressing Modes,  Prev: Trampolines,  Up: Target Macros
+
+17.13 Implicit Calls to Library Routines
+========================================
+
+Here is an explanation of implicit calls to library routines.
+
+ -- Macro: DECLARE_LIBRARY_RENAMES
+     This macro, if defined, should expand to a piece of C code that
+     will get expanded when compiling functions for libgcc.a.  It can be
+     used to provide alternate names for GCC's internal library
+     functions if there are ABI-mandated names that the compiler should
+     provide.
+
+ -- Target Hook: void TARGET_INIT_LIBFUNCS (void)
+     This hook should declare additional library routines or rename
+     existing ones, using the functions 'set_optab_libfunc' and
+     'init_one_libfunc' defined in 'optabs.c'.  'init_optabs' calls this
+     macro after initializing all the normal library routines.
+
+     The default is to do nothing.  Most ports don't need to define this
+     hook.
+
+ -- Target Hook: bool TARGET_LIBFUNC_GNU_PREFIX
+     If false (the default), internal library routines start with two
+     underscores.  If set to true, these routines start with '__gnu_'
+     instead.  E.g., '__muldi3' changes to '__gnu_muldi3'.  This
+     currently only affects functions defined in 'libgcc2.c'.  If this
+     is set to true, the 'tm.h' file must also '#define
+     LIBGCC2_GNU_PREFIX'.
+
+ -- Macro: FLOAT_LIB_COMPARE_RETURNS_BOOL (MODE, COMPARISON)
+     This macro should return 'true' if the library routine that
+     implements the floating point comparison operator COMPARISON in
+     mode MODE will return a boolean, and FALSE if it will return a
+     tristate.
+
+     GCC's own floating point libraries return tristates from the
+     comparison operators, so the default returns false always.  Most
+     ports don't need to define this macro.
+
+ -- Macro: TARGET_LIB_INT_CMP_BIASED
+     This macro should evaluate to 'true' if the integer comparison
+     functions (like '__cmpdi2') return 0 to indicate that the first
+     operand is smaller than the second, 1 to indicate that they are
+     equal, and 2 to indicate that the first operand is greater than the
+     second.  If this macro evaluates to 'false' the comparison
+     functions return -1, 0, and 1 instead of 0, 1, and 2.  If the
+     target uses the routines in 'libgcc.a', you do not need to define
+     this macro.
+
+ -- Macro: TARGET_HAS_NO_HW_DIVIDE
+     This macro should be defined if the target has no hardware divide
+     instructions.  If this macro is defined, GCC will use an algorithm
+     which make use of simple logical and arithmetic operations for
+     64-bit division.  If the macro is not defined, GCC will use an
+     algorithm which make use of a 64-bit by 32-bit divide primitive.
+
+ -- Macro: TARGET_EDOM
+     The value of 'EDOM' on the target machine, as a C integer constant
+     expression.  If you don't define this macro, GCC does not attempt
+     to deposit the value of 'EDOM' into 'errno' directly.  Look in
+     '/usr/include/errno.h' to find the value of 'EDOM' on your system.
+
+     If you do not define 'TARGET_EDOM', then compiled code reports
+     domain errors by calling the library function and letting it report
+     the error.  If mathematical functions on your system use 'matherr'
+     when there is an error, then you should leave 'TARGET_EDOM'
+     undefined so that 'matherr' is used normally.
+
+ -- Macro: GEN_ERRNO_RTX
+     Define this macro as a C expression to create an rtl expression
+     that refers to the global "variable" 'errno'.  (On certain systems,
+     'errno' may not actually be a variable.)  If you don't define this
+     macro, a reasonable default is used.
+
+ -- Target Hook: bool TARGET_LIBC_HAS_FUNCTION (enum function_class
+          FN_CLASS)
+     This hook determines whether a function from a class of functions
+     FN_CLASS is present at the runtime.
+
+ -- Macro: NEXT_OBJC_RUNTIME
+     Set this macro to 1 to use the "NeXT" Objective-C message sending
+     conventions by default.  This calling convention involves passing
+     the object, the selector and the method arguments all at once to
+     the method-lookup library function.  This is the usual setting when
+     targeting Darwin/Mac OS X systems, which have the NeXT runtime
+     installed.
+
+     If the macro is set to 0, the "GNU" Objective-C message sending
+     convention will be used by default.  This convention passes just
+     the object and the selector to the method-lookup function, which
+     returns a pointer to the method.
+
+     In either case, it remains possible to select code-generation for
+     the alternate scheme, by means of compiler command line switches.
+
+
+File: gccint.info,  Node: Addressing Modes,  Next: Anchored Addresses,  Prev: Library Calls,  Up: Target Macros
+
+17.14 Addressing Modes
+======================
+
+This is about addressing modes.
+
+ -- Macro: HAVE_PRE_INCREMENT
+ -- Macro: HAVE_PRE_DECREMENT
+ -- Macro: HAVE_POST_INCREMENT
+ -- Macro: HAVE_POST_DECREMENT
+     A C expression that is nonzero if the machine supports
+     pre-increment, pre-decrement, post-increment, or post-decrement
+     addressing respectively.
+
+ -- Macro: HAVE_PRE_MODIFY_DISP
+ -- Macro: HAVE_POST_MODIFY_DISP
+     A C expression that is nonzero if the machine supports pre- or
+     post-address side-effect generation involving constants other than
+     the size of the memory operand.
+
+ -- Macro: HAVE_PRE_MODIFY_REG
+ -- Macro: HAVE_POST_MODIFY_REG
+     A C expression that is nonzero if the machine supports pre- or
+     post-address side-effect generation involving a register
+     displacement.
+
+ -- Macro: CONSTANT_ADDRESS_P (X)
+     A C expression that is 1 if the RTX X is a constant which is a
+     valid address.  On most machines the default definition of
+     '(CONSTANT_P (X) && GET_CODE (X) != CONST_DOUBLE)' is acceptable,
+     but a few machines are more restrictive as to which constant
+     addresses are supported.
+
+ -- Macro: CONSTANT_P (X)
+     'CONSTANT_P', which is defined by target-independent code, accepts
+     integer-values expressions whose values are not explicitly known,
+     such as 'symbol_ref', 'label_ref', and 'high' expressions and
+     'const' arithmetic expressions, in addition to 'const_int' and
+     'const_double' expressions.
+
+ -- Macro: MAX_REGS_PER_ADDRESS
+     A number, the maximum number of registers that can appear in a
+     valid memory address.  Note that it is up to you to specify a value
+     equal to the maximum number that 'TARGET_LEGITIMATE_ADDRESS_P'
+     would ever accept.
+
+ -- Target Hook: bool TARGET_LEGITIMATE_ADDRESS_P (enum machine_mode
+          MODE, rtx X, bool STRICT)
+     A function that returns whether X (an RTX) is a legitimate memory
+     address on the target machine for a memory operand of mode MODE.
+
+     Legitimate addresses are defined in two variants: a strict variant
+     and a non-strict one.  The STRICT parameter chooses which variant
+     is desired by the caller.
+
+     The strict variant is used in the reload pass.  It must be defined
+     so that any pseudo-register that has not been allocated a hard
+     register is considered a memory reference.  This is because in
+     contexts where some kind of register is required, a pseudo-register
+     with no hard register must be rejected.  For non-hard registers,
+     the strict variant should look up the 'reg_renumber' array; it
+     should then proceed using the hard register number in the array, or
+     treat the pseudo as a memory reference if the array holds '-1'.
+
+     The non-strict variant is used in other passes.  It must be defined
+     to accept all pseudo-registers in every context where some kind of
+     register is required.
+
+     Normally, constant addresses which are the sum of a 'symbol_ref'
+     and an integer are stored inside a 'const' RTX to mark them as
+     constant.  Therefore, there is no need to recognize such sums
+     specifically as legitimate addresses.  Normally you would simply
+     recognize any 'const' as legitimate.
+
+     Usually 'PRINT_OPERAND_ADDRESS' is not prepared to handle constant
+     sums that are not marked with 'const'.  It assumes that a naked
+     'plus' indicates indexing.  If so, then you _must_ reject such
+     naked constant sums as illegitimate addresses, so that none of them
+     will be given to 'PRINT_OPERAND_ADDRESS'.
+
+     On some machines, whether a symbolic address is legitimate depends
+     on the section that the address refers to.  On these machines,
+     define the target hook 'TARGET_ENCODE_SECTION_INFO' to store the
+     information into the 'symbol_ref', and then check for it here.
+     When you see a 'const', you will have to look inside it to find the
+     'symbol_ref' in order to determine the section.  *Note Assembler
+     Format::.
+
+     Some ports are still using a deprecated legacy substitute for this
+     hook, the 'GO_IF_LEGITIMATE_ADDRESS' macro.  This macro has this
+     syntax:
+
+          #define GO_IF_LEGITIMATE_ADDRESS (MODE, X, LABEL)
+
+     and should 'goto LABEL' if the address X is a valid address on the
+     target machine for a memory operand of mode MODE.
+
+     Compiler source files that want to use the strict variant of this
+     macro define the macro 'REG_OK_STRICT'.  You should use an '#ifdef
+     REG_OK_STRICT' conditional to define the strict variant in that
+     case and the non-strict variant otherwise.
+
+     Using the hook is usually simpler because it limits the number of
+     files that are recompiled when changes are made.
+
+ -- Macro: TARGET_MEM_CONSTRAINT
+     A single character to be used instead of the default ''m''
+     character for general memory addresses.  This defines the
+     constraint letter which matches the memory addresses accepted by
+     'TARGET_LEGITIMATE_ADDRESS_P'.  Define this macro if you want to
+     support new address formats in your back end without changing the
+     semantics of the ''m'' constraint.  This is necessary in order to
+     preserve functionality of inline assembly constructs using the
+     ''m'' constraint.
+
+ -- Macro: FIND_BASE_TERM (X)
+     A C expression to determine the base term of address X, or to
+     provide a simplified version of X from which 'alias.c' can easily
+     find the base term.  This macro is used in only two places:
+     'find_base_value' and 'find_base_term' in 'alias.c'.
+
+     It is always safe for this macro to not be defined.  It exists so
+     that alias analysis can understand machine-dependent addresses.
+
+     The typical use of this macro is to handle addresses containing a
+     label_ref or symbol_ref within an UNSPEC.
+
+ -- Target Hook: rtx TARGET_LEGITIMIZE_ADDRESS (rtx X, rtx OLDX, enum
+          machine_mode MODE)
+     This hook is given an invalid memory address X for an operand of
+     mode MODE and should try to return a valid memory address.
+
+     X will always be the result of a call to 'break_out_memory_refs',
+     and OLDX will be the operand that was given to that function to
+     produce X.
+
+     The code of the hook should not alter the substructure of X.  If it
+     transforms X into a more legitimate form, it should return the new
+     X.
+
+     It is not necessary for this hook to come up with a legitimate
+     address, with the exception of native TLS addresses (*note Emulated
+     TLS::).  The compiler has standard ways of doing so in all cases.
+     In fact, if the target supports only emulated TLS, it is safe to
+     omit this hook or make it return X if it cannot find a valid way to
+     legitimize the address.  But often a machine-dependent strategy can
+     generate better code.
+
+ -- Macro: LEGITIMIZE_RELOAD_ADDRESS (X, MODE, OPNUM, TYPE, IND_LEVELS,
+          WIN)
+     A C compound statement that attempts to replace X, which is an
+     address that needs reloading, with a valid memory address for an
+     operand of mode MODE.  WIN will be a C statement label elsewhere in
+     the code.  It is not necessary to define this macro, but it might
+     be useful for performance reasons.
+
+     For example, on the i386, it is sometimes possible to use a single
+     reload register instead of two by reloading a sum of two pseudo
+     registers into a register.  On the other hand, for number of RISC
+     processors offsets are limited so that often an intermediate
+     address needs to be generated in order to address a stack slot.  By
+     defining 'LEGITIMIZE_RELOAD_ADDRESS' appropriately, the
+     intermediate addresses generated for adjacent some stack slots can
+     be made identical, and thus be shared.
+
+     _Note_: This macro should be used with caution.  It is necessary to
+     know something of how reload works in order to effectively use
+     this, and it is quite easy to produce macros that build in too much
+     knowledge of reload internals.
+
+     _Note_: This macro must be able to reload an address created by a
+     previous invocation of this macro.  If it fails to handle such
+     addresses then the compiler may generate incorrect code or abort.
+
+     The macro definition should use 'push_reload' to indicate parts
+     that need reloading; OPNUM, TYPE and IND_LEVELS are usually
+     suitable to be passed unaltered to 'push_reload'.
+
+     The code generated by this macro must not alter the substructure of
+     X.  If it transforms X into a more legitimate form, it should
+     assign X (which will always be a C variable) a new value.  This
+     also applies to parts that you change indirectly by calling
+     'push_reload'.
+
+     The macro definition may use 'strict_memory_address_p' to test if
+     the address has become legitimate.
+
+     If you want to change only a part of X, one standard way of doing
+     this is to use 'copy_rtx'.  Note, however, that it unshares only a
+     single level of rtl.  Thus, if the part to be changed is not at the
+     top level, you'll need to replace first the top level.  It is not
+     necessary for this macro to come up with a legitimate address; but
+     often a machine-dependent strategy can generate better code.
+
+ -- Target Hook: bool TARGET_MODE_DEPENDENT_ADDRESS_P (const_rtx ADDR,
+          addr_space_t ADDRSPACE)
+     This hook returns 'true' if memory address ADDR in address space
+     ADDRSPACE can have different meanings depending on the machine mode
+     of the memory reference it is used for or if the address is valid
+     for some modes but not others.
+
+     Autoincrement and autodecrement addresses typically have
+     mode-dependent effects because the amount of the increment or
+     decrement is the size of the operand being addressed.  Some
+     machines have other mode-dependent addresses.  Many RISC machines
+     have no mode-dependent addresses.
+
+     You may assume that ADDR is a valid address for the machine.
+
+     The default version of this hook returns 'false'.
+
+ -- Target Hook: bool TARGET_LEGITIMATE_CONSTANT_P (enum machine_mode
+          MODE, rtx X)
+     This hook returns true if X is a legitimate constant for a
+     MODE-mode immediate operand on the target machine.  You can assume
+     that X satisfies 'CONSTANT_P', so you need not check this.
+
+     The default definition returns true.
+
+ -- Target Hook: rtx TARGET_DELEGITIMIZE_ADDRESS (rtx X)
+     This hook is used to undo the possibly obfuscating effects of the
+     'LEGITIMIZE_ADDRESS' and 'LEGITIMIZE_RELOAD_ADDRESS' target macros.
+     Some backend implementations of these macros wrap symbol references
+     inside an 'UNSPEC' rtx to represent PIC or similar addressing
+     modes.  This target hook allows GCC's optimizers to understand the
+     semantics of these opaque 'UNSPEC's by converting them back into
+     their original form.
+
+ -- Target Hook: bool TARGET_CONST_NOT_OK_FOR_DEBUG_P (rtx X)
+     This hook should return true if X should not be emitted into debug
+     sections.
+
+ -- Target Hook: bool TARGET_CANNOT_FORCE_CONST_MEM (enum machine_mode
+          MODE, rtx X)
+     This hook should return true if X is of a form that cannot (or
+     should not) be spilled to the constant pool.  MODE is the mode of
+     X.
+
+     The default version of this hook returns false.
+
+     The primary reason to define this hook is to prevent reload from
+     deciding that a non-legitimate constant would be better reloaded
+     from the constant pool instead of spilling and reloading a register
+     holding the constant.  This restriction is often true of addresses
+     of TLS symbols for various targets.
+
+ -- Target Hook: bool TARGET_USE_BLOCKS_FOR_CONSTANT_P (enum
+          machine_mode MODE, const_rtx X)
+     This hook should return true if pool entries for constant X can be
+     placed in an 'object_block' structure.  MODE is the mode of X.
+
+     The default version returns false for all constants.
+
+ -- Target Hook: bool TARGET_USE_BLOCKS_FOR_DECL_P (const_tree DECL)
+     This hook should return true if pool entries for DECL should be
+     placed in an 'object_block' structure.
+
+     The default version returns true for all decls.
+
+ -- Target Hook: tree TARGET_BUILTIN_RECIPROCAL (unsigned FN, bool
+          MD_FN, bool SQRT)
+     This hook should return the DECL of a function that implements
+     reciprocal of the builtin function with builtin function code FN,
+     or 'NULL_TREE' if such a function is not available.  MD_FN is true
+     when FN is a code of a machine-dependent builtin function.  When
+     SQRT is true, additional optimizations that apply only to the
+     reciprocal of a square root function are performed, and only
+     reciprocals of 'sqrt' function are valid.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD (void)
+     This hook should return the DECL of a function F that given an
+     address ADDR as an argument returns a mask M that can be used to
+     extract from two vectors the relevant data that resides in ADDR in
+     case ADDR is not properly aligned.
+
+     The autovectorizer, when vectorizing a load operation from an
+     address ADDR that may be unaligned, will generate two vector loads
+     from the two aligned addresses around ADDR.  It then generates a
+     'REALIGN_LOAD' operation to extract the relevant data from the two
+     loaded vectors.  The first two arguments to 'REALIGN_LOAD', V1 and
+     V2, are the two vectors, each of size VS, and the third argument,
+     OFF, defines how the data will be extracted from these two vectors:
+     if OFF is 0, then the returned vector is V2; otherwise, the
+     returned vector is composed from the last VS-OFF elements of V1
+     concatenated to the first OFF elements of V2.
+
+     If this hook is defined, the autovectorizer will generate a call to
+     F (using the DECL tree that this hook returns) and will use the
+     return value of F as the argument OFF to 'REALIGN_LOAD'.
+     Therefore, the mask M returned by F should comply with the
+     semantics expected by 'REALIGN_LOAD' described above.  If this hook
+     is not defined, then ADDR will be used as the argument OFF to
+     'REALIGN_LOAD', in which case the low log2(VS) - 1 bits of ADDR
+     will be considered.
+
+ -- Target Hook: int TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST (enum
+          vect_cost_for_stmt TYPE_OF_COST, tree VECTYPE, int MISALIGN)
+     Returns cost of different scalar or vector statements for
+     vectorization cost model.  For vector memory operations the cost
+     may depend on type (VECTYPE) and misalignment value (MISALIGN).
+
+ -- Target Hook: bool TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE
+          (const_tree TYPE, bool IS_PACKED)
+     Return true if vector alignment is reachable (by peeling N
+     iterations) for the given type.
+
+ -- Target Hook: bool TARGET_VECTORIZE_VEC_PERM_CONST_OK (enum
+          MACHINE_MODE, const unsigned char *SEL)
+     Return true if a vector created for 'vec_perm_const' is valid.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_CONVERSION (unsigned
+          CODE, tree DEST_TYPE, tree SRC_TYPE)
+     This hook should return the DECL of a function that implements
+     conversion of the input vector of type SRC_TYPE to type DEST_TYPE.
+     The value of CODE is one of the enumerators in 'enum tree_code' and
+     specifies how the conversion is to be applied (truncation,
+     rounding, etc.).
+
+     If this hook is defined, the autovectorizer will use the
+     'TARGET_VECTORIZE_BUILTIN_CONVERSION' target hook when vectorizing
+     conversion.  Otherwise, it will return 'NULL_TREE'.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION (tree
+          FNDECL, tree VEC_TYPE_OUT, tree VEC_TYPE_IN)
+     This hook should return the decl of a function that implements the
+     vectorized variant of the builtin function with builtin function
+     code CODE or 'NULL_TREE' if such a function is not available.  The
+     value of FNDECL is the builtin function declaration.  The return
+     type of the vectorized function shall be of vector type
+     VEC_TYPE_OUT and the argument types should be VEC_TYPE_IN.
+
+ -- Target Hook: bool TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT (enum
+          machine_mode MODE, const_tree TYPE, int MISALIGNMENT, bool
+          IS_PACKED)
+     This hook should return true if the target supports misaligned
+     vector store/load of a specific factor denoted in the MISALIGNMENT
+     parameter.  The vector store/load should be of machine mode MODE
+     and the elements in the vectors should be of type TYPE.  IS_PACKED
+     parameter is true if the memory access is defined in a packed
+     struct.
+
+ -- Target Hook: enum machine_mode TARGET_VECTORIZE_PREFERRED_SIMD_MODE
+          (enum machine_mode MODE)
+     This hook should return the preferred mode for vectorizing scalar
+     mode MODE.  The default is equal to 'word_mode', because the
+     vectorizer can do some transformations even in absence of
+     specialized SIMD hardware.
+
+ -- Target Hook: unsigned int
+          TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES (void)
+     This hook should return a mask of sizes that should be iterated
+     over after trying to autovectorize using the vector size derived
+     from the mode returned by 'TARGET_VECTORIZE_PREFERRED_SIMD_MODE'.
+     The default is zero which means to not iterate over other vector
+     sizes.
+
+ -- Target Hook: void * TARGET_VECTORIZE_INIT_COST (struct loop
+          *LOOP_INFO)
+     This hook should initialize target-specific data structures in
+     preparation for modeling the costs of vectorizing a loop or basic
+     block.  The default allocates three unsigned integers for
+     accumulating costs for the prologue, body, and epilogue of the loop
+     or basic block.  If LOOP_INFO is non-NULL, it identifies the loop
+     being vectorized; otherwise a single block is being vectorized.
+
+ -- Target Hook: unsigned TARGET_VECTORIZE_ADD_STMT_COST (void *DATA,
+          int COUNT, enum vect_cost_for_stmt KIND, struct _stmt_vec_info
+          *STMT_INFO, int MISALIGN, enum vect_cost_model_location WHERE)
+     This hook should update the target-specific DATA in response to
+     adding COUNT copies of the given KIND of statement to a loop or
+     basic block.  The default adds the builtin vectorizer cost for the
+     copies of the statement to the accumulator specified by WHERE, (the
+     prologue, body, or epilogue) and returns the amount added.  The
+     return value should be viewed as a tentative cost that may later be
+     revised.
+
+ -- Target Hook: void TARGET_VECTORIZE_FINISH_COST (void *DATA, unsigned
+          *PROLOGUE_COST, unsigned *BODY_COST, unsigned *EPILOGUE_COST)
+     This hook should complete calculations of the cost of vectorizing a
+     loop or basic block based on DATA, and return the prologue, body,
+     and epilogue costs as unsigned integers.  The default returns the
+     value of the three accumulators.
+
+ -- Target Hook: void TARGET_VECTORIZE_DESTROY_COST_DATA (void *DATA)
+     This hook should release DATA and any related data structures
+     allocated by TARGET_VECTORIZE_INIT_COST. The default releases the
+     accumulator.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_LOAD (tree)
+     This hook should return the built-in decl needed to load a vector
+     of the given type within a transaction.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_TM_STORE (tree)
+     This hook should return the built-in decl needed to store a vector
+     of the given type within a transaction.
+
+ -- Target Hook: tree TARGET_VECTORIZE_BUILTIN_GATHER (const_tree
+          MEM_VECTYPE, const_tree INDEX_TYPE, int SCALE)
+     Target builtin that implements vector gather operation.
+     MEM_VECTYPE is the vector type of the load and INDEX_TYPE is scalar
+     type of the index, scaled by SCALE.  The default is 'NULL_TREE'
+     which means to not vectorize gather loads.
+
+ -- Target Hook: int TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN
+          (struct cgraph_node *, struct cgraph_simd_clone *, TREE, INT)
+     This hook should set VECSIZE_MANGLE, VECSIZE_INT, VECSIZE_FLOAT
+     fields in SIMD_CLONE structure pointed by CLONE_INFO argument and
+     also SIMDLEN field if it was previously 0.  The hook should return
+     0 if SIMD clones shouldn't be emitted, or number of VECSIZE_MANGLE
+     variants that should be emitted.
+
+ -- Target Hook: void TARGET_SIMD_CLONE_ADJUST (struct cgraph_node *)
+     This hook should add implicit 'attribute(target("..."))' attribute
+     to SIMD clone NODE if needed.
+
+ -- Target Hook: int TARGET_SIMD_CLONE_USABLE (struct cgraph_node *)
+     This hook should return -1 if SIMD clone NODE shouldn't be used in
+     vectorized loops in current function, or non-negative number if it
+     is usable.  In that case, the smaller the number is, the more
+     desirable it is to use it.
+
+
+File: gccint.info,  Node: Anchored Addresses,  Next: Condition Code,  Prev: Addressing Modes,  Up: Target Macros
+
+17.15 Anchored Addresses
+========================
+
+GCC usually addresses every static object as a separate entity.  For
+example, if we have:
+
+     static int a, b, c;
+     int foo (void) { return a + b + c; }
+
+ the code for 'foo' will usually calculate three separate symbolic
+addresses: those of 'a', 'b' and 'c'.  On some targets, it would be
+better to calculate just one symbolic address and access the three
+variables relative to it.  The equivalent pseudocode would be something
+like:
+
+     int foo (void)
+     {
+       register int *xr = &x;
+       return xr[&a - &x] + xr[&b - &x] + xr[&c - &x];
+     }
+
+ (which isn't valid C). We refer to shared addresses like 'x' as
+"section anchors".  Their use is controlled by '-fsection-anchors'.
+
+ The hooks below describe the target properties that GCC needs to know
+in order to make effective use of section anchors.  It won't use section
+anchors at all unless either 'TARGET_MIN_ANCHOR_OFFSET' or
+'TARGET_MAX_ANCHOR_OFFSET' is set to a nonzero value.
+
+ -- Target Hook: HOST_WIDE_INT TARGET_MIN_ANCHOR_OFFSET
+     The minimum offset that should be applied to a section anchor.  On
+     most targets, it should be the smallest offset that can be applied
+     to a base register while still giving a legitimate address for
+     every mode.  The default value is 0.
+
+ -- Target Hook: HOST_WIDE_INT TARGET_MAX_ANCHOR_OFFSET
+     Like 'TARGET_MIN_ANCHOR_OFFSET', but the maximum (inclusive) offset
+     that should be applied to section anchors.  The default value is 0.
+
+ -- Target Hook: void TARGET_ASM_OUTPUT_ANCHOR (rtx X)
+     Write the assembly code to define section anchor X, which is a
+     'SYMBOL_REF' for which 'SYMBOL_REF_ANCHOR_P (X)' is true.  The hook
+     is called with the assembly output position set to the beginning of
+     'SYMBOL_REF_BLOCK (X)'.
+
+     If 'ASM_OUTPUT_DEF' is available, the hook's default definition
+     uses it to define the symbol as '. + SYMBOL_REF_BLOCK_OFFSET (X)'.
+     If 'ASM_OUTPUT_DEF' is not available, the hook's default definition
+     is 'NULL', which disables the use of section anchors altogether.
+
+ -- Target Hook: bool TARGET_USE_ANCHORS_FOR_SYMBOL_P (const_rtx X)
+     Return true if GCC should attempt to use anchors to access
+     'SYMBOL_REF' X.  You can assume 'SYMBOL_REF_HAS_BLOCK_INFO_P (X)'
+     and '!SYMBOL_REF_ANCHOR_P (X)'.
+
+     The default version is correct for most targets, but you might need
+     to intercept this hook to handle things like target-specific
+     attributes or target-specific sections.
+
+
+File: gccint.info,  Node: Condition Code,  Next: Costs,  Prev: Anchored Addresses,  Up: Target Macros
+
+17.16 Condition Code Status
+===========================
+
+The macros in this section can be split in two families, according to
+the two ways of representing condition codes in GCC.
+
+ The first representation is the so called '(cc0)' representation (*note
+Jump Patterns::), where all instructions can have an implicit clobber of
+the condition codes.  The second is the condition code register
+representation, which provides better schedulability for architectures
+that do have a condition code register, but on which most instructions
+do not affect it.  The latter category includes most RISC machines.
+
+ The implicit clobbering poses a strong restriction on the placement of
+the definition and use of the condition code.  In the past the
+definition and use were always adjacent.  However, recent changes to
+support trapping arithmatic may result in the definition and user being
+in different blocks.  Thus, there may be a 'NOTE_INSN_BASIC_BLOCK'
+between them.  Additionally, the definition may be the source of
+exception handling edges.
+
+ These restrictions can prevent important optimizations on some
+machines.  For example, on the IBM RS/6000, there is a delay for taken
+branches unless the condition code register is set three instructions
+earlier than the conditional branch.  The instruction scheduler cannot
+perform this optimization if it is not permitted to separate the
+definition and use of the condition code register.
+
+ For this reason, it is possible and suggested to use a register to
+represent the condition code for new ports.  If there is a specific
+condition code register in the machine, use a hard register.  If the
+condition code or comparison result can be placed in any general
+register, or if there are multiple condition registers, use a pseudo
+register.  Registers used to store the condition code value will usually
+have a mode that is in class 'MODE_CC'.
+
+ Alternatively, you can use 'BImode' if the comparison operator is
+specified already in the compare instruction.  In this case, you are not
+interested in most macros in this section.
+
+* Menu:
+
+* CC0 Condition Codes::      Old style representation of condition codes.
+* MODE_CC Condition Codes::  Modern representation of condition codes.
+
+
+File: gccint.info,  Node: CC0 Condition Codes,  Next: MODE_CC Condition Codes,  Up: Condition Code
+
+17.16.1 Representation of condition codes using '(cc0)'
+-------------------------------------------------------
+
+The file 'conditions.h' defines a variable 'cc_status' to describe how
+the condition code was computed (in case the interpretation of the
+condition code depends on the instruction that it was set by).  This
+variable contains the RTL expressions on which the condition code is
+currently based, and several standard flags.
+
+ Sometimes additional machine-specific flags must be defined in the
+machine description header file.  It can also add additional
+machine-specific information by defining 'CC_STATUS_MDEP'.
+
+ -- Macro: CC_STATUS_MDEP
+     C code for a data type which is used for declaring the 'mdep'
+     component of 'cc_status'.  It defaults to 'int'.
+
+     This macro is not used on machines that do not use 'cc0'.
+
+ -- Macro: CC_STATUS_MDEP_INIT
+     A C expression to initialize the 'mdep' field to "empty".  The
+     default definition does nothing, since most machines don't use the
+     field anyway.  If you want to use the field, you should probably
+     define this macro to initialize it.
+
+     This macro is not used on machines that do not use 'cc0'.
+
+ -- Macro: NOTICE_UPDATE_CC (EXP, INSN)
+     A C compound statement to set the components of 'cc_status'
+     appropriately for an insn INSN whose body is EXP.  It is this
+     macro's responsibility to recognize insns that set the condition
+     code as a byproduct of other activity as well as those that
+     explicitly set '(cc0)'.
+
+     This macro is not used on machines that do not use 'cc0'.
+
+     If there are insns that do not set the condition code but do alter
+     other machine registers, this macro must check to see whether they
+     invalidate the expressions that the condition code is recorded as
+     reflecting.  For example, on the 68000, insns that store in address
+     registers do not set the condition code, which means that usually
+     'NOTICE_UPDATE_CC' can leave 'cc_status' unaltered for such insns.
+     But suppose that the previous insn set the condition code based on
+     location 'a4@(102)' and the current insn stores a new value in
+     'a4'.  Although the condition code is not changed by this, it will
+     no longer be true that it reflects the contents of 'a4@(102)'.
+     Therefore, 'NOTICE_UPDATE_CC' must alter 'cc_status' in this case
+     to say that nothing is known about the condition code value.
+
+     The definition of 'NOTICE_UPDATE_CC' must be prepared to deal with
+     the results of peephole optimization: insns whose patterns are
+     'parallel' RTXs containing various 'reg', 'mem' or constants which
+     are just the operands.  The RTL structure of these insns is not
+     sufficient to indicate what the insns actually do.  What
+     'NOTICE_UPDATE_CC' should do when it sees one is just to run
+     'CC_STATUS_INIT'.
+
+     A possible definition of 'NOTICE_UPDATE_CC' is to call a function
+     that looks at an attribute (*note Insn Attributes::) named, for
+     example, 'cc'.  This avoids having detailed information about
+     patterns in two places, the 'md' file and in 'NOTICE_UPDATE_CC'.
+
+
+File: gccint.info,  Node: MODE_CC Condition Codes,  Prev: CC0 Condition Codes,  Up: Condition Code
+
+17.16.2 Representation of condition codes using registers
+---------------------------------------------------------
+
+ -- Macro: SELECT_CC_MODE (OP, X, Y)
+     On many machines, the condition code may be produced by other
+     instructions than compares, for example the branch can use directly
+     the condition code set by a subtract instruction.  However, on some
+     machines when the condition code is set this way some bits (such as
+     the overflow bit) are not set in the same way as a test
+     instruction, so that a different branch instruction must be used
+     for some conditional branches.  When this happens, use the machine
+     mode of the condition code register to record different formats of
+     the condition code register.  Modes can also be used to record
+     which compare instruction (e.g.  a signed or an unsigned
+     comparison) produced the condition codes.
+
+     If other modes than 'CCmode' are required, add them to
+     'MACHINE-modes.def' and define 'SELECT_CC_MODE' to choose a mode
+     given an operand of a compare.  This is needed because the modes
+     have to be chosen not only during RTL generation but also, for
+     example, by instruction combination.  The result of
+     'SELECT_CC_MODE' should be consistent with the mode used in the
+     patterns; for example to support the case of the add on the SPARC
+     discussed above, we have the pattern
+
+          (define_insn ""
+            [(set (reg:CC_NOOV 0)
+                  (compare:CC_NOOV
+                    (plus:SI (match_operand:SI 0 "register_operand" "%r")
+                             (match_operand:SI 1 "arith_operand" "rI"))
+                    (const_int 0)))]
+            ""
+            "...")
+
+     together with a 'SELECT_CC_MODE' that returns 'CC_NOOVmode' for
+     comparisons whose argument is a 'plus':
+
+          #define SELECT_CC_MODE(OP,X,Y) \
+            (GET_MODE_CLASS (GET_MODE (X)) == MODE_FLOAT          \
+             ? ((OP == EQ || OP == NE) ? CCFPmode : CCFPEmode)    \
+             : ((GET_CODE (X) == PLUS || GET_CODE (X) == MINUS    \
+                 || GET_CODE (X) == NEG) \
+                ? CC_NOOVmode : CCmode))
+
+     Another reason to use modes is to retain information on which
+     operands were used by the comparison; see 'REVERSIBLE_CC_MODE'
+     later in this section.
+
+     You should define this macro if and only if you define extra CC
+     modes in 'MACHINE-modes.def'.
+
+ -- Target Hook: void TARGET_CANONICALIZE_COMPARISON (int *CODE, rtx
+          *OP0, rtx *OP1, bool OP0_PRESERVE_VALUE)
+     On some machines not all possible comparisons are defined, but you
+     can convert an invalid comparison into a valid one.  For example,
+     the Alpha does not have a 'GT' comparison, but you can use an 'LT'
+     comparison instead and swap the order of the operands.
+
+     On such machines, implement this hook to do any required
+     conversions.  CODE is the initial comparison code and OP0 and OP1
+     are the left and right operands of the comparison, respectively.
+     If OP0_PRESERVE_VALUE is 'true' the implementation is not allowed
+     to change the value of OP0 since the value might be used in RTXs
+     which aren't comparisons.  E.g.  the implementation is not allowed
+     to swap operands in that case.
+
+     GCC will not assume that the comparison resulting from this macro
+     is valid but will see if the resulting insn matches a pattern in
+     the 'md' file.
+
+     You need not to implement this hook if it would never change the
+     comparison code or operands.
+
+ -- Macro: REVERSIBLE_CC_MODE (MODE)
+     A C expression whose value is one if it is always safe to reverse a
+     comparison whose mode is MODE.  If 'SELECT_CC_MODE' can ever return
+     MODE for a floating-point inequality comparison, then
+     'REVERSIBLE_CC_MODE (MODE)' must be zero.
+
+     You need not define this macro if it would always returns zero or
+     if the floating-point format is anything other than
+     'IEEE_FLOAT_FORMAT'.  For example, here is the definition used on
+     the SPARC, where floating-point inequality comparisons are always
+     given 'CCFPEmode':
+
+          #define REVERSIBLE_CC_MODE(MODE)  ((MODE) != CCFPEmode)
+
+ -- Macro: REVERSE_CONDITION (CODE, MODE)
+     A C expression whose value is reversed condition code of the CODE
+     for comparison done in CC_MODE MODE.  The macro is used only in
+     case 'REVERSIBLE_CC_MODE (MODE)' is nonzero.  Define this macro in
+     case machine has some non-standard way how to reverse certain
+     conditionals.  For instance in case all floating point conditions
+     are non-trapping, compiler may freely convert unordered compares to
+     ordered one.  Then definition may look like:
+
+          #define REVERSE_CONDITION(CODE, MODE) \
+             ((MODE) != CCFPmode ? reverse_condition (CODE) \
+              : reverse_condition_maybe_unordered (CODE))
+
+ -- Target Hook: bool TARGET_FIXED_CONDITION_CODE_REGS (unsigned int
+          *P1, unsigned int *P2)
+     On targets which do not use '(cc0)', and which use a hard register
+     rather than a pseudo-register to hold condition codes, the regular
+     CSE passes are often not able to identify cases in which the hard
+     register is set to a common value.  Use this hook to enable a small
+     pass which optimizes such cases.  This hook should return true to
+     enable this pass, and it should set the integers to which its
+     arguments point to the hard register numbers used for condition
+     codes.  When there is only one such register, as is true on most
+     systems, the integer pointed to by P2 should be set to
+     'INVALID_REGNUM'.
+
+     The default version of this hook returns false.
+
+ -- Target Hook: enum machine_mode TARGET_CC_MODES_COMPATIBLE (enum
+          machine_mode M1, enum machine_mode M2)
+     On targets which use multiple condition code modes in class
+     'MODE_CC', it is sometimes the case that a comparison can be
+     validly done in more than one mode.  On such a system, define this
+     target hook to take two mode arguments and to return a mode in
+     which both comparisons may be validly done.  If there is no such
+     mode, return 'VOIDmode'.
+
+     The default version of this hook checks whether the modes are the
+     same.  If they are, it returns that mode.  If they are different,
+     it returns 'VOIDmode'.
+
+
+File: gccint.info,  Node: Costs,  Next: Scheduling,  Prev: Condition Code,  Up: Target Macros
+
+17.17 Describing Relative Costs of Operations
+=============================================
+
+These macros let you describe the relative speed of various operations
+on the target machine.
+
+ -- Macro: REGISTER_MOVE_COST (MODE, FROM, TO)
+     A C expression for the cost of moving data of mode MODE from a
+     register in class FROM to one in class TO.  The classes are
+     expressed using the enumeration values such as 'GENERAL_REGS'.  A
+     value of 2 is the default; other values are interpreted relative to
+     that.
+
+     It is not required that the cost always equal 2 when FROM is the
+     same as TO; on some machines it is expensive to move between
+     registers if they are not general registers.
+
+     If reload sees an insn consisting of a single 'set' between two
+     hard registers, and if 'REGISTER_MOVE_COST' applied to their
+     classes returns a value of 2, reload does not check to ensure that
+     the constraints of the insn are met.  Setting a cost of other than
+     2 will allow reload to verify that the constraints are met.  You
+     should do this if the 'movM' pattern's constraints do not allow
+     such copying.
+
+     These macros are obsolete, new ports should use the target hook
+     'TARGET_REGISTER_MOVE_COST' instead.
+
+ -- Target Hook: int TARGET_REGISTER_MOVE_COST (enum machine_mode MODE,
+          reg_class_t FROM, reg_class_t TO)
+     This target hook should return the cost of moving data of mode MODE
+     from a register in class FROM to one in class TO.  The classes are
+     expressed using the enumeration values such as 'GENERAL_REGS'.  A
+     value of 2 is the default; other values are interpreted relative to
+     that.
+
+     It is not required that the cost always equal 2 when FROM is the
+     same as TO; on some machines it is expensive to move between
+     registers if they are not general registers.
+
+     If reload sees an insn consisting of a single 'set' between two
+     hard registers, and if 'TARGET_REGISTER_MOVE_COST' applied to their
+     classes returns a value of 2, reload does not check to ensure that
+     the constraints of the insn are met.  Setting a cost of other than
+     2 will allow reload to verify that the constraints are met.  You
+     should do this if the 'movM' pattern's constraints do not allow
+     such copying.
+
+     The default version of this function returns 2.
+
+ -- Macro: MEMORY_MOVE_COST (MODE, CLASS, IN)
+     A C expression for the cost of moving data of mode MODE between a
+     register of class CLASS and memory; IN is zero if the value is to
+     be written to memory, nonzero if it is to be read in.  This cost is
+     relative to those in 'REGISTER_MOVE_COST'.  If moving between
+     registers and memory is more expensive than between two registers,
+     you should define this macro to express the relative cost.
+
+     If you do not define this macro, GCC uses a default cost of 4 plus
+     the cost of copying via a secondary reload register, if one is
+     needed.  If your machine requires a secondary reload register to
+     copy between memory and a register of CLASS but the reload
+     mechanism is more complex than copying via an intermediate, define
+     this macro to reflect the actual cost of the move.
+
+     GCC defines the function 'memory_move_secondary_cost' if secondary
+     reloads are needed.  It computes the costs due to copying via a
+     secondary register.  If your machine copies from memory using a
+     secondary register in the conventional way but the default base
+     value of 4 is not correct for your machine, define this macro to
+     add some other value to the result of that function.  The arguments
+     to that function are the same as to this macro.
+
+     These macros are obsolete, new ports should use the target hook
+     'TARGET_MEMORY_MOVE_COST' instead.
+
+ -- Target Hook: int TARGET_MEMORY_MOVE_COST (enum machine_mode MODE,
+          reg_class_t RCLASS, bool IN)
+     This target hook should return the cost of moving data of mode MODE
+     between a register of class RCLASS and memory; IN is 'false' if the
+     value is to be written to memory, 'true' if it is to be read in.
+     This cost is relative to those in 'TARGET_REGISTER_MOVE_COST'.  If
+     moving between registers and memory is more expensive than between
+     two registers, you should add this target hook to express the
+     relative cost.
+
+     If you do not add this target hook, GCC uses a default cost of 4
+     plus the cost of copying via a secondary reload register, if one is
+     needed.  If your machine requires a secondary reload register to
+     copy between memory and a register of RCLASS but the reload
+     mechanism is more complex than copying via an intermediate, use
+     this target hook to reflect the actual cost of the move.
+
+     GCC defines the function 'memory_move_secondary_cost' if secondary
+     reloads are needed.  It computes the costs due to copying via a
+     secondary register.  If your machine copies from memory using a
+     secondary register in the conventional way but the default base
+     value of 4 is not correct for your machine, use this target hook to
+     add some other value to the result of that function.  The arguments
+     to that function are the same as to this target hook.
+
+ -- Macro: BRANCH_COST (SPEED_P, PREDICTABLE_P)
+     A C expression for the cost of a branch instruction.  A value of 1
+     is the default; other values are interpreted relative to that.
+     Parameter SPEED_P is true when the branch in question should be
+     optimized for speed.  When it is false, 'BRANCH_COST' should return
+     a value optimal for code size rather than performance.
+     PREDICTABLE_P is true for well-predicted branches.  On many
+     architectures the 'BRANCH_COST' can be reduced then.
+
+ Here are additional macros which do not specify precise relative costs,
+but only that certain actions are more expensive than GCC would
+ordinarily expect.
+
+ -- Macro: SLOW_BYTE_ACCESS
+     Define this macro as a C expression which is nonzero if accessing
+     less than a word of memory (i.e. a 'char' or a 'short') is no
+     faster than accessing a word of memory, i.e., if such access
+     require more than one instruction or if there is no difference in
+     cost between byte and (aligned) word loads.
+
+     When this macro is not defined, the compiler will access a field by
+     finding the smallest containing object; when it is defined, a
+     fullword load will be used if alignment permits.  Unless bytes
+     accesses are faster than word accesses, using word accesses is
+     preferable since it may eliminate subsequent memory access if
+     subsequent accesses occur to other fields in the same word of the
+     structure, but to different bytes.
+
+ -- Macro: SLOW_UNALIGNED_ACCESS (MODE, ALIGNMENT)
+     Define this macro to be the value 1 if memory accesses described by
+     the MODE and ALIGNMENT parameters have a cost many times greater
+     than aligned accesses, for example if they are emulated in a trap
+     handler.
+
+     When this macro is nonzero, the compiler will act as if
+     'STRICT_ALIGNMENT' were nonzero when generating code for block
+     moves.  This can cause significantly more instructions to be
+     produced.  Therefore, do not set this macro nonzero if unaligned
+     accesses only add a cycle or two to the time for a memory access.
+
+     If the value of this macro is always zero, it need not be defined.
+     If this macro is defined, it should produce a nonzero value when
+     'STRICT_ALIGNMENT' is nonzero.
+
+ -- Macro: MOVE_RATIO (SPEED)
+     The threshold of number of scalar memory-to-memory move insns,
+     _below_ which a sequence of insns should be generated instead of a
+     string move insn or a library call.  Increasing the value will
+     always make code faster, but eventually incurs high cost in
+     increased code size.
+
+     Note that on machines where the corresponding move insn is a
+     'define_expand' that emits a sequence of insns, this macro counts
+     the number of such sequences.
+
+     The parameter SPEED is true if the code is currently being
+     optimized for speed rather than size.
+
+     If you don't define this, a reasonable default is used.
+
+ -- Macro: MOVE_BY_PIECES_P (SIZE, ALIGNMENT)
+     A C expression used to determine whether 'move_by_pieces' will be
+     used to copy a chunk of memory, or whether some other block move
+     mechanism will be used.  Defaults to 1 if 'move_by_pieces_ninsns'
+     returns less than 'MOVE_RATIO'.
+
+ -- Macro: MOVE_MAX_PIECES
+     A C expression used by 'move_by_pieces' to determine the largest
+     unit a load or store used to copy memory is.  Defaults to
+     'MOVE_MAX'.
+
+ -- Macro: CLEAR_RATIO (SPEED)
+     The threshold of number of scalar move insns, _below_ which a
+     sequence of insns should be generated to clear memory instead of a
+     string clear insn or a library call.  Increasing the value will
+     always make code faster, but eventually incurs high cost in
+     increased code size.
+
+     The parameter SPEED is true if the code is currently being
+     optimized for speed rather than size.
+
+     If you don't define this, a reasonable default is used.
+
+ -- Macro: CLEAR_BY_PIECES_P (SIZE, ALIGNMENT)
+     A C expression used to determine whether 'clear_by_pieces' will be
+     used to clear a chunk of memory, or whether some other block clear
+     mechanism will be used.  Defaults to 1 if 'move_by_pieces_ninsns'
+     returns less than 'CLEAR_RATIO'.
+
+ -- Macro: SET_RATIO (SPEED)
+     The threshold of number of scalar move insns, _below_ which a
+     sequence of insns should be generated to set memory to a constant
+     value, instead of a block set insn or a library call.  Increasing
+     the value will always make code faster, but eventually incurs high
+     cost in increased code size.
+
+     The parameter SPEED is true if the code is currently being
+     optimized for speed rather than size.
+
+     If you don't define this, it defaults to the value of 'MOVE_RATIO'.
+
+ -- Macro: SET_BY_PIECES_P (SIZE, ALIGNMENT)
+     A C expression used to determine whether 'store_by_pieces' will be
+     used to set a chunk of memory to a constant value, or whether some
+     other mechanism will be used.  Used by '__builtin_memset' when
+     storing values other than constant zero.  Defaults to 1 if
+     'move_by_pieces_ninsns' returns less than 'SET_RATIO'.
+
+ -- Macro: STORE_BY_PIECES_P (SIZE, ALIGNMENT)
+     A C expression used to determine whether 'store_by_pieces' will be
+     used to set a chunk of memory to a constant string value, or
+     whether some other mechanism will be used.  Used by
+     '__builtin_strcpy' when called with a constant source string.
+     Defaults to 1 if 'move_by_pieces_ninsns' returns less than
+     'MOVE_RATIO'.
+
+ -- Macro: USE_LOAD_POST_INCREMENT (MODE)
+     A C expression used to determine whether a load postincrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     'HAVE_POST_INCREMENT'.
+
+ -- Macro: USE_LOAD_POST_DECREMENT (MODE)
+     A C expression used to determine whether a load postdecrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     'HAVE_POST_DECREMENT'.
+
+ -- Macro: USE_LOAD_PRE_INCREMENT (MODE)
+     A C expression used to determine whether a load preincrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     'HAVE_PRE_INCREMENT'.
+
+ -- Macro: USE_LOAD_PRE_DECREMENT (MODE)
+     A C expression used to determine whether a load predecrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     'HAVE_PRE_DECREMENT'.
+
+ -- Macro: USE_STORE_POST_INCREMENT (MODE)
+     A C expression used to determine whether a store postincrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     'HAVE_POST_INCREMENT'.
+
+ -- Macro: USE_STORE_POST_DECREMENT (MODE)
+     A C expression used to determine whether a store postdecrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     'HAVE_POST_DECREMENT'.
+
+ -- Macro: USE_STORE_PRE_INCREMENT (MODE)
+     This macro is used to determine whether a store preincrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     'HAVE_PRE_INCREMENT'.
+
+ -- Macro: USE_STORE_PRE_DECREMENT (MODE)
+     This macro is used to determine whether a store predecrement is a
+     good thing to use for a given mode.  Defaults to the value of
+     'HAVE_PRE_DECREMENT'.
+
+ -- Macro: NO_FUNCTION_CSE
+     Define this macro if it is as good or better to call a constant
+     function address than to call an address kept in a register.
+
+ -- Macro: LOGICAL_OP_NON_SHORT_CIRCUIT
+     Define this macro if a non-short-circuit operation produced by
+     'fold_range_test ()' is optimal.  This macro defaults to true if
+     'BRANCH_COST' is greater than or equal to the value 2.
+
+ -- Target Hook: bool TARGET_RTX_COSTS (rtx X, int CODE, int OUTER_CODE,
+          int OPNO, int *TOTAL, bool SPEED)
+     This target hook describes the relative costs of RTL expressions.
+
+     The cost may depend on the precise form of the expression, which is
+     available for examination in X, and the fact that X appears as
+     operand OPNO of an expression with rtx code OUTER_CODE.  That is,
+     the hook can assume that there is some rtx Y such that 'GET_CODE
+     (Y) == OUTER_CODE' and such that either (a) 'XEXP (Y, OPNO) == X'
+     or (b) 'XVEC (Y, OPNO)' contains X.
+
+     CODE is X's expression code--redundant, since it can be obtained
+     with 'GET_CODE (X)'.
+
+     In implementing this hook, you can use the construct 'COSTS_N_INSNS
+     (N)' to specify a cost equal to N fast instructions.
+
+     On entry to the hook, '*TOTAL' contains a default estimate for the
+     cost of the expression.  The hook should modify this value as
+     necessary.  Traditionally, the default costs are 'COSTS_N_INSNS
+     (5)' for multiplications, 'COSTS_N_INSNS (7)' for division and
+     modulus operations, and 'COSTS_N_INSNS (1)' for all other
+     operations.
+
+     When optimizing for code size, i.e. when 'speed' is false, this
+     target hook should be used to estimate the relative size cost of an
+     expression, again relative to 'COSTS_N_INSNS'.
+
+     The hook returns true when all subexpressions of X have been
+     processed, and false when 'rtx_cost' should recurse.
+
+ -- Target Hook: int TARGET_ADDRESS_COST (rtx ADDRESS, enum machine_mode
+          MODE, addr_space_t AS, bool SPEED)
+     This hook computes the cost of an addressing mode that contains
+     ADDRESS.  If not defined, the cost is computed from the ADDRESS
+     expression and the 'TARGET_RTX_COST' hook.
+
+     For most CISC machines, the default cost is a good approximation of
+     the true cost of the addressing mode.  However, on RISC machines,
+     all instructions normally have the same length and execution time.
+     Hence all addresses will have equal costs.
+
+     In cases where more than one form of an address is known, the form
+     with the lowest cost will be used.  If multiple forms have the
+     same, lowest, cost, the one that is the most complex will be used.
+
+     For example, suppose an address that is equal to the sum of a
+     register and a constant is used twice in the same basic block.
+     When this macro is not defined, the address will be computed in a
+     register and memory references will be indirect through that
+     register.  On machines where the cost of the addressing mode
+     containing the sum is no higher than that of a simple indirect
+     reference, this will produce an additional instruction and possibly
+     require an additional register.  Proper specification of this macro
+     eliminates this overhead for such machines.
+
+     This hook is never called with an invalid address.
+
+     On machines where an address involving more than one register is as
+     cheap as an address computation involving only one register,
+     defining 'TARGET_ADDRESS_COST' to reflect this can cause two
+     registers to be live over a region of code where only one would
+     have been if 'TARGET_ADDRESS_COST' were not defined in that manner.
+     This effect should be considered in the definition of this macro.
+     Equivalent costs should probably only be given to addresses with
+     different numbers of registers on machines with lots of registers.
+
+
+File: gccint.info,  Node: Scheduling,  Next: Sections,  Prev: Costs,  Up: Target Macros
+
+17.18 Adjusting the Instruction Scheduler
+=========================================
+
+The instruction scheduler may need a fair amount of machine-specific
+adjustment in order to produce good code.  GCC provides several target
+hooks for this purpose.  It is usually enough to define just a few of
+them: try the first ones in this list first.
+
+ -- Target Hook: int TARGET_SCHED_ISSUE_RATE (void)
+     This hook returns the maximum number of instructions that can ever
+     issue at the same time on the target machine.  The default is one.
+     Although the insn scheduler can define itself the possibility of
+     issue an insn on the same cycle, the value can serve as an
+     additional constraint to issue insns on the same simulated
+     processor cycle (see hooks 'TARGET_SCHED_REORDER' and
+     'TARGET_SCHED_REORDER2').  This value must be constant over the
+     entire compilation.  If you need it to vary depending on what the
+     instructions are, you must use 'TARGET_SCHED_VARIABLE_ISSUE'.
+
+ -- Target Hook: int TARGET_SCHED_VARIABLE_ISSUE (FILE *FILE, int
+          VERBOSE, rtx INSN, int MORE)
+     This hook is executed by the scheduler after it has scheduled an
+     insn from the ready list.  It should return the number of insns
+     which can still be issued in the current cycle.  The default is
+     'MORE - 1' for insns other than 'CLOBBER' and 'USE', which normally
+     are not counted against the issue rate.  You should define this
+     hook if some insns take more machine resources than others, so that
+     fewer insns can follow them in the same cycle.  FILE is either a
+     null pointer, or a stdio stream to write any debug output to.
+     VERBOSE is the verbose level provided by '-fsched-verbose-N'.  INSN
+     is the instruction that was scheduled.
+
+ -- Target Hook: int TARGET_SCHED_ADJUST_COST (rtx INSN, rtx LINK, rtx
+          DEP_INSN, int COST)
+     This function corrects the value of COST based on the relationship
+     between INSN and DEP_INSN through the dependence LINK.  It should
+     return the new value.  The default is to make no adjustment to
+     COST.  This can be used for example to specify to the scheduler
+     using the traditional pipeline description that an output- or
+     anti-dependence does not incur the same cost as a data-dependence.
+     If the scheduler using the automaton based pipeline description,
+     the cost of anti-dependence is zero and the cost of
+     output-dependence is maximum of one and the difference of latency
+     times of the first and the second insns.  If these values are not
+     acceptable, you could use the hook to modify them too.  See also
+     *note Processor pipeline description::.
+
+ -- Target Hook: int TARGET_SCHED_ADJUST_PRIORITY (rtx INSN, int
+          PRIORITY)
+     This hook adjusts the integer scheduling priority PRIORITY of INSN.
+     It should return the new priority.  Increase the priority to
+     execute INSN earlier, reduce the priority to execute INSN later.
+     Do not define this hook if you do not need to adjust the scheduling
+     priorities of insns.
+
+ -- Target Hook: int TARGET_SCHED_REORDER (FILE *FILE, int VERBOSE, rtx
+          *READY, int *N_READYP, int CLOCK)
+     This hook is executed by the scheduler after it has scheduled the
+     ready list, to allow the machine description to reorder it (for
+     example to combine two small instructions together on 'VLIW'
+     machines).  FILE is either a null pointer, or a stdio stream to
+     write any debug output to.  VERBOSE is the verbose level provided
+     by '-fsched-verbose-N'.  READY is a pointer to the ready list of
+     instructions that are ready to be scheduled.  N_READYP is a pointer
+     to the number of elements in the ready list.  The scheduler reads
+     the ready list in reverse order, starting with READY[*N_READYP - 1]
+     and going to READY[0].  CLOCK is the timer tick of the scheduler.
+     You may modify the ready list and the number of ready insns.  The
+     return value is the number of insns that can issue this cycle;
+     normally this is just 'issue_rate'.  See also
+     'TARGET_SCHED_REORDER2'.
+
+ -- Target Hook: int TARGET_SCHED_REORDER2 (FILE *FILE, int VERBOSE, rtx
+          *READY, int *N_READYP, int CLOCK)
+     Like 'TARGET_SCHED_REORDER', but called at a different time.  That
+     function is called whenever the scheduler starts a new cycle.  This
+     one is called once per iteration over a cycle, immediately after
+     'TARGET_SCHED_VARIABLE_ISSUE'; it can reorder the ready list and
+     return the number of insns to be scheduled in the same cycle.
+     Defining this hook can be useful if there are frequent situations
+     where scheduling one insn causes other insns to become ready in the
+     same cycle.  These other insns can then be taken into account
+     properly.
+
+ -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_P (void)
+     This hook is used to check whether target platform supports macro
+     fusion.
+
+ -- Target Hook: bool TARGET_SCHED_MACRO_FUSION_PAIR_P (rtx CONDGEN, rtx
+          CONDJMP)
+     This hook is used to check whether two insns could be macro fused
+     for target microarchitecture.  If this hook returns true for the
+     given insn pair (CONDGEN and CONDJMP), scheduler will put them into
+     a sched group, and they will not be scheduled apart.
+
+ -- Target Hook: void TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK (rtx
+          HEAD, rtx TAIL)
+     This hook is called after evaluation forward dependencies of insns
+     in chain given by two parameter values (HEAD and TAIL
+     correspondingly) but before insns scheduling of the insn chain.
+     For example, it can be used for better insn classification if it
+     requires analysis of dependencies.  This hook can use backward and
+     forward dependencies of the insn scheduler because they are already
+     calculated.
+
+ -- Target Hook: void TARGET_SCHED_INIT (FILE *FILE, int VERBOSE, int
+          MAX_READY)
+     This hook is executed by the scheduler at the beginning of each
+     block of instructions that are to be scheduled.  FILE is either a
+     null pointer, or a stdio stream to write any debug output to.
+     VERBOSE is the verbose level provided by '-fsched-verbose-N'.
+     MAX_READY is the maximum number of insns in the current scheduling
+     region that can be live at the same time.  This can be used to
+     allocate scratch space if it is needed, e.g. by
+     'TARGET_SCHED_REORDER'.
+
+ -- Target Hook: void TARGET_SCHED_FINISH (FILE *FILE, int VERBOSE)
+     This hook is executed by the scheduler at the end of each block of
+     instructions that are to be scheduled.  It can be used to perform
+     cleanup of any actions done by the other scheduling hooks.  FILE is
+     either a null pointer, or a stdio stream to write any debug output
+     to.  VERBOSE is the verbose level provided by '-fsched-verbose-N'.
+
+ -- Target Hook: void TARGET_SCHED_INIT_GLOBAL (FILE *FILE, int VERBOSE,
+          int OLD_MAX_UID)
+     This hook is executed by the scheduler after function level
+     initializations.  FILE is either a null pointer, or a stdio stream
+     to write any debug output to.  VERBOSE is the verbose level
+     provided by '-fsched-verbose-N'.  OLD_MAX_UID is the maximum insn
+     uid when scheduling begins.
+
+ -- Target Hook: void TARGET_SCHED_FINISH_GLOBAL (FILE *FILE, int
+          VERBOSE)
+     This is the cleanup hook corresponding to
+     'TARGET_SCHED_INIT_GLOBAL'.  FILE is either a null pointer, or a
+     stdio stream to write any debug output to.  VERBOSE is the verbose
+     level provided by '-fsched-verbose-N'.
+
+ -- Target Hook: rtx TARGET_SCHED_DFA_PRE_CYCLE_INSN (void)
+     The hook returns an RTL insn.  The automaton state used in the
+     pipeline hazard recognizer is changed as if the insn were scheduled
+     when the new simulated processor cycle starts.  Usage of the hook
+     may simplify the automaton pipeline description for some VLIW
+     processors.  If the hook is defined, it is used only for the
+     automaton based pipeline description.  The default is not to change
+     the state when the new simulated processor cycle starts.
+
+ -- Target Hook: void TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN (void)
+     The hook can be used to initialize data used by the previous hook.
+
+ -- Target Hook: rtx TARGET_SCHED_DFA_POST_CYCLE_INSN (void)
+     The hook is analogous to 'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used
+     to changed the state as if the insn were scheduled when the new
+     simulated processor cycle finishes.
+
+ -- Target Hook: void TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN (void)
+     The hook is analogous to 'TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN' but
+     used to initialize data used by the previous hook.
+
+ -- Target Hook: void TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE (void)
+     The hook to notify target that the current simulated cycle is about
+     to finish.  The hook is analogous to
+     'TARGET_SCHED_DFA_PRE_CYCLE_INSN' but used to change the state in
+     more complicated situations - e.g., when advancing state on a
+     single insn is not enough.
+
+ -- Target Hook: void TARGET_SCHED_DFA_POST_ADVANCE_CYCLE (void)
+     The hook to notify target that new simulated cycle has just
+     started.  The hook is analogous to
+     'TARGET_SCHED_DFA_POST_CYCLE_INSN' but used to change the state in
+     more complicated situations - e.g., when advancing state on a
+     single insn is not enough.
+
+ -- Target Hook: int TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD
+          (void)
+     This hook controls better choosing an insn from the ready insn
+     queue for the DFA-based insn scheduler.  Usually the scheduler
+     chooses the first insn from the queue.  If the hook returns a
+     positive value, an additional scheduler code tries all permutations
+     of 'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD ()' subsequent
+     ready insns to choose an insn whose issue will result in maximal
+     number of issued insns on the same cycle.  For the VLIW processor,
+     the code could actually solve the problem of packing simple insns
+     into the VLIW insn.  Of course, if the rules of VLIW packing are
+     described in the automaton.
+
+     This code also could be used for superscalar RISC processors.  Let
+     us consider a superscalar RISC processor with 3 pipelines.  Some
+     insns can be executed in pipelines A or B, some insns can be
+     executed only in pipelines B or C, and one insn can be executed in
+     pipeline B.  The processor may issue the 1st insn into A and the
+     2nd one into B.  In this case, the 3rd insn will wait for freeing B
+     until the next cycle.  If the scheduler issues the 3rd insn the
+     first, the processor could issue all 3 insns per cycle.
+
+     Actually this code demonstrates advantages of the automaton based
+     pipeline hazard recognizer.  We try quickly and easy many insn
+     schedules to choose the best one.
+
+     The default is no multipass scheduling.
+
+ -- Target Hook: int
+          TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD (rtx
+          INSN)
+
+     This hook controls what insns from the ready insn queue will be
+     considered for the multipass insn scheduling.  If the hook returns
+     zero for INSN, the insn will be not chosen to be issued.
+
+     The default is that any ready insns can be chosen to be issued.
+
+ -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN (void
+          *DATA, char *READY_TRY, int N_READY, bool FIRST_CYCLE_INSN_P)
+     This hook prepares the target backend for a new round of multipass
+     scheduling.
+
+ -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE (void
+          *DATA, char *READY_TRY, int N_READY, rtx INSN, const void
+          *PREV_DATA)
+     This hook is called when multipass scheduling evaluates instruction
+     INSN.
+
+ -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK
+          (const void *DATA, char *READY_TRY, int N_READY)
+     This is called when multipass scheduling backtracks from evaluation
+     of an instruction.
+
+ -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END (const void
+          *DATA)
+     This hook notifies the target about the result of the concluded
+     current round of multipass scheduling.
+
+ -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT (void
+          *DATA)
+     This hook initializes target-specific data used in multipass
+     scheduling.
+
+ -- Target Hook: void TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI (void
+          *DATA)
+     This hook finalizes target-specific data used in multipass
+     scheduling.
+
+ -- Target Hook: int TARGET_SCHED_DFA_NEW_CYCLE (FILE *DUMP, int
+          VERBOSE, rtx INSN, int LAST_CLOCK, int CLOCK, int *SORT_P)
+     This hook is called by the insn scheduler before issuing INSN on
+     cycle CLOCK.  If the hook returns nonzero, INSN is not issued on
+     this processor cycle.  Instead, the processor cycle is advanced.
+     If *SORT_P is zero, the insn ready queue is not sorted on the new
+     cycle start as usually.  DUMP and VERBOSE specify the file and
+     verbosity level to use for debugging output.  LAST_CLOCK and CLOCK
+     are, respectively, the processor cycle on which the previous insn
+     has been issued, and the current processor cycle.
+
+ -- Target Hook: bool TARGET_SCHED_IS_COSTLY_DEPENDENCE (struct _dep
+          *_DEP, int COST, int DISTANCE)
+     This hook is used to define which dependences are considered costly
+     by the target, so costly that it is not advisable to schedule the
+     insns that are involved in the dependence too close to one another.
+     The parameters to this hook are as follows: The first parameter
+     _DEP is the dependence being evaluated.  The second parameter COST
+     is the cost of the dependence as estimated by the scheduler, and
+     the third parameter DISTANCE is the distance in cycles between the
+     two insns.  The hook returns 'true' if considering the distance
+     between the two insns the dependence between them is considered
+     costly by the target, and 'false' otherwise.
+
+     Defining this hook can be useful in multiple-issue out-of-order
+     machines, where (a) it's practically hopeless to predict the actual
+     data/resource delays, however: (b) there's a better chance to
+     predict the actual grouping that will be formed, and (c) correctly
+     emulating the grouping can be very important.  In such targets one
+     may want to allow issuing dependent insns closer to one
+     another--i.e., closer than the dependence distance; however, not in
+     cases of "costly dependences", which this hooks allows to define.
+
+ -- Target Hook: void TARGET_SCHED_H_I_D_EXTENDED (void)
+     This hook is called by the insn scheduler after emitting a new
+     instruction to the instruction stream.  The hook notifies a target
+     backend to extend its per instruction data structures.
+
+ -- Target Hook: void * TARGET_SCHED_ALLOC_SCHED_CONTEXT (void)
+     Return a pointer to a store large enough to hold target scheduling
+     context.
+
+ -- Target Hook: void TARGET_SCHED_INIT_SCHED_CONTEXT (void *TC, bool
+          CLEAN_P)
+     Initialize store pointed to by TC to hold target scheduling
+     context.  It CLEAN_P is true then initialize TC as if scheduler is
+     at the beginning of the block.  Otherwise, copy the current context
+     into TC.
+
+ -- Target Hook: void TARGET_SCHED_SET_SCHED_CONTEXT (void *TC)
+     Copy target scheduling context pointed to by TC to the current
+     context.
+
+ -- Target Hook: void TARGET_SCHED_CLEAR_SCHED_CONTEXT (void *TC)
+     Deallocate internal data in target scheduling context pointed to by
+     TC.
+
+ -- Target Hook: void TARGET_SCHED_FREE_SCHED_CONTEXT (void *TC)
+     Deallocate a store for target scheduling context pointed to by TC.
+
+ -- Target Hook: int TARGET_SCHED_SPECULATE_INSN (rtx INSN, unsigned int
+          DEP_STATUS, rtx *NEW_PAT)
+     This hook is called by the insn scheduler when INSN has only
+     speculative dependencies and therefore can be scheduled
+     speculatively.  The hook is used to check if the pattern of INSN
+     has a speculative version and, in case of successful check, to
+     generate that speculative pattern.  The hook should return 1, if
+     the instruction has a speculative form, or -1, if it doesn't.
+     REQUEST describes the type of requested speculation.  If the return
+     value equals 1 then NEW_PAT is assigned the generated speculative
+     pattern.
+
+ -- Target Hook: bool TARGET_SCHED_NEEDS_BLOCK_P (unsigned int
+          DEP_STATUS)
+     This hook is called by the insn scheduler during generation of
+     recovery code for INSN.  It should return 'true', if the
+     corresponding check instruction should branch to recovery code, or
+     'false' otherwise.
+
+ -- Target Hook: rtx TARGET_SCHED_GEN_SPEC_CHECK (rtx INSN, rtx LABEL,
+          unsigned int DS)
+     This hook is called by the insn scheduler to generate a pattern for
+     recovery check instruction.  If MUTATE_P is zero, then INSN is a
+     speculative instruction for which the check should be generated.
+     LABEL is either a label of a basic block, where recovery code
+     should be emitted, or a null pointer, when requested check doesn't
+     branch to recovery code (a simple check).  If MUTATE_P is nonzero,
+     then a pattern for a branchy check corresponding to a simple check
+     denoted by INSN should be generated.  In this case LABEL can't be
+     null.
+
+ -- Target Hook: bool
+          TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC
+          (const_rtx INSN)
+     This hook is used as a workaround for
+     'TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD' not being
+     called on the first instruction of the ready list.  The hook is
+     used to discard speculative instructions that stand first in the
+     ready list from being scheduled on the current cycle.  If the hook
+     returns 'false', INSN will not be chosen to be issued.  For
+     non-speculative instructions, the hook should always return 'true'.
+     For example, in the ia64 backend the hook is used to cancel data
+     speculative insns when the ALAT table is nearly full.
+
+ -- Target Hook: void TARGET_SCHED_SET_SCHED_FLAGS (struct spec_info_def
+          *SPEC_INFO)
+     This hook is used by the insn scheduler to find out what features
+     should be enabled/used.  The structure *SPEC_INFO should be filled
+     in by the target.  The structure describes speculation types that
+     can be used in the scheduler.
+
+ -- Target Hook: int TARGET_SCHED_SMS_RES_MII (struct ddg *G)
+     This hook is called by the swing modulo scheduler to calculate a
+     resource-based lower bound which is based on the resources
+     available in the machine and the resources required by each
+     instruction.  The target backend can use G to calculate such bound.
+     A very simple lower bound will be used in case this hook is not
+     implemented: the total number of instructions divided by the issue
+     rate.
+
+ -- Target Hook: bool TARGET_SCHED_DISPATCH (rtx INSN, int X)
+     This hook is called by Haifa Scheduler.  It returns true if
+     dispatch scheduling is supported in hardware and the condition
+     specified in the parameter is true.
+
+ -- Target Hook: void TARGET_SCHED_DISPATCH_DO (rtx INSN, int X)
+     This hook is called by Haifa Scheduler.  It performs the operation
+     specified in its second parameter.
+
+ -- Target Hook: bool TARGET_SCHED_EXPOSED_PIPELINE
+     True if the processor has an exposed pipeline, which means that not
+     just the order of instructions is important for correctness when
+     scheduling, but also the latencies of operations.
+
+ -- Target Hook: int TARGET_SCHED_REASSOCIATION_WIDTH (unsigned int OPC,
+          enum machine_mode MODE)
+     This hook is called by tree reassociator to determine a level of
+     parallelism required in output calculations chain.
+
+
+File: gccint.info,  Node: Sections,  Next: PIC,  Prev: Scheduling,  Up: Target Macros
+
+17.19 Dividing the Output into Sections (Texts, Data, ...)
+==========================================================
+
+An object file is divided into sections containing different types of
+data.  In the most common case, there are three sections: the "text
+section", which holds instructions and read-only data; the "data
+section", which holds initialized writable data; and the "bss section",
+which holds uninitialized data.  Some systems have other kinds of
+sections.
+
+ 'varasm.c' provides several well-known sections, such as
+'text_section', 'data_section' and 'bss_section'.  The normal way of
+controlling a 'FOO_section' variable is to define the associated
+'FOO_SECTION_ASM_OP' macro, as described below.  The macros are only
+read once, when 'varasm.c' initializes itself, so their values must be
+run-time constants.  They may however depend on command-line flags.
+
+ _Note:_ Some run-time files, such 'crtstuff.c', also make use of the
+'FOO_SECTION_ASM_OP' macros, and expect them to be string literals.
+
+ Some assemblers require a different string to be written every time a
+section is selected.  If your assembler falls into this category, you
+should define the 'TARGET_ASM_INIT_SECTIONS' hook and use
+'get_unnamed_section' to set up the sections.
+
+ You must always create a 'text_section', either by defining
+'TEXT_SECTION_ASM_OP' or by initializing 'text_section' in
+'TARGET_ASM_INIT_SECTIONS'.  The same is true of 'data_section' and
+'DATA_SECTION_ASM_OP'.  If you do not create a distinct
+'readonly_data_section', the default is to reuse 'text_section'.
+
+ All the other 'varasm.c' sections are optional, and are null if the
+target does not provide them.
+
+ -- Macro: TEXT_SECTION_ASM_OP
+     A C expression whose value is a string, including spacing,
+     containing the assembler operation that should precede instructions
+     and read-only data.  Normally '"\t.text"' is right.
+
+ -- Macro: HOT_TEXT_SECTION_NAME
+     If defined, a C string constant for the name of the section
+     containing most frequently executed functions of the program.  If
+     not defined, GCC will provide a default definition if the target
+     supports named sections.
+
+ -- Macro: UNLIKELY_EXECUTED_TEXT_SECTION_NAME
+     If defined, a C string constant for the name of the section
+     containing unlikely executed functions in the program.
+
+ -- Macro: DATA_SECTION_ASM_OP
+     A C expression whose value is a string, including spacing,
+     containing the assembler operation to identify the following data
+     as writable initialized data.  Normally '"\t.data"' is right.
+
+ -- Macro: SDATA_SECTION_ASM_OP
+     If defined, a C expression whose value is a string, including
+     spacing, containing the assembler operation to identify the
+     following data as initialized, writable small data.
+
+ -- Macro: READONLY_DATA_SECTION_ASM_OP
+     A C expression whose value is a string, including spacing,
+     containing the assembler operation to identify the following data
+     as read-only initialized data.
+
+ -- Macro: BSS_SECTION_ASM_OP
+     If defined, a C expression whose value is a string, including
+     spacing, containing the assembler operation to identify the
+     following data as uninitialized global data.  If not defined, and
+     'ASM_OUTPUT_ALIGNED_BSS' not defined, uninitialized global data
+     will be output in the data section if '-fno-common' is passed,
+     otherwise 'ASM_OUTPUT_COMMON' will be used.
+
+ -- Macro: SBSS_SECTION_ASM_OP
+     If defined, a C expression whose value is a string, including
+     spacing, containing the assembler operation to identify the
+     following data as uninitialized, writable small data.
+
+ -- Macro: TLS_COMMON_ASM_OP
+     If defined, a C expression whose value is a string containing the
+     assembler operation to identify the following data as thread-local
+     common data.  The default is '".tls_common"'.
+
+ -- Macro: TLS_SECTION_ASM_FLAG
+     If defined, a C expression whose value is a character constant
+     containing the flag used to mark a section as a TLS section.  The
+     default is ''T''.
+
+ -- Macro: INIT_SECTION_ASM_OP
+     If defined, a C expression whose value is a string, including
+     spacing, containing the assembler operation to identify the
+     following data as initialization code.  If not defined, GCC will
+     assume such a section does not exist.  This section has no
+     corresponding 'init_section' variable; it is used entirely in
+     runtime code.
+
+ -- Macro: FINI_SECTION_ASM_OP
+     If defined, a C expression whose value is a string, including
+     spacing, containing the assembler operation to identify the
+     following data as finalization code.  If not defined, GCC will
+     assume such a section does not exist.  This section has no
+     corresponding 'fini_section' variable; it is used entirely in
+     runtime code.
+
+ -- Macro: INIT_ARRAY_SECTION_ASM_OP
+     If defined, a C expression whose value is a string, including
+     spacing, containing the assembler operation to identify the
+     following data as part of the '.init_array' (or equivalent)
+     section.  If not defined, GCC will assume such a section does not
+     exist.  Do not define both this macro and 'INIT_SECTION_ASM_OP'.
+
+ -- Macro: FINI_ARRAY_SECTION_ASM_OP
+     If defined, a C expression whose value is a string, including
+     spacing, containing the assembler operation to identify the
+     following data as part of the '.fini_array' (or equivalent)
+     section.  If not defined, GCC will assume such a section does not
+     exist.  Do not define both this macro and 'FINI_SECTION_ASM_OP'.
+
+ -- Macro: CRT_CALL_STATIC_FUNCTION (SECTION_OP, FUNCTION)
+     If defined, an ASM statement that switches to a different section
+     via SECTION_OP, calls FUNCTION, and switches back to the text
+     section.  This is used in 'crtstuff.c' if 'INIT_SECTION_ASM_OP' or
+     'FINI_SECTION_ASM_OP' to calls to initialization and finalization
+     functions from the init and fini sections.  By default, this macro
+     uses a simple function call.  Some ports need hand-crafted assembly
+     code to avoid dependencies on registers initialized in the function
+     prologue or to ensure that constant pools don't end up too far way
+     in the text section.
+
+ -- Macro: TARGET_LIBGCC_SDATA_SECTION
+     If defined, a string which names the section into which small
+     variables defined in crtstuff and libgcc should go.  This is useful
+     when the target has options for optimizing access to small data,
+     and you want the crtstuff and libgcc routines to be conservative in
+     what they expect of your application yet liberal in what your
+     application expects.  For example, for targets with a '.sdata'
+     section (like MIPS), you could compile crtstuff with '-G 0' so that
+     it doesn't require small data support from your application, but
+     use this macro to put small data into '.sdata' so that your
+     application can access these variables whether it uses small data
+     or not.
+
+ -- Macro: FORCE_CODE_SECTION_ALIGN
+     If defined, an ASM statement that aligns a code section to some
+     arbitrary boundary.  This is used to force all fragments of the
+     '.init' and '.fini' sections to have to same alignment and thus
+     prevent the linker from having to add any padding.
+
+ -- Macro: JUMP_TABLES_IN_TEXT_SECTION
+     Define this macro to be an expression with a nonzero value if jump
+     tables (for 'tablejump' insns) should be output in the text
+     section, along with the assembler instructions.  Otherwise, the
+     readonly data section is used.
+
+     This macro is irrelevant if there is no separate readonly data
+     section.
+
+ -- Target Hook: void TARGET_ASM_INIT_SECTIONS (void)
+     Define this hook if you need to do something special to set up the
+     'varasm.c' sections, or if your target has some special sections of
+     its own that you need to create.
+
+     GCC calls this hook after processing the command line, but before
+     writing any assembly code, and before calling any of the
+     section-returning hooks described below.
+
+ -- Target Hook: int TARGET_ASM_RELOC_RW_MASK (void)
+     Return a mask describing how relocations should be treated when
+     selecting sections.  Bit 1 should be set if global relocations
+     should be placed in a read-write section; bit 0 should be set if
+     local relocations should be placed in a read-write section.
+
+     The default version of this function returns 3 when '-fpic' is in
+     effect, and 0 otherwise.  The hook is typically redefined when the
+     target cannot support (some kinds of) dynamic relocations in
+     read-only sections even in executables.
+
+ -- Target Hook: section * TARGET_ASM_SELECT_SECTION (tree EXP, int
+          RELOC, unsigned HOST_WIDE_INT ALIGN)
+     Return the section into which EXP should be placed.  You can assume
+     that EXP is either a 'VAR_DECL' node or a constant of some sort.
+     RELOC indicates whether the initial value of EXP requires link-time
+     relocations.  Bit 0 is set when variable contains local relocations
+     only, while bit 1 is set for global relocations.  ALIGN is the
+     constant alignment in bits.
+
+     The default version of this function takes care of putting
+     read-only variables in 'readonly_data_section'.
+
+     See also USE_SELECT_SECTION_FOR_FUNCTIONS.
+
+ -- Macro: USE_SELECT_SECTION_FOR_FUNCTIONS
+     Define this macro if you wish TARGET_ASM_SELECT_SECTION to be
+     called for 'FUNCTION_DECL's as well as for variables and constants.
+
+     In the case of a 'FUNCTION_DECL', RELOC will be zero if the
+     function has been determined to be likely to be called, and nonzero
+     if it is unlikely to be called.
+
+ -- Target Hook: void TARGET_ASM_UNIQUE_SECTION (tree DECL, int RELOC)
+     Build up a unique section name, expressed as a 'STRING_CST' node,
+     and assign it to 'DECL_SECTION_NAME (DECL)'.  As with
+     'TARGET_ASM_SELECT_SECTION', RELOC indicates whether the initial
+     value of EXP requires link-time relocations.
+
+     The default version of this function appends the symbol name to the
+     ELF section name that would normally be used for the symbol.  For
+     example, the function 'foo' would be placed in '.text.foo'.
+     Whatever the actual target object format, this is often good
+     enough.
+
+ -- Target Hook: section * TARGET_ASM_FUNCTION_RODATA_SECTION (tree
+          DECL)
+     Return the readonly data section associated with 'DECL_SECTION_NAME
+     (DECL)'.  The default version of this function selects
+     '.gnu.linkonce.r.name' if the function's section is
+     '.gnu.linkonce.t.name', '.rodata.name' if function is in
+     '.text.name', and the normal readonly-data section otherwise.
+
+ -- Target Hook: const char * TARGET_ASM_MERGEABLE_RODATA_PREFIX
+     Usually, the compiler uses the prefix '".rodata"' to construct
+     section names for mergeable constant data.  Define this macro to
+     override the string if a different section name should be used.
+
+ -- Target Hook: section * TARGET_ASM_TM_CLONE_TABLE_SECTION (void)
+     Return the section that should be used for transactional memory
+     clone tables.
+
+ -- Target Hook: section * TARGET_ASM_SELECT_RTX_SECTION (enum
+          machine_mode MODE, rtx X, unsigned HOST_WIDE_INT ALIGN)
+     Return the section into which a constant X, of mode MODE, should be
+     placed.  You can assume that X is some kind of constant in RTL.
+     The argument MODE is redundant except in the case of a 'const_int'
+     rtx.  ALIGN is the constant alignment in bits.
+
+     The default version of this function takes care of putting symbolic
+     constants in 'flag_pic' mode in 'data_section' and everything else
+     in 'readonly_data_section'.
+
+ -- Target Hook: tree TARGET_MANGLE_DECL_ASSEMBLER_NAME (tree DECL, tree
+          ID)
+     Define this hook if you need to postprocess the assembler name
+     generated by target-independent code.  The ID provided to this hook
+     will be the computed name (e.g., the macro 'DECL_NAME' of the DECL
+     in C, or the mangled name of the DECL in C++).  The return value of
+     the hook is an 'IDENTIFIER_NODE' for the appropriate mangled name
+     on your target system.  The default implementation of this hook
+     just returns the ID provided.
+
+ -- Target Hook: void TARGET_ENCODE_SECTION_INFO (tree DECL, rtx RTL,
+          int NEW_DECL_P)
+     Define this hook if references to a symbol or a constant must be
+     treated differently depending on something about the variable or
+     function named by the symbol (such as what section it is in).
+
+     The hook is executed immediately after rtl has been created for
+     DECL, which may be a variable or function declaration or an entry
+     in the constant pool.  In either case, RTL is the rtl in question.
+     Do _not_ use 'DECL_RTL (DECL)' in this hook; that field may not
+     have been initialized yet.
+
+     In the case of a constant, it is safe to assume that the rtl is a
+     'mem' whose address is a 'symbol_ref'.  Most decls will also have
+     this form, but that is not guaranteed.  Global register variables,
+     for instance, will have a 'reg' for their rtl.  (Normally the right
+     thing to do with such unusual rtl is leave it alone.)
+
+     The NEW_DECL_P argument will be true if this is the first time that
+     'TARGET_ENCODE_SECTION_INFO' has been invoked on this decl.  It
+     will be false for subsequent invocations, which will happen for
+     duplicate declarations.  Whether or not anything must be done for
+     the duplicate declaration depends on whether the hook examines
+     'DECL_ATTRIBUTES'.  NEW_DECL_P is always true when the hook is
+     called for a constant.
+
+     The usual thing for this hook to do is to record flags in the
+     'symbol_ref', using 'SYMBOL_REF_FLAG' or 'SYMBOL_REF_FLAGS'.
+     Historically, the name string was modified if it was necessary to
+     encode more than one bit of information, but this practice is now
+     discouraged; use 'SYMBOL_REF_FLAGS'.
+
+     The default definition of this hook, 'default_encode_section_info'
+     in 'varasm.c', sets a number of commonly-useful bits in
+     'SYMBOL_REF_FLAGS'.  Check whether the default does what you need
+     before overriding it.
+
+ -- Target Hook: const char * TARGET_STRIP_NAME_ENCODING (const char
+          *NAME)
+     Decode NAME and return the real name part, sans the characters that
+     'TARGET_ENCODE_SECTION_INFO' may have added.
+
+ -- Target Hook: bool TARGET_IN_SMALL_DATA_P (const_tree EXP)
+     Returns true if EXP should be placed into a "small data" section.
+     The default version of this hook always returns false.
+
+ -- Target Hook: bool TARGET_HAVE_SRODATA_SECTION
+     Contains the value true if the target places read-only "small data"
+     into a separate section.  The default value is false.
+
+ -- Target Hook: bool TARGET_PROFILE_BEFORE_PROLOGUE (void)
+     It returns true if target wants profile code emitted before
+     prologue.
+
+     The default version of this hook use the target macro
+     'PROFILE_BEFORE_PROLOGUE'.
+
+ -- Target Hook: bool TARGET_BINDS_LOCAL_P (const_tree EXP)
+     Returns true if EXP names an object for which name resolution rules
+     must resolve to the current "module" (dynamic shared library or
+     executable image).
+
+     The default version of this hook implements the name resolution
+     rules for ELF, which has a looser model of global name binding than
+     other currently supported object file formats.
+
+ -- Target Hook: bool TARGET_HAVE_TLS
+     Contains the value true if the target supports thread-local
+     storage.  The default value is false.
+
+
+File: gccint.info,  Node: PIC,  Next: Assembler Format,  Prev: Sections,  Up: Target Macros
+
+17.20 Position Independent Code
+===============================
+
+This section describes macros that help implement generation of position
+independent code.  Simply defining these macros is not enough to
+generate valid PIC; you must also add support to the hook
+'TARGET_LEGITIMATE_ADDRESS_P' and to the macro 'PRINT_OPERAND_ADDRESS',
+as well as 'LEGITIMIZE_ADDRESS'.  You must modify the definition of
+'movsi' to do something appropriate when the source operand contains a
+symbolic address.  You may also need to alter the handling of switch
+statements so that they use relative addresses.
+
+ -- Macro: PIC_OFFSET_TABLE_REGNUM
+     The register number of the register used to address a table of
+     static data addresses in memory.  In some cases this register is
+     defined by a processor's "application binary interface" (ABI).
+     When this macro is defined, RTL is generated for this register
+     once, as with the stack pointer and frame pointer registers.  If
+     this macro is not defined, it is up to the machine-dependent files
+     to allocate such a register (if necessary).  Note that this
+     register must be fixed when in use (e.g. when 'flag_pic' is true).
+
+ -- Macro: PIC_OFFSET_TABLE_REG_CALL_CLOBBERED
+     A C expression that is nonzero if the register defined by
+     'PIC_OFFSET_TABLE_REGNUM' is clobbered by calls.  If not defined,
+     the default is zero.  Do not define this macro if
+     'PIC_OFFSET_TABLE_REGNUM' is not defined.
+
+ -- Macro: LEGITIMATE_PIC_OPERAND_P (X)
+     A C expression that is nonzero if X is a legitimate immediate
+     operand on the target machine when generating position independent
+     code.  You can assume that X satisfies 'CONSTANT_P', so you need
+     not check this.  You can also assume FLAG_PIC is true, so you need
+     not check it either.  You need not define this macro if all
+     constants (including 'SYMBOL_REF') can be immediate operands when
+     generating position independent code.
+
+
+File: gccint.info,  Node: Assembler Format,  Next: Debugging Info,  Prev: PIC,  Up: Target Macros
+
+17.21 Defining the Output Assembler Language
+============================================
+
+This section describes macros whose principal purpose is to describe how
+to write instructions in assembler language--rather than what the
+instructions do.
+
+* Menu:
+
+* File Framework::       Structural information for the assembler file.
+* Data Output::          Output of constants (numbers, strings, addresses).
+* Uninitialized Data::   Output of uninitialized variables.
+* Label Output::         Output and generation of labels.
+* Initialization::       General principles of initialization
+                         and termination routines.
+* Macros for Initialization::
+                         Specific macros that control the handling of
+                         initialization and termination routines.
+* Instruction Output::   Output of actual instructions.
+* Dispatch Tables::      Output of jump tables.
+* Exception Region Output:: Output of exception region code.
+* Alignment Output::     Pseudo ops for alignment and skipping data.
+
+
+File: gccint.info,  Node: File Framework,  Next: Data Output,  Up: Assembler Format
+
+17.21.1 The Overall Framework of an Assembler File
+--------------------------------------------------
+
+This describes the overall framework of an assembly file.
+
+ -- Target Hook: void TARGET_ASM_FILE_START (void)
+     Output to 'asm_out_file' any text which the assembler expects to
+     find at the beginning of a file.  The default behavior is
+     controlled by two flags, documented below.  Unless your target's
+     assembler is quite unusual, if you override the default, you should
+     call 'default_file_start' at some point in your target hook.  This
+     lets other target files rely on these variables.
+
+ -- Target Hook: bool TARGET_ASM_FILE_START_APP_OFF
+     If this flag is true, the text of the macro 'ASM_APP_OFF' will be
+     printed as the very first line in the assembly file, unless
+     '-fverbose-asm' is in effect.  (If that macro has been defined to
+     the empty string, this variable has no effect.)  With the normal
+     definition of 'ASM_APP_OFF', the effect is to notify the GNU
+     assembler that it need not bother stripping comments or extra
+     whitespace from its input.  This allows it to work a bit faster.
+
+     The default is false.  You should not set it to true unless you
+     have verified that your port does not generate any extra whitespace
+     or comments that will cause GAS to issue errors in NO_APP mode.
+
+ -- Target Hook: bool TARGET_ASM_FILE_START_FILE_DIRECTIVE
+     If this flag is true, 'output_file_directive' will be called for
+     the primary source file, immediately after printing 'ASM_APP_OFF'
+     (if that is enabled).  Most ELF assemblers expect this to be done.
+     The default is false.
+
+ -- Target Hook: void TARGET_ASM_FILE_END (void)
+     Output to 'asm_out_file' any text which the assembler expects to
+     find at the end of a file.  The default is to output nothing.
+
+ -- Function: void file_end_indicate_exec_stack ()
+     Some systems use a common convention, the '.note.GNU-stack' special
+     section, to indicate whether or not an object file relies on the
+     stack being executable.  If your system uses this convention, you
+     should define 'TARGET_ASM_FILE_END' to this function.  If you need
+     to do other things in that hook, have your hook function call this
+     function.
+
+ -- Target Hook: void TARGET_ASM_LTO_START (void)
+     Output to 'asm_out_file' any text which the assembler expects to
+     find at the start of an LTO section.  The default is to output
+     nothing.
+
+ -- Target Hook: void TARGET_ASM_LTO_END (void)
+     Output to 'asm_out_file' any text which the assembler expects to
+     find at the end of an LTO section.  The default is to output
+     nothing.
+
+ -- Target Hook: void TARGET_ASM_CODE_END (void)
+     Output to 'asm_out_file' any text which is needed before emitting
+     unwind info and debug info at the end of a file.  Some targets emit
+     here PIC setup thunks that cannot be emitted at the end of file,
+     because they couldn't have unwind info then.  The default is to
+     output nothing.
+
+ -- Macro: ASM_COMMENT_START
+     A C string constant describing how to begin a comment in the target
+     assembler language.  The compiler assumes that the comment will end
+     at the end of the line.
+
+ -- Macro: ASM_APP_ON
+     A C string constant for text to be output before each 'asm'
+     statement or group of consecutive ones.  Normally this is '"#APP"',
+     which is a comment that has no effect on most assemblers but tells
+     the GNU assembler that it must check the lines that follow for all
+     valid assembler constructs.
+
+ -- Macro: ASM_APP_OFF
+     A C string constant for text to be output after each 'asm'
+     statement or group of consecutive ones.  Normally this is
+     '"#NO_APP"', which tells the GNU assembler to resume making the
+     time-saving assumptions that are valid for ordinary compiler
+     output.
+
+ -- Macro: ASM_OUTPUT_SOURCE_FILENAME (STREAM, NAME)
+     A C statement to output COFF information or DWARF debugging
+     information which indicates that filename NAME is the current
+     source file to the stdio stream STREAM.
+
+     This macro need not be defined if the standard form of output for
+     the file format in use is appropriate.
+
+ -- Target Hook: void TARGET_ASM_OUTPUT_SOURCE_FILENAME (FILE *FILE,
+          const char *NAME)
+     Output COFF information or DWARF debugging information which
+     indicates that filename NAME is the current source file to the
+     stdio stream FILE.
+
+     This target hook need not be defined if the standard form of output
+     for the file format in use is appropriate.
+
+ -- Target Hook: void TARGET_ASM_OUTPUT_IDENT (const char *NAME)
+     Output a string based on NAME, suitable for the '#ident' directive,
+     or the equivalent directive or pragma in non-C-family languages.
+     If this hook is not defined, nothing is output for the '#ident'
+     directive.
+
+ -- Macro: OUTPUT_QUOTED_STRING (STREAM, STRING)
+     A C statement to output the string STRING to the stdio stream
+     STREAM.  If you do not call the function 'output_quoted_string' in
+     your config files, GCC will only call it to output filenames to the
+     assembler source.  So you can use it to canonicalize the format of
+     the filename using this macro.
+
+ -- Target Hook: void TARGET_ASM_NAMED_SECTION (const char *NAME,
+          unsigned int FLAGS, tree DECL)
+     Output assembly directives to switch to section NAME.  The section
+     should have attributes as specified by FLAGS, which is a bit mask
+     of the 'SECTION_*' flags defined in 'output.h'.  If DECL is
+     non-NULL, it is the 'VAR_DECL' or 'FUNCTION_DECL' with which this
+     section is associated.
+
+ -- Target Hook: section * TARGET_ASM_FUNCTION_SECTION (tree DECL, enum
+          node_frequency FREQ, bool STARTUP, bool EXIT)
+     Return preferred text (sub)section for function DECL.  Main purpose
+     of this function is to separate cold, normal and hot functions.
+     STARTUP is true when function is known to be used only at startup
+     (from static constructors or it is 'main()').  EXIT is true when
+     function is known to be used only at exit (from static
+     destructors).  Return NULL if function should go to default text
+     section.
+
+ -- Target Hook: void TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS (FILE
+          *FILE, tree DECL, bool NEW_IS_COLD)
+     Used by the target to emit any assembler directives or additional
+     labels needed when a function is partitioned between different
+     sections.  Output should be written to FILE.  The function decl is
+     available as DECL and the new section is 'cold' if NEW_IS_COLD is
+     'true'.
+
+ -- Common Target Hook: bool TARGET_HAVE_NAMED_SECTIONS
+     This flag is true if the target supports
+     'TARGET_ASM_NAMED_SECTION'.  It must not be modified by
+     command-line option processing.
+
+ -- Target Hook: bool TARGET_HAVE_SWITCHABLE_BSS_SECTIONS
+     This flag is true if we can create zeroed data by switching to a
+     BSS section and then using 'ASM_OUTPUT_SKIP' to allocate the space.
+     This is true on most ELF targets.
+
+ -- Target Hook: unsigned int TARGET_SECTION_TYPE_FLAGS (tree DECL,
+          const char *NAME, int RELOC)
+     Choose a set of section attributes for use by
+     'TARGET_ASM_NAMED_SECTION' based on a variable or function decl, a
+     section name, and whether or not the declaration's initializer may
+     contain runtime relocations.  DECL may be null, in which case
+     read-write data should be assumed.
+
+     The default version of this function handles choosing code vs data,
+     read-only vs read-write data, and 'flag_pic'.  You should only need
+     to override this if your target has special flags that might be set
+     via '__attribute__'.
+
+ -- Target Hook: int TARGET_ASM_RECORD_GCC_SWITCHES (print_switch_type
+          TYPE, const char *TEXT)
+     Provides the target with the ability to record the gcc command line
+     switches that have been passed to the compiler, and options that
+     are enabled.  The TYPE argument specifies what is being recorded.
+     It can take the following values:
+
+     'SWITCH_TYPE_PASSED'
+          TEXT is a command line switch that has been set by the user.
+
+     'SWITCH_TYPE_ENABLED'
+          TEXT is an option which has been enabled.  This might be as a
+          direct result of a command line switch, or because it is
+          enabled by default or because it has been enabled as a side
+          effect of a different command line switch.  For example, the
+          '-O2' switch enables various different individual optimization
+          passes.
+
+     'SWITCH_TYPE_DESCRIPTIVE'
+          TEXT is either NULL or some descriptive text which should be
+          ignored.  If TEXT is NULL then it is being used to warn the
+          target hook that either recording is starting or ending.  The
+          first time TYPE is SWITCH_TYPE_DESCRIPTIVE and TEXT is NULL,
+          the warning is for start up and the second time the warning is
+          for wind down.  This feature is to allow the target hook to
+          make any necessary preparations before it starts to record
+          switches and to perform any necessary tidying up after it has
+          finished recording switches.
+
+     'SWITCH_TYPE_LINE_START'
+          This option can be ignored by this target hook.
+
+     'SWITCH_TYPE_LINE_END'
+          This option can be ignored by this target hook.
+
+     The hook's return value must be zero.  Other return values may be
+     supported in the future.
+
+     By default this hook is set to NULL, but an example implementation
+     is provided for ELF based targets.  Called ELF_RECORD_GCC_SWITCHES,
+     it records the switches as ASCII text inside a new, string
+     mergeable section in the assembler output file.  The name of the
+     new section is provided by the
+     'TARGET_ASM_RECORD_GCC_SWITCHES_SECTION' target hook.
+
+ -- Target Hook: const char * TARGET_ASM_RECORD_GCC_SWITCHES_SECTION
+     This is the name of the section that will be created by the example
+     ELF implementation of the 'TARGET_ASM_RECORD_GCC_SWITCHES' target
+     hook.
+
+
+File: gccint.info,  Node: Data Output,  Next: Uninitialized Data,  Prev: File Framework,  Up: Assembler Format
+
+17.21.2 Output of Data
+----------------------
+
+ -- Target Hook: const char * TARGET_ASM_BYTE_OP
+ -- Target Hook: const char * TARGET_ASM_ALIGNED_HI_OP
+ -- Target Hook: const char * TARGET_ASM_ALIGNED_SI_OP
+ -- Target Hook: const char * TARGET_ASM_ALIGNED_DI_OP
+ -- Target Hook: const char * TARGET_ASM_ALIGNED_TI_OP
+ -- Target Hook: const char * TARGET_ASM_UNALIGNED_HI_OP
+ -- Target Hook: const char * TARGET_ASM_UNALIGNED_SI_OP
+ -- Target Hook: const char * TARGET_ASM_UNALIGNED_DI_OP
+ -- Target Hook: const char * TARGET_ASM_UNALIGNED_TI_OP
+     These hooks specify assembly directives for creating certain kinds
+     of integer object.  The 'TARGET_ASM_BYTE_OP' directive creates a
+     byte-sized object, the 'TARGET_ASM_ALIGNED_HI_OP' one creates an
+     aligned two-byte object, and so on.  Any of the hooks may be
+     'NULL', indicating that no suitable directive is available.
+
+     The compiler will print these strings at the start of a new line,
+     followed immediately by the object's initial value.  In most cases,
+     the string should contain a tab, a pseudo-op, and then another tab.
+
+ -- Target Hook: bool TARGET_ASM_INTEGER (rtx X, unsigned int SIZE, int
+          ALIGNED_P)
+     The 'assemble_integer' function uses this hook to output an integer
+     object.  X is the object's value, SIZE is its size in bytes and
+     ALIGNED_P indicates whether it is aligned.  The function should
+     return 'true' if it was able to output the object.  If it returns
+     false, 'assemble_integer' will try to split the object into smaller
+     parts.
+
+     The default implementation of this hook will use the
+     'TARGET_ASM_BYTE_OP' family of strings, returning 'false' when the
+     relevant string is 'NULL'.
+
+ -- Target Hook: bool TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA (FILE *FILE,
+          rtx X)
+     A target hook to recognize RTX patterns that 'output_addr_const'
+     can't deal with, and output assembly code to FILE corresponding to
+     the pattern X.  This may be used to allow machine-dependent
+     'UNSPEC's to appear within constants.
+
+     If target hook fails to recognize a pattern, it must return
+     'false', so that a standard error message is printed.  If it prints
+     an error message itself, by calling, for example,
+     'output_operand_lossage', it may just return 'true'.
+
+ -- Macro: ASM_OUTPUT_ASCII (STREAM, PTR, LEN)
+     A C statement to output to the stdio stream STREAM an assembler
+     instruction to assemble a string constant containing the LEN bytes
+     at PTR.  PTR will be a C expression of type 'char *' and LEN a C
+     expression of type 'int'.
+
+     If the assembler has a '.ascii' pseudo-op as found in the Berkeley
+     Unix assembler, do not define the macro 'ASM_OUTPUT_ASCII'.
+
+ -- Macro: ASM_OUTPUT_FDESC (STREAM, DECL, N)
+     A C statement to output word N of a function descriptor for DECL.
+     This must be defined if 'TARGET_VTABLE_USES_DESCRIPTORS' is
+     defined, and is otherwise unused.
+
+ -- Macro: CONSTANT_POOL_BEFORE_FUNCTION
+     You may define this macro as a C expression.  You should define the
+     expression to have a nonzero value if GCC should output the
+     constant pool for a function before the code for the function, or a
+     zero value if GCC should output the constant pool after the
+     function.  If you do not define this macro, the usual case, GCC
+     will output the constant pool before the function.
+
+ -- Macro: ASM_OUTPUT_POOL_PROLOGUE (FILE, FUNNAME, FUNDECL, SIZE)
+     A C statement to output assembler commands to define the start of
+     the constant pool for a function.  FUNNAME is a string giving the
+     name of the function.  Should the return type of the function be
+     required, it can be obtained via FUNDECL.  SIZE is the size, in
+     bytes, of the constant pool that will be written immediately after
+     this call.
+
+     If no constant-pool prefix is required, the usual case, this macro
+     need not be defined.
+
+ -- Macro: ASM_OUTPUT_SPECIAL_POOL_ENTRY (FILE, X, MODE, ALIGN, LABELNO,
+          JUMPTO)
+     A C statement (with or without semicolon) to output a constant in
+     the constant pool, if it needs special treatment.  (This macro need
+     not do anything for RTL expressions that can be output normally.)
+
+     The argument FILE is the standard I/O stream to output the
+     assembler code on.  X is the RTL expression for the constant to
+     output, and MODE is the machine mode (in case X is a 'const_int').
+     ALIGN is the required alignment for the value X; you should output
+     an assembler directive to force this much alignment.
+
+     The argument LABELNO is a number to use in an internal label for
+     the address of this pool entry.  The definition of this macro is
+     responsible for outputting the label definition at the proper
+     place.  Here is how to do this:
+
+          (*targetm.asm_out.internal_label) (FILE, "LC", LABELNO);
+
+     When you output a pool entry specially, you should end with a
+     'goto' to the label JUMPTO.  This will prevent the same pool entry
+     from being output a second time in the usual manner.
+
+     You need not define this macro if it would do nothing.
+
+ -- Macro: ASM_OUTPUT_POOL_EPILOGUE (FILE FUNNAME FUNDECL SIZE)
+     A C statement to output assembler commands to at the end of the
+     constant pool for a function.  FUNNAME is a string giving the name
+     of the function.  Should the return type of the function be
+     required, you can obtain it via FUNDECL.  SIZE is the size, in
+     bytes, of the constant pool that GCC wrote immediately before this
+     call.
+
+     If no constant-pool epilogue is required, the usual case, you need
+     not define this macro.
+
+ -- Macro: IS_ASM_LOGICAL_LINE_SEPARATOR (C, STR)
+     Define this macro as a C expression which is nonzero if C is used
+     as a logical line separator by the assembler.  STR points to the
+     position in the string where C was found; this can be used if a
+     line separator uses multiple characters.
+
+     If you do not define this macro, the default is that only the
+     character ';' is treated as a logical line separator.
+
+ -- Target Hook: const char * TARGET_ASM_OPEN_PAREN
+ -- Target Hook: const char * TARGET_ASM_CLOSE_PAREN
+     These target hooks are C string constants, describing the syntax in
+     the assembler for grouping arithmetic expressions.  If not
+     overridden, they default to normal parentheses, which is correct
+     for most assemblers.
+
+ These macros are provided by 'real.h' for writing the definitions of
+'ASM_OUTPUT_DOUBLE' and the like:
+
+ -- Macro: REAL_VALUE_TO_TARGET_SINGLE (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_DOUBLE (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_LONG_DOUBLE (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_DECIMAL32 (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_DECIMAL64 (X, L)
+ -- Macro: REAL_VALUE_TO_TARGET_DECIMAL128 (X, L)
+     These translate X, of type 'REAL_VALUE_TYPE', to the target's
+     floating point representation, and store its bit pattern in the
+     variable L.  For 'REAL_VALUE_TO_TARGET_SINGLE' and
+     'REAL_VALUE_TO_TARGET_DECIMAL32', this variable should be a simple
+     'long int'.  For the others, it should be an array of 'long int'.
+     The number of elements in this array is determined by the size of
+     the desired target floating point data type: 32 bits of it go in
+     each 'long int' array element.  Each array element holds 32 bits of
+     the result, even if 'long int' is wider than 32 bits on the host
+     machine.
+
+     The array element values are designed so that you can print them
+     out using 'fprintf' in the order they should appear in the target
+     machine's memory.
+
+
+File: gccint.info,  Node: Uninitialized Data,  Next: Label Output,  Prev: Data Output,  Up: Assembler Format
+
+17.21.3 Output of Uninitialized Variables
+-----------------------------------------
+
+Each of the macros in this section is used to do the whole job of
+outputting a single uninitialized variable.
+
+ -- Macro: ASM_OUTPUT_COMMON (STREAM, NAME, SIZE, ROUNDED)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     the assembler definition of a common-label named NAME whose size is
+     SIZE bytes.  The variable ROUNDED is the size rounded up to
+     whatever alignment the caller wants.  It is possible that SIZE may
+     be zero, for instance if a struct with no other member than a
+     zero-length array is defined.  In this case, the backend must
+     output a symbol definition that allocates at least one byte, both
+     so that the address of the resulting object does not compare equal
+     to any other, and because some object formats cannot even express
+     the concept of a zero-sized common symbol, as that is how they
+     represent an ordinary undefined external.
+
+     Use the expression 'assemble_name (STREAM, NAME)' to output the
+     name itself; before and after that, output the additional assembler
+     syntax for defining the name, and a newline.
+
+     This macro controls how the assembler definitions of uninitialized
+     common global variables are output.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_COMMON (STREAM, NAME, SIZE, ALIGNMENT)
+     Like 'ASM_OUTPUT_COMMON' except takes the required alignment as a
+     separate, explicit argument.  If you define this macro, it is used
+     in place of 'ASM_OUTPUT_COMMON', and gives you more flexibility in
+     handling the required alignment of the variable.  The alignment is
+     specified as the number of bits.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_DECL_COMMON (STREAM, DECL, NAME, SIZE,
+          ALIGNMENT)
+     Like 'ASM_OUTPUT_ALIGNED_COMMON' except that DECL of the variable
+     to be output, if there is one, or 'NULL_TREE' if there is no
+     corresponding variable.  If you define this macro, GCC will use it
+     in place of both 'ASM_OUTPUT_COMMON' and
+     'ASM_OUTPUT_ALIGNED_COMMON'.  Define this macro when you need to
+     see the variable's decl in order to chose what to output.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_BSS (STREAM, DECL, NAME, SIZE, ALIGNMENT)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     the assembler definition of uninitialized global DECL named NAME
+     whose size is SIZE bytes.  The variable ALIGNMENT is the alignment
+     specified as the number of bits.
+
+     Try to use function 'asm_output_aligned_bss' defined in file
+     'varasm.c' when defining this macro.  If unable, use the expression
+     'assemble_name (STREAM, NAME)' to output the name itself; before
+     and after that, output the additional assembler syntax for defining
+     the name, and a newline.
+
+     There are two ways of handling global BSS.  One is to define this
+     macro.  The other is to have 'TARGET_ASM_SELECT_SECTION' return a
+     switchable BSS section (*note
+     TARGET_HAVE_SWITCHABLE_BSS_SECTIONS::).  You do not need to do
+     both.
+
+     Some languages do not have 'common' data, and require a non-common
+     form of global BSS in order to handle uninitialized globals
+     efficiently.  C++ is one example of this.  However, if the target
+     does not support global BSS, the front end may choose to make
+     globals common in order to save space in the object file.
+
+ -- Macro: ASM_OUTPUT_LOCAL (STREAM, NAME, SIZE, ROUNDED)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     the assembler definition of a local-common-label named NAME whose
+     size is SIZE bytes.  The variable ROUNDED is the size rounded up to
+     whatever alignment the caller wants.
+
+     Use the expression 'assemble_name (STREAM, NAME)' to output the
+     name itself; before and after that, output the additional assembler
+     syntax for defining the name, and a newline.
+
+     This macro controls how the assembler definitions of uninitialized
+     static variables are output.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_LOCAL (STREAM, NAME, SIZE, ALIGNMENT)
+     Like 'ASM_OUTPUT_LOCAL' except takes the required alignment as a
+     separate, explicit argument.  If you define this macro, it is used
+     in place of 'ASM_OUTPUT_LOCAL', and gives you more flexibility in
+     handling the required alignment of the variable.  The alignment is
+     specified as the number of bits.
+
+ -- Macro: ASM_OUTPUT_ALIGNED_DECL_LOCAL (STREAM, DECL, NAME, SIZE,
+          ALIGNMENT)
+     Like 'ASM_OUTPUT_ALIGNED_DECL' except that DECL of the variable to
+     be output, if there is one, or 'NULL_TREE' if there is no
+     corresponding variable.  If you define this macro, GCC will use it
+     in place of both 'ASM_OUTPUT_DECL' and 'ASM_OUTPUT_ALIGNED_DECL'.
+     Define this macro when you need to see the variable's decl in order
+     to chose what to output.
+
+
+File: gccint.info,  Node: Label Output,  Next: Initialization,  Prev: Uninitialized Data,  Up: Assembler Format
+
+17.21.4 Output and Generation of Labels
+---------------------------------------
+
+This is about outputting labels.
+
+ -- Macro: ASM_OUTPUT_LABEL (STREAM, NAME)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     the assembler definition of a label named NAME.  Use the expression
+     'assemble_name (STREAM, NAME)' to output the name itself; before
+     and after that, output the additional assembler syntax for defining
+     the name, and a newline.  A default definition of this macro is
+     provided which is correct for most systems.
+
+ -- Macro: ASM_OUTPUT_FUNCTION_LABEL (STREAM, NAME, DECL)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     the assembler definition of a label named NAME of a function.  Use
+     the expression 'assemble_name (STREAM, NAME)' to output the name
+     itself; before and after that, output the additional assembler
+     syntax for defining the name, and a newline.  A default definition
+     of this macro is provided which is correct for most systems.
+
+     If this macro is not defined, then the function name is defined in
+     the usual manner as a label (by means of 'ASM_OUTPUT_LABEL').
+
+ -- Macro: ASM_OUTPUT_INTERNAL_LABEL (STREAM, NAME)
+     Identical to 'ASM_OUTPUT_LABEL', except that NAME is known to refer
+     to a compiler-generated label.  The default definition uses
+     'assemble_name_raw', which is like 'assemble_name' except that it
+     is more efficient.
+
+ -- Macro: SIZE_ASM_OP
+     A C string containing the appropriate assembler directive to
+     specify the size of a symbol, without any arguments.  On systems
+     that use ELF, the default (in 'config/elfos.h') is '"\t.size\t"';
+     on other systems, the default is not to define this macro.
+
+     Define this macro only if it is correct to use the default
+     definitions of 'ASM_OUTPUT_SIZE_DIRECTIVE' and
+     'ASM_OUTPUT_MEASURED_SIZE' for your system.  If you need your own
+     custom definitions of those macros, or if you do not need explicit
+     symbol sizes at all, do not define this macro.
+
+ -- Macro: ASM_OUTPUT_SIZE_DIRECTIVE (STREAM, NAME, SIZE)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     a directive telling the assembler that the size of the symbol NAME
+     is SIZE.  SIZE is a 'HOST_WIDE_INT'.  If you define 'SIZE_ASM_OP',
+     a default definition of this macro is provided.
+
+ -- Macro: ASM_OUTPUT_MEASURED_SIZE (STREAM, NAME)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     a directive telling the assembler to calculate the size of the
+     symbol NAME by subtracting its address from the current address.
+
+     If you define 'SIZE_ASM_OP', a default definition of this macro is
+     provided.  The default assumes that the assembler recognizes a
+     special '.' symbol as referring to the current address, and can
+     calculate the difference between this and another symbol.  If your
+     assembler does not recognize '.' or cannot do calculations with it,
+     you will need to redefine 'ASM_OUTPUT_MEASURED_SIZE' to use some
+     other technique.
+
+ -- Macro: NO_DOLLAR_IN_LABEL
+     Define this macro if the assembler does not accept the character
+     '$' in label names.  By default constructors and destructors in G++
+     have '$' in the identifiers.  If this macro is defined, '.' is used
+     instead.
+
+ -- Macro: NO_DOT_IN_LABEL
+     Define this macro if the assembler does not accept the character
+     '.' in label names.  By default constructors and destructors in G++
+     have names that use '.'.  If this macro is defined, these names are
+     rewritten to avoid '.'.
+
+ -- Macro: TYPE_ASM_OP
+     A C string containing the appropriate assembler directive to
+     specify the type of a symbol, without any arguments.  On systems
+     that use ELF, the default (in 'config/elfos.h') is '"\t.type\t"';
+     on other systems, the default is not to define this macro.
+
+     Define this macro only if it is correct to use the default
+     definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system.  If you
+     need your own custom definition of this macro, or if you do not
+     need explicit symbol types at all, do not define this macro.
+
+ -- Macro: TYPE_OPERAND_FMT
+     A C string which specifies (using 'printf' syntax) the format of
+     the second operand to 'TYPE_ASM_OP'.  On systems that use ELF, the
+     default (in 'config/elfos.h') is '"@%s"'; on other systems, the
+     default is not to define this macro.
+
+     Define this macro only if it is correct to use the default
+     definition of 'ASM_OUTPUT_TYPE_DIRECTIVE' for your system.  If you
+     need your own custom definition of this macro, or if you do not
+     need explicit symbol types at all, do not define this macro.
+
+ -- Macro: ASM_OUTPUT_TYPE_DIRECTIVE (STREAM, TYPE)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     a directive telling the assembler that the type of the symbol NAME
+     is TYPE.  TYPE is a C string; currently, that string is always
+     either '"function"' or '"object"', but you should not count on
+     this.
+
+     If you define 'TYPE_ASM_OP' and 'TYPE_OPERAND_FMT', a default
+     definition of this macro is provided.
+
+ -- Macro: ASM_DECLARE_FUNCTION_NAME (STREAM, NAME, DECL)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     any text necessary for declaring the name NAME of a function which
+     is being defined.  This macro is responsible for outputting the
+     label definition (perhaps using 'ASM_OUTPUT_FUNCTION_LABEL').  The
+     argument DECL is the 'FUNCTION_DECL' tree node representing the
+     function.
+
+     If this macro is not defined, then the function name is defined in
+     the usual manner as a label (by means of
+     'ASM_OUTPUT_FUNCTION_LABEL').
+
+     You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in the definition
+     of this macro.
+
+ -- Macro: ASM_DECLARE_FUNCTION_SIZE (STREAM, NAME, DECL)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     any text necessary for declaring the size of a function which is
+     being defined.  The argument NAME is the name of the function.  The
+     argument DECL is the 'FUNCTION_DECL' tree node representing the
+     function.
+
+     If this macro is not defined, then the function size is not
+     defined.
+
+     You may wish to use 'ASM_OUTPUT_MEASURED_SIZE' in the definition of
+     this macro.
+
+ -- Macro: ASM_DECLARE_OBJECT_NAME (STREAM, NAME, DECL)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     any text necessary for declaring the name NAME of an initialized
+     variable which is being defined.  This macro must output the label
+     definition (perhaps using 'ASM_OUTPUT_LABEL').  The argument DECL
+     is the 'VAR_DECL' tree node representing the variable.
+
+     If this macro is not defined, then the variable name is defined in
+     the usual manner as a label (by means of 'ASM_OUTPUT_LABEL').
+
+     You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' and/or
+     'ASM_OUTPUT_SIZE_DIRECTIVE' in the definition of this macro.
+
+ -- Target Hook: void TARGET_ASM_DECLARE_CONSTANT_NAME (FILE *FILE,
+          const char *NAME, const_tree EXPR, HOST_WIDE_INT SIZE)
+     A target hook to output to the stdio stream FILE any text necessary
+     for declaring the name NAME of a constant which is being defined.
+     This target hook is responsible for outputting the label definition
+     (perhaps using 'assemble_label').  The argument EXP is the value of
+     the constant, and SIZE is the size of the constant in bytes.  The
+     NAME will be an internal label.
+
+     The default version of this target hook, define the NAME in the
+     usual manner as a label (by means of 'assemble_label').
+
+     You may wish to use 'ASM_OUTPUT_TYPE_DIRECTIVE' in this target
+     hook.
+
+ -- Macro: ASM_DECLARE_REGISTER_GLOBAL (STREAM, DECL, REGNO, NAME)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     any text necessary for claiming a register REGNO for a global
+     variable DECL with name NAME.
+
+     If you don't define this macro, that is equivalent to defining it
+     to do nothing.
+
+ -- Macro: ASM_FINISH_DECLARE_OBJECT (STREAM, DECL, TOPLEVEL, ATEND)
+     A C statement (sans semicolon) to finish up declaring a variable
+     name once the compiler has processed its initializer fully and thus
+     has had a chance to determine the size of an array when controlled
+     by an initializer.  This is used on systems where it's necessary to
+     declare something about the size of the object.
+
+     If you don't define this macro, that is equivalent to defining it
+     to do nothing.
+
+     You may wish to use 'ASM_OUTPUT_SIZE_DIRECTIVE' and/or
+     'ASM_OUTPUT_MEASURED_SIZE' in the definition of this macro.
+
+ -- Target Hook: void TARGET_ASM_GLOBALIZE_LABEL (FILE *STREAM, const
+          char *NAME)
+     This target hook is a function to output to the stdio stream STREAM
+     some commands that will make the label NAME global; that is,
+     available for reference from other files.
+
+     The default implementation relies on a proper definition of
+     'GLOBAL_ASM_OP'.
+
+ -- Target Hook: void TARGET_ASM_GLOBALIZE_DECL_NAME (FILE *STREAM, tree
+          DECL)
+     This target hook is a function to output to the stdio stream STREAM
+     some commands that will make the name associated with DECL global;
+     that is, available for reference from other files.
+
+     The default implementation uses the TARGET_ASM_GLOBALIZE_LABEL
+     target hook.
+
+ -- Macro: ASM_WEAKEN_LABEL (STREAM, NAME)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     some commands that will make the label NAME weak; that is,
+     available for reference from other files but only used if no other
+     definition is available.  Use the expression 'assemble_name
+     (STREAM, NAME)' to output the name itself; before and after that,
+     output the additional assembler syntax for making that name weak,
+     and a newline.
+
+     If you don't define this macro or 'ASM_WEAKEN_DECL', GCC will not
+     support weak symbols and you should not define the 'SUPPORTS_WEAK'
+     macro.
+
+ -- Macro: ASM_WEAKEN_DECL (STREAM, DECL, NAME, VALUE)
+     Combines (and replaces) the function of 'ASM_WEAKEN_LABEL' and
+     'ASM_OUTPUT_WEAK_ALIAS', allowing access to the associated function
+     or variable decl.  If VALUE is not 'NULL', this C statement should
+     output to the stdio stream STREAM assembler code which defines
+     (equates) the weak symbol NAME to have the value VALUE.  If VALUE
+     is 'NULL', it should output commands to make NAME weak.
+
+ -- Macro: ASM_OUTPUT_WEAKREF (STREAM, DECL, NAME, VALUE)
+     Outputs a directive that enables NAME to be used to refer to symbol
+     VALUE with weak-symbol semantics.  'decl' is the declaration of
+     'name'.
+
+ -- Macro: SUPPORTS_WEAK
+     A preprocessor constant expression which evaluates to true if the
+     target supports weak symbols.
+
+     If you don't define this macro, 'defaults.h' provides a default
+     definition.  If either 'ASM_WEAKEN_LABEL' or 'ASM_WEAKEN_DECL' is
+     defined, the default definition is '1'; otherwise, it is '0'.
+
+ -- Macro: TARGET_SUPPORTS_WEAK
+     A C expression which evaluates to true if the target supports weak
+     symbols.
+
+     If you don't define this macro, 'defaults.h' provides a default
+     definition.  The default definition is '(SUPPORTS_WEAK)'.  Define
+     this macro if you want to control weak symbol support with a
+     compiler flag such as '-melf'.
+
+ -- Macro: MAKE_DECL_ONE_ONLY (DECL)
+     A C statement (sans semicolon) to mark DECL to be emitted as a
+     public symbol such that extra copies in multiple translation units
+     will be discarded by the linker.  Define this macro if your object
+     file format provides support for this concept, such as the 'COMDAT'
+     section flags in the Microsoft Windows PE/COFF format, and this
+     support requires changes to DECL, such as putting it in a separate
+     section.
+
+ -- Macro: SUPPORTS_ONE_ONLY
+     A C expression which evaluates to true if the target supports
+     one-only semantics.
+
+     If you don't define this macro, 'varasm.c' provides a default
+     definition.  If 'MAKE_DECL_ONE_ONLY' is defined, the default
+     definition is '1'; otherwise, it is '0'.  Define this macro if you
+     want to control one-only symbol support with a compiler flag, or if
+     setting the 'DECL_ONE_ONLY' flag is enough to mark a declaration to
+     be emitted as one-only.
+
+ -- Target Hook: void TARGET_ASM_ASSEMBLE_VISIBILITY (tree DECL, int
+          VISIBILITY)
+     This target hook is a function to output to ASM_OUT_FILE some
+     commands that will make the symbol(s) associated with DECL have
+     hidden, protected or internal visibility as specified by
+     VISIBILITY.
+
+ -- Macro: TARGET_WEAK_NOT_IN_ARCHIVE_TOC
+     A C expression that evaluates to true if the target's linker
+     expects that weak symbols do not appear in a static archive's table
+     of contents.  The default is '0'.
+
+     Leaving weak symbols out of an archive's table of contents means
+     that, if a symbol will only have a definition in one translation
+     unit and will have undefined references from other translation
+     units, that symbol should not be weak.  Defining this macro to be
+     nonzero will thus have the effect that certain symbols that would
+     normally be weak (explicit template instantiations, and vtables for
+     polymorphic classes with noninline key methods) will instead be
+     nonweak.
+
+     The C++ ABI requires this macro to be zero.  Define this macro for
+     targets where full C++ ABI compliance is impossible and where
+     linker restrictions require weak symbols to be left out of a static
+     archive's table of contents.
+
+ -- Macro: ASM_OUTPUT_EXTERNAL (STREAM, DECL, NAME)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     any text necessary for declaring the name of an external symbol
+     named NAME which is referenced in this compilation but not defined.
+     The value of DECL is the tree node for the declaration.
+
+     This macro need not be defined if it does not need to output
+     anything.  The GNU assembler and most Unix assemblers don't require
+     anything.
+
+ -- Target Hook: void TARGET_ASM_EXTERNAL_LIBCALL (rtx SYMREF)
+     This target hook is a function to output to ASM_OUT_FILE an
+     assembler pseudo-op to declare a library function name external.
+     The name of the library function is given by SYMREF, which is a
+     'symbol_ref'.
+
+ -- Target Hook: void TARGET_ASM_MARK_DECL_PRESERVED (const char
+          *SYMBOL)
+     This target hook is a function to output to ASM_OUT_FILE an
+     assembler directive to annotate SYMBOL as used.  The Darwin target
+     uses the .no_dead_code_strip directive.
+
+ -- Macro: ASM_OUTPUT_LABELREF (STREAM, NAME)
+     A C statement (sans semicolon) to output to the stdio stream STREAM
+     a reference in assembler syntax to a label named NAME.  This should
+     add '_' to the front of the name, if that is customary on your
+     operating system, as it is in most Berkeley Unix systems.  This
+     macro is used in 'assemble_name'.
+
+ -- Target Hook: tree TARGET_MANGLE_ASSEMBLER_NAME (const char *NAME)
+     Given a symbol NAME, perform same mangling as 'varasm.c''s
+     'assemble_name', but in memory rather than to a file stream,
+     returning result as an 'IDENTIFIER_NODE'.  Required for correct LTO
+     symtabs.  The default implementation calls the
+     'TARGET_STRIP_NAME_ENCODING' hook and then prepends the
+     'USER_LABEL_PREFIX', if any.
+
+ -- Macro: ASM_OUTPUT_SYMBOL_REF (STREAM, SYM)
+     A C statement (sans semicolon) to output a reference to
+     'SYMBOL_REF' SYM.  If not defined, 'assemble_name' will be used to
+     output the name of the symbol.  This macro may be used to modify
+     the way a symbol is referenced depending on information encoded by
+     'TARGET_ENCODE_SECTION_INFO'.
+
+ -- Macro: ASM_OUTPUT_LABEL_REF (STREAM, BUF)
+     A C statement (sans semicolon) to output a reference to BUF, the
+     result of 'ASM_GENERATE_INTERNAL_LABEL'.  If not defined,
+     'assemble_name' will be used to output the name of the symbol.
+     This macro is not used by 'output_asm_label', or the '%l' specifier
+     that calls it; the intention is that this macro should be set when
+     it is necessary to output a label differently when its address is
+     being taken.
+
+ -- Target Hook: void TARGET_ASM_INTERNAL_LABEL (FILE *STREAM, const
+          char *PREFIX, unsigned long LABELNO)
+     A function to output to the stdio stream STREAM a label whose name
+     is made from the string PREFIX and the number LABELNO.
+
+     It is absolutely essential that these labels be distinct from the
+     labels used for user-level functions and variables.  Otherwise,
+     certain programs will have name conflicts with internal labels.
+
+     It is desirable to exclude internal labels from the symbol table of
+     the object file.  Most assemblers have a naming convention for
+     labels that should be excluded; on many systems, the letter 'L' at
+     the beginning of a label has this effect.  You should find out what
+     convention your system uses, and follow it.
+
+     The default version of this function utilizes
+     'ASM_GENERATE_INTERNAL_LABEL'.
+
+ -- Macro: ASM_OUTPUT_DEBUG_LABEL (STREAM, PREFIX, NUM)
+     A C statement to output to the stdio stream STREAM a debug info
+     label whose name is made from the string PREFIX and the number NUM.
+     This is useful for VLIW targets, where debug info labels may need
+     to be treated differently than branch target labels.  On some
+     systems, branch target labels must be at the beginning of
+     instruction bundles, but debug info labels can occur in the middle
+     of instruction bundles.
+
+     If this macro is not defined, then
+     '(*targetm.asm_out.internal_label)' will be used.
+
+ -- Macro: ASM_GENERATE_INTERNAL_LABEL (STRING, PREFIX, NUM)
+     A C statement to store into the string STRING a label whose name is
+     made from the string PREFIX and the number NUM.
+
+     This string, when output subsequently by 'assemble_name', should
+     produce the output that '(*targetm.asm_out.internal_label)' would
+     produce with the same PREFIX and NUM.
+
+     If the string begins with '*', then 'assemble_name' will output the
+     rest of the string unchanged.  It is often convenient for
+     'ASM_GENERATE_INTERNAL_LABEL' to use '*' in this way.  If the
+     string doesn't start with '*', then 'ASM_OUTPUT_LABELREF' gets to
+     output the string, and may change it.  (Of course,
+     'ASM_OUTPUT_LABELREF' is also part of your machine description, so
+     you should know what it does on your machine.)
+
+ -- Macro: ASM_FORMAT_PRIVATE_NAME (OUTVAR, NAME, NUMBER)
+     A C expression to assign to OUTVAR (which is a variable of type
+     'char *') a newly allocated string made from the string NAME and
+     the number NUMBER, with some suitable punctuation added.  Use
+     'alloca' to get space for the string.
+
+     The string will be used as an argument to 'ASM_OUTPUT_LABELREF' to
+     produce an assembler label for an internal static variable whose
+     name is NAME.  Therefore, the string must be such as to result in
+     valid assembler code.  The argument NUMBER is different each time
+     this macro is executed; it prevents conflicts between
+     similarly-named internal static variables in different scopes.
+
+     Ideally this string should not be a valid C identifier, to prevent
+     any conflict with the user's own symbols.  Most assemblers allow
+     periods or percent signs in assembler symbols; putting at least one
+     of these between the name and the number will suffice.
+
+     If this macro is not defined, a default definition will be provided
+     which is correct for most systems.
+
+ -- Macro: ASM_OUTPUT_DEF (STREAM, NAME, VALUE)
+     A C statement to output to the stdio stream STREAM assembler code
+     which defines (equates) the symbol NAME to have the value VALUE.
+
+     If 'SET_ASM_OP' is defined, a default definition is provided which
+     is correct for most systems.
+
+ -- Macro: ASM_OUTPUT_DEF_FROM_DECLS (STREAM, DECL_OF_NAME,
+          DECL_OF_VALUE)
+     A C statement to output to the stdio stream STREAM assembler code
+     which defines (equates) the symbol whose tree node is DECL_OF_NAME
+     to have the value of the tree node DECL_OF_VALUE.  This macro will
+     be used in preference to 'ASM_OUTPUT_DEF' if it is defined and if
+     the tree nodes are available.
+
+     If 'SET_ASM_OP' is defined, a default definition is provided which
+     is correct for most systems.
+
+ -- Macro: TARGET_DEFERRED_OUTPUT_DEFS (DECL_OF_NAME, DECL_OF_VALUE)
+     A C statement that evaluates to true if the assembler code which
+     defines (equates) the symbol whose tree node is DECL_OF_NAME to
+     have the value of the tree node DECL_OF_VALUE should be emitted
+     near the end of the current compilation unit.  The default is to
+     not defer output of defines.  This macro affects defines output by
+     'ASM_OUTPUT_DEF' and 'ASM_OUTPUT_DEF_FROM_DECLS'.
+
+ -- Macro: ASM_OUTPUT_WEAK_ALIAS (STREAM, NAME, VALUE)
+     A C statement to output to the stdio stream STREAM assembler code
+     which defines (equates) the weak symbol NAME to have the value
+     VALUE.  If VALUE is 'NULL', it defines NAME as an undefined weak
+     symbol.
+
+     Define this macro if the target only supports weak aliases; define
+     'ASM_OUTPUT_DEF' instead if possible.
+
+ -- Macro: OBJC_GEN_METHOD_LABEL (BUF, IS_INST, CLASS_NAME, CAT_NAME,
+          SEL_NAME)
+     Define this macro to override the default assembler names used for
+     Objective-C methods.
+
+     The default name is a unique method number followed by the name of
+     the class (e.g. '_1_Foo').  For methods in categories, the name of
+     the category is also included in the assembler name (e.g.
+     '_1_Foo_Bar').
+
+     These names are safe on most systems, but make debugging difficult
+     since the method's selector is not present in the name.  Therefore,
+     particular systems define other ways of computing names.
+
+     BUF is an expression of type 'char *' which gives you a buffer in
+     which to store the name; its length is as long as CLASS_NAME,
+     CAT_NAME and SEL_NAME put together, plus 50 characters extra.
+
+     The argument IS_INST specifies whether the method is an instance
+     method or a class method; CLASS_NAME is the name of the class;
+     CAT_NAME is the name of the category (or 'NULL' if the method is
+     not in a category); and SEL_NAME is the name of the selector.
+
+     On systems where the assembler can handle quoted names, you can use
+     this macro to provide more human-readable names.
+
+
+File: gccint.info,  Node: Initialization,  Next: Macros for Initialization,  Prev: Label Output,  Up: Assembler Format
+
+17.21.5 How Initialization Functions Are Handled
+------------------------------------------------
+
+The compiled code for certain languages includes "constructors" (also
+called "initialization routines")--functions to initialize data in the
+program when the program is started.  These functions need to be called
+before the program is "started"--that is to say, before 'main' is
+called.
+
+ Compiling some languages generates "destructors" (also called
+"termination routines") that should be called when the program
+terminates.
+
+ To make the initialization and termination functions work, the compiler
+must output something in the assembler code to cause those functions to
+be called at the appropriate time.  When you port the compiler to a new
+system, you need to specify how to do this.
+
+ There are two major ways that GCC currently supports the execution of
+initialization and termination functions.  Each way has two variants.
+Much of the structure is common to all four variations.
+
+ The linker must build two lists of these functions--a list of
+initialization functions, called '__CTOR_LIST__', and a list of
+termination functions, called '__DTOR_LIST__'.
+
+ Each list always begins with an ignored function pointer (which may
+hold 0, -1, or a count of the function pointers after it, depending on
+the environment).  This is followed by a series of zero or more function
+pointers to constructors (or destructors), followed by a function
+pointer containing zero.
+
+ Depending on the operating system and its executable file format,
+either 'crtstuff.c' or 'libgcc2.c' traverses these lists at startup time
+and exit time.  Constructors are called in reverse order of the list;
+destructors in forward order.
+
+ The best way to handle static constructors works only for object file
+formats which provide arbitrarily-named sections.  A section is set
+aside for a list of constructors, and another for a list of destructors.
+Traditionally these are called '.ctors' and '.dtors'.  Each object file
+that defines an initialization function also puts a word in the
+constructor section to point to that function.  The linker accumulates
+all these words into one contiguous '.ctors' section.  Termination
+functions are handled similarly.
+
+ This method will be chosen as the default by 'target-def.h' if
+'TARGET_ASM_NAMED_SECTION' is defined.  A target that does not support
+arbitrary sections, but does support special designated constructor and
+destructor sections may define 'CTORS_SECTION_ASM_OP' and
+'DTORS_SECTION_ASM_OP' to achieve the same effect.
+
+ When arbitrary sections are available, there are two variants,
+depending upon how the code in 'crtstuff.c' is called.  On systems that
+support a ".init" section which is executed at program startup, parts of
+'crtstuff.c' are compiled into that section.  The program is linked by
+the 'gcc' driver like this:
+
+     ld -o OUTPUT_FILE crti.o crtbegin.o ... -lgcc crtend.o crtn.o
+
+ The prologue of a function ('__init') appears in the '.init' section of
+'crti.o'; the epilogue appears in 'crtn.o'.  Likewise for the function
+'__fini' in the ".fini" section.  Normally these files are provided by
+the operating system or by the GNU C library, but are provided by GCC
+for a few targets.
+
+ The objects 'crtbegin.o' and 'crtend.o' are (for most targets) compiled
+from 'crtstuff.c'.  They contain, among other things, code fragments
+within the '.init' and '.fini' sections that branch to routines in the
+'.text' section.  The linker will pull all parts of a section together,
+which results in a complete '__init' function that invokes the routines
+we need at startup.
+
+ To use this variant, you must define the 'INIT_SECTION_ASM_OP' macro
+properly.
+
+ If no init section is available, when GCC compiles any function called
+'main' (or more accurately, any function designated as a program entry
+point by the language front end calling 'expand_main_function'), it
+inserts a procedure call to '__main' as the first executable code after
+the function prologue.  The '__main' function is defined in 'libgcc2.c'
+and runs the global constructors.
+
+ In file formats that don't support arbitrary sections, there are again
+two variants.  In the simplest variant, the GNU linker (GNU 'ld') and an
+'a.out' format must be used.  In this case, 'TARGET_ASM_CONSTRUCTOR' is
+defined to produce a '.stabs' entry of type 'N_SETT', referencing the
+name '__CTOR_LIST__', and with the address of the void function
+containing the initialization code as its value.  The GNU linker
+recognizes this as a request to add the value to a "set"; the values are
+accumulated, and are eventually placed in the executable as a vector in
+the format described above, with a leading (ignored) count and a
+trailing zero element.  'TARGET_ASM_DESTRUCTOR' is handled similarly.
+Since no init section is available, the absence of 'INIT_SECTION_ASM_OP'
+causes the compilation of 'main' to call '__main' as above, starting the
+initialization process.
+
+ The last variant uses neither arbitrary sections nor the GNU linker.
+This is preferable when you want to do dynamic linking and when using
+file formats which the GNU linker does not support, such as 'ECOFF'.  In
+this case, 'TARGET_HAVE_CTORS_DTORS' is false, initialization and
+termination functions are recognized simply by their names.  This
+requires an extra program in the linkage step, called 'collect2'.  This
+program pretends to be the linker, for use with GCC; it does its job by
+running the ordinary linker, but also arranges to include the vectors of
+initialization and termination functions.  These functions are called
+via '__main' as described above.  In order to use this method,
+'use_collect2' must be defined in the target in 'config.gcc'.
+
+ The following section describes the specific macros that control and
+customize the handling of initialization and termination functions.
+
+
+File: gccint.info,  Node: Macros for Initialization,  Next: Instruction Output,  Prev: Initialization,  Up: Assembler Format
+
+17.21.6 Macros Controlling Initialization Routines
+--------------------------------------------------
+
+Here are the macros that control how the compiler handles initialization
+and termination functions:
+
+ -- Macro: INIT_SECTION_ASM_OP
+     If defined, a C string constant, including spacing, for the
+     assembler operation to identify the following data as
+     initialization code.  If not defined, GCC will assume such a
+     section does not exist.  When you are using special sections for
+     initialization and termination functions, this macro also controls
+     how 'crtstuff.c' and 'libgcc2.c' arrange to run the initialization
+     functions.
+
+ -- Macro: HAS_INIT_SECTION
+     If defined, 'main' will not call '__main' as described above.  This
+     macro should be defined for systems that control start-up code on a
+     symbol-by-symbol basis, such as OSF/1, and should not be defined
+     explicitly for systems that support 'INIT_SECTION_ASM_OP'.
+
+ -- Macro: LD_INIT_SWITCH
+     If defined, a C string constant for a switch that tells the linker
+     that the following symbol is an initialization routine.
+
+ -- Macro: LD_FINI_SWITCH
+     If defined, a C string constant for a switch that tells the linker
+     that the following symbol is a finalization routine.
+
+ -- Macro: COLLECT_SHARED_INIT_FUNC (STREAM, FUNC)
+     If defined, a C statement that will write a function that can be
+     automatically called when a shared library is loaded.  The function
+     should call FUNC, which takes no arguments.  If not defined, and
+     the object format requires an explicit initialization function,
+     then a function called '_GLOBAL__DI' will be generated.
+
+     This function and the following one are used by collect2 when
+     linking a shared library that needs constructors or destructors, or
+     has DWARF2 exception tables embedded in the code.
+
+ -- Macro: COLLECT_SHARED_FINI_FUNC (STREAM, FUNC)
+     If defined, a C statement that will write a function that can be
+     automatically called when a shared library is unloaded.  The
+     function should call FUNC, which takes no arguments.  If not
+     defined, and the object format requires an explicit finalization
+     function, then a function called '_GLOBAL__DD' will be generated.
+
+ -- Macro: INVOKE__main
+     If defined, 'main' will call '__main' despite the presence of
+     'INIT_SECTION_ASM_OP'.  This macro should be defined for systems
+     where the init section is not actually run automatically, but is
+     still useful for collecting the lists of constructors and
+     destructors.
+
+ -- Macro: SUPPORTS_INIT_PRIORITY
+     If nonzero, the C++ 'init_priority' attribute is supported and the
+     compiler should emit instructions to control the order of
+     initialization of objects.  If zero, the compiler will issue an
+     error message upon encountering an 'init_priority' attribute.
+
+ -- Target Hook: bool TARGET_HAVE_CTORS_DTORS
+     This value is true if the target supports some "native" method of
+     collecting constructors and destructors to be run at startup and
+     exit.  It is false if we must use 'collect2'.
+
+ -- Target Hook: void TARGET_ASM_CONSTRUCTOR (rtx SYMBOL, int PRIORITY)
+     If defined, a function that outputs assembler code to arrange to
+     call the function referenced by SYMBOL at initialization time.
+
+     Assume that SYMBOL is a 'SYMBOL_REF' for a function taking no
+     arguments and with no return value.  If the target supports
+     initialization priorities, PRIORITY is a value between 0 and
+     'MAX_INIT_PRIORITY'; otherwise it must be 'DEFAULT_INIT_PRIORITY'.
+
+     If this macro is not defined by the target, a suitable default will
+     be chosen if (1) the target supports arbitrary section names, (2)
+     the target defines 'CTORS_SECTION_ASM_OP', or (3) 'USE_COLLECT2' is
+     not defined.
+
+ -- Target Hook: void TARGET_ASM_DESTRUCTOR (rtx SYMBOL, int PRIORITY)
+     This is like 'TARGET_ASM_CONSTRUCTOR' but used for termination
+     functions rather than initialization functions.
+
+ If 'TARGET_HAVE_CTORS_DTORS' is true, the initialization routine
+generated for the generated object file will have static linkage.
+
+ If your system uses 'collect2' as the means of processing constructors,
+then that program normally uses 'nm' to scan an object file for
+constructor functions to be called.
+
+ On certain kinds of systems, you can define this macro to make
+'collect2' work faster (and, in some cases, make it work at all):
+
+ -- Macro: OBJECT_FORMAT_COFF
+     Define this macro if the system uses COFF (Common Object File
+     Format) object files, so that 'collect2' can assume this format and
+     scan object files directly for dynamic constructor/destructor
+     functions.
+
+     This macro is effective only in a native compiler; 'collect2' as
+     part of a cross compiler always uses 'nm' for the target machine.
+
+ -- Macro: REAL_NM_FILE_NAME
+     Define this macro as a C string constant containing the file name
+     to use to execute 'nm'.  The default is to search the path normally
+     for 'nm'.
+
+ -- Macro: NM_FLAGS
+     'collect2' calls 'nm' to scan object files for static constructors
+     and destructors and LTO info.  By default, '-n' is passed.  Define
+     'NM_FLAGS' to a C string constant if other options are needed to
+     get the same output format as GNU 'nm -n' produces.
+
+ If your system supports shared libraries and has a program to list the
+dynamic dependencies of a given library or executable, you can define
+these macros to enable support for running initialization and
+termination functions in shared libraries:
+
+ -- Macro: LDD_SUFFIX
+     Define this macro to a C string constant containing the name of the
+     program which lists dynamic dependencies, like 'ldd' under SunOS 4.
+
+ -- Macro: PARSE_LDD_OUTPUT (PTR)
+     Define this macro to be C code that extracts filenames from the
+     output of the program denoted by 'LDD_SUFFIX'.  PTR is a variable
+     of type 'char *' that points to the beginning of a line of output
+     from 'LDD_SUFFIX'.  If the line lists a dynamic dependency, the
+     code must advance PTR to the beginning of the filename on that
+     line.  Otherwise, it must set PTR to 'NULL'.
+
+ -- Macro: SHLIB_SUFFIX
+     Define this macro to a C string constant containing the default
+     shared library extension of the target (e.g., '".so"').  'collect2'
+     strips version information after this suffix when generating global
+     constructor and destructor names.  This define is only needed on
+     targets that use 'collect2' to process constructors and
+     destructors.
+
+
+File: gccint.info,  Node: Instruction Output,  Next: Dispatch Tables,  Prev: Macros for Initialization,  Up: Assembler Format
+
+17.21.7 Output of Assembler Instructions
+----------------------------------------
+
+This describes assembler instruction output.
+
+ -- Macro: REGISTER_NAMES
+     A C initializer containing the assembler's names for the machine
+     registers, each one as a C string constant.  This is what
+     translates register numbers in the compiler into assembler
+     language.
+
+ -- Macro: ADDITIONAL_REGISTER_NAMES
+     If defined, a C initializer for an array of structures containing a
+     name and a register number.  This macro defines additional names
+     for hard registers, thus allowing the 'asm' option in declarations
+     to refer to registers using alternate names.
+
+ -- Macro: OVERLAPPING_REGISTER_NAMES
+     If defined, a C initializer for an array of structures containing a
+     name, a register number and a count of the number of consecutive
+     machine registers the name overlaps.  This macro defines additional
+     names for hard registers, thus allowing the 'asm' option in
+     declarations to refer to registers using alternate names.  Unlike
+     'ADDITIONAL_REGISTER_NAMES', this macro should be used when the
+     register name implies multiple underlying registers.
+
+     This macro should be used when it is important that a clobber in an
+     'asm' statement clobbers all the underlying values implied by the
+     register name.  For example, on ARM, clobbering the
+     double-precision VFP register "d0" implies clobbering both
+     single-precision registers "s0" and "s1".
+
+ -- Macro: ASM_OUTPUT_OPCODE (STREAM, PTR)
+     Define this macro if you are using an unusual assembler that
+     requires different names for the machine instructions.
+
+     The definition is a C statement or statements which output an
+     assembler instruction opcode to the stdio stream STREAM.  The
+     macro-operand PTR is a variable of type 'char *' which points to
+     the opcode name in its "internal" form--the form that is written in
+     the machine description.  The definition should output the opcode
+     name to STREAM, performing any translation you desire, and
+     increment the variable PTR to point at the end of the opcode so
+     that it will not be output twice.
+
+     In fact, your macro definition may process less than the entire
+     opcode name, or more than the opcode name; but if you want to
+     process text that includes '%'-sequences to substitute operands,
+     you must take care of the substitution yourself.  Just be sure to
+     increment PTR over whatever text should not be output normally.
+
+     If you need to look at the operand values, they can be found as the
+     elements of 'recog_data.operand'.
+
+     If the macro definition does nothing, the instruction is output in
+     the usual way.
+
+ -- Macro: FINAL_PRESCAN_INSN (INSN, OPVEC, NOPERANDS)
+     If defined, a C statement to be executed just prior to the output
+     of assembler code for INSN, to modify the extracted operands so
+     they will be output differently.
+
+     Here the argument OPVEC is the vector containing the operands
+     extracted from INSN, and NOPERANDS is the number of elements of the
+     vector which contain meaningful data for this insn.  The contents
+     of this vector are what will be used to convert the insn template
+     into assembler code, so you can change the assembler output by
+     changing the contents of the vector.
+
+     This macro is useful when various assembler syntaxes share a single
+     file of instruction patterns; by defining this macro differently,
+     you can cause a large class of instructions to be output
+     differently (such as with rearranged operands).  Naturally,
+     variations in assembler syntax affecting individual insn patterns
+     ought to be handled by writing conditional output routines in those
+     patterns.
+
+     If this macro is not defined, it is equivalent to a null statement.
+
+ -- Target Hook: void TARGET_ASM_FINAL_POSTSCAN_INSN (FILE *FILE, rtx
+          INSN, rtx *OPVEC, int NOPERANDS)
+     If defined, this target hook is a function which is executed just
+     after the output of assembler code for INSN, to change the mode of
+     the assembler if necessary.
+
+     Here the argument OPVEC is the vector containing the operands
+     extracted from INSN, and NOPERANDS is the number of elements of the
+     vector which contain meaningful data for this insn.  The contents
+     of this vector are what was used to convert the insn template into
+     assembler code, so you can change the assembler mode by checking
+     the contents of the vector.
+
+ -- Macro: PRINT_OPERAND (STREAM, X, CODE)
+     A C compound statement to output to stdio stream STREAM the
+     assembler syntax for an instruction operand X.  X is an RTL
+     expression.
+
+     CODE is a value that can be used to specify one of several ways of
+     printing the operand.  It is used when identical operands must be
+     printed differently depending on the context.  CODE comes from the
+     '%' specification that was used to request printing of the operand.
+     If the specification was just '%DIGIT' then CODE is 0; if the
+     specification was '%LTR DIGIT' then CODE is the ASCII code for LTR.
+
+     If X is a register, this macro should print the register's name.
+     The names can be found in an array 'reg_names' whose type is 'char
+     *[]'.  'reg_names' is initialized from 'REGISTER_NAMES'.
+
+     When the machine description has a specification '%PUNCT' (a '%'
+     followed by a punctuation character), this macro is called with a
+     null pointer for X and the punctuation character for CODE.
+
+ -- Macro: PRINT_OPERAND_PUNCT_VALID_P (CODE)
+     A C expression which evaluates to true if CODE is a valid
+     punctuation character for use in the 'PRINT_OPERAND' macro.  If
+     'PRINT_OPERAND_PUNCT_VALID_P' is not defined, it means that no
+     punctuation characters (except for the standard one, '%') are used
+     in this way.
+
+ -- Macro: PRINT_OPERAND_ADDRESS (STREAM, X)
+     A C compound statement to output to stdio stream STREAM the
+     assembler syntax for an instruction operand that is a memory
+     reference whose address is X.  X is an RTL expression.
+
+     On some machines, the syntax for a symbolic address depends on the
+     section that the address refers to.  On these machines, define the
+     hook 'TARGET_ENCODE_SECTION_INFO' to store the information into the
+     'symbol_ref', and then check for it here.  *Note Assembler
+     Format::.
+
+ -- Macro: DBR_OUTPUT_SEQEND (FILE)
+     A C statement, to be executed after all slot-filler instructions
+     have been output.  If necessary, call 'dbr_sequence_length' to
+     determine the number of slots filled in a sequence (zero if not
+     currently outputting a sequence), to decide how many no-ops to
+     output, or whatever.
+
+     Don't define this macro if it has nothing to do, but it is helpful
+     in reading assembly output if the extent of the delay sequence is
+     made explicit (e.g. with white space).
+
+ Note that output routines for instructions with delay slots must be
+prepared to deal with not being output as part of a sequence (i.e. when
+the scheduling pass is not run, or when no slot fillers could be found.)
+The variable 'final_sequence' is null when not processing a sequence,
+otherwise it contains the 'sequence' rtx being output.
+
+ -- Macro: REGISTER_PREFIX
+ -- Macro: LOCAL_LABEL_PREFIX
+ -- Macro: USER_LABEL_PREFIX
+ -- Macro: IMMEDIATE_PREFIX
+     If defined, C string expressions to be used for the '%R', '%L',
+     '%U', and '%I' options of 'asm_fprintf' (see 'final.c').  These are
+     useful when a single 'md' file must support multiple assembler
+     formats.  In that case, the various 'tm.h' files can define these
+     macros differently.
+
+ -- Macro: ASM_FPRINTF_EXTENSIONS (FILE, ARGPTR, FORMAT)
+     If defined this macro should expand to a series of 'case'
+     statements which will be parsed inside the 'switch' statement of
+     the 'asm_fprintf' function.  This allows targets to define extra
+     printf formats which may useful when generating their assembler
+     statements.  Note that uppercase letters are reserved for future
+     generic extensions to asm_fprintf, and so are not available to
+     target specific code.  The output file is given by the parameter
+     FILE.  The varargs input pointer is ARGPTR and the rest of the
+     format string, starting the character after the one that is being
+     switched upon, is pointed to by FORMAT.
+
+ -- Macro: ASSEMBLER_DIALECT
+     If your target supports multiple dialects of assembler language
+     (such as different opcodes), define this macro as a C expression
+     that gives the numeric index of the assembler language dialect to
+     use, with zero as the first variant.
+
+     If this macro is defined, you may use constructs of the form
+          '{option0|option1|option2...}'
+     in the output templates of patterns (*note Output Template::) or in
+     the first argument of 'asm_fprintf'.  This construct outputs
+     'option0', 'option1', 'option2', etc., if the value of
+     'ASSEMBLER_DIALECT' is zero, one, two, etc.  Any special characters
+     within these strings retain their usual meaning.  If there are
+     fewer alternatives within the braces than the value of
+     'ASSEMBLER_DIALECT', the construct outputs nothing.  If it's needed
+     to print curly braces or '|' character in assembler output
+     directly, '%{', '%}' and '%|' can be used.
+
+     If you do not define this macro, the characters '{', '|' and '}' do
+     not have any special meaning when used in templates or operands to
+     'asm_fprintf'.
+
+     Define the macros 'REGISTER_PREFIX', 'LOCAL_LABEL_PREFIX',
+     'USER_LABEL_PREFIX' and 'IMMEDIATE_PREFIX' if you can express the
+     variations in assembler language syntax with that mechanism.
+     Define 'ASSEMBLER_DIALECT' and use the '{option0|option1}' syntax
+     if the syntax variant are larger and involve such things as
+     different opcodes or operand order.
+
+ -- Macro: ASM_OUTPUT_REG_PUSH (STREAM, REGNO)
+     A C expression to output to STREAM some assembler code which will
+     push hard register number REGNO onto the stack.  The code need not
+     be optimal, since this macro is used only when profiling.
+
+ -- Macro: ASM_OUTPUT_REG_POP (STREAM, REGNO)
+     A C expression to output to STREAM some assembler code which will
+     pop hard register number REGNO off of the stack.  The code need not
+     be optimal, since this macro is used only when profiling.
+
+
+File: gccint.info,  Node: Dispatch Tables,  Next: Exception Region Output,  Prev: Instruction Output,  Up: Assembler Format
+
+17.21.8 Output of Dispatch Tables
+---------------------------------
+
+This concerns dispatch tables.
+
+ -- Macro: ASM_OUTPUT_ADDR_DIFF_ELT (STREAM, BODY, VALUE, REL)
+     A C statement to output to the stdio stream STREAM an assembler
+     pseudo-instruction to generate a difference between two labels.
+     VALUE and REL are the numbers of two internal labels.  The
+     definitions of these labels are output using
+     '(*targetm.asm_out.internal_label)', and they must be printed in
+     the same way here.  For example,
+
+          fprintf (STREAM, "\t.word L%d-L%d\n",
+                   VALUE, REL)
+
+     You must provide this macro on machines where the addresses in a
+     dispatch table are relative to the table's own address.  If
+     defined, GCC will also use this macro on all machines when
+     producing PIC.  BODY is the body of the 'ADDR_DIFF_VEC'; it is
+     provided so that the mode and flags can be read.
+
+ -- Macro: ASM_OUTPUT_ADDR_VEC_ELT (STREAM, VALUE)
+     This macro should be provided on machines where the addresses in a
+     dispatch table are absolute.
+
+     The definition should be a C statement to output to the stdio
+     stream STREAM an assembler pseudo-instruction to generate a
+     reference to a label.  VALUE is the number of an internal label
+     whose definition is output using
+     '(*targetm.asm_out.internal_label)'.  For example,
+
+          fprintf (STREAM, "\t.word L%d\n", VALUE)
+
+ -- Macro: ASM_OUTPUT_CASE_LABEL (STREAM, PREFIX, NUM, TABLE)
+     Define this if the label before a jump-table needs to be output
+     specially.  The first three arguments are the same as for
+     '(*targetm.asm_out.internal_label)'; the fourth argument is the
+     jump-table which follows (a 'jump_table_data' containing an
+     'addr_vec' or 'addr_diff_vec').
+
+     This feature is used on system V to output a 'swbeg' statement for
+     the table.
+
+     If this macro is not defined, these labels are output with
+     '(*targetm.asm_out.internal_label)'.
+
+ -- Macro: ASM_OUTPUT_CASE_END (STREAM, NUM, TABLE)
+     Define this if something special must be output at the end of a
+     jump-table.  The definition should be a C statement to be executed
+     after the assembler code for the table is written.  It should write
+     the appropriate code to stdio stream STREAM.  The argument TABLE is
+     the jump-table insn, and NUM is the label-number of the preceding
+     label.
+
+     If this macro is not defined, nothing special is output at the end
+     of the jump-table.
+
+ -- Target Hook: void TARGET_ASM_EMIT_UNWIND_LABEL (FILE *STREAM, tree
+          DECL, int FOR_EH, int EMPTY)
+     This target hook emits a label at the beginning of each FDE.  It
+     should be defined on targets where FDEs need special labels, and it
+     should write the appropriate label, for the FDE associated with the
+     function declaration DECL, to the stdio stream STREAM.  The third
+     argument, FOR_EH, is a boolean: true if this is for an exception
+     table.  The fourth argument, EMPTY, is a boolean: true if this is a
+     placeholder label for an omitted FDE.
+
+     The default is that FDEs are not given nonlocal labels.
+
+ -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL (FILE *STREAM)
+     This target hook emits a label at the beginning of the exception
+     table.  It should be defined on targets where it is desirable for
+     the table to be broken up according to function.
+
+     The default is that no label is emitted.
+
+ -- Target Hook: void TARGET_ASM_EMIT_EXCEPT_PERSONALITY (rtx
+          PERSONALITY)
+     If the target implements 'TARGET_ASM_UNWIND_EMIT', this hook may be
+     used to emit a directive to install a personality hook into the
+     unwind info.  This hook should not be used if dwarf2 unwind info is
+     used.
+
+ -- Target Hook: void TARGET_ASM_UNWIND_EMIT (FILE *STREAM, rtx INSN)
+     This target hook emits assembly directives required to unwind the
+     given instruction.  This is only used when
+     'TARGET_EXCEPT_UNWIND_INFO' returns 'UI_TARGET'.
+
+ -- Target Hook: bool TARGET_ASM_UNWIND_EMIT_BEFORE_INSN
+     True if the 'TARGET_ASM_UNWIND_EMIT' hook should be called before
+     the assembly for INSN has been emitted, false if the hook should be
+     called afterward.
+
+
+File: gccint.info,  Node: Exception Region Output,  Next: Alignment Output,  Prev: Dispatch Tables,  Up: Assembler Format
+
+17.21.9 Assembler Commands for Exception Regions
+------------------------------------------------
+
+This describes commands marking the start and the end of an exception
+region.
+
+ -- Macro: EH_FRAME_SECTION_NAME
+     If defined, a C string constant for the name of the section
+     containing exception handling frame unwind information.  If not
+     defined, GCC will provide a default definition if the target
+     supports named sections.  'crtstuff.c' uses this macro to switch to
+     the appropriate section.
+
+     You should define this symbol if your target supports DWARF 2 frame
+     unwind information and the default definition does not work.
+
+ -- Macro: EH_FRAME_IN_DATA_SECTION
+     If defined, DWARF 2 frame unwind information will be placed in the
+     data section even though the target supports named sections.  This
+     might be necessary, for instance, if the system linker does garbage
+     collection and sections cannot be marked as not to be collected.
+
+     Do not define this macro unless 'TARGET_ASM_NAMED_SECTION' is also
+     defined.
+
+ -- Macro: EH_TABLES_CAN_BE_READ_ONLY
+     Define this macro to 1 if your target is such that no frame unwind
+     information encoding used with non-PIC code will ever require a
+     runtime relocation, but the linker may not support merging
+     read-only and read-write sections into a single read-write section.
+
+ -- Macro: MASK_RETURN_ADDR
+     An rtx used to mask the return address found via 'RETURN_ADDR_RTX',
+     so that it does not contain any extraneous set bits in it.
+
+ -- Macro: DWARF2_UNWIND_INFO
+     Define this macro to 0 if your target supports DWARF 2 frame unwind
+     information, but it does not yet work with exception handling.
+     Otherwise, if your target supports this information (if it defines
+     'INCOMING_RETURN_ADDR_RTX' and 'OBJECT_FORMAT_ELF'), GCC will
+     provide a default definition of 1.
+
+ -- Common Target Hook: enum unwind_info_type TARGET_EXCEPT_UNWIND_INFO
+          (struct gcc_options *OPTS)
+     This hook defines the mechanism that will be used for exception
+     handling by the target.  If the target has ABI specified unwind
+     tables, the hook should return 'UI_TARGET'.  If the target is to
+     use the 'setjmp'/'longjmp'-based exception handling scheme, the
+     hook should return 'UI_SJLJ'.  If the target supports DWARF 2 frame
+     unwind information, the hook should return 'UI_DWARF2'.
+
+     A target may, if exceptions are disabled, choose to return
+     'UI_NONE'.  This may end up simplifying other parts of
+     target-specific code.  The default implementation of this hook
+     never returns 'UI_NONE'.
+
+     Note that the value returned by this hook should be constant.  It
+     should not depend on anything except the command-line switches
+     described by OPTS.  In particular, the setting 'UI_SJLJ' must be
+     fixed at compiler start-up as C pre-processor macros and builtin
+     functions related to exception handling are set up depending on
+     this setting.
+
+     The default implementation of the hook first honors the
+     '--enable-sjlj-exceptions' configure option, then
+     'DWARF2_UNWIND_INFO', and finally defaults to 'UI_SJLJ'.  If
+     'DWARF2_UNWIND_INFO' depends on command-line options, the target
+     must define this hook so that OPTS is used correctly.
+
+ -- Common Target Hook: bool TARGET_UNWIND_TABLES_DEFAULT
+     This variable should be set to 'true' if the target ABI requires
+     unwinding tables even when exceptions are not used.  It must not be
+     modified by command-line option processing.
+
+ -- Macro: DONT_USE_BUILTIN_SETJMP
+     Define this macro to 1 if the 'setjmp'/'longjmp'-based scheme
+     should use the 'setjmp'/'longjmp' functions from the C library
+     instead of the '__builtin_setjmp'/'__builtin_longjmp' machinery.
+
+ -- Macro: JMP_BUF_SIZE
+     This macro has no effect unless 'DONT_USE_BUILTIN_SETJMP' is also
+     defined.  Define this macro if the default size of 'jmp_buf' buffer
+     for the 'setjmp'/'longjmp'-based exception handling mechanism is
+     not large enough, or if it is much too large.  The default size is
+     'FIRST_PSEUDO_REGISTER * sizeof(void *)'.
+
+ -- Macro: DWARF_CIE_DATA_ALIGNMENT
+     This macro need only be defined if the target might save registers
+     in the function prologue at an offset to the stack pointer that is
+     not aligned to 'UNITS_PER_WORD'.  The definition should be the
+     negative minimum alignment if 'STACK_GROWS_DOWNWARD' is defined,
+     and the positive minimum alignment otherwise.  *Note SDB and
+     DWARF::.  Only applicable if the target supports DWARF 2 frame
+     unwind information.
+
+ -- Target Hook: bool TARGET_TERMINATE_DW2_EH_FRAME_INFO
+     Contains the value true if the target should add a zero word onto
+     the end of a Dwarf-2 frame info section when used for exception
+     handling.  Default value is false if 'EH_FRAME_SECTION_NAME' is
+     defined, and true otherwise.
+
+ -- Target Hook: rtx TARGET_DWARF_REGISTER_SPAN (rtx REG)
+     Given a register, this hook should return a parallel of registers
+     to represent where to find the register pieces.  Define this hook
+     if the register and its mode are represented in Dwarf in
+     non-contiguous locations, or if the register should be represented
+     in more than one register in Dwarf.  Otherwise, this hook should
+     return 'NULL_RTX'.  If not defined, the default is to return
+     'NULL_RTX'.
+
+ -- Target Hook: void TARGET_INIT_DWARF_REG_SIZES_EXTRA (tree ADDRESS)
+     If some registers are represented in Dwarf-2 unwind information in
+     multiple pieces, define this hook to fill in information about the
+     sizes of those pieces in the table used by the unwinder at runtime.
+     It will be called by 'expand_builtin_init_dwarf_reg_sizes' after
+     filling in a single size corresponding to each hard register;
+     ADDRESS is the address of the table.
+
+ -- Target Hook: bool TARGET_ASM_TTYPE (rtx SYM)
+     This hook is used to output a reference from a frame unwinding
+     table to the type_info object identified by SYM.  It should return
+     'true' if the reference was output.  Returning 'false' will cause
+     the reference to be output using the normal Dwarf2 routines.
+
+ -- Target Hook: bool TARGET_ARM_EABI_UNWINDER
+     This flag should be set to 'true' on targets that use an ARM EABI
+     based unwinding library, and 'false' on other targets.  This
+     effects the format of unwinding tables, and how the unwinder in
+     entered after running a cleanup.  The default is 'false'.
+
+
+File: gccint.info,  Node: Alignment Output,  Prev: Exception Region Output,  Up: Assembler Format
+
+17.21.10 Assembler Commands for Alignment
+-----------------------------------------
+
+This describes commands for alignment.
+
+ -- Macro: JUMP_ALIGN (LABEL)
+     The alignment (log base 2) to put in front of LABEL, which is a
+     common destination of jumps and has no fallthru incoming edge.
+
+     This macro need not be defined if you don't want any special
+     alignment to be done at such a time.  Most machine descriptions do
+     not currently define the macro.
+
+     Unless it's necessary to inspect the LABEL parameter, it is better
+     to set the variable ALIGN_JUMPS in the target's
+     'TARGET_OPTION_OVERRIDE'.  Otherwise, you should try to honor the
+     user's selection in ALIGN_JUMPS in a 'JUMP_ALIGN' implementation.
+
+ -- Target Hook: int TARGET_ASM_JUMP_ALIGN_MAX_SKIP (rtx LABEL)
+     The maximum number of bytes to skip before LABEL when applying
+     'JUMP_ALIGN'.  This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is
+     defined.
+
+ -- Macro: LABEL_ALIGN_AFTER_BARRIER (LABEL)
+     The alignment (log base 2) to put in front of LABEL, which follows
+     a 'BARRIER'.
+
+     This macro need not be defined if you don't want any special
+     alignment to be done at such a time.  Most machine descriptions do
+     not currently define the macro.
+
+ -- Target Hook: int TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP (rtx
+          LABEL)
+     The maximum number of bytes to skip before LABEL when applying
+     'LABEL_ALIGN_AFTER_BARRIER'.  This works only if
+     'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
+
+ -- Macro: LOOP_ALIGN (LABEL)
+     The alignment (log base 2) to put in front of LABEL that heads a
+     frequently executed basic block (usually the header of a loop).
+
+     This macro need not be defined if you don't want any special
+     alignment to be done at such a time.  Most machine descriptions do
+     not currently define the macro.
+
+     Unless it's necessary to inspect the LABEL parameter, it is better
+     to set the variable 'align_loops' in the target's
+     'TARGET_OPTION_OVERRIDE'.  Otherwise, you should try to honor the
+     user's selection in 'align_loops' in a 'LOOP_ALIGN' implementation.
+
+ -- Target Hook: int TARGET_ASM_LOOP_ALIGN_MAX_SKIP (rtx LABEL)
+     The maximum number of bytes to skip when applying 'LOOP_ALIGN' to
+     LABEL.  This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
+
+ -- Macro: LABEL_ALIGN (LABEL)
+     The alignment (log base 2) to put in front of LABEL.  If
+     'LABEL_ALIGN_AFTER_BARRIER' / 'LOOP_ALIGN' specify a different
+     alignment, the maximum of the specified values is used.
+
+     Unless it's necessary to inspect the LABEL parameter, it is better
+     to set the variable 'align_labels' in the target's
+     'TARGET_OPTION_OVERRIDE'.  Otherwise, you should try to honor the
+     user's selection in 'align_labels' in a 'LABEL_ALIGN'
+     implementation.
+
+ -- Target Hook: int TARGET_ASM_LABEL_ALIGN_MAX_SKIP (rtx LABEL)
+     The maximum number of bytes to skip when applying 'LABEL_ALIGN' to
+     LABEL.  This works only if 'ASM_OUTPUT_MAX_SKIP_ALIGN' is defined.
+
+ -- Macro: ASM_OUTPUT_SKIP (STREAM, NBYTES)
+     A C statement to output to the stdio stream STREAM an assembler
+     instruction to advance the location counter by NBYTES bytes.  Those
+     bytes should be zero when loaded.  NBYTES will be a C expression of
+     type 'unsigned HOST_WIDE_INT'.
+
+ -- Macro: ASM_NO_SKIP_IN_TEXT
+     Define this macro if 'ASM_OUTPUT_SKIP' should not be used in the
+     text section because it fails to put zeros in the bytes that are
+     skipped.  This is true on many Unix systems, where the pseudo-op to
+     skip bytes produces no-op instructions rather than zeros when used
+     in the text section.
+
+ -- Macro: ASM_OUTPUT_ALIGN (STREAM, POWER)
+     A C statement to output to the stdio stream STREAM an assembler
+     command to advance the location counter to a multiple of 2 to the
+     POWER bytes.  POWER will be a C expression of type 'int'.
+
+ -- Macro: ASM_OUTPUT_ALIGN_WITH_NOP (STREAM, POWER)
+     Like 'ASM_OUTPUT_ALIGN', except that the "nop" instruction is used
+     for padding, if necessary.
+
+ -- Macro: ASM_OUTPUT_MAX_SKIP_ALIGN (STREAM, POWER, MAX_SKIP)
+     A C statement to output to the stdio stream STREAM an assembler
+     command to advance the location counter to a multiple of 2 to the
+     POWER bytes, but only if MAX_SKIP or fewer bytes are needed to
+     satisfy the alignment request.  POWER and MAX_SKIP will be a C
+     expression of type 'int'.
+
+
+File: gccint.info,  Node: Debugging Info,  Next: Floating Point,  Prev: Assembler Format,  Up: Target Macros
+
+17.22 Controlling Debugging Information Format
+==============================================
+
+This describes how to specify debugging information.
+
+* Menu:
+
+* All Debuggers::      Macros that affect all debugging formats uniformly.
+* DBX Options::        Macros enabling specific options in DBX format.
+* DBX Hooks::          Hook macros for varying DBX format.
+* File Names and DBX:: Macros controlling output of file names in DBX format.
+* SDB and DWARF::      Macros for SDB (COFF) and DWARF formats.
+* VMS Debug::          Macros for VMS debug format.
+
+
+File: gccint.info,  Node: All Debuggers,  Next: DBX Options,  Up: Debugging Info
+
+17.22.1 Macros Affecting All Debugging Formats
+----------------------------------------------
+
+These macros affect all debugging formats.
+
+ -- Macro: DBX_REGISTER_NUMBER (REGNO)
+     A C expression that returns the DBX register number for the
+     compiler register number REGNO.  In the default macro provided, the
+     value of this expression will be REGNO itself.  But sometimes there
+     are some registers that the compiler knows about and DBX does not,
+     or vice versa.  In such cases, some register may need to have one
+     number in the compiler and another for DBX.
+
+     If two registers have consecutive numbers inside GCC, and they can
+     be used as a pair to hold a multiword value, then they _must_ have
+     consecutive numbers after renumbering with 'DBX_REGISTER_NUMBER'.
+     Otherwise, debuggers will be unable to access such a pair, because
+     they expect register pairs to be consecutive in their own numbering
+     scheme.
+
+     If you find yourself defining 'DBX_REGISTER_NUMBER' in way that
+     does not preserve register pairs, then what you must do instead is
+     redefine the actual register numbering scheme.
+
+ -- Macro: DEBUGGER_AUTO_OFFSET (X)
+     A C expression that returns the integer offset value for an
+     automatic variable having address X (an RTL expression).  The
+     default computation assumes that X is based on the frame-pointer
+     and gives the offset from the frame-pointer.  This is required for
+     targets that produce debugging output for DBX or COFF-style
+     debugging output for SDB and allow the frame-pointer to be
+     eliminated when the '-g' options is used.
+
+ -- Macro: DEBUGGER_ARG_OFFSET (OFFSET, X)
+     A C expression that returns the integer offset value for an
+     argument having address X (an RTL expression).  The nominal offset
+     is OFFSET.
+
+ -- Macro: PREFERRED_DEBUGGING_TYPE
+     A C expression that returns the type of debugging output GCC should
+     produce when the user specifies just '-g'.  Define this if you have
+     arranged for GCC to support more than one format of debugging
+     output.  Currently, the allowable values are 'DBX_DEBUG',
+     'SDB_DEBUG', 'DWARF_DEBUG', 'DWARF2_DEBUG', 'XCOFF_DEBUG',
+     'VMS_DEBUG', and 'VMS_AND_DWARF2_DEBUG'.
+
+     When the user specifies '-ggdb', GCC normally also uses the value
+     of this macro to select the debugging output format, but with two
+     exceptions.  If 'DWARF2_DEBUGGING_INFO' is defined, GCC uses the
+     value 'DWARF2_DEBUG'.  Otherwise, if 'DBX_DEBUGGING_INFO' is
+     defined, GCC uses 'DBX_DEBUG'.
+
+     The value of this macro only affects the default debugging output;
+     the user can always get a specific type of output by using
+     '-gstabs', '-gcoff', '-gdwarf-2', '-gxcoff', or '-gvms'.
+
+
+File: gccint.info,  Node: DBX Options,  Next: DBX Hooks,  Prev: All Debuggers,  Up: Debugging Info
+
+17.22.2 Specific Options for DBX Output
+---------------------------------------
+
+These are specific options for DBX output.
+
+ -- Macro: DBX_DEBUGGING_INFO
+     Define this macro if GCC should produce debugging output for DBX in
+     response to the '-g' option.
+
+ -- Macro: XCOFF_DEBUGGING_INFO
+     Define this macro if GCC should produce XCOFF format debugging
+     output in response to the '-g' option.  This is a variant of DBX
+     format.
+
+ -- Macro: DEFAULT_GDB_EXTENSIONS
+     Define this macro to control whether GCC should by default generate
+     GDB's extended version of DBX debugging information (assuming
+     DBX-format debugging information is enabled at all).  If you don't
+     define the macro, the default is 1: always generate the extended
+     information if there is any occasion to.
+
+ -- Macro: DEBUG_SYMS_TEXT
+     Define this macro if all '.stabs' commands should be output while
+     in the text section.
+
+ -- Macro: ASM_STABS_OP
+     A C string constant, including spacing, naming the assembler pseudo
+     op to use instead of '"\t.stabs\t"' to define an ordinary debugging
+     symbol.  If you don't define this macro, '"\t.stabs\t"' is used.
+     This macro applies only to DBX debugging information format.
+
+ -- Macro: ASM_STABD_OP
+     A C string constant, including spacing, naming the assembler pseudo
+     op to use instead of '"\t.stabd\t"' to define a debugging symbol
+     whose value is the current location.  If you don't define this
+     macro, '"\t.stabd\t"' is used.  This macro applies only to DBX
+     debugging information format.
+
+ -- Macro: ASM_STABN_OP
+     A C string constant, including spacing, naming the assembler pseudo
+     op to use instead of '"\t.stabn\t"' to define a debugging symbol
+     with no name.  If you don't define this macro, '"\t.stabn\t"' is
+     used.  This macro applies only to DBX debugging information format.
+
+ -- Macro: DBX_NO_XREFS
+     Define this macro if DBX on your system does not support the
+     construct 'xsTAGNAME'.  On some systems, this construct is used to
+     describe a forward reference to a structure named TAGNAME.  On
+     other systems, this construct is not supported at all.
+
+ -- Macro: DBX_CONTIN_LENGTH
+     A symbol name in DBX-format debugging information is normally
+     continued (split into two separate '.stabs' directives) when it
+     exceeds a certain length (by default, 80 characters).  On some
+     operating systems, DBX requires this splitting; on others,
+     splitting must not be done.  You can inhibit splitting by defining
+     this macro with the value zero.  You can override the default
+     splitting-length by defining this macro as an expression for the
+     length you desire.
+
+ -- Macro: DBX_CONTIN_CHAR
+     Normally continuation is indicated by adding a '\' character to the
+     end of a '.stabs' string when a continuation follows.  To use a
+     different character instead, define this macro as a character
+     constant for the character you want to use.  Do not define this
+     macro if backslash is correct for your system.
+
+ -- Macro: DBX_STATIC_STAB_DATA_SECTION
+     Define this macro if it is necessary to go to the data section
+     before outputting the '.stabs' pseudo-op for a non-global static
+     variable.
+
+ -- Macro: DBX_TYPE_DECL_STABS_CODE
+     The value to use in the "code" field of the '.stabs' directive for
+     a typedef.  The default is 'N_LSYM'.
+
+ -- Macro: DBX_STATIC_CONST_VAR_CODE
+     The value to use in the "code" field of the '.stabs' directive for
+     a static variable located in the text section.  DBX format does not
+     provide any "right" way to do this.  The default is 'N_FUN'.
+
+ -- Macro: DBX_REGPARM_STABS_CODE
+     The value to use in the "code" field of the '.stabs' directive for
+     a parameter passed in registers.  DBX format does not provide any
+     "right" way to do this.  The default is 'N_RSYM'.
+
+ -- Macro: DBX_REGPARM_STABS_LETTER
+     The letter to use in DBX symbol data to identify a symbol as a
+     parameter passed in registers.  DBX format does not customarily
+     provide any way to do this.  The default is ''P''.
+
+ -- Macro: DBX_FUNCTION_FIRST
+     Define this macro if the DBX information for a function and its
+     arguments should precede the assembler code for the function.
+     Normally, in DBX format, the debugging information entirely follows
+     the assembler code.
+
+ -- Macro: DBX_BLOCKS_FUNCTION_RELATIVE
+     Define this macro, with value 1, if the value of a symbol
+     describing the scope of a block ('N_LBRAC' or 'N_RBRAC') should be
+     relative to the start of the enclosing function.  Normally, GCC
+     uses an absolute address.
+
+ -- Macro: DBX_LINES_FUNCTION_RELATIVE
+     Define this macro, with value 1, if the value of a symbol
+     indicating the current line number ('N_SLINE') should be relative
+     to the start of the enclosing function.  Normally, GCC uses an
+     absolute address.
+
+ -- Macro: DBX_USE_BINCL
+     Define this macro if GCC should generate 'N_BINCL' and 'N_EINCL'
+     stabs for included header files, as on Sun systems.  This macro
+     also directs GCC to output a type number as a pair of a file number
+     and a type number within the file.  Normally, GCC does not generate
+     'N_BINCL' or 'N_EINCL' stabs, and it outputs a single number for a
+     type number.
+
+
+File: gccint.info,  Node: DBX Hooks,  Next: File Names and DBX,  Prev: DBX Options,  Up: Debugging Info
+
+17.22.3 Open-Ended Hooks for DBX Format
+---------------------------------------
+
+These are hooks for DBX format.
+
+ -- Macro: DBX_OUTPUT_SOURCE_LINE (STREAM, LINE, COUNTER)
+     A C statement to output DBX debugging information before code for
+     line number LINE of the current source file to the stdio stream
+     STREAM.  COUNTER is the number of time the macro was invoked,
+     including the current invocation; it is intended to generate unique
+     labels in the assembly output.
+
+     This macro should not be defined if the default output is correct,
+     or if it can be made correct by defining
+     'DBX_LINES_FUNCTION_RELATIVE'.
+
+ -- Macro: NO_DBX_FUNCTION_END
+     Some stabs encapsulation formats (in particular ECOFF), cannot
+     handle the '.stabs "",N_FUN,,0,0,Lscope-function-1' gdb dbx
+     extension construct.  On those machines, define this macro to turn
+     this feature off without disturbing the rest of the gdb extensions.
+
+ -- Macro: NO_DBX_BNSYM_ENSYM
+     Some assemblers cannot handle the '.stabd BNSYM/ENSYM,0,0' gdb dbx
+     extension construct.  On those machines, define this macro to turn
+     this feature off without disturbing the rest of the gdb extensions.
+
+
+File: gccint.info,  Node: File Names and DBX,  Next: SDB and DWARF,  Prev: DBX Hooks,  Up: Debugging Info
+
+17.22.4 File Names in DBX Format
+--------------------------------
+
+This describes file names in DBX format.
+
+ -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILENAME (STREAM, NAME)
+     A C statement to output DBX debugging information to the stdio
+     stream STREAM, which indicates that file NAME is the main source
+     file--the file specified as the input file for compilation.  This
+     macro is called only once, at the beginning of compilation.
+
+     This macro need not be defined if the standard form of output for
+     DBX debugging information is appropriate.
+
+     It may be necessary to refer to a label equal to the beginning of
+     the text section.  You can use 'assemble_name (stream,
+     ltext_label_name)' to do so.  If you do this, you must also set the
+     variable USED_LTEXT_LABEL_NAME to 'true'.
+
+ -- Macro: NO_DBX_MAIN_SOURCE_DIRECTORY
+     Define this macro, with value 1, if GCC should not emit an
+     indication of the current directory for compilation and current
+     source language at the beginning of the file.
+
+ -- Macro: NO_DBX_GCC_MARKER
+     Define this macro, with value 1, if GCC should not emit an
+     indication that this object file was compiled by GCC.  The default
+     is to emit an 'N_OPT' stab at the beginning of every source file,
+     with 'gcc2_compiled.' for the string and value 0.
+
+ -- Macro: DBX_OUTPUT_MAIN_SOURCE_FILE_END (STREAM, NAME)
+     A C statement to output DBX debugging information at the end of
+     compilation of the main source file NAME.  Output should be written
+     to the stdio stream STREAM.
+
+     If you don't define this macro, nothing special is output at the
+     end of compilation, which is correct for most machines.
+
+ -- Macro: DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END
+     Define this macro _instead of_ defining
+     'DBX_OUTPUT_MAIN_SOURCE_FILE_END', if what needs to be output at
+     the end of compilation is an 'N_SO' stab with an empty string,
+     whose value is the highest absolute text address in the file.
+
+
+File: gccint.info,  Node: SDB and DWARF,  Next: VMS Debug,  Prev: File Names and DBX,  Up: Debugging Info
+
+17.22.5 Macros for SDB and DWARF Output
+---------------------------------------
+
+Here are macros for SDB and DWARF output.
+
+ -- Macro: SDB_DEBUGGING_INFO
+     Define this macro if GCC should produce COFF-style debugging output
+     for SDB in response to the '-g' option.
+
+ -- Macro: DWARF2_DEBUGGING_INFO
+     Define this macro if GCC should produce dwarf version 2 format
+     debugging output in response to the '-g' option.
+
+      -- Target Hook: int TARGET_DWARF_CALLING_CONVENTION (const_tree
+               FUNCTION)
+          Define this to enable the dwarf attribute
+          'DW_AT_calling_convention' to be emitted for each function.
+          Instead of an integer return the enum value for the 'DW_CC_'
+          tag.
+
+     To support optional call frame debugging information, you must also
+     define 'INCOMING_RETURN_ADDR_RTX' and either set
+     'RTX_FRAME_RELATED_P' on the prologue insns if you use RTL for the
+     prologue, or call 'dwarf2out_def_cfa' and 'dwarf2out_reg_save' as
+     appropriate from 'TARGET_ASM_FUNCTION_PROLOGUE' if you don't.
+
+ -- Macro: DWARF2_FRAME_INFO
+     Define this macro to a nonzero value if GCC should always output
+     Dwarf 2 frame information.  If 'TARGET_EXCEPT_UNWIND_INFO' (*note
+     Exception Region Output::) returns 'UI_DWARF2', and exceptions are
+     enabled, GCC will output this information not matter how you define
+     'DWARF2_FRAME_INFO'.
+
+ -- Target Hook: enum unwind_info_type TARGET_DEBUG_UNWIND_INFO (void)
+     This hook defines the mechanism that will be used for describing
+     frame unwind information to the debugger.  Normally the hook will
+     return 'UI_DWARF2' if DWARF 2 debug information is enabled, and
+     return 'UI_NONE' otherwise.
+
+     A target may return 'UI_DWARF2' even when DWARF 2 debug information
+     is disabled in order to always output DWARF 2 frame information.
+
+     A target may return 'UI_TARGET' if it has ABI specified unwind
+     tables.  This will suppress generation of the normal debug frame
+     unwind information.
+
+ -- Macro: DWARF2_ASM_LINE_DEBUG_INFO
+     Define this macro to be a nonzero value if the assembler can
+     generate Dwarf 2 line debug info sections.  This will result in
+     much more compact line number tables, and hence is desirable if it
+     works.
+
+ -- Target Hook: bool TARGET_WANT_DEBUG_PUB_SECTIONS
+     True if the '.debug_pubtypes' and '.debug_pubnames' sections should
+     be emitted.  These sections are not used on most platforms, and in
+     particular GDB does not use them.
+
+ -- Target Hook: bool TARGET_FORCE_AT_COMP_DIR
+     True if the 'DW_AT_comp_dir' attribute should be emitted for each
+     compilation unit.  This attribute is required for the darwin linker
+     to emit debug information.
+
+ -- Target Hook: bool TARGET_DELAY_SCHED2
+     True if sched2 is not to be run at its normal place.  This usually
+     means it will be run as part of machine-specific reorg.
+
+ -- Target Hook: bool TARGET_DELAY_VARTRACK
+     True if vartrack is not to be run at its normal place.  This
+     usually means it will be run as part of machine-specific reorg.
+
+ -- Macro: ASM_OUTPUT_DWARF_DELTA (STREAM, SIZE, LABEL1, LABEL2)
+     A C statement to issue assembly directives that create a difference
+     LAB1 minus LAB2, using an integer of the given SIZE.
+
+ -- Macro: ASM_OUTPUT_DWARF_VMS_DELTA (STREAM, SIZE, LABEL1, LABEL2)
+     A C statement to issue assembly directives that create a difference
+     between the two given labels in system defined units, e.g.
+     instruction slots on IA64 VMS, using an integer of the given size.
+
+ -- Macro: ASM_OUTPUT_DWARF_OFFSET (STREAM, SIZE, LABEL, SECTION)
+     A C statement to issue assembly directives that create a
+     section-relative reference to the given LABEL, using an integer of
+     the given SIZE.  The label is known to be defined in the given
+     SECTION.
+
+ -- Macro: ASM_OUTPUT_DWARF_PCREL (STREAM, SIZE, LABEL)
+     A C statement to issue assembly directives that create a
+     self-relative reference to the given LABEL, using an integer of the
+     given SIZE.
+
+ -- Macro: ASM_OUTPUT_DWARF_TABLE_REF (LABEL)
+     A C statement to issue assembly directives that create a reference
+     to the DWARF table identifier LABEL from the current section.  This
+     is used on some systems to avoid garbage collecting a DWARF table
+     which is referenced by a function.
+
+ -- Target Hook: void TARGET_ASM_OUTPUT_DWARF_DTPREL (FILE *FILE, int
+          SIZE, rtx X)
+     If defined, this target hook is a function which outputs a
+     DTP-relative reference to the given TLS symbol of the specified
+     size.
+
+ -- Macro: PUT_SDB_ ...
+     Define these macros to override the assembler syntax for the
+     special SDB assembler directives.  See 'sdbout.c' for a list of
+     these macros and their arguments.  If the standard syntax is used,
+     you need not define them yourself.
+
+ -- Macro: SDB_DELIM
+     Some assemblers do not support a semicolon as a delimiter, even
+     between SDB assembler directives.  In that case, define this macro
+     to be the delimiter to use (usually '\n').  It is not necessary to
+     define a new set of 'PUT_SDB_OP' macros if this is the only change
+     required.
+
+ -- Macro: SDB_ALLOW_UNKNOWN_REFERENCES
+     Define this macro to allow references to unknown structure, union,
+     or enumeration tags to be emitted.  Standard COFF does not allow
+     handling of unknown references, MIPS ECOFF has support for it.
+
+ -- Macro: SDB_ALLOW_FORWARD_REFERENCES
+     Define this macro to allow references to structure, union, or
+     enumeration tags that have not yet been seen to be handled.  Some
+     assemblers choke if forward tags are used, while some require it.
+
+ -- Macro: SDB_OUTPUT_SOURCE_LINE (STREAM, LINE)
+     A C statement to output SDB debugging information before code for
+     line number LINE of the current source file to the stdio stream
+     STREAM.  The default is to emit an '.ln' directive.
+
+
+File: gccint.info,  Node: VMS Debug,  Prev: SDB and DWARF,  Up: Debugging Info
+
+17.22.6 Macros for VMS Debug Format
+-----------------------------------
+
+Here are macros for VMS debug format.
+
+ -- Macro: VMS_DEBUGGING_INFO
+     Define this macro if GCC should produce debugging output for VMS in
+     response to the '-g' option.  The default behavior for VMS is to
+     generate minimal debug info for a traceback in the absence of '-g'
+     unless explicitly overridden with '-g0'.  This behavior is
+     controlled by 'TARGET_OPTION_OPTIMIZATION' and
+     'TARGET_OPTION_OVERRIDE'.
+
+
+File: gccint.info,  Node: Floating Point,  Next: Mode Switching,  Prev: Debugging Info,  Up: Target Macros
+
+17.23 Cross Compilation and Floating Point
+==========================================
+
+While all modern machines use twos-complement representation for
+integers, there are a variety of representations for floating point
+numbers.  This means that in a cross-compiler the representation of
+floating point numbers in the compiled program may be different from
+that used in the machine doing the compilation.
+
+ Because different representation systems may offer different amounts of
+range and precision, all floating point constants must be represented in
+the target machine's format.  Therefore, the cross compiler cannot
+safely use the host machine's floating point arithmetic; it must emulate
+the target's arithmetic.  To ensure consistency, GCC always uses
+emulation to work with floating point values, even when the host and
+target floating point formats are identical.
+
+ The following macros are provided by 'real.h' for the compiler to use.
+All parts of the compiler which generate or optimize floating-point
+calculations must use these macros.  They may evaluate their operands
+more than once, so operands must not have side effects.
+
+ -- Macro: REAL_VALUE_TYPE
+     The C data type to be used to hold a floating point value in the
+     target machine's format.  Typically this is a 'struct' containing
+     an array of 'HOST_WIDE_INT', but all code should treat it as an
+     opaque quantity.
+
+ -- Macro: int REAL_VALUES_EQUAL (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
+     Compares for equality the two values, X and Y.  If the target
+     floating point format supports negative zeroes and/or NaNs,
+     'REAL_VALUES_EQUAL (-0.0, 0.0)' is true, and 'REAL_VALUES_EQUAL
+     (NaN, NaN)' is false.
+
+ -- Macro: int REAL_VALUES_LESS (REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
+     Tests whether X is less than Y.
+
+ -- Macro: HOST_WIDE_INT REAL_VALUE_FIX (REAL_VALUE_TYPE X)
+     Truncates X to a signed integer, rounding toward zero.
+
+ -- Macro: unsigned HOST_WIDE_INT REAL_VALUE_UNSIGNED_FIX
+          (REAL_VALUE_TYPE X)
+     Truncates X to an unsigned integer, rounding toward zero.  If X is
+     negative, returns zero.
+
+ -- Macro: REAL_VALUE_TYPE REAL_VALUE_ATOF (const char *STRING, enum
+          machine_mode MODE)
+     Converts STRING into a floating point number in the target
+     machine's representation for mode MODE.  This routine can handle
+     both decimal and hexadecimal floating point constants, using the
+     syntax defined by the C language for both.
+
+ -- Macro: int REAL_VALUE_NEGATIVE (REAL_VALUE_TYPE X)
+     Returns 1 if X is negative (including negative zero), 0 otherwise.
+
+ -- Macro: int REAL_VALUE_ISINF (REAL_VALUE_TYPE X)
+     Determines whether X represents infinity (positive or negative).
+
+ -- Macro: int REAL_VALUE_ISNAN (REAL_VALUE_TYPE X)
+     Determines whether X represents a "NaN" (not-a-number).
+
+ -- Macro: void REAL_ARITHMETIC (REAL_VALUE_TYPE OUTPUT, enum tree_code
+          CODE, REAL_VALUE_TYPE X, REAL_VALUE_TYPE Y)
+     Calculates an arithmetic operation on the two floating point values
+     X and Y, storing the result in OUTPUT (which must be a variable).
+
+     The operation to be performed is specified by CODE.  Only the
+     following codes are supported: 'PLUS_EXPR', 'MINUS_EXPR',
+     'MULT_EXPR', 'RDIV_EXPR', 'MAX_EXPR', 'MIN_EXPR'.
+
+     If 'REAL_ARITHMETIC' is asked to evaluate division by zero and the
+     target's floating point format cannot represent infinity, it will
+     call 'abort'.  Callers should check for this situation first, using
+     'MODE_HAS_INFINITIES'.  *Note Storage Layout::.
+
+ -- Macro: REAL_VALUE_TYPE REAL_VALUE_NEGATE (REAL_VALUE_TYPE X)
+     Returns the negative of the floating point value X.
+
+ -- Macro: REAL_VALUE_TYPE REAL_VALUE_ABS (REAL_VALUE_TYPE X)
+     Returns the absolute value of X.
+
+ -- Macro: void REAL_VALUE_TO_INT (HOST_WIDE_INT LOW, HOST_WIDE_INT
+          HIGH, REAL_VALUE_TYPE X)
+     Converts a floating point value X into a double-precision integer
+     which is then stored into LOW and HIGH.  If the value is not
+     integral, it is truncated.
+
+ -- Macro: void REAL_VALUE_FROM_INT (REAL_VALUE_TYPE X, HOST_WIDE_INT
+          LOW, HOST_WIDE_INT HIGH, enum machine_mode MODE)
+     Converts a double-precision integer found in LOW and HIGH, into a
+     floating point value which is then stored into X.  The value is
+     truncated to fit in mode MODE.
+
+
+File: gccint.info,  Node: Mode Switching,  Next: Target Attributes,  Prev: Floating Point,  Up: Target Macros
+
+17.24 Mode Switching Instructions
+=================================
+
+The following macros control mode switching optimizations:
+
+ -- Macro: OPTIMIZE_MODE_SWITCHING (ENTITY)
+     Define this macro if the port needs extra instructions inserted for
+     mode switching in an optimizing compilation.
+
+     For an example, the SH4 can perform both single and double
+     precision floating point operations, but to perform a single
+     precision operation, the FPSCR PR bit has to be cleared, while for
+     a double precision operation, this bit has to be set.  Changing the
+     PR bit requires a general purpose register as a scratch register,
+     hence these FPSCR sets have to be inserted before reload, i.e. you
+     can't put this into instruction emitting or
+     'TARGET_MACHINE_DEPENDENT_REORG'.
+
+     You can have multiple entities that are mode-switched, and select
+     at run time which entities actually need it.
+     'OPTIMIZE_MODE_SWITCHING' should return nonzero for any ENTITY that
+     needs mode-switching.  If you define this macro, you also have to
+     define 'NUM_MODES_FOR_MODE_SWITCHING', 'MODE_NEEDED',
+     'MODE_PRIORITY_TO_MODE' and 'EMIT_MODE_SET'.  'MODE_AFTER',
+     'MODE_ENTRY', and 'MODE_EXIT' are optional.
+
+ -- Macro: NUM_MODES_FOR_MODE_SWITCHING
+     If you define 'OPTIMIZE_MODE_SWITCHING', you have to define this as
+     initializer for an array of integers.  Each initializer element N
+     refers to an entity that needs mode switching, and specifies the
+     number of different modes that might need to be set for this
+     entity.  The position of the initializer in the
+     initializer--starting counting at zero--determines the integer that
+     is used to refer to the mode-switched entity in question.  In
+     macros that take mode arguments / yield a mode result, modes are
+     represented as numbers 0 ... N - 1.  N is used to specify that no
+     mode switch is needed / supplied.
+
+ -- Macro: MODE_NEEDED (ENTITY, INSN)
+     ENTITY is an integer specifying a mode-switched entity.  If
+     'OPTIMIZE_MODE_SWITCHING' is defined, you must define this macro to
+     return an integer value not larger than the corresponding element
+     in 'NUM_MODES_FOR_MODE_SWITCHING', to denote the mode that ENTITY
+     must be switched into prior to the execution of INSN.
+
+ -- Macro: MODE_AFTER (ENTITY, MODE, INSN)
+     ENTITY is an integer specifying a mode-switched entity.  If this
+     macro is defined, it is evaluated for every INSN during mode
+     switching.  It determines the mode that an insn results in (if
+     different from the incoming mode).
+
+ -- Macro: MODE_ENTRY (ENTITY)
+     If this macro is defined, it is evaluated for every ENTITY that
+     needs mode switching.  It should evaluate to an integer, which is a
+     mode that ENTITY is assumed to be switched to at function entry.
+     If 'MODE_ENTRY' is defined then 'MODE_EXIT' must be defined.
+
+ -- Macro: MODE_EXIT (ENTITY)
+     If this macro is defined, it is evaluated for every ENTITY that
+     needs mode switching.  It should evaluate to an integer, which is a
+     mode that ENTITY is assumed to be switched to at function exit.  If
+     'MODE_EXIT' is defined then 'MODE_ENTRY' must be defined.
+
+ -- Macro: MODE_PRIORITY_TO_MODE (ENTITY, N)
+     This macro specifies the order in which modes for ENTITY are
+     processed.  0 is the highest priority,
+     'NUM_MODES_FOR_MODE_SWITCHING[ENTITY] - 1' the lowest.  The value
+     of the macro should be an integer designating a mode for ENTITY.
+     For any fixed ENTITY, 'mode_priority_to_mode' (ENTITY, N) shall be
+     a bijection in 0 ... 'num_modes_for_mode_switching[ENTITY] - 1'.
+
+ -- Macro: EMIT_MODE_SET (ENTITY, MODE, HARD_REGS_LIVE)
+     Generate one or more insns to set ENTITY to MODE.  HARD_REG_LIVE is
+     the set of hard registers live at the point where the insn(s) are
+     to be inserted.
+
+
+File: gccint.info,  Node: Target Attributes,  Next: Emulated TLS,  Prev: Mode Switching,  Up: Target Macros
+
+17.25 Defining target-specific uses of '__attribute__'
+======================================================
+
+Target-specific attributes may be defined for functions, data and types.
+These are described using the following target hooks; they also need to
+be documented in 'extend.texi'.
+
+ -- Target Hook: const struct attribute_spec * TARGET_ATTRIBUTE_TABLE
+     If defined, this target hook points to an array of 'struct
+     attribute_spec' (defined in 'tree.h') specifying the machine
+     specific attributes for this target and some of the restrictions on
+     the entities to which these attributes are applied and the
+     arguments they take.
+
+ -- Target Hook: bool TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P (const_tree
+          NAME)
+     If defined, this target hook is a function which returns true if
+     the machine-specific attribute named NAME expects an identifier
+     given as its first argument to be passed on as a plain identifier,
+     not subjected to name lookup.  If this is not defined, the default
+     is false for all machine-specific attributes.
+
+ -- Target Hook: int TARGET_COMP_TYPE_ATTRIBUTES (const_tree TYPE1,
+          const_tree TYPE2)
+     If defined, this target hook is a function which returns zero if
+     the attributes on TYPE1 and TYPE2 are incompatible, one if they are
+     compatible, and two if they are nearly compatible (which causes a
+     warning to be generated).  If this is not defined, machine-specific
+     attributes are supposed always to be compatible.
+
+ -- Target Hook: void TARGET_SET_DEFAULT_TYPE_ATTRIBUTES (tree TYPE)
+     If defined, this target hook is a function which assigns default
+     attributes to the newly defined TYPE.
+
+ -- Target Hook: tree TARGET_MERGE_TYPE_ATTRIBUTES (tree TYPE1, tree
+          TYPE2)
+     Define this target hook if the merging of type attributes needs
+     special handling.  If defined, the result is a list of the combined
+     'TYPE_ATTRIBUTES' of TYPE1 and TYPE2.  It is assumed that
+     'comptypes' has already been called and returned 1.  This function
+     may call 'merge_attributes' to handle machine-independent merging.
+
+ -- Target Hook: tree TARGET_MERGE_DECL_ATTRIBUTES (tree OLDDECL, tree
+          NEWDECL)
+     Define this target hook if the merging of decl attributes needs
+     special handling.  If defined, the result is a list of the combined
+     'DECL_ATTRIBUTES' of OLDDECL and NEWDECL.  NEWDECL is a duplicate
+     declaration of OLDDECL.  Examples of when this is needed are when
+     one attribute overrides another, or when an attribute is nullified
+     by a subsequent definition.  This function may call
+     'merge_attributes' to handle machine-independent merging.
+
+     If the only target-specific handling you require is 'dllimport' for
+     Microsoft Windows targets, you should define the macro
+     'TARGET_DLLIMPORT_DECL_ATTRIBUTES' to '1'.  The compiler will then
+     define a function called 'merge_dllimport_decl_attributes' which
+     can then be defined as the expansion of
+     'TARGET_MERGE_DECL_ATTRIBUTES'.  You can also add
+     'handle_dll_attribute' in the attribute table for your port to
+     perform initial processing of the 'dllimport' and 'dllexport'
+     attributes.  This is done in 'i386/cygwin.h' and 'i386/i386.c', for
+     example.
+
+ -- Target Hook: bool TARGET_VALID_DLLIMPORT_ATTRIBUTE_P (const_tree
+          DECL)
+     DECL is a variable or function with '__attribute__((dllimport))'
+     specified.  Use this hook if the target needs to add extra
+     validation checks to 'handle_dll_attribute'.
+
+ -- Macro: TARGET_DECLSPEC
+     Define this macro to a nonzero value if you want to treat
+     '__declspec(X)' as equivalent to '__attribute((X))'.  By default,
+     this behavior is enabled only for targets that define
+     'TARGET_DLLIMPORT_DECL_ATTRIBUTES'.  The current implementation of
+     '__declspec' is via a built-in macro, but you should not rely on
+     this implementation detail.
+
+ -- Target Hook: void TARGET_INSERT_ATTRIBUTES (tree NODE, tree
+          *ATTR_PTR)
+     Define this target hook if you want to be able to add attributes to
+     a decl when it is being created.  This is normally useful for back
+     ends which wish to implement a pragma by using the attributes which
+     correspond to the pragma's effect.  The NODE argument is the decl
+     which is being created.  The ATTR_PTR argument is a pointer to the
+     attribute list for this decl.  The list itself should not be
+     modified, since it may be shared with other decls, but attributes
+     may be chained on the head of the list and '*ATTR_PTR' modified to
+     point to the new attributes, or a copy of the list may be made if
+     further changes are needed.
+
+ -- Target Hook: bool TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P (const_tree
+          FNDECL)
+     This target hook returns 'true' if it is OK to inline FNDECL into
+     the current function, despite its having target-specific
+     attributes, 'false' otherwise.  By default, if a function has a
+     target specific attribute attached to it, it will not be inlined.
+
+ -- Target Hook: bool TARGET_OPTION_VALID_ATTRIBUTE_P (tree FNDECL, tree
+          NAME, tree ARGS, int FLAGS)
+     This hook is called to parse 'attribute(target("..."))', which
+     allows setting target-specific options on individual functions.
+     These function-specific options may differ from the options
+     specified on the command line.  The hook should return 'true' if
+     the options are valid.
+
+     The hook should set the 'DECL_FUNCTION_SPECIFIC_TARGET' field in
+     the function declaration to hold a pointer to a target-specific
+     'struct cl_target_option' structure.
+
+ -- Target Hook: void TARGET_OPTION_SAVE (struct cl_target_option *PTR,
+          struct gcc_options *OPTS)
+     This hook is called to save any additional target-specific
+     information in the 'struct cl_target_option' structure for
+     function-specific options from the 'struct gcc_options' structure.
+     *Note Option file format::.
+
+ -- Target Hook: void TARGET_OPTION_RESTORE (struct gcc_options *OPTS,
+          struct cl_target_option *PTR)
+     This hook is called to restore any additional target-specific
+     information in the 'struct cl_target_option' structure for
+     function-specific options to the 'struct gcc_options' structure.
+
+ -- Target Hook: void TARGET_OPTION_PRINT (FILE *FILE, int INDENT,
+          struct cl_target_option *PTR)
+     This hook is called to print any additional target-specific
+     information in the 'struct cl_target_option' structure for
+     function-specific options.
+
+ -- Target Hook: bool TARGET_OPTION_PRAGMA_PARSE (tree ARGS, tree
+          POP_TARGET)
+     This target hook parses the options for '#pragma GCC target', which
+     sets the target-specific options for functions that occur later in
+     the input stream.  The options accepted should be the same as those
+     handled by the 'TARGET_OPTION_VALID_ATTRIBUTE_P' hook.
+
+ -- Target Hook: void TARGET_OPTION_OVERRIDE (void)
+     Sometimes certain combinations of command options do not make sense
+     on a particular target machine.  You can override the hook
+     'TARGET_OPTION_OVERRIDE' to take account of this.  This hooks is
+     called once just after all the command options have been parsed.
+
+     Don't use this hook to turn on various extra optimizations for
+     '-O'.  That is what 'TARGET_OPTION_OPTIMIZATION' is for.
+
+     If you need to do something whenever the optimization level is
+     changed via the optimize attribute or pragma, see
+     'TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE'
+
+ -- Target Hook: bool TARGET_OPTION_FUNCTION_VERSIONS (tree DECL1, tree
+          DECL2)
+     This target hook returns 'true' if DECL1 and DECL2 are versions of
+     the same function.  DECL1 and DECL2 are function versions if and
+     only if they have the same function signature and different target
+     specific attributes, that is, they are compiled for different
+     target machines.
+
+ -- Target Hook: bool TARGET_CAN_INLINE_P (tree CALLER, tree CALLEE)
+     This target hook returns 'false' if the CALLER function cannot
+     inline CALLEE, based on target specific information.  By default,
+     inlining is not allowed if the callee function has function
+     specific target options and the caller does not use the same
+     options.
+
+
+File: gccint.info,  Node: Emulated TLS,  Next: MIPS Coprocessors,  Prev: Target Attributes,  Up: Target Macros
+
+17.26 Emulating TLS
+===================
+
+For targets whose psABI does not provide Thread Local Storage via
+specific relocations and instruction sequences, an emulation layer is
+used.  A set of target hooks allows this emulation layer to be
+configured for the requirements of a particular target.  For instance
+the psABI may in fact specify TLS support in terms of an emulation
+layer.
+
+ The emulation layer works by creating a control object for every TLS
+object.  To access the TLS object, a lookup function is provided which,
+when given the address of the control object, will return the address of
+the current thread's instance of the TLS object.
+
+ -- Target Hook: const char * TARGET_EMUTLS_GET_ADDRESS
+     Contains the name of the helper function that uses a TLS control
+     object to locate a TLS instance.  The default causes libgcc's
+     emulated TLS helper function to be used.
+
+ -- Target Hook: const char * TARGET_EMUTLS_REGISTER_COMMON
+     Contains the name of the helper function that should be used at
+     program startup to register TLS objects that are implicitly
+     initialized to zero.  If this is 'NULL', all TLS objects will have
+     explicit initializers.  The default causes libgcc's emulated TLS
+     registration function to be used.
+
+ -- Target Hook: const char * TARGET_EMUTLS_VAR_SECTION
+     Contains the name of the section in which TLS control variables
+     should be placed.  The default of 'NULL' allows these to be placed
+     in any section.
+
+ -- Target Hook: const char * TARGET_EMUTLS_TMPL_SECTION
+     Contains the name of the section in which TLS initializers should
+     be placed.  The default of 'NULL' allows these to be placed in any
+     section.
+
+ -- Target Hook: const char * TARGET_EMUTLS_VAR_PREFIX
+     Contains the prefix to be prepended to TLS control variable names.
+     The default of 'NULL' uses a target-specific prefix.
+
+ -- Target Hook: const char * TARGET_EMUTLS_TMPL_PREFIX
+     Contains the prefix to be prepended to TLS initializer objects.
+     The default of 'NULL' uses a target-specific prefix.
+
+ -- Target Hook: tree TARGET_EMUTLS_VAR_FIELDS (tree TYPE, tree *NAME)
+     Specifies a function that generates the FIELD_DECLs for a TLS
+     control object type.  TYPE is the RECORD_TYPE the fields are for
+     and NAME should be filled with the structure tag, if the default of
+     '__emutls_object' is unsuitable.  The default creates a type
+     suitable for libgcc's emulated TLS function.
+
+ -- Target Hook: tree TARGET_EMUTLS_VAR_INIT (tree VAR, tree DECL, tree
+          TMPL_ADDR)
+     Specifies a function that generates the CONSTRUCTOR to initialize a
+     TLS control object.  VAR is the TLS control object, DECL is the TLS
+     object and TMPL_ADDR is the address of the initializer.  The
+     default initializes libgcc's emulated TLS control object.
+
+ -- Target Hook: bool TARGET_EMUTLS_VAR_ALIGN_FIXED
+     Specifies whether the alignment of TLS control variable objects is
+     fixed and should not be increased as some backends may do to
+     optimize single objects.  The default is false.
+
+ -- Target Hook: bool TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS
+     Specifies whether a DWARF 'DW_OP_form_tls_address' location
+     descriptor may be used to describe emulated TLS control objects.
+
+
+File: gccint.info,  Node: MIPS Coprocessors,  Next: PCH Target,  Prev: Emulated TLS,  Up: Target Macros
+
+17.27 Defining coprocessor specifics for MIPS targets.
+======================================================
+
+The MIPS specification allows MIPS implementations to have as many as 4
+coprocessors, each with as many as 32 private registers.  GCC supports
+accessing these registers and transferring values between the registers
+and memory using asm-ized variables.  For example:
+
+       register unsigned int cp0count asm ("c0r1");
+       unsigned int d;
+
+       d = cp0count + 3;
+
+ ("c0r1" is the default name of register 1 in coprocessor 0; alternate
+names may be added as described below, or the default names may be
+overridden entirely in 'SUBTARGET_CONDITIONAL_REGISTER_USAGE'.)
+
+ Coprocessor registers are assumed to be epilogue-used; sets to them
+will be preserved even if it does not appear that the register is used
+again later in the function.
+
+ Another note: according to the MIPS spec, coprocessor 1 (if present) is
+the FPU.  One accesses COP1 registers through standard mips
+floating-point support; they are not included in this mechanism.
+
+ There is one macro used in defining the MIPS coprocessor interface
+which you may want to override in subtargets; it is described below.
+
+
+File: gccint.info,  Node: PCH Target,  Next: C++ ABI,  Prev: MIPS Coprocessors,  Up: Target Macros
+
+17.28 Parameters for Precompiled Header Validity Checking
+=========================================================
+
+ -- Target Hook: void * TARGET_GET_PCH_VALIDITY (size_t *SZ)
+     This hook returns a pointer to the data needed by
+     'TARGET_PCH_VALID_P' and sets '*SZ' to the size of the data in
+     bytes.
+
+ -- Target Hook: const char * TARGET_PCH_VALID_P (const void *DATA,
+          size_t SZ)
+     This hook checks whether the options used to create a PCH file are
+     compatible with the current settings.  It returns 'NULL' if so and
+     a suitable error message if not.  Error messages will be presented
+     to the user and must be localized using '_(MSG)'.
+
+     DATA is the data that was returned by 'TARGET_GET_PCH_VALIDITY'
+     when the PCH file was created and SZ is the size of that data in
+     bytes.  It's safe to assume that the data was created by the same
+     version of the compiler, so no format checking is needed.
+
+     The default definition of 'default_pch_valid_p' should be suitable
+     for most targets.
+
+ -- Target Hook: const char * TARGET_CHECK_PCH_TARGET_FLAGS (int
+          PCH_FLAGS)
+     If this hook is nonnull, the default implementation of
+     'TARGET_PCH_VALID_P' will use it to check for compatible values of
+     'target_flags'.  PCH_FLAGS specifies the value that 'target_flags'
+     had when the PCH file was created.  The return value is the same as
+     for 'TARGET_PCH_VALID_P'.
+
+ -- Target Hook: void TARGET_PREPARE_PCH_SAVE (void)
+     Called before writing out a PCH file.  If the target has some
+     garbage-collected data that needs to be in a particular state on
+     PCH loads, it can use this hook to enforce that state.  Very few
+     targets need to do anything here.
+
+
+File: gccint.info,  Node: C++ ABI,  Next: Named Address Spaces,  Prev: PCH Target,  Up: Target Macros
+
+17.29 C++ ABI parameters
+========================
+
+ -- Target Hook: tree TARGET_CXX_GUARD_TYPE (void)
+     Define this hook to override the integer type used for guard
+     variables.  These are used to implement one-time construction of
+     static objects.  The default is long_long_integer_type_node.
+
+ -- Target Hook: bool TARGET_CXX_GUARD_MASK_BIT (void)
+     This hook determines how guard variables are used.  It should
+     return 'false' (the default) if the first byte should be used.  A
+     return value of 'true' indicates that only the least significant
+     bit should be used.
+
+ -- Target Hook: tree TARGET_CXX_GET_COOKIE_SIZE (tree TYPE)
+     This hook returns the size of the cookie to use when allocating an
+     array whose elements have the indicated TYPE.  Assumes that it is
+     already known that a cookie is needed.  The default is 'max(sizeof
+     (size_t), alignof(type))', as defined in section 2.7 of the
+     IA64/Generic C++ ABI.
+
+ -- Target Hook: bool TARGET_CXX_COOKIE_HAS_SIZE (void)
+     This hook should return 'true' if the element size should be stored
+     in array cookies.  The default is to return 'false'.
+
+ -- Target Hook: int TARGET_CXX_IMPORT_EXPORT_CLASS (tree TYPE, int
+          IMPORT_EXPORT)
+     If defined by a backend this hook allows the decision made to
+     export class TYPE to be overruled.  Upon entry IMPORT_EXPORT will
+     contain 1 if the class is going to be exported, -1 if it is going
+     to be imported and 0 otherwise.  This function should return the
+     modified value and perform any other actions necessary to support
+     the backend's targeted operating system.
+
+ -- Target Hook: bool TARGET_CXX_CDTOR_RETURNS_THIS (void)
+     This hook should return 'true' if constructors and destructors
+     return the address of the object created/destroyed.  The default is
+     to return 'false'.
+
+ -- Target Hook: bool TARGET_CXX_KEY_METHOD_MAY_BE_INLINE (void)
+     This hook returns true if the key method for a class (i.e., the
+     method which, if defined in the current translation unit, causes
+     the virtual table to be emitted) may be an inline function.  Under
+     the standard Itanium C++ ABI the key method may be an inline
+     function so long as the function is not declared inline in the
+     class definition.  Under some variants of the ABI, an inline
+     function can never be the key method.  The default is to return
+     'true'.
+
+ -- Target Hook: void TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY (tree
+          DECL)
+     DECL is a virtual table, virtual table table, typeinfo object, or
+     other similar implicit class data object that will be emitted with
+     external linkage in this translation unit.  No ELF visibility has
+     been explicitly specified.  If the target needs to specify a
+     visibility other than that of the containing class, use this hook
+     to set 'DECL_VISIBILITY' and 'DECL_VISIBILITY_SPECIFIED'.
+
+ -- Target Hook: bool TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT (void)
+     This hook returns true (the default) if virtual tables and other
+     similar implicit class data objects are always COMDAT if they have
+     external linkage.  If this hook returns false, then class data for
+     classes whose virtual table will be emitted in only one translation
+     unit will not be COMDAT.
+
+ -- Target Hook: bool TARGET_CXX_LIBRARY_RTTI_COMDAT (void)
+     This hook returns true (the default) if the RTTI information for
+     the basic types which is defined in the C++ runtime should always
+     be COMDAT, false if it should not be COMDAT.
+
+ -- Target Hook: bool TARGET_CXX_USE_AEABI_ATEXIT (void)
+     This hook returns true if '__aeabi_atexit' (as defined by the ARM
+     EABI) should be used to register static destructors when
+     '-fuse-cxa-atexit' is in effect.  The default is to return false to
+     use '__cxa_atexit'.
+
+ -- Target Hook: bool TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT (void)
+     This hook returns true if the target 'atexit' function can be used
+     in the same manner as '__cxa_atexit' to register C++ static
+     destructors.  This requires that 'atexit'-registered functions in
+     shared libraries are run in the correct order when the libraries
+     are unloaded.  The default is to return false.
+
+ -- Target Hook: void TARGET_CXX_ADJUST_CLASS_AT_DEFINITION (tree TYPE)
+     TYPE is a C++ class (i.e., RECORD_TYPE or UNION_TYPE) that has just
+     been defined.  Use this hook to make adjustments to the class (eg,
+     tweak visibility or perform any other required target
+     modifications).
+
+ -- Target Hook: tree TARGET_CXX_DECL_MANGLING_CONTEXT (const_tree DECL)
+     Return target-specific mangling context of DECL or 'NULL_TREE'.
+
+
+File: gccint.info,  Node: Named Address Spaces,  Next: Misc,  Prev: C++ ABI,  Up: Target Macros
+
+17.30 Adding support for named address spaces
+=============================================
+
+The draft technical report of the ISO/IEC JTC1 S22 WG14 N1275 standards
+committee, 'Programming Languages - C - Extensions to support embedded
+processors', specifies a syntax for embedded processors to specify
+alternate address spaces.  You can configure a GCC port to support
+section 5.1 of the draft report to add support for address spaces other
+than the default address space.  These address spaces are new keywords
+that are similar to the 'volatile' and 'const' type attributes.
+
+ Pointers to named address spaces can have a different size than
+pointers to the generic address space.
+
+ For example, the SPU port uses the '__ea' address space to refer to
+memory in the host processor, rather than memory local to the SPU
+processor.  Access to memory in the '__ea' address space involves
+issuing DMA operations to move data between the host processor and the
+local processor memory address space.  Pointers in the '__ea' address
+space are either 32 bits or 64 bits based on the '-mea32' or '-mea64'
+switches (native SPU pointers are always 32 bits).
+
+ Internally, address spaces are represented as a small integer in the
+range 0 to 15 with address space 0 being reserved for the generic
+address space.
+
+ To register a named address space qualifier keyword with the C front
+end, the target may call the 'c_register_addr_space' routine.  For
+example, the SPU port uses the following to declare '__ea' as the
+keyword for named address space #1:
+     #define ADDR_SPACE_EA 1
+     c_register_addr_space ("__ea", ADDR_SPACE_EA);
+
+ -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_POINTER_MODE
+          (addr_space_t ADDRESS_SPACE)
+     Define this to return the machine mode to use for pointers to
+     ADDRESS_SPACE if the target supports named address spaces.  The
+     default version of this hook returns 'ptr_mode' for the generic
+     address space only.
+
+ -- Target Hook: enum machine_mode TARGET_ADDR_SPACE_ADDRESS_MODE
+          (addr_space_t ADDRESS_SPACE)
+     Define this to return the machine mode to use for addresses in
+     ADDRESS_SPACE if the target supports named address spaces.  The
+     default version of this hook returns 'Pmode' for the generic
+     address space only.
+
+ -- Target Hook: bool TARGET_ADDR_SPACE_VALID_POINTER_MODE (enum
+          machine_mode MODE, addr_space_t AS)
+     Define this to return nonzero if the port can handle pointers with
+     machine mode MODE to address space AS.  This target hook is the
+     same as the 'TARGET_VALID_POINTER_MODE' target hook, except that it
+     includes explicit named address space support.  The default version
+     of this hook returns true for the modes returned by either the
+     'TARGET_ADDR_SPACE_POINTER_MODE' or
+     'TARGET_ADDR_SPACE_ADDRESS_MODE' target hooks for the given address
+     space.
+
+ -- Target Hook: bool TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P (enum
+          machine_mode MODE, rtx EXP, bool STRICT, addr_space_t AS)
+     Define this to return true if EXP is a valid address for mode MODE
+     in the named address space AS.  The STRICT parameter says whether
+     strict addressing is in effect after reload has finished.  This
+     target hook is the same as the 'TARGET_LEGITIMATE_ADDRESS_P' target
+     hook, except that it includes explicit named address space support.
+
+ -- Target Hook: rtx TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS (rtx X, rtx
+          OLDX, enum machine_mode MODE, addr_space_t AS)
+     Define this to modify an invalid address X to be a valid address
+     with mode MODE in the named address space AS.  This target hook is
+     the same as the 'TARGET_LEGITIMIZE_ADDRESS' target hook, except
+     that it includes explicit named address space support.
+
+ -- Target Hook: bool TARGET_ADDR_SPACE_SUBSET_P (addr_space_t SUBSET,
+          addr_space_t SUPERSET)
+     Define this to return whether the SUBSET named address space is
+     contained within the SUPERSET named address space.  Pointers to a
+     named address space that is a subset of another named address space
+     will be converted automatically without a cast if used together in
+     arithmetic operations.  Pointers to a superset address space can be
+     converted to pointers to a subset address space via explicit casts.
+
+ -- Target Hook: rtx TARGET_ADDR_SPACE_CONVERT (rtx OP, tree FROM_TYPE,
+          tree TO_TYPE)
+     Define this to convert the pointer expression represented by the
+     RTL OP with type FROM_TYPE that points to a named address space to
+     a new pointer expression with type TO_TYPE that points to a
+     different named address space.  When this hook it called, it is
+     guaranteed that one of the two address spaces is a subset of the
+     other, as determined by the 'TARGET_ADDR_SPACE_SUBSET_P' target
+     hook.
+
+
+File: gccint.info,  Node: Misc,  Prev: Named Address Spaces,  Up: Target Macros
+
+17.31 Miscellaneous Parameters
+==============================
+
+Here are several miscellaneous parameters.
+
+ -- Macro: HAS_LONG_COND_BRANCH
+     Define this boolean macro to indicate whether or not your
+     architecture has conditional branches that can span all of memory.
+     It is used in conjunction with an optimization that partitions hot
+     and cold basic blocks into separate sections of the executable.  If
+     this macro is set to false, gcc will convert any conditional
+     branches that attempt to cross between sections into unconditional
+     branches or indirect jumps.
+
+ -- Macro: HAS_LONG_UNCOND_BRANCH
+     Define this boolean macro to indicate whether or not your
+     architecture has unconditional branches that can span all of
+     memory.  It is used in conjunction with an optimization that
+     partitions hot and cold basic blocks into separate sections of the
+     executable.  If this macro is set to false, gcc will convert any
+     unconditional branches that attempt to cross between sections into
+     indirect jumps.
+
+ -- Macro: CASE_VECTOR_MODE
+     An alias for a machine mode name.  This is the machine mode that
+     elements of a jump-table should have.
+
+ -- Macro: CASE_VECTOR_SHORTEN_MODE (MIN_OFFSET, MAX_OFFSET, BODY)
+     Optional: return the preferred mode for an 'addr_diff_vec' when the
+     minimum and maximum offset are known.  If you define this, it
+     enables extra code in branch shortening to deal with
+     'addr_diff_vec'.  To make this work, you also have to define
+     'INSN_ALIGN' and make the alignment for 'addr_diff_vec' explicit.
+     The BODY argument is provided so that the offset_unsigned and scale
+     flags can be updated.
+
+ -- Macro: CASE_VECTOR_PC_RELATIVE
+     Define this macro to be a C expression to indicate when jump-tables
+     should contain relative addresses.  You need not define this macro
+     if jump-tables never contain relative addresses, or jump-tables
+     should contain relative addresses only when '-fPIC' or '-fPIC' is
+     in effect.
+
+ -- Target Hook: unsigned int TARGET_CASE_VALUES_THRESHOLD (void)
+     This function return the smallest number of different values for
+     which it is best to use a jump-table instead of a tree of
+     conditional branches.  The default is four for machines with a
+     'casesi' instruction and five otherwise.  This is best for most
+     machines.
+
+ -- Macro: WORD_REGISTER_OPERATIONS
+     Define this macro if operations between registers with integral
+     mode smaller than a word are always performed on the entire
+     register.  Most RISC machines have this property and most CISC
+     machines do not.
+
+ -- Macro: LOAD_EXTEND_OP (MEM_MODE)
+     Define this macro to be a C expression indicating when insns that
+     read memory in MEM_MODE, an integral mode narrower than a word, set
+     the bits outside of MEM_MODE to be either the sign-extension or the
+     zero-extension of the data read.  Return 'SIGN_EXTEND' for values
+     of MEM_MODE for which the insn sign-extends, 'ZERO_EXTEND' for
+     which it zero-extends, and 'UNKNOWN' for other modes.
+
+     This macro is not called with MEM_MODE non-integral or with a width
+     greater than or equal to 'BITS_PER_WORD', so you may return any
+     value in this case.  Do not define this macro if it would always
+     return 'UNKNOWN'.  On machines where this macro is defined, you
+     will normally define it as the constant 'SIGN_EXTEND' or
+     'ZERO_EXTEND'.
+
+     You may return a non-'UNKNOWN' value even if for some hard
+     registers the sign extension is not performed, if for the
+     'REGNO_REG_CLASS' of these hard registers
+     'CANNOT_CHANGE_MODE_CLASS' returns nonzero when the FROM mode is
+     MEM_MODE and the TO mode is any integral mode larger than this but
+     not larger than 'word_mode'.
+
+     You must return 'UNKNOWN' if for some hard registers that allow
+     this mode, 'CANNOT_CHANGE_MODE_CLASS' says that they cannot change
+     to 'word_mode', but that they can change to another integral mode
+     that is larger then MEM_MODE but still smaller than 'word_mode'.
+
+ -- Macro: SHORT_IMMEDIATES_SIGN_EXTEND
+     Define this macro if loading short immediate values into registers
+     sign extends.
+
+ -- Target Hook: unsigned int TARGET_MIN_DIVISIONS_FOR_RECIP_MUL (enum
+          machine_mode MODE)
+     When '-ffast-math' is in effect, GCC tries to optimize divisions by
+     the same divisor, by turning them into multiplications by the
+     reciprocal.  This target hook specifies the minimum number of
+     divisions that should be there for GCC to perform the optimization
+     for a variable of mode MODE.  The default implementation returns 3
+     if the machine has an instruction for the division, and 2 if it
+     does not.
+
+ -- Macro: MOVE_MAX
+     The maximum number of bytes that a single instruction can move
+     quickly between memory and registers or between two memory
+     locations.
+
+ -- Macro: MAX_MOVE_MAX
+     The maximum number of bytes that a single instruction can move
+     quickly between memory and registers or between two memory
+     locations.  If this is undefined, the default is 'MOVE_MAX'.
+     Otherwise, it is the constant value that is the largest value that
+     'MOVE_MAX' can have at run-time.
+
+ -- Macro: SHIFT_COUNT_TRUNCATED
+     A C expression that is nonzero if on this machine the number of
+     bits actually used for the count of a shift operation is equal to
+     the number of bits needed to represent the size of the object being
+     shifted.  When this macro is nonzero, the compiler will assume that
+     it is safe to omit a sign-extend, zero-extend, and certain bitwise
+     'and' instructions that truncates the count of a shift operation.
+     On machines that have instructions that act on bit-fields at
+     variable positions, which may include 'bit test' instructions, a
+     nonzero 'SHIFT_COUNT_TRUNCATED' also enables deletion of
+     truncations of the values that serve as arguments to bit-field
+     instructions.
+
+     If both types of instructions truncate the count (for shifts) and
+     position (for bit-field operations), or if no variable-position
+     bit-field instructions exist, you should define this macro.
+
+     However, on some machines, such as the 80386 and the 680x0,
+     truncation only applies to shift operations and not the (real or
+     pretended) bit-field operations.  Define 'SHIFT_COUNT_TRUNCATED' to
+     be zero on such machines.  Instead, add patterns to the 'md' file
+     that include the implied truncation of the shift instructions.
+
+     You need not define this macro if it would always have the value of
+     zero.
+
+ -- Target Hook: unsigned HOST_WIDE_INT TARGET_SHIFT_TRUNCATION_MASK
+          (enum machine_mode MODE)
+     This function describes how the standard shift patterns for MODE
+     deal with shifts by negative amounts or by more than the width of
+     the mode.  *Note shift patterns::.
+
+     On many machines, the shift patterns will apply a mask M to the
+     shift count, meaning that a fixed-width shift of X by Y is
+     equivalent to an arbitrary-width shift of X by Y & M.  If this is
+     true for mode MODE, the function should return M, otherwise it
+     should return 0.  A return value of 0 indicates that no particular
+     behavior is guaranteed.
+
+     Note that, unlike 'SHIFT_COUNT_TRUNCATED', this function does _not_
+     apply to general shift rtxes; it applies only to instructions that
+     are generated by the named shift patterns.
+
+     The default implementation of this function returns
+     'GET_MODE_BITSIZE (MODE) - 1' if 'SHIFT_COUNT_TRUNCATED' and 0
+     otherwise.  This definition is always safe, but if
+     'SHIFT_COUNT_TRUNCATED' is false, and some shift patterns
+     nevertheless truncate the shift count, you may get better code by
+     overriding it.
+
+ -- Macro: TRULY_NOOP_TRUNCATION (OUTPREC, INPREC)
+     A C expression which is nonzero if on this machine it is safe to
+     "convert" an integer of INPREC bits to one of OUTPREC bits (where
+     OUTPREC is smaller than INPREC) by merely operating on it as if it
+     had only OUTPREC bits.
+
+     On many machines, this expression can be 1.
+
+     When 'TRULY_NOOP_TRUNCATION' returns 1 for a pair of sizes for
+     modes for which 'MODES_TIEABLE_P' is 0, suboptimal code can result.
+     If this is the case, making 'TRULY_NOOP_TRUNCATION' return 0 in
+     such cases may improve things.
+
+ -- Target Hook: int TARGET_MODE_REP_EXTENDED (enum machine_mode MODE,
+          enum machine_mode REP_MODE)
+     The representation of an integral mode can be such that the values
+     are always extended to a wider integral mode.  Return 'SIGN_EXTEND'
+     if values of MODE are represented in sign-extended form to
+     REP_MODE.  Return 'UNKNOWN' otherwise.  (Currently, none of the
+     targets use zero-extended representation this way so unlike
+     'LOAD_EXTEND_OP', 'TARGET_MODE_REP_EXTENDED' is expected to return
+     either 'SIGN_EXTEND' or 'UNKNOWN'.  Also no target extends MODE to
+     REP_MODE so that REP_MODE is not the next widest integral mode and
+     currently we take advantage of this fact.)
+
+     Similarly to 'LOAD_EXTEND_OP' you may return a non-'UNKNOWN' value
+     even if the extension is not performed on certain hard registers as
+     long as for the 'REGNO_REG_CLASS' of these hard registers
+     'CANNOT_CHANGE_MODE_CLASS' returns nonzero.
+
+     Note that 'TARGET_MODE_REP_EXTENDED' and 'LOAD_EXTEND_OP' describe
+     two related properties.  If you define 'TARGET_MODE_REP_EXTENDED
+     (mode, word_mode)' you probably also want to define 'LOAD_EXTEND_OP
+     (mode)' to return the same type of extension.
+
+     In order to enforce the representation of 'mode',
+     'TRULY_NOOP_TRUNCATION' should return false when truncating to
+     'mode'.
+
+ -- Macro: STORE_FLAG_VALUE
+     A C expression describing the value returned by a comparison
+     operator with an integral mode and stored by a store-flag
+     instruction ('cstoreMODE4') when the condition is true.  This
+     description must apply to _all_ the 'cstoreMODE4' patterns and all
+     the comparison operators whose results have a 'MODE_INT' mode.
+
+     A value of 1 or -1 means that the instruction implementing the
+     comparison operator returns exactly 1 or -1 when the comparison is
+     true and 0 when the comparison is false.  Otherwise, the value
+     indicates which bits of the result are guaranteed to be 1 when the
+     comparison is true.  This value is interpreted in the mode of the
+     comparison operation, which is given by the mode of the first
+     operand in the 'cstoreMODE4' pattern.  Either the low bit or the
+     sign bit of 'STORE_FLAG_VALUE' be on.  Presently, only those bits
+     are used by the compiler.
+
+     If 'STORE_FLAG_VALUE' is neither 1 or -1, the compiler will
+     generate code that depends only on the specified bits.  It can also
+     replace comparison operators with equivalent operations if they
+     cause the required bits to be set, even if the remaining bits are
+     undefined.  For example, on a machine whose comparison operators
+     return an 'SImode' value and where 'STORE_FLAG_VALUE' is defined as
+     '0x80000000', saying that just the sign bit is relevant, the
+     expression
+
+          (ne:SI (and:SI X (const_int POWER-OF-2)) (const_int 0))
+
+     can be converted to
+
+          (ashift:SI X (const_int N))
+
+     where N is the appropriate shift count to move the bit being tested
+     into the sign bit.
+
+     There is no way to describe a machine that always sets the
+     low-order bit for a true value, but does not guarantee the value of
+     any other bits, but we do not know of any machine that has such an
+     instruction.  If you are trying to port GCC to such a machine,
+     include an instruction to perform a logical-and of the result with
+     1 in the pattern for the comparison operators and let us know at
+     <gcc@gcc.gnu.org>.
+
+     Often, a machine will have multiple instructions that obtain a
+     value from a comparison (or the condition codes).  Here are rules
+     to guide the choice of value for 'STORE_FLAG_VALUE', and hence the
+     instructions to be used:
+
+        * Use the shortest sequence that yields a valid definition for
+          'STORE_FLAG_VALUE'.  It is more efficient for the compiler to
+          "normalize" the value (convert it to, e.g., 1 or 0) than for
+          the comparison operators to do so because there may be
+          opportunities to combine the normalization with other
+          operations.
+
+        * For equal-length sequences, use a value of 1 or -1, with -1
+          being slightly preferred on machines with expensive jumps and
+          1 preferred on other machines.
+
+        * As a second choice, choose a value of '0x80000001' if
+          instructions exist that set both the sign and low-order bits
+          but do not define the others.
+
+        * Otherwise, use a value of '0x80000000'.
+
+     Many machines can produce both the value chosen for
+     'STORE_FLAG_VALUE' and its negation in the same number of
+     instructions.  On those machines, you should also define a pattern
+     for those cases, e.g., one matching
+
+          (set A (neg:M (ne:M B C)))
+
+     Some machines can also perform 'and' or 'plus' operations on
+     condition code values with less instructions than the corresponding
+     'cstoreMODE4' insn followed by 'and' or 'plus'.  On those machines,
+     define the appropriate patterns.  Use the names 'incscc' and
+     'decscc', respectively, for the patterns which perform 'plus' or
+     'minus' operations on condition code values.  See 'rs6000.md' for
+     some examples.  The GNU Superoptimizer can be used to find such
+     instruction sequences on other machines.
+
+     If this macro is not defined, the default value, 1, is used.  You
+     need not define 'STORE_FLAG_VALUE' if the machine has no store-flag
+     instructions, or if the value generated by these instructions is 1.
+
+ -- Macro: FLOAT_STORE_FLAG_VALUE (MODE)
+     A C expression that gives a nonzero 'REAL_VALUE_TYPE' value that is
+     returned when comparison operators with floating-point results are
+     true.  Define this macro on machines that have comparison
+     operations that return floating-point values.  If there are no such
+     operations, do not define this macro.
+
+ -- Macro: VECTOR_STORE_FLAG_VALUE (MODE)
+     A C expression that gives a rtx representing the nonzero true
+     element for vector comparisons.  The returned rtx should be valid
+     for the inner mode of MODE which is guaranteed to be a vector mode.
+     Define this macro on machines that have vector comparison
+     operations that return a vector result.  If there are no such
+     operations, do not define this macro.  Typically, this macro is
+     defined as 'const1_rtx' or 'constm1_rtx'.  This macro may return
+     'NULL_RTX' to prevent the compiler optimizing such vector
+     comparison operations for the given mode.
+
+ -- Macro: CLZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
+ -- Macro: CTZ_DEFINED_VALUE_AT_ZERO (MODE, VALUE)
+     A C expression that indicates whether the architecture defines a
+     value for 'clz' or 'ctz' with a zero operand.  A result of '0'
+     indicates the value is undefined.  If the value is defined for only
+     the RTL expression, the macro should evaluate to '1'; if the value
+     applies also to the corresponding optab entry (which is normally
+     the case if it expands directly into the corresponding RTL), then
+     the macro should evaluate to '2'.  In the cases where the value is
+     defined, VALUE should be set to this value.
+
+     If this macro is not defined, the value of 'clz' or 'ctz' at zero
+     is assumed to be undefined.
+
+     This macro must be defined if the target's expansion for 'ffs'
+     relies on a particular value to get correct results.  Otherwise it
+     is not necessary, though it may be used to optimize some corner
+     cases, and to provide a default expansion for the 'ffs' optab.
+
+     Note that regardless of this macro the "definedness" of 'clz' and
+     'ctz' at zero do _not_ extend to the builtin functions visible to
+     the user.  Thus one may be free to adjust the value at will to
+     match the target expansion of these operations without fear of
+     breaking the API.
+
+ -- Macro: Pmode
+     An alias for the machine mode for pointers.  On most machines,
+     define this to be the integer mode corresponding to the width of a
+     hardware pointer; 'SImode' on 32-bit machine or 'DImode' on 64-bit
+     machines.  On some machines you must define this to be one of the
+     partial integer modes, such as 'PSImode'.
+
+     The width of 'Pmode' must be at least as large as the value of
+     'POINTER_SIZE'.  If it is not equal, you must define the macro
+     'POINTERS_EXTEND_UNSIGNED' to specify how pointers are extended to
+     'Pmode'.
+
+ -- Macro: FUNCTION_MODE
+     An alias for the machine mode used for memory references to
+     functions being called, in 'call' RTL expressions.  On most CISC
+     machines, where an instruction can begin at any byte address, this
+     should be 'QImode'.  On most RISC machines, where all instructions
+     have fixed size and alignment, this should be a mode with the same
+     size and alignment as the machine instruction words - typically
+     'SImode' or 'HImode'.
+
+ -- Macro: STDC_0_IN_SYSTEM_HEADERS
+     In normal operation, the preprocessor expands '__STDC__' to the
+     constant 1, to signify that GCC conforms to ISO Standard C.  On
+     some hosts, like Solaris, the system compiler uses a different
+     convention, where '__STDC__' is normally 0, but is 1 if the user
+     specifies strict conformance to the C Standard.
+
+     Defining 'STDC_0_IN_SYSTEM_HEADERS' makes GNU CPP follows the host
+     convention when processing system header files, but when processing
+     user files '__STDC__' will always expand to 1.
+
+ -- C Target Hook: const char * TARGET_C_PREINCLUDE (void)
+     Define this hook to return the name of a header file to be included
+     at the start of all compilations, as if it had been included with
+     '#include <FILE>'.  If this hook returns 'NULL', or is not defined,
+     or the header is not found, or if the user specifies
+     '-ffreestanding' or '-nostdinc', no header is included.
+
+     This hook can be used together with a header provided by the system
+     C library to implement ISO C requirements for certain macros to be
+     predefined that describe properties of the whole implementation
+     rather than just the compiler.
+
+ -- C Target Hook: bool TARGET_CXX_IMPLICIT_EXTERN_C (const char*)
+     Define this hook to add target-specific C++ implicit extern C
+     functions.  If this function returns true for the name of a
+     file-scope function, that function implicitly gets extern "C"
+     linkage rather than whatever language linkage the declaration would
+     normally have.  An example of such function is WinMain on Win32
+     targets.
+
+ -- Macro: NO_IMPLICIT_EXTERN_C
+     Define this macro if the system header files support C++ as well as
+     C.  This macro inhibits the usual method of using system header
+     files in C++, which is to pretend that the file's contents are
+     enclosed in 'extern "C" {...}'.
+
+ -- Macro: REGISTER_TARGET_PRAGMAS ()
+     Define this macro if you want to implement any target-specific
+     pragmas.  If defined, it is a C expression which makes a series of
+     calls to 'c_register_pragma' or 'c_register_pragma_with_expansion'
+     for each pragma.  The macro may also do any setup required for the
+     pragmas.
+
+     The primary reason to define this macro is to provide compatibility
+     with other compilers for the same target.  In general, we
+     discourage definition of target-specific pragmas for GCC.
+
+     If the pragma can be implemented by attributes then you should
+     consider defining the target hook 'TARGET_INSERT_ATTRIBUTES' as
+     well.
+
+     Preprocessor macros that appear on pragma lines are not expanded.
+     All '#pragma' directives that do not match any registered pragma
+     are silently ignored, unless the user specifies
+     '-Wunknown-pragmas'.
+
+ -- Function: void c_register_pragma (const char *SPACE, const char
+          *NAME, void (*CALLBACK) (struct cpp_reader *))
+ -- Function: void c_register_pragma_with_expansion (const char *SPACE,
+          const char *NAME, void (*CALLBACK) (struct cpp_reader *))
+
+     Each call to 'c_register_pragma' or
+     'c_register_pragma_with_expansion' establishes one pragma.  The
+     CALLBACK routine will be called when the preprocessor encounters a
+     pragma of the form
+
+          #pragma [SPACE] NAME ...
+
+     SPACE is the case-sensitive namespace of the pragma, or 'NULL' to
+     put the pragma in the global namespace.  The callback routine
+     receives PFILE as its first argument, which can be passed on to
+     cpplib's functions if necessary.  You can lex tokens after the NAME
+     by calling 'pragma_lex'.  Tokens that are not read by the callback
+     will be silently ignored.  The end of the line is indicated by a
+     token of type 'CPP_EOF'.  Macro expansion occurs on the arguments
+     of pragmas registered with 'c_register_pragma_with_expansion' but
+     not on the arguments of pragmas registered with
+     'c_register_pragma'.
+
+     Note that the use of 'pragma_lex' is specific to the C and C++
+     compilers.  It will not work in the Java or Fortran compilers, or
+     any other language compilers for that matter.  Thus if 'pragma_lex'
+     is going to be called from target-specific code, it must only be
+     done so when building the C and C++ compilers.  This can be done by
+     defining the variables 'c_target_objs' and 'cxx_target_objs' in the
+     target entry in the 'config.gcc' file.  These variables should name
+     the target-specific, language-specific object file which contains
+     the code that uses 'pragma_lex'.  Note it will also be necessary to
+     add a rule to the makefile fragment pointed to by 'tmake_file' that
+     shows how to build this object file.
+
+ -- Macro: HANDLE_PRAGMA_PACK_WITH_EXPANSION
+     Define this macro if macros should be expanded in the arguments of
+     '#pragma pack'.
+
+ -- Macro: TARGET_DEFAULT_PACK_STRUCT
+     If your target requires a structure packing default other than 0
+     (meaning the machine default), define this macro to the necessary
+     value (in bytes).  This must be a value that would also be valid to
+     use with '#pragma pack()' (that is, a small power of two).
+
+ -- Macro: DOLLARS_IN_IDENTIFIERS
+     Define this macro to control use of the character '$' in identifier
+     names for the C family of languages.  0 means '$' is not allowed by
+     default; 1 means it is allowed.  1 is the default; there is no need
+     to define this macro in that case.
+
+ -- Macro: INSN_SETS_ARE_DELAYED (INSN)
+     Define this macro as a C expression that is nonzero if it is safe
+     for the delay slot scheduler to place instructions in the delay
+     slot of INSN, even if they appear to use a resource set or
+     clobbered in INSN.  INSN is always a 'jump_insn' or an 'insn'; GCC
+     knows that every 'call_insn' has this behavior.  On machines where
+     some 'insn' or 'jump_insn' is really a function call and hence has
+     this behavior, you should define this macro.
+
+     You need not define this macro if it would always return zero.
+
+ -- Macro: INSN_REFERENCES_ARE_DELAYED (INSN)
+     Define this macro as a C expression that is nonzero if it is safe
+     for the delay slot scheduler to place instructions in the delay
+     slot of INSN, even if they appear to set or clobber a resource
+     referenced in INSN.  INSN is always a 'jump_insn' or an 'insn'.  On
+     machines where some 'insn' or 'jump_insn' is really a function call
+     and its operands are registers whose use is actually in the
+     subroutine it calls, you should define this macro.  Doing so allows
+     the delay slot scheduler to move instructions which copy arguments
+     into the argument registers into the delay slot of INSN.
+
+     You need not define this macro if it would always return zero.
+
+ -- Macro: MULTIPLE_SYMBOL_SPACES
+     Define this macro as a C expression that is nonzero if, in some
+     cases, global symbols from one translation unit may not be bound to
+     undefined symbols in another translation unit without user
+     intervention.  For instance, under Microsoft Windows symbols must
+     be explicitly imported from shared libraries (DLLs).
+
+     You need not define this macro if it would always evaluate to zero.
+
+ -- Target Hook: tree TARGET_MD_ASM_CLOBBERS (tree OUTPUTS, tree INPUTS,
+          tree CLOBBERS)
+     This target hook should add to CLOBBERS 'STRING_CST' trees for any
+     hard regs the port wishes to automatically clobber for an asm.  It
+     should return the result of the last 'tree_cons' used to add a
+     clobber.  The OUTPUTS, INPUTS and CLOBBER lists are the
+     corresponding parameters to the asm and may be inspected to avoid
+     clobbering a register that is an input or output of the asm.  You
+     can use 'tree_overlaps_hard_reg_set', declared in 'tree.h', to test
+     for overlap with regards to asm-declared registers.
+
+ -- Macro: MATH_LIBRARY
+     Define this macro as a C string constant for the linker argument to
+     link in the system math library, minus the initial '"-l"', or '""'
+     if the target does not have a separate math library.
+
+     You need only define this macro if the default of '"m"' is wrong.
+
+ -- Macro: LIBRARY_PATH_ENV
+     Define this macro as a C string constant for the environment
+     variable that specifies where the linker should look for libraries.
+
+     You need only define this macro if the default of '"LIBRARY_PATH"'
+     is wrong.
+
+ -- Macro: TARGET_POSIX_IO
+     Define this macro if the target supports the following POSIX file
+     functions, access, mkdir and file locking with fcntl / F_SETLKW.
+     Defining 'TARGET_POSIX_IO' will enable the test coverage code to
+     use file locking when exiting a program, which avoids race
+     conditions if the program has forked.  It will also create
+     directories at run-time for cross-profiling.
+
+ -- Macro: MAX_CONDITIONAL_EXECUTE
+
+     A C expression for the maximum number of instructions to execute
+     via conditional execution instructions instead of a branch.  A
+     value of 'BRANCH_COST'+1 is the default if the machine does not use
+     cc0, and 1 if it does use cc0.
+
+ -- Macro: IFCVT_MODIFY_TESTS (CE_INFO, TRUE_EXPR, FALSE_EXPR)
+     Used if the target needs to perform machine-dependent modifications
+     on the conditionals used for turning basic blocks into
+     conditionally executed code.  CE_INFO points to a data structure,
+     'struct ce_if_block', which contains information about the
+     currently processed blocks.  TRUE_EXPR and FALSE_EXPR are the tests
+     that are used for converting the then-block and the else-block,
+     respectively.  Set either TRUE_EXPR or FALSE_EXPR to a null pointer
+     if the tests cannot be converted.
+
+ -- Macro: IFCVT_MODIFY_MULTIPLE_TESTS (CE_INFO, BB, TRUE_EXPR,
+          FALSE_EXPR)
+     Like 'IFCVT_MODIFY_TESTS', but used when converting more
+     complicated if-statements into conditions combined by 'and' and
+     'or' operations.  BB contains the basic block that contains the
+     test that is currently being processed and about to be turned into
+     a condition.
+
+ -- Macro: IFCVT_MODIFY_INSN (CE_INFO, PATTERN, INSN)
+     A C expression to modify the PATTERN of an INSN that is to be
+     converted to conditional execution format.  CE_INFO points to a
+     data structure, 'struct ce_if_block', which contains information
+     about the currently processed blocks.
+
+ -- Macro: IFCVT_MODIFY_FINAL (CE_INFO)
+     A C expression to perform any final machine dependent modifications
+     in converting code to conditional execution.  The involved basic
+     blocks can be found in the 'struct ce_if_block' structure that is
+     pointed to by CE_INFO.
+
+ -- Macro: IFCVT_MODIFY_CANCEL (CE_INFO)
+     A C expression to cancel any machine dependent modifications in
+     converting code to conditional execution.  The involved basic
+     blocks can be found in the 'struct ce_if_block' structure that is
+     pointed to by CE_INFO.
+
+ -- Macro: IFCVT_MACHDEP_INIT (CE_INFO)
+     A C expression to initialize any machine specific data for
+     if-conversion of the if-block in the 'struct ce_if_block' structure
+     that is pointed to by CE_INFO.
+
+ -- Target Hook: void TARGET_MACHINE_DEPENDENT_REORG (void)
+     If non-null, this hook performs a target-specific pass over the
+     instruction stream.  The compiler will run it at all optimization
+     levels, just before the point at which it normally does
+     delayed-branch scheduling.
+
+     The exact purpose of the hook varies from target to target.  Some
+     use it to do transformations that are necessary for correctness,
+     such as laying out in-function constant pools or avoiding hardware
+     hazards.  Others use it as an opportunity to do some
+     machine-dependent optimizations.
+
+     You need not implement the hook if it has nothing to do.  The
+     default definition is null.
+
+ -- Target Hook: void TARGET_INIT_BUILTINS (void)
+     Define this hook if you have any machine-specific built-in
+     functions that need to be defined.  It should be a function that
+     performs the necessary setup.
+
+     Machine specific built-in functions can be useful to expand special
+     machine instructions that would otherwise not normally be generated
+     because they have no equivalent in the source language (for
+     example, SIMD vector instructions or prefetch instructions).
+
+     To create a built-in function, call the function
+     'lang_hooks.builtin_function' which is defined by the language
+     front end.  You can use any type nodes set up by
+     'build_common_tree_nodes'; only language front ends that use those
+     two functions will call 'TARGET_INIT_BUILTINS'.
+
+ -- Target Hook: tree TARGET_BUILTIN_DECL (unsigned CODE, bool
+          INITIALIZE_P)
+     Define this hook if you have any machine-specific built-in
+     functions that need to be defined.  It should be a function that
+     returns the builtin function declaration for the builtin function
+     code CODE.  If there is no such builtin and it cannot be
+     initialized at this time if INITIALIZE_P is true the function
+     should return 'NULL_TREE'.  If CODE is out of range the function
+     should return 'error_mark_node'.
+
+ -- Target Hook: rtx TARGET_EXPAND_BUILTIN (tree EXP, rtx TARGET, rtx
+          SUBTARGET, enum machine_mode MODE, int IGNORE)
+
+     Expand a call to a machine specific built-in function that was set
+     up by 'TARGET_INIT_BUILTINS'.  EXP is the expression for the
+     function call; the result should go to TARGET if that is
+     convenient, and have mode MODE if that is convenient.  SUBTARGET
+     may be used as the target for computing one of EXP's operands.
+     IGNORE is nonzero if the value is to be ignored.  This function
+     should return the result of the call to the built-in function.
+
+ -- Target Hook: tree TARGET_RESOLVE_OVERLOADED_BUILTIN (unsigned int
+          LOC, tree FNDECL, void *ARGLIST)
+     Select a replacement for a machine specific built-in function that
+     was set up by 'TARGET_INIT_BUILTINS'.  This is done _before_
+     regular type checking, and so allows the target to implement a
+     crude form of function overloading.  FNDECL is the declaration of
+     the built-in function.  ARGLIST is the list of arguments passed to
+     the built-in function.  The result is a complete expression that
+     implements the operation, usually another 'CALL_EXPR'.  ARGLIST
+     really has type 'VEC(tree,gc)*'
+
+ -- Target Hook: tree TARGET_FOLD_BUILTIN (tree FNDECL, int N_ARGS, tree
+          *ARGP, bool IGNORE)
+     Fold a call to a machine specific built-in function that was set up
+     by 'TARGET_INIT_BUILTINS'.  FNDECL is the declaration of the
+     built-in function.  N_ARGS is the number of arguments passed to the
+     function; the arguments themselves are pointed to by ARGP.  The
+     result is another tree, valid for both GIMPLE and GENERIC,
+     containing a simplified expression for the call's result.  If
+     IGNORE is true the value will be ignored.
+
+ -- Target Hook: bool TARGET_GIMPLE_FOLD_BUILTIN (gimple_stmt_iterator
+          *GSI)
+     Fold a call to a machine specific built-in function that was set up
+     by 'TARGET_INIT_BUILTINS'.  GSI points to the gimple statement
+     holding the function call.  Returns true if any change was made to
+     the GIMPLE stream.
+
+ -- Target Hook: int TARGET_COMPARE_VERSION_PRIORITY (tree DECL1, tree
+          DECL2)
+     This hook is used to compare the target attributes in two functions
+     to determine which function's features get higher priority.  This
+     is used during function multi-versioning to figure out the order in
+     which two versions must be dispatched.  A function version with a
+     higher priority is checked for dispatching earlier.  DECL1 and
+     DECL2 are the two function decls that will be compared.
+
+ -- Target Hook: tree TARGET_GET_FUNCTION_VERSIONS_DISPATCHER (void
+          *DECL)
+     This hook is used to get the dispatcher function for a set of
+     function versions.  The dispatcher function is called to invoke the
+     right function version at run-time.  DECL is one version from a set
+     of semantically identical versions.
+
+ -- Target Hook: tree TARGET_GENERATE_VERSION_DISPATCHER_BODY (void
+          *ARG)
+     This hook is used to generate the dispatcher logic to invoke the
+     right function version at run-time for a given set of function
+     versions.  ARG points to the callgraph node of the dispatcher
+     function whose body must be generated.
+
+ -- Target Hook: bool TARGET_CAN_USE_DOLOOP_P (double_int ITERATIONS,
+          double_int ITERATIONS_MAX, unsigned int LOOP_DEPTH, bool
+          ENTERED_AT_TOP)
+     Return true if it is possible to use low-overhead loops
+     ('doloop_end' and 'doloop_begin') for a particular loop.
+     ITERATIONS gives the exact number of iterations, or 0 if not known.
+     ITERATIONS_MAX gives the maximum number of iterations, or 0 if not
+     known.  LOOP_DEPTH is the nesting depth of the loop, with 1 for
+     innermost loops, 2 for loops that contain innermost loops, and so
+     on.  ENTERED_AT_TOP is true if the loop is only entered from the
+     top.
+
+     This hook is only used if 'doloop_end' is available.  The default
+     implementation returns true.  You can use
+     'can_use_doloop_if_innermost' if the loop must be the innermost,
+     and if there are no other restrictions.
+
+ -- Target Hook: const char * TARGET_INVALID_WITHIN_DOLOOP (const_rtx
+          INSN)
+
+     Take an instruction in INSN and return NULL if it is valid within a
+     low-overhead loop, otherwise return a string explaining why doloop
+     could not be applied.
+
+     Many targets use special registers for low-overhead looping.  For
+     any instruction that clobbers these this function should return a
+     string indicating the reason why the doloop could not be applied.
+     By default, the RTL loop optimizer does not use a present doloop
+     pattern for loops containing function calls or branch on table
+     instructions.
+
+ -- Target Hook: bool TARGET_LEGITIMATE_COMBINED_INSN (rtx INSN)
+     Take an instruction in INSN and return 'false' if the instruction
+     is not appropriate as a combination of two or more instructions.
+     The default is to accept all instructions.
+
+ -- Macro: MD_CAN_REDIRECT_BRANCH (BRANCH1, BRANCH2)
+
+     Take a branch insn in BRANCH1 and another in BRANCH2.  Return true
+     if redirecting BRANCH1 to the destination of BRANCH2 is possible.
+
+     On some targets, branches may have a limited range.  Optimizing the
+     filling of delay slots can result in branches being redirected, and
+     this may in turn cause a branch offset to overflow.
+
+ -- Target Hook: bool TARGET_CAN_FOLLOW_JUMP (const_rtx FOLLOWER,
+          const_rtx FOLLOWEE)
+     FOLLOWER and FOLLOWEE are JUMP_INSN instructions; return true if
+     FOLLOWER may be modified to follow FOLLOWEE; false, if it can't.
+     For example, on some targets, certain kinds of branches can't be
+     made to follow through a hot/cold partitioning.
+
+ -- Target Hook: bool TARGET_COMMUTATIVE_P (const_rtx X, int OUTER_CODE)
+     This target hook returns 'true' if X is considered to be
+     commutative.  Usually, this is just COMMUTATIVE_P (X), but the HP
+     PA doesn't consider PLUS to be commutative inside a MEM.
+     OUTER_CODE is the rtx code of the enclosing rtl, if known,
+     otherwise it is UNKNOWN.
+
+ -- Target Hook: rtx TARGET_ALLOCATE_INITIAL_VALUE (rtx HARD_REG)
+
+     When the initial value of a hard register has been copied in a
+     pseudo register, it is often not necessary to actually allocate
+     another register to this pseudo register, because the original hard
+     register or a stack slot it has been saved into can be used.
+     'TARGET_ALLOCATE_INITIAL_VALUE' is called at the start of register
+     allocation once for each hard register that had its initial value
+     copied by using 'get_func_hard_reg_initial_val' or
+     'get_hard_reg_initial_val'.  Possible values are 'NULL_RTX', if you
+     don't want to do any special allocation, a 'REG' rtx--that would
+     typically be the hard register itself, if it is known not to be
+     clobbered--or a 'MEM'.  If you are returning a 'MEM', this is only
+     a hint for the allocator; it might decide to use another register
+     anyways.  You may use 'current_function_is_leaf' or 'REG_N_SETS' in
+     the hook to determine if the hard register in question will not be
+     clobbered.  The default value of this hook is 'NULL', which
+     disables any special allocation.
+
+ -- Target Hook: int TARGET_UNSPEC_MAY_TRAP_P (const_rtx X, unsigned
+          FLAGS)
+     This target hook returns nonzero if X, an 'unspec' or
+     'unspec_volatile' operation, might cause a trap.  Targets can use
+     this hook to enhance precision of analysis for 'unspec' and
+     'unspec_volatile' operations.  You may call 'may_trap_p_1' to
+     analyze inner elements of X in which case FLAGS should be passed
+     along.
+
+ -- Target Hook: void TARGET_SET_CURRENT_FUNCTION (tree DECL)
+     The compiler invokes this hook whenever it changes its current
+     function context ('cfun').  You can define this function if the
+     back end needs to perform any initialization or reset actions on a
+     per-function basis.  For example, it may be used to implement
+     function attributes that affect register usage or code generation
+     patterns.  The argument DECL is the declaration for the new
+     function context, and may be null to indicate that the compiler has
+     left a function context and is returning to processing at the top
+     level.  The default hook function does nothing.
+
+     GCC sets 'cfun' to a dummy function context during initialization
+     of some parts of the back end.  The hook function is not invoked in
+     this situation; you need not worry about the hook being invoked
+     recursively, or when the back end is in a partially-initialized
+     state.  'cfun' might be 'NULL' to indicate processing at top level,
+     outside of any function scope.
+
+ -- Macro: TARGET_OBJECT_SUFFIX
+     Define this macro to be a C string representing the suffix for
+     object files on your target machine.  If you do not define this
+     macro, GCC will use '.o' as the suffix for object files.
+
+ -- Macro: TARGET_EXECUTABLE_SUFFIX
+     Define this macro to be a C string representing the suffix to be
+     automatically added to executable files on your target machine.  If
+     you do not define this macro, GCC will use the null string as the
+     suffix for executable files.
+
+ -- Macro: COLLECT_EXPORT_LIST
+     If defined, 'collect2' will scan the individual object files
+     specified on its command line and create an export list for the
+     linker.  Define this macro for systems like AIX, where the linker
+     discards object files that are not referenced from 'main' and uses
+     export lists.
+
+ -- Macro: MODIFY_JNI_METHOD_CALL (MDECL)
+     Define this macro to a C expression representing a variant of the
+     method call MDECL, if Java Native Interface (JNI) methods must be
+     invoked differently from other methods on your target.  For
+     example, on 32-bit Microsoft Windows, JNI methods must be invoked
+     using the 'stdcall' calling convention and this macro is then
+     defined as this expression:
+
+          build_type_attribute_variant (MDECL,
+                                        build_tree_list
+                                        (get_identifier ("stdcall"),
+                                         NULL))
+
+ -- Target Hook: bool TARGET_CANNOT_MODIFY_JUMPS_P (void)
+     This target hook returns 'true' past the point in which new jump
+     instructions could be created.  On machines that require a register
+     for every jump such as the SHmedia ISA of SH5, this point would
+     typically be reload, so this target hook should be defined to a
+     function such as:
+
+          static bool
+          cannot_modify_jumps_past_reload_p ()
+          {
+            return (reload_completed || reload_in_progress);
+          }
+
+ -- Target Hook: reg_class_t TARGET_BRANCH_TARGET_REGISTER_CLASS (void)
+     This target hook returns a register class for which branch target
+     register optimizations should be applied.  All registers in this
+     class should be usable interchangeably.  After reload, registers in
+     this class will be re-allocated and loads will be hoisted out of
+     loops and be subjected to inter-block scheduling.
+
+ -- Target Hook: bool TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED (bool
+          AFTER_PROLOGUE_EPILOGUE_GEN)
+     Branch target register optimization will by default exclude
+     callee-saved registers that are not already live during the current
+     function; if this target hook returns true, they will be included.
+     The target code must than make sure that all target registers in
+     the class returned by 'TARGET_BRANCH_TARGET_REGISTER_CLASS' that
+     might need saving are saved.  AFTER_PROLOGUE_EPILOGUE_GEN indicates
+     if prologues and epilogues have already been generated.  Note, even
+     if you only return true when AFTER_PROLOGUE_EPILOGUE_GEN is false,
+     you still are likely to have to make special provisions in
+     'INITIAL_ELIMINATION_OFFSET' to reserve space for caller-saved
+     target registers.
+
+ -- Target Hook: bool TARGET_HAVE_CONDITIONAL_EXECUTION (void)
+     This target hook returns true if the target supports conditional
+     execution.  This target hook is required only when the target has
+     several different modes and they have different conditional
+     execution capability, such as ARM.
+
+ -- Target Hook: unsigned TARGET_LOOP_UNROLL_ADJUST (unsigned NUNROLL,
+          struct loop *LOOP)
+     This target hook returns a new value for the number of times LOOP
+     should be unrolled.  The parameter NUNROLL is the number of times
+     the loop is to be unrolled.  The parameter LOOP is a pointer to the
+     loop, which is going to be checked for unrolling.  This target hook
+     is required only when the target has special constraints like
+     maximum number of memory accesses.
+
+ -- Macro: POWI_MAX_MULTS
+     If defined, this macro is interpreted as a signed integer C
+     expression that specifies the maximum number of floating point
+     multiplications that should be emitted when expanding
+     exponentiation by an integer constant inline.  When this value is
+     defined, exponentiation requiring more than this number of
+     multiplications is implemented by calling the system library's
+     'pow', 'powf' or 'powl' routines.  The default value places no
+     upper bound on the multiplication count.
+
+ -- Macro: void TARGET_EXTRA_INCLUDES (const char *SYSROOT, const char
+          *IPREFIX, int STDINC)
+     This target hook should register any extra include files for the
+     target.  The parameter STDINC indicates if normal include files are
+     present.  The parameter SYSROOT is the system root directory.  The
+     parameter IPREFIX is the prefix for the gcc directory.
+
+ -- Macro: void TARGET_EXTRA_PRE_INCLUDES (const char *SYSROOT, const
+          char *IPREFIX, int STDINC)
+     This target hook should register any extra include files for the
+     target before any standard headers.  The parameter STDINC indicates
+     if normal include files are present.  The parameter SYSROOT is the
+     system root directory.  The parameter IPREFIX is the prefix for the
+     gcc directory.
+
+ -- Macro: void TARGET_OPTF (char *PATH)
+     This target hook should register special include paths for the
+     target.  The parameter PATH is the include to register.  On Darwin
+     systems, this is used for Framework includes, which have semantics
+     that are different from '-I'.
+
+ -- Macro: bool TARGET_USE_LOCAL_THUNK_ALIAS_P (tree FNDECL)
+     This target macro returns 'true' if it is safe to use a local alias
+     for a virtual function FNDECL when constructing thunks, 'false'
+     otherwise.  By default, the macro returns 'true' for all functions,
+     if a target supports aliases (i.e. defines 'ASM_OUTPUT_DEF'),
+     'false' otherwise,
+
+ -- Macro: TARGET_FORMAT_TYPES
+     If defined, this macro is the name of a global variable containing
+     target-specific format checking information for the '-Wformat'
+     option.  The default is to have no target-specific format checks.
+
+ -- Macro: TARGET_N_FORMAT_TYPES
+     If defined, this macro is the number of entries in
+     'TARGET_FORMAT_TYPES'.
+
+ -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES
+     If defined, this macro is the name of a global variable containing
+     target-specific format overrides for the '-Wformat' option.  The
+     default is to have no target-specific format overrides.  If
+     defined, 'TARGET_FORMAT_TYPES' must be defined, too.
+
+ -- Macro: TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT
+     If defined, this macro specifies the number of entries in
+     'TARGET_OVERRIDES_FORMAT_ATTRIBUTES'.
+
+ -- Macro: TARGET_OVERRIDES_FORMAT_INIT
+     If defined, this macro specifies the optional initialization
+     routine for target specific customizations of the system printf and
+     scanf formatter settings.
+
+ -- Target Hook: bool TARGET_RELAXED_ORDERING
+     If set to 'true', means that the target's memory model does not
+     guarantee that loads which do not depend on one another will access
+     main memory in the order of the instruction stream; if ordering is
+     important, an explicit memory barrier must be used.  This is true
+     of many recent processors which implement a policy of "relaxed,"
+     "weak," or "release" memory consistency, such as Alpha, PowerPC,
+     and ia64.  The default is 'false'.
+
+ -- Target Hook: const char * TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN
+          (const_tree TYPELIST, const_tree FUNCDECL, const_tree VAL)
+     If defined, this macro returns the diagnostic message when it is
+     illegal to pass argument VAL to function FUNCDECL with prototype
+     TYPELIST.
+
+ -- Target Hook: const char * TARGET_INVALID_CONVERSION (const_tree
+          FROMTYPE, const_tree TOTYPE)
+     If defined, this macro returns the diagnostic message when it is
+     invalid to convert from FROMTYPE to TOTYPE, or 'NULL' if validity
+     should be determined by the front end.
+
+ -- Target Hook: const char * TARGET_INVALID_UNARY_OP (int OP,
+          const_tree TYPE)
+     If defined, this macro returns the diagnostic message when it is
+     invalid to apply operation OP (where unary plus is denoted by
+     'CONVERT_EXPR') to an operand of type TYPE, or 'NULL' if validity
+     should be determined by the front end.
+
+ -- Target Hook: const char * TARGET_INVALID_BINARY_OP (int OP,
+          const_tree TYPE1, const_tree TYPE2)
+     If defined, this macro returns the diagnostic message when it is
+     invalid to apply operation OP to operands of types TYPE1 and TYPE2,
+     or 'NULL' if validity should be determined by the front end.
+
+ -- Target Hook: const char * TARGET_INVALID_PARAMETER_TYPE (const_tree
+          TYPE)
+     If defined, this macro returns the diagnostic message when it is
+     invalid for functions to include parameters of type TYPE, or 'NULL'
+     if validity should be determined by the front end.  This is
+     currently used only by the C and C++ front ends.
+
+ -- Target Hook: const char * TARGET_INVALID_RETURN_TYPE (const_tree
+          TYPE)
+     If defined, this macro returns the diagnostic message when it is
+     invalid for functions to have return type TYPE, or 'NULL' if
+     validity should be determined by the front end.  This is currently
+     used only by the C and C++ front ends.
+
+ -- Target Hook: tree TARGET_PROMOTED_TYPE (const_tree TYPE)
+     If defined, this target hook returns the type to which values of
+     TYPE should be promoted when they appear in expressions, analogous
+     to the integer promotions, or 'NULL_TREE' to use the front end's
+     normal promotion rules.  This hook is useful when there are
+     target-specific types with special promotion rules.  This is
+     currently used only by the C and C++ front ends.
+
+ -- Target Hook: tree TARGET_CONVERT_TO_TYPE (tree TYPE, tree EXPR)
+     If defined, this hook returns the result of converting EXPR to
+     TYPE.  It should return the converted expression, or 'NULL_TREE' to
+     apply the front end's normal conversion rules.  This hook is useful
+     when there are target-specific types with special conversion rules.
+     This is currently used only by the C and C++ front ends.
+
+ -- Macro: TARGET_USE_JCR_SECTION
+     This macro determines whether to use the JCR section to register
+     Java classes.  By default, TARGET_USE_JCR_SECTION is defined to 1
+     if both SUPPORTS_WEAK and TARGET_HAVE_NAMED_SECTIONS are true, else
+     0.
+
+ -- Macro: OBJC_JBLEN
+     This macro determines the size of the objective C jump buffer for
+     the NeXT runtime.  By default, OBJC_JBLEN is defined to an
+     innocuous value.
+
+ -- Macro: LIBGCC2_UNWIND_ATTRIBUTE
+     Define this macro if any target-specific attributes need to be
+     attached to the functions in 'libgcc' that provide low-level
+     support for call stack unwinding.  It is used in declarations in
+     'unwind-generic.h' and the associated definitions of those
+     functions.
+
+ -- Target Hook: void TARGET_UPDATE_STACK_BOUNDARY (void)
+     Define this macro to update the current function stack boundary if
+     necessary.
+
+ -- Target Hook: rtx TARGET_GET_DRAP_RTX (void)
+     This hook should return an rtx for Dynamic Realign Argument Pointer
+     (DRAP) if a different argument pointer register is needed to access
+     the function's argument list due to stack realignment.  Return
+     'NULL' if no DRAP is needed.
+
+ -- Target Hook: bool TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS (void)
+     When optimization is disabled, this hook indicates whether or not
+     arguments should be allocated to stack slots.  Normally, GCC
+     allocates stacks slots for arguments when not optimizing in order
+     to make debugging easier.  However, when a function is declared
+     with '__attribute__((naked))', there is no stack frame, and the
+     compiler cannot safely move arguments from the registers in which
+     they are passed to the stack.  Therefore, this hook should return
+     true in general, but false for naked functions.  The default
+     implementation always returns true.
+
+ -- Target Hook: unsigned HOST_WIDE_INT TARGET_CONST_ANCHOR
+     On some architectures it can take multiple instructions to
+     synthesize a constant.  If there is another constant already in a
+     register that is close enough in value then it is preferable that
+     the new constant is computed from this register using immediate
+     addition or subtraction.  We accomplish this through CSE. Besides
+     the value of the constant we also add a lower and an upper constant
+     anchor to the available expressions.  These are then queried when
+     encountering new constants.  The anchors are computed by rounding
+     the constant up and down to a multiple of the value of
+     'TARGET_CONST_ANCHOR'.  'TARGET_CONST_ANCHOR' should be the maximum
+     positive value accepted by immediate-add plus one.  We currently
+     assume that the value of 'TARGET_CONST_ANCHOR' is a power of 2.
+     For example, on MIPS, where add-immediate takes a 16-bit signed
+     value, 'TARGET_CONST_ANCHOR' is set to '0x8000'.  The default value
+     is zero, which disables this optimization.
+
+ -- Target Hook: unsigned HOST_WIDE_INT TARGET_ASAN_SHADOW_OFFSET (void)
+     Return the offset bitwise ored into shifted address to get
+     corresponding Address Sanitizer shadow memory address.  NULL if
+     Address Sanitizer is not supported by the target.
+
+ -- Target Hook: unsigned HOST_WIDE_INT TARGET_MEMMODEL_CHECK (unsigned
+          HOST_WIDE_INT VAL)
+     Validate target specific memory model mask bits.  When NULL no
+     target specific memory model bits are allowed.
+
+ -- Target Hook: unsigned char TARGET_ATOMIC_TEST_AND_SET_TRUEVAL
+     This value should be set if the result written by
+     'atomic_test_and_set' is not exactly 1, i.e.  the 'bool' 'true'.
+
+ -- Target Hook: bool TARGET_HAS_IFUNC_P (void)
+     It returns true if the target supports GNU indirect functions.  The
+     support includes the assembler, linker and dynamic linker.  The
+     default value of this hook is based on target's libc.
+
+ -- Target Hook: unsigned int TARGET_ATOMIC_ALIGN_FOR_MODE (enum
+          machine_mode MODE)
+     If defined, this function returns an appropriate alignment in bits
+     for an atomic object of machine_mode MODE.  If 0 is returned then
+     the default alignment for the specified mode is used.
+
+ -- Target Hook: void TARGET_ATOMIC_ASSIGN_EXPAND_FENV (tree *HOLD, tree
+          *CLEAR, tree *UPDATE)
+     ISO C11 requires atomic compound assignments that may raise
+     floating-point exceptions to raise exceptions corresponding to the
+     arithmetic operation whose result was successfully stored in a
+     compare-and-exchange sequence.  This requires code equivalent to
+     calls to 'feholdexcept', 'feclearexcept' and 'feupdateenv' to be
+     generated at appropriate points in the compare-and-exchange
+     sequence.  This hook should set '*HOLD' to an expression equivalent
+     to the call to 'feholdexcept', '*CLEAR' to an expression equivalent
+     to the call to 'feclearexcept' and '*UPDATE' to an expression
+     equivalent to the call to 'feupdateenv'.  The three expressions are
+     'NULL_TREE' on entry to the hook and may be left as 'NULL_TREE' if
+     no code is required in a particular place.  The default
+     implementation leaves all three expressions as 'NULL_TREE'.  The
+     '__atomic_feraiseexcept' function from 'libatomic' may be of use as
+     part of the code generated in '*UPDATE'.
+
+
+File: gccint.info,  Node: Host Config,  Next: Fragments,  Prev: Target Macros,  Up: Top
+
+18 Host Configuration
+*********************
+
+Most details about the machine and system on which the compiler is
+actually running are detected by the 'configure' script.  Some things
+are impossible for 'configure' to detect; these are described in two
+ways, either by macros defined in a file named 'xm-MACHINE.h' or by hook
+functions in the file specified by the OUT_HOST_HOOK_OBJ variable in
+'config.gcc'.  (The intention is that very few hosts will need a header
+file but nearly every fully supported host will need to override some
+hooks.)
+
+ If you need to define only a few macros, and they have simple
+definitions, consider using the 'xm_defines' variable in your
+'config.gcc' entry instead of creating a host configuration header.
+*Note System Config::.
+
+* Menu:
+
+* Host Common::         Things every host probably needs implemented.
+* Filesystem::          Your host can't have the letter 'a' in filenames?
+* Host Misc::           Rare configuration options for hosts.
+
+
+File: gccint.info,  Node: Host Common,  Next: Filesystem,  Up: Host Config
+
+18.1 Host Common
+================
+
+Some things are just not portable, even between similar operating
+systems, and are too difficult for autoconf to detect.  They get
+implemented using hook functions in the file specified by the
+HOST_HOOK_OBJ variable in 'config.gcc'.
+
+ -- Host Hook: void HOST_HOOKS_EXTRA_SIGNALS (void)
+     This host hook is used to set up handling for extra signals.  The
+     most common thing to do in this hook is to detect stack overflow.
+
+ -- Host Hook: void * HOST_HOOKS_GT_PCH_GET_ADDRESS (size_t SIZE, int
+          FD)
+     This host hook returns the address of some space that is likely to
+     be free in some subsequent invocation of the compiler.  We intend
+     to load the PCH data at this address such that the data need not be
+     relocated.  The area should be able to hold SIZE bytes.  If the
+     host uses 'mmap', FD is an open file descriptor that can be used
+     for probing.
+
+ -- Host Hook: int HOST_HOOKS_GT_PCH_USE_ADDRESS (void * ADDRESS, size_t
+          SIZE, int FD, size_t OFFSET)
+     This host hook is called when a PCH file is about to be loaded.  We
+     want to load SIZE bytes from FD at OFFSET into memory at ADDRESS.
+     The given address will be the result of a previous invocation of
+     'HOST_HOOKS_GT_PCH_GET_ADDRESS'.  Return -1 if we couldn't allocate
+     SIZE bytes at ADDRESS.  Return 0 if the memory is allocated but the
+     data is not loaded.  Return 1 if the hook has performed everything.
+
+     If the implementation uses reserved address space, free any
+     reserved space beyond SIZE, regardless of the return value.  If no
+     PCH will be loaded, this hook may be called with SIZE zero, in
+     which case all reserved address space should be freed.
+
+     Do not try to handle values of ADDRESS that could not have been
+     returned by this executable; just return -1.  Such values usually
+     indicate an out-of-date PCH file (built by some other GCC
+     executable), and such a PCH file won't work.
+
+ -- Host Hook: size_t HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY (void);
+     This host hook returns the alignment required for allocating
+     virtual memory.  Usually this is the same as getpagesize, but on
+     some hosts the alignment for reserving memory differs from the
+     pagesize for committing memory.
+
+
+File: gccint.info,  Node: Filesystem,  Next: Host Misc,  Prev: Host Common,  Up: Host Config
+
+18.2 Host Filesystem
+====================
+
+GCC needs to know a number of things about the semantics of the host
+machine's filesystem.  Filesystems with Unix and MS-DOS semantics are
+automatically detected.  For other systems, you can define the following
+macros in 'xm-MACHINE.h'.
+
+'HAVE_DOS_BASED_FILE_SYSTEM'
+     This macro is automatically defined by 'system.h' if the host file
+     system obeys the semantics defined by MS-DOS instead of Unix.  DOS
+     file systems are case insensitive, file specifications may begin
+     with a drive letter, and both forward slash and backslash ('/' and
+     '\') are directory separators.
+
+'DIR_SEPARATOR'
+'DIR_SEPARATOR_2'
+     If defined, these macros expand to character constants specifying
+     separators for directory names within a file specification.
+     'system.h' will automatically give them appropriate values on Unix
+     and MS-DOS file systems.  If your file system is neither of these,
+     define one or both appropriately in 'xm-MACHINE.h'.
+
+     However, operating systems like VMS, where constructing a pathname
+     is more complicated than just stringing together directory names
+     separated by a special character, should not define either of these
+     macros.
+
+'PATH_SEPARATOR'
+     If defined, this macro should expand to a character constant
+     specifying the separator for elements of search paths.  The default
+     value is a colon (':').  DOS-based systems usually, but not always,
+     use semicolon (';').
+
+'VMS'
+     Define this macro if the host system is VMS.
+
+'HOST_OBJECT_SUFFIX'
+     Define this macro to be a C string representing the suffix for
+     object files on your host machine.  If you do not define this
+     macro, GCC will use '.o' as the suffix for object files.
+
+'HOST_EXECUTABLE_SUFFIX'
+     Define this macro to be a C string representing the suffix for
+     executable files on your host machine.  If you do not define this
+     macro, GCC will use the null string as the suffix for executable
+     files.
+
+'HOST_BIT_BUCKET'
+     A pathname defined by the host operating system, which can be
+     opened as a file and written to, but all the information written is
+     discarded.  This is commonly known as a "bit bucket" or "null
+     device".  If you do not define this macro, GCC will use '/dev/null'
+     as the bit bucket.  If the host does not support a bit bucket,
+     define this macro to an invalid filename.
+
+'UPDATE_PATH_HOST_CANONICALIZE (PATH)'
+     If defined, a C statement (sans semicolon) that performs
+     host-dependent canonicalization when a path used in a compilation
+     driver or preprocessor is canonicalized.  PATH is a malloc-ed path
+     to be canonicalized.  If the C statement does canonicalize PATH
+     into a different buffer, the old path should be freed and the new
+     buffer should have been allocated with malloc.
+
+'DUMPFILE_FORMAT'
+     Define this macro to be a C string representing the format to use
+     for constructing the index part of debugging dump file names.  The
+     resultant string must fit in fifteen bytes.  The full filename will
+     be the concatenation of: the prefix of the assembler file name, the
+     string resulting from applying this format to an index number, and
+     a string unique to each dump file kind, e.g. 'rtl'.
+
+     If you do not define this macro, GCC will use '.%02d.'.  You should
+     define this macro if using the default will create an invalid file
+     name.
+
+'DELETE_IF_ORDINARY'
+     Define this macro to be a C statement (sans semicolon) that
+     performs host-dependent removal of ordinary temp files in the
+     compilation driver.
+
+     If you do not define this macro, GCC will use the default version.
+     You should define this macro if the default version does not
+     reliably remove the temp file as, for example, on VMS which allows
+     multiple versions of a file.
+
+'HOST_LACKS_INODE_NUMBERS'
+     Define this macro if the host filesystem does not report meaningful
+     inode numbers in struct stat.
+
+
+File: gccint.info,  Node: Host Misc,  Prev: Filesystem,  Up: Host Config
+
+18.3 Host Misc
+==============
+
+'FATAL_EXIT_CODE'
+     A C expression for the status code to be returned when the compiler
+     exits after serious errors.  The default is the system-provided
+     macro 'EXIT_FAILURE', or '1' if the system doesn't define that
+     macro.  Define this macro only if these defaults are incorrect.
+
+'SUCCESS_EXIT_CODE'
+     A C expression for the status code to be returned when the compiler
+     exits without serious errors.  (Warnings are not serious errors.)
+     The default is the system-provided macro 'EXIT_SUCCESS', or '0' if
+     the system doesn't define that macro.  Define this macro only if
+     these defaults are incorrect.
+
+'USE_C_ALLOCA'
+     Define this macro if GCC should use the C implementation of
+     'alloca' provided by 'libiberty.a'.  This only affects how some
+     parts of the compiler itself allocate memory.  It does not change
+     code generation.
+
+     When GCC is built with a compiler other than itself, the C 'alloca'
+     is always used.  This is because most other implementations have
+     serious bugs.  You should define this macro only on a system where
+     no stack-based 'alloca' can possibly work.  For instance, if a
+     system has a small limit on the size of the stack, GCC's builtin
+     'alloca' will not work reliably.
+
+'COLLECT2_HOST_INITIALIZATION'
+     If defined, a C statement (sans semicolon) that performs
+     host-dependent initialization when 'collect2' is being initialized.
+
+'GCC_DRIVER_HOST_INITIALIZATION'
+     If defined, a C statement (sans semicolon) that performs
+     host-dependent initialization when a compilation driver is being
+     initialized.
+
+'HOST_LONG_LONG_FORMAT'
+     If defined, the string used to indicate an argument of type 'long
+     long' to functions like 'printf'.  The default value is '"ll"'.
+
+'HOST_LONG_FORMAT'
+     If defined, the string used to indicate an argument of type 'long'
+     to functions like 'printf'.  The default value is '"l"'.
+
+'HOST_PTR_PRINTF'
+     If defined, the string used to indicate an argument of type 'void
+     *' to functions like 'printf'.  The default value is '"%p"'.
+
+ In addition, if 'configure' generates an incorrect definition of any of
+the macros in 'auto-host.h', you can override that definition in a host
+configuration header.  If you need to do this, first see if it is
+possible to fix 'configure'.
+
+
+File: gccint.info,  Node: Fragments,  Next: Collect2,  Prev: Host Config,  Up: Top
+
+19 Makefile Fragments
+*********************
+
+When you configure GCC using the 'configure' script, it will construct
+the file 'Makefile' from the template file 'Makefile.in'.  When it does
+this, it can incorporate makefile fragments from the 'config' directory.
+These are used to set Makefile parameters that are not amenable to being
+calculated by autoconf.  The list of fragments to incorporate is set by
+'config.gcc' (and occasionally 'config.build' and 'config.host'); *Note
+System Config::.
+
+ Fragments are named either 't-TARGET' or 'x-HOST', depending on whether
+they are relevant to configuring GCC to produce code for a particular
+target, or to configuring GCC to run on a particular host.  Here TARGET
+and HOST are mnemonics which usually have some relationship to the
+canonical system name, but no formal connection.
+
+ If these files do not exist, it means nothing needs to be added for a
+given target or host.  Most targets need a few 't-TARGET' fragments, but
+needing 'x-HOST' fragments is rare.
+
+* Menu:
+
+* Target Fragment:: Writing 't-TARGET' files.
+* Host Fragment::   Writing 'x-HOST' files.
+
+
+File: gccint.info,  Node: Target Fragment,  Next: Host Fragment,  Up: Fragments
+
+19.1 Target Makefile Fragments
+==============================
+
+Target makefile fragments can set these Makefile variables.
+
+'LIBGCC2_CFLAGS'
+     Compiler flags to use when compiling 'libgcc2.c'.
+
+'LIB2FUNCS_EXTRA'
+     A list of source file names to be compiled or assembled and
+     inserted into 'libgcc.a'.
+
+'CRTSTUFF_T_CFLAGS'
+     Special flags used when compiling 'crtstuff.c'.  *Note
+     Initialization::.
+
+'CRTSTUFF_T_CFLAGS_S'
+     Special flags used when compiling 'crtstuff.c' for shared linking.
+     Used if you use 'crtbeginS.o' and 'crtendS.o' in 'EXTRA-PARTS'.
+     *Note Initialization::.
+
+'MULTILIB_OPTIONS'
+     For some targets, invoking GCC in different ways produces objects
+     that can not be linked together.  For example, for some targets GCC
+     produces both big and little endian code.  For these targets, you
+     must arrange for multiple versions of 'libgcc.a' to be compiled,
+     one for each set of incompatible options.  When GCC invokes the
+     linker, it arranges to link in the right version of 'libgcc.a',
+     based on the command line options used.
+
+     The 'MULTILIB_OPTIONS' macro lists the set of options for which
+     special versions of 'libgcc.a' must be built.  Write options that
+     are mutually incompatible side by side, separated by a slash.
+     Write options that may be used together separated by a space.  The
+     build procedure will build all combinations of compatible options.
+
+     For example, if you set 'MULTILIB_OPTIONS' to 'm68000/m68020
+     msoft-float', 'Makefile' will build special versions of 'libgcc.a'
+     using the following sets of options: '-m68000', '-m68020',
+     '-msoft-float', '-m68000 -msoft-float', and '-m68020 -msoft-float'.
+
+'MULTILIB_DIRNAMES'
+     If 'MULTILIB_OPTIONS' is used, this variable specifies the
+     directory names that should be used to hold the various libraries.
+     Write one element in 'MULTILIB_DIRNAMES' for each element in
+     'MULTILIB_OPTIONS'.  If 'MULTILIB_DIRNAMES' is not used, the
+     default value will be 'MULTILIB_OPTIONS', with all slashes treated
+     as spaces.
+
+     'MULTILIB_DIRNAMES' describes the multilib directories using GCC
+     conventions and is applied to directories that are part of the GCC
+     installation.  When multilib-enabled, the compiler will add a
+     subdirectory of the form PREFIX/MULTILIB before each directory in
+     the search path for libraries and crt files.
+
+     For example, if 'MULTILIB_OPTIONS' is set to 'm68000/m68020
+     msoft-float', then the default value of 'MULTILIB_DIRNAMES' is
+     'm68000 m68020 msoft-float'.  You may specify a different value if
+     you desire a different set of directory names.
+
+'MULTILIB_MATCHES'
+     Sometimes the same option may be written in two different ways.  If
+     an option is listed in 'MULTILIB_OPTIONS', GCC needs to know about
+     any synonyms.  In that case, set 'MULTILIB_MATCHES' to a list of
+     items of the form 'option=option' to describe all relevant
+     synonyms.  For example, 'm68000=mc68000 m68020=mc68020'.
+
+'MULTILIB_EXCEPTIONS'
+     Sometimes when there are multiple sets of 'MULTILIB_OPTIONS' being
+     specified, there are combinations that should not be built.  In
+     that case, set 'MULTILIB_EXCEPTIONS' to be all of the switch
+     exceptions in shell case syntax that should not be built.
+
+     For example the ARM processor cannot execute both hardware floating
+     point instructions and the reduced size THUMB instructions at the
+     same time, so there is no need to build libraries with both of
+     these options enabled.  Therefore 'MULTILIB_EXCEPTIONS' is set to:
+          *mthumb/*mhard-float*
+
+'MULTILIB_REQUIRED'
+     Sometimes when there are only a few combinations are required, it
+     would be a big effort to come up with a 'MULTILIB_EXCEPTIONS' list
+     to cover all undesired ones.  In such a case, just listing all the
+     required combinations in 'MULTILIB_REQUIRED' would be more
+     straightforward.
+
+     The way to specify the entries in 'MULTILIB_REQUIRED' is same with
+     the way used for 'MULTILIB_EXCEPTIONS', only this time what are
+     required will be specified.  Suppose there are multiple sets of
+     'MULTILIB_OPTIONS' and only two combinations are required, one for
+     ARMv7-M and one for ARMv7-R with hard floating-point ABI and FPU,
+     the 'MULTILIB_REQUIRED' can be set to:
+          MULTILIB_REQUIRED =  mthumb/march=armv7-m
+          MULTILIB_REQUIRED += march=armv7-r/mfloat-abi=hard/mfpu=vfpv3-d16
+
+     The 'MULTILIB_REQUIRED' can be used together with
+     'MULTILIB_EXCEPTIONS'.  The option combinations generated from
+     'MULTILIB_OPTIONS' will be filtered by 'MULTILIB_EXCEPTIONS' and
+     then by 'MULTILIB_REQUIRED'.
+
+'MULTILIB_REUSE'
+     Sometimes it is desirable to reuse one existing multilib for
+     different sets of options.  Such kind of reuse can minimize the
+     number of multilib variants.  And for some targets it is better to
+     reuse an existing multilib than to fall back to default multilib
+     when there is no corresponding multilib.  This can be done by
+     adding reuse rules to 'MULTILIB_REUSE'.
+
+     A reuse rule is comprised of two parts connected by equality sign.
+     The left part is option set used to build multilib and the right
+     part is option set that will reuse this multilib.  The order of
+     options in the left part matters and should be same with those
+     specified in 'MULTILIB_REQUIRED' or aligned with order in
+     'MULTILIB_OPTIONS'.  There is no such limitation for options in
+     right part as we don't build multilib from them.  But the equality
+     sign in both parts should be replaced with period.
+
+     The 'MULTILIB_REUSE' is different from 'MULTILIB_MATCHES' in that
+     it sets up relations between two option sets rather than two
+     options.  Here is an example to demo how we reuse libraries built
+     in Thumb mode for applications built in ARM mode:
+          MULTILIB_REUSE = mthumb/march.armv7-r=marm/march.armv7-r
+
+     Before the advent of 'MULTILIB_REUSE', GCC select multilib by
+     comparing command line options with options used to build multilib.
+     The 'MULTILIB_REUSE' is complementary to that way.  Only when the
+     original comparison matches nothing it will work to see if it is OK
+     to reuse some existing multilib.
+
+'MULTILIB_EXTRA_OPTS'
+     Sometimes it is desirable that when building multiple versions of
+     'libgcc.a' certain options should always be passed on to the
+     compiler.  In that case, set 'MULTILIB_EXTRA_OPTS' to be the list
+     of options to be used for all builds.  If you set this, you should
+     probably set 'CRTSTUFF_T_CFLAGS' to a dash followed by it.
+
+'MULTILIB_OSDIRNAMES'
+     If 'MULTILIB_OPTIONS' is used, this variable specifies a list of
+     subdirectory names, that are used to modify the search path
+     depending on the chosen multilib.  Unlike 'MULTILIB_DIRNAMES',
+     'MULTILIB_OSDIRNAMES' describes the multilib directories using
+     operating systems conventions, and is applied to the directories
+     such as 'lib' or those in the 'LIBRARY_PATH' environment variable.
+     The format is either the same as of 'MULTILIB_DIRNAMES', or a set
+     of mappings.  When it is the same as 'MULTILIB_DIRNAMES', it
+     describes the multilib directories using operating system
+     conventions, rather than GCC conventions.  When it is a set of
+     mappings of the form GCCDIR=OSDIR, the left side gives the GCC
+     convention and the right gives the equivalent OS defined location.
+     If the OSDIR part begins with a '!', GCC will not search in the
+     non-multilib directory and use exclusively the multilib directory.
+     Otherwise, the compiler will examine the search path for libraries
+     and crt files twice; the first time it will add MULTILIB to each
+     directory in the search path, the second it will not.
+
+     For configurations that support both multilib and multiarch,
+     'MULTILIB_OSDIRNAMES' also encodes the multiarch name, thus
+     subsuming 'MULTIARCH_DIRNAME'.  The multiarch name is appended to
+     each directory name, separated by a colon (e.g.
+     '../lib32:i386-linux-gnu').
+
+     Each multiarch subdirectory will be searched before the
+     corresponding OS multilib directory, for example
+     '/lib/i386-linux-gnu' before '/lib/../lib32'.  The multiarch name
+     will also be used to modify the system header search path, as
+     explained for 'MULTIARCH_DIRNAME'.
+
+'MULTIARCH_DIRNAME'
+     This variable specifies the multiarch name for configurations that
+     are multiarch-enabled but not multilibbed configurations.
+
+     The multiarch name is used to augment the search path for
+     libraries, crt files and system header files with additional
+     locations.  The compiler will add a multiarch subdirectory of the
+     form PREFIX/MULTIARCH before each directory in the library and crt
+     search path.  It will also add two directories
+     'LOCAL_INCLUDE_DIR'/MULTIARCH and
+     'NATIVE_SYSTEM_HEADER_DIR'/MULTIARCH) to the system header search
+     path, respectively before 'LOCAL_INCLUDE_DIR' and
+     'NATIVE_SYSTEM_HEADER_DIR'.
+
+     'MULTIARCH_DIRNAME' is not used for configurations that support
+     both multilib and multiarch.  In that case, multiarch names are
+     encoded in 'MULTILIB_OSDIRNAMES' instead.
+
+     More documentation about multiarch can be found at
+     <http://wiki.debian.org/Multiarch>.
+
+'SPECS'
+     Unfortunately, setting 'MULTILIB_EXTRA_OPTS' is not enough, since
+     it does not affect the build of target libraries, at least not the
+     build of the default multilib.  One possible work-around is to use
+     'DRIVER_SELF_SPECS' to bring options from the 'specs' file as if
+     they had been passed in the compiler driver command line.  However,
+     you don't want to be adding these options after the toolchain is
+     installed, so you can instead tweak the 'specs' file that will be
+     used during the toolchain build, while you still install the
+     original, built-in 'specs'.  The trick is to set 'SPECS' to some
+     other filename (say 'specs.install'), that will then be created out
+     of the built-in specs, and introduce a 'Makefile' rule to generate
+     the 'specs' file that's going to be used at build time out of your
+     'specs.install'.
+
+'T_CFLAGS'
+     These are extra flags to pass to the C compiler.  They are used
+     both when building GCC, and when compiling things with the
+     just-built GCC.  This variable is deprecated and should not be
+     used.
+
+
+File: gccint.info,  Node: Host Fragment,  Prev: Target Fragment,  Up: Fragments
+
+19.2 Host Makefile Fragments
+============================
+
+The use of 'x-HOST' fragments is discouraged.  You should only use it
+for makefile dependencies.
+
+
+File: gccint.info,  Node: Collect2,  Next: Header Dirs,  Prev: Fragments,  Up: Top
+
+20 'collect2'
+*************
+
+GCC uses a utility called 'collect2' on nearly all systems to arrange to
+call various initialization functions at start time.
+
+ The program 'collect2' works by linking the program once and looking
+through the linker output file for symbols with particular names
+indicating they are constructor functions.  If it finds any, it creates
+a new temporary '.c' file containing a table of them, compiles it, and
+links the program a second time including that file.
+
+ The actual calls to the constructors are carried out by a subroutine
+called '__main', which is called (automatically) at the beginning of the
+body of 'main' (provided 'main' was compiled with GNU CC).  Calling
+'__main' is necessary, even when compiling C code, to allow linking C
+and C++ object code together.  (If you use '-nostdlib', you get an
+unresolved reference to '__main', since it's defined in the standard GCC
+library.  Include '-lgcc' at the end of your compiler command line to
+resolve this reference.)
+
+ The program 'collect2' is installed as 'ld' in the directory where the
+passes of the compiler are installed.  When 'collect2' needs to find the
+_real_ 'ld', it tries the following file names:
+
+   * a hard coded linker file name, if GCC was configured with the
+     '--with-ld' option.
+
+   * 'real-ld' in the directories listed in the compiler's search
+     directories.
+
+   * 'real-ld' in the directories listed in the environment variable
+     'PATH'.
+
+   * The file specified in the 'REAL_LD_FILE_NAME' configuration macro,
+     if specified.
+
+   * 'ld' in the compiler's search directories, except that 'collect2'
+     will not execute itself recursively.
+
+   * 'ld' in 'PATH'.
+
+ "The compiler's search directories" means all the directories where
+'gcc' searches for passes of the compiler.  This includes directories
+that you specify with '-B'.
+
+ Cross-compilers search a little differently:
+
+   * 'real-ld' in the compiler's search directories.
+
+   * 'TARGET-real-ld' in 'PATH'.
+
+   * The file specified in the 'REAL_LD_FILE_NAME' configuration macro,
+     if specified.
+
+   * 'ld' in the compiler's search directories.
+
+   * 'TARGET-ld' in 'PATH'.
+
+ 'collect2' explicitly avoids running 'ld' using the file name under
+which 'collect2' itself was invoked.  In fact, it remembers up a list of
+such names--in case one copy of 'collect2' finds another copy (or
+version) of 'collect2' installed as 'ld' in a second place in the search
+path.
+
+ 'collect2' searches for the utilities 'nm' and 'strip' using the same
+algorithm as above for 'ld'.
+
+
+File: gccint.info,  Node: Header Dirs,  Next: Type Information,  Prev: Collect2,  Up: Top
+
+21 Standard Header File Directories
+***********************************
+
+'GCC_INCLUDE_DIR' means the same thing for native and cross.  It is
+where GCC stores its private include files, and also where GCC stores
+the fixed include files.  A cross compiled GCC runs 'fixincludes' on the
+header files in '$(tooldir)/include'.  (If the cross compilation header
+files need to be fixed, they must be installed before GCC is built.  If
+the cross compilation header files are already suitable for GCC, nothing
+special need be done).
+
+ 'GPLUSPLUS_INCLUDE_DIR' means the same thing for native and cross.  It
+is where 'g++' looks first for header files.  The C++ library installs
+only target independent header files in that directory.
+
+ 'LOCAL_INCLUDE_DIR' is used only by native compilers.  GCC doesn't
+install anything there.  It is normally '/usr/local/include'.  This is
+where local additions to a packaged system should place header files.
+
+ 'CROSS_INCLUDE_DIR' is used only by cross compilers.  GCC doesn't
+install anything there.
+
+ 'TOOL_INCLUDE_DIR' is used for both native and cross compilers.  It is
+the place for other packages to install header files that GCC will use.
+For a cross-compiler, this is the equivalent of '/usr/include'.  When
+you build a cross-compiler, 'fixincludes' processes any header files in
+this directory.
+
+
+File: gccint.info,  Node: Type Information,  Next: Plugins,  Prev: Header Dirs,  Up: Top
+
+22 Memory Management and Type Information
+*****************************************
+
+GCC uses some fairly sophisticated memory management techniques, which
+involve determining information about GCC's data structures from GCC's
+source code and using this information to perform garbage collection and
+implement precompiled headers.
+
+ A full C++ parser would be too complicated for this task, so a limited
+subset of C++ is interpreted and special markers are used to determine
+what parts of the source to look at.  All 'struct', 'union' and
+'template' structure declarations that define data structures that are
+allocated under control of the garbage collector must be marked.  All
+global variables that hold pointers to garbage-collected memory must
+also be marked.  Finally, all global variables that need to be saved and
+restored by a precompiled header must be marked.  (The precompiled
+header mechanism can only save static variables if they're scalar.
+Complex data structures must be allocated in garbage-collected memory to
+be saved in a precompiled header.)
+
+ The full format of a marker is
+     GTY (([OPTION] [(PARAM)], [OPTION] [(PARAM)] ...))
+but in most cases no options are needed.  The outer double parentheses
+are still necessary, though: 'GTY(())'.  Markers can appear:
+
+   * In a structure definition, before the open brace;
+   * In a global variable declaration, after the keyword 'static' or
+     'extern'; and
+   * In a structure field definition, before the name of the field.
+
+ Here are some examples of marking simple data structures and globals.
+
+     struct GTY(()) TAG
+     {
+       FIELDS...
+     };
+
+     typedef struct GTY(()) TAG
+     {
+       FIELDS...
+     } *TYPENAME;
+
+     static GTY(()) struct TAG *LIST;   /* points to GC memory */
+     static GTY(()) int COUNTER;        /* save counter in a PCH */
+
+ The parser understands simple typedefs such as 'typedef struct TAG
+*NAME;' and 'typedef int NAME;'.  These don't need to be marked.
+
+ Since 'gengtype''s understanding of C++ is limited, there are several
+constructs and declarations that are not supported inside
+classes/structures marked for automatic GC code generation.  The
+following C++ constructs produce a 'gengtype' error on
+structures/classes marked for automatic GC code generation:
+
+   * Type definitions inside classes/structures are not supported.
+   * Enumerations inside classes/structures are not supported.
+
+ If you have a class or structure using any of the above constructs, you
+need to mark that class as 'GTY ((user))' and provide your own marking
+routines (see section *note User GC:: for details).
+
+ It is always valid to include function definitions inside classes.
+Those are always ignored by 'gengtype', as it only cares about data
+members.
+
+* Menu:
+
+* GTY Options::         What goes inside a 'GTY(())'.
+* Inheritance and GTY:: Adding GTY to a class hierarchy.
+* User GC::		Adding user-provided GC marking routines.
+* GGC Roots::           Making global variables GGC roots.
+* Files::               How the generated files work.
+* Invoking the garbage collector::   How to invoke the garbage collector.
+* Troubleshooting::     When something does not work as expected.
+
+
+File: gccint.info,  Node: GTY Options,  Next: Inheritance and GTY,  Up: Type Information
+
+22.1 The Inside of a 'GTY(())'
+==============================
+
+Sometimes the C code is not enough to fully describe the type structure.
+Extra information can be provided with 'GTY' options and additional
+markers.  Some options take a parameter, which may be either a string or
+a type name, depending on the parameter.  If an option takes no
+parameter, it is acceptable either to omit the parameter entirely, or to
+provide an empty string as a parameter.  For example, 'GTY ((skip))' and
+'GTY ((skip ("")))' are equivalent.
+
+ When the parameter is a string, often it is a fragment of C code.  Four
+special escapes may be used in these strings, to refer to pieces of the
+data structure being marked:
+
+'%h'
+     The current structure.
+'%1'
+     The structure that immediately contains the current structure.
+'%0'
+     The outermost structure that contains the current structure.
+'%a'
+     A partial expression of the form '[i1][i2]...' that indexes the
+     array item currently being marked.
+
+ For instance, suppose that you have a structure of the form
+     struct A {
+       ...
+     };
+     struct B {
+       struct A foo[12];
+     };
+and 'b' is a variable of type 'struct B'.  When marking 'b.foo[11]',
+'%h' would expand to 'b.foo[11]', '%0' and '%1' would both expand to
+'b', and '%a' would expand to '[11]'.
+
+ As in ordinary C, adjacent strings will be concatenated; this is
+helpful when you have a complicated expression.
+     GTY ((chain_next ("TREE_CODE (&%h.generic) == INTEGER_TYPE"
+                       " ? TYPE_NEXT_VARIANT (&%h.generic)"
+                       " : TREE_CHAIN (&%h.generic)")))
+
+ The available options are:
+
+'length ("EXPRESSION")'
+
+     There are two places the type machinery will need to be explicitly
+     told the length of an array of non-atomic objects.  The first case
+     is when a structure ends in a variable-length array, like this:
+          struct GTY(()) rtvec_def {
+            int num_elem;         /* number of elements */
+            rtx GTY ((length ("%h.num_elem"))) elem[1];
+          };
+
+     In this case, the 'length' option is used to override the specified
+     array length (which should usually be '1').  The parameter of the
+     option is a fragment of C code that calculates the length.
+
+     The second case is when a structure or a global variable contains a
+     pointer to an array, like this:
+          struct gimple_omp_for_iter * GTY((length ("%h.collapse"))) iter;
+     In this case, 'iter' has been allocated by writing something like
+            x->iter = ggc_alloc_cleared_vec_gimple_omp_for_iter (collapse);
+     and the 'collapse' provides the length of the field.
+
+     This second use of 'length' also works on global variables, like:
+     static GTY((length("reg_known_value_size"))) rtx *reg_known_value;
+
+     Note that the 'length' option is only meant for use with arrays of
+     non-atomic objects, that is, objects that contain pointers pointing
+     to other GTY-managed objects.  For other GC-allocated arrays and
+     strings you should use 'atomic'.
+
+'skip'
+
+     If 'skip' is applied to a field, the type machinery will ignore it.
+     This is somewhat dangerous; the only safe use is in a union when
+     one field really isn't ever used.
+
+'desc ("EXPRESSION")'
+'tag ("CONSTANT")'
+'default'
+
+     The type machinery needs to be told which field of a 'union' is
+     currently active.  This is done by giving each field a constant
+     'tag' value, and then specifying a discriminator using 'desc'.  The
+     value of the expression given by 'desc' is compared against each
+     'tag' value, each of which should be different.  If no 'tag' is
+     matched, the field marked with 'default' is used if there is one,
+     otherwise no field in the union will be marked.
+
+     In the 'desc' option, the "current structure" is the union that it
+     discriminates.  Use '%1' to mean the structure containing it.
+     There are no escapes available to the 'tag' option, since it is a
+     constant.
+
+     For example,
+          struct GTY(()) tree_binding
+          {
+            struct tree_common common;
+            union tree_binding_u {
+              tree GTY ((tag ("0"))) scope;
+              struct cp_binding_level * GTY ((tag ("1"))) level;
+            } GTY ((desc ("BINDING_HAS_LEVEL_P ((tree)&%0)"))) xscope;
+            tree value;
+          };
+
+     In this example, the value of BINDING_HAS_LEVEL_P when applied to a
+     'struct tree_binding *' is presumed to be 0 or 1.  If 1, the type
+     mechanism will treat the field 'level' as being present and if 0,
+     will treat the field 'scope' as being present.
+
+     The 'desc' and 'tag' options can also be used for inheritance to
+     denote which subclass an instance is.  See *note Inheritance and
+     GTY:: for more information.
+
+'param_is (TYPE)'
+'use_param'
+
+     Sometimes it's convenient to define some data structure to work on
+     generic pointers (that is, 'PTR') and then use it with a specific
+     type.  'param_is' specifies the real type pointed to, and
+     'use_param' says where in the generic data structure that type
+     should be put.
+
+     For instance, to have a 'htab_t' that points to trees, one would
+     write the definition of 'htab_t' like this:
+          typedef struct GTY(()) {
+            ...
+            void ** GTY ((use_param, ...)) entries;
+            ...
+          } htab_t;
+     and then declare variables like this:
+            static htab_t GTY ((param_is (union tree_node))) ict;
+
+'paramN_is (TYPE)'
+'use_paramN'
+
+     In more complicated cases, the data structure might need to work on
+     several different types, which might not necessarily all be
+     pointers.  For this, 'param1_is' through 'param9_is' may be used to
+     specify the real type of a field identified by 'use_param1' through
+     'use_param9'.
+
+'use_params'
+
+     When a structure contains another structure that is parameterized,
+     there's no need to do anything special, the inner structure
+     inherits the parameters of the outer one.  When a structure
+     contains a pointer to a parameterized structure, the type machinery
+     won't automatically detect this (it could, it just doesn't yet), so
+     it's necessary to tell it that the pointed-to structure should use
+     the same parameters as the outer structure.  This is done by
+     marking the pointer with the 'use_params' option.
+
+'deletable'
+
+     'deletable', when applied to a global variable, indicates that when
+     garbage collection runs, there's no need to mark anything pointed
+     to by this variable, it can just be set to 'NULL' instead.  This is
+     used to keep a list of free structures around for re-use.
+
+'if_marked ("EXPRESSION")'
+
+     Suppose you want some kinds of object to be unique, and so you put
+     them in a hash table.  If garbage collection marks the hash table,
+     these objects will never be freed, even if the last other reference
+     to them goes away.  GGC has special handling to deal with this: if
+     you use the 'if_marked' option on a global hash table, GGC will
+     call the routine whose name is the parameter to the option on each
+     hash table entry.  If the routine returns nonzero, the hash table
+     entry will be marked as usual.  If the routine returns zero, the
+     hash table entry will be deleted.
+
+     The routine 'ggc_marked_p' can be used to determine if an element
+     has been marked already; in fact, the usual case is to use
+     'if_marked ("ggc_marked_p")'.
+
+'mark_hook ("HOOK-ROUTINE-NAME")'
+
+     If provided for a structure or union type, the given
+     HOOK-ROUTINE-NAME (between double-quotes) is the name of a routine
+     called when the garbage collector has just marked the data as
+     reachable.  This routine should not change the data, or call any
+     ggc routine.  Its only argument is a pointer to the just marked
+     (const) structure or union.
+
+'maybe_undef'
+
+     When applied to a field, 'maybe_undef' indicates that it's OK if
+     the structure that this fields points to is never defined, so long
+     as this field is always 'NULL'.  This is used to avoid requiring
+     backends to define certain optional structures.  It doesn't work
+     with language frontends.
+
+'nested_ptr (TYPE, "TO EXPRESSION", "FROM EXPRESSION")'
+
+     The type machinery expects all pointers to point to the start of an
+     object.  Sometimes for abstraction purposes it's convenient to have
+     a pointer which points inside an object.  So long as it's possible
+     to convert the original object to and from the pointer, such
+     pointers can still be used.  TYPE is the type of the original
+     object, the TO EXPRESSION returns the pointer given the original
+     object, and the FROM EXPRESSION returns the original object given
+     the pointer.  The pointer will be available using the '%h' escape.
+
+'chain_next ("EXPRESSION")'
+'chain_prev ("EXPRESSION")'
+'chain_circular ("EXPRESSION")'
+
+     It's helpful for the type machinery to know if objects are often
+     chained together in long lists; this lets it generate code that
+     uses less stack space by iterating along the list instead of
+     recursing down it.  'chain_next' is an expression for the next item
+     in the list, 'chain_prev' is an expression for the previous item.
+     For singly linked lists, use only 'chain_next'; for doubly linked
+     lists, use both.  The machinery requires that taking the next item
+     of the previous item gives the original item.  'chain_circular' is
+     similar to 'chain_next', but can be used for circular single linked
+     lists.
+
+'reorder ("FUNCTION NAME")'
+
+     Some data structures depend on the relative ordering of pointers.
+     If the precompiled header machinery needs to change that ordering,
+     it will call the function referenced by the 'reorder' option,
+     before changing the pointers in the object that's pointed to by the
+     field the option applies to.  The function must take four
+     arguments, with the signature
+     'void *, void *, gt_pointer_operator, void *'.  The first parameter
+     is a pointer to the structure that contains the object being
+     updated, or the object itself if there is no containing structure.
+     The second parameter is a cookie that should be ignored.  The third
+     parameter is a routine that, given a pointer, will update it to its
+     correct new value.  The fourth parameter is a cookie that must be
+     passed to the second parameter.
+
+     PCH cannot handle data structures that depend on the absolute
+     values of pointers.  'reorder' functions can be expensive.  When
+     possible, it is better to depend on properties of the data, like an
+     ID number or the hash of a string instead.
+
+'variable_size'
+
+     The type machinery expects the types to be of constant size.  When
+     this is not true, for example, with structs that have array fields
+     or unions, the type machinery cannot tell how many bytes need to be
+     allocated at each allocation.  The 'variable_size' is used to mark
+     such types.  The type machinery then provides allocators that take
+     a parameter indicating an exact size of object being allocated.
+     Note that the size must be provided in bytes whereas the 'length'
+     option works with array lengths in number of elements.
+
+     For example,
+          struct GTY((variable_size)) sorted_fields_type {
+            int len;
+            tree GTY((length ("%h.len"))) elts[1];
+          };
+
+     Then the objects of 'struct sorted_fields_type' are allocated in GC
+     memory as follows:
+            field_vec = ggc_alloc_sorted_fields_type (size);
+
+     If FIELD_VEC->ELTS stores N elements, then SIZE could be calculated
+     as follows:
+            size_t size = sizeof (struct sorted_fields_type) + n * sizeof (tree);
+
+'atomic'
+
+     The 'atomic' option can only be used with pointers.  It informs the
+     GC machinery that the memory that the pointer points to does not
+     contain any pointers, and hence it should be treated by the GC and
+     PCH machinery as an "atomic" block of memory that does not need to
+     be examined when scanning memory for pointers.  In particular, the
+     machinery will not scan that memory for pointers to mark them as
+     reachable (when marking pointers for GC) or to relocate them (when
+     writing a PCH file).
+
+     The 'atomic' option differs from the 'skip' option.  'atomic' keeps
+     the memory under Garbage Collection, but makes the GC ignore the
+     contents of the memory.  'skip' is more drastic in that it causes
+     the pointer and the memory to be completely ignored by the Garbage
+     Collector.  So, memory marked as 'atomic' is automatically freed
+     when no longer reachable, while memory marked as 'skip' is not.
+
+     The 'atomic' option must be used with great care, because all sorts
+     of problem can occur if used incorrectly, that is, if the memory
+     the pointer points to does actually contain a pointer.
+
+     Here is an example of how to use it:
+          struct GTY(()) my_struct {
+            int number_of_elements;
+            unsigned int * GTY ((atomic)) elements;
+          };
+     In this case, 'elements' is a pointer under GC, and the memory it
+     points to needs to be allocated using the Garbage Collector, and
+     will be freed automatically by the Garbage Collector when it is no
+     longer referenced.  But the memory that the pointer points to is an
+     array of 'unsigned int' elements, and the GC must not try to scan
+     it to find pointers to mark or relocate, which is why it is marked
+     with the 'atomic' option.
+
+     Note that, currently, global variables can not be marked with
+     'atomic'; only fields of a struct can.  This is a known limitation.
+     It would be useful to be able to mark global pointers with 'atomic'
+     to make the PCH machinery aware of them so that they are saved and
+     restored correctly to PCH files.
+
+'special ("NAME")'
+
+     The 'special' option is used to mark types that have to be dealt
+     with by special case machinery.  The parameter is the name of the
+     special case.  See 'gengtype.c' for further details.  Avoid adding
+     new special cases unless there is no other alternative.
+
+'user'
+
+     The 'user' option indicates that the code to mark structure fields
+     is completely handled by user-provided routines.  See section *note
+     User GC:: for details on what functions need to be provided.
+
+
+File: gccint.info,  Node: Inheritance and GTY,  Next: User GC,  Prev: GTY Options,  Up: Type Information
+
+22.2 Support for inheritance
+============================
+
+gengtype has some support for simple class hierarchies.  You can use
+this to have gengtype autogenerate marking routines, provided:
+
+   * There must be a concrete base class, with a discriminator
+     expression that can be used to identify which subclass an instance
+     is.
+   * Only single inheritance is used.
+   * None of the classes within the hierarchy are templates.
+
+ If your class hierarchy does not fit in this pattern, you must use
+*note User GC:: instead.
+
+ The base class and its discriminator must be identified using the
+"desc" option.  Each concrete subclass must use the "tag" option to
+identify which value of the discriminator it corresponds to.
+
+ Every class in the hierarchy must have a 'GTY(())' marker, as gengtype
+will only attempt to parse classes that have such a marker (1).
+
+     class GTY((desc("%h.kind"), tag("0"))) example_base
+     {
+     public:
+         int kind;
+         tree a;
+     };
+
+     class GTY((tag("1")) some_subclass : public example_base
+     {
+     public:
+         tree b;
+     };
+
+     class GTY((tag("2")) some_other_subclass : public example_base
+     {
+     public:
+         tree c;
+     };
+
+ The generated marking routines for the above will contain a "switch" on
+"kind", visiting all appropriate fields.  For example, if kind is 2, it
+will cast to "some_other_subclass" and visit fields a, b, and c.
+
+   ---------- Footnotes ----------
+
+   (1) Classes lacking such a marker will not be identified as being
+part of the hierarchy, and so the marking routines will not handle them,
+leading to a assertion failure within the marking routines due to an
+unknown tag value (assuming that assertions are enabled).
+
+
+File: gccint.info,  Node: User GC,  Next: GGC Roots,  Prev: Inheritance and GTY,  Up: Type Information
+
+22.3 Support for user-provided GC marking routines
+==================================================
+
+The garbage collector supports types for which no automatic marking code
+is generated.  For these types, the user is required to provide three
+functions: one to act as a marker for garbage collection, and two
+functions to act as marker and pointer walker for pre-compiled headers.
+
+ Given a structure 'struct GTY((user)) my_struct', the following
+functions should be defined to mark 'my_struct':
+
+     void gt_ggc_mx (my_struct *p)
+     {
+       /* This marks field 'fld'.  */
+       gt_ggc_mx (p->fld);
+     }
+
+     void gt_pch_nx (my_struct *p)
+     {
+       /* This marks field 'fld'.  */
+       gt_pch_nx (tp->fld);
+     }
+
+     void gt_pch_nx (my_struct *p, gt_pointer_operator op, void *cookie)
+     {
+       /* For every field 'fld', call the given pointer operator.  */
+       op (&(tp->fld), cookie);
+     }
+
+ In general, each marker 'M' should call 'M' for every pointer field in
+the structure.  Fields that are not allocated in GC or are not pointers
+must be ignored.
+
+ For embedded lists (e.g., structures with a 'next' or 'prev' pointer),
+the marker must follow the chain and mark every element in it.
+
+ Note that the rules for the pointer walker 'gt_pch_nx (my_struct *,
+gt_pointer_operator, void *)' are slightly different.  In this case, the
+operation 'op' must be applied to the _address_ of every pointer field.
+
+22.3.1 User-provided marking routines for template types
+--------------------------------------------------------
+
+When a template type 'TP' is marked with 'GTY', all instances of that
+type are considered user-provided types.  This means that the individual
+instances of 'TP' do not need to be marked with 'GTY'.  The user needs
+to provide template functions to mark all the fields of the type.
+
+ The following code snippets represent all the functions that need to be
+provided.  Note that type 'TP' may reference to more than one type.  In
+these snippets, there is only one type 'T', but there could be more.
+
+     template<typename T>
+     void gt_ggc_mx (TP<T> *tp)
+     {
+       extern void gt_ggc_mx (T&);
+
+       /* This marks field 'fld' of type 'T'.  */
+       gt_ggc_mx (tp->fld);
+     }
+
+     template<typename T>
+     void gt_pch_nx (TP<T> *tp)
+     {
+       extern void gt_pch_nx (T&);
+
+       /* This marks field 'fld' of type 'T'.  */
+       gt_pch_nx (tp->fld);
+     }
+
+     template<typename T>
+     void gt_pch_nx (TP<T *> *tp, gt_pointer_operator op, void *cookie)
+     {
+       /* For every field 'fld' of 'tp' with type 'T *', call the given
+          pointer operator.  */
+       op (&(tp->fld), cookie);
+     }
+
+     template<typename T>
+     void gt_pch_nx (TP<T> *tp, gt_pointer_operator, void *cookie)
+     {
+       extern void gt_pch_nx (T *, gt_pointer_operator, void *);
+
+       /* For every field 'fld' of 'tp' with type 'T', call the pointer
+          walker for all the fields of T.  */
+       gt_pch_nx (&(tp->fld), op, cookie);
+     }
+
+ Support for user-defined types is currently limited.  The following
+restrictions apply:
+
+  1. Type 'TP' and all the argument types 'T' must be marked with 'GTY'.
+
+  2. Type 'TP' can only have type names in its argument list.
+
+  3. The pointer walker functions are different for 'TP<T>' and 'TP<T
+     *>'.  In the case of 'TP<T>', references to 'T' must be handled by
+     calling 'gt_pch_nx' (which will, in turn, walk all the pointers
+     inside fields of 'T').  In the case of 'TP<T *>', references to 'T
+     *' must be handled by calling the 'op' function on the address of
+     the pointer (see the code snippets above).
+
+
+File: gccint.info,  Node: GGC Roots,  Next: Files,  Prev: User GC,  Up: Type Information
+
+22.4 Marking Roots for the Garbage Collector
+============================================
+
+In addition to keeping track of types, the type machinery also locates
+the global variables ("roots") that the garbage collector starts at.
+Roots must be declared using one of the following syntaxes:
+
+   * 'extern GTY(([OPTIONS])) TYPE NAME;'
+   * 'static GTY(([OPTIONS])) TYPE NAME;'
+The syntax
+   * 'GTY(([OPTIONS])) TYPE NAME;'
+is _not_ accepted.  There should be an 'extern' declaration of such a
+variable in a header somewhere--mark that, not the definition.  Or, if
+the variable is only used in one file, make it 'static'.
+
+
+File: gccint.info,  Node: Files,  Next: Invoking the garbage collector,  Prev: GGC Roots,  Up: Type Information
+
+22.5 Source Files Containing Type Information
+=============================================
+
+Whenever you add 'GTY' markers to a source file that previously had
+none, or create a new source file containing 'GTY' markers, there are
+three things you need to do:
+
+  1. You need to add the file to the list of source files the type
+     machinery scans.  There are four cases:
+
+       a. For a back-end file, this is usually done automatically; if
+          not, you should add it to 'target_gtfiles' in the appropriate
+          port's entries in 'config.gcc'.
+
+       b. For files shared by all front ends, add the filename to the
+          'GTFILES' variable in 'Makefile.in'.
+
+       c. For files that are part of one front end, add the filename to
+          the 'gtfiles' variable defined in the appropriate
+          'config-lang.in'.  Headers should appear before non-headers in
+          this list.
+
+       d. For files that are part of some but not all front ends, add
+          the filename to the 'gtfiles' variable of _all_ the front ends
+          that use it.
+
+  2. If the file was a header file, you'll need to check that it's
+     included in the right place to be visible to the generated files.
+     For a back-end header file, this should be done automatically.  For
+     a front-end header file, it needs to be included by the same file
+     that includes 'gtype-LANG.h'.  For other header files, it needs to
+     be included in 'gtype-desc.c', which is a generated file, so add it
+     to 'ifiles' in 'open_base_file' in 'gengtype.c'.
+
+     For source files that aren't header files, the machinery will
+     generate a header file that should be included in the source file
+     you just changed.  The file will be called 'gt-PATH.h' where PATH
+     is the pathname relative to the 'gcc' directory with slashes
+     replaced by -, so for example the header file to be included in
+     'cp/parser.c' is called 'gt-cp-parser.c'.  The generated header
+     file should be included after everything else in the source file.
+     Don't forget to mention this file as a dependency in the
+     'Makefile'!
+
+ For language frontends, there is another file that needs to be included
+somewhere.  It will be called 'gtype-LANG.h', where LANG is the name of
+the subdirectory the language is contained in.
+
+ Plugins can add additional root tables.  Run the 'gengtype' utility in
+plugin mode as 'gengtype -P pluginout.h SOURCE-DIR FILE-LIST PLUGIN*.C'
+with your plugin files PLUGIN*.C using 'GTY' to generate the PLUGINOUT.H
+file.  The GCC build tree is needed to be present in that mode.
+
+
+File: gccint.info,  Node: Invoking the garbage collector,  Next: Troubleshooting,  Prev: Files,  Up: Type Information
+
+22.6 How to invoke the garbage collector
+========================================
+
+The GCC garbage collector GGC is only invoked explicitly.  In contrast
+with many other garbage collectors, it is not implicitly invoked by
+allocation routines when a lot of memory has been consumed.  So the only
+way to have GGC reclaim storage is to call the 'ggc_collect' function
+explicitly.  This call is an expensive operation, as it may have to scan
+the entire heap.  Beware that local variables (on the GCC call stack)
+are not followed by such an invocation (as many other garbage collectors
+do): you should reference all your data from static or external 'GTY'-ed
+variables, and it is advised to call 'ggc_collect' with a shallow call
+stack.  The GGC is an exact mark and sweep garbage collector (so it does
+not scan the call stack for pointers).  In practice GCC passes don't
+often call 'ggc_collect' themselves, because it is called by the pass
+manager between passes.
+
+ At the time of the 'ggc_collect' call all pointers in the GC-marked
+structures must be valid or 'NULL'.  In practice this means that there
+should not be uninitialized pointer fields in the structures even if
+your code never reads or writes those fields at a particular instance.
+One way to ensure this is to use cleared versions of allocators unless
+all the fields are initialized manually immediately after allocation.
+
+
+File: gccint.info,  Node: Troubleshooting,  Prev: Invoking the garbage collector,  Up: Type Information
+
+22.7 Troubleshooting the garbage collector
+==========================================
+
+With the current garbage collector implementation, most issues should
+show up as GCC compilation errors.  Some of the most commonly
+encountered issues are described below.
+
+   * Gengtype does not produce allocators for a 'GTY'-marked type.
+     Gengtype checks if there is at least one possible path from GC
+     roots to at least one instance of each type before outputting
+     allocators.  If there is no such path, the 'GTY' markers will be
+     ignored and no allocators will be output.  Solve this by making
+     sure that there exists at least one such path.  If creating it is
+     unfeasible or raises a "code smell", consider if you really must
+     use GC for allocating such type.
+
+   * Link-time errors about undefined 'gt_ggc_r_foo_bar' and
+     similarly-named symbols.  Check if your 'foo_bar' source file has
+     '#include "gt-foo_bar.h"' as its very last line.
+
+
+File: gccint.info,  Node: Plugins,  Next: LTO,  Prev: Type Information,  Up: Top
+
+23 Plugins
+**********
+
+GCC plugin is a loadable module that provides extra features to the
+compiler, which they can further pass around as a shareable module.
+
+ GCC plugins provide developers with a rich subset of the GCC API to
+allow them to extend GCC as they see fit.  Whether it is writing an
+additional optimization pass, transforming code, or analyzing
+information, plugins can be quite useful.
+
+* Menu:
+
+* Plugins loading::      How can we load plugins.
+* Plugin API::           The APIs for plugins.
+* Plugins pass::         How a plugin interact with the pass manager.
+* Plugins GC::           How a plugin Interact with GCC Garbage Collector.
+* Plugins description::  Giving information about a plugin itself.
+* Plugins attr::         Registering custom attributes or pragmas.
+* Plugins recording::    Recording information about pass execution.
+* Plugins gate::         Controlling which passes are being run.
+* Plugins tracking::     Keeping track of available passes.
+* Plugins building::     How can we build a plugin.
+
+
+File: gccint.info,  Node: Plugins loading,  Next: Plugin API,  Up: Plugins
+
+23.1 Loading Plugins
+====================
+
+Plugins are supported on platforms that support '-ldl -rdynamic'.  They
+are loaded by the compiler using 'dlopen' and invoked at pre-determined
+locations in the compilation process.
+
+ Plugins are loaded with
+
+ '-fplugin=/path/to/NAME.so' '-fplugin-arg-NAME-KEY1[=VALUE1]'
+
+ The plugin arguments are parsed by GCC and passed to respective plugins
+as key-value pairs.  Multiple plugins can be invoked by specifying
+multiple '-fplugin' arguments.
+
+ A plugin can be simply given by its short name (no dots or slashes).
+When simply passing '-fplugin=NAME', the plugin is loaded from the
+'plugin' directory, so '-fplugin=NAME' is the same as '-fplugin=`gcc
+-print-file-name=plugin`/NAME.so', using backquote shell syntax to query
+the 'plugin' directory.
+
+
+File: gccint.info,  Node: Plugin API,  Next: Plugins pass,  Prev: Plugins loading,  Up: Plugins
+
+23.2 Plugin API
+===============
+
+Plugins are activated by the compiler at specific events as defined in
+'gcc-plugin.h'.  For each event of interest, the plugin should call
+'register_callback' specifying the name of the event and address of the
+callback function that will handle that event.
+
+ The header 'gcc-plugin.h' must be the first gcc header to be included.
+
+23.2.1 Plugin license check
+---------------------------
+
+Every plugin should define the global symbol 'plugin_is_GPL_compatible'
+to assert that it has been licensed under a GPL-compatible license.  If
+this symbol does not exist, the compiler will emit a fatal error and
+exit with the error message:
+
+     fatal error: plugin NAME is not licensed under a GPL-compatible license
+     NAME: undefined symbol: plugin_is_GPL_compatible
+     compilation terminated
+
+ The declared type of the symbol should be int, to match a forward
+declaration in 'gcc-plugin.h' that suppresses C++ mangling.  It does not
+need to be in any allocated section, though.  The compiler merely
+asserts that the symbol exists in the global scope.  Something like this
+is enough:
+
+     int plugin_is_GPL_compatible;
+
+23.2.2 Plugin initialization
+----------------------------
+
+Every plugin should export a function called 'plugin_init' that is
+called right after the plugin is loaded.  This function is responsible
+for registering all the callbacks required by the plugin and do any
+other required initialization.
+
+ This function is called from 'compile_file' right before invoking the
+parser.  The arguments to 'plugin_init' are:
+
+   * 'plugin_info': Plugin invocation information.
+   * 'version': GCC version.
+
+ The 'plugin_info' struct is defined as follows:
+
+     struct plugin_name_args
+     {
+       char *base_name;              /* Short name of the plugin
+                                        (filename without .so suffix). */
+       const char *full_name;        /* Path to the plugin as specified with
+                                        -fplugin=. */
+       int argc;                     /* Number of arguments specified with
+                                        -fplugin-arg-.... */
+       struct plugin_argument *argv; /* Array of ARGC key-value pairs. */
+       const char *version;          /* Version string provided by plugin. */
+       const char *help;             /* Help string provided by plugin. */
+     }
+
+ If initialization fails, 'plugin_init' must return a non-zero value.
+Otherwise, it should return 0.
+
+ The version of the GCC compiler loading the plugin is described by the
+following structure:
+
+     struct plugin_gcc_version
+     {
+       const char *basever;
+       const char *datestamp;
+       const char *devphase;
+       const char *revision;
+       const char *configuration_arguments;
+     };
+
+ The function 'plugin_default_version_check' takes two pointers to such
+structure and compare them field by field.  It can be used by the
+plugin's 'plugin_init' function.
+
+ The version of GCC used to compile the plugin can be found in the
+symbol 'gcc_version' defined in the header 'plugin-version.h'.  The
+recommended version check to perform looks like
+
+     #include "plugin-version.h"
+     ...
+
+     int
+     plugin_init (struct plugin_name_args *plugin_info,
+                  struct plugin_gcc_version *version)
+     {
+       if (!plugin_default_version_check (version, &gcc_version))
+         return 1;
+
+     }
+
+ but you can also check the individual fields if you want a less strict
+check.
+
+23.2.3 Plugin callbacks
+-----------------------
+
+Callback functions have the following prototype:
+
+     /* The prototype for a plugin callback function.
+          gcc_data  - event-specific data provided by GCC
+          user_data - plugin-specific data provided by the plug-in.  */
+     typedef void (*plugin_callback_func)(void *gcc_data, void *user_data);
+
+ Callbacks can be invoked at the following pre-determined events:
+
+     enum plugin_event
+     {
+       PLUGIN_PASS_MANAGER_SETUP,    /* To hook into pass manager.  */
+       PLUGIN_FINISH_TYPE,           /* After finishing parsing a type.  */
+       PLUGIN_FINISH_DECL,           /* After finishing parsing a declaration. */
+       PLUGIN_FINISH_UNIT,           /* Useful for summary processing.  */
+       PLUGIN_PRE_GENERICIZE,        /* Allows to see low level AST in C and C++ frontends.  */
+       PLUGIN_FINISH,                /* Called before GCC exits.  */
+       PLUGIN_INFO,                  /* Information about the plugin. */
+       PLUGIN_GGC_START,             /* Called at start of GCC Garbage Collection. */
+       PLUGIN_GGC_MARKING,           /* Extend the GGC marking. */
+       PLUGIN_GGC_END,               /* Called at end of GGC. */
+       PLUGIN_REGISTER_GGC_ROOTS,    /* Register an extra GGC root table. */
+       PLUGIN_REGISTER_GGC_CACHES,   /* Register an extra GGC cache table. */
+       PLUGIN_ATTRIBUTES,            /* Called during attribute registration */
+       PLUGIN_START_UNIT,            /* Called before processing a translation unit.  */
+       PLUGIN_PRAGMAS,               /* Called during pragma registration. */
+       /* Called before first pass from all_passes.  */
+       PLUGIN_ALL_PASSES_START,
+       /* Called after last pass from all_passes.  */
+       PLUGIN_ALL_PASSES_END,
+       /* Called before first ipa pass.  */
+       PLUGIN_ALL_IPA_PASSES_START,
+       /* Called after last ipa pass.  */
+       PLUGIN_ALL_IPA_PASSES_END,
+       /* Allows to override pass gate decision for current_pass.  */
+       PLUGIN_OVERRIDE_GATE,
+       /* Called before executing a pass.  */
+       PLUGIN_PASS_EXECUTION,
+       /* Called before executing subpasses of a GIMPLE_PASS in
+          execute_ipa_pass_list.  */
+       PLUGIN_EARLY_GIMPLE_PASSES_START,
+       /* Called after executing subpasses of a GIMPLE_PASS in
+          execute_ipa_pass_list.  */
+       PLUGIN_EARLY_GIMPLE_PASSES_END,
+       /* Called when a pass is first instantiated.  */
+       PLUGIN_NEW_PASS,
+     /* Called when a file is #include-d or given via the #line directive.
+        This could happen many times.  The event data is the included file path,
+        as a const char* pointer.  */
+       PLUGIN_INCLUDE_FILE,
+
+       PLUGIN_EVENT_FIRST_DYNAMIC    /* Dummy event used for indexing callback
+                                        array.  */
+     };
+
+ In addition, plugins can also look up the enumerator of a named event,
+and / or generate new events dynamically, by calling the function
+'get_named_event_id'.
+
+ To register a callback, the plugin calls 'register_callback' with the
+arguments:
+
+   * 'char *name': Plugin name.
+   * 'int event': The event code.
+   * 'plugin_callback_func callback': The function that handles 'event'.
+   * 'void *user_data': Pointer to plugin-specific data.
+
+ For the PLUGIN_PASS_MANAGER_SETUP, PLUGIN_INFO,
+PLUGIN_REGISTER_GGC_ROOTS and PLUGIN_REGISTER_GGC_CACHES pseudo-events
+the 'callback' should be null, and the 'user_data' is specific.
+
+ When the PLUGIN_PRAGMAS event is triggered (with a null pointer as data
+from GCC), plugins may register their own pragmas.  Notice that pragmas
+are not available from 'lto1', so plugins used with '-flto' option to
+GCC during link-time optimization cannot use pragmas and do not even see
+functions like 'c_register_pragma' or 'pragma_lex'.
+
+ The PLUGIN_INCLUDE_FILE event, with a 'const char*' file path as GCC
+data, is triggered for processing of '#include' or '#line' directives.
+
+ The PLUGIN_FINISH event is the last time that plugins can call GCC
+functions, notably emit diagnostics with 'warning', 'error' etc.
+
+
+File: gccint.info,  Node: Plugins pass,  Next: Plugins GC,  Prev: Plugin API,  Up: Plugins
+
+23.3 Interacting with the pass manager
+======================================
+
+There needs to be a way to add/reorder/remove passes dynamically.  This
+is useful for both analysis plugins (plugging in after a certain pass
+such as CFG or an IPA pass) and optimization plugins.
+
+ Basic support for inserting new passes or replacing existing passes is
+provided.  A plugin registers a new pass with GCC by calling
+'register_callback' with the 'PLUGIN_PASS_MANAGER_SETUP' event and a
+pointer to a 'struct register_pass_info' object defined as follows
+
+     enum pass_positioning_ops
+     {
+       PASS_POS_INSERT_AFTER,  // Insert after the reference pass.
+       PASS_POS_INSERT_BEFORE, // Insert before the reference pass.
+       PASS_POS_REPLACE        // Replace the reference pass.
+     };
+
+     struct register_pass_info
+     {
+       struct opt_pass *pass;            /* New pass provided by the plugin.  */
+       const char *reference_pass_name;  /* Name of the reference pass for hooking
+                                            up the new pass.  */
+       int ref_pass_instance_number;     /* Insert the pass at the specified
+                                            instance number of the reference pass.  */
+                                         /* Do it for every instance if it is 0.  */
+       enum pass_positioning_ops pos_op; /* how to insert the new pass.  */
+     };
+
+
+     /* Sample plugin code that registers a new pass.  */
+     int
+     plugin_init (struct plugin_name_args *plugin_info,
+                  struct plugin_gcc_version *version)
+     {
+       struct register_pass_info pass_info;
+
+       ...
+
+       /* Code to fill in the pass_info object with new pass information.  */
+
+       ...
+
+       /* Register the new pass.  */
+       register_callback (plugin_info->base_name, PLUGIN_PASS_MANAGER_SETUP, NULL, &pass_info);
+
+       ...
+     }
+
+
+File: gccint.info,  Node: Plugins GC,  Next: Plugins description,  Prev: Plugins pass,  Up: Plugins
+
+23.4 Interacting with the GCC Garbage Collector
+===============================================
+
+Some plugins may want to be informed when GGC (the GCC Garbage
+Collector) is running.  They can register callbacks for the
+'PLUGIN_GGC_START' and 'PLUGIN_GGC_END' events (for which the callback
+is called with a null 'gcc_data') to be notified of the start or end of
+the GCC garbage collection.
+
+ Some plugins may need to have GGC mark additional data.  This can be
+done by registering a callback (called with a null 'gcc_data') for the
+'PLUGIN_GGC_MARKING' event.  Such callbacks can call the 'ggc_set_mark'
+routine, preferably through the 'ggc_mark' macro (and conversely, these
+routines should usually not be used in plugins outside of the
+'PLUGIN_GGC_MARKING' event).
+
+ Some plugins may need to add extra GGC root tables, e.g.  to handle
+their own 'GTY'-ed data.  This can be done with the
+'PLUGIN_REGISTER_GGC_ROOTS' pseudo-event with a null callback and the
+extra root table (of type 'struct ggc_root_tab*') as 'user_data'.
+Plugins that want to use the 'if_marked' hash table option can add the
+extra GGC cache tables generated by 'gengtype' using the
+'PLUGIN_REGISTER_GGC_CACHES' pseudo-event with a null callback and the
+extra cache table (of type 'struct ggc_cache_tab*') as 'user_data'.
+Running the 'gengtype -p SOURCE-DIR FILE-LIST PLUGIN*.C ...' utility
+generates these extra root tables.
+
+ You should understand the details of memory management inside GCC
+before using 'PLUGIN_GGC_MARKING', 'PLUGIN_REGISTER_GGC_ROOTS' or
+'PLUGIN_REGISTER_GGC_CACHES'.
+
+
+File: gccint.info,  Node: Plugins description,  Next: Plugins attr,  Prev: Plugins GC,  Up: Plugins
+
+23.5 Giving information about a plugin
+======================================
+
+A plugin should give some information to the user about itself.  This
+uses the following structure:
+
+     struct plugin_info
+     {
+       const char *version;
+       const char *help;
+     };
+
+ Such a structure is passed as the 'user_data' by the plugin's init
+routine using 'register_callback' with the 'PLUGIN_INFO' pseudo-event
+and a null callback.
+
+
+File: gccint.info,  Node: Plugins attr,  Next: Plugins recording,  Prev: Plugins description,  Up: Plugins
+
+23.6 Registering custom attributes or pragmas
+=============================================
+
+For analysis (or other) purposes it is useful to be able to add custom
+attributes or pragmas.
+
+ The 'PLUGIN_ATTRIBUTES' callback is called during attribute
+registration.  Use the 'register_attribute' function to register custom
+attributes.
+
+     /* Attribute handler callback */
+     static tree
+     handle_user_attribute (tree *node, tree name, tree args,
+                            int flags, bool *no_add_attrs)
+     {
+       return NULL_TREE;
+     }
+
+     /* Attribute definition */
+     static struct attribute_spec user_attr =
+       { "user", 1, 1, false,  false, false, handle_user_attribute, false };
+
+     /* Plugin callback called during attribute registration.
+     Registered with register_callback (plugin_name, PLUGIN_ATTRIBUTES, register_attributes, NULL)
+     */
+     static void
+     register_attributes (void *event_data, void *data)
+     {
+       warning (0, G_("Callback to register attributes"));
+       register_attribute (&user_attr);
+     }
+
+ The PLUGIN_PRAGMAS callback is called once during pragmas registration.
+Use the 'c_register_pragma', 'c_register_pragma_with_data',
+'c_register_pragma_with_expansion',
+'c_register_pragma_with_expansion_and_data' functions to register custom
+pragmas and their handlers (which often want to call 'pragma_lex') from
+'c-family/c-pragma.h'.
+
+     /* Plugin callback called during pragmas registration. Registered with
+          register_callback (plugin_name, PLUGIN_PRAGMAS,
+                             register_my_pragma, NULL);
+     */
+     static void
+     register_my_pragma (void *event_data, void *data)
+     {
+       warning (0, G_("Callback to register pragmas"));
+       c_register_pragma ("GCCPLUGIN", "sayhello", handle_pragma_sayhello);
+     }
+
+ It is suggested to pass '"GCCPLUGIN"' (or a short name identifying your
+plugin) as the "space" argument of your pragma.
+
+ Pragmas registered with 'c_register_pragma_with_expansion' or
+'c_register_pragma_with_expansion_and_data' support preprocessor
+expansions.  For example:
+
+     #define NUMBER 10
+     #pragma GCCPLUGIN foothreshold (NUMBER)
+
+
+File: gccint.info,  Node: Plugins recording,  Next: Plugins gate,  Prev: Plugins attr,  Up: Plugins
+
+23.7 Recording information about pass execution
+===============================================
+
+The event PLUGIN_PASS_EXECUTION passes the pointer to the executed pass
+(the same as current_pass) as 'gcc_data' to the callback.  You can also
+inspect cfun to find out about which function this pass is executed for.
+Note that this event will only be invoked if the gate check (if
+applicable, modified by PLUGIN_OVERRIDE_GATE) succeeds.  You can use
+other hooks, like 'PLUGIN_ALL_PASSES_START', 'PLUGIN_ALL_PASSES_END',
+'PLUGIN_ALL_IPA_PASSES_START', 'PLUGIN_ALL_IPA_PASSES_END',
+'PLUGIN_EARLY_GIMPLE_PASSES_START', and/or
+'PLUGIN_EARLY_GIMPLE_PASSES_END' to manipulate global state in your
+plugin(s) in order to get context for the pass execution.
+
+
+File: gccint.info,  Node: Plugins gate,  Next: Plugins tracking,  Prev: Plugins recording,  Up: Plugins
+
+23.8 Controlling which passes are being run
+===========================================
+
+After the original gate function for a pass is called, its result - the
+gate status - is stored as an integer.  Then the event
+'PLUGIN_OVERRIDE_GATE' is invoked, with a pointer to the gate status in
+the 'gcc_data' parameter to the callback function.  A nonzero value of
+the gate status means that the pass is to be executed.  You can both
+read and write the gate status via the passed pointer.
+
+
+File: gccint.info,  Node: Plugins tracking,  Next: Plugins building,  Prev: Plugins gate,  Up: Plugins
+
+23.9 Keeping track of available passes
+======================================
+
+When your plugin is loaded, you can inspect the various pass lists to
+determine what passes are available.  However, other plugins might add
+new passes.  Also, future changes to GCC might cause generic passes to
+be added after plugin loading.  When a pass is first added to one of the
+pass lists, the event 'PLUGIN_NEW_PASS' is invoked, with the callback
+parameter 'gcc_data' pointing to the new pass.
+
+
+File: gccint.info,  Node: Plugins building,  Prev: Plugins tracking,  Up: Plugins
+
+23.10 Building GCC plugins
+==========================
+
+If plugins are enabled, GCC installs the headers needed to build a
+plugin (somewhere in the installation tree, e.g.  under '/usr/local').
+In particular a 'plugin/include' directory is installed, containing all
+the header files needed to build plugins.
+
+ On most systems, you can query this 'plugin' directory by invoking 'gcc
+-print-file-name=plugin' (replace if needed 'gcc' with the appropriate
+program path).
+
+ Inside plugins, this 'plugin' directory name can be queried by calling
+'default_plugin_dir_name ()'.
+
+ Plugins may know, when they are compiled, the GCC version for which
+'plugin-version.h' is provided.  The constant macros
+'GCCPLUGIN_VERSION_MAJOR', 'GCCPLUGIN_VERSION_MINOR',
+'GCCPLUGIN_VERSION_PATCHLEVEL', 'GCCPLUGIN_VERSION' are integer numbers,
+so a plugin could ensure it is built for GCC 4.7 with
+     #if GCCPLUGIN_VERSION != 4007
+     #error this GCC plugin is for GCC 4.7
+     #endif
+
+ The following GNU Makefile excerpt shows how to build a simple plugin:
+
+     HOST_GCC=g++
+     TARGET_GCC=gcc
+     PLUGIN_SOURCE_FILES= plugin1.c plugin2.cc
+     GCCPLUGINS_DIR:= $(shell $(TARGET_GCC) -print-file-name=plugin)
+     CXXFLAGS+= -I$(GCCPLUGINS_DIR)/include -fPIC -fno-rtti -O2
+
+     plugin.so: $(PLUGIN_SOURCE_FILES)
+        $(HOST_GCC) -shared $(CXXFLAGS) $^ -o $@
+
+ A single source file plugin may be built with 'g++ -I`gcc
+-print-file-name=plugin`/include -fPIC -shared -fno-rtti -O2 plugin.c -o
+plugin.so', using backquote shell syntax to query the 'plugin'
+directory.
+
+ When a plugin needs to use 'gengtype', be sure that both 'gengtype' and
+'gtype.state' have the same version as the GCC for which the plugin is
+built.
+
+
+File: gccint.info,  Node: LTO,  Next: Funding,  Prev: Plugins,  Up: Top
+
+24 Link Time Optimization
+*************************
+
+Link Time Optimization (LTO) gives GCC the capability of dumping its
+internal representation (GIMPLE) to disk, so that all the different
+compilation units that make up a single executable can be optimized as a
+single module.  This expands the scope of inter-procedural optimizations
+to encompass the whole program (or, rather, everything that is visible
+at link time).
+
+* Menu:
+
+* LTO Overview::            Overview of LTO.
+* LTO object file layout::  LTO file sections in ELF.
+* IPA::                     Using summary information in IPA passes.
+* WHOPR::                   Whole program assumptions,
+                            linker plugin and symbol visibilities.
+* Internal flags::          Internal flags controlling 'lto1'.
+
+
+File: gccint.info,  Node: LTO Overview,  Next: LTO object file layout,  Up: LTO
+
+24.1 Design Overview
+====================
+
+Link time optimization is implemented as a GCC front end for a bytecode
+representation of GIMPLE that is emitted in special sections of '.o'
+files.  Currently, LTO support is enabled in most ELF-based systems, as
+well as darwin, cygwin and mingw systems.
+
+ Since GIMPLE bytecode is saved alongside final object code, object
+files generated with LTO support are larger than regular object files.
+This "fat" object format makes it easy to integrate LTO into existing
+build systems, as one can, for instance, produce archives of the files.
+Additionally, one might be able to ship one set of fat objects which
+could be used both for development and the production of optimized
+builds.  A, perhaps surprising, side effect of this feature is that any
+mistake in the toolchain that leads to LTO information not being used
+(e.g. an older 'libtool' calling 'ld' directly).  This is both an
+advantage, as the system is more robust, and a disadvantage, as the user
+is not informed that the optimization has been disabled.
+
+ The current implementation only produces "fat" objects, effectively
+doubling compilation time and increasing file sizes up to 5x the
+original size.  This hides the problem that some tools, such as 'ar' and
+'nm', need to understand symbol tables of LTO sections.  These tools
+were extended to use the plugin infrastructure, and with these problems
+solved, GCC will also support "slim" objects consisting of the
+intermediate code alone.
+
+ At the highest level, LTO splits the compiler in two.  The first half
+(the "writer") produces a streaming representation of all the internal
+data structures needed to optimize and generate code.  This includes
+declarations, types, the callgraph and the GIMPLE representation of
+function bodies.
+
+ When '-flto' is given during compilation of a source file, the pass
+manager executes all the passes in 'all_lto_gen_passes'.  Currently,
+this phase is composed of two IPA passes:
+
+   * 'pass_ipa_lto_gimple_out' This pass executes the function
+     'lto_output' in 'lto-streamer-out.c', which traverses the call
+     graph encoding every reachable declaration, type and function.
+     This generates a memory representation of all the file sections
+     described below.
+
+   * 'pass_ipa_lto_finish_out' This pass executes the function
+     'produce_asm_for_decls' in 'lto-streamer-out.c', which takes the
+     memory image built in the previous pass and encodes it in the
+     corresponding ELF file sections.
+
+ The second half of LTO support is the "reader".  This is implemented as
+the GCC front end 'lto1' in 'lto/lto.c'.  When 'collect2' detects a link
+set of '.o'/'.a' files with LTO information and the '-flto' is enabled,
+it invokes 'lto1' which reads the set of files and aggregates them into
+a single translation unit for optimization.  The main entry point for
+the reader is 'lto/lto.c':'lto_main'.
+
+24.1.1 LTO modes of operation
+-----------------------------
+
+One of the main goals of the GCC link-time infrastructure was to allow
+effective compilation of large programs.  For this reason GCC implements
+two link-time compilation modes.
+
+  1. _LTO mode_, in which the whole program is read into the compiler at
+     link-time and optimized in a similar way as if it were a single
+     source-level compilation unit.
+
+  2. _WHOPR or partitioned mode_, designed to utilize multiple CPUs
+     and/or a distributed compilation environment to quickly link large
+     applications.  WHOPR stands for WHOle Program optimizeR (not to be
+     confused with the semantics of '-fwhole-program').  It partitions
+     the aggregated callgraph from many different '.o' files and
+     distributes the compilation of the sub-graphs to different CPUs.
+
+     Note that distributed compilation is not implemented yet, but since
+     the parallelism is facilitated via generating a 'Makefile', it
+     would be easy to implement.
+
+ WHOPR splits LTO into three main stages:
+  1. Local generation (LGEN) This stage executes in parallel.  Every
+     file in the program is compiled into the intermediate language and
+     packaged together with the local call-graph and summary
+     information.  This stage is the same for both the LTO and WHOPR
+     compilation mode.
+
+  2. Whole Program Analysis (WPA) WPA is performed sequentially.  The
+     global call-graph is generated, and a global analysis procedure
+     makes transformation decisions.  The global call-graph is
+     partitioned to facilitate parallel optimization during phase 3.
+     The results of the WPA stage are stored into new object files which
+     contain the partitions of program expressed in the intermediate
+     language and the optimization decisions.
+
+  3. Local transformations (LTRANS) This stage executes in parallel.
+     All the decisions made during phase 2 are implemented locally in
+     each partitioned object file, and the final object code is
+     generated.  Optimizations which cannot be decided efficiently
+     during the phase 2 may be performed on the local call-graph
+     partitions.
+
+ WHOPR can be seen as an extension of the usual LTO mode of compilation.
+In LTO, WPA and LTRANS are executed within a single execution of the
+compiler, after the whole program has been read into memory.
+
+ When compiling in WHOPR mode, the callgraph is partitioned during the
+WPA stage.  The whole program is split into a given number of partitions
+of roughly the same size.  The compiler tries to minimize the number of
+references which cross partition boundaries.  The main advantage of
+WHOPR is to allow the parallel execution of LTRANS stages, which are the
+most time-consuming part of the compilation process.  Additionally, it
+avoids the need to load the whole program into memory.
+
+
+File: gccint.info,  Node: LTO object file layout,  Next: IPA,  Prev: LTO Overview,  Up: LTO
+
+24.2 LTO file sections
+======================
+
+LTO information is stored in several ELF sections inside object files.
+Data structures and enum codes for sections are defined in
+'lto-streamer.h'.
+
+ These sections are emitted from 'lto-streamer-out.c' and mapped in all
+at once from 'lto/lto.c':'lto_file_read'.  The individual functions
+dealing with the reading/writing of each section are described below.
+
+   * Command line options ('.gnu.lto_.opts')
+
+     This section contains the command line options used to generate the
+     object files.  This is used at link time to determine the
+     optimization level and other settings when they are not explicitly
+     specified at the linker command line.
+
+     Currently, GCC does not support combining LTO object files compiled
+     with different set of the command line options into a single
+     binary.  At link time, the options given on the command line and
+     the options saved on all the files in a link-time set are applied
+     globally.  No attempt is made at validating the combination of
+     flags (other than the usual validation done by option processing).
+     This is implemented in 'lto/lto.c':'lto_read_all_file_options'.
+
+   * Symbol table ('.gnu.lto_.symtab')
+
+     This table replaces the ELF symbol table for functions and
+     variables represented in the LTO IL. Symbols used and exported by
+     the optimized assembly code of "fat" objects might not match the
+     ones used and exported by the intermediate code.  This table is
+     necessary because the intermediate code is less optimized and thus
+     requires a separate symbol table.
+
+     Additionally, the binary code in the "fat" object will lack a call
+     to a function, since the call was optimized out at compilation time
+     after the intermediate language was streamed out.  In some special
+     cases, the same optimization may not happen during link-time
+     optimization.  This would lead to an undefined symbol if only one
+     symbol table was used.
+
+     The symbol table is emitted in
+     'lto-streamer-out.c':'produce_symtab'.
+
+   * Global declarations and types ('.gnu.lto_.decls')
+
+     This section contains an intermediate language dump of all
+     declarations and types required to represent the callgraph, static
+     variables and top-level debug info.
+
+     The contents of this section are emitted in
+     'lto-streamer-out.c':'produce_asm_for_decls'.  Types and symbols
+     are emitted in a topological order that preserves the sharing of
+     pointers when the file is read back in
+     ('lto.c':'read_cgraph_and_symbols').
+
+   * The callgraph ('.gnu.lto_.cgraph')
+
+     This section contains the basic data structure used by the GCC
+     inter-procedural optimization infrastructure.  This section stores
+     an annotated multi-graph which represents the functions and call
+     sites as well as the variables, aliases and top-level 'asm'
+     statements.
+
+     This section is emitted in 'lto-streamer-out.c':'output_cgraph' and
+     read in 'lto-cgraph.c':'input_cgraph'.
+
+   * IPA references ('.gnu.lto_.refs')
+
+     This section contains references between function and static
+     variables.  It is emitted by 'lto-cgraph.c':'output_refs' and read
+     by 'lto-cgraph.c':'input_refs'.
+
+   * Function bodies ('.gnu.lto_.function_body.<name>')
+
+     This section contains function bodies in the intermediate language
+     representation.  Every function body is in a separate section to
+     allow copying of the section independently to different object
+     files or reading the function on demand.
+
+     Functions are emitted in 'lto-streamer-out.c':'output_function' and
+     read in 'lto-streamer-in.c':'input_function'.
+
+   * Static variable initializers ('.gnu.lto_.vars')
+
+     This section contains all the symbols in the global variable pool.
+     It is emitted by 'lto-cgraph.c':'output_varpool' and read in
+     'lto-cgraph.c':'input_cgraph'.
+
+   * Summaries and optimization summaries used by IPA passes
+     ('.gnu.lto_.<xxx>', where '<xxx>' is one of 'jmpfuncs', 'pureconst'
+     or 'reference')
+
+     These sections are used by IPA passes that need to emit summary
+     information during LTO generation to be read and aggregated at link
+     time.  Each pass is responsible for implementing two pass manager
+     hooks: one for writing the summary and another for reading it in.
+     The format of these sections is entirely up to each individual
+     pass.  The only requirement is that the writer and reader hooks
+     agree on the format.
+
+
+File: gccint.info,  Node: IPA,  Next: WHOPR,  Prev: LTO object file layout,  Up: LTO
+
+24.3 Using summary information in IPA passes
+============================================
+
+Programs are represented internally as a _callgraph_ (a multi-graph
+where nodes are functions and edges are call sites) and a _varpool_ (a
+list of static and external variables in the program).
+
+ The inter-procedural optimization is organized as a sequence of
+individual passes, which operate on the callgraph and the varpool.  To
+make the implementation of WHOPR possible, every inter-procedural
+optimization pass is split into several stages that are executed at
+different times during WHOPR compilation:
+
+   * LGEN time
+       1. _Generate summary_ ('generate_summary' in 'struct
+          ipa_opt_pass_d').  This stage analyzes every function body and
+          variable initializer is examined and stores relevant
+          information into a pass-specific data structure.
+
+       2. _Write summary_ ('write_summary' in 'struct ipa_opt_pass_d').
+          This stage writes all the pass-specific information generated
+          by 'generate_summary'.  Summaries go into their own
+          'LTO_section_*' sections that have to be declared in
+          'lto-streamer.h':'enum lto_section_type'.  A new section is
+          created by calling 'create_output_block' and data can be
+          written using the 'lto_output_*' routines.
+
+   * WPA time
+       1. _Read summary_ ('read_summary' in 'struct ipa_opt_pass_d').
+          This stage reads all the pass-specific information in exactly
+          the same order that it was written by 'write_summary'.
+
+       2. _Execute_ ('execute' in 'struct opt_pass').  This performs
+          inter-procedural propagation.  This must be done without
+          actual access to the individual function bodies or variable
+          initializers.  Typically, this results in a transitive closure
+          operation over the summary information of all the nodes in the
+          callgraph.
+
+       3. _Write optimization summary_ ('write_optimization_summary' in
+          'struct ipa_opt_pass_d').  This writes the result of the
+          inter-procedural propagation into the object file.  This can
+          use the same data structures and helper routines used in
+          'write_summary'.
+
+   * LTRANS time
+       1. _Read optimization summary_ ('read_optimization_summary' in
+          'struct ipa_opt_pass_d').  The counterpart to
+          'write_optimization_summary'.  This reads the interprocedural
+          optimization decisions in exactly the same format emitted by
+          'write_optimization_summary'.
+
+       2. _Transform_ ('function_transform' and 'variable_transform' in
+          'struct ipa_opt_pass_d').  The actual function bodies and
+          variable initializers are updated based on the information
+          passed down from the _Execute_ stage.
+
+ The implementation of the inter-procedural passes are shared between
+LTO, WHOPR and classic non-LTO compilation.
+
+   * During the traditional file-by-file mode every pass executes its
+     own _Generate summary_, _Execute_, and _Transform_ stages within
+     the single execution context of the compiler.
+
+   * In LTO compilation mode, every pass uses _Generate summary_ and
+     _Write summary_ stages at compilation time, while the _Read
+     summary_, _Execute_, and _Transform_ stages are executed at link
+     time.
+
+   * In WHOPR mode all stages are used.
+
+ To simplify development, the GCC pass manager differentiates between
+normal inter-procedural passes and small inter-procedural passes.  A
+_small inter-procedural pass_ ('SIMPLE_IPA_PASS') is a pass that does
+everything at once and thus it can not be executed during WPA in WHOPR
+mode.  It defines only the _Execute_ stage and during this stage it
+accesses and modifies the function bodies.  Such passes are useful for
+optimization at LGEN or LTRANS time and are used, for example, to
+implement early optimization before writing object files.  The simple
+inter-procedural passes can also be used for easier prototyping and
+development of a new inter-procedural pass.
+
+24.3.1 Virtual clones
+---------------------
+
+One of the main challenges of introducing the WHOPR compilation mode was
+addressing the interactions between optimization passes.  In LTO
+compilation mode, the passes are executed in a sequence, each of which
+consists of analysis (or _Generate summary_), propagation (or _Execute_)
+and _Transform_ stages.  Once the work of one pass is finished, the next
+pass sees the updated program representation and can execute.  This
+makes the individual passes dependent on each other.
+
+ In WHOPR mode all passes first execute their _Generate summary_ stage.
+Then summary writing marks the end of the LGEN stage.  At WPA time, the
+summaries are read back into memory and all passes run the _Execute_
+stage.  Optimization summaries are streamed and sent to LTRANS, where
+all the passes execute the _Transform_ stage.
+
+ Most optimization passes split naturally into analysis, propagation and
+transformation stages.  But some do not.  The main problem arises when
+one pass performs changes and the following pass gets confused by seeing
+different callgraphs between the _Transform_ stage and the _Generate
+summary_ or _Execute_ stage.  This means that the passes are required to
+communicate their decisions with each other.
+
+ To facilitate this communication, the GCC callgraph infrastructure
+implements _virtual clones_, a method of representing the changes
+performed by the optimization passes in the callgraph without needing to
+update function bodies.
+
+ A _virtual clone_ in the callgraph is a function that has no associated
+body, just a description of how to create its body based on a different
+function (which itself may be a virtual clone).
+
+ The description of function modifications includes adjustments to the
+function's signature (which allows, for example, removing or adding
+function arguments), substitutions to perform on the function body, and,
+for inlined functions, a pointer to the function that it will be inlined
+into.
+
+ It is also possible to redirect any edge of the callgraph from a
+function to its virtual clone.  This implies updating of the call site
+to adjust for the new function signature.
+
+ Most of the transformations performed by inter-procedural optimizations
+can be represented via virtual clones.  For instance, a constant
+propagation pass can produce a virtual clone of the function which
+replaces one of its arguments by a constant.  The inliner can represent
+its decisions by producing a clone of a function whose body will be
+later integrated into a given function.
+
+ Using _virtual clones_, the program can be easily updated during the
+_Execute_ stage, solving most of pass interactions problems that would
+otherwise occur during _Transform_.
+
+ Virtual clones are later materialized in the LTRANS stage and turned
+into real functions.  Passes executed after the virtual clone were
+introduced also perform their _Transform_ stage on new functions, so for
+a pass there is no significant difference between operating on a real
+function or a virtual clone introduced before its _Execute_ stage.
+
+ Optimization passes then work on virtual clones introduced before their
+_Execute_ stage as if they were real functions.  The only difference is
+that clones are not visible during the _Generate Summary_ stage.
+
+ To keep function summaries updated, the callgraph interface allows an
+optimizer to register a callback that is called every time a new clone
+is introduced as well as when the actual function or variable is
+generated or when a function or variable is removed.  These hooks are
+registered in the _Generate summary_ stage and allow the pass to keep
+its information intact until the _Execute_ stage.  The same hooks can
+also be registered during the _Execute_ stage to keep the optimization
+summaries updated for the _Transform_ stage.
+
+24.3.2 IPA references
+---------------------
+
+GCC represents IPA references in the callgraph.  For a function or
+variable 'A', the _IPA reference_ is a list of all locations where the
+address of 'A' is taken and, when 'A' is a variable, a list of all
+direct stores and reads to/from 'A'.  References represent an oriented
+multi-graph on the union of nodes of the callgraph and the varpool.  See
+'ipa-reference.c':'ipa_reference_write_optimization_summary' and
+'ipa-reference.c':'ipa_reference_read_optimization_summary' for details.
+
+24.3.3 Jump functions
+---------------------
+
+Suppose that an optimization pass sees a function 'A' and it knows the
+values of (some of) its arguments.  The _jump function_ describes the
+value of a parameter of a given function call in function 'A' based on
+this knowledge.
+
+ Jump functions are used by several optimizations, such as the
+inter-procedural constant propagation pass and the devirtualization
+pass.  The inliner also uses jump functions to perform inlining of
+callbacks.
+
+
+File: gccint.info,  Node: WHOPR,  Next: Internal flags,  Prev: IPA,  Up: LTO
+
+24.4 Whole program assumptions, linker plugin and symbol visibilities
+=====================================================================
+
+Link-time optimization gives relatively minor benefits when used alone.
+The problem is that propagation of inter-procedural information does not
+work well across functions and variables that are called or referenced
+by other compilation units (such as from a dynamically linked library).
+We say that such functions and variables are _externally visible_.
+
+ To make the situation even more difficult, many applications organize
+themselves as a set of shared libraries, and the default ELF visibility
+rules allow one to overwrite any externally visible symbol with a
+different symbol at runtime.  This basically disables any optimizations
+across such functions and variables, because the compiler cannot be sure
+that the function body it is seeing is the same function body that will
+be used at runtime.  Any function or variable not declared 'static' in
+the sources degrades the quality of inter-procedural optimization.
+
+ To avoid this problem the compiler must assume that it sees the whole
+program when doing link-time optimization.  Strictly speaking, the whole
+program is rarely visible even at link-time.  Standard system libraries
+are usually linked dynamically or not provided with the link-time
+information.  In GCC, the whole program option ('-fwhole-program')
+asserts that every function and variable defined in the current
+compilation unit is static, except for function 'main' (note: at link
+time, the current unit is the union of all objects compiled with LTO).
+Since some functions and variables need to be referenced externally, for
+example by another DSO or from an assembler file, GCC also provides the
+function and variable attribute 'externally_visible' which can be used
+to disable the effect of '-fwhole-program' on a specific symbol.
+
+ The whole program mode assumptions are slightly more complex in C++,
+where inline functions in headers are put into _COMDAT_ sections.
+COMDAT function and variables can be defined by multiple object files
+and their bodies are unified at link-time and dynamic link-time.  COMDAT
+functions are changed to local only when their address is not taken and
+thus un-sharing them with a library is not harmful.  COMDAT variables
+always remain externally visible, however for readonly variables it is
+assumed that their initializers cannot be overwritten by a different
+value.
+
+ GCC provides the function and variable attribute 'visibility' that can
+be used to specify the visibility of externally visible symbols (or
+alternatively an '-fdefault-visibility' command line option).  ELF
+defines the 'default', 'protected', 'hidden' and 'internal'
+visibilities.
+
+ The most commonly used is visibility is 'hidden'.  It specifies that
+the symbol cannot be referenced from outside of the current shared
+library.  Unfortunately, this information cannot be used directly by the
+link-time optimization in the compiler since the whole shared library
+also might contain non-LTO objects and those are not visible to the
+compiler.
+
+ GCC solves this problem using linker plugins.  A _linker plugin_ is an
+interface to the linker that allows an external program to claim the
+ownership of a given object file.  The linker then performs the linking
+procedure by querying the plugin about the symbol table of the claimed
+objects and once the linking decisions are complete, the plugin is
+allowed to provide the final object file before the actual linking is
+made.  The linker plugin obtains the symbol resolution information which
+specifies which symbols provided by the claimed objects are bound from
+the rest of a binary being linked.
+
+ Currently, the linker plugin works only in combination with the Gold
+linker, but a GNU ld implementation is under development.
+
+ GCC is designed to be independent of the rest of the toolchain and aims
+to support linkers without plugin support.  For this reason it does not
+use the linker plugin by default.  Instead, the object files are
+examined by 'collect2' before being passed to the linker and objects
+found to have LTO sections are passed to 'lto1' first.  This mode does
+not work for library archives.  The decision on what object files from
+the archive are needed depends on the actual linking and thus GCC would
+have to implement the linker itself.  The resolution information is
+missing too and thus GCC needs to make an educated guess based on
+'-fwhole-program'.  Without the linker plugin GCC also assumes that
+symbols are declared 'hidden' and not referred by non-LTO code by
+default.
+
+
+File: gccint.info,  Node: Internal flags,  Prev: WHOPR,  Up: LTO
+
+24.5 Internal flags controlling 'lto1'
+======================================
+
+The following flags are passed into 'lto1' and are not meant to be used
+directly from the command line.
+
+   * -fwpa This option runs the serial part of the link-time optimizer
+     performing the inter-procedural propagation (WPA mode).  The
+     compiler reads in summary information from all inputs and performs
+     an analysis based on summary information only.  It generates object
+     files for subsequent runs of the link-time optimizer where
+     individual object files are optimized using both summary
+     information from the WPA mode and the actual function bodies.  It
+     then drives the LTRANS phase.
+
+   * -fltrans This option runs the link-time optimizer in the
+     local-transformation (LTRANS) mode, which reads in output from a
+     previous run of the LTO in WPA mode.  In the LTRANS mode, LTO
+     optimizes an object and produces the final assembly.
+
+   * -fltrans-output-list=FILE This option specifies a file to which the
+     names of LTRANS output files are written.  This option is only
+     meaningful in conjunction with '-fwpa'.
+
+   * -fresolution=FILE This option specifies the linker resolution file.
+     This option is only meaningful in conjunction with '-fwpa' and as
+     option to pass through to the LTO linker plugin.
+
+
+File: gccint.info,  Node: Funding,  Next: GNU Project,  Prev: LTO,  Up: Top
+
+Funding Free Software
+*********************
+
+If you want to have more free software a few years from now, it makes
+sense for you to help encourage people to contribute funds for its
+development.  The most effective approach known is to encourage
+commercial redistributors to donate.
+
+ Users of free software systems can boost the pace of development by
+encouraging for-a-fee distributors to donate part of their selling price
+to free software developers--the Free Software Foundation, and others.
+
+ The way to convince distributors to do this is to demand it and expect
+it from them.  So when you compare distributors, judge them partly by
+how much they give to free software development.  Show distributors they
+must compete to be the one who gives the most.
+
+ To make this approach work, you must insist on numbers that you can
+compare, such as, "We will donate ten dollars to the Frobnitz project
+for each disk sold."  Don't be satisfied with a vague promise, such as
+"A portion of the profits are donated," since it doesn't give a basis
+for comparison.
+
+ Even a precise fraction "of the profits from this disk" is not very
+meaningful, since creative accounting and unrelated business decisions
+can greatly alter what fraction of the sales price counts as profit.  If
+the price you pay is $50, ten percent of the profit is probably less
+than a dollar; it might be a few cents, or nothing at all.
+
+ Some redistributors do development work themselves.  This is useful
+too; but to keep everyone honest, you need to inquire how much they do,
+and what kind.  Some kinds of development make much more long-term
+difference than others.  For example, maintaining a separate version of
+a program contributes very little; maintaining the standard version of a
+program for the whole community contributes much.  Easy new ports
+contribute little, since someone else would surely do them; difficult
+ports such as adding a new CPU to the GNU Compiler Collection contribute
+more; major new features or packages contribute the most.
+
+ By establishing the idea that supporting further development is "the
+proper thing to do" when distributing free software for a fee, we can
+assure a steady flow of resources into making more free software.
+
+     Copyright (C) 1994 Free Software Foundation, Inc.
+     Verbatim copying and redistribution of this section is permitted
+     without royalty; alteration is not permitted.
+
+
+File: gccint.info,  Node: GNU Project,  Next: Copying,  Prev: Funding,  Up: Top
+
+The GNU Project and GNU/Linux
+*****************************
+
+The GNU Project was launched in 1984 to develop a complete Unix-like
+operating system which is free software: the GNU system.  (GNU is a
+recursive acronym for "GNU's Not Unix"; it is pronounced "guh-NEW".)
+Variants of the GNU operating system, which use the kernel Linux, are
+now widely used; though these systems are often referred to as "Linux",
+they are more accurately called GNU/Linux systems.
+
+ For more information, see:
+     <http://www.gnu.org/>
+     <http://www.gnu.org/gnu/linux-and-gnu.html>
+
+
+File: gccint.info,  Node: Copying,  Next: GNU Free Documentation License,  Prev: GNU Project,  Up: Top
+
+GNU General Public License
+**************************
+
+                        Version 3, 29 June 2007
+
+     Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+
+     Everyone is permitted to copy and distribute verbatim copies of this
+     license document, but changing it is not allowed.
+
+Preamble
+========
+
+The GNU General Public License is a free, copyleft license for software
+and other kinds of works.
+
+ The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program-to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+ When we speak of free software, we are referring to freedom, not price.
+Our General Public Licenses are designed to make sure that you have the
+freedom to distribute copies of free software (and charge for them if
+you wish), that you receive source code or can get it if you want it,
+that you can change the software or use pieces of it in new free
+programs, and that you know you can do these things.
+
+ To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+ For example, if you distribute copies of such a program, whether gratis
+or for a fee, you must pass on to the recipients the same freedoms that
+you received.  You must make sure that they, too, receive or can get the
+source code.  And you must show them these terms so they know their
+rights.
+
+ Developers that use the GNU GPL protect your rights with two steps: (1)
+assert copyright on the software, and (2) offer you this License giving
+you legal permission to copy, distribute and/or modify it.
+
+ For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+ Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+ Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+ The precise terms and conditions for copying, distribution and
+modification follow.
+
+TERMS AND CONDITIONS
+====================
+
+  0. Definitions.
+
+     "This License" refers to version 3 of the GNU General Public
+     License.
+
+     "Copyright" also means copyright-like laws that apply to other
+     kinds of works, such as semiconductor masks.
+
+     "The Program" refers to any copyrightable work licensed under this
+     License.  Each licensee is addressed as "you".  "Licensees" and
+     "recipients" may be individuals or organizations.
+
+     To "modify" a work means to copy from or adapt all or part of the
+     work in a fashion requiring copyright permission, other than the
+     making of an exact copy.  The resulting work is called a "modified
+     version" of the earlier work or a work "based on" the earlier work.
+
+     A "covered work" means either the unmodified Program or a work
+     based on the Program.
+
+     To "propagate" a work means to do anything with it that, without
+     permission, would make you directly or secondarily liable for
+     infringement under applicable copyright law, except executing it on
+     a computer or modifying a private copy.  Propagation includes
+     copying, distribution (with or without modification), making
+     available to the public, and in some countries other activities as
+     well.
+
+     To "convey" a work means any kind of propagation that enables other
+     parties to make or receive copies.  Mere interaction with a user
+     through a computer network, with no transfer of a copy, is not
+     conveying.
+
+     An interactive user interface displays "Appropriate Legal Notices"
+     to the extent that it includes a convenient and prominently visible
+     feature that (1) displays an appropriate copyright notice, and (2)
+     tells the user that there is no warranty for the work (except to
+     the extent that warranties are provided), that licensees may convey
+     the work under this License, and how to view a copy of this
+     License.  If the interface presents a list of user commands or
+     options, such as a menu, a prominent item in the list meets this
+     criterion.
+
+  1. Source Code.
+
+     The "source code" for a work means the preferred form of the work
+     for making modifications to it.  "Object code" means any non-source
+     form of a work.
+
+     A "Standard Interface" means an interface that either is an
+     official standard defined by a recognized standards body, or, in
+     the case of interfaces specified for a particular programming
+     language, one that is widely used among developers working in that
+     language.
+
+     The "System Libraries" of an executable work include anything,
+     other than the work as a whole, that (a) is included in the normal
+     form of packaging a Major Component, but which is not part of that
+     Major Component, and (b) serves only to enable use of the work with
+     that Major Component, or to implement a Standard Interface for
+     which an implementation is available to the public in source code
+     form.  A "Major Component", in this context, means a major
+     essential component (kernel, window system, and so on) of the
+     specific operating system (if any) on which the executable work
+     runs, or a compiler used to produce the work, or an object code
+     interpreter used to run it.
+
+     The "Corresponding Source" for a work in object code form means all
+     the source code needed to generate, install, and (for an executable
+     work) run the object code and to modify the work, including scripts
+     to control those activities.  However, it does not include the
+     work's System Libraries, or general-purpose tools or generally
+     available free programs which are used unmodified in performing
+     those activities but which are not part of the work.  For example,
+     Corresponding Source includes interface definition files associated
+     with source files for the work, and the source code for shared
+     libraries and dynamically linked subprograms that the work is
+     specifically designed to require, such as by intimate data
+     communication or control flow between those subprograms and other
+     parts of the work.
+
+     The Corresponding Source need not include anything that users can
+     regenerate automatically from other parts of the Corresponding
+     Source.
+
+     The Corresponding Source for a work in source code form is that
+     same work.
+
+  2. Basic Permissions.
+
+     All rights granted under this License are granted for the term of
+     copyright on the Program, and are irrevocable provided the stated
+     conditions are met.  This License explicitly affirms your unlimited
+     permission to run the unmodified Program.  The output from running
+     a covered work is covered by this License only if the output, given
+     its content, constitutes a covered work.  This License acknowledges
+     your rights of fair use or other equivalent, as provided by
+     copyright law.
+
+     You may make, run and propagate covered works that you do not
+     convey, without conditions so long as your license otherwise
+     remains in force.  You may convey covered works to others for the
+     sole purpose of having them make modifications exclusively for you,
+     or provide you with facilities for running those works, provided
+     that you comply with the terms of this License in conveying all
+     material for which you do not control copyright.  Those thus making
+     or running the covered works for you must do so exclusively on your
+     behalf, under your direction and control, on terms that prohibit
+     them from making any copies of your copyrighted material outside
+     their relationship with you.
+
+     Conveying under any other circumstances is permitted solely under
+     the conditions stated below.  Sublicensing is not allowed; section
+     10 makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+     No covered work shall be deemed part of an effective technological
+     measure under any applicable law fulfilling obligations under
+     article 11 of the WIPO copyright treaty adopted on 20 December
+     1996, or similar laws prohibiting or restricting circumvention of
+     such measures.
+
+     When you convey a covered work, you waive any legal power to forbid
+     circumvention of technological measures to the extent such
+     circumvention is effected by exercising rights under this License
+     with respect to the covered work, and you disclaim any intention to
+     limit operation or modification of the work as a means of
+     enforcing, against the work's users, your or third parties' legal
+     rights to forbid circumvention of technological measures.
+
+  4. Conveying Verbatim Copies.
+
+     You may convey verbatim copies of the Program's source code as you
+     receive it, in any medium, provided that you conspicuously and
+     appropriately publish on each copy an appropriate copyright notice;
+     keep intact all notices stating that this License and any
+     non-permissive terms added in accord with section 7 apply to the
+     code; keep intact all notices of the absence of any warranty; and
+     give all recipients a copy of this License along with the Program.
+
+     You may charge any price or no price for each copy that you convey,
+     and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+     You may convey a work based on the Program, or the modifications to
+     produce it from the Program, in the form of source code under the
+     terms of section 4, provided that you also meet all of these
+     conditions:
+
+       a. The work must carry prominent notices stating that you
+          modified it, and giving a relevant date.
+
+       b. The work must carry prominent notices stating that it is
+          released under this License and any conditions added under
+          section 7.  This requirement modifies the requirement in
+          section 4 to "keep intact all notices".
+
+       c. You must license the entire work, as a whole, under this
+          License to anyone who comes into possession of a copy.  This
+          License will therefore apply, along with any applicable
+          section 7 additional terms, to the whole of the work, and all
+          its parts, regardless of how they are packaged.  This License
+          gives no permission to license the work in any other way, but
+          it does not invalidate such permission if you have separately
+          received it.
+
+       d. If the work has interactive user interfaces, each must display
+          Appropriate Legal Notices; however, if the Program has
+          interactive interfaces that do not display Appropriate Legal
+          Notices, your work need not make them do so.
+
+     A compilation of a covered work with other separate and independent
+     works, which are not by their nature extensions of the covered
+     work, and which are not combined with it such as to form a larger
+     program, in or on a volume of a storage or distribution medium, is
+     called an "aggregate" if the compilation and its resulting
+     copyright are not used to limit the access or legal rights of the
+     compilation's users beyond what the individual works permit.
+     Inclusion of a covered work in an aggregate does not cause this
+     License to apply to the other parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+     You may convey a covered work in object code form under the terms
+     of sections 4 and 5, provided that you also convey the
+     machine-readable Corresponding Source under the terms of this
+     License, in one of these ways:
+
+       a. Convey the object code in, or embodied in, a physical product
+          (including a physical distribution medium), accompanied by the
+          Corresponding Source fixed on a durable physical medium
+          customarily used for software interchange.
+
+       b. Convey the object code in, or embodied in, a physical product
+          (including a physical distribution medium), accompanied by a
+          written offer, valid for at least three years and valid for as
+          long as you offer spare parts or customer support for that
+          product model, to give anyone who possesses the object code
+          either (1) a copy of the Corresponding Source for all the
+          software in the product that is covered by this License, on a
+          durable physical medium customarily used for software
+          interchange, for a price no more than your reasonable cost of
+          physically performing this conveying of source, or (2) access
+          to copy the Corresponding Source from a network server at no
+          charge.
+
+       c. Convey individual copies of the object code with a copy of the
+          written offer to provide the Corresponding Source.  This
+          alternative is allowed only occasionally and noncommercially,
+          and only if you received the object code with such an offer,
+          in accord with subsection 6b.
+
+       d. Convey the object code by offering access from a designated
+          place (gratis or for a charge), and offer equivalent access to
+          the Corresponding Source in the same way through the same
+          place at no further charge.  You need not require recipients
+          to copy the Corresponding Source along with the object code.
+          If the place to copy the object code is a network server, the
+          Corresponding Source may be on a different server (operated by
+          you or a third party) that supports equivalent copying
+          facilities, provided you maintain clear directions next to the
+          object code saying where to find the Corresponding Source.
+          Regardless of what server hosts the Corresponding Source, you
+          remain obligated to ensure that it is available for as long as
+          needed to satisfy these requirements.
+
+       e. Convey the object code using peer-to-peer transmission,
+          provided you inform other peers where the object code and
+          Corresponding Source of the work are being offered to the
+          general public at no charge under subsection 6d.
+
+     A separable portion of the object code, whose source code is
+     excluded from the Corresponding Source as a System Library, need
+     not be included in conveying the object code work.
+
+     A "User Product" is either (1) a "consumer product", which means
+     any tangible personal property which is normally used for personal,
+     family, or household purposes, or (2) anything designed or sold for
+     incorporation into a dwelling.  In determining whether a product is
+     a consumer product, doubtful cases shall be resolved in favor of
+     coverage.  For a particular product received by a particular user,
+     "normally used" refers to a typical or common use of that class of
+     product, regardless of the status of the particular user or of the
+     way in which the particular user actually uses, or expects or is
+     expected to use, the product.  A product is a consumer product
+     regardless of whether the product has substantial commercial,
+     industrial or non-consumer uses, unless such uses represent the
+     only significant mode of use of the product.
+
+     "Installation Information" for a User Product means any methods,
+     procedures, authorization keys, or other information required to
+     install and execute modified versions of a covered work in that
+     User Product from a modified version of its Corresponding Source.
+     The information must suffice to ensure that the continued
+     functioning of the modified object code is in no case prevented or
+     interfered with solely because modification has been made.
+
+     If you convey an object code work under this section in, or with,
+     or specifically for use in, a User Product, and the conveying
+     occurs as part of a transaction in which the right of possession
+     and use of the User Product is transferred to the recipient in
+     perpetuity or for a fixed term (regardless of how the transaction
+     is characterized), the Corresponding Source conveyed under this
+     section must be accompanied by the Installation Information.  But
+     this requirement does not apply if neither you nor any third party
+     retains the ability to install modified object code on the User
+     Product (for example, the work has been installed in ROM).
+
+     The requirement to provide Installation Information does not
+     include a requirement to continue to provide support service,
+     warranty, or updates for a work that has been modified or installed
+     by the recipient, or for the User Product in which it has been
+     modified or installed.  Access to a network may be denied when the
+     modification itself materially and adversely affects the operation
+     of the network or violates the rules and protocols for
+     communication across the network.
+
+     Corresponding Source conveyed, and Installation Information
+     provided, in accord with this section must be in a format that is
+     publicly documented (and with an implementation available to the
+     public in source code form), and must require no special password
+     or key for unpacking, reading or copying.
+
+  7. Additional Terms.
+
+     "Additional permissions" are terms that supplement the terms of
+     this License by making exceptions from one or more of its
+     conditions.  Additional permissions that are applicable to the
+     entire Program shall be treated as though they were included in
+     this License, to the extent that they are valid under applicable
+     law.  If additional permissions apply only to part of the Program,
+     that part may be used separately under those permissions, but the
+     entire Program remains governed by this License without regard to
+     the additional permissions.
+
+     When you convey a copy of a covered work, you may at your option
+     remove any additional permissions from that copy, or from any part
+     of it.  (Additional permissions may be written to require their own
+     removal in certain cases when you modify the work.)  You may place
+     additional permissions on material, added by you to a covered work,
+     for which you have or can give appropriate copyright permission.
+
+     Notwithstanding any other provision of this License, for material
+     you add to a covered work, you may (if authorized by the copyright
+     holders of that material) supplement the terms of this License with
+     terms:
+
+       a. Disclaiming warranty or limiting liability differently from
+          the terms of sections 15 and 16 of this License; or
+
+       b. Requiring preservation of specified reasonable legal notices
+          or author attributions in that material or in the Appropriate
+          Legal Notices displayed by works containing it; or
+
+       c. Prohibiting misrepresentation of the origin of that material,
+          or requiring that modified versions of such material be marked
+          in reasonable ways as different from the original version; or
+
+       d. Limiting the use for publicity purposes of names of licensors
+          or authors of the material; or
+
+       e. Declining to grant rights under trademark law for use of some
+          trade names, trademarks, or service marks; or
+
+       f. Requiring indemnification of licensors and authors of that
+          material by anyone who conveys the material (or modified
+          versions of it) with contractual assumptions of liability to
+          the recipient, for any liability that these contractual
+          assumptions directly impose on those licensors and authors.
+
+     All other non-permissive additional terms are considered "further
+     restrictions" within the meaning of section 10.  If the Program as
+     you received it, or any part of it, contains a notice stating that
+     it is governed by this License along with a term that is a further
+     restriction, you may remove that term.  If a license document
+     contains a further restriction but permits relicensing or conveying
+     under this License, you may add to a covered work material governed
+     by the terms of that license document, provided that the further
+     restriction does not survive such relicensing or conveying.
+
+     If you add terms to a covered work in accord with this section, you
+     must place, in the relevant source files, a statement of the
+     additional terms that apply to those files, or a notice indicating
+     where to find the applicable terms.
+
+     Additional terms, permissive or non-permissive, may be stated in
+     the form of a separately written license, or stated as exceptions;
+     the above requirements apply either way.
+
+  8. Termination.
+
+     You may not propagate or modify a covered work except as expressly
+     provided under this License.  Any attempt otherwise to propagate or
+     modify it is void, and will automatically terminate your rights
+     under this License (including any patent licenses granted under the
+     third paragraph of section 11).
+
+     However, if you cease all violation of this License, then your
+     license from a particular copyright holder is reinstated (a)
+     provisionally, unless and until the copyright holder explicitly and
+     finally terminates your license, and (b) permanently, if the
+     copyright holder fails to notify you of the violation by some
+     reasonable means prior to 60 days after the cessation.
+
+     Moreover, your license from a particular copyright holder is
+     reinstated permanently if the copyright holder notifies you of the
+     violation by some reasonable means, this is the first time you have
+     received notice of violation of this License (for any work) from
+     that copyright holder, and you cure the violation prior to 30 days
+     after your receipt of the notice.
+
+     Termination of your rights under this section does not terminate
+     the licenses of parties who have received copies or rights from you
+     under this License.  If your rights have been terminated and not
+     permanently reinstated, you do not qualify to receive new licenses
+     for the same material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+     You are not required to accept this License in order to receive or
+     run a copy of the Program.  Ancillary propagation of a covered work
+     occurring solely as a consequence of using peer-to-peer
+     transmission to receive a copy likewise does not require
+     acceptance.  However, nothing other than this License grants you
+     permission to propagate or modify any covered work.  These actions
+     infringe copyright if you do not accept this License.  Therefore,
+     by modifying or propagating a covered work, you indicate your
+     acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+     Each time you convey a covered work, the recipient automatically
+     receives a license from the original licensors, to run, modify and
+     propagate that work, subject to this License.  You are not
+     responsible for enforcing compliance by third parties with this
+     License.
+
+     An "entity transaction" is a transaction transferring control of an
+     organization, or substantially all assets of one, or subdividing an
+     organization, or merging organizations.  If propagation of a
+     covered work results from an entity transaction, each party to that
+     transaction who receives a copy of the work also receives whatever
+     licenses to the work the party's predecessor in interest had or
+     could give under the previous paragraph, plus a right to possession
+     of the Corresponding Source of the work from the predecessor in
+     interest, if the predecessor has it or can get it with reasonable
+     efforts.
+
+     You may not impose any further restrictions on the exercise of the
+     rights granted or affirmed under this License.  For example, you
+     may not impose a license fee, royalty, or other charge for exercise
+     of rights granted under this License, and you may not initiate
+     litigation (including a cross-claim or counterclaim in a lawsuit)
+     alleging that any patent claim is infringed by making, using,
+     selling, offering for sale, or importing the Program or any portion
+     of it.
+
+  11. Patents.
+
+     A "contributor" is a copyright holder who authorizes use under this
+     License of the Program or a work on which the Program is based.
+     The work thus licensed is called the contributor's "contributor
+     version".
+
+     A contributor's "essential patent claims" are all patent claims
+     owned or controlled by the contributor, whether already acquired or
+     hereafter acquired, that would be infringed by some manner,
+     permitted by this License, of making, using, or selling its
+     contributor version, but do not include claims that would be
+     infringed only as a consequence of further modification of the
+     contributor version.  For purposes of this definition, "control"
+     includes the right to grant patent sublicenses in a manner
+     consistent with the requirements of this License.
+
+     Each contributor grants you a non-exclusive, worldwide,
+     royalty-free patent license under the contributor's essential
+     patent claims, to make, use, sell, offer for sale, import and
+     otherwise run, modify and propagate the contents of its contributor
+     version.
+
+     In the following three paragraphs, a "patent license" is any
+     express agreement or commitment, however denominated, not to
+     enforce a patent (such as an express permission to practice a
+     patent or covenant not to sue for patent infringement).  To "grant"
+     such a patent license to a party means to make such an agreement or
+     commitment not to enforce a patent against the party.
+
+     If you convey a covered work, knowingly relying on a patent
+     license, and the Corresponding Source of the work is not available
+     for anyone to copy, free of charge and under the terms of this
+     License, through a publicly available network server or other
+     readily accessible means, then you must either (1) cause the
+     Corresponding Source to be so available, or (2) arrange to deprive
+     yourself of the benefit of the patent license for this particular
+     work, or (3) arrange, in a manner consistent with the requirements
+     of this License, to extend the patent license to downstream
+     recipients.  "Knowingly relying" means you have actual knowledge
+     that, but for the patent license, your conveying the covered work
+     in a country, or your recipient's use of the covered work in a
+     country, would infringe one or more identifiable patents in that
+     country that you have reason to believe are valid.
+
+     If, pursuant to or in connection with a single transaction or
+     arrangement, you convey, or propagate by procuring conveyance of, a
+     covered work, and grant a patent license to some of the parties
+     receiving the covered work authorizing them to use, propagate,
+     modify or convey a specific copy of the covered work, then the
+     patent license you grant is automatically extended to all
+     recipients of the covered work and works based on it.
+
+     A patent license is "discriminatory" if it does not include within
+     the scope of its coverage, prohibits the exercise of, or is
+     conditioned on the non-exercise of one or more of the rights that
+     are specifically granted under this License.  You may not convey a
+     covered work if you are a party to an arrangement with a third
+     party that is in the business of distributing software, under which
+     you make payment to the third party based on the extent of your
+     activity of conveying the work, and under which the third party
+     grants, to any of the parties who would receive the covered work
+     from you, a discriminatory patent license (a) in connection with
+     copies of the covered work conveyed by you (or copies made from
+     those copies), or (b) primarily for and in connection with specific
+     products or compilations that contain the covered work, unless you
+     entered into that arrangement, or that patent license was granted,
+     prior to 28 March 2007.
+
+     Nothing in this License shall be construed as excluding or limiting
+     any implied license or other defenses to infringement that may
+     otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+     If conditions are imposed on you (whether by court order, agreement
+     or otherwise) that contradict the conditions of this License, they
+     do not excuse you from the conditions of this License.  If you
+     cannot convey a covered work so as to satisfy simultaneously your
+     obligations under this License and any other pertinent obligations,
+     then as a consequence you may not convey it at all.  For example,
+     if you agree to terms that obligate you to collect a royalty for
+     further conveying from those to whom you convey the Program, the
+     only way you could satisfy both those terms and this License would
+     be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+     Notwithstanding any other provision of this License, you have
+     permission to link or combine any covered work with a work licensed
+     under version 3 of the GNU Affero General Public License into a
+     single combined work, and to convey the resulting work.  The terms
+     of this License will continue to apply to the part which is the
+     covered work, but the special requirements of the GNU Affero
+     General Public License, section 13, concerning interaction through
+     a network will apply to the combination as such.
+
+  14. Revised Versions of this License.
+
+     The Free Software Foundation may publish revised and/or new
+     versions of the GNU General Public License from time to time.  Such
+     new versions will be similar in spirit to the present version, but
+     may differ in detail to address new problems or concerns.
+
+     Each version is given a distinguishing version number.  If the
+     Program specifies that a certain numbered version of the GNU
+     General Public License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that numbered version or of any later version published by the Free
+     Software Foundation.  If the Program does not specify a version
+     number of the GNU General Public License, you may choose any
+     version ever published by the Free Software Foundation.
+
+     If the Program specifies that a proxy can decide which future
+     versions of the GNU General Public License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Program.
+
+     Later license versions may give you additional or different
+     permissions.  However, no additional obligations are imposed on any
+     author or copyright holder as a result of your choosing to follow a
+     later version.
+
+  15. Disclaimer of Warranty.
+
+     THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+     APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
+     COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
+     WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
+     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
+     RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
+     SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
+     NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+     IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+     WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
+     AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR
+     DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+     CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
+     THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
+     BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+     PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+     PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
+     THE POSSIBILITY OF SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+     If the disclaimer of warranty and limitation of liability provided
+     above cannot be given local legal effect according to their terms,
+     reviewing courts shall apply local law that most closely
+     approximates an absolute waiver of all civil liability in
+     connection with the Program, unless a warranty or assumption of
+     liability accompanies a copy of the Program in return for a fee.
+
+END OF TERMS AND CONDITIONS
+===========================
+
+How to Apply These Terms to Your New Programs
+=============================================
+
+If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+
+ To do so, attach the following notices to the program.  It is safest to
+attach them to the start of each source file to most effectively state
+the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+     ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
+     Copyright (C) YEAR NAME OF AUTHOR
+
+     This program is free software: you can redistribute it and/or modify
+     it under the terms of the GNU General Public License as published by
+     the Free Software Foundation, either version 3 of the License, or (at
+     your option) any later version.
+
+     This program is distributed in the hope that it will be useful, but
+     WITHOUT ANY WARRANTY; without even the implied warranty of
+     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+     General Public License for more details.
+
+     You should have received a copy of the GNU General Public License
+     along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+ Also add information on how to contact you by electronic and paper
+mail.
+
+ If the program does terminal interaction, make it output a short notice
+like this when it starts in an interactive mode:
+
+     PROGRAM Copyright (C) YEAR NAME OF AUTHOR
+     This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'.
+     This is free software, and you are welcome to redistribute it
+     under certain conditions; type 'show c' for details.
+
+ The hypothetical commands 'show w' and 'show c' should show the
+appropriate parts of the General Public License.  Of course, your
+program's commands might be different; for a GUI interface, you would
+use an "about box".
+
+ You should also get your employer (if you work as a programmer) or
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  For more information on this, and how to apply and follow
+the GNU GPL, see <http://www.gnu.org/licenses/>.
+
+ The GNU General Public License does not permit incorporating your
+program into proprietary programs.  If your program is a subroutine
+library, you may consider it more useful to permit linking proprietary
+applications with the library.  If this is what you want to do, use the
+GNU Lesser General Public License instead of this License.  But first,
+please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.
+
+
+File: gccint.info,  Node: GNU Free Documentation License,  Next: Contributors,  Prev: Copying,  Up: Top
+
+GNU Free Documentation License
+******************************
+
+                     Version 1.3, 3 November 2008
+
+     Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
+     <http://fsf.org/>
+
+     Everyone is permitted to copy and distribute verbatim copies
+     of this license document, but changing it is not allowed.
+
+  0. PREAMBLE
+
+     The purpose of this License is to make a manual, textbook, or other
+     functional and useful document "free" in the sense of freedom: to
+     assure everyone the effective freedom to copy and redistribute it,
+     with or without modifying it, either commercially or
+     noncommercially.  Secondarily, this License preserves for the
+     author and publisher a way to get credit for their work, while not
+     being considered responsible for modifications made by others.
+
+     This License is a kind of "copyleft", which means that derivative
+     works of the document must themselves be free in the same sense.
+     It complements the GNU General Public License, which is a copyleft
+     license designed for free software.
+
+     We have designed this License in order to use it for manuals for
+     free software, because free software needs free documentation: a
+     free program should come with manuals providing the same freedoms
+     that the software does.  But this License is not limited to
+     software manuals; it can be used for any textual work, regardless
+     of subject matter or whether it is published as a printed book.  We
+     recommend this License principally for works whose purpose is
+     instruction or reference.
+
+  1. APPLICABILITY AND DEFINITIONS
+
+     This License applies to any manual or other work, in any medium,
+     that contains a notice placed by the copyright holder saying it can
+     be distributed under the terms of this License.  Such a notice
+     grants a world-wide, royalty-free license, unlimited in duration,
+     to use that work under the conditions stated herein.  The
+     "Document", below, refers to any such manual or work.  Any member
+     of the public is a licensee, and is addressed as "you".  You accept
+     the license if you copy, modify or distribute the work in a way
+     requiring permission under copyright law.
+
+     A "Modified Version" of the Document means any work containing the
+     Document or a portion of it, either copied verbatim, or with
+     modifications and/or translated into another language.
+
+     A "Secondary Section" is a named appendix or a front-matter section
+     of the Document that deals exclusively with the relationship of the
+     publishers or authors of the Document to the Document's overall
+     subject (or to related matters) and contains nothing that could
+     fall directly within that overall subject.  (Thus, if the Document
+     is in part a textbook of mathematics, a Secondary Section may not
+     explain any mathematics.)  The relationship could be a matter of
+     historical connection with the subject or with related matters, or
+     of legal, commercial, philosophical, ethical or political position
+     regarding them.
+
+     The "Invariant Sections" are certain Secondary Sections whose
+     titles are designated, as being those of Invariant Sections, in the
+     notice that says that the Document is released under this License.
+     If a section does not fit the above definition of Secondary then it
+     is not allowed to be designated as Invariant.  The Document may
+     contain zero Invariant Sections.  If the Document does not identify
+     any Invariant Sections then there are none.
+
+     The "Cover Texts" are certain short passages of text that are
+     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
+     that says that the Document is released under this License.  A
+     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
+     be at most 25 words.
+
+     A "Transparent" copy of the Document means a machine-readable copy,
+     represented in a format whose specification is available to the
+     general public, that is suitable for revising the document
+     straightforwardly with generic text editors or (for images composed
+     of pixels) generic paint programs or (for drawings) some widely
+     available drawing editor, and that is suitable for input to text
+     formatters or for automatic translation to a variety of formats
+     suitable for input to text formatters.  A copy made in an otherwise
+     Transparent file format whose markup, or absence of markup, has
+     been arranged to thwart or discourage subsequent modification by
+     readers is not Transparent.  An image format is not Transparent if
+     used for any substantial amount of text.  A copy that is not
+     "Transparent" is called "Opaque".
+
+     Examples of suitable formats for Transparent copies include plain
+     ASCII without markup, Texinfo input format, LaTeX input format,
+     SGML or XML using a publicly available DTD, and standard-conforming
+     simple HTML, PostScript or PDF designed for human modification.
+     Examples of transparent image formats include PNG, XCF and JPG.
+     Opaque formats include proprietary formats that can be read and
+     edited only by proprietary word processors, SGML or XML for which
+     the DTD and/or processing tools are not generally available, and
+     the machine-generated HTML, PostScript or PDF produced by some word
+     processors for output purposes only.
+
+     The "Title Page" means, for a printed book, the title page itself,
+     plus such following pages as are needed to hold, legibly, the
+     material this License requires to appear in the title page.  For
+     works in formats which do not have any title page as such, "Title
+     Page" means the text near the most prominent appearance of the
+     work's title, preceding the beginning of the body of the text.
+
+     The "publisher" means any person or entity that distributes copies
+     of the Document to the public.
+
+     A section "Entitled XYZ" means a named subunit of the Document
+     whose title either is precisely XYZ or contains XYZ in parentheses
+     following text that translates XYZ in another language.  (Here XYZ
+     stands for a specific section name mentioned below, such as
+     "Acknowledgements", "Dedications", "Endorsements", or "History".)
+     To "Preserve the Title" of such a section when you modify the
+     Document means that it remains a section "Entitled XYZ" according
+     to this definition.
+
+     The Document may include Warranty Disclaimers next to the notice
+     which states that this License applies to the Document.  These
+     Warranty Disclaimers are considered to be included by reference in
+     this License, but only as regards disclaiming warranties: any other
+     implication that these Warranty Disclaimers may have is void and
+     has no effect on the meaning of this License.
+
+  2. VERBATIM COPYING
+
+     You may copy and distribute the Document in any medium, either
+     commercially or noncommercially, provided that this License, the
+     copyright notices, and the license notice saying this License
+     applies to the Document are reproduced in all copies, and that you
+     add no other conditions whatsoever to those of this License.  You
+     may not use technical measures to obstruct or control the reading
+     or further copying of the copies you make or distribute.  However,
+     you may accept compensation in exchange for copies.  If you
+     distribute a large enough number of copies you must also follow the
+     conditions in section 3.
+
+     You may also lend copies, under the same conditions stated above,
+     and you may publicly display copies.
+
+  3. COPYING IN QUANTITY
+
+     If you publish printed copies (or copies in media that commonly
+     have printed covers) of the Document, numbering more than 100, and
+     the Document's license notice requires Cover Texts, you must
+     enclose the copies in covers that carry, clearly and legibly, all
+     these Cover Texts: Front-Cover Texts on the front cover, and
+     Back-Cover Texts on the back cover.  Both covers must also clearly
+     and legibly identify you as the publisher of these copies.  The
+     front cover must present the full title with all words of the title
+     equally prominent and visible.  You may add other material on the
+     covers in addition.  Copying with changes limited to the covers, as
+     long as they preserve the title of the Document and satisfy these
+     conditions, can be treated as verbatim copying in other respects.
+
+     If the required texts for either cover are too voluminous to fit
+     legibly, you should put the first ones listed (as many as fit
+     reasonably) on the actual cover, and continue the rest onto
+     adjacent pages.
+
+     If you publish or distribute Opaque copies of the Document
+     numbering more than 100, you must either include a machine-readable
+     Transparent copy along with each Opaque copy, or state in or with
+     each Opaque copy a computer-network location from which the general
+     network-using public has access to download using public-standard
+     network protocols a complete Transparent copy of the Document, free
+     of added material.  If you use the latter option, you must take
+     reasonably prudent steps, when you begin distribution of Opaque
+     copies in quantity, to ensure that this Transparent copy will
+     remain thus accessible at the stated location until at least one
+     year after the last time you distribute an Opaque copy (directly or
+     through your agents or retailers) of that edition to the public.
+
+     It is requested, but not required, that you contact the authors of
+     the Document well before redistributing any large number of copies,
+     to give them a chance to provide you with an updated version of the
+     Document.
+
+  4. MODIFICATIONS
+
+     You may copy and distribute a Modified Version of the Document
+     under the conditions of sections 2 and 3 above, provided that you
+     release the Modified Version under precisely this License, with the
+     Modified Version filling the role of the Document, thus licensing
+     distribution and modification of the Modified Version to whoever
+     possesses a copy of it.  In addition, you must do these things in
+     the Modified Version:
+
+       A. Use in the Title Page (and on the covers, if any) a title
+          distinct from that of the Document, and from those of previous
+          versions (which should, if there were any, be listed in the
+          History section of the Document).  You may use the same title
+          as a previous version if the original publisher of that
+          version gives permission.
+
+       B. List on the Title Page, as authors, one or more persons or
+          entities responsible for authorship of the modifications in
+          the Modified Version, together with at least five of the
+          principal authors of the Document (all of its principal
+          authors, if it has fewer than five), unless they release you
+          from this requirement.
+
+       C. State on the Title page the name of the publisher of the
+          Modified Version, as the publisher.
+
+       D. Preserve all the copyright notices of the Document.
+
+       E. Add an appropriate copyright notice for your modifications
+          adjacent to the other copyright notices.
+
+       F. Include, immediately after the copyright notices, a license
+          notice giving the public permission to use the Modified
+          Version under the terms of this License, in the form shown in
+          the Addendum below.
+
+       G. Preserve in that license notice the full lists of Invariant
+          Sections and required Cover Texts given in the Document's
+          license notice.
+
+       H. Include an unaltered copy of this License.
+
+       I. Preserve the section Entitled "History", Preserve its Title,
+          and add to it an item stating at least the title, year, new
+          authors, and publisher of the Modified Version as given on the
+          Title Page.  If there is no section Entitled "History" in the
+          Document, create one stating the title, year, authors, and
+          publisher of the Document as given on its Title Page, then add
+          an item describing the Modified Version as stated in the
+          previous sentence.
+
+       J. Preserve the network location, if any, given in the Document
+          for public access to a Transparent copy of the Document, and
+          likewise the network locations given in the Document for
+          previous versions it was based on.  These may be placed in the
+          "History" section.  You may omit a network location for a work
+          that was published at least four years before the Document
+          itself, or if the original publisher of the version it refers
+          to gives permission.
+
+       K. For any section Entitled "Acknowledgements" or "Dedications",
+          Preserve the Title of the section, and preserve in the section
+          all the substance and tone of each of the contributor
+          acknowledgements and/or dedications given therein.
+
+       L. Preserve all the Invariant Sections of the Document, unaltered
+          in their text and in their titles.  Section numbers or the
+          equivalent are not considered part of the section titles.
+
+       M. Delete any section Entitled "Endorsements".  Such a section
+          may not be included in the Modified Version.
+
+       N. Do not retitle any existing section to be Entitled
+          "Endorsements" or to conflict in title with any Invariant
+          Section.
+
+       O. Preserve any Warranty Disclaimers.
+
+     If the Modified Version includes new front-matter sections or
+     appendices that qualify as Secondary Sections and contain no
+     material copied from the Document, you may at your option designate
+     some or all of these sections as invariant.  To do this, add their
+     titles to the list of Invariant Sections in the Modified Version's
+     license notice.  These titles must be distinct from any other
+     section titles.
+
+     You may add a section Entitled "Endorsements", provided it contains
+     nothing but endorsements of your Modified Version by various
+     parties--for example, statements of peer review or that the text
+     has been approved by an organization as the authoritative
+     definition of a standard.
+
+     You may add a passage of up to five words as a Front-Cover Text,
+     and a passage of up to 25 words as a Back-Cover Text, to the end of
+     the list of Cover Texts in the Modified Version.  Only one passage
+     of Front-Cover Text and one of Back-Cover Text may be added by (or
+     through arrangements made by) any one entity.  If the Document
+     already includes a cover text for the same cover, previously added
+     by you or by arrangement made by the same entity you are acting on
+     behalf of, you may not add another; but you may replace the old
+     one, on explicit permission from the previous publisher that added
+     the old one.
+
+     The author(s) and publisher(s) of the Document do not by this
+     License give permission to use their names for publicity for or to
+     assert or imply endorsement of any Modified Version.
+
+  5. COMBINING DOCUMENTS
+
+     You may combine the Document with other documents released under
+     this License, under the terms defined in section 4 above for
+     modified versions, provided that you include in the combination all
+     of the Invariant Sections of all of the original documents,
+     unmodified, and list them all as Invariant Sections of your
+     combined work in its license notice, and that you preserve all
+     their Warranty Disclaimers.
+
+     The combined work need only contain one copy of this License, and
+     multiple identical Invariant Sections may be replaced with a single
+     copy.  If there are multiple Invariant Sections with the same name
+     but different contents, make the title of each such section unique
+     by adding at the end of it, in parentheses, the name of the
+     original author or publisher of that section if known, or else a
+     unique number.  Make the same adjustment to the section titles in
+     the list of Invariant Sections in the license notice of the
+     combined work.
+
+     In the combination, you must combine any sections Entitled
+     "History" in the various original documents, forming one section
+     Entitled "History"; likewise combine any sections Entitled
+     "Acknowledgements", and any sections Entitled "Dedications".  You
+     must delete all sections Entitled "Endorsements."
+
+  6. COLLECTIONS OF DOCUMENTS
+
+     You may make a collection consisting of the Document and other
+     documents released under this License, and replace the individual
+     copies of this License in the various documents with a single copy
+     that is included in the collection, provided that you follow the
+     rules of this License for verbatim copying of each of the documents
+     in all other respects.
+
+     You may extract a single document from such a collection, and
+     distribute it individually under this License, provided you insert
+     a copy of this License into the extracted document, and follow this
+     License in all other respects regarding verbatim copying of that
+     document.
+
+  7. AGGREGATION WITH INDEPENDENT WORKS
+
+     A compilation of the Document or its derivatives with other
+     separate and independent documents or works, in or on a volume of a
+     storage or distribution medium, is called an "aggregate" if the
+     copyright resulting from the compilation is not used to limit the
+     legal rights of the compilation's users beyond what the individual
+     works permit.  When the Document is included in an aggregate, this
+     License does not apply to the other works in the aggregate which
+     are not themselves derivative works of the Document.
+
+     If the Cover Text requirement of section 3 is applicable to these
+     copies of the Document, then if the Document is less than one half
+     of the entire aggregate, the Document's Cover Texts may be placed
+     on covers that bracket the Document within the aggregate, or the
+     electronic equivalent of covers if the Document is in electronic
+     form.  Otherwise they must appear on printed covers that bracket
+     the whole aggregate.
+
+  8. TRANSLATION
+
+     Translation is considered a kind of modification, so you may
+     distribute translations of the Document under the terms of section
+     4.  Replacing Invariant Sections with translations requires special
+     permission from their copyright holders, but you may include
+     translations of some or all Invariant Sections in addition to the
+     original versions of these Invariant Sections.  You may include a
+     translation of this License, and all the license notices in the
+     Document, and any Warranty Disclaimers, provided that you also
+     include the original English version of this License and the
+     original versions of those notices and disclaimers.  In case of a
+     disagreement between the translation and the original version of
+     this License or a notice or disclaimer, the original version will
+     prevail.
+
+     If a section in the Document is Entitled "Acknowledgements",
+     "Dedications", or "History", the requirement (section 4) to
+     Preserve its Title (section 1) will typically require changing the
+     actual title.
+
+  9. TERMINATION
+
+     You may not copy, modify, sublicense, or distribute the Document
+     except as expressly provided under this License.  Any attempt
+     otherwise to copy, modify, sublicense, or distribute it is void,
+     and will automatically terminate your rights under this License.
+
+     However, if you cease all violation of this License, then your
+     license from a particular copyright holder is reinstated (a)
+     provisionally, unless and until the copyright holder explicitly and
+     finally terminates your license, and (b) permanently, if the
+     copyright holder fails to notify you of the violation by some
+     reasonable means prior to 60 days after the cessation.
+
+     Moreover, your license from a particular copyright holder is
+     reinstated permanently if the copyright holder notifies you of the
+     violation by some reasonable means, this is the first time you have
+     received notice of violation of this License (for any work) from
+     that copyright holder, and you cure the violation prior to 30 days
+     after your receipt of the notice.
+
+     Termination of your rights under this section does not terminate
+     the licenses of parties who have received copies or rights from you
+     under this License.  If your rights have been terminated and not
+     permanently reinstated, receipt of a copy of some or all of the
+     same material does not give you any rights to use it.
+
+  10. FUTURE REVISIONS OF THIS LICENSE
+
+     The Free Software Foundation may publish new, revised versions of
+     the GNU Free Documentation License from time to time.  Such new
+     versions will be similar in spirit to the present version, but may
+     differ in detail to address new problems or concerns.  See
+     <http://www.gnu.org/copyleft/>.
+
+     Each version of the License is given a distinguishing version
+     number.  If the Document specifies that a particular numbered
+     version of this License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that specified version or of any later version that has been
+     published (not as a draft) by the Free Software Foundation.  If the
+     Document does not specify a version number of this License, you may
+     choose any version ever published (not as a draft) by the Free
+     Software Foundation.  If the Document specifies that a proxy can
+     decide which future versions of this License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Document.
+
+  11. RELICENSING
+
+     "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
+     World Wide Web server that publishes copyrightable works and also
+     provides prominent facilities for anybody to edit those works.  A
+     public wiki that anybody can edit is an example of such a server.
+     A "Massive Multiauthor Collaboration" (or "MMC") contained in the
+     site means any set of copyrightable works thus published on the MMC
+     site.
+
+     "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
+     license published by Creative Commons Corporation, a not-for-profit
+     corporation with a principal place of business in San Francisco,
+     California, as well as future copyleft versions of that license
+     published by that same organization.
+
+     "Incorporate" means to publish or republish a Document, in whole or
+     in part, as part of another Document.
+
+     An MMC is "eligible for relicensing" if it is licensed under this
+     License, and if all works that were first published under this
+     License somewhere other than this MMC, and subsequently
+     incorporated in whole or in part into the MMC, (1) had no cover
+     texts or invariant sections, and (2) were thus incorporated prior
+     to November 1, 2008.
+
+     The operator of an MMC Site may republish an MMC contained in the
+     site under CC-BY-SA on the same site at any time before August 1,
+     2009, provided the MMC is eligible for relicensing.
+
+ADDENDUM: How to use this License for your documents
+====================================================
+
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and license
+notices just after the title page:
+
+       Copyright (C)  YEAR  YOUR NAME.
+       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, no Front-Cover Texts, and no Back-Cover
+       Texts.  A copy of the license is included in the section entitled ``GNU
+       Free Documentation License''.
+
+ If you have Invariant Sections, Front-Cover Texts and Back-Cover Texts,
+replace the "with...Texts."  line with this:
+
+         with the Invariant Sections being LIST THEIR TITLES, with
+         the Front-Cover Texts being LIST, and with the Back-Cover Texts
+         being LIST.
+
+ If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+
+ If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of free
+software license, such as the GNU General Public License, to permit
+their use in free software.
+
+
+File: gccint.info,  Node: Contributors,  Next: Option Index,  Prev: GNU Free Documentation License,  Up: Top
+
+Contributors to GCC
+*******************
+
+The GCC project would like to thank its many contributors.  Without them
+the project would not have been nearly as successful as it has been.
+Any omissions in this list are accidental.  Feel free to contact
+<law@redhat.com> or <gerald@pfeifer.com> if you have been left out or
+some of your contributions are not listed.  Please keep this list in
+alphabetical order.
+
+   * Analog Devices helped implement the support for complex data types
+     and iterators.
+
+   * John David Anglin for threading-related fixes and improvements to
+     libstdc++-v3, and the HP-UX port.
+
+   * James van Artsdalen wrote the code that makes efficient use of the
+     Intel 80387 register stack.
+
+   * Abramo and Roberto Bagnara for the SysV68 Motorola 3300 Delta
+     Series port.
+
+   * Alasdair Baird for various bug fixes.
+
+   * Giovanni Bajo for analyzing lots of complicated C++ problem
+     reports.
+
+   * Peter Barada for his work to improve code generation for new
+     ColdFire cores.
+
+   * Gerald Baumgartner added the signature extension to the C++ front
+     end.
+
+   * Godmar Back for his Java improvements and encouragement.
+
+   * Scott Bambrough for help porting the Java compiler.
+
+   * Wolfgang Bangerth for processing tons of bug reports.
+
+   * Jon Beniston for his Microsoft Windows port of Java and port to
+     Lattice Mico32.
+
+   * Daniel Berlin for better DWARF2 support, faster/better
+     optimizations, improved alias analysis, plus migrating GCC to
+     Bugzilla.
+
+   * Geoff Berry for his Java object serialization work and various
+     patches.
+
+   * David Binderman tests weekly snapshots of GCC trunk against Fedora
+     Rawhide for several architectures.
+
+   * Uros Bizjak for the implementation of x87 math built-in functions
+     and for various middle end and i386 back end improvements and bug
+     fixes.
+
+   * Eric Blake for helping to make GCJ and libgcj conform to the
+     specifications.
+
+   * Janne Blomqvist for contributions to GNU Fortran.
+
+   * Segher Boessenkool for various fixes.
+
+   * Hans-J. Boehm for his garbage collector, IA-64 libffi port, and
+     other Java work.
+
+   * Neil Booth for work on cpplib, lang hooks, debug hooks and other
+     miscellaneous clean-ups.
+
+   * Steven Bosscher for integrating the GNU Fortran front end into GCC
+     and for contributing to the tree-ssa branch.
+
+   * Eric Botcazou for fixing middle- and backend bugs left and right.
+
+   * Per Bothner for his direction via the steering committee and
+     various improvements to the infrastructure for supporting new
+     languages.  Chill front end implementation.  Initial
+     implementations of cpplib, fix-header, config.guess, libio, and
+     past C++ library (libg++) maintainer.  Dreaming up, designing and
+     implementing much of GCJ.
+
+   * Devon Bowen helped port GCC to the Tahoe.
+
+   * Don Bowman for mips-vxworks contributions.
+
+   * Dave Brolley for work on cpplib and Chill.
+
+   * Paul Brook for work on the ARM architecture and maintaining GNU
+     Fortran.
+
+   * Robert Brown implemented the support for Encore 32000 systems.
+
+   * Christian Bruel for improvements to local store elimination.
+
+   * Herman A.J. ten Brugge for various fixes.
+
+   * Joerg Brunsmann for Java compiler hacking and help with the GCJ
+     FAQ.
+
+   * Joe Buck for his direction via the steering committee.
+
+   * Craig Burley for leadership of the G77 Fortran effort.
+
+   * Stephan Buys for contributing Doxygen notes for libstdc++.
+
+   * Paolo Carlini for libstdc++ work: lots of efficiency improvements
+     to the C++ strings, streambufs and formatted I/O, hard detective
+     work on the frustrating localization issues, and keeping up with
+     the problem reports.
+
+   * John Carr for his alias work, SPARC hacking, infrastructure
+     improvements, previous contributions to the steering committee,
+     loop optimizations, etc.
+
+   * Stephane Carrez for 68HC11 and 68HC12 ports.
+
+   * Steve Chamberlain for support for the Renesas SH and H8 processors
+     and the PicoJava processor, and for GCJ config fixes.
+
+   * Glenn Chambers for help with the GCJ FAQ.
+
+   * John-Marc Chandonia for various libgcj patches.
+
+   * Denis Chertykov for contributing and maintaining the AVR port, the
+     first GCC port for an 8-bit architecture.
+
+   * Scott Christley for his Objective-C contributions.
+
+   * Eric Christopher for his Java porting help and clean-ups.
+
+   * Branko Cibej for more warning contributions.
+
+   * The GNU Classpath project for all of their merged runtime code.
+
+   * Nick Clifton for arm, mcore, fr30, v850, m32r, msp430 rx work,
+     '--help', and other random hacking.
+
+   * Michael Cook for libstdc++ cleanup patches to reduce warnings.
+
+   * R. Kelley Cook for making GCC buildable from a read-only directory
+     as well as other miscellaneous build process and documentation
+     clean-ups.
+
+   * Ralf Corsepius for SH testing and minor bug fixing.
+
+   * Stan Cox for care and feeding of the x86 port and lots of behind
+     the scenes hacking.
+
+   * Alex Crain provided changes for the 3b1.
+
+   * Ian Dall for major improvements to the NS32k port.
+
+   * Paul Dale for his work to add uClinux platform support to the m68k
+     backend.
+
+   * Dario Dariol contributed the four varieties of sample programs that
+     print a copy of their source.
+
+   * Russell Davidson for fstream and stringstream fixes in libstdc++.
+
+   * Bud Davis for work on the G77 and GNU Fortran compilers.
+
+   * Mo DeJong for GCJ and libgcj bug fixes.
+
+   * DJ Delorie for the DJGPP port, build and libiberty maintenance,
+     various bug fixes, and the M32C, MeP, MSP430, and RL78 ports.
+
+   * Arnaud Desitter for helping to debug GNU Fortran.
+
+   * Gabriel Dos Reis for contributions to G++, contributions and
+     maintenance of GCC diagnostics infrastructure, libstdc++-v3,
+     including 'valarray<>', 'complex<>', maintaining the numerics
+     library (including that pesky '<limits>' :-) and keeping up-to-date
+     anything to do with numbers.
+
+   * Ulrich Drepper for his work on glibc, testing of GCC using glibc,
+     ISO C99 support, CFG dumping support, etc., plus support of the C++
+     runtime libraries including for all kinds of C interface issues,
+     contributing and maintaining 'complex<>', sanity checking and
+     disbursement, configuration architecture, libio maintenance, and
+     early math work.
+
+   * Franc,ois Dumont for his work on libstdc++-v3, especially
+     maintaining and improving 'debug-mode' and associative and
+     unordered containers.
+
+   * Zdenek Dvorak for a new loop unroller and various fixes.
+
+   * Michael Eager for his work on the Xilinx MicroBlaze port.
+
+   * Richard Earnshaw for his ongoing work with the ARM.
+
+   * David Edelsohn for his direction via the steering committee,
+     ongoing work with the RS6000/PowerPC port, help cleaning up Haifa
+     loop changes, doing the entire AIX port of libstdc++ with his bare
+     hands, and for ensuring GCC properly keeps working on AIX.
+
+   * Kevin Ediger for the floating point formatting of num_put::do_put
+     in libstdc++.
+
+   * Phil Edwards for libstdc++ work including configuration hackery,
+     documentation maintainer, chief breaker of the web pages, the
+     occasional iostream bug fix, and work on shared library symbol
+     versioning.
+
+   * Paul Eggert for random hacking all over GCC.
+
+   * Mark Elbrecht for various DJGPP improvements, and for libstdc++
+     configuration support for locales and fstream-related fixes.
+
+   * Vadim Egorov for libstdc++ fixes in strings, streambufs, and
+     iostreams.
+
+   * Christian Ehrhardt for dealing with bug reports.
+
+   * Ben Elliston for his work to move the Objective-C runtime into its
+     own subdirectory and for his work on autoconf.
+
+   * Revital Eres for work on the PowerPC 750CL port.
+
+   * Marc Espie for OpenBSD support.
+
+   * Doug Evans for much of the global optimization framework, arc,
+     m32r, and SPARC work.
+
+   * Christopher Faylor for his work on the Cygwin port and for caring
+     and feeding the gcc.gnu.org box and saving its users tons of spam.
+
+   * Fred Fish for BeOS support and Ada fixes.
+
+   * Ivan Fontes Garcia for the Portuguese translation of the GCJ FAQ.
+
+   * Peter Gerwinski for various bug fixes and the Pascal front end.
+
+   * Kaveh R. Ghazi for his direction via the steering committee,
+     amazing work to make '-W -Wall -W* -Werror' useful, and testing GCC
+     on a plethora of platforms.  Kaveh extends his gratitude to the
+     CAIP Center at Rutgers University for providing him with computing
+     resources to work on Free Software from the late 1980s to 2010.
+
+   * John Gilmore for a donation to the FSF earmarked improving GNU
+     Java.
+
+   * Judy Goldberg for c++ contributions.
+
+   * Torbjorn Granlund for various fixes and the c-torture testsuite,
+     multiply- and divide-by-constant optimization, improved long long
+     support, improved leaf function register allocation, and his
+     direction via the steering committee.
+
+   * Anthony Green for his '-Os' contributions, the moxie port, and Java
+     front end work.
+
+   * Stu Grossman for gdb hacking, allowing GCJ developers to debug Java
+     code.
+
+   * Michael K. Gschwind contributed the port to the PDP-11.
+
+   * Richard Biener for his ongoing middle-end contributions and bug
+     fixes and for release management.
+
+   * Ron Guilmette implemented the 'protoize' and 'unprotoize' tools,
+     the support for Dwarf symbolic debugging information, and much of
+     the support for System V Release 4.  He has also worked heavily on
+     the Intel 386 and 860 support.
+
+   * Sumanth Gundapaneni for contributing the CR16 port.
+
+   * Mostafa Hagog for Swing Modulo Scheduling (SMS) and post reload
+     GCSE.
+
+   * Bruno Haible for improvements in the runtime overhead for EH, new
+     warnings and assorted bug fixes.
+
+   * Andrew Haley for his amazing Java compiler and library efforts.
+
+   * Chris Hanson assisted in making GCC work on HP-UX for the 9000
+     series 300.
+
+   * Michael Hayes for various thankless work he's done trying to get
+     the c30/c40 ports functional.  Lots of loop and unroll improvements
+     and fixes.
+
+   * Dara Hazeghi for wading through myriads of target-specific bug
+     reports.
+
+   * Kate Hedstrom for staking the G77 folks with an initial testsuite.
+
+   * Richard Henderson for his ongoing SPARC, alpha, ia32, and ia64
+     work, loop opts, and generally fixing lots of old problems we've
+     ignored for years, flow rewrite and lots of further stuff,
+     including reviewing tons of patches.
+
+   * Aldy Hernandez for working on the PowerPC port, SIMD support, and
+     various fixes.
+
+   * Nobuyuki Hikichi of Software Research Associates, Tokyo,
+     contributed the support for the Sony NEWS machine.
+
+   * Kazu Hirata for caring and feeding the Renesas H8/300 port and
+     various fixes.
+
+   * Katherine Holcomb for work on GNU Fortran.
+
+   * Manfred Hollstein for his ongoing work to keep the m88k alive, lots
+     of testing and bug fixing, particularly of GCC configury code.
+
+   * Steve Holmgren for MachTen patches.
+
+   * Mat Hostetter for work on the TILE-Gx and TILEPro ports.
+
+   * Jan Hubicka for his x86 port improvements.
+
+   * Falk Hueffner for working on C and optimization bug reports.
+
+   * Bernardo Innocenti for his m68k work, including merging of ColdFire
+     improvements and uClinux support.
+
+   * Christian Iseli for various bug fixes.
+
+   * Kamil Iskra for general m68k hacking.
+
+   * Lee Iverson for random fixes and MIPS testing.
+
+   * Andreas Jaeger for testing and benchmarking of GCC and various bug
+     fixes.
+
+   * Jakub Jelinek for his SPARC work and sibling call optimizations as
+     well as lots of bug fixes and test cases, and for improving the
+     Java build system.
+
+   * Janis Johnson for ia64 testing and fixes, her quality improvement
+     sidetracks, and web page maintenance.
+
+   * Kean Johnston for SCO OpenServer support and various fixes.
+
+   * Tim Josling for the sample language treelang based originally on
+     Richard Kenner's "toy" language.
+
+   * Nicolai Josuttis for additional libstdc++ documentation.
+
+   * Klaus Kaempf for his ongoing work to make alpha-vms a viable
+     target.
+
+   * Steven G. Kargl for work on GNU Fortran.
+
+   * David Kashtan of SRI adapted GCC to VMS.
+
+   * Ryszard Kabatek for many, many libstdc++ bug fixes and
+     optimizations of strings, especially member functions, and for
+     auto_ptr fixes.
+
+   * Geoffrey Keating for his ongoing work to make the PPC work for
+     GNU/Linux and his automatic regression tester.
+
+   * Brendan Kehoe for his ongoing work with G++ and for a lot of early
+     work in just about every part of libstdc++.
+
+   * Oliver M. Kellogg of Deutsche Aerospace contributed the port to the
+     MIL-STD-1750A.
+
+   * Richard Kenner of the New York University Ultracomputer Research
+     Laboratory wrote the machine descriptions for the AMD 29000, the
+     DEC Alpha, the IBM RT PC, and the IBM RS/6000 as well as the
+     support for instruction attributes.  He also made changes to better
+     support RISC processors including changes to common subexpression
+     elimination, strength reduction, function calling sequence
+     handling, and condition code support, in addition to generalizing
+     the code for frame pointer elimination and delay slot scheduling.
+     Richard Kenner was also the head maintainer of GCC for several
+     years.
+
+   * Mumit Khan for various contributions to the Cygwin and Mingw32
+     ports and maintaining binary releases for Microsoft Windows hosts,
+     and for massive libstdc++ porting work to Cygwin/Mingw32.
+
+   * Robin Kirkham for cpu32 support.
+
+   * Mark Klein for PA improvements.
+
+   * Thomas Koenig for various bug fixes.
+
+   * Bruce Korb for the new and improved fixincludes code.
+
+   * Benjamin Kosnik for his G++ work and for leading the libstdc++-v3
+     effort.
+
+   * Charles LaBrec contributed the support for the Integrated Solutions
+     68020 system.
+
+   * Asher Langton and Mike Kumbera for contributing Cray pointer
+     support to GNU Fortran, and for other GNU Fortran improvements.
+
+   * Jeff Law for his direction via the steering committee, coordinating
+     the entire egcs project and GCC 2.95, rolling out snapshots and
+     releases, handling merges from GCC2, reviewing tons of patches that
+     might have fallen through the cracks else, and random but extensive
+     hacking.
+
+   * Walter Lee for work on the TILE-Gx and TILEPro ports.
+
+   * Marc Lehmann for his direction via the steering committee and
+     helping with analysis and improvements of x86 performance.
+
+   * Victor Leikehman for work on GNU Fortran.
+
+   * Ted Lemon wrote parts of the RTL reader and printer.
+
+   * Kriang Lerdsuwanakij for C++ improvements including template as
+     template parameter support, and many C++ fixes.
+
+   * Warren Levy for tremendous work on libgcj (Java Runtime Library)
+     and random work on the Java front end.
+
+   * Alain Lichnewsky ported GCC to the MIPS CPU.
+
+   * Oskar Liljeblad for hacking on AWT and his many Java bug reports
+     and patches.
+
+   * Robert Lipe for OpenServer support, new testsuites, testing, etc.
+
+   * Chen Liqin for various S+core related fixes/improvement, and for
+     maintaining the S+core port.
+
+   * Weiwen Liu for testing and various bug fixes.
+
+   * Manuel Lo'pez-Iba'n~ez for improving '-Wconversion' and many other
+     diagnostics fixes and improvements.
+
+   * Dave Love for his ongoing work with the Fortran front end and
+     runtime libraries.
+
+   * Martin von Lo"wis for internal consistency checking infrastructure,
+     various C++ improvements including namespace support, and tons of
+     assistance with libstdc++/compiler merges.
+
+   * H.J. Lu for his previous contributions to the steering committee,
+     many x86 bug reports, prototype patches, and keeping the GNU/Linux
+     ports working.
+
+   * Greg McGary for random fixes and (someday) bounded pointers.
+
+   * Andrew MacLeod for his ongoing work in building a real EH system,
+     various code generation improvements, work on the global optimizer,
+     etc.
+
+   * Vladimir Makarov for hacking some ugly i960 problems, PowerPC
+     hacking improvements to compile-time performance, overall knowledge
+     and direction in the area of instruction scheduling, and design and
+     implementation of the automaton based instruction scheduler.
+
+   * Bob Manson for his behind the scenes work on dejagnu.
+
+   * Philip Martin for lots of libstdc++ string and vector iterator
+     fixes and improvements, and string clean up and testsuites.
+
+   * All of the Mauve project contributors, for Java test code.
+
+   * Bryce McKinlay for numerous GCJ and libgcj fixes and improvements.
+
+   * Adam Megacz for his work on the Microsoft Windows port of GCJ.
+
+   * Michael Meissner for LRS framework, ia32, m32r, v850, m88k, MIPS,
+     powerpc, haifa, ECOFF debug support, and other assorted hacking.
+
+   * Jason Merrill for his direction via the steering committee and
+     leading the G++ effort.
+
+   * Martin Michlmayr for testing GCC on several architectures using the
+     entire Debian archive.
+
+   * David Miller for his direction via the steering committee, lots of
+     SPARC work, improvements in jump.c and interfacing with the Linux
+     kernel developers.
+
+   * Gary Miller ported GCC to Charles River Data Systems machines.
+
+   * Alfred Minarik for libstdc++ string and ios bug fixes, and turning
+     the entire libstdc++ testsuite namespace-compatible.
+
+   * Mark Mitchell for his direction via the steering committee,
+     mountains of C++ work, load/store hoisting out of loops, alias
+     analysis improvements, ISO C 'restrict' support, and serving as
+     release manager from 2000 to 2011.
+
+   * Alan Modra for various GNU/Linux bits and testing.
+
+   * Toon Moene for his direction via the steering committee, Fortran
+     maintenance, and his ongoing work to make us make Fortran run fast.
+
+   * Jason Molenda for major help in the care and feeding of all the
+     services on the gcc.gnu.org (formerly egcs.cygnus.com)
+     machine--mail, web services, ftp services, etc etc.  Doing all this
+     work on scrap paper and the backs of envelopes would have been...
+     difficult.
+
+   * Catherine Moore for fixing various ugly problems we have sent her
+     way, including the haifa bug which was killing the Alpha & PowerPC
+     Linux kernels.
+
+   * Mike Moreton for his various Java patches.
+
+   * David Mosberger-Tang for various Alpha improvements, and for the
+     initial IA-64 port.
+
+   * Stephen Moshier contributed the floating point emulator that
+     assists in cross-compilation and permits support for floating point
+     numbers wider than 64 bits and for ISO C99 support.
+
+   * Bill Moyer for his behind the scenes work on various issues.
+
+   * Philippe De Muyter for his work on the m68k port.
+
+   * Joseph S. Myers for his work on the PDP-11 port, format checking
+     and ISO C99 support, and continuous emphasis on (and contributions
+     to) documentation.
+
+   * Nathan Myers for his work on libstdc++-v3: architecture and
+     authorship through the first three snapshots, including
+     implementation of locale infrastructure, string, shadow C headers,
+     and the initial project documentation (DESIGN, CHECKLIST, and so
+     forth).  Later, more work on MT-safe string and shadow headers.
+
+   * Felix Natter for documentation on porting libstdc++.
+
+   * Nathanael Nerode for cleaning up the configuration/build process.
+
+   * NeXT, Inc. donated the front end that supports the Objective-C
+     language.
+
+   * Hans-Peter Nilsson for the CRIS and MMIX ports, improvements to the
+     search engine setup, various documentation fixes and other small
+     fixes.
+
+   * Geoff Noer for his work on getting cygwin native builds working.
+
+   * Diego Novillo for his work on Tree SSA, OpenMP, SPEC performance
+     tracking web pages, GIMPLE tuples, and assorted fixes.
+
+   * David O'Brien for the FreeBSD/alpha, FreeBSD/AMD x86-64,
+     FreeBSD/ARM, FreeBSD/PowerPC, and FreeBSD/SPARC64 ports and related
+     infrastructure improvements.
+
+   * Alexandre Oliva for various build infrastructure improvements,
+     scripts and amazing testing work, including keeping libtool issues
+     sane and happy.
+
+   * Stefan Olsson for work on mt_alloc.
+
+   * Melissa O'Neill for various NeXT fixes.
+
+   * Rainer Orth for random MIPS work, including improvements to GCC's
+     o32 ABI support, improvements to dejagnu's MIPS support, Java
+     configuration clean-ups and porting work, and maintaining the IRIX,
+     Solaris 2, and Tru64 UNIX ports.
+
+   * Hartmut Penner for work on the s390 port.
+
+   * Paul Petersen wrote the machine description for the Alliant FX/8.
+
+   * Alexandre Petit-Bianco for implementing much of the Java compiler
+     and continued Java maintainership.
+
+   * Matthias Pfaller for major improvements to the NS32k port.
+
+   * Gerald Pfeifer for his direction via the steering committee,
+     pointing out lots of problems we need to solve, maintenance of the
+     web pages, and taking care of documentation maintenance in general.
+
+   * Andrew Pinski for processing bug reports by the dozen.
+
+   * Ovidiu Predescu for his work on the Objective-C front end and
+     runtime libraries.
+
+   * Jerry Quinn for major performance improvements in C++ formatted
+     I/O.
+
+   * Ken Raeburn for various improvements to checker, MIPS ports and
+     various cleanups in the compiler.
+
+   * Rolf W. Rasmussen for hacking on AWT.
+
+   * David Reese of Sun Microsystems contributed to the Solaris on
+     PowerPC port.
+
+   * Volker Reichelt for keeping up with the problem reports.
+
+   * Joern Rennecke for maintaining the sh port, loop, regmove & reload
+     hacking and developing and maintaining the Epiphany port.
+
+   * Loren J. Rittle for improvements to libstdc++-v3 including the
+     FreeBSD port, threading fixes, thread-related configury changes,
+     critical threading documentation, and solutions to really tricky
+     I/O problems, as well as keeping GCC properly working on FreeBSD
+     and continuous testing.
+
+   * Craig Rodrigues for processing tons of bug reports.
+
+   * Ola Ro"nnerup for work on mt_alloc.
+
+   * Gavin Romig-Koch for lots of behind the scenes MIPS work.
+
+   * David Ronis inspired and encouraged Craig to rewrite the G77
+     documentation in texinfo format by contributing a first pass at a
+     translation of the old 'g77-0.5.16/f/DOC' file.
+
+   * Ken Rose for fixes to GCC's delay slot filling code.
+
+   * Paul Rubin wrote most of the preprocessor.
+
+   * Pe'tur Runo'lfsson for major performance improvements in C++
+     formatted I/O and large file support in C++ filebuf.
+
+   * Chip Salzenberg for libstdc++ patches and improvements to locales,
+     traits, Makefiles, libio, libtool hackery, and "long long" support.
+
+   * Juha Sarlin for improvements to the H8 code generator.
+
+   * Greg Satz assisted in making GCC work on HP-UX for the 9000 series
+     300.
+
+   * Roger Sayle for improvements to constant folding and GCC's RTL
+     optimizers as well as for fixing numerous bugs.
+
+   * Bradley Schatz for his work on the GCJ FAQ.
+
+   * Peter Schauer wrote the code to allow debugging to work on the
+     Alpha.
+
+   * William Schelter did most of the work on the Intel 80386 support.
+
+   * Tobias Schlu"ter for work on GNU Fortran.
+
+   * Bernd Schmidt for various code generation improvements and major
+     work in the reload pass, serving as release manager for GCC 2.95.3,
+     and work on the Blackfin and C6X ports.
+
+   * Peter Schmid for constant testing of libstdc++--especially
+     application testing, going above and beyond what was requested for
+     the release criteria--and libstdc++ header file tweaks.
+
+   * Jason Schroeder for jcf-dump patches.
+
+   * Andreas Schwab for his work on the m68k port.
+
+   * Lars Segerlund for work on GNU Fortran.
+
+   * Dodji Seketeli for numerous C++ bug fixes and debug info
+     improvements.
+
+   * Tim Shen for major work on '<regex>'.
+
+   * Joel Sherrill for his direction via the steering committee, RTEMS
+     contributions and RTEMS testing.
+
+   * Nathan Sidwell for many C++ fixes/improvements.
+
+   * Jeffrey Siegal for helping RMS with the original design of GCC,
+     some code which handles the parse tree and RTL data structures,
+     constant folding and help with the original VAX & m68k ports.
+
+   * Kenny Simpson for prompting libstdc++ fixes due to defect reports
+     from the LWG (thereby keeping GCC in line with updates from the
+     ISO).
+
+   * Franz Sirl for his ongoing work with making the PPC port stable for
+     GNU/Linux.
+
+   * Andrey Slepuhin for assorted AIX hacking.
+
+   * Trevor Smigiel for contributing the SPU port.
+
+   * Christopher Smith did the port for Convex machines.
+
+   * Danny Smith for his major efforts on the Mingw (and Cygwin) ports.
+
+   * Randy Smith finished the Sun FPA support.
+
+   * Ed Smith-Rowland for his continuous work on libstdc++-v3, special
+     functions, '<random>', and various improvements to C++11 features.
+
+   * Scott Snyder for queue, iterator, istream, and string fixes and
+     libstdc++ testsuite entries.  Also for providing the patch to G77
+     to add rudimentary support for 'INTEGER*1', 'INTEGER*2', and
+     'LOGICAL*1'.
+
+   * Zdenek Sojka for running automated regression testing of GCC and
+     reporting numerous bugs.
+
+   * Jayant Sonar for contributing the CR16 port.
+
+   * Brad Spencer for contributions to the GLIBCPP_FORCE_NEW technique.
+
+   * Richard Stallman, for writing the original GCC and launching the
+     GNU project.
+
+   * Jan Stein of the Chalmers Computer Society provided support for
+     Genix, as well as part of the 32000 machine description.
+
+   * Nigel Stephens for various mips16 related fixes/improvements.
+
+   * Jonathan Stone wrote the machine description for the Pyramid
+     computer.
+
+   * Graham Stott for various infrastructure improvements.
+
+   * John Stracke for his Java HTTP protocol fixes.
+
+   * Mike Stump for his Elxsi port, G++ contributions over the years and
+     more recently his vxworks contributions
+
+   * Jeff Sturm for Java porting help, bug fixes, and encouragement.
+
+   * Shigeya Suzuki for this fixes for the bsdi platforms.
+
+   * Ian Lance Taylor for the Go frontend, the initial mips16 and mips64
+     support, general configury hacking, fixincludes, etc.
+
+   * Holger Teutsch provided the support for the Clipper CPU.
+
+   * Gary Thomas for his ongoing work to make the PPC work for
+     GNU/Linux.
+
+   * Philipp Thomas for random bug fixes throughout the compiler
+
+   * Jason Thorpe for thread support in libstdc++ on NetBSD.
+
+   * Kresten Krab Thorup wrote the run time support for the Objective-C
+     language and the fantastic Java bytecode interpreter.
+
+   * Michael Tiemann for random bug fixes, the first instruction
+     scheduler, initial C++ support, function integration, NS32k, SPARC
+     and M88k machine description work, delay slot scheduling.
+
+   * Andreas Tobler for his work porting libgcj to Darwin.
+
+   * Teemu Torma for thread safe exception handling support.
+
+   * Leonard Tower wrote parts of the parser, RTL generator, and RTL
+     definitions, and of the VAX machine description.
+
+   * Daniel Towner and Hariharan Sandanagobalane contributed and
+     maintain the picoChip port.
+
+   * Tom Tromey for internationalization support and for his many Java
+     contributions and libgcj maintainership.
+
+   * Lassi Tuura for improvements to config.guess to determine HP
+     processor types.
+
+   * Petter Urkedal for libstdc++ CXXFLAGS, math, and algorithms fixes.
+
+   * Andy Vaught for the design and initial implementation of the GNU
+     Fortran front end.
+
+   * Brent Verner for work with the libstdc++ cshadow files and their
+     associated configure steps.
+
+   * Todd Vierling for contributions for NetBSD ports.
+
+   * Jonathan Wakely for contributing libstdc++ Doxygen notes and XHTML
+     guidance.
+
+   * Dean Wakerley for converting the install documentation from HTML to
+     texinfo in time for GCC 3.0.
+
+   * Krister Walfridsson for random bug fixes.
+
+   * Feng Wang for contributions to GNU Fortran.
+
+   * Stephen M. Webb for time and effort on making libstdc++ shadow
+     files work with the tricky Solaris 8+ headers, and for pushing the
+     build-time header tree.  Also, for starting and driving the
+     '<regex>' effort.
+
+   * John Wehle for various improvements for the x86 code generator,
+     related infrastructure improvements to help x86 code generation,
+     value range propagation and other work, WE32k port.
+
+   * Ulrich Weigand for work on the s390 port.
+
+   * Zack Weinberg for major work on cpplib and various other bug fixes.
+
+   * Matt Welsh for help with Linux Threads support in GCJ.
+
+   * Urban Widmark for help fixing java.io.
+
+   * Mark Wielaard for new Java library code and his work integrating
+     with Classpath.
+
+   * Dale Wiles helped port GCC to the Tahoe.
+
+   * Bob Wilson from Tensilica, Inc. for the Xtensa port.
+
+   * Jim Wilson for his direction via the steering committee, tackling
+     hard problems in various places that nobody else wanted to work on,
+     strength reduction and other loop optimizations.
+
+   * Paul Woegerer and Tal Agmon for the CRX port.
+
+   * Carlo Wood for various fixes.
+
+   * Tom Wood for work on the m88k port.
+
+   * Chung-Ju Wu for his work on the Andes NDS32 port.
+
+   * Canqun Yang for work on GNU Fortran.
+
+   * Masanobu Yuhara of Fujitsu Laboratories implemented the machine
+     description for the Tron architecture (specifically, the Gmicro).
+
+   * Kevin Zachmann helped port GCC to the Tahoe.
+
+   * Ayal Zaks for Swing Modulo Scheduling (SMS).
+
+   * Xiaoqiang Zhang for work on GNU Fortran.
+
+   * Gilles Zunino for help porting Java to Irix.
+
+ The following people are recognized for their contributions to GNAT,
+the Ada front end of GCC:
+   * Bernard Banner
+
+   * Romain Berrendonner
+
+   * Geert Bosch
+
+   * Emmanuel Briot
+
+   * Joel Brobecker
+
+   * Ben Brosgol
+
+   * Vincent Celier
+
+   * Arnaud Charlet
+
+   * Chien Chieng
+
+   * Cyrille Comar
+
+   * Cyrille Crozes
+
+   * Robert Dewar
+
+   * Gary Dismukes
+
+   * Robert Duff
+
+   * Ed Falis
+
+   * Ramon Fernandez
+
+   * Sam Figueroa
+
+   * Vasiliy Fofanov
+
+   * Michael Friess
+
+   * Franco Gasperoni
+
+   * Ted Giering
+
+   * Matthew Gingell
+
+   * Laurent Guerby
+
+   * Jerome Guitton
+
+   * Olivier Hainque
+
+   * Jerome Hugues
+
+   * Hristian Kirtchev
+
+   * Jerome Lambourg
+
+   * Bruno Leclerc
+
+   * Albert Lee
+
+   * Sean McNeil
+
+   * Javier Miranda
+
+   * Laurent Nana
+
+   * Pascal Obry
+
+   * Dong-Ik Oh
+
+   * Laurent Pautet
+
+   * Brett Porter
+
+   * Thomas Quinot
+
+   * Nicolas Roche
+
+   * Pat Rogers
+
+   * Jose Ruiz
+
+   * Douglas Rupp
+
+   * Sergey Rybin
+
+   * Gail Schenker
+
+   * Ed Schonberg
+
+   * Nicolas Setton
+
+   * Samuel Tardieu
+
+ The following people are recognized for their contributions of new
+features, bug reports, testing and integration of classpath/libgcj for
+GCC version 4.1:
+   * Lillian Angel for 'JTree' implementation and lots Free Swing
+     additions and bug fixes.
+
+   * Wolfgang Baer for 'GapContent' bug fixes.
+
+   * Anthony Balkissoon for 'JList', Free Swing 1.5 updates and mouse
+     event fixes, lots of Free Swing work including 'JTable' editing.
+
+   * Stuart Ballard for RMI constant fixes.
+
+   * Goffredo Baroncelli for 'HTTPURLConnection' fixes.
+
+   * Gary Benson for 'MessageFormat' fixes.
+
+   * Daniel Bonniot for 'Serialization' fixes.
+
+   * Chris Burdess for lots of gnu.xml and http protocol fixes, 'StAX'
+     and 'DOM xml:id' support.
+
+   * Ka-Hing Cheung for 'TreePath' and 'TreeSelection' fixes.
+
+   * Archie Cobbs for build fixes, VM interface updates,
+     'URLClassLoader' updates.
+
+   * Kelley Cook for build fixes.
+
+   * Martin Cordova for Suggestions for better 'SocketTimeoutException'.
+
+   * David Daney for 'BitSet' bug fixes, 'HttpURLConnection' rewrite and
+     improvements.
+
+   * Thomas Fitzsimmons for lots of upgrades to the gtk+ AWT and Cairo
+     2D support.  Lots of imageio framework additions, lots of AWT and
+     Free Swing bug fixes.
+
+   * Jeroen Frijters for 'ClassLoader' and nio cleanups, serialization
+     fixes, better 'Proxy' support, bug fixes and IKVM integration.
+
+   * Santiago Gala for 'AccessControlContext' fixes.
+
+   * Nicolas Geoffray for 'VMClassLoader' and 'AccessController'
+     improvements.
+
+   * David Gilbert for 'basic' and 'metal' icon and plaf support and
+     lots of documenting, Lots of Free Swing and metal theme additions.
+     'MetalIconFactory' implementation.
+
+   * Anthony Green for 'MIDI' framework, 'ALSA' and 'DSSI' providers.
+
+   * Andrew Haley for 'Serialization' and 'URLClassLoader' fixes, gcj
+     build speedups.
+
+   * Kim Ho for 'JFileChooser' implementation.
+
+   * Andrew John Hughes for 'Locale' and net fixes, URI RFC2986 updates,
+     'Serialization' fixes, 'Properties' XML support and generic branch
+     work, VMIntegration guide update.
+
+   * Bastiaan Huisman for 'TimeZone' bug fixing.
+
+   * Andreas Jaeger for mprec updates.
+
+   * Paul Jenner for better '-Werror' support.
+
+   * Ito Kazumitsu for 'NetworkInterface' implementation and updates.
+
+   * Roman Kennke for 'BoxLayout', 'GrayFilter' and 'SplitPane', plus
+     bug fixes all over.  Lots of Free Swing work including styled text.
+
+   * Simon Kitching for 'String' cleanups and optimization suggestions.
+
+   * Michael Koch for configuration fixes, 'Locale' updates, bug and
+     build fixes.
+
+   * Guilhem Lavaux for configuration, thread and channel fixes and
+     Kaffe integration.  JCL native 'Pointer' updates.  Logger bug
+     fixes.
+
+   * David Lichteblau for JCL support library global/local reference
+     cleanups.
+
+   * Aaron Luchko for JDWP updates and documentation fixes.
+
+   * Ziga Mahkovec for 'Graphics2D' upgraded to Cairo 0.5 and new regex
+     features.
+
+   * Sven de Marothy for BMP imageio support, CSS and 'TextLayout'
+     fixes.  'GtkImage' rewrite, 2D, awt, free swing and date/time fixes
+     and implementing the Qt4 peers.
+
+   * Casey Marshall for crypto algorithm fixes, 'FileChannel' lock,
+     'SystemLogger' and 'FileHandler' rotate implementations, NIO
+     'FileChannel.map' support, security and policy updates.
+
+   * Bryce McKinlay for RMI work.
+
+   * Audrius Meskauskas for lots of Free Corba, RMI and HTML work plus
+     testing and documenting.
+
+   * Kalle Olavi Niemitalo for build fixes.
+
+   * Rainer Orth for build fixes.
+
+   * Andrew Overholt for 'File' locking fixes.
+
+   * Ingo Proetel for 'Image', 'Logger' and 'URLClassLoader' updates.
+
+   * Olga Rodimina for 'MenuSelectionManager' implementation.
+
+   * Jan Roehrich for 'BasicTreeUI' and 'JTree' fixes.
+
+   * Julian Scheid for documentation updates and gjdoc support.
+
+   * Christian Schlichtherle for zip fixes and cleanups.
+
+   * Robert Schuster for documentation updates and beans fixes,
+     'TreeNode' enumerations and 'ActionCommand' and various fixes, XML
+     and URL, AWT and Free Swing bug fixes.
+
+   * Keith Seitz for lots of JDWP work.
+
+   * Christian Thalinger for 64-bit cleanups, Configuration and VM
+     interface fixes and 'CACAO' integration, 'fdlibm' updates.
+
+   * Gael Thomas for 'VMClassLoader' boot packages support suggestions.
+
+   * Andreas Tobler for Darwin and Solaris testing and fixing, 'Qt4'
+     support for Darwin/OS X, 'Graphics2D' support, 'gtk+' updates.
+
+   * Dalibor Topic for better 'DEBUG' support, build cleanups and Kaffe
+     integration.  'Qt4' build infrastructure, 'SHA1PRNG' and
+     'GdkPixbugDecoder' updates.
+
+   * Tom Tromey for Eclipse integration, generics work, lots of bug
+     fixes and gcj integration including coordinating The Big Merge.
+
+   * Mark Wielaard for bug fixes, packaging and release management,
+     'Clipboard' implementation, system call interrupts and network
+     timeouts and 'GdkPixpufDecoder' fixes.
+
+ In addition to the above, all of which also contributed time and energy
+in testing GCC, we would like to thank the following for their
+contributions to testing:
+
+   * Michael Abd-El-Malek
+
+   * Thomas Arend
+
+   * Bonzo Armstrong
+
+   * Steven Ashe
+
+   * Chris Baldwin
+
+   * David Billinghurst
+
+   * Jim Blandy
+
+   * Stephane Bortzmeyer
+
+   * Horst von Brand
+
+   * Frank Braun
+
+   * Rodney Brown
+
+   * Sidney Cadot
+
+   * Bradford Castalia
+
+   * Robert Clark
+
+   * Jonathan Corbet
+
+   * Ralph Doncaster
+
+   * Richard Emberson
+
+   * Levente Farkas
+
+   * Graham Fawcett
+
+   * Mark Fernyhough
+
+   * Robert A. French
+
+   * Jo"rgen Freyh
+
+   * Mark K. Gardner
+
+   * Charles-Antoine Gauthier
+
+   * Yung Shing Gene
+
+   * David Gilbert
+
+   * Simon Gornall
+
+   * Fred Gray
+
+   * John Griffin
+
+   * Patrik Hagglund
+
+   * Phil Hargett
+
+   * Amancio Hasty
+
+   * Takafumi Hayashi
+
+   * Bryan W. Headley
+
+   * Kevin B. Hendricks
+
+   * Joep Jansen
+
+   * Christian Joensson
+
+   * Michel Kern
+
+   * David Kidd
+
+   * Tobias Kuipers
+
+   * Anand Krishnaswamy
+
+   * A. O. V. Le Blanc
+
+   * llewelly
+
+   * Damon Love
+
+   * Brad Lucier
+
+   * Matthias Klose
+
+   * Martin Knoblauch
+
+   * Rick Lutowski
+
+   * Jesse Macnish
+
+   * Stefan Morrell
+
+   * Anon A. Mous
+
+   * Matthias Mueller
+
+   * Pekka Nikander
+
+   * Rick Niles
+
+   * Jon Olson
+
+   * Magnus Persson
+
+   * Chris Pollard
+
+   * Richard Polton
+
+   * Derk Reefman
+
+   * David Rees
+
+   * Paul Reilly
+
+   * Tom Reilly
+
+   * Torsten Rueger
+
+   * Danny Sadinoff
+
+   * Marc Schifer
+
+   * Erik Schnetter
+
+   * Wayne K. Schroll
+
+   * David Schuler
+
+   * Vin Shelton
+
+   * Tim Souder
+
+   * Adam Sulmicki
+
+   * Bill Thorson
+
+   * George Talbot
+
+   * Pedro A. M. Vazquez
+
+   * Gregory Warnes
+
+   * Ian Watson
+
+   * David E. Young
+
+   * And many others
+
+ And finally we'd like to thank everyone who uses the compiler, provides
+feedback and generally reminds us why we're doing this work in the first
+place.
+
+
+File: gccint.info,  Node: Option Index,  Next: Concept Index,  Prev: Contributors,  Up: Top
+
+Option Index
+************
+
+GCC's command line options are indexed here without any initial '-' or
+'--'.  Where an option has both positive and negative forms (such as
+'-fOPTION' and '-fno-OPTION'), relevant entries in the manual are
+indexed under the most appropriate form; it may sometimes be useful to
+look up both forms.
+
+
+* Menu:
+
+* fltrans:                               Internal flags.       (line 18)
+* fltrans-output-list:                   Internal flags.       (line 23)
+* fresolution:                           Internal flags.       (line 27)
+* fwpa:                                  Internal flags.       (line  9)
+* msoft-float:                           Soft float library routines.
+                                                               (line  6)
+
+
+File: gccint.info,  Node: Concept Index,  Prev: Option Index,  Up: Top
+
+Concept Index
+*************
+
+
+* Menu:
+
+* '!' in constraint:                     Multi-Alternative.  (line   47)
+* '#' in constraint:                     Modifiers.          (line   67)
+* '#' in template:                       Output Template.    (line   66)
+* #pragma:                               Misc.               (line  387)
+* '%' in constraint:                     Modifiers.          (line   45)
+* % in GTY option:                       GTY Options.        (line   18)
+* '%' in template:                       Output Template.    (line    6)
+* '&' in constraint:                     Modifiers.          (line   25)
+* (nil):                                 RTL Objects.        (line   73)
+* '*' in constraint:                     Modifiers.          (line   72)
+* '*' in template:                       Output Statement.   (line   29)
+* '+' in constraint:                     Modifiers.          (line   12)
+* '-fsection-anchors':                   Special Accessors.  (line  117)
+* '-fsection-anchors' <1>:               Anchored Addresses. (line    6)
+* '/c' in RTL dump:                      Flags.              (line  221)
+* '/f' in RTL dump:                      Flags.              (line  229)
+* '/i' in RTL dump:                      Flags.              (line  274)
+* '/j' in RTL dump:                      Flags.              (line  286)
+* '/s' in RTL dump:                      Flags.              (line  245)
+* '/u' in RTL dump:                      Flags.              (line  296)
+* '/v' in RTL dump:                      Flags.              (line  328)
+* '0' in constraint:                     Simple Constraints. (line  128)
+* '<' in constraint:                     Simple Constraints. (line   47)
+* '=' in constraint:                     Modifiers.          (line    8)
+* '>' in constraint:                     Simple Constraints. (line   59)
+* '?' in constraint:                     Multi-Alternative.  (line   41)
+* \:                                     Output Template.    (line   46)
+* __absvdi2:                             Integer library routines.
+                                                             (line  106)
+* __absvsi2:                             Integer library routines.
+                                                             (line  105)
+* __addda3:                              Fixed-point fractional library routines.
+                                                             (line   44)
+* __adddf3:                              Soft float library routines.
+                                                             (line   22)
+* __adddq3:                              Fixed-point fractional library routines.
+                                                             (line   31)
+* __addha3:                              Fixed-point fractional library routines.
+                                                             (line   41)
+* __addhq3:                              Fixed-point fractional library routines.
+                                                             (line   29)
+* __addqq3:                              Fixed-point fractional library routines.
+                                                             (line   27)
+* __addsa3:                              Fixed-point fractional library routines.
+                                                             (line   43)
+* __addsf3:                              Soft float library routines.
+                                                             (line   21)
+* __addsq3:                              Fixed-point fractional library routines.
+                                                             (line   30)
+* __addta3:                              Fixed-point fractional library routines.
+                                                             (line   45)
+* __addtf3:                              Soft float library routines.
+                                                             (line   23)
+* __adduda3:                             Fixed-point fractional library routines.
+                                                             (line   51)
+* __addudq3:                             Fixed-point fractional library routines.
+                                                             (line   39)
+* __adduha3:                             Fixed-point fractional library routines.
+                                                             (line   47)
+* __adduhq3:                             Fixed-point fractional library routines.
+                                                             (line   35)
+* __adduqq3:                             Fixed-point fractional library routines.
+                                                             (line   33)
+* __addusa3:                             Fixed-point fractional library routines.
+                                                             (line   49)
+* __addusq3:                             Fixed-point fractional library routines.
+                                                             (line   37)
+* __adduta3:                             Fixed-point fractional library routines.
+                                                             (line   53)
+* __addvdi3:                             Integer library routines.
+                                                             (line  110)
+* __addvsi3:                             Integer library routines.
+                                                             (line  109)
+* __addxf3:                              Soft float library routines.
+                                                             (line   25)
+* __ashlda3:                             Fixed-point fractional library routines.
+                                                             (line  350)
+* __ashldi3:                             Integer library routines.
+                                                             (line   13)
+* __ashldq3:                             Fixed-point fractional library routines.
+                                                             (line  338)
+* __ashlha3:                             Fixed-point fractional library routines.
+                                                             (line  348)
+* __ashlhq3:                             Fixed-point fractional library routines.
+                                                             (line  336)
+* __ashlqq3:                             Fixed-point fractional library routines.
+                                                             (line  335)
+* __ashlsa3:                             Fixed-point fractional library routines.
+                                                             (line  349)
+* __ashlsi3:                             Integer library routines.
+                                                             (line   12)
+* __ashlsq3:                             Fixed-point fractional library routines.
+                                                             (line  337)
+* __ashlta3:                             Fixed-point fractional library routines.
+                                                             (line  351)
+* __ashlti3:                             Integer library routines.
+                                                             (line   14)
+* __ashluda3:                            Fixed-point fractional library routines.
+                                                             (line  357)
+* __ashludq3:                            Fixed-point fractional library routines.
+                                                             (line  346)
+* __ashluha3:                            Fixed-point fractional library routines.
+                                                             (line  353)
+* __ashluhq3:                            Fixed-point fractional library routines.
+                                                             (line  342)
+* __ashluqq3:                            Fixed-point fractional library routines.
+                                                             (line  340)
+* __ashlusa3:                            Fixed-point fractional library routines.
+                                                             (line  355)
+* __ashlusq3:                            Fixed-point fractional library routines.
+                                                             (line  344)
+* __ashluta3:                            Fixed-point fractional library routines.
+                                                             (line  359)
+* __ashrda3:                             Fixed-point fractional library routines.
+                                                             (line  370)
+* __ashrdi3:                             Integer library routines.
+                                                             (line   18)
+* __ashrdq3:                             Fixed-point fractional library routines.
+                                                             (line  366)
+* __ashrha3:                             Fixed-point fractional library routines.
+                                                             (line  368)
+* __ashrhq3:                             Fixed-point fractional library routines.
+                                                             (line  364)
+* __ashrqq3:                             Fixed-point fractional library routines.
+                                                             (line  363)
+* __ashrsa3:                             Fixed-point fractional library routines.
+                                                             (line  369)
+* __ashrsi3:                             Integer library routines.
+                                                             (line   17)
+* __ashrsq3:                             Fixed-point fractional library routines.
+                                                             (line  365)
+* __ashrta3:                             Fixed-point fractional library routines.
+                                                             (line  371)
+* __ashrti3:                             Integer library routines.
+                                                             (line   19)
+* __bid_adddd3:                          Decimal float library routines.
+                                                             (line   23)
+* __bid_addsd3:                          Decimal float library routines.
+                                                             (line   19)
+* __bid_addtd3:                          Decimal float library routines.
+                                                             (line   27)
+* __bid_divdd3:                          Decimal float library routines.
+                                                             (line   66)
+* __bid_divsd3:                          Decimal float library routines.
+                                                             (line   62)
+* __bid_divtd3:                          Decimal float library routines.
+                                                             (line   70)
+* __bid_eqdd2:                           Decimal float library routines.
+                                                             (line  258)
+* __bid_eqsd2:                           Decimal float library routines.
+                                                             (line  256)
+* __bid_eqtd2:                           Decimal float library routines.
+                                                             (line  260)
+* __bid_extendddtd2:                     Decimal float library routines.
+                                                             (line   91)
+* __bid_extendddtf:                      Decimal float library routines.
+                                                             (line  139)
+* __bid_extendddxf:                      Decimal float library routines.
+                                                             (line  133)
+* __bid_extenddfdd:                      Decimal float library routines.
+                                                             (line  146)
+* __bid_extenddftd:                      Decimal float library routines.
+                                                             (line  106)
+* __bid_extendsddd2:                     Decimal float library routines.
+                                                             (line   87)
+* __bid_extendsddf:                      Decimal float library routines.
+                                                             (line  127)
+* __bid_extendsdtd2:                     Decimal float library routines.
+                                                             (line   89)
+* __bid_extendsdtf:                      Decimal float library routines.
+                                                             (line  137)
+* __bid_extendsdxf:                      Decimal float library routines.
+                                                             (line  131)
+* __bid_extendsfdd:                      Decimal float library routines.
+                                                             (line  102)
+* __bid_extendsfsd:                      Decimal float library routines.
+                                                             (line  144)
+* __bid_extendsftd:                      Decimal float library routines.
+                                                             (line  104)
+* __bid_extendtftd:                      Decimal float library routines.
+                                                             (line  148)
+* __bid_extendxftd:                      Decimal float library routines.
+                                                             (line  108)
+* __bid_fixdddi:                         Decimal float library routines.
+                                                             (line  169)
+* __bid_fixddsi:                         Decimal float library routines.
+                                                             (line  161)
+* __bid_fixsddi:                         Decimal float library routines.
+                                                             (line  167)
+* __bid_fixsdsi:                         Decimal float library routines.
+                                                             (line  159)
+* __bid_fixtddi:                         Decimal float library routines.
+                                                             (line  171)
+* __bid_fixtdsi:                         Decimal float library routines.
+                                                             (line  163)
+* __bid_fixunsdddi:                      Decimal float library routines.
+                                                             (line  186)
+* __bid_fixunsddsi:                      Decimal float library routines.
+                                                             (line  177)
+* __bid_fixunssddi:                      Decimal float library routines.
+                                                             (line  184)
+* __bid_fixunssdsi:                      Decimal float library routines.
+                                                             (line  175)
+* __bid_fixunstddi:                      Decimal float library routines.
+                                                             (line  188)
+* __bid_fixunstdsi:                      Decimal float library routines.
+                                                             (line  179)
+* __bid_floatdidd:                       Decimal float library routines.
+                                                             (line  204)
+* __bid_floatdisd:                       Decimal float library routines.
+                                                             (line  202)
+* __bid_floatditd:                       Decimal float library routines.
+                                                             (line  206)
+* __bid_floatsidd:                       Decimal float library routines.
+                                                             (line  195)
+* __bid_floatsisd:                       Decimal float library routines.
+                                                             (line  193)
+* __bid_floatsitd:                       Decimal float library routines.
+                                                             (line  197)
+* __bid_floatunsdidd:                    Decimal float library routines.
+                                                             (line  222)
+* __bid_floatunsdisd:                    Decimal float library routines.
+                                                             (line  220)
+* __bid_floatunsditd:                    Decimal float library routines.
+                                                             (line  224)
+* __bid_floatunssidd:                    Decimal float library routines.
+                                                             (line  213)
+* __bid_floatunssisd:                    Decimal float library routines.
+                                                             (line  211)
+* __bid_floatunssitd:                    Decimal float library routines.
+                                                             (line  215)
+* __bid_gedd2:                           Decimal float library routines.
+                                                             (line  276)
+* __bid_gesd2:                           Decimal float library routines.
+                                                             (line  274)
+* __bid_getd2:                           Decimal float library routines.
+                                                             (line  278)
+* __bid_gtdd2:                           Decimal float library routines.
+                                                             (line  303)
+* __bid_gtsd2:                           Decimal float library routines.
+                                                             (line  301)
+* __bid_gttd2:                           Decimal float library routines.
+                                                             (line  305)
+* __bid_ledd2:                           Decimal float library routines.
+                                                             (line  294)
+* __bid_lesd2:                           Decimal float library routines.
+                                                             (line  292)
+* __bid_letd2:                           Decimal float library routines.
+                                                             (line  296)
+* __bid_ltdd2:                           Decimal float library routines.
+                                                             (line  285)
+* __bid_ltsd2:                           Decimal float library routines.
+                                                             (line  283)
+* __bid_lttd2:                           Decimal float library routines.
+                                                             (line  287)
+* __bid_muldd3:                          Decimal float library routines.
+                                                             (line   52)
+* __bid_mulsd3:                          Decimal float library routines.
+                                                             (line   48)
+* __bid_multd3:                          Decimal float library routines.
+                                                             (line   56)
+* __bid_nedd2:                           Decimal float library routines.
+                                                             (line  267)
+* __bid_negdd2:                          Decimal float library routines.
+                                                             (line   77)
+* __bid_negsd2:                          Decimal float library routines.
+                                                             (line   75)
+* __bid_negtd2:                          Decimal float library routines.
+                                                             (line   79)
+* __bid_nesd2:                           Decimal float library routines.
+                                                             (line  265)
+* __bid_netd2:                           Decimal float library routines.
+                                                             (line  269)
+* __bid_subdd3:                          Decimal float library routines.
+                                                             (line   37)
+* __bid_subsd3:                          Decimal float library routines.
+                                                             (line   33)
+* __bid_subtd3:                          Decimal float library routines.
+                                                             (line   41)
+* __bid_truncdddf:                       Decimal float library routines.
+                                                             (line  152)
+* __bid_truncddsd2:                      Decimal float library routines.
+                                                             (line   93)
+* __bid_truncddsf:                       Decimal float library routines.
+                                                             (line  123)
+* __bid_truncdfsd:                       Decimal float library routines.
+                                                             (line  110)
+* __bid_truncsdsf:                       Decimal float library routines.
+                                                             (line  150)
+* __bid_trunctddd2:                      Decimal float library routines.
+                                                             (line   97)
+* __bid_trunctddf:                       Decimal float library routines.
+                                                             (line  129)
+* __bid_trunctdsd2:                      Decimal float library routines.
+                                                             (line   95)
+* __bid_trunctdsf:                       Decimal float library routines.
+                                                             (line  125)
+* __bid_trunctdtf:                       Decimal float library routines.
+                                                             (line  154)
+* __bid_trunctdxf:                       Decimal float library routines.
+                                                             (line  135)
+* __bid_trunctfdd:                       Decimal float library routines.
+                                                             (line  118)
+* __bid_trunctfsd:                       Decimal float library routines.
+                                                             (line  114)
+* __bid_truncxfdd:                       Decimal float library routines.
+                                                             (line  116)
+* __bid_truncxfsd:                       Decimal float library routines.
+                                                             (line  112)
+* __bid_unorddd2:                        Decimal float library routines.
+                                                             (line  234)
+* __bid_unordsd2:                        Decimal float library routines.
+                                                             (line  232)
+* __bid_unordtd2:                        Decimal float library routines.
+                                                             (line  236)
+* __bswapdi2:                            Integer library routines.
+                                                             (line  161)
+* __bswapsi2:                            Integer library routines.
+                                                             (line  160)
+* __builtin_classify_type:               Varargs.            (line   48)
+* __builtin_next_arg:                    Varargs.            (line   39)
+* __builtin_saveregs:                    Varargs.            (line   22)
+* __clear_cache:                         Miscellaneous routines.
+                                                             (line    9)
+* __clzdi2:                              Integer library routines.
+                                                             (line  130)
+* __clzsi2:                              Integer library routines.
+                                                             (line  129)
+* __clzti2:                              Integer library routines.
+                                                             (line  131)
+* __cmpda2:                              Fixed-point fractional library routines.
+                                                             (line  450)
+* __cmpdf2:                              Soft float library routines.
+                                                             (line  163)
+* __cmpdi2:                              Integer library routines.
+                                                             (line   86)
+* __cmpdq2:                              Fixed-point fractional library routines.
+                                                             (line  439)
+* __cmpha2:                              Fixed-point fractional library routines.
+                                                             (line  448)
+* __cmphq2:                              Fixed-point fractional library routines.
+                                                             (line  437)
+* __cmpqq2:                              Fixed-point fractional library routines.
+                                                             (line  436)
+* __cmpsa2:                              Fixed-point fractional library routines.
+                                                             (line  449)
+* __cmpsf2:                              Soft float library routines.
+                                                             (line  162)
+* __cmpsq2:                              Fixed-point fractional library routines.
+                                                             (line  438)
+* __cmpta2:                              Fixed-point fractional library routines.
+                                                             (line  451)
+* __cmptf2:                              Soft float library routines.
+                                                             (line  164)
+* __cmpti2:                              Integer library routines.
+                                                             (line   87)
+* __cmpuda2:                             Fixed-point fractional library routines.
+                                                             (line  456)
+* __cmpudq2:                             Fixed-point fractional library routines.
+                                                             (line  446)
+* __cmpuha2:                             Fixed-point fractional library routines.
+                                                             (line  453)
+* __cmpuhq2:                             Fixed-point fractional library routines.
+                                                             (line  443)
+* __cmpuqq2:                             Fixed-point fractional library routines.
+                                                             (line  441)
+* __cmpusa2:                             Fixed-point fractional library routines.
+                                                             (line  455)
+* __cmpusq2:                             Fixed-point fractional library routines.
+                                                             (line  444)
+* __cmputa2:                             Fixed-point fractional library routines.
+                                                             (line  458)
+* __CTOR_LIST__:                         Initialization.     (line   25)
+* __ctzdi2:                              Integer library routines.
+                                                             (line  137)
+* __ctzsi2:                              Integer library routines.
+                                                             (line  136)
+* __ctzti2:                              Integer library routines.
+                                                             (line  138)
+* __divda3:                              Fixed-point fractional library routines.
+                                                             (line  226)
+* __divdc3:                              Soft float library routines.
+                                                             (line  250)
+* __divdf3:                              Soft float library routines.
+                                                             (line   47)
+* __divdi3:                              Integer library routines.
+                                                             (line   24)
+* __divdq3:                              Fixed-point fractional library routines.
+                                                             (line  221)
+* __divha3:                              Fixed-point fractional library routines.
+                                                             (line  223)
+* __divhq3:                              Fixed-point fractional library routines.
+                                                             (line  219)
+* __divqq3:                              Fixed-point fractional library routines.
+                                                             (line  217)
+* __divsa3:                              Fixed-point fractional library routines.
+                                                             (line  225)
+* __divsc3:                              Soft float library routines.
+                                                             (line  248)
+* __divsf3:                              Soft float library routines.
+                                                             (line   46)
+* __divsi3:                              Integer library routines.
+                                                             (line   23)
+* __divsq3:                              Fixed-point fractional library routines.
+                                                             (line  220)
+* __divta3:                              Fixed-point fractional library routines.
+                                                             (line  227)
+* __divtc3:                              Soft float library routines.
+                                                             (line  252)
+* __divtf3:                              Soft float library routines.
+                                                             (line   48)
+* __divti3:                              Integer library routines.
+                                                             (line   25)
+* __divxc3:                              Soft float library routines.
+                                                             (line  254)
+* __divxf3:                              Soft float library routines.
+                                                             (line   50)
+* __dpd_adddd3:                          Decimal float library routines.
+                                                             (line   21)
+* __dpd_addsd3:                          Decimal float library routines.
+                                                             (line   17)
+* __dpd_addtd3:                          Decimal float library routines.
+                                                             (line   25)
+* __dpd_divdd3:                          Decimal float library routines.
+                                                             (line   64)
+* __dpd_divsd3:                          Decimal float library routines.
+                                                             (line   60)
+* __dpd_divtd3:                          Decimal float library routines.
+                                                             (line   68)
+* __dpd_eqdd2:                           Decimal float library routines.
+                                                             (line  257)
+* __dpd_eqsd2:                           Decimal float library routines.
+                                                             (line  255)
+* __dpd_eqtd2:                           Decimal float library routines.
+                                                             (line  259)
+* __dpd_extendddtd2:                     Decimal float library routines.
+                                                             (line   90)
+* __dpd_extendddtf:                      Decimal float library routines.
+                                                             (line  138)
+* __dpd_extendddxf:                      Decimal float library routines.
+                                                             (line  132)
+* __dpd_extenddfdd:                      Decimal float library routines.
+                                                             (line  145)
+* __dpd_extenddftd:                      Decimal float library routines.
+                                                             (line  105)
+* __dpd_extendsddd2:                     Decimal float library routines.
+                                                             (line   86)
+* __dpd_extendsddf:                      Decimal float library routines.
+                                                             (line  126)
+* __dpd_extendsdtd2:                     Decimal float library routines.
+                                                             (line   88)
+* __dpd_extendsdtf:                      Decimal float library routines.
+                                                             (line  136)
+* __dpd_extendsdxf:                      Decimal float library routines.
+                                                             (line  130)
+* __dpd_extendsfdd:                      Decimal float library routines.
+                                                             (line  101)
+* __dpd_extendsfsd:                      Decimal float library routines.
+                                                             (line  143)
+* __dpd_extendsftd:                      Decimal float library routines.
+                                                             (line  103)
+* __dpd_extendtftd:                      Decimal float library routines.
+                                                             (line  147)
+* __dpd_extendxftd:                      Decimal float library routines.
+                                                             (line  107)
+* __dpd_fixdddi:                         Decimal float library routines.
+                                                             (line  168)
+* __dpd_fixddsi:                         Decimal float library routines.
+                                                             (line  160)
+* __dpd_fixsddi:                         Decimal float library routines.
+                                                             (line  166)
+* __dpd_fixsdsi:                         Decimal float library routines.
+                                                             (line  158)
+* __dpd_fixtddi:                         Decimal float library routines.
+                                                             (line  170)
+* __dpd_fixtdsi:                         Decimal float library routines.
+                                                             (line  162)
+* __dpd_fixunsdddi:                      Decimal float library routines.
+                                                             (line  185)
+* __dpd_fixunsddsi:                      Decimal float library routines.
+                                                             (line  176)
+* __dpd_fixunssddi:                      Decimal float library routines.
+                                                             (line  183)
+* __dpd_fixunssdsi:                      Decimal float library routines.
+                                                             (line  174)
+* __dpd_fixunstddi:                      Decimal float library routines.
+                                                             (line  187)
+* __dpd_fixunstdsi:                      Decimal float library routines.
+                                                             (line  178)
+* __dpd_floatdidd:                       Decimal float library routines.
+                                                             (line  203)
+* __dpd_floatdisd:                       Decimal float library routines.
+                                                             (line  201)
+* __dpd_floatditd:                       Decimal float library routines.
+                                                             (line  205)
+* __dpd_floatsidd:                       Decimal float library routines.
+                                                             (line  194)
+* __dpd_floatsisd:                       Decimal float library routines.
+                                                             (line  192)
+* __dpd_floatsitd:                       Decimal float library routines.
+                                                             (line  196)
+* __dpd_floatunsdidd:                    Decimal float library routines.
+                                                             (line  221)
+* __dpd_floatunsdisd:                    Decimal float library routines.
+                                                             (line  219)
+* __dpd_floatunsditd:                    Decimal float library routines.
+                                                             (line  223)
+* __dpd_floatunssidd:                    Decimal float library routines.
+                                                             (line  212)
+* __dpd_floatunssisd:                    Decimal float library routines.
+                                                             (line  210)
+* __dpd_floatunssitd:                    Decimal float library routines.
+                                                             (line  214)
+* __dpd_gedd2:                           Decimal float library routines.
+                                                             (line  275)
+* __dpd_gesd2:                           Decimal float library routines.
+                                                             (line  273)
+* __dpd_getd2:                           Decimal float library routines.
+                                                             (line  277)
+* __dpd_gtdd2:                           Decimal float library routines.
+                                                             (line  302)
+* __dpd_gtsd2:                           Decimal float library routines.
+                                                             (line  300)
+* __dpd_gttd2:                           Decimal float library routines.
+                                                             (line  304)
+* __dpd_ledd2:                           Decimal float library routines.
+                                                             (line  293)
+* __dpd_lesd2:                           Decimal float library routines.
+                                                             (line  291)
+* __dpd_letd2:                           Decimal float library routines.
+                                                             (line  295)
+* __dpd_ltdd2:                           Decimal float library routines.
+                                                             (line  284)
+* __dpd_ltsd2:                           Decimal float library routines.
+                                                             (line  282)
+* __dpd_lttd2:                           Decimal float library routines.
+                                                             (line  286)
+* __dpd_muldd3:                          Decimal float library routines.
+                                                             (line   50)
+* __dpd_mulsd3:                          Decimal float library routines.
+                                                             (line   46)
+* __dpd_multd3:                          Decimal float library routines.
+                                                             (line   54)
+* __dpd_nedd2:                           Decimal float library routines.
+                                                             (line  266)
+* __dpd_negdd2:                          Decimal float library routines.
+                                                             (line   76)
+* __dpd_negsd2:                          Decimal float library routines.
+                                                             (line   74)
+* __dpd_negtd2:                          Decimal float library routines.
+                                                             (line   78)
+* __dpd_nesd2:                           Decimal float library routines.
+                                                             (line  264)
+* __dpd_netd2:                           Decimal float library routines.
+                                                             (line  268)
+* __dpd_subdd3:                          Decimal float library routines.
+                                                             (line   35)
+* __dpd_subsd3:                          Decimal float library routines.
+                                                             (line   31)
+* __dpd_subtd3:                          Decimal float library routines.
+                                                             (line   39)
+* __dpd_truncdddf:                       Decimal float library routines.
+                                                             (line  151)
+* __dpd_truncddsd2:                      Decimal float library routines.
+                                                             (line   92)
+* __dpd_truncddsf:                       Decimal float library routines.
+                                                             (line  122)
+* __dpd_truncdfsd:                       Decimal float library routines.
+                                                             (line  109)
+* __dpd_truncsdsf:                       Decimal float library routines.
+                                                             (line  149)
+* __dpd_trunctddd2:                      Decimal float library routines.
+                                                             (line   96)
+* __dpd_trunctddf:                       Decimal float library routines.
+                                                             (line  128)
+* __dpd_trunctdsd2:                      Decimal float library routines.
+                                                             (line   94)
+* __dpd_trunctdsf:                       Decimal float library routines.
+                                                             (line  124)
+* __dpd_trunctdtf:                       Decimal float library routines.
+                                                             (line  153)
+* __dpd_trunctdxf:                       Decimal float library routines.
+                                                             (line  134)
+* __dpd_trunctfdd:                       Decimal float library routines.
+                                                             (line  117)
+* __dpd_trunctfsd:                       Decimal float library routines.
+                                                             (line  113)
+* __dpd_truncxfdd:                       Decimal float library routines.
+                                                             (line  115)
+* __dpd_truncxfsd:                       Decimal float library routines.
+                                                             (line  111)
+* __dpd_unorddd2:                        Decimal float library routines.
+                                                             (line  233)
+* __dpd_unordsd2:                        Decimal float library routines.
+                                                             (line  231)
+* __dpd_unordtd2:                        Decimal float library routines.
+                                                             (line  235)
+* __DTOR_LIST__:                         Initialization.     (line   25)
+* __eqdf2:                               Soft float library routines.
+                                                             (line  193)
+* __eqsf2:                               Soft float library routines.
+                                                             (line  192)
+* __eqtf2:                               Soft float library routines.
+                                                             (line  194)
+* __extenddftf2:                         Soft float library routines.
+                                                             (line   67)
+* __extenddfxf2:                         Soft float library routines.
+                                                             (line   68)
+* __extendsfdf2:                         Soft float library routines.
+                                                             (line   64)
+* __extendsftf2:                         Soft float library routines.
+                                                             (line   65)
+* __extendsfxf2:                         Soft float library routines.
+                                                             (line   66)
+* __ffsdi2:                              Integer library routines.
+                                                             (line  143)
+* __ffsti2:                              Integer library routines.
+                                                             (line  144)
+* __fixdfdi:                             Soft float library routines.
+                                                             (line   87)
+* __fixdfsi:                             Soft float library routines.
+                                                             (line   80)
+* __fixdfti:                             Soft float library routines.
+                                                             (line   93)
+* __fixsfdi:                             Soft float library routines.
+                                                             (line   86)
+* __fixsfsi:                             Soft float library routines.
+                                                             (line   79)
+* __fixsfti:                             Soft float library routines.
+                                                             (line   92)
+* __fixtfdi:                             Soft float library routines.
+                                                             (line   88)
+* __fixtfsi:                             Soft float library routines.
+                                                             (line   81)
+* __fixtfti:                             Soft float library routines.
+                                                             (line   94)
+* __fixunsdfdi:                          Soft float library routines.
+                                                             (line  107)
+* __fixunsdfsi:                          Soft float library routines.
+                                                             (line  100)
+* __fixunsdfti:                          Soft float library routines.
+                                                             (line  114)
+* __fixunssfdi:                          Soft float library routines.
+                                                             (line  106)
+* __fixunssfsi:                          Soft float library routines.
+                                                             (line   99)
+* __fixunssfti:                          Soft float library routines.
+                                                             (line  113)
+* __fixunstfdi:                          Soft float library routines.
+                                                             (line  108)
+* __fixunstfsi:                          Soft float library routines.
+                                                             (line  101)
+* __fixunstfti:                          Soft float library routines.
+                                                             (line  115)
+* __fixunsxfdi:                          Soft float library routines.
+                                                             (line  109)
+* __fixunsxfsi:                          Soft float library routines.
+                                                             (line  102)
+* __fixunsxfti:                          Soft float library routines.
+                                                             (line  116)
+* __fixxfdi:                             Soft float library routines.
+                                                             (line   89)
+* __fixxfsi:                             Soft float library routines.
+                                                             (line   82)
+* __fixxfti:                             Soft float library routines.
+                                                             (line   95)
+* __floatdidf:                           Soft float library routines.
+                                                             (line  127)
+* __floatdisf:                           Soft float library routines.
+                                                             (line  126)
+* __floatditf:                           Soft float library routines.
+                                                             (line  128)
+* __floatdixf:                           Soft float library routines.
+                                                             (line  129)
+* __floatsidf:                           Soft float library routines.
+                                                             (line  121)
+* __floatsisf:                           Soft float library routines.
+                                                             (line  120)
+* __floatsitf:                           Soft float library routines.
+                                                             (line  122)
+* __floatsixf:                           Soft float library routines.
+                                                             (line  123)
+* __floattidf:                           Soft float library routines.
+                                                             (line  133)
+* __floattisf:                           Soft float library routines.
+                                                             (line  132)
+* __floattitf:                           Soft float library routines.
+                                                             (line  134)
+* __floattixf:                           Soft float library routines.
+                                                             (line  135)
+* __floatundidf:                         Soft float library routines.
+                                                             (line  145)
+* __floatundisf:                         Soft float library routines.
+                                                             (line  144)
+* __floatunditf:                         Soft float library routines.
+                                                             (line  146)
+* __floatundixf:                         Soft float library routines.
+                                                             (line  147)
+* __floatunsidf:                         Soft float library routines.
+                                                             (line  139)
+* __floatunsisf:                         Soft float library routines.
+                                                             (line  138)
+* __floatunsitf:                         Soft float library routines.
+                                                             (line  140)
+* __floatunsixf:                         Soft float library routines.
+                                                             (line  141)
+* __floatuntidf:                         Soft float library routines.
+                                                             (line  151)
+* __floatuntisf:                         Soft float library routines.
+                                                             (line  150)
+* __floatuntitf:                         Soft float library routines.
+                                                             (line  152)
+* __floatuntixf:                         Soft float library routines.
+                                                             (line  153)
+* __fractdadf:                           Fixed-point fractional library routines.
+                                                             (line  635)
+* __fractdadi:                           Fixed-point fractional library routines.
+                                                             (line  632)
+* __fractdadq:                           Fixed-point fractional library routines.
+                                                             (line  615)
+* __fractdaha2:                          Fixed-point fractional library routines.
+                                                             (line  616)
+* __fractdahi:                           Fixed-point fractional library routines.
+                                                             (line  630)
+* __fractdahq:                           Fixed-point fractional library routines.
+                                                             (line  613)
+* __fractdaqi:                           Fixed-point fractional library routines.
+                                                             (line  629)
+* __fractdaqq:                           Fixed-point fractional library routines.
+                                                             (line  612)
+* __fractdasa2:                          Fixed-point fractional library routines.
+                                                             (line  617)
+* __fractdasf:                           Fixed-point fractional library routines.
+                                                             (line  634)
+* __fractdasi:                           Fixed-point fractional library routines.
+                                                             (line  631)
+* __fractdasq:                           Fixed-point fractional library routines.
+                                                             (line  614)
+* __fractdata2:                          Fixed-point fractional library routines.
+                                                             (line  618)
+* __fractdati:                           Fixed-point fractional library routines.
+                                                             (line  633)
+* __fractdauda:                          Fixed-point fractional library routines.
+                                                             (line  626)
+* __fractdaudq:                          Fixed-point fractional library routines.
+                                                             (line  622)
+* __fractdauha:                          Fixed-point fractional library routines.
+                                                             (line  624)
+* __fractdauhq:                          Fixed-point fractional library routines.
+                                                             (line  620)
+* __fractdauqq:                          Fixed-point fractional library routines.
+                                                             (line  619)
+* __fractdausa:                          Fixed-point fractional library routines.
+                                                             (line  625)
+* __fractdausq:                          Fixed-point fractional library routines.
+                                                             (line  621)
+* __fractdauta:                          Fixed-point fractional library routines.
+                                                             (line  627)
+* __fractdfda:                           Fixed-point fractional library routines.
+                                                             (line 1024)
+* __fractdfdq:                           Fixed-point fractional library routines.
+                                                             (line 1021)
+* __fractdfha:                           Fixed-point fractional library routines.
+                                                             (line 1022)
+* __fractdfhq:                           Fixed-point fractional library routines.
+                                                             (line 1019)
+* __fractdfqq:                           Fixed-point fractional library routines.
+                                                             (line 1018)
+* __fractdfsa:                           Fixed-point fractional library routines.
+                                                             (line 1023)
+* __fractdfsq:                           Fixed-point fractional library routines.
+                                                             (line 1020)
+* __fractdfta:                           Fixed-point fractional library routines.
+                                                             (line 1025)
+* __fractdfuda:                          Fixed-point fractional library routines.
+                                                             (line 1032)
+* __fractdfudq:                          Fixed-point fractional library routines.
+                                                             (line 1029)
+* __fractdfuha:                          Fixed-point fractional library routines.
+                                                             (line 1030)
+* __fractdfuhq:                          Fixed-point fractional library routines.
+                                                             (line 1027)
+* __fractdfuqq:                          Fixed-point fractional library routines.
+                                                             (line 1026)
+* __fractdfusa:                          Fixed-point fractional library routines.
+                                                             (line 1031)
+* __fractdfusq:                          Fixed-point fractional library routines.
+                                                             (line 1028)
+* __fractdfuta:                          Fixed-point fractional library routines.
+                                                             (line 1033)
+* __fractdida:                           Fixed-point fractional library routines.
+                                                             (line  974)
+* __fractdidq:                           Fixed-point fractional library routines.
+                                                             (line  971)
+* __fractdiha:                           Fixed-point fractional library routines.
+                                                             (line  972)
+* __fractdihq:                           Fixed-point fractional library routines.
+                                                             (line  969)
+* __fractdiqq:                           Fixed-point fractional library routines.
+                                                             (line  968)
+* __fractdisa:                           Fixed-point fractional library routines.
+                                                             (line  973)
+* __fractdisq:                           Fixed-point fractional library routines.
+                                                             (line  970)
+* __fractdita:                           Fixed-point fractional library routines.
+                                                             (line  975)
+* __fractdiuda:                          Fixed-point fractional library routines.
+                                                             (line  982)
+* __fractdiudq:                          Fixed-point fractional library routines.
+                                                             (line  979)
+* __fractdiuha:                          Fixed-point fractional library routines.
+                                                             (line  980)
+* __fractdiuhq:                          Fixed-point fractional library routines.
+                                                             (line  977)
+* __fractdiuqq:                          Fixed-point fractional library routines.
+                                                             (line  976)
+* __fractdiusa:                          Fixed-point fractional library routines.
+                                                             (line  981)
+* __fractdiusq:                          Fixed-point fractional library routines.
+                                                             (line  978)
+* __fractdiuta:                          Fixed-point fractional library routines.
+                                                             (line  983)
+* __fractdqda:                           Fixed-point fractional library routines.
+                                                             (line  543)
+* __fractdqdf:                           Fixed-point fractional library routines.
+                                                             (line  565)
+* __fractdqdi:                           Fixed-point fractional library routines.
+                                                             (line  562)
+* __fractdqha:                           Fixed-point fractional library routines.
+                                                             (line  541)
+* __fractdqhi:                           Fixed-point fractional library routines.
+                                                             (line  560)
+* __fractdqhq2:                          Fixed-point fractional library routines.
+                                                             (line  539)
+* __fractdqqi:                           Fixed-point fractional library routines.
+                                                             (line  559)
+* __fractdqqq2:                          Fixed-point fractional library routines.
+                                                             (line  538)
+* __fractdqsa:                           Fixed-point fractional library routines.
+                                                             (line  542)
+* __fractdqsf:                           Fixed-point fractional library routines.
+                                                             (line  564)
+* __fractdqsi:                           Fixed-point fractional library routines.
+                                                             (line  561)
+* __fractdqsq2:                          Fixed-point fractional library routines.
+                                                             (line  540)
+* __fractdqta:                           Fixed-point fractional library routines.
+                                                             (line  544)
+* __fractdqti:                           Fixed-point fractional library routines.
+                                                             (line  563)
+* __fractdquda:                          Fixed-point fractional library routines.
+                                                             (line  555)
+* __fractdqudq:                          Fixed-point fractional library routines.
+                                                             (line  550)
+* __fractdquha:                          Fixed-point fractional library routines.
+                                                             (line  552)
+* __fractdquhq:                          Fixed-point fractional library routines.
+                                                             (line  547)
+* __fractdquqq:                          Fixed-point fractional library routines.
+                                                             (line  545)
+* __fractdqusa:                          Fixed-point fractional library routines.
+                                                             (line  554)
+* __fractdqusq:                          Fixed-point fractional library routines.
+                                                             (line  548)
+* __fractdquta:                          Fixed-point fractional library routines.
+                                                             (line  557)
+* __fracthada2:                          Fixed-point fractional library routines.
+                                                             (line  571)
+* __fracthadf:                           Fixed-point fractional library routines.
+                                                             (line  589)
+* __fracthadi:                           Fixed-point fractional library routines.
+                                                             (line  586)
+* __fracthadq:                           Fixed-point fractional library routines.
+                                                             (line  569)
+* __fracthahi:                           Fixed-point fractional library routines.
+                                                             (line  584)
+* __fracthahq:                           Fixed-point fractional library routines.
+                                                             (line  567)
+* __fracthaqi:                           Fixed-point fractional library routines.
+                                                             (line  583)
+* __fracthaqq:                           Fixed-point fractional library routines.
+                                                             (line  566)
+* __fracthasa2:                          Fixed-point fractional library routines.
+                                                             (line  570)
+* __fracthasf:                           Fixed-point fractional library routines.
+                                                             (line  588)
+* __fracthasi:                           Fixed-point fractional library routines.
+                                                             (line  585)
+* __fracthasq:                           Fixed-point fractional library routines.
+                                                             (line  568)
+* __fracthata2:                          Fixed-point fractional library routines.
+                                                             (line  572)
+* __fracthati:                           Fixed-point fractional library routines.
+                                                             (line  587)
+* __fracthauda:                          Fixed-point fractional library routines.
+                                                             (line  580)
+* __fracthaudq:                          Fixed-point fractional library routines.
+                                                             (line  576)
+* __fracthauha:                          Fixed-point fractional library routines.
+                                                             (line  578)
+* __fracthauhq:                          Fixed-point fractional library routines.
+                                                             (line  574)
+* __fracthauqq:                          Fixed-point fractional library routines.
+                                                             (line  573)
+* __fracthausa:                          Fixed-point fractional library routines.
+                                                             (line  579)
+* __fracthausq:                          Fixed-point fractional library routines.
+                                                             (line  575)
+* __fracthauta:                          Fixed-point fractional library routines.
+                                                             (line  581)
+* __fracthida:                           Fixed-point fractional library routines.
+                                                             (line  942)
+* __fracthidq:                           Fixed-point fractional library routines.
+                                                             (line  939)
+* __fracthiha:                           Fixed-point fractional library routines.
+                                                             (line  940)
+* __fracthihq:                           Fixed-point fractional library routines.
+                                                             (line  937)
+* __fracthiqq:                           Fixed-point fractional library routines.
+                                                             (line  936)
+* __fracthisa:                           Fixed-point fractional library routines.
+                                                             (line  941)
+* __fracthisq:                           Fixed-point fractional library routines.
+                                                             (line  938)
+* __fracthita:                           Fixed-point fractional library routines.
+                                                             (line  943)
+* __fracthiuda:                          Fixed-point fractional library routines.
+                                                             (line  950)
+* __fracthiudq:                          Fixed-point fractional library routines.
+                                                             (line  947)
+* __fracthiuha:                          Fixed-point fractional library routines.
+                                                             (line  948)
+* __fracthiuhq:                          Fixed-point fractional library routines.
+                                                             (line  945)
+* __fracthiuqq:                          Fixed-point fractional library routines.
+                                                             (line  944)
+* __fracthiusa:                          Fixed-point fractional library routines.
+                                                             (line  949)
+* __fracthiusq:                          Fixed-point fractional library routines.
+                                                             (line  946)
+* __fracthiuta:                          Fixed-point fractional library routines.
+                                                             (line  951)
+* __fracthqda:                           Fixed-point fractional library routines.
+                                                             (line  497)
+* __fracthqdf:                           Fixed-point fractional library routines.
+                                                             (line  513)
+* __fracthqdi:                           Fixed-point fractional library routines.
+                                                             (line  510)
+* __fracthqdq2:                          Fixed-point fractional library routines.
+                                                             (line  494)
+* __fracthqha:                           Fixed-point fractional library routines.
+                                                             (line  495)
+* __fracthqhi:                           Fixed-point fractional library routines.
+                                                             (line  508)
+* __fracthqqi:                           Fixed-point fractional library routines.
+                                                             (line  507)
+* __fracthqqq2:                          Fixed-point fractional library routines.
+                                                             (line  492)
+* __fracthqsa:                           Fixed-point fractional library routines.
+                                                             (line  496)
+* __fracthqsf:                           Fixed-point fractional library routines.
+                                                             (line  512)
+* __fracthqsi:                           Fixed-point fractional library routines.
+                                                             (line  509)
+* __fracthqsq2:                          Fixed-point fractional library routines.
+                                                             (line  493)
+* __fracthqta:                           Fixed-point fractional library routines.
+                                                             (line  498)
+* __fracthqti:                           Fixed-point fractional library routines.
+                                                             (line  511)
+* __fracthquda:                          Fixed-point fractional library routines.
+                                                             (line  505)
+* __fracthqudq:                          Fixed-point fractional library routines.
+                                                             (line  502)
+* __fracthquha:                          Fixed-point fractional library routines.
+                                                             (line  503)
+* __fracthquhq:                          Fixed-point fractional library routines.
+                                                             (line  500)
+* __fracthquqq:                          Fixed-point fractional library routines.
+                                                             (line  499)
+* __fracthqusa:                          Fixed-point fractional library routines.
+                                                             (line  504)
+* __fracthqusq:                          Fixed-point fractional library routines.
+                                                             (line  501)
+* __fracthquta:                          Fixed-point fractional library routines.
+                                                             (line  506)
+* __fractqida:                           Fixed-point fractional library routines.
+                                                             (line  924)
+* __fractqidq:                           Fixed-point fractional library routines.
+                                                             (line  921)
+* __fractqiha:                           Fixed-point fractional library routines.
+                                                             (line  922)
+* __fractqihq:                           Fixed-point fractional library routines.
+                                                             (line  919)
+* __fractqiqq:                           Fixed-point fractional library routines.
+                                                             (line  918)
+* __fractqisa:                           Fixed-point fractional library routines.
+                                                             (line  923)
+* __fractqisq:                           Fixed-point fractional library routines.
+                                                             (line  920)
+* __fractqita:                           Fixed-point fractional library routines.
+                                                             (line  925)
+* __fractqiuda:                          Fixed-point fractional library routines.
+                                                             (line  933)
+* __fractqiudq:                          Fixed-point fractional library routines.
+                                                             (line  929)
+* __fractqiuha:                          Fixed-point fractional library routines.
+                                                             (line  931)
+* __fractqiuhq:                          Fixed-point fractional library routines.
+                                                             (line  927)
+* __fractqiuqq:                          Fixed-point fractional library routines.
+                                                             (line  926)
+* __fractqiusa:                          Fixed-point fractional library routines.
+                                                             (line  932)
+* __fractqiusq:                          Fixed-point fractional library routines.
+                                                             (line  928)
+* __fractqiuta:                          Fixed-point fractional library routines.
+                                                             (line  934)
+* __fractqqda:                           Fixed-point fractional library routines.
+                                                             (line  473)
+* __fractqqdf:                           Fixed-point fractional library routines.
+                                                             (line  491)
+* __fractqqdi:                           Fixed-point fractional library routines.
+                                                             (line  488)
+* __fractqqdq2:                          Fixed-point fractional library routines.
+                                                             (line  470)
+* __fractqqha:                           Fixed-point fractional library routines.
+                                                             (line  471)
+* __fractqqhi:                           Fixed-point fractional library routines.
+                                                             (line  486)
+* __fractqqhq2:                          Fixed-point fractional library routines.
+                                                             (line  468)
+* __fractqqqi:                           Fixed-point fractional library routines.
+                                                             (line  485)
+* __fractqqsa:                           Fixed-point fractional library routines.
+                                                             (line  472)
+* __fractqqsf:                           Fixed-point fractional library routines.
+                                                             (line  490)
+* __fractqqsi:                           Fixed-point fractional library routines.
+                                                             (line  487)
+* __fractqqsq2:                          Fixed-point fractional library routines.
+                                                             (line  469)
+* __fractqqta:                           Fixed-point fractional library routines.
+                                                             (line  474)
+* __fractqqti:                           Fixed-point fractional library routines.
+                                                             (line  489)
+* __fractqquda:                          Fixed-point fractional library routines.
+                                                             (line  482)
+* __fractqqudq:                          Fixed-point fractional library routines.
+                                                             (line  478)
+* __fractqquha:                          Fixed-point fractional library routines.
+                                                             (line  480)
+* __fractqquhq:                          Fixed-point fractional library routines.
+                                                             (line  476)
+* __fractqquqq:                          Fixed-point fractional library routines.
+                                                             (line  475)
+* __fractqqusa:                          Fixed-point fractional library routines.
+                                                             (line  481)
+* __fractqqusq:                          Fixed-point fractional library routines.
+                                                             (line  477)
+* __fractqquta:                          Fixed-point fractional library routines.
+                                                             (line  483)
+* __fractsada2:                          Fixed-point fractional library routines.
+                                                             (line  595)
+* __fractsadf:                           Fixed-point fractional library routines.
+                                                             (line  611)
+* __fractsadi:                           Fixed-point fractional library routines.
+                                                             (line  608)
+* __fractsadq:                           Fixed-point fractional library routines.
+                                                             (line  593)
+* __fractsaha2:                          Fixed-point fractional library routines.
+                                                             (line  594)
+* __fractsahi:                           Fixed-point fractional library routines.
+                                                             (line  606)
+* __fractsahq:                           Fixed-point fractional library routines.
+                                                             (line  591)
+* __fractsaqi:                           Fixed-point fractional library routines.
+                                                             (line  605)
+* __fractsaqq:                           Fixed-point fractional library routines.
+                                                             (line  590)
+* __fractsasf:                           Fixed-point fractional library routines.
+                                                             (line  610)
+* __fractsasi:                           Fixed-point fractional library routines.
+                                                             (line  607)
+* __fractsasq:                           Fixed-point fractional library routines.
+                                                             (line  592)
+* __fractsata2:                          Fixed-point fractional library routines.
+                                                             (line  596)
+* __fractsati:                           Fixed-point fractional library routines.
+                                                             (line  609)
+* __fractsauda:                          Fixed-point fractional library routines.
+                                                             (line  603)
+* __fractsaudq:                          Fixed-point fractional library routines.
+                                                             (line  600)
+* __fractsauha:                          Fixed-point fractional library routines.
+                                                             (line  601)
+* __fractsauhq:                          Fixed-point fractional library routines.
+                                                             (line  598)
+* __fractsauqq:                          Fixed-point fractional library routines.
+                                                             (line  597)
+* __fractsausa:                          Fixed-point fractional library routines.
+                                                             (line  602)
+* __fractsausq:                          Fixed-point fractional library routines.
+                                                             (line  599)
+* __fractsauta:                          Fixed-point fractional library routines.
+                                                             (line  604)
+* __fractsfda:                           Fixed-point fractional library routines.
+                                                             (line 1008)
+* __fractsfdq:                           Fixed-point fractional library routines.
+                                                             (line 1005)
+* __fractsfha:                           Fixed-point fractional library routines.
+                                                             (line 1006)
+* __fractsfhq:                           Fixed-point fractional library routines.
+                                                             (line 1003)
+* __fractsfqq:                           Fixed-point fractional library routines.
+                                                             (line 1002)
+* __fractsfsa:                           Fixed-point fractional library routines.
+                                                             (line 1007)
+* __fractsfsq:                           Fixed-point fractional library routines.
+                                                             (line 1004)
+* __fractsfta:                           Fixed-point fractional library routines.
+                                                             (line 1009)
+* __fractsfuda:                          Fixed-point fractional library routines.
+                                                             (line 1016)
+* __fractsfudq:                          Fixed-point fractional library routines.
+                                                             (line 1013)
+* __fractsfuha:                          Fixed-point fractional library routines.
+                                                             (line 1014)
+* __fractsfuhq:                          Fixed-point fractional library routines.
+                                                             (line 1011)
+* __fractsfuqq:                          Fixed-point fractional library routines.
+                                                             (line 1010)
+* __fractsfusa:                          Fixed-point fractional library routines.
+                                                             (line 1015)
+* __fractsfusq:                          Fixed-point fractional library routines.
+                                                             (line 1012)
+* __fractsfuta:                          Fixed-point fractional library routines.
+                                                             (line 1017)
+* __fractsida:                           Fixed-point fractional library routines.
+                                                             (line  958)
+* __fractsidq:                           Fixed-point fractional library routines.
+                                                             (line  955)
+* __fractsiha:                           Fixed-point fractional library routines.
+                                                             (line  956)
+* __fractsihq:                           Fixed-point fractional library routines.
+                                                             (line  953)
+* __fractsiqq:                           Fixed-point fractional library routines.
+                                                             (line  952)
+* __fractsisa:                           Fixed-point fractional library routines.
+                                                             (line  957)
+* __fractsisq:                           Fixed-point fractional library routines.
+                                                             (line  954)
+* __fractsita:                           Fixed-point fractional library routines.
+                                                             (line  959)
+* __fractsiuda:                          Fixed-point fractional library routines.
+                                                             (line  966)
+* __fractsiudq:                          Fixed-point fractional library routines.
+                                                             (line  963)
+* __fractsiuha:                          Fixed-point fractional library routines.
+                                                             (line  964)
+* __fractsiuhq:                          Fixed-point fractional library routines.
+                                                             (line  961)
+* __fractsiuqq:                          Fixed-point fractional library routines.
+                                                             (line  960)
+* __fractsiusa:                          Fixed-point fractional library routines.
+                                                             (line  965)
+* __fractsiusq:                          Fixed-point fractional library routines.
+                                                             (line  962)
+* __fractsiuta:                          Fixed-point fractional library routines.
+                                                             (line  967)
+* __fractsqda:                           Fixed-point fractional library routines.
+                                                             (line  519)
+* __fractsqdf:                           Fixed-point fractional library routines.
+                                                             (line  537)
+* __fractsqdi:                           Fixed-point fractional library routines.
+                                                             (line  534)
+* __fractsqdq2:                          Fixed-point fractional library routines.
+                                                             (line  516)
+* __fractsqha:                           Fixed-point fractional library routines.
+                                                             (line  517)
+* __fractsqhi:                           Fixed-point fractional library routines.
+                                                             (line  532)
+* __fractsqhq2:                          Fixed-point fractional library routines.
+                                                             (line  515)
+* __fractsqqi:                           Fixed-point fractional library routines.
+                                                             (line  531)
+* __fractsqqq2:                          Fixed-point fractional library routines.
+                                                             (line  514)
+* __fractsqsa:                           Fixed-point fractional library routines.
+                                                             (line  518)
+* __fractsqsf:                           Fixed-point fractional library routines.
+                                                             (line  536)
+* __fractsqsi:                           Fixed-point fractional library routines.
+                                                             (line  533)
+* __fractsqta:                           Fixed-point fractional library routines.
+                                                             (line  520)
+* __fractsqti:                           Fixed-point fractional library routines.
+                                                             (line  535)
+* __fractsquda:                          Fixed-point fractional library routines.
+                                                             (line  528)
+* __fractsqudq:                          Fixed-point fractional library routines.
+                                                             (line  524)
+* __fractsquha:                          Fixed-point fractional library routines.
+                                                             (line  526)
+* __fractsquhq:                          Fixed-point fractional library routines.
+                                                             (line  522)
+* __fractsquqq:                          Fixed-point fractional library routines.
+                                                             (line  521)
+* __fractsqusa:                          Fixed-point fractional library routines.
+                                                             (line  527)
+* __fractsqusq:                          Fixed-point fractional library routines.
+                                                             (line  523)
+* __fractsquta:                          Fixed-point fractional library routines.
+                                                             (line  529)
+* __fracttada2:                          Fixed-point fractional library routines.
+                                                             (line  642)
+* __fracttadf:                           Fixed-point fractional library routines.
+                                                             (line  663)
+* __fracttadi:                           Fixed-point fractional library routines.
+                                                             (line  660)
+* __fracttadq:                           Fixed-point fractional library routines.
+                                                             (line  639)
+* __fracttaha2:                          Fixed-point fractional library routines.
+                                                             (line  640)
+* __fracttahi:                           Fixed-point fractional library routines.
+                                                             (line  658)
+* __fracttahq:                           Fixed-point fractional library routines.
+                                                             (line  637)
+* __fracttaqi:                           Fixed-point fractional library routines.
+                                                             (line  657)
+* __fracttaqq:                           Fixed-point fractional library routines.
+                                                             (line  636)
+* __fracttasa2:                          Fixed-point fractional library routines.
+                                                             (line  641)
+* __fracttasf:                           Fixed-point fractional library routines.
+                                                             (line  662)
+* __fracttasi:                           Fixed-point fractional library routines.
+                                                             (line  659)
+* __fracttasq:                           Fixed-point fractional library routines.
+                                                             (line  638)
+* __fracttati:                           Fixed-point fractional library routines.
+                                                             (line  661)
+* __fracttauda:                          Fixed-point fractional library routines.
+                                                             (line  653)
+* __fracttaudq:                          Fixed-point fractional library routines.
+                                                             (line  648)
+* __fracttauha:                          Fixed-point fractional library routines.
+                                                             (line  650)
+* __fracttauhq:                          Fixed-point fractional library routines.
+                                                             (line  645)
+* __fracttauqq:                          Fixed-point fractional library routines.
+                                                             (line  643)
+* __fracttausa:                          Fixed-point fractional library routines.
+                                                             (line  652)
+* __fracttausq:                          Fixed-point fractional library routines.
+                                                             (line  646)
+* __fracttauta:                          Fixed-point fractional library routines.
+                                                             (line  655)
+* __fracttida:                           Fixed-point fractional library routines.
+                                                             (line  990)
+* __fracttidq:                           Fixed-point fractional library routines.
+                                                             (line  987)
+* __fracttiha:                           Fixed-point fractional library routines.
+                                                             (line  988)
+* __fracttihq:                           Fixed-point fractional library routines.
+                                                             (line  985)
+* __fracttiqq:                           Fixed-point fractional library routines.
+                                                             (line  984)
+* __fracttisa:                           Fixed-point fractional library routines.
+                                                             (line  989)
+* __fracttisq:                           Fixed-point fractional library routines.
+                                                             (line  986)
+* __fracttita:                           Fixed-point fractional library routines.
+                                                             (line  991)
+* __fracttiuda:                          Fixed-point fractional library routines.
+                                                             (line  999)
+* __fracttiudq:                          Fixed-point fractional library routines.
+                                                             (line  995)
+* __fracttiuha:                          Fixed-point fractional library routines.
+                                                             (line  997)
+* __fracttiuhq:                          Fixed-point fractional library routines.
+                                                             (line  993)
+* __fracttiuqq:                          Fixed-point fractional library routines.
+                                                             (line  992)
+* __fracttiusa:                          Fixed-point fractional library routines.
+                                                             (line  998)
+* __fracttiusq:                          Fixed-point fractional library routines.
+                                                             (line  994)
+* __fracttiuta:                          Fixed-point fractional library routines.
+                                                             (line 1000)
+* __fractudada:                          Fixed-point fractional library routines.
+                                                             (line  857)
+* __fractudadf:                          Fixed-point fractional library routines.
+                                                             (line  880)
+* __fractudadi:                          Fixed-point fractional library routines.
+                                                             (line  877)
+* __fractudadq:                          Fixed-point fractional library routines.
+                                                             (line  853)
+* __fractudaha:                          Fixed-point fractional library routines.
+                                                             (line  855)
+* __fractudahi:                          Fixed-point fractional library routines.
+                                                             (line  875)
+* __fractudahq:                          Fixed-point fractional library routines.
+                                                             (line  851)
+* __fractudaqi:                          Fixed-point fractional library routines.
+                                                             (line  874)
+* __fractudaqq:                          Fixed-point fractional library routines.
+                                                             (line  850)
+* __fractudasa:                          Fixed-point fractional library routines.
+                                                             (line  856)
+* __fractudasf:                          Fixed-point fractional library routines.
+                                                             (line  879)
+* __fractudasi:                          Fixed-point fractional library routines.
+                                                             (line  876)
+* __fractudasq:                          Fixed-point fractional library routines.
+                                                             (line  852)
+* __fractudata:                          Fixed-point fractional library routines.
+                                                             (line  858)
+* __fractudati:                          Fixed-point fractional library routines.
+                                                             (line  878)
+* __fractudaudq:                         Fixed-point fractional library routines.
+                                                             (line  866)
+* __fractudauha2:                        Fixed-point fractional library routines.
+                                                             (line  868)
+* __fractudauhq:                         Fixed-point fractional library routines.
+                                                             (line  862)
+* __fractudauqq:                         Fixed-point fractional library routines.
+                                                             (line  860)
+* __fractudausa2:                        Fixed-point fractional library routines.
+                                                             (line  870)
+* __fractudausq:                         Fixed-point fractional library routines.
+                                                             (line  864)
+* __fractudauta2:                        Fixed-point fractional library routines.
+                                                             (line  872)
+* __fractudqda:                          Fixed-point fractional library routines.
+                                                             (line  764)
+* __fractudqdf:                          Fixed-point fractional library routines.
+                                                             (line  790)
+* __fractudqdi:                          Fixed-point fractional library routines.
+                                                             (line  786)
+* __fractudqdq:                          Fixed-point fractional library routines.
+                                                             (line  759)
+* __fractudqha:                          Fixed-point fractional library routines.
+                                                             (line  761)
+* __fractudqhi:                          Fixed-point fractional library routines.
+                                                             (line  784)
+* __fractudqhq:                          Fixed-point fractional library routines.
+                                                             (line  756)
+* __fractudqqi:                          Fixed-point fractional library routines.
+                                                             (line  782)
+* __fractudqqq:                          Fixed-point fractional library routines.
+                                                             (line  754)
+* __fractudqsa:                          Fixed-point fractional library routines.
+                                                             (line  763)
+* __fractudqsf:                          Fixed-point fractional library routines.
+                                                             (line  789)
+* __fractudqsi:                          Fixed-point fractional library routines.
+                                                             (line  785)
+* __fractudqsq:                          Fixed-point fractional library routines.
+                                                             (line  757)
+* __fractudqta:                          Fixed-point fractional library routines.
+                                                             (line  766)
+* __fractudqti:                          Fixed-point fractional library routines.
+                                                             (line  787)
+* __fractudquda:                         Fixed-point fractional library routines.
+                                                             (line  778)
+* __fractudquha:                         Fixed-point fractional library routines.
+                                                             (line  774)
+* __fractudquhq2:                        Fixed-point fractional library routines.
+                                                             (line  770)
+* __fractudquqq2:                        Fixed-point fractional library routines.
+                                                             (line  768)
+* __fractudqusa:                         Fixed-point fractional library routines.
+                                                             (line  776)
+* __fractudqusq2:                        Fixed-point fractional library routines.
+                                                             (line  772)
+* __fractudquta:                         Fixed-point fractional library routines.
+                                                             (line  780)
+* __fractuhada:                          Fixed-point fractional library routines.
+                                                             (line  798)
+* __fractuhadf:                          Fixed-point fractional library routines.
+                                                             (line  821)
+* __fractuhadi:                          Fixed-point fractional library routines.
+                                                             (line  818)
+* __fractuhadq:                          Fixed-point fractional library routines.
+                                                             (line  794)
+* __fractuhaha:                          Fixed-point fractional library routines.
+                                                             (line  796)
+* __fractuhahi:                          Fixed-point fractional library routines.
+                                                             (line  816)
+* __fractuhahq:                          Fixed-point fractional library routines.
+                                                             (line  792)
+* __fractuhaqi:                          Fixed-point fractional library routines.
+                                                             (line  815)
+* __fractuhaqq:                          Fixed-point fractional library routines.
+                                                             (line  791)
+* __fractuhasa:                          Fixed-point fractional library routines.
+                                                             (line  797)
+* __fractuhasf:                          Fixed-point fractional library routines.
+                                                             (line  820)
+* __fractuhasi:                          Fixed-point fractional library routines.
+                                                             (line  817)
+* __fractuhasq:                          Fixed-point fractional library routines.
+                                                             (line  793)
+* __fractuhata:                          Fixed-point fractional library routines.
+                                                             (line  799)
+* __fractuhati:                          Fixed-point fractional library routines.
+                                                             (line  819)
+* __fractuhauda2:                        Fixed-point fractional library routines.
+                                                             (line  811)
+* __fractuhaudq:                         Fixed-point fractional library routines.
+                                                             (line  807)
+* __fractuhauhq:                         Fixed-point fractional library routines.
+                                                             (line  803)
+* __fractuhauqq:                         Fixed-point fractional library routines.
+                                                             (line  801)
+* __fractuhausa2:                        Fixed-point fractional library routines.
+                                                             (line  809)
+* __fractuhausq:                         Fixed-point fractional library routines.
+                                                             (line  805)
+* __fractuhauta2:                        Fixed-point fractional library routines.
+                                                             (line  813)
+* __fractuhqda:                          Fixed-point fractional library routines.
+                                                             (line  701)
+* __fractuhqdf:                          Fixed-point fractional library routines.
+                                                             (line  722)
+* __fractuhqdi:                          Fixed-point fractional library routines.
+                                                             (line  719)
+* __fractuhqdq:                          Fixed-point fractional library routines.
+                                                             (line  698)
+* __fractuhqha:                          Fixed-point fractional library routines.
+                                                             (line  699)
+* __fractuhqhi:                          Fixed-point fractional library routines.
+                                                             (line  717)
+* __fractuhqhq:                          Fixed-point fractional library routines.
+                                                             (line  696)
+* __fractuhqqi:                          Fixed-point fractional library routines.
+                                                             (line  716)
+* __fractuhqqq:                          Fixed-point fractional library routines.
+                                                             (line  695)
+* __fractuhqsa:                          Fixed-point fractional library routines.
+                                                             (line  700)
+* __fractuhqsf:                          Fixed-point fractional library routines.
+                                                             (line  721)
+* __fractuhqsi:                          Fixed-point fractional library routines.
+                                                             (line  718)
+* __fractuhqsq:                          Fixed-point fractional library routines.
+                                                             (line  697)
+* __fractuhqta:                          Fixed-point fractional library routines.
+                                                             (line  702)
+* __fractuhqti:                          Fixed-point fractional library routines.
+                                                             (line  720)
+* __fractuhquda:                         Fixed-point fractional library routines.
+                                                             (line  712)
+* __fractuhqudq2:                        Fixed-point fractional library routines.
+                                                             (line  707)
+* __fractuhquha:                         Fixed-point fractional library routines.
+                                                             (line  709)
+* __fractuhquqq2:                        Fixed-point fractional library routines.
+                                                             (line  703)
+* __fractuhqusa:                         Fixed-point fractional library routines.
+                                                             (line  711)
+* __fractuhqusq2:                        Fixed-point fractional library routines.
+                                                             (line  705)
+* __fractuhquta:                         Fixed-point fractional library routines.
+                                                             (line  714)
+* __fractunsdadi:                        Fixed-point fractional library routines.
+                                                             (line 1554)
+* __fractunsdahi:                        Fixed-point fractional library routines.
+                                                             (line 1552)
+* __fractunsdaqi:                        Fixed-point fractional library routines.
+                                                             (line 1551)
+* __fractunsdasi:                        Fixed-point fractional library routines.
+                                                             (line 1553)
+* __fractunsdati:                        Fixed-point fractional library routines.
+                                                             (line 1555)
+* __fractunsdida:                        Fixed-point fractional library routines.
+                                                             (line 1706)
+* __fractunsdidq:                        Fixed-point fractional library routines.
+                                                             (line 1703)
+* __fractunsdiha:                        Fixed-point fractional library routines.
+                                                             (line 1704)
+* __fractunsdihq:                        Fixed-point fractional library routines.
+                                                             (line 1701)
+* __fractunsdiqq:                        Fixed-point fractional library routines.
+                                                             (line 1700)
+* __fractunsdisa:                        Fixed-point fractional library routines.
+                                                             (line 1705)
+* __fractunsdisq:                        Fixed-point fractional library routines.
+                                                             (line 1702)
+* __fractunsdita:                        Fixed-point fractional library routines.
+                                                             (line 1707)
+* __fractunsdiuda:                       Fixed-point fractional library routines.
+                                                             (line 1718)
+* __fractunsdiudq:                       Fixed-point fractional library routines.
+                                                             (line 1713)
+* __fractunsdiuha:                       Fixed-point fractional library routines.
+                                                             (line 1715)
+* __fractunsdiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1710)
+* __fractunsdiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1708)
+* __fractunsdiusa:                       Fixed-point fractional library routines.
+                                                             (line 1717)
+* __fractunsdiusq:                       Fixed-point fractional library routines.
+                                                             (line 1711)
+* __fractunsdiuta:                       Fixed-point fractional library routines.
+                                                             (line 1720)
+* __fractunsdqdi:                        Fixed-point fractional library routines.
+                                                             (line 1538)
+* __fractunsdqhi:                        Fixed-point fractional library routines.
+                                                             (line 1536)
+* __fractunsdqqi:                        Fixed-point fractional library routines.
+                                                             (line 1535)
+* __fractunsdqsi:                        Fixed-point fractional library routines.
+                                                             (line 1537)
+* __fractunsdqti:                        Fixed-point fractional library routines.
+                                                             (line 1539)
+* __fractunshadi:                        Fixed-point fractional library routines.
+                                                             (line 1544)
+* __fractunshahi:                        Fixed-point fractional library routines.
+                                                             (line 1542)
+* __fractunshaqi:                        Fixed-point fractional library routines.
+                                                             (line 1541)
+* __fractunshasi:                        Fixed-point fractional library routines.
+                                                             (line 1543)
+* __fractunshati:                        Fixed-point fractional library routines.
+                                                             (line 1545)
+* __fractunshida:                        Fixed-point fractional library routines.
+                                                             (line 1662)
+* __fractunshidq:                        Fixed-point fractional library routines.
+                                                             (line 1659)
+* __fractunshiha:                        Fixed-point fractional library routines.
+                                                             (line 1660)
+* __fractunshihq:                        Fixed-point fractional library routines.
+                                                             (line 1657)
+* __fractunshiqq:                        Fixed-point fractional library routines.
+                                                             (line 1656)
+* __fractunshisa:                        Fixed-point fractional library routines.
+                                                             (line 1661)
+* __fractunshisq:                        Fixed-point fractional library routines.
+                                                             (line 1658)
+* __fractunshita:                        Fixed-point fractional library routines.
+                                                             (line 1663)
+* __fractunshiuda:                       Fixed-point fractional library routines.
+                                                             (line 1674)
+* __fractunshiudq:                       Fixed-point fractional library routines.
+                                                             (line 1669)
+* __fractunshiuha:                       Fixed-point fractional library routines.
+                                                             (line 1671)
+* __fractunshiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1666)
+* __fractunshiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1664)
+* __fractunshiusa:                       Fixed-point fractional library routines.
+                                                             (line 1673)
+* __fractunshiusq:                       Fixed-point fractional library routines.
+                                                             (line 1667)
+* __fractunshiuta:                       Fixed-point fractional library routines.
+                                                             (line 1676)
+* __fractunshqdi:                        Fixed-point fractional library routines.
+                                                             (line 1528)
+* __fractunshqhi:                        Fixed-point fractional library routines.
+                                                             (line 1526)
+* __fractunshqqi:                        Fixed-point fractional library routines.
+                                                             (line 1525)
+* __fractunshqsi:                        Fixed-point fractional library routines.
+                                                             (line 1527)
+* __fractunshqti:                        Fixed-point fractional library routines.
+                                                             (line 1529)
+* __fractunsqida:                        Fixed-point fractional library routines.
+                                                             (line 1640)
+* __fractunsqidq:                        Fixed-point fractional library routines.
+                                                             (line 1637)
+* __fractunsqiha:                        Fixed-point fractional library routines.
+                                                             (line 1638)
+* __fractunsqihq:                        Fixed-point fractional library routines.
+                                                             (line 1635)
+* __fractunsqiqq:                        Fixed-point fractional library routines.
+                                                             (line 1634)
+* __fractunsqisa:                        Fixed-point fractional library routines.
+                                                             (line 1639)
+* __fractunsqisq:                        Fixed-point fractional library routines.
+                                                             (line 1636)
+* __fractunsqita:                        Fixed-point fractional library routines.
+                                                             (line 1641)
+* __fractunsqiuda:                       Fixed-point fractional library routines.
+                                                             (line 1652)
+* __fractunsqiudq:                       Fixed-point fractional library routines.
+                                                             (line 1647)
+* __fractunsqiuha:                       Fixed-point fractional library routines.
+                                                             (line 1649)
+* __fractunsqiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1644)
+* __fractunsqiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1642)
+* __fractunsqiusa:                       Fixed-point fractional library routines.
+                                                             (line 1651)
+* __fractunsqiusq:                       Fixed-point fractional library routines.
+                                                             (line 1645)
+* __fractunsqiuta:                       Fixed-point fractional library routines.
+                                                             (line 1654)
+* __fractunsqqdi:                        Fixed-point fractional library routines.
+                                                             (line 1523)
+* __fractunsqqhi:                        Fixed-point fractional library routines.
+                                                             (line 1521)
+* __fractunsqqqi:                        Fixed-point fractional library routines.
+                                                             (line 1520)
+* __fractunsqqsi:                        Fixed-point fractional library routines.
+                                                             (line 1522)
+* __fractunsqqti:                        Fixed-point fractional library routines.
+                                                             (line 1524)
+* __fractunssadi:                        Fixed-point fractional library routines.
+                                                             (line 1549)
+* __fractunssahi:                        Fixed-point fractional library routines.
+                                                             (line 1547)
+* __fractunssaqi:                        Fixed-point fractional library routines.
+                                                             (line 1546)
+* __fractunssasi:                        Fixed-point fractional library routines.
+                                                             (line 1548)
+* __fractunssati:                        Fixed-point fractional library routines.
+                                                             (line 1550)
+* __fractunssida:                        Fixed-point fractional library routines.
+                                                             (line 1684)
+* __fractunssidq:                        Fixed-point fractional library routines.
+                                                             (line 1681)
+* __fractunssiha:                        Fixed-point fractional library routines.
+                                                             (line 1682)
+* __fractunssihq:                        Fixed-point fractional library routines.
+                                                             (line 1679)
+* __fractunssiqq:                        Fixed-point fractional library routines.
+                                                             (line 1678)
+* __fractunssisa:                        Fixed-point fractional library routines.
+                                                             (line 1683)
+* __fractunssisq:                        Fixed-point fractional library routines.
+                                                             (line 1680)
+* __fractunssita:                        Fixed-point fractional library routines.
+                                                             (line 1685)
+* __fractunssiuda:                       Fixed-point fractional library routines.
+                                                             (line 1696)
+* __fractunssiudq:                       Fixed-point fractional library routines.
+                                                             (line 1691)
+* __fractunssiuha:                       Fixed-point fractional library routines.
+                                                             (line 1693)
+* __fractunssiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1688)
+* __fractunssiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1686)
+* __fractunssiusa:                       Fixed-point fractional library routines.
+                                                             (line 1695)
+* __fractunssiusq:                       Fixed-point fractional library routines.
+                                                             (line 1689)
+* __fractunssiuta:                       Fixed-point fractional library routines.
+                                                             (line 1698)
+* __fractunssqdi:                        Fixed-point fractional library routines.
+                                                             (line 1533)
+* __fractunssqhi:                        Fixed-point fractional library routines.
+                                                             (line 1531)
+* __fractunssqqi:                        Fixed-point fractional library routines.
+                                                             (line 1530)
+* __fractunssqsi:                        Fixed-point fractional library routines.
+                                                             (line 1532)
+* __fractunssqti:                        Fixed-point fractional library routines.
+                                                             (line 1534)
+* __fractunstadi:                        Fixed-point fractional library routines.
+                                                             (line 1559)
+* __fractunstahi:                        Fixed-point fractional library routines.
+                                                             (line 1557)
+* __fractunstaqi:                        Fixed-point fractional library routines.
+                                                             (line 1556)
+* __fractunstasi:                        Fixed-point fractional library routines.
+                                                             (line 1558)
+* __fractunstati:                        Fixed-point fractional library routines.
+                                                             (line 1560)
+* __fractunstida:                        Fixed-point fractional library routines.
+                                                             (line 1729)
+* __fractunstidq:                        Fixed-point fractional library routines.
+                                                             (line 1725)
+* __fractunstiha:                        Fixed-point fractional library routines.
+                                                             (line 1727)
+* __fractunstihq:                        Fixed-point fractional library routines.
+                                                             (line 1723)
+* __fractunstiqq:                        Fixed-point fractional library routines.
+                                                             (line 1722)
+* __fractunstisa:                        Fixed-point fractional library routines.
+                                                             (line 1728)
+* __fractunstisq:                        Fixed-point fractional library routines.
+                                                             (line 1724)
+* __fractunstita:                        Fixed-point fractional library routines.
+                                                             (line 1730)
+* __fractunstiuda:                       Fixed-point fractional library routines.
+                                                             (line 1744)
+* __fractunstiudq:                       Fixed-point fractional library routines.
+                                                             (line 1738)
+* __fractunstiuha:                       Fixed-point fractional library routines.
+                                                             (line 1740)
+* __fractunstiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1734)
+* __fractunstiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1732)
+* __fractunstiusa:                       Fixed-point fractional library routines.
+                                                             (line 1742)
+* __fractunstiusq:                       Fixed-point fractional library routines.
+                                                             (line 1736)
+* __fractunstiuta:                       Fixed-point fractional library routines.
+                                                             (line 1746)
+* __fractunsudadi:                       Fixed-point fractional library routines.
+                                                             (line 1620)
+* __fractunsudahi:                       Fixed-point fractional library routines.
+                                                             (line 1616)
+* __fractunsudaqi:                       Fixed-point fractional library routines.
+                                                             (line 1614)
+* __fractunsudasi:                       Fixed-point fractional library routines.
+                                                             (line 1618)
+* __fractunsudati:                       Fixed-point fractional library routines.
+                                                             (line 1622)
+* __fractunsudqdi:                       Fixed-point fractional library routines.
+                                                             (line 1594)
+* __fractunsudqhi:                       Fixed-point fractional library routines.
+                                                             (line 1590)
+* __fractunsudqqi:                       Fixed-point fractional library routines.
+                                                             (line 1588)
+* __fractunsudqsi:                       Fixed-point fractional library routines.
+                                                             (line 1592)
+* __fractunsudqti:                       Fixed-point fractional library routines.
+                                                             (line 1596)
+* __fractunsuhadi:                       Fixed-point fractional library routines.
+                                                             (line 1604)
+* __fractunsuhahi:                       Fixed-point fractional library routines.
+                                                             (line 1600)
+* __fractunsuhaqi:                       Fixed-point fractional library routines.
+                                                             (line 1598)
+* __fractunsuhasi:                       Fixed-point fractional library routines.
+                                                             (line 1602)
+* __fractunsuhati:                       Fixed-point fractional library routines.
+                                                             (line 1606)
+* __fractunsuhqdi:                       Fixed-point fractional library routines.
+                                                             (line 1575)
+* __fractunsuhqhi:                       Fixed-point fractional library routines.
+                                                             (line 1573)
+* __fractunsuhqqi:                       Fixed-point fractional library routines.
+                                                             (line 1572)
+* __fractunsuhqsi:                       Fixed-point fractional library routines.
+                                                             (line 1574)
+* __fractunsuhqti:                       Fixed-point fractional library routines.
+                                                             (line 1576)
+* __fractunsuqqdi:                       Fixed-point fractional library routines.
+                                                             (line 1568)
+* __fractunsuqqhi:                       Fixed-point fractional library routines.
+                                                             (line 1564)
+* __fractunsuqqqi:                       Fixed-point fractional library routines.
+                                                             (line 1562)
+* __fractunsuqqsi:                       Fixed-point fractional library routines.
+                                                             (line 1566)
+* __fractunsuqqti:                       Fixed-point fractional library routines.
+                                                             (line 1570)
+* __fractunsusadi:                       Fixed-point fractional library routines.
+                                                             (line 1611)
+* __fractunsusahi:                       Fixed-point fractional library routines.
+                                                             (line 1609)
+* __fractunsusaqi:                       Fixed-point fractional library routines.
+                                                             (line 1608)
+* __fractunsusasi:                       Fixed-point fractional library routines.
+                                                             (line 1610)
+* __fractunsusati:                       Fixed-point fractional library routines.
+                                                             (line 1612)
+* __fractunsusqdi:                       Fixed-point fractional library routines.
+                                                             (line 1584)
+* __fractunsusqhi:                       Fixed-point fractional library routines.
+                                                             (line 1580)
+* __fractunsusqqi:                       Fixed-point fractional library routines.
+                                                             (line 1578)
+* __fractunsusqsi:                       Fixed-point fractional library routines.
+                                                             (line 1582)
+* __fractunsusqti:                       Fixed-point fractional library routines.
+                                                             (line 1586)
+* __fractunsutadi:                       Fixed-point fractional library routines.
+                                                             (line 1630)
+* __fractunsutahi:                       Fixed-point fractional library routines.
+                                                             (line 1626)
+* __fractunsutaqi:                       Fixed-point fractional library routines.
+                                                             (line 1624)
+* __fractunsutasi:                       Fixed-point fractional library routines.
+                                                             (line 1628)
+* __fractunsutati:                       Fixed-point fractional library routines.
+                                                             (line 1632)
+* __fractuqqda:                          Fixed-point fractional library routines.
+                                                             (line  671)
+* __fractuqqdf:                          Fixed-point fractional library routines.
+                                                             (line  694)
+* __fractuqqdi:                          Fixed-point fractional library routines.
+                                                             (line  691)
+* __fractuqqdq:                          Fixed-point fractional library routines.
+                                                             (line  667)
+* __fractuqqha:                          Fixed-point fractional library routines.
+                                                             (line  669)
+* __fractuqqhi:                          Fixed-point fractional library routines.
+                                                             (line  689)
+* __fractuqqhq:                          Fixed-point fractional library routines.
+                                                             (line  665)
+* __fractuqqqi:                          Fixed-point fractional library routines.
+                                                             (line  688)
+* __fractuqqqq:                          Fixed-point fractional library routines.
+                                                             (line  664)
+* __fractuqqsa:                          Fixed-point fractional library routines.
+                                                             (line  670)
+* __fractuqqsf:                          Fixed-point fractional library routines.
+                                                             (line  693)
+* __fractuqqsi:                          Fixed-point fractional library routines.
+                                                             (line  690)
+* __fractuqqsq:                          Fixed-point fractional library routines.
+                                                             (line  666)
+* __fractuqqta:                          Fixed-point fractional library routines.
+                                                             (line  672)
+* __fractuqqti:                          Fixed-point fractional library routines.
+                                                             (line  692)
+* __fractuqquda:                         Fixed-point fractional library routines.
+                                                             (line  684)
+* __fractuqqudq2:                        Fixed-point fractional library routines.
+                                                             (line  678)
+* __fractuqquha:                         Fixed-point fractional library routines.
+                                                             (line  680)
+* __fractuqquhq2:                        Fixed-point fractional library routines.
+                                                             (line  674)
+* __fractuqqusa:                         Fixed-point fractional library routines.
+                                                             (line  682)
+* __fractuqqusq2:                        Fixed-point fractional library routines.
+                                                             (line  676)
+* __fractuqquta:                         Fixed-point fractional library routines.
+                                                             (line  686)
+* __fractusada:                          Fixed-point fractional library routines.
+                                                             (line  828)
+* __fractusadf:                          Fixed-point fractional library routines.
+                                                             (line  849)
+* __fractusadi:                          Fixed-point fractional library routines.
+                                                             (line  846)
+* __fractusadq:                          Fixed-point fractional library routines.
+                                                             (line  825)
+* __fractusaha:                          Fixed-point fractional library routines.
+                                                             (line  826)
+* __fractusahi:                          Fixed-point fractional library routines.
+                                                             (line  844)
+* __fractusahq:                          Fixed-point fractional library routines.
+                                                             (line  823)
+* __fractusaqi:                          Fixed-point fractional library routines.
+                                                             (line  843)
+* __fractusaqq:                          Fixed-point fractional library routines.
+                                                             (line  822)
+* __fractusasa:                          Fixed-point fractional library routines.
+                                                             (line  827)
+* __fractusasf:                          Fixed-point fractional library routines.
+                                                             (line  848)
+* __fractusasi:                          Fixed-point fractional library routines.
+                                                             (line  845)
+* __fractusasq:                          Fixed-point fractional library routines.
+                                                             (line  824)
+* __fractusata:                          Fixed-point fractional library routines.
+                                                             (line  829)
+* __fractusati:                          Fixed-point fractional library routines.
+                                                             (line  847)
+* __fractusauda2:                        Fixed-point fractional library routines.
+                                                             (line  839)
+* __fractusaudq:                         Fixed-point fractional library routines.
+                                                             (line  835)
+* __fractusauha2:                        Fixed-point fractional library routines.
+                                                             (line  837)
+* __fractusauhq:                         Fixed-point fractional library routines.
+                                                             (line  832)
+* __fractusauqq:                         Fixed-point fractional library routines.
+                                                             (line  830)
+* __fractusausq:                         Fixed-point fractional library routines.
+                                                             (line  833)
+* __fractusauta2:                        Fixed-point fractional library routines.
+                                                             (line  841)
+* __fractusqda:                          Fixed-point fractional library routines.
+                                                             (line  730)
+* __fractusqdf:                          Fixed-point fractional library routines.
+                                                             (line  753)
+* __fractusqdi:                          Fixed-point fractional library routines.
+                                                             (line  750)
+* __fractusqdq:                          Fixed-point fractional library routines.
+                                                             (line  726)
+* __fractusqha:                          Fixed-point fractional library routines.
+                                                             (line  728)
+* __fractusqhi:                          Fixed-point fractional library routines.
+                                                             (line  748)
+* __fractusqhq:                          Fixed-point fractional library routines.
+                                                             (line  724)
+* __fractusqqi:                          Fixed-point fractional library routines.
+                                                             (line  747)
+* __fractusqqq:                          Fixed-point fractional library routines.
+                                                             (line  723)
+* __fractusqsa:                          Fixed-point fractional library routines.
+                                                             (line  729)
+* __fractusqsf:                          Fixed-point fractional library routines.
+                                                             (line  752)
+* __fractusqsi:                          Fixed-point fractional library routines.
+                                                             (line  749)
+* __fractusqsq:                          Fixed-point fractional library routines.
+                                                             (line  725)
+* __fractusqta:                          Fixed-point fractional library routines.
+                                                             (line  731)
+* __fractusqti:                          Fixed-point fractional library routines.
+                                                             (line  751)
+* __fractusquda:                         Fixed-point fractional library routines.
+                                                             (line  743)
+* __fractusqudq2:                        Fixed-point fractional library routines.
+                                                             (line  737)
+* __fractusquha:                         Fixed-point fractional library routines.
+                                                             (line  739)
+* __fractusquhq2:                        Fixed-point fractional library routines.
+                                                             (line  735)
+* __fractusquqq2:                        Fixed-point fractional library routines.
+                                                             (line  733)
+* __fractusqusa:                         Fixed-point fractional library routines.
+                                                             (line  741)
+* __fractusquta:                         Fixed-point fractional library routines.
+                                                             (line  745)
+* __fractutada:                          Fixed-point fractional library routines.
+                                                             (line  891)
+* __fractutadf:                          Fixed-point fractional library routines.
+                                                             (line  917)
+* __fractutadi:                          Fixed-point fractional library routines.
+                                                             (line  913)
+* __fractutadq:                          Fixed-point fractional library routines.
+                                                             (line  886)
+* __fractutaha:                          Fixed-point fractional library routines.
+                                                             (line  888)
+* __fractutahi:                          Fixed-point fractional library routines.
+                                                             (line  911)
+* __fractutahq:                          Fixed-point fractional library routines.
+                                                             (line  883)
+* __fractutaqi:                          Fixed-point fractional library routines.
+                                                             (line  909)
+* __fractutaqq:                          Fixed-point fractional library routines.
+                                                             (line  881)
+* __fractutasa:                          Fixed-point fractional library routines.
+                                                             (line  890)
+* __fractutasf:                          Fixed-point fractional library routines.
+                                                             (line  916)
+* __fractutasi:                          Fixed-point fractional library routines.
+                                                             (line  912)
+* __fractutasq:                          Fixed-point fractional library routines.
+                                                             (line  884)
+* __fractutata:                          Fixed-point fractional library routines.
+                                                             (line  893)
+* __fractutati:                          Fixed-point fractional library routines.
+                                                             (line  914)
+* __fractutauda2:                        Fixed-point fractional library routines.
+                                                             (line  907)
+* __fractutaudq:                         Fixed-point fractional library routines.
+                                                             (line  901)
+* __fractutauha2:                        Fixed-point fractional library routines.
+                                                             (line  903)
+* __fractutauhq:                         Fixed-point fractional library routines.
+                                                             (line  897)
+* __fractutauqq:                         Fixed-point fractional library routines.
+                                                             (line  895)
+* __fractutausa2:                        Fixed-point fractional library routines.
+                                                             (line  905)
+* __fractutausq:                         Fixed-point fractional library routines.
+                                                             (line  899)
+* __gedf2:                               Soft float library routines.
+                                                             (line  205)
+* __gesf2:                               Soft float library routines.
+                                                             (line  204)
+* __getf2:                               Soft float library routines.
+                                                             (line  206)
+* __gtdf2:                               Soft float library routines.
+                                                             (line  223)
+* __gtsf2:                               Soft float library routines.
+                                                             (line  222)
+* __gttf2:                               Soft float library routines.
+                                                             (line  224)
+* __ledf2:                               Soft float library routines.
+                                                             (line  217)
+* __lesf2:                               Soft float library routines.
+                                                             (line  216)
+* __letf2:                               Soft float library routines.
+                                                             (line  218)
+* __lshrdi3:                             Integer library routines.
+                                                             (line   30)
+* __lshrsi3:                             Integer library routines.
+                                                             (line   29)
+* __lshrti3:                             Integer library routines.
+                                                             (line   31)
+* __lshruda3:                            Fixed-point fractional library routines.
+                                                             (line  388)
+* __lshrudq3:                            Fixed-point fractional library routines.
+                                                             (line  382)
+* __lshruha3:                            Fixed-point fractional library routines.
+                                                             (line  384)
+* __lshruhq3:                            Fixed-point fractional library routines.
+                                                             (line  378)
+* __lshruqq3:                            Fixed-point fractional library routines.
+                                                             (line  376)
+* __lshrusa3:                            Fixed-point fractional library routines.
+                                                             (line  386)
+* __lshrusq3:                            Fixed-point fractional library routines.
+                                                             (line  380)
+* __lshruta3:                            Fixed-point fractional library routines.
+                                                             (line  390)
+* __ltdf2:                               Soft float library routines.
+                                                             (line  211)
+* __ltsf2:                               Soft float library routines.
+                                                             (line  210)
+* __lttf2:                               Soft float library routines.
+                                                             (line  212)
+* __main:                                Collect2.           (line   15)
+* __moddi3:                              Integer library routines.
+                                                             (line   36)
+* __modsi3:                              Integer library routines.
+                                                             (line   35)
+* __modti3:                              Integer library routines.
+                                                             (line   37)
+* __morestack_current_segment:           Miscellaneous routines.
+                                                             (line   45)
+* __morestack_initial_sp:                Miscellaneous routines.
+                                                             (line   46)
+* __morestack_segments:                  Miscellaneous routines.
+                                                             (line   44)
+* __mulda3:                              Fixed-point fractional library routines.
+                                                             (line  170)
+* __muldc3:                              Soft float library routines.
+                                                             (line  239)
+* __muldf3:                              Soft float library routines.
+                                                             (line   39)
+* __muldi3:                              Integer library routines.
+                                                             (line   42)
+* __muldq3:                              Fixed-point fractional library routines.
+                                                             (line  157)
+* __mulha3:                              Fixed-point fractional library routines.
+                                                             (line  167)
+* __mulhq3:                              Fixed-point fractional library routines.
+                                                             (line  155)
+* __mulqq3:                              Fixed-point fractional library routines.
+                                                             (line  153)
+* __mulsa3:                              Fixed-point fractional library routines.
+                                                             (line  169)
+* __mulsc3:                              Soft float library routines.
+                                                             (line  237)
+* __mulsf3:                              Soft float library routines.
+                                                             (line   38)
+* __mulsi3:                              Integer library routines.
+                                                             (line   41)
+* __mulsq3:                              Fixed-point fractional library routines.
+                                                             (line  156)
+* __multa3:                              Fixed-point fractional library routines.
+                                                             (line  171)
+* __multc3:                              Soft float library routines.
+                                                             (line  241)
+* __multf3:                              Soft float library routines.
+                                                             (line   40)
+* __multi3:                              Integer library routines.
+                                                             (line   43)
+* __muluda3:                             Fixed-point fractional library routines.
+                                                             (line  177)
+* __muludq3:                             Fixed-point fractional library routines.
+                                                             (line  165)
+* __muluha3:                             Fixed-point fractional library routines.
+                                                             (line  173)
+* __muluhq3:                             Fixed-point fractional library routines.
+                                                             (line  161)
+* __muluqq3:                             Fixed-point fractional library routines.
+                                                             (line  159)
+* __mulusa3:                             Fixed-point fractional library routines.
+                                                             (line  175)
+* __mulusq3:                             Fixed-point fractional library routines.
+                                                             (line  163)
+* __muluta3:                             Fixed-point fractional library routines.
+                                                             (line  179)
+* __mulvdi3:                             Integer library routines.
+                                                             (line  114)
+* __mulvsi3:                             Integer library routines.
+                                                             (line  113)
+* __mulxc3:                              Soft float library routines.
+                                                             (line  243)
+* __mulxf3:                              Soft float library routines.
+                                                             (line   42)
+* __nedf2:                               Soft float library routines.
+                                                             (line  199)
+* __negda2:                              Fixed-point fractional library routines.
+                                                             (line  298)
+* __negdf2:                              Soft float library routines.
+                                                             (line   55)
+* __negdi2:                              Integer library routines.
+                                                             (line   46)
+* __negdq2:                              Fixed-point fractional library routines.
+                                                             (line  288)
+* __negha2:                              Fixed-point fractional library routines.
+                                                             (line  296)
+* __neghq2:                              Fixed-point fractional library routines.
+                                                             (line  286)
+* __negqq2:                              Fixed-point fractional library routines.
+                                                             (line  285)
+* __negsa2:                              Fixed-point fractional library routines.
+                                                             (line  297)
+* __negsf2:                              Soft float library routines.
+                                                             (line   54)
+* __negsq2:                              Fixed-point fractional library routines.
+                                                             (line  287)
+* __negta2:                              Fixed-point fractional library routines.
+                                                             (line  299)
+* __negtf2:                              Soft float library routines.
+                                                             (line   56)
+* __negti2:                              Integer library routines.
+                                                             (line   47)
+* __neguda2:                             Fixed-point fractional library routines.
+                                                             (line  303)
+* __negudq2:                             Fixed-point fractional library routines.
+                                                             (line  294)
+* __neguha2:                             Fixed-point fractional library routines.
+                                                             (line  300)
+* __neguhq2:                             Fixed-point fractional library routines.
+                                                             (line  291)
+* __neguqq2:                             Fixed-point fractional library routines.
+                                                             (line  289)
+* __negusa2:                             Fixed-point fractional library routines.
+                                                             (line  302)
+* __negusq2:                             Fixed-point fractional library routines.
+                                                             (line  292)
+* __neguta2:                             Fixed-point fractional library routines.
+                                                             (line  305)
+* __negvdi2:                             Integer library routines.
+                                                             (line  118)
+* __negvsi2:                             Integer library routines.
+                                                             (line  117)
+* __negxf2:                              Soft float library routines.
+                                                             (line   57)
+* __nesf2:                               Soft float library routines.
+                                                             (line  198)
+* __netf2:                               Soft float library routines.
+                                                             (line  200)
+* __paritydi2:                           Integer library routines.
+                                                             (line  150)
+* __paritysi2:                           Integer library routines.
+                                                             (line  149)
+* __parityti2:                           Integer library routines.
+                                                             (line  151)
+* __popcountdi2:                         Integer library routines.
+                                                             (line  156)
+* __popcountsi2:                         Integer library routines.
+                                                             (line  155)
+* __popcountti2:                         Integer library routines.
+                                                             (line  157)
+* __powidf2:                             Soft float library routines.
+                                                             (line  232)
+* __powisf2:                             Soft float library routines.
+                                                             (line  231)
+* __powitf2:                             Soft float library routines.
+                                                             (line  233)
+* __powixf2:                             Soft float library routines.
+                                                             (line  234)
+* __satfractdadq:                        Fixed-point fractional library routines.
+                                                             (line 1152)
+* __satfractdaha2:                       Fixed-point fractional library routines.
+                                                             (line 1153)
+* __satfractdahq:                        Fixed-point fractional library routines.
+                                                             (line 1150)
+* __satfractdaqq:                        Fixed-point fractional library routines.
+                                                             (line 1149)
+* __satfractdasa2:                       Fixed-point fractional library routines.
+                                                             (line 1154)
+* __satfractdasq:                        Fixed-point fractional library routines.
+                                                             (line 1151)
+* __satfractdata2:                       Fixed-point fractional library routines.
+                                                             (line 1155)
+* __satfractdauda:                       Fixed-point fractional library routines.
+                                                             (line 1165)
+* __satfractdaudq:                       Fixed-point fractional library routines.
+                                                             (line 1160)
+* __satfractdauha:                       Fixed-point fractional library routines.
+                                                             (line 1162)
+* __satfractdauhq:                       Fixed-point fractional library routines.
+                                                             (line 1158)
+* __satfractdauqq:                       Fixed-point fractional library routines.
+                                                             (line 1156)
+* __satfractdausa:                       Fixed-point fractional library routines.
+                                                             (line 1164)
+* __satfractdausq:                       Fixed-point fractional library routines.
+                                                             (line 1159)
+* __satfractdauta:                       Fixed-point fractional library routines.
+                                                             (line 1166)
+* __satfractdfda:                        Fixed-point fractional library routines.
+                                                             (line 1505)
+* __satfractdfdq:                        Fixed-point fractional library routines.
+                                                             (line 1502)
+* __satfractdfha:                        Fixed-point fractional library routines.
+                                                             (line 1503)
+* __satfractdfhq:                        Fixed-point fractional library routines.
+                                                             (line 1500)
+* __satfractdfqq:                        Fixed-point fractional library routines.
+                                                             (line 1499)
+* __satfractdfsa:                        Fixed-point fractional library routines.
+                                                             (line 1504)
+* __satfractdfsq:                        Fixed-point fractional library routines.
+                                                             (line 1501)
+* __satfractdfta:                        Fixed-point fractional library routines.
+                                                             (line 1506)
+* __satfractdfuda:                       Fixed-point fractional library routines.
+                                                             (line 1514)
+* __satfractdfudq:                       Fixed-point fractional library routines.
+                                                             (line 1510)
+* __satfractdfuha:                       Fixed-point fractional library routines.
+                                                             (line 1512)
+* __satfractdfuhq:                       Fixed-point fractional library routines.
+                                                             (line 1508)
+* __satfractdfuqq:                       Fixed-point fractional library routines.
+                                                             (line 1507)
+* __satfractdfusa:                       Fixed-point fractional library routines.
+                                                             (line 1513)
+* __satfractdfusq:                       Fixed-point fractional library routines.
+                                                             (line 1509)
+* __satfractdfuta:                       Fixed-point fractional library routines.
+                                                             (line 1515)
+* __satfractdida:                        Fixed-point fractional library routines.
+                                                             (line 1455)
+* __satfractdidq:                        Fixed-point fractional library routines.
+                                                             (line 1452)
+* __satfractdiha:                        Fixed-point fractional library routines.
+                                                             (line 1453)
+* __satfractdihq:                        Fixed-point fractional library routines.
+                                                             (line 1450)
+* __satfractdiqq:                        Fixed-point fractional library routines.
+                                                             (line 1449)
+* __satfractdisa:                        Fixed-point fractional library routines.
+                                                             (line 1454)
+* __satfractdisq:                        Fixed-point fractional library routines.
+                                                             (line 1451)
+* __satfractdita:                        Fixed-point fractional library routines.
+                                                             (line 1456)
+* __satfractdiuda:                       Fixed-point fractional library routines.
+                                                             (line 1463)
+* __satfractdiudq:                       Fixed-point fractional library routines.
+                                                             (line 1460)
+* __satfractdiuha:                       Fixed-point fractional library routines.
+                                                             (line 1461)
+* __satfractdiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1458)
+* __satfractdiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1457)
+* __satfractdiusa:                       Fixed-point fractional library routines.
+                                                             (line 1462)
+* __satfractdiusq:                       Fixed-point fractional library routines.
+                                                             (line 1459)
+* __satfractdiuta:                       Fixed-point fractional library routines.
+                                                             (line 1464)
+* __satfractdqda:                        Fixed-point fractional library routines.
+                                                             (line 1097)
+* __satfractdqha:                        Fixed-point fractional library routines.
+                                                             (line 1095)
+* __satfractdqhq2:                       Fixed-point fractional library routines.
+                                                             (line 1093)
+* __satfractdqqq2:                       Fixed-point fractional library routines.
+                                                             (line 1092)
+* __satfractdqsa:                        Fixed-point fractional library routines.
+                                                             (line 1096)
+* __satfractdqsq2:                       Fixed-point fractional library routines.
+                                                             (line 1094)
+* __satfractdqta:                        Fixed-point fractional library routines.
+                                                             (line 1098)
+* __satfractdquda:                       Fixed-point fractional library routines.
+                                                             (line 1109)
+* __satfractdqudq:                       Fixed-point fractional library routines.
+                                                             (line 1104)
+* __satfractdquha:                       Fixed-point fractional library routines.
+                                                             (line 1106)
+* __satfractdquhq:                       Fixed-point fractional library routines.
+                                                             (line 1101)
+* __satfractdquqq:                       Fixed-point fractional library routines.
+                                                             (line 1099)
+* __satfractdqusa:                       Fixed-point fractional library routines.
+                                                             (line 1108)
+* __satfractdqusq:                       Fixed-point fractional library routines.
+                                                             (line 1102)
+* __satfractdquta:                       Fixed-point fractional library routines.
+                                                             (line 1111)
+* __satfracthada2:                       Fixed-point fractional library routines.
+                                                             (line 1118)
+* __satfracthadq:                        Fixed-point fractional library routines.
+                                                             (line 1116)
+* __satfracthahq:                        Fixed-point fractional library routines.
+                                                             (line 1114)
+* __satfracthaqq:                        Fixed-point fractional library routines.
+                                                             (line 1113)
+* __satfracthasa2:                       Fixed-point fractional library routines.
+                                                             (line 1117)
+* __satfracthasq:                        Fixed-point fractional library routines.
+                                                             (line 1115)
+* __satfracthata2:                       Fixed-point fractional library routines.
+                                                             (line 1119)
+* __satfracthauda:                       Fixed-point fractional library routines.
+                                                             (line 1130)
+* __satfracthaudq:                       Fixed-point fractional library routines.
+                                                             (line 1125)
+* __satfracthauha:                       Fixed-point fractional library routines.
+                                                             (line 1127)
+* __satfracthauhq:                       Fixed-point fractional library routines.
+                                                             (line 1122)
+* __satfracthauqq:                       Fixed-point fractional library routines.
+                                                             (line 1120)
+* __satfracthausa:                       Fixed-point fractional library routines.
+                                                             (line 1129)
+* __satfracthausq:                       Fixed-point fractional library routines.
+                                                             (line 1123)
+* __satfracthauta:                       Fixed-point fractional library routines.
+                                                             (line 1132)
+* __satfracthida:                        Fixed-point fractional library routines.
+                                                             (line 1423)
+* __satfracthidq:                        Fixed-point fractional library routines.
+                                                             (line 1420)
+* __satfracthiha:                        Fixed-point fractional library routines.
+                                                             (line 1421)
+* __satfracthihq:                        Fixed-point fractional library routines.
+                                                             (line 1418)
+* __satfracthiqq:                        Fixed-point fractional library routines.
+                                                             (line 1417)
+* __satfracthisa:                        Fixed-point fractional library routines.
+                                                             (line 1422)
+* __satfracthisq:                        Fixed-point fractional library routines.
+                                                             (line 1419)
+* __satfracthita:                        Fixed-point fractional library routines.
+                                                             (line 1424)
+* __satfracthiuda:                       Fixed-point fractional library routines.
+                                                             (line 1431)
+* __satfracthiudq:                       Fixed-point fractional library routines.
+                                                             (line 1428)
+* __satfracthiuha:                       Fixed-point fractional library routines.
+                                                             (line 1429)
+* __satfracthiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1426)
+* __satfracthiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1425)
+* __satfracthiusa:                       Fixed-point fractional library routines.
+                                                             (line 1430)
+* __satfracthiusq:                       Fixed-point fractional library routines.
+                                                             (line 1427)
+* __satfracthiuta:                       Fixed-point fractional library routines.
+                                                             (line 1432)
+* __satfracthqda:                        Fixed-point fractional library routines.
+                                                             (line 1063)
+* __satfracthqdq2:                       Fixed-point fractional library routines.
+                                                             (line 1060)
+* __satfracthqha:                        Fixed-point fractional library routines.
+                                                             (line 1061)
+* __satfracthqqq2:                       Fixed-point fractional library routines.
+                                                             (line 1058)
+* __satfracthqsa:                        Fixed-point fractional library routines.
+                                                             (line 1062)
+* __satfracthqsq2:                       Fixed-point fractional library routines.
+                                                             (line 1059)
+* __satfracthqta:                        Fixed-point fractional library routines.
+                                                             (line 1064)
+* __satfracthquda:                       Fixed-point fractional library routines.
+                                                             (line 1071)
+* __satfracthqudq:                       Fixed-point fractional library routines.
+                                                             (line 1068)
+* __satfracthquha:                       Fixed-point fractional library routines.
+                                                             (line 1069)
+* __satfracthquhq:                       Fixed-point fractional library routines.
+                                                             (line 1066)
+* __satfracthquqq:                       Fixed-point fractional library routines.
+                                                             (line 1065)
+* __satfracthqusa:                       Fixed-point fractional library routines.
+                                                             (line 1070)
+* __satfracthqusq:                       Fixed-point fractional library routines.
+                                                             (line 1067)
+* __satfracthquta:                       Fixed-point fractional library routines.
+                                                             (line 1072)
+* __satfractqida:                        Fixed-point fractional library routines.
+                                                             (line 1401)
+* __satfractqidq:                        Fixed-point fractional library routines.
+                                                             (line 1398)
+* __satfractqiha:                        Fixed-point fractional library routines.
+                                                             (line 1399)
+* __satfractqihq:                        Fixed-point fractional library routines.
+                                                             (line 1396)
+* __satfractqiqq:                        Fixed-point fractional library routines.
+                                                             (line 1395)
+* __satfractqisa:                        Fixed-point fractional library routines.
+                                                             (line 1400)
+* __satfractqisq:                        Fixed-point fractional library routines.
+                                                             (line 1397)
+* __satfractqita:                        Fixed-point fractional library routines.
+                                                             (line 1402)
+* __satfractqiuda:                       Fixed-point fractional library routines.
+                                                             (line 1413)
+* __satfractqiudq:                       Fixed-point fractional library routines.
+                                                             (line 1408)
+* __satfractqiuha:                       Fixed-point fractional library routines.
+                                                             (line 1410)
+* __satfractqiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1405)
+* __satfractqiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1403)
+* __satfractqiusa:                       Fixed-point fractional library routines.
+                                                             (line 1412)
+* __satfractqiusq:                       Fixed-point fractional library routines.
+                                                             (line 1406)
+* __satfractqiuta:                       Fixed-point fractional library routines.
+                                                             (line 1415)
+* __satfractqqda:                        Fixed-point fractional library routines.
+                                                             (line 1042)
+* __satfractqqdq2:                       Fixed-point fractional library routines.
+                                                             (line 1039)
+* __satfractqqha:                        Fixed-point fractional library routines.
+                                                             (line 1040)
+* __satfractqqhq2:                       Fixed-point fractional library routines.
+                                                             (line 1037)
+* __satfractqqsa:                        Fixed-point fractional library routines.
+                                                             (line 1041)
+* __satfractqqsq2:                       Fixed-point fractional library routines.
+                                                             (line 1038)
+* __satfractqqta:                        Fixed-point fractional library routines.
+                                                             (line 1043)
+* __satfractqquda:                       Fixed-point fractional library routines.
+                                                             (line 1054)
+* __satfractqqudq:                       Fixed-point fractional library routines.
+                                                             (line 1049)
+* __satfractqquha:                       Fixed-point fractional library routines.
+                                                             (line 1051)
+* __satfractqquhq:                       Fixed-point fractional library routines.
+                                                             (line 1046)
+* __satfractqquqq:                       Fixed-point fractional library routines.
+                                                             (line 1044)
+* __satfractqqusa:                       Fixed-point fractional library routines.
+                                                             (line 1053)
+* __satfractqqusq:                       Fixed-point fractional library routines.
+                                                             (line 1047)
+* __satfractqquta:                       Fixed-point fractional library routines.
+                                                             (line 1056)
+* __satfractsada2:                       Fixed-point fractional library routines.
+                                                             (line 1139)
+* __satfractsadq:                        Fixed-point fractional library routines.
+                                                             (line 1137)
+* __satfractsaha2:                       Fixed-point fractional library routines.
+                                                             (line 1138)
+* __satfractsahq:                        Fixed-point fractional library routines.
+                                                             (line 1135)
+* __satfractsaqq:                        Fixed-point fractional library routines.
+                                                             (line 1134)
+* __satfractsasq:                        Fixed-point fractional library routines.
+                                                             (line 1136)
+* __satfractsata2:                       Fixed-point fractional library routines.
+                                                             (line 1140)
+* __satfractsauda:                       Fixed-point fractional library routines.
+                                                             (line 1147)
+* __satfractsaudq:                       Fixed-point fractional library routines.
+                                                             (line 1144)
+* __satfractsauha:                       Fixed-point fractional library routines.
+                                                             (line 1145)
+* __satfractsauhq:                       Fixed-point fractional library routines.
+                                                             (line 1142)
+* __satfractsauqq:                       Fixed-point fractional library routines.
+                                                             (line 1141)
+* __satfractsausa:                       Fixed-point fractional library routines.
+                                                             (line 1146)
+* __satfractsausq:                       Fixed-point fractional library routines.
+                                                             (line 1143)
+* __satfractsauta:                       Fixed-point fractional library routines.
+                                                             (line 1148)
+* __satfractsfda:                        Fixed-point fractional library routines.
+                                                             (line 1489)
+* __satfractsfdq:                        Fixed-point fractional library routines.
+                                                             (line 1486)
+* __satfractsfha:                        Fixed-point fractional library routines.
+                                                             (line 1487)
+* __satfractsfhq:                        Fixed-point fractional library routines.
+                                                             (line 1484)
+* __satfractsfqq:                        Fixed-point fractional library routines.
+                                                             (line 1483)
+* __satfractsfsa:                        Fixed-point fractional library routines.
+                                                             (line 1488)
+* __satfractsfsq:                        Fixed-point fractional library routines.
+                                                             (line 1485)
+* __satfractsfta:                        Fixed-point fractional library routines.
+                                                             (line 1490)
+* __satfractsfuda:                       Fixed-point fractional library routines.
+                                                             (line 1497)
+* __satfractsfudq:                       Fixed-point fractional library routines.
+                                                             (line 1494)
+* __satfractsfuha:                       Fixed-point fractional library routines.
+                                                             (line 1495)
+* __satfractsfuhq:                       Fixed-point fractional library routines.
+                                                             (line 1492)
+* __satfractsfuqq:                       Fixed-point fractional library routines.
+                                                             (line 1491)
+* __satfractsfusa:                       Fixed-point fractional library routines.
+                                                             (line 1496)
+* __satfractsfusq:                       Fixed-point fractional library routines.
+                                                             (line 1493)
+* __satfractsfuta:                       Fixed-point fractional library routines.
+                                                             (line 1498)
+* __satfractsida:                        Fixed-point fractional library routines.
+                                                             (line 1439)
+* __satfractsidq:                        Fixed-point fractional library routines.
+                                                             (line 1436)
+* __satfractsiha:                        Fixed-point fractional library routines.
+                                                             (line 1437)
+* __satfractsihq:                        Fixed-point fractional library routines.
+                                                             (line 1434)
+* __satfractsiqq:                        Fixed-point fractional library routines.
+                                                             (line 1433)
+* __satfractsisa:                        Fixed-point fractional library routines.
+                                                             (line 1438)
+* __satfractsisq:                        Fixed-point fractional library routines.
+                                                             (line 1435)
+* __satfractsita:                        Fixed-point fractional library routines.
+                                                             (line 1440)
+* __satfractsiuda:                       Fixed-point fractional library routines.
+                                                             (line 1447)
+* __satfractsiudq:                       Fixed-point fractional library routines.
+                                                             (line 1444)
+* __satfractsiuha:                       Fixed-point fractional library routines.
+                                                             (line 1445)
+* __satfractsiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1442)
+* __satfractsiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1441)
+* __satfractsiusa:                       Fixed-point fractional library routines.
+                                                             (line 1446)
+* __satfractsiusq:                       Fixed-point fractional library routines.
+                                                             (line 1443)
+* __satfractsiuta:                       Fixed-point fractional library routines.
+                                                             (line 1448)
+* __satfractsqda:                        Fixed-point fractional library routines.
+                                                             (line 1078)
+* __satfractsqdq2:                       Fixed-point fractional library routines.
+                                                             (line 1075)
+* __satfractsqha:                        Fixed-point fractional library routines.
+                                                             (line 1076)
+* __satfractsqhq2:                       Fixed-point fractional library routines.
+                                                             (line 1074)
+* __satfractsqqq2:                       Fixed-point fractional library routines.
+                                                             (line 1073)
+* __satfractsqsa:                        Fixed-point fractional library routines.
+                                                             (line 1077)
+* __satfractsqta:                        Fixed-point fractional library routines.
+                                                             (line 1079)
+* __satfractsquda:                       Fixed-point fractional library routines.
+                                                             (line 1089)
+* __satfractsqudq:                       Fixed-point fractional library routines.
+                                                             (line 1084)
+* __satfractsquha:                       Fixed-point fractional library routines.
+                                                             (line 1086)
+* __satfractsquhq:                       Fixed-point fractional library routines.
+                                                             (line 1082)
+* __satfractsquqq:                       Fixed-point fractional library routines.
+                                                             (line 1080)
+* __satfractsqusa:                       Fixed-point fractional library routines.
+                                                             (line 1088)
+* __satfractsqusq:                       Fixed-point fractional library routines.
+                                                             (line 1083)
+* __satfractsquta:                       Fixed-point fractional library routines.
+                                                             (line 1090)
+* __satfracttada2:                       Fixed-point fractional library routines.
+                                                             (line 1174)
+* __satfracttadq:                        Fixed-point fractional library routines.
+                                                             (line 1171)
+* __satfracttaha2:                       Fixed-point fractional library routines.
+                                                             (line 1172)
+* __satfracttahq:                        Fixed-point fractional library routines.
+                                                             (line 1169)
+* __satfracttaqq:                        Fixed-point fractional library routines.
+                                                             (line 1168)
+* __satfracttasa2:                       Fixed-point fractional library routines.
+                                                             (line 1173)
+* __satfracttasq:                        Fixed-point fractional library routines.
+                                                             (line 1170)
+* __satfracttauda:                       Fixed-point fractional library routines.
+                                                             (line 1185)
+* __satfracttaudq:                       Fixed-point fractional library routines.
+                                                             (line 1180)
+* __satfracttauha:                       Fixed-point fractional library routines.
+                                                             (line 1182)
+* __satfracttauhq:                       Fixed-point fractional library routines.
+                                                             (line 1177)
+* __satfracttauqq:                       Fixed-point fractional library routines.
+                                                             (line 1175)
+* __satfracttausa:                       Fixed-point fractional library routines.
+                                                             (line 1184)
+* __satfracttausq:                       Fixed-point fractional library routines.
+                                                             (line 1178)
+* __satfracttauta:                       Fixed-point fractional library routines.
+                                                             (line 1187)
+* __satfracttida:                        Fixed-point fractional library routines.
+                                                             (line 1471)
+* __satfracttidq:                        Fixed-point fractional library routines.
+                                                             (line 1468)
+* __satfracttiha:                        Fixed-point fractional library routines.
+                                                             (line 1469)
+* __satfracttihq:                        Fixed-point fractional library routines.
+                                                             (line 1466)
+* __satfracttiqq:                        Fixed-point fractional library routines.
+                                                             (line 1465)
+* __satfracttisa:                        Fixed-point fractional library routines.
+                                                             (line 1470)
+* __satfracttisq:                        Fixed-point fractional library routines.
+                                                             (line 1467)
+* __satfracttita:                        Fixed-point fractional library routines.
+                                                             (line 1472)
+* __satfracttiuda:                       Fixed-point fractional library routines.
+                                                             (line 1480)
+* __satfracttiudq:                       Fixed-point fractional library routines.
+                                                             (line 1476)
+* __satfracttiuha:                       Fixed-point fractional library routines.
+                                                             (line 1478)
+* __satfracttiuhq:                       Fixed-point fractional library routines.
+                                                             (line 1474)
+* __satfracttiuqq:                       Fixed-point fractional library routines.
+                                                             (line 1473)
+* __satfracttiusa:                       Fixed-point fractional library routines.
+                                                             (line 1479)
+* __satfracttiusq:                       Fixed-point fractional library routines.
+                                                             (line 1475)
+* __satfracttiuta:                       Fixed-point fractional library routines.
+                                                             (line 1481)
+* __satfractudada:                       Fixed-point fractional library routines.
+                                                             (line 1350)
+* __satfractudadq:                       Fixed-point fractional library routines.
+                                                             (line 1345)
+* __satfractudaha:                       Fixed-point fractional library routines.
+                                                             (line 1347)
+* __satfractudahq:                       Fixed-point fractional library routines.
+                                                             (line 1343)
+* __satfractudaqq:                       Fixed-point fractional library routines.
+                                                             (line 1341)
+* __satfractudasa:                       Fixed-point fractional library routines.
+                                                             (line 1349)
+* __satfractudasq:                       Fixed-point fractional library routines.
+                                                             (line 1344)
+* __satfractudata:                       Fixed-point fractional library routines.
+                                                             (line 1351)
+* __satfractudaudq:                      Fixed-point fractional library routines.
+                                                             (line 1359)
+* __satfractudauha2:                     Fixed-point fractional library routines.
+                                                             (line 1361)
+* __satfractudauhq:                      Fixed-point fractional library routines.
+                                                             (line 1355)
+* __satfractudauqq:                      Fixed-point fractional library routines.
+                                                             (line 1353)
+* __satfractudausa2:                     Fixed-point fractional library routines.
+                                                             (line 1363)
+* __satfractudausq:                      Fixed-point fractional library routines.
+                                                             (line 1357)
+* __satfractudauta2:                     Fixed-point fractional library routines.
+                                                             (line 1365)
+* __satfractudqda:                       Fixed-point fractional library routines.
+                                                             (line 1274)
+* __satfractudqdq:                       Fixed-point fractional library routines.
+                                                             (line 1269)
+* __satfractudqha:                       Fixed-point fractional library routines.
+                                                             (line 1271)
+* __satfractudqhq:                       Fixed-point fractional library routines.
+                                                             (line 1266)
+* __satfractudqqq:                       Fixed-point fractional library routines.
+                                                             (line 1264)
+* __satfractudqsa:                       Fixed-point fractional library routines.
+                                                             (line 1273)
+* __satfractudqsq:                       Fixed-point fractional library routines.
+                                                             (line 1267)
+* __satfractudqta:                       Fixed-point fractional library routines.
+                                                             (line 1276)
+* __satfractudquda:                      Fixed-point fractional library routines.
+                                                             (line 1288)
+* __satfractudquha:                      Fixed-point fractional library routines.
+                                                             (line 1284)
+* __satfractudquhq2:                     Fixed-point fractional library routines.
+                                                             (line 1280)
+* __satfractudquqq2:                     Fixed-point fractional library routines.
+                                                             (line 1278)
+* __satfractudqusa:                      Fixed-point fractional library routines.
+                                                             (line 1286)
+* __satfractudqusq2:                     Fixed-point fractional library routines.
+                                                             (line 1282)
+* __satfractudquta:                      Fixed-point fractional library routines.
+                                                             (line 1290)
+* __satfractuhada:                       Fixed-point fractional library routines.
+                                                             (line 1302)
+* __satfractuhadq:                       Fixed-point fractional library routines.
+                                                             (line 1297)
+* __satfractuhaha:                       Fixed-point fractional library routines.
+                                                             (line 1299)
+* __satfractuhahq:                       Fixed-point fractional library routines.
+                                                             (line 1294)
+* __satfractuhaqq:                       Fixed-point fractional library routines.
+                                                             (line 1292)
+* __satfractuhasa:                       Fixed-point fractional library routines.
+                                                             (line 1301)
+* __satfractuhasq:                       Fixed-point fractional library routines.
+                                                             (line 1295)
+* __satfractuhata:                       Fixed-point fractional library routines.
+                                                             (line 1304)
+* __satfractuhauda2:                     Fixed-point fractional library routines.
+                                                             (line 1316)
+* __satfractuhaudq:                      Fixed-point fractional library routines.
+                                                             (line 1312)
+* __satfractuhauhq:                      Fixed-point fractional library routines.
+                                                             (line 1308)
+* __satfractuhauqq:                      Fixed-point fractional library routines.
+                                                             (line 1306)
+* __satfractuhausa2:                     Fixed-point fractional library routines.
+                                                             (line 1314)
+* __satfractuhausq:                      Fixed-point fractional library routines.
+                                                             (line 1310)
+* __satfractuhauta2:                     Fixed-point fractional library routines.
+                                                             (line 1318)
+* __satfractuhqda:                       Fixed-point fractional library routines.
+                                                             (line 1223)
+* __satfractuhqdq:                       Fixed-point fractional library routines.
+                                                             (line 1220)
+* __satfractuhqha:                       Fixed-point fractional library routines.
+                                                             (line 1221)
+* __satfractuhqhq:                       Fixed-point fractional library routines.
+                                                             (line 1218)
+* __satfractuhqqq:                       Fixed-point fractional library routines.
+                                                             (line 1217)
+* __satfractuhqsa:                       Fixed-point fractional library routines.
+                                                             (line 1222)
+* __satfractuhqsq:                       Fixed-point fractional library routines.
+                                                             (line 1219)
+* __satfractuhqta:                       Fixed-point fractional library routines.
+                                                             (line 1224)
+* __satfractuhquda:                      Fixed-point fractional library routines.
+                                                             (line 1234)
+* __satfractuhqudq2:                     Fixed-point fractional library routines.
+                                                             (line 1229)
+* __satfractuhquha:                      Fixed-point fractional library routines.
+                                                             (line 1231)
+* __satfractuhquqq2:                     Fixed-point fractional library routines.
+                                                             (line 1225)
+* __satfractuhqusa:                      Fixed-point fractional library routines.
+                                                             (line 1233)
+* __satfractuhqusq2:                     Fixed-point fractional library routines.
+                                                             (line 1227)
+* __satfractuhquta:                      Fixed-point fractional library routines.
+                                                             (line 1236)
+* __satfractunsdida:                     Fixed-point fractional library routines.
+                                                             (line 1833)
+* __satfractunsdidq:                     Fixed-point fractional library routines.
+                                                             (line 1829)
+* __satfractunsdiha:                     Fixed-point fractional library routines.
+                                                             (line 1831)
+* __satfractunsdihq:                     Fixed-point fractional library routines.
+                                                             (line 1827)
+* __satfractunsdiqq:                     Fixed-point fractional library routines.
+                                                             (line 1826)
+* __satfractunsdisa:                     Fixed-point fractional library routines.
+                                                             (line 1832)
+* __satfractunsdisq:                     Fixed-point fractional library routines.
+                                                             (line 1828)
+* __satfractunsdita:                     Fixed-point fractional library routines.
+                                                             (line 1834)
+* __satfractunsdiuda:                    Fixed-point fractional library routines.
+                                                             (line 1848)
+* __satfractunsdiudq:                    Fixed-point fractional library routines.
+                                                             (line 1842)
+* __satfractunsdiuha:                    Fixed-point fractional library routines.
+                                                             (line 1844)
+* __satfractunsdiuhq:                    Fixed-point fractional library routines.
+                                                             (line 1838)
+* __satfractunsdiuqq:                    Fixed-point fractional library routines.
+                                                             (line 1836)
+* __satfractunsdiusa:                    Fixed-point fractional library routines.
+                                                             (line 1846)
+* __satfractunsdiusq:                    Fixed-point fractional library routines.
+                                                             (line 1840)
+* __satfractunsdiuta:                    Fixed-point fractional library routines.
+                                                             (line 1850)
+* __satfractunshida:                     Fixed-point fractional library routines.
+                                                             (line 1785)
+* __satfractunshidq:                     Fixed-point fractional library routines.
+                                                             (line 1781)
+* __satfractunshiha:                     Fixed-point fractional library routines.
+                                                             (line 1783)
+* __satfractunshihq:                     Fixed-point fractional library routines.
+                                                             (line 1779)
+* __satfractunshiqq:                     Fixed-point fractional library routines.
+                                                             (line 1778)
+* __satfractunshisa:                     Fixed-point fractional library routines.
+                                                             (line 1784)
+* __satfractunshisq:                     Fixed-point fractional library routines.
+                                                             (line 1780)
+* __satfractunshita:                     Fixed-point fractional library routines.
+                                                             (line 1786)
+* __satfractunshiuda:                    Fixed-point fractional library routines.
+                                                             (line 1800)
+* __satfractunshiudq:                    Fixed-point fractional library routines.
+                                                             (line 1794)
+* __satfractunshiuha:                    Fixed-point fractional library routines.
+                                                             (line 1796)
+* __satfractunshiuhq:                    Fixed-point fractional library routines.
+                                                             (line 1790)
+* __satfractunshiuqq:                    Fixed-point fractional library routines.
+                                                             (line 1788)
+* __satfractunshiusa:                    Fixed-point fractional library routines.
+                                                             (line 1798)
+* __satfractunshiusq:                    Fixed-point fractional library routines.
+                                                             (line 1792)
+* __satfractunshiuta:                    Fixed-point fractional library routines.
+                                                             (line 1802)
+* __satfractunsqida:                     Fixed-point fractional library routines.
+                                                             (line 1759)
+* __satfractunsqidq:                     Fixed-point fractional library routines.
+                                                             (line 1755)
+* __satfractunsqiha:                     Fixed-point fractional library routines.
+                                                             (line 1757)
+* __satfractunsqihq:                     Fixed-point fractional library routines.
+                                                             (line 1753)
+* __satfractunsqiqq:                     Fixed-point fractional library routines.
+                                                             (line 1752)
+* __satfractunsqisa:                     Fixed-point fractional library routines.
+                                                             (line 1758)
+* __satfractunsqisq:                     Fixed-point fractional library routines.
+                                                             (line 1754)
+* __satfractunsqita:                     Fixed-point fractional library routines.
+                                                             (line 1760)
+* __satfractunsqiuda:                    Fixed-point fractional library routines.
+                                                             (line 1774)
+* __satfractunsqiudq:                    Fixed-point fractional library routines.
+                                                             (line 1768)
+* __satfractunsqiuha:                    Fixed-point fractional library routines.
+                                                             (line 1770)
+* __satfractunsqiuhq:                    Fixed-point fractional library routines.
+                                                             (line 1764)
+* __satfractunsqiuqq:                    Fixed-point fractional library routines.
+                                                             (line 1762)
+* __satfractunsqiusa:                    Fixed-point fractional library routines.
+                                                             (line 1772)
+* __satfractunsqiusq:                    Fixed-point fractional library routines.
+                                                             (line 1766)
+* __satfractunsqiuta:                    Fixed-point fractional library routines.
+                                                             (line 1776)
+* __satfractunssida:                     Fixed-point fractional library routines.
+                                                             (line 1810)
+* __satfractunssidq:                     Fixed-point fractional library routines.
+                                                             (line 1807)
+* __satfractunssiha:                     Fixed-point fractional library routines.
+                                                             (line 1808)
+* __satfractunssihq:                     Fixed-point fractional library routines.
+                                                             (line 1805)
+* __satfractunssiqq:                     Fixed-point fractional library routines.
+                                                             (line 1804)
+* __satfractunssisa:                     Fixed-point fractional library routines.
+                                                             (line 1809)
+* __satfractunssisq:                     Fixed-point fractional library routines.
+                                                             (line 1806)
+* __satfractunssita:                     Fixed-point fractional library routines.
+                                                             (line 1811)
+* __satfractunssiuda:                    Fixed-point fractional library routines.
+                                                             (line 1822)
+* __satfractunssiudq:                    Fixed-point fractional library routines.
+                                                             (line 1817)
+* __satfractunssiuha:                    Fixed-point fractional library routines.
+                                                             (line 1819)
+* __satfractunssiuhq:                    Fixed-point fractional library routines.
+                                                             (line 1814)
+* __satfractunssiuqq:                    Fixed-point fractional library routines.
+                                                             (line 1812)
+* __satfractunssiusa:                    Fixed-point fractional library routines.
+                                                             (line 1821)
+* __satfractunssiusq:                    Fixed-point fractional library routines.
+                                                             (line 1815)
+* __satfractunssiuta:                    Fixed-point fractional library routines.
+                                                             (line 1824)
+* __satfractunstida:                     Fixed-point fractional library routines.
+                                                             (line 1862)
+* __satfractunstidq:                     Fixed-point fractional library routines.
+                                                             (line 1857)
+* __satfractunstiha:                     Fixed-point fractional library routines.
+                                                             (line 1859)
+* __satfractunstihq:                     Fixed-point fractional library routines.
+                                                             (line 1854)
+* __satfractunstiqq:                     Fixed-point fractional library routines.
+                                                             (line 1852)
+* __satfractunstisa:                     Fixed-point fractional library routines.
+                                                             (line 1861)
+* __satfractunstisq:                     Fixed-point fractional library routines.
+                                                             (line 1855)
+* __satfractunstita:                     Fixed-point fractional library routines.
+                                                             (line 1864)
+* __satfractunstiuda:                    Fixed-point fractional library routines.
+                                                             (line 1878)
+* __satfractunstiudq:                    Fixed-point fractional library routines.
+                                                             (line 1872)
+* __satfractunstiuha:                    Fixed-point fractional library routines.
+                                                             (line 1874)
+* __satfractunstiuhq:                    Fixed-point fractional library routines.
+                                                             (line 1868)
+* __satfractunstiuqq:                    Fixed-point fractional library routines.
+                                                             (line 1866)
+* __satfractunstiusa:                    Fixed-point fractional library routines.
+                                                             (line 1876)
+* __satfractunstiusq:                    Fixed-point fractional library routines.
+                                                             (line 1870)
+* __satfractunstiuta:                    Fixed-point fractional library routines.
+                                                             (line 1880)
+* __satfractuqqda:                       Fixed-point fractional library routines.
+                                                             (line 1199)
+* __satfractuqqdq:                       Fixed-point fractional library routines.
+                                                             (line 1194)
+* __satfractuqqha:                       Fixed-point fractional library routines.
+                                                             (line 1196)
+* __satfractuqqhq:                       Fixed-point fractional library routines.
+                                                             (line 1191)
+* __satfractuqqqq:                       Fixed-point fractional library routines.
+                                                             (line 1189)
+* __satfractuqqsa:                       Fixed-point fractional library routines.
+                                                             (line 1198)
+* __satfractuqqsq:                       Fixed-point fractional library routines.
+                                                             (line 1192)
+* __satfractuqqta:                       Fixed-point fractional library routines.
+                                                             (line 1201)
+* __satfractuqquda:                      Fixed-point fractional library routines.
+                                                             (line 1213)
+* __satfractuqqudq2:                     Fixed-point fractional library routines.
+                                                             (line 1207)
+* __satfractuqquha:                      Fixed-point fractional library routines.
+                                                             (line 1209)
+* __satfractuqquhq2:                     Fixed-point fractional library routines.
+                                                             (line 1203)
+* __satfractuqqusa:                      Fixed-point fractional library routines.
+                                                             (line 1211)
+* __satfractuqqusq2:                     Fixed-point fractional library routines.
+                                                             (line 1205)
+* __satfractuqquta:                      Fixed-point fractional library routines.
+                                                             (line 1215)
+* __satfractusada:                       Fixed-point fractional library routines.
+                                                             (line 1326)
+* __satfractusadq:                       Fixed-point fractional library routines.
+                                                             (line 1323)
+* __satfractusaha:                       Fixed-point fractional library routines.
+                                                             (line 1324)
+* __satfractusahq:                       Fixed-point fractional library routines.
+                                                             (line 1321)
+* __satfractusaqq:                       Fixed-point fractional library routines.
+                                                             (line 1320)
+* __satfractusasa:                       Fixed-point fractional library routines.
+                                                             (line 1325)
+* __satfractusasq:                       Fixed-point fractional library routines.
+                                                             (line 1322)
+* __satfractusata:                       Fixed-point fractional library routines.
+                                                             (line 1327)
+* __satfractusauda2:                     Fixed-point fractional library routines.
+                                                             (line 1337)
+* __satfractusaudq:                      Fixed-point fractional library routines.
+                                                             (line 1333)
+* __satfractusauha2:                     Fixed-point fractional library routines.
+                                                             (line 1335)
+* __satfractusauhq:                      Fixed-point fractional library routines.
+                                                             (line 1330)
+* __satfractusauqq:                      Fixed-point fractional library routines.
+                                                             (line 1328)
+* __satfractusausq:                      Fixed-point fractional library routines.
+                                                             (line 1331)
+* __satfractusauta2:                     Fixed-point fractional library routines.
+                                                             (line 1339)
+* __satfractusqda:                       Fixed-point fractional library routines.
+                                                             (line 1247)
+* __satfractusqdq:                       Fixed-point fractional library routines.
+                                                             (line 1242)
+* __satfractusqha:                       Fixed-point fractional library routines.
+                                                             (line 1244)
+* __satfractusqhq:                       Fixed-point fractional library routines.
+                                                             (line 1240)
+* __satfractusqqq:                       Fixed-point fractional library routines.
+                                                             (line 1238)
+* __satfractusqsa:                       Fixed-point fractional library routines.
+                                                             (line 1246)
+* __satfractusqsq:                       Fixed-point fractional library routines.
+                                                             (line 1241)
+* __satfractusqta:                       Fixed-point fractional library routines.
+                                                             (line 1248)
+* __satfractusquda:                      Fixed-point fractional library routines.
+                                                             (line 1260)
+* __satfractusqudq2:                     Fixed-point fractional library routines.
+                                                             (line 1254)
+* __satfractusquha:                      Fixed-point fractional library routines.
+                                                             (line 1256)
+* __satfractusquhq2:                     Fixed-point fractional library routines.
+                                                             (line 1252)
+* __satfractusquqq2:                     Fixed-point fractional library routines.
+                                                             (line 1250)
+* __satfractusqusa:                      Fixed-point fractional library routines.
+                                                             (line 1258)
+* __satfractusquta:                      Fixed-point fractional library routines.
+                                                             (line 1262)
+* __satfractutada:                       Fixed-point fractional library routines.
+                                                             (line 1377)
+* __satfractutadq:                       Fixed-point fractional library routines.
+                                                             (line 1372)
+* __satfractutaha:                       Fixed-point fractional library routines.
+                                                             (line 1374)
+* __satfractutahq:                       Fixed-point fractional library routines.
+                                                             (line 1369)
+* __satfractutaqq:                       Fixed-point fractional library routines.
+                                                             (line 1367)
+* __satfractutasa:                       Fixed-point fractional library routines.
+                                                             (line 1376)
+* __satfractutasq:                       Fixed-point fractional library routines.
+                                                             (line 1370)
+* __satfractutata:                       Fixed-point fractional library routines.
+                                                             (line 1379)
+* __satfractutauda2:                     Fixed-point fractional library routines.
+                                                             (line 1393)
+* __satfractutaudq:                      Fixed-point fractional library routines.
+                                                             (line 1387)
+* __satfractutauha2:                     Fixed-point fractional library routines.
+                                                             (line 1389)
+* __satfractutauhq:                      Fixed-point fractional library routines.
+                                                             (line 1383)
+* __satfractutauqq:                      Fixed-point fractional library routines.
+                                                             (line 1381)
+* __satfractutausa2:                     Fixed-point fractional library routines.
+                                                             (line 1391)
+* __satfractutausq:                      Fixed-point fractional library routines.
+                                                             (line 1385)
+* __splitstack_find:                     Miscellaneous routines.
+                                                             (line   15)
+* __ssaddda3:                            Fixed-point fractional library routines.
+                                                             (line   66)
+* __ssadddq3:                            Fixed-point fractional library routines.
+                                                             (line   61)
+* __ssaddha3:                            Fixed-point fractional library routines.
+                                                             (line   63)
+* __ssaddhq3:                            Fixed-point fractional library routines.
+                                                             (line   59)
+* __ssaddqq3:                            Fixed-point fractional library routines.
+                                                             (line   57)
+* __ssaddsa3:                            Fixed-point fractional library routines.
+                                                             (line   65)
+* __ssaddsq3:                            Fixed-point fractional library routines.
+                                                             (line   60)
+* __ssaddta3:                            Fixed-point fractional library routines.
+                                                             (line   67)
+* __ssashlda3:                           Fixed-point fractional library routines.
+                                                             (line  401)
+* __ssashldq3:                           Fixed-point fractional library routines.
+                                                             (line  397)
+* __ssashlha3:                           Fixed-point fractional library routines.
+                                                             (line  399)
+* __ssashlhq3:                           Fixed-point fractional library routines.
+                                                             (line  395)
+* __ssashlsa3:                           Fixed-point fractional library routines.
+                                                             (line  400)
+* __ssashlsq3:                           Fixed-point fractional library routines.
+                                                             (line  396)
+* __ssashlta3:                           Fixed-point fractional library routines.
+                                                             (line  402)
+* __ssdivda3:                            Fixed-point fractional library routines.
+                                                             (line  260)
+* __ssdivdq3:                            Fixed-point fractional library routines.
+                                                             (line  255)
+* __ssdivha3:                            Fixed-point fractional library routines.
+                                                             (line  257)
+* __ssdivhq3:                            Fixed-point fractional library routines.
+                                                             (line  253)
+* __ssdivqq3:                            Fixed-point fractional library routines.
+                                                             (line  251)
+* __ssdivsa3:                            Fixed-point fractional library routines.
+                                                             (line  259)
+* __ssdivsq3:                            Fixed-point fractional library routines.
+                                                             (line  254)
+* __ssdivta3:                            Fixed-point fractional library routines.
+                                                             (line  261)
+* __ssmulda3:                            Fixed-point fractional library routines.
+                                                             (line  192)
+* __ssmuldq3:                            Fixed-point fractional library routines.
+                                                             (line  187)
+* __ssmulha3:                            Fixed-point fractional library routines.
+                                                             (line  189)
+* __ssmulhq3:                            Fixed-point fractional library routines.
+                                                             (line  185)
+* __ssmulqq3:                            Fixed-point fractional library routines.
+                                                             (line  183)
+* __ssmulsa3:                            Fixed-point fractional library routines.
+                                                             (line  191)
+* __ssmulsq3:                            Fixed-point fractional library routines.
+                                                             (line  186)
+* __ssmulta3:                            Fixed-point fractional library routines.
+                                                             (line  193)
+* __ssnegda2:                            Fixed-point fractional library routines.
+                                                             (line  315)
+* __ssnegdq2:                            Fixed-point fractional library routines.
+                                                             (line  312)
+* __ssnegha2:                            Fixed-point fractional library routines.
+                                                             (line  313)
+* __ssneghq2:                            Fixed-point fractional library routines.
+                                                             (line  310)
+* __ssnegqq2:                            Fixed-point fractional library routines.
+                                                             (line  309)
+* __ssnegsa2:                            Fixed-point fractional library routines.
+                                                             (line  314)
+* __ssnegsq2:                            Fixed-point fractional library routines.
+                                                             (line  311)
+* __ssnegta2:                            Fixed-point fractional library routines.
+                                                             (line  316)
+* __sssubda3:                            Fixed-point fractional library routines.
+                                                             (line  128)
+* __sssubdq3:                            Fixed-point fractional library routines.
+                                                             (line  123)
+* __sssubha3:                            Fixed-point fractional library routines.
+                                                             (line  125)
+* __sssubhq3:                            Fixed-point fractional library routines.
+                                                             (line  121)
+* __sssubqq3:                            Fixed-point fractional library routines.
+                                                             (line  119)
+* __sssubsa3:                            Fixed-point fractional library routines.
+                                                             (line  127)
+* __sssubsq3:                            Fixed-point fractional library routines.
+                                                             (line  122)
+* __sssubta3:                            Fixed-point fractional library routines.
+                                                             (line  129)
+* __subda3:                              Fixed-point fractional library routines.
+                                                             (line  106)
+* __subdf3:                              Soft float library routines.
+                                                             (line   30)
+* __subdq3:                              Fixed-point fractional library routines.
+                                                             (line   93)
+* __subha3:                              Fixed-point fractional library routines.
+                                                             (line  103)
+* __subhq3:                              Fixed-point fractional library routines.
+                                                             (line   91)
+* __subqq3:                              Fixed-point fractional library routines.
+                                                             (line   89)
+* __subsa3:                              Fixed-point fractional library routines.
+                                                             (line  105)
+* __subsf3:                              Soft float library routines.
+                                                             (line   29)
+* __subsq3:                              Fixed-point fractional library routines.
+                                                             (line   92)
+* __subta3:                              Fixed-point fractional library routines.
+                                                             (line  107)
+* __subtf3:                              Soft float library routines.
+                                                             (line   31)
+* __subuda3:                             Fixed-point fractional library routines.
+                                                             (line  113)
+* __subudq3:                             Fixed-point fractional library routines.
+                                                             (line  101)
+* __subuha3:                             Fixed-point fractional library routines.
+                                                             (line  109)
+* __subuhq3:                             Fixed-point fractional library routines.
+                                                             (line   97)
+* __subuqq3:                             Fixed-point fractional library routines.
+                                                             (line   95)
+* __subusa3:                             Fixed-point fractional library routines.
+                                                             (line  111)
+* __subusq3:                             Fixed-point fractional library routines.
+                                                             (line   99)
+* __subuta3:                             Fixed-point fractional library routines.
+                                                             (line  115)
+* __subvdi3:                             Integer library routines.
+                                                             (line  122)
+* __subvsi3:                             Integer library routines.
+                                                             (line  121)
+* __subxf3:                              Soft float library routines.
+                                                             (line   33)
+* __truncdfsf2:                          Soft float library routines.
+                                                             (line   75)
+* __trunctfdf2:                          Soft float library routines.
+                                                             (line   72)
+* __trunctfsf2:                          Soft float library routines.
+                                                             (line   74)
+* __truncxfdf2:                          Soft float library routines.
+                                                             (line   71)
+* __truncxfsf2:                          Soft float library routines.
+                                                             (line   73)
+* __ucmpdi2:                             Integer library routines.
+                                                             (line   92)
+* __ucmpti2:                             Integer library routines.
+                                                             (line   93)
+* __udivdi3:                             Integer library routines.
+                                                             (line   52)
+* __udivmoddi4:                          Integer library routines.
+                                                             (line   59)
+* __udivmodti4:                          Integer library routines.
+                                                             (line   61)
+* __udivsi3:                             Integer library routines.
+                                                             (line   50)
+* __udivti3:                             Integer library routines.
+                                                             (line   54)
+* __udivuda3:                            Fixed-point fractional library routines.
+                                                             (line  244)
+* __udivudq3:                            Fixed-point fractional library routines.
+                                                             (line  238)
+* __udivuha3:                            Fixed-point fractional library routines.
+                                                             (line  240)
+* __udivuhq3:                            Fixed-point fractional library routines.
+                                                             (line  234)
+* __udivuqq3:                            Fixed-point fractional library routines.
+                                                             (line  232)
+* __udivusa3:                            Fixed-point fractional library routines.
+                                                             (line  242)
+* __udivusq3:                            Fixed-point fractional library routines.
+                                                             (line  236)
+* __udivuta3:                            Fixed-point fractional library routines.
+                                                             (line  246)
+* __umoddi3:                             Integer library routines.
+                                                             (line   69)
+* __umodsi3:                             Integer library routines.
+                                                             (line   67)
+* __umodti3:                             Integer library routines.
+                                                             (line   71)
+* __unorddf2:                            Soft float library routines.
+                                                             (line  172)
+* __unordsf2:                            Soft float library routines.
+                                                             (line  171)
+* __unordtf2:                            Soft float library routines.
+                                                             (line  173)
+* __usadduda3:                           Fixed-point fractional library routines.
+                                                             (line   83)
+* __usaddudq3:                           Fixed-point fractional library routines.
+                                                             (line   77)
+* __usadduha3:                           Fixed-point fractional library routines.
+                                                             (line   79)
+* __usadduhq3:                           Fixed-point fractional library routines.
+                                                             (line   73)
+* __usadduqq3:                           Fixed-point fractional library routines.
+                                                             (line   71)
+* __usaddusa3:                           Fixed-point fractional library routines.
+                                                             (line   81)
+* __usaddusq3:                           Fixed-point fractional library routines.
+                                                             (line   75)
+* __usadduta3:                           Fixed-point fractional library routines.
+                                                             (line   85)
+* __usashluda3:                          Fixed-point fractional library routines.
+                                                             (line  419)
+* __usashludq3:                          Fixed-point fractional library routines.
+                                                             (line  413)
+* __usashluha3:                          Fixed-point fractional library routines.
+                                                             (line  415)
+* __usashluhq3:                          Fixed-point fractional library routines.
+                                                             (line  409)
+* __usashluqq3:                          Fixed-point fractional library routines.
+                                                             (line  407)
+* __usashlusa3:                          Fixed-point fractional library routines.
+                                                             (line  417)
+* __usashlusq3:                          Fixed-point fractional library routines.
+                                                             (line  411)
+* __usashluta3:                          Fixed-point fractional library routines.
+                                                             (line  421)
+* __usdivuda3:                           Fixed-point fractional library routines.
+                                                             (line  278)
+* __usdivudq3:                           Fixed-point fractional library routines.
+                                                             (line  272)
+* __usdivuha3:                           Fixed-point fractional library routines.
+                                                             (line  274)
+* __usdivuhq3:                           Fixed-point fractional library routines.
+                                                             (line  268)
+* __usdivuqq3:                           Fixed-point fractional library routines.
+                                                             (line  266)
+* __usdivusa3:                           Fixed-point fractional library routines.
+                                                             (line  276)
+* __usdivusq3:                           Fixed-point fractional library routines.
+                                                             (line  270)
+* __usdivuta3:                           Fixed-point fractional library routines.
+                                                             (line  280)
+* __usmuluda3:                           Fixed-point fractional library routines.
+                                                             (line  210)
+* __usmuludq3:                           Fixed-point fractional library routines.
+                                                             (line  204)
+* __usmuluha3:                           Fixed-point fractional library routines.
+                                                             (line  206)
+* __usmuluhq3:                           Fixed-point fractional library routines.
+                                                             (line  200)
+* __usmuluqq3:                           Fixed-point fractional library routines.
+                                                             (line  198)
+* __usmulusa3:                           Fixed-point fractional library routines.
+                                                             (line  208)
+* __usmulusq3:                           Fixed-point fractional library routines.
+                                                             (line  202)
+* __usmuluta3:                           Fixed-point fractional library routines.
+                                                             (line  212)
+* __usneguda2:                           Fixed-point fractional library routines.
+                                                             (line  329)
+* __usnegudq2:                           Fixed-point fractional library routines.
+                                                             (line  324)
+* __usneguha2:                           Fixed-point fractional library routines.
+                                                             (line  326)
+* __usneguhq2:                           Fixed-point fractional library routines.
+                                                             (line  321)
+* __usneguqq2:                           Fixed-point fractional library routines.
+                                                             (line  319)
+* __usnegusa2:                           Fixed-point fractional library routines.
+                                                             (line  328)
+* __usnegusq2:                           Fixed-point fractional library routines.
+                                                             (line  322)
+* __usneguta2:                           Fixed-point fractional library routines.
+                                                             (line  331)
+* __ussubuda3:                           Fixed-point fractional library routines.
+                                                             (line  146)
+* __ussubudq3:                           Fixed-point fractional library routines.
+                                                             (line  140)
+* __ussubuha3:                           Fixed-point fractional library routines.
+                                                             (line  142)
+* __ussubuhq3:                           Fixed-point fractional library routines.
+                                                             (line  136)
+* __ussubuqq3:                           Fixed-point fractional library routines.
+                                                             (line  134)
+* __ussubusa3:                           Fixed-point fractional library routines.
+                                                             (line  144)
+* __ussubusq3:                           Fixed-point fractional library routines.
+                                                             (line  138)
+* __ussubuta3:                           Fixed-point fractional library routines.
+                                                             (line  148)
+* abort:                                 Portability.        (line   20)
+* abs:                                   Arithmetic.         (line  201)
+* 'abs' and attributes:                  Expressions.        (line   83)
+* absence_set:                           Processor pipeline description.
+                                                             (line  223)
+* 'absM2' instruction pattern:           Standard Names.     (line  541)
+* absolute value:                        Arithmetic.         (line  201)
+* ABS_EXPR:                              Unary and Binary Expressions.
+                                                             (line    6)
+* access to operands:                    Accessors.          (line    6)
+* access to special operands:            Special Accessors.  (line    6)
+* accessors:                             Accessors.          (line    6)
+* ACCUMULATE_OUTGOING_ARGS:              Stack Arguments.    (line   48)
+* 'ACCUMULATE_OUTGOING_ARGS' and stack frames: Function Entry.
+                                                             (line  133)
+* ACCUM_TYPE_SIZE:                       Type Layout.        (line   87)
+* ADA_LONG_TYPE_SIZE:                    Type Layout.        (line   25)
+* Adding a new GIMPLE statement code:    Adding a new GIMPLE statement code.
+                                                             (line    6)
+* ADDITIONAL_REGISTER_NAMES:             Instruction Output. (line   14)
+* 'addM3' instruction pattern:           Standard Names.     (line  260)
+* 'addMODEcc' instruction pattern:       Standard Names.     (line 1063)
+* 'addptrM3' instruction pattern:        Standard Names.     (line  266)
+* address constraints:                   Simple Constraints. (line  162)
+* addressing modes:                      Addressing Modes.   (line    6)
+* address_operand:                       Machine-Independent Predicates.
+                                                             (line   62)
+* address_operand <1>:                   Simple Constraints. (line  166)
+* addr_diff_vec:                         Side Effects.       (line  313)
+* 'addr_diff_vec', length of:            Insn Lengths.       (line   26)
+* ADDR_EXPR:                             Storage References. (line    6)
+* addr_vec:                              Side Effects.       (line  308)
+* 'addr_vec', length of:                 Insn Lengths.       (line   26)
+* ADJUST_FIELD_ALIGN:                    Storage Layout.     (line  190)
+* ADJUST_INSN_LENGTH:                    Insn Lengths.       (line   35)
+* ADJUST_REG_ALLOC_ORDER:                Allocation Order.   (line   22)
+* aggregates as return values:           Aggregate Return.   (line    6)
+* alias:                                 Alias analysis.     (line    6)
+* 'allocate_stack' instruction pattern:  Standard Names.     (line 1377)
+* ALL_REGS:                              Register Classes.   (line   17)
+* alternate entry points:                Insns.              (line  146)
+* anchored addresses:                    Anchored Addresses. (line    6)
+* and:                                   Arithmetic.         (line  159)
+* 'and' and attributes:                  Expressions.        (line   50)
+* 'and', canonicalization of:            Insn Canonicalizations.
+                                                             (line   51)
+* 'andM3' instruction pattern:           Standard Names.     (line  276)
+* ANNOTATE_EXPR:                         Unary and Binary Expressions.
+                                                             (line    6)
+* annotations:                           Annotations.        (line    6)
+* APPLY_RESULT_SIZE:                     Scalar Return.      (line  112)
+* ARGS_GROW_DOWNWARD:                    Frame Layout.       (line   34)
+* argument passing:                      Interface.          (line   36)
+* arguments in registers:                Register Arguments. (line    6)
+* arguments on stack:                    Stack Arguments.    (line    6)
+* ARG_POINTER_CFA_OFFSET:                Frame Layout.       (line  192)
+* ARG_POINTER_REGNUM:                    Frame Registers.    (line   40)
+* 'ARG_POINTER_REGNUM' and virtual registers: Regs and Memory.
+                                                             (line   65)
+* arg_pointer_rtx:                       Frame Registers.    (line  104)
+* arithmetic library:                    Soft float library routines.
+                                                             (line    6)
+* arithmetic shift:                      Arithmetic.         (line  174)
+* arithmetic shift with signed saturation: Arithmetic.       (line  174)
+* arithmetic shift with unsigned saturation: Arithmetic.     (line  174)
+* arithmetic, in RTL:                    Arithmetic.         (line    6)
+* ARITHMETIC_TYPE_P:                     Types for C++.      (line   59)
+* array:                                 Types.              (line    6)
+* ARRAY_RANGE_REF:                       Storage References. (line    6)
+* ARRAY_REF:                             Storage References. (line    6)
+* ARRAY_TYPE:                            Types.              (line    6)
+* ashift:                                Arithmetic.         (line  174)
+* 'ashift' and attributes:               Expressions.        (line   83)
+* ashiftrt:                              Arithmetic.         (line  191)
+* 'ashiftrt' and attributes:             Expressions.        (line   83)
+* 'ashlM3' instruction pattern:          Standard Names.     (line  516)
+* 'ashrM3' instruction pattern:          Standard Names.     (line  526)
+* ASM_APP_OFF:                           File Framework.     (line   76)
+* ASM_APP_ON:                            File Framework.     (line   69)
+* ASM_COMMENT_START:                     File Framework.     (line   64)
+* ASM_DECLARE_FUNCTION_NAME:             Label Output.       (line  108)
+* ASM_DECLARE_FUNCTION_SIZE:             Label Output.       (line  123)
+* ASM_DECLARE_OBJECT_NAME:               Label Output.       (line  136)
+* ASM_DECLARE_REGISTER_GLOBAL:           Label Output.       (line  164)
+* ASM_FINAL_SPEC:                        Driver.             (line   81)
+* ASM_FINISH_DECLARE_OBJECT:             Label Output.       (line  172)
+* ASM_FORMAT_PRIVATE_NAME:               Label Output.       (line  391)
+* asm_fprintf:                           Instruction Output. (line  150)
+* ASM_FPRINTF_EXTENSIONS:                Instruction Output. (line  160)
+* ASM_GENERATE_INTERNAL_LABEL:           Label Output.       (line  375)
+* asm_input:                             Side Effects.       (line  295)
+* 'asm_input' and '/v':                  Flags.              (line   76)
+* ASM_MAYBE_OUTPUT_ENCODED_ADDR_RTX:     Exception Handling. (line   80)
+* asm_noperands:                         Insns.              (line  304)
+* ASM_NO_SKIP_IN_TEXT:                   Alignment Output.   (line   78)
+* 'asm_operands' and '/v':               Flags.              (line   76)
+* 'asm_operands', RTL sharing:           Sharing.            (line   45)
+* 'asm_operands', usage:                 Assembler.          (line    6)
+* ASM_OUTPUT_ADDR_DIFF_ELT:              Dispatch Tables.    (line    8)
+* ASM_OUTPUT_ADDR_VEC_ELT:               Dispatch Tables.    (line   25)
+* ASM_OUTPUT_ALIGN:                      Alignment Output.   (line   85)
+* ASM_OUTPUT_ALIGNED_BSS:                Uninitialized Data. (line   45)
+* ASM_OUTPUT_ALIGNED_COMMON:             Uninitialized Data. (line   29)
+* ASM_OUTPUT_ALIGNED_DECL_COMMON:        Uninitialized Data. (line   36)
+* ASM_OUTPUT_ALIGNED_DECL_LOCAL:         Uninitialized Data. (line   89)
+* ASM_OUTPUT_ALIGNED_LOCAL:              Uninitialized Data. (line   82)
+* ASM_OUTPUT_ALIGN_WITH_NOP:             Alignment Output.   (line   90)
+* ASM_OUTPUT_ASCII:                      Data Output.        (line   50)
+* ASM_OUTPUT_CASE_END:                   Dispatch Tables.    (line   50)
+* ASM_OUTPUT_CASE_LABEL:                 Dispatch Tables.    (line   37)
+* ASM_OUTPUT_COMMON:                     Uninitialized Data. (line    9)
+* ASM_OUTPUT_DEBUG_LABEL:                Label Output.       (line  363)
+* ASM_OUTPUT_DEF:                        Label Output.       (line  412)
+* ASM_OUTPUT_DEF_FROM_DECLS:             Label Output.       (line  419)
+* ASM_OUTPUT_DWARF_DELTA:                SDB and DWARF.      (line   73)
+* ASM_OUTPUT_DWARF_OFFSET:               SDB and DWARF.      (line   82)
+* ASM_OUTPUT_DWARF_PCREL:                SDB and DWARF.      (line   88)
+* ASM_OUTPUT_DWARF_TABLE_REF:            SDB and DWARF.      (line   93)
+* ASM_OUTPUT_DWARF_VMS_DELTA:            SDB and DWARF.      (line   77)
+* ASM_OUTPUT_EXTERNAL:                   Label Output.       (line  292)
+* ASM_OUTPUT_FDESC:                      Data Output.        (line   59)
+* ASM_OUTPUT_FUNCTION_LABEL:             Label Output.       (line   16)
+* ASM_OUTPUT_INTERNAL_LABEL:             Label Output.       (line   27)
+* ASM_OUTPUT_LABEL:                      Label Output.       (line    8)
+* ASM_OUTPUT_LABELREF:                   Label Output.       (line  314)
+* ASM_OUTPUT_LABEL_REF:                  Label Output.       (line  336)
+* ASM_OUTPUT_LOCAL:                      Uninitialized Data. (line   69)
+* ASM_OUTPUT_MAX_SKIP_ALIGN:             Alignment Output.   (line   94)
+* ASM_OUTPUT_MEASURED_SIZE:              Label Output.       (line   51)
+* ASM_OUTPUT_OPCODE:                     Instruction Output. (line   35)
+* ASM_OUTPUT_POOL_EPILOGUE:              Data Output.        (line  108)
+* ASM_OUTPUT_POOL_PROLOGUE:              Data Output.        (line   72)
+* ASM_OUTPUT_REG_POP:                    Instruction Output. (line  206)
+* ASM_OUTPUT_REG_PUSH:                   Instruction Output. (line  201)
+* ASM_OUTPUT_SIZE_DIRECTIVE:             Label Output.       (line   45)
+* ASM_OUTPUT_SKIP:                       Alignment Output.   (line   72)
+* ASM_OUTPUT_SOURCE_FILENAME:            File Framework.     (line   83)
+* ASM_OUTPUT_SPECIAL_POOL_ENTRY:         Data Output.        (line   83)
+* ASM_OUTPUT_SYMBOL_REF:                 Label Output.       (line  329)
+* ASM_OUTPUT_TYPE_DIRECTIVE:             Label Output.       (line   98)
+* ASM_OUTPUT_WEAKREF:                    Label Output.       (line  224)
+* ASM_OUTPUT_WEAK_ALIAS:                 Label Output.       (line  438)
+* ASM_PREFERRED_EH_DATA_FORMAT:          Exception Handling. (line   66)
+* ASM_SPEC:                              Driver.             (line   73)
+* ASM_STABD_OP:                          DBX Options.        (line   34)
+* ASM_STABN_OP:                          DBX Options.        (line   41)
+* ASM_STABS_OP:                          DBX Options.        (line   28)
+* ASM_WEAKEN_DECL:                       Label Output.       (line  216)
+* ASM_WEAKEN_LABEL:                      Label Output.       (line  203)
+* assembler format:                      File Framework.     (line    6)
+* assembler instructions in RTL:         Assembler.          (line    6)
+* ASSEMBLER_DIALECT:                     Instruction Output. (line  172)
+* assemble_name:                         Label Output.       (line    8)
+* assemble_name_raw:                     Label Output.       (line   27)
+* assigning attribute values to insns:   Tagging Insns.      (line    6)
+* ASSUME_EXTENDED_UNWIND_CONTEXT:        Frame Registers.    (line  165)
+* asterisk in template:                  Output Statement.   (line   29)
+* AS_NEEDS_DASH_FOR_PIPED_INPUT:         Driver.             (line   88)
+* 'atan2M3' instruction pattern:         Standard Names.     (line  624)
+* atomic:                                GTY Options.        (line  270)
+* 'atomic_addMODE' instruction pattern:  Standard Names.     (line 1788)
+* 'atomic_add_fetchMODE' instruction pattern: Standard Names.
+                                                             (line 1819)
+* 'atomic_andMODE' instruction pattern:  Standard Names.     (line 1788)
+* 'atomic_and_fetchMODE' instruction pattern: Standard Names.
+                                                             (line 1819)
+* 'atomic_compare_and_swapMODE' instruction pattern: Standard Names.
+                                                             (line 1724)
+* 'atomic_exchangeMODE' instruction pattern: Standard Names. (line 1776)
+* 'atomic_fetch_addMODE' instruction pattern: Standard Names.
+                                                             (line 1803)
+* 'atomic_fetch_andMODE' instruction pattern: Standard Names.
+                                                             (line 1803)
+* 'atomic_fetch_nandMODE' instruction pattern: Standard Names.
+                                                             (line 1803)
+* 'atomic_fetch_orMODE' instruction pattern: Standard Names. (line 1803)
+* 'atomic_fetch_subMODE' instruction pattern: Standard Names.
+                                                             (line 1803)
+* 'atomic_fetch_xorMODE' instruction pattern: Standard Names.
+                                                             (line 1803)
+* 'atomic_loadMODE' instruction pattern: Standard Names.     (line 1755)
+* 'atomic_nandMODE' instruction pattern: Standard Names.     (line 1788)
+* 'atomic_nand_fetchMODE' instruction pattern: Standard Names.
+                                                             (line 1819)
+* 'atomic_orMODE' instruction pattern:   Standard Names.     (line 1788)
+* 'atomic_or_fetchMODE' instruction pattern: Standard Names. (line 1819)
+* 'atomic_storeMODE' instruction pattern: Standard Names.    (line 1765)
+* 'atomic_subMODE' instruction pattern:  Standard Names.     (line 1788)
+* 'atomic_sub_fetchMODE' instruction pattern: Standard Names.
+                                                             (line 1819)
+* 'atomic_test_and_set' instruction pattern: Standard Names. (line 1837)
+* 'atomic_xorMODE' instruction pattern:  Standard Names.     (line 1788)
+* 'atomic_xor_fetchMODE' instruction pattern: Standard Names.
+                                                             (line 1819)
+* attr:                                  Expressions.        (line  163)
+* attr <1>:                              Tagging Insns.      (line   54)
+* attribute expressions:                 Expressions.        (line    6)
+* attribute specifications:              Attr Example.       (line    6)
+* attribute specifications example:      Attr Example.       (line    6)
+* attributes:                            Attributes.         (line    6)
+* attributes, defining:                  Defining Attributes.
+                                                             (line    6)
+* attributes, target-specific:           Target Attributes.  (line    6)
+* ATTRIBUTE_ALIGNED_VALUE:               Storage Layout.     (line  172)
+* attr_flag:                             Expressions.        (line  138)
+* autoincrement addressing, availability: Portability.       (line   20)
+* autoincrement/decrement addressing:    Simple Constraints. (line   30)
+* automata_option:                       Processor pipeline description.
+                                                             (line  304)
+* automaton based pipeline description:  Processor pipeline description.
+                                                             (line    6)
+* automaton based pipeline description <1>: Processor pipeline description.
+                                                             (line   49)
+* automaton based scheduler:             Processor pipeline description.
+                                                             (line    6)
+* AVOID_CCMODE_COPIES:                   Values in Registers.
+                                                             (line  150)
+* backslash:                             Output Template.    (line   46)
+* barrier:                               Insns.              (line  176)
+* 'barrier' and '/f':                    Flags.              (line  107)
+* 'barrier' and '/v':                    Flags.              (line   44)
+* BASE_REG_CLASS:                        Register Classes.   (line  111)
+* basic block:                           Basic Blocks.       (line    6)
+* Basic Statements:                      Basic Statements.   (line    6)
+* basic-block.h:                         Control Flow.       (line    6)
+* basic_block:                           Basic Blocks.       (line    6)
+* BASIC_BLOCK:                           Basic Blocks.       (line   14)
+* BB_HEAD, BB_END:                       Maintaining the CFG.
+                                                             (line   76)
+* bb_seq:                                GIMPLE sequences.   (line   72)
+* BIGGEST_ALIGNMENT:                     Storage Layout.     (line  162)
+* BIGGEST_FIELD_ALIGNMENT:               Storage Layout.     (line  183)
+* BImode:                                Machine Modes.      (line   22)
+* BIND_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* BINFO_TYPE:                            Classes.            (line    6)
+* bit-fields:                            Bit-Fields.         (line    6)
+* BITFIELD_NBYTES_LIMITED:               Storage Layout.     (line  393)
+* BITS_BIG_ENDIAN:                       Storage Layout.     (line   11)
+* 'BITS_BIG_ENDIAN', effect on 'sign_extract': Bit-Fields.   (line    8)
+* BITS_PER_UNIT:                         Machine Modes.      (line  345)
+* BITS_PER_WORD:                         Storage Layout.     (line   50)
+* bitwise complement:                    Arithmetic.         (line  155)
+* bitwise exclusive-or:                  Arithmetic.         (line  169)
+* bitwise inclusive-or:                  Arithmetic.         (line  164)
+* bitwise logical-and:                   Arithmetic.         (line  159)
+* BIT_AND_EXPR:                          Unary and Binary Expressions.
+                                                             (line    6)
+* BIT_IOR_EXPR:                          Unary and Binary Expressions.
+                                                             (line    6)
+* BIT_NOT_EXPR:                          Unary and Binary Expressions.
+                                                             (line    6)
+* BIT_XOR_EXPR:                          Unary and Binary Expressions.
+                                                             (line    6)
+* BLKmode:                               Machine Modes.      (line  185)
+* 'BLKmode', and function return values: Calls.              (line   23)
+* 'blockage' instruction pattern:        Standard Names.     (line 1579)
+* Blocks:                                Blocks.             (line    6)
+* BLOCK_FOR_INSN, gimple_bb:             Maintaining the CFG.
+                                                             (line   28)
+* BLOCK_REG_PADDING:                     Register Arguments. (line  228)
+* bool:                                  Misc.               (line  891)
+* BOOLEAN_TYPE:                          Types.              (line    6)
+* BOOL_TYPE_SIZE:                        Type Layout.        (line   43)
+* branch prediction:                     Profile information.
+                                                             (line   24)
+* BRANCH_COST:                           Costs.              (line  104)
+* break_out_memory_refs:                 Addressing Modes.   (line  134)
+* BREAK_STMT:                            Statements for C++. (line    6)
+* BSS_SECTION_ASM_OP:                    Sections.           (line   67)
+* bswap:                                 Arithmetic.         (line  247)
+* 'bswapM2' instruction pattern:         Standard Names.     (line  534)
+* 'btruncM2' instruction pattern:        Standard Names.     (line  642)
+* build0:                                Macros and Functions.
+                                                             (line   16)
+* build1:                                Macros and Functions.
+                                                             (line   17)
+* build2:                                Macros and Functions.
+                                                             (line   18)
+* build3:                                Macros and Functions.
+                                                             (line   19)
+* build4:                                Macros and Functions.
+                                                             (line   20)
+* build5:                                Macros and Functions.
+                                                             (line   21)
+* build6:                                Macros and Functions.
+                                                             (line   22)
+* 'builtin_longjmp' instruction pattern: Standard Names.     (line 1475)
+* 'builtin_setjmp_receiver' instruction pattern: Standard Names.
+                                                             (line 1465)
+* 'builtin_setjmp_setup' instruction pattern: Standard Names.
+                                                             (line 1454)
+* BYTES_BIG_ENDIAN:                      Storage Layout.     (line   23)
+* 'BYTES_BIG_ENDIAN', effect on 'subreg': Regs and Memory.   (line  219)
+* byte_mode:                             Machine Modes.      (line  358)
+* C statements for assembler output:     Output Statement.   (line    6)
+* call:                                  Flags.              (line  221)
+* call <1>:                              Side Effects.       (line   92)
+* 'call' instruction pattern:            Standard Names.     (line 1120)
+* 'call' usage:                          Calls.              (line   10)
+* 'call', in 'call_insn':                Flags.              (line   33)
+* 'call', in 'mem':                      Flags.              (line   81)
+* call-clobbered register:               Register Basics.    (line   35)
+* call-clobbered register <1>:           Register Basics.    (line   46)
+* call-clobbered register <2>:           Register Basics.    (line   53)
+* call-saved register:                   Register Basics.    (line   35)
+* call-saved register <1>:               Register Basics.    (line   46)
+* call-saved register <2>:               Register Basics.    (line   53)
+* call-used register:                    Register Basics.    (line   35)
+* call-used register <1>:                Register Basics.    (line   46)
+* call-used register <2>:                Register Basics.    (line   53)
+* CALLER_SAVE_PROFITABLE:                Caller Saves.       (line   10)
+* calling conventions:                   Stack and Calling.  (line    6)
+* calling functions in RTL:              Calls.              (line    6)
+* CALL_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* call_insn:                             Insns.              (line   95)
+* 'call_insn' and '/c':                  Flags.              (line   33)
+* 'call_insn' and '/f':                  Flags.              (line  107)
+* 'call_insn' and '/i':                  Flags.              (line   24)
+* 'call_insn' and '/j':                  Flags.              (line  161)
+* 'call_insn' and '/s':                  Flags.              (line   49)
+* 'call_insn' and '/s' <1>:              Flags.              (line  148)
+* 'call_insn' and '/u':                  Flags.              (line   19)
+* 'call_insn' and '/u' <1>:              Flags.              (line   39)
+* 'call_insn' and '/u' or '/i':          Flags.              (line   29)
+* 'call_insn' and '/v':                  Flags.              (line   44)
+* CALL_INSN_FUNCTION_USAGE:              Insns.              (line  101)
+* 'call_pop' instruction pattern:        Standard Names.     (line 1148)
+* CALL_POPS_ARGS:                        Stack Arguments.    (line  132)
+* CALL_REALLY_USED_REGISTERS:            Register Basics.    (line   45)
+* CALL_USED_REGISTERS:                   Register Basics.    (line   34)
+* call_used_regs:                        Register Basics.    (line   59)
+* 'call_value' instruction pattern:      Standard Names.     (line 1140)
+* 'call_value_pop' instruction pattern:  Standard Names.     (line 1148)
+* canadian:                              Configure Terms.    (line    6)
+* CANNOT_CHANGE_MODE_CLASS:              Register Classes.   (line  533)
+* 'CANNOT_CHANGE_MODE_CLASS' and subreg semantics: Regs and Memory.
+                                                             (line  276)
+* canonicalization of instructions:      Insn Canonicalizations.
+                                                             (line    6)
+* 'canonicalize_funcptr_for_compare' instruction pattern: Standard Names.
+                                                             (line 1309)
+* can_create_pseudo_p:                   Standard Names.     (line   75)
+* can_fallthru:                          Basic Blocks.       (line   67)
+* 'casesi' instruction pattern:          Standard Names.     (line 1241)
+* CASE_VECTOR_MODE:                      Misc.               (line   26)
+* CASE_VECTOR_PC_RELATIVE:               Misc.               (line   39)
+* CASE_VECTOR_SHORTEN_MODE:              Misc.               (line   30)
+* 'cbranchMODE4' instruction pattern:    Standard Names.     (line 1109)
+* cc0:                                   Regs and Memory.    (line  303)
+* cc0 <1>:                               CC0 Condition Codes.
+                                                             (line    6)
+* 'cc0', RTL sharing:                    Sharing.            (line   27)
+* cc0_rtx:                               Regs and Memory.    (line  329)
+* CC1PLUS_SPEC:                          Driver.             (line   63)
+* CC1_SPEC:                              Driver.             (line   55)
+* CCmode:                                Machine Modes.      (line  178)
+* CCmode <1>:                            MODE_CC Condition Codes.
+                                                             (line    6)
+* cc_status:                             CC0 Condition Codes.
+                                                             (line    6)
+* CC_STATUS_MDEP:                        CC0 Condition Codes.
+                                                             (line   16)
+* CC_STATUS_MDEP_INIT:                   CC0 Condition Codes.
+                                                             (line   22)
+* CDImode:                               Machine Modes.      (line  204)
+* 'ceilM2' instruction pattern:          Standard Names.     (line  658)
+* CEIL_DIV_EXPR:                         Unary and Binary Expressions.
+                                                             (line    6)
+* CEIL_MOD_EXPR:                         Unary and Binary Expressions.
+                                                             (line    6)
+* CFA_FRAME_BASE_OFFSET:                 Frame Layout.       (line  224)
+* CFG verification:                      Maintaining the CFG.
+                                                             (line  117)
+* CFG, Control Flow Graph:               Control Flow.       (line    6)
+* cfghooks.h:                            Maintaining the CFG.
+                                                             (line    6)
+* cgraph_finalize_function:              Parsing pass.       (line   51)
+* chain_circular:                        GTY Options.        (line  209)
+* chain_next:                            GTY Options.        (line  209)
+* chain_prev:                            GTY Options.        (line  209)
+* change_address:                        Standard Names.     (line   47)
+* CHAR_TYPE_SIZE:                        Type Layout.        (line   38)
+* 'check_stack' instruction pattern:     Standard Names.     (line 1395)
+* CHImode:                               Machine Modes.      (line  204)
+* CILK_PLUS:                             Cilk Plus Transformation.
+                                                             (line    6)
+* class definitions, register:           Register Classes.   (line    6)
+* class preference constraints:          Class Preferences.  (line    6)
+* class, scope:                          Classes.            (line    6)
+* classes of RTX codes:                  RTL Classes.        (line    6)
+* CLASSTYPE_DECLARED_CLASS:              Classes.            (line    6)
+* CLASSTYPE_HAS_MUTABLE:                 Classes.            (line   85)
+* CLASSTYPE_NON_POD_P:                   Classes.            (line   90)
+* CLASS_MAX_NREGS:                       Register Classes.   (line  521)
+* CLASS_TYPE_P:                          Types for C++.      (line   63)
+* Cleanups:                              Cleanups.           (line    6)
+* CLEANUP_DECL:                          Statements for C++. (line    6)
+* CLEANUP_EXPR:                          Statements for C++. (line    6)
+* CLEANUP_POINT_EXPR:                    Unary and Binary Expressions.
+                                                             (line    6)
+* CLEANUP_STMT:                          Statements for C++. (line    6)
+* CLEAR_BY_PIECES_P:                     Costs.              (line  187)
+* 'clear_cache' instruction pattern:     Standard Names.     (line 1900)
+* CLEAR_INSN_CACHE:                      Trampolines.        (line   98)
+* CLEAR_RATIO:                           Costs.              (line  175)
+* clobber:                               Side Effects.       (line  106)
+* clrsb:                                 Arithmetic.         (line  216)
+* clz:                                   Arithmetic.         (line  223)
+* 'clzM2' instruction pattern:           Standard Names.     (line  723)
+* CLZ_DEFINED_VALUE_AT_ZERO:             Misc.               (line  304)
+* 'cmpmemM' instruction pattern:         Standard Names.     (line  863)
+* 'cmpstrM' instruction pattern:         Standard Names.     (line  842)
+* 'cmpstrnM' instruction pattern:        Standard Names.     (line  829)
+* code generation RTL sequences:         Expander Definitions.
+                                                             (line    6)
+* code iterators in '.md' files:         Code Iterators.     (line    6)
+* codes, RTL expression:                 RTL Objects.        (line   47)
+* code_label:                            Insns.              (line  125)
+* CODE_LABEL:                            Basic Blocks.       (line   50)
+* 'code_label' and '/i':                 Flags.              (line   59)
+* 'code_label' and '/v':                 Flags.              (line   44)
+* CODE_LABEL_NUMBER:                     Insns.              (line  125)
+* COImode:                               Machine Modes.      (line  204)
+* COLLECT2_HOST_INITIALIZATION:          Host Misc.          (line   32)
+* COLLECT_EXPORT_LIST:                   Misc.               (line  791)
+* COLLECT_SHARED_FINI_FUNC:              Macros for Initialization.
+                                                             (line   43)
+* COLLECT_SHARED_INIT_FUNC:              Macros for Initialization.
+                                                             (line   32)
+* commit_edge_insertions:                Maintaining the CFG.
+                                                             (line  105)
+* compare:                               Arithmetic.         (line   46)
+* 'compare', canonicalization of:        Insn Canonicalizations.
+                                                             (line   36)
+* comparison_operator:                   Machine-Independent Predicates.
+                                                             (line  110)
+* compiler passes and files:             Passes.             (line    6)
+* complement, bitwise:                   Arithmetic.         (line  155)
+* COMPLEX_CST:                           Constant expressions.
+                                                             (line    6)
+* COMPLEX_EXPR:                          Unary and Binary Expressions.
+                                                             (line    6)
+* COMPLEX_TYPE:                          Types.              (line    6)
+* COMPONENT_REF:                         Storage References. (line    6)
+* Compound Expressions:                  Compound Expressions.
+                                                             (line    6)
+* Compound Lvalues:                      Compound Lvalues.   (line    6)
+* COMPOUND_EXPR:                         Unary and Binary Expressions.
+                                                             (line    6)
+* COMPOUND_LITERAL_EXPR:                 Unary and Binary Expressions.
+                                                             (line    6)
+* COMPOUND_LITERAL_EXPR_DECL:            Unary and Binary Expressions.
+                                                             (line  377)
+* COMPOUND_LITERAL_EXPR_DECL_EXPR:       Unary and Binary Expressions.
+                                                             (line  377)
+* computed jump:                         Edges.              (line  127)
+* computing the length of an insn:       Insn Lengths.       (line    6)
+* concat:                                Regs and Memory.    (line  381)
+* concatn:                               Regs and Memory.    (line  387)
+* cond:                                  Comparisons.        (line   90)
+* 'cond' and attributes:                 Expressions.        (line   37)
+* condition code register:               Regs and Memory.    (line  303)
+* condition code status:                 Condition Code.     (line    6)
+* condition codes:                       Comparisons.        (line   20)
+* conditional execution:                 Conditional Execution.
+                                                             (line    6)
+* Conditional Expressions:               Conditional Expressions.
+                                                             (line    6)
+* conditions, in patterns:               Patterns.           (line   43)
+* cond_exec:                             Side Effects.       (line  253)
+* COND_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* configuration file:                    Filesystem.         (line    6)
+* configuration file <1>:                Host Misc.          (line    6)
+* configure terms:                       Configure Terms.    (line    6)
+* CONJ_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* const:                                 Constants.          (line  109)
+* const0_rtx:                            Constants.          (line   21)
+* CONST0_RTX:                            Constants.          (line  129)
+* const1_rtx:                            Constants.          (line   21)
+* CONST1_RTX:                            Constants.          (line  129)
+* const2_rtx:                            Constants.          (line   21)
+* CONST2_RTX:                            Constants.          (line  129)
+* constant attributes:                   Constant Attributes.
+                                                             (line    6)
+* constant definitions:                  Constant Definitions.
+                                                             (line    6)
+* constants in constraints:              Simple Constraints. (line   68)
+* CONSTANT_ADDRESS_P:                    Addressing Modes.   (line   28)
+* CONSTANT_ALIGNMENT:                    Storage Layout.     (line  236)
+* CONSTANT_P:                            Addressing Modes.   (line   35)
+* CONSTANT_POOL_ADDRESS_P:               Flags.              (line   10)
+* CONSTANT_POOL_BEFORE_FUNCTION:         Data Output.        (line   64)
+* constm1_rtx:                           Constants.          (line   21)
+* constraint modifier characters:        Modifiers.          (line    6)
+* constraint, matching:                  Simple Constraints. (line  140)
+* constraints:                           Constraints.        (line    6)
+* constraints, defining:                 Define Constraints. (line    6)
+* constraints, defining, obsolete method: Old Constraints.   (line    6)
+* constraints, machine specific:         Machine Constraints.
+                                                             (line    6)
+* constraints, testing:                  C Constraint Interface.
+                                                             (line    6)
+* CONSTRAINT_LEN:                        Old Constraints.    (line   11)
+* constraint_num:                        C Constraint Interface.
+                                                             (line   37)
+* constraint_satisfied_p:                C Constraint Interface.
+                                                             (line   52)
+* CONSTRUCTOR:                           Unary and Binary Expressions.
+                                                             (line    6)
+* constructors, automatic calls:         Collect2.           (line   15)
+* constructors, output of:               Initialization.     (line    6)
+* CONST_DECL:                            Declarations.       (line    6)
+* const_double:                          Constants.          (line   37)
+* 'const_double', RTL sharing:           Sharing.            (line   29)
+* CONST_DOUBLE_LOW:                      Constants.          (line   49)
+* CONST_DOUBLE_OK_FOR_CONSTRAINT_P:      Old Constraints.    (line   66)
+* CONST_DOUBLE_OK_FOR_LETTER_P:          Old Constraints.    (line   51)
+* const_double_operand:                  Machine-Independent Predicates.
+                                                             (line   20)
+* const_fixed:                           Constants.          (line   62)
+* const_int:                             Constants.          (line    8)
+* 'const_int' and attribute tests:       Expressions.        (line   47)
+* 'const_int' and attributes:            Expressions.        (line   10)
+* 'const_int', RTL sharing:              Sharing.            (line   23)
+* const_int_operand:                     Machine-Independent Predicates.
+                                                             (line   15)
+* CONST_OK_FOR_CONSTRAINT_P:             Old Constraints.    (line   46)
+* CONST_OK_FOR_LETTER_P:                 Old Constraints.    (line   38)
+* const_string:                          Constants.          (line   81)
+* 'const_string' and attributes:         Expressions.        (line   20)
+* const_true_rtx:                        Constants.          (line   31)
+* const_vector:                          Constants.          (line   69)
+* 'const_vector', RTL sharing:           Sharing.            (line   32)
+* container:                             Containers.         (line    6)
+* CONTINUE_STMT:                         Statements for C++. (line    6)
+* contributors:                          Contributors.       (line    6)
+* controlling register usage:            Register Basics.    (line   73)
+* controlling the compilation driver:    Driver.             (line    6)
+* conventions, run-time:                 Interface.          (line    6)
+* conversions:                           Conversions.        (line    6)
+* CONVERT_EXPR:                          Unary and Binary Expressions.
+                                                             (line    6)
+* 'copysignM3' instruction pattern:      Standard Names.     (line  704)
+* copy_rtx:                              Addressing Modes.   (line  189)
+* copy_rtx_if_shared:                    Sharing.            (line   64)
+* 'cosM2' instruction pattern:           Standard Names.     (line  570)
+* costs of instructions:                 Costs.              (line    6)
+* CPLUSPLUS_CPP_SPEC:                    Driver.             (line   50)
+* CPP_SPEC:                              Driver.             (line   43)
+* CP_INTEGRAL_TYPE:                      Types for C++.      (line   55)
+* cp_namespace_decls:                    Namespaces.         (line   49)
+* CP_TYPE_CONST_NON_VOLATILE_P:          Types for C++.      (line   33)
+* CP_TYPE_CONST_P:                       Types for C++.      (line   24)
+* cp_type_quals:                         Types for C++.      (line    6)
+* cp_type_quals <1>:                     Types for C++.      (line   16)
+* CP_TYPE_RESTRICT_P:                    Types for C++.      (line   30)
+* CP_TYPE_VOLATILE_P:                    Types for C++.      (line   27)
+* CQImode:                               Machine Modes.      (line  204)
+* cross compilation and floating point:  Floating Point.     (line    6)
+* crtl->args.pops_args:                  Function Entry.     (line  104)
+* crtl->args.pretend_args_size:          Function Entry.     (line  110)
+* crtl->outgoing_args_size:              Stack Arguments.    (line   48)
+* CRTSTUFF_T_CFLAGS:                     Target Fragment.    (line   15)
+* CRTSTUFF_T_CFLAGS_S:                   Target Fragment.    (line   19)
+* CRT_CALL_STATIC_FUNCTION:              Sections.           (line  120)
+* CSImode:                               Machine Modes.      (line  204)
+* 'cstoreMODE4' instruction pattern:     Standard Names.     (line 1070)
+* CTImode:                               Machine Modes.      (line  204)
+* 'ctrapMM4' instruction pattern:        Standard Names.     (line 1547)
+* ctz:                                   Arithmetic.         (line  231)
+* 'ctzM2' instruction pattern:           Standard Names.     (line  732)
+* CTZ_DEFINED_VALUE_AT_ZERO:             Misc.               (line  305)
+* CUMULATIVE_ARGS:                       Register Arguments. (line  126)
+* current_function_is_leaf:              Leaf Functions.     (line   50)
+* current_function_uses_only_leaf_regs:  Leaf Functions.     (line   50)
+* current_insn_predicate:                Conditional Execution.
+                                                             (line   27)
+* C_COMMON_OVERRIDE_OPTIONS:             Run-time Target.    (line  136)
+* c_register_pragma:                     Misc.               (line  407)
+* c_register_pragma_with_expansion:      Misc.               (line  409)
+* DAmode:                                Machine Modes.      (line  154)
+* data bypass:                           Processor pipeline description.
+                                                             (line  105)
+* data bypass <1>:                       Processor pipeline description.
+                                                             (line  196)
+* data dependence delays:                Processor pipeline description.
+                                                             (line    6)
+* Data Dependency Analysis:              Dependency analysis.
+                                                             (line    6)
+* data structures:                       Per-Function Data.  (line    6)
+* DATA_ABI_ALIGNMENT:                    Storage Layout.     (line  228)
+* DATA_ALIGNMENT:                        Storage Layout.     (line  215)
+* DATA_SECTION_ASM_OP:                   Sections.           (line   52)
+* DBR_OUTPUT_SEQEND:                     Instruction Output. (line  133)
+* dbr_sequence_length:                   Instruction Output. (line  133)
+* DBX_BLOCKS_FUNCTION_RELATIVE:          DBX Options.        (line  100)
+* DBX_CONTIN_CHAR:                       DBX Options.        (line   63)
+* DBX_CONTIN_LENGTH:                     DBX Options.        (line   53)
+* DBX_DEBUGGING_INFO:                    DBX Options.        (line    8)
+* DBX_FUNCTION_FIRST:                    DBX Options.        (line   94)
+* DBX_LINES_FUNCTION_RELATIVE:           DBX Options.        (line  106)
+* DBX_NO_XREFS:                          DBX Options.        (line   47)
+* DBX_OUTPUT_MAIN_SOURCE_FILENAME:       File Names and DBX. (line    8)
+* DBX_OUTPUT_MAIN_SOURCE_FILE_END:       File Names and DBX. (line   33)
+* DBX_OUTPUT_NULL_N_SO_AT_MAIN_SOURCE_FILE_END: File Names and DBX.
+                                                             (line   41)
+* DBX_OUTPUT_SOURCE_LINE:                DBX Hooks.          (line    8)
+* DBX_REGISTER_NUMBER:                   All Debuggers.      (line    8)
+* DBX_REGPARM_STABS_CODE:                DBX Options.        (line   84)
+* DBX_REGPARM_STABS_LETTER:              DBX Options.        (line   89)
+* DBX_STATIC_CONST_VAR_CODE:             DBX Options.        (line   79)
+* DBX_STATIC_STAB_DATA_SECTION:          DBX Options.        (line   70)
+* DBX_TYPE_DECL_STABS_CODE:              DBX Options.        (line   75)
+* DBX_USE_BINCL:                         DBX Options.        (line  112)
+* DCmode:                                Machine Modes.      (line  199)
+* DDmode:                                Machine Modes.      (line   93)
+* De Morgan's law:                       Insn Canonicalizations.
+                                                             (line   51)
+* dead_or_set_p:                         define_peephole.    (line   65)
+* DEBUGGER_ARG_OFFSET:                   All Debuggers.      (line   36)
+* DEBUGGER_AUTO_OFFSET:                  All Debuggers.      (line   27)
+* debug_expr:                            Debug Information.  (line   22)
+* DEBUG_EXPR_DECL:                       Declarations.       (line    6)
+* debug_insn:                            Insns.              (line  236)
+* DEBUG_SYMS_TEXT:                       DBX Options.        (line   24)
+* decimal float library:                 Decimal float library routines.
+                                                             (line    6)
+* declaration:                           Declarations.       (line    6)
+* declarations, RTL:                     RTL Declarations.   (line    6)
+* DECLARE_LIBRARY_RENAMES:               Library Calls.      (line    8)
+* DECL_ALIGN:                            Declarations.       (line    6)
+* DECL_ANTICIPATED:                      Functions for C++.  (line   42)
+* DECL_ARGUMENTS:                        Function Basics.    (line   36)
+* DECL_ARRAY_DELETE_OPERATOR_P:          Functions for C++.  (line  158)
+* DECL_ARTIFICIAL:                       Working with declarations.
+                                                             (line   24)
+* DECL_ARTIFICIAL <1>:                   Function Basics.    (line    6)
+* DECL_ARTIFICIAL <2>:                   Function Properties.
+                                                             (line   47)
+* DECL_ASSEMBLER_NAME:                   Function Basics.    (line    6)
+* DECL_ASSEMBLER_NAME <1>:               Function Basics.    (line   19)
+* DECL_ATTRIBUTES:                       Attributes.         (line   21)
+* DECL_BASE_CONSTRUCTOR_P:               Functions for C++.  (line   88)
+* DECL_COMPLETE_CONSTRUCTOR_P:           Functions for C++.  (line   84)
+* DECL_COMPLETE_DESTRUCTOR_P:            Functions for C++.  (line   98)
+* DECL_CONSTRUCTOR_P:                    Functions for C++.  (line   77)
+* DECL_CONST_MEMFUNC_P:                  Functions for C++.  (line   71)
+* DECL_CONTEXT:                          Namespaces.         (line   31)
+* DECL_CONV_FN_P:                        Functions for C++.  (line  105)
+* DECL_COPY_CONSTRUCTOR_P:               Functions for C++.  (line   92)
+* DECL_DESTRUCTOR_P:                     Functions for C++.  (line   95)
+* DECL_EXTERNAL:                         Declarations.       (line    6)
+* DECL_EXTERNAL <1>:                     Function Properties.
+                                                             (line   25)
+* DECL_EXTERN_C_FUNCTION_P:              Functions for C++.  (line   46)
+* DECL_FUNCTION_MEMBER_P:                Functions for C++.  (line   61)
+* DECL_FUNCTION_SPECIFIC_OPTIMIZATION:   Function Basics.    (line    6)
+* DECL_FUNCTION_SPECIFIC_OPTIMIZATION <1>: Function Properties.
+                                                             (line   61)
+* DECL_FUNCTION_SPECIFIC_TARGET:         Function Basics.    (line    6)
+* DECL_FUNCTION_SPECIFIC_TARGET <1>:     Function Properties.
+                                                             (line   55)
+* DECL_GLOBAL_CTOR_P:                    Functions for C++.  (line  108)
+* DECL_GLOBAL_DTOR_P:                    Functions for C++.  (line  112)
+* DECL_INITIAL:                          Declarations.       (line    6)
+* DECL_INITIAL <1>:                      Function Basics.    (line   51)
+* DECL_LINKONCE_P:                       Functions for C++.  (line   50)
+* DECL_LOCAL_FUNCTION_P:                 Functions for C++.  (line   38)
+* DECL_MAIN_P:                           Functions for C++.  (line   34)
+* DECL_NAME:                             Working with declarations.
+                                                             (line    7)
+* DECL_NAME <1>:                         Function Basics.    (line    6)
+* DECL_NAME <2>:                         Function Basics.    (line    9)
+* DECL_NAME <3>:                         Namespaces.         (line   20)
+* DECL_NAMESPACE_ALIAS:                  Namespaces.         (line   35)
+* DECL_NAMESPACE_STD_P:                  Namespaces.         (line   45)
+* DECL_NONCONVERTING_P:                  Functions for C++.  (line   80)
+* DECL_NONSTATIC_MEMBER_FUNCTION_P:      Functions for C++.  (line   68)
+* DECL_NON_THUNK_FUNCTION_P:             Functions for C++.  (line  138)
+* DECL_OVERLOADED_OPERATOR_P:            Functions for C++.  (line  102)
+* DECL_PURE_P:                           Function Properties.
+                                                             (line   40)
+* DECL_RESULT:                           Function Basics.    (line   41)
+* DECL_SAVED_TREE:                       Function Basics.    (line   44)
+* DECL_SIZE:                             Declarations.       (line    6)
+* DECL_STATIC_FUNCTION_P:                Functions for C++.  (line   65)
+* DECL_STMT:                             Statements for C++. (line    6)
+* DECL_STMT_DECL:                        Statements for C++. (line    6)
+* DECL_THUNK_P:                          Functions for C++.  (line  116)
+* DECL_VIRTUAL_P:                        Function Properties.
+                                                             (line   44)
+* DECL_VOLATILE_MEMFUNC_P:               Functions for C++.  (line   74)
+* 'decrement_and_branch_until_zero' instruction pattern: Standard Names.
+                                                             (line 1278)
+* default:                               GTY Options.        (line   82)
+* default_file_start:                    File Framework.     (line    8)
+* DEFAULT_GDB_EXTENSIONS:                DBX Options.        (line   17)
+* DEFAULT_PCC_STRUCT_RETURN:             Aggregate Return.   (line   34)
+* DEFAULT_SIGNED_CHAR:                   Type Layout.        (line  160)
+* define_address_constraint:             Define Constraints. (line   99)
+* define_asm_attributes:                 Tagging Insns.      (line   73)
+* define_attr:                           Defining Attributes.
+                                                             (line    6)
+* define_automaton:                      Processor pipeline description.
+                                                             (line   53)
+* define_bypass:                         Processor pipeline description.
+                                                             (line  196)
+* define_code_attr:                      Code Iterators.     (line    6)
+* define_code_iterator:                  Code Iterators.     (line    6)
+* define_cond_exec:                      Conditional Execution.
+                                                             (line   13)
+* define_constants:                      Constant Definitions.
+                                                             (line    6)
+* define_constraint:                     Define Constraints. (line   45)
+* define_cpu_unit:                       Processor pipeline description.
+                                                             (line   68)
+* define_c_enum:                         Constant Definitions.
+                                                             (line   49)
+* define_delay:                          Delay Slots.        (line   25)
+* define_enum:                           Constant Definitions.
+                                                             (line  118)
+* define_enum_attr:                      Defining Attributes.
+                                                             (line   83)
+* define_enum_attr <1>:                  Constant Definitions.
+                                                             (line  136)
+* define_expand:                         Expander Definitions.
+                                                             (line   11)
+* define_insn:                           Patterns.           (line    6)
+* 'define_insn' example:                 Example.            (line    6)
+* define_insn_and_split:                 Insn Splitting.     (line  170)
+* define_insn_reservation:               Processor pipeline description.
+                                                             (line  105)
+* define_int_attr:                       Int Iterators.      (line    6)
+* define_int_iterator:                   Int Iterators.      (line    6)
+* define_memory_constraint:              Define Constraints. (line   80)
+* define_mode_attr:                      Substitutions.      (line    6)
+* define_mode_iterator:                  Defining Mode Iterators.
+                                                             (line    6)
+* define_peephole:                       define_peephole.    (line    6)
+* define_peephole2:                      define_peephole2.   (line    6)
+* define_predicate:                      Defining Predicates.
+                                                             (line    6)
+* define_query_cpu_unit:                 Processor pipeline description.
+                                                             (line   90)
+* define_register_constraint:            Define Constraints. (line   26)
+* define_reservation:                    Processor pipeline description.
+                                                             (line  185)
+* define_special_predicate:              Defining Predicates.
+                                                             (line    6)
+* define_split:                          Insn Splitting.     (line   32)
+* define_subst:                          Define Subst.       (line    6)
+* define_subst <1>:                      Define Subst Example.
+                                                             (line    6)
+* define_subst <2>:                      Define Subst Pattern Matching.
+                                                             (line    6)
+* define_subst <3>:                      Define Subst Output Template.
+                                                             (line    6)
+* define_subst <4>:                      Define Subst.       (line   14)
+* define_subst <5>:                      Subst Iterators.    (line    6)
+* define_subst_attr:                     Subst Iterators.    (line    6)
+* define_subst_attr <1>:                 Subst Iterators.    (line   26)
+* defining attributes and their values:  Defining Attributes.
+                                                             (line    6)
+* defining constraints:                  Define Constraints. (line    6)
+* defining constraints, obsolete method: Old Constraints.    (line    6)
+* defining jump instruction patterns:    Jump Patterns.      (line    6)
+* defining looping instruction patterns: Looping Patterns.   (line    6)
+* defining peephole optimizers:          Peephole Definitions.
+                                                             (line    6)
+* defining predicates:                   Defining Predicates.
+                                                             (line    6)
+* defining RTL sequences for code generation: Expander Definitions.
+                                                             (line    6)
+* delay slots, defining:                 Delay Slots.        (line    6)
+* deletable:                             GTY Options.        (line  158)
+* DELETE_IF_ORDINARY:                    Filesystem.         (line   79)
+* Dependent Patterns:                    Dependent Patterns. (line    6)
+* desc:                                  GTY Options.        (line   82)
+* destructors, output of:                Initialization.     (line    6)
+* deterministic finite state automaton:  Processor pipeline description.
+                                                             (line    6)
+* deterministic finite state automaton <1>: Processor pipeline description.
+                                                             (line  304)
+* DFmode:                                Machine Modes.      (line   76)
+* DF_SIZE:                               Type Layout.        (line  136)
+* digits in constraint:                  Simple Constraints. (line  128)
+* DImode:                                Machine Modes.      (line   45)
+* directory options .md:                 Including Patterns. (line   45)
+* DIR_SEPARATOR:                         Filesystem.         (line   18)
+* DIR_SEPARATOR_2:                       Filesystem.         (line   19)
+* disabling certain registers:           Register Basics.    (line   73)
+* dispatch table:                        Dispatch Tables.    (line    8)
+* div:                                   Arithmetic.         (line  117)
+* 'div' and attributes:                  Expressions.        (line   83)
+* division:                              Arithmetic.         (line  117)
+* division <1>:                          Arithmetic.         (line  131)
+* division <2>:                          Arithmetic.         (line  137)
+* 'divM3' instruction pattern:           Standard Names.     (line  276)
+* 'divmodM4' instruction pattern:        Standard Names.     (line  496)
+* DOLLARS_IN_IDENTIFIERS:                Misc.               (line  452)
+* 'doloop_begin' instruction pattern:    Standard Names.     (line 1300)
+* 'doloop_end' instruction pattern:      Standard Names.     (line 1288)
+* DONE:                                  Expander Definitions.
+                                                             (line   77)
+* DONT_USE_BUILTIN_SETJMP:               Exception Region Output.
+                                                             (line   77)
+* DOUBLE_TYPE_SIZE:                      Type Layout.        (line   52)
+* DO_BODY:                               Statements for C++. (line    6)
+* DO_COND:                               Statements for C++. (line    6)
+* DO_STMT:                               Statements for C++. (line    6)
+* DQmode:                                Machine Modes.      (line  118)
+* driver:                                Driver.             (line    6)
+* DRIVER_SELF_SPECS:                     Driver.             (line    8)
+* dump examples:                         Dump examples.      (line    6)
+* dump setup:                            Dump setup.         (line    6)
+* dump types:                            Dump types.         (line    6)
+* dump verbosity:                        Dump output verbosity.
+                                                             (line    6)
+* DUMPFILE_FORMAT:                       Filesystem.         (line   67)
+* dump_basic_block:                      Dump types.         (line   29)
+* dump_generic_expr:                     Dump types.         (line   31)
+* dump_gimple_stmt:                      Dump types.         (line   33)
+* dump_printf:                           Dump types.         (line    6)
+* DWARF2_ASM_LINE_DEBUG_INFO:            SDB and DWARF.      (line   49)
+* DWARF2_DEBUGGING_INFO:                 SDB and DWARF.      (line   12)
+* DWARF2_FRAME_INFO:                     SDB and DWARF.      (line   29)
+* DWARF2_FRAME_REG_OUT:                  Frame Registers.    (line  151)
+* DWARF2_UNWIND_INFO:                    Exception Region Output.
+                                                             (line   38)
+* DWARF_ALT_FRAME_RETURN_COLUMN:         Frame Layout.       (line  150)
+* DWARF_CIE_DATA_ALIGNMENT:              Exception Region Output.
+                                                             (line   89)
+* DWARF_FRAME_REGISTERS:                 Frame Registers.    (line  109)
+* DWARF_FRAME_REGNUM:                    Frame Registers.    (line  143)
+* DWARF_REG_TO_UNWIND_COLUMN:            Frame Registers.    (line  134)
+* DWARF_ZERO_REG:                        Frame Layout.       (line  161)
+* DYNAMIC_CHAIN_ADDRESS:                 Frame Layout.       (line   90)
+* 'E' in constraint:                     Simple Constraints. (line   87)
+* earlyclobber operand:                  Modifiers.          (line   25)
+* edge:                                  Edges.              (line    6)
+* edge in the flow graph:                Edges.              (line    6)
+* edge iterators:                        Edges.              (line   15)
+* edge splitting:                        Maintaining the CFG.
+                                                             (line  105)
+* EDGE_ABNORMAL:                         Edges.              (line  127)
+* EDGE_ABNORMAL, EDGE_ABNORMAL_CALL:     Edges.              (line  171)
+* EDGE_ABNORMAL, EDGE_EH:                Edges.              (line   95)
+* EDGE_ABNORMAL, EDGE_SIBCALL:           Edges.              (line  121)
+* EDGE_FALLTHRU, force_nonfallthru:      Edges.              (line   85)
+* 'EDOM', implicit usage:                Library Calls.      (line   59)
+* EH_FRAME_IN_DATA_SECTION:              Exception Region Output.
+                                                             (line   19)
+* EH_FRAME_SECTION_NAME:                 Exception Region Output.
+                                                             (line    9)
+* 'eh_return' instruction pattern:       Standard Names.     (line 1481)
+* EH_RETURN_DATA_REGNO:                  Exception Handling. (line    6)
+* EH_RETURN_HANDLER_RTX:                 Exception Handling. (line   38)
+* EH_RETURN_STACKADJ_RTX:                Exception Handling. (line   21)
+* EH_TABLES_CAN_BE_READ_ONLY:            Exception Region Output.
+                                                             (line   28)
+* EH_USES:                               Function Entry.     (line  155)
+* ei_edge:                               Edges.              (line   43)
+* ei_end_p:                              Edges.              (line   27)
+* ei_last:                               Edges.              (line   23)
+* ei_next:                               Edges.              (line   35)
+* ei_one_before_end_p:                   Edges.              (line   31)
+* ei_prev:                               Edges.              (line   39)
+* ei_safe_safe:                          Edges.              (line   47)
+* ei_start:                              Edges.              (line   19)
+* ELIMINABLE_REGS:                       Elimination.        (line   46)
+* ELSE_CLAUSE:                           Statements for C++. (line    6)
+* Embedded C:                            Fixed-point fractional library routines.
+                                                             (line    6)
+* EMIT_MODE_SET:                         Mode Switching.     (line   74)
+* Empty Statements:                      Empty Statements.   (line    6)
+* EMPTY_CLASS_EXPR:                      Statements for C++. (line    6)
+* EMPTY_FIELD_BOUNDARY:                  Storage Layout.     (line  306)
+* Emulated TLS:                          Emulated TLS.       (line    6)
+* enabled:                               Disable Insn Alternatives.
+                                                             (line    6)
+* ENDFILE_SPEC:                          Driver.             (line  155)
+* endianness:                            Portability.        (line   20)
+* ENTRY_BLOCK_PTR, EXIT_BLOCK_PTR:       Basic Blocks.       (line   10)
+* enum machine_mode:                     Machine Modes.      (line    6)
+* enum reg_class:                        Register Classes.   (line   70)
+* ENUMERAL_TYPE:                         Types.              (line    6)
+* enumerations:                          Constant Definitions.
+                                                             (line   49)
+* epilogue:                              Function Entry.     (line    6)
+* 'epilogue' instruction pattern:        Standard Names.     (line 1519)
+* EPILOGUE_USES:                         Function Entry.     (line  149)
+* eq:                                    Comparisons.        (line   52)
+* 'eq' and attributes:                   Expressions.        (line   83)
+* equal:                                 Comparisons.        (line   52)
+* eq_attr:                               Expressions.        (line  104)
+* EQ_EXPR:                               Unary and Binary Expressions.
+                                                             (line    6)
+* 'errno', implicit usage:               Library Calls.      (line   71)
+* EXACT_DIV_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* examining SSA_NAMEs:                   SSA.                (line  214)
+* exception handling:                    Edges.              (line   95)
+* exception handling <1>:                Exception Handling. (line    6)
+* 'exception_receiver' instruction pattern: Standard Names.  (line 1446)
+* exclamation point:                     Multi-Alternative.  (line   47)
+* exclusion_set:                         Processor pipeline description.
+                                                             (line  223)
+* exclusive-or, bitwise:                 Arithmetic.         (line  169)
+* EXIT_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* EXIT_IGNORE_STACK:                     Function Entry.     (line  137)
+* expander definitions:                  Expander Definitions.
+                                                             (line    6)
+* 'expM2' instruction pattern:           Standard Names.     (line  599)
+* expression:                            Expression trees.   (line    6)
+* expression codes:                      RTL Objects.        (line   47)
+* EXPR_FILENAME:                         Working with declarations.
+                                                             (line   14)
+* EXPR_LINENO:                           Working with declarations.
+                                                             (line   20)
+* expr_list:                             Insns.              (line  540)
+* EXPR_STMT:                             Statements for C++. (line    6)
+* EXPR_STMT_EXPR:                        Statements for C++. (line    6)
+* 'extendMN2' instruction pattern:       Standard Names.     (line  921)
+* extensible constraints:                Simple Constraints. (line  171)
+* EXTRA_ADDRESS_CONSTRAINT:              Old Constraints.    (line  120)
+* EXTRA_CONSTRAINT:                      Old Constraints.    (line   71)
+* EXTRA_CONSTRAINT_STR:                  Old Constraints.    (line   92)
+* EXTRA_MEMORY_CONSTRAINT:               Old Constraints.    (line   97)
+* EXTRA_SPECS:                           Driver.             (line  182)
+* 'extv' instruction pattern:            Standard Names.     (line 1012)
+* 'extvM' instruction pattern:           Standard Names.     (line  957)
+* 'extvmisalignM' instruction pattern:   Standard Names.     (line  967)
+* 'extzv' instruction pattern:           Standard Names.     (line 1030)
+* 'extzvM' instruction pattern:          Standard Names.     (line  981)
+* 'extzvmisalignM' instruction pattern:  Standard Names.     (line  984)
+* 'F' in constraint:                     Simple Constraints. (line   92)
+* FAIL:                                  Expander Definitions.
+                                                             (line   83)
+* fall-thru:                             Edges.              (line   68)
+* FATAL_EXIT_CODE:                       Host Misc.          (line    6)
+* FDL, GNU Free Documentation License:   GNU Free Documentation License.
+                                                             (line    6)
+* features, optional, in system conventions: Run-time Target.
+                                                             (line   59)
+* ffs:                                   Arithmetic.         (line  211)
+* 'ffsM2' instruction pattern:           Standard Names.     (line  713)
+* FIELD_DECL:                            Declarations.       (line    6)
+* files and passes of the compiler:      Passes.             (line    6)
+* files, generated:                      Files.              (line    6)
+* file_end_indicate_exec_stack:          File Framework.     (line   39)
+* final_absence_set:                     Processor pipeline description.
+                                                             (line  223)
+* FINAL_PRESCAN_INSN:                    Instruction Output. (line   60)
+* final_presence_set:                    Processor pipeline description.
+                                                             (line  223)
+* final_sequence:                        Instruction Output. (line  144)
+* FIND_BASE_TERM:                        Addressing Modes.   (line  117)
+* finite state automaton minimization:   Processor pipeline description.
+                                                             (line  304)
+* FINI_ARRAY_SECTION_ASM_OP:             Sections.           (line  113)
+* FINI_SECTION_ASM_OP:                   Sections.           (line   98)
+* FIRST_PARM_OFFSET:                     Frame Layout.       (line   65)
+* 'FIRST_PARM_OFFSET' and virtual registers: Regs and Memory.
+                                                             (line   65)
+* FIRST_PSEUDO_REGISTER:                 Register Basics.    (line    8)
+* FIRST_STACK_REG:                       Stack Registers.    (line   26)
+* FIRST_VIRTUAL_REGISTER:                Regs and Memory.    (line   51)
+* fix:                                   Conversions.        (line   66)
+* fixed register:                        Register Basics.    (line   15)
+* fixed-point fractional library:        Fixed-point fractional library routines.
+                                                             (line    6)
+* FIXED_CONVERT_EXPR:                    Unary and Binary Expressions.
+                                                             (line    6)
+* FIXED_CST:                             Constant expressions.
+                                                             (line    6)
+* FIXED_POINT_TYPE:                      Types.              (line    6)
+* FIXED_REGISTERS:                       Register Basics.    (line   14)
+* fixed_regs:                            Register Basics.    (line   59)
+* 'fixMN2' instruction pattern:          Standard Names.     (line  888)
+* 'fixunsMN2' instruction pattern:       Standard Names.     (line  897)
+* 'fixuns_truncMN2' instruction pattern: Standard Names.     (line  912)
+* 'fix_truncMN2' instruction pattern:    Standard Names.     (line  908)
+* FIX_TRUNC_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* flags in RTL expression:               Flags.              (line    6)
+* float:                                 Conversions.        (line   58)
+* floating point and cross compilation:  Floating Point.     (line    6)
+* 'floatMN2' instruction pattern:        Standard Names.     (line  880)
+* 'floatunsMN2' instruction pattern:     Standard Names.     (line  884)
+* FLOAT_EXPR:                            Unary and Binary Expressions.
+                                                             (line    6)
+* float_extend:                          Conversions.        (line   33)
+* FLOAT_LIB_COMPARE_RETURNS_BOOL:        Library Calls.      (line   32)
+* FLOAT_STORE_FLAG_VALUE:                Misc.               (line  286)
+* float_truncate:                        Conversions.        (line   53)
+* FLOAT_TYPE_SIZE:                       Type Layout.        (line   48)
+* FLOAT_WORDS_BIG_ENDIAN:                Storage Layout.     (line   41)
+* 'FLOAT_WORDS_BIG_ENDIAN', (lack of) effect on 'subreg': Regs and Memory.
+                                                             (line  224)
+* 'floorM2' instruction pattern:         Standard Names.     (line  634)
+* FLOOR_DIV_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* FLOOR_MOD_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* flow-insensitive alias analysis:       Alias analysis.     (line    6)
+* flow-sensitive alias analysis:         Alias analysis.     (line    6)
+* fma:                                   Arithmetic.         (line  112)
+* 'fmaM4' instruction pattern:           Standard Names.     (line  286)
+* 'fmodM3' instruction pattern:          Standard Names.     (line  552)
+* 'fmsM4' instruction pattern:           Standard Names.     (line  293)
+* 'fnmaM4' instruction pattern:          Standard Names.     (line  299)
+* 'fnmsM4' instruction pattern:          Standard Names.     (line  305)
+* FORCE_CODE_SECTION_ALIGN:              Sections.           (line  144)
+* force_reg:                             Standard Names.     (line   36)
+* FOR_BODY:                              Statements for C++. (line    6)
+* FOR_COND:                              Statements for C++. (line    6)
+* FOR_EXPR:                              Statements for C++. (line    6)
+* FOR_INIT_STMT:                         Statements for C++. (line    6)
+* FOR_STMT:                              Statements for C++. (line    6)
+* fractional types:                      Fixed-point fractional library routines.
+                                                             (line    6)
+* 'fractMN2' instruction pattern:        Standard Names.     (line  930)
+* 'fractunsMN2' instruction pattern:     Standard Names.     (line  945)
+* fract_convert:                         Conversions.        (line   82)
+* FRACT_TYPE_SIZE:                       Type Layout.        (line   67)
+* frame layout:                          Frame Layout.       (line    6)
+* FRAME_ADDR_RTX:                        Frame Layout.       (line  114)
+* FRAME_GROWS_DOWNWARD:                  Frame Layout.       (line   30)
+* 'FRAME_GROWS_DOWNWARD' and virtual registers: Regs and Memory.
+                                                             (line   69)
+* FRAME_POINTER_CFA_OFFSET:              Frame Layout.       (line  210)
+* frame_pointer_needed:                  Function Entry.     (line   34)
+* FRAME_POINTER_REGNUM:                  Frame Registers.    (line   13)
+* 'FRAME_POINTER_REGNUM' and virtual registers: Regs and Memory.
+                                                             (line   74)
+* frame_pointer_rtx:                     Frame Registers.    (line  104)
+* frame_related:                         Flags.              (line  229)
+* 'frame_related', in 'insn', 'call_insn', 'jump_insn', 'barrier', and 'set': Flags.
+                                                             (line  107)
+* 'frame_related', in 'mem':             Flags.              (line   85)
+* 'frame_related', in 'reg':             Flags.              (line   94)
+* 'frame_related', in 'symbol_ref':      Flags.              (line  165)
+* frequency, count, BB_FREQ_BASE:        Profile information.
+                                                             (line   30)
+* 'ftruncM2' instruction pattern:        Standard Names.     (line  903)
+* function:                              Functions.          (line    6)
+* function <1>:                          Functions for C++.  (line    6)
+* function call conventions:             Interface.          (line    6)
+* function entry and exit:               Function Entry.     (line    6)
+* function entry point, alternate function entry point: Edges.
+                                                             (line  180)
+* function properties:                   Function Properties.
+                                                             (line    6)
+* function-call insns:                   Calls.              (line    6)
+* functions, leaf:                       Leaf Functions.     (line    6)
+* FUNCTION_ARG_OFFSET:                   Register Arguments. (line  196)
+* FUNCTION_ARG_PADDING:                  Register Arguments. (line  203)
+* FUNCTION_ARG_REGNO_P:                  Register Arguments. (line  251)
+* FUNCTION_BOUNDARY:                     Storage Layout.     (line  159)
+* FUNCTION_DECL:                         Functions.          (line    6)
+* FUNCTION_DECL <1>:                     Functions for C++.  (line    6)
+* FUNCTION_MODE:                         Misc.               (line  341)
+* FUNCTION_PROFILER:                     Profiling.          (line    8)
+* FUNCTION_TYPE:                         Types.              (line    6)
+* FUNCTION_VALUE:                        Scalar Return.      (line   52)
+* FUNCTION_VALUE_REGNO_P:                Scalar Return.      (line   78)
+* fundamental type:                      Types.              (line    6)
+* 'G' in constraint:                     Simple Constraints. (line   96)
+* 'g' in constraint:                     Simple Constraints. (line  118)
+* garbage collector, invocation:         Invoking the garbage collector.
+                                                             (line    6)
+* garbage collector, troubleshooting:    Troubleshooting.    (line    6)
+* GCC and portability:                   Portability.        (line    6)
+* GCC_DRIVER_HOST_INITIALIZATION:        Host Misc.          (line   36)
+* gcov_type:                             Profile information.
+                                                             (line   41)
+* ge:                                    Comparisons.        (line   72)
+* 'ge' and attributes:                   Expressions.        (line   83)
+* gencodes:                              RTL passes.         (line   18)
+* general_operand:                       Machine-Independent Predicates.
+                                                             (line  104)
+* GENERAL_REGS:                          Register Classes.   (line   22)
+* generated files:                       Files.              (line    6)
+* generating assembler output:           Output Statement.   (line    6)
+* generating insns:                      RTL Template.       (line    6)
+* GENERIC:                               Parsing pass.       (line    6)
+* GENERIC <1>:                           GENERIC.            (line    6)
+* generic predicates:                    Machine-Independent Predicates.
+                                                             (line    6)
+* genflags:                              RTL passes.         (line   18)
+* GEN_ERRNO_RTX:                         Library Calls.      (line   71)
+* get_attr:                              Expressions.        (line   99)
+* get_attr_length:                       Insn Lengths.       (line   46)
+* GET_CLASS_NARROWEST_MODE:              Machine Modes.      (line  335)
+* GET_CODE:                              RTL Objects.        (line   47)
+* get_frame_size:                        Elimination.        (line   34)
+* get_insns:                             Insns.              (line   34)
+* get_last_insn:                         Insns.              (line   34)
+* GET_MODE:                              Machine Modes.      (line  282)
+* GET_MODE_ALIGNMENT:                    Machine Modes.      (line  322)
+* GET_MODE_BITSIZE:                      Machine Modes.      (line  306)
+* GET_MODE_CLASS:                        Machine Modes.      (line  296)
+* GET_MODE_FBIT:                         Machine Modes.      (line  313)
+* GET_MODE_IBIT:                         Machine Modes.      (line  309)
+* GET_MODE_MASK:                         Machine Modes.      (line  317)
+* GET_MODE_NAME:                         Machine Modes.      (line  293)
+* GET_MODE_NUNITS:                       Machine Modes.      (line  331)
+* GET_MODE_SIZE:                         Machine Modes.      (line  303)
+* GET_MODE_UNIT_SIZE:                    Machine Modes.      (line  325)
+* GET_MODE_WIDER_MODE:                   Machine Modes.      (line  299)
+* GET_RTX_CLASS:                         RTL Classes.        (line    6)
+* GET_RTX_FORMAT:                        RTL Classes.        (line  131)
+* GET_RTX_LENGTH:                        RTL Classes.        (line  128)
+* 'get_thread_pointerMODE' instruction pattern: Standard Names.
+                                                             (line 1869)
+* geu:                                   Comparisons.        (line   72)
+* 'geu' and attributes:                  Expressions.        (line   83)
+* GE_EXPR:                               Unary and Binary Expressions.
+                                                             (line    6)
+* GGC:                                   Type Information.   (line    6)
+* ggc_collect:                           Invoking the garbage collector.
+                                                             (line    6)
+* GIMPLE:                                Parsing pass.       (line   13)
+* GIMPLE <1>:                            Gimplification pass.
+                                                             (line    6)
+* GIMPLE <2>:                            GIMPLE.             (line    6)
+* GIMPLE Exception Handling:             GIMPLE Exception Handling.
+                                                             (line    6)
+* GIMPLE instruction set:                GIMPLE instruction set.
+                                                             (line    6)
+* GIMPLE sequences:                      GIMPLE sequences.   (line    6)
+* GIMPLE statement iterators:            Basic Blocks.       (line   78)
+* GIMPLE statement iterators <1>:        Maintaining the CFG.
+                                                             (line   33)
+* gimple_addresses_taken:                Manipulating GIMPLE statements.
+                                                             (line   89)
+* 'GIMPLE_ASM':                          'GIMPLE_ASM'.       (line    6)
+* gimple_asm_clobber_op:                 'GIMPLE_ASM'.       (line   44)
+* gimple_asm_input_op:                   'GIMPLE_ASM'.       (line   29)
+* gimple_asm_nclobbers:                  'GIMPLE_ASM'.       (line   26)
+* gimple_asm_ninputs:                    'GIMPLE_ASM'.       (line   20)
+* gimple_asm_noutputs:                   'GIMPLE_ASM'.       (line   23)
+* gimple_asm_output_op:                  'GIMPLE_ASM'.       (line   36)
+* gimple_asm_set_clobber_op:             'GIMPLE_ASM'.       (line   48)
+* gimple_asm_set_input_op:               'GIMPLE_ASM'.       (line   32)
+* gimple_asm_set_output_op:              'GIMPLE_ASM'.       (line   40)
+* gimple_asm_set_volatile:               'GIMPLE_ASM'.       (line   59)
+* gimple_asm_string:                     'GIMPLE_ASM'.       (line   52)
+* gimple_asm_volatile_p:                 'GIMPLE_ASM'.       (line   56)
+* 'GIMPLE_ASSIGN':                       'GIMPLE_ASSIGN'.    (line    6)
+* gimple_assign_cast_p:                  Logical Operators.  (line  158)
+* gimple_assign_cast_p <1>:              'GIMPLE_ASSIGN'.    (line   92)
+* gimple_assign_lhs:                     'GIMPLE_ASSIGN'.    (line   50)
+* gimple_assign_lhs_ptr:                 'GIMPLE_ASSIGN'.    (line   53)
+* gimple_assign_rhs1:                    'GIMPLE_ASSIGN'.    (line   56)
+* gimple_assign_rhs1_ptr:                'GIMPLE_ASSIGN'.    (line   59)
+* gimple_assign_rhs2:                    'GIMPLE_ASSIGN'.    (line   63)
+* gimple_assign_rhs2_ptr:                'GIMPLE_ASSIGN'.    (line   66)
+* gimple_assign_rhs3:                    'GIMPLE_ASSIGN'.    (line   70)
+* gimple_assign_rhs3_ptr:                'GIMPLE_ASSIGN'.    (line   73)
+* gimple_assign_rhs_class:               'GIMPLE_ASSIGN'.    (line   44)
+* gimple_assign_rhs_code:                'GIMPLE_ASSIGN'.    (line   40)
+* gimple_assign_set_lhs:                 'GIMPLE_ASSIGN'.    (line   77)
+* gimple_assign_set_rhs1:                'GIMPLE_ASSIGN'.    (line   80)
+* gimple_assign_set_rhs2:                'GIMPLE_ASSIGN'.    (line   84)
+* gimple_assign_set_rhs3:                'GIMPLE_ASSIGN'.    (line   88)
+* gimple_bb:                             Manipulating GIMPLE statements.
+                                                             (line   17)
+* 'GIMPLE_BIND':                         'GIMPLE_BIND'.      (line    6)
+* gimple_bind_add_seq:                   'GIMPLE_BIND'.      (line   34)
+* gimple_bind_add_stmt:                  'GIMPLE_BIND'.      (line   31)
+* gimple_bind_append_vars:               'GIMPLE_BIND'.      (line   18)
+* gimple_bind_block:                     'GIMPLE_BIND'.      (line   39)
+* gimple_bind_body:                      'GIMPLE_BIND'.      (line   22)
+* gimple_bind_set_block:                 'GIMPLE_BIND'.      (line   44)
+* gimple_bind_set_body:                  'GIMPLE_BIND'.      (line   26)
+* gimple_bind_set_vars:                  'GIMPLE_BIND'.      (line   14)
+* gimple_bind_vars:                      'GIMPLE_BIND'.      (line   11)
+* gimple_block:                          Manipulating GIMPLE statements.
+                                                             (line   20)
+* gimple_build_asm:                      'GIMPLE_ASM'.       (line    6)
+* gimple_build_asm_vec:                  'GIMPLE_ASM'.       (line   15)
+* gimple_build_assign:                   'GIMPLE_ASSIGN'.    (line    6)
+* gimple_build_assign_with_ops:          'GIMPLE_ASSIGN'.    (line   28)
+* gimple_build_bind:                     'GIMPLE_BIND'.      (line    6)
+* gimple_build_call:                     'GIMPLE_CALL'.      (line    6)
+* gimple_build_call_from_tree:           'GIMPLE_CALL'.      (line   15)
+* gimple_build_call_vec:                 'GIMPLE_CALL'.      (line   23)
+* gimple_build_catch:                    'GIMPLE_CATCH'.     (line    6)
+* gimple_build_cond:                     'GIMPLE_COND'.      (line    6)
+* gimple_build_cond_from_tree:           'GIMPLE_COND'.      (line   14)
+* gimple_build_debug_bind:               'GIMPLE_DEBUG'.     (line    6)
+* gimple_build_eh_filter:                'GIMPLE_EH_FILTER'. (line    6)
+* gimple_build_goto:                     'GIMPLE_LABEL'.     (line   17)
+* gimple_build_label:                    'GIMPLE_LABEL'.     (line    6)
+* gimple_build_nop:                      'GIMPLE_NOP'.       (line    6)
+* gimple_build_omp_atomic_load:          'GIMPLE_OMP_ATOMIC_LOAD'.
+                                                             (line    6)
+* gimple_build_omp_atomic_store:         'GIMPLE_OMP_ATOMIC_STORE'.
+                                                             (line    6)
+* gimple_build_omp_continue:             'GIMPLE_OMP_CONTINUE'.
+                                                             (line    6)
+* gimple_build_omp_critical:             'GIMPLE_OMP_CRITICAL'.
+                                                             (line    6)
+* gimple_build_omp_for:                  'GIMPLE_OMP_FOR'.   (line    6)
+* gimple_build_omp_master:               'GIMPLE_OMP_MASTER'.
+                                                             (line    6)
+* gimple_build_omp_ordered:              'GIMPLE_OMP_ORDERED'.
+                                                             (line    6)
+* gimple_build_omp_parallel:             'GIMPLE_OMP_PARALLEL'.
+                                                             (line    6)
+* gimple_build_omp_return:               'GIMPLE_OMP_RETURN'.
+                                                             (line    6)
+* gimple_build_omp_section:              'GIMPLE_OMP_SECTION'.
+                                                             (line    6)
+* gimple_build_omp_sections:             'GIMPLE_OMP_SECTIONS'.
+                                                             (line    6)
+* gimple_build_omp_sections_switch:      'GIMPLE_OMP_SECTIONS'.
+                                                             (line   13)
+* gimple_build_omp_single:               'GIMPLE_OMP_SINGLE'.
+                                                             (line    6)
+* gimple_build_resx:                     'GIMPLE_RESX'.      (line    6)
+* gimple_build_return:                   'GIMPLE_RETURN'.    (line    6)
+* gimple_build_switch:                   'GIMPLE_SWITCH'.    (line    6)
+* gimple_build_try:                      'GIMPLE_TRY'.       (line    6)
+* gimple_build_wce:                      'GIMPLE_WITH_CLEANUP_EXPR'.
+                                                             (line    6)
+* 'GIMPLE_CALL':                         'GIMPLE_CALL'.      (line    6)
+* gimple_call_arg:                       'GIMPLE_CALL'.      (line   65)
+* gimple_call_arg_ptr:                   'GIMPLE_CALL'.      (line   69)
+* gimple_call_cannot_inline_p:           'GIMPLE_CALL'.      (line   90)
+* gimple_call_chain:                     'GIMPLE_CALL'.      (line   56)
+* gimple_call_copy_skip_args:            'GIMPLE_CALL'.      (line   96)
+* gimple_call_fn:                        'GIMPLE_CALL'.      (line   37)
+* gimple_call_fndecl:                    'GIMPLE_CALL'.      (line   45)
+* gimple_call_lhs:                       'GIMPLE_CALL'.      (line   28)
+* gimple_call_lhs_ptr:                   'GIMPLE_CALL'.      (line   31)
+* gimple_call_mark_uninlinable:          'GIMPLE_CALL'.      (line   87)
+* gimple_call_noreturn_p:                'GIMPLE_CALL'.      (line   93)
+* gimple_call_num_args:                  'GIMPLE_CALL'.      (line   62)
+* gimple_call_return_type:               'GIMPLE_CALL'.      (line   53)
+* gimple_call_set_arg:                   'GIMPLE_CALL'.      (line   74)
+* gimple_call_set_chain:                 'GIMPLE_CALL'.      (line   59)
+* gimple_call_set_fn:                    'GIMPLE_CALL'.      (line   41)
+* gimple_call_set_fndecl:                'GIMPLE_CALL'.      (line   50)
+* gimple_call_set_lhs:                   'GIMPLE_CALL'.      (line   34)
+* gimple_call_set_tail:                  'GIMPLE_CALL'.      (line   79)
+* gimple_call_tail_p:                    'GIMPLE_CALL'.      (line   84)
+* 'GIMPLE_CATCH':                        'GIMPLE_CATCH'.     (line    6)
+* gimple_catch_handler:                  'GIMPLE_CATCH'.     (line   19)
+* gimple_catch_set_handler:              'GIMPLE_CATCH'.     (line   26)
+* gimple_catch_set_types:                'GIMPLE_CATCH'.     (line   23)
+* gimple_catch_types:                    'GIMPLE_CATCH'.     (line   12)
+* gimple_catch_types_ptr:                'GIMPLE_CATCH'.     (line   15)
+* gimple_code:                           Manipulating GIMPLE statements.
+                                                             (line   14)
+* 'GIMPLE_COND':                         'GIMPLE_COND'.      (line    6)
+* gimple_cond_code:                      'GIMPLE_COND'.      (line   20)
+* gimple_cond_false_label:               'GIMPLE_COND'.      (line   59)
+* gimple_cond_lhs:                       'GIMPLE_COND'.      (line   29)
+* gimple_cond_make_false:                'GIMPLE_COND'.      (line   63)
+* gimple_cond_make_true:                 'GIMPLE_COND'.      (line   66)
+* gimple_cond_rhs:                       'GIMPLE_COND'.      (line   37)
+* gimple_cond_set_code:                  'GIMPLE_COND'.      (line   24)
+* gimple_cond_set_false_label:           'GIMPLE_COND'.      (line   54)
+* gimple_cond_set_lhs:                   'GIMPLE_COND'.      (line   33)
+* gimple_cond_set_rhs:                   'GIMPLE_COND'.      (line   41)
+* gimple_cond_set_true_label:            'GIMPLE_COND'.      (line   49)
+* gimple_cond_true_label:                'GIMPLE_COND'.      (line   45)
+* gimple_copy:                           Manipulating GIMPLE statements.
+                                                             (line  146)
+* 'GIMPLE_DEBUG':                        'GIMPLE_DEBUG'.     (line    6)
+* 'GIMPLE_DEBUG_BIND':                   'GIMPLE_DEBUG'.     (line    6)
+* gimple_debug_bind_get_value:           'GIMPLE_DEBUG'.     (line   46)
+* gimple_debug_bind_get_value_ptr:       'GIMPLE_DEBUG'.     (line   50)
+* gimple_debug_bind_get_var:             'GIMPLE_DEBUG'.     (line   43)
+* gimple_debug_bind_has_value_p:         'GIMPLE_DEBUG'.     (line   68)
+* gimple_debug_bind_p:                   Logical Operators.  (line  162)
+* gimple_debug_bind_reset_value:         'GIMPLE_DEBUG'.     (line   64)
+* gimple_debug_bind_set_value:           'GIMPLE_DEBUG'.     (line   59)
+* gimple_debug_bind_set_var:             'GIMPLE_DEBUG'.     (line   55)
+* gimple_def_ops:                        Manipulating GIMPLE statements.
+                                                             (line   93)
+* 'GIMPLE_EH_FILTER':                    'GIMPLE_EH_FILTER'. (line    6)
+* gimple_eh_filter_failure:              'GIMPLE_EH_FILTER'. (line   18)
+* gimple_eh_filter_must_not_throw:       'GIMPLE_EH_FILTER'. (line   32)
+* gimple_eh_filter_set_failure:          'GIMPLE_EH_FILTER'. (line   27)
+* gimple_eh_filter_set_must_not_throw:   'GIMPLE_EH_FILTER'. (line   35)
+* gimple_eh_filter_set_types:            'GIMPLE_EH_FILTER'. (line   22)
+* gimple_eh_filter_types:                'GIMPLE_EH_FILTER'. (line   11)
+* gimple_eh_filter_types_ptr:            'GIMPLE_EH_FILTER'. (line   14)
+* gimple_expr_code:                      Manipulating GIMPLE statements.
+                                                             (line   30)
+* gimple_expr_type:                      Manipulating GIMPLE statements.
+                                                             (line   23)
+* gimple_goto_dest:                      'GIMPLE_LABEL'.     (line   20)
+* gimple_goto_set_dest:                  'GIMPLE_LABEL'.     (line   23)
+* gimple_has_mem_ops:                    Manipulating GIMPLE statements.
+                                                             (line   71)
+* gimple_has_ops:                        Manipulating GIMPLE statements.
+                                                             (line   68)
+* gimple_has_volatile_ops:               Manipulating GIMPLE statements.
+                                                             (line  133)
+* 'GIMPLE_LABEL':                        'GIMPLE_LABEL'.     (line    6)
+* gimple_label_label:                    'GIMPLE_LABEL'.     (line   10)
+* gimple_label_set_label:                'GIMPLE_LABEL'.     (line   13)
+* gimple_loaded_syms:                    Manipulating GIMPLE statements.
+                                                             (line  121)
+* gimple_locus:                          Manipulating GIMPLE statements.
+                                                             (line   41)
+* gimple_locus_empty_p:                  Manipulating GIMPLE statements.
+                                                             (line   47)
+* gimple_modified_p:                     Manipulating GIMPLE statements.
+                                                             (line  129)
+* 'GIMPLE_NOP':                          'GIMPLE_NOP'.       (line    6)
+* gimple_nop_p:                          'GIMPLE_NOP'.       (line    9)
+* gimple_no_warning_p:                   Manipulating GIMPLE statements.
+                                                             (line   50)
+* gimple_num_ops:                        Logical Operators.  (line   76)
+* gimple_num_ops <1>:                    Manipulating GIMPLE statements.
+                                                             (line   74)
+* 'GIMPLE_OMP_ATOMIC_LOAD':              'GIMPLE_OMP_ATOMIC_LOAD'.
+                                                             (line    6)
+* gimple_omp_atomic_load_lhs:            'GIMPLE_OMP_ATOMIC_LOAD'.
+                                                             (line   16)
+* gimple_omp_atomic_load_rhs:            'GIMPLE_OMP_ATOMIC_LOAD'.
+                                                             (line   23)
+* gimple_omp_atomic_load_set_lhs:        'GIMPLE_OMP_ATOMIC_LOAD'.
+                                                             (line   12)
+* gimple_omp_atomic_load_set_rhs:        'GIMPLE_OMP_ATOMIC_LOAD'.
+                                                             (line   19)
+* 'GIMPLE_OMP_ATOMIC_STORE':             'GIMPLE_OMP_ATOMIC_STORE'.
+                                                             (line    6)
+* gimple_omp_atomic_store_set_val:       'GIMPLE_OMP_ATOMIC_STORE'.
+                                                             (line   10)
+* gimple_omp_atomic_store_val:           'GIMPLE_OMP_ATOMIC_STORE'.
+                                                             (line   14)
+* gimple_omp_body:                       'GIMPLE_OMP_PARALLEL'.
+                                                             (line   23)
+* 'GIMPLE_OMP_CONTINUE':                 'GIMPLE_OMP_CONTINUE'.
+                                                             (line    6)
+* gimple_omp_continue_control_def:       'GIMPLE_OMP_CONTINUE'.
+                                                             (line   12)
+* gimple_omp_continue_control_def_ptr:   'GIMPLE_OMP_CONTINUE'.
+                                                             (line   16)
+* gimple_omp_continue_control_use:       'GIMPLE_OMP_CONTINUE'.
+                                                             (line   23)
+* gimple_omp_continue_control_use_ptr:   'GIMPLE_OMP_CONTINUE'.
+                                                             (line   27)
+* gimple_omp_continue_set_control_def:   'GIMPLE_OMP_CONTINUE'.
+                                                             (line   19)
+* gimple_omp_continue_set_control_use:   'GIMPLE_OMP_CONTINUE'.
+                                                             (line   30)
+* 'GIMPLE_OMP_CRITICAL':                 'GIMPLE_OMP_CRITICAL'.
+                                                             (line    6)
+* gimple_omp_critical_name:              'GIMPLE_OMP_CRITICAL'.
+                                                             (line   12)
+* gimple_omp_critical_name_ptr:          'GIMPLE_OMP_CRITICAL'.
+                                                             (line   15)
+* gimple_omp_critical_set_name:          'GIMPLE_OMP_CRITICAL'.
+                                                             (line   19)
+* 'GIMPLE_OMP_FOR':                      'GIMPLE_OMP_FOR'.   (line    6)
+* gimple_omp_for_clauses:                'GIMPLE_OMP_FOR'.   (line   19)
+* gimple_omp_for_clauses_ptr:            'GIMPLE_OMP_FOR'.   (line   22)
+* gimple_omp_for_cond:                   'GIMPLE_OMP_FOR'.   (line   82)
+* gimple_omp_for_final:                  'GIMPLE_OMP_FOR'.   (line   50)
+* gimple_omp_for_final_ptr:              'GIMPLE_OMP_FOR'.   (line   53)
+* gimple_omp_for_incr:                   'GIMPLE_OMP_FOR'.   (line   60)
+* gimple_omp_for_incr_ptr:               'GIMPLE_OMP_FOR'.   (line   63)
+* gimple_omp_for_index:                  'GIMPLE_OMP_FOR'.   (line   30)
+* gimple_omp_for_index_ptr:              'GIMPLE_OMP_FOR'.   (line   33)
+* gimple_omp_for_initial:                'GIMPLE_OMP_FOR'.   (line   40)
+* gimple_omp_for_initial_ptr:            'GIMPLE_OMP_FOR'.   (line   43)
+* gimple_omp_for_pre_body:               'GIMPLE_OMP_FOR'.   (line   69)
+* gimple_omp_for_set_clauses:            'GIMPLE_OMP_FOR'.   (line   25)
+* gimple_omp_for_set_cond:               'GIMPLE_OMP_FOR'.   (line   78)
+* gimple_omp_for_set_final:              'GIMPLE_OMP_FOR'.   (line   56)
+* gimple_omp_for_set_incr:               'GIMPLE_OMP_FOR'.   (line   66)
+* gimple_omp_for_set_index:              'GIMPLE_OMP_FOR'.   (line   36)
+* gimple_omp_for_set_initial:            'GIMPLE_OMP_FOR'.   (line   46)
+* gimple_omp_for_set_pre_body:           'GIMPLE_OMP_FOR'.   (line   73)
+* 'GIMPLE_OMP_MASTER':                   'GIMPLE_OMP_MASTER'.
+                                                             (line    6)
+* 'GIMPLE_OMP_ORDERED':                  'GIMPLE_OMP_ORDERED'.
+                                                             (line    6)
+* 'GIMPLE_OMP_PARALLEL':                 'GIMPLE_OMP_PARALLEL'.
+                                                             (line    6)
+* gimple_omp_parallel_child_fn:          'GIMPLE_OMP_PARALLEL'.
+                                                             (line   41)
+* gimple_omp_parallel_child_fn_ptr:      'GIMPLE_OMP_PARALLEL'.
+                                                             (line   45)
+* gimple_omp_parallel_clauses:           'GIMPLE_OMP_PARALLEL'.
+                                                             (line   30)
+* gimple_omp_parallel_clauses_ptr:       'GIMPLE_OMP_PARALLEL'.
+                                                             (line   33)
+* gimple_omp_parallel_combined_p:        'GIMPLE_OMP_PARALLEL'.
+                                                             (line   15)
+* gimple_omp_parallel_data_arg:          'GIMPLE_OMP_PARALLEL'.
+                                                             (line   53)
+* gimple_omp_parallel_data_arg_ptr:      'GIMPLE_OMP_PARALLEL'.
+                                                             (line   57)
+* gimple_omp_parallel_set_child_fn:      'GIMPLE_OMP_PARALLEL'.
+                                                             (line   49)
+* gimple_omp_parallel_set_clauses:       'GIMPLE_OMP_PARALLEL'.
+                                                             (line   36)
+* gimple_omp_parallel_set_combined_p:    'GIMPLE_OMP_PARALLEL'.
+                                                             (line   19)
+* gimple_omp_parallel_set_data_arg:      'GIMPLE_OMP_PARALLEL'.
+                                                             (line   60)
+* 'GIMPLE_OMP_RETURN':                   'GIMPLE_OMP_RETURN'.
+                                                             (line    6)
+* gimple_omp_return_nowait_p:            'GIMPLE_OMP_RETURN'.
+                                                             (line   13)
+* gimple_omp_return_set_nowait:          'GIMPLE_OMP_RETURN'.
+                                                             (line   10)
+* 'GIMPLE_OMP_SECTION':                  'GIMPLE_OMP_SECTION'.
+                                                             (line    6)
+* 'GIMPLE_OMP_SECTIONS':                 'GIMPLE_OMP_SECTIONS'.
+                                                             (line    6)
+* gimple_omp_sections_clauses:           'GIMPLE_OMP_SECTIONS'.
+                                                             (line   29)
+* gimple_omp_sections_clauses_ptr:       'GIMPLE_OMP_SECTIONS'.
+                                                             (line   32)
+* gimple_omp_sections_control:           'GIMPLE_OMP_SECTIONS'.
+                                                             (line   16)
+* gimple_omp_sections_control_ptr:       'GIMPLE_OMP_SECTIONS'.
+                                                             (line   20)
+* gimple_omp_sections_set_clauses:       'GIMPLE_OMP_SECTIONS'.
+                                                             (line   35)
+* gimple_omp_sections_set_control:       'GIMPLE_OMP_SECTIONS'.
+                                                             (line   24)
+* gimple_omp_section_last_p:             'GIMPLE_OMP_SECTION'.
+                                                             (line   11)
+* gimple_omp_section_set_last:           'GIMPLE_OMP_SECTION'.
+                                                             (line   15)
+* gimple_omp_set_body:                   'GIMPLE_OMP_PARALLEL'.
+                                                             (line   26)
+* 'GIMPLE_OMP_SINGLE':                   'GIMPLE_OMP_SINGLE'.
+                                                             (line    6)
+* gimple_omp_single_clauses:             'GIMPLE_OMP_SINGLE'.
+                                                             (line   13)
+* gimple_omp_single_clauses_ptr:         'GIMPLE_OMP_SINGLE'.
+                                                             (line   16)
+* gimple_omp_single_set_clauses:         'GIMPLE_OMP_SINGLE'.
+                                                             (line   19)
+* gimple_op:                             Logical Operators.  (line   79)
+* gimple_op <1>:                         Manipulating GIMPLE statements.
+                                                             (line   80)
+* gimple_ops:                            Logical Operators.  (line   82)
+* gimple_ops <1>:                        Manipulating GIMPLE statements.
+                                                             (line   77)
+* gimple_op_ptr:                         Manipulating GIMPLE statements.
+                                                             (line   83)
+* 'GIMPLE_PHI':                          'GIMPLE_PHI'.       (line    6)
+* gimple_phi_arg:                        'GIMPLE_PHI'.       (line   24)
+* gimple_phi_arg <1>:                    SSA.                (line   62)
+* gimple_phi_arg_def:                    SSA.                (line   68)
+* gimple_phi_arg_edge:                   SSA.                (line   65)
+* gimple_phi_capacity:                   'GIMPLE_PHI'.       (line    6)
+* gimple_phi_num_args:                   'GIMPLE_PHI'.       (line   10)
+* gimple_phi_num_args <1>:               SSA.                (line   58)
+* gimple_phi_result:                     'GIMPLE_PHI'.       (line   15)
+* gimple_phi_result <1>:                 SSA.                (line   55)
+* gimple_phi_result_ptr:                 'GIMPLE_PHI'.       (line   18)
+* gimple_phi_set_arg:                    'GIMPLE_PHI'.       (line   28)
+* gimple_phi_set_result:                 'GIMPLE_PHI'.       (line   21)
+* gimple_plf:                            Manipulating GIMPLE statements.
+                                                             (line   64)
+* 'GIMPLE_RESX':                         'GIMPLE_RESX'.      (line    6)
+* gimple_resx_region:                    'GIMPLE_RESX'.      (line   12)
+* gimple_resx_set_region:                'GIMPLE_RESX'.      (line   15)
+* 'GIMPLE_RETURN':                       'GIMPLE_RETURN'.    (line    6)
+* gimple_return_retval:                  'GIMPLE_RETURN'.    (line    9)
+* gimple_return_set_retval:              'GIMPLE_RETURN'.    (line   12)
+* gimple_seq_add_seq:                    GIMPLE sequences.   (line   30)
+* gimple_seq_add_stmt:                   GIMPLE sequences.   (line   24)
+* gimple_seq_alloc:                      GIMPLE sequences.   (line   61)
+* gimple_seq_copy:                       GIMPLE sequences.   (line   65)
+* gimple_seq_deep_copy:                  GIMPLE sequences.   (line   36)
+* gimple_seq_empty_p:                    GIMPLE sequences.   (line   69)
+* gimple_seq_first:                      GIMPLE sequences.   (line   43)
+* gimple_seq_init:                       GIMPLE sequences.   (line   58)
+* gimple_seq_last:                       GIMPLE sequences.   (line   46)
+* gimple_seq_reverse:                    GIMPLE sequences.   (line   39)
+* gimple_seq_set_first:                  GIMPLE sequences.   (line   53)
+* gimple_seq_set_last:                   GIMPLE sequences.   (line   49)
+* gimple_seq_singleton_p:                GIMPLE sequences.   (line   78)
+* gimple_set_block:                      Manipulating GIMPLE statements.
+                                                             (line   38)
+* gimple_set_def_ops:                    Manipulating GIMPLE statements.
+                                                             (line   96)
+* gimple_set_has_volatile_ops:           Manipulating GIMPLE statements.
+                                                             (line  136)
+* gimple_set_locus:                      Manipulating GIMPLE statements.
+                                                             (line   44)
+* gimple_set_op:                         Manipulating GIMPLE statements.
+                                                             (line   86)
+* gimple_set_plf:                        Manipulating GIMPLE statements.
+                                                             (line   60)
+* gimple_set_use_ops:                    Manipulating GIMPLE statements.
+                                                             (line  103)
+* gimple_set_vdef_ops:                   Manipulating GIMPLE statements.
+                                                             (line  117)
+* gimple_set_visited:                    Manipulating GIMPLE statements.
+                                                             (line   53)
+* gimple_set_vuse_ops:                   Manipulating GIMPLE statements.
+                                                             (line  110)
+* gimple_statement_base:                 Tuple representation.
+                                                             (line   14)
+* gimple_statement_with_ops:             Tuple representation.
+                                                             (line   96)
+* gimple_stored_syms:                    Manipulating GIMPLE statements.
+                                                             (line  125)
+* 'GIMPLE_SWITCH':                       'GIMPLE_SWITCH'.    (line    6)
+* gimple_switch_default_label:           'GIMPLE_SWITCH'.    (line   38)
+* gimple_switch_index:                   'GIMPLE_SWITCH'.    (line   23)
+* gimple_switch_label:                   'GIMPLE_SWITCH'.    (line   29)
+* gimple_switch_num_labels:              'GIMPLE_SWITCH'.    (line   14)
+* gimple_switch_set_default_label:       'GIMPLE_SWITCH'.    (line   41)
+* gimple_switch_set_index:               'GIMPLE_SWITCH'.    (line   26)
+* gimple_switch_set_label:               'GIMPLE_SWITCH'.    (line   33)
+* gimple_switch_set_num_labels:          'GIMPLE_SWITCH'.    (line   18)
+* 'GIMPLE_TRY':                          'GIMPLE_TRY'.       (line    6)
+* gimple_try_catch_is_cleanup:           'GIMPLE_TRY'.       (line   19)
+* gimple_try_cleanup:                    'GIMPLE_TRY'.       (line   26)
+* gimple_try_eval:                       'GIMPLE_TRY'.       (line   22)
+* gimple_try_kind:                       'GIMPLE_TRY'.       (line   15)
+* gimple_try_set_catch_is_cleanup:       'GIMPLE_TRY'.       (line   30)
+* gimple_try_set_cleanup:                'GIMPLE_TRY'.       (line   39)
+* gimple_try_set_eval:                   'GIMPLE_TRY'.       (line   34)
+* gimple_use_ops:                        Manipulating GIMPLE statements.
+                                                             (line  100)
+* gimple_vdef_ops:                       Manipulating GIMPLE statements.
+                                                             (line  114)
+* gimple_visited_p:                      Manipulating GIMPLE statements.
+                                                             (line   57)
+* gimple_vuse_ops:                       Manipulating GIMPLE statements.
+                                                             (line  107)
+* gimple_wce_cleanup:                    'GIMPLE_WITH_CLEANUP_EXPR'.
+                                                             (line   10)
+* gimple_wce_cleanup_eh_only:            'GIMPLE_WITH_CLEANUP_EXPR'.
+                                                             (line   17)
+* gimple_wce_set_cleanup:                'GIMPLE_WITH_CLEANUP_EXPR'.
+                                                             (line   13)
+* gimple_wce_set_cleanup_eh_only:        'GIMPLE_WITH_CLEANUP_EXPR'.
+                                                             (line   20)
+* 'GIMPLE_WITH_CLEANUP_EXPR':            'GIMPLE_WITH_CLEANUP_EXPR'.
+                                                             (line    6)
+* gimplification:                        Parsing pass.       (line   13)
+* gimplification <1>:                    Gimplification pass.
+                                                             (line    6)
+* gimplifier:                            Parsing pass.       (line   13)
+* gimplify_assign:                       'GIMPLE_ASSIGN'.    (line   17)
+* gimplify_expr:                         Gimplification pass.
+                                                             (line   18)
+* gimplify_function_tree:                Gimplification pass.
+                                                             (line   18)
+* GLOBAL_INIT_PRIORITY:                  Functions for C++.  (line  141)
+* global_regs:                           Register Basics.    (line   59)
+* 'GO_IF_LEGITIMATE_ADDRESS':            Addressing Modes.   (line   90)
+* greater than:                          Comparisons.        (line   60)
+* greater than <1>:                      Comparisons.        (line   64)
+* greater than <2>:                      Comparisons.        (line   72)
+* gsi_after_labels:                      Sequence iterators. (line   74)
+* gsi_bb:                                Sequence iterators. (line   82)
+* gsi_commit_edge_inserts:               Sequence iterators. (line  193)
+* gsi_commit_edge_inserts <1>:           Maintaining the CFG.
+                                                             (line  105)
+* gsi_commit_one_edge_insert:            Sequence iterators. (line  188)
+* gsi_end_p:                             Sequence iterators. (line   59)
+* gsi_end_p <1>:                         Maintaining the CFG.
+                                                             (line   48)
+* gsi_for_stmt:                          Sequence iterators. (line  156)
+* gsi_insert_after:                      Sequence iterators. (line  145)
+* gsi_insert_after <1>:                  Maintaining the CFG.
+                                                             (line   60)
+* gsi_insert_before:                     Sequence iterators. (line  134)
+* gsi_insert_before <1>:                 Maintaining the CFG.
+                                                             (line   66)
+* gsi_insert_on_edge:                    Sequence iterators. (line  173)
+* gsi_insert_on_edge <1>:                Maintaining the CFG.
+                                                             (line  105)
+* gsi_insert_on_edge_immediate:          Sequence iterators. (line  183)
+* gsi_insert_seq_after:                  Sequence iterators. (line  152)
+* gsi_insert_seq_before:                 Sequence iterators. (line  141)
+* gsi_insert_seq_on_edge:                Sequence iterators. (line  177)
+* gsi_last:                              Sequence iterators. (line   49)
+* gsi_last <1>:                          Maintaining the CFG.
+                                                             (line   44)
+* gsi_last_bb:                           Sequence iterators. (line   55)
+* gsi_link_after:                        Sequence iterators. (line  113)
+* gsi_link_before:                       Sequence iterators. (line  103)
+* gsi_link_seq_after:                    Sequence iterators. (line  108)
+* gsi_link_seq_before:                   Sequence iterators. (line   97)
+* gsi_move_after:                        Sequence iterators. (line  159)
+* gsi_move_before:                       Sequence iterators. (line  164)
+* gsi_move_to_bb_end:                    Sequence iterators. (line  169)
+* gsi_next:                              Sequence iterators. (line   65)
+* gsi_next <1>:                          Maintaining the CFG.
+                                                             (line   52)
+* gsi_one_before_end_p:                  Sequence iterators. (line   62)
+* gsi_prev:                              Sequence iterators. (line   68)
+* gsi_prev <1>:                          Maintaining the CFG.
+                                                             (line   56)
+* gsi_remove:                            Sequence iterators. (line   88)
+* gsi_remove <1>:                        Maintaining the CFG.
+                                                             (line   72)
+* gsi_replace:                           Sequence iterators. (line  128)
+* gsi_seq:                               Sequence iterators. (line   85)
+* gsi_split_seq_after:                   Sequence iterators. (line  118)
+* gsi_split_seq_before:                  Sequence iterators. (line  123)
+* gsi_start:                             Sequence iterators. (line   39)
+* gsi_start <1>:                         Maintaining the CFG.
+                                                             (line   40)
+* gsi_start_bb:                          Sequence iterators. (line   45)
+* gsi_stmt:                              Sequence iterators. (line   71)
+* gsi_stmt_ptr:                          Sequence iterators. (line   79)
+* gt:                                    Comparisons.        (line   60)
+* 'gt' and attributes:                   Expressions.        (line   83)
+* gtu:                                   Comparisons.        (line   64)
+* 'gtu' and attributes:                  Expressions.        (line   83)
+* GTY:                                   Type Information.   (line    6)
+* GT_EXPR:                               Unary and Binary Expressions.
+                                                             (line    6)
+* 'H' in constraint:                     Simple Constraints. (line   96)
+* HAmode:                                Machine Modes.      (line  146)
+* HANDLER:                               Statements for C++. (line    6)
+* HANDLER_BODY:                          Statements for C++. (line    6)
+* HANDLER_PARMS:                         Statements for C++. (line    6)
+* HANDLE_PRAGMA_PACK_WITH_EXPANSION:     Misc.               (line  442)
+* hard registers:                        Regs and Memory.    (line    9)
+* HARD_FRAME_POINTER_IS_ARG_POINTER:     Frame Registers.    (line   57)
+* HARD_FRAME_POINTER_IS_FRAME_POINTER:   Frame Registers.    (line   50)
+* HARD_FRAME_POINTER_REGNUM:             Frame Registers.    (line   19)
+* HARD_REGNO_CALLER_SAVE_MODE:           Caller Saves.       (line   19)
+* HARD_REGNO_CALL_PART_CLOBBERED:        Register Basics.    (line   52)
+* HARD_REGNO_MODE_OK:                    Values in Registers.
+                                                             (line   57)
+* HARD_REGNO_NREGS:                      Values in Registers.
+                                                             (line   10)
+* HARD_REGNO_NREGS_HAS_PADDING:          Values in Registers.
+                                                             (line   24)
+* HARD_REGNO_NREGS_WITH_PADDING:         Values in Registers.
+                                                             (line   42)
+* HARD_REGNO_RENAME_OK:                  Values in Registers.
+                                                             (line  117)
+* HAS_INIT_SECTION:                      Macros for Initialization.
+                                                             (line   18)
+* HAS_LONG_COND_BRANCH:                  Misc.               (line    8)
+* HAS_LONG_UNCOND_BRANCH:                Misc.               (line   17)
+* HAVE_DOS_BASED_FILE_SYSTEM:            Filesystem.         (line   11)
+* HAVE_POST_DECREMENT:                   Addressing Modes.   (line   11)
+* HAVE_POST_INCREMENT:                   Addressing Modes.   (line   10)
+* HAVE_POST_MODIFY_DISP:                 Addressing Modes.   (line   17)
+* HAVE_POST_MODIFY_REG:                  Addressing Modes.   (line   23)
+* HAVE_PRE_DECREMENT:                    Addressing Modes.   (line    9)
+* HAVE_PRE_INCREMENT:                    Addressing Modes.   (line    8)
+* HAVE_PRE_MODIFY_DISP:                  Addressing Modes.   (line   16)
+* HAVE_PRE_MODIFY_REG:                   Addressing Modes.   (line   22)
+* HCmode:                                Machine Modes.      (line  199)
+* HFmode:                                Machine Modes.      (line   61)
+* high:                                  Constants.          (line  119)
+* HImode:                                Machine Modes.      (line   29)
+* 'HImode', in 'insn':                   Insns.              (line  268)
+* HONOR_REG_ALLOC_ORDER:                 Allocation Order.   (line   36)
+* host configuration:                    Host Config.        (line    6)
+* host functions:                        Host Common.        (line    6)
+* host hooks:                            Host Common.        (line    6)
+* host makefile fragment:                Host Fragment.      (line    6)
+* HOST_BIT_BUCKET:                       Filesystem.         (line   51)
+* HOST_EXECUTABLE_SUFFIX:                Filesystem.         (line   45)
+* HOST_HOOKS_EXTRA_SIGNALS:              Host Common.        (line   11)
+* HOST_HOOKS_GT_PCH_ALLOC_GRANULARITY:   Host Common.        (line   43)
+* HOST_HOOKS_GT_PCH_GET_ADDRESS:         Host Common.        (line   15)
+* HOST_HOOKS_GT_PCH_USE_ADDRESS:         Host Common.        (line   24)
+* HOST_LACKS_INODE_NUMBERS:              Filesystem.         (line   89)
+* HOST_LONG_FORMAT:                      Host Misc.          (line   45)
+* HOST_LONG_LONG_FORMAT:                 Host Misc.          (line   41)
+* HOST_OBJECT_SUFFIX:                    Filesystem.         (line   40)
+* HOST_PTR_PRINTF:                       Host Misc.          (line   49)
+* HOT_TEXT_SECTION_NAME:                 Sections.           (line   42)
+* HQmode:                                Machine Modes.      (line  110)
+* 'i' in constraint:                     Simple Constraints. (line   68)
+* 'I' in constraint:                     Simple Constraints. (line   79)
+* identifier:                            Identifiers.        (line    6)
+* IDENTIFIER_LENGTH:                     Identifiers.        (line   22)
+* IDENTIFIER_NODE:                       Identifiers.        (line    6)
+* IDENTIFIER_OPNAME_P:                   Identifiers.        (line   27)
+* IDENTIFIER_POINTER:                    Identifiers.        (line   17)
+* IDENTIFIER_TYPENAME_P:                 Identifiers.        (line   33)
+* IEEE 754-2008:                         Decimal float library routines.
+                                                             (line    6)
+* IFCVT_MACHDEP_INIT:                    Misc.               (line  567)
+* IFCVT_MODIFY_CANCEL:                   Misc.               (line  561)
+* IFCVT_MODIFY_FINAL:                    Misc.               (line  555)
+* IFCVT_MODIFY_INSN:                     Misc.               (line  549)
+* IFCVT_MODIFY_MULTIPLE_TESTS:           Misc.               (line  541)
+* IFCVT_MODIFY_TESTS:                    Misc.               (line  531)
+* IF_COND:                               Statements for C++. (line    6)
+* if_marked:                             GTY Options.        (line  165)
+* IF_STMT:                               Statements for C++. (line    6)
+* if_then_else:                          Comparisons.        (line   80)
+* 'if_then_else' and attributes:         Expressions.        (line   32)
+* 'if_then_else' usage:                  Side Effects.       (line   56)
+* IMAGPART_EXPR:                         Unary and Binary Expressions.
+                                                             (line    6)
+* Immediate Uses:                        SSA Operands.       (line  258)
+* immediate_operand:                     Machine-Independent Predicates.
+                                                             (line   10)
+* IMMEDIATE_PREFIX:                      Instruction Output. (line  153)
+* include:                               Including Patterns. (line    6)
+* INCLUDE_DEFAULTS:                      Driver.             (line  327)
+* inclusive-or, bitwise:                 Arithmetic.         (line  164)
+* INCOMING_FRAME_SP_OFFSET:              Frame Layout.       (line  181)
+* INCOMING_REGNO:                        Register Basics.    (line   87)
+* INCOMING_RETURN_ADDR_RTX:              Frame Layout.       (line  137)
+* INCOMING_STACK_BOUNDARY:               Storage Layout.     (line  154)
+* INDEX_REG_CLASS:                       Register Classes.   (line  140)
+* 'indirect_jump' instruction pattern:   Standard Names.     (line 1237)
+* indirect_operand:                      Machine-Independent Predicates.
+                                                             (line   70)
+* INDIRECT_REF:                          Storage References. (line    6)
+* initialization routines:               Initialization.     (line    6)
+* INITIAL_ELIMINATION_OFFSET:            Elimination.        (line   84)
+* INITIAL_FRAME_ADDRESS_RTX:             Frame Layout.       (line   81)
+* INITIAL_FRAME_POINTER_OFFSET:          Elimination.        (line   34)
+* INIT_ARRAY_SECTION_ASM_OP:             Sections.           (line  106)
+* INIT_CUMULATIVE_ARGS:                  Register Arguments. (line  147)
+* INIT_CUMULATIVE_INCOMING_ARGS:         Register Arguments. (line  175)
+* INIT_CUMULATIVE_LIBCALL_ARGS:          Register Arguments. (line  169)
+* INIT_ENVIRONMENT:                      Driver.             (line  305)
+* INIT_EXPANDERS:                        Per-Function Data.  (line   36)
+* INIT_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* init_machine_status:                   Per-Function Data.  (line   42)
+* init_one_libfunc:                      Library Calls.      (line   15)
+* INIT_SECTION_ASM_OP:                   Sections.           (line   90)
+* INIT_SECTION_ASM_OP <1>:               Macros for Initialization.
+                                                             (line    9)
+* inlining:                              Target Attributes.  (line   95)
+* insert_insn_on_edge:                   Maintaining the CFG.
+                                                             (line  105)
+* insn:                                  Insns.              (line   63)
+* 'insn' and '/f':                       Flags.              (line  107)
+* 'insn' and '/j':                       Flags.              (line  157)
+* 'insn' and '/s':                       Flags.              (line   49)
+* 'insn' and '/s' <1>:                   Flags.              (line  148)
+* 'insn' and '/u':                       Flags.              (line   39)
+* 'insn' and '/v':                       Flags.              (line   44)
+* insn attributes:                       Insn Attributes.    (line    6)
+* insn canonicalization:                 Insn Canonicalizations.
+                                                             (line    6)
+* insn includes:                         Including Patterns. (line    6)
+* insn lengths, computing:               Insn Lengths.       (line    6)
+* insn notes, notes:                     Basic Blocks.       (line   52)
+* insn splitting:                        Insn Splitting.     (line    6)
+* insn-attr.h:                           Defining Attributes.
+                                                             (line   34)
+* insns:                                 Insns.              (line    6)
+* insns, generating:                     RTL Template.       (line    6)
+* insns, recognizing:                    RTL Template.       (line    6)
+* INSN_ANNULLED_BRANCH_P:                Flags.              (line   39)
+* INSN_CODE:                             Insns.              (line  295)
+* INSN_DELETED_P:                        Flags.              (line   44)
+* INSN_FROM_TARGET_P:                    Flags.              (line   49)
+* insn_list:                             Insns.              (line  540)
+* INSN_REFERENCES_ARE_DELAYED:           Misc.               (line  469)
+* INSN_SETS_ARE_DELAYED:                 Misc.               (line  458)
+* INSN_UID:                              Insns.              (line   23)
+* INSN_VAR_LOCATION:                     Insns.              (line  236)
+* instruction attributes:                Insn Attributes.    (line    6)
+* instruction latency time:              Processor pipeline description.
+                                                             (line    6)
+* instruction latency time <1>:          Processor pipeline description.
+                                                             (line  105)
+* instruction latency time <2>:          Processor pipeline description.
+                                                             (line  196)
+* instruction patterns:                  Patterns.           (line    6)
+* instruction splitting:                 Insn Splitting.     (line    6)
+* 'insv' instruction pattern:            Standard Names.     (line 1036)
+* 'insvM' instruction pattern:           Standard Names.     (line  988)
+* 'insvmisalignM' instruction pattern:   Standard Names.     (line  998)
+* int iterators in '.md' files:          Int Iterators.      (line    6)
+* INT16_TYPE:                            Type Layout.        (line  253)
+* INT32_TYPE:                            Type Layout.        (line  254)
+* INT64_TYPE:                            Type Layout.        (line  255)
+* INT8_TYPE:                             Type Layout.        (line  252)
+* INTEGER_CST:                           Constant expressions.
+                                                             (line    6)
+* INTEGER_TYPE:                          Types.              (line    6)
+* Interdependence of Patterns:           Dependent Patterns. (line    6)
+* interfacing to GCC output:             Interface.          (line    6)
+* interlock delays:                      Processor pipeline description.
+                                                             (line    6)
+* intermediate representation lowering:  Parsing pass.       (line   13)
+* INTMAX_TYPE:                           Type Layout.        (line  229)
+* INTPTR_TYPE:                           Type Layout.        (line  276)
+* introduction:                          Top.                (line    6)
+* INT_FAST16_TYPE:                       Type Layout.        (line  269)
+* INT_FAST32_TYPE:                       Type Layout.        (line  270)
+* INT_FAST64_TYPE:                       Type Layout.        (line  271)
+* INT_FAST8_TYPE:                        Type Layout.        (line  268)
+* INT_LEAST16_TYPE:                      Type Layout.        (line  261)
+* INT_LEAST32_TYPE:                      Type Layout.        (line  262)
+* INT_LEAST64_TYPE:                      Type Layout.        (line  263)
+* INT_LEAST8_TYPE:                       Type Layout.        (line  260)
+* INT_TYPE_SIZE:                         Type Layout.        (line   11)
+* INVOKE__main:                          Macros for Initialization.
+                                                             (line   50)
+* in_struct:                             Flags.              (line  245)
+* 'in_struct', in 'code_label' and 'note': Flags.            (line   59)
+* 'in_struct', in 'insn' and 'jump_insn' and 'call_insn': Flags.
+                                                             (line   49)
+* 'in_struct', in 'insn', 'call_insn', 'jump_insn' and 'jump_table_data': Flags.
+                                                             (line  148)
+* 'in_struct', in 'subreg':              Flags.              (line  187)
+* ior:                                   Arithmetic.         (line  164)
+* 'ior' and attributes:                  Expressions.        (line   50)
+* 'ior', canonicalization of:            Insn Canonicalizations.
+                                                             (line   51)
+* 'iorM3' instruction pattern:           Standard Names.     (line  276)
+* IRA_HARD_REGNO_ADD_COST_MULTIPLIER:    Allocation Order.   (line   44)
+* IS_ASM_LOGICAL_LINE_SEPARATOR:         Data Output.        (line  119)
+* is_gimple_addressable:                 Logical Operators.  (line  113)
+* is_gimple_asm_val:                     Logical Operators.  (line  117)
+* is_gimple_assign:                      Logical Operators.  (line  149)
+* is_gimple_call:                        Logical Operators.  (line  152)
+* is_gimple_call_addr:                   Logical Operators.  (line  120)
+* is_gimple_constant:                    Logical Operators.  (line  128)
+* is_gimple_debug:                       Logical Operators.  (line  155)
+* is_gimple_ip_invariant:                Logical Operators.  (line  137)
+* is_gimple_ip_invariant_address:        Logical Operators.  (line  142)
+* is_gimple_mem_ref_addr:                Logical Operators.  (line  124)
+* is_gimple_min_invariant:               Logical Operators.  (line  131)
+* is_gimple_omp:                         Logical Operators.  (line  166)
+* is_gimple_val:                         Logical Operators.  (line  107)
+* iterators in '.md' files:              Iterators.          (line    6)
+* IV analysis on GIMPLE:                 Scalar evolutions.  (line    6)
+* IV analysis on RTL:                    loop-iv.            (line    6)
+* JMP_BUF_SIZE:                          Exception Region Output.
+                                                             (line   82)
+* jump:                                  Flags.              (line  286)
+* 'jump' instruction pattern:            Standard Names.     (line 1115)
+* jump instruction patterns:             Jump Patterns.      (line    6)
+* jump instructions and 'set':           Side Effects.       (line   56)
+* 'jump', in 'call_insn':                Flags.              (line  161)
+* 'jump', in 'insn':                     Flags.              (line  157)
+* 'jump', in 'mem':                      Flags.              (line   70)
+* Jumps:                                 Jumps.              (line    6)
+* JUMP_ALIGN:                            Alignment Output.   (line    8)
+* jump_insn:                             Insns.              (line   73)
+* 'jump_insn' and '/f':                  Flags.              (line  107)
+* 'jump_insn' and '/s':                  Flags.              (line   49)
+* 'jump_insn' and '/s' <1>:              Flags.              (line  148)
+* 'jump_insn' and '/u':                  Flags.              (line   39)
+* 'jump_insn' and '/v':                  Flags.              (line   44)
+* JUMP_LABEL:                            Insns.              (line   80)
+* JUMP_TABLES_IN_TEXT_SECTION:           Sections.           (line  150)
+* jump_table_data:                       Insns.              (line  166)
+* 'jump_table_data' and '/s':            Flags.              (line  148)
+* 'jump_table_data' and '/v':            Flags.              (line   44)
+* LABEL_ALIGN:                           Alignment Output.   (line   57)
+* LABEL_ALIGN_AFTER_BARRIER:             Alignment Output.   (line   26)
+* LABEL_ALTERNATE_NAME:                  Edges.              (line  180)
+* LABEL_ALT_ENTRY_P:                     Insns.              (line  146)
+* LABEL_DECL:                            Declarations.       (line    6)
+* LABEL_KIND:                            Insns.              (line  146)
+* LABEL_NUSES:                           Insns.              (line  142)
+* LABEL_PRESERVE_P:                      Flags.              (line   59)
+* label_ref:                             Constants.          (line   96)
+* 'label_ref' and '/v':                  Flags.              (line   65)
+* 'label_ref', RTL sharing:              Sharing.            (line   35)
+* LABEL_REF_NONLOCAL_P:                  Flags.              (line   65)
+* language-dependent trees:              Language-dependent trees.
+                                                             (line    6)
+* language-independent intermediate representation: Parsing pass.
+                                                             (line   13)
+* lang_hooks.gimplify_expr:              Gimplification pass.
+                                                             (line   18)
+* lang_hooks.parse_file:                 Parsing pass.       (line    6)
+* large return values:                   Aggregate Return.   (line    6)
+* LARGEST_EXPONENT_IS_NORMAL:            Storage Layout.     (line  483)
+* LAST_STACK_REG:                        Stack Registers.    (line   30)
+* LAST_VIRTUAL_REGISTER:                 Regs and Memory.    (line   51)
+* 'lceilMN2':                            Standard Names.     (line  699)
+* LCSSA:                                 LCSSA.              (line    6)
+* LDD_SUFFIX:                            Macros for Initialization.
+                                                             (line  121)
+* LD_FINI_SWITCH:                        Macros for Initialization.
+                                                             (line   28)
+* LD_INIT_SWITCH:                        Macros for Initialization.
+                                                             (line   24)
+* le:                                    Comparisons.        (line   76)
+* 'le' and attributes:                   Expressions.        (line   83)
+* leaf functions:                        Leaf Functions.     (line    6)
+* leaf_function_p:                       Standard Names.     (line 1199)
+* LEAF_REGISTERS:                        Leaf Functions.     (line   23)
+* LEAF_REG_REMAP:                        Leaf Functions.     (line   37)
+* left rotate:                           Arithmetic.         (line  196)
+* left shift:                            Arithmetic.         (line  174)
+* LEGITIMATE_PIC_OPERAND_P:              PIC.                (line   31)
+* LEGITIMIZE_RELOAD_ADDRESS:             Addressing Modes.   (line  150)
+* length:                                GTY Options.        (line   47)
+* less than:                             Comparisons.        (line   68)
+* less than or equal:                    Comparisons.        (line   76)
+* leu:                                   Comparisons.        (line   76)
+* 'leu' and attributes:                  Expressions.        (line   83)
+* LE_EXPR:                               Unary and Binary Expressions.
+                                                             (line    6)
+* 'lfloorMN2':                           Standard Names.     (line  694)
+* LIB2FUNCS_EXTRA:                       Target Fragment.    (line   11)
+* LIBCALL_VALUE:                         Scalar Return.      (line   56)
+* 'libgcc.a':                            Library Calls.      (line    6)
+* LIBGCC2_CFLAGS:                        Target Fragment.    (line    8)
+* LIBGCC2_GNU_PREFIX:                    Type Layout.        (line  127)
+* LIBGCC2_HAS_DF_MODE:                   Type Layout.        (line  108)
+* LIBGCC2_HAS_TF_MODE:                   Type Layout.        (line  121)
+* LIBGCC2_HAS_XF_MODE:                   Type Layout.        (line  115)
+* LIBGCC2_LONG_DOUBLE_TYPE_SIZE:         Type Layout.        (line  102)
+* LIBGCC2_UNWIND_ATTRIBUTE:              Misc.               (line  996)
+* LIBGCC_SPEC:                           Driver.             (line  115)
+* library subroutine names:              Library Calls.      (line    6)
+* LIBRARY_PATH_ENV:                      Misc.               (line  509)
+* LIB_SPEC:                              Driver.             (line  107)
+* LIMIT_RELOAD_CLASS:                    Register Classes.   (line  296)
+* LINK_COMMAND_SPEC:                     Driver.             (line  236)
+* LINK_EH_SPEC:                          Driver.             (line  142)
+* LINK_GCC_C_SEQUENCE_SPEC:              Driver.             (line  232)
+* LINK_LIBGCC_SPECIAL_1:                 Driver.             (line  227)
+* LINK_SPEC:                             Driver.             (line  100)
+* list:                                  Containers.         (line    6)
+* Liveness representation:               Liveness information.
+                                                             (line    6)
+* load address instruction:              Simple Constraints. (line  162)
+* LOAD_EXTEND_OP:                        Misc.               (line   59)
+* 'load_multiple' instruction pattern:   Standard Names.     (line  136)
+* Local Register Allocator (LRA):        RTL passes.         (line  187)
+* LOCAL_ALIGNMENT:                       Storage Layout.     (line  249)
+* LOCAL_CLASS_P:                         Classes.            (line   73)
+* LOCAL_DECL_ALIGNMENT:                  Storage Layout.     (line  286)
+* LOCAL_INCLUDE_DIR:                     Driver.             (line  312)
+* LOCAL_LABEL_PREFIX:                    Instruction Output. (line  151)
+* LOCAL_REGNO:                           Register Basics.    (line  101)
+* Logical Operators:                     Logical Operators.  (line    6)
+* logical-and, bitwise:                  Arithmetic.         (line  159)
+* LOGICAL_OP_NON_SHORT_CIRCUIT:          Costs.              (line  264)
+* 'logM2' instruction pattern:           Standard Names.     (line  607)
+* LOG_LINKS:                             Insns.              (line  314)
+* 'longjmp' and automatic variables:     Interface.          (line   52)
+* LONG_ACCUM_TYPE_SIZE:                  Type Layout.        (line   92)
+* LONG_DOUBLE_TYPE_SIZE:                 Type Layout.        (line   57)
+* LONG_FRACT_TYPE_SIZE:                  Type Layout.        (line   72)
+* LONG_LONG_ACCUM_TYPE_SIZE:             Type Layout.        (line   97)
+* LONG_LONG_FRACT_TYPE_SIZE:             Type Layout.        (line   77)
+* LONG_LONG_TYPE_SIZE:                   Type Layout.        (line   32)
+* LONG_TYPE_SIZE:                        Type Layout.        (line   21)
+* Loop analysis:                         Loop representation.
+                                                             (line    6)
+* Loop manipulation:                     Loop manipulation.  (line    6)
+* Loop querying:                         Loop querying.      (line    6)
+* Loop representation:                   Loop representation.
+                                                             (line    6)
+* Loop-closed SSA form:                  LCSSA.              (line    6)
+* looping instruction patterns:          Looping Patterns.   (line    6)
+* LOOP_ALIGN:                            Alignment Output.   (line   40)
+* LOOP_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* lowering, language-dependent intermediate representation: Parsing pass.
+                                                             (line   13)
+* lo_sum:                                Arithmetic.         (line   25)
+* 'lrintMN2':                            Standard Names.     (line  684)
+* 'lroundMN2':                           Standard Names.     (line  689)
+* lshiftrt:                              Arithmetic.         (line  191)
+* 'lshiftrt' and attributes:             Expressions.        (line   83)
+* LSHIFT_EXPR:                           Unary and Binary Expressions.
+                                                             (line    6)
+* 'lshrM3' instruction pattern:          Standard Names.     (line  526)
+* lt:                                    Comparisons.        (line   68)
+* 'lt' and attributes:                   Expressions.        (line   83)
+* LTGT_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* lto:                                   LTO.                (line    6)
+* ltrans:                                LTO.                (line    6)
+* ltu:                                   Comparisons.        (line   68)
+* LT_EXPR:                               Unary and Binary Expressions.
+                                                             (line    6)
+* 'm' in constraint:                     Simple Constraints. (line   17)
+* machine attributes:                    Target Attributes.  (line    6)
+* machine description macros:            Target Macros.      (line    6)
+* machine descriptions:                  Machine Desc.       (line    6)
+* machine mode conversions:              Conversions.        (line    6)
+* machine modes:                         Machine Modes.      (line    6)
+* machine specific constraints:          Machine Constraints.
+                                                             (line    6)
+* machine-independent predicates:        Machine-Independent Predicates.
+                                                             (line    6)
+* macros, target description:            Target Macros.      (line    6)
+* 'maddMN4' instruction pattern:         Standard Names.     (line  449)
+* makefile fragment:                     Fragments.          (line    6)
+* makefile targets:                      Makefile.           (line    6)
+* MAKE_DECL_ONE_ONLY:                    Label Output.       (line  246)
+* make_safe_from:                        Expander Definitions.
+                                                             (line  151)
+* MALLOC_ABI_ALIGNMENT:                  Storage Layout.     (line  168)
+* Manipulating GIMPLE statements:        Manipulating GIMPLE statements.
+                                                             (line    6)
+* marking roots:                         GGC Roots.          (line    6)
+* mark_hook:                             GTY Options.        (line  181)
+* MASK_RETURN_ADDR:                      Exception Region Output.
+                                                             (line   34)
+* matching constraint:                   Simple Constraints. (line  140)
+* matching operands:                     Output Template.    (line   49)
+* match_dup:                             RTL Template.       (line   73)
+* match_dup <1>:                         define_peephole2.   (line   28)
+* 'match_dup' and attributes:            Insn Lengths.       (line   16)
+* match_operand:                         RTL Template.       (line   16)
+* 'match_operand' and attributes:        Expressions.        (line   55)
+* match_operator:                        RTL Template.       (line   95)
+* match_op_dup:                          RTL Template.       (line  163)
+* match_parallel:                        RTL Template.       (line  172)
+* match_par_dup:                         RTL Template.       (line  219)
+* match_scratch:                         RTL Template.       (line   58)
+* match_scratch <1>:                     define_peephole2.   (line   28)
+* 'match_test' and attributes:           Expressions.        (line   64)
+* math library:                          Soft float library routines.
+                                                             (line    6)
+* math, in RTL:                          Arithmetic.         (line    6)
+* matherr:                               Library Calls.      (line   59)
+* MATH_LIBRARY:                          Misc.               (line  502)
+* 'maxM3' instruction pattern:           Standard Names.     (line  311)
+* MAX_BITSIZE_MODE_ANY_INT:              Machine Modes.      (line  349)
+* MAX_BITSIZE_MODE_ANY_MODE:             Machine Modes.      (line  355)
+* MAX_BITS_PER_WORD:                     Storage Layout.     (line   54)
+* MAX_CONDITIONAL_EXECUTE:               Misc.               (line  524)
+* MAX_FIXED_MODE_SIZE:                   Storage Layout.     (line  431)
+* MAX_MOVE_MAX:                          Misc.               (line  105)
+* MAX_OFILE_ALIGNMENT:                   Storage Layout.     (line  203)
+* MAX_REGS_PER_ADDRESS:                  Addressing Modes.   (line   42)
+* MAX_STACK_ALIGNMENT:                   Storage Layout.     (line  197)
+* maybe_undef:                           GTY Options.        (line  190)
+* may_trap_p, tree_could_trap_p:         Edges.              (line  114)
+* mcount:                                Profiling.          (line   12)
+* MD_CAN_REDIRECT_BRANCH:                Misc.               (line  711)
+* MD_EXEC_PREFIX:                        Driver.             (line  267)
+* MD_FALLBACK_FRAME_STATE_FOR:           Exception Handling. (line   93)
+* MD_HANDLE_UNWABI:                      Exception Handling. (line  112)
+* MD_STARTFILE_PREFIX:                   Driver.             (line  295)
+* MD_STARTFILE_PREFIX_1:                 Driver.             (line  300)
+* mem:                                   Regs and Memory.    (line  370)
+* 'mem' and '/c':                        Flags.              (line   81)
+* 'mem' and '/f':                        Flags.              (line   85)
+* 'mem' and '/j':                        Flags.              (line   70)
+* 'mem' and '/u':                        Flags.              (line  134)
+* 'mem' and '/v':                        Flags.              (line   76)
+* 'mem', RTL sharing:                    Sharing.            (line   40)
+* memory model:                          Memory model.       (line    6)
+* memory reference, nonoffsettable:      Simple Constraints. (line  254)
+* memory references in constraints:      Simple Constraints. (line   17)
+* 'memory_barrier' instruction pattern:  Standard Names.     (line 1587)
+* MEMORY_MOVE_COST:                      Costs.              (line   53)
+* memory_operand:                        Machine-Independent Predicates.
+                                                             (line   57)
+* MEM_ADDR_SPACE:                        Special Accessors.  (line   48)
+* MEM_ALIAS_SET:                         Special Accessors.  (line    9)
+* MEM_ALIGN:                             Special Accessors.  (line   45)
+* MEM_EXPR:                              Special Accessors.  (line   19)
+* MEM_KEEP_ALIAS_SET_P:                  Flags.              (line   70)
+* MEM_NOTRAP_P:                          Flags.              (line   81)
+* MEM_OFFSET:                            Special Accessors.  (line   31)
+* MEM_OFFSET_KNOWN_P:                    Special Accessors.  (line   27)
+* MEM_POINTER:                           Flags.              (line   85)
+* MEM_READONLY_P:                        Flags.              (line  134)
+* MEM_REF:                               Storage References. (line    6)
+* 'mem_signal_fenceMODE' instruction pattern: Standard Names.
+                                                             (line 1857)
+* MEM_SIZE:                              Special Accessors.  (line   39)
+* MEM_SIZE_KNOWN_P:                      Special Accessors.  (line   35)
+* 'mem_thread_fenceMODE' instruction pattern: Standard Names.
+                                                             (line 1849)
+* MEM_VOLATILE_P:                        Flags.              (line   76)
+* METHOD_TYPE:                           Types.              (line    6)
+* MINIMUM_ALIGNMENT:                     Storage Layout.     (line  299)
+* MINIMUM_ATOMIC_ALIGNMENT:              Storage Layout.     (line  176)
+* 'minM3' instruction pattern:           Standard Names.     (line  311)
+* minus:                                 Arithmetic.         (line   38)
+* 'minus' and attributes:                Expressions.        (line   83)
+* 'minus', canonicalization of:          Insn Canonicalizations.
+                                                             (line   27)
+* MINUS_EXPR:                            Unary and Binary Expressions.
+                                                             (line    6)
+* MIN_UNITS_PER_WORD:                    Storage Layout.     (line   64)
+* MIPS coprocessor-definition macros:    MIPS Coprocessors.  (line    6)
+* mnemonic attribute:                    Mnemonic Attribute. (line    6)
+* mod:                                   Arithmetic.         (line  137)
+* 'mod' and attributes:                  Expressions.        (line   83)
+* mode classes:                          Machine Modes.      (line  221)
+* mode iterators in '.md' files:         Mode Iterators.     (line    6)
+* mode switching:                        Mode Switching.     (line    6)
+* MODES_TIEABLE_P:                       Values in Registers.
+                                                             (line  127)
+* MODE_ACCUM:                            Machine Modes.      (line  251)
+* MODE_AFTER:                            Mode Switching.     (line   48)
+* MODE_BASE_REG_CLASS:                   Register Classes.   (line  116)
+* MODE_BASE_REG_REG_CLASS:               Register Classes.   (line  122)
+* MODE_CC:                               Machine Modes.      (line  270)
+* MODE_CC <1>:                           MODE_CC Condition Codes.
+                                                             (line    6)
+* MODE_CODE_BASE_REG_CLASS:              Register Classes.   (line  129)
+* MODE_COMPLEX_FLOAT:                    Machine Modes.      (line  262)
+* MODE_COMPLEX_INT:                      Machine Modes.      (line  259)
+* MODE_DECIMAL_FLOAT:                    Machine Modes.      (line  239)
+* MODE_ENTRY:                            Mode Switching.     (line   54)
+* MODE_EXIT:                             Mode Switching.     (line   60)
+* MODE_FLOAT:                            Machine Modes.      (line  235)
+* MODE_FRACT:                            Machine Modes.      (line  243)
+* MODE_FUNCTION:                         Machine Modes.      (line  266)
+* MODE_INT:                              Machine Modes.      (line  227)
+* MODE_NEEDED:                           Mode Switching.     (line   41)
+* MODE_PARTIAL_INT:                      Machine Modes.      (line  231)
+* MODE_PRIORITY_TO_MODE:                 Mode Switching.     (line   66)
+* MODE_RANDOM:                           Machine Modes.      (line  275)
+* MODE_UACCUM:                           Machine Modes.      (line  255)
+* MODE_UFRACT:                           Machine Modes.      (line  247)
+* modifiers in constraints:              Modifiers.          (line    6)
+* MODIFY_EXPR:                           Unary and Binary Expressions.
+                                                             (line    6)
+* MODIFY_JNI_METHOD_CALL:                Misc.               (line  798)
+* 'modM3' instruction pattern:           Standard Names.     (line  276)
+* modulo scheduling:                     RTL passes.         (line  123)
+* MOVE_BY_PIECES_P:                      Costs.              (line  164)
+* MOVE_MAX:                              Misc.               (line  100)
+* MOVE_MAX_PIECES:                       Costs.              (line  170)
+* MOVE_RATIO:                            Costs.              (line  148)
+* 'movM' instruction pattern:            Standard Names.     (line   11)
+* 'movmemM' instruction pattern:         Standard Names.     (line  756)
+* 'movmisalignM' instruction pattern:    Standard Names.     (line  125)
+* 'movMODEcc' instruction pattern:       Standard Names.     (line 1050)
+* 'movstr' instruction pattern:          Standard Names.     (line  791)
+* 'movstrictM' instruction pattern:      Standard Names.     (line  119)
+* 'msubMN4' instruction pattern:         Standard Names.     (line  472)
+* 'mulhisi3' instruction pattern:        Standard Names.     (line  425)
+* 'mulM3' instruction pattern:           Standard Names.     (line  276)
+* 'mulqihi3' instruction pattern:        Standard Names.     (line  429)
+* 'mulsidi3' instruction pattern:        Standard Names.     (line  429)
+* mult:                                  Arithmetic.         (line   93)
+* 'mult' and attributes:                 Expressions.        (line   83)
+* 'mult', canonicalization of:           Insn Canonicalizations.
+                                                             (line   27)
+* 'mult', canonicalization of <1>:       Insn Canonicalizations.
+                                                             (line   91)
+* MULTIARCH_DIRNAME:                     Target Fragment.    (line  170)
+* MULTILIB_DEFAULTS:                     Driver.             (line  252)
+* MULTILIB_DIRNAMES:                     Target Fragment.    (line   44)
+* MULTILIB_EXCEPTIONS:                   Target Fragment.    (line   70)
+* MULTILIB_EXTRA_OPTS:                   Target Fragment.    (line  132)
+* MULTILIB_MATCHES:                      Target Fragment.    (line   63)
+* MULTILIB_OPTIONS:                      Target Fragment.    (line   24)
+* MULTILIB_OSDIRNAMES:                   Target Fragment.    (line  139)
+* MULTILIB_REQUIRED:                     Target Fragment.    (line   82)
+* MULTILIB_REUSE:                        Target Fragment.    (line  103)
+* multiple alternative constraints:      Multi-Alternative.  (line    6)
+* MULTIPLE_SYMBOL_SPACES:                Misc.               (line  482)
+* multiplication:                        Arithmetic.         (line   93)
+* multiplication with signed saturation: Arithmetic.         (line   93)
+* multiplication with unsigned saturation: Arithmetic.       (line   93)
+* MULT_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* MULT_HIGHPART_EXPR:                    Unary and Binary Expressions.
+                                                             (line    6)
+* 'n' in constraint:                     Simple Constraints. (line   73)
+* name:                                  Identifiers.        (line    6)
+* named address spaces:                  Named Address Spaces.
+                                                             (line    6)
+* named patterns and conditions:         Patterns.           (line   47)
+* names, pattern:                        Standard Names.     (line    6)
+* namespace, scope:                      Namespaces.         (line    6)
+* NAMESPACE_DECL:                        Declarations.       (line    6)
+* NAMESPACE_DECL <1>:                    Namespaces.         (line    6)
+* NATIVE_SYSTEM_HEADER_COMPONENT:        Driver.             (line  322)
+* ne:                                    Comparisons.        (line   56)
+* 'ne' and attributes:                   Expressions.        (line   83)
+* 'nearbyintM2' instruction pattern:     Standard Names.     (line  666)
+* neg:                                   Arithmetic.         (line   82)
+* 'neg' and attributes:                  Expressions.        (line   83)
+* 'neg', canonicalization of:            Insn Canonicalizations.
+                                                             (line   27)
+* NEGATE_EXPR:                           Unary and Binary Expressions.
+                                                             (line    6)
+* negation:                              Arithmetic.         (line   82)
+* negation with signed saturation:       Arithmetic.         (line   82)
+* negation with unsigned saturation:     Arithmetic.         (line   82)
+* 'negM2' instruction pattern:           Standard Names.     (line  538)
+* nested functions, trampolines for:     Trampolines.        (line    6)
+* nested_ptr:                            GTY Options.        (line  198)
+* next_bb, prev_bb, FOR_EACH_BB, FOR_ALL_BB: Basic Blocks.   (line   25)
+* NEXT_INSN:                             Insns.              (line   30)
+* NEXT_OBJC_RUNTIME:                     Library Calls.      (line   82)
+* NE_EXPR:                               Unary and Binary Expressions.
+                                                             (line    6)
+* nil:                                   RTL Objects.        (line   73)
+* NM_FLAGS:                              Macros for Initialization.
+                                                             (line  110)
+* nondeterministic finite state automaton: Processor pipeline description.
+                                                             (line  304)
+* nonimmediate_operand:                  Machine-Independent Predicates.
+                                                             (line  100)
+* nonlocal goto handler:                 Edges.              (line  171)
+* 'nonlocal_goto' instruction pattern:   Standard Names.     (line 1419)
+* 'nonlocal_goto_receiver' instruction pattern: Standard Names.
+                                                             (line 1436)
+* nonmemory_operand:                     Machine-Independent Predicates.
+                                                             (line   96)
+* nonoffsettable memory reference:       Simple Constraints. (line  254)
+* NON_LVALUE_EXPR:                       Unary and Binary Expressions.
+                                                             (line    6)
+* 'nop' instruction pattern:             Standard Names.     (line 1232)
+* NOP_EXPR:                              Unary and Binary Expressions.
+                                                             (line    6)
+* normal predicates:                     Predicates.         (line   31)
+* not:                                   Arithmetic.         (line  155)
+* 'not' and attributes:                  Expressions.        (line   50)
+* not equal:                             Comparisons.        (line   56)
+* 'not', canonicalization of:            Insn Canonicalizations.
+                                                             (line   27)
+* note:                                  Insns.              (line  183)
+* 'note' and '/i':                       Flags.              (line   59)
+* 'note' and '/v':                       Flags.              (line   44)
+* NOTE_INSN_BASIC_BLOCK:                 Basic Blocks.       (line   50)
+* NOTE_INSN_BASIC_BLOCK <1>:             Basic Blocks.       (line   52)
+* NOTE_INSN_BLOCK_BEG:                   Insns.              (line  208)
+* NOTE_INSN_BLOCK_END:                   Insns.              (line  208)
+* NOTE_INSN_DELETED:                     Insns.              (line  198)
+* NOTE_INSN_DELETED_LABEL:               Insns.              (line  203)
+* NOTE_INSN_EH_REGION_BEG:               Insns.              (line  214)
+* NOTE_INSN_EH_REGION_END:               Insns.              (line  214)
+* NOTE_INSN_FUNCTION_BEG:                Insns.              (line  221)
+* NOTE_INSN_VAR_LOCATION:                Insns.              (line  225)
+* NOTE_LINE_NUMBER:                      Insns.              (line  183)
+* NOTE_SOURCE_FILE:                      Insns.              (line  183)
+* NOTE_VAR_LOCATION:                     Insns.              (line  225)
+* NOTICE_UPDATE_CC:                      CC0 Condition Codes.
+                                                             (line   30)
+* NO_DBX_BNSYM_ENSYM:                    DBX Hooks.          (line   25)
+* NO_DBX_FUNCTION_END:                   DBX Hooks.          (line   19)
+* NO_DBX_GCC_MARKER:                     File Names and DBX. (line   27)
+* NO_DBX_MAIN_SOURCE_DIRECTORY:          File Names and DBX. (line   22)
+* NO_DOLLAR_IN_LABEL:                    Label Output.       (line   64)
+* NO_DOT_IN_LABEL:                       Label Output.       (line   70)
+* NO_FUNCTION_CSE:                       Costs.              (line  260)
+* NO_IMPLICIT_EXTERN_C:                  Misc.               (line  381)
+* NO_PROFILE_COUNTERS:                   Profiling.          (line   27)
+* NO_REGS:                               Register Classes.   (line   17)
+* Number of iterations analysis:         Number of iterations.
+                                                             (line    6)
+* NUM_MACHINE_MODES:                     Machine Modes.      (line  288)
+* NUM_MODES_FOR_MODE_SWITCHING:          Mode Switching.     (line   29)
+* N_REG_CLASSES:                         Register Classes.   (line   81)
+* 'o' in constraint:                     Simple Constraints. (line   23)
+* OBJC_GEN_METHOD_LABEL:                 Label Output.       (line  447)
+* OBJC_JBLEN:                            Misc.               (line  991)
+* OBJECT_FORMAT_COFF:                    Macros for Initialization.
+                                                             (line   96)
+* offsettable address:                   Simple Constraints. (line   23)
+* OFFSET_TYPE:                           Types.              (line    6)
+* OImode:                                Machine Modes.      (line   51)
+* Omega a solver for linear programming problems: Omega.     (line    6)
+* OMP_ATOMIC:                            OpenMP.             (line    6)
+* OMP_CLAUSE:                            OpenMP.             (line    6)
+* OMP_CONTINUE:                          OpenMP.             (line    6)
+* OMP_CRITICAL:                          OpenMP.             (line    6)
+* OMP_FOR:                               OpenMP.             (line    6)
+* OMP_MASTER:                            OpenMP.             (line    6)
+* OMP_ORDERED:                           OpenMP.             (line    6)
+* OMP_PARALLEL:                          OpenMP.             (line    6)
+* OMP_RETURN:                            OpenMP.             (line    6)
+* OMP_SECTION:                           OpenMP.             (line    6)
+* OMP_SECTIONS:                          OpenMP.             (line    6)
+* OMP_SINGLE:                            OpenMP.             (line    6)
+* 'one_cmplM2' instruction pattern:      Standard Names.     (line  753)
+* operand access:                        Accessors.          (line    6)
+* Operand Access Routines:               SSA Operands.       (line  116)
+* operand constraints:                   Constraints.        (line    6)
+* Operand Iterators:                     SSA Operands.       (line  116)
+* operand predicates:                    Predicates.         (line    6)
+* operand substitution:                  Output Template.    (line    6)
+* Operands:                              Operands.           (line    6)
+* operands:                              SSA Operands.       (line    6)
+* operands <1>:                          Patterns.           (line   53)
+* operator predicates:                   Predicates.         (line    6)
+* 'optc-gen.awk':                        Options.            (line    6)
+* OPTGROUP_ALL:                          Optimization groups.
+                                                             (line   25)
+* OPTGROUP_INLINE:                       Optimization groups.
+                                                             (line   15)
+* OPTGROUP_IPA:                          Optimization groups.
+                                                             (line    9)
+* OPTGROUP_LOOP:                         Optimization groups.
+                                                             (line   12)
+* OPTGROUP_OTHER:                        Optimization groups.
+                                                             (line   21)
+* OPTGROUP_VEC:                          Optimization groups.
+                                                             (line   18)
+* optimization dumps:                    Optimization info.  (line    6)
+* optimization groups:                   Optimization groups.
+                                                             (line    6)
+* optimization info file names:          Dump files and streams.
+                                                             (line    6)
+* Optimization infrastructure for GIMPLE: Tree SSA.          (line    6)
+* OPTIMIZE_MODE_SWITCHING:               Mode Switching.     (line    8)
+* option specification files:            Options.            (line    6)
+* optional hardware or system features:  Run-time Target.    (line   59)
+* options, directory search:             Including Patterns. (line   45)
+* OPTION_DEFAULT_SPECS:                  Driver.             (line   25)
+* order of register allocation:          Allocation Order.   (line    6)
+* ordered_comparison_operator:           Machine-Independent Predicates.
+                                                             (line  115)
+* ORDERED_EXPR:                          Unary and Binary Expressions.
+                                                             (line    6)
+* Ordering of Patterns:                  Pattern Ordering.   (line    6)
+* ORIGINAL_REGNO:                        Special Accessors.  (line   53)
+* other register constraints:            Simple Constraints. (line  171)
+* outgoing_args_size:                    Stack Arguments.    (line   48)
+* OUTGOING_REGNO:                        Register Basics.    (line   94)
+* OUTGOING_REG_PARM_STACK_SPACE:         Stack Arguments.    (line   73)
+* output of assembler code:              File Framework.     (line    6)
+* output statements:                     Output Statement.   (line    6)
+* output templates:                      Output Template.    (line    6)
+* output_asm_insn:                       Output Statement.   (line   52)
+* OUTPUT_QUOTED_STRING:                  File Framework.     (line  106)
+* OVERLAPPING_REGISTER_NAMES:            Instruction Output. (line   20)
+* OVERLOAD:                              Functions for C++.  (line    6)
+* OVERRIDE_ABI_FORMAT:                   Register Arguments. (line  139)
+* OVL_CURRENT:                           Functions for C++.  (line    6)
+* OVL_NEXT:                              Functions for C++.  (line    6)
+* 'p' in constraint:                     Simple Constraints. (line  162)
+* PAD_VARARGS_DOWN:                      Register Arguments. (line  220)
+* parallel:                              Side Effects.       (line  209)
+* parameters, c++ abi:                   C++ ABI.            (line    6)
+* parameters, miscellaneous:             Misc.               (line    6)
+* parameters, precompiled headers:       PCH Target.         (line    6)
+* paramN_is:                             GTY Options.        (line  138)
+* param_is:                              GTY Options.        (line  119)
+* parity:                                Arithmetic.         (line  243)
+* 'parityM2' instruction pattern:        Standard Names.     (line  747)
+* PARM_BOUNDARY:                         Storage Layout.     (line  133)
+* PARM_DECL:                             Declarations.       (line    6)
+* PARSE_LDD_OUTPUT:                      Macros for Initialization.
+                                                             (line  125)
+* pass dumps:                            Passes.             (line    6)
+* passes and files of the compiler:      Passes.             (line    6)
+* passing arguments:                     Interface.          (line   36)
+* pass_duplicate_computed_gotos:         Edges.              (line  161)
+* PATH_SEPARATOR:                        Filesystem.         (line   31)
+* PATTERN:                               Insns.              (line  284)
+* pattern conditions:                    Patterns.           (line   43)
+* pattern names:                         Standard Names.     (line    6)
+* Pattern Ordering:                      Pattern Ordering.   (line    6)
+* patterns:                              Patterns.           (line    6)
+* pc:                                    Regs and Memory.    (line  357)
+* 'pc' and attributes:                   Insn Lengths.       (line   20)
+* 'pc', RTL sharing:                     Sharing.            (line   25)
+* PCC_BITFIELD_TYPE_MATTERS:             Storage Layout.     (line  325)
+* PCC_STATIC_STRUCT_RETURN:              Aggregate Return.   (line   64)
+* PC_REGNUM:                             Register Basics.    (line  108)
+* pc_rtx:                                Regs and Memory.    (line  362)
+* PDImode:                               Machine Modes.      (line   40)
+* peephole optimization, RTL representation: Side Effects.   (line  243)
+* peephole optimizer definitions:        Peephole Definitions.
+                                                             (line    6)
+* per-function data:                     Per-Function Data.  (line    6)
+* percent sign:                          Output Template.    (line    6)
+* PHI nodes:                             SSA.                (line   31)
+* PIC:                                   PIC.                (line    6)
+* PIC_OFFSET_TABLE_REGNUM:               PIC.                (line   15)
+* PIC_OFFSET_TABLE_REG_CALL_CLOBBERED:   PIC.                (line   25)
+* pipeline hazard recognizer:            Processor pipeline description.
+                                                             (line    6)
+* pipeline hazard recognizer <1>:        Processor pipeline description.
+                                                             (line   53)
+* Plugins:                               Plugins.            (line    6)
+* plus:                                  Arithmetic.         (line   14)
+* 'plus' and attributes:                 Expressions.        (line   83)
+* 'plus', canonicalization of:           Insn Canonicalizations.
+                                                             (line   27)
+* PLUS_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* Pmode:                                 Misc.               (line  329)
+* pmode_register_operand:                Machine-Independent Predicates.
+                                                             (line   34)
+* pointer:                               Types.              (line    6)
+* POINTERS_EXTEND_UNSIGNED:              Storage Layout.     (line   76)
+* POINTER_PLUS_EXPR:                     Unary and Binary Expressions.
+                                                             (line    6)
+* POINTER_SIZE:                          Storage Layout.     (line   70)
+* POINTER_TYPE:                          Types.              (line    6)
+* popcount:                              Arithmetic.         (line  239)
+* 'popcountM2' instruction pattern:      Standard Names.     (line  741)
+* pops_args:                             Function Entry.     (line  104)
+* pop_operand:                           Machine-Independent Predicates.
+                                                             (line   87)
+* portability:                           Portability.        (line    6)
+* position independent code:             PIC.                (line    6)
+* POSTDECREMENT_EXPR:                    Unary and Binary Expressions.
+                                                             (line    6)
+* POSTINCREMENT_EXPR:                    Unary and Binary Expressions.
+                                                             (line    6)
+* post_dec:                              Incdec.             (line   25)
+* post_inc:                              Incdec.             (line   30)
+* post_modify:                           Incdec.             (line   33)
+* post_order_compute, inverted_post_order_compute, walk_dominator_tree: Basic Blocks.
+                                                             (line   34)
+* POWI_MAX_MULTS:                        Misc.               (line  860)
+* 'powM3' instruction pattern:           Standard Names.     (line  615)
+* pragma:                                Misc.               (line  387)
+* PREDECREMENT_EXPR:                     Unary and Binary Expressions.
+                                                             (line    6)
+* predefined macros:                     Run-time Target.    (line    6)
+* predicates:                            Predicates.         (line    6)
+* predicates and machine modes:          Predicates.         (line   31)
+* predication:                           Conditional Execution.
+                                                             (line    6)
+* predict.def:                           Profile information.
+                                                             (line   24)
+* PREFERRED_DEBUGGING_TYPE:              All Debuggers.      (line   41)
+* PREFERRED_RELOAD_CLASS:                Register Classes.   (line  249)
+* PREFERRED_STACK_BOUNDARY:              Storage Layout.     (line  147)
+* prefetch:                              Side Effects.       (line  323)
+* 'prefetch' and '/v':                   Flags.              (line  214)
+* 'prefetch' instruction pattern:        Standard Names.     (line 1562)
+* PREFETCH_SCHEDULE_BARRIER_P:           Flags.              (line  214)
+* PREINCREMENT_EXPR:                     Unary and Binary Expressions.
+                                                             (line    6)
+* presence_set:                          Processor pipeline description.
+                                                             (line  223)
+* preserving SSA form:                   SSA.                (line   74)
+* preserving virtual SSA form:           SSA.                (line  182)
+* pretend_args_size:                     Function Entry.     (line  110)
+* prev_active_insn:                      define_peephole.    (line   60)
+* PREV_INSN:                             Insns.              (line   26)
+* pre_dec:                               Incdec.             (line    8)
+* PRE_GCC3_DWARF_FRAME_REGISTERS:        Frame Registers.    (line  126)
+* pre_inc:                               Incdec.             (line   22)
+* pre_modify:                            Incdec.             (line   52)
+* PRINT_OPERAND:                         Instruction Output. (line   95)
+* PRINT_OPERAND_ADDRESS:                 Instruction Output. (line  122)
+* PRINT_OPERAND_PUNCT_VALID_P:           Instruction Output. (line  115)
+* 'probe_stack' instruction pattern:     Standard Names.     (line 1411)
+* 'probe_stack_address' instruction pattern: Standard Names. (line 1404)
+* processor functional units:            Processor pipeline description.
+                                                             (line    6)
+* processor functional units <1>:        Processor pipeline description.
+                                                             (line   68)
+* processor pipeline description:        Processor pipeline description.
+                                                             (line    6)
+* product:                               Arithmetic.         (line   93)
+* profile feedback:                      Profile information.
+                                                             (line   14)
+* profile representation:                Profile information.
+                                                             (line    6)
+* PROFILE_BEFORE_PROLOGUE:               Profiling.          (line   34)
+* PROFILE_HOOK:                          Profiling.          (line   22)
+* profiling, code generation:            Profiling.          (line    6)
+* program counter:                       Regs and Memory.    (line  358)
+* prologue:                              Function Entry.     (line    6)
+* 'prologue' instruction pattern:        Standard Names.     (line 1500)
+* PROMOTE_MODE:                          Storage Layout.     (line   87)
+* pseudo registers:                      Regs and Memory.    (line    9)
+* PSImode:                               Machine Modes.      (line   32)
+* PTRDIFF_TYPE:                          Type Layout.        (line  200)
+* purge_dead_edges:                      Edges.              (line  103)
+* purge_dead_edges <1>:                  Maintaining the CFG.
+                                                             (line   81)
+* push address instruction:              Simple Constraints. (line  162)
+* 'pushM1' instruction pattern:          Standard Names.     (line  253)
+* PUSH_ARGS:                             Stack Arguments.    (line   17)
+* PUSH_ARGS_REVERSED:                    Stack Arguments.    (line   25)
+* push_operand:                          Machine-Independent Predicates.
+                                                             (line   80)
+* push_reload:                           Addressing Modes.   (line  176)
+* PUSH_ROUNDING:                         Stack Arguments.    (line   31)
+* PUT_CODE:                              RTL Objects.        (line   47)
+* PUT_MODE:                              Machine Modes.      (line  285)
+* PUT_REG_NOTE_KIND:                     Insns.              (line  346)
+* PUT_SDB_:                              SDB and DWARF.      (line  105)
+* QCmode:                                Machine Modes.      (line  199)
+* QFmode:                                Machine Modes.      (line   57)
+* QImode:                                Machine Modes.      (line   25)
+* 'QImode', in 'insn':                   Insns.              (line  268)
+* QQmode:                                Machine Modes.      (line  106)
+* qualified type:                        Types.              (line    6)
+* qualified type <1>:                    Types for C++.      (line    6)
+* querying function unit reservations:   Processor pipeline description.
+                                                             (line   90)
+* question mark:                         Multi-Alternative.  (line   41)
+* quotient:                              Arithmetic.         (line  117)
+* 'r' in constraint:                     Simple Constraints. (line   64)
+* RDIV_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* READONLY_DATA_SECTION_ASM_OP:          Sections.           (line   62)
+* real operands:                         SSA Operands.       (line    6)
+* REALPART_EXPR:                         Unary and Binary Expressions.
+                                                             (line    6)
+* REAL_ARITHMETIC:                       Floating Point.     (line   64)
+* REAL_CST:                              Constant expressions.
+                                                             (line    6)
+* REAL_LIBGCC_SPEC:                      Driver.             (line  124)
+* REAL_NM_FILE_NAME:                     Macros for Initialization.
+                                                             (line  105)
+* REAL_TYPE:                             Types.              (line    6)
+* REAL_VALUES_EQUAL:                     Floating Point.     (line   31)
+* REAL_VALUES_LESS:                      Floating Point.     (line   37)
+* REAL_VALUE_ABS:                        Floating Point.     (line   81)
+* REAL_VALUE_ATOF:                       Floating Point.     (line   48)
+* REAL_VALUE_FIX:                        Floating Point.     (line   40)
+* REAL_VALUE_FROM_INT:                   Floating Point.     (line   90)
+* REAL_VALUE_ISINF:                      Floating Point.     (line   58)
+* REAL_VALUE_ISNAN:                      Floating Point.     (line   61)
+* REAL_VALUE_NEGATE:                     Floating Point.     (line   78)
+* REAL_VALUE_NEGATIVE:                   Floating Point.     (line   55)
+* REAL_VALUE_TO_INT:                     Floating Point.     (line   84)
+* REAL_VALUE_TO_TARGET_DECIMAL128:       Data Output.        (line  143)
+* REAL_VALUE_TO_TARGET_DECIMAL32:        Data Output.        (line  141)
+* REAL_VALUE_TO_TARGET_DECIMAL64:        Data Output.        (line  142)
+* REAL_VALUE_TO_TARGET_DOUBLE:           Data Output.        (line  139)
+* REAL_VALUE_TO_TARGET_LONG_DOUBLE:      Data Output.        (line  140)
+* REAL_VALUE_TO_TARGET_SINGLE:           Data Output.        (line  138)
+* REAL_VALUE_TYPE:                       Floating Point.     (line   25)
+* REAL_VALUE_UNSIGNED_FIX:               Floating Point.     (line   43)
+* recognizing insns:                     RTL Template.       (line    6)
+* recog_data.operand:                    Instruction Output. (line   54)
+* RECORD_TYPE:                           Types.              (line    6)
+* RECORD_TYPE <1>:                       Classes.            (line    6)
+* redirect_edge_and_branch:              Profile information.
+                                                             (line   71)
+* redirect_edge_and_branch, redirect_jump: Maintaining the CFG.
+                                                             (line   90)
+* 'reduc_smax_M' instruction pattern:    Standard Names.     (line  317)
+* 'reduc_smin_M' instruction pattern:    Standard Names.     (line  317)
+* 'reduc_splus_M' instruction pattern:   Standard Names.     (line  329)
+* 'reduc_umax_M' instruction pattern:    Standard Names.     (line  323)
+* 'reduc_umin_M' instruction pattern:    Standard Names.     (line  323)
+* 'reduc_uplus_M' instruction pattern:   Standard Names.     (line  335)
+* reference:                             Types.              (line    6)
+* REFERENCE_TYPE:                        Types.              (line    6)
+* reg:                                   Regs and Memory.    (line    9)
+* 'reg' and '/f':                        Flags.              (line   94)
+* 'reg' and '/i':                        Flags.              (line   89)
+* 'reg' and '/v':                        Flags.              (line   98)
+* 'reg', RTL sharing:                    Sharing.            (line   17)
+* regclass_for_constraint:               C Constraint Interface.
+                                                             (line   58)
+* register allocation order:             Allocation Order.   (line    6)
+* register class definitions:            Register Classes.   (line    6)
+* register class preference constraints: Class Preferences.  (line    6)
+* register pairs:                        Values in Registers.
+                                                             (line   69)
+* Register Transfer Language (RTL):      RTL.                (line    6)
+* register usage:                        Registers.          (line    6)
+* registers arguments:                   Register Arguments. (line    6)
+* registers in constraints:              Simple Constraints. (line   64)
+* REGISTER_MOVE_COST:                    Costs.              (line    9)
+* REGISTER_NAMES:                        Instruction Output. (line    8)
+* register_operand:                      Machine-Independent Predicates.
+                                                             (line   29)
+* REGISTER_PREFIX:                       Instruction Output. (line  150)
+* REGISTER_TARGET_PRAGMAS:               Misc.               (line  387)
+* REGMODE_NATURAL_SIZE:                  Values in Registers.
+                                                             (line   49)
+* REGNO_MODE_CODE_OK_FOR_BASE_P:         Register Classes.   (line  172)
+* REGNO_MODE_OK_FOR_BASE_P:              Register Classes.   (line  150)
+* REGNO_MODE_OK_FOR_REG_BASE_P:          Register Classes.   (line  160)
+* REGNO_OK_FOR_BASE_P:                   Register Classes.   (line  146)
+* REGNO_OK_FOR_INDEX_P:                  Register Classes.   (line  186)
+* REGNO_REG_CLASS:                       Register Classes.   (line  105)
+* regs_ever_live:                        Function Entry.     (line   21)
+* regular expressions:                   Processor pipeline description.
+                                                             (line    6)
+* regular expressions <1>:               Processor pipeline description.
+                                                             (line  105)
+* REG_ALLOC_ORDER:                       Allocation Order.   (line    8)
+* REG_BR_PRED:                           Insns.              (line  526)
+* REG_BR_PROB:                           Insns.              (line  519)
+* REG_BR_PROB_BASE, BB_FREQ_BASE, count: Profile information.
+                                                             (line   82)
+* REG_BR_PROB_BASE, EDGE_FREQUENCY:      Profile information.
+                                                             (line   52)
+* REG_CC_SETTER:                         Insns.              (line  491)
+* REG_CC_USER:                           Insns.              (line  491)
+* reg_class_contents:                    Register Basics.    (line   59)
+* REG_CLASS_CONTENTS:                    Register Classes.   (line   91)
+* REG_CLASS_FROM_CONSTRAINT:             Old Constraints.    (line   33)
+* REG_CLASS_FROM_LETTER:                 Old Constraints.    (line   25)
+* REG_CLASS_NAMES:                       Register Classes.   (line   86)
+* REG_CROSSING_JUMP:                     Insns.              (line  405)
+* REG_DEAD:                              Insns.              (line  357)
+* REG_DEAD, REG_UNUSED:                  Liveness information.
+                                                             (line   32)
+* REG_DEP_ANTI:                          Insns.              (line  513)
+* REG_DEP_OUTPUT:                        Insns.              (line  509)
+* REG_DEP_TRUE:                          Insns.              (line  506)
+* REG_EH_REGION, EDGE_ABNORMAL_CALL:     Edges.              (line  109)
+* REG_EQUAL:                             Insns.              (line  420)
+* REG_EQUIV:                             Insns.              (line  420)
+* REG_EXPR:                              Special Accessors.  (line   58)
+* REG_FRAME_RELATED_EXPR:                Insns.              (line  532)
+* REG_FUNCTION_VALUE_P:                  Flags.              (line   89)
+* REG_INC:                               Insns.              (line  373)
+* 'reg_label' and '/v':                  Flags.              (line   65)
+* REG_LABEL_OPERAND:                     Insns.              (line  387)
+* REG_LABEL_TARGET:                      Insns.              (line  396)
+* reg_names:                             Register Basics.    (line   59)
+* reg_names <1>:                         Instruction Output. (line  107)
+* REG_NONNEG:                            Insns.              (line  379)
+* REG_NOTES:                             Insns.              (line  321)
+* REG_NOTE_KIND:                         Insns.              (line  346)
+* REG_OFFSET:                            Special Accessors.  (line   62)
+* REG_OK_STRICT:                         Addressing Modes.   (line   99)
+* REG_PARM_STACK_SPACE:                  Stack Arguments.    (line   58)
+* 'REG_PARM_STACK_SPACE', and 'TARGET_FUNCTION_ARG': Register Arguments.
+                                                             (line   50)
+* REG_POINTER:                           Flags.              (line   94)
+* REG_SETJMP:                            Insns.              (line  414)
+* REG_UNUSED:                            Insns.              (line  366)
+* REG_USERVAR_P:                         Flags.              (line   98)
+* REG_VALUE_IN_UNWIND_CONTEXT:           Frame Registers.    (line  158)
+* REG_WORDS_BIG_ENDIAN:                  Storage Layout.     (line   35)
+* relative costs:                        Costs.              (line    6)
+* RELATIVE_PREFIX_NOT_LINKDIR:           Driver.             (line  262)
+* reloading:                             RTL passes.         (line  170)
+* reload_completed:                      Standard Names.     (line 1199)
+* 'reload_in' instruction pattern:       Standard Names.     (line   98)
+* reload_in_progress:                    Standard Names.     (line   57)
+* 'reload_out' instruction pattern:      Standard Names.     (line   98)
+* remainder:                             Arithmetic.         (line  137)
+* 'remainderM3' instruction pattern:     Standard Names.     (line  561)
+* reorder:                               GTY Options.        (line  224)
+* representation of RTL:                 RTL.                (line    6)
+* reservation delays:                    Processor pipeline description.
+                                                             (line    6)
+* 'restore_stack_block' instruction pattern: Standard Names. (line 1325)
+* 'restore_stack_function' instruction pattern: Standard Names.
+                                                             (line 1325)
+* 'restore_stack_nonlocal' instruction pattern: Standard Names.
+                                                             (line 1325)
+* rest_of_decl_compilation:              Parsing pass.       (line   51)
+* rest_of_type_compilation:              Parsing pass.       (line   51)
+* RESULT_DECL:                           Declarations.       (line    6)
+* return:                                Side Effects.       (line   72)
+* 'return' instruction pattern:          Standard Names.     (line 1173)
+* return values in registers:            Scalar Return.      (line    6)
+* returning aggregate values:            Aggregate Return.   (line    6)
+* returning structures and unions:       Interface.          (line   10)
+* RETURN_ADDRESS_POINTER_REGNUM:         Frame Registers.    (line   64)
+* RETURN_ADDR_IN_PREVIOUS_FRAME:         Frame Layout.       (line  133)
+* RETURN_ADDR_OFFSET:                    Exception Handling. (line   59)
+* RETURN_ADDR_RTX:                       Frame Layout.       (line  122)
+* RETURN_EXPR:                           Statements for C++. (line    6)
+* RETURN_STMT:                           Statements for C++. (line    6)
+* return_val:                            Flags.              (line  274)
+* 'return_val', in 'call_insn':          Flags.              (line   24)
+* 'return_val', in 'reg':                Flags.              (line   89)
+* 'return_val', in 'symbol_ref':         Flags.              (line  202)
+* reverse probability:                   Profile information.
+                                                             (line   66)
+* REVERSE_CONDITION:                     MODE_CC Condition Codes.
+                                                             (line   90)
+* REVERSIBLE_CC_MODE:                    MODE_CC Condition Codes.
+                                                             (line   76)
+* right rotate:                          Arithmetic.         (line  196)
+* right shift:                           Arithmetic.         (line  191)
+* 'rintM2' instruction pattern:          Standard Names.     (line  674)
+* RISC:                                  Processor pipeline description.
+                                                             (line    6)
+* RISC <1>:                              Processor pipeline description.
+                                                             (line  223)
+* roots, marking:                        GGC Roots.          (line    6)
+* rotate:                                Arithmetic.         (line  196)
+* rotate <1>:                            Arithmetic.         (line  196)
+* rotatert:                              Arithmetic.         (line  196)
+* 'rotlM3' instruction pattern:          Standard Names.     (line  526)
+* 'rotrM3' instruction pattern:          Standard Names.     (line  526)
+* 'roundM2' instruction pattern:         Standard Names.     (line  650)
+* ROUND_DIV_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* ROUND_MOD_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* ROUND_TOWARDS_ZERO:                    Storage Layout.     (line  474)
+* ROUND_TYPE_ALIGN:                      Storage Layout.     (line  422)
+* RSHIFT_EXPR:                           Unary and Binary Expressions.
+                                                             (line    6)
+* RTL addition:                          Arithmetic.         (line   14)
+* RTL addition with signed saturation:   Arithmetic.         (line   14)
+* RTL addition with unsigned saturation: Arithmetic.         (line   14)
+* RTL classes:                           RTL Classes.        (line    6)
+* RTL comparison:                        Arithmetic.         (line   46)
+* RTL comparison operations:             Comparisons.        (line    6)
+* RTL constant expression types:         Constants.          (line    6)
+* RTL constants:                         Constants.          (line    6)
+* RTL declarations:                      RTL Declarations.   (line    6)
+* RTL difference:                        Arithmetic.         (line   38)
+* RTL expression:                        RTL Objects.        (line    6)
+* RTL expressions for arithmetic:        Arithmetic.         (line    6)
+* RTL format:                            RTL Classes.        (line   72)
+* RTL format characters:                 RTL Classes.        (line   77)
+* RTL function-call insns:               Calls.              (line    6)
+* RTL insn template:                     RTL Template.       (line    6)
+* RTL integers:                          RTL Objects.        (line    6)
+* RTL memory expressions:                Regs and Memory.    (line    6)
+* RTL object types:                      RTL Objects.        (line    6)
+* RTL postdecrement:                     Incdec.             (line    6)
+* RTL postincrement:                     Incdec.             (line    6)
+* RTL predecrement:                      Incdec.             (line    6)
+* RTL preincrement:                      Incdec.             (line    6)
+* RTL register expressions:              Regs and Memory.    (line    6)
+* RTL representation:                    RTL.                (line    6)
+* RTL side effect expressions:           Side Effects.       (line    6)
+* RTL strings:                           RTL Objects.        (line    6)
+* RTL structure sharing assumptions:     Sharing.            (line    6)
+* RTL subtraction:                       Arithmetic.         (line   38)
+* RTL subtraction with signed saturation: Arithmetic.        (line   38)
+* RTL subtraction with unsigned saturation: Arithmetic.      (line   38)
+* RTL sum:                               Arithmetic.         (line   14)
+* RTL vectors:                           RTL Objects.        (line    6)
+* RTL_CONST_CALL_P:                      Flags.              (line   19)
+* RTL_CONST_OR_PURE_CALL_P:              Flags.              (line   29)
+* RTL_LOOPING_CONST_OR_PURE_CALL_P:      Flags.              (line   33)
+* RTL_PURE_CALL_P:                       Flags.              (line   24)
+* RTX (See RTL):                         RTL Objects.        (line    6)
+* RTX codes, classes of:                 RTL Classes.        (line    6)
+* RTX_FRAME_RELATED_P:                   Flags.              (line  107)
+* run-time conventions:                  Interface.          (line    6)
+* run-time target specification:         Run-time Target.    (line    6)
+* 's' in constraint:                     Simple Constraints. (line  100)
+* same_type_p:                           Types.              (line   86)
+* SAmode:                                Machine Modes.      (line  150)
+* 'satfractMN2' instruction pattern:     Standard Names.     (line  938)
+* 'satfractunsMN2' instruction pattern:  Standard Names.     (line  951)
+* satisfies_constraint_:                 C Constraint Interface.
+                                                             (line   46)
+* sat_fract:                             Conversions.        (line   90)
+* SAVE_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* 'save_stack_block' instruction pattern: Standard Names.    (line 1325)
+* 'save_stack_function' instruction pattern: Standard Names. (line 1325)
+* 'save_stack_nonlocal' instruction pattern: Standard Names. (line 1325)
+* SBSS_SECTION_ASM_OP:                   Sections.           (line   75)
+* Scalar evolutions:                     Scalar evolutions.  (line    6)
+* scalars, returned as values:           Scalar Return.      (line    6)
+* SCHED_GROUP_P:                         Flags.              (line  148)
+* SCmode:                                Machine Modes.      (line  199)
+* scratch:                               Regs and Memory.    (line  294)
+* scratch operands:                      Regs and Memory.    (line  294)
+* 'scratch', RTL sharing:                Sharing.            (line   35)
+* scratch_operand:                       Machine-Independent Predicates.
+                                                             (line   49)
+* SDATA_SECTION_ASM_OP:                  Sections.           (line   57)
+* SDB_ALLOW_FORWARD_REFERENCES:          SDB and DWARF.      (line  123)
+* SDB_ALLOW_UNKNOWN_REFERENCES:          SDB and DWARF.      (line  118)
+* SDB_DEBUGGING_INFO:                    SDB and DWARF.      (line    8)
+* SDB_DELIM:                             SDB and DWARF.      (line  111)
+* SDB_OUTPUT_SOURCE_LINE:                SDB and DWARF.      (line  128)
+* SDmode:                                Machine Modes.      (line   88)
+* 'sdot_prodM' instruction pattern:      Standard Names.     (line  341)
+* search options:                        Including Patterns. (line   45)
+* SECONDARY_INPUT_RELOAD_CLASS:          Register Classes.   (line  391)
+* SECONDARY_MEMORY_NEEDED:               Register Classes.   (line  447)
+* SECONDARY_MEMORY_NEEDED_MODE:          Register Classes.   (line  466)
+* SECONDARY_MEMORY_NEEDED_RTX:           Register Classes.   (line  457)
+* SECONDARY_OUTPUT_RELOAD_CLASS:         Register Classes.   (line  392)
+* SECONDARY_RELOAD_CLASS:                Register Classes.   (line  390)
+* SELECT_CC_MODE:                        MODE_CC Condition Codes.
+                                                             (line    6)
+* sequence:                              Side Effects.       (line  258)
+* Sequence iterators:                    Sequence iterators. (line    6)
+* set:                                   Side Effects.       (line   15)
+* 'set' and '/f':                        Flags.              (line  107)
+* 'setmemM' instruction pattern:         Standard Names.     (line  802)
+* SETUP_FRAME_ADDRESSES:                 Frame Layout.       (line  100)
+* SET_ASM_OP:                            Label Output.       (line  416)
+* SET_ASM_OP <1>:                        Label Output.       (line  427)
+* set_attr:                              Tagging Insns.      (line   31)
+* set_attr_alternative:                  Tagging Insns.      (line   49)
+* set_bb_seq:                            GIMPLE sequences.   (line   75)
+* SET_BY_PIECES_P:                       Costs.              (line  205)
+* SET_DEST:                              Side Effects.       (line   69)
+* SET_IS_RETURN_P:                       Flags.              (line  157)
+* SET_LABEL_KIND:                        Insns.              (line  146)
+* set_optab_libfunc:                     Library Calls.      (line   15)
+* SET_RATIO:                             Costs.              (line  193)
+* SET_SRC:                               Side Effects.       (line   69)
+* 'set_thread_pointerMODE' instruction pattern: Standard Names.
+                                                             (line 1869)
+* SET_TYPE_STRUCTURAL_EQUALITY:          Types.              (line    6)
+* SET_TYPE_STRUCTURAL_EQUALITY <1>:      Types.              (line   81)
+* SFmode:                                Machine Modes.      (line   69)
+* SF_SIZE:                               Type Layout.        (line  135)
+* sharing of RTL components:             Sharing.            (line    6)
+* shift:                                 Arithmetic.         (line  174)
+* SHIFT_COUNT_TRUNCATED:                 Misc.               (line  112)
+* SHLIB_SUFFIX:                          Macros for Initialization.
+                                                             (line  133)
+* SHORT_ACCUM_TYPE_SIZE:                 Type Layout.        (line   82)
+* SHORT_FRACT_TYPE_SIZE:                 Type Layout.        (line   62)
+* SHORT_IMMEDIATES_SIGN_EXTEND:          Misc.               (line   86)
+* SHORT_TYPE_SIZE:                       Type Layout.        (line   15)
+* 'sibcall_epilogue' instruction pattern: Standard Names.    (line 1532)
+* sibling call:                          Edges.              (line  121)
+* SIBLING_CALL_P:                        Flags.              (line  161)
+* signed division:                       Arithmetic.         (line  117)
+* signed division with signed saturation: Arithmetic.        (line  117)
+* signed maximum:                        Arithmetic.         (line  142)
+* signed minimum:                        Arithmetic.         (line  142)
+* sign_extend:                           Conversions.        (line   23)
+* sign_extract:                          Bit-Fields.         (line    8)
+* 'sign_extract', canonicalization of:   Insn Canonicalizations.
+                                                             (line   87)
+* SIG_ATOMIC_TYPE:                       Type Layout.        (line  251)
+* SImode:                                Machine Modes.      (line   37)
+* simple constraints:                    Simple Constraints. (line    6)
+* simple_return:                         Side Effects.       (line   86)
+* 'simple_return' instruction pattern:   Standard Names.     (line 1188)
+* 'sincosM3' instruction pattern:        Standard Names.     (line  586)
+* 'sinM2' instruction pattern:           Standard Names.     (line  578)
+* SIZETYPE:                              Type Layout.        (line  190)
+* SIZE_ASM_OP:                           Label Output.       (line   33)
+* SIZE_TYPE:                             Type Layout.        (line  174)
+* skip:                                  GTY Options.        (line   76)
+* SLOW_BYTE_ACCESS:                      Costs.              (line  117)
+* SLOW_UNALIGNED_ACCESS:                 Costs.              (line  132)
+* smax:                                  Arithmetic.         (line  142)
+* smin:                                  Arithmetic.         (line  142)
+* sms, swing, software pipelining:       RTL passes.         (line  123)
+* 'smulM3_highpart' instruction pattern: Standard Names.     (line  441)
+* soft float library:                    Soft float library routines.
+                                                             (line    6)
+* special:                               GTY Options.        (line  311)
+* special predicates:                    Predicates.         (line   31)
+* SPECS:                                 Target Fragment.    (line  191)
+* speed of instructions:                 Costs.              (line    6)
+* splitting instructions:                Insn Splitting.     (line    6)
+* split_block:                           Maintaining the CFG.
+                                                             (line   97)
+* SQmode:                                Machine Modes.      (line  114)
+* sqrt:                                  Arithmetic.         (line  207)
+* 'sqrtM2' instruction pattern:          Standard Names.     (line  544)
+* square root:                           Arithmetic.         (line  207)
+* SSA:                                   SSA.                (line    6)
+* 'ssaddM3' instruction pattern:         Standard Names.     (line  276)
+* 'ssashlM3' instruction pattern:        Standard Names.     (line  516)
+* SSA_NAME_DEF_STMT:                     SSA.                (line  216)
+* SSA_NAME_VERSION:                      SSA.                (line  221)
+* 'ssdivM3' instruction pattern:         Standard Names.     (line  276)
+* 'ssmaddMN4' instruction pattern:       Standard Names.     (line  464)
+* 'ssmsubMN4' instruction pattern:       Standard Names.     (line  488)
+* 'ssmulM3' instruction pattern:         Standard Names.     (line  276)
+* 'ssnegM2' instruction pattern:         Standard Names.     (line  538)
+* 'sssubM3' instruction pattern:         Standard Names.     (line  276)
+* 'ssum_widenM3' instruction pattern:    Standard Names.     (line  350)
+* ss_abs:                                Arithmetic.         (line  201)
+* ss_ashift:                             Arithmetic.         (line  174)
+* ss_div:                                Arithmetic.         (line  117)
+* ss_minus:                              Arithmetic.         (line   38)
+* ss_mult:                               Arithmetic.         (line   93)
+* ss_neg:                                Arithmetic.         (line   82)
+* ss_plus:                               Arithmetic.         (line   14)
+* ss_truncate:                           Conversions.        (line   43)
+* stack arguments:                       Stack Arguments.    (line    6)
+* stack frame layout:                    Frame Layout.       (line    6)
+* stack smashing protection:             Stack Smashing Protection.
+                                                             (line    6)
+* STACK_ALIGNMENT_NEEDED:                Frame Layout.       (line   47)
+* STACK_BOUNDARY:                        Storage Layout.     (line  139)
+* STACK_CHECK_BUILTIN:                   Stack Checking.     (line   31)
+* STACK_CHECK_FIXED_FRAME_SIZE:          Stack Checking.     (line   82)
+* STACK_CHECK_MAX_FRAME_SIZE:            Stack Checking.     (line   73)
+* STACK_CHECK_MAX_VAR_SIZE:              Stack Checking.     (line   89)
+* STACK_CHECK_MOVING_SP:                 Stack Checking.     (line   53)
+* STACK_CHECK_PROBE_INTERVAL_EXP:        Stack Checking.     (line   45)
+* STACK_CHECK_PROTECT:                   Stack Checking.     (line   62)
+* STACK_CHECK_STATIC_BUILTIN:            Stack Checking.     (line   38)
+* STACK_DYNAMIC_OFFSET:                  Frame Layout.       (line   73)
+* 'STACK_DYNAMIC_OFFSET' and virtual registers: Regs and Memory.
+                                                             (line   83)
+* STACK_GROWS_DOWNWARD:                  Frame Layout.       (line    8)
+* STACK_PARMS_IN_REG_PARM_AREA:          Stack Arguments.    (line   83)
+* STACK_POINTER_OFFSET:                  Frame Layout.       (line   57)
+* 'STACK_POINTER_OFFSET' and virtual registers: Regs and Memory.
+                                                             (line   93)
+* STACK_POINTER_REGNUM:                  Frame Registers.    (line    8)
+* 'STACK_POINTER_REGNUM' and virtual registers: Regs and Memory.
+                                                             (line   83)
+* stack_pointer_rtx:                     Frame Registers.    (line  104)
+* 'stack_protect_set' instruction pattern: Standard Names.   (line 1879)
+* 'stack_protect_test' instruction pattern: Standard Names.  (line 1890)
+* STACK_PUSH_CODE:                       Frame Layout.       (line   16)
+* STACK_REGS:                            Stack Registers.    (line   19)
+* STACK_REG_COVER_CLASS:                 Stack Registers.    (line   22)
+* STACK_SAVEAREA_MODE:                   Storage Layout.     (line  438)
+* STACK_SIZE_MODE:                       Storage Layout.     (line  449)
+* STACK_SLOT_ALIGNMENT:                  Storage Layout.     (line  270)
+* standard pattern names:                Standard Names.     (line    6)
+* STANDARD_STARTFILE_PREFIX:             Driver.             (line  274)
+* STANDARD_STARTFILE_PREFIX_1:           Driver.             (line  281)
+* STANDARD_STARTFILE_PREFIX_2:           Driver.             (line  288)
+* STARTFILE_SPEC:                        Driver.             (line  147)
+* STARTING_FRAME_OFFSET:                 Frame Layout.       (line   38)
+* 'STARTING_FRAME_OFFSET' and virtual registers: Regs and Memory.
+                                                             (line   74)
+* Statement and operand traversals:      Statement and operand traversals.
+                                                             (line    6)
+* Statement Sequences:                   Statement Sequences.
+                                                             (line    6)
+* Statements:                            Statements.         (line    6)
+* statements:                            Function Properties.
+                                                             (line    6)
+* statements <1>:                        Statements for C++. (line    6)
+* Static profile estimation:             Profile information.
+                                                             (line   24)
+* static single assignment:              SSA.                (line    6)
+* STATIC_CHAIN_INCOMING_REGNUM:          Frame Registers.    (line   77)
+* STATIC_CHAIN_REGNUM:                   Frame Registers.    (line   76)
+* 'stdarg.h' and register arguments:     Register Arguments. (line   45)
+* STDC_0_IN_SYSTEM_HEADERS:              Misc.               (line  350)
+* STMT_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* STMT_IS_FULL_EXPR_P:                   Statements for C++. (line   22)
+* storage layout:                        Storage Layout.     (line    6)
+* STORE_BY_PIECES_P:                     Costs.              (line  212)
+* STORE_FLAG_VALUE:                      Misc.               (line  201)
+* 'store_multiple' instruction pattern:  Standard Names.     (line  159)
+* strcpy:                                Storage Layout.     (line  223)
+* STRICT_ALIGNMENT:                      Storage Layout.     (line  320)
+* strict_low_part:                       RTL Declarations.   (line    9)
+* strict_memory_address_p:               Addressing Modes.   (line  186)
+* STRING_CST:                            Constant expressions.
+                                                             (line    6)
+* STRING_POOL_ADDRESS_P:                 Flags.              (line  165)
+* 'strlenM' instruction pattern:         Standard Names.     (line  873)
+* structure value address:               Aggregate Return.   (line    6)
+* structures, returning:                 Interface.          (line   10)
+* STRUCTURE_SIZE_BOUNDARY:               Storage Layout.     (line  312)
+* 'subM3' instruction pattern:           Standard Names.     (line  276)
+* SUBOBJECT:                             Statements for C++. (line    6)
+* SUBOBJECT_CLEANUP:                     Statements for C++. (line    6)
+* subreg:                                Regs and Memory.    (line   97)
+* 'subreg' and '/s':                     Flags.              (line  187)
+* 'subreg' and '/u':                     Flags.              (line  180)
+* 'subreg' and '/u' and '/v':            Flags.              (line  170)
+* 'subreg', in 'strict_low_part':        RTL Declarations.   (line    9)
+* SUBREG_BYTE:                           Regs and Memory.    (line  285)
+* SUBREG_PROMOTED_UNSIGNED_P:            Flags.              (line  170)
+* SUBREG_PROMOTED_UNSIGNED_SET:          Flags.              (line  180)
+* SUBREG_PROMOTED_VAR_P:                 Flags.              (line  187)
+* SUBREG_REG:                            Regs and Memory.    (line  285)
+* subst iterators in '.md' files:        Subst Iterators.    (line    6)
+* SUCCESS_EXIT_CODE:                     Host Misc.          (line   12)
+* SUPPORTS_INIT_PRIORITY:                Macros for Initialization.
+                                                             (line   57)
+* SUPPORTS_ONE_ONLY:                     Label Output.       (line  255)
+* SUPPORTS_WEAK:                         Label Output.       (line  229)
+* SWITCHABLE_TARGET:                     Run-time Target.    (line  164)
+* SWITCH_BODY:                           Statements for C++. (line    6)
+* SWITCH_COND:                           Statements for C++. (line    6)
+* SWITCH_STMT:                           Statements for C++. (line    6)
+* symbolic label:                        Sharing.            (line   20)
+* SYMBOL_FLAG_ANCHOR:                    Special Accessors.  (line  117)
+* SYMBOL_FLAG_EXTERNAL:                  Special Accessors.  (line   99)
+* SYMBOL_FLAG_FUNCTION:                  Special Accessors.  (line   92)
+* SYMBOL_FLAG_HAS_BLOCK_INFO:            Special Accessors.  (line  113)
+* SYMBOL_FLAG_LOCAL:                     Special Accessors.  (line   95)
+* SYMBOL_FLAG_SMALL:                     Special Accessors.  (line  104)
+* SYMBOL_FLAG_TLS_SHIFT:                 Special Accessors.  (line  108)
+* symbol_ref:                            Constants.          (line   86)
+* 'symbol_ref' and '/f':                 Flags.              (line  165)
+* 'symbol_ref' and '/i':                 Flags.              (line  202)
+* 'symbol_ref' and '/u':                 Flags.              (line   10)
+* 'symbol_ref' and '/v':                 Flags.              (line  206)
+* 'symbol_ref', RTL sharing:             Sharing.            (line   20)
+* SYMBOL_REF_ANCHOR_P:                   Special Accessors.  (line  117)
+* SYMBOL_REF_BLOCK:                      Special Accessors.  (line  130)
+* SYMBOL_REF_BLOCK_OFFSET:               Special Accessors.  (line  135)
+* SYMBOL_REF_CONSTANT:                   Special Accessors.  (line   78)
+* SYMBOL_REF_DATA:                       Special Accessors.  (line   82)
+* SYMBOL_REF_DECL:                       Special Accessors.  (line   67)
+* SYMBOL_REF_EXTERNAL_P:                 Special Accessors.  (line   99)
+* SYMBOL_REF_FLAG:                       Flags.              (line  206)
+* 'SYMBOL_REF_FLAG', in 'TARGET_ENCODE_SECTION_INFO': Sections.
+                                                             (line  277)
+* SYMBOL_REF_FLAGS:                      Special Accessors.  (line   86)
+* SYMBOL_REF_FUNCTION_P:                 Special Accessors.  (line   92)
+* SYMBOL_REF_HAS_BLOCK_INFO_P:           Special Accessors.  (line  113)
+* SYMBOL_REF_LOCAL_P:                    Special Accessors.  (line   95)
+* SYMBOL_REF_SMALL_P:                    Special Accessors.  (line  104)
+* SYMBOL_REF_TLS_MODEL:                  Special Accessors.  (line  108)
+* SYMBOL_REF_USED:                       Flags.              (line  197)
+* SYMBOL_REF_WEAK:                       Flags.              (line  202)
+* 'sync_addMODE' instruction pattern:    Standard Names.     (line 1635)
+* 'sync_andMODE' instruction pattern:    Standard Names.     (line 1635)
+* 'sync_compare_and_swapMODE' instruction pattern: Standard Names.
+                                                             (line 1594)
+* 'sync_iorMODE' instruction pattern:    Standard Names.     (line 1635)
+* 'sync_lock_releaseMODE' instruction pattern: Standard Names.
+                                                             (line 1704)
+* 'sync_lock_test_and_setMODE' instruction pattern: Standard Names.
+                                                             (line 1677)
+* 'sync_nandMODE' instruction pattern:   Standard Names.     (line 1635)
+* 'sync_new_addMODE' instruction pattern: Standard Names.    (line 1669)
+* 'sync_new_andMODE' instruction pattern: Standard Names.    (line 1669)
+* 'sync_new_iorMODE' instruction pattern: Standard Names.    (line 1669)
+* 'sync_new_nandMODE' instruction pattern: Standard Names.   (line 1669)
+* 'sync_new_subMODE' instruction pattern: Standard Names.    (line 1669)
+* 'sync_new_xorMODE' instruction pattern: Standard Names.    (line 1669)
+* 'sync_old_addMODE' instruction pattern: Standard Names.    (line 1651)
+* 'sync_old_andMODE' instruction pattern: Standard Names.    (line 1651)
+* 'sync_old_iorMODE' instruction pattern: Standard Names.    (line 1651)
+* 'sync_old_nandMODE' instruction pattern: Standard Names.   (line 1651)
+* 'sync_old_subMODE' instruction pattern: Standard Names.    (line 1651)
+* 'sync_old_xorMODE' instruction pattern: Standard Names.    (line 1651)
+* 'sync_subMODE' instruction pattern:    Standard Names.     (line 1635)
+* 'sync_xorMODE' instruction pattern:    Standard Names.     (line 1635)
+* SYSROOT_HEADERS_SUFFIX_SPEC:           Driver.             (line  176)
+* SYSROOT_SUFFIX_SPEC:                   Driver.             (line  171)
+* 't-TARGET':                            Target Fragment.    (line    6)
+* table jump:                            Basic Blocks.       (line   67)
+* 'tablejump' instruction pattern:       Standard Names.     (line 1261)
+* tag:                                   GTY Options.        (line   82)
+* tagging insns:                         Tagging Insns.      (line    6)
+* tail calls:                            Tail Calls.         (line    6)
+* TAmode:                                Machine Modes.      (line  158)
+* target attributes:                     Target Attributes.  (line    6)
+* target description macros:             Target Macros.      (line    6)
+* target functions:                      Target Structure.   (line    6)
+* target hooks:                          Target Structure.   (line    6)
+* target makefile fragment:              Target Fragment.    (line    6)
+* target specifications:                 Run-time Target.    (line    6)
+* targetm:                               Target Structure.   (line    6)
+* targets, makefile:                     Makefile.           (line    6)
+* TARGET_ADDRESS_COST:                   Costs.              (line  300)
+* TARGET_ADDR_SPACE_ADDRESS_MODE:        Named Address Spaces.
+                                                             (line   43)
+* TARGET_ADDR_SPACE_CONVERT:             Named Address Spaces.
+                                                             (line   85)
+* TARGET_ADDR_SPACE_LEGITIMATE_ADDRESS_P: Named Address Spaces.
+                                                             (line   61)
+* TARGET_ADDR_SPACE_LEGITIMIZE_ADDRESS:  Named Address Spaces.
+                                                             (line   69)
+* TARGET_ADDR_SPACE_POINTER_MODE:        Named Address Spaces.
+                                                             (line   36)
+* TARGET_ADDR_SPACE_SUBSET_P:            Named Address Spaces.
+                                                             (line   76)
+* TARGET_ADDR_SPACE_VALID_POINTER_MODE:  Named Address Spaces.
+                                                             (line   50)
+* TARGET_ALIGN_ANON_BITFIELD:            Storage Layout.     (line  397)
+* TARGET_ALLOCATE_INITIAL_VALUE:         Misc.               (line  734)
+* TARGET_ALLOCATE_STACK_SLOTS_FOR_ARGS:  Misc.               (line 1013)
+* TARGET_ALWAYS_STRIP_DOTDOT:            Driver.             (line  246)
+* TARGET_ARG_PARTIAL_BYTES:              Register Arguments. (line   81)
+* TARGET_ARM_EABI_UNWINDER:              Exception Region Output.
+                                                             (line  127)
+* TARGET_ARRAY_MODE_SUPPORTED_P:         Register Arguments. (line  333)
+* TARGET_ASAN_SHADOW_OFFSET:             Misc.               (line 1041)
+* TARGET_ASM_ALIGNED_DI_OP:              Data Output.        (line    9)
+* TARGET_ASM_ALIGNED_HI_OP:              Data Output.        (line    7)
+* TARGET_ASM_ALIGNED_SI_OP:              Data Output.        (line    8)
+* TARGET_ASM_ALIGNED_TI_OP:              Data Output.        (line   10)
+* TARGET_ASM_ASSEMBLE_VISIBILITY:        Label Output.       (line  266)
+* TARGET_ASM_BYTE_OP:                    Data Output.        (line    6)
+* TARGET_ASM_CAN_OUTPUT_MI_THUNK:        Function Entry.     (line  202)
+* TARGET_ASM_CLOSE_PAREN:                Data Output.        (line  129)
+* TARGET_ASM_CODE_END:                   File Framework.     (line   57)
+* TARGET_ASM_CONSTRUCTOR:                Macros for Initialization.
+                                                             (line   68)
+* TARGET_ASM_DECLARE_CONSTANT_NAME:      Label Output.       (line  149)
+* TARGET_ASM_DESTRUCTOR:                 Macros for Initialization.
+                                                             (line   82)
+* TARGET_ASM_EMIT_EXCEPT_PERSONALITY:    Dispatch Tables.    (line   80)
+* TARGET_ASM_EMIT_EXCEPT_TABLE_LABEL:    Dispatch Tables.    (line   73)
+* TARGET_ASM_EMIT_UNWIND_LABEL:          Dispatch Tables.    (line   61)
+* TARGET_ASM_EXTERNAL_LIBCALL:           Label Output.       (line  302)
+* TARGET_ASM_FILE_END:                   File Framework.     (line   35)
+* TARGET_ASM_FILE_START:                 File Framework.     (line    8)
+* TARGET_ASM_FILE_START_APP_OFF:         File Framework.     (line   16)
+* TARGET_ASM_FILE_START_FILE_DIRECTIVE:  File Framework.     (line   29)
+* TARGET_ASM_FINAL_POSTSCAN_INSN:        Instruction Output. (line   82)
+* TARGET_ASM_FUNCTION_BEGIN_EPILOGUE:    Function Entry.     (line   59)
+* TARGET_ASM_FUNCTION_END_PROLOGUE:      Function Entry.     (line   53)
+* TARGET_ASM_FUNCTION_EPILOGUE:          Function Entry.     (line   65)
+* TARGET_ASM_FUNCTION_PROLOGUE:          Function Entry.     (line    9)
+* TARGET_ASM_FUNCTION_RODATA_SECTION:    Sections.           (line  213)
+* TARGET_ASM_FUNCTION_SECTION:           File Framework.     (line  121)
+* TARGET_ASM_FUNCTION_SWITCHED_TEXT_SECTIONS: File Framework.
+                                                             (line  131)
+* TARGET_ASM_GLOBALIZE_DECL_NAME:        Label Output.       (line  194)
+* TARGET_ASM_GLOBALIZE_LABEL:            Label Output.       (line  185)
+* TARGET_ASM_INIT_SECTIONS:              Sections.           (line  159)
+* TARGET_ASM_INTEGER:                    Data Output.        (line   25)
+* TARGET_ASM_INTERNAL_LABEL:             Label Output.       (line  345)
+* TARGET_ASM_JUMP_ALIGN_MAX_SKIP:        Alignment Output.   (line   21)
+* TARGET_ASM_LABEL_ALIGN_AFTER_BARRIER_MAX_SKIP: Alignment Output.
+                                                             (line   34)
+* TARGET_ASM_LABEL_ALIGN_MAX_SKIP:       Alignment Output.   (line   68)
+* TARGET_ASM_LOOP_ALIGN_MAX_SKIP:        Alignment Output.   (line   53)
+* TARGET_ASM_LTO_END:                    File Framework.     (line   52)
+* TARGET_ASM_LTO_START:                  File Framework.     (line   47)
+* TARGET_ASM_MARK_DECL_PRESERVED:        Label Output.       (line  308)
+* TARGET_ASM_MERGEABLE_RODATA_PREFIX:    Sections.           (line  221)
+* TARGET_ASM_NAMED_SECTION:              File Framework.     (line  113)
+* TARGET_ASM_OPEN_PAREN:                 Data Output.        (line  128)
+* TARGET_ASM_OUTPUT_ADDR_CONST_EXTRA:    Data Output.        (line   38)
+* TARGET_ASM_OUTPUT_ANCHOR:              Anchored Addresses. (line   42)
+* TARGET_ASM_OUTPUT_DWARF_DTPREL:        SDB and DWARF.      (line   99)
+* TARGET_ASM_OUTPUT_IDENT:               File Framework.     (line  100)
+* TARGET_ASM_OUTPUT_MI_THUNK:            Function Entry.     (line  160)
+* TARGET_ASM_OUTPUT_SOURCE_FILENAME:     File Framework.     (line   91)
+* TARGET_ASM_RECORD_GCC_SWITCHES:        File Framework.     (line  162)
+* TARGET_ASM_RECORD_GCC_SWITCHES_SECTION: File Framework.    (line  207)
+* TARGET_ASM_RELOC_RW_MASK:              Sections.           (line  168)
+* TARGET_ASM_SELECT_RTX_SECTION:         Sections.           (line  230)
+* TARGET_ASM_SELECT_SECTION:             Sections.           (line  179)
+* TARGET_ASM_TM_CLONE_TABLE_SECTION:     Sections.           (line  226)
+* TARGET_ASM_TRAMPOLINE_TEMPLATE:        Trampolines.        (line   28)
+* TARGET_ASM_TTYPE:                      Exception Region Output.
+                                                             (line  121)
+* TARGET_ASM_UNALIGNED_DI_OP:            Data Output.        (line   13)
+* TARGET_ASM_UNALIGNED_HI_OP:            Data Output.        (line   11)
+* TARGET_ASM_UNALIGNED_SI_OP:            Data Output.        (line   12)
+* TARGET_ASM_UNALIGNED_TI_OP:            Data Output.        (line   14)
+* TARGET_ASM_UNIQUE_SECTION:             Sections.           (line  201)
+* TARGET_ASM_UNWIND_EMIT:                Dispatch Tables.    (line   87)
+* TARGET_ASM_UNWIND_EMIT_BEFORE_INSN:    Dispatch Tables.    (line   92)
+* TARGET_ATOMIC_ALIGN_FOR_MODE:          Misc.               (line 1060)
+* TARGET_ATOMIC_ASSIGN_EXPAND_FENV:      Misc.               (line 1066)
+* TARGET_ATOMIC_TEST_AND_SET_TRUEVAL:    Misc.               (line 1051)
+* TARGET_ATTRIBUTE_TABLE:                Target Attributes.  (line   10)
+* TARGET_ATTRIBUTE_TAKES_IDENTIFIER_P:   Target Attributes.  (line   17)
+* TARGET_BINDS_LOCAL_P:                  Sections.           (line  308)
+* TARGET_BRANCH_TARGET_REGISTER_CALLEE_SAVED: Misc.          (line  831)
+* TARGET_BRANCH_TARGET_REGISTER_CLASS:   Misc.               (line  824)
+* TARGET_BUILD_BUILTIN_VA_LIST:          Register Arguments. (line  271)
+* TARGET_BUILTIN_DECL:                   Misc.               (line  603)
+* TARGET_BUILTIN_RECIPROCAL:             Addressing Modes.   (line  261)
+* TARGET_BUILTIN_SETJMP_FRAME_VALUE:     Frame Layout.       (line  107)
+* TARGET_CALLEE_COPIES:                  Register Arguments. (line  113)
+* TARGET_CANNOT_FORCE_CONST_MEM:         Addressing Modes.   (line  234)
+* TARGET_CANNOT_MODIFY_JUMPS_P:          Misc.               (line  811)
+* TARGET_CANONICALIZE_COMPARISON:        MODE_CC Condition Codes.
+                                                             (line   54)
+* TARGET_CANONICAL_VA_LIST_TYPE:         Register Arguments. (line  292)
+* TARGET_CAN_ELIMINATE:                  Elimination.        (line   73)
+* TARGET_CAN_FOLLOW_JUMP:                Misc.               (line  720)
+* TARGET_CAN_INLINE_P:                   Target Attributes.  (line  159)
+* TARGET_CAN_USE_DOLOOP_P:               Misc.               (line  675)
+* TARGET_CASE_VALUES_THRESHOLD:          Misc.               (line   46)
+* TARGET_CC_MODES_COMPATIBLE:            MODE_CC Condition Codes.
+                                                             (line  118)
+* TARGET_CHECK_PCH_TARGET_FLAGS:         PCH Target.         (line   26)
+* TARGET_CHECK_STRING_OBJECT_FORMAT_ARG: Run-time Target.    (line  119)
+* TARGET_CLASS_LIKELY_SPILLED_P:         Register Classes.   (line  489)
+* TARGET_CLASS_MAX_NREGS:                Register Classes.   (line  505)
+* TARGET_COMMUTATIVE_P:                  Misc.               (line  727)
+* TARGET_COMPARE_VERSION_PRIORITY:       Misc.               (line  652)
+* TARGET_COMP_TYPE_ATTRIBUTES:           Target Attributes.  (line   25)
+* TARGET_CONDITIONAL_REGISTER_USAGE:     Register Basics.    (line   59)
+* TARGET_CONST_ANCHOR:                   Misc.               (line 1024)
+* TARGET_CONST_NOT_OK_FOR_DEBUG_P:       Addressing Modes.   (line  230)
+* TARGET_CONVERT_TO_TYPE:                Misc.               (line  978)
+* TARGET_CPU_CPP_BUILTINS:               Run-time Target.    (line    8)
+* TARGET_CSTORE_MODE:                    Register Classes.   (line  588)
+* TARGET_CXX_ADJUST_CLASS_AT_DEFINITION: C++ ABI.            (line   86)
+* TARGET_CXX_CDTOR_RETURNS_THIS:         C++ ABI.            (line   37)
+* TARGET_CXX_CLASS_DATA_ALWAYS_COMDAT:   C++ ABI.            (line   61)
+* TARGET_CXX_COOKIE_HAS_SIZE:            C++ ABI.            (line   24)
+* TARGET_CXX_DECL_MANGLING_CONTEXT:      C++ ABI.            (line   92)
+* TARGET_CXX_DETERMINE_CLASS_DATA_VISIBILITY: C++ ABI.       (line   52)
+* TARGET_CXX_GET_COOKIE_SIZE:            C++ ABI.            (line   17)
+* TARGET_CXX_GUARD_MASK_BIT:             C++ ABI.            (line   11)
+* TARGET_CXX_GUARD_TYPE:                 C++ ABI.            (line    6)
+* TARGET_CXX_IMPLICIT_EXTERN_C:          Misc.               (line  373)
+* TARGET_CXX_IMPORT_EXPORT_CLASS:        C++ ABI.            (line   28)
+* TARGET_CXX_KEY_METHOD_MAY_BE_INLINE:   C++ ABI.            (line   42)
+* TARGET_CXX_LIBRARY_RTTI_COMDAT:        C++ ABI.            (line   68)
+* TARGET_CXX_USE_AEABI_ATEXIT:           C++ ABI.            (line   73)
+* TARGET_CXX_USE_ATEXIT_FOR_CXA_ATEXIT:  C++ ABI.            (line   79)
+* TARGET_C_PREINCLUDE:                   Misc.               (line  361)
+* TARGET_DEBUG_UNWIND_INFO:              SDB and DWARF.      (line   36)
+* TARGET_DECIMAL_FLOAT_SUPPORTED_P:      Storage Layout.     (line  521)
+* TARGET_DECLSPEC:                       Target Attributes.  (line   72)
+* TARGET_DEFAULT_PACK_STRUCT:            Misc.               (line  446)
+* TARGET_DEFAULT_SHORT_ENUMS:            Type Layout.        (line  166)
+* TARGET_DEFAULT_TARGET_FLAGS:           Run-time Target.    (line   55)
+* TARGET_DEFERRED_OUTPUT_DEFS:           Label Output.       (line  430)
+* TARGET_DELAY_SCHED2:                   SDB and DWARF.      (line   65)
+* TARGET_DELAY_VARTRACK:                 SDB and DWARF.      (line   69)
+* TARGET_DELEGITIMIZE_ADDRESS:           Addressing Modes.   (line  221)
+* TARGET_DIFFERENT_ADDR_DISPLACEMENT_P:  Register Classes.   (line  574)
+* TARGET_DLLIMPORT_DECL_ATTRIBUTES:      Target Attributes.  (line   55)
+* TARGET_DWARF_CALLING_CONVENTION:       SDB and DWARF.      (line   16)
+* TARGET_DWARF_HANDLE_FRAME_UNSPEC:      Frame Layout.       (line  169)
+* TARGET_DWARF_REGISTER_SPAN:            Exception Region Output.
+                                                             (line  104)
+* TARGET_EDOM:                           Library Calls.      (line   59)
+* TARGET_EMUTLS_DEBUG_FORM_TLS_ADDRESS:  Emulated TLS.       (line   67)
+* TARGET_EMUTLS_GET_ADDRESS:             Emulated TLS.       (line   18)
+* TARGET_EMUTLS_REGISTER_COMMON:         Emulated TLS.       (line   23)
+* TARGET_EMUTLS_TMPL_PREFIX:             Emulated TLS.       (line   44)
+* TARGET_EMUTLS_TMPL_SECTION:            Emulated TLS.       (line   35)
+* TARGET_EMUTLS_VAR_ALIGN_FIXED:         Emulated TLS.       (line   62)
+* TARGET_EMUTLS_VAR_FIELDS:              Emulated TLS.       (line   48)
+* TARGET_EMUTLS_VAR_INIT:                Emulated TLS.       (line   55)
+* TARGET_EMUTLS_VAR_PREFIX:              Emulated TLS.       (line   40)
+* TARGET_EMUTLS_VAR_SECTION:             Emulated TLS.       (line   30)
+* TARGET_ENCODE_SECTION_INFO:            Sections.           (line  251)
+* 'TARGET_ENCODE_SECTION_INFO' and address validation: Addressing Modes.
+                                                             (line   82)
+* 'TARGET_ENCODE_SECTION_INFO' usage:    Instruction Output. (line  127)
+* TARGET_ENUM_VA_LIST_P:                 Register Arguments. (line  275)
+* TARGET_EXCEPT_UNWIND_INFO:             Exception Region Output.
+                                                             (line   45)
+* TARGET_EXECUTABLE_SUFFIX:              Misc.               (line  785)
+* TARGET_EXPAND_BUILTIN:                 Misc.               (line  613)
+* TARGET_EXPAND_BUILTIN_SAVEREGS:        Varargs.            (line   64)
+* TARGET_EXPAND_TO_RTL_HOOK:             Storage Layout.     (line  527)
+* TARGET_EXPR:                           Unary and Binary Expressions.
+                                                             (line    6)
+* TARGET_EXTRA_INCLUDES:                 Misc.               (line  870)
+* TARGET_EXTRA_LIVE_ON_ENTRY:            Tail Calls.         (line   20)
+* TARGET_EXTRA_PRE_INCLUDES:             Misc.               (line  877)
+* TARGET_FIXED_CONDITION_CODE_REGS:      MODE_CC Condition Codes.
+                                                             (line  103)
+* TARGET_FIXED_POINT_SUPPORTED_P:        Storage Layout.     (line  524)
+* target_flags:                          Run-time Target.    (line   51)
+* TARGET_FLAGS_REGNUM:                   Register Arguments. (line  391)
+* TARGET_FLOAT_EXCEPTIONS_ROUNDING_SUPPORTED_P: Run-time Target.
+                                                             (line  183)
+* TARGET_FLT_EVAL_METHOD:                Type Layout.        (line  147)
+* TARGET_FN_ABI_VA_LIST:                 Register Arguments. (line  287)
+* TARGET_FOLD_BUILTIN:                   Misc.               (line  635)
+* TARGET_FORCE_AT_COMP_DIR:              SDB and DWARF.      (line   60)
+* TARGET_FORMAT_TYPES:                   Misc.               (line  898)
+* TARGET_FRAME_POINTER_REQUIRED:         Elimination.        (line    8)
+* TARGET_FUNCTION_ARG:                   Register Arguments. (line   10)
+* TARGET_FUNCTION_ARG_ADVANCE:           Register Arguments. (line  184)
+* TARGET_FUNCTION_ARG_BOUNDARY:          Register Arguments. (line  238)
+* TARGET_FUNCTION_ARG_ROUND_BOUNDARY:    Register Arguments. (line  244)
+* TARGET_FUNCTION_ATTRIBUTE_INLINABLE_P: Target Attributes.  (line   93)
+* TARGET_FUNCTION_INCOMING_ARG:          Register Arguments. (line   65)
+* TARGET_FUNCTION_OK_FOR_SIBCALL:        Tail Calls.         (line    6)
+* TARGET_FUNCTION_VALUE:                 Scalar Return.      (line    9)
+* TARGET_FUNCTION_VALUE_REGNO_P:         Scalar Return.      (line   96)
+* TARGET_GENERATE_VERSION_DISPATCHER_BODY: Misc.             (line  668)
+* TARGET_GET_DRAP_RTX:                   Misc.               (line 1007)
+* TARGET_GET_FUNCTION_VERSIONS_DISPATCHER: Misc.             (line  661)
+* TARGET_GET_PCH_VALIDITY:               PCH Target.         (line    6)
+* TARGET_GET_RAW_ARG_MODE:               Aggregate Return.   (line   82)
+* TARGET_GET_RAW_RESULT_MODE:            Aggregate Return.   (line   76)
+* TARGET_GIMPLE_FOLD_BUILTIN:            Misc.               (line  645)
+* TARGET_GIMPLIFY_VA_ARG_EXPR:           Register Arguments. (line  297)
+* TARGET_HANDLE_C_OPTION:                Run-time Target.    (line   73)
+* TARGET_HANDLE_OPTION:                  Run-time Target.    (line   59)
+* TARGET_HARD_REGNO_SCRATCH_OK:          Values in Registers.
+                                                             (line  141)
+* TARGET_HAS_IFUNC_P:                    Misc.               (line 1055)
+* TARGET_HAS_NO_HW_DIVIDE:               Library Calls.      (line   52)
+* TARGET_HAVE_CONDITIONAL_EXECUTION:     Misc.               (line  845)
+* TARGET_HAVE_CTORS_DTORS:               Macros for Initialization.
+                                                             (line   63)
+* TARGET_HAVE_NAMED_SECTIONS:            File Framework.     (line  139)
+* TARGET_HAVE_SRODATA_SECTION:           Sections.           (line  297)
+* TARGET_HAVE_SWITCHABLE_BSS_SECTIONS:   File Framework.     (line  144)
+* TARGET_HAVE_TLS:                       Sections.           (line  317)
+* TARGET_INIT_BUILTINS:                  Misc.               (line  587)
+* TARGET_INIT_DWARF_REG_SIZES_EXTRA:     Exception Region Output.
+                                                             (line  113)
+* TARGET_INIT_LIBFUNCS:                  Library Calls.      (line   15)
+* TARGET_INSERT_ATTRIBUTES:              Target Attributes.  (line   80)
+* TARGET_INSTANTIATE_DECLS:              Storage Layout.     (line  535)
+* TARGET_INVALID_ARG_FOR_UNPROTOTYPED_FN: Misc.              (line  931)
+* TARGET_INVALID_BINARY_OP:              Misc.               (line  950)
+* TARGET_INVALID_CONVERSION:             Misc.               (line  937)
+* TARGET_INVALID_PARAMETER_TYPE:         Misc.               (line  956)
+* TARGET_INVALID_RETURN_TYPE:            Misc.               (line  963)
+* TARGET_INVALID_UNARY_OP:               Misc.               (line  943)
+* TARGET_INVALID_WITHIN_DOLOOP:          Misc.               (line  692)
+* TARGET_IN_SMALL_DATA_P:                Sections.           (line  293)
+* TARGET_LEGITIMATE_ADDRESS_P:           Addressing Modes.   (line   48)
+* TARGET_LEGITIMATE_COMBINED_INSN:       Misc.               (line  706)
+* TARGET_LEGITIMATE_CONSTANT_P:          Addressing Modes.   (line  213)
+* TARGET_LEGITIMIZE_ADDRESS:             Addressing Modes.   (line  129)
+* TARGET_LIBCALL_VALUE:                  Scalar Return.      (line   65)
+* TARGET_LIBC_HAS_FUNCTION:              Library Calls.      (line   77)
+* TARGET_LIBFUNC_GNU_PREFIX:             Library Calls.      (line   24)
+* TARGET_LIBGCC_CMP_RETURN_MODE:         Storage Layout.     (line  458)
+* TARGET_LIBGCC_SDATA_SECTION:           Sections.           (line  131)
+* TARGET_LIBGCC_SHIFT_COUNT_MODE:        Storage Layout.     (line  464)
+* TARGET_LIB_INT_CMP_BIASED:             Library Calls.      (line   42)
+* TARGET_LOOP_UNROLL_ADJUST:             Misc.               (line  851)
+* TARGET_LRA_P:                          Register Classes.   (line  548)
+* TARGET_MACHINE_DEPENDENT_REORG:        Misc.               (line  572)
+* TARGET_MANGLE_ASSEMBLER_NAME:          Label Output.       (line  321)
+* TARGET_MANGLE_DECL_ASSEMBLER_NAME:     Sections.           (line  241)
+* TARGET_MANGLE_TYPE:                    Storage Layout.     (line  539)
+* TARGET_MAX_ANCHOR_OFFSET:              Anchored Addresses. (line   38)
+* TARGET_MD_ASM_CLOBBERS:                Misc.               (line  491)
+* TARGET_MEMBER_TYPE_FORCES_BLK:         Storage Layout.     (line  410)
+* TARGET_MEMMODEL_CHECK:                 Misc.               (line 1046)
+* TARGET_MEMORY_MOVE_COST:               Costs.              (line   79)
+* TARGET_MEM_CONSTRAINT:                 Addressing Modes.   (line  107)
+* TARGET_MEM_REF:                        Storage References. (line    6)
+* TARGET_MERGE_DECL_ATTRIBUTES:          Target Attributes.  (line   45)
+* TARGET_MERGE_TYPE_ATTRIBUTES:          Target Attributes.  (line   37)
+* TARGET_MIN_ANCHOR_OFFSET:              Anchored Addresses. (line   32)
+* TARGET_MIN_DIVISIONS_FOR_RECIP_MUL:    Misc.               (line   90)
+* TARGET_MODE_DEPENDENT_ADDRESS_P:       Addressing Modes.   (line  196)
+* TARGET_MODE_REP_EXTENDED:              Misc.               (line  175)
+* TARGET_MS_BITFIELD_LAYOUT_P:           Storage Layout.     (line  493)
+* TARGET_MUST_PASS_IN_STACK:             Register Arguments. (line   58)
+* 'TARGET_MUST_PASS_IN_STACK', and 'TARGET_FUNCTION_ARG': Register Arguments.
+                                                             (line   50)
+* TARGET_NARROW_VOLATILE_BITFIELD:       Storage Layout.     (line  403)
+* TARGET_N_FORMAT_TYPES:                 Misc.               (line  903)
+* TARGET_OBJC_CONSTRUCT_STRING_OBJECT:   Run-time Target.    (line   88)
+* TARGET_OBJC_DECLARE_CLASS_DEFINITION:  Run-time Target.    (line  109)
+* TARGET_OBJC_DECLARE_UNRESOLVED_CLASS_REFERENCE: Run-time Target.
+                                                             (line  104)
+* TARGET_OBJECT_SUFFIX:                  Misc.               (line  780)
+* TARGET_OBJFMT_CPP_BUILTINS:            Run-time Target.    (line   45)
+* TARGET_OPTF:                           Misc.               (line  885)
+* TARGET_OPTION_DEFAULT_PARAMS:          Run-time Target.    (line  160)
+* TARGET_OPTION_FUNCTION_VERSIONS:       Target Attributes.  (line  151)
+* TARGET_OPTION_INIT_STRUCT:             Run-time Target.    (line  156)
+* TARGET_OPTION_OPTIMIZATION_TABLE:      Run-time Target.    (line  142)
+* TARGET_OPTION_OVERRIDE:                Target Attributes.  (line  138)
+* TARGET_OPTION_PRAGMA_PARSE:            Target Attributes.  (line  131)
+* TARGET_OPTION_PRINT:                   Target Attributes.  (line  125)
+* TARGET_OPTION_RESTORE:                 Target Attributes.  (line  119)
+* TARGET_OPTION_SAVE:                    Target Attributes.  (line  112)
+* TARGET_OPTION_VALID_ATTRIBUTE_P:       Target Attributes.  (line  100)
+* TARGET_OS_CPP_BUILTINS:                Run-time Target.    (line   41)
+* TARGET_OVERRIDES_FORMAT_ATTRIBUTES:    Misc.               (line  907)
+* TARGET_OVERRIDES_FORMAT_ATTRIBUTES_COUNT: Misc.            (line  913)
+* TARGET_OVERRIDES_FORMAT_INIT:          Misc.               (line  917)
+* TARGET_OVERRIDE_OPTIONS_AFTER_CHANGE:  Run-time Target.    (line  126)
+* TARGET_PASS_BY_REFERENCE:              Register Arguments. (line  101)
+* TARGET_PCH_VALID_P:                    PCH Target.         (line   11)
+* TARGET_POSIX_IO:                       Misc.               (line  516)
+* TARGET_PREFERRED_OUTPUT_RELOAD_CLASS:  Register Classes.   (line  284)
+* TARGET_PREFERRED_RELOAD_CLASS:         Register Classes.   (line  213)
+* TARGET_PREFERRED_RENAME_CLASS:         Register Classes.   (line  201)
+* TARGET_PREPARE_PCH_SAVE:               PCH Target.         (line   34)
+* TARGET_PRETEND_OUTGOING_VARARGS_NAMED: Varargs.            (line  123)
+* TARGET_PROFILE_BEFORE_PROLOGUE:        Sections.           (line  301)
+* TARGET_PROMOTED_TYPE:                  Misc.               (line  970)
+* TARGET_PROMOTE_FUNCTION_MODE:          Storage Layout.     (line  109)
+* TARGET_PROMOTE_PROTOTYPES:             Stack Arguments.    (line   10)
+* TARGET_PTRMEMFUNC_VBIT_LOCATION:       Type Layout.        (line  293)
+* TARGET_REF_MAY_ALIAS_ERRNO:            Register Arguments. (line  308)
+* TARGET_REGISTER_MOVE_COST:             Costs.              (line   31)
+* TARGET_REGISTER_PRIORITY:              Register Classes.   (line  553)
+* TARGET_REGISTER_USAGE_LEVELING_P:      Register Classes.   (line  564)
+* TARGET_RELAXED_ORDERING:               Misc.               (line  922)
+* TARGET_RESOLVE_OVERLOADED_BUILTIN:     Misc.               (line  624)
+* TARGET_RETURN_IN_MEMORY:               Aggregate Return.   (line   15)
+* TARGET_RETURN_IN_MSB:                  Scalar Return.      (line  117)
+* TARGET_RETURN_POPS_ARGS:               Stack Arguments.    (line   92)
+* TARGET_RTX_COSTS:                      Costs.              (line  269)
+* TARGET_SCALAR_MODE_SUPPORTED_P:        Register Arguments. (line  315)
+* TARGET_SCHED_ADJUST_COST:              Scheduling.         (line   35)
+* TARGET_SCHED_ADJUST_PRIORITY:          Scheduling.         (line   50)
+* TARGET_SCHED_ALLOC_SCHED_CONTEXT:      Scheduling.         (line  283)
+* TARGET_SCHED_CLEAR_SCHED_CONTEXT:      Scheduling.         (line  298)
+* TARGET_SCHED_DEPENDENCIES_EVALUATION_HOOK: Scheduling.     (line   98)
+* TARGET_SCHED_DFA_NEW_CYCLE:            Scheduling.         (line  245)
+* TARGET_SCHED_DFA_POST_ADVANCE_CYCLE:   Scheduling.         (line  169)
+* TARGET_SCHED_DFA_POST_CYCLE_INSN:      Scheduling.         (line  153)
+* TARGET_SCHED_DFA_PRE_ADVANCE_CYCLE:    Scheduling.         (line  162)
+* TARGET_SCHED_DFA_PRE_CYCLE_INSN:       Scheduling.         (line  141)
+* TARGET_SCHED_DISPATCH:                 Scheduling.         (line  365)
+* TARGET_SCHED_DISPATCH_DO:              Scheduling.         (line  370)
+* TARGET_SCHED_EXPOSED_PIPELINE:         Scheduling.         (line  374)
+* TARGET_SCHED_FINISH:                   Scheduling.         (line  119)
+* TARGET_SCHED_FINISH_GLOBAL:            Scheduling.         (line  134)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BACKTRACK: Scheduling.  (line  225)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_BEGIN: Scheduling.      (line  214)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD: Scheduling.
+                                                             (line  176)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD: Scheduling.
+                                                             (line  204)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_DFA_LOOKAHEAD_GUARD_SPEC: Scheduling.
+                                                             (line  336)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_END: Scheduling.        (line  230)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_FINI: Scheduling.       (line  240)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_INIT: Scheduling.       (line  235)
+* TARGET_SCHED_FIRST_CYCLE_MULTIPASS_ISSUE: Scheduling.      (line  219)
+* TARGET_SCHED_FREE_SCHED_CONTEXT:       Scheduling.         (line  302)
+* TARGET_SCHED_GEN_SPEC_CHECK:           Scheduling.         (line  324)
+* TARGET_SCHED_H_I_D_EXTENDED:           Scheduling.         (line  278)
+* TARGET_SCHED_INIT:                     Scheduling.         (line  108)
+* TARGET_SCHED_INIT_DFA_POST_CYCLE_INSN: Scheduling.         (line  158)
+* TARGET_SCHED_INIT_DFA_PRE_CYCLE_INSN:  Scheduling.         (line  150)
+* TARGET_SCHED_INIT_GLOBAL:              Scheduling.         (line  126)
+* TARGET_SCHED_INIT_SCHED_CONTEXT:       Scheduling.         (line  287)
+* TARGET_SCHED_ISSUE_RATE:               Scheduling.         (line   11)
+* TARGET_SCHED_IS_COSTLY_DEPENDENCE:     Scheduling.         (line  256)
+* TARGET_SCHED_MACRO_FUSION_P:           Scheduling.         (line   87)
+* TARGET_SCHED_MACRO_FUSION_PAIR_P:      Scheduling.         (line   91)
+* TARGET_SCHED_NEEDS_BLOCK_P:            Scheduling.         (line  317)
+* TARGET_SCHED_REASSOCIATION_WIDTH:      Scheduling.         (line  379)
+* TARGET_SCHED_REORDER:                  Scheduling.         (line   58)
+* TARGET_SCHED_REORDER2:                 Scheduling.         (line   75)
+* TARGET_SCHED_SET_SCHED_CONTEXT:        Scheduling.         (line  294)
+* TARGET_SCHED_SET_SCHED_FLAGS:          Scheduling.         (line  349)
+* TARGET_SCHED_SMS_RES_MII:              Scheduling.         (line  356)
+* TARGET_SCHED_SPECULATE_INSN:           Scheduling.         (line  305)
+* TARGET_SCHED_VARIABLE_ISSUE:           Scheduling.         (line   22)
+* TARGET_SECONDARY_RELOAD:               Register Classes.   (line  312)
+* TARGET_SECTION_TYPE_FLAGS:             File Framework.     (line  149)
+* TARGET_SETUP_INCOMING_VARARGS:         Varargs.            (line   71)
+* TARGET_SET_CURRENT_FUNCTION:           Misc.               (line  762)
+* TARGET_SET_DEFAULT_TYPE_ATTRIBUTES:    Target Attributes.  (line   33)
+* TARGET_SET_UP_BY_PROLOGUE:             Tail Calls.         (line   29)
+* TARGET_SHIFT_TRUNCATION_MASK:          Misc.               (line  138)
+* TARGET_SIMD_CLONE_ADJUST:              Addressing Modes.   (line  413)
+* TARGET_SIMD_CLONE_COMPUTE_VECSIZE_AND_SIMDLEN: Addressing Modes.
+                                                             (line  405)
+* TARGET_SIMD_CLONE_USABLE:              Addressing Modes.   (line  417)
+* TARGET_SMALL_REGISTER_CLASSES_FOR_MODE_P: Register Arguments.
+                                                             (line  357)
+* TARGET_SPILL_CLASS:                    Register Classes.   (line  581)
+* TARGET_SPLIT_COMPLEX_ARG:              Register Arguments. (line  259)
+* TARGET_STACK_PROTECT_FAIL:             Stack Smashing Protection.
+                                                             (line   16)
+* TARGET_STACK_PROTECT_GUARD:            Stack Smashing Protection.
+                                                             (line    6)
+* TARGET_STATIC_CHAIN:                   Frame Registers.    (line   90)
+* TARGET_STRICT_ARGUMENT_NAMING:         Varargs.            (line  107)
+* TARGET_STRING_OBJECT_REF_TYPE_P:       Run-time Target.    (line  114)
+* TARGET_STRIP_NAME_ENCODING:            Sections.           (line  288)
+* TARGET_STRUCT_VALUE_RTX:               Aggregate Return.   (line   44)
+* TARGET_SUPPORTS_SPLIT_STACK:           Stack Smashing Protection.
+                                                             (line   25)
+* TARGET_SUPPORTS_WEAK:                  Label Output.       (line  237)
+* TARGET_TERMINATE_DW2_EH_FRAME_INFO:    Exception Region Output.
+                                                             (line   98)
+* TARGET_TRAMPOLINE_ADJUST_ADDRESS:      Trampolines.        (line   74)
+* TARGET_TRAMPOLINE_INIT:                Trampolines.        (line   54)
+* TARGET_UNSPEC_MAY_TRAP_P:              Misc.               (line  753)
+* TARGET_UNWIND_TABLES_DEFAULT:          Exception Region Output.
+                                                             (line   72)
+* TARGET_UNWIND_WORD_MODE:               Storage Layout.     (line  470)
+* TARGET_UPDATE_STACK_BOUNDARY:          Misc.               (line 1003)
+* TARGET_USES_WEAK_UNWIND_INFO:          Exception Handling. (line  123)
+* TARGET_USE_ANCHORS_FOR_SYMBOL_P:       Anchored Addresses. (line   53)
+* TARGET_USE_BLOCKS_FOR_CONSTANT_P:      Addressing Modes.   (line  248)
+* TARGET_USE_BLOCKS_FOR_DECL_P:          Addressing Modes.   (line  255)
+* TARGET_USE_JCR_SECTION:                Misc.               (line  985)
+* TARGET_VALID_DLLIMPORT_ATTRIBUTE_P:    Target Attributes.  (line   66)
+* TARGET_VALID_POINTER_MODE:             Register Arguments. (line  303)
+* TARGET_VECTORIZE_ADD_STMT_COST:        Addressing Modes.   (line  367)
+* TARGET_VECTORIZE_AUTOVECTORIZE_VECTOR_SIZES: Addressing Modes.
+                                                             (line  350)
+* TARGET_VECTORIZE_BUILTIN_CONVERSION:   Addressing Modes.   (line  312)
+* TARGET_VECTORIZE_BUILTIN_GATHER:       Addressing Modes.   (line  398)
+* TARGET_VECTORIZE_BUILTIN_MASK_FOR_LOAD: Addressing Modes.  (line  271)
+* TARGET_VECTORIZE_BUILTIN_TM_LOAD:      Addressing Modes.   (line  390)
+* TARGET_VECTORIZE_BUILTIN_TM_STORE:     Addressing Modes.   (line  394)
+* TARGET_VECTORIZE_BUILTIN_VECTORIZATION_COST: Addressing Modes.
+                                                             (line  297)
+* TARGET_VECTORIZE_BUILTIN_VECTORIZED_FUNCTION: Addressing Modes.
+                                                             (line  324)
+* TARGET_VECTORIZE_DESTROY_COST_DATA:    Addressing Modes.   (line  385)
+* TARGET_VECTORIZE_FINISH_COST:          Addressing Modes.   (line  378)
+* TARGET_VECTORIZE_INIT_COST:            Addressing Modes.   (line  358)
+* TARGET_VECTORIZE_PREFERRED_SIMD_MODE:  Addressing Modes.   (line  343)
+* TARGET_VECTORIZE_SUPPORT_VECTOR_MISALIGNMENT: Addressing Modes.
+                                                             (line  333)
+* TARGET_VECTORIZE_VECTOR_ALIGNMENT_REACHABLE: Addressing Modes.
+                                                             (line  303)
+* TARGET_VECTORIZE_VEC_PERM_CONST_OK:    Addressing Modes.   (line  308)
+* TARGET_VECTOR_ALIGNMENT:               Storage Layout.     (line  263)
+* TARGET_VECTOR_MODE_SUPPORTED_P:        Register Arguments. (line  327)
+* TARGET_VTABLE_DATA_ENTRY_DISTANCE:     Type Layout.        (line  346)
+* TARGET_VTABLE_ENTRY_ALIGN:             Type Layout.        (line  340)
+* TARGET_VTABLE_USES_DESCRIPTORS:        Type Layout.        (line  329)
+* TARGET_WANT_DEBUG_PUB_SECTIONS:        SDB and DWARF.      (line   55)
+* TARGET_WARN_FUNC_RETURN:               Tail Calls.         (line   35)
+* TARGET_WEAK_NOT_IN_ARCHIVE_TOC:        Label Output.       (line  273)
+* TCmode:                                Machine Modes.      (line  199)
+* TDmode:                                Machine Modes.      (line   97)
+* TEMPLATE_DECL:                         Declarations.       (line    6)
+* Temporaries:                           Temporaries.        (line    6)
+* termination routines:                  Initialization.     (line    6)
+* testing constraints:                   C Constraint Interface.
+                                                             (line    6)
+* TEXT_SECTION_ASM_OP:                   Sections.           (line   37)
+* TFmode:                                Machine Modes.      (line  101)
+* TF_SIZE:                               Type Layout.        (line  138)
+* THEN_CLAUSE:                           Statements for C++. (line    6)
+* THREAD_MODEL_SPEC:                     Driver.             (line  162)
+* THROW_EXPR:                            Unary and Binary Expressions.
+                                                             (line    6)
+* THUNK_DECL:                            Declarations.       (line    6)
+* THUNK_DELTA:                           Declarations.       (line    6)
+* TImode:                                Machine Modes.      (line   48)
+* 'TImode', in 'insn':                   Insns.              (line  268)
+* TLS_COMMON_ASM_OP:                     Sections.           (line   80)
+* TLS_SECTION_ASM_FLAG:                  Sections.           (line   85)
+* 'tm.h' macros:                         Target Macros.      (line    6)
+* TQFmode:                               Machine Modes.      (line   65)
+* TQmode:                                Machine Modes.      (line  122)
+* trampolines for nested functions:      Trampolines.        (line    6)
+* TRAMPOLINE_ALIGNMENT:                  Trampolines.        (line   48)
+* TRAMPOLINE_SECTION:                    Trampolines.        (line   39)
+* TRAMPOLINE_SIZE:                       Trampolines.        (line   44)
+* TRANSFER_FROM_TRAMPOLINE:              Trampolines.        (line  110)
+* 'trap' instruction pattern:            Standard Names.     (line 1542)
+* tree:                                  Tree overview.      (line    6)
+* tree <1>:                              Macros and Functions.
+                                                             (line    6)
+* Tree SSA:                              Tree SSA.           (line    6)
+* TREE_CHAIN:                            Macros and Functions.
+                                                             (line    6)
+* TREE_CODE:                             Tree overview.      (line    6)
+* tree_int_cst_equal:                    Constant expressions.
+                                                             (line    6)
+* TREE_INT_CST_HIGH:                     Constant expressions.
+                                                             (line    6)
+* TREE_INT_CST_LOW:                      Constant expressions.
+                                                             (line    6)
+* tree_int_cst_lt:                       Constant expressions.
+                                                             (line    6)
+* TREE_LIST:                             Containers.         (line    6)
+* TREE_OPERAND:                          Expression trees.   (line    6)
+* TREE_PUBLIC:                           Function Basics.    (line    6)
+* TREE_PUBLIC <1>:                       Function Properties.
+                                                             (line   28)
+* TREE_PURPOSE:                          Containers.         (line    6)
+* TREE_READONLY:                         Function Properties.
+                                                             (line   37)
+* tree_size:                             Macros and Functions.
+                                                             (line   13)
+* TREE_STATIC:                           Function Properties.
+                                                             (line   31)
+* TREE_STRING_LENGTH:                    Constant expressions.
+                                                             (line    6)
+* TREE_STRING_POINTER:                   Constant expressions.
+                                                             (line    6)
+* TREE_THIS_VOLATILE:                    Function Properties.
+                                                             (line   34)
+* TREE_TYPE:                             Macros and Functions.
+                                                             (line    6)
+* TREE_TYPE <1>:                         Types.              (line    6)
+* TREE_TYPE <2>:                         Working with declarations.
+                                                             (line   11)
+* TREE_TYPE <3>:                         Expression trees.   (line    6)
+* TREE_TYPE <4>:                         Expression trees.   (line   17)
+* TREE_TYPE <5>:                         Function Basics.    (line   47)
+* TREE_TYPE <6>:                         Types for C++.      (line    6)
+* TREE_VALUE:                            Containers.         (line    6)
+* TREE_VEC:                              Containers.         (line    6)
+* TREE_VEC_ELT:                          Containers.         (line    6)
+* TREE_VEC_LENGTH:                       Containers.         (line    6)
+* TRULY_NOOP_TRUNCATION:                 Misc.               (line  162)
+* truncate:                              Conversions.        (line   38)
+* 'truncMN2' instruction pattern:        Standard Names.     (line  916)
+* TRUNC_DIV_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* TRUNC_MOD_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* TRUTH_ANDIF_EXPR:                      Unary and Binary Expressions.
+                                                             (line    6)
+* TRUTH_AND_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* TRUTH_NOT_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* TRUTH_ORIF_EXPR:                       Unary and Binary Expressions.
+                                                             (line    6)
+* TRUTH_OR_EXPR:                         Unary and Binary Expressions.
+                                                             (line    6)
+* TRUTH_XOR_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* TRY_BLOCK:                             Statements for C++. (line    6)
+* TRY_HANDLERS:                          Statements for C++. (line    6)
+* TRY_STMTS:                             Statements for C++. (line    6)
+* Tuple specific accessors:              Tuple specific accessors.
+                                                             (line    6)
+* tuples:                                Tuple representation.
+                                                             (line    6)
+* type:                                  Types.              (line    6)
+* type declaration:                      Declarations.       (line    6)
+* TYPENAME_TYPE:                         Types for C++.      (line    6)
+* TYPENAME_TYPE_FULLNAME:                Types.              (line    6)
+* TYPENAME_TYPE_FULLNAME <1>:            Types for C++.      (line    6)
+* TYPEOF_TYPE:                           Types for C++.      (line    6)
+* TYPE_ALIGN:                            Types.              (line    6)
+* TYPE_ALIGN <1>:                        Types.              (line   30)
+* TYPE_ALIGN <2>:                        Types for C++.      (line    6)
+* TYPE_ALIGN <3>:                        Types for C++.      (line   44)
+* TYPE_ARG_TYPES:                        Types.              (line    6)
+* TYPE_ARG_TYPES <1>:                    Types for C++.      (line    6)
+* TYPE_ASM_OP:                           Label Output.       (line   76)
+* TYPE_ATTRIBUTES:                       Attributes.         (line   24)
+* TYPE_BINFO:                            Classes.            (line    6)
+* TYPE_BUILT_IN:                         Types for C++.      (line   66)
+* TYPE_CANONICAL:                        Types.              (line    6)
+* TYPE_CANONICAL <1>:                    Types.              (line   41)
+* TYPE_CONTEXT:                          Types.              (line    6)
+* TYPE_CONTEXT <1>:                      Types for C++.      (line    6)
+* TYPE_DECL:                             Declarations.       (line    6)
+* TYPE_FIELDS:                           Types.              (line    6)
+* TYPE_FIELDS <1>:                       Types for C++.      (line    6)
+* TYPE_FIELDS <2>:                       Classes.            (line    6)
+* TYPE_HAS_ARRAY_NEW_OPERATOR:           Classes.            (line   96)
+* TYPE_HAS_DEFAULT_CONSTRUCTOR:          Classes.            (line   81)
+* TYPE_HAS_MUTABLE_P:                    Classes.            (line   86)
+* TYPE_HAS_NEW_OPERATOR:                 Classes.            (line   93)
+* TYPE_MAIN_VARIANT:                     Types.              (line    6)
+* TYPE_MAIN_VARIANT <1>:                 Types.              (line   19)
+* TYPE_MAIN_VARIANT <2>:                 Types for C++.      (line    6)
+* TYPE_MAX_VALUE:                        Types.              (line    6)
+* TYPE_METHODS:                          Classes.            (line    6)
+* TYPE_METHOD_BASETYPE:                  Types.              (line    6)
+* TYPE_METHOD_BASETYPE <1>:              Types for C++.      (line    6)
+* TYPE_MIN_VALUE:                        Types.              (line    6)
+* TYPE_NAME:                             Types.              (line    6)
+* TYPE_NAME <1>:                         Types.              (line   33)
+* TYPE_NAME <2>:                         Types for C++.      (line    6)
+* TYPE_NAME <3>:                         Types for C++.      (line   47)
+* TYPE_NOTHROW_P:                        Functions for C++.  (line  154)
+* TYPE_OFFSET_BASETYPE:                  Types.              (line    6)
+* TYPE_OFFSET_BASETYPE <1>:              Types for C++.      (line    6)
+* TYPE_OPERAND_FMT:                      Label Output.       (line   87)
+* TYPE_OVERLOADS_ARRAY_REF:              Classes.            (line  104)
+* TYPE_OVERLOADS_ARROW:                  Classes.            (line  107)
+* TYPE_OVERLOADS_CALL_EXPR:              Classes.            (line  100)
+* TYPE_POLYMORPHIC_P:                    Classes.            (line   77)
+* TYPE_PRECISION:                        Types.              (line    6)
+* TYPE_PRECISION <1>:                    Types for C++.      (line    6)
+* TYPE_PTRDATAMEM_P:                     Types for C++.      (line    6)
+* TYPE_PTRDATAMEM_P <1>:                 Types for C++.      (line   69)
+* TYPE_PTRFN_P:                          Types for C++.      (line   76)
+* TYPE_PTROBV_P:                         Types for C++.      (line    6)
+* TYPE_PTROB_P:                          Types for C++.      (line   79)
+* TYPE_PTR_P:                            Types for C++.      (line   72)
+* TYPE_QUAL_CONST:                       Types.              (line    6)
+* TYPE_QUAL_CONST <1>:                   Types for C++.      (line    6)
+* TYPE_QUAL_RESTRICT:                    Types.              (line    6)
+* TYPE_QUAL_RESTRICT <1>:                Types for C++.      (line    6)
+* TYPE_QUAL_VOLATILE:                    Types.              (line    6)
+* TYPE_QUAL_VOLATILE <1>:                Types for C++.      (line    6)
+* TYPE_RAISES_EXCEPTIONS:                Functions for C++.  (line  149)
+* TYPE_SIZE:                             Types.              (line    6)
+* TYPE_SIZE <1>:                         Types.              (line   25)
+* TYPE_SIZE <2>:                         Types for C++.      (line    6)
+* TYPE_SIZE <3>:                         Types for C++.      (line   39)
+* TYPE_STRUCTURAL_EQUALITY_P:            Types.              (line    6)
+* TYPE_STRUCTURAL_EQUALITY_P <1>:        Types.              (line   77)
+* TYPE_UNQUALIFIED:                      Types.              (line    6)
+* TYPE_UNQUALIFIED <1>:                  Types for C++.      (line    6)
+* TYPE_VFIELD:                           Classes.            (line    6)
+* UDAmode:                               Machine Modes.      (line  170)
+* udiv:                                  Arithmetic.         (line  131)
+* 'udivM3' instruction pattern:          Standard Names.     (line  276)
+* 'udivmodM4' instruction pattern:       Standard Names.     (line  513)
+* 'udot_prodM' instruction pattern:      Standard Names.     (line  342)
+* UDQmode:                               Machine Modes.      (line  138)
+* UHAmode:                               Machine Modes.      (line  162)
+* UHQmode:                               Machine Modes.      (line  130)
+* UINT16_TYPE:                           Type Layout.        (line  257)
+* UINT32_TYPE:                           Type Layout.        (line  258)
+* UINT64_TYPE:                           Type Layout.        (line  259)
+* UINT8_TYPE:                            Type Layout.        (line  256)
+* UINTMAX_TYPE:                          Type Layout.        (line  240)
+* UINTPTR_TYPE:                          Type Layout.        (line  277)
+* UINT_FAST16_TYPE:                      Type Layout.        (line  273)
+* UINT_FAST32_TYPE:                      Type Layout.        (line  274)
+* UINT_FAST64_TYPE:                      Type Layout.        (line  275)
+* UINT_FAST8_TYPE:                       Type Layout.        (line  272)
+* UINT_LEAST16_TYPE:                     Type Layout.        (line  265)
+* UINT_LEAST32_TYPE:                     Type Layout.        (line  266)
+* UINT_LEAST64_TYPE:                     Type Layout.        (line  267)
+* UINT_LEAST8_TYPE:                      Type Layout.        (line  264)
+* 'umaddMN4' instruction pattern:        Standard Names.     (line  460)
+* umax:                                  Arithmetic.         (line  150)
+* 'umaxM3' instruction pattern:          Standard Names.     (line  276)
+* umin:                                  Arithmetic.         (line  150)
+* 'uminM3' instruction pattern:          Standard Names.     (line  276)
+* umod:                                  Arithmetic.         (line  137)
+* 'umodM3' instruction pattern:          Standard Names.     (line  276)
+* 'umsubMN4' instruction pattern:        Standard Names.     (line  484)
+* 'umulhisi3' instruction pattern:       Standard Names.     (line  432)
+* 'umulM3_highpart' instruction pattern: Standard Names.     (line  446)
+* 'umulqihi3' instruction pattern:       Standard Names.     (line  432)
+* 'umulsidi3' instruction pattern:       Standard Names.     (line  432)
+* unchanging:                            Flags.              (line  296)
+* 'unchanging', in 'call_insn':          Flags.              (line   19)
+* 'unchanging', in 'jump_insn', 'call_insn' and 'insn': Flags.
+                                                             (line   39)
+* 'unchanging', in 'mem':                Flags.              (line  134)
+* 'unchanging', in 'subreg':             Flags.              (line  170)
+* 'unchanging', in 'subreg' <1>:         Flags.              (line  180)
+* 'unchanging', in 'symbol_ref':         Flags.              (line   10)
+* UNEQ_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* UNGE_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* UNGT_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* unions, returning:                     Interface.          (line   10)
+* UNION_TYPE:                            Types.              (line    6)
+* UNION_TYPE <1>:                        Classes.            (line    6)
+* UNITS_PER_WORD:                        Storage Layout.     (line   60)
+* UNKNOWN_TYPE:                          Types.              (line    6)
+* UNKNOWN_TYPE <1>:                      Types for C++.      (line    6)
+* UNLE_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* UNLIKELY_EXECUTED_TEXT_SECTION_NAME:   Sections.           (line   48)
+* UNLT_EXPR:                             Unary and Binary Expressions.
+                                                             (line    6)
+* UNORDERED_EXPR:                        Unary and Binary Expressions.
+                                                             (line    6)
+* unshare_all_rtl:                       Sharing.            (line   58)
+* unsigned division:                     Arithmetic.         (line  131)
+* unsigned division with unsigned saturation: Arithmetic.    (line  131)
+* unsigned greater than:                 Comparisons.        (line   64)
+* unsigned greater than <1>:             Comparisons.        (line   72)
+* unsigned less than:                    Comparisons.        (line   68)
+* unsigned less than <1>:                Comparisons.        (line   76)
+* unsigned minimum and maximum:          Arithmetic.         (line  150)
+* unsigned_fix:                          Conversions.        (line   77)
+* unsigned_float:                        Conversions.        (line   62)
+* unsigned_fract_convert:                Conversions.        (line   97)
+* unsigned_sat_fract:                    Conversions.        (line  103)
+* unspec:                                Side Effects.       (line  298)
+* unspec <1>:                            Constant Definitions.
+                                                             (line  111)
+* unspec_volatile:                       Side Effects.       (line  298)
+* unspec_volatile <1>:                   Constant Definitions.
+                                                             (line   99)
+* 'untyped_call' instruction pattern:    Standard Names.     (line 1158)
+* 'untyped_return' instruction pattern:  Standard Names.     (line 1221)
+* UPDATE_PATH_HOST_CANONICALIZE (PATH):  Filesystem.         (line   59)
+* update_ssa:                            SSA.                (line   74)
+* update_stmt:                           Manipulating GIMPLE statements.
+                                                             (line  140)
+* update_stmt <1>:                       SSA Operands.       (line    6)
+* update_stmt_if_modified:               Manipulating GIMPLE statements.
+                                                             (line  143)
+* UQQmode:                               Machine Modes.      (line  126)
+* 'usaddM3' instruction pattern:         Standard Names.     (line  276)
+* USAmode:                               Machine Modes.      (line  166)
+* 'usashlM3' instruction pattern:        Standard Names.     (line  516)
+* 'usdivM3' instruction pattern:         Standard Names.     (line  276)
+* use:                                   Side Effects.       (line  168)
+* used:                                  Flags.              (line  314)
+* 'used', in 'symbol_ref':               Flags.              (line  197)
+* user:                                  GTY Options.        (line  318)
+* user gc:                               User GC.            (line    6)
+* USER_LABEL_PREFIX:                     Instruction Output. (line  152)
+* USE_C_ALLOCA:                          Host Misc.          (line   19)
+* USE_LD_AS_NEEDED:                      Driver.             (line  135)
+* USE_LOAD_POST_DECREMENT:               Costs.              (line  225)
+* USE_LOAD_POST_INCREMENT:               Costs.              (line  220)
+* USE_LOAD_PRE_DECREMENT:                Costs.              (line  235)
+* USE_LOAD_PRE_INCREMENT:                Costs.              (line  230)
+* use_param:                             GTY Options.        (line  119)
+* use_paramN:                            GTY Options.        (line  138)
+* use_params:                            GTY Options.        (line  147)
+* USE_SELECT_SECTION_FOR_FUNCTIONS:      Sections.           (line  193)
+* USE_STORE_POST_DECREMENT:              Costs.              (line  245)
+* USE_STORE_POST_INCREMENT:              Costs.              (line  240)
+* USE_STORE_PRE_DECREMENT:               Costs.              (line  255)
+* USE_STORE_PRE_INCREMENT:               Costs.              (line  250)
+* USING_STMT:                            Statements for C++. (line    6)
+* 'usmaddMN4' instruction pattern:       Standard Names.     (line  468)
+* 'usmsubMN4' instruction pattern:       Standard Names.     (line  492)
+* 'usmulhisi3' instruction pattern:      Standard Names.     (line  436)
+* 'usmulM3' instruction pattern:         Standard Names.     (line  276)
+* 'usmulqihi3' instruction pattern:      Standard Names.     (line  436)
+* 'usmulsidi3' instruction pattern:      Standard Names.     (line  436)
+* 'usnegM2' instruction pattern:         Standard Names.     (line  538)
+* USQmode:                               Machine Modes.      (line  134)
+* 'ussubM3' instruction pattern:         Standard Names.     (line  276)
+* 'usum_widenM3' instruction pattern:    Standard Names.     (line  351)
+* us_ashift:                             Arithmetic.         (line  174)
+* us_minus:                              Arithmetic.         (line   38)
+* us_mult:                               Arithmetic.         (line   93)
+* us_neg:                                Arithmetic.         (line   82)
+* us_plus:                               Arithmetic.         (line   14)
+* us_truncate:                           Conversions.        (line   48)
+* UTAmode:                               Machine Modes.      (line  174)
+* UTQmode:                               Machine Modes.      (line  142)
+* 'V' in constraint:                     Simple Constraints. (line   43)
+* values, returned by functions:         Scalar Return.      (line    6)
+* varargs implementation:                Varargs.            (line    6)
+* variable:                              Declarations.       (line    6)
+* Variable Location Debug Information in RTL: Debug Information.
+                                                             (line    6)
+* variable_size:                         GTY Options.        (line  245)
+* VAR_DECL:                              Declarations.       (line    6)
+* var_location:                          Debug Information.  (line   14)
+* 'vashlM3' instruction pattern:         Standard Names.     (line  530)
+* 'vashrM3' instruction pattern:         Standard Names.     (line  530)
+* VA_ARG_EXPR:                           Unary and Binary Expressions.
+                                                             (line    6)
+* 'vcondMN' instruction pattern:         Standard Names.     (line  213)
+* vector:                                Containers.         (line    6)
+* vector operations:                     Vector Operations.  (line    6)
+* VECTOR_CST:                            Constant expressions.
+                                                             (line    6)
+* VECTOR_STORE_FLAG_VALUE:               Misc.               (line  293)
+* vec_concat:                            Vector Operations.  (line   28)
+* vec_duplicate:                         Vector Operations.  (line   33)
+* 'vec_extractM' instruction pattern:    Standard Names.     (line  203)
+* 'vec_initM' instruction pattern:       Standard Names.     (line  208)
+* 'vec_load_lanesMN' instruction pattern: Standard Names.    (line  165)
+* VEC_LSHIFT_EXPR:                       Vectors.            (line    6)
+* vec_merge:                             Vector Operations.  (line   11)
+* VEC_PACK_FIX_TRUNC_EXPR:               Vectors.            (line    6)
+* VEC_PACK_SAT_EXPR:                     Vectors.            (line    6)
+* 'vec_pack_sfix_trunc_M' instruction pattern: Standard Names.
+                                                             (line  377)
+* 'vec_pack_ssat_M' instruction pattern: Standard Names.     (line  370)
+* VEC_PACK_TRUNC_EXPR:                   Vectors.            (line    6)
+* 'vec_pack_trunc_M' instruction pattern: Standard Names.    (line  363)
+* 'vec_pack_ufix_trunc_M' instruction pattern: Standard Names.
+                                                             (line  377)
+* 'vec_pack_usat_M' instruction pattern: Standard Names.     (line  370)
+* 'vec_permM' instruction pattern:       Standard Names.     (line  223)
+* 'vec_perm_constM' instruction pattern: Standard Names.     (line  239)
+* VEC_RSHIFT_EXPR:                       Vectors.            (line    6)
+* vec_select:                            Vector Operations.  (line   19)
+* 'vec_setM' instruction pattern:        Standard Names.     (line  198)
+* 'vec_shl_M' instruction pattern:       Standard Names.     (line  357)
+* 'vec_shr_M' instruction pattern:       Standard Names.     (line  357)
+* 'vec_store_lanesMN' instruction pattern: Standard Names.   (line  187)
+* 'vec_unpacks_float_hi_M' instruction pattern: Standard Names.
+                                                             (line  398)
+* 'vec_unpacks_float_lo_M' instruction pattern: Standard Names.
+                                                             (line  398)
+* 'vec_unpacks_hi_M' instruction pattern: Standard Names.    (line  384)
+* 'vec_unpacks_lo_M' instruction pattern: Standard Names.    (line  384)
+* 'vec_unpacku_float_hi_M' instruction pattern: Standard Names.
+                                                             (line  398)
+* 'vec_unpacku_float_lo_M' instruction pattern: Standard Names.
+                                                             (line  398)
+* 'vec_unpacku_hi_M' instruction pattern: Standard Names.    (line  391)
+* 'vec_unpacku_lo_M' instruction pattern: Standard Names.    (line  391)
+* VEC_UNPACK_FLOAT_HI_EXPR:              Vectors.            (line    6)
+* VEC_UNPACK_FLOAT_LO_EXPR:              Vectors.            (line    6)
+* VEC_UNPACK_HI_EXPR:                    Vectors.            (line    6)
+* VEC_UNPACK_LO_EXPR:                    Vectors.            (line    6)
+* VEC_WIDEN_MULT_HI_EXPR:                Vectors.            (line    6)
+* VEC_WIDEN_MULT_LO_EXPR:                Vectors.            (line    6)
+* 'vec_widen_smult_even_M' instruction pattern: Standard Names.
+                                                             (line  407)
+* 'vec_widen_smult_hi_M' instruction pattern: Standard Names.
+                                                             (line  407)
+* 'vec_widen_smult_lo_M' instruction pattern: Standard Names.
+                                                             (line  407)
+* 'vec_widen_smult_odd_M' instruction pattern: Standard Names.
+                                                             (line  407)
+* 'vec_widen_sshiftl_hi_M' instruction pattern: Standard Names.
+                                                             (line  418)
+* 'vec_widen_sshiftl_lo_M' instruction pattern: Standard Names.
+                                                             (line  418)
+* 'vec_widen_umult_even_M' instruction pattern: Standard Names.
+                                                             (line  407)
+* 'vec_widen_umult_hi_M' instruction pattern: Standard Names.
+                                                             (line  407)
+* 'vec_widen_umult_lo_M' instruction pattern: Standard Names.
+                                                             (line  407)
+* 'vec_widen_umult_odd_M' instruction pattern: Standard Names.
+                                                             (line  407)
+* 'vec_widen_ushiftl_hi_M' instruction pattern: Standard Names.
+                                                             (line  418)
+* 'vec_widen_ushiftl_lo_M' instruction pattern: Standard Names.
+                                                             (line  418)
+* verify_flow_info:                      Maintaining the CFG.
+                                                             (line  117)
+* virtual operands:                      SSA Operands.       (line    6)
+* VIRTUAL_INCOMING_ARGS_REGNUM:          Regs and Memory.    (line   59)
+* VIRTUAL_OUTGOING_ARGS_REGNUM:          Regs and Memory.    (line   87)
+* VIRTUAL_STACK_DYNAMIC_REGNUM:          Regs and Memory.    (line   78)
+* VIRTUAL_STACK_VARS_REGNUM:             Regs and Memory.    (line   69)
+* VLIW:                                  Processor pipeline description.
+                                                             (line    6)
+* VLIW <1>:                              Processor pipeline description.
+                                                             (line  223)
+* 'vlshrM3' instruction pattern:         Standard Names.     (line  530)
+* VMS:                                   Filesystem.         (line   37)
+* VMS_DEBUGGING_INFO:                    VMS Debug.          (line    8)
+* VOIDmode:                              Machine Modes.      (line  192)
+* VOID_TYPE:                             Types.              (line    6)
+* volatil:                               Flags.              (line  328)
+* 'volatil', in 'insn', 'call_insn', 'jump_insn', 'code_label', 'jump_table_data', 'barrier', and 'note': Flags.
+                                                             (line   44)
+* 'volatil', in 'label_ref' and 'reg_label': Flags.          (line   65)
+* 'volatil', in 'mem', 'asm_operands', and 'asm_input': Flags.
+                                                             (line   76)
+* 'volatil', in 'reg':                   Flags.              (line   98)
+* 'volatil', in 'subreg':                Flags.              (line  170)
+* 'volatil', in 'subreg' <1>:            Flags.              (line  180)
+* 'volatil', in 'symbol_ref':            Flags.              (line  206)
+* volatile memory references:            Flags.              (line  329)
+* 'volatile', in 'prefetch':             Flags.              (line  214)
+* voting between constraint alternatives: Class Preferences. (line    6)
+* 'vrotlM3' instruction pattern:         Standard Names.     (line  530)
+* 'vrotrM3' instruction pattern:         Standard Names.     (line  530)
+* walk_dominator_tree:                   SSA.                (line  227)
+* walk_gimple_op:                        Statement and operand traversals.
+                                                             (line   30)
+* walk_gimple_seq:                       Statement and operand traversals.
+                                                             (line   47)
+* walk_gimple_stmt:                      Statement and operand traversals.
+                                                             (line   10)
+* WCHAR_TYPE:                            Type Layout.        (line  208)
+* WCHAR_TYPE_SIZE:                       Type Layout.        (line  216)
+* which_alternative:                     Output Statement.   (line   58)
+* WHILE_BODY:                            Statements for C++. (line    6)
+* WHILE_COND:                            Statements for C++. (line    6)
+* WHILE_STMT:                            Statements for C++. (line    6)
+* whopr:                                 LTO.                (line    6)
+* WIDEST_HARDWARE_FP_SIZE:               Type Layout.        (line  153)
+* 'window_save' instruction pattern:     Standard Names.     (line 1513)
+* WINT_TYPE:                             Type Layout.        (line  221)
+* WORDS_BIG_ENDIAN:                      Storage Layout.     (line   28)
+* 'WORDS_BIG_ENDIAN', effect on 'subreg': Regs and Memory.   (line  215)
+* word_mode:                             Machine Modes.      (line  358)
+* WORD_REGISTER_OPERATIONS:              Misc.               (line   53)
+* wpa:                                   LTO.                (line    6)
+* 'X' in constraint:                     Simple Constraints. (line  122)
+* 'x-HOST':                              Host Fragment.      (line    6)
+* XCmode:                                Machine Modes.      (line  199)
+* XCOFF_DEBUGGING_INFO:                  DBX Options.        (line   12)
+* XEXP:                                  Accessors.          (line    6)
+* XFmode:                                Machine Modes.      (line   82)
+* XF_SIZE:                               Type Layout.        (line  137)
+* XImode:                                Machine Modes.      (line   54)
+* XINT:                                  Accessors.          (line    6)
+* 'xm-MACHINE.h':                        Filesystem.         (line    6)
+* 'xm-MACHINE.h' <1>:                    Host Misc.          (line    6)
+* xor:                                   Arithmetic.         (line  169)
+* 'xor', canonicalization of:            Insn Canonicalizations.
+                                                             (line   78)
+* 'xorM3' instruction pattern:           Standard Names.     (line  276)
+* XSTR:                                  Accessors.          (line    6)
+* XVEC:                                  Accessors.          (line   41)
+* XVECEXP:                               Accessors.          (line   48)
+* XVECLEN:                               Accessors.          (line   44)
+* XWINT:                                 Accessors.          (line    6)
+* zero_extend:                           Conversions.        (line   28)
+* 'zero_extendMN2' instruction pattern:  Standard Names.     (line  926)
+* zero_extract:                          Bit-Fields.         (line   30)
+* 'zero_extract', canonicalization of:   Insn Canonicalizations.
+                                                             (line   87)
+
+
+
+Tag Table:
+Node: Top1789
+Node: Contributing4877
+Node: Portability5606
+Node: Interface7394
+Node: Libgcc10435
+Node: Integer library routines12262
+Node: Soft float library routines19104
+Node: Decimal float library routines31042
+Node: Fixed-point fractional library routines46800
+Node: Exception handling routines147196
+Node: Miscellaneous routines148303
+Node: Languages150423
+Node: Source Tree151970
+Node: Configure Terms152552
+Node: Top Level155508
+Node: gcc Directory158970
+Node: Subdirectories159922
+Node: Configuration162090
+Node: Config Fragments162810
+Node: System Config164035
+Node: Configuration Files164971
+Node: Build167788
+Node: Makefile168200
+Ref: Makefile-Footnote-1175004
+Ref: Makefile-Footnote-2175151
+Node: Library Files175225
+Node: Headers175787
+Node: Documentation177870
+Node: Texinfo Manuals178729
+Node: Man Page Generation181058
+Node: Miscellaneous Docs182971
+Node: Front End184358
+Node: Front End Directory188032
+Node: Front End Config189348
+Node: Front End Makefile192164
+Node: Back End195932
+Node: Testsuites199713
+Node: Test Idioms200644
+Node: Test Directives204042
+Node: Directives204569
+Node: Selectors214866
+Node: Effective-Target Keywords216222
+Ref: arm_neon_ok223910
+Ref: arm_neonv2_ok224068
+Ref: arm_neon_fp16_ok224240
+Ref: arm_vfp3_ok224680
+Node: Add Options234179
+Node: Require Support235496
+Node: Final Actions238003
+Node: Ada Tests243168
+Node: C Tests244499
+Node: libgcj Tests248894
+Node: LTO Testing250021
+Node: gcov Testing251669
+Node: profopt Testing254659
+Node: compat Testing256374
+Node: Torture Tests260614
+Node: Options262229
+Node: Option file format262670
+Node: Option properties269659
+Node: Passes282686
+Node: Parsing pass283576
+Node: Cilk Plus Transformation287109
+Node: Gimplification pass290491
+Node: Pass manager292336
+Node: Tree SSA passes294182
+Node: RTL passes315249
+Node: Optimization info327613
+Node: Dump setup328432
+Node: Optimization groups329561
+Node: Dump files and streams330450
+Node: Dump output verbosity331648
+Node: Dump types332704
+Node: Dump examples334194
+Node: GENERIC335540
+Node: Deficiencies337416
+Node: Tree overview337657
+Node: Macros and Functions341781
+Node: Identifiers342606
+Node: Containers344215
+Node: Types345372
+Node: Declarations357446
+Node: Working with declarations357941
+Node: Internal structure363545
+Node: Current structure hierarchy363929
+Node: Adding new DECL node types366022
+Node: Attributes370306
+Node: Expression trees371550
+Node: Constant expressions373304
+Node: Storage References377517
+Node: Unary and Binary Expressions381036
+Node: Vectors401184
+Node: Statements405916
+Node: Basic Statements406436
+Node: Blocks410943
+Node: Statement Sequences412347
+Node: Empty Statements412680
+Node: Jumps413254
+Node: Cleanups413907
+Node: OpenMP415674
+Node: Functions421518
+Node: Function Basics421989
+Node: Function Properties425673
+Node: Language-dependent trees428454
+Node: C and C++ Trees429341
+Node: Types for C++432245
+Node: Namespaces437215
+Node: Classes440321
+Node: Functions for C++445398
+Node: Statements for C++451649
+Node: C++ Expressions460422
+Node: Java Trees461927
+Node: GIMPLE462040
+Node: Tuple representation465664
+Node: GIMPLE instruction set473968
+Node: GIMPLE Exception Handling475584
+Node: Temporaries477496
+Ref: Temporaries-Footnote-1478814
+Node: Operands478879
+Node: Compound Expressions479640
+Node: Compound Lvalues479874
+Node: Conditional Expressions480636
+Node: Logical Operators481295
+Node: Manipulating GIMPLE statements488153
+Node: Tuple specific accessors494089
+Node: 'GIMPLE_ASM'494908
+Node: 'GIMPLE_ASSIGN'497425
+Node: 'GIMPLE_BIND'501531
+Node: 'GIMPLE_CALL'503339
+Node: 'GIMPLE_CATCH'507610
+Node: 'GIMPLE_COND'508754
+Node: 'GIMPLE_DEBUG'511542
+Node: 'GIMPLE_EH_FILTER'514920
+Node: 'GIMPLE_LABEL'516408
+Node: 'GIMPLE_NOP'517383
+Node: 'GIMPLE_OMP_ATOMIC_LOAD'517752
+Node: 'GIMPLE_OMP_ATOMIC_STORE'518662
+Node: 'GIMPLE_OMP_CONTINUE'519302
+Node: 'GIMPLE_OMP_CRITICAL'520652
+Node: 'GIMPLE_OMP_FOR'521590
+Node: 'GIMPLE_OMP_MASTER'525105
+Node: 'GIMPLE_OMP_ORDERED'525489
+Node: 'GIMPLE_OMP_PARALLEL'525889
+Node: 'GIMPLE_OMP_RETURN'528522
+Node: 'GIMPLE_OMP_SECTION'529173
+Node: 'GIMPLE_OMP_SECTIONS'529839
+Node: 'GIMPLE_OMP_SINGLE'531446
+Node: 'GIMPLE_PHI'532384
+Node: 'GIMPLE_RESX'533671
+Node: 'GIMPLE_RETURN'534390
+Node: 'GIMPLE_SWITCH'534958
+Node: 'GIMPLE_TRY'536760
+Node: 'GIMPLE_WITH_CLEANUP_EXPR'538551
+Node: GIMPLE sequences539434
+Node: Sequence iterators542640
+Node: Adding a new GIMPLE statement code551095
+Node: Statement and operand traversals552371
+Node: Tree SSA554963
+Node: Annotations556751
+Node: SSA Operands557156
+Node: SSA571230
+Node: Alias analysis582262
+Node: Memory model586036
+Node: RTL587395
+Node: RTL Objects589583
+Node: RTL Classes593457
+Node: Accessors598454
+Node: Special Accessors600848
+Node: Flags606635
+Node: Machine Modes621399
+Node: Constants634687
+Node: Regs and Memory641415
+Node: Arithmetic659303
+Node: Comparisons669385
+Node: Bit-Fields673677
+Node: Vector Operations675229
+Node: Conversions677110
+Node: RTL Declarations681608
+Node: Side Effects682429
+Node: Incdec699439
+Node: Assembler702775
+Node: Debug Information704320
+Node: Insns705517
+Node: Calls731938
+Node: Sharing734531
+Node: Reading RTL737642
+Node: Control Flow738633
+Node: Basic Blocks740402
+Node: Edges745691
+Node: Profile information754320
+Node: Maintaining the CFG759004
+Node: Liveness information764865
+Node: Loop Analysis and Representation766991
+Node: Loop representation768101
+Node: Loop querying775664
+Node: Loop manipulation778480
+Node: LCSSA780841
+Node: Scalar evolutions782910
+Node: loop-iv786154
+Node: Number of iterations788076
+Node: Dependency analysis790882
+Node: Omega797246
+Node: Machine Desc798822
+Node: Overview801385
+Node: Patterns803425
+Node: Example806863
+Node: RTL Template808297
+Node: Output Template818952
+Node: Output Statement822915
+Node: Predicates827254
+Node: Machine-Independent Predicates830172
+Node: Defining Predicates835116
+Node: Constraints841079
+Node: Simple Constraints842561
+Node: Multi-Alternative855401
+Node: Class Preferences858242
+Node: Modifiers859134
+Node: Machine Constraints863380
+Node: Disable Insn Alternatives921548
+Node: Define Constraints924449
+Node: C Constraint Interface931234
+Node: Standard Names934886
+Ref: shift patterns958034
+Ref: prologue instruction pattern1002791
+Ref: window_save instruction pattern1003284
+Ref: epilogue instruction pattern1003561
+Node: Pattern Ordering1021147
+Node: Dependent Patterns1022383
+Node: Jump Patterns1024003
+Ref: Jump Patterns-Footnote-11026150
+Node: Looping Patterns1026198
+Node: Insn Canonicalizations1030927
+Node: Expander Definitions1035512
+Node: Insn Splitting1043726
+Node: Including Patterns1053327
+Node: Peephole Definitions1055108
+Node: define_peephole1056361
+Node: define_peephole21062691
+Node: Insn Attributes1065757
+Node: Defining Attributes1066939
+Ref: define_enum_attr1070432
+Node: Expressions1071468
+Node: Tagging Insns1078218
+Node: Attr Example1082571
+Node: Insn Lengths1084944
+Node: Constant Attributes1088003
+Node: Mnemonic Attribute1089179
+Node: Delay Slots1090698
+Node: Processor pipeline description1093921
+Ref: Processor pipeline description-Footnote-11112739
+Node: Conditional Execution1113063
+Node: Define Subst1116546
+Node: Define Subst Example1118582
+Node: Define Subst Pattern Matching1121576
+Node: Define Subst Output Template1122802
+Node: Constant Definitions1124872
+Ref: define_enum1128654
+Node: Iterators1129142
+Node: Mode Iterators1129720
+Node: Defining Mode Iterators1130698
+Node: Substitutions1132192
+Node: Examples1134434
+Node: Code Iterators1135882
+Node: Int Iterators1138161
+Node: Subst Iterators1140605
+Node: Target Macros1142297
+Node: Target Structure1145385
+Node: Driver1147501
+Node: Run-time Target1166313
+Node: Per-Function Data1176024
+Node: Storage Layout1178788
+Node: Type Layout1205040
+Node: Registers1220363
+Node: Register Basics1221337
+Node: Allocation Order1226845
+Node: Values in Registers1229291
+Node: Leaf Functions1236769
+Node: Stack Registers1239628
+Node: Register Classes1240900
+Node: Old Constraints1271844
+Node: Stack and Calling1278984
+Node: Frame Layout1279518
+Node: Exception Handling1290394
+Node: Stack Checking1296606
+Node: Frame Registers1301420
+Node: Elimination1309679
+Node: Stack Arguments1313909
+Node: Register Arguments1320772
+Node: Scalar Return1341073
+Node: Aggregate Return1347160
+Node: Caller Saves1351371
+Node: Function Entry1352548
+Node: Profiling1363642
+Node: Tail Calls1365341
+Node: Stack Smashing Protection1367244
+Node: Varargs1368872
+Node: Trampolines1375559
+Node: Library Calls1381602
+Node: Addressing Modes1386286
+Node: Anchored Addresses1407254
+Node: Condition Code1409897
+Node: CC0 Condition Codes1412224
+Node: MODE_CC Condition Codes1415470
+Node: Costs1421922
+Node: Scheduling1438384
+Node: Sections1458342
+Node: PIC1474040
+Node: Assembler Format1476099
+Node: File Framework1477237
+Ref: TARGET_HAVE_SWITCHABLE_BSS_SECTIONS1484169
+Node: Data Output1487439
+Node: Uninitialized Data1495208
+Node: Label Output1500219
+Node: Initialization1523175
+Node: Macros for Initialization1529136
+Node: Instruction Output1535855
+Node: Dispatch Tables1546478
+Node: Exception Region Output1550862
+Node: Alignment Output1557540
+Node: Debugging Info1562119
+Node: All Debuggers1562789
+Node: DBX Options1565644
+Node: DBX Hooks1571082
+Node: File Names and DBX1572391
+Node: SDB and DWARF1574503
+Node: VMS Debug1580575
+Node: Floating Point1581162
+Node: Mode Switching1585638
+Node: Target Attributes1589634
+Node: Emulated TLS1598092
+Node: MIPS Coprocessors1601482
+Node: PCH Target1602779
+Node: C++ ABI1604621
+Node: Named Address Spaces1609415
+Node: Misc1614349
+Ref: TARGET_SHIFT_TRUNCATION_MASK1621091
+Node: Host Config1669593
+Node: Host Common1670661
+Node: Filesystem1673035
+Node: Host Misc1677150
+Node: Fragments1679599
+Node: Target Fragment1680794
+Node: Host Fragment1691422
+Node: Collect21691662
+Node: Header Dirs1694298
+Node: Type Information1695721
+Node: GTY Options1698997
+Node: Inheritance and GTY1713517
+Ref: Inheritance and GTY-Footnote-11715080
+Node: User GC1715350
+Node: GGC Roots1719089
+Node: Files1719802
+Node: Invoking the garbage collector1722509
+Node: Troubleshooting1724014
+Node: Plugins1725089
+Node: Plugins loading1726207
+Node: Plugin API1727077
+Node: Plugins pass1734740
+Node: Plugins GC1736711
+Node: Plugins description1738376
+Node: Plugins attr1738912
+Node: Plugins recording1741185
+Node: Plugins gate1742035
+Node: Plugins tracking1742626
+Node: Plugins building1743214
+Node: LTO1745004
+Node: LTO Overview1745865
+Node: LTO object file layout1751697
+Node: IPA1756327
+Node: WHOPR1765292
+Node: Internal flags1769981
+Node: Funding1771392
+Node: GNU Project1773876
+Node: Copying1774525
+Node: GNU Free Documentation License1812036
+Node: Contributors1837156
+Node: Option Index1875028
+Node: Concept Index1875905
+
+End Tag Table
diff --git a/gcc-4.9/gcc/doc/gcj-dbtool.1 b/gcc-4.9/gcc/doc/gcj-dbtool.1
new file mode 100644
index 000000000..ab96d585d
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gcj-dbtool.1
@@ -0,0 +1,247 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GCJ-DBTOOL 1"
+.TH GCJ-DBTOOL 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gcj\-dbtool \- Manipulate class file mapping databases for libgcj
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+gcj-dbtool \fB\s-1OPTION\s0\fR \fI\s-1DBFILE\s0\fR [\fB\s-1MORE\s0\fR] ...
+.PP
+gcj-dbtool [\fB\-0\fR] [\fB\-\fR] [\fB\-n\fR] [\fB\-a\fR] [\fB\-f\fR]
+  [\fB\-t\fR] [\fB\-l\fR] [\fB\-p\fR [\fI\s-1LIBDIR\s0\fR]]
+  [\fB\-v\fR] [\fB\-m\fR] [\fB\-\-version\fR] [\fB\-\-help\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\f(CW\*(C`gcj\-dbtool\*(C'\fR is a tool for creating and manipulating class file
+mapping databases.  \f(CW\*(C`libgcj\*(C'\fR can use these databases to find a
+shared library corresponding to the bytecode representation of a
+class.  This functionality is useful for ahead-of-time compilation of
+a program that has no knowledge of \f(CW\*(C`gcj\*(C'\fR.
+.PP
+\&\f(CW\*(C`gcj\-dbtool\*(C'\fR works best if all the jar files added to it are
+compiled using \f(CW\*(C`\-findirect\-dispatch\*(C'\fR.
+.PP
+Note that \f(CW\*(C`gcj\-dbtool\*(C'\fR is currently available as \*(L"preview
+technology\*(R".  We believe it is a reasonable way to allow
+application-transparent ahead-of-time compilation, but this is an
+unexplored area.  We welcome your comments.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-n\fR \fI\s-1DBFILE\s0\fR \fB[\fR\fI\s-1SIZE\s0\fR\fB]\fR" 4
+.IX Item "-n DBFILE [SIZE]"
+This creates a new database.  Currently, databases cannot be resized;
+you can choose a larger initial size if desired.  The default size is
+32,749.
+.IP "\fB\-a\fR \fI\s-1DBFILE\s0\fR\fB \fR\fI\s-1JARFILE\s0\fR\fB \fR\fI\s-1LIB\s0\fR" 4
+.IX Item "-a DBFILE JARFILE LIB"
+.PD 0
+.IP "\fB\-f\fR \fI\s-1DBFILE\s0\fR\fB \fR\fI\s-1JARFILE\s0\fR\fB \fR\fI\s-1LIB\s0\fR" 4
+.IX Item "-f DBFILE JARFILE LIB"
+.PD
+This adds a jar file to the database.  For each class file in the jar,
+a cryptographic signature of the bytecode representation of the class
+is recorded in the database.  At runtime, a class is looked up by its
+signature and the compiled form of the class is looked for in the
+corresponding shared library.  The \fB\-a\fR option will verify
+that \fI\s-1LIB\s0\fR exists before adding it to the database; \fB\-f\fR
+skips this check.
+.IP "\fB[\fR\fB\-\fR\fB][\fR\fB\-0\fR\fB] \-m\fR \fI\s-1DBFILE\s0\fR\fB \fR\fI\s-1DBFILE\s0\fR\fB,[\fR\fI\s-1DBFILE\s0\fR\fB]\fR" 4
+.IX Item "[-][-0] -m DBFILE DBFILE,[DBFILE]"
+Merge a number of databases.  The output database overwrites any
+existing database.  To add databases into an existing database,
+include the destination in the list of sources.
+.Sp
+If \fB\-\fR or \fB\-0\fR are used, the list of files to read is
+taken from standard input instead of the command line.  For
+\&\fB\-0\fR, Input filenames are terminated by a null character
+instead of by whitespace.  Useful when arguments might contain white
+space.  The \s-1GNU\s0 find \-print0 option produces input suitable for this
+mode.
+.IP "\fB\-t\fR \fI\s-1DBFILE\s0\fR" 4
+.IX Item "-t DBFILE"
+Test a database.
+.IP "\fB\-l\fR \fI\s-1DBFILE\s0\fR" 4
+.IX Item "-l DBFILE"
+List the contents of a database.
+.IP "\fB\-p\fR" 4
+.IX Item "-p"
+Print the name of the default database.  If there is no default
+database, this prints a blank line.  If \fI\s-1LIBDIR\s0\fR is specified, use
+it instead of the default library directory component of the database
+name.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+Print a help message, then exit.
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+.PD 0
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+.PD
+Print version information, then exit.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgcc\fR\|(1), \fIgcj\fR\|(1), \fIgcjh\fR\|(1), \fIjcf\-dump\fR\|(1), \fIgfdl\fR\|(7),
+and the Info entries for \fIgcj\fR and \fIgcc\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/gcj.1 b/gcc-4.9/gcc/doc/gcj.1
new file mode 100644
index 000000000..7aedab72f
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gcj.1
@@ -0,0 +1,593 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GCJ 1"
+.TH GCJ 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gcj \- Ahead\-of\-time compiler for the Java language
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+gcj [\fB\-I\fR\fIdir\fR...] [\fB\-d\fR \fIdir\fR...]
+    [\fB\-\-CLASSPATH\fR=\fIpath\fR] [\fB\-\-classpath\fR=\fIpath\fR]
+    [\fB\-f\fR\fIoption\fR...] [\fB\-\-encoding\fR=\fIname\fR]
+    [\fB\-\-main\fR=\fIclassname\fR] [\fB\-D\fR\fIname\fR[=\fIvalue\fR]...]
+    [\fB\-C\fR] [\fB\-\-resource\fR \fIresource-name\fR] [\fB\-d\fR \fIdirectory\fR]
+    [\fB\-W\fR\fIwarn\fR...]
+    \fIsourcefile\fR...
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+As \fBgcj\fR is just another front end to \fBgcc\fR, it supports many
+of the same options as gcc.    This manual only documents the
+options specific to \fBgcj\fR.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.SS "Input and output files"
+.IX Subsection "Input and output files"
+A \fBgcj\fR command is like a \fBgcc\fR command, in that it
+consists of a number of options and file names.  The following kinds
+of input file names are supported:
+.IP "\fIfile\fR\fB.java\fR" 4
+.IX Item "file.java"
+Java source files.
+.IP "\fIfile\fR\fB.class\fR" 4
+.IX Item "file.class"
+Java bytecode files.
+.IP "\fIfile\fR\fB.zip\fR" 4
+.IX Item "file.zip"
+.PD 0
+.IP "\fIfile\fR\fB.jar\fR" 4
+.IX Item "file.jar"
+.PD
+An archive containing one or more \f(CW\*(C`.class\*(C'\fR files, all of
+which are compiled.  The archive may be compressed.  Files in
+an archive which don't end with \fB.class\fR are treated as
+resource files; they are compiled into the resulting object file
+as \fBcore:\fR URLs.
+.IP "\fB@\fR\fIfile\fR" 4
+.IX Item "@file"
+A file containing a whitespace-separated list of input file names.
+(Currently, these must all be \f(CW\*(C`.java\*(C'\fR source files, but that
+may change.)
+Each named file is compiled, just as if it had been on the command line.
+.IP "\fIlibrary\fR\fB.a\fR" 4
+.IX Item "library.a"
+.PD 0
+.IP "\fIlibrary\fR\fB.so\fR" 4
+.IX Item "library.so"
+.IP "\fB\-l\fR\fIlibname\fR" 4
+.IX Item "-llibname"
+.PD
+Libraries to use when linking.  See the \fBgcc\fR manual.
+.PP
+You can specify more than one input file on the \fBgcj\fR command line,
+in which case they will all be compiled.  If you specify a
+\&\f(CW\*(C`\-o \f(CIFILENAME\f(CW\*(C'\fR
+option, all the input files will be compiled together, producing a
+single output file, named \fI\s-1FILENAME\s0\fR.
+This is allowed even when using \f(CW\*(C`\-S\*(C'\fR or \f(CW\*(C`\-c\*(C'\fR,
+but not when using \f(CW\*(C`\-C\*(C'\fR or \f(CW\*(C`\-\-resource\*(C'\fR.
+(This is an extension beyond the what plain \fBgcc\fR allows.)
+(If more than one input file is specified, all must currently
+be \f(CW\*(C`.java\*(C'\fR files, though we hope to fix this.)
+.SS "Input Options"
+.IX Subsection "Input Options"
+\&\fBgcj\fR has options to control where it looks to find files it needs.
+For instance, \fBgcj\fR might need to load a class that is referenced
+by the file it has been asked to compile.  Like other compilers for the
+Java language, \fBgcj\fR has a notion of a \fIclass path\fR.  There are
+several options and environment variables which can be used to
+manipulate the class path.  When \fBgcj\fR looks for a given class, it
+searches the class path looking for matching \fI.class\fR or
+\&\fI.java\fR file.  \fBgcj\fR comes with a built-in class path which
+points at the installed \fIlibgcj.jar\fR, a file which contains all the
+standard classes.
+.PP
+In the text below, a directory or path component can refer either to an
+actual directory on the filesystem, or to a \fI.zip\fR or \fI.jar\fR
+file, which \fBgcj\fR will search as if it is a directory.
+.IP "\fB\-I\fR\fIdir\fR" 4
+.IX Item "-Idir"
+All directories specified by \f(CW\*(C`\-I\*(C'\fR are kept in order and prepended
+to the class path constructed from all the other options.  Unless
+compatibility with tools like \f(CW\*(C`javac\*(C'\fR is important, we recommend
+always using \f(CW\*(C`\-I\*(C'\fR instead of the other options for manipulating the
+class path.
+.IP "\fB\-\-classpath=\fR\fIpath\fR" 4
+.IX Item "--classpath=path"
+This sets the class path to \fIpath\fR, a colon-separated list of paths
+(on Windows-based systems, a semicolon-separate list of paths).
+This does not override the builtin (\*(L"boot\*(R") search path.
+.IP "\fB\-\-CLASSPATH=\fR\fIpath\fR" 4
+.IX Item "--CLASSPATH=path"
+Deprecated synonym for \f(CW\*(C`\-\-classpath\*(C'\fR.
+.IP "\fB\-\-bootclasspath=\fR\fIpath\fR" 4
+.IX Item "--bootclasspath=path"
+Where to find the standard builtin classes, such as \f(CW\*(C`java.lang.String\*(C'\fR.
+.IP "\fB\-\-extdirs=\fR\fIpath\fR" 4
+.IX Item "--extdirs=path"
+For each directory in the \fIpath\fR, place the contents of that
+directory at the end of the class path.
+.IP "\fB\s-1CLASSPATH\s0\fR" 4
+.IX Item "CLASSPATH"
+This is an environment variable which holds a list of paths.
+.PP
+The final class path is constructed like so:
+.IP "\(bu" 4
+First come all directories specified via \f(CW\*(C`\-I\*(C'\fR.
+.IP "\(bu" 4
+If \fB\-\-classpath\fR is specified, its value is appended.
+Otherwise, if the \f(CW\*(C`CLASSPATH\*(C'\fR environment variable is specified,
+then its value is appended.
+Otherwise, the current directory (\f(CW"."\fR) is appended.
+.IP "\(bu" 4
+If \f(CW\*(C`\-\-bootclasspath\*(C'\fR was specified, append its value.
+Otherwise, append the built-in system directory, \fIlibgcj.jar\fR.
+.IP "\(bu" 4
+Finally, if \f(CW\*(C`\-\-extdirs\*(C'\fR was specified, append the contents of the
+specified directories at the end of the class path.  Otherwise, append
+the contents of the built-in extdirs at \f(CW\*(C`$(prefix)/share/java/ext\*(C'\fR.
+.PP
+The classfile built by \fBgcj\fR for the class \f(CW\*(C`java.lang.Object\*(C'\fR
+(and placed in \f(CW\*(C`libgcj.jar\*(C'\fR) contains a special zero length
+attribute \f(CW\*(C`gnu.gcj.gcj\-compiled\*(C'\fR. The compiler looks for this
+attribute when loading \f(CW\*(C`java.lang.Object\*(C'\fR and will report an error
+if it isn't found, unless it compiles to bytecode (the option
+\&\f(CW\*(C`\-fforce\-classes\-archive\-check\*(C'\fR can be used to override this
+behavior in this particular case.)
+.IP "\fB\-fforce\-classes\-archive\-check\fR" 4
+.IX Item "-fforce-classes-archive-check"
+This forces the compiler to always check for the special zero length
+attribute \f(CW\*(C`gnu.gcj.gcj\-compiled\*(C'\fR in \f(CW\*(C`java.lang.Object\*(C'\fR and
+issue an error if it isn't found.
+.IP "\fB\-fsource=\fR\fI\s-1VERSION\s0\fR" 4
+.IX Item "-fsource=VERSION"
+This option is used to choose the source version accepted by
+\&\fBgcj\fR.  The default is \fB1.5\fR.
+.SS "Encodings"
+.IX Subsection "Encodings"
+The Java programming language uses Unicode throughout.  In an effort to
+integrate well with other locales, \fBgcj\fR allows \fI.java\fR files
+to be written using almost any encoding.  \fBgcj\fR knows how to
+convert these encodings into its internal encoding at compile time.
+.PP
+You can use the \f(CW\*(C`\-\-encoding=\f(CINAME\f(CW\*(C'\fR option to specify an
+encoding (of a particular character set) to use for source files.  If
+this is not specified, the default encoding comes from your current
+locale.  If your host system has insufficient locale support, then
+\&\fBgcj\fR assumes the default encoding to be the \fB\s-1UTF\-8\s0\fR encoding
+of Unicode.
+.PP
+To implement \f(CW\*(C`\-\-encoding\*(C'\fR, \fBgcj\fR simply uses the host
+platform's \f(CW\*(C`iconv\*(C'\fR conversion routine.  This means that in practice
+\&\fBgcj\fR is limited by the capabilities of the host platform.
+.PP
+The names allowed for the argument \f(CW\*(C`\-\-encoding\*(C'\fR vary from platform
+to platform (since they are not standardized anywhere).  However,
+\&\fBgcj\fR implements the encoding named \fB\s-1UTF\-8\s0\fR internally, so if
+you choose to use this for your source files you can be assured that it
+will work on every host.
+.SS "Warnings"
+.IX Subsection "Warnings"
+\&\fBgcj\fR implements several warnings.  As with other generic
+\&\fBgcc\fR warnings, if an option of the form \f(CW\*(C`\-Wfoo\*(C'\fR enables a
+warning, then \f(CW\*(C`\-Wno\-foo\*(C'\fR will disable it.  Here we've chosen to
+document the form of the warning which will have an effect \*(-- the
+default being the opposite of what is listed.
+.IP "\fB\-Wredundant\-modifiers\fR" 4
+.IX Item "-Wredundant-modifiers"
+With this flag, \fBgcj\fR will warn about redundant modifiers.  For
+instance, it will warn if an interface method is declared \f(CW\*(C`public\*(C'\fR.
+.IP "\fB\-Wextraneous\-semicolon\fR" 4
+.IX Item "-Wextraneous-semicolon"
+This causes \fBgcj\fR to warn about empty statements.  Empty statements
+have been deprecated.
+.IP "\fB\-Wno\-out\-of\-date\fR" 4
+.IX Item "-Wno-out-of-date"
+This option will cause \fBgcj\fR not to warn when a source file is
+newer than its matching class file.  By default \fBgcj\fR will warn
+about this.
+.IP "\fB\-Wno\-deprecated\fR" 4
+.IX Item "-Wno-deprecated"
+Warn if a deprecated class, method, or field is referred to.
+.IP "\fB\-Wunused\fR" 4
+.IX Item "-Wunused"
+This is the same as \fBgcc\fR's \f(CW\*(C`\-Wunused\*(C'\fR.
+.IP "\fB\-Wall\fR" 4
+.IX Item "-Wall"
+This is the same as \f(CW\*(C`\-Wredundant\-modifiers \-Wextraneous\-semicolon
+\&\-Wunused\*(C'\fR.
+.SS "Linking"
+.IX Subsection "Linking"
+To turn a Java application into an executable program,
+you need to link it with the needed libraries, just as for C or \*(C+.
+The linker by default looks for a global function named \f(CW\*(C`main\*(C'\fR.
+Since Java does not have global functions, and a
+collection of Java classes may have more than one class with a
+\&\f(CW\*(C`main\*(C'\fR method, you need to let the linker know which of those
+\&\f(CW\*(C`main\*(C'\fR methods it should invoke when starting the application.
+You can do that in any of these ways:
+.IP "\(bu" 4
+Specify the class containing the desired \f(CW\*(C`main\*(C'\fR method
+when you link the application, using the \f(CW\*(C`\-\-main\*(C'\fR flag,
+described below.
+.IP "\(bu" 4
+Link the Java package(s) into a shared library (dll) rather than an
+executable.  Then invoke the application using the \f(CW\*(C`gij\*(C'\fR program,
+making sure that \f(CW\*(C`gij\*(C'\fR can find the libraries it needs.
+.IP "\(bu" 4
+Link the Java packages(s) with the flag \f(CW\*(C`\-lgij\*(C'\fR, which links
+in the \f(CW\*(C`main\*(C'\fR routine from the \f(CW\*(C`gij\*(C'\fR command.
+This allows you to select the class whose \f(CW\*(C`main\*(C'\fR method you
+want to run when you run the application.  You can also use
+other \f(CW\*(C`gij\*(C'\fR flags, such as \f(CW\*(C`\-D\*(C'\fR flags to set properties.
+Using the \f(CW\*(C`\-lgij\*(C'\fR library (rather than the \f(CW\*(C`gij\*(C'\fR program
+of the previous mechanism) has some advantages: it is compatible with
+static linking, and does not require configuring or installing libraries.
+.PP
+These \f(CW\*(C`gij\*(C'\fR options relate to linking an executable:
+.IP "\fB\-\-main=\fR\fI\s-1CLASSNAME\s0\fR" 4
+.IX Item "--main=CLASSNAME"
+This option is used when linking to specify the name of the class whose
+\&\f(CW\*(C`main\*(C'\fR method should be invoked when the resulting executable is
+run.
+.IP "\fB\-D\fR\fIname\fR\fB[=\fR\fIvalue\fR\fB]\fR" 4
+.IX Item "-Dname[=value]"
+This option can only be used with \f(CW\*(C`\-\-main\*(C'\fR.  It defines a system
+property named \fIname\fR with value \fIvalue\fR.  If \fIvalue\fR is not
+specified then it defaults to the empty string.  These system properties
+are initialized at the program's startup and can be retrieved at runtime
+using the \f(CW\*(C`java.lang.System.getProperty\*(C'\fR method.
+.IP "\fB\-lgij\fR" 4
+.IX Item "-lgij"
+Create an application whose command-line processing is that
+of the \f(CW\*(C`gij\*(C'\fR command.
+.Sp
+This option is an alternative to using \f(CW\*(C`\-\-main\*(C'\fR; you cannot use both.
+.IP "\fB\-static\-libgcj\fR" 4
+.IX Item "-static-libgcj"
+This option causes linking to be done against a static version of the
+libgcj runtime library.  This option is only available if
+corresponding linker support exists.
+.Sp
+\&\fBCaution:\fR Static linking of libgcj may cause essential parts
+of libgcj to be omitted.  Some parts of libgcj use reflection to load
+classes at runtime.  Since the linker does not see these references at
+link time, it can omit the referred to classes.  The result is usually
+(but not always) a \f(CW\*(C`ClassNotFoundException\*(C'\fR being thrown at
+runtime. Caution must be used when using this option.  For more
+details see:
+<\fBhttp://gcc.gnu.org/wiki/Statically%20linking%20libgcj\fR>
+.SS "Code Generation"
+.IX Subsection "Code Generation"
+In addition to the many \fBgcc\fR options controlling code generation,
+\&\fBgcj\fR has several options specific to itself.
+.IP "\fB\-C\fR" 4
+.IX Item "-C"
+This option is used to tell \fBgcj\fR to generate bytecode
+(\fI.class\fR files) rather than object code.
+.IP "\fB\-\-resource\fR \fIresource-name\fR" 4
+.IX Item "--resource resource-name"
+This option is used to tell \fBgcj\fR to compile the contents of a
+given file to object code so it may be accessed at runtime with the core
+protocol handler as \fBcore:/\fR\fIresource-name\fR.  Note that
+\&\fIresource-name\fR is the name of the resource as found at runtime; for
+instance, it could be used in a call to \f(CW\*(C`ResourceBundle.getBundle\*(C'\fR.
+The actual file name to be compiled this way must be specified
+separately.
+.IP "\fB\-ftarget=\fR\fI\s-1VERSION\s0\fR" 4
+.IX Item "-ftarget=VERSION"
+This can be used with \fB\-C\fR to choose the version of bytecode
+emitted by \fBgcj\fR.  The default is \fB1.5\fR.  When not
+generating bytecode, this option has no effect.
+.IP "\fB\-d\fR \fIdirectory\fR" 4
+.IX Item "-d directory"
+When used with \f(CW\*(C`\-C\*(C'\fR, this causes all generated \fI.class\fR files
+to be put in the appropriate subdirectory of \fIdirectory\fR.  By
+default they will be put in subdirectories of the current working
+directory.
+.IP "\fB\-fno\-bounds\-check\fR" 4
+.IX Item "-fno-bounds-check"
+By default, \fBgcj\fR generates code which checks the bounds of all
+array indexing operations.  With this option, these checks are omitted, which
+can improve performance for code that uses arrays extensively.  Note that this 
+can result in unpredictable behavior if the code in question actually does 
+violate array bounds constraints.  It is safe to use this option if you are 
+sure that your code will never throw an \f(CW\*(C`ArrayIndexOutOfBoundsException\*(C'\fR.
+.IP "\fB\-fno\-store\-check\fR" 4
+.IX Item "-fno-store-check"
+Don't generate array store checks.  When storing objects into arrays, a runtime
+check is normally generated in order to ensure that the object is assignment
+compatible with the component type of the array (which may not be known
+at compile-time).  With this option, these checks are omitted.  This can 
+improve performance for code which stores objects into arrays frequently.
+It is safe to use this option if you are sure your code will never throw an 
+\&\f(CW\*(C`ArrayStoreException\*(C'\fR.
+.IP "\fB\-fjni\fR" 4
+.IX Item "-fjni"
+With \fBgcj\fR there are two options for writing native methods: \s-1CNI\s0
+and \s-1JNI. \s0 By default \fBgcj\fR assumes you are using \s-1CNI. \s0 If you are
+compiling a class with native methods, and these methods are implemented
+using \s-1JNI,\s0 then you must use \f(CW\*(C`\-fjni\*(C'\fR.  This option causes
+\&\fBgcj\fR to generate stubs which will invoke the underlying \s-1JNI\s0
+methods.
+.IP "\fB\-fno\-assert\fR" 4
+.IX Item "-fno-assert"
+Don't recognize the \f(CW\*(C`assert\*(C'\fR keyword.  This is for compatibility
+with older versions of the language specification.
+.IP "\fB\-fno\-optimize\-static\-class\-initialization\fR" 4
+.IX Item "-fno-optimize-static-class-initialization"
+When the optimization level is greater or equal to \f(CW\*(C`\-O2\*(C'\fR,
+\&\fBgcj\fR will try to optimize the way calls into the runtime are made
+to initialize static classes upon their first use (this optimization
+isn't carried out if \f(CW\*(C`\-C\*(C'\fR was specified.) When compiling to native
+code, \f(CW\*(C`\-fno\-optimize\-static\-class\-initialization\*(C'\fR will turn this
+optimization off, regardless of the optimization level in use.
+.IP "\fB\-\-disable\-assertions[=\fR\fIclass-or-package\fR\fB]\fR" 4
+.IX Item "--disable-assertions[=class-or-package]"
+Don't include code for checking assertions in the compiled code.
+If \f(CW\*(C`=\f(CIclass\-or\-package\f(CW\*(C'\fR is missing disables assertion code
+generation for all classes, unless overridden by a more
+specific \f(CW\*(C`\-\-enable\-assertions\*(C'\fR flag.
+If \fIclass-or-package\fR is a class name, only disables generating
+assertion checks within the named class or its inner classes.
+If \fIclass-or-package\fR is a package name, disables generating
+assertion checks within the named package or a subpackage.
+.Sp
+By default, assertions are enabled when generating class files
+or when not optimizing, and disabled when generating optimized binaries.
+.IP "\fB\-\-enable\-assertions[=\fR\fIclass-or-package\fR\fB]\fR" 4
+.IX Item "--enable-assertions[=class-or-package]"
+Generates code to check assertions.  The option is perhaps misnamed,
+as you still need to turn on assertion checking at run-time,
+and we don't support any easy way to do that.
+So this flag isn't very useful yet, except to partially override
+\&\f(CW\*(C`\-\-disable\-assertions\*(C'\fR.
+.IP "\fB\-findirect\-dispatch\fR" 4
+.IX Item "-findirect-dispatch"
+\&\fBgcj\fR has a special binary compatibility \s-1ABI,\s0 which is enabled
+by the \f(CW\*(C`\-findirect\-dispatch\*(C'\fR option.  In this mode, the code
+generated by \fBgcj\fR honors the binary compatibility guarantees
+in the Java Language Specification, and the resulting object files do
+not need to be directly linked against their dependencies.  Instead,
+all dependencies are looked up at runtime.  This allows free mixing of
+interpreted and compiled code.
+.Sp
+Note that, at present, \f(CW\*(C`\-findirect\-dispatch\*(C'\fR can only be used
+when compiling \fI.class\fR files.  It will not work when compiling
+from source.  \s-1CNI\s0 also does not yet work with the binary compatibility
+\&\s-1ABI. \s0 These restrictions will be lifted in some future release.
+.Sp
+However, if you compile \s-1CNI\s0 code with the standard \s-1ABI,\s0 you can call
+it from code built with the binary compatibility \s-1ABI.\s0
+.IP "\fB\-fbootstrap\-classes\fR" 4
+.IX Item "-fbootstrap-classes"
+This option can be use to tell \f(CW\*(C`libgcj\*(C'\fR that the compiled classes
+should be loaded by the bootstrap loader, not the system class loader.
+By default, if you compile a class and link it into an executable, it
+will be treated as if it was loaded using the system class loader.
+This is convenient, as it means that things like
+\&\f(CW\*(C`Class.forName()\*(C'\fR will search \fB\s-1CLASSPATH\s0\fR to find the
+desired class.
+.IP "\fB\-freduced\-reflection\fR" 4
+.IX Item "-freduced-reflection"
+This option causes the code generated by \fBgcj\fR to contain a
+reduced amount of the class meta-data used to support runtime
+reflection. The cost of this savings is the loss of
+the ability to use certain reflection capabilities of the standard
+Java runtime environment. When set all meta-data except for that
+which is needed to obtain correct runtime semantics is eliminated.
+.Sp
+For code that does not use reflection (i.e. serialization, \s-1RMI, CORBA\s0
+or call methods in the \f(CW\*(C`java.lang.reflect\*(C'\fR package),
+\&\f(CW\*(C`\-freduced\-reflection\*(C'\fR will result in proper operation with a
+savings in executable code size.
+.Sp
+\&\s-1JNI \s0(\f(CW\*(C`\-fjni\*(C'\fR) and the binary compatibility \s-1ABI
+\&\s0(\f(CW\*(C`\-findirect\-dispatch\*(C'\fR) do not work properly without full
+reflection meta-data.  Because of this, it is an error to use these options
+with \f(CW\*(C`\-freduced\-reflection\*(C'\fR.
+.Sp
+\&\fBCaution:\fR If there is no reflection meta-data, code that uses
+a \f(CW\*(C`SecurityManager\*(C'\fR may not work properly.  Also calling
+\&\f(CW\*(C`Class.forName()\*(C'\fR may fail if the calling method has no
+reflection meta-data.
+.SS "Configure-time Options"
+.IX Subsection "Configure-time Options"
+Some \fBgcj\fR code generations options affect the resulting \s-1ABI,\s0 and
+so can only be meaningfully given when \f(CW\*(C`libgcj\*(C'\fR, the runtime
+package, is configured.  \f(CW\*(C`libgcj\*(C'\fR puts the appropriate options from
+this group into a \fBspec\fR file which is read by \fBgcj\fR.  These
+options are listed here for completeness; if you are using \f(CW\*(C`libgcj\*(C'\fR
+then you won't want to touch these options.
+.IP "\fB\-fuse\-boehm\-gc\fR" 4
+.IX Item "-fuse-boehm-gc"
+This enables the use of the Boehm \s-1GC\s0 bitmap marking code.  In particular
+this causes \fBgcj\fR to put an object marking descriptor into each
+vtable.
+.IP "\fB\-fhash\-synchronization\fR" 4
+.IX Item "-fhash-synchronization"
+By default, synchronization data (the data used for \f(CW\*(C`synchronize\*(C'\fR,
+\&\f(CW\*(C`wait\*(C'\fR, and \f(CW\*(C`notify\*(C'\fR) is pointed to by a word in each object.
+With this option \fBgcj\fR assumes that this information is stored in a
+hash table and not in the object itself.
+.IP "\fB\-fuse\-divide\-subroutine\fR" 4
+.IX Item "-fuse-divide-subroutine"
+On some systems, a library routine is called to perform integer
+division.  This is required to get exception handling correct when
+dividing by zero.
+.IP "\fB\-fcheck\-references\fR" 4
+.IX Item "-fcheck-references"
+On some systems it's necessary to insert inline checks whenever
+accessing an object via a reference.  On other systems you won't need
+this because null pointer accesses are caught automatically by the
+processor.
+.IP "\fB\-fuse\-atomic\-builtins\fR" 4
+.IX Item "-fuse-atomic-builtins"
+On some systems, \s-1GCC\s0 can generate code for built-in atomic operations.
+Use this option to force gcj to use these builtins when compiling Java
+code.  Where this capability is present it should be automatically
+detected, so you won't usually need to use this option.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgcc\fR\|(1), \fIgcjh\fR\|(1), \fIgjnih\fR\|(1), \fIgij\fR\|(1), \fIjcf\-dump\fR\|(1), \fIgfdl\fR\|(7),
+and the Info entries for \fIgcj\fR and \fIgcc\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/gcj.info b/gcc-4.9/gcc/doc/gcj.info
new file mode 100644
index 000000000..cd5c9b161
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gcj.info
@@ -0,0 +1,3653 @@
+This is gcj.info, produced by makeinfo version 5.1 from gcj.texi.
+
+Copyright (C) 2001-2014 Free Software Foundation, Inc.
+
+   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 "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.
+INFO-DIR-SECTION Software development
+START-INFO-DIR-ENTRY
+* Gcj: (gcj).               Ahead-of-time compiler for the Java language
+END-INFO-DIR-ENTRY
+
+INFO-DIR-SECTION Individual utilities
+START-INFO-DIR-ENTRY
+* jcf-dump: (gcj)Invoking jcf-dump.
+                            Print information about Java class files
+* gij: (gcj)Invoking gij.   GNU interpreter for Java bytecode
+* gcj-dbtool: (gcj)Invoking gcj-dbtool.
+                            Tool for manipulating class file databases.
+* jv-convert: (gcj)Invoking jv-convert.
+                            Convert file from one encoding to another
+* grmic: (gcj)Invoking grmic.
+                            Generate stubs for Remote Method Invocation.
+* gc-analyze: (gcj)Invoking gc-analyze.
+                            Analyze Garbage Collector (GC) memory dumps.
+* aot-compile: (gcj)Invoking aot-compile.
+                            Compile bytecode to native and generate databases.
+* rebuild-gcj-db: (gcj)Invoking rebuild-gcj-db.
+                            Merge the per-solib databases made by aot-compile
+                            into one system-wide database.
+END-INFO-DIR-ENTRY
+
+
+   Copyright (C) 2001-2014 Free Software Foundation, Inc.
+
+   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 "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.
+
+
+File: gcj.info,  Node: Top,  Next: Copying,  Up: (dir)
+
+Introduction
+************
+
+This manual describes how to use 'gcj', the GNU compiler for the Java
+programming language.  'gcj' can generate both '.class' files and object
+files, and it can read both Java source code and '.class' files.
+
+* Menu:
+
+* Copying::             The GNU General Public License
+* GNU Free Documentation License::
+                        How you can share and copy this manual
+* Invoking gcj::        Compiler options supported by 'gcj'
+* Compatibility::       Compatibility between gcj and other tools for Java
+* Invoking jcf-dump::   Print information about class files
+* Invoking gij::        Interpreting Java bytecodes
+* Invoking gcj-dbtool:: Tool for manipulating class file databases.
+* Invoking jv-convert:: Converting from one encoding to another
+* Invoking grmic::      Generate stubs for Remote Method Invocation.
+* Invoking gc-analyze:: Analyze Garbage Collector (GC) memory dumps.
+* Invoking aot-compile:: Compile bytecode to native and generate databases.
+* Invoking rebuild-gcj-db:: Merge the per-solib databases made by aot-compile
+                            into one system-wide database.
+* About CNI::           Description of the Compiled Native Interface
+* System properties::   Modifying runtime behavior of the libgcj library
+* Resources::           Where to look for more information
+* Index::               Index.
+
+
+File: gcj.info,  Node: Copying,  Next: GNU Free Documentation License,  Prev: Top,  Up: Top
+
+GNU General Public License
+**************************
+
+                        Version 3, 29 June 2007
+
+     Copyright (C) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+
+     Everyone is permitted to copy and distribute verbatim copies of this
+     license document, but changing it is not allowed.
+
+Preamble
+========
+
+The GNU General Public License is a free, copyleft license for software
+and other kinds of works.
+
+   The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the GNU General Public License is intended to guarantee your freedom to
+share and change all versions of a program-to make sure it remains free
+software for all its users.  We, the Free Software Foundation, use the
+GNU General Public License for most of our software; it applies also to
+any other work released this way by its authors.  You can apply it to
+your programs, too.
+
+   When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+
+   To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you have
+certain responsibilities if you distribute copies of the software, or if
+you modify it: responsibilities to respect the freedom of others.
+
+   For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too, receive
+or can get the source code.  And you must show them these terms so they
+know their rights.
+
+   Developers that use the GNU GPL protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+
+   For the developers' and authors' protection, the GPL clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the GPL requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+
+   Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the manufacturer
+can do so.  This is fundamentally incompatible with the aim of
+protecting users' freedom to change the software.  The systematic
+pattern of such abuse occurs in the area of products for individuals to
+use, which is precisely where it is most unacceptable.  Therefore, we
+have designed this version of the GPL to prohibit the practice for those
+products.  If such problems arise substantially in other domains, we
+stand ready to extend this provision to those domains in future versions
+of the GPL, as needed to protect the freedom of users.
+
+   Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish to
+avoid the special danger that patents applied to a free program could
+make it effectively proprietary.  To prevent this, the GPL assures that
+patents cannot be used to render the program non-free.
+
+   The precise terms and conditions for copying, distribution and
+modification follow.
+
+TERMS AND CONDITIONS
+====================
+
+  0. Definitions.
+
+     "This License" refers to version 3 of the GNU General Public
+     License.
+
+     "Copyright" also means copyright-like laws that apply to other
+     kinds of works, such as semiconductor masks.
+
+     "The Program" refers to any copyrightable work licensed under this
+     License.  Each licensee is addressed as "you".  "Licensees" and
+     "recipients" may be individuals or organizations.
+
+     To "modify" a work means to copy from or adapt all or part of the
+     work in a fashion requiring copyright permission, other than the
+     making of an exact copy.  The resulting work is called a "modified
+     version" of the earlier work or a work "based on" the earlier work.
+
+     A "covered work" means either the unmodified Program or a work
+     based on the Program.
+
+     To "propagate" a work means to do anything with it that, without
+     permission, would make you directly or secondarily liable for
+     infringement under applicable copyright law, except executing it on
+     a computer or modifying a private copy.  Propagation includes
+     copying, distribution (with or without modification), making
+     available to the public, and in some countries other activities as
+     well.
+
+     To "convey" a work means any kind of propagation that enables other
+     parties to make or receive copies.  Mere interaction with a user
+     through a computer network, with no transfer of a copy, is not
+     conveying.
+
+     An interactive user interface displays "Appropriate Legal Notices"
+     to the extent that it includes a convenient and prominently visible
+     feature that (1) displays an appropriate copyright notice, and (2)
+     tells the user that there is no warranty for the work (except to
+     the extent that warranties are provided), that licensees may convey
+     the work under this License, and how to view a copy of this
+     License.  If the interface presents a list of user commands or
+     options, such as a menu, a prominent item in the list meets this
+     criterion.
+
+  1. Source Code.
+
+     The "source code" for a work means the preferred form of the work
+     for making modifications to it.  "Object code" means any non-source
+     form of a work.
+
+     A "Standard Interface" means an interface that either is an
+     official standard defined by a recognized standards body, or, in
+     the case of interfaces specified for a particular programming
+     language, one that is widely used among developers working in that
+     language.
+
+     The "System Libraries" of an executable work include anything,
+     other than the work as a whole, that (a) is included in the normal
+     form of packaging a Major Component, but which is not part of that
+     Major Component, and (b) serves only to enable use of the work with
+     that Major Component, or to implement a Standard Interface for
+     which an implementation is available to the public in source code
+     form.  A "Major Component", in this context, means a major
+     essential component (kernel, window system, and so on) of the
+     specific operating system (if any) on which the executable work
+     runs, or a compiler used to produce the work, or an object code
+     interpreter used to run it.
+
+     The "Corresponding Source" for a work in object code form means all
+     the source code needed to generate, install, and (for an executable
+     work) run the object code and to modify the work, including scripts
+     to control those activities.  However, it does not include the
+     work's System Libraries, or general-purpose tools or generally
+     available free programs which are used unmodified in performing
+     those activities but which are not part of the work.  For example,
+     Corresponding Source includes interface definition files associated
+     with source files for the work, and the source code for shared
+     libraries and dynamically linked subprograms that the work is
+     specifically designed to require, such as by intimate data
+     communication or control flow between those subprograms and other
+     parts of the work.
+
+     The Corresponding Source need not include anything that users can
+     regenerate automatically from other parts of the Corresponding
+     Source.
+
+     The Corresponding Source for a work in source code form is that
+     same work.
+
+  2. Basic Permissions.
+
+     All rights granted under this License are granted for the term of
+     copyright on the Program, and are irrevocable provided the stated
+     conditions are met.  This License explicitly affirms your unlimited
+     permission to run the unmodified Program.  The output from running
+     a covered work is covered by this License only if the output, given
+     its content, constitutes a covered work.  This License acknowledges
+     your rights of fair use or other equivalent, as provided by
+     copyright law.
+
+     You may make, run and propagate covered works that you do not
+     convey, without conditions so long as your license otherwise
+     remains in force.  You may convey covered works to others for the
+     sole purpose of having them make modifications exclusively for you,
+     or provide you with facilities for running those works, provided
+     that you comply with the terms of this License in conveying all
+     material for which you do not control copyright.  Those thus making
+     or running the covered works for you must do so exclusively on your
+     behalf, under your direction and control, on terms that prohibit
+     them from making any copies of your copyrighted material outside
+     their relationship with you.
+
+     Conveying under any other circumstances is permitted solely under
+     the conditions stated below.  Sublicensing is not allowed; section
+     10 makes it unnecessary.
+
+  3. Protecting Users' Legal Rights From Anti-Circumvention Law.
+
+     No covered work shall be deemed part of an effective technological
+     measure under any applicable law fulfilling obligations under
+     article 11 of the WIPO copyright treaty adopted on 20 December
+     1996, or similar laws prohibiting or restricting circumvention of
+     such measures.
+
+     When you convey a covered work, you waive any legal power to forbid
+     circumvention of technological measures to the extent such
+     circumvention is effected by exercising rights under this License
+     with respect to the covered work, and you disclaim any intention to
+     limit operation or modification of the work as a means of
+     enforcing, against the work's users, your or third parties' legal
+     rights to forbid circumvention of technological measures.
+
+  4. Conveying Verbatim Copies.
+
+     You may convey verbatim copies of the Program's source code as you
+     receive it, in any medium, provided that you conspicuously and
+     appropriately publish on each copy an appropriate copyright notice;
+     keep intact all notices stating that this License and any
+     non-permissive terms added in accord with section 7 apply to the
+     code; keep intact all notices of the absence of any warranty; and
+     give all recipients a copy of this License along with the Program.
+
+     You may charge any price or no price for each copy that you convey,
+     and you may offer support or warranty protection for a fee.
+
+  5. Conveying Modified Source Versions.
+
+     You may convey a work based on the Program, or the modifications to
+     produce it from the Program, in the form of source code under the
+     terms of section 4, provided that you also meet all of these
+     conditions:
+
+       a. The work must carry prominent notices stating that you
+          modified it, and giving a relevant date.
+
+       b. The work must carry prominent notices stating that it is
+          released under this License and any conditions added under
+          section 7.  This requirement modifies the requirement in
+          section 4 to "keep intact all notices".
+
+       c. You must license the entire work, as a whole, under this
+          License to anyone who comes into possession of a copy.  This
+          License will therefore apply, along with any applicable
+          section 7 additional terms, to the whole of the work, and all
+          its parts, regardless of how they are packaged.  This License
+          gives no permission to license the work in any other way, but
+          it does not invalidate such permission if you have separately
+          received it.
+
+       d. If the work has interactive user interfaces, each must display
+          Appropriate Legal Notices; however, if the Program has
+          interactive interfaces that do not display Appropriate Legal
+          Notices, your work need not make them do so.
+
+     A compilation of a covered work with other separate and independent
+     works, which are not by their nature extensions of the covered
+     work, and which are not combined with it such as to form a larger
+     program, in or on a volume of a storage or distribution medium, is
+     called an "aggregate" if the compilation and its resulting
+     copyright are not used to limit the access or legal rights of the
+     compilation's users beyond what the individual works permit.
+     Inclusion of a covered work in an aggregate does not cause this
+     License to apply to the other parts of the aggregate.
+
+  6. Conveying Non-Source Forms.
+
+     You may convey a covered work in object code form under the terms
+     of sections 4 and 5, provided that you also convey the
+     machine-readable Corresponding Source under the terms of this
+     License, in one of these ways:
+
+       a. Convey the object code in, or embodied in, a physical product
+          (including a physical distribution medium), accompanied by the
+          Corresponding Source fixed on a durable physical medium
+          customarily used for software interchange.
+
+       b. Convey the object code in, or embodied in, a physical product
+          (including a physical distribution medium), accompanied by a
+          written offer, valid for at least three years and valid for as
+          long as you offer spare parts or customer support for that
+          product model, to give anyone who possesses the object code
+          either (1) a copy of the Corresponding Source for all the
+          software in the product that is covered by this License, on a
+          durable physical medium customarily used for software
+          interchange, for a price no more than your reasonable cost of
+          physically performing this conveying of source, or (2) access
+          to copy the Corresponding Source from a network server at no
+          charge.
+
+       c. Convey individual copies of the object code with a copy of the
+          written offer to provide the Corresponding Source.  This
+          alternative is allowed only occasionally and noncommercially,
+          and only if you received the object code with such an offer,
+          in accord with subsection 6b.
+
+       d. Convey the object code by offering access from a designated
+          place (gratis or for a charge), and offer equivalent access to
+          the Corresponding Source in the same way through the same
+          place at no further charge.  You need not require recipients
+          to copy the Corresponding Source along with the object code.
+          If the place to copy the object code is a network server, the
+          Corresponding Source may be on a different server (operated by
+          you or a third party) that supports equivalent copying
+          facilities, provided you maintain clear directions next to the
+          object code saying where to find the Corresponding Source.
+          Regardless of what server hosts the Corresponding Source, you
+          remain obligated to ensure that it is available for as long as
+          needed to satisfy these requirements.
+
+       e. Convey the object code using peer-to-peer transmission,
+          provided you inform other peers where the object code and
+          Corresponding Source of the work are being offered to the
+          general public at no charge under subsection 6d.
+
+     A separable portion of the object code, whose source code is
+     excluded from the Corresponding Source as a System Library, need
+     not be included in conveying the object code work.
+
+     A "User Product" is either (1) a "consumer product", which means
+     any tangible personal property which is normally used for personal,
+     family, or household purposes, or (2) anything designed or sold for
+     incorporation into a dwelling.  In determining whether a product is
+     a consumer product, doubtful cases shall be resolved in favor of
+     coverage.  For a particular product received by a particular user,
+     "normally used" refers to a typical or common use of that class of
+     product, regardless of the status of the particular user or of the
+     way in which the particular user actually uses, or expects or is
+     expected to use, the product.  A product is a consumer product
+     regardless of whether the product has substantial commercial,
+     industrial or non-consumer uses, unless such uses represent the
+     only significant mode of use of the product.
+
+     "Installation Information" for a User Product means any methods,
+     procedures, authorization keys, or other information required to
+     install and execute modified versions of a covered work in that
+     User Product from a modified version of its Corresponding Source.
+     The information must suffice to ensure that the continued
+     functioning of the modified object code is in no case prevented or
+     interfered with solely because modification has been made.
+
+     If you convey an object code work under this section in, or with,
+     or specifically for use in, a User Product, and the conveying
+     occurs as part of a transaction in which the right of possession
+     and use of the User Product is transferred to the recipient in
+     perpetuity or for a fixed term (regardless of how the transaction
+     is characterized), the Corresponding Source conveyed under this
+     section must be accompanied by the Installation Information.  But
+     this requirement does not apply if neither you nor any third party
+     retains the ability to install modified object code on the User
+     Product (for example, the work has been installed in ROM).
+
+     The requirement to provide Installation Information does not
+     include a requirement to continue to provide support service,
+     warranty, or updates for a work that has been modified or installed
+     by the recipient, or for the User Product in which it has been
+     modified or installed.  Access to a network may be denied when the
+     modification itself materially and adversely affects the operation
+     of the network or violates the rules and protocols for
+     communication across the network.
+
+     Corresponding Source conveyed, and Installation Information
+     provided, in accord with this section must be in a format that is
+     publicly documented (and with an implementation available to the
+     public in source code form), and must require no special password
+     or key for unpacking, reading or copying.
+
+  7. Additional Terms.
+
+     "Additional permissions" are terms that supplement the terms of
+     this License by making exceptions from one or more of its
+     conditions.  Additional permissions that are applicable to the
+     entire Program shall be treated as though they were included in
+     this License, to the extent that they are valid under applicable
+     law.  If additional permissions apply only to part of the Program,
+     that part may be used separately under those permissions, but the
+     entire Program remains governed by this License without regard to
+     the additional permissions.
+
+     When you convey a copy of a covered work, you may at your option
+     remove any additional permissions from that copy, or from any part
+     of it.  (Additional permissions may be written to require their own
+     removal in certain cases when you modify the work.)  You may place
+     additional permissions on material, added by you to a covered work,
+     for which you have or can give appropriate copyright permission.
+
+     Notwithstanding any other provision of this License, for material
+     you add to a covered work, you may (if authorized by the copyright
+     holders of that material) supplement the terms of this License with
+     terms:
+
+       a. Disclaiming warranty or limiting liability differently from
+          the terms of sections 15 and 16 of this License; or
+
+       b. Requiring preservation of specified reasonable legal notices
+          or author attributions in that material or in the Appropriate
+          Legal Notices displayed by works containing it; or
+
+       c. Prohibiting misrepresentation of the origin of that material,
+          or requiring that modified versions of such material be marked
+          in reasonable ways as different from the original version; or
+
+       d. Limiting the use for publicity purposes of names of licensors
+          or authors of the material; or
+
+       e. Declining to grant rights under trademark law for use of some
+          trade names, trademarks, or service marks; or
+
+       f. Requiring indemnification of licensors and authors of that
+          material by anyone who conveys the material (or modified
+          versions of it) with contractual assumptions of liability to
+          the recipient, for any liability that these contractual
+          assumptions directly impose on those licensors and authors.
+
+     All other non-permissive additional terms are considered "further
+     restrictions" within the meaning of section 10.  If the Program as
+     you received it, or any part of it, contains a notice stating that
+     it is governed by this License along with a term that is a further
+     restriction, you may remove that term.  If a license document
+     contains a further restriction but permits relicensing or conveying
+     under this License, you may add to a covered work material governed
+     by the terms of that license document, provided that the further
+     restriction does not survive such relicensing or conveying.
+
+     If you add terms to a covered work in accord with this section, you
+     must place, in the relevant source files, a statement of the
+     additional terms that apply to those files, or a notice indicating
+     where to find the applicable terms.
+
+     Additional terms, permissive or non-permissive, may be stated in
+     the form of a separately written license, or stated as exceptions;
+     the above requirements apply either way.
+
+  8. Termination.
+
+     You may not propagate or modify a covered work except as expressly
+     provided under this License.  Any attempt otherwise to propagate or
+     modify it is void, and will automatically terminate your rights
+     under this License (including any patent licenses granted under the
+     third paragraph of section 11).
+
+     However, if you cease all violation of this License, then your
+     license from a particular copyright holder is reinstated (a)
+     provisionally, unless and until the copyright holder explicitly and
+     finally terminates your license, and (b) permanently, if the
+     copyright holder fails to notify you of the violation by some
+     reasonable means prior to 60 days after the cessation.
+
+     Moreover, your license from a particular copyright holder is
+     reinstated permanently if the copyright holder notifies you of the
+     violation by some reasonable means, this is the first time you have
+     received notice of violation of this License (for any work) from
+     that copyright holder, and you cure the violation prior to 30 days
+     after your receipt of the notice.
+
+     Termination of your rights under this section does not terminate
+     the licenses of parties who have received copies or rights from you
+     under this License.  If your rights have been terminated and not
+     permanently reinstated, you do not qualify to receive new licenses
+     for the same material under section 10.
+
+  9. Acceptance Not Required for Having Copies.
+
+     You are not required to accept this License in order to receive or
+     run a copy of the Program.  Ancillary propagation of a covered work
+     occurring solely as a consequence of using peer-to-peer
+     transmission to receive a copy likewise does not require
+     acceptance.  However, nothing other than this License grants you
+     permission to propagate or modify any covered work.  These actions
+     infringe copyright if you do not accept this License.  Therefore,
+     by modifying or propagating a covered work, you indicate your
+     acceptance of this License to do so.
+
+  10. Automatic Licensing of Downstream Recipients.
+
+     Each time you convey a covered work, the recipient automatically
+     receives a license from the original licensors, to run, modify and
+     propagate that work, subject to this License.  You are not
+     responsible for enforcing compliance by third parties with this
+     License.
+
+     An "entity transaction" is a transaction transferring control of an
+     organization, or substantially all assets of one, or subdividing an
+     organization, or merging organizations.  If propagation of a
+     covered work results from an entity transaction, each party to that
+     transaction who receives a copy of the work also receives whatever
+     licenses to the work the party's predecessor in interest had or
+     could give under the previous paragraph, plus a right to possession
+     of the Corresponding Source of the work from the predecessor in
+     interest, if the predecessor has it or can get it with reasonable
+     efforts.
+
+     You may not impose any further restrictions on the exercise of the
+     rights granted or affirmed under this License.  For example, you
+     may not impose a license fee, royalty, or other charge for exercise
+     of rights granted under this License, and you may not initiate
+     litigation (including a cross-claim or counterclaim in a lawsuit)
+     alleging that any patent claim is infringed by making, using,
+     selling, offering for sale, or importing the Program or any portion
+     of it.
+
+  11. Patents.
+
+     A "contributor" is a copyright holder who authorizes use under this
+     License of the Program or a work on which the Program is based.
+     The work thus licensed is called the contributor's "contributor
+     version".
+
+     A contributor's "essential patent claims" are all patent claims
+     owned or controlled by the contributor, whether already acquired or
+     hereafter acquired, that would be infringed by some manner,
+     permitted by this License, of making, using, or selling its
+     contributor version, but do not include claims that would be
+     infringed only as a consequence of further modification of the
+     contributor version.  For purposes of this definition, "control"
+     includes the right to grant patent sublicenses in a manner
+     consistent with the requirements of this License.
+
+     Each contributor grants you a non-exclusive, worldwide,
+     royalty-free patent license under the contributor's essential
+     patent claims, to make, use, sell, offer for sale, import and
+     otherwise run, modify and propagate the contents of its contributor
+     version.
+
+     In the following three paragraphs, a "patent license" is any
+     express agreement or commitment, however denominated, not to
+     enforce a patent (such as an express permission to practice a
+     patent or covenant not to sue for patent infringement).  To "grant"
+     such a patent license to a party means to make such an agreement or
+     commitment not to enforce a patent against the party.
+
+     If you convey a covered work, knowingly relying on a patent
+     license, and the Corresponding Source of the work is not available
+     for anyone to copy, free of charge and under the terms of this
+     License, through a publicly available network server or other
+     readily accessible means, then you must either (1) cause the
+     Corresponding Source to be so available, or (2) arrange to deprive
+     yourself of the benefit of the patent license for this particular
+     work, or (3) arrange, in a manner consistent with the requirements
+     of this License, to extend the patent license to downstream
+     recipients.  "Knowingly relying" means you have actual knowledge
+     that, but for the patent license, your conveying the covered work
+     in a country, or your recipient's use of the covered work in a
+     country, would infringe one or more identifiable patents in that
+     country that you have reason to believe are valid.
+
+     If, pursuant to or in connection with a single transaction or
+     arrangement, you convey, or propagate by procuring conveyance of, a
+     covered work, and grant a patent license to some of the parties
+     receiving the covered work authorizing them to use, propagate,
+     modify or convey a specific copy of the covered work, then the
+     patent license you grant is automatically extended to all
+     recipients of the covered work and works based on it.
+
+     A patent license is "discriminatory" if it does not include within
+     the scope of its coverage, prohibits the exercise of, or is
+     conditioned on the non-exercise of one or more of the rights that
+     are specifically granted under this License.  You may not convey a
+     covered work if you are a party to an arrangement with a third
+     party that is in the business of distributing software, under which
+     you make payment to the third party based on the extent of your
+     activity of conveying the work, and under which the third party
+     grants, to any of the parties who would receive the covered work
+     from you, a discriminatory patent license (a) in connection with
+     copies of the covered work conveyed by you (or copies made from
+     those copies), or (b) primarily for and in connection with specific
+     products or compilations that contain the covered work, unless you
+     entered into that arrangement, or that patent license was granted,
+     prior to 28 March 2007.
+
+     Nothing in this License shall be construed as excluding or limiting
+     any implied license or other defenses to infringement that may
+     otherwise be available to you under applicable patent law.
+
+  12. No Surrender of Others' Freedom.
+
+     If conditions are imposed on you (whether by court order, agreement
+     or otherwise) that contradict the conditions of this License, they
+     do not excuse you from the conditions of this License.  If you
+     cannot convey a covered work so as to satisfy simultaneously your
+     obligations under this License and any other pertinent obligations,
+     then as a consequence you may not convey it at all.  For example,
+     if you agree to terms that obligate you to collect a royalty for
+     further conveying from those to whom you convey the Program, the
+     only way you could satisfy both those terms and this License would
+     be to refrain entirely from conveying the Program.
+
+  13. Use with the GNU Affero General Public License.
+
+     Notwithstanding any other provision of this License, you have
+     permission to link or combine any covered work with a work licensed
+     under version 3 of the GNU Affero General Public License into a
+     single combined work, and to convey the resulting work.  The terms
+     of this License will continue to apply to the part which is the
+     covered work, but the special requirements of the GNU Affero
+     General Public License, section 13, concerning interaction through
+     a network will apply to the combination as such.
+
+  14. Revised Versions of this License.
+
+     The Free Software Foundation may publish revised and/or new
+     versions of the GNU General Public License from time to time.  Such
+     new versions will be similar in spirit to the present version, but
+     may differ in detail to address new problems or concerns.
+
+     Each version is given a distinguishing version number.  If the
+     Program specifies that a certain numbered version of the GNU
+     General Public License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that numbered version or of any later version published by the Free
+     Software Foundation.  If the Program does not specify a version
+     number of the GNU General Public License, you may choose any
+     version ever published by the Free Software Foundation.
+
+     If the Program specifies that a proxy can decide which future
+     versions of the GNU General Public License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Program.
+
+     Later license versions may give you additional or different
+     permissions.  However, no additional obligations are imposed on any
+     author or copyright holder as a result of your choosing to follow a
+     later version.
+
+  15. Disclaimer of Warranty.
+
+     THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+     APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE
+     COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM "AS IS"
+     WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED,
+     INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
+     MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE
+     RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU.
+     SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL
+     NECESSARY SERVICING, REPAIR OR CORRECTION.
+
+  16. Limitation of Liability.
+
+     IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN
+     WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES
+     AND/OR CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR
+     DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR
+     CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE
+     THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA
+     BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD
+     PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER
+     PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF
+     THE POSSIBILITY OF SUCH DAMAGES.
+
+  17. Interpretation of Sections 15 and 16.
+
+     If the disclaimer of warranty and limitation of liability provided
+     above cannot be given local legal effect according to their terms,
+     reviewing courts shall apply local law that most closely
+     approximates an absolute waiver of all civil liability in
+     connection with the Program, unless a warranty or assumption of
+     liability accompanies a copy of the Program in return for a fee.
+
+END OF TERMS AND CONDITIONS
+===========================
+
+How to Apply These Terms to Your New Programs
+=============================================
+
+If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+
+   To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least the
+"copyright" line and a pointer to where the full notice is found.
+
+     ONE LINE TO GIVE THE PROGRAM'S NAME AND A BRIEF IDEA OF WHAT IT DOES.
+     Copyright (C) YEAR NAME OF AUTHOR
+
+     This program is free software: you can redistribute it and/or modify
+     it under the terms of the GNU General Public License as published by
+     the Free Software Foundation, either version 3 of the License, or (at
+     your option) any later version.
+
+     This program is distributed in the hope that it will be useful, but
+     WITHOUT ANY WARRANTY; without even the implied warranty of
+     MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+     General Public License for more details.
+
+     You should have received a copy of the GNU General Public License
+     along with this program.  If not, see <http://www.gnu.org/licenses/>.
+
+   Also add information on how to contact you by electronic and paper
+mail.
+
+   If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+
+     PROGRAM Copyright (C) YEAR NAME OF AUTHOR
+     This program comes with ABSOLUTELY NO WARRANTY; for details type 'show w'.
+     This is free software, and you are welcome to redistribute it
+     under certain conditions; type 'show c' for details.
+
+   The hypothetical commands 'show w' and 'show c' should show the
+appropriate parts of the General Public License.  Of course, your
+program's commands might be different; for a GUI interface, you would
+use an "about box".
+
+   You should also get your employer (if you work as a programmer) or
+school, if any, to sign a "copyright disclaimer" for the program, if
+necessary.  For more information on this, and how to apply and follow
+the GNU GPL, see <http://www.gnu.org/licenses/>.
+
+   The GNU General Public License does not permit incorporating your
+program into proprietary programs.  If your program is a subroutine
+library, you may consider it more useful to permit linking proprietary
+applications with the library.  If this is what you want to do, use the
+GNU Lesser General Public License instead of this License.  But first,
+please read <http://www.gnu.org/philosophy/why-not-lgpl.html>.
+
+
+File: gcj.info,  Node: GNU Free Documentation License,  Next: Invoking gcj,  Prev: Copying,  Up: Top
+
+GNU Free Documentation License
+******************************
+
+                     Version 1.3, 3 November 2008
+
+     Copyright (C) 2000, 2001, 2002, 2007, 2008 Free Software Foundation, Inc.
+     <http://fsf.org/>
+
+     Everyone is permitted to copy and distribute verbatim copies
+     of this license document, but changing it is not allowed.
+
+  0. PREAMBLE
+
+     The purpose of this License is to make a manual, textbook, or other
+     functional and useful document "free" in the sense of freedom: to
+     assure everyone the effective freedom to copy and redistribute it,
+     with or without modifying it, either commercially or
+     noncommercially.  Secondarily, this License preserves for the
+     author and publisher a way to get credit for their work, while not
+     being considered responsible for modifications made by others.
+
+     This License is a kind of "copyleft", which means that derivative
+     works of the document must themselves be free in the same sense.
+     It complements the GNU General Public License, which is a copyleft
+     license designed for free software.
+
+     We have designed this License in order to use it for manuals for
+     free software, because free software needs free documentation: a
+     free program should come with manuals providing the same freedoms
+     that the software does.  But this License is not limited to
+     software manuals; it can be used for any textual work, regardless
+     of subject matter or whether it is published as a printed book.  We
+     recommend this License principally for works whose purpose is
+     instruction or reference.
+
+  1. APPLICABILITY AND DEFINITIONS
+
+     This License applies to any manual or other work, in any medium,
+     that contains a notice placed by the copyright holder saying it can
+     be distributed under the terms of this License.  Such a notice
+     grants a world-wide, royalty-free license, unlimited in duration,
+     to use that work under the conditions stated herein.  The
+     "Document", below, refers to any such manual or work.  Any member
+     of the public is a licensee, and is addressed as "you".  You accept
+     the license if you copy, modify or distribute the work in a way
+     requiring permission under copyright law.
+
+     A "Modified Version" of the Document means any work containing the
+     Document or a portion of it, either copied verbatim, or with
+     modifications and/or translated into another language.
+
+     A "Secondary Section" is a named appendix or a front-matter section
+     of the Document that deals exclusively with the relationship of the
+     publishers or authors of the Document to the Document's overall
+     subject (or to related matters) and contains nothing that could
+     fall directly within that overall subject.  (Thus, if the Document
+     is in part a textbook of mathematics, a Secondary Section may not
+     explain any mathematics.)  The relationship could be a matter of
+     historical connection with the subject or with related matters, or
+     of legal, commercial, philosophical, ethical or political position
+     regarding them.
+
+     The "Invariant Sections" are certain Secondary Sections whose
+     titles are designated, as being those of Invariant Sections, in the
+     notice that says that the Document is released under this License.
+     If a section does not fit the above definition of Secondary then it
+     is not allowed to be designated as Invariant.  The Document may
+     contain zero Invariant Sections.  If the Document does not identify
+     any Invariant Sections then there are none.
+
+     The "Cover Texts" are certain short passages of text that are
+     listed, as Front-Cover Texts or Back-Cover Texts, in the notice
+     that says that the Document is released under this License.  A
+     Front-Cover Text may be at most 5 words, and a Back-Cover Text may
+     be at most 25 words.
+
+     A "Transparent" copy of the Document means a machine-readable copy,
+     represented in a format whose specification is available to the
+     general public, that is suitable for revising the document
+     straightforwardly with generic text editors or (for images composed
+     of pixels) generic paint programs or (for drawings) some widely
+     available drawing editor, and that is suitable for input to text
+     formatters or for automatic translation to a variety of formats
+     suitable for input to text formatters.  A copy made in an otherwise
+     Transparent file format whose markup, or absence of markup, has
+     been arranged to thwart or discourage subsequent modification by
+     readers is not Transparent.  An image format is not Transparent if
+     used for any substantial amount of text.  A copy that is not
+     "Transparent" is called "Opaque".
+
+     Examples of suitable formats for Transparent copies include plain
+     ASCII without markup, Texinfo input format, LaTeX input format,
+     SGML or XML using a publicly available DTD, and standard-conforming
+     simple HTML, PostScript or PDF designed for human modification.
+     Examples of transparent image formats include PNG, XCF and JPG.
+     Opaque formats include proprietary formats that can be read and
+     edited only by proprietary word processors, SGML or XML for which
+     the DTD and/or processing tools are not generally available, and
+     the machine-generated HTML, PostScript or PDF produced by some word
+     processors for output purposes only.
+
+     The "Title Page" means, for a printed book, the title page itself,
+     plus such following pages as are needed to hold, legibly, the
+     material this License requires to appear in the title page.  For
+     works in formats which do not have any title page as such, "Title
+     Page" means the text near the most prominent appearance of the
+     work's title, preceding the beginning of the body of the text.
+
+     The "publisher" means any person or entity that distributes copies
+     of the Document to the public.
+
+     A section "Entitled XYZ" means a named subunit of the Document
+     whose title either is precisely XYZ or contains XYZ in parentheses
+     following text that translates XYZ in another language.  (Here XYZ
+     stands for a specific section name mentioned below, such as
+     "Acknowledgements", "Dedications", "Endorsements", or "History".)
+     To "Preserve the Title" of such a section when you modify the
+     Document means that it remains a section "Entitled XYZ" according
+     to this definition.
+
+     The Document may include Warranty Disclaimers next to the notice
+     which states that this License applies to the Document.  These
+     Warranty Disclaimers are considered to be included by reference in
+     this License, but only as regards disclaiming warranties: any other
+     implication that these Warranty Disclaimers may have is void and
+     has no effect on the meaning of this License.
+
+  2. VERBATIM COPYING
+
+     You may copy and distribute the Document in any medium, either
+     commercially or noncommercially, provided that this License, the
+     copyright notices, and the license notice saying this License
+     applies to the Document are reproduced in all copies, and that you
+     add no other conditions whatsoever to those of this License.  You
+     may not use technical measures to obstruct or control the reading
+     or further copying of the copies you make or distribute.  However,
+     you may accept compensation in exchange for copies.  If you
+     distribute a large enough number of copies you must also follow the
+     conditions in section 3.
+
+     You may also lend copies, under the same conditions stated above,
+     and you may publicly display copies.
+
+  3. COPYING IN QUANTITY
+
+     If you publish printed copies (or copies in media that commonly
+     have printed covers) of the Document, numbering more than 100, and
+     the Document's license notice requires Cover Texts, you must
+     enclose the copies in covers that carry, clearly and legibly, all
+     these Cover Texts: Front-Cover Texts on the front cover, and
+     Back-Cover Texts on the back cover.  Both covers must also clearly
+     and legibly identify you as the publisher of these copies.  The
+     front cover must present the full title with all words of the title
+     equally prominent and visible.  You may add other material on the
+     covers in addition.  Copying with changes limited to the covers, as
+     long as they preserve the title of the Document and satisfy these
+     conditions, can be treated as verbatim copying in other respects.
+
+     If the required texts for either cover are too voluminous to fit
+     legibly, you should put the first ones listed (as many as fit
+     reasonably) on the actual cover, and continue the rest onto
+     adjacent pages.
+
+     If you publish or distribute Opaque copies of the Document
+     numbering more than 100, you must either include a machine-readable
+     Transparent copy along with each Opaque copy, or state in or with
+     each Opaque copy a computer-network location from which the general
+     network-using public has access to download using public-standard
+     network protocols a complete Transparent copy of the Document, free
+     of added material.  If you use the latter option, you must take
+     reasonably prudent steps, when you begin distribution of Opaque
+     copies in quantity, to ensure that this Transparent copy will
+     remain thus accessible at the stated location until at least one
+     year after the last time you distribute an Opaque copy (directly or
+     through your agents or retailers) of that edition to the public.
+
+     It is requested, but not required, that you contact the authors of
+     the Document well before redistributing any large number of copies,
+     to give them a chance to provide you with an updated version of the
+     Document.
+
+  4. MODIFICATIONS
+
+     You may copy and distribute a Modified Version of the Document
+     under the conditions of sections 2 and 3 above, provided that you
+     release the Modified Version under precisely this License, with the
+     Modified Version filling the role of the Document, thus licensing
+     distribution and modification of the Modified Version to whoever
+     possesses a copy of it.  In addition, you must do these things in
+     the Modified Version:
+
+       A. Use in the Title Page (and on the covers, if any) a title
+          distinct from that of the Document, and from those of previous
+          versions (which should, if there were any, be listed in the
+          History section of the Document).  You may use the same title
+          as a previous version if the original publisher of that
+          version gives permission.
+
+       B. List on the Title Page, as authors, one or more persons or
+          entities responsible for authorship of the modifications in
+          the Modified Version, together with at least five of the
+          principal authors of the Document (all of its principal
+          authors, if it has fewer than five), unless they release you
+          from this requirement.
+
+       C. State on the Title page the name of the publisher of the
+          Modified Version, as the publisher.
+
+       D. Preserve all the copyright notices of the Document.
+
+       E. Add an appropriate copyright notice for your modifications
+          adjacent to the other copyright notices.
+
+       F. Include, immediately after the copyright notices, a license
+          notice giving the public permission to use the Modified
+          Version under the terms of this License, in the form shown in
+          the Addendum below.
+
+       G. Preserve in that license notice the full lists of Invariant
+          Sections and required Cover Texts given in the Document's
+          license notice.
+
+       H. Include an unaltered copy of this License.
+
+       I. Preserve the section Entitled "History", Preserve its Title,
+          and add to it an item stating at least the title, year, new
+          authors, and publisher of the Modified Version as given on the
+          Title Page.  If there is no section Entitled "History" in the
+          Document, create one stating the title, year, authors, and
+          publisher of the Document as given on its Title Page, then add
+          an item describing the Modified Version as stated in the
+          previous sentence.
+
+       J. Preserve the network location, if any, given in the Document
+          for public access to a Transparent copy of the Document, and
+          likewise the network locations given in the Document for
+          previous versions it was based on.  These may be placed in the
+          "History" section.  You may omit a network location for a work
+          that was published at least four years before the Document
+          itself, or if the original publisher of the version it refers
+          to gives permission.
+
+       K. For any section Entitled "Acknowledgements" or "Dedications",
+          Preserve the Title of the section, and preserve in the section
+          all the substance and tone of each of the contributor
+          acknowledgements and/or dedications given therein.
+
+       L. Preserve all the Invariant Sections of the Document, unaltered
+          in their text and in their titles.  Section numbers or the
+          equivalent are not considered part of the section titles.
+
+       M. Delete any section Entitled "Endorsements".  Such a section
+          may not be included in the Modified Version.
+
+       N. Do not retitle any existing section to be Entitled
+          "Endorsements" or to conflict in title with any Invariant
+          Section.
+
+       O. Preserve any Warranty Disclaimers.
+
+     If the Modified Version includes new front-matter sections or
+     appendices that qualify as Secondary Sections and contain no
+     material copied from the Document, you may at your option designate
+     some or all of these sections as invariant.  To do this, add their
+     titles to the list of Invariant Sections in the Modified Version's
+     license notice.  These titles must be distinct from any other
+     section titles.
+
+     You may add a section Entitled "Endorsements", provided it contains
+     nothing but endorsements of your Modified Version by various
+     parties--for example, statements of peer review or that the text
+     has been approved by an organization as the authoritative
+     definition of a standard.
+
+     You may add a passage of up to five words as a Front-Cover Text,
+     and a passage of up to 25 words as a Back-Cover Text, to the end of
+     the list of Cover Texts in the Modified Version.  Only one passage
+     of Front-Cover Text and one of Back-Cover Text may be added by (or
+     through arrangements made by) any one entity.  If the Document
+     already includes a cover text for the same cover, previously added
+     by you or by arrangement made by the same entity you are acting on
+     behalf of, you may not add another; but you may replace the old
+     one, on explicit permission from the previous publisher that added
+     the old one.
+
+     The author(s) and publisher(s) of the Document do not by this
+     License give permission to use their names for publicity for or to
+     assert or imply endorsement of any Modified Version.
+
+  5. COMBINING DOCUMENTS
+
+     You may combine the Document with other documents released under
+     this License, under the terms defined in section 4 above for
+     modified versions, provided that you include in the combination all
+     of the Invariant Sections of all of the original documents,
+     unmodified, and list them all as Invariant Sections of your
+     combined work in its license notice, and that you preserve all
+     their Warranty Disclaimers.
+
+     The combined work need only contain one copy of this License, and
+     multiple identical Invariant Sections may be replaced with a single
+     copy.  If there are multiple Invariant Sections with the same name
+     but different contents, make the title of each such section unique
+     by adding at the end of it, in parentheses, the name of the
+     original author or publisher of that section if known, or else a
+     unique number.  Make the same adjustment to the section titles in
+     the list of Invariant Sections in the license notice of the
+     combined work.
+
+     In the combination, you must combine any sections Entitled
+     "History" in the various original documents, forming one section
+     Entitled "History"; likewise combine any sections Entitled
+     "Acknowledgements", and any sections Entitled "Dedications".  You
+     must delete all sections Entitled "Endorsements."
+
+  6. COLLECTIONS OF DOCUMENTS
+
+     You may make a collection consisting of the Document and other
+     documents released under this License, and replace the individual
+     copies of this License in the various documents with a single copy
+     that is included in the collection, provided that you follow the
+     rules of this License for verbatim copying of each of the documents
+     in all other respects.
+
+     You may extract a single document from such a collection, and
+     distribute it individually under this License, provided you insert
+     a copy of this License into the extracted document, and follow this
+     License in all other respects regarding verbatim copying of that
+     document.
+
+  7. AGGREGATION WITH INDEPENDENT WORKS
+
+     A compilation of the Document or its derivatives with other
+     separate and independent documents or works, in or on a volume of a
+     storage or distribution medium, is called an "aggregate" if the
+     copyright resulting from the compilation is not used to limit the
+     legal rights of the compilation's users beyond what the individual
+     works permit.  When the Document is included in an aggregate, this
+     License does not apply to the other works in the aggregate which
+     are not themselves derivative works of the Document.
+
+     If the Cover Text requirement of section 3 is applicable to these
+     copies of the Document, then if the Document is less than one half
+     of the entire aggregate, the Document's Cover Texts may be placed
+     on covers that bracket the Document within the aggregate, or the
+     electronic equivalent of covers if the Document is in electronic
+     form.  Otherwise they must appear on printed covers that bracket
+     the whole aggregate.
+
+  8. TRANSLATION
+
+     Translation is considered a kind of modification, so you may
+     distribute translations of the Document under the terms of section
+     4.  Replacing Invariant Sections with translations requires special
+     permission from their copyright holders, but you may include
+     translations of some or all Invariant Sections in addition to the
+     original versions of these Invariant Sections.  You may include a
+     translation of this License, and all the license notices in the
+     Document, and any Warranty Disclaimers, provided that you also
+     include the original English version of this License and the
+     original versions of those notices and disclaimers.  In case of a
+     disagreement between the translation and the original version of
+     this License or a notice or disclaimer, the original version will
+     prevail.
+
+     If a section in the Document is Entitled "Acknowledgements",
+     "Dedications", or "History", the requirement (section 4) to
+     Preserve its Title (section 1) will typically require changing the
+     actual title.
+
+  9. TERMINATION
+
+     You may not copy, modify, sublicense, or distribute the Document
+     except as expressly provided under this License.  Any attempt
+     otherwise to copy, modify, sublicense, or distribute it is void,
+     and will automatically terminate your rights under this License.
+
+     However, if you cease all violation of this License, then your
+     license from a particular copyright holder is reinstated (a)
+     provisionally, unless and until the copyright holder explicitly and
+     finally terminates your license, and (b) permanently, if the
+     copyright holder fails to notify you of the violation by some
+     reasonable means prior to 60 days after the cessation.
+
+     Moreover, your license from a particular copyright holder is
+     reinstated permanently if the copyright holder notifies you of the
+     violation by some reasonable means, this is the first time you have
+     received notice of violation of this License (for any work) from
+     that copyright holder, and you cure the violation prior to 30 days
+     after your receipt of the notice.
+
+     Termination of your rights under this section does not terminate
+     the licenses of parties who have received copies or rights from you
+     under this License.  If your rights have been terminated and not
+     permanently reinstated, receipt of a copy of some or all of the
+     same material does not give you any rights to use it.
+
+  10. FUTURE REVISIONS OF THIS LICENSE
+
+     The Free Software Foundation may publish new, revised versions of
+     the GNU Free Documentation License from time to time.  Such new
+     versions will be similar in spirit to the present version, but may
+     differ in detail to address new problems or concerns.  See
+     <http://www.gnu.org/copyleft/>.
+
+     Each version of the License is given a distinguishing version
+     number.  If the Document specifies that a particular numbered
+     version of this License "or any later version" applies to it, you
+     have the option of following the terms and conditions either of
+     that specified version or of any later version that has been
+     published (not as a draft) by the Free Software Foundation.  If the
+     Document does not specify a version number of this License, you may
+     choose any version ever published (not as a draft) by the Free
+     Software Foundation.  If the Document specifies that a proxy can
+     decide which future versions of this License can be used, that
+     proxy's public statement of acceptance of a version permanently
+     authorizes you to choose that version for the Document.
+
+  11. RELICENSING
+
+     "Massive Multiauthor Collaboration Site" (or "MMC Site") means any
+     World Wide Web server that publishes copyrightable works and also
+     provides prominent facilities for anybody to edit those works.  A
+     public wiki that anybody can edit is an example of such a server.
+     A "Massive Multiauthor Collaboration" (or "MMC") contained in the
+     site means any set of copyrightable works thus published on the MMC
+     site.
+
+     "CC-BY-SA" means the Creative Commons Attribution-Share Alike 3.0
+     license published by Creative Commons Corporation, a not-for-profit
+     corporation with a principal place of business in San Francisco,
+     California, as well as future copyleft versions of that license
+     published by that same organization.
+
+     "Incorporate" means to publish or republish a Document, in whole or
+     in part, as part of another Document.
+
+     An MMC is "eligible for relicensing" if it is licensed under this
+     License, and if all works that were first published under this
+     License somewhere other than this MMC, and subsequently
+     incorporated in whole or in part into the MMC, (1) had no cover
+     texts or invariant sections, and (2) were thus incorporated prior
+     to November 1, 2008.
+
+     The operator of an MMC Site may republish an MMC contained in the
+     site under CC-BY-SA on the same site at any time before August 1,
+     2009, provided the MMC is eligible for relicensing.
+
+ADDENDUM: How to use this License for your documents
+====================================================
+
+To use this License in a document you have written, include a copy of
+the License in the document and put the following copyright and license
+notices just after the title page:
+
+       Copyright (C)  YEAR  YOUR NAME.
+       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, no Front-Cover Texts, and no Back-Cover
+       Texts.  A copy of the license is included in the section entitled ``GNU
+       Free Documentation License''.
+
+   If you have Invariant Sections, Front-Cover Texts and Back-Cover
+Texts, replace the "with...Texts."  line with this:
+
+         with the Invariant Sections being LIST THEIR TITLES, with
+         the Front-Cover Texts being LIST, and with the Back-Cover Texts
+         being LIST.
+
+   If you have Invariant Sections without Cover Texts, or some other
+combination of the three, merge those two alternatives to suit the
+situation.
+
+   If your document contains nontrivial examples of program code, we
+recommend releasing these examples in parallel under your choice of free
+software license, such as the GNU General Public License, to permit
+their use in free software.
+
+
+File: gcj.info,  Node: Invoking gcj,  Next: Compatibility,  Prev: GNU Free Documentation License,  Up: Top
+
+1 Invoking gcj
+**************
+
+As 'gcj' is just another front end to 'gcc', it supports many of the
+same options as gcc.  *Note Option Summary: (gcc)Option Summary.  This
+manual only documents the options specific to 'gcj'.
+
+* Menu:
+
+* Input and output files::
+* Input Options::               How gcj finds files
+* Encodings::                   Options controlling source file encoding
+* Warnings::                    Options controlling warnings specific to gcj
+* Linking::                     Options for making an executable
+* Code Generation::             Options controlling the output of gcj
+* Configure-time Options::      Options you won't use
+
+
+File: gcj.info,  Node: Input and output files,  Next: Input Options,  Up: Invoking gcj
+
+1.1 Input and output files
+==========================
+
+A 'gcj' command is like a 'gcc' command, in that it consists of a number
+of options and file names.  The following kinds of input file names are
+supported:
+
+'FILE.java'
+     Java source files.
+'FILE.class'
+     Java bytecode files.
+'FILE.zip'
+'FILE.jar'
+     An archive containing one or more '.class' files, all of which are
+     compiled.  The archive may be compressed.  Files in an archive
+     which don't end with '.class' are treated as resource files; they
+     are compiled into the resulting object file as 'core:' URLs.
+'@FILE'
+     A file containing a whitespace-separated list of input file names.
+     (Currently, these must all be '.java' source files, but that may
+     change.)  Each named file is compiled, just as if it had been on
+     the command line.
+'LIBRARY.a'
+'LIBRARY.so'
+'-lLIBNAME'
+     Libraries to use when linking.  See the 'gcc' manual.
+
+   You can specify more than one input file on the 'gcj' command line,
+in which case they will all be compiled.  If you specify a '-o FILENAME'
+option, all the input files will be compiled together, producing a
+single output file, named FILENAME.  This is allowed even when using
+'-S' or '-c', but not when using '-C' or '--resource'.  (This is an
+extension beyond the what plain 'gcc' allows.)  (If more than one input
+file is specified, all must currently be '.java' files, though we hope
+to fix this.)
+
+
+File: gcj.info,  Node: Input Options,  Next: Encodings,  Prev: Input and output files,  Up: Invoking gcj
+
+1.2 Input Options
+=================
+
+'gcj' has options to control where it looks to find files it needs.  For
+instance, 'gcj' might need to load a class that is referenced by the
+file it has been asked to compile.  Like other compilers for the Java
+language, 'gcj' has a notion of a "class path".  There are several
+options and environment variables which can be used to manipulate the
+class path.  When 'gcj' looks for a given class, it searches the class
+path looking for matching '.class' or '.java' file.  'gcj' comes with a
+built-in class path which points at the installed 'libgcj.jar', a file
+which contains all the standard classes.
+
+   In the text below, a directory or path component can refer either to
+an actual directory on the filesystem, or to a '.zip' or '.jar' file,
+which 'gcj' will search as if it is a directory.
+
+'-IDIR'
+     All directories specified by '-I' are kept in order and prepended
+     to the class path constructed from all the other options.  Unless
+     compatibility with tools like 'javac' is important, we recommend
+     always using '-I' instead of the other options for manipulating the
+     class path.
+
+'--classpath=PATH'
+     This sets the class path to PATH, a colon-separated list of paths
+     (on Windows-based systems, a semicolon-separate list of paths).
+     This does not override the builtin ("boot") search path.
+
+'--CLASSPATH=PATH'
+     Deprecated synonym for '--classpath'.
+
+'--bootclasspath=PATH'
+     Where to find the standard builtin classes, such as
+     'java.lang.String'.
+
+'--extdirs=PATH'
+     For each directory in the PATH, place the contents of that
+     directory at the end of the class path.
+
+'CLASSPATH'
+     This is an environment variable which holds a list of paths.
+
+   The final class path is constructed like so:
+
+   * First come all directories specified via '-I'.
+
+   * If '--classpath' is specified, its value is appended.  Otherwise,
+     if the 'CLASSPATH' environment variable is specified, then its
+     value is appended.  Otherwise, the current directory ('"."') is
+     appended.
+
+   * If '--bootclasspath' was specified, append its value.  Otherwise,
+     append the built-in system directory, 'libgcj.jar'.
+
+   * Finally, if '--extdirs' was specified, append the contents of the
+     specified directories at the end of the class path.  Otherwise,
+     append the contents of the built-in extdirs at
+     '$(prefix)/share/java/ext'.
+
+   The classfile built by 'gcj' for the class 'java.lang.Object' (and
+placed in 'libgcj.jar') contains a special zero length attribute
+'gnu.gcj.gcj-compiled'.  The compiler looks for this attribute when
+loading 'java.lang.Object' and will report an error if it isn't found,
+unless it compiles to bytecode (the option
+'-fforce-classes-archive-check' can be used to override this behavior in
+this particular case.)
+
+'-fforce-classes-archive-check'
+     This forces the compiler to always check for the special zero
+     length attribute 'gnu.gcj.gcj-compiled' in 'java.lang.Object' and
+     issue an error if it isn't found.
+
+'-fsource=VERSION'
+     This option is used to choose the source version accepted by 'gcj'.
+     The default is '1.5'.
+
+
+File: gcj.info,  Node: Encodings,  Next: Warnings,  Prev: Input Options,  Up: Invoking gcj
+
+1.3 Encodings
+=============
+
+The Java programming language uses Unicode throughout.  In an effort to
+integrate well with other locales, 'gcj' allows '.java' files to be
+written using almost any encoding.  'gcj' knows how to convert these
+encodings into its internal encoding at compile time.
+
+   You can use the '--encoding=NAME' option to specify an encoding (of a
+particular character set) to use for source files.  If this is not
+specified, the default encoding comes from your current locale.  If your
+host system has insufficient locale support, then 'gcj' assumes the
+default encoding to be the 'UTF-8' encoding of Unicode.
+
+   To implement '--encoding', 'gcj' simply uses the host platform's
+'iconv' conversion routine.  This means that in practice 'gcj' is
+limited by the capabilities of the host platform.
+
+   The names allowed for the argument '--encoding' vary from platform to
+platform (since they are not standardized anywhere).  However, 'gcj'
+implements the encoding named 'UTF-8' internally, so if you choose to
+use this for your source files you can be assured that it will work on
+every host.
+
+
+File: gcj.info,  Node: Warnings,  Next: Linking,  Prev: Encodings,  Up: Invoking gcj
+
+1.4 Warnings
+============
+
+'gcj' implements several warnings.  As with other generic 'gcc'
+warnings, if an option of the form '-Wfoo' enables a warning, then
+'-Wno-foo' will disable it.  Here we've chosen to document the form of
+the warning which will have an effect - the default being the opposite
+of what is listed.
+
+'-Wredundant-modifiers'
+     With this flag, 'gcj' will warn about redundant modifiers.  For
+     instance, it will warn if an interface method is declared 'public'.
+
+'-Wextraneous-semicolon'
+     This causes 'gcj' to warn about empty statements.  Empty statements
+     have been deprecated.
+
+'-Wno-out-of-date'
+     This option will cause 'gcj' not to warn when a source file is
+     newer than its matching class file.  By default 'gcj' will warn
+     about this.
+
+'-Wno-deprecated'
+     Warn if a deprecated class, method, or field is referred to.
+
+'-Wunused'
+     This is the same as 'gcc''s '-Wunused'.
+
+'-Wall'
+     This is the same as '-Wredundant-modifiers -Wextraneous-semicolon
+     -Wunused'.
+
+
+File: gcj.info,  Node: Linking,  Next: Code Generation,  Prev: Warnings,  Up: Invoking gcj
+
+1.5 Linking
+===========
+
+To turn a Java application into an executable program, you need to link
+it with the needed libraries, just as for C or C++.  The linker by
+default looks for a global function named 'main'.  Since Java does not
+have global functions, and a collection of Java classes may have more
+than one class with a 'main' method, you need to let the linker know
+which of those 'main' methods it should invoke when starting the
+application.  You can do that in any of these ways:
+
+   * Specify the class containing the desired 'main' method when you
+     link the application, using the '--main' flag, described below.
+   * Link the Java package(s) into a shared library (dll) rather than an
+     executable.  Then invoke the application using the 'gij' program,
+     making sure that 'gij' can find the libraries it needs.
+   * Link the Java packages(s) with the flag '-lgij', which links in the
+     'main' routine from the 'gij' command.  This allows you to select
+     the class whose 'main' method you want to run when you run the
+     application.  You can also use other 'gij' flags, such as '-D'
+     flags to set properties.  Using the '-lgij' library (rather than
+     the 'gij' program of the previous mechanism) has some advantages:
+     it is compatible with static linking, and does not require
+     configuring or installing libraries.
+
+   These 'gij' options relate to linking an executable:
+
+'--main=CLASSNAME'
+     This option is used when linking to specify the name of the class
+     whose 'main' method should be invoked when the resulting executable
+     is run.
+
+'-DNAME[=VALUE]'
+     This option can only be used with '--main'.  It defines a system
+     property named NAME with value VALUE.  If VALUE is not specified
+     then it defaults to the empty string.  These system properties are
+     initialized at the program's startup and can be retrieved at
+     runtime using the 'java.lang.System.getProperty' method.
+
+'-lgij'
+     Create an application whose command-line processing is that of the
+     'gij' command.
+
+     This option is an alternative to using '--main'; you cannot use
+     both.
+
+'-static-libgcj'
+     This option causes linking to be done against a static version of
+     the libgcj runtime library.  This option is only available if
+     corresponding linker support exists.
+
+     *Caution:* Static linking of libgcj may cause essential parts of
+     libgcj to be omitted.  Some parts of libgcj use reflection to load
+     classes at runtime.  Since the linker does not see these references
+     at link time, it can omit the referred to classes.  The result is
+     usually (but not always) a 'ClassNotFoundException' being thrown at
+     runtime.  Caution must be used when using this option.  For more
+     details see: <http://gcc.gnu.org/wiki/Statically%20linking%20libgcj>
+
+
+File: gcj.info,  Node: Code Generation,  Next: Configure-time Options,  Prev: Linking,  Up: Invoking gcj
+
+1.6 Code Generation
+===================
+
+In addition to the many 'gcc' options controlling code generation, 'gcj'
+has several options specific to itself.
+
+'-C'
+     This option is used to tell 'gcj' to generate bytecode ('.class'
+     files) rather than object code.
+
+'--resource RESOURCE-NAME'
+     This option is used to tell 'gcj' to compile the contents of a
+     given file to object code so it may be accessed at runtime with the
+     core protocol handler as 'core:/RESOURCE-NAME'.  Note that
+     RESOURCE-NAME is the name of the resource as found at runtime; for
+     instance, it could be used in a call to 'ResourceBundle.getBundle'.
+     The actual file name to be compiled this way must be specified
+     separately.
+
+'-ftarget=VERSION'
+     This can be used with '-C' to choose the version of bytecode
+     emitted by 'gcj'.  The default is '1.5'.  When not generating
+     bytecode, this option has no effect.
+
+'-d DIRECTORY'
+     When used with '-C', this causes all generated '.class' files to be
+     put in the appropriate subdirectory of DIRECTORY.  By default they
+     will be put in subdirectories of the current working directory.
+
+'-fno-bounds-check'
+     By default, 'gcj' generates code which checks the bounds of all
+     array indexing operations.  With this option, these checks are
+     omitted, which can improve performance for code that uses arrays
+     extensively.  Note that this can result in unpredictable behavior
+     if the code in question actually does violate array bounds
+     constraints.  It is safe to use this option if you are sure that
+     your code will never throw an 'ArrayIndexOutOfBoundsException'.
+
+'-fno-store-check'
+     Don't generate array store checks.  When storing objects into
+     arrays, a runtime check is normally generated in order to ensure
+     that the object is assignment compatible with the component type of
+     the array (which may not be known at compile-time).  With this
+     option, these checks are omitted.  This can improve performance for
+     code which stores objects into arrays frequently.  It is safe to
+     use this option if you are sure your code will never throw an
+     'ArrayStoreException'.
+
+'-fjni'
+     With 'gcj' there are two options for writing native methods: CNI
+     and JNI.  By default 'gcj' assumes you are using CNI.  If you are
+     compiling a class with native methods, and these methods are
+     implemented using JNI, then you must use '-fjni'.  This option
+     causes 'gcj' to generate stubs which will invoke the underlying JNI
+     methods.
+
+'-fno-assert'
+     Don't recognize the 'assert' keyword.  This is for compatibility
+     with older versions of the language specification.
+
+'-fno-optimize-static-class-initialization'
+     When the optimization level is greater or equal to '-O2', 'gcj'
+     will try to optimize the way calls into the runtime are made to
+     initialize static classes upon their first use (this optimization
+     isn't carried out if '-C' was specified.)  When compiling to native
+     code, '-fno-optimize-static-class-initialization' will turn this
+     optimization off, regardless of the optimization level in use.
+
+'--disable-assertions[=CLASS-OR-PACKAGE]'
+     Don't include code for checking assertions in the compiled code.
+     If '=CLASS-OR-PACKAGE' is missing disables assertion code
+     generation for all classes, unless overridden by a more specific
+     '--enable-assertions' flag.  If CLASS-OR-PACKAGE is a class name,
+     only disables generating assertion checks within the named class or
+     its inner classes.  If CLASS-OR-PACKAGE is a package name, disables
+     generating assertion checks within the named package or a
+     subpackage.
+
+     By default, assertions are enabled when generating class files or
+     when not optimizing, and disabled when generating optimized
+     binaries.
+
+'--enable-assertions[=CLASS-OR-PACKAGE]'
+     Generates code to check assertions.  The option is perhaps
+     misnamed, as you still need to turn on assertion checking at
+     run-time, and we don't support any easy way to do that.  So this
+     flag isn't very useful yet, except to partially override
+     '--disable-assertions'.
+
+'-findirect-dispatch'
+     'gcj' has a special binary compatibility ABI, which is enabled by
+     the '-findirect-dispatch' option.  In this mode, the code generated
+     by 'gcj' honors the binary compatibility guarantees in the Java
+     Language Specification, and the resulting object files do not need
+     to be directly linked against their dependencies.  Instead, all
+     dependencies are looked up at runtime.  This allows free mixing of
+     interpreted and compiled code.
+
+     Note that, at present, '-findirect-dispatch' can only be used when
+     compiling '.class' files.  It will not work when compiling from
+     source.  CNI also does not yet work with the binary compatibility
+     ABI. These restrictions will be lifted in some future release.
+
+     However, if you compile CNI code with the standard ABI, you can
+     call it from code built with the binary compatibility ABI.
+
+'-fbootstrap-classes'
+     This option can be use to tell 'libgcj' that the compiled classes
+     should be loaded by the bootstrap loader, not the system class
+     loader.  By default, if you compile a class and link it into an
+     executable, it will be treated as if it was loaded using the system
+     class loader.  This is convenient, as it means that things like
+     'Class.forName()' will search 'CLASSPATH' to find the desired
+     class.
+
+'-freduced-reflection'
+     This option causes the code generated by 'gcj' to contain a reduced
+     amount of the class meta-data used to support runtime reflection.
+     The cost of this savings is the loss of the ability to use certain
+     reflection capabilities of the standard Java runtime environment.
+     When set all meta-data except for that which is needed to obtain
+     correct runtime semantics is eliminated.
+
+     For code that does not use reflection (i.e.  serialization, RMI,
+     CORBA or call methods in the 'java.lang.reflect' package),
+     '-freduced-reflection' will result in proper operation with a
+     savings in executable code size.
+
+     JNI ('-fjni') and the binary compatibility ABI
+     ('-findirect-dispatch') do not work properly without full
+     reflection meta-data.  Because of this, it is an error to use these
+     options with '-freduced-reflection'.
+
+     *Caution:* If there is no reflection meta-data, code that uses a
+     'SecurityManager' may not work properly.  Also calling
+     'Class.forName()' may fail if the calling method has no reflection
+     meta-data.
+
+
+File: gcj.info,  Node: Configure-time Options,  Prev: Code Generation,  Up: Invoking gcj
+
+1.7 Configure-time Options
+==========================
+
+Some 'gcj' code generations options affect the resulting ABI, and so can
+only be meaningfully given when 'libgcj', the runtime package, is
+configured.  'libgcj' puts the appropriate options from this group into
+a 'spec' file which is read by 'gcj'.  These options are listed here for
+completeness; if you are using 'libgcj' then you won't want to touch
+these options.
+
+'-fuse-boehm-gc'
+     This enables the use of the Boehm GC bitmap marking code.  In
+     particular this causes 'gcj' to put an object marking descriptor
+     into each vtable.
+
+'-fhash-synchronization'
+     By default, synchronization data (the data used for 'synchronize',
+     'wait', and 'notify') is pointed to by a word in each object.  With
+     this option 'gcj' assumes that this information is stored in a hash
+     table and not in the object itself.
+
+'-fuse-divide-subroutine'
+     On some systems, a library routine is called to perform integer
+     division.  This is required to get exception handling correct when
+     dividing by zero.
+
+'-fcheck-references'
+     On some systems it's necessary to insert inline checks whenever
+     accessing an object via a reference.  On other systems you won't
+     need this because null pointer accesses are caught automatically by
+     the processor.
+
+'-fuse-atomic-builtins'
+     On some systems, GCC can generate code for built-in atomic
+     operations.  Use this option to force gcj to use these builtins
+     when compiling Java code.  Where this capability is present it
+     should be automatically detected, so you won't usually need to use
+     this option.
+
+
+File: gcj.info,  Node: Compatibility,  Next: Invoking jcf-dump,  Prev: Invoking gcj,  Up: Top
+
+2 Compatibility with the Java Platform
+**************************************
+
+As we believe it is important that the Java platform not be fragmented,
+'gcj' and 'libgcj' try to conform to the relevant Java specifications.
+However, limited manpower and incomplete and unclear documentation work
+against us.  So, there are caveats to using 'gcj'.
+
+* Menu:
+
+* Limitations::                 
+* Extensions::                  
+
+
+File: gcj.info,  Node: Limitations,  Next: Extensions,  Up: Compatibility
+
+2.1 Standard features not yet supported
+=======================================
+
+This list of compatibility issues is by no means complete.
+
+   * 'gcj' implements the JDK 1.2 language.  It supports inner classes
+     and the new 1.4 'assert' keyword.  It does not yet support the Java
+     2 'strictfp' keyword (it recognizes the keyword but ignores it).
+
+   * 'libgcj' is largely compatible with the JDK 1.2 libraries.
+     However, 'libgcj' is missing many packages, most notably
+     'java.awt'.  There are also individual missing classes and methods.
+     We currently do not have a list showing differences between
+     'libgcj' and the Java 2 platform.
+
+   * Sometimes the 'libgcj' implementation of a method or class differs
+     from the JDK implementation.  This is not always a bug.  Still, if
+     it affects you, it probably makes sense to report it so that we can
+     discuss the appropriate response.
+
+   * 'gcj' does not currently allow for piecemeal replacement of
+     components within 'libgcj'.  Unfortunately, programmers often want
+     to use newer versions of certain packages, such as those provided
+     by the Apache Software Foundation's Jakarta project.  This has
+     forced us to place the 'org.w3c.dom' and 'org.xml.sax' packages
+     into their own libraries, separate from 'libgcj'.  If you intend to
+     use these classes, you must link them explicitly with
+     '-l-org-w3c-dom' and '-l-org-xml-sax'.  Future versions of 'gcj'
+     may not have this restriction.
+
+
+File: gcj.info,  Node: Extensions,  Prev: Limitations,  Up: Compatibility
+
+2.2 Extra features unique to gcj
+================================
+
+The main feature of 'gcj' is that it can compile programs written in the
+Java programming language to native code.  Most extensions that have
+been added are to facilitate this functionality.
+
+   * 'gcj' makes it easy and efficient to mix code written in Java and
+     C++.  *Note About CNI::, for more info on how to use this in your
+     programs.
+
+   * When you compile your classes into a shared library using
+     '-findirect-dispatch' then add them to the system-wide classmap.db
+     file using 'gcj-dbtool', they will be automatically loaded by the
+     'libgcj' system classloader.  This is the new, preferred
+     classname-to-library resolution mechanism.  *Note Invoking
+     gcj-dbtool::, for more information on using the classmap database.
+
+   * The old classname-to-library lookup mechanism is still supported
+     through the 'gnu.gcj.runtime.VMClassLoader.library_control'
+     property, but it is deprecated and will likely be removed in some
+     future release.  When trying to load a class 'gnu.pkg.SomeClass'
+     the system classloader will first try to load the shared library
+     'lib-gnu-pkg-SomeClass.so', if that fails to load the class then it
+     will try to load 'lib-gnu-pkg.so' and finally when the class is
+     still not loaded it will try to load 'lib-gnu.so'.  Note that all
+     '.'s will be transformed into '-'s and that searching for inner
+     classes starts with their outermost outer class.  If the class
+     cannot be found this way the system classloader tries to use the
+     'libgcj' bytecode interpreter to load the class from the standard
+     classpath.  This process can be controlled to some degree via the
+     'gnu.gcj.runtime.VMClassLoader.library_control' property; *Note
+     libgcj Runtime Properties::.
+
+   * 'libgcj' includes a special 'gcjlib' URL type.  A URL of this form
+     is like a 'jar' URL, and looks like
+     'gcjlib:/path/to/shared/library.so!/path/to/resource'.  An access
+     to one of these URLs causes the shared library to be 'dlopen()'d,
+     and then the resource is looked for in that library.  These URLs
+     are most useful when used in conjunction with
+     'java.net.URLClassLoader'.  Note that, due to implementation
+     limitations, currently any such URL can be accessed by only one
+     class loader, and libraries are never unloaded.  This means some
+     care must be exercised to make sure that a 'gcjlib' URL is not
+     accessed by more than one class loader at once.  In a future
+     release this limitation will be lifted, and such libraries will be
+     mapped privately.
+
+   * A program compiled by 'gcj' will examine the 'GCJ_PROPERTIES'
+     environment variable and change its behavior in some ways.  In
+     particular 'GCJ_PROPERTIES' holds a list of assignments to global
+     properties, such as would be set with the '-D' option to 'java'.
+     For instance, 'java.compiler=gcj' is a valid (but currently
+     meaningless) setting.
+
+
+File: gcj.info,  Node: Invoking jcf-dump,  Next: Invoking gij,  Prev: Compatibility,  Up: Top
+
+3 Invoking jcf-dump
+*******************
+
+This is a class file examiner, similar to 'javap'.  It will print
+information about a number of classes, which are specified by class name
+or file name.
+
+'-c'
+     Disassemble method bodies.  By default method bodies are not
+     printed.
+
+'--print-constants'
+     Print the constant pool.  When printing a reference to a constant
+     also print its index in the constant pool.
+
+'--javap'
+     Generate output in 'javap' format.  The implementation of this
+     feature is very incomplete.
+
+'--classpath=PATH'
+'--CLASSPATH=PATH'
+'-IDIRECTORY'
+'-o FILE'
+     These options as the same as the corresponding 'gcj' options.
+
+'--help'
+     Print help, then exit.
+
+'--version'
+     Print version number, then exit.
+
+'-v, --verbose'
+     Print extra information while running.  Implies
+     '--print-constants'.
+
+
+File: gcj.info,  Node: Invoking gij,  Next: Invoking gcj-dbtool,  Prev: Invoking jcf-dump,  Up: Top
+
+4 Invoking gij
+**************
+
+'gij' is a Java bytecode interpreter included with 'libgcj'.  'gij' is
+not available on every platform; porting it requires a small amount of
+assembly programming which has not been done for all the targets
+supported by 'gcj'.
+
+   The primary argument to 'gij' is the name of a class or, with '-jar',
+a jar file.  Options before this argument are interpreted by 'gij';
+remaining options are passed to the interpreted program.
+
+   If a class name is specified and this class does not have a 'main'
+method with the appropriate signature (a 'static void' method with a
+'String[]' as its sole argument), then 'gij' will print an error and
+exit.
+
+   If a jar file is specified then 'gij' will use information in it to
+determine which class' 'main' method will be invoked.
+
+   'gij' will invoke the 'main' method with all the remaining
+command-line options.
+
+   Note that 'gij' is not limited to interpreting code.  Because
+'libgcj' includes a class loader which can dynamically load shared
+objects, it is possible to give 'gij' the name of a class which has been
+compiled and put into a shared library on the class path.
+
+'-cp PATH'
+'-classpath PATH'
+     Set the initial class path.  The class path is used for finding
+     class and resource files.  If specified, this option overrides the
+     'CLASSPATH' environment variable.  Note that this option is ignored
+     if '-jar' is used.
+
+'-DNAME[=VALUE]'
+     This defines a system property named NAME with value VALUE.  If
+     VALUE is not specified then it defaults to the empty string.  These
+     system properties are initialized at the program's startup and can
+     be retrieved at runtime using the 'java.lang.System.getProperty'
+     method.
+
+'-ms=NUMBER'
+     Equivalent to '-Xms'.
+
+'-mx=NUMBER'
+     Equivalent to '-Xmx'.
+
+'-noverify'
+     Do not verify compliance of bytecode with the VM specification.  In
+     addition, this option disables type verification which is otherwise
+     performed on BC-ABI compiled code.
+
+'-X'
+'-XARGUMENT'
+     Supplying '-X' by itself will cause 'gij' to list all the supported
+     '-X' options.  Currently these options are supported:
+
+     '-XmsSIZE'
+          Set the initial heap size.
+
+     '-XmxSIZE'
+          Set the maximum heap size.
+
+     '-XssSIZE'
+          Set the thread stack size.
+
+     Unrecognized '-X' options are ignored, for compatibility with other
+     runtimes.
+
+'-jar'
+     This indicates that the name passed to 'gij' should be interpreted
+     as the name of a jar file, not a class.
+
+'--help'
+'-?'
+     Print help, then exit.
+
+'--showversion'
+     Print version number and continue.
+
+'--fullversion'
+     Print detailed version information, then exit.
+
+'--version'
+     Print version number, then exit.
+
+'-verbose'
+'-verbose:class'
+     Each time a class is initialized, print a short message on standard
+     error.
+
+   'gij' also recognizes and ignores the following options, for
+compatibility with existing application launch scripts: '-client',
+'-server', '-hotspot', '-jrockit', '-agentlib', '-agentpath', '-debug',
+'-d32', '-d64', '-javaagent', '-noclassgc', '-verify', and
+'-verifyremote'.
+
+
+File: gcj.info,  Node: Invoking gcj-dbtool,  Next: Invoking jv-convert,  Prev: Invoking gij,  Up: Top
+
+5 Invoking gcj-dbtool.
+**********************
+
+'gcj-dbtool' is a tool for creating and manipulating class file mapping
+databases.  'libgcj' can use these databases to find a shared library
+corresponding to the bytecode representation of a class.  This
+functionality is useful for ahead-of-time compilation of a program that
+has no knowledge of 'gcj'.
+
+   'gcj-dbtool' works best if all the jar files added to it are compiled
+using '-findirect-dispatch'.
+
+   Note that 'gcj-dbtool' is currently available as "preview
+technology".  We believe it is a reasonable way to allow
+application-transparent ahead-of-time compilation, but this is an
+unexplored area.  We welcome your comments.
+
+'-n DBFILE [SIZE]'
+     This creates a new database.  Currently, databases cannot be
+     resized; you can choose a larger initial size if desired.  The
+     default size is 32,749.
+
+'-a DBFILE JARFILE LIB'
+'-f DBFILE JARFILE LIB'
+     This adds a jar file to the database.  For each class file in the
+     jar, a cryptographic signature of the bytecode representation of
+     the class is recorded in the database.  At runtime, a class is
+     looked up by its signature and the compiled form of the class is
+     looked for in the corresponding shared library.  The '-a' option
+     will verify that LIB exists before adding it to the database; '-f'
+     skips this check.
+
+'[-][-0] -m DBFILE DBFILE,[DBFILE]'
+     Merge a number of databases.  The output database overwrites any
+     existing database.  To add databases into an existing database,
+     include the destination in the list of sources.
+
+     If '-' or '-0' are used, the list of files to read is taken from
+     standard input instead of the command line.  For '-0', Input
+     filenames are terminated by a null character instead of by
+     whitespace.  Useful when arguments might contain white space.  The
+     GNU find -print0 option produces input suitable for this mode.
+
+'-t DBFILE'
+     Test a database.
+
+'-l DBFILE'
+     List the contents of a database.
+
+'-p'
+     Print the name of the default database.  If there is no default
+     database, this prints a blank line.  If LIBDIR is specified, use it
+     instead of the default library directory component of the database
+     name.
+
+'--help'
+     Print a help message, then exit.
+
+'--version'
+'-v'
+     Print version information, then exit.
+
+
+File: gcj.info,  Node: Invoking jv-convert,  Next: Invoking grmic,  Prev: Invoking gcj-dbtool,  Up: Top
+
+6 Invoking jv-convert
+*********************
+
+'jv-convert' ['OPTION'] ... [INPUTFILE [OUTPUTFILE]]
+
+   'jv-convert' is a utility included with 'libgcj' which converts a
+file from one encoding to another.  It is similar to the Unix 'iconv'
+utility.
+
+   The encodings supported by 'jv-convert' are platform-dependent.
+Currently there is no way to get a list of all supported encodings.
+
+'--encoding NAME'
+'--from NAME'
+     Use NAME as the input encoding.  The default is the current
+     locale's encoding.
+
+'--to NAME'
+     Use NAME as the output encoding.  The default is the 'JavaSrc'
+     encoding; this is ASCII with '\u' escapes for non-ASCII characters.
+
+'-i FILE'
+     Read from FILE.  The default is to read from standard input.
+
+'-o FILE'
+     Write to FILE.  The default is to write to standard output.
+
+'--reverse'
+     Swap the input and output encodings.
+
+'--help'
+     Print a help message, then exit.
+
+'--version'
+     Print version information, then exit.
+
+
+File: gcj.info,  Node: Invoking grmic,  Next: Invoking gc-analyze,  Prev: Invoking jv-convert,  Up: Top
+
+7 Invoking grmic
+****************
+
+'grmic' ['OPTION'] ... CLASS ...
+
+   'grmic' is a utility included with 'libgcj' which generates stubs for
+remote objects.
+
+   Note that this program isn't yet fully compatible with the JDK
+'grmic'.  Some options, such as '-classpath', are recognized but
+currently ignored.  We have left these options undocumented for now.
+
+   Long options can also be given with a GNU-style leading '--'.  For
+instance, '--help' is accepted.
+
+'-keep'
+'-keepgenerated'
+     By default, 'grmic' deletes intermediate files.  Either of these
+     options causes it not to delete such files.
+
+'-v1.1'
+     Cause 'grmic' to create stubs and skeletons for the 1.1 protocol
+     version.
+
+'-vcompat'
+     Cause 'grmic' to create stubs and skeletons compatible with both
+     the 1.1 and 1.2 protocol versions.  This is the default.
+
+'-v1.2'
+     Cause 'grmic' to create stubs and skeletons for the 1.2 protocol
+     version.
+
+'-nocompile'
+     Don't compile the generated files.
+
+'-verbose'
+     Print information about what 'grmic' is doing.
+
+'-d DIRECTORY'
+     Put output files in DIRECTORY.  By default the files are put in the
+     current working directory.
+
+'-help'
+     Print a help message, then exit.
+
+'-version'
+     Print version information, then exit.
+
+
+File: gcj.info,  Node: Invoking gc-analyze,  Next: Invoking aot-compile,  Prev: Invoking grmic,  Up: Top
+
+8 Invoking gc-analyze
+*********************
+
+'gc-analyze' ['OPTION'] ... [FILE]
+
+   'gc-analyze' prints an analysis of a GC memory dump to standard out.
+
+   The memory dumps may be created by calling
+'gnu.gcj.util.GCInfo.enumerate(String namePrefix)' from java code.  A
+memory dump will be created on an out of memory condition if
+'gnu.gcj.util.GCInfo.setOOMDump(String namePrefix)' is called before the
+out of memory occurs.
+
+   Running this program will create two files: 'TestDump001' and
+'TestDump001.bytes'.
+
+     import gnu.gcj.util.*;
+     import java.util.*;
+
+     public class GCDumpTest
+     {
+         static public void main(String args[])
+         {
+             ArrayList<String> l = new ArrayList<String>(1000);
+
+             for (int i = 1; i < 1500; i++) {
+                 l.add("This is string #" + i);
+             }
+             GCInfo.enumerate("TestDump");
+         }
+     }
+
+   The memory dump may then be displayed by running:
+
+     gc-analyze -v TestDump001
+
+'--verbose'
+'-v'
+     Verbose output.
+
+'-p TOOL-PREFIX'
+     Prefix added to the names of the 'nm' and 'readelf' commands.
+
+'-d DIRECTORY'
+     Directory that contains the executable and shared libraries used
+     when the dump was generated.
+
+'--help'
+     Print a help message, then exit.
+
+'--version'
+     Print version information, then exit.
+
+
+File: gcj.info,  Node: Invoking aot-compile,  Next: Invoking rebuild-gcj-db,  Prev: Invoking gc-analyze,  Up: Top
+
+9 Invoking aot-compile
+**********************
+
+'aot-compile' is a script that searches a directory for Java bytecode
+(as class files, or in jars) and uses 'gcj' to compile it to native code
+and generate the databases from it.
+
+'-M, --make=PATH'
+     Specify the path to the 'make' executable to use.
+
+'-C, --gcj=PATH'
+     Specify the path to the 'gcj' executable to use.
+
+'-D, --dbtool=PATH'
+     Specify the path to the 'gcj-dbtool' executable to use.
+
+'-m, --makeflags=FLAGS'
+     Specify flags to pass to 'make' during the build.
+
+'-c, --gcjflags=FLAGS'
+     Specify flags to pass to 'gcj' during compilation, in addition to
+     '-fPIC -findirect-dispatch -fjni'.
+
+'-l, --ldflags=FLAGS'
+     Specify flags to pass to 'gcj' during linking, in addition to
+     '-Wl,-Bsymbolic'.
+
+'-e, --exclude=PATH'
+     Do not compile PATH.
+
+
+File: gcj.info,  Node: Invoking rebuild-gcj-db,  Next: About CNI,  Prev: Invoking aot-compile,  Up: Top
+
+10 Invoking rebuild-gcj-db
+**************************
+
+'rebuild-gcj-db' is a script that merges the per-solib databases made by
+'aot-compile' into one system-wide database so 'gij' can find the
+solibs.
+
+
+File: gcj.info,  Node: About CNI,  Next: System properties,  Prev: Invoking rebuild-gcj-db,  Up: Top
+
+11 About CNI
+************
+
+This documents CNI, the Compiled Native Interface, which is is a
+convenient way to write Java native methods using C++.  This is a more
+efficient, more convenient, but less portable alternative to the
+standard JNI (Java Native Interface).
+
+* Menu:
+
+* Basic concepts::              Introduction to using CNI.
+* Packages::                    How packages are mapped to C++.
+* Primitive types::             Handling primitive Java types in C++.
+* Reference types::             Handling Java reference types in C++.
+* Interfaces::                  How Java interfaces map to C++.
+* Objects and Classes::         C++ and Java classes.
+* Class Initialization::        How objects are initialized.
+* Object allocation::           How to create Java objects in C++.
+* Memory allocation::           How to allocate and free memory.
+* Arrays::                      Dealing with Java arrays in C++.
+* Methods::                     Java methods in C++.
+* Strings::                     Information about Java Strings.
+* Mixing with C++::             How CNI can interoperate with C++.
+* Exception Handling::          How exceptions are handled.
+* Synchronization::             Synchronizing between Java and C++.
+* Invocation::                  Starting the Java runtime from C++.
+* Reflection::                  Using reflection from C++.
+
+
+File: gcj.info,  Node: Basic concepts,  Next: Packages,  Up: About CNI
+
+11.1 Basic concepts
+===================
+
+In terms of languages features, Java is mostly a subset of C++.  Java
+has a few important extensions, plus a powerful standard class library,
+but on the whole that does not change the basic similarity.  Java is a
+hybrid object-oriented language, with a few native types, in addition to
+class types.  It is class-based, where a class may have static as well
+as per-object fields, and static as well as instance methods.
+Non-static methods may be virtual, and may be overloaded.  Overloading
+is resolved at compile time by matching the actual argument types
+against the parameter types.  Virtual methods are implemented using
+indirect calls through a dispatch table (virtual function table).
+Objects are allocated on the heap, and initialized using a constructor
+method.  Classes are organized in a package hierarchy.
+
+   All of the listed attributes are also true of C++, though C++ has
+extra features (for example in C++ objects may be allocated not just on
+the heap, but also statically or in a local stack frame).  Because 'gcj'
+uses the same compiler technology as G++ (the GNU C++ compiler), it is
+possible to make the intersection of the two languages use the same ABI
+(object representation and calling conventions).  The key idea in CNI is
+that Java objects are C++ objects, and all Java classes are C++ classes
+(but not the other way around).  So the most important task in
+integrating Java and C++ is to remove gratuitous incompatibilities.
+
+   You write CNI code as a regular C++ source file.  (You do have to use
+a Java/CNI-aware C++ compiler, specifically a recent version of G++.)
+
+A CNI C++ source file must have:
+
+     #include <gcj/cni.h>
+
+and then must include one header file for each Java class it uses, e.g.:
+
+     #include <java/lang/Character.h>
+     #include <java/util/Date.h>
+     #include <java/lang/IndexOutOfBoundsException.h>
+
+These header files are automatically generated by 'gcjh'.
+
+   CNI provides some functions and macros to make using Java objects and
+primitive types from C++ easier.  In general, these CNI functions and
+macros start with the 'Jv' prefix, for example the function
+'JvNewObjectArray'.  This convention is used to avoid conflicts with
+other libraries.  Internal functions in CNI start with the prefix
+'_Jv_'.  You should not call these; if you find a need to, let us know
+and we will try to come up with an alternate solution.
+
+11.1.1 Limitations
+------------------
+
+Whilst a Java class is just a C++ class that doesn't mean that you are
+freed from the shackles of Java, a CNI C++ class must adhere to the
+rules of the Java programming language.
+
+   For example: it is not possible to declare a method in a CNI class
+that will take a C string ('char*') as an argument, or to declare a
+member variable of some non-Java datatype.
+
+
+File: gcj.info,  Node: Packages,  Next: Primitive types,  Prev: Basic concepts,  Up: About CNI
+
+11.2 Packages
+=============
+
+The only global names in Java are class names, and packages.  A
+"package" can contain zero or more classes, and also zero or more
+sub-packages.  Every class belongs to either an unnamed package or a
+package that has a hierarchical and globally unique name.
+
+   A Java package is mapped to a C++ "namespace".  The Java class
+'java.lang.String' is in the package 'java.lang', which is a sub-package
+of 'java'.  The C++ equivalent is the class 'java::lang::String', which
+is in the namespace 'java::lang' which is in the namespace 'java'.
+
+Here is how you could express this:
+
+     (// Declare the class(es), possibly in a header file:
+     namespace java {
+       namespace lang {
+         class Object;
+         class String;
+         ...
+       }
+     }
+
+     class java::lang::String : public java::lang::Object
+     {
+       ...
+     };
+
+The 'gcjh' tool automatically generates the necessary namespace
+declarations.
+
+11.2.1 Leaving out package names
+--------------------------------
+
+Always using the fully-qualified name of a java class can be tiresomely
+verbose.  Using the full qualified name also ties the code to a single
+package making code changes necessary should the class move from one
+package to another.  The Java 'package' declaration specifies that the
+following class declarations are in the named package, without having to
+explicitly name the full package qualifiers.  The 'package' declaration
+can be followed by zero or more 'import' declarations, which allows
+either a single class or all the classes in a package to be named by a
+simple identifier.  C++ provides something similar with the 'using'
+declaration and directive.
+
+In Java:
+
+     import PACKAGE-NAME.CLASS-NAME;
+
+allows the program text to refer to CLASS-NAME as a shorthand for the
+fully qualified name: 'PACKAGE-NAME.CLASS-NAME'.
+
+To achieve the same effect C++, you have to do this:
+
+     using PACKAGE-NAME::CLASS-NAME;
+
+Java can also cause imports on demand, like this:
+
+     import PACKAGE-NAME.*;
+
+Doing this allows any class from the package PACKAGE-NAME to be referred
+to only by its class-name within the program text.
+
+The same effect can be achieved in C++ like this:
+
+     using namespace PACKAGE-NAME;
+
+
+File: gcj.info,  Node: Primitive types,  Next: Reference types,  Prev: Packages,  Up: About CNI
+
+11.3 Primitive types
+====================
+
+Java provides 8 "primitives" types which represent integers, floats,
+characters and booleans (and also the void type).  C++ has its own very
+similar concrete types.  Such types in C++ however are not always
+implemented in the same way (an int might be 16, 32 or 64 bits for
+example) so CNI provides a special C++ type for each primitive Java
+type:
+
+*Java type*    *C/C++ typename*   *Description*
+'char'         'jchar'            16 bit Unicode character
+'boolean'      'jboolean'         logical (true or false) values
+'byte'         'jbyte'            8-bit signed integer
+'short'        'jshort'           16 bit signed integer
+'int'          'jint'             32 bit signed integer
+'long'         'jlong'            64 bit signed integer
+'float'        'jfloat'           32 bit IEEE floating point number
+'double'       'jdouble'          64 bit IEEE floating point number
+'void'         'void'             no value
+
+   When referring to a Java type You should always use these C++
+typenames (e.g.: 'jint') to avoid disappointment.
+
+11.3.1 Reference types associated with primitive types
+------------------------------------------------------
+
+In Java each primitive type has an associated reference type, e.g.:
+'boolean' has an associated 'java.lang.Boolean.TYPE' class.  In order to
+make working with such classes easier GCJ provides the macro
+'JvPrimClass':
+
+ -- macro: JvPrimClass type
+     Return a pointer to the 'Class' object corresponding to the type
+     supplied.
+
+          JvPrimClass(void) => java.lang.Void.TYPE
+
+
+File: gcj.info,  Node: Reference types,  Next: Interfaces,  Prev: Primitive types,  Up: About CNI
+
+11.4 Reference types
+====================
+
+A Java reference type is treated as a class in C++.  Classes and
+interfaces are handled this way.  A Java reference is translated to a
+C++ pointer, so for instance a Java 'java.lang.String' becomes, in C++,
+'java::lang::String *'.
+
+   CNI provides a few built-in typedefs for the most common classes:
+*Java type*            *C++ typename*     *Description*
+'java.lang.Object'     'jobject'          Object type
+'java.lang.String'     'jstring'          String type
+'java.lang.Class'      'jclass'           Class type
+
+   Every Java class or interface has a corresponding 'Class' instance.
+These can be accessed in CNI via the static 'class$' field of a class.
+The 'class$' field is of type 'Class' (and not 'Class *'), so you will
+typically take the address of it.
+
+   Here is how you can refer to the class of 'String', which in Java
+would be written 'String.class':
+
+     using namespace java::lang;
+     doSomething (&String::class$);
+
+
+File: gcj.info,  Node: Interfaces,  Next: Objects and Classes,  Prev: Reference types,  Up: About CNI
+
+11.5 Interfaces
+===============
+
+A Java class can "implement" zero or more "interfaces", in addition to
+inheriting from a single base class.
+
+   CNI allows CNI code to implement methods of interfaces.  You can also
+call methods through interface references, with some limitations.
+
+   CNI doesn't understand interface inheritance at all yet.  So, you can
+only call an interface method when the declared type of the field being
+called matches the interface which declares that method.  The workaround
+is to cast the interface reference to the right superinterface.
+
+   For example if you have:
+
+     interface A
+     {
+       void a();
+     }
+
+     interface B extends A
+     {
+       void b();
+     }
+
+   and declare a variable of type 'B' in C++, you can't call 'a()'
+unless you cast it to an 'A' first.
+
+
+File: gcj.info,  Node: Objects and Classes,  Next: Class Initialization,  Prev: Interfaces,  Up: About CNI
+
+11.6 Objects and Classes
+========================
+
+11.6.1 Classes
+--------------
+
+All Java classes are derived from 'java.lang.Object'.  C++ does not have
+a unique root class, but we use the C++ class 'java::lang::Object' as
+the C++ version of the 'java.lang.Object' Java class.  All other Java
+classes are mapped into corresponding C++ classes derived from
+'java::lang::Object'.
+
+   Interface inheritance (the 'implements' keyword) is currently not
+reflected in the C++ mapping.
+
+11.6.2 Object fields
+--------------------
+
+Each object contains an object header, followed by the instance fields
+of the class, in order.  The object header consists of a single pointer
+to a dispatch or virtual function table.  (There may be extra fields _in
+front of_ the object, for example for memory management, but this is
+invisible to the application, and the reference to the object points to
+the dispatch table pointer.)
+
+   The fields are laid out in the same order, alignment, and size as in
+C++.  Specifically, 8-bit and 16-bit native types ('byte', 'short',
+'char', and 'boolean') are _not_ widened to 32 bits.  Note that the Java
+VM does extend 8-bit and 16-bit types to 32 bits when on the VM stack or
+temporary registers.
+
+   If you include the 'gcjh'-generated header for a class, you can
+access fields of Java classes in the _natural_ way.  For example, given
+the following Java class:
+
+     public class Int
+     {
+       public int i;
+       public Int (int i) { this.i = i; }
+       public static Int zero = new Int(0);
+     }
+
+   you can write:
+
+     #include <gcj/cni.h>;
+     #include <Int>;
+
+     Int*
+     mult (Int *p, jint k)
+     {
+       if (k == 0)
+         return Int::zero;  // Static member access.
+       return new Int(p->i * k);
+     }
+
+11.6.3 Access specifiers
+------------------------
+
+CNI does not strictly enforce the Java access specifiers, because Java
+permissions cannot be directly mapped into C++ permission.  Private Java
+fields and methods are mapped to private C++ fields and methods, but
+other fields and methods are mapped to public fields and methods.
+
+
+File: gcj.info,  Node: Class Initialization,  Next: Object allocation,  Prev: Objects and Classes,  Up: About CNI
+
+11.7 Class Initialization
+=========================
+
+Java requires that each class be automatically initialized at the time
+of the first active use.  Initializing a class involves initializing the
+static fields, running code in class initializer methods, and
+initializing base classes.  There may also be some implementation
+specific actions, such as allocating 'String' objects corresponding to
+string literals in the code.
+
+   The GCJ compiler inserts calls to 'JvInitClass' at appropriate places
+to ensure that a class is initialized when required.  The C++ compiler
+does not insert these calls automatically--it is the programmer's
+responsibility to make sure classes are initialized.  However, this is
+fairly painless because of the conventions assumed by the Java system.
+
+   First, 'libgcj' will make sure a class is initialized before an
+instance of that object is created.  This is one of the responsibilities
+of the 'new' operation.  This is taken care of both in Java code, and in
+C++ code.  When G++ sees a 'new' of a Java class, it will call a routine
+in 'libgcj' to allocate the object, and that routine will take care of
+initializing the class.  Note however that this does not happen for Java
+arrays; you must allocate those using the appropriate CNI function.  It
+follows that you can access an instance field, or call an instance
+(non-static) method and be safe in the knowledge that the class and all
+of its base classes have been initialized.
+
+   Invoking a static method is also safe.  This is because the Java
+compiler adds code to the start of a static method to make sure the
+class is initialized.  However, the C++ compiler does not add this extra
+code.  Hence, if you write a native static method using CNI, you are
+responsible for calling 'JvInitClass' before doing anything else in the
+method (unless you are sure it is safe to leave it out).
+
+   Accessing a static field also requires the class of the field to be
+initialized.  The Java compiler will generate code to call 'JvInitClass'
+before getting or setting the field.  However, the C++ compiler will not
+generate this extra code, so it is your responsibility to make sure the
+class is initialized before you access a static field from C++.
+
+
+File: gcj.info,  Node: Object allocation,  Next: Memory allocation,  Prev: Class Initialization,  Up: About CNI
+
+11.8 Object allocation
+======================
+
+New Java objects are allocated using a "class instance creation
+expression", e.g.:
+
+     new TYPE ( ... )
+
+   The same syntax is used in C++.  The main difference is that C++
+objects have to be explicitly deleted; in Java they are automatically
+deleted by the garbage collector.  Using CNI, you can allocate a new
+Java object using standard C++ syntax and the C++ compiler will allocate
+memory from the garbage collector.  If you have overloaded constructors,
+the compiler will choose the correct one using standard C++ overload
+resolution rules.
+
+For example:
+
+     java::util::Hashtable *ht = new java::util::Hashtable(120);
+
+
+File: gcj.info,  Node: Memory allocation,  Next: Arrays,  Prev: Object allocation,  Up: About CNI
+
+11.9 Memory allocation
+======================
+
+When allocating memory in CNI methods it is best to handle out-of-memory
+conditions by throwing a Java exception.  These functions are provided
+for that purpose:
+
+ -- Function: void* JvMalloc (jsize SIZE)
+     Calls malloc.  Throws 'java.lang.OutOfMemoryError' if allocation
+     fails.
+
+ -- Function: void* JvRealloc (void* PTR, jsize SIZE)
+     Calls realloc.  Throws 'java.lang.OutOfMemoryError' if reallocation
+     fails.
+
+ -- Function: void JvFree (void* PTR)
+     Calls free.
+
+
+File: gcj.info,  Node: Arrays,  Next: Methods,  Prev: Memory allocation,  Up: About CNI
+
+11.10 Arrays
+============
+
+While in many ways Java is similar to C and C++, it is quite different
+in its treatment of arrays.  C arrays are based on the idea of pointer
+arithmetic, which would be incompatible with Java's security
+requirements.  Java arrays are true objects (array types inherit from
+'java.lang.Object').  An array-valued variable is one that contains a
+reference (pointer) to an array object.
+
+   Referencing a Java array in C++ code is done using the 'JArray'
+template, which as defined as follows:
+
+     class __JArray : public java::lang::Object
+     {
+     public:
+       int length;
+     };
+
+     template<class T>
+     class JArray : public __JArray
+     {
+       T data[0];
+     public:
+       T& operator[](jint i) { return data[i]; }
+     };
+
+   There are a number of 'typedef's which correspond to 'typedef's from
+the JNI.  Each is the type of an array holding objects of the relevant
+type:
+
+     typedef __JArray *jarray;
+     typedef JArray<jobject> *jobjectArray;
+     typedef JArray<jboolean> *jbooleanArray;
+     typedef JArray<jbyte> *jbyteArray;
+     typedef JArray<jchar> *jcharArray;
+     typedef JArray<jshort> *jshortArray;
+     typedef JArray<jint> *jintArray;
+     typedef JArray<jlong> *jlongArray;
+     typedef JArray<jfloat> *jfloatArray;
+     typedef JArray<jdouble> *jdoubleArray;
+
+ -- Method on template<class T>: T* elements (JArray<T> ARRAY)
+     This template function can be used to get a pointer to the elements
+     of the 'array'.  For instance, you can fetch a pointer to the
+     integers that make up an 'int[]' like so:
+
+          extern jintArray foo;
+          jint *intp = elements (foo);
+
+     The name of this function may change in the future.
+
+ -- Function: jobjectArray JvNewObjectArray (jsize LENGTH, jclass KLASS,
+          jobject INIT)
+     This creates a new array whose elements have reference type.
+     'klass' is the type of elements of the array and 'init' is the
+     initial value put into every slot in the array.
+
+     using namespace java::lang;
+     JArray<String *> *array
+       = (JArray<String *> *) JvNewObjectArray(length, &String::class$, NULL);
+
+11.10.1 Creating arrays
+-----------------------
+
+For each primitive type there is a function which can be used to create
+a new array of that type.  The name of the function is of the form:
+
+     JvNewTYPEArray
+
+For example:
+
+     JvNewBooleanArray
+
+can be used to create an array of Java primitive boolean types.
+
+The following function definition is the template for all such
+functions:
+
+ -- Function: jbooleanArray JvNewBooleanArray (jint LENGTH)
+     Creates an array LENGTH indices long.
+
+ -- Function: jsize JvGetArrayLength (jarray ARRAY)
+     Returns the length of the ARRAY.
+
+
+File: gcj.info,  Node: Methods,  Next: Strings,  Prev: Arrays,  Up: About CNI
+
+11.11 Methods
+=============
+
+Java methods are mapped directly into C++ methods.  The header files
+generated by 'gcjh' include the appropriate method definitions.
+Basically, the generated methods have the same names and _corresponding_
+types as the Java methods, and are called in the natural manner.
+
+11.11.1 Overloading
+-------------------
+
+Both Java and C++ provide method overloading, where multiple methods in
+a class have the same name, and the correct one is chosen (at compile
+time) depending on the argument types.  The rules for choosing the
+correct method are (as expected) more complicated in C++ than in Java,
+but given a set of overloaded methods generated by 'gcjh' the C++
+compiler will choose the expected one.
+
+   Common assemblers and linkers are not aware of C++ overloading, so
+the standard implementation strategy is to encode the parameter types of
+a method into its assembly-level name.  This encoding is called
+"mangling", and the encoded name is the "mangled name".  The same
+mechanism is used to implement Java overloading.  For C++/Java
+interoperability, it is important that both the Java and C++ compilers
+use the _same_ encoding scheme.
+
+11.11.2 Static methods
+----------------------
+
+Static Java methods are invoked in CNI using the standard C++ syntax,
+using the '::' operator rather than the '.' operator.
+
+For example:
+
+     jint i = java::lang::Math::round((jfloat) 2.3);
+
+C++ method definition syntax is used to define a static native method.
+For example:
+
+     #include <java/lang/Integer>
+     java::lang::Integer*
+     java::lang::Integer::getInteger(jstring str)
+     {
+       ...
+     }
+
+11.11.3 Object Constructors
+---------------------------
+
+Constructors are called implicitly as part of object allocation using
+the 'new' operator.
+
+For example:
+
+     java::lang::Integer *x = new java::lang::Integer(234);
+
+   Java does not allow a constructor to be a native method.  This
+limitation can be coded round however because a constructor can _call_ a
+native method.
+
+11.11.4 Instance methods
+------------------------
+
+Calling a Java instance method from a C++ CNI method is done using the
+standard C++ syntax, e.g.:
+
+     // First create the Java object.
+     java::lang::Integer *x = new java::lang::Integer(234);
+     // Now call a method.
+     jint prim_value = x->intValue();
+     if (x->longValue == 0)
+       ...
+
+Defining a Java native instance method is also done the natural way:
+
+     #include <java/lang/Integer.h>
+
+     jdouble
+     java::lang:Integer::doubleValue()
+     {
+       return (jdouble) value;
+     }
+
+11.11.5 Interface methods
+-------------------------
+
+In Java you can call a method using an interface reference.  This is
+supported, but not completely.  *Note Interfaces::.
+
+
+File: gcj.info,  Node: Strings,  Next: Mixing with C++,  Prev: Methods,  Up: About CNI
+
+11.12 Strings
+=============
+
+CNI provides a number of utility functions for working with Java Java
+'String' objects.  The names and interfaces are analogous to those of
+JNI.
+
+ -- Function: jstring JvNewString (const jchar* CHARS, jsize LEN)
+     Returns a Java 'String' object with characters from the array of
+     Unicode characters CHARS up to the index LEN in that array.
+
+ -- Function: jstring JvNewStringLatin1 (const char* BYTES, jsize LEN)
+     Returns a Java 'String' made up of LEN bytes from BYTES.
+
+ -- Function: jstring JvNewStringLatin1 (const char* BYTES)
+     As above but the length of the 'String' is 'strlen(BYTES)'.
+
+ -- Function: jstring JvNewStringUTF (const char* BYTES)
+     Returns a 'String' which is made up of the UTF encoded characters
+     present in the C string BYTES.
+
+ -- Function: jchar* JvGetStringChars (jstring STR)
+     Returns a pointer to an array of characters making up the 'String'
+     STR.
+
+ -- Function: int JvGetStringUTFLength (jstring STR)
+     Returns the number of bytes required to encode the contents of the
+     'String' STR in UTF-8.
+
+ -- Function: jsize JvGetStringUTFRegion (jstring STR, jsize START,
+          jsize LEN, char* BUF)
+     Puts the UTF-8 encoding of a region of the 'String' STR into the
+     buffer 'buf'.  The region to fetch is marked by START and LEN.
+
+     Note that BUF is a buffer, not a C string.  It is _not_ null
+     terminated.
+
+
+File: gcj.info,  Node: Mixing with C++,  Next: Exception Handling,  Prev: Strings,  Up: About CNI
+
+11.13 Interoperating with C/C++
+===============================
+
+Because CNI is designed to represent Java classes and methods it cannot
+be mixed readily with C/C++ types.
+
+   One important restriction is that Java classes cannot have non-Java
+type instance or static variables and cannot have methods which take
+non-Java types as arguments or return non-Java types.
+
+None of the following is possible with CNI:
+
+
+     class ::MyClass : public java::lang::Object
+     {
+        char* variable;  // char* is not a valid Java type.
+     }
+
+
+     uint
+     ::SomeClass::someMethod (char *arg)
+     {
+       .
+       .
+       .
+     }   // 'uint' is not a valid Java type, neither is 'char*'
+
+Of course, it is ok to use C/C++ types within the scope of a method:
+
+     jint
+     ::SomeClass::otherMethod (jstring str)
+     {
+        char *arg = ...
+        .
+        .
+        .
+     }
+
+11.13.1 RawData
+---------------
+
+The above restriction can be problematic, so CNI includes the
+'gnu.gcj.RawData' class.  The 'RawData' class is a "non-scanned
+reference" type.  In other words variables declared of type 'RawData'
+can contain any data and are not checked by the compiler or memory
+manager in any way.
+
+   This means that you can put C/C++ data structures (including classes)
+in your CNI classes, as long as you use the appropriate cast.
+
+Here are some examples:
+
+
+     class ::MyClass : public java::lang::Object
+     {
+        gnu.gcj.RawData string;
+
+        MyClass ();
+        gnu.gcj.RawData getText ();
+        void printText ();
+     }
+
+     ::MyClass::MyClass ()
+     {
+        char* text = ...
+        string = text;
+     }
+
+     gnu.gcj.RawData
+     ::MyClass::getText ()
+     {
+        return string;
+     }
+
+     void
+     ::MyClass::printText ()
+     {
+       printf("%s\n", (char*) string);
+     }
+
+11.13.2 RawDataManaged
+----------------------
+
+'gnu.gcj.RawDataManaged' is another type used to indicate special data
+used by native code.  Unlike the 'RawData' type, fields declared as
+'RawDataManaged' will be "marked" by the memory manager and considered
+for garbage collection.
+
+   Native data which is allocated using CNI's 'JvAllocBytes()' function
+and stored in a 'RawDataManaged' will be automatically freed when the
+Java object it is associated with becomes unreachable.
+
+11.13.3 Native memory allocation
+--------------------------------
+
+ -- Function: void* JvAllocBytes (jsize SIZE)
+     Allocates SIZE bytes from the heap.  The memory returned is zeroed.
+     This memory is not scanned for pointers by the garbage collector,
+     but will be freed if no references to it are discovered.
+
+     This function can be useful if you need to associate some native
+     data with a Java object.  Using a CNI's special 'RawDataManaged'
+     type, native data allocated with 'JvAllocBytes' will be
+     automatically freed when the Java object itself becomes
+     unreachable.
+
+11.13.4 Posix signals
+---------------------
+
+On Posix based systems the 'libgcj' library uses several signals
+internally.  CNI code should not attempt to use the same signals as
+doing so may cause 'libgcj' and/or the CNI code to fail.
+
+   SIGSEGV is used on many systems to generate 'NullPointerExceptions'.
+SIGCHLD is used internally by 'Runtime.exec()'.  Several other signals
+(that vary from platform to platform) can be used by the memory manager
+and by 'Thread.interrupt()'.
+
+
+File: gcj.info,  Node: Exception Handling,  Next: Synchronization,  Prev: Mixing with C++,  Up: About CNI
+
+11.14 Exception Handling
+========================
+
+While C++ and Java share a common exception handling framework, things
+are not yet perfectly integrated.  The main issue is that the run-time
+type information facilities of the two languages are not integrated.
+
+   Still, things work fairly well.  You can throw a Java exception from
+C++ using the ordinary 'throw' construct, and this exception can be
+caught by Java code.  Similarly, you can catch an exception thrown from
+Java using the C++ 'catch' construct.
+
+Here is an example:
+
+     if (i >= count)
+        throw new java::lang::IndexOutOfBoundsException();
+
+   Normally, G++ will automatically detect when you are writing C++ code
+that uses Java exceptions, and handle them appropriately.  However, if
+C++ code only needs to execute destructors when Java exceptions are
+thrown through it, GCC will guess incorrectly.  Sample problematic code:
+
+     struct S { ~S(); };
+
+     extern void bar();    // Is implemented in Java and may throw exceptions.
+
+     void foo()
+     {
+       S s;
+       bar();
+     }
+
+   The usual effect of an incorrect guess is a link failure, complaining
+of a missing routine called '__gxx_personality_v0'.
+
+   You can inform the compiler that Java exceptions are to be used in a
+translation unit, irrespective of what it might think, by writing
+'#pragma GCC java_exceptions' at the head of the file.  This '#pragma'
+must appear before any functions that throw or catch exceptions, or run
+destructors when exceptions are thrown through them.
+
+
+File: gcj.info,  Node: Synchronization,  Next: Invocation,  Prev: Exception Handling,  Up: About CNI
+
+11.15 Synchronization
+=====================
+
+Each Java object has an implicit monitor.  The Java VM uses the
+instruction 'monitorenter' to acquire and lock a monitor, and
+'monitorexit' to release it.
+
+   The corresponding CNI macros are 'JvMonitorEnter' and 'JvMonitorExit'
+(JNI has similar methods 'MonitorEnter' and 'MonitorExit').
+
+   The Java source language does not provide direct access to these
+primitives.  Instead, there is a 'synchronized' statement that does an
+implicit 'monitorenter' before entry to the block, and does a
+'monitorexit' on exit from the block.  Note that the lock has to be
+released even when the block is abnormally terminated by an exception,
+which means there is an implicit 'try finally' surrounding
+synchronization locks.
+
+   From C++, it makes sense to use a destructor to release a lock.  CNI
+defines the following utility class:
+
+     class JvSynchronize() {
+       jobject obj;
+       JvSynchronize(jobject o) { obj = o; JvMonitorEnter(o); }
+       ~JvSynchronize() { JvMonitorExit(obj); }
+     };
+
+   So this Java code:
+
+     synchronized (OBJ)
+     {
+        CODE
+     }
+
+might become this C++ code:
+
+     {
+        JvSynchronize dummy (OBJ);
+        CODE;
+     }
+
+   Java also has methods with the 'synchronized' attribute.  This is
+equivalent to wrapping the entire method body in a 'synchronized'
+statement.  (Alternatively, an implementation could require the caller
+to do the synchronization.  This is not practical for a compiler,
+because each virtual method call would have to test at run-time if
+synchronization is needed.)  Since in 'gcj' the 'synchronized' attribute
+is handled by the method implementation, it is up to the programmer of a
+synchronized native method to handle the synchronization (in the C++
+implementation of the method).  In other words, you need to manually add
+'JvSynchronize' in a 'native synchronized' method.
+
+
+File: gcj.info,  Node: Invocation,  Next: Reflection,  Prev: Synchronization,  Up: About CNI
+
+11.16 Invocation
+================
+
+CNI permits C++ applications to make calls into Java classes, in
+addition to allowing Java code to call into C++.  Several functions,
+known as the "invocation API", are provided to support this.
+
+ -- Function: jint JvCreateJavaVM (JvVMInitArgs* VM_ARGS)
+
+     Initializes the Java runtime.  This function performs essential
+     initialization of the threads interface, garbage collector,
+     exception handling and other key aspects of the runtime.  It must
+     be called once by an application with a non-Java 'main()' function,
+     before any other Java or CNI calls are made.  It is safe, but not
+     recommended, to call 'JvCreateJavaVM()' more than once provided it
+     is only called from a single thread.  The VMARGS parameter can be
+     used to specify initialization parameters for the Java runtime.  It
+     may be 'NULL'.
+
+     JvVMInitArgs represents a list of virtual machine initialization
+     arguments.  'JvCreateJavaVM()' ignores the version field.
+
+          typedef struct JvVMOption
+          {
+            // a VM initialization option
+            char* optionString;
+            // extra information associated with this option
+            void* extraInfo;
+          } JvVMOption;
+
+          typedef struct JvVMInitArgs
+          {
+            // for compatibility with JavaVMInitArgs
+            jint version;
+
+            // number of VM initialization options
+            jint nOptions;
+
+            // an array of VM initialization options
+            JvVMOption* options;
+
+            // true if the option parser should ignore unrecognized options
+            jboolean ignoreUnrecognized;
+          } JvVMInitArgs;
+
+     'JvCreateJavaVM()' returns '0' upon success, or '-1' if the runtime
+     is already initialized.
+
+     _Note:_ In GCJ 3.1, the 'vm_args' parameter is ignored.  It is
+     recognized and used as of release 4.0.
+
+ -- Function: java::lang::Thread* JvAttachCurrentThread (jstring NAME,
+          java::lang::ThreadGroup* GROUP)
+     Registers an existing thread with the Java runtime.  This must be
+     called once from each thread, before that thread makes any other
+     Java or CNI calls.  It must be called after 'JvCreateJavaVM'.  NAME
+     specifies a name for the thread.  It may be 'NULL', in which case a
+     name will be generated.  GROUP is the ThreadGroup in which this
+     thread will be a member.  If it is 'NULL', the thread will be a
+     member of the main thread group.  The return value is the Java
+     'Thread' object that represents the thread.  It is safe to call
+     'JvAttachCurrentThread()' more than once from the same thread.  If
+     the thread is already attached, the call is ignored and the current
+     thread object is returned.
+
+ -- Function: jint JvDetachCurrentThread ()
+     Unregisters a thread from the Java runtime.  This should be called
+     by threads that were attached using 'JvAttachCurrentThread()',
+     after they have finished making calls to Java code.  This ensures
+     that any resources associated with the thread become eligible for
+     garbage collection.  This function returns '0' upon success, or
+     '-1' if the current thread is not attached.
+
+11.16.1 Handling uncaught exceptions
+------------------------------------
+
+If an exception is thrown from Java code called using the invocation
+API, and no handler for the exception can be found, the runtime will
+abort the application.  In order to make the application more robust, it
+is recommended that code which uses the invocation API be wrapped by a
+top-level try/catch block that catches all Java exceptions.
+
+11.16.2 Example
+---------------
+
+The following code demonstrates the use of the invocation API. In this
+example, the C++ application initializes the Java runtime and attaches
+itself.  The 'java.lang.System' class is initialized in order to access
+its 'out' field, and a Java string is printed.  Finally, the thread is
+detached from the runtime once it has finished making Java calls.
+Everything is wrapped with a try/catch block to provide a default
+handler for any uncaught exceptions.
+
+   The example can be compiled with 'c++ -c test.cc; gcj test.o'.
+
+     // test.cc
+     #include <gcj/cni.h>
+     #include <java/lang/System.h>
+     #include <java/io/PrintStream.h>
+     #include <java/lang/Throwable.h>
+
+     int main(int argc, char *argv[])
+     {
+       using namespace java::lang;
+
+       try
+       {
+         JvCreateJavaVM(NULL);
+         JvAttachCurrentThread(NULL, NULL);
+
+         String *message = JvNewStringLatin1("Hello from C++");
+         JvInitClass(&System::class$);
+         System::out->println(message);
+
+         JvDetachCurrentThread();
+       }
+       catch (Throwable *t)
+       {
+         System::err->println(JvNewStringLatin1("Unhandled Java exception:"));
+         t->printStackTrace();
+       }
+     }
+
+
+File: gcj.info,  Node: Reflection,  Prev: Invocation,  Up: About CNI
+
+11.17 Reflection
+================
+
+Reflection is possible with CNI code, it functions similarly to how it
+functions with JNI.
+
+   The types 'jfieldID' and 'jmethodID' are as in JNI.
+
+The functions:
+
+   * 'JvFromReflectedField',
+   * 'JvFromReflectedMethod',
+   * 'JvToReflectedField'
+   * 'JvToFromReflectedMethod'
+
+will be added shortly, as will other functions corresponding to JNI.
+
+
+File: gcj.info,  Node: System properties,  Next: Resources,  Prev: About CNI,  Up: Top
+
+12 System properties
+********************
+
+The runtime behavior of the 'libgcj' library can be modified by setting
+certain system properties.  These properties can be compiled into the
+program using the '-DNAME[=VALUE]' option to 'gcj' or by setting them
+explicitly in the program by calling the
+'java.lang.System.setProperty()' method.  Some system properties are
+only used for informational purposes (like giving a version number or a
+user name).  A program can inspect the current value of a property by
+calling the 'java.lang.System.getProperty()' method.
+
+* Menu:
+
+* Standard Properties::         Standard properties supported by 'libgcj'
+* GNU Classpath Properties::    Properties found in Classpath based libraries
+* libgcj Runtime Properties::   Properties specific to 'libgcj'
+
+
+File: gcj.info,  Node: Standard Properties,  Next: GNU Classpath Properties,  Up: System properties
+
+12.1 Standard Properties
+========================
+
+The following properties are normally found in all implementations of
+the core libraries for the Java language.
+
+'java.version'
+     The 'libgcj' version number.
+
+'java.vendor'
+     Set to 'The Free Software Foundation, Inc.'
+
+'java.vendor.url'
+     Set to <http://gcc.gnu.org/java/>.
+
+'java.home'
+     The directory where 'gcj' was installed.  Taken from the '--prefix'
+     option given to 'configure'.
+
+'java.class.version'
+     The class format version number supported by the libgcj byte code
+     interpreter.  (Currently '46.0')
+
+'java.vm.specification.version'
+     The Virtual Machine Specification version implemented by 'libgcj'.
+     (Currently '1.0')
+
+'java.vm.specification.vendor'
+     The name of the Virtual Machine specification designer.
+
+'java.vm.specification.name'
+     The name of the Virtual Machine specification (Set to 'Java Virtual
+     Machine Specification').
+
+'java.vm.version'
+     The 'gcj' version number.
+
+'java.vm.vendor'
+     Set to 'The Free Software Foundation, Inc.'
+
+'java.vm.name'
+     Set to 'GNU libgcj'.
+
+'java.specification.version'
+     The Runtime Environment specification version implemented by
+     'libgcj'.  (Currently set to '1.3')
+
+'java.specification.vendor'
+     The Runtime Environment specification designer.
+
+'java.specification.name'
+     The name of the Runtime Environment specification (Set to 'Java
+     Platform API Specification').
+
+'java.class.path'
+     The paths (jar files, zip files and directories) used for finding
+     class files.
+
+'java.library.path'
+     Directory path used for finding native libraries.
+
+'java.io.tmpdir'
+     The directory used to put temporary files in.
+
+'java.compiler'
+     Name of the Just In Time compiler to use by the byte code
+     interpreter.  Currently not used in 'libgcj'.
+
+'java.ext.dirs'
+     Directories containing jar files with extra libraries.  Will be
+     used when resolving classes.
+
+'java.protocol.handler.pkgs'
+     A '|' separated list of package names that is used to find classes
+     that implement handlers for 'java.net.URL'.
+
+'java.rmi.server.codebase'
+     A list of URLs that is used by the 'java.rmi.server.RMIClassLoader'
+     to load classes from.
+
+'jdbc.drivers'
+     A list of class names that will be loaded by the
+     'java.sql.DriverManager' when it starts up.
+
+'file.separator'
+     The separator used in when directories are included in a filename
+     (normally '/' or '\' ).
+
+'file.encoding'
+     The default character encoding used when converting platform native
+     files to Unicode (usually set to '8859_1').
+
+'path.separator'
+     The standard separator used when a string contains multiple paths
+     (normally ':' or ';'), the string is usually not a valid character
+     to use in normal directory names.)
+
+'line.separator'
+     The default line separator used on the platform (normally '\n',
+     '\r' or a combination of those two characters).
+
+'policy.provider'
+     The class name used for the default policy provider returned by
+     'java.security.Policy.getPolicy'.
+
+'user.name'
+     The name of the user running the program.  Can be the full name,
+     the login name or empty if unknown.
+
+'user.home'
+     The default directory to put user specific files in.
+
+'user.dir'
+     The current working directory from which the program was started.
+
+'user.language'
+     The default language as used by the 'java.util.Locale' class.
+
+'user.region'
+     The default region as used by the 'java.util.Local' class.
+
+'user.variant'
+     The default variant of the language and region local used.
+
+'user.timezone'
+     The default timezone as used by the 'java.util.TimeZone' class.
+
+'os.name'
+     The operating system/kernel name that the program runs on.
+
+'os.arch'
+     The hardware that we are running on.
+
+'os.version'
+     The version number of the operating system/kernel.
+
+'awt.appletWarning'
+     The string to display when an untrusted applet is displayed.
+     Returned by 'java.awt.Window.getWarningString()' when the window is
+     "insecure".
+
+'awt.toolkit'
+     The class name used for initializing the default
+     'java.awt.Toolkit'.  Defaults to 'gnu.awt.gtk.GtkToolkit'.
+
+'http.proxyHost'
+     Name of proxy host for http connections.
+
+'http.proxyPort'
+     Port number to use when a proxy host is in use.
+
+
+File: gcj.info,  Node: GNU Classpath Properties,  Next: libgcj Runtime Properties,  Prev: Standard Properties,  Up: System properties
+
+12.2 GNU Classpath Properties
+=============================
+
+'libgcj' is based on the GNU Classpath (Essential Libraries for Java) a
+GNU project to create free core class libraries for use with virtual
+machines and compilers for the Java language.  The following properties
+are common to libraries based on GNU Classpath.
+
+'gcj.dumpobject'
+     Enables printing serialization debugging by the
+     'java.io.ObjectInput' and 'java.io.ObjectOutput' classes when set
+     to something else then the empty string.  Only used when running a
+     debug build of the library.
+
+'gnu.classpath.vm.shortname'
+     This is a succinct name of the virtual machine.  For 'libgcj', this
+     will always be 'libgcj'.
+
+'gnu.classpath.home.url'
+     A base URL used for finding system property files (e.g.,
+     'classpath.security').  By default this is a 'file:' URL pointing
+     to the 'lib' directory under 'java.home'.
+
+
+File: gcj.info,  Node: libgcj Runtime Properties,  Prev: GNU Classpath Properties,  Up: System properties
+
+12.3 libgcj Runtime Properties
+==============================
+
+The following properties are specific to the 'libgcj' runtime and will
+normally not be found in other core libraries for the java language.
+
+'java.fullversion'
+     The combination of 'java.vm.name' and 'java.vm.version'.
+
+'java.vm.info'
+     Same as 'java.fullversion'.
+
+'impl.prefix'
+     Used by the 'java.net.DatagramSocket' class when set to something
+     else then the empty string.  When set all newly created
+     'DatagramSocket's will try to load a class
+     'java.net.[impl.prefix]DatagramSocketImpl' instead of the normal
+     'java.net.PlainDatagramSocketImpl'.
+
+'gnu.gcj.progname'
+     The class or binary name that was used to invoke the program.  This
+     will be the name of the "main" class in the case where the 'gij'
+     front end is used, or the program binary name in the case where an
+     application is compiled to a native binary.
+
+'gnu.gcj.user.realname'
+     The real name of the user, as taken from the password file.  This
+     may not always hold only the user's name (as some sites put extra
+     information in this field).  Also, this property is not available
+     on all platforms.
+
+'gnu.gcj.runtime.NameFinder.use_addr2line'
+     Whether an external process, 'addr2line', should be used to
+     determine line number information when tracing the stack.  Setting
+     this to 'false' may suppress line numbers when printing stack
+     traces and when using the java.util.logging infrastructure.
+     However, performance may improve significantly for applications
+     that print stack traces or make logging calls frequently.
+
+'gnu.gcj.runtime.NameFinder.show_raw'
+     Whether the address of a stack frame should be printed when the
+     line number is unavailable.  Setting this to 'true' will cause the
+     name of the object and the offset within that object to be printed
+     when no line number is available.  This allows for off-line
+     decoding of stack traces if necessary debug information is
+     available.  The default is 'false', no raw addresses are printed.
+
+'gnu.gcj.runtime.NameFinder.remove_unknown'
+     Whether stack frames for non-java code should be included in a
+     stack trace.  The default value is 'true', stack frames for
+     non-java code are suppressed.  Setting this to 'false' will cause
+     any non-java stack frames to be printed in addition to frames for
+     the java code.
+
+'gnu.gcj.runtime.VMClassLoader.library_control'
+     This controls how shared libraries are automatically loaded by the
+     built-in class loader.  If this property is set to 'full', a full
+     search is done for each requested class.  If this property is set
+     to 'cache', then any failed lookups are cached and not tried again.
+     If this property is set to 'never' (the default), then lookups are
+     never done.  For more information, *Note Extensions::.
+
+'gnu.gcj.runtime.endorsed.dirs'
+     This is like the standard 'java.endorsed.dirs', property, but
+     specifies some extra directories which are searched after the
+     standard endorsed directories.  This is primarily useful for
+     telling 'libgcj' about additional libraries which are ordinarily
+     incorporated into the JDK, and which should be loaded by the
+     bootstrap class loader, but which are not yet part of 'libgcj'
+     itself for some reason.
+
+'gnu.gcj.jit.compiler'
+     This is the full path to 'gcj' executable which should be used to
+     compile classes just-in-time when 'ClassLoader.defineClass' is
+     called.  If not set, 'gcj' will not be invoked by the runtime; this
+     can also be controlled via 'Compiler.disable'.
+
+'gnu.gcj.jit.options'
+     This is a space-separated string of options which should be passed
+     to 'gcj' when in JIT mode.  If not set, a sensible default is
+     chosen.
+
+'gnu.gcj.jit.cachedir'
+     This is the directory where cached shared library files are stored.
+     If not set, JIT compilation is disabled.  This should never be set
+     to a directory that is writable by any other user.
+
+'gnu.gcj.precompiled.db.path'
+     This is a sequence of file names, each referring to a file created
+     by 'gcj-dbtool'.  These files will be used by 'libgcj' to find
+     shared libraries corresponding to classes that are loaded from
+     bytecode.  'libgcj' often has a built-in default database; it can
+     be queried using 'gcj-dbtool -p'.
+
+
+File: gcj.info,  Node: Resources,  Next: Index,  Prev: System properties,  Up: Top
+
+13 Resources
+************
+
+While writing 'gcj' and 'libgcj' we have, of course, relied heavily on
+documentation from Sun Microsystems.  In particular we have used The
+Java Language Specification (both first and second editions), the Java
+Class Libraries (volumes one and two), and the Java Virtual Machine
+Specification.  In addition we've used Sun's online documentation.
+
+   The current 'gcj' home page is <http://gcc.gnu.org/java/>.
+
+   For more information on GCC, see <http://gcc.gnu.org/>.
+
+   Some 'libgcj' testing is done using the Mauve test suite.  This is a
+free software Java class library test suite which is being written
+because the JCK is not free.  See <http://www.sourceware.org/mauve/> for
+more information.
+
+
+File: gcj.info,  Node: Index,  Prev: Resources,  Up: Top
+
+Index
+*****
+
+
+* Menu:
+
+* class path:                            Input Options.        (line  6)
+* class$:                                Reference types.      (line 20)
+* elements on template<class T>:         Arrays.               (line 45)
+* FDL, GNU Free Documentation License:   GNU Free Documentation License.
+                                                               (line  6)
+* GCJ_PROPERTIES:                        Extensions.           (line 56)
+* GCJ_PROPERTIES <1>:                    Extensions.           (line 56)
+* jclass:                                Reference types.      (line 16)
+* jobject:                               Reference types.      (line 16)
+* jstring:                               Reference types.      (line 16)
+* JvAllocBytes:                          Mixing with C++.      (line 98)
+* JvAttachCurrentThread:                 Invocation.           (line 54)
+* JvCreateJavaVM:                        Invocation.           (line 10)
+* JvDetachCurrentThread:                 Invocation.           (line 68)
+* JvFree:                                Memory allocation.    (line 18)
+* JvGetArrayLength:                      Arrays.               (line 85)
+* JvGetStringChars:                      Strings.              (line 24)
+* JvGetStringUTFLength:                  Strings.              (line 28)
+* JvGetStringUTFRegion:                  Strings.              (line 32)
+* JvMalloc:                              Memory allocation.    (line 10)
+* JvNewBooleanArray:                     Arrays.               (line 82)
+* JvNewObjectArray:                      Arrays.               (line 55)
+* JvNewString:                           Strings.              (line 10)
+* JvNewStringLatin1:                     Strings.              (line 14)
+* JvNewStringLatin1 <1>:                 Strings.              (line 17)
+* JvNewStringUTF:                        Strings.              (line 20)
+* JvPrimClass:                           Primitive types.      (line 35)
+* JvRealloc:                             Memory allocation.    (line 14)
+
+
+
+Tag Table:
+Node: Top2678
+Node: Copying4097
+Node: GNU Free Documentation License41628
+Node: Invoking gcj66751
+Node: Input and output files67514
+Node: Input Options69036
+Node: Encodings72311
+Node: Warnings73517
+Node: Linking74630
+Node: Code Generation77563
+Node: Configure-time Options84339
+Node: Compatibility86079
+Node: Limitations86598
+Node: Extensions88176
+Node: Invoking jcf-dump91267
+Node: Invoking gij92212
+Node: Invoking gcj-dbtool95468
+Node: Invoking jv-convert97929
+Node: Invoking grmic99008
+Node: Invoking gc-analyze100394
+Node: Invoking aot-compile101835
+Node: Invoking rebuild-gcj-db102783
+Node: About CNI103093
+Node: Basic concepts104552
+Node: Packages107448
+Node: Primitive types109776
+Node: Reference types111453
+Node: Interfaces112537
+Node: Objects and Classes113448
+Node: Class Initialization115643
+Node: Object allocation117986
+Node: Memory allocation118776
+Node: Arrays119408
+Node: Methods122218
+Node: Strings125039
+Node: Mixing with C++126543
+Node: Exception Handling130016
+Node: Synchronization131651
+Node: Invocation133640
+Node: Reflection138592
+Node: System properties139050
+Node: Standard Properties139927
+Node: GNU Classpath Properties144358
+Node: libgcj Runtime Properties145404
+Node: Resources149907
+Node: Index150721
+
+End Tag Table
diff --git a/gcc-4.9/gcc/doc/gcov.1 b/gcc-4.9/gcc/doc/gcov.1
new file mode 100644
index 000000000..8de32cb85
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gcov.1
@@ -0,0 +1,733 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GCOV 1"
+.TH GCOV 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gcov \- coverage testing tool
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+gcov [\fB\-v\fR|\fB\-\-version\fR] [\fB\-h\fR|\fB\-\-help\fR]
+     [\fB\-a\fR|\fB\-\-all\-blocks\fR]
+     [\fB\-b\fR|\fB\-\-branch\-probabilities\fR]
+     [\fB\-c\fR|\fB\-\-branch\-counts\fR]
+     [\fB\-d\fR|\fB\-\-display\-progress\fR]
+     [\fB\-f\fR|\fB\-\-function\-summaries\fR]
+     [\fB\-i\fR|\fB\-\-intermediate\-format\fR]
+     [\fB\-l\fR|\fB\-\-long\-file\-names\fR]
+     [\fB\-m\fR|\fB\-\-demangled\-names\fR]
+     [\fB\-n\fR|\fB\-\-no\-output\fR]
+     [\fB\-o\fR|\fB\-\-object\-directory\fR \fIdirectory|file\fR]
+     [\fB\-p\fR|\fB\-\-preserve\-paths\fR]
+     [\fB\-r\fR|\fB\-\-relative\-only\fR]
+     [\fB\-s\fR|\fB\-\-source\-prefix\fR \fIdirectory\fR]
+     [\fB\-u\fR|\fB\-\-unconditional\-branches\fR]
+     \fIfiles\fR
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBgcov\fR is a test coverage program.  Use it in concert with \s-1GCC\s0
+to analyze your programs to help create more efficient, faster running
+code and to discover untested parts of your program.  You can use
+\&\fBgcov\fR as a profiling tool to help discover where your
+optimization efforts will best affect your code.  You can also use
+\&\fBgcov\fR along with the other profiling tool, \fBgprof\fR, to
+assess which parts of your code use the greatest amount of computing
+time.
+.PP
+Profiling tools help you analyze your code's performance.  Using a
+profiler such as \fBgcov\fR or \fBgprof\fR, you can find out some
+basic performance statistics, such as:
+.IP "\(bu" 4
+how often each line of code executes
+.IP "\(bu" 4
+what lines of code are actually executed
+.IP "\(bu" 4
+how much computing time each section of code uses
+.PP
+Once you know these things about how your code works when compiled, you
+can look at each module to see which modules should be optimized.
+\&\fBgcov\fR helps you determine where to work on optimization.
+.PP
+Software developers also use coverage testing in concert with
+testsuites, to make sure software is actually good enough for a release.
+Testsuites can verify that a program works as expected; a coverage
+program tests to see how much of the program is exercised by the
+testsuite.  Developers can then determine what kinds of test cases need
+to be added to the testsuites to create both better testing and a better
+final product.
+.PP
+You should compile your code without optimization if you plan to use
+\&\fBgcov\fR because the optimization, by combining some lines of code
+into one function, may not give you as much information as you need to
+look for `hot spots' where the code is using a great deal of computer
+time.  Likewise, because \fBgcov\fR accumulates statistics by line (at
+the lowest resolution), it works best with a programming style that
+places only one statement on each line.  If you use complicated macros
+that expand to loops or to other control structures, the statistics are
+less helpful\-\-\-they only report on the line where the macro call
+appears.  If your complex macros behave like functions, you can replace
+them with inline functions to solve this problem.
+.PP
+\&\fBgcov\fR creates a logfile called \fI\fIsourcefile\fI.gcov\fR which
+indicates how many times each line of a source file \fI\fIsourcefile\fI.c\fR
+has executed.  You can use these logfiles along with \fBgprof\fR to aid
+in fine-tuning the performance of your programs.  \fBgprof\fR gives
+timing information you can use along with the information you get from
+\&\fBgcov\fR.
+.PP
+\&\fBgcov\fR works only on code compiled with \s-1GCC. \s0 It is not
+compatible with any other profiling or test coverage mechanism.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-h\fR" 4
+.IX Item "-h"
+.PD 0
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+.PD
+Display help about using \fBgcov\fR (on the standard output), and
+exit without doing any further processing.
+.IP "\fB\-v\fR" 4
+.IX Item "-v"
+.PD 0
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+.PD
+Display the \fBgcov\fR version number (on the standard output),
+and exit without doing any further processing.
+.IP "\fB\-a\fR" 4
+.IX Item "-a"
+.PD 0
+.IP "\fB\-\-all\-blocks\fR" 4
+.IX Item "--all-blocks"
+.PD
+Write individual execution counts for every basic block.  Normally gcov
+outputs execution counts only for the main blocks of a line.  With this
+option you can determine if blocks within a single line are not being
+executed.
+.IP "\fB\-b\fR" 4
+.IX Item "-b"
+.PD 0
+.IP "\fB\-\-branch\-probabilities\fR" 4
+.IX Item "--branch-probabilities"
+.PD
+Write branch frequencies to the output file, and write branch summary
+info to the standard output.  This option allows you to see how often
+each branch in your program was taken.  Unconditional branches will not
+be shown, unless the \fB\-u\fR option is given.
+.IP "\fB\-c\fR" 4
+.IX Item "-c"
+.PD 0
+.IP "\fB\-\-branch\-counts\fR" 4
+.IX Item "--branch-counts"
+.PD
+Write branch frequencies as the number of branches taken, rather than
+the percentage of branches taken.
+.IP "\fB\-n\fR" 4
+.IX Item "-n"
+.PD 0
+.IP "\fB\-\-no\-output\fR" 4
+.IX Item "--no-output"
+.PD
+Do not create the \fBgcov\fR output file.
+.IP "\fB\-l\fR" 4
+.IX Item "-l"
+.PD 0
+.IP "\fB\-\-long\-file\-names\fR" 4
+.IX Item "--long-file-names"
+.PD
+Create long file names for included source files.  For example, if the
+header file \fIx.h\fR contains code, and was included in the file
+\&\fIa.c\fR, then running \fBgcov\fR on the file \fIa.c\fR will
+produce an output file called \fIa.c##x.h.gcov\fR instead of
+\&\fIx.h.gcov\fR.  This can be useful if \fIx.h\fR is included in
+multiple source files and you want to see the individual
+contributions.  If you use the \fB\-p\fR option, both the including
+and included file names will be complete path names.
+.IP "\fB\-p\fR" 4
+.IX Item "-p"
+.PD 0
+.IP "\fB\-\-preserve\-paths\fR" 4
+.IX Item "--preserve-paths"
+.PD
+Preserve complete path information in the names of generated
+\&\fI.gcov\fR files.  Without this option, just the filename component is
+used.  With this option, all directories are used, with \fB/\fR characters
+translated to \fB#\fR characters, \fI.\fR directory components
+removed and unremoveable \fI..\fR
+components renamed to \fB^\fR.  This is useful if sourcefiles are in several
+different directories.
+.IP "\fB\-r\fR" 4
+.IX Item "-r"
+.PD 0
+.IP "\fB\-\-relative\-only\fR" 4
+.IX Item "--relative-only"
+.PD
+Only output information about source files with a relative pathname
+(after source prefix elision).  Absolute paths are usually system
+header files and coverage of any inline functions therein is normally
+uninteresting.
+.IP "\fB\-f\fR" 4
+.IX Item "-f"
+.PD 0
+.IP "\fB\-\-function\-summaries\fR" 4
+.IX Item "--function-summaries"
+.PD
+Output summaries for each function in addition to the file level summary.
+.IP "\fB\-o\fR \fIdirectory|file\fR" 4
+.IX Item "-o directory|file"
+.PD 0
+.IP "\fB\-\-object\-directory\fR \fIdirectory\fR" 4
+.IX Item "--object-directory directory"
+.IP "\fB\-\-object\-file\fR \fIfile\fR" 4
+.IX Item "--object-file file"
+.PD
+Specify either the directory containing the gcov data files, or the
+object path name.  The \fI.gcno\fR, and
+\&\fI.gcda\fR data files are searched for using this option.  If a directory
+is specified, the data files are in that directory and named after the
+input file name, without its extension.  If a file is specified here,
+the data files are named after that file, without its extension.
+.IP "\fB\-s\fR \fIdirectory\fR" 4
+.IX Item "-s directory"
+.PD 0
+.IP "\fB\-\-source\-prefix\fR \fIdirectory\fR" 4
+.IX Item "--source-prefix directory"
+.PD
+A prefix for source file names to remove when generating the output
+coverage files.  This option is useful when building in a separate
+directory, and the pathname to the source directory is not wanted when
+determining the output file names.  Note that this prefix detection is
+applied before determining whether the source file is absolute.
+.IP "\fB\-u\fR" 4
+.IX Item "-u"
+.PD 0
+.IP "\fB\-\-unconditional\-branches\fR" 4
+.IX Item "--unconditional-branches"
+.PD
+When branch probabilities are given, include those of unconditional branches.
+Unconditional branches are normally not interesting.
+.IP "\fB\-d\fR" 4
+.IX Item "-d"
+.PD 0
+.IP "\fB\-\-display\-progress\fR" 4
+.IX Item "--display-progress"
+.PD
+Display the progress on the standard output.
+.IP "\fB\-i\fR" 4
+.IX Item "-i"
+.PD 0
+.IP "\fB\-\-intermediate\-format\fR" 4
+.IX Item "--intermediate-format"
+.PD
+Output gcov file in an easy-to-parse intermediate text format that can
+be used by \fBlcov\fR or other tools. The output is a single
+\&\fI.gcov\fR file per \fI.gcda\fR file. No source code is required.
+.Sp
+The format of the intermediate \fI.gcov\fR file is plain text with
+one entry per line
+.Sp
+.Vb 4
+\&        file:<source_file_name>
+\&        function:<line_number>,<execution_count>,<function_name>
+\&        lcount:<line number>,<execution_count>
+\&        branch:<line_number>,<branch_coverage_type>
+\&        
+\&        Where the <branch_coverage_type> is
+\&           notexec (Branch not executed)
+\&           taken (Branch executed and taken)
+\&           nottaken (Branch executed, but not taken)
+\&        
+\&        There can be multiple <file> entries in an intermediate gcov
+\&        file. All entries following a <file> pertain to that source file
+\&        until the next <file> entry.
+.Ve
+.Sp
+Here is a sample when \fB\-i\fR is used in conjunction with \fB\-b\fR option:
+.Sp
+.Vb 9
+\&        file:array.cc
+\&        function:11,1,_Z3sumRKSt6vectorIPiSaIS0_EE
+\&        function:22,1,main
+\&        lcount:11,1
+\&        lcount:12,1
+\&        lcount:14,1
+\&        branch:14,taken
+\&        lcount:26,1
+\&        branch:28,nottaken
+.Ve
+.IP "\fB\-m\fR" 4
+.IX Item "-m"
+.PD 0
+.IP "\fB\-\-demangled\-names\fR" 4
+.IX Item "--demangled-names"
+.PD
+Display demangled function names in output. The default is to show
+mangled function names.
+.PP
+\&\fBgcov\fR should be run with the current directory the same as that
+when you invoked the compiler.  Otherwise it will not be able to locate
+the source files.  \fBgcov\fR produces files called
+\&\fI\fImangledname\fI.gcov\fR in the current directory.  These contain
+the coverage information of the source file they correspond to.
+One \fI.gcov\fR file is produced for each source (or header) file
+containing code,
+which was compiled to produce the data files.  The \fImangledname\fR part
+of the output file name is usually simply the source file name, but can
+be something more complicated if the \fB\-l\fR or \fB\-p\fR options are
+given.  Refer to those options for details.
+.PP
+If you invoke \fBgcov\fR with multiple input files, the
+contributions from each input file are summed.  Typically you would
+invoke it with the same list of files as the final link of your executable.
+.PP
+The \fI.gcov\fR files contain the \fB:\fR separated fields along with
+program source code.  The format is
+.PP
+.Vb 1
+\&        <execution_count>:<line_number>:<source line text>
+.Ve
+.PP
+Additional block information may succeed each line, when requested by
+command line option.  The \fIexecution_count\fR is \fB\-\fR for lines
+containing no code.  Unexecuted lines are marked \fB#####\fR or
+\&\fB====\fR, depending on whether they are reachable by
+non-exceptional paths or only exceptional paths such as \*(C+ exception
+handlers, respectively.
+.PP
+Some lines of information at the start have \fIline_number\fR of zero.
+These preamble lines are of the form
+.PP
+.Vb 1
+\&        \-:0:<tag>:<value>
+.Ve
+.PP
+The ordering and number of these preamble lines will be augmented as
+\&\fBgcov\fR development progresses \-\-\- do not rely on them remaining
+unchanged.  Use \fItag\fR to locate a particular preamble line.
+.PP
+The additional block information is of the form
+.PP
+.Vb 1
+\&        <tag> <information>
+.Ve
+.PP
+The \fIinformation\fR is human readable, but designed to be simple
+enough for machine parsing too.
+.PP
+When printing percentages, 0% and 100% are only printed when the values
+are \fIexactly\fR 0% and 100% respectively.  Other values which would
+conventionally be rounded to 0% or 100% are instead printed as the
+nearest non-boundary value.
+.PP
+When using \fBgcov\fR, you must first compile your program with two
+special \s-1GCC\s0 options: \fB\-fprofile\-arcs \-ftest\-coverage\fR.
+This tells the compiler to generate additional information needed by
+gcov (basically a flow graph of the program) and also includes
+additional code in the object files for generating the extra profiling
+information needed by gcov.  These additional files are placed in the
+directory where the object file is located.
+.PP
+Running the program will cause profile output to be generated.  For each
+source file compiled with \fB\-fprofile\-arcs\fR, an accompanying
+\&\fI.gcda\fR file will be placed in the object file directory.
+.PP
+Running \fBgcov\fR with your program's source file names as arguments
+will now produce a listing of the code along with frequency of execution
+for each line.  For example, if your program is called \fItmp.c\fR, this
+is what you see when you use the basic \fBgcov\fR facility:
+.PP
+.Vb 5
+\&        $ gcc \-fprofile\-arcs \-ftest\-coverage tmp.c
+\&        $ a.out
+\&        $ gcov tmp.c
+\&        90.00% of 10 source lines executed in file tmp.c
+\&        Creating tmp.c.gcov.
+.Ve
+.PP
+The file \fItmp.c.gcov\fR contains output from \fBgcov\fR.
+Here is a sample:
+.PP
+.Vb 10
+\&                \-:    0:Source:tmp.c
+\&                \-:    0:Graph:tmp.gcno
+\&                \-:    0:Data:tmp.gcda
+\&                \-:    0:Runs:1
+\&                \-:    0:Programs:1
+\&                \-:    1:#include <stdio.h>
+\&                \-:    2:
+\&                \-:    3:int main (void)
+\&                1:    4:{
+\&                1:    5:  int i, total;
+\&                \-:    6:
+\&                1:    7:  total = 0;
+\&                \-:    8:
+\&               11:    9:  for (i = 0; i < 10; i++)
+\&               10:   10:    total += i;
+\&                \-:   11:
+\&                1:   12:  if (total != 45)
+\&            #####:   13:    printf ("Failure\en");
+\&                \-:   14:  else
+\&                1:   15:    printf ("Success\en");
+\&                1:   16:  return 0;
+\&                \-:   17:}
+.Ve
+.PP
+When you use the \fB\-a\fR option, you will get individual block
+counts, and the output looks like this:
+.PP
+.Vb 10
+\&                \-:    0:Source:tmp.c
+\&                \-:    0:Graph:tmp.gcno
+\&                \-:    0:Data:tmp.gcda
+\&                \-:    0:Runs:1
+\&                \-:    0:Programs:1
+\&                \-:    1:#include <stdio.h>
+\&                \-:    2:
+\&                \-:    3:int main (void)
+\&                1:    4:{
+\&                1:    4\-block  0
+\&                1:    5:  int i, total;
+\&                \-:    6:
+\&                1:    7:  total = 0;
+\&                \-:    8:
+\&               11:    9:  for (i = 0; i < 10; i++)
+\&               11:    9\-block  0
+\&               10:   10:    total += i;
+\&               10:   10\-block  0
+\&                \-:   11:
+\&                1:   12:  if (total != 45)
+\&                1:   12\-block  0
+\&            #####:   13:    printf ("Failure\en");
+\&            $$$$$:   13\-block  0
+\&                \-:   14:  else
+\&                1:   15:    printf ("Success\en");
+\&                1:   15\-block  0
+\&                1:   16:  return 0;
+\&                1:   16\-block  0
+\&                \-:   17:}
+.Ve
+.PP
+In this mode, each basic block is only shown on one line \*(-- the last
+line of the block.  A multi-line block will only contribute to the
+execution count of that last line, and other lines will not be shown
+to contain code, unless previous blocks end on those lines.
+The total execution count of a line is shown and subsequent lines show
+the execution counts for individual blocks that end on that line.  After each
+block, the branch and call counts of the block will be shown, if the
+\&\fB\-b\fR option is given.
+.PP
+Because of the way \s-1GCC\s0 instruments calls, a call count can be shown
+after a line with no individual blocks.
+As you can see, line 13 contains a basic block that was not executed.
+.PP
+When you use the \fB\-b\fR option, your output looks like this:
+.PP
+.Vb 6
+\&        $ gcov \-b tmp.c
+\&        90.00% of 10 source lines executed in file tmp.c
+\&        80.00% of 5 branches executed in file tmp.c
+\&        80.00% of 5 branches taken at least once in file tmp.c
+\&        50.00% of 2 calls executed in file tmp.c
+\&        Creating tmp.c.gcov.
+.Ve
+.PP
+Here is a sample of a resulting \fItmp.c.gcov\fR file:
+.PP
+.Vb 10
+\&                \-:    0:Source:tmp.c
+\&                \-:    0:Graph:tmp.gcno
+\&                \-:    0:Data:tmp.gcda
+\&                \-:    0:Runs:1
+\&                \-:    0:Programs:1
+\&                \-:    1:#include <stdio.h>
+\&                \-:    2:
+\&                \-:    3:int main (void)
+\&        function main called 1 returned 1 blocks executed 75%
+\&                1:    4:{
+\&                1:    5:  int i, total;
+\&                \-:    6:
+\&                1:    7:  total = 0;
+\&                \-:    8:
+\&               11:    9:  for (i = 0; i < 10; i++)
+\&        branch  0 taken 91% (fallthrough)
+\&        branch  1 taken 9%
+\&               10:   10:    total += i;
+\&                \-:   11:
+\&                1:   12:  if (total != 45)
+\&        branch  0 taken 0% (fallthrough)
+\&        branch  1 taken 100%
+\&            #####:   13:    printf ("Failure\en");
+\&        call    0 never executed
+\&                \-:   14:  else
+\&                1:   15:    printf ("Success\en");
+\&        call    0 called 1 returned 100%
+\&                1:   16:  return 0;
+\&                \-:   17:}
+.Ve
+.PP
+For each function, a line is printed showing how many times the function
+is called, how many times it returns and what percentage of the
+function's blocks were executed.
+.PP
+For each basic block, a line is printed after the last line of the basic
+block describing the branch or call that ends the basic block.  There can
+be multiple branches and calls listed for a single source line if there
+are multiple basic blocks that end on that line.  In this case, the
+branches and calls are each given a number.  There is no simple way to map
+these branches and calls back to source constructs.  In general, though,
+the lowest numbered branch or call will correspond to the leftmost construct
+on the source line.
+.PP
+For a branch, if it was executed at least once, then a percentage
+indicating the number of times the branch was taken divided by the
+number of times the branch was executed will be printed.  Otherwise, the
+message \*(L"never executed\*(R" is printed.
+.PP
+For a call, if it was executed at least once, then a percentage
+indicating the number of times the call returned divided by the number
+of times the call was executed will be printed.  This will usually be
+100%, but may be less for functions that call \f(CW\*(C`exit\*(C'\fR or \f(CW\*(C`longjmp\*(C'\fR,
+and thus may not return every time they are called.
+.PP
+The execution counts are cumulative.  If the example program were
+executed again without removing the \fI.gcda\fR file, the count for the
+number of times each line in the source was executed would be added to
+the results of the previous run(s).  This is potentially useful in
+several ways.  For example, it could be used to accumulate data over a
+number of program runs as part of a test verification suite, or to
+provide more accurate long-term information over a large number of
+program runs.
+.PP
+The data in the \fI.gcda\fR files is saved immediately before the program
+exits.  For each source file compiled with \fB\-fprofile\-arcs\fR, the
+profiling code first attempts to read in an existing \fI.gcda\fR file; if
+the file doesn't match the executable (differing number of basic block
+counts) it will ignore the contents of the file.  It then adds in the
+new execution counts and finally writes the data to the file.
+.SS "Using \fBgcov\fP with \s-1GCC\s0 Optimization"
+.IX Subsection "Using gcov with GCC Optimization"
+If you plan to use \fBgcov\fR to help optimize your code, you must
+first compile your program with two special \s-1GCC\s0 options:
+\&\fB\-fprofile\-arcs \-ftest\-coverage\fR.  Aside from that, you can use any
+other \s-1GCC\s0 options; but if you want to prove that every single line
+in your program was executed, you should not compile with optimization
+at the same time.  On some machines the optimizer can eliminate some
+simple code lines by combining them with other lines.  For example, code
+like this:
+.PP
+.Vb 4
+\&        if (a != b)
+\&          c = 1;
+\&        else
+\&          c = 0;
+.Ve
+.PP
+can be compiled into one instruction on some machines.  In this case,
+there is no way for \fBgcov\fR to calculate separate execution counts
+for each line because there isn't separate code for each line.  Hence
+the \fBgcov\fR output looks like this if you compiled the program with
+optimization:
+.PP
+.Vb 4
+\&              100:   12:if (a != b)
+\&              100:   13:  c = 1;
+\&              100:   14:else
+\&              100:   15:  c = 0;
+.Ve
+.PP
+The output shows that this block of code, combined by optimization,
+executed 100 times.  In one sense this result is correct, because there
+was only one instruction representing all four of these lines.  However,
+the output does not indicate how many times the result was 0 and how
+many times the result was 1.
+.PP
+Inlineable functions can create unexpected line counts.  Line counts are
+shown for the source code of the inlineable function, but what is shown
+depends on where the function is inlined, or if it is not inlined at all.
+.PP
+If the function is not inlined, the compiler must emit an out of line
+copy of the function, in any object file that needs it.  If
+\&\fIfileA.o\fR and \fIfileB.o\fR both contain out of line bodies of a
+particular inlineable function, they will also both contain coverage
+counts for that function.  When \fIfileA.o\fR and \fIfileB.o\fR are
+linked together, the linker will, on many systems, select one of those
+out of line bodies for all calls to that function, and remove or ignore
+the other.  Unfortunately, it will not remove the coverage counters for
+the unused function body.  Hence when instrumented, all but one use of
+that function will show zero counts.
+.PP
+If the function is inlined in several places, the block structure in
+each location might not be the same.  For instance, a condition might
+now be calculable at compile time in some instances.  Because the
+coverage of all the uses of the inline function will be shown for the
+same source lines, the line counts themselves might seem inconsistent.
+.PP
+Long-running applications can use the \f(CW\*(C`_gcov_reset\*(C'\fR and \f(CW\*(C`_gcov_dump\*(C'\fR
+facilities to restrict profile collection to the program region of
+interest. Calling \f(CW\*(C`_gcov_reset(void)\*(C'\fR will clear all profile counters
+to zero, and calling \f(CW\*(C`_gcov_dump(void)\*(C'\fR will cause the profile information
+collected at that point to be dumped to \fI.gcda\fR output files.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7), \fIgcc\fR\|(1) and the Info entry for \fIgcc\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 1996\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being \*(L"\s-1GNU\s0 General Public License\*(R" and \*(L"Funding
+Free Software\*(R", 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 \fIgfdl\fR\|(7) man page.
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/generic.texi b/gcc-4.9/gcc/doc/generic.texi
index e85fa1d04..5b3b528e5 100644
--- a/gcc-4.9/gcc/doc/generic.texi
+++ b/gcc-4.9/gcc/doc/generic.texi
@@ -13,7 +13,7 @@
 The purpose of GENERIC is simply to provide a
 language-independent way of representing an entire function in
 trees.  To this end, it was necessary to add a few new tree codes
-to the back end, but most everything was already there.  If you
+to the back end, but almost everything was already there.  If you
 can express it with the codes in @code{gcc/tree.def}, it's
 GENERIC@.
 
@@ -203,7 +203,7 @@ operands, each of which is also a tree.
 @tindex IDENTIFIER_NODE
 
 An @code{IDENTIFIER_NODE} represents a slightly more general concept
-that the standard C or C++ concept of identifier.  In particular, an
+than the standard C or C++ concept of identifier.  In particular, an
 @code{IDENTIFIER_NODE} may contain a @samp{$}, or other extraordinary
 characters.
 
diff --git a/gcc-4.9/gcc/doc/gfdl.7 b/gcc-4.9/gcc/doc/gfdl.7
new file mode 100644
index 000000000..9788f7023
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gfdl.7
@@ -0,0 +1 @@
+timestamp
diff --git a/gcc-4.9/gcc/doc/gfortran.1 b/gcc-4.9/gcc/doc/gfortran.1
new file mode 100644
index 000000000..285fdafd7
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gfortran.1
@@ -0,0 +1,1411 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GFORTRAN 1"
+.TH GFORTRAN 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gfortran \- GNU Fortran compiler
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+gfortran [\fB\-c\fR|\fB\-S\fR|\fB\-E\fR]
+         [\fB\-g\fR] [\fB\-pg\fR] [\fB\-O\fR\fIlevel\fR]
+         [\fB\-W\fR\fIwarn\fR...] [\fB\-pedantic\fR]
+         [\fB\-I\fR\fIdir\fR...] [\fB\-L\fR\fIdir\fR...]
+         [\fB\-D\fR\fImacro\fR[=\fIdefn\fR]...] [\fB\-U\fR\fImacro\fR]
+         [\fB\-f\fR\fIoption\fR...]
+         [\fB\-m\fR\fImachine-option\fR...]
+         [\fB\-o\fR \fIoutfile\fR] \fIinfile\fR...
+.PP
+Only the most useful options are listed here; see below for the
+remainder.
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+The \fBgfortran\fR command supports all the options supported by the
+\&\fBgcc\fR command.  Only options specific to \s-1GNU\s0 Fortran are documented
+here.
+.PP
+All \s-1GCC\s0 and \s-1GNU\s0 Fortran options
+are accepted both by \fBgfortran\fR and by \fBgcc\fR
+(as well as any other drivers built at the same time,
+such as \fBg++\fR),
+since adding \s-1GNU\s0 Fortran to the \s-1GCC\s0 distribution
+enables acceptance of \s-1GNU\s0 Fortran options
+by all of the relevant drivers.
+.PP
+In some cases, options have positive and negative forms;
+the negative form of \fB\-ffoo\fR would be \fB\-fno\-foo\fR.
+This manual documents only one of these two forms, whichever
+one is not the default.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+Here is a summary of all the options specific to \s-1GNU\s0 Fortran, grouped
+by type.  Explanations are in the following sections.
+.IP "\fIFortran Language Options\fR" 4
+.IX Item "Fortran Language Options"
+\&\fB\-fall\-intrinsics \-fbackslash \-fcray\-pointer \-fd\-lines\-as\-code 
+\&\-fd\-lines\-as\-comments \-fdefault\-double\-8 \-fdefault\-integer\-8 
+\&\-fdefault\-real\-8 \-fdollar\-ok \-ffixed\-line\-length\-\fR\fIn\fR 
+\&\fB\-ffixed\-line\-length\-none \-ffree\-form \-ffree\-line\-length\-\fR\fIn\fR 
+\&\fB\-ffree\-line\-length\-none \-fimplicit\-none \-finteger\-4\-integer\-8 
+\&\-fmax\-identifier\-length \-fmodule\-private \-fno\-fixed\-form \-fno\-range\-check 
+\&\-fopenmp \-freal\-4\-real\-10 \-freal\-4\-real\-16 \-freal\-4\-real\-8 
+\&\-freal\-8\-real\-10 \-freal\-8\-real\-16 \-freal\-8\-real\-4 \-std=\fR\fIstd\fR\fB \fR
+.IP "\fIPreprocessing Options\fR" 4
+.IX Item "Preprocessing Options"
+\&\fB\-A\-\fR\fIquestion\fR[\fB=\fR\fIanswer\fR]
+\&\fB\-A\fR\fIquestion\fR\fB=\fR\fIanswer\fR \fB\-C \-CC \-D\fR\fImacro\fR[\fB=\fR\fIdefn\fR]
+\&\fB\-H \-P 
+\&\-U\fR\fImacro\fR \fB\-cpp \-dD \-dI \-dM \-dN \-dU \-fworking\-directory
+\&\-imultilib\fR \fIdir\fR 
+\&\fB\-iprefix\fR \fIfile\fR \fB\-iquote \-isysroot\fR \fIdir\fR \fB\-isystem\fR \fIdir\fR \fB\-nocpp 
+\&\-nostdinc 
+\&\-undef\fR
+.IP "\fIError and Warning Options\fR" 4
+.IX Item "Error and Warning Options"
+\&\fB\-Waliasing \-Wall \-Wampersand \-Warray\-bounds
+\&\-Wc\-binding\-type \-Wcharacter\-truncation 
+\&\-Wconversion \-Wfunction\-elimination \-Wimplicit\-interface 
+\&\-Wimplicit\-procedure \-Wintrinsic\-shadow \-Wintrinsics\-std 
+\&\-Wline\-truncation \-Wno\-align\-commons \-Wno\-tabs \-Wreal\-q\-constant 
+\&\-Wsurprising \-Wunderflow \-Wunused\-parameter \-Wrealloc\-lhs \-Wrealloc\-lhs\-all 
+\&\-Wtarget\-lifetime \-fmax\-errors=\fR\fIn\fR \fB\-fsyntax\-only \-pedantic \-pedantic\-errors\fR
+.IP "\fIDebugging Options\fR" 4
+.IX Item "Debugging Options"
+\&\fB\-fbacktrace \-fdump\-fortran\-optimized \-fdump\-fortran\-original 
+\&\-fdump\-parse\-tree \-ffpe\-trap=\fR\fIlist\fR \fB\-ffpe\-summary=\fR\fIlist\fR\fB \fR
+.IP "\fIDirectory Options\fR" 4
+.IX Item "Directory Options"
+\&\fB\-I\fR\fIdir\fR  \fB\-J\fR\fIdir\fR \fB\-fintrinsic\-modules\-path\fR \fIdir\fR
+.IP "\fILink Options\fR" 4
+.IX Item "Link Options"
+\&\fB\-static\-libgfortran\fR
+.IP "\fIRuntime Options\fR" 4
+.IX Item "Runtime Options"
+\&\fB\-fconvert=\fR\fIconversion\fR \fB\-fmax\-subrecord\-length=\fR\fIlength\fR 
+\&\fB\-frecord\-marker=\fR\fIlength\fR \fB\-fsign\-zero\fR
+.IP "\fICode Generation Options\fR" 4
+.IX Item "Code Generation Options"
+\&\fB\-faggressive\-function\-elimination \-fblas\-matmul\-limit=\fR\fIn\fR 
+\&\fB\-fbounds\-check \-fcheck\-array\-temporaries 
+\&\-fcheck=\fR\fI<all|array\-temps|bounds|do|mem|pointer|recursion>\fR 
+\&\fB\-fcoarray=\fR\fI<none|single|lib>\fR \fB\-fexternal\-blas \-ff2c
+\&\-ffrontend\-optimize 
+\&\-finit\-character=\fR\fIn\fR \fB\-finit\-integer=\fR\fIn\fR \fB\-finit\-local\-zero 
+\&\-finit\-logical=\fR\fI<true|false>\fR
+\&\fB\-finit\-real=\fR\fI<zero|inf|\-inf|nan|snan>\fR 
+\&\fB\-fmax\-array\-constructor=\fR\fIn\fR \fB\-fmax\-stack\-var\-size=\fR\fIn\fR
+\&\fB\-fno\-align\-commons 
+\&\-fno\-automatic \-fno\-protect\-parens \-fno\-underscoring 
+\&\-fsecond\-underscore \-fpack\-derived \-frealloc\-lhs \-frecursive 
+\&\-frepack\-arrays \-fshort\-enums \-fstack\-arrays\fR
+.SS "Options controlling Fortran dialect"
+.IX Subsection "Options controlling Fortran dialect"
+The following options control the details of the Fortran dialect
+accepted by the compiler:
+.IP "\fB\-ffree\-form\fR" 4
+.IX Item "-ffree-form"
+.PD 0
+.IP "\fB\-ffixed\-form\fR" 4
+.IX Item "-ffixed-form"
+.PD
+Specify the layout used by the source file.  The free form layout
+was introduced in Fortran 90.  Fixed form was traditionally used in
+older Fortran programs.  When neither option is specified, the source
+form is determined by the file extension.
+.IP "\fB\-fall\-intrinsics\fR" 4
+.IX Item "-fall-intrinsics"
+This option causes all intrinsic procedures (including the GNU-specific
+extensions) to be accepted.  This can be useful with \fB\-std=f95\fR to
+force standard-compliance but get access to the full range of intrinsics
+available with \fBgfortran\fR.  As a consequence, \fB\-Wintrinsics\-std\fR
+will be ignored and no user-defined procedure with the same name as any
+intrinsic will be called except when it is explicitly declared \f(CW\*(C`EXTERNAL\*(C'\fR.
+.IP "\fB\-fd\-lines\-as\-code\fR" 4
+.IX Item "-fd-lines-as-code"
+.PD 0
+.IP "\fB\-fd\-lines\-as\-comments\fR" 4
+.IX Item "-fd-lines-as-comments"
+.PD
+Enable special treatment for lines beginning with \f(CW\*(C`d\*(C'\fR or \f(CW\*(C`D\*(C'\fR
+in fixed form sources.  If the \fB\-fd\-lines\-as\-code\fR option is
+given they are treated as if the first column contained a blank.  If the
+\&\fB\-fd\-lines\-as\-comments\fR option is given, they are treated as
+comment lines.
+.IP "\fB\-fdollar\-ok\fR" 4
+.IX Item "-fdollar-ok"
+Allow \fB$\fR as a valid non-first character in a symbol name. Symbols 
+that start with \fB$\fR are rejected since it is unclear which rules to
+apply to implicit typing as different vendors implement different rules.
+Using \fB$\fR in \f(CW\*(C`IMPLICIT\*(C'\fR statements is also rejected.
+.IP "\fB\-fbackslash\fR" 4
+.IX Item "-fbackslash"
+Change the interpretation of backslashes in string literals from a single
+backslash character to \*(L"C\-style\*(R" escape characters. The following
+combinations are expanded \f(CW\*(C`\ea\*(C'\fR, \f(CW\*(C`\eb\*(C'\fR, \f(CW\*(C`\ef\*(C'\fR, \f(CW\*(C`\en\*(C'\fR,
+\&\f(CW\*(C`\er\*(C'\fR, \f(CW\*(C`\et\*(C'\fR, \f(CW\*(C`\ev\*(C'\fR, \f(CW\*(C`\e\e\*(C'\fR, and \f(CW\*(C`\e0\*(C'\fR to the \s-1ASCII\s0
+characters alert, backspace, form feed, newline, carriage return,
+horizontal tab, vertical tab, backslash, and \s-1NUL,\s0 respectively.
+Additionally, \f(CW\*(C`\ex\*(C'\fR\fInn\fR, \f(CW\*(C`\eu\*(C'\fR\fInnnn\fR and
+\&\f(CW\*(C`\eU\*(C'\fR\fInnnnnnnn\fR (where each \fIn\fR is a hexadecimal digit) are
+translated into the Unicode characters corresponding to the specified code
+points. All other combinations of a character preceded by \e are
+unexpanded.
+.IP "\fB\-fmodule\-private\fR" 4
+.IX Item "-fmodule-private"
+Set the default accessibility of module entities to \f(CW\*(C`PRIVATE\*(C'\fR.
+Use-associated entities will not be accessible unless they are explicitly
+declared as \f(CW\*(C`PUBLIC\*(C'\fR.
+.IP "\fB\-ffixed\-line\-length\-\fR\fIn\fR" 4
+.IX Item "-ffixed-line-length-n"
+Set column after which characters are ignored in typical fixed-form
+lines in the source file, and through which spaces are assumed (as
+if padded to that length) after the ends of short fixed-form lines.
+.Sp
+Popular values for \fIn\fR include 72 (the
+standard and the default), 80 (card image), and 132 (corresponding
+to \*(L"extended-source\*(R" options in some popular compilers).
+\&\fIn\fR may also be \fBnone\fR, meaning that the entire line is meaningful
+and that continued character constants never have implicit spaces appended
+to them to fill out the line.
+\&\fB\-ffixed\-line\-length\-0\fR means the same thing as
+\&\fB\-ffixed\-line\-length\-none\fR.
+.IP "\fB\-ffree\-line\-length\-\fR\fIn\fR" 4
+.IX Item "-ffree-line-length-n"
+Set column after which characters are ignored in typical free-form
+lines in the source file. The default value is 132.
+\&\fIn\fR may be \fBnone\fR, meaning that the entire line is meaningful.
+\&\fB\-ffree\-line\-length\-0\fR means the same thing as
+\&\fB\-ffree\-line\-length\-none\fR.
+.IP "\fB\-fmax\-identifier\-length=\fR\fIn\fR" 4
+.IX Item "-fmax-identifier-length=n"
+Specify the maximum allowed identifier length. Typical values are
+31 (Fortran 95) and 63 (Fortran 2003 and Fortran 2008).
+.IP "\fB\-fimplicit\-none\fR" 4
+.IX Item "-fimplicit-none"
+Specify that no implicit typing is allowed, unless overridden by explicit
+\&\f(CW\*(C`IMPLICIT\*(C'\fR statements.  This is the equivalent of adding
+\&\f(CW\*(C`implicit none\*(C'\fR to the start of every procedure.
+.IP "\fB\-fcray\-pointer\fR" 4
+.IX Item "-fcray-pointer"
+Enable the Cray pointer extension, which provides C\-like pointer
+functionality.
+.IP "\fB\-fopenmp\fR" 4
+.IX Item "-fopenmp"
+Enable the OpenMP extensions.  This includes OpenMP \f(CW\*(C`!$omp\*(C'\fR directives
+in free form
+and \f(CW\*(C`c$omp\*(C'\fR, \f(CW*$omp\fR and \f(CW\*(C`!$omp\*(C'\fR directives in fixed form,
+\&\f(CW\*(C`!$\*(C'\fR conditional compilation sentinels in free form
+and \f(CW\*(C`c$\*(C'\fR, \f(CW\*(C`*$\*(C'\fR and \f(CW\*(C`!$\*(C'\fR sentinels in fixed form, 
+and when linking arranges for the OpenMP runtime library to be linked
+in.  The option \fB\-fopenmp\fR implies \fB\-frecursive\fR.
+.IP "\fB\-fno\-range\-check\fR" 4
+.IX Item "-fno-range-check"
+Disable range checking on results of simplification of constant
+expressions during compilation.  For example, \s-1GNU\s0 Fortran will give
+an error at compile time when simplifying \f(CW\*(C`a = 1. / 0\*(C'\fR.
+With this option, no error will be given and \f(CW\*(C`a\*(C'\fR will be assigned
+the value \f(CW\*(C`+Infinity\*(C'\fR.  If an expression evaluates to a value
+outside of the relevant range of [\f(CW\*(C`\-HUGE()\*(C'\fR:\f(CW\*(C`HUGE()\*(C'\fR],
+then the expression will be replaced by \f(CW\*(C`\-Inf\*(C'\fR or \f(CW\*(C`+Inf\*(C'\fR
+as appropriate.
+Similarly, \f(CW\*(C`DATA i/Z\*(AqFFFFFFFF\*(Aq/\*(C'\fR will result in an integer overflow
+on most systems, but with \fB\-fno\-range\-check\fR the value will
+\&\*(L"wrap around\*(R" and \f(CW\*(C`i\*(C'\fR will be initialized to \-1 instead.
+.IP "\fB\-fdefault\-integer\-8\fR" 4
+.IX Item "-fdefault-integer-8"
+Set the default integer and logical types to an 8 byte wide type.  This option
+also affects the kind of integer constants like \f(CW42\fR. Unlike
+\&\fB\-finteger\-4\-integer\-8\fR, it does not promote variables with explicit
+kind declaration.
+.IP "\fB\-fdefault\-real\-8\fR" 4
+.IX Item "-fdefault-real-8"
+Set the default real type to an 8 byte wide type. This option also affects
+the kind of non-double real constants like \f(CW1.0\fR, and does promote
+the default width of \f(CW\*(C`DOUBLE PRECISION\*(C'\fR to 16 bytes if possible, unless
+\&\f(CW\*(C`\-fdefault\-double\-8\*(C'\fR is given, too. Unlike \fB\-freal\-4\-real\-8\fR,
+it does not promote variables with explicit kind declaration.
+.IP "\fB\-fdefault\-double\-8\fR" 4
+.IX Item "-fdefault-double-8"
+Set the \f(CW\*(C`DOUBLE PRECISION\*(C'\fR type to an 8 byte wide type.  Do nothing if this
+is already the default.  If \fB\-fdefault\-real\-8\fR is given,
+\&\f(CW\*(C`DOUBLE PRECISION\*(C'\fR would instead be promoted to 16 bytes if possible, and
+\&\fB\-fdefault\-double\-8\fR can be used to prevent this.  The kind of real
+constants like \f(CW\*(C`1.d0\*(C'\fR will not be changed by \fB\-fdefault\-real\-8\fR
+though, so also \fB\-fdefault\-double\-8\fR does not affect it.
+.IP "\fB\-finteger\-4\-integer\-8\fR" 4
+.IX Item "-finteger-4-integer-8"
+Promote all \f(CW\*(C`INTEGER(KIND=4)\*(C'\fR entities to an \f(CW\*(C`INTEGER(KIND=8)\*(C'\fR
+entities.  If \f(CW\*(C`KIND=8\*(C'\fR is unavailable, then an error will be issued.
+This option should be used with care and may not be suitable for your codes.
+Areas of possible concern include calls to external procedures,
+alignment in \f(CW\*(C`EQUIVALENCE\*(C'\fR and/or \f(CW\*(C`COMMON\*(C'\fR, generic interfaces,
+\&\s-1BOZ\s0 literal constant conversion, and I/O.  Inspection of the intermediate
+representation of the translated Fortran code, produced by
+\&\fB\-fdump\-tree\-original\fR, is suggested.
+.IP "\fB\-freal\-4\-real\-8\fR" 4
+.IX Item "-freal-4-real-8"
+.PD 0
+.IP "\fB\-freal\-4\-real\-10\fR" 4
+.IX Item "-freal-4-real-10"
+.IP "\fB\-freal\-4\-real\-16\fR" 4
+.IX Item "-freal-4-real-16"
+.IP "\fB\-freal\-8\-real\-4\fR" 4
+.IX Item "-freal-8-real-4"
+.IP "\fB\-freal\-8\-real\-10\fR" 4
+.IX Item "-freal-8-real-10"
+.IP "\fB\-freal\-8\-real\-16\fR" 4
+.IX Item "-freal-8-real-16"
+.PD
+Promote all \f(CW\*(C`REAL(KIND=M)\*(C'\fR entities to \f(CW\*(C`REAL(KIND=N)\*(C'\fR entities.
+If \f(CW\*(C`REAL(KIND=N)\*(C'\fR is unavailable, then an error will be issued.
+All other real kind types are unaffected by this option.
+These options should be used with care and may not be suitable for your
+codes.  Areas of possible concern include calls to external procedures,
+alignment in \f(CW\*(C`EQUIVALENCE\*(C'\fR and/or \f(CW\*(C`COMMON\*(C'\fR, generic interfaces,
+\&\s-1BOZ\s0 literal constant conversion, and I/O.  Inspection of the intermediate
+representation of the translated Fortran code, produced by
+\&\fB\-fdump\-tree\-original\fR, is suggested.
+.IP "\fB\-std=\fR\fIstd\fR" 4
+.IX Item "-std=std"
+Specify the standard to which the program is expected to conform, which
+may be one of \fBf95\fR, \fBf2003\fR, \fBf2008\fR, \fBgnu\fR, or
+\&\fBlegacy\fR.  The default value for \fIstd\fR is \fBgnu\fR, which
+specifies a superset of the Fortran 95 standard that includes all of the
+extensions supported by \s-1GNU\s0 Fortran, although warnings will be given for
+obsolete extensions not recommended for use in new code.  The
+\&\fBlegacy\fR value is equivalent but without the warnings for obsolete
+extensions, and may be useful for old non-standard programs.  The
+\&\fBf95\fR, \fBf2003\fR and \fBf2008\fR values specify strict
+conformance to the Fortran 95, Fortran 2003 and Fortran 2008 standards,
+respectively; errors are given for all extensions beyond the relevant
+language standard, and warnings are given for the Fortran 77 features
+that are permitted but obsolescent in later standards. \fB\-std=f2008ts\fR
+allows the Fortran 2008 standard including the additions of the 
+Technical Specification (\s-1TS\s0) 29113 on Further Interoperability of Fortran
+with C.
+.SS "Enable and customize preprocessing"
+.IX Subsection "Enable and customize preprocessing"
+Preprocessor related options. See section 
+\&\fBPreprocessing and conditional compilation\fR for more detailed
+information on preprocessing in \fBgfortran\fR.
+.IP "\fB\-cpp\fR" 4
+.IX Item "-cpp"
+.PD 0
+.IP "\fB\-nocpp\fR" 4
+.IX Item "-nocpp"
+.PD
+Enable preprocessing. The preprocessor is automatically invoked if
+the file extension is \fI.fpp\fR, \fI.FPP\fR,  \fI.F\fR, \fI.FOR\fR,
+\&\fI.FTN\fR, \fI.F90\fR, \fI.F95\fR, \fI.F03\fR or \fI.F08\fR. Use
+this option to manually enable preprocessing of any kind of Fortran file.
+.Sp
+To disable preprocessing of files with any of the above listed extensions,
+use the negative form: \fB\-nocpp\fR.
+.Sp
+The preprocessor is run in traditional mode. Any restrictions of the
+file-format, especially the limits on line length, apply for
+preprocessed output as well, so it might be advisable to use the
+\&\fB\-ffree\-line\-length\-none\fR or \fB\-ffixed\-line\-length\-none\fR
+options.
+.IP "\fB\-dM\fR" 4
+.IX Item "-dM"
+Instead of the normal output, generate a list of \f(CW\*(Aq#define\*(Aq\fR
+directives for all the macros defined during the execution of the
+preprocessor, including predefined macros. This gives you a way
+of finding out what is predefined in your version of the preprocessor.
+Assuming you have no file \fIfoo.f90\fR, the command
+.Sp
+.Vb 1
+\&          touch foo.f90; gfortran \-cpp \-E \-dM foo.f90
+.Ve
+.Sp
+will show all the predefined macros.
+.IP "\fB\-dD\fR" 4
+.IX Item "-dD"
+Like \fB\-dM\fR except in two respects: it does not include the
+predefined macros, and it outputs both the \f(CW\*(C`#define\*(C'\fR directives
+and the result of preprocessing. Both kinds of output go to the
+standard output file.
+.IP "\fB\-dN\fR" 4
+.IX Item "-dN"
+Like \fB\-dD\fR, but emit only the macro names, not their expansions.
+.IP "\fB\-dU\fR" 4
+.IX Item "-dU"
+Like \fBdD\fR except that only macros that are expanded, or whose
+definedness is tested in preprocessor directives, are output; the 
+output is delayed until the use or test of the macro; and \f(CW\*(Aq#undef\*(Aq\fR
+directives are also output for macros tested but undefined at the time.
+.IP "\fB\-dI\fR" 4
+.IX Item "-dI"
+Output \f(CW\*(Aq#include\*(Aq\fR directives in addition to the result
+of preprocessing.
+.IP "\fB\-fworking\-directory\fR" 4
+.IX Item "-fworking-directory"
+Enable generation of linemarkers in the preprocessor output that will
+let the compiler know the current working directory at the time of
+preprocessing. When this option is enabled, the preprocessor will emit,
+after the initial linemarker, a second linemarker with the current
+working directory followed by two slashes. \s-1GCC\s0 will use this directory,
+when it is present in the preprocessed input, as the directory emitted
+as the current working directory in some debugging information formats.
+This option is implicitly enabled if debugging information is enabled,
+but this can be inhibited with the negated form
+\&\fB\-fno\-working\-directory\fR. If the \fB\-P\fR flag is present
+in the command line, this option has no effect, since no \f(CW\*(C`#line\*(C'\fR
+directives are emitted whatsoever.
+.IP "\fB\-idirafter\fR \fIdir\fR" 4
+.IX Item "-idirafter dir"
+Search \fIdir\fR for include files, but do it after all directories
+specified with \fB\-I\fR and the standard system directories have
+been exhausted. \fIdir\fR is treated as a system include directory.
+If dir begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced by
+the sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-imultilib\fR \fIdir\fR" 4
+.IX Item "-imultilib dir"
+Use \fIdir\fR as a subdirectory of the directory containing target-specific
+\&\*(C+ headers.
+.IP "\fB\-iprefix\fR \fIprefix\fR" 4
+.IX Item "-iprefix prefix"
+Specify \fIprefix\fR as the prefix for subsequent \fB\-iwithprefix\fR
+options. If the \fIprefix\fR represents a directory, you should include
+the final \f(CW\*(Aq/\*(Aq\fR.
+.IP "\fB\-isysroot\fR \fIdir\fR" 4
+.IX Item "-isysroot dir"
+This option is like the \fB\-\-sysroot\fR option, but applies only to
+header files. See the \fB\-\-sysroot\fR option for more information.
+.IP "\fB\-iquote\fR \fIdir\fR" 4
+.IX Item "-iquote dir"
+Search \fIdir\fR only for header files requested with \f(CW\*(C`#include "file"\*(C'\fR;
+they are not searched for \f(CW\*(C`#include <file>\*(C'\fR, before all directories
+specified by \fB\-I\fR and before the standard system directories. If
+\&\fIdir\fR begins with \f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced by the
+sysroot prefix; see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-isystem\fR \fIdir\fR" 4
+.IX Item "-isystem dir"
+Search \fIdir\fR for header files, after all directories specified by
+\&\fB\-I\fR but before the standard system directories. Mark it as a
+system directory, so that it gets the same special treatment as is
+applied to the standard system directories. If \fIdir\fR begins with
+\&\f(CW\*(C`=\*(C'\fR, then the \f(CW\*(C`=\*(C'\fR will be replaced by the sysroot prefix;
+see \fB\-\-sysroot\fR and \fB\-isysroot\fR.
+.IP "\fB\-nostdinc\fR" 4
+.IX Item "-nostdinc"
+Do not search the standard system directories for header files. Only
+the directories you have specified with \fB\-I\fR options (and the
+directory of the current file, if appropriate) are searched.
+.IP "\fB\-undef\fR" 4
+.IX Item "-undef"
+Do not predefine any system-specific or GCC-specific macros.
+The standard predefined macros remain defined.
+.IP "\fB\-A\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
+.IX Item "-Apredicate=answer"
+Make an assertion with the predicate \fIpredicate\fR and answer \fIanswer\fR.
+This form is preferred to the older form \-A predicate(answer), which is still
+supported, because it does not use shell special characters.
+.IP "\fB\-A\-\fR\fIpredicate\fR\fB=\fR\fIanswer\fR" 4
+.IX Item "-A-predicate=answer"
+Cancel an assertion with the predicate \fIpredicate\fR and answer \fIanswer\fR.
+.IP "\fB\-C\fR" 4
+.IX Item "-C"
+Do not discard comments. All comments are passed through to the output
+file, except for comments in processed directives, which are deleted
+along with the directive.
+.Sp
+You should be prepared for side effects when using \fB\-C\fR; it causes
+the preprocessor to treat comments as tokens in their own right. For example,
+comments appearing at the start of what would be a directive line have the
+effect of turning that line into an ordinary source line, since the first
+token on the line is no longer a \f(CW\*(Aq#\*(Aq\fR.
+.Sp
+Warning: this currently handles C\-Style comments only. The preprocessor
+does not yet recognize Fortran-style comments.
+.IP "\fB\-CC\fR" 4
+.IX Item "-CC"
+Do not discard comments, including during macro expansion. This is like
+\&\fB\-C\fR, except that comments contained within macros are also passed
+through to the output file where the macro is expanded.
+.Sp
+In addition to the side-effects of the \fB\-C\fR option, the \fB\-CC\fR
+option causes all \*(C+\-style comments inside a macro to be converted to C\-style
+comments. This is to prevent later use of that macro from inadvertently
+commenting out the remainder of the source line. The \fB\-CC\fR option
+is generally used to support lint comments.
+.Sp
+Warning: this currently handles C\- and \*(C+\-Style comments only. The
+preprocessor does not yet recognize Fortran-style comments.
+.IP "\fB\-D\fR\fIname\fR" 4
+.IX Item "-Dname"
+Predefine name as a macro, with definition \f(CW1\fR.
+.IP "\fB\-D\fR\fIname\fR\fB=\fR\fIdefinition\fR" 4
+.IX Item "-Dname=definition"
+The contents of \fIdefinition\fR are tokenized and processed as if they
+appeared during translation phase three in a \f(CW\*(Aq#define\*(Aq\fR directive.
+In particular, the definition will be truncated by embedded newline
+characters.
+.Sp
+If you are invoking the preprocessor from a shell or shell-like program
+you may need to use the shell's quoting syntax to protect characters such
+as spaces that have a meaning in the shell syntax.
+.Sp
+If you wish to define a function-like macro on the command line, write
+its argument list with surrounding parentheses before the equals sign
+(if any). Parentheses are meaningful to most shells, so you will need
+to quote the option. With sh and csh, \f(CW\*(C`\-D\*(Aqname(args...)=definition\*(Aq\*(C'\fR
+works.
+.Sp
+\&\fB\-D\fR and \fB\-U\fR options are processed in the order they are
+given on the command line. All \-imacros file and \-include file options
+are processed after all \-D and \-U options.
+.IP "\fB\-H\fR" 4
+.IX Item "-H"
+Print the name of each header file used, in addition to other normal
+activities. Each name is indented to show how deep in the \f(CW\*(Aq#include\*(Aq\fR
+stack it is.
+.IP "\fB\-P\fR" 4
+.IX Item "-P"
+Inhibit generation of linemarkers in the output from the preprocessor.
+This might be useful when running the preprocessor on something that
+is not C code, and will be sent to a program which might be confused
+by the linemarkers.
+.IP "\fB\-U\fR\fIname\fR" 4
+.IX Item "-Uname"
+Cancel any previous definition of \fIname\fR, either built in or provided
+with a \fB\-D\fR option.
+.SS "Options to request or suppress errors and warnings"
+.IX Subsection "Options to request or suppress errors and warnings"
+Errors are diagnostic messages that report that the \s-1GNU\s0 Fortran compiler
+cannot compile the relevant piece of source code.  The compiler will
+continue to process the program in an attempt to report further errors
+to aid in debugging, but will not produce any compiled output.
+.PP
+Warnings are diagnostic messages that report constructions which
+are not inherently erroneous but which are risky or suggest there is
+likely to be a bug in the program.  Unless \fB\-Werror\fR is specified,
+they do not prevent compilation of the program.
+.PP
+You can request many specific warnings with options beginning \fB\-W\fR,
+for example \fB\-Wimplicit\fR to request warnings on implicit
+declarations.  Each of these specific warning options also has a
+negative form beginning \fB\-Wno\-\fR to turn off warnings;
+for example, \fB\-Wno\-implicit\fR.  This manual lists only one of the
+two forms, whichever is not the default.
+.PP
+These options control the amount and kinds of errors and warnings produced
+by \s-1GNU\s0 Fortran:
+.IP "\fB\-fmax\-errors=\fR\fIn\fR" 4
+.IX Item "-fmax-errors=n"
+Limits the maximum number of error messages to \fIn\fR, at which point
+\&\s-1GNU\s0 Fortran bails out rather than attempting to continue processing the
+source code.  If \fIn\fR is 0, there is no limit on the number of error
+messages produced.
+.IP "\fB\-fsyntax\-only\fR" 4
+.IX Item "-fsyntax-only"
+Check the code for syntax errors, but do not actually compile it.  This
+will generate module files for each module present in the code, but no
+other output file.
+.IP "\fB\-pedantic\fR" 4
+.IX Item "-pedantic"
+Issue warnings for uses of extensions to Fortran 95.
+\&\fB\-pedantic\fR also applies to C\-language constructs where they
+occur in \s-1GNU\s0 Fortran source files, such as use of \fB\ee\fR in a
+character constant within a directive like \f(CW\*(C`#include\*(C'\fR.
+.Sp
+Valid Fortran 95 programs should compile properly with or without
+this option.
+However, without this option, certain \s-1GNU\s0 extensions and traditional
+Fortran features are supported as well.
+With this option, many of them are rejected.
+.Sp
+Some users try to use \fB\-pedantic\fR to check programs for conformance.
+They soon find that it does not do quite what they want\-\-\-it finds some
+nonstandard practices, but not all.
+However, improvements to \s-1GNU\s0 Fortran in this area are welcome.
+.Sp
+This should be used in conjunction with \fB\-std=f95\fR,
+\&\fB\-std=f2003\fR or \fB\-std=f2008\fR.
+.IP "\fB\-pedantic\-errors\fR" 4
+.IX Item "-pedantic-errors"
+Like \fB\-pedantic\fR, except that errors are produced rather than
+warnings.
+.IP "\fB\-Wall\fR" 4
+.IX Item "-Wall"
+Enables commonly used warning options pertaining to usage that
+we recommend avoiding and that we believe are easy to avoid.
+This currently includes \fB\-Waliasing\fR, \fB\-Wampersand\fR,
+\&\fB\-Wconversion\fR, \fB\-Wsurprising\fR, \fB\-Wc\-binding\-type\fR,
+\&\fB\-Wintrinsics\-std\fR, \fB\-Wno\-tabs\fR, \fB\-Wintrinsic\-shadow\fR,
+\&\fB\-Wline\-truncation\fR, \fB\-Wtarget\-lifetime\fR,
+\&\fB\-Wreal\-q\-constant\fR and \fB\-Wunused\fR.
+.IP "\fB\-Waliasing\fR" 4
+.IX Item "-Waliasing"
+Warn about possible aliasing of dummy arguments. Specifically, it warns
+if the same actual argument is associated with a dummy argument with
+\&\f(CW\*(C`INTENT(IN)\*(C'\fR and a dummy argument with \f(CW\*(C`INTENT(OUT)\*(C'\fR in a call
+with an explicit interface.
+.Sp
+The following example will trigger the warning.
+.Sp
+.Vb 7
+\&          interface
+\&            subroutine bar(a,b)
+\&              integer, intent(in) :: a
+\&              integer, intent(out) :: b
+\&            end subroutine
+\&          end interface
+\&          integer :: a
+\&        
+\&          call bar(a,a)
+.Ve
+.IP "\fB\-Wampersand\fR" 4
+.IX Item "-Wampersand"
+Warn about missing ampersand in continued character constants. The warning is
+given with \fB\-Wampersand\fR, \fB\-pedantic\fR, \fB\-std=f95\fR,
+\&\fB\-std=f2003\fR and \fB\-std=f2008\fR. Note: With no ampersand
+given in a continued character constant, \s-1GNU\s0 Fortran assumes continuation
+at the first non-comment, non-whitespace character after the ampersand
+that initiated the continuation.
+.IP "\fB\-Warray\-temporaries\fR" 4
+.IX Item "-Warray-temporaries"
+Warn about array temporaries generated by the compiler.  The information
+generated by this warning is sometimes useful in optimization, in order to
+avoid such temporaries.
+.IP "\fB\-Wc\-binding\-type\fR" 4
+.IX Item "-Wc-binding-type"
+Warn if the a variable might not be C interoperable.  In particular, warn if 
+the variable has been declared using an intrinsic type with default kind
+instead of using a kind parameter defined for C interoperability in the
+intrinsic \f(CW\*(C`ISO_C_Binding\*(C'\fR module.  This option is implied by
+\&\fB\-Wall\fR.
+.IP "\fB\-Wcharacter\-truncation\fR" 4
+.IX Item "-Wcharacter-truncation"
+Warn when a character assignment will truncate the assigned string.
+.IP "\fB\-Wline\-truncation\fR" 4
+.IX Item "-Wline-truncation"
+Warn when a source code line will be truncated.  This option is
+implied by \fB\-Wall\fR.
+.IP "\fB\-Wconversion\fR" 4
+.IX Item "-Wconversion"
+Warn about implicit conversions that are likely to change the value of 
+the expression after conversion. Implied by \fB\-Wall\fR.
+.IP "\fB\-Wconversion\-extra\fR" 4
+.IX Item "-Wconversion-extra"
+Warn about implicit conversions between different types and kinds.
+.IP "\fB\-Wextra\fR" 4
+.IX Item "-Wextra"
+Enables some warning options for usages of language features which
+may be problematic. This currently includes \fB\-Wcompare\-reals\fR
+and \fB\-Wunused\-parameter\fR.
+.IP "\fB\-Wimplicit\-interface\fR" 4
+.IX Item "-Wimplicit-interface"
+Warn if a procedure is called without an explicit interface.
+Note this only checks that an explicit interface is present.  It does not
+check that the declared interfaces are consistent across program units.
+.IP "\fB\-Wimplicit\-procedure\fR" 4
+.IX Item "-Wimplicit-procedure"
+Warn if a procedure is called that has neither an explicit interface
+nor has been declared as \f(CW\*(C`EXTERNAL\*(C'\fR.
+.IP "\fB\-Wintrinsics\-std\fR" 4
+.IX Item "-Wintrinsics-std"
+Warn if \fBgfortran\fR finds a procedure named like an intrinsic not
+available in the currently selected standard (with \fB\-std\fR) and treats
+it as \f(CW\*(C`EXTERNAL\*(C'\fR procedure because of this.  \fB\-fall\-intrinsics\fR can
+be used to never trigger this behavior and always link to the intrinsic
+regardless of the selected standard.
+.IP "\fB\-Wreal\-q\-constant\fR" 4
+.IX Item "-Wreal-q-constant"
+Produce a warning if a real-literal-constant contains a \f(CW\*(C`q\*(C'\fR
+exponent-letter.
+.IP "\fB\-Wsurprising\fR" 4
+.IX Item "-Wsurprising"
+Produce a warning when \*(L"suspicious\*(R" code constructs are encountered.
+While technically legal these usually indicate that an error has been made.
+.Sp
+This currently produces a warning under the following circumstances:
+.RS 4
+.IP "\(bu" 4
+An \s-1INTEGER SELECT\s0 construct has a \s-1CASE\s0 that can never be matched as its
+lower value is greater than its upper value.
+.IP "\(bu" 4
+A \s-1LOGICAL SELECT\s0 construct has three \s-1CASE\s0 statements.
+.IP "\(bu" 4
+A \s-1TRANSFER\s0 specifies a source that is shorter than the destination.
+.IP "\(bu" 4
+The type of a function result is declared more than once with the same type.  If
+\&\fB\-pedantic\fR or standard-conforming mode is enabled, this is an error.
+.IP "\(bu" 4
+A \f(CW\*(C`CHARACTER\*(C'\fR variable is declared with negative length.
+.RE
+.RS 4
+.RE
+.IP "\fB\-Wtabs\fR" 4
+.IX Item "-Wtabs"
+By default, tabs are accepted as whitespace, but tabs are not members
+of the Fortran Character Set.  For continuation lines, a tab followed
+by a digit between 1 and 9 is supported.  \fB\-Wno\-tabs\fR will cause
+a warning to be issued if a tab is encountered. Note, \fB\-Wno\-tabs\fR
+is active for \fB\-pedantic\fR, \fB\-std=f95\fR, \fB\-std=f2003\fR,
+\&\fB\-std=f2008\fR and \fB\-Wall\fR.
+.IP "\fB\-Wunderflow\fR" 4
+.IX Item "-Wunderflow"
+Produce a warning when numerical constant expressions are
+encountered, which yield an \s-1UNDERFLOW\s0 during compilation.
+.IP "\fB\-Wintrinsic\-shadow\fR" 4
+.IX Item "-Wintrinsic-shadow"
+Warn if a user-defined procedure or module procedure has the same name as an
+intrinsic; in this case, an explicit interface or \f(CW\*(C`EXTERNAL\*(C'\fR or
+\&\f(CW\*(C`INTRINSIC\*(C'\fR declaration might be needed to get calls later resolved to
+the desired intrinsic/procedure.  This option is implied by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-dummy\-argument\fR" 4
+.IX Item "-Wunused-dummy-argument"
+Warn about unused dummy arguments. This option is implied by \fB\-Wall\fR.
+.IP "\fB\-Wunused\-parameter\fR" 4
+.IX Item "-Wunused-parameter"
+Contrary to \fBgcc\fR's meaning of \fB\-Wunused\-parameter\fR,
+\&\fBgfortran\fR's implementation of this option does not warn
+about unused dummy arguments (see \fB\-Wunused\-dummy\-argument\fR),
+but about unused \f(CW\*(C`PARAMETER\*(C'\fR values. \fB\-Wunused\-parameter\fR
+is not included in \fB\-Wall\fR but is implied by \fB\-Wall \-Wextra\fR.
+.IP "\fB\-Walign\-commons\fR" 4
+.IX Item "-Walign-commons"
+By default, \fBgfortran\fR warns about any occasion of variables being
+padded for proper alignment inside a \f(CW\*(C`COMMON\*(C'\fR block. This warning can be turned
+off via \fB\-Wno\-align\-commons\fR. See also \fB\-falign\-commons\fR.
+.IP "\fB\-Wfunction\-elimination\fR" 4
+.IX Item "-Wfunction-elimination"
+Warn if any calls to functions are eliminated by the optimizations
+enabled by the \fB\-ffrontend\-optimize\fR option.
+.IP "\fB\-Wrealloc\-lhs\fR" 4
+.IX Item "-Wrealloc-lhs"
+Warn when the compiler might insert code to for allocation or reallocation of
+an allocatable array variable of intrinsic type in intrinsic assignments.  In
+hot loops, the Fortran 2003 reallocation feature may reduce the performance.
+If the array is already allocated with the correct shape, consider using a
+whole-array array-spec (e.g. \f(CW\*(C`(:,:,:)\*(C'\fR) for the variable on the left-hand
+side to prevent the reallocation check. Note that in some cases the warning
+is shown, even if the compiler will optimize reallocation checks away.  For
+instance, when the right-hand side contains the same variable multiplied by
+a scalar.  See also \fB\-frealloc\-lhs\fR.
+.IP "\fB\-Wrealloc\-lhs\-all\fR" 4
+.IX Item "-Wrealloc-lhs-all"
+Warn when the compiler inserts code to for allocation or reallocation of an
+allocatable variable; this includes scalars and derived types.
+.IP "\fB\-Wcompare\-reals\fR" 4
+.IX Item "-Wcompare-reals"
+Warn when comparing real or complex types for equality or inequality.
+This option is implied by \fB\-Wextra\fR.
+.IP "\fB\-Wtarget\-lifetime\fR" 4
+.IX Item "-Wtarget-lifetime"
+Warn if the pointer in a pointer assignment might be longer than the its
+target. This option is implied by \fB\-Wall\fR.
+.IP "\fB\-Wzerotrip\fR" 4
+.IX Item "-Wzerotrip"
+Warn if a \f(CW\*(C`DO\*(C'\fR loop is known to execute zero times at compile
+time.  This option is implied by \fB\-Wall\fR.
+.IP "\fB\-Werror\fR" 4
+.IX Item "-Werror"
+Turns all warnings into errors.
+.PP
+Some of these have no effect when compiling programs written in Fortran.
+.SS "Options for debugging your program or \s-1GNU\s0 Fortran"
+.IX Subsection "Options for debugging your program or GNU Fortran"
+\&\s-1GNU\s0 Fortran has various special options that are used for debugging
+either your program or the \s-1GNU\s0 Fortran compiler.
+.IP "\fB\-fdump\-fortran\-original\fR" 4
+.IX Item "-fdump-fortran-original"
+Output the internal parse tree after translating the source program
+into internal representation.  Only really useful for debugging the
+\&\s-1GNU\s0 Fortran compiler itself.
+.IP "\fB\-fdump\-fortran\-optimized\fR" 4
+.IX Item "-fdump-fortran-optimized"
+Output the parse tree after front-end optimization.  Only really
+useful for debugging the \s-1GNU\s0 Fortran compiler itself.
+.IP "\fB\-fdump\-parse\-tree\fR" 4
+.IX Item "-fdump-parse-tree"
+Output the internal parse tree after translating the source program
+into internal representation.  Only really useful for debugging the
+\&\s-1GNU\s0 Fortran compiler itself.  This option is deprecated; use
+\&\f(CW\*(C`\-fdump\-fortran\-original\*(C'\fR instead.
+.IP "\fB\-ffpe\-trap=\fR\fIlist\fR" 4
+.IX Item "-ffpe-trap=list"
+Specify a list of floating point exception traps to enable.  On most
+systems, if a floating point exception occurs and the trap for that
+exception is enabled, a \s-1SIGFPE\s0 signal will be sent and the program
+being aborted, producing a core file useful for debugging.  \fIlist\fR
+is a (possibly empty) comma-separated list of the following
+exceptions: \fBinvalid\fR (invalid floating point operation, such as
+\&\f(CW\*(C`SQRT(\-1.0)\*(C'\fR), \fBzero\fR (division by zero), \fBoverflow\fR
+(overflow in a floating point operation), \fBunderflow\fR (underflow
+in a floating point operation), \fBinexact\fR (loss of precision
+during operation), and \fBdenormal\fR (operation performed on a
+denormal value).  The first five exceptions correspond to the five
+\&\s-1IEEE 754\s0 exceptions, whereas the last one (\fBdenormal\fR) is not
+part of the \s-1IEEE 754\s0 standard but is available on some common
+architectures such as x86.
+.Sp
+The first three exceptions (\fBinvalid\fR, \fBzero\fR, and
+\&\fBoverflow\fR) often indicate serious errors, and unless the program
+has provisions for dealing with these exceptions, enabling traps for
+these three exceptions is probably a good idea.
+.Sp
+Many, if not most, floating point operations incur loss of precision
+due to rounding, and hence the \f(CW\*(C`ffpe\-trap=inexact\*(C'\fR is likely to
+be uninteresting in practice.
+.Sp
+By default no exception traps are enabled.
+.IP "\fB\-ffpe\-summary=\fR\fIlist\fR" 4
+.IX Item "-ffpe-summary=list"
+Specify a list of floating-point exceptions, whose flag status is printed
+to \f(CW\*(C`ERROR_UNIT\*(C'\fR when invoking \f(CW\*(C`STOP\*(C'\fR and \f(CW\*(C`ERROR STOP\*(C'\fR.
+\&\fIlist\fR can be either \fBnone\fR, \fBall\fR or a comma-separated list
+of the following exceptions: \fBinvalid\fR, \fBzero\fR, \fBoverflow\fR,
+\&\fBunderflow\fR, \fBinexact\fR and \fBdenormal\fR. (See
+\&\fB\-ffpe\-trap\fR for a description of the exceptions.)
+.Sp
+By default, a summary for all exceptions but \fBinexact\fR is shown.
+.IP "\fB\-fno\-backtrace\fR" 4
+.IX Item "-fno-backtrace"
+When a serious runtime error is encountered or a deadly signal is
+emitted (segmentation fault, illegal instruction, bus error,
+floating-point exception, and the other \s-1POSIX\s0 signals that have the
+action \fBcore\fR), the Fortran runtime library tries to output a
+backtrace of the error. \f(CW\*(C`\-fno\-backtrace\*(C'\fR disables the backtrace
+generation. This option only has influence for compilation of the
+Fortran main program.
+.SS "Options for directory search"
+.IX Subsection "Options for directory search"
+These options affect how \s-1GNU\s0 Fortran searches
+for files specified by the \f(CW\*(C`INCLUDE\*(C'\fR directive and where it searches
+for previously compiled modules.
+.PP
+It also affects the search paths used by \fBcpp\fR when used to preprocess
+Fortran source.
+.IP "\fB\-I\fR\fIdir\fR" 4
+.IX Item "-Idir"
+These affect interpretation of the \f(CW\*(C`INCLUDE\*(C'\fR directive
+(as well as of the \f(CW\*(C`#include\*(C'\fR directive of the \fBcpp\fR
+preprocessor).
+.Sp
+Also note that the general behavior of \fB\-I\fR and
+\&\f(CW\*(C`INCLUDE\*(C'\fR is pretty much the same as of \fB\-I\fR with
+\&\f(CW\*(C`#include\*(C'\fR in the \fBcpp\fR preprocessor, with regard to
+looking for \fIheader.gcc\fR files and other such things.
+.Sp
+This path is also used to search for \fI.mod\fR files when previously
+compiled modules are required by a \f(CW\*(C`USE\*(C'\fR statement.
+.IP "\fB\-J\fR\fIdir\fR" 4
+.IX Item "-Jdir"
+This option specifies where to put \fI.mod\fR files for compiled modules.
+It is also added to the list of directories to searched by an \f(CW\*(C`USE\*(C'\fR
+statement.
+.Sp
+The default is the current directory.
+.IP "\fB\-fintrinsic\-modules\-path\fR \fIdir\fR" 4
+.IX Item "-fintrinsic-modules-path dir"
+This option specifies the location of pre-compiled intrinsic modules, if
+they are not in the default location expected by the compiler.
+.SS "Influencing the linking step"
+.IX Subsection "Influencing the linking step"
+These options come into play when the compiler links object files into an 
+executable output file. They are meaningless if the compiler is not doing 
+a link step.
+.IP "\fB\-static\-libgfortran\fR" 4
+.IX Item "-static-libgfortran"
+On systems that provide \fIlibgfortran\fR as a shared and a static
+library, this option forces the use of the static version. If no
+shared version of \fIlibgfortran\fR was built when the compiler was
+configured, this option has no effect.
+.SS "Influencing runtime behavior"
+.IX Subsection "Influencing runtime behavior"
+These options affect the runtime behavior of programs compiled with \s-1GNU\s0 Fortran.
+.IP "\fB\-fconvert=\fR\fIconversion\fR" 4
+.IX Item "-fconvert=conversion"
+Specify the representation of data for unformatted files.  Valid
+values for conversion are: \fBnative\fR, the default; \fBswap\fR,
+swap between big\- and little-endian; \fBbig-endian\fR, use big-endian
+representation for unformatted files; \fBlittle-endian\fR, use little-endian
+representation for unformatted files.
+.Sp
+\&\fIThis option has an effect only when used in the main program.
+The \f(CI\*(C`CONVERT\*(C'\fI specifier and the \s-1GFORTRAN_CONVERT_UNIT\s0 environment
+variable override the default specified by \f(BI\-fconvert\fI.\fR
+.IP "\fB\-frecord\-marker=\fR\fIlength\fR" 4
+.IX Item "-frecord-marker=length"
+Specify the length of record markers for unformatted files.
+Valid values for \fIlength\fR are 4 and 8.  Default is 4.
+\&\fIThis is different from previous versions of\fR \fBgfortran\fR,
+which specified a default record marker length of 8 on most
+systems.  If you want to read or write files compatible
+with earlier versions of \fBgfortran\fR, use \fB\-frecord\-marker=8\fR.
+.IP "\fB\-fmax\-subrecord\-length=\fR\fIlength\fR" 4
+.IX Item "-fmax-subrecord-length=length"
+Specify the maximum length for a subrecord.  The maximum permitted
+value for length is 2147483639, which is also the default.  Only
+really useful for use by the gfortran testsuite.
+.IP "\fB\-fsign\-zero\fR" 4
+.IX Item "-fsign-zero"
+When enabled, floating point numbers of value zero with the sign bit set
+are written as negative number in formatted output and treated as
+negative in the \f(CW\*(C`SIGN\*(C'\fR intrinsic.  \fB\-fno\-sign\-zero\fR does not
+print the negative sign of zero values (or values rounded to zero for I/O)
+and regards zero as positive number in the \f(CW\*(C`SIGN\*(C'\fR intrinsic for
+compatibility with Fortran 77. The default is \fB\-fsign\-zero\fR.
+.SS "Options for code generation conventions"
+.IX Subsection "Options for code generation conventions"
+These machine-independent options control the interface conventions
+used in code generation.
+.PP
+Most of them have both positive and negative forms; the negative form
+of \fB\-ffoo\fR would be \fB\-fno\-foo\fR.  In the table below, only
+one of the forms is listed\-\-\-the one which is not the default.  You
+can figure out the other form by either removing \fBno\-\fR or adding
+it.
+.IP "\fB\-fno\-automatic\fR" 4
+.IX Item "-fno-automatic"
+Treat each program unit (except those marked as \s-1RECURSIVE\s0) as if the
+\&\f(CW\*(C`SAVE\*(C'\fR statement were specified for every local variable and array
+referenced in it. Does not affect common blocks. (Some Fortran compilers
+provide this option under the name \fB\-static\fR or \fB\-save\fR.)
+The default, which is \fB\-fautomatic\fR, uses the stack for local
+variables smaller than the value given by \fB\-fmax\-stack\-var\-size\fR.
+Use the option \fB\-frecursive\fR to use no static memory.
+.IP "\fB\-ff2c\fR" 4
+.IX Item "-ff2c"
+Generate code designed to be compatible with code generated
+by \fBg77\fR and \fBf2c\fR.
+.Sp
+The calling conventions used by \fBg77\fR (originally implemented
+in \fBf2c\fR) require functions that return type
+default \f(CW\*(C`REAL\*(C'\fR to actually return the C type \f(CW\*(C`double\*(C'\fR, and
+functions that return type \f(CW\*(C`COMPLEX\*(C'\fR to return the values via an
+extra argument in the calling sequence that points to where to
+store the return value.  Under the default \s-1GNU\s0 calling conventions, such
+functions simply return their results as they would in \s-1GNU\s0
+C\-\-\-default \f(CW\*(C`REAL\*(C'\fR functions return the C type \f(CW\*(C`float\*(C'\fR, and
+\&\f(CW\*(C`COMPLEX\*(C'\fR functions return the \s-1GNU C\s0 type \f(CW\*(C`complex\*(C'\fR.
+Additionally, this option implies the \fB\-fsecond\-underscore\fR
+option, unless \fB\-fno\-second\-underscore\fR is explicitly requested.
+.Sp
+This does not affect the generation of code that interfaces with
+the \fBlibgfortran\fR library.
+.Sp
+\&\fICaution:\fR It is not a good idea to mix Fortran code compiled with
+\&\fB\-ff2c\fR with code compiled with the default \fB\-fno\-f2c\fR
+calling conventions as, calling \f(CW\*(C`COMPLEX\*(C'\fR or default \f(CW\*(C`REAL\*(C'\fR
+functions between program parts which were compiled with different
+calling conventions will break at execution time.
+.Sp
+\&\fICaution:\fR This will break code which passes intrinsic functions
+of type default \f(CW\*(C`REAL\*(C'\fR or \f(CW\*(C`COMPLEX\*(C'\fR as actual arguments, as
+the library implementations use the \fB\-fno\-f2c\fR calling conventions.
+.IP "\fB\-fno\-underscoring\fR" 4
+.IX Item "-fno-underscoring"
+Do not transform names of entities specified in the Fortran
+source file by appending underscores to them.
+.Sp
+With \fB\-funderscoring\fR in effect, \s-1GNU\s0 Fortran appends one
+underscore to external names with no underscores.  This is done to ensure
+compatibility with code produced by many \s-1UNIX\s0 Fortran compilers.
+.Sp
+\&\fICaution\fR: The default behavior of \s-1GNU\s0 Fortran is
+incompatible with \fBf2c\fR and \fBg77\fR, please use the
+\&\fB\-ff2c\fR option if you want object files compiled with
+\&\s-1GNU\s0 Fortran to be compatible with object code created with these
+tools.
+.Sp
+Use of \fB\-fno\-underscoring\fR is not recommended unless you are
+experimenting with issues such as integration of \s-1GNU\s0 Fortran into
+existing system environments (vis\-a\*`\-vis existing libraries, tools,
+and so on).
+.Sp
+For example, with \fB\-funderscoring\fR, and assuming other defaults like
+\&\fB\-fcase\-lower\fR and that \f(CW\*(C`j()\*(C'\fR and \f(CW\*(C`max_count()\*(C'\fR are
+external functions while \f(CW\*(C`my_var\*(C'\fR and \f(CW\*(C`lvar\*(C'\fR are local variables,
+a statement like
+.Sp
+.Vb 1
+\&        I = J() + MAX_COUNT (MY_VAR, LVAR)
+.Ve
+.Sp
+is implemented as something akin to:
+.Sp
+.Vb 1
+\&        i = j_() + max_count_\|_(&my_var_\|_, &lvar);
+.Ve
+.Sp
+With \fB\-fno\-underscoring\fR, the same statement is implemented as:
+.Sp
+.Vb 1
+\&        i = j() + max_count(&my_var, &lvar);
+.Ve
+.Sp
+Use of \fB\-fno\-underscoring\fR allows direct specification of
+user-defined names while debugging and when interfacing \s-1GNU\s0 Fortran
+code with other languages.
+.Sp
+Note that just because the names match does \fInot\fR mean that the
+interface implemented by \s-1GNU\s0 Fortran for an external name matches the
+interface implemented by some other language for that same name.
+That is, getting code produced by \s-1GNU\s0 Fortran to link to code produced
+by some other compiler using this or any other method can be only a
+small part of the overall solution\-\-\-getting the code generated by
+both compilers to agree on issues other than naming can require
+significant effort, and, unlike naming disagreements, linkers normally
+cannot detect disagreements in these other areas.
+.Sp
+Also, note that with \fB\-fno\-underscoring\fR, the lack of appended
+underscores introduces the very real possibility that a user-defined
+external name will conflict with a name in a system library, which
+could make finding unresolved-reference bugs quite difficult in some
+cases\-\-\-they might occur at program run time, and show up only as
+buggy behavior at run time.
+.Sp
+In future versions of \s-1GNU\s0 Fortran we hope to improve naming and linking
+issues so that debugging always involves using the names as they appear
+in the source, even if the names as seen by the linker are mangled to
+prevent accidental linking between procedures with incompatible
+interfaces.
+.IP "\fB\-fsecond\-underscore\fR" 4
+.IX Item "-fsecond-underscore"
+By default, \s-1GNU\s0 Fortran appends an underscore to external
+names.  If this option is used \s-1GNU\s0 Fortran appends two
+underscores to names with underscores and one underscore to external names
+with no underscores.  \s-1GNU\s0 Fortran also appends two underscores to
+internal names with underscores to avoid naming collisions with external
+names.
+.Sp
+This option has no effect if \fB\-fno\-underscoring\fR is
+in effect.  It is implied by the \fB\-ff2c\fR option.
+.Sp
+Otherwise, with this option, an external name such as \f(CW\*(C`MAX_COUNT\*(C'\fR
+is implemented as a reference to the link-time external symbol
+\&\f(CW\*(C`max_count_\|_\*(C'\fR, instead of \f(CW\*(C`max_count_\*(C'\fR.  This is required
+for compatibility with \fBg77\fR and \fBf2c\fR, and is implied
+by use of the \fB\-ff2c\fR option.
+.IP "\fB\-fcoarray=\fR\fI<keyword>\fR" 4
+.IX Item "-fcoarray=<keyword>"
+.RS 4
+.PD 0
+.IP "\fBnone\fR" 4
+.IX Item "none"
+.PD
+Disable coarray support; using coarray declarations and image-control
+statements will produce a compile-time error. (Default)
+.IP "\fBsingle\fR" 4
+.IX Item "single"
+Single-image mode, i.e. \f(CW\*(C`num_images()\*(C'\fR is always one.
+.IP "\fBlib\fR" 4
+.IX Item "lib"
+Library-based coarray parallelization; a suitable \s-1GNU\s0 Fortran coarray
+library needs to be linked.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fcheck=\fR\fI<keyword>\fR" 4
+.IX Item "-fcheck=<keyword>"
+Enable the generation of run-time checks; the argument shall be
+a comma-delimited list of the following keywords.
+.RS 4
+.IP "\fBall\fR" 4
+.IX Item "all"
+Enable all run-time test of \fB\-fcheck\fR.
+.IP "\fBarray-temps\fR" 4
+.IX Item "array-temps"
+Warns at run time when for passing an actual argument a temporary array
+had to be generated. The information generated by this warning is
+sometimes useful in optimization, in order to avoid such temporaries.
+.Sp
+Note: The warning is only printed once per location.
+.IP "\fBbounds\fR" 4
+.IX Item "bounds"
+Enable generation of run-time checks for array subscripts
+and against the declared minimum and maximum values.  It also
+checks array indices for assumed and deferred
+shape arrays against the actual allocated bounds and ensures that all string
+lengths are equal for character array constructors without an explicit
+typespec.
+.Sp
+Some checks require that \fB\-fcheck=bounds\fR is set for
+the compilation of the main program.
+.Sp
+Note: In the future this may also include other forms of checking, e.g.,
+checking substring references.
+.IP "\fBdo\fR" 4
+.IX Item "do"
+Enable generation of run-time checks for invalid modification of loop
+iteration variables.
+.IP "\fBmem\fR" 4
+.IX Item "mem"
+Enable generation of run-time checks for memory allocation.
+Note: This option does not affect explicit allocations using the
+\&\f(CW\*(C`ALLOCATE\*(C'\fR statement, which will be always checked.
+.IP "\fBpointer\fR" 4
+.IX Item "pointer"
+Enable generation of run-time checks for pointers and allocatables.
+.IP "\fBrecursion\fR" 4
+.IX Item "recursion"
+Enable generation of run-time checks for recursively called subroutines and
+functions which are not marked as recursive. See also \fB\-frecursive\fR.
+Note: This check does not work for OpenMP programs and is disabled if used
+together with \fB\-frecursive\fR and \fB\-fopenmp\fR.
+.RE
+.RS 4
+.RE
+.IP "\fB\-fbounds\-check\fR" 4
+.IX Item "-fbounds-check"
+Deprecated alias for \fB\-fcheck=bounds\fR.
+.IP "\fB\-fcheck\-array\-temporaries\fR" 4
+.IX Item "-fcheck-array-temporaries"
+Deprecated alias for \fB\-fcheck=array\-temps\fR.
+.IP "\fB\-fmax\-array\-constructor=\fR\fIn\fR" 4
+.IX Item "-fmax-array-constructor=n"
+This option can be used to increase the upper limit permitted in 
+array constructors.  The code below requires this option to expand
+the array at compile time.
+.Sp
+.Vb 7
+\&        program test
+\&        implicit none
+\&        integer j
+\&        integer, parameter :: n = 100000
+\&        integer, parameter :: i(n) = (/ (2*j, j = 1, n) /)
+\&        print \*(Aq(10(I0,1X))\*(Aq, i
+\&        end program test
+.Ve
+.Sp
+\&\fICaution:  This option can lead to long compile times and excessively
+large object files.\fR
+.Sp
+The default value for \fIn\fR is 65535.
+.IP "\fB\-fmax\-stack\-var\-size=\fR\fIn\fR" 4
+.IX Item "-fmax-stack-var-size=n"
+This option specifies the size in bytes of the largest array that will be put
+on the stack; if the size is exceeded static memory is used (except in
+procedures marked as \s-1RECURSIVE\s0). Use the option \fB\-frecursive\fR to
+allow for recursive procedures which do not have a \s-1RECURSIVE\s0 attribute or
+for parallel programs. Use \fB\-fno\-automatic\fR to never use the stack.
+.Sp
+This option currently only affects local arrays declared with constant
+bounds, and may not apply to all character variables.
+Future versions of \s-1GNU\s0 Fortran may improve this behavior.
+.Sp
+The default value for \fIn\fR is 32768.
+.IP "\fB\-fstack\-arrays\fR" 4
+.IX Item "-fstack-arrays"
+Adding this option will make the Fortran compiler put all local arrays,
+even those of unknown size onto stack memory.  If your program uses very
+large local arrays it is possible that you will have to extend your runtime
+limits for stack memory on some operating systems. This flag is enabled
+by default at optimization level \fB\-Ofast\fR.
+.IP "\fB\-fpack\-derived\fR" 4
+.IX Item "-fpack-derived"
+This option tells \s-1GNU\s0 Fortran to pack derived type members as closely as
+possible.  Code compiled with this option is likely to be incompatible
+with code compiled without this option, and may execute slower.
+.IP "\fB\-frepack\-arrays\fR" 4
+.IX Item "-frepack-arrays"
+In some circumstances \s-1GNU\s0 Fortran may pass assumed shape array
+sections via a descriptor describing a noncontiguous area of memory.
+This option adds code to the function prologue to repack the data into
+a contiguous block at runtime.
+.Sp
+This should result in faster accesses to the array.  However it can introduce
+significant overhead to the function call, especially  when the passed data
+is noncontiguous.
+.IP "\fB\-fshort\-enums\fR" 4
+.IX Item "-fshort-enums"
+This option is provided for interoperability with C code that was
+compiled with the \fB\-fshort\-enums\fR option.  It will make
+\&\s-1GNU\s0 Fortran choose the smallest \f(CW\*(C`INTEGER\*(C'\fR kind a given
+enumerator set will fit in, and give all its enumerators this kind.
+.IP "\fB\-fexternal\-blas\fR" 4
+.IX Item "-fexternal-blas"
+This option will make \fBgfortran\fR generate calls to \s-1BLAS\s0 functions
+for some matrix operations like \f(CW\*(C`MATMUL\*(C'\fR, instead of using our own
+algorithms, if the size of the matrices involved is larger than a given
+limit (see \fB\-fblas\-matmul\-limit\fR).  This may be profitable if an
+optimized vendor \s-1BLAS\s0 library is available.  The \s-1BLAS\s0 library will have
+to be specified at link time.
+.IP "\fB\-fblas\-matmul\-limit=\fR\fIn\fR" 4
+.IX Item "-fblas-matmul-limit=n"
+Only significant when \fB\-fexternal\-blas\fR is in effect.
+Matrix multiplication of matrices with size larger than (or equal to) \fIn\fR
+will be performed by calls to \s-1BLAS\s0 functions, while others will be
+handled by \fBgfortran\fR internal algorithms. If the matrices
+involved are not square, the size comparison is performed using the
+geometric mean of the dimensions of the argument and result matrices.
+.Sp
+The default value for \fIn\fR is 30.
+.IP "\fB\-frecursive\fR" 4
+.IX Item "-frecursive"
+Allow indirect recursion by forcing all local arrays to be allocated
+on the stack. This flag cannot be used together with
+\&\fB\-fmax\-stack\-var\-size=\fR or \fB\-fno\-automatic\fR.
+.IP "\fB\-finit\-local\-zero\fR" 4
+.IX Item "-finit-local-zero"
+.PD 0
+.IP "\fB\-finit\-integer=\fR\fIn\fR" 4
+.IX Item "-finit-integer=n"
+.IP "\fB\-finit\-real=\fR\fI<zero|inf|\-inf|nan|snan>\fR" 4
+.IX Item "-finit-real=<zero|inf|-inf|nan|snan>"
+.IP "\fB\-finit\-logical=\fR\fI<true|false>\fR" 4
+.IX Item "-finit-logical=<true|false>"
+.IP "\fB\-finit\-character=\fR\fIn\fR" 4
+.IX Item "-finit-character=n"
+.PD
+The \fB\-finit\-local\-zero\fR option instructs the compiler to
+initialize local \f(CW\*(C`INTEGER\*(C'\fR, \f(CW\*(C`REAL\*(C'\fR, and \f(CW\*(C`COMPLEX\*(C'\fR
+variables to zero, \f(CW\*(C`LOGICAL\*(C'\fR variables to false, and
+\&\f(CW\*(C`CHARACTER\*(C'\fR variables to a string of null bytes.  Finer-grained
+initialization options are provided by the
+\&\fB\-finit\-integer=\fR\fIn\fR,
+\&\fB\-finit\-real=\fR\fI<zero|inf|\-inf|nan|snan>\fR (which also initializes
+the real and imaginary parts of local \f(CW\*(C`COMPLEX\*(C'\fR variables),
+\&\fB\-finit\-logical=\fR\fI<true|false>\fR, and
+\&\fB\-finit\-character=\fR\fIn\fR (where \fIn\fR is an \s-1ASCII\s0 character
+value) options.  These options do not initialize
+.RS 4
+.IP "\(bu" 4
+allocatable arrays
+.IP "\(bu" 4
+components of derived type variables
+.IP "\(bu" 4
+variables that appear in an \f(CW\*(C`EQUIVALENCE\*(C'\fR statement.
+.RE
+.RS 4
+.Sp
+(These limitations may be removed in future releases).
+.Sp
+Note that the \fB\-finit\-real=nan\fR option initializes \f(CW\*(C`REAL\*(C'\fR
+and \f(CW\*(C`COMPLEX\*(C'\fR variables with a quiet NaN. For a signalling NaN
+use \fB\-finit\-real=snan\fR; note, however, that compile-time
+optimizations may convert them into quiet NaN and that trapping
+needs to be enabled (e.g. via \fB\-ffpe\-trap\fR).
+.Sp
+Finally, note that enabling any of the \fB\-finit\-*\fR options will
+silence warnings that would have been emitted by \fB\-Wuninitialized\fR
+for the affected local variables.
+.RE
+.IP "\fB\-falign\-commons\fR" 4
+.IX Item "-falign-commons"
+By default, \fBgfortran\fR enforces proper alignment of all variables in a
+\&\f(CW\*(C`COMMON\*(C'\fR block by padding them as needed. On certain platforms this is mandatory,
+on others it increases performance. If a \f(CW\*(C`COMMON\*(C'\fR block is not declared with
+consistent data types everywhere, this padding can cause trouble, and
+\&\fB\-fno\-align\-commons\fR can be used to disable automatic alignment. The
+same form of this option should be used for all files that share a \f(CW\*(C`COMMON\*(C'\fR block.
+To avoid potential alignment issues in \f(CW\*(C`COMMON\*(C'\fR blocks, it is recommended to order
+objects from largest to smallest.
+.IP "\fB\-fno\-protect\-parens\fR" 4
+.IX Item "-fno-protect-parens"
+By default the parentheses in expression are honored for all optimization
+levels such that the compiler does not do any re-association. Using
+\&\fB\-fno\-protect\-parens\fR allows the compiler to reorder \f(CW\*(C`REAL\*(C'\fR and
+\&\f(CW\*(C`COMPLEX\*(C'\fR expressions to produce faster code. Note that for the re-association
+optimization \fB\-fno\-signed\-zeros\fR and \fB\-fno\-trapping\-math\fR
+need to be in effect. The parentheses protection is enabled by default, unless
+\&\fB\-Ofast\fR is given.
+.IP "\fB\-frealloc\-lhs\fR" 4
+.IX Item "-frealloc-lhs"
+An allocatable left-hand side of an intrinsic assignment is automatically
+(re)allocated if it is either unallocated or has a different shape. The
+option is enabled by default except when \fB\-std=f95\fR is given. See
+also \fB\-Wrealloc\-lhs\fR.
+.IP "\fB\-faggressive\-function\-elimination\fR" 4
+.IX Item "-faggressive-function-elimination"
+Functions with identical argument lists are eliminated within
+statements, regardless of whether these functions are marked
+\&\f(CW\*(C`PURE\*(C'\fR or not. For example, in
+.Sp
+.Vb 1
+\&          a = f(b,c) + f(b,c)
+.Ve
+.Sp
+there will only be a single call to \f(CW\*(C`f\*(C'\fR.  This option only works
+if \fB\-ffrontend\-optimize\fR is in effect.
+.IP "\fB\-ffrontend\-optimize\fR" 4
+.IX Item "-ffrontend-optimize"
+This option performs front-end optimization, based on manipulating
+parts the Fortran parse tree.  Enabled by default by any \fB\-O\fR
+option.  Optimizations enabled by this option include elimination of
+identical function calls within expressions, removing unnecessary
+calls to \f(CW\*(C`TRIM\*(C'\fR in comparisons and assignments and replacing
+\&\f(CWTRIM(a)\fR with \f(CW\*(C`a(1:LEN_TRIM(a))\*(C'\fR. 
+It can be deselected by specifying \fB\-fno\-frontend\-optimize\fR.
+.SH "ENVIRONMENT"
+.IX Header "ENVIRONMENT"
+The \fBgfortran\fR compiler currently does not make use of any environment
+variables to control its operation above and beyond those
+that affect the operation of \fBgcc\fR.
+.SH "BUGS"
+.IX Header "BUGS"
+For instructions on reporting bugs, see
+<\fBhttp://gcc.gnu.org/bugs.html\fR>.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgpl\fR\|(7), \fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7),
+\&\fIcpp\fR\|(1), \fIgcov\fR\|(1), \fIgcc\fR\|(1), \fIas\fR\|(1), \fIld\fR\|(1), \fIgdb\fR\|(1), \fIadb\fR\|(1), \fIdbx\fR\|(1), \fIsdb\fR\|(1)
+and the Info entries for \fIgcc\fR, \fIcpp\fR, \fIgfortran\fR, \fIas\fR,
+\&\fIld\fR, \fIbinutils\fR and \fIgdb\fR.
+.SH "AUTHOR"
+.IX Header "AUTHOR"
+See the Info entry for \fBgfortran\fR for contributors to \s-1GCC\s0 and
+\&\s-1GNU\s0 Fortran.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2004\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 Free Documentation License, Version 1.3 or
+any later version published by the Free Software Foundation; with the
+Invariant Sections being \*(L"Funding Free Software\*(R", 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 \fIgfdl\fR\|(7) man page.
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/gij.1 b/gcc-4.9/gcc/doc/gij.1
new file mode 100644
index 000000000..78c1f4c59
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gij.1
@@ -0,0 +1,295 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GIJ 1"
+.TH GIJ 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gij \- GNU interpreter for Java bytecode
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+gij [\fB\s-1OPTION\s0\fR] ... \fI\s-1JARFILE\s0\fR [\fI\s-1ARGS\s0\fR...]
+.PP
+gij [\fB\-jar\fR] [\fB\s-1OPTION\s0\fR] ... \fI\s-1CLASS\s0\fR [\fI\s-1ARGS\s0\fR...]
+  [\fB\-cp\fR \fIpath\fR] [\fB\-classpath\fR \fIpath\fR]
+  [\fB\-D\fR\fIname\fR[=\fIvalue\fR]...]
+  [\fB\-ms=\fR\fInumber\fR] [\fB\-mx=\fR\fInumber\fR]
+  [\fB\-X\fR\fIargument\fR] [\fB\-verbose\fR] [\fB\-verbose:class\fR]
+  [\fB\-\-showversion\fR] [\fB\-\-version\fR] [\fB\-\-help\fR][\fB\-?\fR]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\f(CW\*(C`gij\*(C'\fR is a Java bytecode interpreter included with \f(CW\*(C`libgcj\*(C'\fR.
+\&\f(CW\*(C`gij\*(C'\fR is not available on every platform; porting it requires a
+small amount of assembly programming which has not been done for all the
+targets supported by \fBgcj\fR.
+.PP
+The primary argument to \f(CW\*(C`gij\*(C'\fR is the name of a class or, with
+\&\f(CW\*(C`\-jar\*(C'\fR, a jar file.  Options before this argument are interpreted
+by \f(CW\*(C`gij\*(C'\fR; remaining options are passed to the interpreted program.
+.PP
+If a class name is specified and this class does not have a \f(CW\*(C`main\*(C'\fR
+method with the appropriate signature (a \f(CW\*(C`static void\*(C'\fR method with
+a \f(CW\*(C`String[]\*(C'\fR as its sole argument), then \f(CW\*(C`gij\*(C'\fR will print an
+error and exit.
+.PP
+If a jar file is specified then \f(CW\*(C`gij\*(C'\fR will use information in it to
+determine which class' \f(CW\*(C`main\*(C'\fR method will be invoked.
+.PP
+\&\f(CW\*(C`gij\*(C'\fR will invoke the \f(CW\*(C`main\*(C'\fR method with all the remaining
+command-line options.
+.PP
+Note that \f(CW\*(C`gij\*(C'\fR is not limited to interpreting code.  Because
+\&\f(CW\*(C`libgcj\*(C'\fR includes a class loader which can dynamically load shared
+objects, it is possible to give \f(CW\*(C`gij\*(C'\fR the name of a class which has
+been compiled and put into a shared library on the class path.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-cp\fR \fIpath\fR" 4
+.IX Item "-cp path"
+.PD 0
+.IP "\fB\-classpath\fR \fIpath\fR" 4
+.IX Item "-classpath path"
+.PD
+Set the initial class path.  The class path is used for finding
+class and resource files.  If specified, this option overrides the
+\&\f(CW\*(C`CLASSPATH\*(C'\fR environment variable.  Note that this option is
+ignored if \f(CW\*(C`\-jar\*(C'\fR is used.
+.IP "\fB\-D\fR\fIname\fR\fB[=\fR\fIvalue\fR\fB]\fR" 4
+.IX Item "-Dname[=value]"
+This defines a system property named \fIname\fR with value \fIvalue\fR.
+If \fIvalue\fR is not specified then it defaults to the empty string.
+These system properties are initialized at the program's startup and can
+be retrieved at runtime using the \f(CW\*(C`java.lang.System.getProperty\*(C'\fR
+method.
+.IP "\fB\-ms=\fR\fInumber\fR" 4
+.IX Item "-ms=number"
+Equivalent to \f(CW\*(C`\-Xms\*(C'\fR.
+.IP "\fB\-mx=\fR\fInumber\fR" 4
+.IX Item "-mx=number"
+Equivalent to \f(CW\*(C`\-Xmx\*(C'\fR.
+.IP "\fB\-noverify\fR" 4
+.IX Item "-noverify"
+Do not verify compliance of bytecode with the \s-1VM\s0 specification. In addition,
+this option disables type verification which is otherwise performed on BC-ABI
+compiled code.
+.IP "\fB\-X\fR" 4
+.IX Item "-X"
+.PD 0
+.IP "\fB\-X\fR\fIargument\fR" 4
+.IX Item "-Xargument"
+.PD
+Supplying \f(CW\*(C`\-X\*(C'\fR by itself will cause \f(CW\*(C`gij\*(C'\fR to list all the
+supported \f(CW\*(C`\-X\*(C'\fR options.  Currently these options are supported:
+.RS 4
+.IP "\fB\-Xms\fR\fIsize\fR" 4
+.IX Item "-Xmssize"
+Set the initial heap size.
+.IP "\fB\-Xmx\fR\fIsize\fR" 4
+.IX Item "-Xmxsize"
+Set the maximum heap size.
+.IP "\fB\-Xss\fR\fIsize\fR" 4
+.IX Item "-Xsssize"
+Set the thread stack size.
+.RE
+.RS 4
+.Sp
+Unrecognized \f(CW\*(C`\-X\*(C'\fR options are ignored, for compatibility with
+other runtimes.
+.RE
+.IP "\fB\-jar\fR" 4
+.IX Item "-jar"
+This indicates that the name passed to \f(CW\*(C`gij\*(C'\fR should be interpreted
+as the name of a jar file, not a class.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+.PD 0
+.IP "\fB\-?\fR" 4
+.IX Item "-?"
+.PD
+Print help, then exit.
+.IP "\fB\-\-showversion\fR" 4
+.IX Item "--showversion"
+Print version number and continue.
+.IP "\fB\-\-fullversion\fR" 4
+.IX Item "--fullversion"
+Print detailed version information, then exit.
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+Print version number, then exit.
+.IP "\fB\-verbose\fR" 4
+.IX Item "-verbose"
+.PD 0
+.IP "\fB\-verbose:class\fR" 4
+.IX Item "-verbose:class"
+.PD
+Each time a class is initialized, print a short message on standard error.
+.PP
+\&\f(CW\*(C`gij\*(C'\fR also recognizes and ignores the following options, for
+compatibility with existing application launch scripts:
+\&\f(CW\*(C`\-client\*(C'\fR, \f(CW\*(C`\-server\*(C'\fR, \f(CW\*(C`\-hotspot\*(C'\fR, \f(CW\*(C`\-jrockit\*(C'\fR,
+\&\f(CW\*(C`\-agentlib\*(C'\fR, \f(CW\*(C`\-agentpath\*(C'\fR, \f(CW\*(C`\-debug\*(C'\fR, \f(CW\*(C`\-d32\*(C'\fR,
+\&\f(CW\*(C`\-d64\*(C'\fR, \f(CW\*(C`\-javaagent\*(C'\fR, \f(CW\*(C`\-noclassgc\*(C'\fR, \f(CW\*(C`\-verify\*(C'\fR,
+and \f(CW\*(C`\-verifyremote\*(C'\fR.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgcc\fR\|(1), \fIgcj\fR\|(1), \fIgcjh\fR\|(1), \fIjcf\-dump\fR\|(1), \fIgfdl\fR\|(7),
+and the Info entries for \fIgcj\fR and \fIgcc\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/gpl.7 b/gcc-4.9/gcc/doc/gpl.7
new file mode 100644
index 000000000..82bee2334
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gpl.7
@@ -0,0 +1,850 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GPL 7"
+.TH GPL 7 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+gpl \- GNU General Public License
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+.SS "\s-1GNU\s0 General Public License"
+.IX Subsection "GNU General Public License"
+.SS "Version 3, 29 June 2007"
+.IX Subsection "Version 3, 29 June 2007"
+.Vb 1
+\&        Copyright (c) 2007 Free Software Foundation, Inc. <http://fsf.org/>
+\&        
+\&        Everyone is permitted to copy and distribute verbatim copies of this
+\&        license document, but changing it is not allowed.
+.Ve
+.SS "Preamble"
+.IX Subsection "Preamble"
+The \s-1GNU\s0 General Public License is a free, copyleft license for
+software and other kinds of works.
+.PP
+The licenses for most software and other practical works are designed
+to take away your freedom to share and change the works.  By contrast,
+the \s-1GNU\s0 General Public License is intended to guarantee your freedom
+to share and change all versions of a program\*(--to make sure it remains
+free software for all its users.  We, the Free Software Foundation,
+use the \s-1GNU\s0 General Public License for most of our software; it
+applies also to any other work released this way by its authors.  You
+can apply it to your programs, too.
+.PP
+When we speak of free software, we are referring to freedom, not
+price.  Our General Public Licenses are designed to make sure that you
+have the freedom to distribute copies of free software (and charge for
+them if you wish), that you receive source code or can get it if you
+want it, that you can change the software or use pieces of it in new
+free programs, and that you know you can do these things.
+.PP
+To protect your rights, we need to prevent others from denying you
+these rights or asking you to surrender the rights.  Therefore, you
+have certain responsibilities if you distribute copies of the
+software, or if you modify it: responsibilities to respect the freedom
+of others.
+.PP
+For example, if you distribute copies of such a program, whether
+gratis or for a fee, you must pass on to the recipients the same
+freedoms that you received.  You must make sure that they, too,
+receive or can get the source code.  And you must show them these
+terms so they know their rights.
+.PP
+Developers that use the \s-1GNU GPL\s0 protect your rights with two steps:
+(1) assert copyright on the software, and (2) offer you this License
+giving you legal permission to copy, distribute and/or modify it.
+.PP
+For the developers' and authors' protection, the \s-1GPL\s0 clearly explains
+that there is no warranty for this free software.  For both users' and
+authors' sake, the \s-1GPL\s0 requires that modified versions be marked as
+changed, so that their problems will not be attributed erroneously to
+authors of previous versions.
+.PP
+Some devices are designed to deny users access to install or run
+modified versions of the software inside them, although the
+manufacturer can do so.  This is fundamentally incompatible with the
+aim of protecting users' freedom to change the software.  The
+systematic pattern of such abuse occurs in the area of products for
+individuals to use, which is precisely where it is most unacceptable.
+Therefore, we have designed this version of the \s-1GPL\s0 to prohibit the
+practice for those products.  If such problems arise substantially in
+other domains, we stand ready to extend this provision to those
+domains in future versions of the \s-1GPL,\s0 as needed to protect the
+freedom of users.
+.PP
+Finally, every program is threatened constantly by software patents.
+States should not allow patents to restrict development and use of
+software on general-purpose computers, but in those that do, we wish
+to avoid the special danger that patents applied to a free program
+could make it effectively proprietary.  To prevent this, the \s-1GPL\s0
+assures that patents cannot be used to render the program non-free.
+.PP
+The precise terms and conditions for copying, distribution and
+modification follow.
+.SS "\s-1TERMS AND CONDITIONS\s0"
+.IX Subsection "TERMS AND CONDITIONS"
+.IP "0. Definitions." 4
+.IX Item "0. Definitions."
+\&\*(L"This License\*(R" refers to version 3 of the \s-1GNU\s0 General Public License.
+.Sp
+\&\*(L"Copyright\*(R" also means copyright-like laws that apply to other kinds
+of works, such as semiconductor masks.
+.Sp
+\&\*(L"The Program\*(R" refers to any copyrightable work licensed under this
+License.  Each licensee is addressed as \*(L"you\*(R".  \*(L"Licensees\*(R" and
+\&\*(L"recipients\*(R" may be individuals or organizations.
+.Sp
+To \*(L"modify\*(R" a work means to copy from or adapt all or part of the work
+in a fashion requiring copyright permission, other than the making of
+an exact copy.  The resulting work is called a \*(L"modified version\*(R" of
+the earlier work or a work \*(L"based on\*(R" the earlier work.
+.Sp
+A \*(L"covered work\*(R" means either the unmodified Program or a work based
+on the Program.
+.Sp
+To \*(L"propagate\*(R" a work means to do anything with it that, without
+permission, would make you directly or secondarily liable for
+infringement under applicable copyright law, except executing it on a
+computer or modifying a private copy.  Propagation includes copying,
+distribution (with or without modification), making available to the
+public, and in some countries other activities as well.
+.Sp
+To \*(L"convey\*(R" a work means any kind of propagation that enables other
+parties to make or receive copies.  Mere interaction with a user
+through a computer network, with no transfer of a copy, is not
+conveying.
+.Sp
+An interactive user interface displays \*(L"Appropriate Legal Notices\*(R" to
+the extent that it includes a convenient and prominently visible
+feature that (1) displays an appropriate copyright notice, and (2)
+tells the user that there is no warranty for the work (except to the
+extent that warranties are provided), that licensees may convey the
+work under this License, and how to view a copy of this License.  If
+the interface presents a list of user commands or options, such as a
+menu, a prominent item in the list meets this criterion.
+.IP "1. Source Code." 4
+.IX Item "1. Source Code."
+The \*(L"source code\*(R" for a work means the preferred form of the work for
+making modifications to it.  \*(L"Object code\*(R" means any non-source form
+of a work.
+.Sp
+A \*(L"Standard Interface\*(R" means an interface that either is an official
+standard defined by a recognized standards body, or, in the case of
+interfaces specified for a particular programming language, one that
+is widely used among developers working in that language.
+.Sp
+The \*(L"System Libraries\*(R" of an executable work include anything, other
+than the work as a whole, that (a) is included in the normal form of
+packaging a Major Component, but which is not part of that Major
+Component, and (b) serves only to enable use of the work with that
+Major Component, or to implement a Standard Interface for which an
+implementation is available to the public in source code form.  A
+\&\*(L"Major Component\*(R", in this context, means a major essential component
+(kernel, window system, and so on) of the specific operating system
+(if any) on which the executable work runs, or a compiler used to
+produce the work, or an object code interpreter used to run it.
+.Sp
+The \*(L"Corresponding Source\*(R" for a work in object code form means all
+the source code needed to generate, install, and (for an executable
+work) run the object code and to modify the work, including scripts to
+control those activities.  However, it does not include the work's
+System Libraries, or general-purpose tools or generally available free
+programs which are used unmodified in performing those activities but
+which are not part of the work.  For example, Corresponding Source
+includes interface definition files associated with source files for
+the work, and the source code for shared libraries and dynamically
+linked subprograms that the work is specifically designed to require,
+such as by intimate data communication or control flow between those
+subprograms and other parts of the work.
+.Sp
+The Corresponding Source need not include anything that users can
+regenerate automatically from other parts of the Corresponding Source.
+.Sp
+The Corresponding Source for a work in source code form is that same
+work.
+.IP "2. Basic Permissions." 4
+.IX Item "2. Basic Permissions."
+All rights granted under this License are granted for the term of
+copyright on the Program, and are irrevocable provided the stated
+conditions are met.  This License explicitly affirms your unlimited
+permission to run the unmodified Program.  The output from running a
+covered work is covered by this License only if the output, given its
+content, constitutes a covered work.  This License acknowledges your
+rights of fair use or other equivalent, as provided by copyright law.
+.Sp
+You may make, run and propagate covered works that you do not convey,
+without conditions so long as your license otherwise remains in force.
+You may convey covered works to others for the sole purpose of having
+them make modifications exclusively for you, or provide you with
+facilities for running those works, provided that you comply with the
+terms of this License in conveying all material for which you do not
+control copyright.  Those thus making or running the covered works for
+you must do so exclusively on your behalf, under your direction and
+control, on terms that prohibit them from making any copies of your
+copyrighted material outside their relationship with you.
+.Sp
+Conveying under any other circumstances is permitted solely under the
+conditions stated below.  Sublicensing is not allowed; section 10
+makes it unnecessary.
+.IP "3. Protecting Users' Legal Rights From Anti-Circumvention Law." 4
+.IX Item "3. Protecting Users' Legal Rights From Anti-Circumvention Law."
+No covered work shall be deemed part of an effective technological
+measure under any applicable law fulfilling obligations under article
+11 of the \s-1WIPO\s0 copyright treaty adopted on 20 December 1996, or
+similar laws prohibiting or restricting circumvention of such
+measures.
+.Sp
+When you convey a covered work, you waive any legal power to forbid
+circumvention of technological measures to the extent such
+circumvention is effected by exercising rights under this License with
+respect to the covered work, and you disclaim any intention to limit
+operation or modification of the work as a means of enforcing, against
+the work's users, your or third parties' legal rights to forbid
+circumvention of technological measures.
+.IP "4. Conveying Verbatim Copies." 4
+.IX Item "4. Conveying Verbatim Copies."
+You may convey verbatim copies of the Program's source code as you
+receive it, in any medium, provided that you conspicuously and
+appropriately publish on each copy an appropriate copyright notice;
+keep intact all notices stating that this License and any
+non-permissive terms added in accord with section 7 apply to the code;
+keep intact all notices of the absence of any warranty; and give all
+recipients a copy of this License along with the Program.
+.Sp
+You may charge any price or no price for each copy that you convey,
+and you may offer support or warranty protection for a fee.
+.IP "5. Conveying Modified Source Versions." 4
+.IX Item "5. Conveying Modified Source Versions."
+You may convey a work based on the Program, or the modifications to
+produce it from the Program, in the form of source code under the
+terms of section 4, provided that you also meet all of these
+conditions:
+.RS 4
+.IP "a." 4
+.IX Item "a."
+The work must carry prominent notices stating that you modified it,
+and giving a relevant date.
+.IP "b." 4
+.IX Item "b."
+The work must carry prominent notices stating that it is released
+under this License and any conditions added under section 7.  This
+requirement modifies the requirement in section 4 to \*(L"keep intact all
+notices\*(R".
+.IP "c." 4
+.IX Item "c."
+You must license the entire work, as a whole, under this License to
+anyone who comes into possession of a copy.  This License will
+therefore apply, along with any applicable section 7 additional terms,
+to the whole of the work, and all its parts, regardless of how they
+are packaged.  This License gives no permission to license the work in
+any other way, but it does not invalidate such permission if you have
+separately received it.
+.IP "d." 4
+.IX Item "d."
+If the work has interactive user interfaces, each must display
+Appropriate Legal Notices; however, if the Program has interactive
+interfaces that do not display Appropriate Legal Notices, your work
+need not make them do so.
+.RE
+.RS 4
+.Sp
+A compilation of a covered work with other separate and independent
+works, which are not by their nature extensions of the covered work,
+and which are not combined with it such as to form a larger program,
+in or on a volume of a storage or distribution medium, is called an
+\&\*(L"aggregate\*(R" if the compilation and its resulting copyright are not
+used to limit the access or legal rights of the compilation's users
+beyond what the individual works permit.  Inclusion of a covered work
+in an aggregate does not cause this License to apply to the other
+parts of the aggregate.
+.RE
+.IP "6. Conveying Non-Source Forms." 4
+.IX Item "6. Conveying Non-Source Forms."
+You may convey a covered work in object code form under the terms of
+sections 4 and 5, provided that you also convey the machine-readable
+Corresponding Source under the terms of this License, in one of these
+ways:
+.RS 4
+.IP "a." 4
+.IX Item "a."
+Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by the
+Corresponding Source fixed on a durable physical medium customarily
+used for software interchange.
+.IP "b." 4
+.IX Item "b."
+Convey the object code in, or embodied in, a physical product
+(including a physical distribution medium), accompanied by a written
+offer, valid for at least three years and valid for as long as you
+offer spare parts or customer support for that product model, to give
+anyone who possesses the object code either (1) a copy of the
+Corresponding Source for all the software in the product that is
+covered by this License, on a durable physical medium customarily used
+for software interchange, for a price no more than your reasonable
+cost of physically performing this conveying of source, or (2) access
+to copy the Corresponding Source from a network server at no charge.
+.IP "c." 4
+.IX Item "c."
+Convey individual copies of the object code with a copy of the written
+offer to provide the Corresponding Source.  This alternative is
+allowed only occasionally and noncommercially, and only if you
+received the object code with such an offer, in accord with subsection
+6b.
+.IP "d." 4
+.IX Item "d."
+Convey the object code by offering access from a designated place
+(gratis or for a charge), and offer equivalent access to the
+Corresponding Source in the same way through the same place at no
+further charge.  You need not require recipients to copy the
+Corresponding Source along with the object code.  If the place to copy
+the object code is a network server, the Corresponding Source may be
+on a different server (operated by you or a third party) that supports
+equivalent copying facilities, provided you maintain clear directions
+next to the object code saying where to find the Corresponding Source.
+Regardless of what server hosts the Corresponding Source, you remain
+obligated to ensure that it is available for as long as needed to
+satisfy these requirements.
+.IP "e." 4
+.IX Item "e."
+Convey the object code using peer-to-peer transmission, provided you
+inform other peers where the object code and Corresponding Source of
+the work are being offered to the general public at no charge under
+subsection 6d.
+.RE
+.RS 4
+.Sp
+A separable portion of the object code, whose source code is excluded
+from the Corresponding Source as a System Library, need not be
+included in conveying the object code work.
+.Sp
+A \*(L"User Product\*(R" is either (1) a \*(L"consumer product\*(R", which means any
+tangible personal property which is normally used for personal,
+family, or household purposes, or (2) anything designed or sold for
+incorporation into a dwelling.  In determining whether a product is a
+consumer product, doubtful cases shall be resolved in favor of
+coverage.  For a particular product received by a particular user,
+\&\*(L"normally used\*(R" refers to a typical or common use of that class of
+product, regardless of the status of the particular user or of the way
+in which the particular user actually uses, or expects or is expected
+to use, the product.  A product is a consumer product regardless of
+whether the product has substantial commercial, industrial or
+non-consumer uses, unless such uses represent the only significant
+mode of use of the product.
+.Sp
+\&\*(L"Installation Information\*(R" for a User Product means any methods,
+procedures, authorization keys, or other information required to
+install and execute modified versions of a covered work in that User
+Product from a modified version of its Corresponding Source.  The
+information must suffice to ensure that the continued functioning of
+the modified object code is in no case prevented or interfered with
+solely because modification has been made.
+.Sp
+If you convey an object code work under this section in, or with, or
+specifically for use in, a User Product, and the conveying occurs as
+part of a transaction in which the right of possession and use of the
+User Product is transferred to the recipient in perpetuity or for a
+fixed term (regardless of how the transaction is characterized), the
+Corresponding Source conveyed under this section must be accompanied
+by the Installation Information.  But this requirement does not apply
+if neither you nor any third party retains the ability to install
+modified object code on the User Product (for example, the work has
+been installed in \s-1ROM\s0).
+.Sp
+The requirement to provide Installation Information does not include a
+requirement to continue to provide support service, warranty, or
+updates for a work that has been modified or installed by the
+recipient, or for the User Product in which it has been modified or
+installed.  Access to a network may be denied when the modification
+itself materially and adversely affects the operation of the network
+or violates the rules and protocols for communication across the
+network.
+.Sp
+Corresponding Source conveyed, and Installation Information provided,
+in accord with this section must be in a format that is publicly
+documented (and with an implementation available to the public in
+source code form), and must require no special password or key for
+unpacking, reading or copying.
+.RE
+.IP "7. Additional Terms." 4
+.IX Item "7. Additional Terms."
+\&\*(L"Additional permissions\*(R" are terms that supplement the terms of this
+License by making exceptions from one or more of its conditions.
+Additional permissions that are applicable to the entire Program shall
+be treated as though they were included in this License, to the extent
+that they are valid under applicable law.  If additional permissions
+apply only to part of the Program, that part may be used separately
+under those permissions, but the entire Program remains governed by
+this License without regard to the additional permissions.
+.Sp
+When you convey a copy of a covered work, you may at your option
+remove any additional permissions from that copy, or from any part of
+it.  (Additional permissions may be written to require their own
+removal in certain cases when you modify the work.)  You may place
+additional permissions on material, added by you to a covered work,
+for which you have or can give appropriate copyright permission.
+.Sp
+Notwithstanding any other provision of this License, for material you
+add to a covered work, you may (if authorized by the copyright holders
+of that material) supplement the terms of this License with terms:
+.RS 4
+.IP "a." 4
+.IX Item "a."
+Disclaiming warranty or limiting liability differently from the terms
+of sections 15 and 16 of this License; or
+.IP "b." 4
+.IX Item "b."
+Requiring preservation of specified reasonable legal notices or author
+attributions in that material or in the Appropriate Legal Notices
+displayed by works containing it; or
+.IP "c." 4
+.IX Item "c."
+Prohibiting misrepresentation of the origin of that material, or
+requiring that modified versions of such material be marked in
+reasonable ways as different from the original version; or
+.IP "d." 4
+.IX Item "d."
+Limiting the use for publicity purposes of names of licensors or
+authors of the material; or
+.IP "e." 4
+.IX Item "e."
+Declining to grant rights under trademark law for use of some trade
+names, trademarks, or service marks; or
+.IP "f." 4
+.IX Item "f."
+Requiring indemnification of licensors and authors of that material by
+anyone who conveys the material (or modified versions of it) with
+contractual assumptions of liability to the recipient, for any
+liability that these contractual assumptions directly impose on those
+licensors and authors.
+.RE
+.RS 4
+.Sp
+All other non-permissive additional terms are considered \*(L"further
+restrictions\*(R" within the meaning of section 10.  If the Program as you
+received it, or any part of it, contains a notice stating that it is
+governed by this License along with a term that is a further
+restriction, you may remove that term.  If a license document contains
+a further restriction but permits relicensing or conveying under this
+License, you may add to a covered work material governed by the terms
+of that license document, provided that the further restriction does
+not survive such relicensing or conveying.
+.Sp
+If you add terms to a covered work in accord with this section, you
+must place, in the relevant source files, a statement of the
+additional terms that apply to those files, or a notice indicating
+where to find the applicable terms.
+.Sp
+Additional terms, permissive or non-permissive, may be stated in the
+form of a separately written license, or stated as exceptions; the
+above requirements apply either way.
+.RE
+.IP "8. Termination." 4
+.IX Item "8. Termination."
+You may not propagate or modify a covered work except as expressly
+provided under this License.  Any attempt otherwise to propagate or
+modify it is void, and will automatically terminate your rights under
+this License (including any patent licenses granted under the third
+paragraph of section 11).
+.Sp
+However, if you cease all violation of this License, then your license
+from a particular copyright holder is reinstated (a) provisionally,
+unless and until the copyright holder explicitly and finally
+terminates your license, and (b) permanently, if the copyright holder
+fails to notify you of the violation by some reasonable means prior to
+60 days after the cessation.
+.Sp
+Moreover, your license from a particular copyright holder is
+reinstated permanently if the copyright holder notifies you of the
+violation by some reasonable means, this is the first time you have
+received notice of violation of this License (for any work) from that
+copyright holder, and you cure the violation prior to 30 days after
+your receipt of the notice.
+.Sp
+Termination of your rights under this section does not terminate the
+licenses of parties who have received copies or rights from you under
+this License.  If your rights have been terminated and not permanently
+reinstated, you do not qualify to receive new licenses for the same
+material under section 10.
+.IP "9. Acceptance Not Required for Having Copies." 4
+.IX Item "9. Acceptance Not Required for Having Copies."
+You are not required to accept this License in order to receive or run
+a copy of the Program.  Ancillary propagation of a covered work
+occurring solely as a consequence of using peer-to-peer transmission
+to receive a copy likewise does not require acceptance.  However,
+nothing other than this License grants you permission to propagate or
+modify any covered work.  These actions infringe copyright if you do
+not accept this License.  Therefore, by modifying or propagating a
+covered work, you indicate your acceptance of this License to do so.
+.IP "10. Automatic Licensing of Downstream Recipients." 4
+.IX Item "10. Automatic Licensing of Downstream Recipients."
+Each time you convey a covered work, the recipient automatically
+receives a license from the original licensors, to run, modify and
+propagate that work, subject to this License.  You are not responsible
+for enforcing compliance by third parties with this License.
+.Sp
+An \*(L"entity transaction\*(R" is a transaction transferring control of an
+organization, or substantially all assets of one, or subdividing an
+organization, or merging organizations.  If propagation of a covered
+work results from an entity transaction, each party to that
+transaction who receives a copy of the work also receives whatever
+licenses to the work the party's predecessor in interest had or could
+give under the previous paragraph, plus a right to possession of the
+Corresponding Source of the work from the predecessor in interest, if
+the predecessor has it or can get it with reasonable efforts.
+.Sp
+You may not impose any further restrictions on the exercise of the
+rights granted or affirmed under this License.  For example, you may
+not impose a license fee, royalty, or other charge for exercise of
+rights granted under this License, and you may not initiate litigation
+(including a cross-claim or counterclaim in a lawsuit) alleging that
+any patent claim is infringed by making, using, selling, offering for
+sale, or importing the Program or any portion of it.
+.IP "11. Patents." 4
+.IX Item "11. Patents."
+A \*(L"contributor\*(R" is a copyright holder who authorizes use under this
+License of the Program or a work on which the Program is based.  The
+work thus licensed is called the contributor's \*(L"contributor version\*(R".
+.Sp
+A contributor's \*(L"essential patent claims\*(R" are all patent claims owned
+or controlled by the contributor, whether already acquired or
+hereafter acquired, that would be infringed by some manner, permitted
+by this License, of making, using, or selling its contributor version,
+but do not include claims that would be infringed only as a
+consequence of further modification of the contributor version.  For
+purposes of this definition, \*(L"control\*(R" includes the right to grant
+patent sublicenses in a manner consistent with the requirements of
+this License.
+.Sp
+Each contributor grants you a non-exclusive, worldwide, royalty-free
+patent license under the contributor's essential patent claims, to
+make, use, sell, offer for sale, import and otherwise run, modify and
+propagate the contents of its contributor version.
+.Sp
+In the following three paragraphs, a \*(L"patent license\*(R" is any express
+agreement or commitment, however denominated, not to enforce a patent
+(such as an express permission to practice a patent or covenant not to
+sue for patent infringement).  To \*(L"grant\*(R" such a patent license to a
+party means to make such an agreement or commitment not to enforce a
+patent against the party.
+.Sp
+If you convey a covered work, knowingly relying on a patent license,
+and the Corresponding Source of the work is not available for anyone
+to copy, free of charge and under the terms of this License, through a
+publicly available network server or other readily accessible means,
+then you must either (1) cause the Corresponding Source to be so
+available, or (2) arrange to deprive yourself of the benefit of the
+patent license for this particular work, or (3) arrange, in a manner
+consistent with the requirements of this License, to extend the patent
+license to downstream recipients.  \*(L"Knowingly relying\*(R" means you have
+actual knowledge that, but for the patent license, your conveying the
+covered work in a country, or your recipient's use of the covered work
+in a country, would infringe one or more identifiable patents in that
+country that you have reason to believe are valid.
+.Sp
+If, pursuant to or in connection with a single transaction or
+arrangement, you convey, or propagate by procuring conveyance of, a
+covered work, and grant a patent license to some of the parties
+receiving the covered work authorizing them to use, propagate, modify
+or convey a specific copy of the covered work, then the patent license
+you grant is automatically extended to all recipients of the covered
+work and works based on it.
+.Sp
+A patent license is \*(L"discriminatory\*(R" if it does not include within the
+scope of its coverage, prohibits the exercise of, or is conditioned on
+the non-exercise of one or more of the rights that are specifically
+granted under this License.  You may not convey a covered work if you
+are a party to an arrangement with a third party that is in the
+business of distributing software, under which you make payment to the
+third party based on the extent of your activity of conveying the
+work, and under which the third party grants, to any of the parties
+who would receive the covered work from you, a discriminatory patent
+license (a) in connection with copies of the covered work conveyed by
+you (or copies made from those copies), or (b) primarily for and in
+connection with specific products or compilations that contain the
+covered work, unless you entered into that arrangement, or that patent
+license was granted, prior to 28 March 2007.
+.Sp
+Nothing in this License shall be construed as excluding or limiting
+any implied license or other defenses to infringement that may
+otherwise be available to you under applicable patent law.
+.IP "12. No Surrender of Others' Freedom." 4
+.IX Item "12. No Surrender of Others' Freedom."
+If conditions are imposed on you (whether by court order, agreement or
+otherwise) that contradict the conditions of this License, they do not
+excuse you from the conditions of this License.  If you cannot convey
+a covered work so as to satisfy simultaneously your obligations under
+this License and any other pertinent obligations, then as a
+consequence you may not convey it at all.  For example, if you agree
+to terms that obligate you to collect a royalty for further conveying
+from those to whom you convey the Program, the only way you could
+satisfy both those terms and this License would be to refrain entirely
+from conveying the Program.
+.IP "13. Use with the \s-1GNU\s0 Affero General Public License." 4
+.IX Item "13. Use with the GNU Affero General Public License."
+Notwithstanding any other provision of this License, you have
+permission to link or combine any covered work with a work licensed
+under version 3 of the \s-1GNU\s0 Affero General Public License into a single
+combined work, and to convey the resulting work.  The terms of this
+License will continue to apply to the part which is the covered work,
+but the special requirements of the \s-1GNU\s0 Affero General Public License,
+section 13, concerning interaction through a network will apply to the
+combination as such.
+.IP "14. Revised Versions of this License." 4
+.IX Item "14. Revised Versions of this License."
+The Free Software Foundation may publish revised and/or new versions
+of the \s-1GNU\s0 General Public License from time to time.  Such new
+versions will be similar in spirit to the present version, but may
+differ in detail to address new problems or concerns.
+.Sp
+Each version is given a distinguishing version number.  If the Program
+specifies that a certain numbered version of the \s-1GNU\s0 General Public
+License \*(L"or any later version\*(R" applies to it, you have the option of
+following the terms and conditions either of that numbered version or
+of any later version published by the Free Software Foundation.  If
+the Program does not specify a version number of the \s-1GNU\s0 General
+Public License, you may choose any version ever published by the Free
+Software Foundation.
+.Sp
+If the Program specifies that a proxy can decide which future versions
+of the \s-1GNU\s0 General Public License can be used, that proxy's public
+statement of acceptance of a version permanently authorizes you to
+choose that version for the Program.
+.Sp
+Later license versions may give you additional or different
+permissions.  However, no additional obligations are imposed on any
+author or copyright holder as a result of your choosing to follow a
+later version.
+.IP "15. Disclaimer of Warranty." 4
+.IX Item "15. Disclaimer of Warranty."
+\&\s-1THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY
+APPLICABLE LAW.  EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT
+HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM \*(L"AS IS\*(R" WITHOUT
+WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT
+LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR
+A PARTICULAR PURPOSE.  THE ENTIRE RISK AS TO THE QUALITY AND
+PERFORMANCE OF THE PROGRAM IS WITH YOU.  SHOULD THE PROGRAM PROVE
+DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR
+CORRECTION.\s0
+.IP "16. Limitation of Liability." 4
+.IX Item "16. Limitation of Liability."
+\&\s-1IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING
+WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MODIFIES AND/OR
+CONVEYS THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES,
+INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES
+ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM \s0(\s-1INCLUDING BUT
+NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR
+LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM
+TO OPERATE WITH ANY OTHER PROGRAMS\s0), \s-1EVEN IF SUCH HOLDER OR OTHER
+PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.\s0
+.IP "17. Interpretation of Sections 15 and 16." 4
+.IX Item "17. Interpretation of Sections 15 and 16."
+If the disclaimer of warranty and limitation of liability provided
+above cannot be given local legal effect according to their terms,
+reviewing courts shall apply local law that most closely approximates
+an absolute waiver of all civil liability in connection with the
+Program, unless a warranty or assumption of liability accompanies a
+copy of the Program in return for a fee.
+.SS "\s-1END OF TERMS AND CONDITIONS\s0"
+.IX Subsection "END OF TERMS AND CONDITIONS"
+.SS "How to Apply These Terms to Your New Programs"
+.IX Subsection "How to Apply These Terms to Your New Programs"
+If you develop a new program, and you want it to be of the greatest
+possible use to the public, the best way to achieve this is to make it
+free software which everyone can redistribute and change under these
+terms.
+.PP
+To do so, attach the following notices to the program.  It is safest
+to attach them to the start of each source file to most effectively
+state the exclusion of warranty; and each file should have at least
+the \*(L"copyright\*(R" line and a pointer to where the full notice is found.
+.PP
+.Vb 2
+\&        <one line to give the program\*(Aqs name and a brief idea of what it does.>  
+\&        Copyright (C) <year> <name of author>
+\&        
+\&        This program is free software: you can redistribute it and/or modify
+\&        it under the terms of the GNU General Public License as published by
+\&        the Free Software Foundation, either version 3 of the License, or (at
+\&        your option) any later version.
+\&        
+\&        This program is distributed in the hope that it will be useful, but
+\&        WITHOUT ANY WARRANTY; without even the implied warranty of
+\&        MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
+\&        General Public License for more details.
+\&        
+\&        You should have received a copy of the GNU General Public License
+\&        along with this program.  If not, see <http://www.gnu.org/licenses/>.
+.Ve
+.PP
+Also add information on how to contact you by electronic and paper mail.
+.PP
+If the program does terminal interaction, make it output a short
+notice like this when it starts in an interactive mode:
+.PP
+.Vb 4
+\&        <program> Copyright (C) <year> <name of author> 
+\&        This program comes with ABSOLUTELY NO WARRANTY; for details type "show w".
+\&        This is free software, and you are welcome to redistribute it
+\&        under certain conditions; type "show c" for details.
+.Ve
+.PP
+The hypothetical commands \fBshow w\fR and \fBshow c\fR should show
+the appropriate parts of the General Public License.  Of course, your
+program's commands might be different; for a \s-1GUI\s0 interface, you would
+use an \*(L"about box\*(R".
+.PP
+You should also get your employer (if you work as a programmer) or school,
+if any, to sign a \*(L"copyright disclaimer\*(R" for the program, if necessary.
+For more information on this, and how to apply and follow the \s-1GNU GPL,\s0 see
+<\fBhttp://www.gnu.org/licenses/\fR>.
+.PP
+The \s-1GNU\s0 General Public License does not permit incorporating your
+program into proprietary programs.  If your program is a subroutine
+library, you may consider it more useful to permit linking proprietary
+applications with the library.  If this is what you want to do, use
+the \s-1GNU\s0 Lesser General Public License instead of this License.  But
+first, please read <\fBhttp://www.gnu.org/philosophy/why\-not\-lgpl.html\fR>.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgfdl\fR\|(7), \fIfsf\-funding\fR\|(7).
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2007 Free Software Foundation, Inc.
+.PP
+Everyone is permitted to copy and distribute verbatim copies of this
+license document, but changing it is not allowed.
diff --git a/gcc-4.9/gcc/doc/grmic.1 b/gcc-4.9/gcc/doc/grmic.1
new file mode 100644
index 000000000..4706a5c09
--- /dev/null
+++ b/gcc-4.9/gcc/doc/grmic.1
@@ -0,0 +1,222 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "GRMIC 1"
+.TH GRMIC 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+grmic \- Generate stubs for Remote Method Invocation
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBgrmic\fR [\fB\s-1OPTION\s0\fR] ... \fIclass\fR ...
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBgrmic\fR is a utility included with \f(CW\*(C`libgcj\*(C'\fR which generates
+stubs for remote objects.
+.PP
+Note that this program isn't yet fully compatible with the \s-1JDK
+\&\s0\fBgrmic\fR.  Some options, such as \fB\-classpath\fR, are
+recognized but currently ignored.  We have left these options
+undocumented for now.
+.PP
+Long options can also be given with a GNU-style leading \fB\-\-\fR.  For
+instance, \fB\-\-help\fR is accepted.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-keep\fR" 4
+.IX Item "-keep"
+.PD 0
+.IP "\fB\-keepgenerated\fR" 4
+.IX Item "-keepgenerated"
+.PD
+By default, \fBgrmic\fR deletes intermediate files.  Either of these
+options causes it not to delete such files.
+.IP "\fB\-v1.1\fR" 4
+.IX Item "-v1.1"
+Cause \fBgrmic\fR to create stubs and skeletons for the 1.1
+protocol version.
+.IP "\fB\-vcompat\fR" 4
+.IX Item "-vcompat"
+Cause \fBgrmic\fR to create stubs and skeletons compatible with both
+the 1.1 and 1.2 protocol versions.  This is the default.
+.IP "\fB\-v1.2\fR" 4
+.IX Item "-v1.2"
+Cause \fBgrmic\fR to create stubs and skeletons for the 1.2
+protocol version.
+.IP "\fB\-nocompile\fR" 4
+.IX Item "-nocompile"
+Don't compile the generated files.
+.IP "\fB\-verbose\fR" 4
+.IX Item "-verbose"
+Print information about what \fBgrmic\fR is doing.
+.IP "\fB\-d\fR \fIdirectory\fR" 4
+.IX Item "-d directory"
+Put output files in \fIdirectory\fR.  By default the files are put in
+the current working directory.
+.IP "\fB\-help\fR" 4
+.IX Item "-help"
+Print a help message, then exit.
+.IP "\fB\-version\fR" 4
+.IX Item "-version"
+Print version information, then exit.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/install.texi b/gcc-4.9/gcc/doc/install.texi
index dc040cbc3..c32f1f90e 100644
--- a/gcc-4.9/gcc/doc/install.texi
+++ b/gcc-4.9/gcc/doc/install.texi
@@ -3144,6 +3144,10 @@ information have to.
 @item
 @uref{#mips-sgi-irix6,,mips-sgi-irix6}
 @item
+@uref{#nds32le-x-elf,,nds32le-*-elf}
+@item
+@uref{#nds32be-x-elf,,nds32be-*-elf}
+@item
 @uref{#powerpc-x-x,,powerpc*-*-*}
 @item
 @uref{#powerpc-x-darwin,,powerpc-*-darwin*}
@@ -4100,6 +4104,20 @@ This configuration is intended for embedded systems.
 @html
 <hr />
 @end html
+@anchor{nds32le-x-elf}
+@heading nds32le-*-elf
+Andes NDS32 target in little endian mode.
+
+@html
+<hr />
+@end html
+@anchor{nds32be-x-elf}
+@heading nds32be-*-elf
+Andes NDS32 target in big endian mode.
+
+@html
+<hr />
+@end html
 @anchor{powerpc-x-x}
 @heading powerpc-*-*
 You can specify a default version for the @option{-mcpu=@var{cpu_type}}
diff --git a/gcc-4.9/gcc/doc/invoke.texi b/gcc-4.9/gcc/doc/invoke.texi
index 78ddde07f..2d43457c2 100644
--- a/gcc-4.9/gcc/doc/invoke.texi
+++ b/gcc-4.9/gcc/doc/invoke.texi
@@ -1070,6 +1070,7 @@ See S/390 and zSeries Options.
 -ffixed-@var{reg}  -fexceptions @gol
 -fnon-call-exceptions  -fdelete-dead-exceptions  -funwind-tables @gol
 -fasynchronous-unwind-tables @gol
+-fno-gnu-unique @gol
 -finhibit-size-directive  -finstrument-functions @gol
 -finstrument-functions-exclude-function-list=@var{sym},@var{sym},@dots{} @gol
 -finstrument-functions-exclude-file-list=@var{file},@var{file},@dots{} @gol
@@ -1088,28 +1089,6 @@ See S/390 and zSeries Options.
 -fvisibility -fstrict-volatile-bitfields -fsync-libcalls}
 @end table
 
-@menu
-* Overall Options::     Controlling the kind of output:
-                        an executable, object files, assembler files,
-                        or preprocessed source.
-* C Dialect Options::   Controlling the variant of C language compiled.
-* C++ Dialect Options:: Variations on C++.
-* Objective-C and Objective-C++ Dialect Options:: Variations on Objective-C
-                        and Objective-C++.
-* Language Independent Options:: Controlling how diagnostics should be
-                        formatted.
-* Warning Options::     How picky should the compiler be?
-* Debugging Options::   Symbol tables, measurements, and debugging dumps.
-* Optimize Options::    How much optimization?
-* Preprocessor Options:: Controlling header files and macro definitions.
-                         Also, getting dependency information for Make.
-* Assembler Options::   Passing options to the assembler.
-* Link Options::        Specifying libraries and so on.
-* Directory Options::   Where to find header files and libraries.
-                        Where to find the compiler executable files.
-* Spec Files::          How to pass switches to sub-processes.
-* Target Options::      Running a cross-compiler, or an old version of GCC.
-@end menu
 
 @node Overall Options
 @section Options Controlling the Kind of Output
@@ -2670,9 +2649,10 @@ the compiler to never throw an exception.
 @opindex Wnon-virtual-dtor
 @opindex Wno-non-virtual-dtor
 Warn when a class has virtual functions and an accessible non-virtual
-destructor, in which case it is possible but unsafe to delete
-an instance of a derived class through a pointer to the base class.
-This warning is also enabled if @option{-Weffc++} is specified.
+destructor itself or in an accessible polymorphic base class, in which
+case it is possible but unsafe to delete an instance of a derived
+class through a pointer to the class itself or base class.  This
+warning is automatically enabled if @option{-Weffc++} is specified.
 
 @item -Wreorder @r{(C++ and Objective-C++ only)}
 @opindex Wreorder
@@ -2716,40 +2696,36 @@ The following @option{-W@dots{}} options are not affected by @option{-Wall}.
 @opindex Weffc++
 @opindex Wno-effc++
 Warn about violations of the following style guidelines from Scott Meyers'
-@cite{Effective C++, Second Edition} book:
+@cite{Effective C++} series of books:
 
 @itemize @bullet
 @item
-Item 11:  Define a copy constructor and an assignment operator for classes
+Define a copy constructor and an assignment operator for classes
 with dynamically-allocated memory.
 
 @item
-Item 12:  Prefer initialization to assignment in constructors.
-
-@item
-Item 14:  Make destructors virtual in base classes.
+Prefer initialization to assignment in constructors.
 
 @item
-Item 15:  Have @code{operator=} return a reference to @code{*this}.
+Have @code{operator=} return a reference to @code{*this}.
 
 @item
-Item 23:  Don't try to return a reference when you must return an object.
-
-@end itemize
-
-Also warn about violations of the following style guidelines from
-Scott Meyers' @cite{More Effective C++} book:
+Don't try to return a reference when you must return an object.
 
-@itemize @bullet
 @item
-Item 6:  Distinguish between prefix and postfix forms of increment and
+Distinguish between prefix and postfix forms of increment and
 decrement operators.
 
 @item
-Item 7:  Never overload @code{&&}, @code{||}, or @code{,}.
+Never overload @code{&&}, @code{||}, or @code{,}.
 
 @end itemize
 
+This option also enables @option{-Wnon-virtual-dtor}, which is also
+one of the effective C++ recommendations.  However, the check is
+extended to warn about the lack of virtual destructor in accessible
+non-polymorphic bases classes too.
+
 When selecting this option, be aware that the standard library
 headers do not obey all of these guidelines; use @samp{grep -v}
 to filter out those warnings.
@@ -7414,7 +7390,7 @@ Attempt to remove redundant extension instructions.  This is especially
 helpful for the x86-64 architecture, which implicitly zero-extends in 64-bit
 registers after writing to their lower 32-bit half.
 
-Enabled for x86 at levels @option{-O2}, @option{-O3}.
+Enabled for AArch64 and x86 at levels @option{-O2}, @option{-O3}.
 
 @item -flive-range-shrinkage
 @opindex flive-range-shrinkage
@@ -12988,6 +12964,9 @@ instructions because of a hardware erratum.  Skip instructions are
 The second macro is only defined if @code{__AVR_HAVE_JMP_CALL__} is also
 set.
 
+@item __AVR_ISA_RMW__
+The device has Read-Modify-Write instructions (XCH, LAC, LAS and LAT).
+
 @item __AVR_SFR_OFFSET__=@var{offset}
 Instructions that can address I/O special function registers directly
 like @code{IN}, @code{OUT}, @code{SBI}, etc.@: may use a different
@@ -20848,8 +20827,9 @@ These @samp{-m} options are supported on the SPARC:
 @opindex mno-app-regs
 @opindex mapp-regs
 Specify @option{-mapp-regs} to generate output using the global registers
-2 through 4, which the SPARC SVR4 ABI reserves for applications.  This
-is the default.
+2 through 4, which the SPARC SVR4 ABI reserves for applications.  Like the
+global register 1, each global register 2 through 4 is then treated as an
+allocable register that is clobbered by function calls.  This is the default.
 
 To be fully SVR4 ABI-compliant at the cost of some performance loss,
 specify @option{-mno-app-regs}.  You should compile libraries and system
@@ -22014,6 +21994,20 @@ Generate unwind table in DWARF 2 format, if supported by target machine.  The
 table is exact at each instruction boundary, so it can be used for stack
 unwinding from asynchronous events (such as debugger or garbage collector).
 
+@item -fno-gnu-unique
+@opindex fno-gnu-unique
+On systems with recent GNU assembler and C library, the C++ compiler
+uses the @code{STB_GNU_UNIQUE} binding to make sure that definitions
+of template static data members and static local variables in inline
+functions are unique even in the presence of @code{RTLD_LOCAL}; this
+is necessary to avoid problems with a library used by two different
+@code{RTLD_LOCAL} plugins depending on a definition in one of them and
+therefore disagreeing with the other one about the binding of the
+symbol.  But this causes @code{dlclose} to be ignored for affected
+DSOs; if your program relies on reinitialization of a DSO via
+@code{dlclose} and @code{dlopen}, you can use
+@option{-fno-gnu-unique}.
+
 @item -fpcc-struct-return
 @opindex fpcc-struct-return
 Return ``short'' @code{struct} and @code{union} values in memory like
diff --git a/gcc-4.9/gcc/doc/jcf-dump.1 b/gcc-4.9/gcc/doc/jcf-dump.1
new file mode 100644
index 000000000..eded14430
--- /dev/null
+++ b/gcc-4.9/gcc/doc/jcf-dump.1
@@ -0,0 +1,217 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "JCF-DUMP 1"
+.TH JCF-DUMP 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+jcf\-dump \- print information about Java class files
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+jcf-dump [\fB\-c\fR] [\fB\-\-javap\fR]
+    [\fB\-\-classpath\fR=\fIpath\fR] [\fB\-\-CLASSPATH\fR=\fIpath\fR]
+    [\fB\-I\fR\fIdir\fR...] [\fB\-o\fR \fIfile\fR]
+    [\fB\-\-version\fR] [\fB\-\-help\fR] [\fB\-v\fR] [\fB\-\-verbose\fR]
+    \fIclassname\fR...
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+This is a class file examiner, similar to \f(CW\*(C`javap\*(C'\fR.  It will print
+information about a number of classes, which are specified by class name
+or file name.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-c\fR" 4
+.IX Item "-c"
+Disassemble method bodies.  By default method bodies are not printed.
+.IP "\fB\-\-print\-constants\fR" 4
+.IX Item "--print-constants"
+Print the constant pool.  When printing a reference to a constant
+also print its index in the constant pool.
+.IP "\fB\-\-javap\fR" 4
+.IX Item "--javap"
+Generate output in \f(CW\*(C`javap\*(C'\fR format.  The implementation of this
+feature is very incomplete.
+.IP "\fB\-\-classpath=\fR\fIpath\fR" 4
+.IX Item "--classpath=path"
+.PD 0
+.IP "\fB\-\-CLASSPATH=\fR\fIpath\fR" 4
+.IX Item "--CLASSPATH=path"
+.IP "\fB\-I\fR\fIdirectory\fR" 4
+.IX Item "-Idirectory"
+.IP "\fB\-o\fR \fIfile\fR" 4
+.IX Item "-o file"
+.PD
+These options as the same as the corresponding \fBgcj\fR options.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+Print help, then exit.
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+Print version number, then exit.
+.IP "\fB\-v, \-\-verbose\fR" 4
+.IX Item "-v, --verbose"
+Print extra information while running.
+Implies \f(CW\*(C`\-\-print\-constants\*(C'\fR.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgcc\fR\|(1), \fIgcj\fR\|(1), \fIgcjh\fR\|(1), \fIgij\fR\|(1), \fIjcf\-dump\fR\|(1), \fIgfdl\fR\|(7),
+and the Info entries for \fIgcj\fR and \fIgcc\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/jv-convert.1 b/gcc-4.9/gcc/doc/jv-convert.1
new file mode 100644
index 000000000..a57cc856c
--- /dev/null
+++ b/gcc-4.9/gcc/doc/jv-convert.1
@@ -0,0 +1,210 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "JV-CONVERT 1"
+.TH JV-CONVERT 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+jv\-convert \- Convert file from one encoding to another
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+\&\fBjv-convert\fR [\fB\s-1OPTION\s0\fR] ... [\fI\s-1INPUTFILE\s0\fR [\fI\s-1OUTPUTFILE\s0\fR]]
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\fBjv-convert\fR is a utility included with \f(CW\*(C`libgcj\*(C'\fR which
+converts a file from one encoding to another.  It is similar to the Unix
+\&\fBiconv\fR utility.
+.PP
+The encodings supported by \fBjv-convert\fR are platform-dependent.
+Currently there is no way to get a list of all supported encodings.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.IP "\fB\-\-encoding\fR \fIname\fR" 4
+.IX Item "--encoding name"
+.PD 0
+.IP "\fB\-\-from\fR \fIname\fR" 4
+.IX Item "--from name"
+.PD
+Use \fIname\fR as the input encoding.  The default is the current
+locale's encoding.
+.IP "\fB\-\-to\fR \fIname\fR" 4
+.IX Item "--to name"
+Use \fIname\fR as the output encoding.  The default is the
+\&\f(CW\*(C`JavaSrc\*(C'\fR encoding; this is \s-1ASCII\s0 with \fB\eu\fR escapes for
+non-ASCII characters.
+.IP "\fB\-i\fR \fIfile\fR" 4
+.IX Item "-i file"
+Read from \fIfile\fR.  The default is to read from standard input.
+.IP "\fB\-o\fR \fIfile\fR" 4
+.IX Item "-o file"
+Write to \fIfile\fR.  The default is to write to standard output.
+.IP "\fB\-\-reverse\fR" 4
+.IX Item "--reverse"
+Swap the input and output encodings.
+.IP "\fB\-\-help\fR" 4
+.IX Item "--help"
+Print a help message, then exit.
+.IP "\fB\-\-version\fR" 4
+.IX Item "--version"
+Print version information, then exit.
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/md.texi b/gcc-4.9/gcc/doc/md.texi
index 85fd4b90f..13e34b5e2 100644
--- a/gcc-4.9/gcc/doc/md.texi
+++ b/gcc-4.9/gcc/doc/md.texi
@@ -2162,6 +2162,9 @@ VSX vector register to hold scalar float values or NO_REGS.
 @item wz
 Floating point register if the LFIWZX instruction is enabled or NO_REGS.
 
+@item wD
+Int constant that is the element number of the 64-bit scalar in a vector.
+
 @item wQ
 A memory address that will work with the @code{lq} and @code{stq}
 instructions.
diff --git a/gcc-4.9/gcc/doc/rebuild-gcj-db.1 b/gcc-4.9/gcc/doc/rebuild-gcj-db.1
new file mode 100644
index 000000000..c81d70948
--- /dev/null
+++ b/gcc-4.9/gcc/doc/rebuild-gcj-db.1
@@ -0,0 +1,181 @@
+.\" Automatically generated by Pod::Man 2.27 (Pod::Simple 3.28)
+.\"
+.\" Standard preamble:
+.\" ========================================================================
+.de Sp \" Vertical space (when we can't use .PP)
+.if t .sp .5v
+.if n .sp
+..
+.de Vb \" Begin verbatim text
+.ft CW
+.nf
+.ne \\$1
+..
+.de Ve \" End verbatim text
+.ft R
+.fi
+..
+.\" Set up some character translations and predefined strings.  \*(-- will
+.\" give an unbreakable dash, \*(PI will give pi, \*(L" will give a left
+.\" double quote, and \*(R" will give a right double quote.  \*(C+ will
+.\" give a nicer C++.  Capital omega is used to do unbreakable dashes and
+.\" therefore won't be available.  \*(C` and \*(C' expand to `' in nroff,
+.\" nothing in troff, for use with C<>.
+.tr \(*W-
+.ds C+ C\v'-.1v'\h'-1p'\s-2+\h'-1p'+\s0\v'.1v'\h'-1p'
+.ie n \{\
+.    ds -- \(*W-
+.    ds PI pi
+.    if (\n(.H=4u)&(1m=24u) .ds -- \(*W\h'-12u'\(*W\h'-12u'-\" diablo 10 pitch
+.    if (\n(.H=4u)&(1m=20u) .ds -- \(*W\h'-12u'\(*W\h'-8u'-\"  diablo 12 pitch
+.    ds L" ""
+.    ds R" ""
+.    ds C` ""
+.    ds C' ""
+'br\}
+.el\{\
+.    ds -- \|\(em\|
+.    ds PI \(*p
+.    ds L" ``
+.    ds R" ''
+.    ds C`
+.    ds C'
+'br\}
+.\"
+.\" Escape single quotes in literal strings from groff's Unicode transform.
+.ie \n(.g .ds Aq \(aq
+.el       .ds Aq '
+.\"
+.\" If the F register is turned on, we'll generate index entries on stderr for
+.\" titles (.TH), headers (.SH), subsections (.SS), items (.Ip), and index
+.\" entries marked with X<> in POD.  Of course, you'll have to process the
+.\" output yourself in some meaningful fashion.
+.\"
+.\" Avoid warning from groff about undefined register 'F'.
+.de IX
+..
+.nr rF 0
+.if \n(.g .if rF .nr rF 1
+.if (\n(rF:(\n(.g==0)) \{
+.    if \nF \{
+.        de IX
+.        tm Index:\\$1\t\\n%\t"\\$2"
+..
+.        if !\nF==2 \{
+.            nr % 0
+.            nr F 2
+.        \}
+.    \}
+.\}
+.rr rF
+.\"
+.\" Accent mark definitions (@(#)ms.acc 1.5 88/02/08 SMI; from UCB 4.2).
+.\" Fear.  Run.  Save yourself.  No user-serviceable parts.
+.    \" fudge factors for nroff and troff
+.if n \{\
+.    ds #H 0
+.    ds #V .8m
+.    ds #F .3m
+.    ds #[ \f1
+.    ds #] \fP
+.\}
+.if t \{\
+.    ds #H ((1u-(\\\\n(.fu%2u))*.13m)
+.    ds #V .6m
+.    ds #F 0
+.    ds #[ \&
+.    ds #] \&
+.\}
+.    \" simple accents for nroff and troff
+.if n \{\
+.    ds ' \&
+.    ds ` \&
+.    ds ^ \&
+.    ds , \&
+.    ds ~ ~
+.    ds /
+.\}
+.if t \{\
+.    ds ' \\k:\h'-(\\n(.wu*8/10-\*(#H)'\'\h"|\\n:u"
+.    ds ` \\k:\h'-(\\n(.wu*8/10-\*(#H)'\`\h'|\\n:u'
+.    ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'^\h'|\\n:u'
+.    ds , \\k:\h'-(\\n(.wu*8/10)',\h'|\\n:u'
+.    ds ~ \\k:\h'-(\\n(.wu-\*(#H-.1m)'~\h'|\\n:u'
+.    ds / \\k:\h'-(\\n(.wu*8/10-\*(#H)'\z\(sl\h'|\\n:u'
+.\}
+.    \" troff and (daisy-wheel) nroff accents
+.ds : \\k:\h'-(\\n(.wu*8/10-\*(#H+.1m+\*(#F)'\v'-\*(#V'\z.\h'.2m+\*(#F'.\h'|\\n:u'\v'\*(#V'
+.ds 8 \h'\*(#H'\(*b\h'-\*(#H'
+.ds o \\k:\h'-(\\n(.wu+\w'\(de'u-\*(#H)/2u'\v'-.3n'\*(#[\z\(de\v'.3n'\h'|\\n:u'\*(#]
+.ds d- \h'\*(#H'\(pd\h'-\w'~'u'\v'-.25m'\f2\(hy\fP\v'.25m'\h'-\*(#H'
+.ds D- D\\k:\h'-\w'D'u'\v'-.11m'\z\(hy\v'.11m'\h'|\\n:u'
+.ds th \*(#[\v'.3m'\s+1I\s-1\v'-.3m'\h'-(\w'I'u*2/3)'\s-1o\s+1\*(#]
+.ds Th \*(#[\s+2I\s-2\h'-\w'I'u*3/5'\v'-.3m'o\v'.3m'\*(#]
+.ds ae a\h'-(\w'a'u*4/10)'e
+.ds Ae A\h'-(\w'A'u*4/10)'E
+.    \" corrections for vroff
+.if v .ds ~ \\k:\h'-(\\n(.wu*9/10-\*(#H)'\s-2\u~\d\s+2\h'|\\n:u'
+.if v .ds ^ \\k:\h'-(\\n(.wu*10/11-\*(#H)'\v'-.4m'^\v'.4m'\h'|\\n:u'
+.    \" for low resolution devices (crt and lpr)
+.if \n(.H>23 .if \n(.V>19 \
+\{\
+.    ds : e
+.    ds 8 ss
+.    ds o a
+.    ds d- d\h'-1'\(ga
+.    ds D- D\h'-1'\(hy
+.    ds th \o'bp'
+.    ds Th \o'LP'
+.    ds ae ae
+.    ds Ae AE
+.\}
+.rm #[ #] #H #V #F C
+.\" ========================================================================
+.\"
+.IX Title "REBUILD-GCJ-DB 1"
+.TH REBUILD-GCJ-DB 1 "2014-04-22" "gcc-4.9.0" "GNU"
+.\" For nroff, turn off justification.  Always turn off hyphenation; it makes
+.\" way too many mistakes in technical documents.
+.if n .ad l
+.nh
+.SH "NAME"
+rebuild\-gcj\-db \- Merge the per\-solib databases made by aot\-compile into one system\-wide database.
+.SH "SYNOPSIS"
+.IX Header "SYNOPSIS"
+rebuild-gcj-db
+.SH "DESCRIPTION"
+.IX Header "DESCRIPTION"
+\&\f(CW\*(C`rebuild\-gcj\-db\*(C'\fR is a script that merges the per-solib databases made by
+\&\f(CW\*(C`aot\-compile\*(C'\fR into one system-wide database so \f(CW\*(C`gij\*(C'\fR can find the 
+solibs.
+.SH "OPTIONS"
+.IX Header "OPTIONS"
+.SH "SEE ALSO"
+.IX Header "SEE ALSO"
+\&\fIgcc\fR\|(1), \fIgcj\fR\|(1), \fIgcjh\fR\|(1), \fIjcf\-dump\fR\|(1), \fIgfdl\fR\|(7),
+and the Info entries for \fIgcj\fR and \fIgcc\fR.
+.SH "COPYRIGHT"
+.IX Header "COPYRIGHT"
+Copyright (c) 2001\-2014 Free Software Foundation, Inc.
+.PP
+Permission is granted to copy, distribute and/or modify this document
+under the terms of the \s-1GNU\s0 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
+man page \fIgfdl\fR\|(7).
+.PP
+(a) The \s-1FSF\s0's Front-Cover Text is:
+.PP
+.Vb 1
+\&     A GNU Manual
+.Ve
+.PP
+(b) The \s-1FSF\s0's Back-Cover Text is:
+.PP
+.Vb 3
+\&     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.
+.Ve
diff --git a/gcc-4.9/gcc/doc/sourcebuild.texi b/gcc-4.9/gcc/doc/sourcebuild.texi
index 85ef819c7..914860813 100644
--- a/gcc-4.9/gcc/doc/sourcebuild.texi
+++ b/gcc-4.9/gcc/doc/sourcebuild.texi
@@ -1428,6 +1428,10 @@ Target supports a vector widening multiplication of @code{short} operands
 into @code{int} results, or can promote (unpack) from @code{short} to
 @code{int} and perform non-widening multiplication of @code{int}.
 
+@item vect_widen_mult_si_to_di_pattern
+Target supports a vector widening multiplication of @code{int} operands
+into @code{long} results.
+
 @item vect_sdot_qi
 Target supports a vector dot-product of @code{signed char}.