aboutsummaryrefslogtreecommitdiffstats
path: root/gcc-4.9/gcc/doc
diff options
context:
space:
mode:
Diffstat (limited to 'gcc-4.9/gcc/doc')
-rw-r--r--gcc-4.9/gcc/doc/aot-compile.1209
-rw-r--r--gcc-4.9/gcc/doc/arm-acle-intrinsics.texi10
-rw-r--r--gcc-4.9/gcc/doc/arm-neon-intrinsics.texi2
-rw-r--r--gcc-4.9/gcc/doc/cpp.11046
-rw-r--r--gcc-4.9/gcc/doc/cpp.info5602
-rw-r--r--gcc-4.9/gcc/doc/cppinternals.info1029
-rw-r--r--gcc-4.9/gcc/doc/extend.texi13
-rw-r--r--gcc-4.9/gcc/doc/fsf-funding.7193
-rw-r--r--gcc-4.9/gcc/doc/g++.121501
-rw-r--r--gcc-4.9/gcc/doc/gc-analyze.1231
-rw-r--r--gcc-4.9/gcc/doc/gcc.121501
-rw-r--r--gcc-4.9/gcc/doc/gcc.info56908
-rw-r--r--gcc-4.9/gcc/doc/gcc.texi3
-rw-r--r--gcc-4.9/gcc/doc/gccinstall.info4679
-rw-r--r--gcc-4.9/gcc/doc/gccint.info50307
-rw-r--r--gcc-4.9/gcc/doc/gcj-dbtool.1247
-rw-r--r--gcc-4.9/gcc/doc/gcj.1593
-rw-r--r--gcc-4.9/gcc/doc/gcj.info3653
-rw-r--r--gcc-4.9/gcc/doc/gcov-tool.texi189
-rw-r--r--gcc-4.9/gcc/doc/gcov.1733
-rw-r--r--gcc-4.9/gcc/doc/generic.texi10
-rw-r--r--gcc-4.9/gcc/doc/gfdl.71
-rw-r--r--gcc-4.9/gcc/doc/gfortran.11411
-rw-r--r--gcc-4.9/gcc/doc/gij.1295
-rw-r--r--gcc-4.9/gcc/doc/gpl.7850
-rw-r--r--gcc-4.9/gcc/doc/grmic.1222
-rw-r--r--gcc-4.9/gcc/doc/install.texi38
-rw-r--r--gcc-4.9/gcc/doc/invoke.texi352
-rw-r--r--gcc-4.9/gcc/doc/jcf-dump.1217
-rw-r--r--gcc-4.9/gcc/doc/jv-convert.1210
-rw-r--r--gcc-4.9/gcc/doc/md.texi10
-rw-r--r--gcc-4.9/gcc/doc/options.texi4
-rw-r--r--gcc-4.9/gcc/doc/rebuild-gcj-db.1181
-rw-r--r--gcc-4.9/gcc/doc/sourcebuild.texi3
-rw-r--r--gcc-4.9/gcc/doc/tm.texi7
-rw-r--r--gcc-4.9/gcc/doc/tm.texi.in7
36 files changed, 611 insertions, 171856 deletions
diff --git a/gcc-4.9/gcc/doc/aot-compile.1 b/gcc-4.9/gcc/doc/aot-compile.1
deleted file mode 100644
index 1afeb5837..000000000
--- a/gcc-4.9/gcc/doc/aot-compile.1
+++ /dev/null
@@ -1,209 +0,0 @@
-.\" 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/arm-acle-intrinsics.texi b/gcc-4.9/gcc/doc/arm-acle-intrinsics.texi
index e68f4cd20..8c5523ed5 100644
--- a/gcc-4.9/gcc/doc/arm-acle-intrinsics.texi
+++ b/gcc-4.9/gcc/doc/arm-acle-intrinsics.texi
@@ -4,6 +4,10 @@
@subsubsection CRC32 intrinsics
+These intrinsics are available when the CRC32 architecture extension is
+specified, e.g. when the @option{-march=armv8-a+crc} switch is used, or when
+the target processor specified with @option{-mcpu} supports it.
+
@itemize @bullet
@item uint32_t __crc32b (uint32_t, uint8_t)
@*@emph{Form of expected instruction(s):} @code{crc32b @var{r0}, @var{r0}, @var{r0}}
@@ -25,8 +29,7 @@
@itemize @bullet
@item uint32_t __crc32d (uint32_t, uint64_t)
@*@emph{Form of expected instruction(s):} Two @code{crc32w @var{r0}, @var{r0}, @var{r0}}
-instructions for AArch32. One @code{crc32w @var{w0}, @var{w0}, @var{x0}} instruction for
-AArch64.
+instructions.
@end itemize
@itemize @bullet
@@ -50,6 +53,5 @@ AArch64.
@itemize @bullet
@item uint32_t __crc32cd (uint32_t, uint64_t)
@*@emph{Form of expected instruction(s):} Two @code{crc32cw @var{r0}, @var{r0}, @var{r0}}
-instructions for AArch32. One @code{crc32cw @var{w0}, @var{w0}, @var{x0}} instruction for
-AArch64.
+instructions.
@end itemize
diff --git a/gcc-4.9/gcc/doc/arm-neon-intrinsics.texi b/gcc-4.9/gcc/doc/arm-neon-intrinsics.texi
index 67f84e096..56987e4a6 100644
--- a/gcc-4.9/gcc/doc/arm-neon-intrinsics.texi
+++ b/gcc-4.9/gcc/doc/arm-neon-intrinsics.texi
@@ -2,8 +2,6 @@
@c This is part of the GCC manual.
@c For copying conditions, see the file gcc.texi.
-@c This file is generated automatically using gcc/config/arm/neon-docgen.ml
-@c Please do not edit manually.
@subsubsection Addition
@itemize @bullet
diff --git a/gcc-4.9/gcc/doc/cpp.1 b/gcc-4.9/gcc/doc/cpp.1
deleted file mode 100644
index 0c34e8453..000000000
--- a/gcc-4.9/gcc/doc/cpp.1
+++ /dev/null
@@ -1,1046 +0,0 @@
-.\" 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
deleted file mode 100644
index dcb300666..000000000
--- a/gcc-4.9/gcc/doc/cpp.info
+++ /dev/null
@@ -1,5602 +0,0 @@
-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
deleted file mode 100644
index 391787ef2..000000000
--- a/gcc-4.9/gcc/doc/cppinternals.info
+++ /dev/null
@@ -1,1029 +0,0 @@
-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 169857fc9..dfdedb617 100644
--- a/gcc-4.9/gcc/doc/extend.texi
+++ b/gcc-4.9/gcc/doc/extend.texi
@@ -376,6 +376,8 @@ 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.
+This alternative with label differences is not supported for the AVR target,
+please use the first approach for AVR programs.
The @code{&&foo} expressions for the same label might have different
values if the containing function is inlined or cloned. If a program
@@ -9914,9 +9916,6 @@ when the @option{-mfpu=neon} switch is used:
@node ARM ACLE Intrinsics
@subsection ARM ACLE Intrinsics
-These built-in intrinsics for the ARMv8-A CRC32 extension are available when
-the @option{-march=armv8-a+crc} switch is used:
-
@include arm-acle-intrinsics.texi
@node AVR Built-in Functions
@@ -11336,7 +11335,7 @@ used. All of them generate the machine instruction that is part of the
name.
@smallexample
-v32qi __builtin_ia32_mpsadbw256 (v32qi,v32qi,v32qi,int)
+v32qi __builtin_ia32_mpsadbw256 (v32qi,v32qi,int)
v32qi __builtin_ia32_pabsb256 (v32qi)
v16hi __builtin_ia32_pabsw256 (v16hi)
v8si __builtin_ia32_pabsd256 (v8si)
@@ -11571,8 +11570,8 @@ The following built-in functions are available when @option{-mxop} is used.
@smallexample
v2df __builtin_ia32_vfrczpd (v2df)
v4sf __builtin_ia32_vfrczps (v4sf)
-v2df __builtin_ia32_vfrczsd (v2df, v2df)
-v4sf __builtin_ia32_vfrczss (v4sf, v4sf)
+v2df __builtin_ia32_vfrczsd (v2df)
+v4sf __builtin_ia32_vfrczss (v4sf)
v4df __builtin_ia32_vfrczpd256 (v4df)
v8sf __builtin_ia32_vfrczps256 (v8sf)
v2di __builtin_ia32_vpcmov (v2di, v2di, v2di)
@@ -13573,8 +13572,6 @@ double __builtin_rsqrt (double);
uint64_t __builtin_ppc_get_timebase ();
unsigned long __builtin_ppc_mftb ();
double __builtin_unpack_longdouble (long double, int);
-double __builtin_longdouble_dw0 (long double);
-double __builtin_longdouble_dw1 (long double);
long double __builtin_pack_longdouble (double, double);
@end smallexample
diff --git a/gcc-4.9/gcc/doc/fsf-funding.7 b/gcc-4.9/gcc/doc/fsf-funding.7
deleted file mode 100644
index 9e91dee51..000000000
--- a/gcc-4.9/gcc/doc/fsf-funding.7
+++ /dev/null
@@ -1,193 +0,0 @@
-.\" 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
deleted file mode 100644
index 1ed57fcbb..000000000
--- a/gcc-4.9/gcc/doc/g++.1
+++ /dev/null
@@ -1,21501 +0,0 @@
-.\" 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
deleted file mode 100644
index a446a65ef..000000000
--- a/gcc-4.9/gcc/doc/gc-analyze.1
+++ /dev/null
@@ -1,231 +0,0 @@
-.\" 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
deleted file mode 100644
index 1ed57fcbb..000000000
--- a/gcc-4.9/gcc/doc/gcc.1
+++ /dev/null
@@ -1,21501 +0,0 @@
-.\" 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
deleted file mode 100644
index 29f054977..000000000
--- a/gcc-4.9/gcc/doc/gcc.info
+++ /dev/null
@@ -1,56908 +0,0 @@
-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 c1f385774..7ae2e75c4 100644
--- a/gcc-4.9/gcc/doc/gcc.texi
+++ b/gcc-4.9/gcc/doc/gcc.texi
@@ -66,6 +66,7 @@ Texts being (a) (see below), and with the Back-Cover Texts being (b)
* gcc: (gcc). The GNU Compiler Collection.
* g++: (gcc). The GNU C++ compiler.
* gcov: (gcc) Gcov. @command{gcov}---a test coverage program.
+* gcov-tool: (gcc) Gcov-tool. @command{gcov-tool}---an offline gcda profile processing program.
@end direntry
This file documents the use of the GNU compilers.
@sp 1
@@ -138,6 +139,7 @@ Introduction, gccint, GNU Compiler Collection (GCC) Internals}.
* Objective-C:: GNU Objective-C runtime features.
* Compatibility:: Binary Compatibility
* Gcov:: @command{gcov}---a test coverage program.
+* Gcov-tool:: @command{gcov-tool}---an offline gcda profile processing program.
* Trouble:: If you have trouble using GCC.
* Bugs:: How, why and where to report bugs.
* Service:: How To Get Help with GCC
@@ -164,6 +166,7 @@ Introduction, gccint, GNU Compiler Collection (GCC) Internals}.
@include objc.texi
@include compat.texi
@include gcov.texi
+@include gcov-tool.texi
@include trouble.texi
@include bugreport.texi
@include service.texi
diff --git a/gcc-4.9/gcc/doc/gccinstall.info b/gcc-4.9/gcc/doc/gccinstall.info
deleted file mode 100644
index 5c8cb8c62..000000000
--- a/gcc-4.9/gcc/doc/gccinstall.info
+++ /dev/null
@@ -1,4679 +0,0 @@
-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
deleted file mode 100644
index c4b7319c9..000000000
--- a/gcc-4.9/gcc/doc/gccint.info
+++ /dev/null
@@ -1,50307 +0,0 @@
-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
deleted file mode 100644
index ab96d585d..000000000
--- a/gcc-4.9/gcc/doc/gcj-dbtool.1
+++ /dev/null
@@ -1,247 +0,0 @@
-.\" 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
deleted file mode 100644
index 7aedab72f..000000000
--- a/gcc-4.9/gcc/doc/gcj.1
+++ /dev/null
@@ -1,593 +0,0 @@
-.\" 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
deleted file mode 100644
index cd5c9b161..000000000
--- a/gcc-4.9/gcc/doc/gcj.info
+++ /dev/null
@@ -1,3653 +0,0 @@
-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-tool.texi b/gcc-4.9/gcc/doc/gcov-tool.texi
new file mode 100644
index 000000000..ff8b9e22f
--- /dev/null
+++ b/gcc-4.9/gcc/doc/gcov-tool.texi
@@ -0,0 +1,189 @@
+@c Copyright (C) 2014 Free Software Foundation, Inc.
+@c This is part of the GCC manual.
+@c For copying conditions, see the file gcc.texi.
+
+@ignore
+@c man begin COPYRIGHT
+Copyright @copyright{} 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 ``GNU General Public License'' and ``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 gfdl(7) man page.
+
+(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.
+@c man end
+@c Set file name and title for the man page.
+@setfilename gcov-tool
+@settitle offline gcda profile processing tool
+@end ignore
+
+@node Gcov-tool
+@chapter @command{gcov-tool}---an Offline Gcda Profile Processing Tool
+
+@command{gcov-tool} is a tool you can use in conjunction with GCC to
+manipulate or process gcda profile files offline.
+
+@menu
+* Gcov-tool Intro:: Introduction to gcov-tool.
+* Invoking Gcov-tool:: How to use gcov-tool.
+@end menu
+
+@node Gcov-tool Intro
+@section Introduction to @command{gcov-tool}
+@c man begin DESCRIPTION
+
+@command{gcov-tool} is an offline tool to process gcc's gcda profile files.
+
+Current gcov-tool supports the following functionalities:
+
+@itemize @bullet
+@item
+merge two sets of profiles with weights.
+
+@item
+read one set of profile and rewrite profile contents. One can scale or
+normalize the count values.
+@end itemize
+
+Examples of the use cases for this tool are:
+@itemize @bullet
+@item
+Collect the profiles for different set of inputs, and use this tool to merge
+them. One can specify the weight to factor in the relative importance of
+each input.
+
+@item
+Rewrite the profile after removing a subset of the gcda files, while maintaining
+the consistency of the summary and the histogram.
+
+@item
+It can also be used to debug or libgcov code as the tools shares the majority
+code as the runtime library.
+@end itemize
+
+Note that for the merging operation, this profile generated offline may
+contain slight different values from the online merged profile. Here are
+a list of typical differences:
+
+@itemize @bullet
+@item
+histogram difference: This offline tool recomputes the histogram after merging
+the counters. The resulting histogram, therefore, is precise. The online
+merging does not have this capability -- the histogram is merged from two
+histograms and the result is an approximation.
+
+@item
+summary checksum difference: Summary checksum uses a CRC32 operation. The value
+depends on the link list order of gcov-info objects. This order is different in
+gcov-tool from that in the online merge. It's expected to have different
+summary checksums. It does not really matter as the compiler does not use this
+checksum anywhere.
+
+@item
+value profile counter values difference: Some counter values for value profile
+are runtime dependent, like heap addresses. It's normal to see some difference
+in these kind of counters.
+@end itemize
+
+@c man end
+
+@node Invoking Gcov-tool
+@section Invoking @command{gcov-tool}
+
+@smallexample
+gcov-tool @r{[}@var{global-options}@r{]} SUB_COMMAND
+@r{[}@var{sub_command-options}@r{]} @var{profile_dir}
+@end smallexample
+
+@command{gcov-tool} accepts the following options:
+
+@ignore
+@c man begin SYNOPSIS
+gcov-tool [@option{-v}|@option{--version}] [@option{-h}|@option{--help}]
+
+gcov-tool merge [merge-options] @var{directory1} @var{directory2}
+ [@option{-v}|@option{--verbose}]
+ [@option{-o}|@option{ --output} @var{directory}]
+ [@option{-w}|@option{--weight} @var{w1,w2}]
+
+gcov-tool rewrite [rewrite-options] @var{directory}
+ [@option{-v}|@option{--verbose}]
+ [@option{-o}|@option{--output} @var{directory}]
+ [@option{-s}|@option{--scale} @var{float_or_simple-frac_value}]
+ [@option{-n}|@option{--normalize} @var{long_long_value}]
+@c man end
+@c man begin SEEALSO
+gpl(7), gfdl(7), fsf-funding(7), gcc(1), gcov(1) and the Info entry for
+@file{gcc}.
+@c man end
+@end ignore
+
+@c man begin OPTIONS
+@table @gcctabopt
+@item -h
+@itemx --help
+Display help about using @command{gcov-tool} (on the standard output), and
+exit without doing any further processing.
+
+@item -v
+@itemx --version
+Display the @command{gcov-tool} version number (on the standard output),
+and exit without doing any further processing.
+
+@item merge
+Merge two profile directories.
+
+@table @gcctabopt
+@item -v
+@itemx --verbose
+Set the verbose mode.
+
+@item -o @var{directory}
+@itemx --output @var{directory}
+Set the output profile directory. Default output directory name is
+@var{merged_profile}.
+
+@item -w @var{w1},@var{w2}
+@itemx --weight @var{w1},@var{w2}
+Set the merge weights of the @var{directory1} and @var{directory2},
+respectively. The default weights are 1 for both.
+@end table
+
+@item rewrite
+Read the specified profile directory and rewrite to a new directory.
+
+@table @gcctabopt
+@item -v
+@itemx --verbose
+Set the verbose mode.
+
+@item -o @var{directory}
+@itemx --output @var{directory}
+Set the output profile directory. Default output name is @var{rewrite_profile}.
+
+@item -s @var{float_or_simple-frac_value}
+@itemx --scale @var{float_or_simple-frac_value}
+Scale the profile counters. The specified value can be in floating point value,
+or simple fraction value form, such 1, 2, 2/3, and 5/3.
+
+@item -n @var{long_long_value}
+@itemx --normalize <long_long_value>
+Normalize the profile. The specified value is the max counter value
+in the new profile.
+
+@end table
+@end table
+
+@c man end
diff --git a/gcc-4.9/gcc/doc/gcov.1 b/gcc-4.9/gcc/doc/gcov.1
deleted file mode 100644
index 8de32cb85..000000000
--- a/gcc-4.9/gcc/doc/gcov.1
+++ /dev/null
@@ -1,733 +0,0 @@
-.\" 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 5b3b528e5..7b1d07797 100644
--- a/gcc-4.9/gcc/doc/generic.texi
+++ b/gcc-4.9/gcc/doc/generic.texi
@@ -1715,6 +1715,7 @@ a value from @code{enum annot_expr_kind}.
@tindex VEC_PACK_TRUNC_EXPR
@tindex VEC_PACK_SAT_EXPR
@tindex VEC_PACK_FIX_TRUNC_EXPR
+@tindex SAD_EXPR
@table @code
@item VEC_LSHIFT_EXPR
@@ -1795,6 +1796,15 @@ 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 @code{COND_EXPR}, all operands are always
evaluated.
+
+@item SAD_EXPR
+This node represents the Sum of Absolute Differences operation. The three
+operands must be vectors of integral types. The first and second operand
+must have the same type. The size of the vector element of the third
+operand must be at lease twice of the size of the vector element of the
+first and second one. The SAD is calculated between the first and second
+operands, added to the third operand, and returned.
+
@end table
diff --git a/gcc-4.9/gcc/doc/gfdl.7 b/gcc-4.9/gcc/doc/gfdl.7
deleted file mode 100644
index 9788f7023..000000000
--- a/gcc-4.9/gcc/doc/gfdl.7
+++ /dev/null
@@ -1 +0,0 @@
-timestamp
diff --git a/gcc-4.9/gcc/doc/gfortran.1 b/gcc-4.9/gcc/doc/gfortran.1
deleted file mode 100644
index 285fdafd7..000000000
--- a/gcc-4.9/gcc/doc/gfortran.1
+++ /dev/null
@@ -1,1411 +0,0 @@
-.\" 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
deleted file mode 100644
index 78c1f4c59..000000000
--- a/gcc-4.9/gcc/doc/gij.1
+++ /dev/null
@@ -1,295 +0,0 @@
-.\" 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
deleted file mode 100644
index 82bee2334..000000000
--- a/gcc-4.9/gcc/doc/gpl.7
+++ /dev/null
@@ -1,850 +0,0 @@
-.\" 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
deleted file mode 100644
index 4706a5c09..000000000
--- a/gcc-4.9/gcc/doc/grmic.1
+++ /dev/null
@@ -1,222 +0,0 @@
-.\" 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 6b45e9d0d..80cb0a90c 100644
--- a/gcc-4.9/gcc/doc/install.texi
+++ b/gcc-4.9/gcc/doc/install.texi
@@ -921,6 +921,18 @@ ideas of what it is for. People use it as if it specified where to
install part of GCC@. Perhaps they make this assumption because
installing GCC creates the directory.
+@item --with-runtime-root-prefix=@var{dirname}
+Specifies that @var{dirname} is to be used as a prefix before paths
+to files used at runtime, such as the path to the dynamic linker.
+For instance, if the dynamic linker is normally @file{/lib/ld.so} and
+this option is given as:
+@smallexample
+--with-runtime-root-prefix=/other
+@end smallexample
+then the compiler will cause compiled executables to use
+@file{/other/lib/ld.so} as their dynamic linker at runtime. This option
+is currently only supported by some targets, notably Linux.
+
@item --with-native-system-header-dir=@var{dirname}
Specifies that @var{dirname} is the directory that contains native system
header files, rather than @file{/usr/include}. This option is most useful
@@ -1787,6 +1799,20 @@ This linker should have plugin support such as gold starting with
version 2.20 or GNU ld starting with version 2.21.
See @option{-fuse-linker-plugin} for details.
+@item --enable-canonical-prefixes
+@itemx --disable-canonical-prefixes
+Enable prefix canonicalization for GCC files that the GCC driver locates
+relative to its own path. Canonicalized prefixes have any @code{/x/../}
+elements removed and symbolic links expanded. This is enabled by default,
+and may be disabled using @option{--disable-canonical-prefixes}.
+See @option{-canonical-prefixes} or @option{-no-canonical-prefixes} for
+more details, including how to override this configuration option when
+compiling.
+
+@item --with-warn-frame-larger-than-extra-text=@var{text}
+Append @samp{@var{text}} to frame size warnings generated by
+the @option{-Wframe-larger-than} warning flag.
+
@item --enable-canonical-system-headers
@itemx --disable-canonical-system-headers
Enable system header path canonicalization for @file{libcpp}. This can
@@ -3008,12 +3034,6 @@ OpenServer/Unixware}.
Solaris 2 (SPARC, Intel):
@itemize
@item
-@uref{http://www.sunfreeware.com/,,Sunfreeware}
-
-@item
-@uref{http://www.blastwave.org/,,Blastwave}
-
-@item
@uref{http://www.opencsw.org/,,OpenCSW}
@item
@@ -3764,9 +3784,9 @@ removed and the system libunwind library will always be used.
@end html
@anchor{aarch64-x-x}
@heading aarch64*-*-*
-Pre 2.24 binutils does not have support for selecting -mabi and does not
-support ILP32. If GCC 4.9 or later is built with pre 2.24, GCC will not
-support option -mabi=ilp32.
+Binutils pre 2.24 does not have support for selecting @option{-mabi} and
+does not support ILP32. If it is used to build GCC 4.9 or later, GCC will
+not support option @option{-mabi=ilp32}.
@html
<hr />
diff --git a/gcc-4.9/gcc/doc/invoke.texi b/gcc-4.9/gcc/doc/invoke.texi
index a74c6c54e..d4ced8484 100644
--- a/gcc-4.9/gcc/doc/invoke.texi
+++ b/gcc-4.9/gcc/doc/invoke.texi
@@ -244,7 +244,7 @@ Objective-C and Objective-C++ Dialects}.
-Wno-deprecated -Wno-deprecated-declarations -Wdisabled-optimization @gol
-Wno-div-by-zero -Wdouble-promotion -Wempty-body -Wenum-compare @gol
-Wno-endif-labels -Werror -Werror=* @gol
--Wfatal-errors -Wfloat-equal -Wformat -Wformat=2 @gol
+-Wfatal-errors -Wfloat-equal -Wforce-warnings -Wformat -Wformat=2 @gol
-Wno-format-contains-nul -Wno-format-extra-args -Wformat-nonliteral @gol
-Wformat-security -Wformat-y2k @gol
-Wframe-larger-than=@var{len} -Wno-free-nonheap-object -Wjump-misses-init @gol
@@ -260,8 +260,9 @@ Objective-C and Objective-C++ Dialects}.
-Woverlength-strings -Wpacked -Wpacked-bitfield-compat -Wpadded @gol
-Wparentheses -Wpedantic-ms-format -Wno-pedantic-ms-format @gol
-Wpointer-arith -Wno-pointer-to-int-cast @gol
--Wredundant-decls -Wno-return-local-addr @gol
--Wreturn-type -Wsequence-point -Wshadow @gol
+-Wredundant-decls -Wno-return-local-addr -Wipa-opt-mismatch @gol
+-Wreturn-type -Wself-assign -Wself-assign-non-pod -Wsequence-point -Wshadow @gol
+-Wshadow-compatible-local -Wshadow-local @gol
-Wsign-compare -Wsign-conversion -Wfloat-conversion @gol
-Wsizeof-pointer-memaccess @gol
-Wstack-protector -Wstack-usage=@var{len} -Wstrict-aliasing @gol
@@ -330,16 +331,19 @@ Objective-C and Objective-C++ Dialects}.
-fenable-@var{kind}-@var{pass} @gol
-fenable-@var{kind}-@var{pass}=@var{range-list} @gol
-fdebug-types-section -fmem-report-wpa @gol
+-fenable-@var{kind}-@var{pass} @gol
+-fenable-@var{kind}-@var{pass}=@var{range-list} @gol
+-fdebug-types-section @gol
-fmem-report -fpre-ipa-mem-report -fpost-ipa-mem-report -fprofile-arcs @gol
+-fprofile-strip=@var{suffix} -frandom-seed=@var{string} -fsched-verbose=@var{n} @gol
-fopt-info @gol
-fopt-info-@var{options}@r{[}=@var{file}@r{]} @gol
--frandom-seed=@var{string} -fsched-verbose=@var{n} @gol
-fsel-sched-verbose -fsel-sched-dump-cfg -fsel-sched-pipelining-verbose @gol
-fstack-usage -ftest-coverage -ftime-report -fvar-tracking @gol
-fvar-tracking-assignments -fvar-tracking-assignments-toggle @gol
-g -g@var{level} -gtoggle -gcoff -gdwarf-@var{version} @gol
-ggdb -grecord-gcc-switches -gno-record-gcc-switches @gol
--gstabs -gstabs+ -gstrict-dwarf -gno-strict-dwarf @gol
+-gmlt -gstabs -gstabs+ -gstrict-dwarf -gno-strict-dwarf @gol
-gvms -gxcoff -gxcoff+ @gol
-fno-merge-debug-strings -fno-dwarf2-cfi-asm @gol
-fdebug-prefix-map=@var{old}=@var{new} @gol
@@ -359,7 +363,8 @@ Objective-C and Objective-C++ Dialects}.
-fassociative-math -fauto-inc-dec -fbranch-probabilities @gol
-fbranch-target-load-optimize -fbranch-target-load-optimize2 @gol
-fbtr-bb-exclusive -fcaller-saves @gol
--fcheck-data-deps -fcombine-stack-adjustments -fconserve-stack @gol
+-fcheck-branch-annotation -fcheck-data-deps -fclone-hot-version-paths @gol
+-fcombine-stack-adjustments -fconserve-stack @gol
-fcompare-elim -fcprop-registers -fcrossjumping @gol
-fcse-follow-jumps -fcse-skip-blocks -fcx-fortran-rules @gol
-fcx-limited-range @gol
@@ -393,12 +398,16 @@ Objective-C and Objective-C++ Dialects}.
-fpartial-inlining -fpeel-loops -fpredictive-commoning @gol
-fprefetch-loop-arrays -fprofile-report @gol
-fprofile-correction -fprofile-dir=@var{path} -fprofile-generate @gol
--fprofile-generate=@var{path} @gol
+-fprofile-generate=@var{path} -fprofile-generate-sampling @gol
-fprofile-use -fprofile-use=@var{path} -fprofile-values -fprofile-reorder-functions @gol
-freciprocal-math -free -frename-registers -freorder-blocks @gol
+-frecord-gcc-switches-in-elf@gol
-freorder-blocks-and-partition -freorder-functions @gol
-frerun-cse-after-loop -freschedule-modulo-scheduled-loops @gol
--frounding-math -fsched2-use-superblocks -fsched-pressure @gol
+-fripa -fripa-disallow-asm-modules -fripa-disallow-opt-mismatch @gol
+-fripa-inc-path-sub=@var{path_mapping} -fripa-no-promote-always-inline-func @gol
+-fripa-verbose -frounding-math @gol
+-fsched2-use-superblocks -fsched-pressure @gol
-fsched-spec-load -fsched-spec-load-dangerous @gol
-fsched-stalled-insns-dep[=@var{n}] -fsched-stalled-insns[=@var{n}] @gol
-fsched-group-heuristic -fsched-critical-path-heuristic @gol
@@ -658,6 +667,7 @@ Objective-C and Objective-C++ Dialects}.
-mtune-ctrl=@var{feature-list} -mdump-tune-features -mno-default @gol
-mfpmath=@var{unit} @gol
-masm=@var{dialect} -mno-fancy-math-387 @gol
+-mcopyrelocs @gol
-mno-fp-ret-in-387 -msoft-float @gol
-mno-wide-multiply -mrtd -malign-double @gol
-mpreferred-stack-boundary=@var{num} @gol
@@ -981,7 +991,7 @@ See RS/6000 and PowerPC Options.
-mpretend-cmove -mtas}
@emph{Solaris 2 Options}
-@gccoptlist{-mimpure-text -mno-impure-text @gol
+@gccoptlist{-mclear-hwcap -mno-clear-hwcap -mimpure-text -mno-impure-text @gol
-pthreads -pthread}
@emph{SPARC Options}
@@ -1473,11 +1483,20 @@ gcc -c -Q -O2 --help=optimizers > /tmp/O2-opts
diff /tmp/O2-opts /tmp/O3-opts | grep enabled
@end smallexample
+@item -canonical-prefixes
+@opindex canonical-prefixes
+Always expand any symbolic links, resolve references to @samp{/../}
+or @samp{/./}, and make the path absolute when generating a relative
+prefix.
+
@item -no-canonical-prefixes
@opindex no-canonical-prefixes
-Do not expand any symbolic links, resolve references to @samp{/../}
+Never expand any symbolic links, resolve references to @samp{/../}
or @samp{/./}, or make the path absolute when generating a relative
-prefix.
+prefix. If neither @option{-canonical-prefixes} nor
+@option{-nocanonical-prefixes} is given, GCC tries to set an appropriate
+default by looking for a target-specific subdirectory alongside the
+directory containing the compiler driver.
@item --version
@opindex version
@@ -3237,6 +3256,11 @@ This option causes the compiler to abort compilation on the first error
occurred rather than trying to keep going and printing further error
messages.
+@item -Wforce-warnings
+@opindex Wforce-warnings
+This option causes the compiler to ignore @option{-Werror} and
+@option{-Werror=} and suppress promotion of warnings to errors.
+
@end table
You can request many specific warnings with options beginning with
@@ -3335,6 +3359,7 @@ Options} and @ref{Objective-C and Objective-C++ Dialect Options}.
-Wpointer-sign @gol
-Wreorder @gol
-Wreturn-type @gol
+-Wripa-opt-mismatch @gol
-Wsequence-point @gol
-Wsign-compare @r{(only in C++)} @gol
-Wstrict-aliasing @gol
@@ -3573,7 +3598,7 @@ If @option{-Wformat} is specified, also warn about @code{strftime}
formats that may yield only a two-digit year.
@end table
-@item -Wnonnull
+@item -Wnonnull @r{(C and Objective-C only)}
@opindex Wnonnull
@opindex Wno-nonnull
Warn about passing a null pointer for arguments marked as
@@ -3771,6 +3796,61 @@ definitions, may be found on the GCC readings page, at
This warning is enabled by @option{-Wall} for C and C++.
+@item -Wself-assign
+@opindex Wself-assign
+@opindex Wno-self-assign
+Warn about self-assignment and self-initialization. This warning is intended
+for detecting accidental self-assignment due to typos, and therefore does
+not warn on a statement that is semantically a self-assignment after
+constant folding. Here is an example of what will trigger a self-assign
+warning and what will not:
+
+@smallexample
+@group
+void func()
+@{
+ int i = 2;
+ int x = x; /* warn */
+ float f = 5.0;
+ double a[3];
+
+ i = i + 0; /* not warn */
+ f = f / 1; /* not warn */
+ a[1] = a[1]; /* warn */
+ i += 0; /* not warn */
+@}
+@end group
+@end smallexample
+
+In C++ it will not warn on self-assignment of non-POD variables unless
+@option{-Wself-assign-non-pod} is also enabled.
+
+@item -Wself-assign-non-pod
+@opindex Wself-assign-non-pod
+@opindex Wno-self-assign-non-pod
+Warn about self-assignment of non-POD variables. This is a C++-specific
+warning and only effective when @option{-Wself-assign} is enabled.
+
+There are cases where self-assignment might be intentional. For example,
+a C++ programmer might write code to test whether an overloaded
+@code{operator=} works when the same object is assigned to itself.
+One way to work around the self-assign warning in such cases when this flag
+is enabled is using the functional form @code{object.operator=(object)}
+instead of the assignment form @code{object = object}, as shown in the
+following example.
+
+@smallexample
+@group
+void test_func()
+@{
+ MyType t;
+
+ t.operator=(t); // not warn
+ t = t; // warn
+@}
+@end group
+@end smallexample
+
@item -Wno-return-local-addr
@opindex Wno-return-local-addr
@opindex Wreturn-local-addr
@@ -3793,6 +3873,16 @@ exceptions are @samp{main} and functions defined in system headers.
This warning is enabled by @option{-Wall}.
+@item -Wripa-opt-mismatch
+@opindex Wripa-opt-mismatch
+@opindex Wno-ripa-opt-mismatch
+When doing an FDO build with @option{-fprofile-use} and @option{-fripa},
+warn if importing an axuiliary module that was built with a different
+GCC command line during the profile-generate phase than the primary
+module.
+
+This warning is enabled by @option{-Wall}.
+
@item -Wswitch
@opindex Wswitch
@opindex Wno-switch
@@ -3905,6 +3995,10 @@ This warning is enabled by @option{-Wall}.
To suppress this warning use the @samp{unused} attribute
(@pxref{Variable Attributes}).
+Note that a classic way to avoid @option{-Wunused-variable} warning is
+using @code{x = x}, but that does not work with @option{-Wself-assign}.
+Use @code{(void) x} or @code{static_cast<void>(x)} instead.
+
@item -Wunused-value
@opindex Wunused-value
@opindex Wno-unused-value
@@ -4351,6 +4445,43 @@ 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.
+@item -Wshadow-local
+@opindex Wshadow-local
+@opindex Wno-shadow-local
+Warn when a local variable shadows another local variable or parameter.
+
+@item -Wshadow-compatible-local
+@opindex Wshadow-compatible-local
+@opindex Wno-shadow-compatible-local
+Warn when a local variable shadows another local variable or parameter
+whose type is compatible with that of the shadowing variable. In C++,
+type compatibility here means the type of the shadowing variable can be
+converted to that of the shadowed variable. The creation of this flag
+(in addition to @option{-Wshadow-local}) is based on the idea that when
+a local variable shadows another one of incompatible type, it is most
+likely intentional, not a bug or typo, as shown in the following example:
+
+@smallexample
+@group
+for (SomeIterator i = SomeObj.begin(); i != SomeObj.end(); ++i)
+@{
+ for (int i = 0; i < N; ++i)
+ @{
+ ...
+ @}
+ ...
+@}
+@end group
+@end smallexample
+
+Since the two variable @code{i} in the example above have incompatible types,
+enabling only @option{-Wshadow-compatible-local} will not emit a warning.
+Because their types are incompatible, if a programmer accidentally uses one
+in place of the other, type checking will catch that and emit an error or
+warning. So not warning (about shadowing) in this case will not lead to
+undetected bugs. Use of this flag instead of @option{-Wshadow-local} can
+possibly reduce the number of warnings triggered by intentional shadowing.
+
@item -Wlarger-than=@var{len}
@opindex Wlarger-than=@var{len}
@opindex Wlarger-than-@var{len}
@@ -4955,6 +5086,12 @@ 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. @option{Wint-to-pointer-cast} is enabled by default.
+@item max-lipo-mem
+When importing auxiliary modules during profile-use, check current
+memory consumption after parsing each auxiliary module. If it exceeds
+this limit (specified in kb), don't import any more auxiliary modules.
+Specifying a value of 0 means don't enforce this limit. This parameter
+is only useful when using @option{-fprofile-use} and @option{-fripa}.
@item -Wno-pointer-to-int-cast @r{(C and Objective-C only)}
@opindex Wno-pointer-to-int-cast
@@ -6236,7 +6373,7 @@ passes).
@item missed
Enable showing missed optimization information (only available in certain
passes).
-@item notes
+@item note
Enable other detailed optimization information (only available in
certain passes).
@item =@var{filename}
@@ -7395,7 +7532,8 @@ 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 @option{-O2}, @option{-O3}.
+Enabled for Alpha, AArch64 and x86 at levels @option{-O2},
+@option{-O3}, @option{-Os}.
@item -flive-range-shrinkage
@opindex flive-range-shrinkage
@@ -8297,6 +8435,10 @@ Also profile feedback must be available to make this option effective. See
Enabled at levels @option{-O2}, @option{-O3}, @option{-Os}.
+@item -freorder-functions=@var{alg}
+@opindex freorder-functions
+This invokes a linker plugin that globally reorders functions in the final binary according to the algorithm specified. Currently, only one type of reordering is supported, @code{callgraph}. This algorithm places functions that are connected by hot callgraph edges closer. This option also enables @option{-ffunction-sections}. Also, profile feedback must be available to makes this option effective. This option emits callgraph edge profile information in special sections named .gnu.callgraph.text. The params variable "gnu-cgraph-section-edge-threshold" can be used to only list edges above a certain threshold.
+
@item -fstrict-aliasing
@opindex fstrict-aliasing
Allow the compiler to assume the strictest aliasing rules applicable to
@@ -8801,6 +8943,24 @@ and occasionally eliminate the copy.
Enabled at levels @option{-O}, @option{-O2}, @option{-O3}, @option{-Os}.
+@item -fauto-profile
+@itemx -fauto-profile=@var{path}
+@opindex fauto-profile
+Enable auto-profile feedback directed optimizations, and optimizations
+generally profitable only with profile feedback available.
+
+The following options are enabled: @code{-fbranch-probabilities},
+@code{-funroll-loops}, @code{-fpeel-loops}.
+
+If @var{path} is specified, GCC will look at the @var{path} to find
+the profile feedback data files. Otherwise, GCC will find fbdata.afdo
+in the current directory.
+
+@item -fcheck-branch-annotation
+@opindex -fcheck-branch-annotation
+Compare branch prediction result and autofdo profile information, store the
+result in a section in the generated elf file.
+
@item -fprofile-correction
@opindex fprofile-correction
Profiles collected using an instrumented binary for multi-threaded programs may
@@ -8833,6 +8993,20 @@ The following options are enabled: @code{-fprofile-arcs}, @code{-fprofile-values
If @var{path} is specified, GCC looks at the @var{path} to find
the profile feedback data files. See @option{-fprofile-dir}.
+@item -fprofile-generate-sampling
+@opindex -fprofile-generate-sampling
+
+Enable sampling for instrumented binaries. Instead of recording every event,
+record only every N-th event, where N (the sampling period) can be set either
+at compile time using
+@option{--param profile-generate-sampling-period=@var{value}}, or at
+execution start time through environment variable @samp{GCOV_SAMPLING_PERIOD}.
+
+At this time sampling applies only to branch counters. A sampling period of 100
+decreases instrumentated binary slowdown from up to 20x for heavily threaded
+applications down to around 2x. @option{-fprofile-correction} is always
+needed with sampling.
+
@item -fprofile-use
@itemx -fprofile-use=@var{path}
@opindex fprofile-use
@@ -8850,6 +9024,59 @@ code.
If @var{path} is specified, GCC looks at the @var{path} to find
the profile feedback data files. See @option{-fprofile-dir}.
+
+@item -fprofile-strip=@var{base_suffix}
+@opindex fprofile-strip
+
+The option causes the compiler to strip @var{base_suffix} from the
+base file name and use that to find the gcda file.
+
+@item -fripa
+@opindex fripa
+Perform dynamic inter-procedural analysis. This is used in conjunction with
+the @option{-fprofile-generate} and @option{-fprofile-use} options.
+During the @option{-fprofile-generate} phase, this flag turns on some additional
+instrumentation code that enables dynamic call-graph analysis.
+During the @option{-fprofile-use} phase, this flag enables cross-module
+optimizations such as inlining.
+
+@item -fripa-disallow-asm-modules
+@opindex fripa-disallow-asm-modules
+During profile-gen, if this flag is enabled, and the module has asm statements,
+arrange so that a bit recording this information will be set in the profile
+feedback data file.
+During profile-use, if this flag is enabled, and the same bit in auxiliary
+module's profile feedback data is set, don't import this auxiliary module.
+If this is the primary module, don't export it.
+
+@item -fripa-disallow-opt-mismatch
+@opindex fripa-disallow-opt-mismatch
+Don't import an auxiliary module, if the GCC command line options used for this
+auxiliary module during the profile-generate stage were different from those used
+for the primary module. Note that any mismatches in warning-related options are
+ignored for this comparison.
+
+@item -fripa-inc-path-sub=@var{path_mapping}
+@opindex fripa-inc-path-sub
+This option allows LIPO profile data associated with one compiler to be usable
+by another compiler at different installation path. A user can use this option
+to specify an include search path mapping so that the compiler can convert include
+search paths stored in gcda files into exisiting paths. The mapping is specified
+as a comma separated sub path pairs in the form: OLD_SUBPATH:NEW_SUBPATH.
+
+@item -fripa-no-promote-always-inline-func
+@opindex fripa-no-promote-always-inline-func
+Do not promote static functions with always inline attribute in LIPO compilation.
+
+@item -fripa-verbose
+@opindex fripa-verbose
+Enable printing of verbose information about dynamic inter-procedural optimizations.
+This is used in conjunction with the @option{-fripa}.
+
+@item -frecord-gcc-switches-in-elf
+@opindex frecord-gcc-switches-in-elf
+Record the command line options in the .gnu.switches.text elf section for sample
+based LIPO to do module grouping.
@end table
The following options control compiler behavior regarding floating-point
@@ -9079,6 +9306,12 @@ whether the result of a complex multiplication or division is @code{NaN
The default is @option{-fno-cx-fortran-rules}.
+@item min-mcf-cancel-iters
+The minimum number of iterations of negative cycle cancellation during
+MCF profile correction before early termination. This parameter is
+only useful when using @option{-fprofile-correction}.
+
+
@end table
The following options control optimizations that may improve
@@ -9171,6 +9404,14 @@ the loop is entered. This usually makes programs run more slowly.
@option{-funroll-all-loops} implies the same options as
@option{-funroll-loops}.
+@item -funroll-codesize-limit
+@opindex funroll-codesize-limit
+Limit loop unrolling of non-const non-FP loops in a profile feedback compilation
+under estimates of a large code footprint. Enabled by default with
+@option{-fprofile-use}. Code size and execution weight thresholds are controlled
+by the @option{unrollpeel-codesize-threshold} and
+@option{unrollpeel-hotness-threshold} parameters.
+
@item -fpeel-loops
@opindex fpeel-loops
Peels loops for which there is enough information that they do not
@@ -9179,6 +9420,14 @@ roll much (from profile feedback). It also turns on complete loop peeling
Enabled with @option{-fprofile-use}.
+@item -fpeel-codesize-limit
+@opindex fpeel-codesize-limit
+Limit loop peeling of non-const non-FP loops in a profile feedback compilation
+under estimates of a large code footprint. Enabled by default with
+@option{-fprofile-use}. Code size and execution weight thresholds are controlled
+by the @option{unrollpeel-codesize-threshold} and
+@option{unrollpeel-hotness-threshold} parameters.
+
@item -fmove-loop-invariants
@opindex fmove-loop-invariants
Enables the loop invariant motion pass in the RTL loop optimizer. Enabled
@@ -9548,12 +9797,27 @@ The maximum number of iterations of a loop to be suitable for complete peeling.
@item max-completely-peel-loop-nest-depth
The maximum depth of a loop nest suitable for complete peeling.
+@item unrollpeel-codesize-threshold
+Maximum profile-based code size footprint estimate for loop unrolling and
+peeling.
+
+@item unrollpeel-hotness-threshold
+Maximum ratio of total execution count to loop entry block count under which
+most profile-based code size estimates will be ignored for loop unrolling and
+peeling.
+
@item max-unswitch-insns
The maximum number of insns of an unswitched loop.
@item max-unswitch-level
The maximum number of branches unswitched in a single loop.
+@item min-iter-unroll-with-branches
+Minimum iteration count to ignore branch effects when unrolling.
+
+@item unroll-outer-loop-branch-budget
+Maximum number of branches allowed in hot outer loop region after unroll.
+
@item lim-expensive
The minimum cost of an expensive expression in the loop invariant motion.
@@ -10010,6 +10274,28 @@ parameter in order to propagate them and perform devirtualization.
@option{ipa-cp-value-list-size} is the maximum number of values and types it
stores per one formal parameter of a function.
+@item ipa-cp-eval-threshold
+IPA-CP calculates its own score of cloning profitability heuristics
+and performs those cloning opportunities with scores that exceed
+@option{ipa-cp-eval-threshold}.
+
+@item ipa-max-agg-items
+IPA-CP is also capable to propagate a number of scalar values passed
+in an aggregate. @option{ipa-max-agg-items} controls the maximum
+number of such values per one parameter.
+
+@item ipa-cp-loop-hint-bonus
+When IPA-CP determines that a cloning candidate would make the number
+of iterations of a loop known, it adds a bonus of
+@option{ipa-cp-loop-hint-bonus} bonus to the profitability score of
+the candidate.
+
+@item ipa-cp-array-index-hint-bonus
+When IPA-CP determines that a cloning candidate would make the index of
+an array access known, it adds a bonus of
+@option{ipa-cp-array-index-hint-bonus} bonus to the profitability
+score of the candidate.
+
@item lto-partitions
Specify desired number of partitions produced during WHOPR compilation.
The number of partitions should exceed the number of CPUs used for compilation.
@@ -10082,6 +10368,14 @@ The default choice depends on the target.
Set the maximum number of existing candidates that will be considered when
seeking a basis for a new straight-line strength reduction candidate.
+@item coverage-callback
+Set to 1 to instrument a callback function together with
+arc counter update. The name of the callback function
+is "__coverage_callback".
+
+@item coverage-exec_once
+Set to 1 to update each arc counter only once.
+
@item asan-globals
Enable buffer overflow detection for global objects. This kind
of protection is enabled by default if you are using
@@ -10194,6 +10488,9 @@ recognize.
If you want to pass an option that takes an argument, you must use
@option{-Xassembler} twice, once for the option and once for the argument.
+@item profile-generate-sampling-rate
+Set the sampling rate with @option{-fprofile-generate-sampling}.
+
@end table
@node Link Options
@@ -10457,6 +10754,11 @@ systems using the GNU linker. On some targets, such as bare-board
targets without an operating system, the @option{-T} option may be required
when linking to avoid references to undefined symbols.
+@item -Xclang-only @var{option}
+@opindex Xclang-only
+Ignore @var{option}. This is used by some custom drivers to pass options
+to Clang but not GCC.
+
@item -Xlinker @var{option}
@opindex Xlinker
Pass @var{option} as an option to the linker. You can use this to
@@ -11188,6 +11490,12 @@ given to GCC, substitutes @code{Y}; else substitutes @code{D}. There can
be as many clauses as you need. This may be combined with @code{.},
@code{,}, @code{!}, @code{|}, and @code{*} as needed.
+@item max-lipo-mem
+When importing auxiliary modules during profile-use, check current
+memory consumption after parsing each auxiliary module. If it exceeds
+this limit (specified in kb), don't import any more auxiliary modules.
+Specifying a value of 0 means don't enforce this limit. This parameter
+is only useful when using @option{-fprofile-use} and @option{-fripa}.
@end table
@@ -14990,6 +15298,15 @@ Control whether or not the compiler uses IEEE floating-point
comparisons. These correctly handle the case where the result of a
comparison is unordered.
+@item -mcopyrelocs
+@itemx -mno-copyrelocs
+@opindex mcopyrelocs
+@opindex mno-copyrelocs
+With @option{-fpie} and @option{fPIE}, copy relocations support allows the
+compiler to assume that all symbol references are local. This allows the
+compiler to skip the GOT for global accesses and this applies only to the
+x86-64 architecture.
+
@item -msoft-float
@opindex msoft-float
Generate output containing library calls for floating point.
@@ -20853,6 +21170,13 @@ patterns. This can result in faster code on the SH4 processor.
These @samp{-m} options are supported on Solaris 2:
@table @gcctabopt
+@item -mclear-hwcap
+@opindex mclear-hwcap
+@option{-mclear-hwcap} tells the compiler to remove the hardware
+capabilities generated by the Solaris assembler. This is only necessary
+when object files use ISA extensions not supported by the current
+machine, but check at runtime whether or not to use them.
+
@item -mimpure-text
@opindex mimpure-text
@option{-mimpure-text}, used in addition to @option{-shared}, tells
diff --git a/gcc-4.9/gcc/doc/jcf-dump.1 b/gcc-4.9/gcc/doc/jcf-dump.1
deleted file mode 100644
index eded14430..000000000
--- a/gcc-4.9/gcc/doc/jcf-dump.1
+++ /dev/null
@@ -1,217 +0,0 @@
-.\" 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
deleted file mode 100644
index a57cc856c..000000000
--- a/gcc-4.9/gcc/doc/jv-convert.1
+++ /dev/null
@@ -1,210 +0,0 @@
-.\" 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 e2fe11b32..8e30aca94 100644
--- a/gcc-4.9/gcc/doc/md.texi
+++ b/gcc-4.9/gcc/doc/md.texi
@@ -4844,6 +4844,16 @@ 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.
+@cindex @code{ssad@var{m}} instruction pattern
+@item @samp{ssad@var{m}}
+@cindex @code{usad@var{m}} instruction pattern
+@item @samp{usad@var{m}}
+Compute the sum of absolute differences of two signed/unsigned elements.
+Operand 1 and operand 2 are of the same mode. Their absolute difference, 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 absolute difference. The result is placed
+in operand 0, which is of the same mode as operand 3.
+
@cindex @code{ssum_widen@var{m3}} instruction pattern
@item @samp{ssum_widen@var{m3}}
@cindex @code{usum_widen@var{m3}} instruction pattern
diff --git a/gcc-4.9/gcc/doc/options.texi b/gcc-4.9/gcc/doc/options.texi
index 938017ade..3b63aa232 100644
--- a/gcc-4.9/gcc/doc/options.texi
+++ b/gcc-4.9/gcc/doc/options.texi
@@ -479,6 +479,10 @@ record. @xref{Option file format}.
The option is omitted from the producer string written by
@option{-grecord-gcc-switches}.
+@item NoDWARFRecord
+The option is omitted from the producer string written by
+@option{-grecord-gcc-switches}.
+
@item PchIgnore
Even if this is a target option, this option will not be recorded / compared
to determine if a precompiled header file matches.
diff --git a/gcc-4.9/gcc/doc/rebuild-gcj-db.1 b/gcc-4.9/gcc/doc/rebuild-gcj-db.1
deleted file mode 100644
index c81d70948..000000000
--- a/gcc-4.9/gcc/doc/rebuild-gcj-db.1
+++ /dev/null
@@ -1,181 +0,0 @@
-.\" 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 7438980f0..39152df27 100644
--- a/gcc-4.9/gcc/doc/sourcebuild.texi
+++ b/gcc-4.9/gcc/doc/sourcebuild.texi
@@ -1295,6 +1295,9 @@ Target has 64-bit @code{double}.
@item double64plus
Target has @code{double} that is 64 bits or longer.
+@item longdouble128
+Target has 128-bit @code{long double}.
+
@item int32plus
Target has @code{int} that is at 32 bits or longer.
diff --git a/gcc-4.9/gcc/doc/tm.texi b/gcc-4.9/gcc/doc/tm.texi
index f3c0c14a9..28029a14c 100644
--- a/gcc-4.9/gcc/doc/tm.texi
+++ b/gcc-4.9/gcc/doc/tm.texi
@@ -3947,6 +3947,13 @@ which.
@c above is overfull. not sure what to do. --mew 5feb93 did
@c something, not sure if it looks good. --mew 10feb93
+@defmac INCOMING_REG_PARM_STACK_SPACE (@var{fndecl})
+Like @code{REG_PARM_STACK_SPACE}, but for incoming register arguments.
+Define this macro if space guaranteed when compiling a function body
+is different to space required when making a call, a situation that
+can arise with K&R style function definitions.
+@end defmac
+
@defmac OUTGOING_REG_PARM_STACK_SPACE (@var{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
diff --git a/gcc-4.9/gcc/doc/tm.texi.in b/gcc-4.9/gcc/doc/tm.texi.in
index fb26c1f41..a59abba17 100644
--- a/gcc-4.9/gcc/doc/tm.texi.in
+++ b/gcc-4.9/gcc/doc/tm.texi.in
@@ -3498,6 +3498,13 @@ which.
@c above is overfull. not sure what to do. --mew 5feb93 did
@c something, not sure if it looks good. --mew 10feb93
+@defmac INCOMING_REG_PARM_STACK_SPACE (@var{fndecl})
+Like @code{REG_PARM_STACK_SPACE}, but for incoming register arguments.
+Define this macro if space guaranteed when compiling a function body
+is different to space required when making a call, a situation that
+can arise with K&R style function definitions.
+@end defmac
+
@defmac OUTGOING_REG_PARM_STACK_SPACE (@var{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